simeononsecurity

Module 1: Red Team Methodology

Sat, 12 Sep 2026 00:00:00 +0000

Red team methodology connects an agreed business question to a controlled test and evidence the customer is able to use. This course uses seven phases to organize the work, with feedback between phases as observations change the plan. Your outcome is an evidence-backed conclusion, an explained limit, and a verified restoration record.

Allow 25 minutes for reading and 30 minutes for the tabletop exercise. No attack tooling is required for this module.

Learning Outcomes #

Recall the phases: place a technique within a larger operation.
Explain the objective: distinguish access, business impact, and assessment evidence.
Apply a planning method: connect an approved action to a specific observation.
Evaluate a result: distinguish prevention, missing telemetry, and insufficient evidence.
Create a test plan: define entry conditions, stopping points, cleanup, and acceptance criteria.

The Seven Phases #

The seven-phase model is this course’s organizing convention. It is not the MITRE ATT&CK matrix, an official maturity score, or a guarantee of one correct sequence. An operation often returns to reconnaissance after a new observation, and some tests finish without persistence or a domain-controller objective.

Phase	Main question	Deliverable
Mission preparation	What is authorized and ready?	Scope, test conditions, contacts, and infrastructure inventory
Open-source intelligence	What does public information support?	Attributed observations with confidence and collection dates
Active reconnaissance	What does interaction with the approved environment reveal?	A bounded target and dependency map
Target exploitation	Does the selected route produce the intended test condition?	Reproducible evidence of success, prevention, or a limit
Post exploitation	Which approved objective follows from the obtained context?	An access path and its observed effects
Cleanup and backout	What must be removed or restored?	Artifact ledger, backout actions, and baseline verification
Mission objective and reporting	What did the assessment prove?	Findings, restoration evidence, and remediation priorities

Cleanup, backout, and reporting begin during preparation. They are not tasks postponed until the final day. An operation lacking an artifact register, original-state record, or timestamps is difficult to explain even when the technical action succeeds.

Objectives Before Techniques #

A mission objective states the question the assessment is intended to answer. “Obtain administrator access” is incomplete unless it explains which business or control outcome the access tests. A customer might instead need evidence about segregation between application roles or the ability to recognize one defined behavior.

Illustrative objective: Determine whether a synthetic finance user is permitted to read a restricted sample report outside their role. The sample report contains no real financial data. Success means the test establishes an access-control result and collects enough evidence to reproduce the conclusion.

Weak objective	More useful formulation
Get a shell	Determine whether the approved entry route reaches the designated lab execution context
Become domain admin	Evaluate the named privilege boundary supporting the agreed business scenario
Avoid detection	Measure which approved behaviors produce telemetry, alerts, and analyst action
Exfiltrate data	Demonstrate the approved data path using a designated synthetic marker and transfer limit

An objective also defines when to stop. If a sample-file read answers the question, copying an entire share adds data exposure without improving the finding. The test plan should identify the minimum proof before an operator reaches the resource.

Use ATT&CK Precisely #

MITRE ATT&CK provides a vocabulary for adversary behavior. A tactic describes an adversary goal, while a technique describes behavior supporting a goal. Map a specific observation to a technique when the evidence supports it, then retain the actual procedure and environment details alongside the mapping. MITRE guidance on adversary emulation and red teaming

A technique identifier is not a test result. Listing an identifier does not establish whether an action executed, whether a sensor recorded it, or whether an analyst understood it. Different implementations of a related behavior also exercise different prerequisites and telemetry.

Every test needs a question, a bounded action, and evidence supporting its conclusion

Preparation and Scope #

Mission preparation establishes the assets, actions, identities, and time windows included in the exercise. It also records exclusions, data-handling rules, operational contacts, and the restoration process. NIST’s assessment guidance provides a planning reference for these decisions. NIST SP 800-115

Deconfliction is the process for comparing suspicious activity with the team’s authorized actions. A matching source address alone is weak evidence. Use timestamps, action identifiers, hosts, accounts, and operator records to distinguish the exercise from an unrelated incident.

Planning item	Example decision
Target boundary	Only the named lab application and two test accounts
Permitted action	Attempt a read of the designated synthetic report
Stop condition	An unrelated production record appears
Contact	Named exercise controller and a tested backup channel
Restoration	Remove test grants and verify the baseline role assignments

Scope changes require a recorded decision. A newly reachable system or interesting credential is an observation, not an extension of the approved target list. Bring the observation to the exercise controller before treating it as another test step.

OSINT and Active Reconnaissance #

Open-source intelligence (OSINT) uses publicly available information. Its collection method determines whether it touches customer-controlled infrastructure. Reading an archived page differs from browsing the customer’s live site, and public content still produces access logs when requested directly.

Active reconnaissance deliberately interacts with a target to answer a specific question. The important distinction is the collection path and the resulting evidence, not an absolute claim about generating zero alerts. Document both third-party sources and direct interactions.

Collection	Likely observation point	Limitation
Third-party archive	Archive provider	Historical content might be stale
Public registration record	Registry or lookup provider	Ownership does not establish test authorization
Live customer webpage	Customer web or proxy logs	Public access is still direct interaction
Approved service probe	Target network and service logs	A response establishes only the tested condition

Reconnaissance produces hypotheses. A banner suggesting an older product version is a lead to validate, not proof of an exploitable vulnerability. A missing response likewise does not prove a host is absent.

Exploitation and Post Exploitation #

Target exploitation tests a selected route within the agreed conditions. Select the route because it answers the objective and fits the risk constraints. There is no requirement to demonstrate every possible weakness or to persist after every successful entry.

Post exploitation evaluates the context obtained after access. Identity, privilege, reachable resources, and dependencies determine which approved next step is meaningful. Extra persistence or lateral movement adds work and artifacts, so it needs a reason tied to the scenario.

Result	Useful next decision
Route prevented	Preserve prevention evidence and determine whether another route is part of scope
Low-privilege access obtained	Record the context and test the permitted objective
Objective already satisfied	Stop expansion and validate evidence and restoration
Unexpected sensitive access	Pause and use the agreed deconfliction channel

A domain controller is one possible dependency, not the destination of every operation. The assessment might finish at a file-server permission boundary or a cloud application’s role check. Explain the business significance of the result instead of treating domain control as a universal score.

Supplemental Video #

Watch: Adversary Emulation: Generating MITRE ATT&CK Technique Sequences , presented by Martin Eian and published by FIRST. The presentation examines dependencies between techniques when assembling an emulation sequence. Use it to assess why a list of behaviors needs an execution plan.

Viewing task: Pick two behaviors from a fictional scenario and write the prerequisite connecting them. Then identify one condition under which the second behavior would be irrelevant. Compare the dependency with the objective instead of assuming a longer sequence is a better test.

Evidence Has Several Stages #

Execution, collection, alerting, and response are different outcomes. A successful test action might produce an event without generating an alert. An alert might exist without reaching an analyst inside the evaluation window. Report each observed stage separately.

Stage	Evidence needed
Action executed	Operator record and observed target-side result
Telemetry collected	Relevant event present at the expected sensor or collector
Detection generated	Alert tied to the test’s entity and time
Analyst response	Case activity showing interpretation and an action
Restoration verified	Comparison against the agreed baseline

An empty search is not a detection verdict. The event might be missing because logging was disabled, collection failed, timestamps differ, or the search selected the wrong host. Resolve these possibilities before classifying a control gap.

Illustrative reasoning: A file-access exercise succeeds at 10:05 UTC. The operator has a screenshot, but the analyst searches local time and finds no event. The first follow-up is time and collection correlation, not a claim of undetected access.

Cleanup and Backout #

Cleanup removes artifacts owned by the exercise. Backout returns modified systems to the agreed baseline. The two actions overlap, but they are not identical. A newly created test value might be removed, while a pre-existing permission change needs its recorded original value restored.

Plan the backout before the first state change. Record the owner, original value, affected process, trigger, evidence location, and verification step. Preserve customer logs and assessment evidence according to the engagement agreement. Backout does not mean erasing the record of what happened.

Backout item	Required evidence
Created artifact	Ownership record, removal result, and absence check
Modified setting	Original value, narrow restoration, and comparison
Running process	Process owner, stop action, and later state
Service or task	Configuration baseline, state, and trigger retest
Customer evidence	Retention decision and report reference

Backout completion is a finding, not an assumption. Mark each item verified, unresolved, or retained by agreement. If another administrator changed the same object, pause the reversal and use the named owner to resolve the conflict.

Exercise: Add a cleanup and backout section to the synthetic finance-report test card. List one created artifact, one modified setting, one running process, and the evidence proving each final state. State the condition preventing backout from proceeding safely.

Expected reasoning: The artifact register determines ownership. The original-state record determines restoration. A process check determines whether the removed trigger left an existing instance running. A conflict with a later administrator change requires owner review rather than an automatic overwrite.

Design One Bounded Test #

Use this test-card template before a tabletop or lab exercise:

Business question:
Approved assets and identities:
Required starting context:
Behavior and ATT&CK mapping, if justified:
Permitted action and maximum scope:
Expected operator-side evidence:
Expected defender-side observation:
Stop conditions and controller contact:
Restoration steps and verification:
Observed result, limitations, and next decision:

Micro emulation plans provide examples of narrowly scoped tests organized around specific behaviors. Their value is repeatability and an explicit relationship between action and observation. Adapt the idea to the customer question rather than treating a public plan as approval to run it. MITRE Center for Threat-Informed Defense project

Exercise: Create a card for the synthetic finance-report scenario. Include an authorized reader and a restricted reader, the exact sample resource, a collection window, and the restoration check. Record what would establish a permission problem and what would leave the result inconclusive.

Evaluate Your Test Card #

Expected reasoning: The authorized reader establishes a baseline for the resource’s availability. The restricted reader tests the intended access boundary. A successful unauthorized read supports the access-control finding, while a timeout requires investigation before it supports any permission conclusion.

Improve the plan by adding one controlled variation. For example, repeat the same read after correcting the sample folder permission. Keep the identities, resource, and collection method stable so the comparison answers a clear question.

Review question	A useful answer contains
What is being tested?	A named business or control boundary
What changes?	One explicit action or configuration difference
What proves the result?	Evidence from the relevant layer
What ends the test?	A success condition, limit, or stop rule
What remains afterward?	An artifact inventory and verified baseline

Self-Check #

Seven phases: Which phases repeat after new evidence appears?
OSINT: Why does publicly available information not imply zero interaction?
ATT&CK: What does a technique identifier leave unspecified?
Post exploitation: When is additional persistence unnecessary?
Negative result: What must you examine before calling an action undetected?

Answer key: Reconnaissance and planning repeat as the situation changes. Public resources still have collection paths and access logs. ATT&CK identifiers leave procedure, prerequisites, and actual test results to document.

Operation decisions: Persistence is unnecessary when the objective does not require it. An undetected-action claim needs verified execution, appropriate collection, a valid search, and a defined observation window. Cleanup and backout need their own final-state evidence.

Next Steps #

Keep your test card and refine its infrastructure and deconfliction requirements in Module 2: Mission Preparation and Infrastructure . Return to the course hub for the module sequence.

Read More at https://simeononsecurity.com/

CompTIA A+ (220-1201): Mobile Devices

Wed, 01 Jan 2025 00:00:00 +0000

Click Here to Return To the CompTIA A+ Course Page

Mobile Devices is 13% of the CompTIA A+ 220-1201 Core 1 exam. This module covers laptop hardware repair, accessories, connectivity, mobile device management, and synchronization. Mobile support is daily work at any help desk, so know the parts and the settings cold.

Laptops, smartphones, and tablets pack desktop power into sealed, compact bodies. You repair them with the right replacement parts, connect them with the right cables and radios, and manage them with policy. This module builds the hands-on knowledge you need to support users on the move.

Laptop Hardware and Components #

You replace failed parts inside laptops. Unlike desktops, laptop parts are small, often glued, and model-specific.

Component	Replacement notes
Battery	Lithium-ion, often glued in. A swollen battery is a fire risk and a mandatory replacement
Keyboard	Often riveted to the chassis on thin models
RAM	Uses SODIMM modules, smaller than desktop DIMMs
Storage	M.2 NVMe, 2.5-inch SATA, or soldered storage
Wireless card	Mini-PCIe or M.2 with antenna leads

Always power down, unplug, and use an ESD strap before opening a laptop. Document screw locations because they vary in length and placement.

Display Components #

Laptop displays combine several layers you must identify.

LCD panel types trade cost for quality: TN is cheap and fast but has poor angles, VA offers deep contrast, and IPS delivers the best color and viewing angles.
OLED lights each pixel individually for true blacks and higher contrast.
Touchscreen digitizers sit on top of the panel and convert touch into input.
Inverters powered backlights on older CCFL displays, while modern panels use LED backlights.
A webcam and microphone live in the top bezel, with Wi-Fi antenna wires routed through the display hinges.

Accessories and Connectivity #

You connect mobile devices with the right ports and protocols.

Connection	Use
USB-C	Reversible connector for data, video, and power delivery
Lightning	Older Apple connector for charging and data
NFC	Short-range tap for payments and pairing
Bluetooth	Wireless peripherals like headsets and keyboards
Hotspot/Tethering	Shares a phone’s cellular data with other devices

USB-C with Power Delivery charges laptops and phones over one cable. Bluetooth pairing requires the device to be discoverable, then confirmed on both ends.

Mobile Network Connectivity #

You configure how devices reach the internet and the carrier.

Cellular data spans 3G, 4G/LTE, and 5G. Newer generations support higher peak rates, but actual service depends on coverage, spectrum, device, and congestion.
A SIM or eSIM holds the subscriber identity that authenticates the device on the carrier network.
A hotspot turns the device into a Wi-Fi access point for other devices.
Airplane mode changes radio settings for flights or troubleshooting. Check the device because Wi-Fi or Bluetooth might remain available or be turned back on separately.

Location services combine GPS satellites with cellular and Wi-Fi positioning for faster, indoor-capable location fixes. Disabling GPS saves battery but breaks maps and find-my-device features.

Mobile Device Management and Synchronization #

You manage fleets of devices with policy and keep their data in sync.

Mobile Device Management (MDM) pushes settings, apps, and security policy to corporate and BYOD (bring your own device) phones. MDM enforces passcodes, remote wipe, and encryption from a central console.

Synchronization keeps mail, calendar, and contacts consistent across devices. You sync to the cloud, to a desktop, or to an automobile.

Sync target	Example
Cloud	Microsoft 365, iCloud, Google
Desktop	Local backup over USB
Automobile	Contacts and media over Bluetooth or USB

Watch data caps because large syncs over cellular can cost the user money.

Next Steps #

Continue Core 1 with Networking Fundamentals and Hardware Components . When devices fail, apply Hardware and Network Troubleshooting . For a hardened mobile platform, read how to install GrapheneOS . Return to the CompTIA A+ Course and review tips for passing CompTIA exams .

Read More at https://simeononsecurity.com/

Module 2: Mission Preparation and Infrastructure

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Mission preparation makes an assessment reproducible and controllable before the first test action. Scope, contacts, infrastructure ownership, evidence storage, and teardown belong in the same plan. This module turns the methodology test card into an operational readiness record.

Allow 25 minutes for reading and 30 minutes for a preparation review. Complete Module 1 and use your own isolated lab for technical checks.

Learning Outcomes #

Define scope: name approved assets, accounts, actions, and time windows.
Explain dependencies: separate the management path, assessment traffic, and evidence storage.
Inspect readiness: verify the paths the test depends on without assuming a webpage proves everything works.
Resolve uncertainty: pause for a recorded decision when a dependency or target is ambiguous.
Create an asset register: account for ownership, expiration, collection, and removal.

Scope Is More Than Addresses #

An address list is only one part of scope. An approved IP might host several tenants, a public hostname might point to a shared provider, and a login might expose both permitted and excluded resources. Record the relevant identities and actions as well as network locations.

Rules of engagement (ROE) describe how the assessment is conducted. The document should connect the objective, permitted work, exclusions, contacts, and response to unexpected events. NIST provides a rules-of-engagement template and assessment-planning guidance. NIST SP 800-115

Boundary	Example entry
Assets	Named lab hosts and an application tenant identifier
Identities	Two designated synthetic accounts
Actions	Approved discovery and one sample-file permission test
Time	Explicit start, pause, and end times with a time zone
Exclusions	Production customer data and unrelated tenants
Limits	Maximum requests, data volume, and permitted configuration changes

Asset ownership and authorization are separate facts. A registration record, DNS response, or customer brand on a page is insufficient to establish permission to test the underlying service. Record any required provider or tenant authorization through the agreed engagement process.

Make Stop Conditions Operational #

A stop condition names an observable event and an immediate response. “Be careful” is not a useful instruction. “Pause if the sample query returns a real customer record, preserve the minimal incident reference, and contact the controller” is specific enough for another operator to follow.

A restart decision also needs an owner. After a pause, document what changed, who approved resumption, and which actions remain permitted. A timed outage window expiring does not silently renew itself.

Trigger	Immediate action	Decision owner
Unexpected production data	Stop collection and preserve the minimal reference	Exercise controller
Service health degrades	Pause the action and record timestamps	Service owner and controller
Unrecognized callback or host	Stop interaction pending scope verification	Controller
Customer reports an incident	Compare records through the deconfliction channel	Incident lead

Deconfliction should work during an outage. Test a backup contact path which does not depend on the same application or network under assessment. Record who is able to stop work when the primary controller is unavailable.

Separate Infrastructure Roles #

The operator workstation is the management endpoint. A team server coordinates the assessment platform when one is used. A redirector forwards an approved traffic path, while an evidence store retains the records required for analysis and reporting. Some labs combine roles, but their permissions and failure dependencies still differ.

A redirector is not a guarantee of anonymity. Hosting, DNS, certificates, network logs, and server administration produce records. Its placement should follow the authorized test architecture and the customer’s expected observation points.

Map ownership and allowed communication for every assessment component

Role	Required inventory detail
Operator endpoint	Responsible operator, authentication, and approved management access
Assessment server	Owner, version, listeners, and retention settings
Redirector	Domain, address, forwarding purpose, and expiration
Evidence store	Access list, encryption, retention, and deletion owner
Target dependency	Service owner, test boundary, and restoration contact

Choose the smallest sufficient topology. A second approved path helps only if it addresses a real dependency and has its own cleanup plan. Two hosts on one provider, account, or network still share failure conditions. Redundancy is a design decision, not a fixed required number of servers.

Build a Lab Redirector #

Create the redirector as a small public edge VM in the customer-approved cloud account or provider account. Keep it separate from the operator workstation, assessment server, and target network. Select a region and jurisdiction approved by the engagement owner. A nearby region reduces avoidable latency, while provider reputation, data handling, and ownership matter more than a particular country.

The redirector should have one public address and one narrowly defined upstream path. Put the assessment server behind a private tunnel or an allowlisted origin address. Do not place the redirector inside the customer production network, give it a broad internal route, or reuse it as the evidence store. Those choices turn a forwarding host into an unnecessary bridge.

Placement decision	Recommended lab choice
Public edge	Separate low-cost VM in the approved provider account
Origin	Assessment server on a private tunnel or fixed allowlist
Management	Provider console or restricted admin source, separate from test traffic
Ingress	TCP 80/443 only when the test requires them
Egress	Origin address and approved update or monitoring services
Expiration	Provider, address, domain, certificate, and VM teardown dates

For a benign HTTP exercise, install Nginx on the edge VM and proxy one named test path to a harmless origin service. The configuration below is a template for a disposable lab. Replace the example names and address with values in the connection matrix.

sudo apt update
sudo apt install nginx
sudo install -d -m 0750 /etc/nginx/lab
sudoedit /etc/nginx/sites-available/lab-redirector

