Hitchhiker's Guide — Observe the Sensors, Find a Gap, Close It on an Owned Range

The operator/detection-engineer range walkthrough for Phase 07. You stand up an owned detection range, run benign Atomic Red Team tests, observe which sensors actually fire, identify a telemetry gap, then close it with a Sysmon config change plus a Sigma rule, and verify the rule fires. This is the runtime counterpart to the WARMUP: it proves effective visibility, not intended config.

Safety (non-negotiable). Everything here runs on an isolated, owned range you built. The only "attacker" actions are benign Atomic Red Team test cases that simulate a technique's observable footprint without doing harm. There are no bypass steps in this guide — no unhooking, no ETW/AMSI patching, no evasion artifact. The exercise is purely defensive: see what the sensors see, find the blind spot, and close it. Never run any of this on a host you do not own.

Table of Contents

0. Authorize and scope

Before anything boots, write down — in the range notebook — the five facts from Phase 00:

  • Owner: you. The range is yours; no shared infrastructure, no corporate domain.
  • Scope: the named lab VMs only, on an isolated vSwitch with deny-by-default egress.
  • Methods: benign Atomic Red Team tests and defensive configuration only. No bypass, no evasion artifact, no live malware.
  • Data: synthetic; no real credentials, customer data, or PII in any fixture, capture, or screenshot.
  • Stop conditions: any unexpected egress, any VM reaching a non-lab network, or any test that is not on the pre-approved benign list → stop, snapshot, investigate.

If you cannot name owner/scope/methods/data/stop-conditions, you do not power on. This is the same reflex Phase 00 trained.

1. Build the range

A minimal, free, fully-owned detection range:

         isolated vSwitch (host-only, deny-by-default egress)
        /                          |                          \
   Win 10/11 client          Win Server (optional DC)     Detection stack
   - Sysmon (driver)         - same Sysmon config         - Wazuh OR Elastic (free)
   - a free EDR agent        - log forwarder              - log ingest + Sigma rules
   - PowerShell 5.1 + 7      - log forwarder              - dashboards / alerts
   - Atomic Red Team
  • Endpoint: a Windows 10/11 VM. Install Sysmon (Sysinternals) with a known config, and a free EDR (e.g. Wazuh agent, or the Elastic Agent/Defend, or Microsoft Defender for the AMSI/ETW side). PowerShell is pre-installed; install Atomic Red Team (Invoke-Atomic) for the benign tests.
  • Detection stack: a Wazuh or Elastic server VM to ingest the endpoint's logs and run detections. Both are free, both ingest Sysmon and Windows event logs, and both can run Sigma rules (Wazuh via converted rules; Elastic via the detection engine / sigmac/sigma-cli conversion).
  • Snapshot every VM in a clean state before you start. You will roll back to it for each test.

This mirrors the detection range in the repo's range diagram — never bridged to home, corporate, or public networks.

