Sign In
In this module

PT1.12 Smoke Test — Fire Your First Technique

4-8 hours · Module 1 · Free
What you already know

You've built the entire lab — three VMs, one domain, one M365 tenant, three SIEMs. This sub is the end-to-end validation. One technique. Three SIEMs. If all three detect it, the lab works. If any miss, the troubleshooting section covers every link in the pipeline.

Operational Objective
The lab has twelve components. Any one could have a misconfiguration that prevents telemetry from flowing. This sub fires a single technique — T1059.001 PowerShell execution — and verifies that the resulting telemetry appears in Sentinel, Defender XDR Advanced Hunting, and your secondary SIEM. If all three show the event, the lab is ready. This is also your first real purple-team cycle: attack → detect → verify.
Deliverable: Confirmed telemetry flow from the Windows endpoint to all three SIEMs. A verified, working purple-team lab.
Estimated completion: 20–30 minutes

Step 1: Prepare

Confirm both VMs are running:

  • PT-WIN-ENDPOINT (10.0.0.10) — logged in as YOURLAB\t.ashworth
  • PT-LINUX01 (10.0.0.20) — running (for Splunk/Elastic)

If you're logged in as labadmin on the endpoint, sign out and sign in as YOURLAB\t.ashworth — you want the domain user context in the telemetry.

Note the current time — you'll use it to scope your SIEM queries.

Step 2: Fire the technique

On PT-WIN-ENDPOINT, open PowerShell and run:

# Import Atomic Red Team if not auto-loaded
Import-Module "C:\AtomicRedTeam\invoke-atomicredteam\Invoke-AtomicRedTeam.psd1" -Force

# Fire T1059.001 — PowerShell Execution (encoded command variant)
Invoke-AtomicTest T1059.001 -TestNumbers 4

Expected output:

PathToAtomicsFolder = C:\AtomicRedTeam\atomics
Executing test: T1059.001-4 ComponentBasedServicing & DISM Log File
  Command: powershell.exe -EncodedCommand <base64 string>
  Exit code: 0
Done executing test: T1059.001-4

The test ran a PowerShell encoded command — the pattern attackers use to obfuscate their commands. Sysmon Event 1 captured the process creation. Now check if each SIEM received it.

Record the time: note when you ran the test (e.g. 15:42). You'll need this for the SIEM queries.

Step 3: Check SIEM 1 — Microsoft Sentinel

Open the Sentinel Logs blade → select your law-purpleteam workspace → Logs.

Run:

// Sentinel — check for the encoded PowerShell execution
DeviceProcessEvents
| where TimeGenerated > ago(30m)
| where InitiatingProcessFileName =~ "powershell.exe"
| where ProcessCommandLine has "-EncodedCommand"
    or ProcessCommandLine has "-enc"
| project TimeGenerated, DeviceName,
          InitiatingProcessFileName,
          ProcessCommandLine, AccountName

Expected: one row showing the encoded PowerShell command, with AccountName showing t.ashworth and DeviceName showing PT-WIN-ENDPOINT.

If the query returns nothing:

Wait 10 minutes and try again — Sentinel ingestion can lag, especially on the first few events after connecting a new data source. If still empty after 15 minutes, troubleshoot the MDE connector:

// Check if ANY endpoint data is arriving
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| summarize count() by DeviceName

If this returns 0, the MDE connector isn't sending data. Go back to PT1.8 Step 5 and verify the connector status.

Also check the raw Sysmon events via AMA:

// Check Sysmon events via the AMA pipeline
Event
| where Source == "Microsoft-Windows-Sysmon"
| where TimeGenerated > ago(30m)
| where RenderedDescription has "powershell"
| take 5

If the AMA pipeline has data but the MDE pipeline doesn't, the issue is the MDE connector specifically — check the endpoint's onboarding status in the Defender portal.

Step 4: Check SIEM 2 — Defender XDR Advanced Hunting

Open Advanced Hunting and run:

// Defender XDR — same check, different time column
DeviceProcessEvents
| where Timestamp > ago(30m)
| where InitiatingProcessFileName == "powershell.exe"
| where ProcessCommandLine contains "-EncodedCommand"
    or ProcessCommandLine contains "-enc"
| project Timestamp, DeviceName,
          InitiatingProcessFileName,
          ProcessCommandLine, AccountName

Expected: the same event, with Timestamp instead of TimeGenerated.

If the query returns nothing:

Check the endpoint is onboarded:

// Is the endpoint visible in Defender?
DeviceInfo
| where Timestamp > ago(24h)
| where DeviceName == "PT-WIN-ENDPOINT"
| project DeviceName, OnboardingStatus, OSPlatform

If this returns nothing, the endpoint isn't onboarded. Go back to PT1.7 Step 4 and re-run the onboarding script.

Step 5: Check SIEM 3 — Secondary SIEM

index=main sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
    EventCode=1 CommandLine="*-EncodedCommand*" OR CommandLine="*-enc*"
| table _time, Computer, Image, CommandLine, User
| head 5
In Kibana Discover with the winlogbeat-* data view, search:

event.code: "1" and process.command_line: (*EncodedCommand* or *-enc*)

If your secondary SIEM shows nothing:

Splunk troubleshooting:

# On the endpoint — is the forwarder running?
Get-Service SplunkForwarder

