The Toolkit and What Comes Next

Operational Context

The course uses a wide toolset and teaches none of it as content. Tools are infrastructure: they appear in Module 1 and function as plumbing thereafter. A learner who swaps Splunk for Elastic, or VirtualBox for Hyper-V, still completes the same course, because the curriculum is techniques.

Every tool in the course, shown as it actually behaves, so Module 1 holds no surprises.

Learning Objectives

• Place each tool in the loop rather than learning it in isolation. Atomic Red Team fires the technique, Sysmon produces the telemetry, Sigma expresses the rule, VECTR records the result, Navigator shows the shape. This matters because the loop is what makes the tool choice reversible: swap any one component and the sequence still holds.
• Treat the techniques as the curriculum and the tools as replaceable. This matters because every tool here has substitutes and the technique does not, so the reasoning survives a change of tooling and the tool-specific knowledge does not.
• Know what Module 1 asks of you before you start it. This matters because the lab build is the one module where an error costs you hours later rather than minutes now, and knowing what it produces makes the sequence of steps make sense.

Tools as plumbing, techniques as curriculum

This course is structured around ATT&CK techniques, not tools. A technique sub teaches T1003.001 LSASS dumping: the attack, the telemetry, the detection, the tuning. The tools that make it possible are the plumbing. Here's how each one looks in practice.

Atomic Red Team, running the attack

Atomic Red Team is the primary way you execute techniques in the lab. One command, one technique, one test number:

# Run T1003.001 LSASS Memory. Test 1 (Mimikatz variant)
Invoke-AtomicTest T1003.001 -TestNumbers 1

Output:

PathToAtomicsFolder = C:\AtomicRedTeam\atomics
Executing test: T1003.001-1 Dump LSASS.exe Memory using ProcDump
  Command: C:\AtomicRedTeam\atomics\T1003.001\bin\procdump.exe -ma lsass.exe
           C:\Windows\Temp\lsass_dump.dmp
  Exit code: 0
Done executing test: T1003.001-1 Dump LSASS.exe Memory using ProcDump

That's the attack. It ran procdump.exe against lsass.exe and produced a memory dump. Sysmon Event 10 fired. Now you check whether your detection rule caught it.

The course cites specific test numbers per technique sub, T1003.001 -TestNumbers 1, T1059.001 -TestNumbers 3, etc. Each test is a specific variant of the technique. You can also run techniques manually when the course calls for it (not every variant has an Atomic test).

The property that makes it useful for this course is that each test is a small, readable definition rather than a compiled binary. You can see exactly what a test will run before running it, which matters when the thing you are about to execute is a credential dump on a machine you own. Read the test, then run it.

Sysmon: the telemetry source

Sysmon produces the raw events your rules match on. Here's the Sysmon Event 10 that the Atomic Red Team test above generated:

{
  "EventID": 10,
  "SourceImage": "C:\\AtomicRedTeam\\atomics\\T1003.001\\bin\\procdump.exe",
  "TargetImage": "C:\\Windows\\System32\\lsass.exe",
  "GrantedAccess": "0x1FFFFF",
  "SourceUser": "NORTHGATE\\t.ashworth",
  "UtcTime": "2026-04-22 14:32:01.445"
}

The key fields for detection: TargetImage (what was accessed), GrantedAccess (what access rights were requested), SourceImage (what process did the accessing). The Sigma rule you saw in PT0.1 matches on these fields.

Sysmon is configured in Module 1 with the SwiftOnSecurity baseline. On Linux, auditd fills the same role. Here's the equivalent auditd record for a credential access technique on Linux:

type=SYSCALL msg=audit(1713794521.445:892): arch=c000003e syscall=257
  success=yes exit=3 a0=ffffff9c a1=7f8a2100000 a2=0 a3=0
  items=1 ppid=4872 pid=4891 uid=0 gid=0 euid=0
  comm="cat" exe="/usr/bin/cat"
  key="shadow_access"
type=PATH msg=audit(1713794521.445:892): item=0
  name="/etc/shadow" inode=524289 dev=08:01 mode=0100640

The auditd key="shadow_access" field is the detection anchor, it fires when anything reads /etc/shadow. The course configures these keys in Module 1.

The point worth carrying forward is that Sysmon's value here is not that it sees more than your EDR. It is that its configuration is yours, visible in a file, and identical on every host you point it at.

That matters for a course built on reproducibility. When an exercise produces no telemetry, you can read the configuration and know whether the event was meant to be collected. With a managed EDR the same question frequently cannot be answered from the endpoint at all, which turns a five-minute diagnosis into a support ticket.

So the recommendation is Sysmon alongside whatever you already run, not instead of it. The exercises in this course reference Sysmon event IDs because they are stable and documented, and where your EDR provides the same observation under a different name the reasoning transfers unchanged.

Sigma: the canonical detection format

Every detection in the course is Sigma-first. Here's the LSASS multi-variant rule from PT0.1, plus its conversions to all three SIEM platforms the course covers:

title: LSASS Memory Access - Credential Dumping (Multi-Variant)
id: a4f2c8e0-91d7-4b5a-8c3e-6d9f0e1a2b34
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x10'
            - '0x1FFFFF'
    filter_system:
        SourceImage|startswith:
            - 'C:\Windows\System32\'
            - 'C:\Program Files\Windows Defender\'
    condition: selection and not filter_system
level: critical

// Sentinel KQL: via MDE connector
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where FileName =~ "lsass.exe"
| where InitiatingProcessFileName !in~ (
    "MsMpEng.exe", "csrss.exe", "services.exe"
  )
| project TimeGenerated, DeviceName,
          InitiatingProcessFileName, AccountName

// Defender XDR Advanced Hunting
// Note: Timestamp, not TimeGenerated
DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName == "lsass.exe"
| where InitiatingProcessFileName !in~ (
    "MsMpEng.exe", "csrss.exe", "services.exe"
  )
| project Timestamp, DeviceName,
          InitiatingProcessFileName, AccountName

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
    EventCode=10 TargetImage="*\\lsass.exe"
| where NOT match(SourceImage, "^C:\\\\Windows\\\\System32\\\\")
| table _time, Computer, SourceImage, GrantedAccess, SourceUser
| sort - _time

One rule, four platforms. The tabs above are the pattern you'll see in every technique sub from Module 2 onward. Sigma is canonical: the platform queries are conversions. If you use a platform the course doesn't show (CrowdStrike, SumoLogic, etc.), the Sigma rule converts to your platform via sigma-cli or pySigma.

You can also convert programmatically:

# Convert Sigma to Sentinel KQL using sigma-cli
sigma convert -t microsoft365defender -p sysmon lsass-credential-dump.yml
#
# Convert Sigma to Splunk SPL
sigma convert -t splunk -p sysmon lsass-credential-dump.yml

The reason to write the rule in Sigma first, rather than directly in your SIEM's query language, is that the rule outlives the platform. Estates migrate, teams inherit two SIEMs during an acquisition, and a rule expressed once in a portable format converts to both. A rule written natively converts to neither without a rewrite.

There is a second benefit that matters more for this course. A Sigma rule states the logic without the syntax, which makes it reviewable by somebody who does not know your query language. When you hand a coverage report to an architect or a peer, the rule is the evidence, and evidence nobody can read is not evidence.

The cost is real and worth stating: the conversion is imperfect. Sigma's backends produce workable queries rather than optimal ones, and field mappings for your estate need maintaining. So the working pattern is Sigma as the source of truth, converted output as the deployed artifact, and the deployed artifact tuned in place with the tuning recorded back into the rule.

VECTR, tracking what you've tested

VECTR is where you log the results of every technique test. Here's what an entry looks like after running T1003.001:

VECTR. Technique Test Result
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Technique:     T1003.001. LSASS Memory
Date:          2026-04-22
Target:        DESKTOP-NGE042 (Windows 11)
Tool used:     Atomic Red Team (Test 1, procdump variant)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Detection results:
  Sentinel:     DETECTED, alert fired at 14:32:05 (MTTD: 4s)
  Defender XDR: DETECTED, alert fired at 14:32:03 (MTTD: 2s)
  Splunk:       DETECTED, alert fired at 14:32:10 (MTTD: 9s)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
False positives observed: 2
  1. VeeamAgent.exe, environmental FP (excluded by path+hash)
  2. SCCM CcmExec.exe, environmental FP (excluded by parent)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Verdict:       PASS (3/3 SIEMs detected)
Next action:   Run comsvcs.dll variant (Test 2)

Every technique sub produces one of these entries. By Module 14, you have sixty-one entries: a complete evidence trail of what you've tested and what the results were.

The reason a tracker matters more than it sounds is that the value of this work is longitudinal. A single exercise tells you the state of one technique on one day. The record of forty exercises over a year tells you whether coverage is improving, which is the question leadership actually asks. Without a durable record, each exercise starts from nothing and the program has no memory.

What to record per technique is short: the date, the result, a reference to the evidence, the gap type if any, and the re-test date. Anything more becomes an admin burden that quietly kills the cadence, and the cadence is the part that produces the improvement.

There is a reporting benefit too. A tracker with a year of results in it answers "has this ever been tested" and "when did it last work" without anybody reconstructing history from memory, and those two questions are what an auditor and an incoming security lead both open with.

ATT&CK Navigator, visualizing coverage

The Navigator is browser-based. It shows your coverage as a color-coded heatmap. Here's what the color coding means:

ATT&CK Navigator. Coverage Status
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GREEN    Validated, tested in last 90 days, rule fired, tuned
YELLOW   Partial, some variants missed, or FP rate > 5%
ORANGE   Deployed but untested, rule exists, never validated
RED      No coverage: no rule, or rule confirmed broken
GREY     Out of scope, technique not relevant
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

You update the Navigator after each module's coverage report. The quarterly assessment presents the heatmap to leadership.

One caution about the picture it produces. A Navigator layer is persuasive out of proportion to what it contains, because a grid of colored cells reads as a measurement even when the colors encode only whether a rule exists. So the layer you present should carry its scoring key in the same view, and where the score is breadth rather than quality it should say so on the image rather than in a footnote nobody reads.

