SC-500 Part 8: Advanced Threat Hunting and Forensics

Part 8 of 8 — Advanced domain. This part goes beyond the standard exam objectives to cover proactive threat hunting, deep KQL techniques, ransomware incident response, digital forensics procedures on Azure infrastructure, breach notification obligations, and post-incident hardening. Candidates sitting SC-500 should treat this content as the depth layer behind the incident response and detection objectives.

Advanced Threat Hunting in Sentinel

Hunting vs. Detection: Understanding the Difference

Detection is reactive: an analytics rule fires when a known pattern matches, an alert is created, and an analyst responds. Threat hunting is proactive: a human analyst forms a hypothesis about attacker behaviour, writes a query to test it across historical data, and looks for evidence that has not yet triggered any alert. The distinction matters for the exam because Sentinel supports both modes with different tooling.

Detection (reactive): Scheduled analytics rules, NRT rules, Fusion ML correlations — these generate incidents automatically.
Hunting (proactive): Hunting queries run on demand against the full Log Analytics workspace. Interesting results are bookmarked and can be promoted to incidents.
Hunt outcomes can become the seed of a new analytics rule: once a hunting query consistently finds real threats, you promote it into a scheduled rule to automate future detection.

Hunting Queries: Library, Bookmarks, and Promotion

Sentinel ships with a curated hunting query library — hundreds of pre-built KQL queries mapped to MITRE ATT&CK techniques. Each query shows estimated hit rate, relevant tables, and associated tactics. Analysts can clone and customise these or write their own.

Bookmarks allow an analyst to mark specific result rows during a hunt. A bookmark captures the query, the result row, the analyst's notes, and the timestamp. Bookmarked results can be:

Added to an existing incident as supporting evidence
Used to create a brand-new incident from hunting findings
Tagged with entities (user, host, IP) so they appear in entity timelines

To promote a hunt result to an incident: open the bookmark, choose Create incident, and the platform links all bookmarks associated with that hunt as evidence inside the new incident.

Watchlists: Creation and KQL Integration

Watchlists are custom data tables imported into a Sentinel workspace. They are stored in Log Analytics and are queryable with KQL just like any other table. Common use cases:

IP allowlists: Known-good corporate egress IPs — exclude from external connection alerts
VIP user lists: Executive accounts that need closer monitoring or different alert thresholds
Vulnerable assets: Devices running unpatched software — correlate with inbound exploit attempts
IOC lists: Malicious IPs, file hashes, domains from threat intelligence feeds

Creation methods: CSV upload through the Azure portal, ARM template deployment (for IaC pipelines), or via the Sentinel REST API. Each watchlist needs a unique alias and a search key column.

Reference a watchlist in KQL using the _GetWatchlist() function:

// Correlate sign-ins against VIP user watchlist
let VIPUsers = _GetWatchlist('vip-users') | project UPN = SearchKey;
SigninLogs
| where TimeGenerated > ago(1d)
| where UserPrincipalName in (VIPUsers)
| where ResultType != 0  // failed sign-ins
| project TimeGenerated, UserPrincipalName, IPAddress, Location, ResultDescription

Entity Behavior Analytics (UEBA)

UEBA builds behavioural baselines for users and devices, then surfaces anomalies as scored deviations from that baseline. To use UEBA in Sentinel:

Enable UEBA in the Sentinel settings blade — choose which data sources to include (Entra ID, Active Directory, Microsoft 365, MDE)
Allow 7–10 days for baseline modelling to complete before anomaly scoring becomes meaningful
Access user timelines and device timelines from the Entity behaviour menu or from within a Sentinel incident's entity panel

Key UEBA tables in Log Analytics:

BehaviorAnalytics — one row per anomalous event, with anomaly type, score, contributing factors, and entity identifiers
UserPeerAnalytics — peer group analysis: which users does a given user behave like, and how different is their recent activity from the peer group
IdentityInfo — enriched user context: department, manager, roles, on-premises status

// Find high-anomaly-score users in the last 7 days
BehaviorAnalytics
| where TimeGenerated > ago(7d)
| where ActivityInsights has "IsFirstTimeSignInFromCountry"
    or ActivityInsights has "IsUncommonlyUsedDevice"