# Can the endpoint reach Splunk?
Test-NetConnection 10.0.0.20 -Port 9997
# On the Linux VM — is Splunk listening?
sudo /opt/splunk/bin/splunk display listen -auth admin:SplunkLab2026!

Elastic troubleshooting:

# On the endpoint — is Winlogbeat running?
Get-Service winlogbeat

# Can the endpoint reach Elasticsearch?
Test-NetConnection 10.0.0.20 -Port 9200
# On the Linux VM — is Elasticsearch running?
curl -s http://localhost:9200/_cluster/health | python3 -m json.tool

Step 6: Record the result

Fill in your smoke test results:

Smoke Test Result — PT1.12
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Technique:     T1059.001 — PowerShell Execution
Variant:       Encoded command (ART Test 4)
Target:        PT-WIN-ENDPOINT (YOURLAB\t.ashworth)
Time fired:    ____:____
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                    Detected?    Alert time       MTTD
Sentinel:           [ ]          ____:____        ____
Defender XDR:       [ ]          ____:____        ____
Secondary SIEM:     [ ]          ____:____        ____
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

This is the same format every technique sub uses. You've just completed your first purple-team cycle: fire the attack, check each SIEM, record the MTTD.

Step 7: Cleanup

Revert the atomic test:

Invoke-AtomicTest T1059.001 -TestNumbers 4 -Cleanup

Full pipeline troubleshooting

If any SIEM didn't receive the event, work through this diagnostic sequence. Start at step 1 and fix the first failure — every downstream SIEM depends on the steps before it.

Diagnostic Sequence
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. Did Sysmon capture the event locally?
   On endpoint:
   Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 10 |
     Where-Object { $_.Id -eq 1 -and $_.Message -match "Encoded" }
   → If empty: Sysmon isn't running. Check Get-Service Sysmon64.

2. Is AMA forwarding to Sentinel?
   On endpoint:
   Get-Service AzureMonitorAgent | Select-Object Status
   → If not running: Start-Service AzureMonitorAgent

3. Is the MDE agent forwarding to Defender XDR?
   On endpoint:
   Get-Service Sense | Select-Object Status
   Get-MpComputerStatus | Select-Object OnboardingState
   → If not onboarded: re-run the onboarding script from PT1.7

4. Is the Universal Forwarder running? (Splunk)
   On endpoint:
   Get-Service SplunkForwarder
   → If not running: Start-Service SplunkForwarder

5. Is Winlogbeat running? (Elastic)
   On endpoint:
   Get-Service winlogbeat
   → If not running: Start-Service winlogbeat

6. Can the endpoint reach the Linux VM?
   Test-NetConnection 10.0.0.20 -Port 9997  (Splunk)
   Test-NetConnection 10.0.0.20 -Port 9200  (Elastic)
   → If TcpTestSucceeded is False: check both VMs are on the
     same internal network and the Linux VM's firewall allows
     the port.

7. Is Splunk/Elasticsearch running on the Linux VM?
   Splunk:  sudo /opt/splunk/bin/splunk status
   Elastic: curl http://localhost:9200
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Fix the first step that fails. Everything downstream depends on it.

Verification checklist

☐ T1059.001 fired via Invoke-AtomicTest as YOURLAB\t.ashworth
☐ Event visible in Sentinel (DeviceProcessEvents query returns row)
☐ Event visible in Defender XDR (Advanced Hunting query returns row)
☐ Event visible in secondary SIEM (Splunk search or Kibana query)
☐ MTTD recorded for all three SIEMs
☐ Atomic test cleaned up
☐ Smoke test result recorded

If all seven pass: the lab is complete. You have a working four-environment, three-SIEM purple-team lab. Every technique sub from Module 2 onward uses this lab.

Take a final snapshot of the Windows endpoint in its current state — this is your "lab complete, ready for techniques" baseline:

# Hyper-V
Checkpoint-VM -Name "PT-WIN-ENDPOINT" -SnapshotName "Lab-Complete-Ready"
# VirtualBox
VBoxManage snapshot "PT-WIN-ENDPOINT" take "Lab-Complete-Ready"
Next
PT1.13 — Module Summary. Recaps what you built across Module 1 and what comes next.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.

You've built the lab and understand the validation gap.

Module 0 showed you why detection rules fail silently — vendor schema changes, attacker tool evolution, environment divergence, tuning drift. Module 1 gave you a working four-environment, three-SIEM purple-team lab. From here, you walk the kill chain technique by technique.

  • 61 ATT&CK techniques across 12 tactic modules — Initial Access through Impact, each walked end-to-end with attack commands, annotated telemetry, and multi-SIEM detection rules
  • Every detection in four formats — Sigma rule (canonical), Sentinel KQL, Defender XDR Advanced Hunting KQL, and Splunk SPL or Elastic. Tabbed side-by-side in every technique sub
  • Module 14 Capstone — CHAIN-HARVEST — full purple-team exercise on an AiTM credential-phishing chain. Multi-stage attack, detection results across all three SIEMs, coverage gaps, tuning recommendations
  • Programme template — coverage matrix, MTTD per technique, FP rates, detection quality scores, remediation backlog. Populated as you work, presentable to leadership by Module 14
  • Public Sigma rule repo — every detection rule in a GitHub repository. Alumni contribute via PR. The artefacts outlive the course
Unlock with Specialist — £25/mo See Full Syllabus

Cancel anytime

← Previous Next →