Sign In
In this module

PT1.14 Check My Knowledge

4-8 hours · Module 1 · Free

Check My Knowledge

1. You fire Invoke-AtomicTest T1003.001 -TestNumbers 1 on your Windows endpoint. The Sysmon Event 10 appears in Event Viewer on the endpoint, but no matching event appears in Sentinel after 20 minutes. What is the most likely cause?

The Sysmon configuration doesn't capture Event 10 a
Unlikely — the Event 10 appeared in Event Viewer locally, which means Sysmon captured it. The problem is in the forwarding pipeline, not the capture.
The Azure Monitor Agent isn't forwarding Sysmon events to the Log Analytics workspace b
Correct. The event exists locally (Sysmon captured it) but doesn't reach Sentinel. The break is in the AMA forwarding pipeline — check the AMA service status, the Data Collection Rule configuration, and network connectivity from the endpoint to Azure.
The Sentinel analytics rule for T1003.001 isn't enabled c
A Sentinel analytics rule processes events that have already been ingested. The issue here is that the raw events aren't arriving — this is an ingestion problem, not a rule problem. You can verify by querying the raw table (DeviceProcessEvents or Event) rather than SecurityAlert.

2. Your detection rule works in Sentinel but not in Defender XDR Advanced Hunting. The query is identical. What is the most likely issue?

The endpoint isn't onboarded to Defender for Endpoint a
If the endpoint weren't onboarded, Sentinel wouldn't have data either (the MDE connector feeds Sentinel). The issue is more likely a schema difference.
Defender XDR doesn't support KQL b
Both use KQL. Defender XDR fully supports KQL queries — the language is identical.
The query uses TimeGenerated instead of Timestamp c
Correct. Sentinel uses TimeGenerated as the time column. Defender XDR uses Timestamp. An identical query that works in one and fails in the other almost always has this column name difference. This is the most common cross-portal issue.

3. You want to test credential dumping (T1003.001) against a domain-joined endpoint. Which user should you log in as on the endpoint?

The local labadmin account a
Technically possible, but the Sysmon Event 10 will show a local user as SourceUser. Domain-focused detection rules often filter on domain user context — testing with a local account produces different telemetry than a real attack would.
A domain user like YOURLAB\t.ashworth b
Correct. Logging in as a domain user produces telemetry that matches real attack scenarios — the SourceUser field shows the domain context, and the credentials are domain credentials. This is the realistic telemetry shape your rules need to catch.
The domain admin account YOURLAB\admin.lab c
You wouldn't normally test from a domain admin account because real attacks typically start from a standard user and escalate. Testing as admin produces different alert context (the user already has the privileges, so some detection rules for privilege escalation won't fire).

4. You ran the smoke test. Sentinel and Defender XDR both show the event, but Splunk shows nothing. What's the first thing to check?

Whether the Universal Forwarder service is running on the endpoint a
Correct. The telemetry exists locally (Sysmon captured it — Sentinel and XDR received it via different pipelines). The Splunk pipeline starts with the Universal Forwarder on the endpoint. If that service isn't running, nothing reaches Splunk. Check with Get-Service SplunkForwarder.
Whether Splunk's licence has expired b
Splunk Free doesn't expire — it has a 500 MB/day ingestion cap but no time limit. A licence issue would show a warning in the Splunk UI, not silently drop events.
Whether the Sysmon configuration needs updating c
Sysmon is working — Sentinel and XDR both received the event. The Sysmon configuration is the same regardless of which SIEM receives the data. The issue is in the Splunk forwarding pipeline.

5. Why does the course use a developer tenant for M365 techniques instead of your employer's production tenant?

Because production tenants don't have Advanced Hunting a
Production tenants with appropriate licences do have Advanced Hunting. The reason is safety, not capability.
Because developer tenants have more features b
Developer tenants have E5 licences which include everything the course needs, but that's not the primary reason. Many production tenants also have E5.
Because running attack techniques against production M365 affects real users and may violate authorization boundaries c
Correct. Attack techniques in the course (token theft, AiTM phishing, OAuth abuse) affect real accounts if run against production. The developer tenant has test users only, is fully controlled by you, and carries no risk to real business operations. Authorization for offensive testing in production requires explicit written approval — the developer tenant doesn't need it because you own it.

6. The svc.sql account was created with an SPN. Which technique does this enable in Module 7?

Pass-the-Hash (T1550.002) a
Pass-the-Hash uses NTLM hashes, not SPNs. It doesn't require a service account.
Kerberoasting (T1558.003) b
Correct. Kerberoasting requests Kerberos service tickets (TGS) for accounts with SPNs. The tickets are encrypted with the service account's NTLM hash, which can be cracked offline. The svc.sql account with its SPN (MSSQLSvc/sql01.psyche.yourlab.local:1433) is the Kerberoasting target. Tools like GetUserSPNs.py request this ticket.
DCSync (T1003.003) c
DCSync replicates credentials from a domain controller using the Directory Replication Service protocol. It requires replication privileges (Domain Admin or specific delegated rights), not an SPN.
💬

How was this module?

Your feedback helps us improve the course. One click is enough — comments are optional.

Thank you — your feedback has been received.
© 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 →