| summarize MaxScore = max(InvestigationPriority), Events = count()
    by UserPrincipalName
| where MaxScore > 7
| order by MaxScore desc

ML-Based Anomaly Detection: Fusion and Anomaly Definitions

Fusion is Sentinel's built-in ML correlation engine. It combines low-fidelity signals from multiple sources — signals that individually would not generate an alert — and correlates them into high-confidence multi-stage attack detections. Fusion runs automatically and cannot be modified; you enable or disable it as a single analytics rule.

Anomaly analytics rules (separate from Fusion) are ML models trained on your workspace data that emit anomaly records into the Anomalies table. Each anomaly definition covers a specific scenario (unusual network volume, abnormal process execution) and has a configurable threshold. You can:

View anomaly charts to understand baseline vs. observed values
Use anomaly records as a signal inside scheduled analytics rules — correlate Anomalies with other tables
Adjust sensitivity thresholds per anomaly definition to tune false positive rates

Jupyter Notebooks for Hunting

Sentinel integrates with Azure Machine Learning workspaces to run Jupyter notebooks against workspace data. Notebooks are suited for complex hunting that goes beyond what KQL alone can express — statistical analysis, graph traversal, machine learning inference, and visualisation.

The MSTICPy library (Microsoft Threat Intelligence Python Security Tools) is the primary toolkit for Sentinel notebooks. Key capabilities:

Query Log Analytics and Microsoft 365 Defender data from Python
Enrich IOCs with threat intelligence (VirusTotal, AlienVault OTX, Microsoft TI)
Pivot across entities — follow an IP to domains, to certificates, to related IPs
Visualise timelines, network graphs, and geo maps
Run anomaly detection using scikit-learn models on log data

The Sentinel hunting gallery includes pre-built notebooks for scenarios such as credential theft investigation, C2 beaconing analysis, and lateral movement visualisation. Launch a notebook by selecting it in the Sentinel Notebooks blade and clicking Launch notebook in AML.

Advanced KQL Techniques for Hunting

The SC-500 exam tests practical KQL. The following operators appear in both hunting queries and analytics rule definitions:

Operator	Syntax / Example	Hunting Use Case
`let`	`let threshold = 50;` `let badIPs = externaldata(IP:string) [@"https://..."];`	Define reusable variables, subqueries, or external data references to keep complex queries readable
`join kind=inner`	`T1 \| join kind=inner T2 on $left.UserName == $right.AccountName`	Correlate two event streams where both sides must match — e.g. failed login AND subsequent process creation by same account
`join kind=leftouter`	`T1 \| join kind=leftouter T2 on IPAddress`	Enrich left-side events with optional right-side context — e.g. enrich sign-in logs with threat intelligence, keeping sign-ins even if no TI match
`join kind=leftanti`	`SigninLogs \| join kind=leftanti AllowedIPs on IPAddress`	Return left rows with NO matching right row — find sign-ins from IPs not on the allowlist; identify processes not in a known-good baseline
`summarize make_set()`	`summarize IPs = make_set(IPAddress) by UserPrincipalName`	Collect unique values per group — find all distinct source IPs used by each user in a time window
`summarize make_list()`	`summarize Cmds = make_list(CommandLine) by DeviceName`	Collect ordered values (preserves duplicates) — capture sequence of commands executed on a host
`summarize dcount()`	`summarize UniqueHosts = dcount(DeviceName) by RemoteIP`	Count distinct values — find external IPs connecting to an unusually high number of internal hosts (potential scanner)
`bin() + series_decompose_anomalies()`	`summarize Count=count() by bin(TimeGenerated,1h) \| make-series ... \| extend anomalies=series_decompose_anomalies(Count)`	Time-series anomaly detection — spot sudden spikes in network traffic, authentication failures, or data egress volume
`mv-expand`	`\| mv-expand todynamic(Properties)`	Expand array or JSON columns into individual rows — unpack dynamic columns in Activity logs or Defender alerts
`parse` / `extract()`	`\| parse CommandLine with * "/user:" User " " *` `\| extend Hash = extract(@"MD5=([A-F0-9]{32})",1,Details)`	Pull structured fields out of free-text — extract usernames from command lines, hashes from syslog messages, URLs from proxy logs

