In this section
Check My Knowledge
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 cCorrect. 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 aTechnically 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 bCorrect. 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 cYou 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 license has expired b
Splunk Free doesn't expire — it has a 500 MB/day ingestion cap but no time limit. A license 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 licenses do have Advanced Hunting. The reason is safety, not capability.
Because developer tenants have more features b
Developer tenants have E5 licenses 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.