Skip to content

Lab 02 — Read Endpoint Telemetry From a Real Attack

Hands-on lab · ← Back to the module concept

Setup

git clone https://github.com/plaintext-security/plaintext-labs
cd plaintext-labs/defensive/02-endpoint-telemetry
make up

Run make demo to analyze the bundled seed data/sysmon_events.json — a small 10-event chain (WINWORD.EXE → cmd → PowerShell encoded download → rundll32 LOLBin → LSASS dump → Run key persistence → C2 callback) kept so the demo runs offline. The script reconstructs the process tree, decodes the base64 payload, and flags each technique by ATT&CK ID. This seed is a deterministic teaching sample — not real telemetry.

Analyze a real capture. Run make fetch-data to pull a genuine Sysmon .evtx from EVTX-ATTACK-SAMPLES (GPL-3.0) — specifically Execution/exec_sysmon_1_lolbin_rundll32_advpack_RegisterOCX.evtx, a real EventID 1 rundll32 LOLBin execution. It converts the EVTX to JSON with python-evtx (via evtx_to_json.py) and writes data/real_sysmon_events.json; then run python3 analyze.py data/real_sysmon_events.json to read genuine endpoint telemetry. Point evtx_to_json.py at any other sample (Persistence/, CredentialAccess/, …) to extend it. Source, exact sample path, and license are in data/PROVENANCE.md.

To capture your own telemetry instead, deploy Sysmon with the SwiftOnSecurity config on a Windows VM, export with Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' | ConvertTo-Json | Out-File events.json, then python3 analyze.py events.json.

Scenario

Find an attacker's footprints in real endpoint telemetry — without needing to have run the attack yourself.

Your own VM, or the public sample logs. (If you did Track 01, ingest your own attack's telemetry instead — same skill.)

Do

  1. [ ] Get real endpoint telemetry: load an EVTX-ATTACK-SAMPLES capture, or generate events with one Atomic Red Team test on your VM.
  2. [ ] Find the malicious process: trace its command line and its parent. (What's a normal parent for this process — and is this one normal?)
  3. [ ] Identify the Sysmon Event IDs that captured the activity.
  4. [ ] Author a detection and prove it fires (the build half). Don't stop at "a detection would key on X" — write it. Author a Sigma rule (or a precise predicate in your script) for the malicious behaviour you found — e.g. WINWORD/Office spawning cmd/powershell, or an encoded PowerShell download. Run it over the bundled data/sysmon_events.json and confirm it fires on the malicious chain. Then add one benign event (a normal powershell.exe from a console, say) and confirm your rule stays quiet — a detection that also fires on benign activity is noise. Finding the footprint and authoring a verified detection for it are equal halves.

Success criteria — you're done when

  • [ ] You found the malicious process and its ancestry in real telemetry.
  • [ ] You can name the Sysmon Event IDs involved.
  • [ ] You authored a detection (Sigma rule or scripted predicate) that fires on the malicious chain in sysmon_events.json and does not fire on a benign event you added.

Deliverables

endpoint-telemetry.md: the malicious event, its process ancestry, the Event IDs, and your authored detection plus the fires-on-malicious / quiet-on-benign proof. Commit the rule/predicate alongside it.

AI acceleration

Have a model explain an unfamiliar command line or Event ID — then confirm against the process tree and the real data before calling it malicious.

Connects forward

These events and detection ideas feed module 08 (detection-as-code) and module 11 (endpoint hunting).

Marketable proof

"I deploy Sysmon and read endpoint telemetry from real attack samples — process ancestry, command lines, Event IDs — to find malicious activity."

Automate & own it

Required. Write a script (PowerShell or Python) that pulls the relevant Event IDs from an EVTX and flags suspicious process ancestry; AI drafts, you review it against the real sample; commit it.

Stretch

  • Run an Atomic Red Team test, capture your own Sysmon telemetry, and find it — closing the attacker→defender loop yourself.

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).