Hunting for Lateral Movement

Lateral movement typically shows as a sequence: failed authentication against multiple targets, then a successful authentication, followed by process creation or remote service execution on the newly accessed host. Correlate across three tables:

// Hunt for lateral movement: failed → success → process creation
let FailedLogins = SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4625 and LogonType in (3, 10)
| summarize FailCount = count(), Targets = make_set(Computer)
    by SubjectUserName, IpAddress
| where FailCount > 5;
let SuccessAfterFail = SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4624 and LogonType in (3, 10)
| join kind=inner FailedLogins on $left.IpAddress == $right.IpAddress
| project TimeGenerated, Account, Computer, IpAddress;
SuccessAfterFail
| join kind=inner (
    DeviceProcessEvents
    | where TimeGenerated > ago(1d)
    | project ProcTime = TimeGenerated, DeviceName, FileName, ProcessCommandLine, AccountName
) on $left.Computer == $right.DeviceName
| where ProcTime between (TimeGenerated .. (TimeGenerated + 30min))
| project TimeGenerated, Account, Computer, IpAddress, FileName, ProcessCommandLine

Hunting for Data Exfiltration

Data exfiltration patterns: large outbound data volumes, unusual hours, connections to previously unseen destination IPs or new cloud storage domains. Combine network flow data with time context:

// Hunt for potential exfiltration: large outbound + unusual hour + new dest IP
let KnownIPs = _GetWatchlist('known-egress-ips') | project IPAddress = SearchKey;
AzureNetworkAnalytics_CL
| where TimeGenerated > ago(7d)
| where FlowDirection_s == "O"  // outbound
| where BytesSentInFlowTunnel_d > 500000000  // > 500 MB
| where hourofday(TimeGenerated) !between (8 .. 18)  // outside business hours
| where DestPublicIPs_s !in (KnownIPs)
| project TimeGenerated, VM1_s, DestPublicIPs_s, BytesSentInFlowTunnel_d,
    DestPort_d, L7Protocol_s
| order by BytesSentInFlowTunnel_d desc

Threat Hunting Workflow

Threat hunting workflow: a hypothesis drives a KQL query, interesting rows are bookmarked and tagged with entities, then promoted to a Sentinel incident. Repeatable hunts can become scheduled analytics rules.

Ransomware Incident Response

Detection Phase

Ransomware attackers follow predictable patterns before encrypting files. Microsoft Defender for Endpoint detects several behavioural indicators that should trigger immediate investigation:

Mass file rename/extension change: Hundreds of files renamed with a foreign extension in seconds — detected by MDE file modification monitoring
VSS deletion: vssadmin delete shadows /all /quiet or wmic shadowcopy delete — eliminates Volume Shadow Copies to prevent recovery
Backup catalogue deletion: wbadmin delete catalog -quiet — removes Windows Server Backup catalogue
Security tool tampering: Registry changes or process kills targeting antivirus, EDR, or Windows Defender
BCDEdit changes: Modifying boot configuration to disable recovery (bcdedit /set {default} recoveryenabled No)

KQL for ransomware precursor activity in MDE:

// Detect VSS/backup deletion commands — strong ransomware precursor
DeviceProcessEvents
| where TimeGenerated > ago(1d)
| where FileName in~ ("vssadmin.exe", "wbadmin.exe", "wmic.exe", "bcdedit.exe")
| where ProcessCommandLine has_any (
    "delete shadows", "delete catalog", "shadowcopy delete",
    "recoveryenabled No", "bootstatuspolicy ignoreallfailures"
)
| project TimeGenerated, DeviceName, AccountName,
    FileName, ProcessCommandLine, InitiatingProcessFileName
| order by TimeGenerated desc