server {
    listen 80;
    server_name redirector.lab.example;

    access_log /var/log/nginx/lab-redirector.access.log;
    error_log /var/log/nginx/lab-redirector.error.log warn;

    location = /healthz {
        add_header Content-Type text/plain;
        return 200 "lab redirector ready\n";
    }

    location /lab/ {
        proxy_pass http://10.30.0.10:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Request-ID $request_id;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Enable the single site, check the syntax, and reload only after the configuration review:

sudo ln -s /etc/nginx/sites-available/lab-redirector /etc/nginx/sites-enabled/lab-redirector
sudo nginx -t
sudo systemctl reload nginx

The origin address must be reachable from the redirector through the approved path. An RFC 1918 address in proxy_pass requires a private tunnel or a routed lab network. It does not create connectivity by itself. The origin should expose only the harmless test service and accept traffic from the redirector’s fixed address.

Test each leg with a unique request identifier. First query the edge health endpoint, then request the lab path, and finally compare the edge and origin logs. Do not use a payload, credential collector, or unrestricted forward rule for this readiness test.

curl --fail http://redirector.lab.example/healthz
curl --fail -H 'X-Lab-Request: prep-001' http://redirector.lab.example/lab/healthz
sudo journalctl -u nginx --since '5 minutes ago'

Expected result: The health endpoint returns the fixed readiness text. The second request appears in the edge access log and the origin log with the same test identifier. A successful edge response without an origin record indicates a configuration, route, or collection problem. These commands are documentation examples for an authorized lab.

For HTTPS, use a certificate whose name matches the approved test domain and record its issuer, renewal owner, and expiry. Keep certificate automation separate from the test path. Validate TLS from the same client class used by the exercise, then preserve the certificate and access-log references in the readiness register. Nginx proxy module documentation

Backout for the redirector is part of the build. Remove the enabled site, reload Nginx, revoke or delete the test certificate, remove the DNS record, destroy the VM, and verify the provider account has no remaining address, firewall rule, snapshot, or access key. Retain the agreed logs and teardown evidence instead of deleting the assessment record.

Protect Management and Evidence #

Management access should expose only the services and sources needed by the assessment team. Define inbound and outbound requirements independently. A rule permitting all traffic from a broad customer subnet is different from a narrowly scoped management rule.

Protect the records as well as the listener. Assessment data includes credentials, screenshots, transcripts, and customer configuration. Restrict access to the people who need it, keep secrets out of command histories and shared notes, and document a retention deadline. NIST assessment data-handling guidance

Control	Readiness question
Authentication	Does each operator have accountable access?
Network policy	Are necessary sources, destinations, ports, and address families explicit?
Host updates	Are the selected versions and relevant maintenance decisions recorded?
Secret storage	Are operational secrets separated from general documentation?
Evidence access	Is the reviewer able to read the required records without broad administrative access?
Recovery	Is a known recovery path available before firewall or service changes?

Do not apply an incomplete firewall snippet remotely. A copied default-drop sequence often omits established connections, loopback, management recovery, IPv6, or required infrastructure traffic. Review the actual policy against a connection matrix and test it from a recoverable lab console.

Inspect Listening Services #

On your Linux assessment server, inspect current listeners and nftables policy without changing either:

sudo ss -lntup
sudo nft list ruleset

ss reports socket information. -l selects listeners, -n keeps numeric addresses, -t and -u include TCP and UDP, and -p requests process information. Permissions affect which process details appear. ss manual

nft list ruleset displays nftables configuration. Interpret an empty output in the context of the host’s actual firewall stack and any provider firewall. A host-level ruleset alone does not describe every control on the network path. Netfilter ruleset-management documentation

Expected exercise result: Every listening socket has a documented purpose and owner. An unexpected listener is a finding to explain before launch, not something to terminate blindly. Compare the output with the connection matrix and preserve the timestamp.

Verify Each Connection Leg #

A browsable HTTPS endpoint establishes only the behavior of the request you sent. It does not establish the management path, an internal forwarding rule, the intended application exchange, or evidence collection. Test the intended path in a closed range using harmless test traffic.

Leg	Check	Evidence
Name resolution	Resolve the approved domain through the intended resolver	Name, address, resolver, and time
TLS endpoint	Check the certificate and successful negotiation	Hostname, validity, and observed endpoint
Forwarded request	Send the designated harmless lab request	Matching ingress and application records
Management path	Authenticate through the approved operator route	Operator identity and access log
Evidence collection	Locate the test record in the chosen store	Record identifier and collection time

Correlation beats assumption. Give the harmless test request a unique lab identifier and follow it through the expected logs. If the public endpoint succeeds but the downstream record is absent, investigate forwarding or collection before treating the entire path as ready.

Domains, Certificates, and Mail #

A TLS certificate supports authentication of the endpoint named in the certificate under the client’s trust rules. It does not certify the purpose or authorization of an assessment. Domain categorization also does not guarantee a filtering product permits traffic. Verify actual policy behavior in the approved test conditions.

A mail exercise needs a separate delivery plan. Record the sending service, approved recipients, expected message handling, and reporting channel. Begin with an inert message and a synthetic destination so routing and attribution are checked before the campaign-specific work in Module 10.

Item	What to record
Domain	Registrant or responsible owner, purpose, and expiration
Certificate	Subject names, issuer, validity, and renewal owner
Mail sender	Account, sending service, authentication, and permitted recipients
Delivery test	Message identifier, expected route, and observed result
Teardown	Required revocation, removal, and evidence of completion

Reputation is not a substitute for measurement. A newly registered domain being blocked is a meaningful observation about the tested policy. Whether the test should continue through another route depends on the objective and a recorded controller decision.

Supplemental Video #

Watch: Micro Emulation Plans: Making Adversary Emulation Accessible , published by SANS Offensive Operations and featured by the MITRE Center for Threat-Informed Defense . Use the discussion of bounded tests to identify which infrastructure a particular objective needs.

Viewing task: Choose one proposed test and list its required identities, hosts, network paths, and observations. Remove components which do not support the test. Explain the remaining dependencies and how the operator would recognize a failed prerequisite.

Rehearse Deconfliction #

Tabletop scenario: At 14:20 UTC, the customer reports an unexpected connection from an address assigned to the exercise. Your notes contain a different destination and a test completed ten minutes earlier. The address is shared by two approved operators.

Expected reasoning: The shared source is insufficient attribution. Compare the destination, time, account, process or request identifier, and each operator’s record. Pause relevant activity while the incident lead determines whether the event belongs to the assessment. Do not label unmatched activity as yours to simplify the conversation.

Exercise and action ID:
Time, time zone, and known clock offset:
Operator and approved source:
Target asset and account context:
Intended action and expected effect:
Observed result and evidence reference:
Unexpected behavior:
Pause/resume decision and owner:

Review the rehearsal by checking whether another operator reconstructs the sequence from the record alone. Missing timestamps or shared anonymous access make the record less useful. Correct those gaps before the launch decision.

Create the Readiness Register #

Build one row per asset using the template below. Include temporary domains, provider accounts, test identities, storage locations, and any persistent assessment component. An artifact absent from the register is easy to miss during teardown.

Asset identifier and purpose:
Owner and approved operator:
Address / domain / tenant / host:
Required inbound and outbound paths:
Authentication and secret location:
Evidence and retention location:
Expiration or removal deadline:
Recovery and teardown procedure:
Verification result and reviewer:

Go/no-go exercise: Your listeners are reachable, but the backup contact has not been tested and the evidence store rejects writes. Decide whether the operational prerequisites are satisfied. Separate technical connectivity from the ability to control and document the assessment.

Expected answer: The launch criteria are incomplete. Fix the failed evidence path, test the contact path, and record the verification. A functional connection alone does not satisfy the preparation requirements.

Next Steps #

Retain the readiness register alongside the Module 1 test card. Continue with Module 3: Networking and Active Directory Foundations to interpret the connections and identities the plan depends on. Return to the course hub for the complete sequence.

Read More at https://simeononsecurity.com/

CompTIA A+ (220-1201): Networking Fundamentals

Wed, 01 Jan 2025 00:00:00 +0000

Click Here to Return To the CompTIA A+ Course Page

Networking is 23% of the CompTIA A+ 220-1201 Core 1 exam, the second-largest domain. This module covers ports and protocols, wireless standards, host services, network hardware, SOHO setup, and tools. Memorize the common ports because the exam tests them directly.

Every support call eventually touches the network. You diagnose connectivity by knowing which protocol runs on which port, how wireless bands differ, and what each device on the wire does. This module gives you that foundation.

Common Ports and Protocols #

You must know these ports by number. TCP is connection-oriented and reliable, while UDP is connectionless and fast.

Port	Protocol	Purpose
20/21	FTP	File transfer
22	SSH/SFTP	Secure remote shell
23	Telnet	Insecure remote shell
25	SMTP	Sending email
53	DNS	Name resolution
67/68	DHCP	IP address assignment
80	HTTP	Web traffic
110	POP3	Receiving email
143	IMAP	Receiving email
443	HTTPS	Encrypted web traffic
445	SMB	File and printer sharing
3389	RDP	Remote desktop

Telnet and FTP send data in clear text, so prefer SSH and HTTPS.

Wireless Networking #

You match the band and standard to the environment.

Band	Trait
2.4 GHz	Longer range, slower, more interference
5 GHz	Faster, shorter range, less crowded
6 GHz	Newest, widest channels, Wi-Fi 6E and 7

The 802.11 standards advance over time: 802.11n (Wi-Fi 4), 802.11ac (Wi-Fi 5), 802.11ax (Wi-Fi 6/6E), and 802.11be (Wi-Fi 7). Short-range radios include NFC for tap actions and RFID for tags and badges.

On 2.4 GHz, use non-overlapping channels 1, 6, and 11 to avoid interference.

Services Provided by Networked Hosts #

You identify what each server role does on the network.

DNS resolves names to IP addresses.
DHCP hands out IP addresses, gateways, and DNS servers automatically.
File servers store shared documents centrally.
Print servers queue jobs to shared printers.
Proxy servers filter and cache web requests.
Web servers host sites and applications.

You configure DNS records so services resolve correctly:

Record	Maps
A	Name to IPv4 address
AAAA	Name to IPv6 address
CNAME	Name to another name (alias)
MX	Domain to mail server
TXT	Text for SPF, DKIM, verification

Networking Hardware #

You connect and route traffic with the right device.

A switch forwards frames between devices on the same LAN by MAC address.
A router moves packets between networks and to the internet.
An access point (AP) bridges wireless clients onto the wired network.
A firewall filters traffic by rules at the boundary.
Power over Ethernet (PoE) delivers power and data over one cable to APs, cameras, and phones.

SOHO Network Configuration #

You set up small office and home networks with correct addressing.

Address type	Use
Static	Manually set, for servers and printers
Dynamic (DHCP)	Auto-assigned, for clients
APIPA	169.254.x.x self-assigned when DHCP fails
IPv6	128-bit addresses for modern networks

A private IP range such as 192.168.0.0/16 stays inside the LAN, while NAT translates it to one public address for internet access.

Networking Tools #

You build and test cabling with the right tools.

Tool	Job
Crimper	Attaches RJ45 connectors to cable
Cable tester	Verifies wiring continuity and order
Toner probe	Traces a cable in a bundle
Punchdown tool	Seats wires into patch panels and jacks
Wi-Fi analyzer	Maps signal strength and channel use
Loopback plug	Tests a network port

Next Steps #

Continue Core 1 with Hardware Components and Virtualization and Cloud Computing . Diagnose connectivity in Hardware and Network Troubleshooting . For home wireless design, see the best Wi-Fi mesh system for consumers and Ubiquiti UniFi vs TP-Link Omada . Return to the CompTIA A+ Course .

Read More at https://simeononsecurity.com/

Module 3: Networking and Active Directory Foundations

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Network reachability, authentication, and authorization answer different questions. A reachable server does not prove an account is valid, and a successful login does not grant every permission. This module connects web transports, directory services, DNS, and group membership so you diagnose the right layer before choosing a tool.

Allow 25 minutes for reading and 20 minutes for a small domain-lab exercise. You need basic IP addressing and access to your own Windows lab.

Learning Outcomes #

Distinguish layers: separate an application protocol from its transport and encryption.
Explain the domain: identify the roles of DNS, a domain controller, and a resource server.
Trace permissions: follow a group-membership path to an explicit resource permission.
Interpret failure: distinguish name resolution, connection, authentication, and access denial.
Create an evidence map: connect observations without assuming a complete attack path.

Protocols Have Different Jobs #

TCP provides an ordered byte stream with mechanisms for acknowledging and retransmitting data. UDP sends datagrams without TCP’s connection and delivery mechanisms. An application using UDP still implements additional reliability or security when its protocol requires it. TCP specification, RFC 9293

Layer	Example	Question it answers
Naming	DNS	Which address or service location corresponds to this name?
Transport	TCP or UDP	How are bytes or datagrams carried?
Channel protection	TLS	How is the connection authenticated and protected?
Application	HTTP, SMB, LDAP	What operation does the client request?

A port number is a clue, not proof of the application behind it. A TCP listener on port 443 still needs protocol validation. A service moved to another port keeps its application behavior, and a proxy often presents a different network endpoint from the underlying application.

HTTP, TLS, and Visibility #

HTTPS protects HTTP traffic using a secure channel. TLS provides confidentiality and integrity for application data and supports authentication of the communicating endpoints. The protection applies between the endpoints of the TLS connection, including an inspecting proxy when one terminates the connection. TLS 1.3 specification, RFC 8446

Encryption does not establish ordinary behavior. A network observer still has connection-level information such as destination addresses, timing, and traffic volume. Endpoint tools and a configured inspection proxy have different visibility. A rarely used destination or an unusual initiating process remains relevant even when the content is encrypted.

Observation	Reasonable conclusion	Unsupported conclusion
TLS negotiation succeeds	The tested TLS connection was established	The application is trustworthy
TCP port 443 is reachable	Something accepts connections there	All application requests will succeed
HTTP body contains binary data	The application transfers binary content	The transfer is malicious because it is not readable text
No plaintext in a capture	The capture lacks clear application content	Defenders have no other evidence

HTTP is not limited to text pages. Images, compressed bodies, software downloads, and application data are ordinary uses of HTTP. A claim about command-and-control traffic needs evidence from the application, endpoint, or traffic pattern, rather than a blanket assumption about binary data.

HTTP/3 also corrects the shortcut “web traffic always uses TCP.” It maps HTTP semantics onto QUIC, which uses UDP. Distinguish the application protocol from its transport before interpreting a capture or proposing a firewall rule. HTTP/3 specification, RFC 9114

Read a TCP Exchange #

Client                    Server
SYN --------------------->
    <--------------------- SYN-ACK
ACK --------------------->
Application data -------->

The three-way handshake establishes a TCP connection. It does not prove authentication to the application or permission to read its data. A connection failure belongs to a different diagnostic stage from a valid application response denying access.

A burst of connection attempts deserves interpretation in context. Destination count, port distribution, time interval, and the initiating application help distinguish a scan from an expected inventory job. Completing the handshake does not make scanning invisible, and a SYN scan is not inherently undetectable either.

What Active Directory Stores #

Active Directory Domain Services (AD DS) stores directory objects and supports identity, authentication, and administration for a domain environment. A domain controller (DC) runs those services and participates in directory replication. A deployment normally includes multiple domain controllers rather than a single universal database server. Microsoft AD DS overview

A domain is not a subnet. Systems in different routed networks belong to the same domain, while systems sharing a subnet belong to different domains or no domain. Separate logical identity structure from packet-routing structure in your notes.

Object or role	Purpose
User account	Represents a person or application identity
Computer account	Represents a domain-joined machine identity
Security group	Collects principals for rights or permissions
Organizational unit	Organizes objects for delegation and policy application
Domain controller	Provides directory and authentication services
Resource server	Hosts the share, application, or other resource being accessed

Domain-controller access is not every engagement’s objective. An assessment might instead test access to one application role, a file share, or an approved synthetic record. Domain controllers are sensitive dependencies, and local workstation account secrets are not simply copies of the domain account database.

DNS Finds Domain Services #

DNS service records help clients locate domain controllers and domain services. A directory operation depends on more than reaching an IP address. The client also needs appropriate naming, routing, time, authentication, and permission for the requested action. Microsoft domain-controller location process

Worked failure: A workstation reaches a file server’s address but cannot resolve the domain’s service records through its configured resolver. This supports investigating DNS configuration before calling the account invalid. Record the resolver and query result, then compare them with the intended lab configuration.

Reachability, authentication, and permission require separate evidence

Groups and Effective Access #

Security groups support permission assignments to collections of accounts and other groups. Distribution groups serve a different purpose and are not security principals for permission assignment. Group scope constrains valid membership and where permissions apply. Microsoft security-group documentation

Group names are not permission evidence. A group called Finance Admins needs an actual rights assignment or resource permission before the name establishes anything useful. A direct account entry in an access-control list is also possible. The common administrative preference for groups does not prohibit permissions assigned to an individual account.

Illustrative lab access path:
LAB\Alice
  -> member of Finance-Readers
  -> member of Reports-Read
  -> explicit read permission on a sample report folder

The membership path is only part of the decision. Inspect the intended operation, the resource’s access-control entries, and the token used for the attempt. File access through a share involves both share and filesystem permissions. Membership changes also need an appropriate session or token refresh before testing their effect.

Evidence	What it contributes
Directory membership	A relationship between an account and group
Current access token	Group information available to the running process
Resource permissions	Rights granted or denied on the target object
Observed operation	The result for the exact action and context tested

Illustrative decision: Alice belongs to Reports-Read and successfully reads a sample file. This proves the read operation under the tested context. It does not prove write access, local administrator rights, or access to another share with a similar name.

Supplemental Video #

Watch: Active Directory Domain Service Deep Dive , by John Savill’s Technical Training. Use the architecture explanation to connect domains, forests, and domain controllers. Record the logical relationship between the components before studying the later technique-specific modules.

Viewing task: Draw two domain controllers in one domain and two member servers on different subnets. Explain which relationship is directory membership and which relationship is network reachability. Your diagram should work without treating a subnet as a domain boundary.

Observe a Lab Connection #

Use PowerShell on your domain-joined lab workstation. Replace the example names with your own approved domain and server:

Resolve-DnsName -Name _ldap._tcp.dc._msdcs.lab.example -Type SRV
Test-NetConnection -ComputerName files.lab.example -Port 445
whoami /groups

Resolve-DnsName asks for the specified DNS record type. Test-NetConnection tests the selected TCP destination and reports connection information. whoami /groups shows group information in your current context. None of these commands proves permission to a particular file. Resolve-DnsName reference , Test-NetConnection reference

Record actual results. A successful TCP test indicates reachability for this connection attempt, while an unsuccessful one has several possible causes. Name resolution, routing, firewall policy, and a stopped service belong in the differential diagnosis. Do not label every failure “bad credentials.”

Work Through a Failure #

Scenario: A lab user resolves the file server, connects to port 445, and receives access denied when opening a sample report. Another approved lab user reads the same file successfully. No network or account changes have yet been made.

Check	Observation	Next inference
Name resolution	Both users resolve the same server	Compare the remaining layers
Transport	Both connect to TCP 445	A basic connection is available
Identity	The users present different accounts	Confirm which token and authentication were used
Resource operation	One read succeeds and one fails	Compare the exact permissions and context

Expected reasoning: The successful second read makes a universal service outage less likely. By itself, it does not identify the missing permission or establish whether the denied operation failed authentication or authorization. Inspect the resource and correlated records before recommending a change.

Create a dependency record for this scenario or your own lab observation. Include resolver, destination, protocol, account authority, requested operation, result, and the next evidence needed. This record becomes the starting point for the Windows identity module.

Self-Check #

HTTPS: Which observations remain available outside the encrypted content?
HTTP/3: Why is “all web traffic uses TCP” inaccurate?
Directory structure: Does one subnet imply one domain?
Group nesting: What additional evidence turns a membership chain into a supported access claim?
Connection success: What has a successful TCP 445 test left untested?

Answer key: Addresses, timing, and volume remain useful, and endpoint or proxy visibility differs from a passive capture. HTTP/3 uses QUIC over UDP. A domain and a subnet describe different structures.

Access checks: A membership chain needs the relevant token, permissions, and requested operation. TCP reachability leaves application authentication and authorization unproven.

Next Steps #

Keep the dependency map beside your lab notes. It helps separate a naming problem from a credential or permission problem. Continue with Module 4: Windows Internals and Authentication , or return to the course hub .

Read More at https://simeononsecurity.com/

CompTIA A+ (220-1201): Hardware Components

Wed, 01 Jan 2025 00:00:00 +0000

Click Here to Return To the CompTIA A+ Course Page

Hardware is 25% of the CompTIA A+ 220-1201 Core 1 exam, the largest Core 1 domain. This module covers cables, RAM, storage, motherboards, CPUs, power supplies, and printers. This domain is the hands-on heart of A+, so learn the parts by sight and by spec.

Hardware is the physical foundation of every system you support. You pick the right RAM, install the correct drive, seat a CPU without bending pins, and size a power supply that will not fail under load. This module covers the components you touch every day.

Cables and Connectors #

You match each cable to its job.

Cable	Use
Cat 5e/6/6a	Copper Ethernet, RJ45 connector
Fiber (single-mode)	Long distance, SC/LC connectors
Fiber (multimode)	Short distance, higher bandwidth
USB-C	Reversible data, power, and video
SATA	Internal drive data
HDMI/DisplayPort	Digital video and audio

Single-mode fiber carries one light path over long distances. Multimode fiber carries many paths over short runs inside a building.

RAM Characteristics #

You install the right memory for the board and workload.

DIMM modules go in desktops, SODIMM modules go in laptops.
DDR generations are not interchangeable: DDR3, DDR4, and DDR5 use different notches and voltages.
ECC (Error-Correcting Code) RAM detects and fixes memory errors in servers, while desktops use non-ECC.
Channel configuration (single, dual, quad) boosts bandwidth when you populate matched slots.

Install matched pairs in the correct colored slots to enable dual-channel mode.

Storage Devices #

You choose storage by speed, interface, and form factor.

Drive	Interface	Speed
HDD	SATA	Slowest, mechanical
SATA SSD	SATA	Faster, no moving parts
NVMe SSD	PCIe (M.2)	Fastest

RAID combines drives for speed or redundancy:

Level	Behavior	Minimum drives
RAID 0	Striping, speed, no redundancy	2
RAID 1	Mirroring, full redundancy	2
RAID 5	Striping with parity	3
RAID 6	Double parity	4
RAID 10	Mirror plus stripe	4

RAID is not a backup. It protects against drive failure, not against deletion or ransomware.

Motherboards, CPUs, and Add-on Cards #

You install the core components and configure firmware.

Form factors set board size: ATX is full-size, microATX is smaller, and Mini-ITX is the smallest. CPU architecture spans x86/x64 for desktops and servers and ARM for phones, tablets, and modern laptops.

You set firmware in BIOS/UEFI: boot order, virtualization support, Secure Boot, and a TPM for encryption keys. UEFI supports modern boot features, including Secure Boot, but does not require a graphical interface or mouse. Booting from a volume larger than 2 TB also depends on partition layout, firmware, operating system, and device support.

Common UEFI settings to know:
- Boot order / boot priority
- Secure Boot (on/off)
- TPM / fTPM enable
- Intel VT-x / AMD-V virtualization
- XMP/EXPO memory profile

Power Supplies #

You size the power supply unit (PSU) to the system load with headroom. You match input voltage (110V/230V), wattage, and connector types (24-pin ATX, 8-pin CPU, PCIe for GPUs). An undersized PSU causes random shutdowns under load.

Printers #

You deploy and maintain multiple printer types.

Type	How it prints	Maintenance
Laser	Toner fused by heat	Replace toner, maintenance kit
Inkjet	Sprayed liquid ink	Clean heads, replace cartridges
Thermal	Heat on special paper	Replace paper, clean heating element
Impact	Pins strike a ribbon	Replace ribbon, used for carbon copies

The laser imaging process has seven steps: processing, charging, exposing, developing, transferring, fusing, and cleaning. You configure drivers, network connectivity, and secure features like PIN-released printing.

Next Steps #

Continue Core 1 with Virtualization and Cloud Computing and diagnose failures in Hardware and Network Troubleshooting . Review Networking Fundamentals for cabling context. Return to the CompTIA A+ Course and review tips for passing CompTIA exams .

Read More at https://simeononsecurity.com/

Module 4: Windows Internals and Authentication

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Windows security context determines which account a process represents, which objects it is permitted to access, and which user profile it reads. This module connects registry paths, security identifiers, access tokens, and authentication. You will inspect a disposable Windows VM and produce an identity record before changing anything.

Allow 25 minutes for reading and 20 minutes for the optional lab. Complete the networking and Active Directory module first.

Learning Outcomes #

Identify registry context: distinguish predefined keys from the loaded hives behind them.
Read a token: separate account identity, group membership, and enabled privileges.
Explain authentication artifacts: distinguish an NT password hash from a network challenge response and a Kerberos ticket.
Check an observation: use account authority, SID, process context, and timestamps together.
Create a context record: document the identity and registry view behind each lab observation.

The Registry Model #

The registry organizes operating-system and application configuration into keys and named values. A key contains subkeys and values, while each value has a name, a type, and data. A path identifies a location, but the process context and registry view determine what a particular program reads.

Term	Meaning	Example
Key	Container for subkeys and values	`Software\ExampleApp`
Value name	Identifier within a key	`DisplayMode`
Value type	Interpretation of the data	`REG_SZ` for a string
Value data	Stored setting	`Light`
Hive	Logical registry collection with backing files	A loaded user profile hive

A hive is more specific than a top-level name displayed in Registry Editor. For example, HKEY_LOCAL_MACHINE, abbreviated HKLM, groups several machine hives. A user’s NTUSER.DAT backs much of their user configuration. Microsoft registry-hive documentation

Predefined Keys and Profiles #

HKEY_USERS, abbreviated HKU, exposes loaded user hives. It is not an inventory of every account ever used on the machine. An existing profile on disk and a currently loaded hive are different observations.

HKEY_CURRENT_USER, abbreviated HKCU, resolves through the calling process’s user context. Do not equate it with the person sitting at the keyboard. Microsoft also documents limitations around cached predefined handles and impersonation, so programs impersonating a client need the appropriate user-key API. Microsoft predefined-key documentation

Calling context	Important question
Alice’s ordinary application	Which Alice account and SID launched this process?
Application elevated as Alice	Did elevation change privileges while retaining Alice’s identity?
Application started as Bob	Is the application reading Bob’s profile instead?
LocalSystem service	Is the code using its service context or explicitly opening another user’s loaded hive?

Worked example: Alice’s startup entry is present in her profile. A LocalSystem service reads its own HKCU location and finds no matching value. This establishes a context mismatch, not successful removal of Alice’s entry. Record Alice’s SID and verify her specific loaded hive before drawing a conclusion.

The same desktop session contains processes with different identities and privileges

SIDs Identify Principals #

A security identifier (SID) identifies an account or group. A display name is a label, while the SID is the identifier Windows uses in access-control decisions. Deleting and recreating an account with the same name produces a different identity. Microsoft security-identifier documentation

Local and domain accounts require an authority as well as a name. LABPC\Alice and LAB\Alice represent different accounts even if their display names match. Do not infer account origin from the apparent length of its SID. Local and domain account SIDs use comparable structures.

LAB\Alice              Domain account, down-level name
LABPC\Alice            Local account on LABPC
Alice@lab.example      User principal name, when configured

User principal name (UPN) suffixes are configured identity names and need not match a workstation’s DNS suffix. A nonexistent prefix does not universally trigger local authentication. The logon interface, authentication provider, and requested account determine the result, including failure. Microsoft user-name formats

Processes and Access Tokens #

An access token describes a process or thread’s security context. It includes an account SID, group SIDs, privileges, and other security attributes. A process has a primary token, while a thread performing impersonation has an additional context to consider. Microsoft access-token documentation

Identity and permission are different questions. Knowing which account launched a program does not establish whether its current token authorizes a particular operation. Group attributes, privilege state, the requested operation, and the target object’s access-control entries all matter.

Observation	What it establishes	What remains unresolved
Account belongs to Administrators	Administrative group membership	Whether this process holds an elevated token
Privilege appears in a token	The token contains the privilege	Whether it is enabled and relevant to this operation
Process runs as LocalSystem	A highly privileged local identity	Access to every remote service or protected resource
Thread impersonates a client	A separate thread context is involved	Which context the specific API uses

User Account Control (UAC) adds another distinction. In Admin Approval Mode, an administrator normally starts applications with a filtered token and elevates selected operations. An elevated process remains subject to security checks. Microsoft explanation of UAC

Supplemental Video #

Watch: Windows Access Tokens - From Authentication to Exploitation , published by Compass Security. Use the token explanation to distinguish account identity from the privileges available to a particular process. The accompanying presentations page provides the speaker’s material.

Viewing task: Draw a process with its primary token and a thread with an impersonation token. Explain why a username alone is insufficient evidence for predicting an access check. Compare your diagram with Microsoft’s access-token reference before moving to the lab.

Inspect Your Own Context #

Run these read-only commands in Command Prompt on your own Windows lab VM:

whoami /user
whoami /groups
whoami /priv
whoami /all

whoami /user reports the account and SID. /groups shows group information, /priv shows privileges, and /all combines current-token details. Save output from the ordinary shell before opening an elevated shell for comparison. Microsoft whoami reference

Expected reasoning: Under same-account elevation, the account SID should remain the same while token details differ. If the elevation prompt uses another account, compare the new account’s SID instead. An observed difference needs an explanation tied to the login path, not a blanket rule about administrator usernames.

Read the Registry Context #

Inspect the current profile without adding or removing values:

reg query "HKCU\Volatile Environment"
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
reg query HKU

reg query reads the named key. A missing Run key or an empty result is not an error in the exercise, since the profile might contain no startup entries there. Record the account, path, return message, and time instead of inventing an expected value. Microsoft reg query reference

Do not change user context mid-comparison. First relate the whoami result to the current-profile query. Then compare a second explicitly identified lab account if available. The point is to prove which identity produced the observation, not to obtain a privileged session.

Hashes, Responses, and Tickets #

An NT password hash is derived from a password and is distinct from the challenge-response messages exchanged during NTLM authentication. Two identical passwords produce identical NT hashes under the same derivation. A captured NTLMv2 response is not interchangeable with the stored NT hash. Microsoft NTLM protocol overview

Pass-the-hash describes authentication using suitable password-derived material without recovering the plaintext password. Its applicability depends on the protocol, account, policy, and target service. It does not mean any hash authenticates to any application. MITRE ATT&CK: Pass the Hash

Artifact	Purpose	Avoid this confusion
NT password hash	Password-derived secret used by relevant authentication mechanisms	A generic file hash
NTLM challenge response	Proof computed for an authentication exchange	The stored password hash
Kerberos ticket	Credential for a ticket-based exchange	A plaintext password
Access token	Local security context used for authorization	A network authentication packet

Kerberos separates initial authentication from obtaining service tickets. Domain membership alone does not establish which protocol a particular connection used. Read the corresponding authentication evidence instead of assuming every Windows connection uses NTLM. Microsoft Kerberos overview

Place Credential Storage Correctly #

Local account material belongs to the machine’s local account database, while domain account material is maintained by Active Directory. A workstation also holds authentication state and, depending on configuration, cached domain-logon information. These are different artifacts with different uses and protections. Microsoft credential-storage explanation

Credential availability is conditional. Privilege alone does not guarantee readable plaintext passwords or every account’s secret. Credential isolation, protected processes, sign-in method, and current session state change what exists and what an administrator is permitted to inspect. The lab needs no credential dump to demonstrate the distinction.

Question	Appropriate evidence
Which account is this?	Authority, account name, and SID
Which process context applies?	Token details from the relevant process
Which authentication occurred?	Authentication package and correlated logon records
Which registry data was read?	Full path, loaded profile, process architecture, and timestamp

Identity Is More Than IP #

DHCP assigns address leases and other network settings. An address often stays the same across renewals, but a later lease change is possible. An IP address is therefore an observation at a time, not a durable machine identifier.

Build a host record from hostname, account context, relevant interface addresses, and collection time. Correlate it with inventory or lease records when needed. Multiple addresses alone do not prove a host routes traffic between networks, and one address alone does not prove two observations concern the same machine.

Observation time and time zone:
Host identity and lab snapshot:
Account authority / name / SID:
Process identity and architecture:
Ordinary or elevated token:
Registry path and loaded profile:
Command and exact observed result:
Inference supported by the evidence:
Unresolved question:

Self-Check and Reasoning #

Same name, different SID: You recreate a deleted lab account named Alice. Should its old file permissions automatically follow the name?
Empty registry query: A service finds no value under its own HKCU. Has it established the user’s startup entry is absent?
Administrator without elevation: Why does a command fail even though its account belongs to Administrators?
Authentication capture: Is an NTLMv2 response the same artifact as an NT password hash?
Changed address: What additional evidence ties yesterday’s address to today’s workstation?

Expected answers: Recreated Alice is a new security principal. The service queried a different context, so it has not proved the user’s state. An administrator’s ordinary process often uses a filtered token.

Artifact and host checks: A challenge response and a stored password-derived secret serve different roles. Correlate host identity and timed inventory or DHCP evidence before joining the network observations.

Deliverable: Complete the identity record for two explicitly named lab contexts and explain one difference. Include actual command output and an interpretation. Label untested assumptions so the record remains useful when another reader repeats the exercise.

Next Steps #

Carry the context record forward into host operations, persistence, and cleanup. A later command is easier to interpret when you already know whose token and profile it uses. Continue with Module 5: Command and Control Operations , or return to the course hub .

Read More at https://simeononsecurity.com/

CompTIA A+ (220-1201): Virtualization and Cloud Computing

Wed, 01 Jan 2025 00:00:00 +0000

Click Here to Return To the CompTIA A+ Course Page

Virtualization and Cloud Computing is 11% of the CompTIA A+ 220-1201 Core 1 exam. This module covers virtual machines, hypervisor types, VDI, containers, cloud models, and cloud characteristics. This is the smallest Core 1 domain, but the concepts appear across modern IT support.

Virtualization runs many systems on one machine. Cloud computing rents that capacity from a provider so you pay only for what you use. Together they power most of the infrastructure you support today. This module gives you the vocabulary and the models.

Virtualization Concepts #

You run software-defined computers on physical hardware.

A virtual machine (VM) emulates a full computer with its own OS, isolated from the host.
A sandbox restricts untrusted code and reduces host exposure. Escapes, shared folders, network access, and management mistakes remain possible.
Test and development environments let you try changes without risking production.
Snapshots capture a VM state so you roll back after a failed change.

Virtualization saves money by packing many workloads onto fewer physical servers.

Hypervisor Types #

You pick the hypervisor that fits the workload.

Type	Runs on	Example	Use
Type 1 (bare metal)	Directly on hardware	ESXi, Hyper-V, Proxmox VE	Data centers, servers
Type 2 (hosted)	On top of an OS	VirtualBox, VMware Workstation	Desktops, labs, testing

Type 1 hypervisors run directly on host hardware, while Type 2 products run through a host OS. Security and speed depend on the product, workload, patch level, and configuration. Neither type guarantees guest isolation.

Virtualization Requirements #

You meet the prerequisites before a VM runs well.

CPU support for Intel VT-x or AMD-V, enabled in UEFI.
Enough RAM to allocate to each guest plus the host.
Storage for virtual disks, ideally on fast SSDs.
Network configuration with bridged, NAT, or host-only adapters.
Security isolation controls to reduce guest-to-host risk. Account for VM escapes, shared resources, network paths, and management mistakes.

Desktop Virtualization and Containers #

You deliver desktops and apps without local installs.

Virtual Desktop Infrastructure (VDI) hosts user desktops on a central server, streamed to thin clients.
Containers package an app with its dependencies but share the host OS kernel, so they are lighter than VMs.

Containers start in seconds and use less memory than full VMs. To understand the trade-offs, read Docker vs VMs .

Cloud Computing Models #

You choose a deployment model by who owns and uses the resources.

Model	Who uses it
Public	Shared infrastructure from a provider like AWS or Azure
Private	Dedicated infrastructure for one organization
Hybrid	A mix of public and private
Community	Shared by organizations with common needs

Cloud Service Models #

You match the service model to how much you want to manage.

Model	You manage	Provider manages
IaaS	OS, apps, data	Hardware, network, virtualization
PaaS	Apps and data	OS, runtime, infrastructure
SaaS	Just your data	Everything else

IaaS gives the most control, SaaS gives the least responsibility. Compare the major providers in AWS vs Azure vs Google Cloud Platform .

Cloud Characteristics #

You recognize the traits that define cloud services.

Shared vs dedicated resources trade cost for isolation.
Metered utilization charges by actual usage.
Rapid elasticity scales capacity up or down on demand.
High availability keeps services running through failures.
Multitenancy lets many customers share infrastructure securely.

Elasticity is what lets a website handle a traffic spike without buying permanent hardware.

Next Steps #

You have now covered all five Core 1 domains. Consolidate with Hardware and Network Troubleshooting , then begin Core 2 with Operating Systems . Review Hardware Components for virtualization hardware. Return to the CompTIA A+ Course .

Read More at https://simeononsecurity.com/

Module 5: Command and Control Operations

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Command and control (C2) connects an operator’s decisions to an agent running in a test environment. A useful operator distinguishes a submitted task from a delivered task, a completed action, and a returned result. Those states explain delays, prevent duplicate changes, and support an accurate activity record.

Allow about 18 minutes, plus time to complete the timing exercise. The exercise uses invented timestamps and requires no deployed agent.

What You Will Learn #

Identify the client, team server, agent, listener, and redirector roles.
Explain how polling affects task latency without treating it as a stealth guarantee.
Calculate delivery delay from a short event timeline.
Compare evidence from the console, network, and endpoint.
Produce a task ledger with ownership, deadlines, and recovery decisions.

Term	Meaning
Client	Operator interface connected to the shared backend
Team server	Backend coordinating sessions, tasks, and operation records
Beacon	Cobalt Strike’s agent on an assessment endpoint
Listener	Named configuration for an agent’s communication channel
Redirector	Intermediary forwarding selected assessment traffic
Task ledger	Your record of requests, results, and unresolved state

Separate the Components #

The client, team server, and Beacon serve different roles. The client is the operator’s interface, while the team server coordinates the operation and the agent performs work on an endpoint. Extension scripts loaded into one operator’s client do not automatically appear in every other client. Mandiant’s component analysis documents these boundaries. Read the component analysis .

A redirector adds another communication dependency. A request reaching the intermediary proves less than a valid task exchange reaching the agent. A listener’s display name is an organizational label, so record the actual destination, transport, owning server, and configuration revision alongside it.

The management connection and the agent channel also have separate failure modes. An operator might retain access to the console while an endpoint loses its permitted outbound route. Avoid describing both conditions as “the server is up” in a handover.

Observation	What it establishes	What remains unknown
Client connects	Management access works	Agent delivery path
Redirector responds	A web endpoint answered	Correct forwarding and task decoding
Agent checks in	Recent communication occurred	Success of a particular task
Task result arrives	Output returned through the channel	Independent target-side confirmation

Follow a Task’s Lifecycle #

Use queued, delivered, completed, and reported as analytical states in your notes. These are course labels, not a promise about a product’s UI terminology. The visible console often exposes only part of the lifecycle, so label unavailable timestamps as unknown.

Asynchronous tasking separates submitting work from receiving its result. Cobalt Strike’s callback documentation describes responses arriving later, influenced by the agent’s sleep interval. A callback in scripting also means a function handling a later result, so distinguish the programming term from a network check-in. Read the callback documentation .

Completion evidence answers a different question from delivery evidence. A transport acknowledgment is insufficient to prove a registry read succeeded or an application accepted an operation. Preserve the task identifier and returned status so the record stays tied to the requested action.

Record unknown states explicitly instead of filling gaps with assumptions

Understand Polling Latency #

A polling interval creates a waiting period before queued work reaches an agent. For a simplified fixed schedule, a task arriving immediately after a poll waits nearly one full interval. Network delay, task duration, missed polls, and output transfer add further delay.

Asynchronous does not necessarily mean “open a new connection for every task.” Transport reuse, peer-to-peer communication, and implementation choices affect the underlying connections. Cobalt Strike supports multiple communication mechanisms, so describe the tested channel instead of assigning every agent one network pattern. Read the vendor overview .

Detection depends on the observed behavior and available sensors. Persistent connections occur in ordinary software, while repeated brief requests also create recognizable patterns. Changing the interval changes a measurement variable, not the truth value of “visible” or “invisible.”

Simplified model	Result	Assumption
Poll every 60 seconds	Wait ranges from nearly 0 to nearly 60 seconds	No missed polls
Uniform task arrival	Mean polling wait is 30 seconds	Arrival independent of the schedule
Five-second task	Add five seconds to completion time	No contention or execution failure

The 30-second mean is a mathematical expectation for this model, not a measured Cobalt Strike benchmark. Once the interval varies or tasks arrive in bursts, use the observed distribution. Report the sample count and collection window with any average.

Work Through a Timeline #

Illustrative scenario: an agent polls at 10:00:00, 10:01:00, and 10:02:00. An operator submits a read-only hostname request at 10:00:10. The task reaches the endpoint at 10:01:00, completes at 10:01:02, and its result appears in the console at 10:01:05.

Event	Timestamp	Elapsed since submission
Queued	10:00:10	0 seconds
Delivered	10:01:00	50 seconds
Completed	10:01:02	52 seconds
Reported	10:01:05	55 seconds

Calculate first: identify queue delay, execution duration, and the remaining reporting delay. Then explain why submitting the same task again at 10:00:40 would complicate the record. Assume all clocks share the same time reference for this exercise.

Expected reasoning: queue delay is 50 seconds, execution takes two seconds, and reporting adds three seconds after completion. The second submission creates another pending request before the first reaches its scheduled delivery opportunity. An absent early result does not establish a failed task.

Change one assumption: suppose the endpoint clock is 20 seconds ahead. Which durations remain trustworthy from these timestamps alone? Cross-host differences now need clock-offset information, while durations measured within a single reliable clock remain interpretable.

Handle Uncertain Results #

Unknown outcome is an operational state worth retaining. A connection loss after delivery leaves open whether the task ran, failed, or completed without returning output. Retrying a state-changing task without reconciliation risks applying the action twice.

Read-only and state-changing tasks need different retry decisions. A repeated inventory query mainly affects workload and evidence volume. A repeated configuration change requires checking current state and the expected effects of repetition before resubmission.

Failure point	First check	Record before retrying
No recent check-in	Channel health and endpoint availability	Last confirmed communication
Delivered, no result	Endpoint outcome and task status	Delivery evidence and uncertainty
Result is an error	Exact error and requested resource	Arguments, context, and timestamp
Conflicting operators	Session owner and pending work	Agreed next action

A deadline belongs in the task record before execution. It sets the point for review or escalation, rather than an automatic instruction to resend. For long-running work, verify the documented cancellation behavior before treating a console action as proof the endpoint stopped.

Observe Both Ends #

Endpoint evidence provides a separate view of the action. For example, configured Sysmon network events associate a connection with a process, while process events help reconstruct execution. Event availability depends on installation, configuration, filtering, and retention. Read Microsoft’s Sysmon documentation .

A missing event has several explanations. The action might not have happened, the relevant event type might be disabled, or collection might have failed. Before treating absence as a security finding, verify the observation path with a known benign control action.

Cross-source correlation needs host identity, timestamps, task identifiers, and the test window. IP addresses and process IDs alone are weak long-term join keys because their assignments change. Keep the raw evidence location with your interpretation so another reviewer has a path back to the source.

Evidence source	Useful question
Operator ledger	Who requested the task and why?
Team-server record	What was queued and returned?
Network record	Which observed endpoints exchanged traffic?
Endpoint record	What process or resource activity occurred?

Watch the Operations Lecture #

The Cobalt Strike Archive lecture covers the operations model, team servers, logging, and reporting. Watch for the separation between managing an operation and proving a task’s outcome. Then map one demonstrated action onto the four analytical states used above.

This is a historical 2019 lecture. Use current vendor documentation for supported releases, authentication requirements, and UI details.

Watch on YouTube: Red Team Ops with Cobalt Strike (1 of 9): Operations .

Build Your Task Ledger #

Create a handover record for three hypothetical tasks: a successful inventory query, a delivered task with no returned result, and a queued task canceled before confirmed delivery. Give each task a different identifier. Include only synthetic hosts and identities.

Task ID:
Objective and approved endpoint:
Operator and session owner:
Requested action and expected output:
Queued timestamp:
Delivery evidence:
Completion evidence:
Returned status and evidence location:
Deadline and review decision:
Retry or cancellation rationale:
Remaining uncertainty:

Review your design with a second reader. They should identify which tasks are safe to close, which require reconciliation, and who owns the next decision without opening the original console. A ledger filled with “done” and “failed” is insufficient if it hides the evidence behind those labels.

Success criterion: every closed task has a supported outcome, and every unresolved task has an owner and next check. Keep timing calculations separate from claims about security-tool performance. This artifact extends the infrastructure register from Module 2 into day-to-day operation.

Check Your Understanding #

Components: why does a working client connection fail to prove agent reachability?
Timing: what assumptions support the half-interval mean waiting time?
Retries: why is missing output insufficient justification for repeating a configuration change?
Evidence: what should you verify before interpreting an absent network event?

Question	Expected reasoning
Components	Management and agent traffic use distinct paths and dependencies
Timing	A fixed successful polling schedule and independent uniform task arrival
Retries	The action might already have completed without returning output
Evidence	Sensor health, event configuration, filters, retention, and a control observation

Next Steps #

Execution location adds another dimension to task reliability. Continue to Module 6: Beacon Execution and Beacon Object Files to compare process boundaries, dependencies, and failure consequences. Return to the Red Team Course hub for the full sequence.

Read More at https://simeononsecurity.com/

CompTIA A+ (220-1201): Hardware and Network Troubleshooting

Wed, 01 Jan 2025 00:00:00 +0000

Click Here to Return To the CompTIA A+ Course Page

Hardware and Network Troubleshooting is 28% of the CompTIA A+ 220-1201 Core 1 exam, tied with two Core 2 domains for the largest listed percentage across the two exams. This module covers the troubleshooting methodology and how to diagnose hardware, displays, mobile devices, printers, and networks. The exam tests process as much as parts, so learn the methodology in order.

Troubleshooting is the skill that defines a good technician. You follow a repeatable process, read the symptoms, form a theory, and prove it before you replace anything. This module turns scattered symptoms into a reliable diagnosis.

The CompTIA Troubleshooting Methodology #

You follow these steps in order on every problem. The exam expects this exact sequence.

Identify the problem. Gather information, question the user, and back up data before changes.
Establish a theory of probable cause. Question the obvious.
Test the theory to confirm it. If it fails, form a new theory or escalate.
Establish a plan of action and identify potential effects.
Implement the solution or escalate as needed.
Verify full functionality and apply preventive measures.
Document findings, actions, and outcomes.

Motherboard, RAM, CPU, and Power Issues #

You read the symptoms of core component failure.

Symptom	Likely cause
POST beep codes	RAM, GPU, or CPU not detected
No power, no fans	Dead PSU or wall power
Random shutdowns	Overheating or failing PSU
Burning smell	Failed PSU or component
Swollen capacitors	Failing motherboard
Continuous reboots	RAM, overheating, or corrupt firmware

Overheating often traces to dust, failed fans, or dried thermal paste.

Drive and RAID Issues #

You catch storage failure before data is lost.

Grinding or clicking noises signal a failing mechanical HDD. Back up immediately.
S.M.A.R.T. failures warn that a drive is degrading.
RAID not found points to a failed controller or member drive.
Slow read/write suggests a dying drive or full disk.
Bootable device not found means a missing or failed boot drive.

Display and Video Issues #

You diagnose what the user sees on screen.

Symptom	Cause
Dead pixels	Failed individual pixels
Burn-in	Static image ghosted on OLED
Dim image	Failing backlight or inverter
Flickering	Loose cable or failing panel
Distorted geometry	Wrong resolution or failing GPU
No image, power on	Cable, input source, or GPU

Mobile Device Hardware Issues #

You handle the special risks of sealed devices.

A swollen battery is a fire hazard. Stop using the device and replace it.
Cracked screens need digitizer and panel replacement.
Liquid damage calls for power-off and professional cleaning.
Poor battery life can mean a worn battery or a rogue app.
Overheating points to heavy load, a failing battery, or a charging fault.

Network Issues #

You isolate connectivity problems from the device outward.

Symptom	Likely cause
No connectivity	Cable, NIC, or DHCP failure
Intermittent drops	Loose cable or wireless interference
Slow speeds	Congestion, bad cable, or duplex mismatch
High latency/jitter	Congestion or weak signal
APIPA address (169.254.x.x)	DHCP server unreachable
Limited connectivity	Wrong IP, gateway, or DNS

Build the underlying knowledge in Networking Fundamentals .

Printer Issues #

You resolve the common print faults.

Paper jams trace to worn rollers, wrong paper, or debris.
Faded prints mean low toner or ink.
Ghosting points to a failing drum or fuser.
Garbled output means a wrong or corrupt driver.
No connectivity points to network, queue, or spooler problems.

Next Steps #

You have now finished all five Core 1 domains. Move into Core 2 with Operating Systems , then Software Troubleshooting for the software side of diagnostics. Review Hardware Components and Mobile Devices . Return to the CompTIA A+ Course .

Read More at https://simeononsecurity.com/

Module 6: Beacon Execution and Beacon Object Files

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

A Beacon Object File (BOF) extends an agent with compiled code executed inside its process. Understanding the file format is only the starting point. You also need to reason about compatibility, dependencies, input handling, runtime behavior, and the consequences of a failure.

Allow about 18 minutes, plus time to build the compatibility record. The examples are illustrative and do not require running an offensive payload.

What You Will Learn #

Distinguish object files, executable images, scripts, and runtime code.
Explain how execution location changes the failure boundary.
Inspect architecture metadata without executing an object file.
Evaluate compatibility and evidence before selecting an execution method.
Create a test record covering valid input, invalid input, and failure handling.

Term	Meaning
COFF	Common Object File Format used for compiled object modules
BOF	Object code following a loader’s expected entry and API conventions
ABI	Application binary interface governing how compiled components interact
Aggressor Script	Cobalt Strike client scripting and integration layer
In-process execution	Code running within an existing process
Fork and run	Tool-specific workflow using another process for a task

Understand the File Format #

A COFF object file contains compiled sections, symbols, and relocation information. A linker ordinarily combines object files into an executable image. An object file is therefore not interchangeable with a complete Windows executable, even if both contain machine code. Read Microsoft’s PE and COFF specification .

A BOF loader supplies another route from an object file to execution. Cobalt Strike resolves the supported components and invokes code using its conventions. The extension depends on its loader’s supported APIs and runtime assumptions, rather than inheriting every facility of a normally linked application. Read the BOF documentation .

Source language is distinct from the object format. C is common, but vendor tooling also demonstrates a C++ development template. The compiled result still needs the required entry convention and compatible runtime behavior. Read the vendor’s development and debugging guide .

Artifact	Typical consumer	Important distinction
Object file	Linker or compatible custom loader	Contains unresolved integration requirements
Executable image	Operating-system image loader	Includes image structure and loading metadata
Client script	Operator application’s script engine	Integrates commands and formats arguments

Separate Script and Endpoint #

An Aggressor script runs in the operator’s client. It often provides a named command, handles arguments, selects an object file, and submits the task. Loading a script is different from running its associated endpoint code. Read Mandiant’s component analysis .

Command registration is one integration mechanism, not a universal requirement for executing every BOF. A missing command might indicate an unloaded script, a naming conflict, a script error, or a different toolkit version. Check the integration layer before concluding the endpoint rejected the object.

Argument agreement matters across the boundary. A script expecting one string format and an object expecting another do not form a compatible pair merely because their filenames match. Record the script revision and object revision together in the test record.

Compatibility and successful delivery are prerequisites, not proof of a correct result

Compare Execution Boundaries #

In-process code shares the host process’s resources and failure consequences. A memory error or unhandled failure in an extension threatens the running agent. The vendor’s BOF documentation explicitly describes this crash risk. Review the documented limitations .

A separate process changes the failure boundary but does not guarantee isolation from every effect. A child might modify shared files, hold network connections, or consume system resources. Judge the action’s effects as well as its location.

Telemetry also changes with the execution method. Avoid treating “no new child process” as “no observable activity.” File, registry, network, and other resource operations remain relevant observations, depending on the sensors and configuration. Review Sysmon’s event categories .

Method	Failure consideration	Evidence consideration
In-process extension	Shares the existing process’s fate	Inspect resource activity and task output
Separate task process	Adds a process with its own lifetime	Correlate creation, execution, and termination
Read-only native tool	Depends on the tool and requested scope	Record executable, arguments, identity, and result

A measured comparison keeps the requested operation constant. Comparing a one-field query with a complete directory inventory mostly measures differences in workload. Use equivalent inputs and outputs before attributing differences to the execution method.

Check Architecture First #

Process architecture is the relevant boundary for code loaded into the receiving process. A 64-bit operating system also supports some 32-bit applications, so the OS label alone is insufficient. Check the object metadata and the receiving process architecture independently.

Static inspection reads an artifact without invoking its entry point. On a Windows development machine with the Visual Studio tools installed, use the Developer Command Prompt to inspect a benign object supplied for your lab. The /headers option displays file and section-header information. Read Microsoft’s DUMPBIN header reference .

dumpbin /headers lab-query.obj

Read the machine field and record it alongside the filename and hash. Microsoft’s COFF specification identifies values such as I386 for x86 and AMD64 for x64. This check establishes the declared machine target, not whether every symbol, API call, or argument is compatible.

Check	Evidence	Insufficient substitute
Architecture	Object header and receiving process	Operating-system marketing name
Entry convention	Loader documentation and source review	Filename extension
Dependencies	Imports, source, and loader support	Successful compilation alone
Integration	Matching script and object revisions	Similar release dates

Account for Runtime Limits #

The documented inline BOF model expects short, single-threaded work. Its execution blocks other Beacon functionality while it runs, and the standard loader does not supply a normal C runtime library. A function available in an ordinary C application is not automatically available through this interface. Read the runtime limitations .

Other job mechanisms have different lifecycles. Cobalt Strike separately documents background tasks running in another process. Do not turn a limitation of the inline BOF model into a claim about every task supported by the platform. Read the job-control documentation .

Version records prevent ambiguous conclusions. Keep the loader release, compiler settings, object revision, script revision, and operating-system build with a test result. A successful run establishes compatibility for the tested combination, not every environment using the same product name.

Symptom	Candidate explanation	Next evidence
Unknown command	Client integration issue	Script load result and registered name
Object rejected	Format or compatibility mismatch	Loader error and header metadata
Agent stops responding	Blocking work, failure, or channel problem	Timing, endpoint health, and task record
Empty output	Empty result, error handling, or formatting issue	Expected result and explicit status

Work a Compatibility Case #

Illustrative scenario: a training VM runs a 64-bit OS, but its exercise loader runs in a 32-bit process. You receive an x64 object and a script from a different release. The script loads successfully and exposes a command.

Your task is to identify the evidence supporting execution and the evidence still missing. Decide whether loading the script proves the object is compatible. Then propose the smallest set of checks needed before a benign inventory test.

Observation	Supported conclusion
64-bit OS	The operating system supports its documented architectures
32-bit loader	Loaded code must match the test process’s supported interface
x64 object	The provided object targets a different architecture
Command appears	Client registration succeeded

Expected reasoning: stop before execution because the object and receiving process do not match. Obtain a reviewed compatible build, then verify the script’s expected arguments against the object interface. Successful client registration does not test endpoint loading.

A second case changes the object to a compatible architecture but produces empty output for a query known to have one result. Architecture is no longer the only issue. Investigate argument handling, permissions, status reporting, and output formatting before claiming the queried item is absent.

Watch the Vendor Demonstration #

The Cobalt Strike Archive demonstration introduces the BOF feature through a small example. Watch how client-side tasking relates to endpoint execution and returned output. Note which parts of the workflow would need separate compatibility evidence in your own record.

The video demonstrates the feature introduced in Cobalt Strike 4.1. Pair it with the current documentation rather than assuming every UI detail still matches.

Watch on YouTube: Beacon Object Files - Luser Demo .

Design a Benign Test #

Choose a small query with a known expected result in a disposable training environment. Suitable examples include reporting the test process’s own architecture or returning a fixed input string. Avoid mixing the compatibility test with a privilege change, network sweep, or persistence action.

Test the input boundary as well as the successful case. Specify expected behavior for missing input, malformed input, and a valid empty result. Vendor debugging guidance includes a standalone development approach, which helps separate basic correctness from agent-channel problems. Read the development guide .

Test identifier:
Question and expected result:
Loader and process architecture:
Object hash and source revision:
Compiler and build settings:
Client script revision:
Input case:
Returned status and output:
Elapsed time and process health:
Observed side effects:
Evidence location and unresolved questions:

Evaluate the result against the expected output, explicit status, elapsed time, and process health. A test which returns the right string but leaves the test process unresponsive has not passed. A failure with a clear error and an intact process still teaches something useful about error handling.

Your deliverable is a compatibility record containing at least three input cases and one justified decision about execution location. Explain the trade-off in terms of correctness, consequences, and observability. Avoid unsupported claims about which method is universally “quietest.”

Check Your Understanding #

Format: why is a COFF object different from a complete executable image?
Architecture: which architecture matters when loading an extension?
Integration: what does successful script loading establish?
Visibility: which observations remain useful without a new child process?

Question	Expected reasoning
Format	An object carries linking and relocation requirements for its consumer
Architecture	The receiving process and loader’s supported interface
Integration	The client accepted the integration, subject to its reported status
Visibility	Resource activity, output, timing, and endpoint health

Next Steps #

Communication behavior is another independent dimension of an operation. Continue to Module 7: Malleable C2 and Communication Evasion to distinguish a valid profile from a supported detection claim. Return to the Red Team Course hub for the full sequence.

Read More at https://simeononsecurity.com/

CompTIA A+ (220-1202): Operating Systems

Wed, 01 Jan 2025 00:00:00 +0000

Click Here to Return To the CompTIA A+ Course Page

Operating Systems is 28% of the CompTIA A+ 220-1202 Core 2 exam, the largest Core 2 domain. This module covers OS types, installations, Windows editions, tools, the command line, settings, and macOS and Linux. Core 2 is software-focused, and this domain rewards hands-on practice in real systems.

The operating system is where users and hardware meet. You install it, configure it, fix it, and secure it. This module covers the three desktop platforms and the Windows tools and commands you will use every shift.

OS Types and Filesystems #

You match the OS and filesystem to the device.

OS	Common filesystem
Windows	NTFS, ReFS, FAT32, exFAT
macOS	APFS, HFS+
Linux	ext4, XFS, Btrfs
Chrome OS	Cloud-centric, ext4 underneath
Mobile (Android/iOS)	Sandboxed app storage

NTFS supports permissions, encryption, and large files. FAT32 is universal but caps files at 4 GB. exFAT removes that cap for large external drives.

Installations and Upgrades #

You deploy Windows the right way for the situation.

Method	Use
Clean install	Fresh OS, wipes the disk
In-place upgrade	Keeps apps and files
Image deployment	Mass rollout from one image
Repair install	Fixes a broken OS, keeps data

Partition styles matter at install: GPT supports drives larger than 2 TB and many partitions, while MBR is the legacy limit of four primary partitions and 2 TB.

Windows Editions #

You pick the edition by required features.

Edition	Key features
Home	Basic, no domain join
Pro	Domain join, BitLocker, Group Policy, RDP host
Enterprise	Volume licensing, advanced management

Only Pro and higher can join a domain and host Remote Desktop.

Windows Tools #

You manage the system with built-in utilities.

Task Manager shows processes, performance, startup apps, and services.
Event Viewer logs system, application, and security events.
Disk Management creates, formats, and resizes partitions.
Registry Editor (regedit) edits the Windows configuration database. Back up the registry before edits.
MMC snap-ins host tools like Device Manager and Local Users and Groups.

Command-Line Tools #

You troubleshoot fast from the command line.

ipconfig /all          # View full IP configuration
ping 8.8.8.8           # Test connectivity
nslookup example.com   # Query DNS
netstat -ano           # List connections and owning PIDs
sfc /scannow           # Repair protected system files
chkdsk /f              # Check and fix the filesystem
robocopy C:\src D:\dst /E   # Mirror folders, including subdirs

For a deeper reference, read the Windows command line guide and the Windows directory structure guide .

Windows Settings and Networking #

You configure how Windows joins and protects the network.

Workgroup vs domain: a workgroup is peer-to-peer, a domain is centrally managed by Active Directory.
Windows Defender Firewall filters inbound and outbound traffic.
VPN connections tunnel traffic securely to a remote network.
Proxy settings route web traffic through a filtering server.

macOS and Linux #

You support the other two desktop platforms.

macOS uses System Settings, Terminal, FileVault disk encryption, Time Machine backups, and Spotlight search.
Linux runs core commands you must know:

ls -l            # List files with permissions
chmod 755 file   # Set permissions
sudo apt update  # Update packages (Debian/Ubuntu)
sudo dnf install # Install packages (Fedora/RHEL)

New to Linux? Start with the best Linux distros for beginners .

Next Steps #

Continue Core 2 with Security and Software Troubleshooting . Close out the exam with Operational Procedures . Return to the CompTIA A+ Course and review tips for passing CompTIA exams .

Read More at https://simeononsecurity.com/

Module 7: Malleable C2 and Communication Evasion

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

A Malleable C2 profile describes configurable aspects of Cobalt Strike communication and related behavior. It changes indicators, but a changed indicator is insufficient evidence of a bypass. This module teaches you to separate configuration validity, successful communication, collected telemetry, and detection outcomes.

Allow about 20 minutes, plus time for the local HTTP exercise. The exercise sends harmless requests to your own loopback interface and does not deploy an agent.

What You Will Learn #

Define profiles, transforms, polling, jitter, and observation points.
Explain which parts of an HTTP exchange different sensors observe.
Inspect two local requests and compare their records.
Evaluate the evidence behind a claim of reduced detection.
Create a controlled comparison with explicit assumptions and limits.

Term	Meaning
Profile	Configuration describing selected communication and runtime behavior
Transform	Reversible operation used to encode and recover exchanged data
Polling	Checking periodically for work or results
Jitter	Variation applied to a timing interval
Telemetry	Recorded observations of system or network activity
Detection	Logic interpreting observations as a condition of interest

Understand Profile Scope #

The communication profile describes where data appears in transactions and how the receiving side recovers it. This is more specific than changing a display name or cosmetic label. Both ends need compatible expectations for the exchange to work. Read the Malleable C2 overview .

Other profile sections govern aspects of memory, process injection, and post-exploitation jobs. Keep those settings separate from a claim about network behavior. A change in one category is not evidence of a result in another. Read the profile-extension overview .

Configuration behavior is version-specific. The 4.13 documentation introduces overrides for a defined subset of settings when generating new payloads. Check the documented override scope instead of assuming a restart is always required or every running agent inherits an edit. Read the override documentation .

Question	Evidence needed
Was the profile accepted?	Validation output and selected configuration
Did the exchange work?	Correct decoded result through the tested path
What did a sensor see?	Sensor record, configuration, and timestamp
Did a rule alert?	Rule identity, outcome, and evaluation window

Separate Four Outcomes #

Syntactic validity means a configuration passed specified checks. Functional success means the intended exchange produced the expected result. Neither outcome establishes how a security product classified the activity.

Telemetry collection precedes many detection decisions. A request might be recorded without generating an alert, or an alert might depend on later correlation with endpoint behavior. Report those stages independently so an absence of alerts does not become a claim of invisibility.

Response adds another stage after detection. An analyst’s investigation or a containment action depends on workflow, policy, and available context. A test of network visibility should not silently become a claim about the entire response program.

A pass at one stage leaves the following stage unproven

Read HTTP in Context #

An HTTP request includes a method, target, headers, and sometimes content. A user-agent value is supplied by the client and does not authenticate the application sending it. Read the whole exchange and its context before assigning meaning to one field. Read the HTTP semantics specification .

HTTPS protects application data in transit between TLS peers. A passive observer outside the TLS session does not ordinarily read its HTTP path and headers, while an endpoint or configured inspection proxy has a different view. State the observation point whenever you discuss visibility. Read the TLS 1.3 specification .

Network metadata still carries useful context, including observed endpoints, timing, and traffic sizes. Which names and application details remain exposed depends on the actual protocols and deployment. Do not equate encrypted content with a complete absence of observable behavior.

Observation point	Typical evidence	Main limitation
Application server	Received request and response outcome	Its configured logs omit some fields
Endpoint sensor	Process and connection context	Coverage depends on configuration
Passive network sensor	Traffic timing and transport metadata	Encrypted application content is restricted

Check Functional Validity #

c2lint is the vendor’s profile-checking tool. It checks syntax and performs additional tests using generated data. Use it as evidence about configuration validity, then validate the actual permitted communication path separately. Read the validator documentation .

./c2lint /path/to/approved-lab.profile

The path argument selects an existing profile for validation. Run the validator supplied with the release under review and retain its output with the profile’s hash. This command checks a file, so it does not prove an agent exchanged tasks through a proxy or a detection rule evaluated the resulting traffic.

Exit code	Documented meaning
0	No reported errors or warnings
1	Warnings only
2	Errors only
3	Both errors and warnings

Intermediaries introduce additional variables. A proxy might rewrite a field, enforce a body-size limit, or reject a request under policy. Successful direct communication in a lab is insufficient proof of the same behavior through a different path.

Inspect Harmless Local Requests #

Create a disposable directory containing one synthetic text file. The following commands create it under your temporary directory and start Python’s demonstration HTTP server bound to 127.0.0.1. The --directory argument limits the served tree to the generated folder. Read Python’s HTTP-server command-line documentation .

lab_dir=$(mktemp -d)
printf 'synthetic training response\n' > "$lab_dir/sample.txt"
python3 -m http.server 8765 --bind 127.0.0.1 --directory "$lab_dir"

Keep this terminal open while making the requests below in a second terminal. The server is a local teaching aid, not a production service. If port 8765 is occupied, choose an unused port and update both commands consistently.

curl --noproxy '*' --verbose \
  --user-agent 'CourseLab/1.0' \
  http://127.0.0.1:8765/sample.txt

curl --noproxy '*' --verbose \
  --user-agent 'CourseLab/2.0' \
  http://127.0.0.1:8765/sample.txt

--noproxy '*' bypasses configured proxies for these requests. --verbose prints request and response details, while --user-agent sets the client-supplied header. The response body remains the same synthetic file in both cases. Read the curl options reference .

Record	Expected comparison
curl request details	User-agent changes between requests
Response body	Same synthetic content
Default server log	Request line and status, without every request header

Interpret the difference: a header changed even if the default server log does not display it. Missing fields in a log reflect the record’s coverage, not necessarily the absence of those fields on the wire. These are expected observations for the example, so compare them with your own run and explain any discrepancy.

Finish the exercise by pressing Ctrl+C in the server terminal. In the same shell, run printf '%s\n' "$lab_dir" to identify the generated folder and remove only the disposable folder when your notes are saved. This exercise measures HTTP representation and logging coverage, not Cobalt Strike behavior or an EDR result.

Evaluate Detection Claims #

A fair comparison defines one changed variable and keeps the remaining conditions stable. Record sensor configuration, rule version, clock reference, workload, and collection window. If several settings change together, attribute the result to the combined experiment instead of guessing which change caused it.

Endpoint detection and response (EDR) combines product-specific sensors and analysis. Direct API use, fewer child processes, or a changed memory layout does not establish the absence of other observable activity. Microsoft’s Sysmon documentation offers concrete examples of separate process, network, registry, and image-load observations. Review the documented events .

Reputation is separate from correctness. Uploading an artifact to a scanning service is not a way to make it trusted. VirusTotal describes sharing submitted samples with its partners and community, so submission decisions require the artifact owner’s data-handling policy. Read how VirusTotal works .

Claim	Evidence problem	Better conclusion
“No alert means unseen”	Collection and rule coverage unverified	No alert observed in the stated window
“Longer sleep is safer”	Timing changed without measured detection	Lower request frequency in this run
“A renamed process is trusted”	Name treated as provenance	Identity and behavior still require review
“The profile passed lint”	Syntax treated as a security outcome	Specified validation checks passed

Work a Comparison Case #

Illustrative scenario: two synthetic request runs each complete successfully. Run A produces an alert and Run B does not. Before Run B, the operator changes the user-agent and the analyst disables the relevant network-event collection rule.

Evaluate the conclusion: is the new user-agent responsible for the missing alert? Identify the confounding variable and write a justified next step. Keep the distinction between actual request behavior and available evidence explicit.

Expected reasoning: the comparison does not isolate the user-agent change. Collection changed as well, so the experiment cannot establish causation. Restore the agreed observation configuration, confirm it with a benign control, then repeat a bounded comparison with one changed variable.

Question:
Fixed environment and software versions:
Changed variable:
Baseline and comparison workloads:
Sensor health and collection configuration:
Expected observation and alert criteria:
Run IDs and timestamps:
Raw evidence locations:
Observed result and missing data:
Supported conclusion:
Follow-up or closure decision:

Your deliverable is a comparison record another reader would repeat using synthetic traffic. Include one alternative explanation for the result and the check which would distinguish it. Keep operational configuration details separate from unsupported claims about universal evasion.

Watch the C2 Lecture #

The Cobalt Strike Archive lecture introduces the profile language and communication design. Use it to identify the distinctions between an indicator, a transport dependency, and a claimed security outcome. Compare its examples with the evidence requirements in your experiment record.

This historical 2019 lecture predates current releases. The documentation linked above takes precedence for current settings and supported behavior.

Watch on YouTube: Red Team Ops with Cobalt Strike (3 of 9): C2 .

Check Your Understanding #

Configuration: why does successful linting leave end-to-end behavior unproven?
Observation: why should every visibility claim name its sensor location?
Experiment: what invalidates the two-run comparison above?
Reporting: how would you phrase an absent alert without claiming invisibility?

Question	Expected reasoning
Configuration	The real route and its intermediaries were not exercised
Observation	Encryption, endpoint context, and log configuration change the available view
Experiment	Both the traffic field and collection configuration changed
Reporting	Name the rule, collection state, window, and absence observed

Next Steps #

Evidence quality matters before any endpoint interaction as well. Continue to Module 8: Open-Source Intelligence to evaluate public information, freshness, and corroboration. Return to the Red Team Course hub for the full sequence.

Read More at https://simeononsecurity.com/

CompTIA A+ (220-1202): Security

Wed, 01 Jan 2025 00:00:00 +0000

Click Here to Return To the CompTIA A+ Course Page

Security is 28% of the CompTIA A+ 220-1202 Core 2 exam, tied for the largest Core 2 domain. This module covers physical and logical security, Windows settings, wireless protocols, malware, social engineering, hardening, and data destruction. Security knowledge protects every system you support, so master these controls.

Security is everyone’s job, and the technician is the first line of defense. You lock down access, configure permissions, recognize attacks, and remove malware. This module builds the practical security skills the exam demands.

Physical and Logical Security #

You combine physical barriers with logical access controls.

Physical	Logical
Bollards, fences, mantraps	Access Control Lists (ACLs)
Badge readers, key fobs	Least privilege
Biometrics (fingerprint, face)	Zero Trust
Locks, cameras, lighting	Multifactor authentication (MFA)

MFA combines factors: something you know (password), something you have (token), and something you are (biometric). Least privilege gives each user only the access the job requires.

Windows Security Settings #

You harden Windows with built-in controls.

Microsoft Defender Antivirus blocks known and behavior-based malware.
Windows Defender Firewall filters network traffic.
NTFS vs share permissions: NTFS applies locally and over the network, share permissions apply only over the network. The most restrictive of the two wins.
BitLocker encrypts the whole drive, while EFS encrypts individual files.
User Account Control (UAC) prompts before privileged actions.

Wireless Security Protocols #

You pick the strongest protocol the hardware supports.

Protocol	Strength
WEP	Broken, never use
WPA2	AES encryption, still common
WPA3	Preferred current option where clients and access points support the selected mode

Prefer a supported WPA3 mode with strong credentials and current device updates. WPA2 with AES-based CCMP remains a compatibility choice. Enterprise Wi-Fi commonly uses 802.1X with RADIUS. TACACS+ typically serves device administration. Kerberos issues tickets in domain environments, but is not a direct substitute for Wi-Fi authentication.

Types of Malware #

You identify malware by its behavior.

Malware	Behavior
Virus	Attaches to files, spreads when run
Trojan	Hides in a useful-looking program
Ransomware	Encrypts data and demands payment
Rootkit	Hides deep in the OS to evade detection
Keylogger	Records keystrokes to steal credentials
Cryptominer	Steals CPU/GPU cycles to mine coins
Fileless	Runs in memory, leaves little on disk

You recognize attacks that target people and systems.

Phishing uses fake emails to steal credentials, vishing uses voice calls, and smishing uses text messages.
Tailgating follows an authorized person through a secure door.
Shoulder surfing reads credentials over a shoulder.
DoS/DDoS floods a service to take it offline.
SQL injection and XSS attack vulnerable web applications.

Strong, unique passwords blunt many of these attacks. Read how to create strong passwords .

Malware Removal and Hardening #

You follow the CompTIA seven-step malware removal process:

Investigate and verify the malware symptoms.
Quarantine the infected system.
Disable System Restore (Windows).
Remediate: update anti-malware and scan in safe mode.
Schedule scans and run updates.
Enable System Restore and create a restore point.
Educate the end user.

You harden workstations with data-at-rest encryption, strong password policies, account management, and by disabling unused services and AutoRun.

Data Destruction #

You destroy data so it cannot be recovered.

Method	Type
Drilling, shredding	Physical destruction
Degaussing	Magnetic wipe of HDDs
Secure erase / cryptographic erase	Software wipe
Certified recycling	Documented disposal

Get a certificate of destruction when a third party handles regulated data.

Next Steps #

Continue Core 2 with Software Troubleshooting for malware diagnosis, and Operational Procedures for policy. Review Operating Systems for Windows security tools. Return to the CompTIA A+ Course .

Read More at https://simeononsecurity.com/

Module 8: Open-Source Intelligence

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Open-source intelligence (OSINT) turns publicly available information into an answer to a defined question. Collection alone produces observations. Useful intelligence adds provenance, context, corroboration, uncertainty, and a decision the assessment team is authorized to make.

Allow about 25 minutes, plus time to complete the evidence-ledger exercise. All organizations, observations, and assessment decisions in the worked case are fictional.

What You Will Learn #

Distinguish a source observation from an inference and a confirmed finding.
Explain the limits of registration, DNS, certificate, and scan-index data.
Apply search operators and normalize a synthetic list of names.
Compare evidence freshness and independent corroboration.
Create a research brief which supports a bounded next action.

Term	Meaning
Provenance	Where information originated and how you obtained it
Observation	A specific item recorded from a source
Inference	A conclusion drawn from one or more observations
Corroboration	Additional evidence supporting or challenging a claim
RDAP	Registration Data Access Protocol for structured registration queries
Certificate transparency	Public logging system for certificates and precertificates
ASN	Autonomous system number identifying a routing administration

Start With a Question #

A research question limits both collection and interpretation. “Which externally named services need ownership clarification before our approved scan?” produces a different collection plan from “Which public documents describe the organization’s remote-work policy?” Write the question before opening tools.

A finding needs a supported statement and its boundary. A search result mentioning a product does not prove the product is deployed now. A service banner naming a version does not establish the installed patch state or exploitability.

Decision relevance keeps the work focused. If a source does not change the answer or the next authorized action, collecting more of it adds handling work without improving the result. Maintain a short list of unresolved questions instead of an unlimited list of names.

Research question	Useful evidence	Premature conclusion
Who manages a service?	Current inventory plus registration context	Shared IP means shared ownership
Was a name publicly disclosed?	Dated certificate or document record	The service is live today
Is a technology plausible?	Recent technical publication	Every listed product is deployed

Map the Collection Path #

Public availability describes access to information, not the visibility of collecting it. Reading a search index, loading the original website, and requesting a fresh service banner contact different systems. Search providers, APIs, resolvers, and websites have their own records of activity.

Passive relative to the target is a useful description if you define it. Querying an existing third-party dataset often avoids a new connection from you to the target service. Opening a result, fetching a linked image, or enabling an active tool module changes the collection path.

Collection records should therefore name the provider, account context where applicable, query, timestamp, and whether the tool initiates fresh target contact. An isolated browser profile separates work from personal sessions, but it does not guarantee anonymity or eliminate service-side logs.

Public information becomes useful intelligence through supported interpretation

Use Search Operators Deliberately #

Search operators narrow indexed results. Google documents quoted phrases, site:, filetype:, exclusions with -, and date filters such as after:. Operator support and interpretation differ between services, so check the search engine’s documentation. Read Google’s search guidance .

Practice query design with the fictional examples below. The reserved example domain is a placeholder, so no matching results are expected. Replace it only with the domain selected for your authorized research task. Read IANA’s example-domain guidance .

site:example.com "remote access"
site:example.com filetype:pdf "annual report"
site:example.com "service status" -careers
site:example.com "migration" after:2025-01-01

Explain each filter before collecting results. The first limits the site and requests an exact phrase, the second adds a document type, the third excludes a word, and the fourth applies a date condition. A search-engine date filter is a retrieval aid, so verify the source’s own dates before interpreting freshness.

An empty result set is limited evidence. Indexing gaps, query wording, access restrictions, and removed pages affect the result. Record the query and its limits instead of concluding the organization has no remote-access service.

Source item	Preserve	Avoid assuming
Search snippet	Query, retrieval time, and destination	Snippet equals current page content
Public document	Original file, date, and source URL	Metadata proves current employment
Job posting	Publication context and named requirements	Every listed skill reflects production use

Read Registration Records Carefully #

Domain registration data and IP-number registration data answer different questions. ICANN’s January 2025 transition made RDAP the definitive delivery mechanism for generic top-level-domain registration information in place of sunsetted WHOIS requirements. This does not mean every country-code domain or number-registry service follows an identical transition. Read ICANN’s announcement .

Regional Internet Registries provide number-resource information. ARIN’s RDAP documentation covers queries for networks, autonomous systems, and related entities. A returned record describes registration relationships, not necessarily the current application operator using an address. Read ARIN’s RDAP guide .

Scope remains a separate record. A cloud provider’s allocation does not authorize testing every tenant within it. Conversely, a customer-operated service on provider address space is not automatically excluded if the agreed scope and applicable provider conditions explicitly include it.

Record	Supports	Does not establish
Domain RDAP	Registration details exposed by the service	Current technical administrator in every case
Network RDAP	Number-resource registration context	Application ownership or assessment permission
Approved asset register	Named assessment targets and constraints	Current network state without verification

Interpret DNS Relationships #

DNS names are not a one-to-one inventory of machines. Multiple names resolve to one service, one name resolves to multiple addresses, and an alias refers to another name. Delegation also separates a parent zone from a child zone. Read the DNS concepts specification .

Record types provide different evidence. Address records associate names with addresses, MX records identify mail exchangers, NS records describe authoritative servers, and TXT records carry text with application-specific meaning. A TXT value mentioning a provider is a lead about configuration, not proof every provider feature is active.

AXFR transfers the contents of a DNS zone under the protocol’s rules. It is not inherently a misconfiguration and does not return every host in an entire delegated domain tree. Whether a requester is permitted to receive a zone is an authorization and configuration question. Read the AXFR specification .

Observation	Reasonable interpretation
Two names, one address	Shared resolution result, with service identity still unresolved
Alias to a provider name	A DNS dependency worth validating with the asset owner
Child-zone delegation	Separate authoritative data below the delegation point
No public answer	No answer from this query context, not proof no internal service exists

Understand Certificate Transparency #

Certificate transparency (CT) makes submitted certificates and precertificates auditable through public logs. It supports monitoring issuance in the public web PKI ecosystem. It is not a complete database of every certificate, private PKI, or service endpoint. Read how CT works .

Certificate names provide historical naming evidence. A certificate containing portal.example.com suggests the name mattered to its requester at issuance, but does not prove a service is currently reachable there. A wildcard such as *.example.com does not enumerate all individual names covered by its pattern.

Log duplicates also need interpretation. One certificate submitted to several logs is not several independently observed servers. Preserve the certificate identity and source relationships when counting evidence.

Certificate evidence	Supported statement	Unsupported leap
Named entry	A name appears in the recorded certificate	A live vulnerable server exists
Wildcard entry	A wildcard name was included	Every possible subdomain is deployed
Expired certificate	Historical issuance evidence exists	The associated service remains active

Treat Scan Data as Historical #

Shodan records describe observations made by Shodan’s collection systems. Their value comes from the captured service information and associated timestamps. A stored banner is not a new measurement from your current vantage point.

Timeframes matter. Shodan documents different historical windows across its services, with its principal search interfaces presenting recent banner observations within a defined rolling window. Read the record’s collection timestamp and the interface’s documented behavior before describing a result as current. Read Shodan’s data-timeframe documentation .

Service identity needs corroboration. An address might be reassigned, a reverse proxy might answer on behalf of several applications, or a banner might conceal the underlying version. A result is a lead for the approved validation plan, not automatic proof of ownership or vulnerability.

Compare these times	Why they differ
Observed at	When the provider collected the source observation
Retrieved at	When you obtained the record
Published at	When a page or report became available
Valid for decision	Your stated freshness requirement for the research question

Choose Automation by Behavior #

SpiderFoot provides modules for gathering and correlating information from multiple sources. Module selection, API access, and collection behavior affect what a run does. Review the selected modules before assuming a tool labeled “OSINT” only reads existing third-party records. Read the project documentation .

Tool choice follows the question. A graph helps review relationships, a document parser extracts metadata, and a search service locates indexed material. None of those operations independently verifies the meaning of the resulting relationship.

Rate and data limits belong in the collection plan. Record provider limits, allowed input types, and the necessary output fields before automation. Avoid expanding from an approved domain investigation into unrelated personal profiles because a module offers more pivots.

Need	Appropriate tool behavior	Review requirement
Find published material	Search an index	Verify the original source
Correlate names	Normalize and graph records	Preserve provenance and duplicates
Extract document metadata	Parse a saved public file	Distinguish metadata from verified identity
Map exposure leads	Read existing service observations	Check age, ownership, and scope

Normalize Without Inventing Evidence #

Normalization removes superficial differences while preserving the original observations. Lowercasing a DNS name and removing its final root dot helps compare names. Treat a certificate wildcard separately instead of converting it into an invented host.

Run this local example with Python 3. It performs no network requests and writes no files. The output separates exact names from a wildcard certificate pattern.

observations = [
    "Portal.Example.com.",
    "portal.example.com",
    "*.example.com",
    "status.example.com",
]

names = set()
wildcards = set()
for original in observations:
    normalized = original.lower().rstrip(".")
    if normalized.startswith("*."):
        wildcards.add(normalized)
    else:
        names.add(normalized)

print("Exact names:", ", ".join(sorted(names)))
print("Wildcard patterns:", ", ".join(sorted(wildcards)))

Expected output contains two distinct exact names and one wildcard pattern. The duplicate portal spelling collapses into one name, but your evidence ledger should retain both original source rows. Deduplication for counting is different from deleting provenance.

Exact names: portal.example.com, status.example.com
Wildcard patterns: *.example.com

Work an Evidence Case #

Illustrative case: an assessment permits research about the fictional Example organization. The active-scan list contains status.example.com only. You collect the following synthetic records while investigating whether a second portal needs ownership review.

Record	Observation	Collection context
A	Certificate names portal.example.com	Issued 18 months before review
B	Blog repeats the certificate name	Links directly to record A
C	Archived banner identifies a portal	Provider observed it 24 days earlier
D	Owner inventory lists a retired portal	Inventory updated this week

Analyze the evidence: decide whether A and B independently corroborate the portal’s current state. Identify the newest relevant record and the unresolved relationship between C and D. Then decide whether these records authorize scanning the portal.

Expected reasoning: B repeats A, so they share one underlying source. D is the newest inventory statement, while C reflects an earlier external observation. The apparent conflict might represent a retirement after collection, a stale inventory, or a mistaken service association.

The next action is ownership clarification through the assessment’s agreed contact. The evidence supports asking about an unresolved exposure lead, not adding the portal to the scan list. A useful brief names the exact conflict and requests the smallest confirmation needed.

Claim ID: OSINT-PORTAL-01
Question: Does the historical portal need approved exposure validation?
Supported facts: Certificate name, dated banner, retirement inventory entry
Shared sources: B derives from A
Uncertainty: Current state and relationship between C and D
Scope status: Not on the approved active-scan list
Next action: Ask the asset owner to reconcile the records
Evidence locations: A, B, C, D with source URLs and timestamps

Assess Source Quality #

Independent corroboration depends on origin, not website count. Ten articles repeating one press release still share a source. Follow citations backward and retain both the originating item and the later interpretation when the distinction matters.

Visual evidence also needs context. An image or video supports claims about what it depicts only after its origin, location, time, and relevant features are examined. Bellingcat’s verification examples demonstrate checking an item’s claimed context against other evidence. Read its social-media verification guide .

Confidence should explain reasoning rather than imply a calculated probability without a model. Use terms such as “supported historical observation,” “current owner confirmation,” and “unverified lead.” State what new evidence would change the conclusion.

Quality question	Useful check
Origin	Locate the earliest identifiable source
Freshness	Compare collection time with the decision window
Independence	Trace whether sources copy one another
Contradiction	Record evidence challenging the preferred explanation
Relevance	Connect the observation to the research question

Watch the Toolkit Introduction #

Bellingcat’s toolkit presentation introduces resources for open-source investigation. Use it to choose a method for a defined question rather than collecting a long list of unrelated tools. For one demonstrated resource, write down its input, output, and verification limits.

Watch on YouTube: Presenting: The Bellingcat Online Open Source Investigations Toolkit .

Create Your Research Brief #

Build a one-page brief from five synthetic observations. Include one duplicate source, one stale record, one conflicting record, and one item irrelevant to the research question. Explain which items affect the decision and which do not.

Preserve a minimal evidence package with source URLs, retrieval times, original records where appropriate, and the relevant excerpts. Avoid unnecessary personal information or secrets. If a public source appears to expose a credential, follow the agreed reporting process rather than treating availability as permission to use it.

Brief section	Required content
Question and scope	What the research should answer and permitted next actions
Evidence	Observations with provenance and timestamps
Analysis	Corroboration, contradictions, and source dependencies
Conclusion	Supported answer and explicit uncertainty
Next action	Owner, requested clarification, or approved validation

Evaluate your brief by asking another reader to reconstruct the reasoning from the preserved evidence. They should distinguish what you observed, what you inferred, and what remains unresolved. A persuasive paragraph without traceable sources is not a finished intelligence product.

Check Your Understanding #

Collection: does public availability guarantee an unobserved lookup?
Registration: why is an IP allocation record insufficient to establish scan scope?
Certificates: does a wildcard enumerate deployed hostnames?
Corroboration: do two websites repeating one certificate entry count as independent evidence?
Freshness: which timestamp describes when a scan provider observed a banner?

Question	Expected reasoning
Collection	Providers and contacted systems have their own observation paths
Registration	Resource registration and assessment authorization are separate facts
Certificates	A wildcard is a naming pattern, not a host list
Corroboration	Shared origin limits independence
Freshness	The observation timestamp, distinct from your retrieval time

Next Steps #

Active reconnaissance tests approved questions against current services. Continue to Module 9: Active Reconnaissance and Scanning with a bounded target list and unresolved questions. Return to the Red Team Course hub for the full sequence.

Read More at https://simeononsecurity.com/

CompTIA A+ (220-1202): Software Troubleshooting

Wed, 01 Jan 2025 00:00:00 +0000

Click Here to Return To the CompTIA A+ Course Page

Software Troubleshooting is 23% of the CompTIA A+ 220-1202 Core 2 exam. This module covers Windows OS issues, mobile OS and application problems, security symptoms, and malware removal. Pair this domain with the Core 1 troubleshooting methodology because the same process applies to software.

Software problems frustrate users and fill the ticket queue. You read the symptoms, match them to a cause, and apply the fix that solves the problem without losing data. This module covers the software faults you will see most.

Windows OS Troubleshooting #

You diagnose the common Windows failures.

Symptom	Likely cause	Fix
BSOD / stop error	Bad driver, RAM, or hardware	Check driver, run memory test
Boot failure	Corrupt boot files	Startup Repair, `bootrec`
Frequent shutdowns	Overheating or PSU	Check temps and power
Services not starting	Dependency or corruption	Check Services and Event Viewer
Slow performance	Startup bloat, low disk, malware	Trim startup, free space, scan
Time drift	Dead CMOS battery or NTP	Replace battery, sync time

You repair core files from the command line:

sfc /scannow                       # Repair system files
DISM /Online /Cleanup-Image /RestoreHealth   # Repair the component store
chkdsk C: /f /r                    # Fix filesystem and recover sectors

Mobile OS and Application Issues #

You fix phones and tablets that misbehave.

Apps failing to launch or crashing call for an update, cache clear, or reinstall.
Battery drain points to a rogue app, poor signal, or background activity.
Random reboots suggest an OS bug, a bad update, or failing hardware.
Slow performance traces to low storage or too many background apps.
Connectivity problems need a check of Wi-Fi, cellular, Bluetooth, and airplane mode.

Mobile Security Issues #

You spot signs that a mobile device is compromised.

Symptom	Concern
Jailbreak / root detected	Security controls bypassed
High network traffic	Data exfiltration or malware
Fake security warnings	Scareware or a malicious app
Unexpected app permissions	Spyware or overreaching app
Unusual battery drain	Hidden background activity

Removing root or jailbreak and reinstalling from a clean image restores trust.

PC Security Symptoms #

You recognize a compromised desktop.

Desktop alerts and fake antivirus warnings are scareware.
Altered or renamed files can signal ransomware.
Browser redirection and frequent pop-ups point to adware or a hijacked browser.
Certificate warnings can indicate a man-in-the-middle attack.
New, unknown toolbars or extensions are often malicious.

A privacy-focused browser reduces this risk. See the best privacy browsers .

Malware Removal Techniques #

You remove stubborn malware with the right tools.

Safe Mode loads fewer drivers and services. It helps isolate some faults and malware interference, but it does not guarantee a clean scan.
Preinstallation environments (WinPE) scan offline before Windows loads.
Reimaging wipes and restores a clean OS image when removal fails.
System Restore rolls back to a clean point, though sophisticated malware can survive it.

Follow the full seven-step process detailed in the Security module . Verify file integrity after cleanup using how to get hashes of files in Windows .

Next Steps #

Finish Core 2 with Operational Procedures . Review the Security module for malware types and the Operating Systems module for repair tools. Return to the CompTIA A+ Course and take the CompTIA A+ Practice Test .

Read More at https://simeononsecurity.com/

Module 9: Active Reconnaissance and Scanning

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Active reconnaissance sends requests to a system to answer a defined question about its current behavior. A scan result describes what the scanner observed from a particular location at a particular time. It becomes useful when you preserve the method, interpret the limits, and connect the result to an approved next action.

Allow about 20 minutes, plus time for the loopback exercise. The exercise uses one port on your own machine.

What You Will Learn #

Distinguish host discovery, port state, service identification, and vulnerability validation.
Explain the differences between TCP SYN and connect scans.
Run a bounded local scan and preserve its output.
Analyze conflicting observations from different vantage points.
Create a scan plan with evidence requirements and stopping conditions.

Term	Meaning
Vantage point	Network location and routing context of the observer
Host discovery	Probes used to identify responsive addresses
Port scan	Probes used to classify transport endpoints
Service identification	Evidence about the application using an endpoint
Deconfliction	Coordination which distinguishes assessment activity from other events
Scan manifest	Record of targets, options, timing, source, and purpose

Ask a Bounded Question #

Start with the decision. “Does the training web service accept TCP connections on its assigned port?” needs less probing than a complete asset inventory. Define the target, transport, port, and allowed method before choosing options.

Scope and ownership remain separate from reachability. A name resolving to an address does not expand your authorization to every service or tenant using it. Carry unresolved ownership questions from Module 8 into the scan plan instead of resolving them through speculative probes.

Source selection determines which network boundary the scan tests. Use the agreed assessment source and record its identity. A redirector is a forwarding role, not a requirement for every scan, and a disposable source still creates costs, records, and coordination obligations.

Question	Smallest relevant observation
Is this port reachable?	Transport response from the approved source
Which service answers?	Authorized application-level response
Does a control block access?	Response plus control-side evidence
Is a vulnerability present?	Separate validated conditions beyond a port label

Understand Scan States #

Nmap states describe the scanner’s interpretation of responses. An open TCP port accepts connections, while a closed port responds without a listening service. Filtered means the scan lacks enough access to determine whether the port is open. These are observations rather than permanent properties of a machine. Read Nmap’s port-state definitions .

Combined states, such as open|filtered, preserve ambiguity. Do not convert them into confirmed open services when building a report. The permitted interpretation depends on the scan method and returned evidence.

Vantage point matters. A service reachable from a management subnet might be filtered from a guest subnet. Those results are compatible with a working segmentation policy, so retain both rather than selecting whichever looks more conclusive.

The scan’s location and method are part of the result

Compare TCP Scan Methods #

A TCP connect scan, selected with -sT, asks the operating system to establish a connection. It completes the TCP handshake when an open service accepts it. It does not require the raw-packet privileges used by a SYN scan. Read Nmap’s connect-scan documentation .

A SYN scan, selected with -sS, examines responses without completing the connection in the same way. Both methods remain observable to suitable sensors. Completing a handshake is insufficient evidence of normal application use or avoided detection.

Method choice follows privileges, platform support, the question, and the permitted assessment behavior. Nmap’s own documentation describes the greater likelihood of application-side records from connect scans. Avoid teaching -sT as universally quieter than -sS.

Method	Connection behavior	Interpretation limit
TCP connect	Uses the operating system’s connection API	Successful handshake proves no application operation
TCP SYN	Evaluates raw TCP responses	Half-open does not mean unobserved
Service probes	Add application-specific requests	More interaction than a port-state check

Separate Discovery From Scanning #

Host discovery is a preliminary question about responsive addresses. Nmap supports several probe types, so it is broader than an ICMP echo request. A blocked discovery probe does not establish the unreachability of every service on the address. Read the host-discovery reference .

-Pn skips ordinary host discovery and treats specified targets as available for the requested scan. It is not a stealth option and does not make a failed route work. On some local network paths, link-layer resolution still takes place.

Port selection should reflect the question. The -p option selects explicit ports, while an ordinary default scan covers Nmap’s selected common ports rather than every possible port. Record the exact selection so readers understand what the scan omitted. Read the port-specification reference .

Observation	Insufficient conclusion
No discovery reply	Every service is unavailable
One selected port is closed	The host has no listening applications
Default scan finds nothing	All TCP and UDP ports were tested
TCP connection succeeds	Authentication and application access will succeed

Run a Loopback Exercise #

Prepare a temporary service with Python 3 in a terminal. The server binds only to 127.0.0.1, and --directory points to a newly created empty folder. This keeps the example’s service off external interfaces and away from your working files. Read Python’s demonstration-server documentation .

scan_lab_dir=$(mktemp -d)
python3 -m http.server 8765 --bind 127.0.0.1 --directory "$scan_lab_dir"

Use a second terminal with Nmap installed to scan the one local port. First create a temporary results directory so repeated exercises do not overwrite previous evidence. The command requests a TCP connect scan, skips DNS lookups and host discovery, and saves XML plus readable output.

scan_results_dir=$(mktemp -d)
nmap -sT -Pn -n -p 8765 --reason \
  -oX "$scan_results_dir/listening.xml" \
  -oN "$scan_results_dir/listening.nmap" \
  127.0.0.1

Flag meanings: -sT selects connect scanning, -Pn skips ordinary discovery, -n disables DNS resolution, and -p 8765 restricts the port list. --reason includes the basis for the state classification. -oX and -oN name the XML and readable output files. Read Nmap’s output reference .

Expected result: port 8765/tcp appears open while the local server is listening. The displayed service name is not proof Python’s HTTP server was identified. No version-detection option was requested.

Exercise phase	Expected TCP state	Required condition
Server running	Open	Server bound successfully to the chosen port
Server stopped	Closed	No replacement listener or filtering interference

Stop the server with Ctrl+C in its terminal. Repeat the scan from the second terminal using different output filenames. Leave the source, target, options, and port unchanged so the listener state is the intended difference.

nmap -sT -Pn -n -p 8765 --reason \
  -oX "$scan_results_dir/stopped.xml" \
  -oN "$scan_results_dir/stopped.nmap" \
  127.0.0.1

Compare your observations with the expected states. If the port remains open, check for another listener or an unsuccessful shutdown. If the initial scan was closed, check whether the server started and whether both commands used the same port.

Preserve the evidence before removing the disposable directories. Print their paths with printf '%s\n' "$scan_lab_dir" and printf '%s\n' "$scan_results_dir" in the respective shells. This exercise demonstrates a controlled state change, not the behavior of a remote firewall.

Identify Services Separately #

A port-number label is a naming convention, not a measured application identity. A service on port 443 is not automatically HTTPS, and an HTTP service is not restricted to port 80. Nmap’s -sV option performs additional probes to identify services and versions. Read the service-detection reference .

Additional probes change the test. A transport check, a banner request, an authenticated application test, and a vulnerability test have different prerequisites and effects. Keep them as separately justified actions rather than adding every available option to the initial command.

Version strings also need context. Reverse proxies, customized banners, vendor backports, and incomplete fingerprints complicate interpretation. A suspected version warrants an evidence-based follow-up, not an automatic vulnerability claim.

Evidence	What to report
Port-state result	Endpoint, method, state, reason, and vantage
Application response	Protocol behavior and observed identifying fields
Version inference	Matched evidence and confidence limits
Validated finding	Specific conditions, supported impact, and reproduction boundaries

Work a Segmentation Case #

Illustrative scenario: a management-source scan reaches a training service, while an approved guest-source scan reports the same port as filtered. Both runs use the same method and time window. The service owner confirms the listener remained healthy throughout.

Analyze the difference before requesting more probes. Identify the policy question, the additional evidence needed, and the strongest conclusion supported by the two results alone. Assume the intended policy permits management access and denies guest access.

Expected reasoning: the observations are consistent with the intended separation. They do not identify the exact filtering device or prove every guest path is blocked. Correlate the test timestamps with the relevant network-control records to locate the enforced boundary.

Proposed statement	Assessment
“The service was unavailable”	Contradicted by the management observation
“The guest test did not reach an open service”	Supported within the recorded method and window
“Every guest access path is blocked”	Broader than the tested evidence

Watch the Nmap Presentation #

Fyodor’s ShmooCon presentation explains network reconnaissance with Nmap. The official Nmap site hosts the presentation context and slides. Focus on how a probe produces evidence and how the observer interprets it. Read the presentation page .

This talk is from 2006. Use the current manual for platform support, defaults, and option behavior.

Watch on YouTube: Fyodor - Advanced Network Reconnaissance with Nmap - ShmooCon 2006 .

Create a Scan Manifest #

Design a bounded scan for an approved training service using the template below. Define the information needed, the smallest relevant port set, and the source from which the result matters. Include a stop condition tied to service health or a scope mismatch.

Scan ID and purpose:
Approved target and resolved address:
Source host, address, and network context:
Transport, ports, and exact command:
Tool version and required privileges:
Start/end timestamps and clock reference:
Expected observations:
Health checks and stopping conditions:
Raw output paths:
Observed states and reasons:
Uncertainty and proposed next action:

Review the manifest against the original question. A useful plan makes omitted coverage visible and records why further probing is justified. Keep scan evidence available for deconfliction even if no alert or finding resulted.

Check Your Understanding #

Methods: why is a connect scan not inherently invisible?
States: what does filtered leave unresolved?
Labels: why is a port’s service label insufficient to identify an application?
Coverage: what did the loopback exercise leave untested?

Question	Expected reasoning
Methods	Completed connections and patterns remain observable
States	Whether the service is open beyond the filtering boundary
Labels	Port conventions differ from observed protocol behavior
Coverage	Other ports, UDP, remote routes, authentication, and application vulnerabilities

Next Steps #

Initial-access planning uses validated context and a separate assessment objective. Continue to Module 10: Initial Access, Phishing and Delivery to distinguish delivery, user interaction, and execution evidence. Return to the Red Team Course hub for the full sequence.

Read More at https://simeononsecurity.com/

CompTIA A+ (220-1202): Operational Procedures

Wed, 01 Jan 2025 00:00:00 +0000

Click Here to Return To the CompTIA A+ Course Page

Operational Procedures is 21% of the CompTIA A+ 220-1202 Core 2 exam. This module covers documentation, change management, backups, safety, environment, professionalism, scripting, remote access, and AI basics. This domain is about doing the job correctly and professionally, not just technically.

A great technician follows process. You document your work, manage change safely, back up before you break things, stay safe, and treat customers well. This module covers the professional habits that keep IT running and keep you employed.

Documentation Best Practices #

You record everything so others can follow your work.

Document	Purpose
Ticketing system	Tracks issues and resolutions
Asset management / CMDB	Inventories hardware and software
Standard Operating Procedures (SOPs)	Step-by-step process guides
Knowledge base	Reusable how-to articles
Network topology diagrams	Maps the network layout

Change Management #

You control change so it does not cause outages.

Request the change with a documented form.
Assess risk and the scope of impact.
Test in a sandbox before production.
Get approval from the change board.
Plan a rollback in case the change fails.
Implement during a maintenance window.
Document the result.

A rollback plan is what saves you when a change goes wrong.

Backup and Recovery #

You protect data with the right backup type and rule.

Backup type	What it copies
Full	Everything, slowest
Incremental	Changes since the last backup
Differential	Changes since the last full
Synthetic full	A full rebuilt from prior backups

The 3-2-1 rule keeps 3 copies of data on 2 media types with 1 copy offsite. Test restores regularly because an untested backup is not a backup.

Safety Procedures #

You protect yourself and the equipment.

ESD straps and mats prevent static damage to components.
Electrical safety means unplugging before service and never opening a PSU or CRT.
Proper lifting uses the legs, not the back.
Fire safety uses a Class C extinguisher for electrical fires.

Environmental Controls #

You handle materials and power responsibly.

MSDS/SDS sheets describe safe handling and disposal of chemicals.
Battery and toner disposal follows local regulations, never the trash.
A UPS provides battery backup and clean power during outages.
A surge suppressor protects against voltage spikes.
Maintain proper temperature and humidity to prevent damage and static.

Policies, Privacy, and Professionalism #

You follow legal and ethical rules.

Chain of custody documents evidence handling for incidents.
DRM and EULA govern software licensing and use.
Regulated data like PII, PHI, and PCI requires special handling.
Acceptable Use Policies (AUPs) define proper use of company systems.

You use professional communication: clear language, active listening, setting expectations, and respecting the customer. Never argue or talk down to a user, even when they are wrong.

Scripting and Remote Access #

You automate tasks and support users remotely.

Extension	Language	Use
.bat	Batch	Legacy Windows scripts
.ps1	PowerShell	Windows automation
.vbs	VBScript	Older Windows automation
.sh	Shell	Linux/macOS automation
.py	Python	Cross-platform scripting
.js	JavaScript	Web and automation

Remote tool	Use
RDP	Full Windows remote desktop
VPN	Secure tunnel to a network
SSH	Secure command-line access
VNC	Cross-platform screen sharing
RMM	Remote monitoring and management

AI Basics #

The 220-1202 exam now includes basic AI concepts. You apply AI tools responsibly.

Application integration brings AI into business workflows.
AI policy covers appropriate use and plagiarism concerns.
AI limitations include bias, hallucinations, and accuracy problems, so verify AI output.
Private vs public AI differs in data security, data source, and privacy. Never paste sensitive company data into a public AI tool.

For the bigger picture, read the state of AI in cybersecurity .

Next Steps #

You have now completed all nine A+ modules across both exams. Test your readiness with the CompTIA A+ Practice Test , then review weak areas in Operating Systems , Security , and Software Troubleshooting . Return to the CompTIA A+ Course and explore more in Courses and Playbooks .

Read More at https://simeononsecurity.com/

Module 10: Initial Access: Phishing and Delivery

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Initial access is the establishment of a usable starting context for an assessment. A delivered message, a clicked link, and code execution represent different outcomes. Your test should identify which boundary it examines and collect evidence appropriate to the tested boundary.

Allow about 20 minutes, plus time to design the simulation record. The worked examples use synthetic events and require no messages sent to real recipients.

What You Will Learn #

Distinguish delivery, interaction, execution, and communication outcomes.
Explain how email, document, identity, and endpoint controls affect an access path.
Analyze a synthetic campaign’s rates and ambiguous events.
Evaluate whether two simulations support a fair comparison.
Create a bounded initial-access test specification and handover record.

Term	Meaning
Delivery	A message or artifact reaches the specified destination
Interaction	A recorded action such as following a link
Execution	Instructions run in an identified process and security context
Foothold	Usable access within the assessment’s permitted scope
Mark of the Web	Windows zone information associated with some downloaded files
Simulation artifact	Harmless material used to exercise an agreed control or behavior

Choose the Access Boundary #

Phishing is one initial-access technique, not a universally reliable route. Its outcome depends on the scenario, delivery path, controls, and user context. An assessment might instead examine a public application boundary or begin from a deliberately supplied test account.

Remote code execution means an input causes instructions to run remotely. An upload feature alone does not establish this condition. File validation, storage location, server configuration, execution permissions, and how the uploaded content is handled determine the effect.

A web shell is server-side code exposing a command interface through a web application. Its presence is an execution and access concern, not the ordinary outcome of every uploaded document. Keep a suspected upload weakness separate from proof of server-side execution. Read MITRE ATT&CK’s web-shell description .

Proposed test	Boundary examined	Minimal useful proof
Mail simulation	Delivery and recipient response	Correlated message and interaction records
Document-control test	Opening and execution policy	Policy result for an inert test artifact
Application assessment	Input handling and authorization	Bounded reproducible behavior
Assumed-access exercise	Controls after a defined starting point	Documented supplied identity and privileges

Trace the Delivery Chain #

A message’s lifecycle crosses several independent controls. Sending infrastructure, receiving mail systems, clients, browsers, endpoint policy, and network access each contribute a possible outcome. Name the stage where the observation occurred instead of reporting every failure as “phishing blocked.”

Human interaction also needs interpretation. A tracking request does not necessarily establish a deliberate click by the recipient. Microsoft documents false positives caused by security applications and automated message inspection, including interactions with forwarded simulation messages. Read the simulation FAQ .

Execution and callback evidence are separate again. Even an authorized test program which starts successfully might fail to reach its reporting endpoint. Use the task-state distinctions from Module 5 when recording these outcomes.

Each transition needs evidence beyond success at the previous stage

Set Up the Measurement #

Gophish campaign configuration combines recipients, an email template, a landing page, a sending profile, and scheduling details. Its campaign records track events for analysis. Review the platform’s event definitions before assigning stronger meanings to the displayed labels. Read the Gophish campaign documentation .

A sending profile defines the approved sending service and related settings. It does not inherently require impersonating an unrelated organization. A landing page also need not collect credentials, so choose an inert completion page when a link-following measurement meets the objective.

Training and control assessment differ in purpose. An awareness exercise measures recognition, reporting, and learning under defined conditions. A technical assessment measures whether the delivery and execution controls work along an agreed path, so changes which permit training delivery alter the technical test.

Measurement	Useful evidence	Limitation
Delivered	Receiving-system or platform delivery record	Does not prove the recipient read it
Opened	Platform-defined observation	Image handling and client behavior affect it
Clicked	Correlated interaction record	Automated inspection needs review
Reported	User-reporting workflow event	Platform coverage and timing differ
Executed	Endpoint-side process and result evidence	Does not prove usable remote access

Account for Document Controls #

Office macro behavior depends on application version, file origin, and policy. Microsoft’s current guidance documents default blocking of macros from internet-sourced files in affected Office applications. An older demonstration of an attachment launching code is insufficient evidence of behavior on a current managed device. Read Microsoft’s macro-blocking guidance .

Record the environment before testing a document control. Include the application build, delivery method, relevant policy, and observed warning or block. A harmless file with no executable content tests delivery or opening, but not whether a malicious macro would have executed.

Do not change the tested control mid-run merely to obtain a desired outcome. If the approved exercise needs an exception for training delivery, record the exception and narrow the conclusion accordingly. An intentionally permitted path does not establish the baseline control would have allowed it.

Test condition	Conclusion boundary
Inert attachment opens	File delivery and opening worked
Macro policy blocks a test document	The observed policy prevented the tested execution path
Training delivery exception enabled	Result applies to the exception configuration
Different Office build used	Comparison needs a version qualification

Work Through Campaign Rates #

Illustrative scenario: a simulation targets 100 approved training accounts. Ten messages fail delivery. Among the 90 delivered messages, the platform records 18 unique accounts with click events, and review identifies six of those accounts as automation-only events. Fifteen accounts report the message through the training workflow.

Calculate the rates before interpreting them. Use delivered accounts as the denominator for this exercise and count each account once per metric. The reporting and clicking groups might overlap, so do not add them as mutually exclusive categories.

Metric	Calculation	Result
Delivery rate	90 / 100	90%
Raw recorded-click rate	18 / 90	20%
Reviewed user-click rate	12 / 90	About 13.3%
Reporting rate	15 / 90	About 16.7%

Expected reasoning: the raw click count overstates the reviewed user count in this synthetic dataset. Keep both values and document the review criteria rather than silently editing history. None of these rates establishes a compromised endpoint or a captured credential.

A stronger report includes delivery failures, ambiguous events, reporting delay, and the exact denominator. Microsoft provides several simulation and training reports with defined metrics, so use the relevant report’s definitions when interpreting a real export. Read the reporting documentation .

Compare Difficulty Fairly #

Different messages create different tasks for recipients. An obviously unrelated request and a plausible work-context message are not equivalent challenges. A lower click rate on the easier message does not establish improved recognition across all phishing scenarios.

The NIST Phish Scale provides a method for rating human phishing-detection difficulty. It considers message cues and premise alignment with the audience. Use its documented method alongside outcome metrics when comparing exercises. Read the NIST Phish Scale User Guide .

Compare like conditions wherever possible. Record audience, message difficulty, reporting tools, delivery exceptions, timing, and any preceding training. If several conditions changed, describe the combined result and avoid attributing it to one cause.

Comparison difference	Possible effect
New recipient group	Different role context and prior experience
Different message premise	Different detection difficulty
Delivery-policy exception	Different exposure to the technical controls
Automated-click filtering	Different measurement rather than changed behavior

Inspect Architecture Context #

Windows process architecture matters when interpreting a subsequent test. Starting a service or using a particular operator command does not automatically imply a 32-bit process. Verify the actual process, operating system, and artifact architecture instead of inferring them from the workflow’s name.

WOW64 filesystem redirection affects many accesses from 32-bit processes to the Windows system directory on 64-bit Windows. The Sysnative alias lets a 32-bit application address the native system directory. It is not an ordinary physical directory or a universal path for 64-bit applications. Read Microsoft’s filesystem-redirector documentation .

A read-only PowerShell check distinguishes the current shell process from the operating system. Run it inside the shell whose context you are examining. It says nothing about the architecture of an unrelated application.

[Environment]::Is64BitOperatingSystem
[Environment]::Is64BitProcess

Interpret the booleans in order. A true OS result and false process result indicate a 32-bit PowerShell process on a 64-bit operating system. Two true results indicate a 64-bit process on a 64-bit OS. Read the .NET process-architecture property .

Handle Unexpected Recipients #

Forwarding and remote reading introduce scope uncertainty. A simulation URL tied to one recipient might be fetched from another device or by another person. Treat the correlation token as a record key, not proof of the operator’s identity or device ownership.

An unexpected interaction should trigger the agreed containment and review process. Stop any dependent assessment action, retain the minimal event evidence, and reconcile the event with the campaign owner. Avoid expanding endpoint access based only on a callback’s arrival.

Handover field	Why it matters
Message and recipient IDs	Correlate the planned delivery
Observed interaction	Describe the event without assuming identity
Endpoint identity	Confirm the approved asset where relevant
Process and token context	Bound any execution claim
Allowed next action	Prevent automatic expansion beyond the test

Watch the Simulation Overview #

Microsoft Security’s overview introduces Attack Simulation Training and its measurement purpose. Watch for how simulation outcomes lead to targeted learning and subsequent evaluation. Compare the presentation’s metrics with the denominator and ambiguity checks above.

The video is an introductory 2021 presentation. Consult current product documentation for availability, UI details, and event semantics.

Watch on YouTube: Attack Simulation Training with Microsoft .

Design Your Test Specification #

Create a specification for an inert link simulation using synthetic recipients. Define delivery evidence, a user-interaction criterion, an automated-event review rule, and a reporting objective. State explicitly which execution and access questions the simulation leaves unanswered.

Test ID and approved objective:
Recipients and excluded groups:
Sending service and artifact revision:
Landing-page behavior and collected fields:
Delivery window and stopping conditions:
Delivery evidence:
Interaction evidence and automation review:
Reporting metric and denominator:
Technical-control exceptions:
Unexpected-recipient handling:
Retention, owner, and follow-up:

Evaluate the design by applying it to the worked dataset. Another reader should reproduce the four rates and explain the remaining uncertainty. Revise any metric which labels a click as endpoint compromise without separate evidence.

Check Your Understanding #

Stages: why is message delivery insufficient proof of execution?
Automation: what else generates a recorded link interaction?
Comparison: why does message difficulty matter when comparing rates?
Architecture: does a 64-bit OS prove the current process is 64-bit?

Question	Expected reasoning
Stages	Client, application, policy, and user-action boundaries remain
Automation	Security inspection, link analysis, and other automated processing
Comparison	The recipient’s recognition task changed
Architecture	A 32-bit process also runs on supported 64-bit Windows systems

Next Steps #

Host awareness establishes what an approved starting context contains. Continue to Module 11: Situational Awareness and Host Operations for identity, process, network, and freshness checks. Return to the Red Team Course hub for the full sequence.

Read More at https://simeononsecurity.com/

Module 11: Situational Awareness and Host Operations

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Situational awareness is a current, evidence-backed picture of the host and security context where an assessment action would run. It starts with identity and scope, then adds the process, network, and service facts needed for the next decision. Collecting every available field is less useful than answering the right questions accurately.

Allow about 18 minutes, plus time to create the host-state record. Commands below inspect local state and do not require credential extraction.

What You Will Learn #

Identify the host, account, process, and network context separately.
Explain why an interface address does not establish a usable route.
Apply read-only Windows or Linux checks in a training environment.
Analyze changes between two host snapshots.
Create a handover record with freshness and collection limits.

Term	Meaning
Host identity	Evidence tying the current system to an approved asset
Security context	Identity and permissions used by the current process or thread
PID	Process identifier, valid within its host and lifetime
Listener	Socket accepting incoming communication
Route	Rule selecting how traffic reaches a destination
Snapshot	Observations collected during a stated time window

Establish Identity Before Interpretation #

A hostname or IP address is one part of an identity check. Match it against the approved inventory and available asset identifiers. DHCP changes, aliases, cloned lab systems, and virtual interfaces make a single label insufficient in some environments.

The account context is a separate fact. A visible desktop user, a remote session’s user, and a service account need not be the same principal. Reuse the SID and token distinctions from Module 4 before interpreting access results.

Freshness belongs beside each observation. A process list gathered before a service restart does not describe the replacement process. Record the collection window and repeat only the checks invalidated by a relevant state change.

Question	Evidence	Common shortcut to avoid
Which host?	Inventory match plus local identifiers	One familiar name
Which account?	Current identity and authority	Visible desktop owner
Which process?	PID, image, start time, and context	Process filename alone
When observed?	Timestamp and collection window	Undated pasted output

Build a Minimal Snapshot #

Choose fields by purpose. Before a local configuration check, you need the current account and target object’s context. Before interpreting an outbound connection, you need the source process, route, destination, and relevant time. These questions call for different snapshots.

Collection itself is activity. Native commands, scripts, and in-process extensions differ in implementation, but all require evidence appropriate to their behavior. Avoid assuming a BOF is automatically quiet or a built-in executable automatically safe for any workload.

Missing information should stay visible. Permissions, process termination, tool filtering, and collection failures all affect completeness. Record “not collected” or “access denied” when appropriate rather than replacing uncertainty with an empty field.

Refresh the fields affected by a change before relying on the snapshot

Inspect Windows Identity #

Start with local identity in a Windows training shell. hostname prints the computer name, whoami /user includes the current user SID, and whoami /groups shows group information for the current context. Compare the result with the approved inventory and account. Read the whoami reference .

hostname
whoami /user
whoami /groups
ipconfig /all

ipconfig /all displays detailed adapter configuration. Read the adapter names, addresses, masks, gateways, and DNS settings together. An address alone does not prove a network is reachable or in scope. Read the ipconfig reference .

Identity and network fields need separate interpretation. A domain account does not establish organizational ownership of every listed network. A successful local identity query also does not establish the account’s permissions on a remote resource.

Output field	Use in the snapshot
Computer name	Correlation with approved asset records
Account SID	Stable identity reference within its authority
Group state	Context for later permission interpretation
Adapter and gateway	Starting point for route analysis

Correlate Processes and Sockets #

Process and connection lists provide complementary observations. tasklist /v adds verbose process information, while netstat -ano displays connections and listeners numerically with associated PIDs. Read both during a short collection window. Read tasklist and netstat .

tasklist /v
netstat -ano

Flag meanings: /v requests verbose task information. For netstat, -a includes connections and listening endpoints, -n keeps numeric addresses and ports, and -o includes the owning PID. These flags inspect state rather than proving application purpose.

PID correlation has a time boundary. A process might exit between commands, and a later process might reuse its identifier. Include image path and start-time evidence where available before joining records from distant timestamps.

Socket observation	Interpretation limit
Loopback listener	Local binding does not establish remote exposure
Wildcard listener	Listening scope does not prove firewall permission
Established connection	Connection state does not establish authorized application behavior
PID match	Correlate within the correct host and process lifetime

Use Process Explorer Carefully #

Process Explorer adds an interactive view of running processes, handles, DLLs, and mapped files. Its lower-pane modes help connect a selected process with resources it has opened. Use this to investigate a specific question rather than treating a large tree as a conclusion. Read Microsoft’s Process Explorer overview .

A useful observation includes the selected process, timestamp, relevant properties, and what the view establishes. An image with a familiar name still needs context such as path, signer information, parentage, and behavior. A signature is evidence about provenance, not a blanket approval of every action.

Pavel Yosifovich’s demonstration explains Process Explorer features in Microsoft’s Sysinternals series. Watch for the distinction between process identity and loaded resources. Then choose one view which would improve your own host-state record.

Watch on YouTube: Sysinternals: Process Explorer deep dive .

Inspect Linux Context #

Kernel and distribution identity answer different questions. uname -a reports kernel and machine information, while /etc/os-release provides distribution identification fields on systems implementing this interface. Neither replaces a package inventory or patch assessment. Read uname and os-release .

id
uname -a
cat /etc/os-release
ip address show
ip route show
ss -lnt

id reports user and group identity for the invoking context. ip address show lists address assignments, and ip route show displays routes in the default listing context. More complex policy routing requires additional interpretation beyond this initial view. Read the address and route references.

ss -lnt displays listening TCP sockets using numeric values. -l selects listeners, -n avoids service-name resolution, and -t selects TCP. Add process information only when needed and available under the current permissions. Read the ss reference .

Linux evidence	Useful distinction
User and groups	Current identity versus another logged-in session
Kernel release	Kernel information versus distribution branding
Addresses	Assigned interfaces versus reachable destinations
Routes	Selected forwarding path versus permitted application access
Listening socket	Bound endpoint versus an external reachability result

Avoid the Two-Address Shortcut #

Multiple addresses do not automatically make a host a bridge into another network. One interface might have several addresses, a VPN might contribute a route, or a virtual interface might belong to a local container network. Identify the interface type and routing context before drawing a topology conclusion.

Forwarding is another condition. A host having interfaces on two networks does not establish forwarding between them. Routes, forwarding settings, firewall policy, and application behavior determine which communication is possible.

Authorization remains independent. Learning about another network does not make it part of the assessment. Record the relationship as an unresolved topology observation and ask the agreed owner to confirm the permitted next step.

Observation	Follow-up question
Second address	Same interface, different interface, or virtual endpoint?
Additional route	Which destinations and policy context use it?
Two connected networks	Is forwarding enabled and permitted?
New reachable service	Is the asset and proposed action in scope?

Work a Snapshot Difference #

Illustrative scenario: at 09:00, PID 4200 runs the approved training service and listens on loopback port 8765. At 09:10, PID 4200 belongs to a different program, while the training service has PID 6100. Its replacement listener binds to all IPv4 interfaces.

Analyze the change: identify which old observations are stale and which new exposure question needs validation. Decide whether the PID reuse proves the original process changed its identity. Keep process lifetime and socket binding separate in your answer.

Expected reasoning: the 09:00 PID-to-process association is stale. The new program’s reuse of PID 4200 does not make it the same process. The binding change warrants a scoped reachability review, but it does not prove the service is reachable through every firewall or network path.

Evidence needed	Purpose
Process start times	Distinguish old and replacement processes
Image and service association	Identify the new service instance
Current socket binding	Confirm the changed local endpoint
Approved external check	Determine reachability from the relevant source

Keep Privilege Claims Precise #

Elevated privileges affect available operations but do not prove any particular credential material is present. Authentication method, logon state, operating-system protections, and configuration all matter. Microsoft’s Credential Guard documentation describes isolation of certain secrets using virtualization-based security. Read the Credential Guard overview .

Credential extraction is a separate assessment action, not a required step in a basic host snapshot. A host-awareness objective is often satisfied by identity, process, network, and service observations. Keep the collected fields tied to the actual decision.

Read-only does not mean free of effects. An expansive query still consumes resources and produces activity. Bound repeated collection by need, particularly on systems with strict availability requirements.

Claim	More precise record
“Administrator means all secrets available”	Current privileges observed, credential availability untested
“No output means no process”	Query returned no record under the stated context
“Two addresses mean a pivot”	Additional address observed, route and permission unresolved

Create a Host-State Record #

Your deliverable is a concise snapshot for one disposable Windows or Linux system. Collect the smallest set of fields needed to explain its identity, current context, one process, and one socket. Include an explicit freshness limit or event which would invalidate the record.

Approved asset and inventory reference:
Collection start/end time:
Host and account identity:
Current process architecture and security context:
Relevant process PID, image, and start time:
Relevant adapter, route, and socket:
Command or tool version:
Raw output location:
Missing fields or access limitations:
Change which requires a refresh:
Supported next action:

Review the record by handing it to another reader. They should identify what is known, which facts are time-sensitive, and what remains untested. Avoid turning a snapshot into a permanent description of the host.

Check Your Understanding #

Identity: why is a hostname insufficient in some environments?
Processes: what makes a PID-only correlation unreliable over time?
Networks: why do two addresses fail to prove forwarding?
Linux: which source distinguishes distribution identity from kernel information?

Question	Expected reasoning
Identity	Names, aliases, and cloned systems require inventory correlation
Processes	PIDs are reused after process exit
Networks	Address assignment, routing, forwarding, and policy are separate conditions
Linux	os-release provides distribution identification fields

Next Steps #

User persistence introduces changes whose trigger, identity, and removal need separate evidence. Continue to Module 12: User Persistence to examine the lifecycle of a user-context startup entry. Return to the Red Team Course hub for the full sequence.

Read More at https://simeononsecurity.com/

Module 12: User Persistence

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

User persistence arranges for an action to recur in a user’s context after a defined trigger. A configuration entry, a successful launch, and a verified removal are three separate outcomes. This module uses a visible Notepad startup entry in a disposable Windows VM to examine the complete lifecycle.

Allow about 20 minutes, plus two lab sign-ins. Use a dedicated test account and save your work before signing out.

What You Will Learn #

Distinguish logon-triggered startup from boot-triggered services.
Explain user identity, executable availability, and policy dependencies.
Inspect startup configuration before changing it.
Observe a benign entry through creation, trigger, and removal.
Create a lifecycle record with independent cleanup evidence.

Term	Meaning
Startup entry	Configuration requesting execution at a defined trigger
Run value	Named registry value specifying a command at user logon
RunOnce value	Startup configuration intended for a single logon execution
HKCU	HKEY_CURRENT_USER, resolved for the calling context
Trigger	Event which makes the configured action eligible to run
Restoration	Return to the recorded baseline with verification

Define the Persistence Requirement #

Persistence is optional unless the assessment objective requires it. A short test with a controlled starting context might have no reason to create a recurring action. If recurrence is needed, define the trigger, account, duration, and removal owner before choosing a mechanism.

A Run entry uses logon, so a reboot without the relevant user signing in is not a complete test. A service with automatic startup follows a different lifecycle. User persistence also does not automatically increase the account’s permissions. Read Microsoft’s Run and RunOnce documentation .

Configuration success proves only the entry was written. The referenced executable must exist, the relevant user must encounter the trigger, and policy must permit the resulting action. Separate those dependencies in both your test and your report.

Mechanism	Trigger context	Question to verify
User Run value	Relevant user’s logon	Which user hive and command?
User Startup shortcut	Relevant user’s logon	Which shortcut, target, and arguments?
Scheduled task	Configured trigger and principal	Which conditions and execution identity?
Automatic service	Service-control startup behavior	Which account, dependencies, and service state?

Resolve the User Context #

HKCU is context-dependent. It is not a universal alias for whichever person appears on the visible desktop. Record the calling account’s SID before interpreting a user startup entry. Read Microsoft’s predefined-key reference .

Profile portability is also conditional. Even if a profile-management system carries a registry entry to another machine, the executable, path, architecture, and applicable policies still need to match. A roaming profile is not a guarantee of execution across the environment.

Scope your claim to the account and machine observed. A successful test for one user does not establish recurrence for every user on the host. Record machine-level and user-level startup locations separately.

Removing configuration and stopping a running process are different cleanup tasks

Inspect Before Changing #

Start with read-only queries in the test account’s shell. The first command records the SID, while the second displays values under the user Run key. A missing key or an access error is a result to document, not permission to create unrelated configuration.

whoami /user
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"

reg query displays the selected key’s entries without changing them. The /v option, used later, restricts the request to a named value. Save the baseline output with the account and timestamp. Read the reg-query reference .

Autoruns provides a broader view of configured automatic-start locations. Select the appropriate user and inspect the Logon category, while recording any active filters. A hidden entry in a filtered view is not an absent entry. Read the Autoruns documentation .

Baseline field	Purpose
Account SID	Identify the user context
Registry path and view	Reproduce the location inspected
Existing value names	Avoid overwriting another entry
Tool filters	Explain which entries the view omits
Executable path	Establish the intended benign target

Create a Benign Lab Entry #

Use native 64-bit PowerShell in a disposable 64-bit Windows VM with the dedicated account. This exercise assumes the Run key already exists and Notepad is installed at the checked system path. If either prerequisite is missing, use a prepared lab image rather than changing broader startup configuration.

The following code creates one visibly named value pointing to Notepad. It stops if the value already exists, checks the target file, and avoids a force-overwrite option. It does not copy an executable or contact a network endpoint.

$runPath = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run'
$valueName = 'CourseLab-Notepad'
$notepadPath = Join-Path $env:SystemRoot 'System32\notepad.exe'
$runKey = Get-Item -LiteralPath $runPath -ErrorAction Stop

if ($runKey.GetValueNames() -contains $valueName) {
    throw 'The lab value already exists. Review the baseline first.'
}
if (-not (Test-Path -LiteralPath $notepadPath -PathType Leaf)) {
    throw 'The expected Notepad executable is missing.'
}
$expectedCommand = '"' + $notepadPath + '"'
New-ItemProperty -LiteralPath $runPath -Name $valueName `
    -PropertyType String -Value $expectedCommand -ErrorAction Stop

Parameter meanings: -LiteralPath uses the exact registry path, -Name selects the single new value, and -PropertyType String creates a string value. -Value stores the quoted command path, while -ErrorAction Stop prevents continuing past a reported error in the selected operation. Read New-ItemProperty .

Verify the stored value before testing logon. The query should show the visible lab name and the intended quoted path. Recheck the account SID if you opened a different shell or changed credentials.

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v CourseLab-Notepad

Observe the Logon Trigger #

Close existing Notepad windows, save the baseline and creation records, then sign out and back into the dedicated VM account. Observe whether a new Notepad instance appears and collect process evidence for the relevant window. Windows does not promise an immediate launch order for Run entries, so record the observation window rather than assuming a precise startup deadline.

Interpret the trigger carefully. Automatic application restoration or another startup entry also might launch Notepad. Correlate the new entry, the sign-in, and process evidence instead of treating a visible window as unique proof of its origin.

A missing launch calls for dependency checks. Verify the account, stored command, executable availability, startup policy, and recorded errors. Do not alter security settings merely to force the expected result.

Observation	Supported conclusion
Registry value exists	Configuration creation succeeded
Relevant logon occurred	The intended trigger was exercised
New process correlated	Execution evidence supports the tested path
No visible window	Further evidence is needed to explain the outcome

Verify Restoration Separately #

Removal starts with identity. Use the same test account and compare its SID with the creation record. Recreate the variables in the new PowerShell session, then verify the stored command still matches the lab entry before removing the named value.

$runPath = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run'
$valueName = 'CourseLab-Notepad'
$notepadPath = Join-Path $env:SystemRoot 'System32\notepad.exe'
$expectedCommand = '"' + $notepadPath + '"'
$runKey = Get-Item -LiteralPath $runPath -ErrorAction Stop

if ($runKey.GetValueNames() -notcontains $valueName) {
    throw 'The lab value is absent. Reconcile the account and evidence.'
}
if ($runKey.GetValue($valueName) -cne $expectedCommand) {
    throw 'The value changed. Review it before removal.'
}
Remove-ItemProperty -LiteralPath $runPath -Name $valueName -ErrorAction Stop
if ((Get-Item -LiteralPath $runPath).GetValueNames() -contains $valueName) {
    throw 'The lab value is still present.'
}

Remove-ItemProperty removes the selected value rather than the entire Run key. The prechecks protect against deleting an unexpected entry encountered during the exercise. Preserve the removal result and a fresh query. Read Remove-ItemProperty .

Configuration removal does not terminate Notepad. Close the specific lab window normally, then repeat the sign-out and sign-in test. Confirm the value remains absent and no execution attributable to the lab entry recurs.

Cleanup layer	Evidence
Configuration	Named value absent in the correct user context
Running instance	Lab process or window closed normally
Later trigger	No recurrence attributable to the removed entry
Baseline	Unrelated startup entries preserved

Understand Observation Limits #

Startup configuration is observable regardless of whether a native utility or in-process extension writes it. MITRE documents registry Run keys and Startup folders as established persistence locations. The delivery mechanism does not erase the resulting configuration. Read ATT&CK T1547.001 .

A familiar value name is not proof of legitimate ownership. Evaluate the command, path, signer information, installation context, and observed behavior together. A file timestamp also does not establish provenance or explain who created the startup entry.

Broader startup locations have different consequences. Winlogon configuration, service settings, and application-loading mechanisms affect different triggers and process contexts. Inspect them as distinct mechanisms rather than treating every autostart entry as an interchangeable Run value.

Evidence type	Useful question
Configuration record	What action is requested, for whom, and when?
File identity	Which executable or document is referenced?
Execution record	Did the intended process run under the expected context?
Removal record	Was the specific change reversed and retested?

Work a Failed-Launch Case #

Illustrative scenario: a user Run value appears in both the registry and Autoruns. After signing into another account, the reviewer sees no Notepad window and reports the persistence test failed. The original account’s hive still contains the lab entry.

Evaluate the report using trigger and identity evidence. Decide which part of the test was completed and which prerequisite was missed. Then write the narrowest justified next step.

Expected reasoning: configuration creation was confirmed, but the intended user’s logon was not tested. Signing into another account does not exercise the same user Run entry. Resume the test in the original lab account or record the untested trigger as a limitation.

Case variation	Expected next check
Wrong user signed in	Reconcile SID and user hive
Correct user, missing executable	Confirm path and file availability
Correct entry, delayed launch	Review the observation window and execution evidence
Entry removed, window remains	Close the existing instance and test recurrence separately

Watch the Autoruns Demonstration #

Aaron Margosis’s Microsoft demonstration explains Autoruns and its startup views. Watch how selecting categories, users, and filters changes the visible configuration. Identify which view supports each stage of your lab record.

Watch on YouTube: Sysinternals: Autoruns deep dive .

Create the Lifecycle Record #

Document the whole exercise, including an unexpected result if one occurred. Record the before-state, exact named change, trigger, evidence, removal, and later retest. If you stop before removal verification, leave the exercise open with a named owner.

Lab asset, account SID, and registry view:
Baseline timestamp and evidence:
Value name, type, and exact command:
Creation result:
Logon trigger and observation window:
Execution evidence and alternative explanations:
Removal result and fresh configuration query:
Existing process closure:
Later logon result:
Remaining differences from baseline:

A completed record proves more than a single screenshot of Notepad. Another reviewer should reconstruct the sequence and identify the evidence supporting restoration. Keep this record for the cleanup comparison in Module 15 .

Check Your Understanding #

Trigger: is a reboot without user logon a sufficient Run-entry test?
Identity: which account determines the HKCU context?
Portability: why does a copied profile entry not guarantee execution elsewhere?
Cleanup: does removing the value stop a running process?

Question	Expected reasoning
Trigger	The relevant user logon still needs to occur
Identity	The calling security context, verified against the recorded SID
Portability	Executable, path, policy, and environment dependencies remain
Cleanup	Configuration removal and process termination are separate actions

Next Steps #

Local privilege escalation concerns crossing a permission boundary, which user persistence alone does not establish. Continue to Module 13: Local Privilege Escalation to analyze prerequisites and supported impact. Return to the Red Team Course hub for the full sequence.

Read More at https://simeononsecurity.com/

Module 13: Local Privilege Escalation

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Local privilege escalation crosses a permission boundary on a host. A writable directory, unusual service, or scanner finding starts an investigation. Establish which identity controls which operation, which privileged process consumes the result, and what evidence supports the claimed impact.

This module develops a permission-boundary record. You will inspect a prepared training service without modifying it, compare incomplete findings, and design a minimal validation with a clear stopping point.

Allow 35–50 minutes. Difficulty: intermediate. The worked case is illustrative, not an observed compromise.

Learning Outcomes #

Define service permissions, file permissions, and DLL search behavior.
Explain why a suspicious configuration is an incomplete escalation claim.
Inspect a training service and its filesystem permissions.
Compare evidence for competing escalation hypotheses.
Produce a validation record with a remediation and retest condition.

Before You Begin #

Use a disposable Windows lab VM with an instructor-provided service named CourseLabService and a documented application directory. Read Windows identity and tokens and host awareness first. Run the inspection from the account whose permissions you intend to assess.

If no training service exists, complete the paper exercise below. Do not substitute an unfamiliar production service. The inspection commands query state, while service installation, ACL changes, and restarts require a separate exercise specification.

Requirement	Record before inspection
Principal	Account SID, groups, integrity level, and relevant token privileges
Object	Exact service name, executable path, and application version
Boundary	Current rights and the additional operation under review
Trigger	Permitted event and its expected service impact
Evidence	Timestamp, command result, trace location, and baseline owner

Define the Boundary #

A discretionary access control list, or DACL, specifies allowed and denied access entries on an object. Effective access depends on the requested operation and the caller’s token. Reading a configuration is different from changing it, and changing a file is different from replacing its containing directory.

The service object and its executable are separate securable objects. Permission to query a service does not imply permission to reconfigure it. A service’s configuration, binary, and supporting directories therefore need separate evidence. Microsoft documents distinct service rights for querying, changing configuration, starting, and stopping a service. Service access rights .

Evidence	Meaning	Missing conclusion
Query succeeds	Configuration is readable	Configuration is writable
Directory is writable	Some filesystem operations are permitted	Privileged code loads a controlled file
Service uses LocalSystem	Configured service identity is highly privileged	Your proposed input reaches its execution path
Start is permitted	Caller has a trigger permission	Caller controls the launched program

Trace the Whole Path #

Every link needs evidence before a configuration finding becomes an escalation result

A useful escalation hypothesis names a chain: principal, permitted modification, privileged consumer, and trigger. One missing link changes the conclusion. The chain also reveals where a defender should break the dependency.

Consider a training application’s plugin directory. An ordinary user writes files there, but the privileged service loads plugins only from a different, protected directory. The writable location deserves configuration review, yet it does not establish the proposed service escalation. Your report should preserve this distinction instead of promoting every weak permission into SYSTEM execution.

Evidence discipline: State the strongest supported claim, then name the next observation needed to strengthen it.

Inspect the Training Service #

whoami.exe /all
sc.exe qc CourseLabService
sc.exe sdshow CourseLabService

whoami.exe /all records the inspection identity and token context. sc.exe qc reads the service configuration, including its configured executable and service account. sc.exe sdshow displays the service security descriptor, whose interpretation concerns the service object rather than its executable. Use sc.exe explicitly in PowerShell to avoid a command-name alias collision. Microsoft’s sc qc reference and sc sdshow reference .

icacls.exe "C:\CourseLab\Service"
icacls.exe "C:\CourseLab\Service\CourseLabService.exe"

icacls.exe displays filesystem DACLs when invoked this way. Replace the example paths only with the instructor’s recorded lab paths. The commands do not grant permissions or establish which file a running process has loaded. Preserve both command output and error messages. Microsoft’s icacls reference .

Result	Next interpretation
Service absent	Check the lab manifest rather than inventing a target
Access denied	Record the blocked query and current principal
Inherited permission	Identify its parent and affected objects before proposing a fix
Path differs	Update the hypothesis to match the configured application

Expected observation: Successful queries produce configuration and permissions for the prepared objects. No particular permission weakness is guaranteed. These Windows examples are documentation-reviewed, not execution-tested on the macOS authoring host.

Interpret Tool Findings #

SharpUp is a C# assessment tool with checks for issues such as modifiable services, modifiable service binaries, unquoted service paths, and hijackable paths. Its repository distinguishes checks from weaponization. Record the source revision and selected check rather than treating an old screenshot as a stable interface. GhostPack’s SharpUp repository .

A checker result prioritizes manual review. An unquoted service path needs more analysis than the presence of a space. A writable PATH entry needs more analysis than a permissive ACL. Compare the tool’s assumptions with the exact process, filesystem layout, and operating-system build in your record.

Execution method also changes the observation surface. An external utility, managed assembly, and in-process BOF have different dependencies and failure boundaries. None guarantees silence, and an in-memory operation still invokes observable system behavior. Revisit Beacon execution and BOFs for compatibility and failure analysis before choosing a collection method.

Collection choice	Question to answer first
Native query	Which process and object access events are expected?
Managed checker	Which runtime, checks, and child processes does this version use?
In-process component	What happens to the hosting process if the component fails?
Existing defender trace	Does its collection window cover the proposed behavior?

Understand DLL Loading #

DLL search-order hijacking depends on actual loader behavior. Windows considers factors such as loaded modules, KnownDLLs, manifests, application type, and loader flags. PATH is only part of some search strategies. An arbitrary writable PATH directory does not guarantee selection. Microsoft’s DLL search-order documentation .

A missing-file event is also incomplete evidence. Programs often probe optional files or continue searching after an unsuccessful lookup. Correlate the requested name, process identity, later lookup results, and the path ultimately loaded. Avoid publishing a named Windows DLL as a universal escalation route without a reproducible affected-version record.

For ordinary native x86/x64 DLL loading, match the library to the loading process. A 64-bit operating system also runs 32-bit processes, so OS bitness alone is insufficient. The file’s expected exports and application behavior matter alongside architecture. Microsoft’s process interoperability documentation .

Observation	Further evidence needed
NAME NOT FOUND	Whether the failed lookup affects a used code path
Writable searched directory	Whether a controlled file would be selected before another copy
Compatible architecture	Required exports and successful application behavior
Privileged loader	Token context at the operation and an approved trigger

Watch a Specific Case #

Compass Security’s case study illustrates how application behavior and timing shape a DLL hijacking investigation. Treat its demonstrated conditions as specific to the researched case. It is supplemental analysis, not proof of vulnerability on every Windows installation. Watch the presentation on YouTube .

While watching, identify the controlled object, the privileged consumer, and the timing dependency. Then ask which observation would invalidate the proposed path. This exercise builds a stronger review habit than remembering a filename.

Compare Three Findings #

The following synthetic findings concern one training application. Assume the instructor supplied complete permission evidence for the stated objects, but no execution test has occurred. Your task is to rank the next investigation step without claiming successful escalation.

Finding	Available evidence	Defensible assessment
A: Writable cache	User modifies cache files, service never reads them	No demonstrated privileged dependency
B: Writable plugin	User modifies a file read by a higher-privilege loader	Strong candidate, loading semantics and trigger remain
C: Readable service	User queries a LocalSystem service with protected files	Read access alone supplies no escalation path

Finding B deserves the next bounded validation because the evidence connects user control to a privileged consumer. Request a prepared benign fixture from the application owner, define its expected marker, and agree on a trigger window. Do not substitute an unrestricted payload or reboot simply because an earlier lab used one.

A negative result still needs interpretation. No marker after the trigger might reflect a failed load, a different path, a blocked action, or missing collection. Preserve the trace and separate these possibilities before closing the finding.

Choose the Smallest Proof #

A good validation plan answers one disputed question. If the dispute is whether the service reads a directory, a file-access trace might suffice. If the dispute is code execution under another identity, a mere file read is insufficient. Agree on the evidence threshold with the reviewer before changing the lab.

Operational cost belongs in the decision. Restarting a service, changing a dependency, or rebooting a host has different effects. A maintenance window does not automatically authorize every trigger. Prefer an owner-provided test application when production timing or recovery is uncertain.

Disputed claim	Minimal useful evidence
Principal controls object	Effective permission result for the required operation
Consumer selects path	Correlated loader or application trace
Boundary is crossed	Benign result tied to the higher-privilege execution context
Remediation breaks path	Repeated narrow test after the specified permission or loader fix

Build Your Boundary Record #

Create a one-page assessment from the synthetic case or your prepared VM. Include exact object names and evidence references. Another reviewer should understand both the finding and its uncertainty without reproducing a risky action.

Current principal and token:
Controlled object and required operation:
Permission evidence and collection time:
Privileged consumer and version:
Actual path selection evidence:
Approved trigger and recovery owner:
Claim established / claim still untested:
Minimal validation and stopping condition:
Remediation owner and retest evidence:

Completion standard: Distinguish configuration exposure from demonstrated execution, identify at least one invalidating condition, and choose a fix at the actual weak boundary. Tightening an unrelated directory does not repair the documented dependency.

Self-Check and Answers #

Question	Expected reasoning
Does querying a service prove modification rights?	No, querying and changing configuration require different access rights
Does a writable PATH entry prove hijacking?	No, establish actual search behavior, selection, privilege, and trigger
Which architecture matters for a DLL?	The loading process and its supported native module architecture
Which synthetic finding deserves more work?	B, because evidence connects controlled input to a privileged consumer
Does no callback prove no execution?	No, distinguish execution evidence from result transport and collection
What makes remediation convincing?	A fix addressing the documented boundary plus a scoped retest

Next Steps #

Carry the permission-boundary record into Module 14: Privileged Persistence and Process Migration . The next lesson examines service state, process lifetime, and whether an additional persistence mechanism serves the mission objective.

Return to the Red Team Course for the complete sequence.

Read More at https://simeononsecurity.com/

Module 14: Privileged Persistence and Process Migration

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Privileged persistence preserves an approved execution opportunity across a defined interruption. A Windows service is one possible mechanism. Its configured account, startup behavior, running process, and recovery dependencies need separate verification.

This module teaches you to build a service lifecycle record and judge whether process migration serves a concrete requirement. A running callback proves connectivity at one moment. It does not establish boot durability, service health, or successful restoration.

Allow 35–45 minutes. Difficulty: intermediate. The timeline exercise uses synthetic observations.

Learning Outcomes #

Distinguish service configuration, service state, and process lifetime.
Explain account selection and filesystem redirection.
Inspect a prepared service without changing its configuration.
Evaluate migration against stability and evidence requirements.
Create a lifecycle record covering trigger, observation, and restoration.

Before You Begin #

Use the prepared Windows lab VM and service manifest from local privilege escalation . You need the exact training service name, expected executable path, permitted inspection account, and the owner’s expected start and stop behavior. An instructor-provided trace supports the paper exercise if no VM is available.

The commands below are read-only queries. A separate service demonstration needs an approved benign service program, a bounded trigger, and a restoration plan. An arbitrary console executable is not a substitute for a program implementing the service interface.

Prerequisite	Why it matters
Service manifest	Separates lab-owned objects from operating-system services
Baseline account	Establishes the identity expected during execution
Lifecycle description	Defines whether the service stays running or completes a task
Collection window	Connects configuration and process evidence in time
Recovery owner	Resolves failures before another experiment starts

Separate Four States #

Service configuration specifies properties such as executable path, startup mode, and account. Service state describes its current relationship with the Service Control Manager, or SCM. Process state describes a particular executing instance. Session state describes the operator’s connection or task transport.

These states often change together, but they are not interchangeable. A service is configured even while stopped. A process might exit before an operator retrieves its result. A lost connection might leave a process running. Design observations around each state instead of using a callback as the single success signal.

Layer	Example question
Configuration	What program and account should the service use?
Service state	Does SCM report running, stopped, or a pending transition?
Process state	Which process instance executed, and when did it exit?
Session state	Did the expected result reach the operator?

Follow the Service Lifecycle #

A service result needs configuration, runtime, and restoration evidence

A Windows service program implements SCM interfaces for startup and control handling. Services use different accounts and startup arrangements, and some share a process. A service is not inherently LocalSystem, automatically started, or a guarantee of durable access. Microsoft’s service-program documentation .

Your success condition follows the exercise objective. A one-shot maintenance service might legitimately stop after completing work. A continuously running service stopping unexpectedly is a different outcome. Record the program’s intended lifecycle before interpreting its state.

Key takeaway: A stopped service is a state to explain, not a universal success or failure signal.

Read the Service Baseline #

sc.exe qc CourseLabService
sc.exe query CourseLabService

sc.exe qc reads configuration, while sc.exe query reports service state and related status fields. Record both outputs with timestamps. An error or missing service belongs in the result, and a similarly named service is not an acceptable substitute. Microsoft’s configuration query and state query .

$service = Get-CimInstance -ClassName Win32_Service `
    -Filter "Name = 'CourseLabService'"
$service | Select-Object Name, State, StartMode, StartName, PathName, ProcessId

Win32_Service exposes the selected service’s state, configured account, path, startup mode, and process ID. The filter narrows the query to the named lab object. A zero or unavailable process ID does not name a running service process. Microsoft’s Win32_Service class .

if ($null -ne $service -and $service.ProcessId -gt 0) {
    Get-Process -Id $service.ProcessId -ErrorAction Stop |
        Select-Object Id, ProcessName, StartTime, Path
}

Process correlation is time-sensitive. A service might stop between the two queries, a PID might be reused, or access to a property might be denied. Preserve those limitations instead of inventing missing values. This example reads process properties through Get-Process .

Expected result: A prepared running service supplies a service record and, with sufficient query access, a matching process observation. These commands were checked against documentation, not executed on the macOS authoring host. Your VM supplies the actual runtime evidence.

Resolve Architecture Questions #

Filesystem redirection affects some paths requested by 32-bit applications on 64-bit Windows. The Sysnative alias lets a 32-bit application address the native system directory. It is not a real directory or a universal path for every process. Microsoft also documents exceptions to redirection. Windows filesystem redirector .

Separate the querying process, the configured executable, and any library it loads. A 32-bit management process does not inherently require migration before inspecting or configuring a service. Verify the resolved path and the application’s compatibility instead of treating a change of process as a mandatory ritual.

Question	Evidence to collect
Which OS architecture?	Host inventory
Which process architecture?	Process properties for the relevant instance
Which executable path?	Service configuration and file identity
Which path was used?	Runtime process or file-access evidence

Evaluate Process Migration #

Process migration places an agent’s execution into a different process context, depending on the tool’s implementation. It is distinct from changing a service’s stored configuration. Moving execution does not automatically preserve every task, handle, impersonation state, or communication property.

Windows checks process access rights for operations such as querying information, writing process memory, and creating threads. Permissions and process protections constrain the available operations. A familiar executable name does not remove those boundaries. Microsoft’s process security and access rights .

The right decision begins with the operational requirement. If a compatible approved process already satisfies the objective, another transition adds dependencies and cleanup work. If a lab investigates migration itself, define the expected before-and-after identity, architecture, task behavior, and failure result.

Consideration	Review question
Lifetime	What event ends the destination process?
Compatibility	Does the implementation support the destination architecture?
Identity	Which primary or impersonation context applies afterward?
Stability	What legitimate function fails if the destination exits?
Evidence	Which source proves the transition occurred?
Restoration	Which processes and configuration changes remain afterward?

No universal safe process list exists. A process’s role, protection, workload, and lifetime matter more than its basename. Avoid inferring either guaranteed detection or guaranteed concealment from names such as rundll32.exe.

Observe Process Evidence #

Microsoft’s Sysmon demonstration provides context for observing endpoint behavior. While watching, distinguish a recorded event from a detection rule and an analyst’s conclusion. Collection configuration determines which event types are available. Watch on YouTube .

A service installation event, where the relevant auditing is enabled, records an installation rather than proving later service health or successful execution. Preserve service metadata and correlate it with the exercise timeline. Microsoft’s event 4697 reference .

For your collection plan, request only the events needed to answer the exercise question. A full host capture introduces review volume and potential sensitive data. An absent event needs a collection-health check before it becomes a statement about the tested behavior.

Analyze a Stopped Service #

This synthetic timeline describes an instructor’s one-shot service. The service manifest says it launches a benign worker and reports completion after dispatch. The worker writes a lab marker and exits independently.

Time	Observation
10:00:00	Approved start request accepted
10:00:01	Service process and worker creation recorded
10:00:02	SCM reports the service stopped
10:00:03	Worker writes the expected marker
10:00:05	Worker exit recorded

The supported conclusion is successful dispatch and worker completion for this specific fixture. The stopped state agrees with its documented design. A callback without the worker evidence would support a weaker conclusion, and the same timeline would violate a continuously running service’s expected behavior.

Durability remains untested. The timeline contains no reboot, dependency outage, or later trigger. If boot survival is the actual requirement, define a separate approved test. Do not use one successful start to claim resilience across events the exercise never observed.

Plan Restoration Early #

A lifecycle record links each created object to its owner and original state. A newly created lab service and a modified pre-existing service require different restoration actions. Deleting a borrowed service would remove the customer’s original configuration.

Service removal also has asynchronous consequences. Microsoft’s deletion API marks a service for deletion, and removal waits for relevant handles to close and the service to stop. A successful deletion request therefore needs a later verification. DeleteService behavior .

Object	Restoration question
Service registration	Was it created for the lab or present beforehand?
Configuration	Which exact fields changed from baseline?
Processes	Which lab-owned instances are still running?
Files	Which hashes and paths identify the lab’s files?
Evidence	Where are logs retained for the joint review?

Create Your Lifecycle Record #

Prepare a service lifecycle record for the synthetic timeline. Include one alternative explanation for a missing marker and one reason to avoid migration. Your review should establish the exercise outcome without assuming any unobserved startup behavior.

Service name and owner:
Original account, startup mode, and path:
Expected lifecycle and approved trigger:
Service and process observations with timestamps:
Identity and architecture evidence:
Migration requirement or reason to omit it:
Observed result and untested durability condition:
Restoration action, owner, and verification:

Expected reasoning: The one-shot fixture succeeded within its stated lifecycle, but boot persistence was not tested. Migration supplies no benefit to this short benign task unless the exercise explicitly studies a process transition. A missing marker needs execution and collection checks before attributing failure to SCM.

Self-Check and Answers #

Question	Expected reasoning
Does every service run as SYSTEM?	No, inspect the configured account and actual execution context
Does stopped always mean success?	No, compare observed state with the program’s intended lifecycle
Does x86 management require migration?	No, investigate compatibility and path resolution directly
Is a process basename a safety guarantee?	No, assess role, access rights, lifetime, and failure consequences
Does one start prove boot durability?	No, the boot condition needs its own approved observation
Does deletion success finish cleanup?	No, verify final registration, runtime state, and owned artifacts

Next Steps #

Bring the lifecycle record to Module 15: Persistence Cleanup and Defense Evasion . Use it to restore the exact objects touched by the exercise and preserve the evidence needed for a joint review.

Return to the Red Team Course for the complete sequence.

Read More at https://simeononsecurity.com/

Module 15: Persistence Cleanup and Defense Evasion

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Cleanup restores agreed system state after an exercise. It removes or reverses the team’s changes while preserving the evidence needed to explain them. Deleting a visible file is only one possible step, and a failed query does not prove an artifact is absent.

This module develops a restoration ledger linking ownership, baseline, action, verification, and unresolved work. It also separates defense-evasion testing from evidence destruction, so the assessment’s final state remains reviewable.

Allow 30–45 minutes. Difficulty: intermediate. The worked cleanup case uses synthetic records.

Learning Outcomes #

Define restoration, artifact ownership, and verification scope.
Explain how registry identity and loaded hives affect cleanup.
Inspect the exact Run entry from the earlier benign exercise.
Analyze failed queries, file identity changes, and remaining processes.
Create a restoration ledger with an independent review condition.

Before You Begin #

Bring the baseline records from user persistence and privileged persistence . You need the original account SID, registry location and view, named values, owned files, process observations, and any configuration fields changed during the exercise.

Use the same disposable VM for the inspection example. If you did not complete the Notepad Run-entry exercise, use the synthetic case instead. This lesson does not create another persistence mechanism or assume every reader has a matching artifact.

Input	Why cleanup needs it
Original state	Distinguishes restoration from deletion
Ownership evidence	Prevents removing a similarly named customer object
Exact identity	Selects the intended user’s configuration
Runtime record	Finds lab activity still running after trigger removal
Evidence location	Preserves observations for the final report

Define the Restoration Target #

A created object usually needs removal if the exercise owns it and the agreement requires no residual artifact. A modified object needs restoration of the affected fields to the agreed baseline. An observed object needs no cleanup merely because it appeared in a tool’s output.

For example, the earlier Notepad exercise created a named Run value, not the Windows Notepad application. Removing the lab value and closing its identified window addresses those changes. Deleting the operating-system executable would damage an unrelated component.

Object category	Appropriate disposition
Created lab value	Remove the exact owned value after comparison
Modified existing setting	Restore approved baseline fields
Existing OS executable	Leave intact
Collected evidence	Retain according to the engagement agreement
Unrecognized change	Escalate for ownership review before mutation

Follow the Restoration Loop #

An action result and a verified final state are separate entries in the cleanup record

The restoration loop begins with a comparison, not a deletion command. Confirm the current object still matches the team’s recorded change. Apply the narrow reversal, then independently check the intended final state and any affected trigger.

Concurrent changes complicate rollback. If an administrator edited a value after the exercise created it, blindly restoring an old snapshot might erase legitimate work. Record the mismatch, preserve the current value, and let the system owner resolve the conflict.

Decision rule: An uncertain owner or changed value is a review task, not permission for broader deletion.

Resolve Registry Identity #

HKCU refers to a current-user registry mapping. Its behavior follows process and security context, with caching details relevant to impersonating applications. A SYSTEM-context cleanup tool should not assume this handle refers to the interactive user who created the artifact. Microsoft’s predefined registry keys .

Use the recorded SID and account authority from the creation record. A short username alone is ambiguous across local and domain accounts. SID length does not distinguish a local account from a domain account, and a _Classes suffix identifies a different registry branch rather than an account’s domain status. Microsoft’s security identifier documentation .

Observation	Interpretation
HKCU value absent	Absence in the queried mapping, if the query succeeded
Recorded SID under HKU	A loaded branch available for a targeted query
Recorded SID not listed	Investigate profile loading and collection context
Similar username	Insufficient evidence of the same security principal

Loaded hives are not a complete user-account inventory. If the target profile is unloaded, a live HKU listing does not prove its persisted configuration is clean. Prefer verification in the original user’s controlled session, or an owner-managed profile inspection procedure with its own rollback plan.

Inspect the Exact Value #

whoami.exe /user
reg.exe query HKU

Identity inspection records the account executing cleanup and lists the loaded registry roots visible to it. Compare the result with the SID captured during the earlier exercise. Do not choose a SID by its position, length, or resemblance to a screenshot.

$recordedSid = 'S-1-5-21-111111111-222222222-333333333-1001'
$runKey = "HKU\$recordedSid\Software\Microsoft\Windows\CurrentVersion\Run"
reg.exe query $runKey /v CourseLab-Notepad /reg:64
$queryExitCode = $LASTEXITCODE
$queryExitCode

Replace the synthetic SID with the exact recorded SID before running the query. /v selects the lab value, and /reg:64 matches the earlier exercise’s 64-bit registry view. $LASTEXITCODE preserves the native command’s exit result. Microsoft’s reg query reference .

Expected interpretation: A successful result reveals the named value and its current data. A failure requires the accompanying error text. Missing key, missing value, and access denied are different outcomes. This example is documentation-reviewed and requires a Windows lab for execution validation.

For the actual removal, use the guarded, value-specific cleanup in Module 12 from the original user’s session. Compare the current name and data with the recorded lab value first. Do not delete the parent Run key, which contains other startup entries.

Verify File Ownership #

Get-FileHash -LiteralPath 'C:\CourseLab\Artifacts\example-marker.txt' `
    -Algorithm SHA256

Get-FileHash reads file content to calculate a digest. Use this example only for a lab-owned file recorded in your manifest. The digest helps compare current content with the creation record, but a matching hash alone does not establish ownership or justify deletion. Microsoft’s Get-FileHash documentation .

Record the exact path, owner, and purpose alongside the digest. Two copies of the same lab file require two artifact records. A file containing another team’s data needs a different disposition even if its name resembles your test artifact.

Comparison	Decision
Path and digest match	Continue with the approved ownership-based reversal
Digest changed	Preserve and investigate the intervening change
Path absent	Check query success and record the observation time
Access denied	Diagnose access before drawing a content conclusion

Diagnose Cleanup Failures #

Access denied does not prove a live agent is holding a file. Windows distinguishes access-denied errors from sharing violations, and other conditions affect file operations. Preserve the exact native error rather than replacing it with a guessed explanation. Windows system error codes .

A remaining process requires its own ownership check. PID alone is insufficient after a long delay because identifiers are reused. Correlate image, start time, parent relationship, and the original exercise record before closing an application or asking the owner to stop a service.

Failure	Narrow next check
Registry access denied	Query account, requested view, and object permissions
File sharing violation	Identify the handle owner and expected application state
Service marked for deletion	Check running state and outstanding management handles
Artifact reappears	Look for another recorded trigger or management policy
Process remains	Determine whether trigger removal affected an existing instance

Trigger removal prevents a future launch through the removed mechanism. It does not automatically end existing activity or remove every alternate launch source. The final check should cover both the startup configuration and the known running lab instance.

Observe With Process Monitor #

Microsoft’s Process Monitor demonstration supplements the file and registry investigation. Focus on process identity, operation, path, result, and event time. An unsuccessful lookup means something different from a successful write or delete. Watch on YouTube .

Process Monitor collects filesystem, registry, and process/thread activity and supports filtering. Use a bounded collection window and preserve the original capture before narrowing the analyst view. Filters help review, but an incomplete capture does not establish the absence of an earlier operation. Microsoft’s Process Monitor documentation .

Preserve Detection Evidence #

Defense-evasion testing examines whether a defined change affects prevention or detection under specified conditions. Its result belongs beside the original configuration, exact test window, and collection status. Fewer child processes or a changed command line does not establish invisibility.

Assessment cleanup should preserve customer event logs and agreed evidence. If an exercise includes a defense-evasion hypothesis, document its measured outcome and restore any authorized configuration change. Do not relabel log destruction as routine housekeeping. Revisit communication and detection comparisons for a controlled comparison method.

Record	Preserve for review
Endpoint observation	Raw event reference and collection status
Operator action	Exact object, time, and task result
Detection outcome	Alert, prevention action, or reviewed absence within a window
Restoration result	Action status plus final-state verification

Review a Synthetic Cleanup #

Assume a training Run value was created for user A, and cleanup occurs later under an administrative account. The operator queries its own HKCU, receives no matching value, and marks cleanup complete. A later sign-in by user A opens the lab Notepad window again.

The failure is scope, not a mysterious registry recovery. The operator queried a different mapping and never verified the original trigger. Correct the ledger to unresolved, return to the recorded SID and view, and compare the actual lab entry with its creation record.

Evidence	Supported conclusion
Administrator’s HKCU lacks value	No matching value in the queried context
User A’s entry still exists	The original trigger remains configured
Known lab window launches later	Runtime behavior is consistent with incomplete cleanup
Exact value removed and logon retested	Stronger evidence of restoration for this mechanism

Expected reasoning: Successful verification names the right account, value, view, and trigger. A remaining Notepad window from before removal does not prove a new launch. Close the identified lab instance before the controlled later sign-in and correlate new process evidence.

Create a Restoration Ledger #

Build a ledger entry for the Run value and a second for any lab-owned file. Mark each as verified, unresolved, or retained by agreement. Avoid a single blanket “host clean” statement when the evidence covers only selected artifacts.

Host and artifact identifier:
Owning exercise and creation evidence:
Original state / exercise change:
Current identity, location, view, and value:
Comparison result and conflicts:
Approved restoration action and result:
Independent query and trigger verification:
Retained evidence and remaining work:
Reviewer, owner, and completion time:

Completion standard: Another reviewer should reproduce your final-state check without guessing the account or deleting additional objects. Unresolved items need an owner and next action, not an optimistic completion label.

Self-Check and Answers #

Question	Expected reasoning
What if a pre-existing value was modified?	Restore its agreed baseline instead of deleting it
Does an empty HKCU query prove cleanup?	Only for the verified queried context and successful query
Does SID length identify domain accounts?	No, use the recorded identifier and account authority
Does access denied prove a live implant?	No, inspect the exact error and object-access conditions
Why retest the trigger?	Configuration absence and future launch behavior are separate observations
What happens to customer logs?	Preserve them for the agreed review and retention process

Next Steps #

Carry the restoration ledger into Module 16: Domain Privilege Escalation and Kerberos Abuse . The next lesson separates ticket requests, password exposure, and account authorization before evaluating domain impact.

Return to the Red Team Course for the complete sequence.

Read More at https://simeononsecurity.com/

Module 16: Domain Privilege Escalation and Kerberos Abuse

Sat, 12 Sep 2026 00:00:00 +0000

← Return to the Red Team Course

Domain privilege escalation combines identity, ticket, directory, and authorization evidence. Kerberoasting is one possible path. A service principal name (SPN) identifies a service account for Kerberos, but it does not grant administrative authority to the account.

This module builds a ticket and privilege review. You will distinguish a ticket request from offline password analysis, compare service-account designs, and produce a defensible decision about the next approved test.

Allow 40–55 minutes. Difficulty: intermediate. Examples use synthetic account names and expected evidence.

Learning Outcomes #

Define KDC, TGT, TGS, SPN, service account, and delegation.
Explain why ticket encryption and account privilege are separate questions.
Inspect ticket-cache and directory evidence in an approved lab.
Compare traditional service accounts with managed service accounts.
Create a domain escalation review with evidence and limits.

Before You Begin #

Use the domain lab and collection agreement from networking and Active Directory . Record the requesting principal, domain controller, account names, SPNs, encryption types, and the purpose of each service. Do not request tickets for customer accounts outside the approved scope.

Record	Why it matters
Requesting identity	Attributes the ticket request to a real principal
Service account	Separates SPN ownership from authorization
Encryption type	Determines which analysis paths are relevant
Group membership	Establishes potential impact after authentication
Collection window	Connects directory and controller evidence

Map Kerberos Roles #

Ticket exposure and account impact require separate evidence

Kerberos uses a key distribution center (KDC) to issue tickets. A ticket-granting ticket (TGT) represents an authenticated session. A ticket-granting service ticket (TGS) authorizes access to a named service and is issued for an SPN.

Component	Role	Does it prove privilege?
KDC	Issues tickets for the domain	No
TGT	Requests later service tickets	No
TGS	Targets one service SPN	No
SPN	Maps a service name to an account	No
Group membership	Contributes to authorization	Sometimes, after policy evaluation

An SPN is a directory mapping, not an access-control decision. A service account might have no elevated groups, or it might run a critical application with delegated rights. Review both the account and the service it supports.

Separate Request and Crack #

Kerberoasting describes requesting service tickets for SPN-associated accounts and analyzing the ticket material offline. The KDC request is a network event. The password-guessing phase runs against a captured representation and does not contact the KDC for each guess.

An offline result is uncertain. Long random passwords, AES keys, account rotation, and managed service accounts change the feasibility of guessing. A failed guess does not prove the account is safe, while a recovered password still requires an authorization review before any use.

Compass Security’s Kerberos presentation supplements the ticket flow. Track which claims describe protocol behavior and which depend on an account’s password, groups, or delegation settings. Watch the presentation on YouTube .

Review Encryption Evidence #

RC4-HMAC and AES are different Kerberos encryption choices. Hashcat mode 13100 is commonly associated with Kerberoastable RC4 ticket material. It is not a universal mode for every ticket representation or encryption type. Confirm the format and encryption field before selecting an analysis method.

Event 4769 records a Kerberos service-ticket request on a domain controller when auditing is enabled. Current Windows documentation includes fields for the requesting account, service name, ticket encryption type, client address, and status. The event shows a request, not a password crack or successful service use. Microsoft’s event 4769 reference .

Evidence	Supports	Does not support
4769 success	A TGS request reached the KDC	Password recovery
RC4 encryption field	RC4-specific review path	Weak password by itself
Offline candidate	A possible secret match	Authorization to use it
Privileged group member	Potential high impact	Current session access

Compare Account Designs #

Traditional user service accounts often keep long-lived secrets managed by a team. Group Managed Service Accounts (gMSAs) allow Windows to manage password retrieval and rotation for approved hosts. Neither design removes the need to review SPNs, delegation, groups, or service scope. Microsoft’s gMSA overview .

Design	Secret management	Review focus
Traditional account	Team-managed password and rotation	Age, length, reuse, and owner
gMSA	Directory-managed rotation	Allowed hosts and delegated use
Computer account	Machine-managed secret	SPNs, delegation, and machine role
Disabled account	Authentication disabled	Stale SPNs and ownership cleanup

SPN ownership also needs review. Duplicate SPNs, stale registrations, and undocumented services create confusing ticket evidence. Resolve the directory object and application owner before assigning impact.

Examine Delegation Carefully #

Delegation permits one service or computer to act toward another service under defined conditions. Unconstrained, constrained, and resource-based constrained delegation use different directory attributes and trust assumptions. A delegation flag alone does not identify which users or services are impersonated in the observed scenario.

Use the MITRE ATT&CK Kerberoasting reference as a taxonomy aid, then validate the actual domain configuration. Record the relevant attribute, object owner, allowed principals, target service, and time of observation. Avoid treating a technique label as evidence of successful abuse.

Inspect a Lab Ticket Cache #

klist.exe
klist.exe get cifs/fileserver.corp.example

klist.exe displays and requests tickets for the current logon session. Use the second command only against the named lab service and within the approved window. Preserve the output without publishing ticket blobs or secrets. Microsoft’s klist reference .

Expected result: The lab either shows a TGS for the requested SPN or returns an error because the service, DNS record, or policy is unavailable. Either result needs the requesting identity, target SPN, time, and controller evidence. This command was documentation-reviewed and not executed on the macOS authoring host.

Analyze a Synthetic Case #

Assume analyst.user requests a TGS for HTTP/reporting.corp.example. Event 4769 records success with AES encryption. The service account is a gMSA allowed on two application hosts and has no privileged group membership. No offline candidate matches the captured lab fixture.

The defensible conclusion is a successful service-ticket request for a managed account. The evidence does not show password recovery, domain privilege, or unauthorized service use. A follow-up should review the gMSA host scope and SPN ownership rather than escalate the severity solely because a ticket exists.

Observation	Correct interpretation
Ticket request	KDC issued or attempted a TGS
AES type	Encryption choice recorded in the event
gMSA owner	Rotation and host policy apply
No password match	Offline test did not recover the lab secret
No privileged group	No group-based domain-admin claim

Choose the Next Test #

A bounded next test should resolve one uncertainty. If the question is SPN ownership, query directory metadata. If it is ticket monitoring, correlate event 4769 with the requesting host. If it is service authorization, inspect the application’s access control. Do not combine password analysis, delegation changes, and remote access in one unexplained action.

Uncertainty	Smallest useful evidence
Who owns the SPN?	Directory object and owner record
Which encryption was used?	Event 4769 encryption field
Account resource reachability	Approved authorization test
Did a password guess succeed?	Reproducible lab fixture result

Create the Review Record #

Produce a ticket and privilege review for the synthetic case. Include the request event, account design, group and delegation evidence, offline result, and one condition able to change your conclusion.

Requesting principal and host:
Domain controller and event reference:
Target SPN and owning object:
Ticket type and encryption evidence:
Account design, groups, and delegation:
Offline analysis scope and result:
Authorization impact established / untested:
Next approved observation and stopping condition:
Owner, timestamp, and retention location:

Completion standard: A reviewer sees which fact came from the KDC, directory, endpoint, or offline analysis. The record states what remains untested.

Self-Check and Answers #

Question	Expected reasoning
Does an SPN grant admin rights?	No, it maps a service name to an account
What does event 4769 show?	A service-ticket request on the domain controller
Does RC4 prove a weak password?	No, it identifies an encryption path for review
Does a recovered secret prove authorization?	No, groups, ACLs, and policy still determine access
Why review gMSAs separately?	Their managed rotation and host scope alter exposure
What makes a conclusion defensible?	Source-specific evidence plus explicit untested conditions

Next Steps #

Carry the ticket and privilege review into Module 17: Lateral Movement and Expanding Access . The next module uses it to test path prerequisites without assuming every credential reaches every host.

Return to the Red Team Course for the complete sequence.

Read More at https://simeononsecurity.com/