2. Turn on the sensors (and prove they're on)

Install Sysmon with a community baseline so you start from sane, well-tuned collection:

# install/update Sysmon with a config (run elevated on the endpoint)
Sysmon.exe -accepteula -i sysmonconfig.xml          # SwiftOnSecurity baseline, or...
Sysmon.exe -c sysmon-modular.xml                    # Olaf Hartong's ATT&CK-tagged modular config

Prove it is effective, not just installed (the WARMUP's "effective state, not intended config" rule):

  • Confirm the Sysmon service/driver is running and the config is loaded: Sysmon.exe -c prints the active config; the Microsoft-Windows-Sysmon/Operational event log should be filling with Event ID 1 (ProcessCreate) as you do normal things.
  • Confirm the endpoint's logs are reaching the detection stack — open the Wazuh/Elastic dashboard and see live events. Collection that never ships is a blind spot that looks covered.
  • Note which data sources are on by default in your config and which are off: many baselines ship with command-line logging on but ProcessAccess (Sysmon 10) limited or off (it is noisy), and DNS query (22) sometimes off. Those off-by-default rows are your candidate gaps.

Record the sensor inventory you actually have — this is the input to Lab 01.

3. Run a benign Atomic test and observe which sensors fire

Atomic Red Team provides small, benign test cases per ATT&CK technique. Pick one whose observable footprint you want to study — described here, run on your range, never against anything you don't own:

  • T1059.001 PowerShell — a benign Atomic that runs a harmless encoded command. Expected sensors: Sysmon 1 (process-create of powershell.exe with the command line), PowerShell script-block log 4104 (the de-obfuscated content), and an AMSI scan of the buffer (Defender). Watch all three fire; this is the "multiple sibling sensors" lesson live.
  • T1218 LOLBin (e.g. a benign rundll32/mshta test) — Expected: Sysmon 1 with the unusual parent/child and command line. The detection lives in command-line + parent/child, which is why command-line logging is so high-value.
  • T1003.001 LSASS access (benign read test) — a test that opens a handle to lsass.exe. Expected: Sysmon 10 ProcessAccess with a GrantedAccess mask — only if ProcessAccess is enabled in your config. This is the gap most ranges discover.

For each test: roll back to the clean snapshot, run the single Atomic, then in the dashboard list exactly which sensors produced an event for it. Write it down as technique -> {sensors that fired}. That mapping is the ground truth you compare against Lab 01's model.

Keep it benign. The goal is the telemetry footprint, not impact. Invoke-Atomic's tests are designed to be safe; still, run only ones you have read and pre-approved, and roll back after each.

4. Identify the telemetry gap

Compare what fired to what should have fired for a robust detection:

  • For T1003.001, if you saw a process-create of the dumping tool but no Sysmon 10 ProcessAccess event on lsass.exe, you have found the gap: your config is not collecting the handle-open data source, so the robust (kernel-boundary) detection has nothing to fire on. You are relying on a brittle process-name signal instead.
  • For T1055 injection (if you study it via a benign test), if you collect user-mode ETW but not ETW-TI, the in-memory allocation/protect/inject signals are absent — a named, high-value blind spot.
  • For T1218 LOLBins, if command-line logging is off, you see that rundll32 ran but not with what arguments — the detection's key field is missing.

This is exactly the Lab 01 classification by hand: the technique is partial (process-create present, the discriminating sensor absent) or blind. Feed your real inventory and the technique's required sensors into the analyzer and confirm it ranks the missing sensor as the top investment.

5. Close the gap: Sysmon config + Sigma rule

Closing a gap is two moves: turn on the data source, then write the detection on it.

(a) Sysmon config change — turn on the data source. For the LSASS-access gap, enable ProcessAccess on lsass.exe (and tune it to keep the noise sane):

<!-- add to the <ProcessAccess> section of your sysmon config -->
<RuleGroup name="lsass-access" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage condition="image">lsass.exe</TargetImage>
  </ProcessAccess>
  <!-- exclude known-legitimate readers to control false positives -->
  <ProcessAccess onmatch="exclude">
    <SourceImage condition="image">MsMpEng.exe</SourceImage>     <!-- Defender -->
    <SourceImage condition="image">wininit.exe</SourceImage>
  </ProcessAccess>
</RuleGroup>

Reload: Sysmon.exe -c sysmonconfig.xml. Now Sysmon 10 events for LSASS handle opens will flow. (This is a telemetry decision — it flips T1003.001 from partial toward detectable in Lab 01's terms.)

(b) Sigma rule — the detection on the new data source, keyed at the TTP level (the behavior, not a tool name), on the kernel-boundary sensor so it survives user-mode evasion:

title: Suspicious LSASS Handle Access (Credential Dumping)
id: 9f1b6e2c-7a44-4c2e-9d11-0c2f3a5b6e88
status: experimental
description: A non-system process opened a handle to lsass.exe with VM-read/clone rights.
references:
  - https://attack.mitre.org/techniques/T1003/001/
logsource:
  product: windows
  category: process_access          # Sysmon Event ID 10
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'                     # PROCESS_VM_READ | QUERY_INFO
      - '0x1410'
      - '0x143a'
  filter_known_good:
    SourceImage|endswith:
      - '\MsMpEng.exe'
      - '\wininit.exe'
      - '\csrss.exe'
  condition: selection and not filter_known_good
falsepositives:
  - EDR/AV/backup agents may legitimately read lsass; tune by SourceImage.
level: high
tags:
  - attack.credential-access
  - attack.t1003.001

Convert and load it into your stack (sigma-cli / sigmac to Wazuh or Elastic). The rule keys on the GrantedAccess rights mask — the irreducible consequence of reading LSASS — not on the tool's name, so renaming or recompiling the tool does not evade it (top of the Pyramid of Pain).

6. Verify the rule fires (and doesn't false-positive)

A rule you did not see fire is a hope, not a detection. Verify both directions:

  • True positive: roll back to clean, re-run the benign T1003.001 Atomic, and confirm the new Sigma rule alerts in the dashboard, with the expected TargetImage, GrantedAccess, and SourceImage.
  • False positive check: do normal activity (log in, open apps, let Defender run) and confirm the rule does not alert — your filter_known_good is doing its job. If Defender (MsMpEng.exe) trips it, widen the exclusion by source, never by weakening the GrantedAccess selection.
  • Robustness reasoning (no bypass run): argue why this rule survives a user-mode evasion — because the handle open is a kernel ProcessAccess event, an ntdll unhook or ETW patch in the dumper's own process does not remove it. This is the Lab 02 residual-visibility claim, applied.

Record the before/after: technique was partial/blind, you added one data source and one rule, and it is now detectable and the alert fires on the benign test with no FP on normal use.

7. The evidence packet

Collect, hash, and store (in the management network, never published raw):

  • The sensor inventory before and after (which data sources were on).
  • The technique -> {sensors that fired} observation table from step 3.
  • The gap finding (the named missing data source) and Lab 01's ranking confirming it.
  • The Sysmon config diff and the Sigma rule (the two artifacts that close the gap).
  • The verification screenshots: the alert firing on the benign Atomic test, and the absence of a false positive on normal activity.
  • A one-paragraph narrative: technique, the blind spot, the boundary it sits at, the close, the verification — observation separated from inference.

This packet is the publishable, sanitized Phase 07 portfolio artifact (the detection-gap close), with no real targets, no credentials, and no evasion code.

8. Teardown and cost control

  • Revert every VM to the clean snapshot; the range holds no engagement state between sessions.
  • If the range is on a cloud sandbox, destroy the VMs and confirm the bill returns to baseline; budgets/quotas/alerts were set before first boot (Phase 00 rule).
  • Purge raw logs you do not need for the evidence packet; keep only what explains and remediates.
  • Confirm no egress occurred to any non-lab network during the session (review the deny-by-default firewall logs).

Common false claims

  • "I evaded the EDR." On a defensive range you ran benign tests and closed a gap — there was no evasion. The honest claim is "I found and closed a telemetry gap and verified the detection."
  • "The EDR can't see LSASS dumping." It can — if the ProcessAccess data source is collected. The gap was config, not capability. Never generalize a config gap into a product limitation.
  • "The rule works because it fired once." Firing on the seeded test is necessary, not sufficient. State where the rule sits on the Pyramid of Pain and which boundary it keys on — that is what predicts whether it survives the next evasion.
  • "Turning on more logging fixes it." You turned on the one data source the gap analysis ranked highest and wrote the rule on it. Unfocused logging is cost without coverage.
  • "Detectable means done." Detectable means the data exists and the rule fires; maintaining the rule (FP tuning, ownership, regression) is the durable deliverable a client actually keeps.