// Detect rapid file rename events (mass encryption pattern)
DeviceFileEvents
| where TimeGenerated > ago(2h)
| where ActionType == "FileRenamed"
| summarize RenameCount = count(),
    Extensions = make_set(tostring(split(FileName,".")[-1]))
    by DeviceName, bin(TimeGenerated, 5m)
| where RenameCount > 200
| order by RenameCount desc

Containment Actions

Speed is critical during ransomware containment. Every minute of delay means more files encrypted and potentially more hosts infected. Execute these actions in parallel where possible:

Network isolate affected devices via MDE: In the MDE portal, select the device → Actions → Isolate device. This cuts all network traffic except the MDE management channel, stopping lateral spread while allowing continued investigation. Can also be triggered via the MDE API for automation.
Disable compromised accounts in Entra ID: Block sign-in on all accounts associated with affected devices, especially service accounts and admin accounts found in process trees.
Revoke OAuth tokens and refresh tokens: Use PowerShell (Revoke-AzureADUserAllRefreshToken) or the Entra portal to invalidate all active sessions for compromised accounts — this forces re-authentication and stops any in-flight token use.
Segment network at NSG/Azure Firewall level: Create emergency NSG rules to block east-west traffic from affected subnets if device-level isolation is insufficient.
Snapshot clean VMs immediately: Capture disk snapshots of systems that appear unaffected while you investigate — this preserves a known-good state for recovery.

Backup Recovery Strategy

Azure Backup provides several layers of protection against ransomware-induced data loss:

Soft delete: When backup data is deleted (even by an attacker who gains access to the Recovery Services vault), it enters a soft-deleted state with a 14-day retention period before permanent deletion. Soft delete is enabled by default and should never be disabled.
Multi-user authorisation (MUA) for backup: Requires a second administrator to approve destructive backup operations (disable protection, delete backup data) — prevents a single compromised admin account from destroying backups.
Point-in-time restore for VMs: Restore to a recovery point that predates the infection. The recovery point must be from before the initial access event, not just before encryption started.
SQL database point-in-time restore: Azure SQL Backup enables restore to any point within the retention period (up to 35 days for Premium tier).
Blob versioning and soft delete: Azure Blob Storage soft delete (7–365 day configurable retention) and versioning provide object-level recovery without needing Azure Backup.

Recovery sequence — never skip steps:

Validate backup integrity before starting restore — check backup health reports and attempt a test restore to an isolated environment
Restore in an isolated network segment or separate subscription — do not restore directly to production until the environment is confirmed clean
Scan restored systems with updated threat intelligence before reconnecting
Patch all vulnerabilities identified as the initial access vector before bringing systems online
Gradually restore production systems, monitoring closely for re-infection indicators
Maintain heightened monitoring for at least 30 days post-recovery — ransomware operators frequently leave backdoors for a second attack

Ransomware TTPs: MITRE ATT&CK Mapping

Tactic	Technique (ID)	Azure/MDE Detection
Initial Access	Phishing: Spearphishing Attachment (T1566.001)	Defender for Office 365 Safe Attachments detonation; MDE alerts on malicious file open
Initial Access	Exploit Public-Facing Application (T1190)	Defender for Cloud vulnerability alerts; WAF logs in Log Analytics
Execution	Command and Scripting: PowerShell (T1059.001)	MDE script behaviour alerts; Script block logging in Windows Event Log (Event 4104)
Persistence	Scheduled Task / Job (T1053.005)	MDE DeviceEvents: ScheduledTaskCreated; SecurityEvent 4698
Defense Evasion	Impair Defenses: Disable or Modify Tools (T1562.001)	MDE alerts: Attempt to disable security product; Windows Defender tamper protection alerts
Credential Access	OS Credential Dumping: LSASS Memory (T1003.001)	MDE: Suspicious LSASS access alert; Credential Guard blocks extraction
Lateral Movement	Remote Services: SMB/Windows Admin Shares (T1021.002)	SecurityEvent 4648 (explicit credentials); NSG flow logs showing SMB spread
Impact	Data Encrypted for Impact (T1486)	MDE: Ransomware behaviour alert; DeviceFileEvents mass rename; Sentinel Fusion multi-stage detection
Impact	Inhibit System Recovery (T1490)	DeviceProcessEvents: vssadmin / wbadmin / bcdedit deletion commands