Per-module attack tooling, what each looks like

The foundation tools land in Module 1. Per-module attack tools are introduced as techniques require them. Here's a preview of what each looks like in practice:

Mimikatz (Module 7. Credential Access):

# Direct LSASS dump: the variant most rules are written for
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit"

Impacket secretsdump.py (Module 7. DCSync):

# Remote credential dump via DCE/RPC: no local Sysmon event
secretsdump.py NORTHGATE/admin@192.0.2.10 -just-dc-ntlm

BloodHound collection (Module 8. Discovery):

# Collect AD structure for attack-path mapping
Import-Module SharpHound.ps1
Invoke-BloodHound -CollectionMethod All -OutputDirectory C:\Temp\

AADInternals (Module 2. M365 Initial Access):

# Extract access token for M365, used in token replay attacks
$token = Get-AADIntAccessTokenForMSGraph
Get-AADIntTenantDetails -AccessToken $token

Evilginx2 (Module 14. Capstone CHAIN-HARVEST):

# AiTM phishing proxy, captures session cookies through MFA
evilginx2 -p ./phishlets -debug
# Configure phishlet for Microsoft 365 login
phishlets hostname o365 login.northgateeng.com
phishlets enable o365

Each tool is installed with step-by-step instructions in the module that first uses it. You don't install everything on day one, you install each piece as the course reaches it.

Adjacent skills, demonstrated

These make the course easier but aren't prerequisites. Here's what "comfortable" looks like for each:

KQL, can you read this query without pausing?

DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any ("-enc", "FromBase64String", "IEX")
| summarize Count = count() by DeviceName, AccountName
| where Count > 5

If you read that and understood it, you're fine. If KQL is newer, the course annotates every query line by line.

Sigma, can you read this rule without pausing?

detection:
    selection:
        EventID: 1
        Image|endswith: '\rundll32.exe'
        CommandLine|contains: 'comsvcs'
    condition: selection

If you understood what that matches on, you're fine. If Sigma is newer, the course teaches it by example across sixty-one rules.

PowerShell, can you read this without Googling?

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
    Where-Object { $_.Properties[8].Value -eq 10 } |
    Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}}

Bash, can you read this without Googling?

ausearch -k shadow_access --start today |
    aureport -f --summary |
    head -20

If most of these read naturally, the course flows. If some are new, you'll learn them in context: the course uses them repeatedly and they become familiar by Module 3 or 4.

What Module 1 asks of you

Module 1 builds the lab. It's free. By the end you've confirmed telemetry flows from all four environments into all three SIEMs by firing T1059.001 (PowerShell execution) and checking each SIEM:

# The Module 1 smoke test, fire T1059.001
Invoke-AtomicTest T1059.001 -TestNumbers 1

Then verify in each SIEM:

// Sentinel: check the event landed
DeviceProcessEvents
| where TimeGenerated > ago(15m)
| where InitiatingProcessFileName =~ "powershell.exe"
| where ProcessCommandLine has "-enc"
| project TimeGenerated, DeviceName, ProcessCommandLine

// Defender XDR Advanced Hunting: same check
DeviceProcessEvents
| where Timestamp > ago(15m)
| where InitiatingProcessFileName == "powershell.exe"
| where ProcessCommandLine contains "-enc"
| project Timestamp, DeviceName, ProcessCommandLine

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
    EventCode=1 Image="*\\powershell.exe" CommandLine="*-enc*"
| table _time, Computer, CommandLine
| head 5

If all three return results, your lab is working. If any is empty, Module 1's troubleshooting guide covers the pipeline diagnostics.

The lab is yours permanently. The paid content builds on it, but the foundation is free.

Two things about the tools are worth settling before you start building, because both cause people to stall in Module 1.

Every tool here is replaceable and the choice is yours. Atomic Red Team can be Caldera or a hand-written script. Sysmon can be your EDR's process telemetry. Sigma can be native rules in whichever SIEM you own. VECTR can be a spreadsheet. None of the reasoning in Modules 2 to 13 depends on the tool, because the reasoning is about what a technique does to your telemetry and what your telemetry can prove. Students who treat the tool list as a prerequisite checklist spend a week installing things and never start the course.

The tools occupy positions in a loop rather than slots in a toolbox. Something fires the technique, something records what happened, something expresses the detection, something records the result, something shows the shape of your coverage. Five positions. Every purple-team program in existence fills those five with something, and the interesting question is never which product you chose but whether the loop closes.

That framing has a practical payoff. When an exercise produces no result, the diagnosis is a question about position rather than product: did the technique execute, did the telemetry arrive, did the rule evaluate, did the result get recorded. Each is checkable in isolation and the loop tells you what order to check them in. A student thinking in tools instead asks whether Sysmon is broken, which is one hypothesis out of four and usually the wrong one.

Module 1 builds the infrastructure filling all five positions. It is the longest setup in the course and the only module where a mistake costs you hours later rather than minutes now, which is why it ends with a smoke test that proves every pipeline before you attack anything.