Ransomware IR Timeline

Ransomware IR timeline: Detection triggers immediate containment actions, followed by systematic eradication, validated recovery, and post-incident hardening. Legal and communication obligations run in parallel throughout.

Digital Forensics on Azure

Evidence Types and Collection

Azure forensic investigations deal with several categories of evidence, each with different collection methods and preservation considerations:

Evidence Type	Collection Method	Preservation Approach
VM Disk Image	Azure Portal → Disk → Create Snapshot (while VM is running); PowerShell: `New-AzSnapshot`	Store snapshot in immutable blob storage with WORM policy; record SHA-256 hash of snapshot VHD; restrict access to forensic team only
VM Memory	Not natively available in Azure; agent-based: MDE Live Response diagnostic package includes process list, open handles, loaded modules; crash dump via Windows if triggered	Collect MDE diagnostic package immediately — memory contents change rapidly; document collection time precisely
Network Traffic	Network Watcher packet capture (on-demand or triggered); NSG flow logs to Storage Account or Log Analytics; Traffic Analytics for aggregated view	Store PCAP files in immutable storage; NSG flow logs have configurable retention up to 90 days; enable flow logs before they are needed
Log Evidence	Export from Log Analytics workspace; Azure Activity log (export to Storage); Entra audit and sign-in logs (export to storage or archive workspace)	Export to immutable storage immediately; Log Analytics default retention is 30–90 days — extend retention or export before data ages out
Files / Artefacts	MDE Live Response: `getfile <path>` to pull specific files from an isolated endpoint without breaking isolation; collect prefetch, registry hives, scheduled task XML	Hash each collected file (SHA-256); store in secured, access-logged location; document chain of custody for each artefact

Chain of Custody

Chain of custody is the documented, unbroken record of who collected, handled, and accessed evidence. For Azure forensic evidence, this means:

Document every action: Who collected what, from which resource, at what time (UTC), using which method
Hash verification: Compute MD5 and SHA-256 hashes of disk snapshots and collected files immediately after collection; re-verify before analysis to confirm no modification
Azure Storage immutability: Use time-based immutability policies (WORM — Write Once Read Many) or legal hold policies on the container storing evidence. Evidence in a WORM container cannot be modified or deleted until the policy expires or is removed (legal hold requires explicit unlock).
Access logging: Enable Azure Storage diagnostic logging for the evidence container; all read/write/delete operations are logged with caller identity and timestamp
Witness documentation: For evidence that may support legal proceedings, have a second person witness collection and sign the chain-of-custody form

Disk Forensics: Snapshot and Analysis

The standard Azure disk forensics process:

Create a snapshot without stopping the VM: Azure managed disk snapshots are crash-consistent and can be taken while the VM is running. This preserves the running state without disrupting the attacker's active session (which you may want to observe) or alerting them via a shutdown event.
Export snapshot to VHD: Generate a SAS URL from the snapshot and download, or copy to a forensic storage account. Use az snapshot grant-access to get the SAS URI.
Attach snapshot to forensic VM: Create a new managed disk from the snapshot and attach it as a data disk to a dedicated forensic analysis VM — preferably in an isolated network with no outbound internet access.
Mount read-only: Use OS-level read-only mounting (mount -o ro on Linux) to prevent any modification to evidence during analysis. Windows forensic tools typically handle this via write-blocking.
Azure Disk Encryption (ADE) considerations: If the source disk was encrypted with ADE, you need the BEK (BitLocker Encryption Key) stored in the source subscription's Key Vault. The forensic VM must have Key Vault access to decrypt — plan this before the disk is detached from the original VM.

Network Forensics

NSG flow logs record metadata about network flows allowed or denied by NSG rules: source/destination IP and port, direction, protocol, bytes sent, and whether the connection was allowed or denied. Flow logs write to a Storage Account in JSON format. Version 2 flow logs include byte and packet counts per flow.

Query NSG flow logs in Log Analytics after enabling the Traffic Analytics integration:

// Identify large outbound flows from a specific VM in the last 24h
AzureNetworkAnalytics_CL
| where TimeGenerated > ago(24h)
| where VM1_s == "compromised-vm-name"
| where FlowDirection_s == "O"
| summarize TotalBytes = sum(BytesSentInFlowTunnel_d)
    by DestPublicIPs_s, DestPort_d, L7Protocol_s
| order by TotalBytes desc

Network Watcher packet capture collects full PCAP files from a running VM. Triggers can be on-demand (portal or API) or condition-based (specific port, packet count threshold, file size limit). PCAP files are stored in an Azure Storage account. Key limitation: packet capture requires the Network Watcher Agent VM extension on the target VM.

MDE Live Response for Forensic Collection

MDE Live Response provides a remote shell into an isolated endpoint, allowing forensic collection without exposing RDP or SSH. Capabilities relevant to forensic investigations:

processes — list running processes with PID, parent PID, and image path
getfile <path> — pull a specific file from the device to the investigation centre
run <script.ps1> — execute an approved PowerShell or bash script on the device; useful for collecting registry hives, prefetch files, or event logs
library — upload scripts to the live response library for repeated use across incidents
Isolation remains active during live response — the device cannot reach the internet, but the MDE management channel stays open

Azure Bastion provides RDP/SSH access to VMs via the Azure portal without requiring a public IP on the VM. During forensic investigation where live response is insufficient (e.g., OS-level recovery scenarios), Bastion provides a controlled access path with Azure Activity Log recording of the connection.

Azure Serial Console gives low-level access to the VM's serial port — useful when the OS is compromised and standard remote access methods are unavailable. Access is logged in the Activity Log.

Legal, Compliance, and Breach Notification

Under GDPR Article 33, a personal data breach must be notified to the relevant supervisory authority (the data protection authority in the EU member state) within 72 hours of the controller becoming aware of it — unless the breach is unlikely to result in a risk to individuals' rights and freedoms.

The notification must include, to the extent possible at the time:

The nature of the breach, including categories and approximate number of data subjects affected
Categories and approximate number of personal data records affected
Name and contact details of the Data Protection Officer (DPO)
Likely consequences of the breach
Measures taken or proposed to address the breach and mitigate its effects

Under Article 34, if the breach is likely to result in high risk to individuals, the affected data subjects must also be notified directly — without undue delay, in clear and plain language.

NIS2 Directive (EU)

The NIS2 Directive (effective October 2024 in EU member states) imposes incident reporting obligations on operators of essential and important entities across 18 sectors. The reporting timeline is more demanding than GDPR:

Early warning: within 24 hours of becoming aware of a significant incident — notify the national CSIRT (or competent authority) that an incident has occurred
Incident notification: within 72 hours — update with an initial assessment including severity, indicators of compromise, and whether the incident is suspected to be caused by a criminal act
Intermediate report: On request from the authority — status updates on the incident
Final report: within one month — detailed description, root cause analysis, cross-border impact, and measures implemented

Breach Notification Timelines by Regulation

Regulation	Notify Whom	Timeline	Threshold
EU GDPR	Supervisory authority (DPA); data subjects if high risk	72 hours from awareness (authority); without undue delay (subjects)	Any personal data breach unless risk to individuals is unlikely
EU NIS2	National CSIRT / competent authority	24 hours early warning; 72 hours full notification; 1 month final report	Significant incident affecting essential/important entity services
US HIPAA	HHS Office for Civil Rights; affected individuals; media (if >500 in state)	60 days from discovery for most; small breaches (<500) reported annually	Unsecured protected health information (PHI) accessed by unauthorised person
US CCPA / CPRA (CA)	California AG; affected consumers	Without unreasonable delay — courts interpret this as 30–45 days in practice	Unauthorised access to non-encrypted personal information of California residents
US SEC (public companies)	SEC (Form 8-K); investors/public	4 business days from determining materiality	Material cybersecurity incident affecting a public company

Legal Holds and eDiscovery in Microsoft Purview

During an incident investigation that may lead to legal proceedings, you must preserve relevant data to prevent spoliation (accidental or deliberate destruction of evidence). Microsoft Purview provides the tools:

eDiscovery holds: In the Microsoft Purview compliance portal, create an eDiscovery case, add custodians (the users whose data is relevant), and place a hold on their mailboxes, OneDrive accounts, and SharePoint sites. Content matching the hold criteria is preserved regardless of user deletion actions.
Litigation hold on mailboxes: A simpler alternative — enable litigation hold on an Exchange Online mailbox to preserve all mailbox content indefinitely (or for a specified period) without needing a full eDiscovery case.
Preservation lock: For regulatory compliance, a preservation lock on a retention policy prevents any administrator — including global admins — from disabling the policy or reducing its retention period. This is the equivalent of an immutability guarantee for retention policies.
Content search: Use Purview content search to locate data across Exchange, SharePoint, OneDrive, and Teams that is relevant to the investigation. Export results as PST (for email) or ZIP (for files) for review by legal counsel.

Forensic Report Structure

A complete forensic report produced at the end of an investigation should contain these sections, in this order:

Executive Summary: 1–2 page non-technical overview — what happened, business impact, and key remediation actions taken. Audience: leadership, board, legal.
Incident Timeline: Chronological sequence of attacker actions from initial access through to detection and containment. Include UTC timestamps for every event.
Technical Findings: Detailed analysis — initial access vector, malware or tools used, accounts compromised, systems affected, data accessed or exfiltrated.
Evidence Inventory: List of all evidence collected, with collection method, hash values, collection time, and current storage location.
Root Cause Analysis: What security control failed or was absent that allowed the incident to occur.
Remediation Recommendations: Specific, prioritised actions to prevent recurrence — patching, configuration changes, new controls, process changes.

Post-Incident Hardening

Security Posture Review

Immediately after an incident is contained, run a security posture review to understand what the incident revealed about gaps in your baseline controls:

Defender for Cloud Secure Score delta: Compare your current Secure Score against the pre-incident baseline. New recommendations triggered by the incident (e.g., "Enable MFA for all users with high-risk roles") represent identified gaps that the attacker exploited or could have exploited.
Regulatory compliance dashboard: Check whether the incident revealed compliance gaps in your assigned standards (NIST, CIS, PCI-DSS). Non-compliant controls that were present before the incident are particularly important.
Attack path analysis in Defender for Cloud: Review the attack path graph to understand each hop the attacker took, then systematically close every step: patch the vulnerability, re-permission the over-privileged identity, disable the unused protocol, or remove the unnecessary network path.

Credential Hygiene Post-Incident

After any incident involving credential compromise, assume all credentials that could have been observed are compromised:

Rotate all secrets and certificates that were present in environment variables, configuration files, or Key Vault instances accessible to compromised workloads
Force password reset for all accounts that logged into affected systems — even accounts that show no suspicious activity may have cached credentials in memory that were dumped
Review service principal credentials in Entra: Check all app registrations for credentials (client secrets and certificates). Rotate any credentials associated with compromised workloads. Use the servicePrincipalRiskDetections API to identify service principals flagged as risky.
Audit OAuth app grants: Compromised user accounts may have been used to grant OAuth permissions to malicious apps. Review and revoke suspicious consent grants in Entra → Enterprise Applications → Permissions → Admin consent requests.
Review Managed Identity assignments: Check which resources have system-assigned or user-assigned managed identities, and what roles those identities hold. Remove any assignments added during the incident window.

Checking for Residual Persistence

Ransomware operators and advanced threat actors routinely leave backdoors for re-entry. Before declaring recovery complete, systematically check for persistence mechanisms:

Scheduled tasks: Review all scheduled tasks on recovered systems for tasks created during the incident window (schtasks /query /fo LIST /v or SecurityEvent 4698)
Registry run keys: HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and RunOnce variants
New local admin accounts: Check for accounts created during the incident window (SecurityEvent 4720 + 4732)
WMI event subscriptions: Get-WMIObject -Namespace root\subscription -Class __EventFilter — a common attacker persistence technique that survives reboots
New OAuth app grants and service principals: Review Entra audit logs for application registrations and OAuth consent grants created during the incident window
New role assignments: Check Azure RBAC and Entra role assignment logs for privilege escalation that occurred before containment

// Find new admin accounts created during incident window (24h)
SecurityEvent
| where TimeGenerated between (datetime(2026-05-01T00:00:00Z) .. datetime(2026-05-02T00:00:00Z))
| where EventID == 4720  // Account created
| join kind=inner (
    SecurityEvent
    | where EventID == 4732  // Added to local admin group
    | where TargetUserName == "Administrators"
) on $left.TargetUserName == $right.MemberName
| project AccountCreatedTime = TimeGenerated, NewAccount = TargetUserName,
    CreatedBy = SubjectUserName, Computer

Tabletop Exercises and Purple Team Operations

Tabletop exercises are structured discussion-based sessions where the IR team walks through a hypothetical incident scenario. Post-incident tabletops specifically focus on what the real incident revealed about gaps:

Which detection rules fired too late, or not at all?
Which playbooks were missing, incomplete, or too slow?
Where did communication break down between teams?
What monitoring needs to be added to detect this class of attack earlier?

Purple team exercises combine red team adversary simulation with blue team defenders working together openly. Unlike red team exercises (where blue team does not know an exercise is happening), purple team exercises are collaborative — the red team announces each technique before executing it, so the blue team can verify whether their detection tools actually catch it. Post-incident, purple team exercises are used to validate that the new detection rules and hardening measures actually work against the techniques the attacker used.

Exam Tips & Key Takeaways

Critical concepts to master for SC-500:

Hunting bookmarks vs. watchlists: Bookmarks capture specific result rows during an active hunt and can be promoted to incidents. Watchlists are pre-loaded reference data (IOC lists, allowlists) used in analytics and hunting queries. These are commonly confused in exam questions.
_GetWatchlist() is the KQL function for referencing a watchlist by its alias — not a table name or a function with a different prefix. Know this syntax precisely.
join kind=leftanti for exclusion: When a question asks how to find events NOT in a known-good list, the answer uses leftanti join, not a where ... !in with a subquery (though both work, leftanti scales better).
UEBA tables: BehaviorAnalytics contains anomaly scores per event; UserPeerAnalytics contains peer group comparison data. Know which table to query for which purpose.
Fusion cannot be customised: Fusion ML rules are managed by Microsoft and cannot be edited, only enabled or disabled. If an exam question asks how to tune Fusion sensitivity, the answer is that you cannot — you manage the underlying data connectors instead.
Disk snapshot before VM shutdown: Capture disk snapshots before deallocating a compromised VM. Snapshotting a running disk is supported and produces a crash-consistent image. Once a VM is deleted without a snapshot, disk evidence is irrecoverable.
Azure Backup soft delete = 14 days: This specific number appears in exam questions. Soft delete keeps deleted backup data for 14 days and is enabled by default in Recovery Services vaults.
GDPR = 72 hours to supervisory authority; NIS2 = 24 hours early warning, then 72 hours: The distinction between GDPR and NIS2 timelines is a likely exam scenario question. NIS2's 24-hour early warning is the shorter, earlier obligation.
MDE network isolation preserves the management channel: An isolated device can still be reached via MDE Live Response. Isolation does not cut the MDE channel — this is by design for continued forensic access.
Legal hold vs. retention policy: A litigation hold on a mailbox preserves content indefinitely. A retention policy with preservation lock cannot be removed by any admin — even a global admin — once locked. These serve different purposes and both appear in exam scenarios.

Exam scenario pattern: "You discover ransomware on three VMs at 09:00. You need to stop the spread immediately while preserving forensic evidence. What two actions do you take first?" The expected answer is: (1) isolate the devices via MDE network isolation — not shut them down, because shutdown destroys memory and running process evidence; and (2) take disk snapshots immediately, before any remediation that might alter disk state.

KQL exam pattern: "You want to find sign-ins from IPs that are not on your corporate allowlist watchlist." The answer combines _GetWatchlist('allowlist-name') with a leftanti join against SigninLogs — not a where IPAddress !in (...) with a hardcoded list.