In this section
Check My Knowledge
Scenario 1. Your organization runs Defender AV with default cloud protection on all endpoints. A phishing email delivers a PowerShell script that downloads and executes a .NET assembly entirely in memory. The assembly has never been seen by any AV vendor. What is the most likely outcome?
Defender blocks the assembly because cloud protection analyzes all unknown files within 10 seconds a
Cloud protection at the default level performs basic analysis but does not extend analysis time or block unknown files as aggressively as High+ or Zero Tolerance. The assembly never touches disk as a standalone file, so file-based scanning does not apply. Default cloud protection is Gen 2 capability operating at minimum. Section 0.1 covers the cloud protection level hierarchy.
AMSI may detect the script if it matches known patterns, but with sufficient obfuscation the in-memory assembly executes — default cloud protection and no custom detection rules leave this as a medium-severity EDR alert at best b
Correct. AMSI intercepts the PowerShell content but can be bypassed through obfuscation or reflection-based patching. The in-memory assembly bypasses file-based AV entirely. EDR behavioral correlation may generate an alert for the suspicious process chain, but with no custom detection rules and default AIR, the response is a medium-severity alert awaiting analyst triage — not prevention. Moving cloud protection to High+ and deploying custom detection rules are the engineering steps that change this outcome. Section 0.1 covers the generation gap between default and engineered configurations.
Network protection blocks the download URL before the script can retrieve the assembly c
Network protection blocks connections to known malicious URLs, but a newly provisioned attacker URL may not be in the blocklist. Network protection is a valuable layer but not a guarantee for unknown infrastructure. Section 0.3 covers why no single layer provides complete coverage.
The attack is completely undetectable by any Defender component d
MDE's EDR engine collects telemetry continuously — process creation, DLL loads, network connections. The attack generates events in DeviceProcessEvents and DeviceNetworkEvents. Built-in MDE behavioral models may flag the chain. The issue is not undetectable — it is that default configuration may not prevent or promptly alert on it. Section 0.1 covers the distinction between deployed and engineered.
Scenario 2. An attacker uses certutil.exe to decode a base64-encoded Cobalt Strike beacon, then uses rundll32.exe to load the decoded DLL. Both are signed Microsoft binaries. Why can AV not block this attack based on binary signatures?
Both are legitimate Windows binaries the OS depends on — the malicious behavior is how they are used, not what they are a
Correct. Certutil and rundll32 are signed Microsoft LOLBins (Living Off the Land Binaries). Blocking their execution would break Windows functionality. The attack is in the behavior — certutil decoding base64 into a DLL, rundll32 loading a DLL from an unusual path. Detecting this requires behavioral analysis: parent-child process chains, command-line arguments, and file write locations. ASR rules and EDR behavioral correlation operate at this level. Section 0.1 covers why LOLBin abuse is invisible to signature-based AV.
AV could block this with faster signature updates — the delay in distribution is the problem b
The binaries being abused (certutil, rundll32) are legitimate and will never receive malware signatures. The decoded DLL might eventually receive a signature, but only after it is discovered and analyzed — which happens after the attack succeeds. Signature speed is not the issue. The architectural limitation of signature-based detection is. Section 0.1 covers this generation gap.
AV should block the decoded DLL when it is written to disk c
If the DLL is written to disk, AV may scan it — but the scan depends on whether the DLL matches known signatures or triggers heuristic analysis. A custom beacon built for this specific operation is unlikely to match existing signatures. Cloud protection at High+ increases the probability of detection. The more fundamental issue is that the attack uses legitimate binaries, not that AV cannot scan the output. Section 0.1 covers cloud protection levels.
Tamper protection would prevent misuse of system binaries d
Tamper protection prevents modification of Defender's own configuration and sensor — it does not restrict the use of system binaries for non-security purposes. Tamper protection and LOLBin abuse operate at different layers. Section 0.3 covers what each layer of the stack actually defends.
Scenario 3. Your CISO asks you to deploy all 18 ASR rules in block mode this week to address an audit finding. You have not run any ASR rules in audit mode. What is the correct response?
Deploy all rules in block mode — the audit finding takes priority over deployment methodology a
Deploying 18 rules simultaneously without audit data risks breaking legitimate applications across the fleet. Multiple failures occurring simultaneously make it impossible to isolate which rule caused which problem. The audit finding is not addressed by a deployment that gets rolled back in 48 hours. Section 0.7 covers why deployment sequence matters more than deployment speed.
Refuse to deploy any ASR rules until a full 90-day assessment is complete b
A 90-day delay is unnecessary. The "safe set" — LSASS credential theft, vulnerable driver abuse, USB untrusted processes — can be deployed to block mode immediately because they have near-zero legitimate triggers. The remaining rules go to audit. Refusing entirely is as wrong as deploying everything. Section 0.7 covers the phased approach that satisfies both the audit and the stability requirement.
Deploy the safe-set rules (LSASS, vulnerable drivers, USB) in block mode immediately, put the rest in audit mode, and present the auditor with a documented phased deployment plan c
Correct. The safe set provides immediate protection with near-zero blast radius. Audit mode on the remaining rules generates the data needed for evidence-based exclusion analysis. The auditor sees: 3 rules in block mode, 15 in audit mode, a documented deployment schedule with success criteria for each phase. An audit that finds a risk-prioritized plan in progress passes. An audit that finds 18 rules deployed and rolled back does not. Section 0.7 and Section 0.8 cover the phased approach and blast radius assessment.
Deploy all rules in audit mode only — block mode is too risky without testing d
Audit-only provides no protection. The safe-set rules have documented low false positive rates across most environments — keeping them in audit when they could safely be in block mode is an unnecessary acceptance of risk. The evidence-based approach deploys the safe set immediately and promotes others as audit data confirms safety. Section 0.8 covers blast radius assessment for each rule.
Scenario 4. Your endpoint security program is at maturity Level 2 (Baseline). You have 95% onboarding, AV at High+, the safe-set ASR rules in block mode, and LAPS deployed. A vendor offers an advanced threat hunting platform. Your CISO is considering purchasing it. What is your recommendation?
Purchase immediately — threat hunting is the highest-value security capability a
Threat hunting is valuable but depends on the foundation beneath it. Without custom detection rules (Level 3), hunting queries have no automated follow-up — findings require manual rule creation each time. Without forensic readiness, hunting queries may not have the telemetry they need. Complete Level 3 first. Section 0.9 covers why maturity levels are cumulative.
Decline — your organization does not need threat hunting until Level 5 b
Threat hunting belongs at Level 3 (Managed), not Level 5. Waiting until Level 5 means years of potential threats going undetected. The recommendation is not to reject hunting — it is to complete the Level 3 prerequisites that make hunting effective first. Section 0.9 covers what each level requires.
Purchase but defer deployment until all ASR rules are in block mode c
ASR rule completion is a Level 2 activity. Hunting requires Level 3 capabilities — custom detection rules and forensic readiness — not just Level 2 completion. The blocker is not ASR rules; it is the detection and forensic infrastructure that makes hunting findings actionable. Section 0.9 covers the Level 2 to Level 3 transition.
Complete Level 3 first — deploy custom detection rules, configure forensic readiness (Sysmon, ScriptBlock logging), then hunting has the foundation it needs d
Correct. Threat hunting requires: telemetry to hunt through (Sysmon + ScriptBlock logging provide the event detail that default logging does not), custom detection rules to automate findings (so each hunting discovery becomes a persistent detection), and an operational cadence that makes hunting sustainable. Without these, the hunting platform produces one-time findings that require manual follow-up. Complete Level 3, then hunting at Level 4 is immediately productive. Section 0.9 covers the maturity progression.
Scenario 5. You are moving the ASR rule "Block Office applications from creating child processes" from audit to block mode. Audit data shows 340 events in 14 days from 12 unique applications. Which approach minimizes both security risk and business disruption?
Wait until all 12 applications are replaced with Office-native alternatives before enabling block mode a
Waiting for application replacement could take months or years. During that time, every phishing email with a malicious macro succeeds. The correct approach builds exclusions for the specific binaries, not replaces all affected applications. Section 0.8 covers exclusion-based promotion.
Classify each of the 12 applications as legitimate or suspicious, create path-specific exclusions for the legitimate ones, enable block mode with exclusions, and test with one user per affected department b
Correct. The audit data is the decision input. Classify each triggering application. Create ASR exclusions for the specific binary paths of legitimate applications. Enable block mode with exclusions applied. Test with pilot users in affected departments. The 12 applications may require only 3-4 exclusions (some applications share a common binary). The remaining audit events from unknown processes are the attack attempts the rule blocks. Section 0.8 walks through this analysis with NE's actual audit data.
Enable block mode without exclusions — 340 events in 14 days is a low volume that users can tolerate c
340 events across 12 applications means those applications break for every user every time they trigger. Even "low volume" becomes high impact if the affected application is a finance team's month-end reporting workflow. Block without exclusions is the approach that causes rollbacks. Section 0.8 covers the three levels of blast radius — direct, indirect, and reputational.
Keep the rule in audit mode permanently — the security benefit does not justify the operational risk d
Audit mode provides zero protection. Every phishing macro that spawns PowerShell succeeds while the rule logs events nobody acts on. The operational risk of block mode with targeted exclusions is minimal — the exclusion analysis from audit data identifies the affected applications before enforcement. Permanent audit mode is accepting the risk of every macro-based attack chain. Section 0.8 covers why audit-only is not a security posture.
Scenario 6. An attacker compromises a user endpoint at NE. Their first action is running Get-MpPreference to check the endpoint's security configuration. The output shows CloudBlockLevel: 0, ASR rules: empty, RunAsPPL: not configured, ScriptBlock logging: not configured. What does this tell the attacker?
Standard tradecraft with no modifications needed — every default tool and technique will work without evasion a
Correct. CloudBlockLevel 0 means default cloud protection — lower detection rates for unknown files. Empty ASR rules means no behavioral prevention at all. No RunAsPPL means LSASS is unprotected by PPL. No ScriptBlock logging means PowerShell commands leave no forensic trail. The attacker uses default Mimikatz, default Cobalt Strike, default PowerShell scripts — no obfuscation, no bypass techniques, no operational security adjustments needed. The cost of operating on this endpoint is near zero. Section 0.10 covers this assessment from the attacker's perspective.
The attacker cannot determine the security posture from Get-MpPreference alone b
Get-MpPreference reveals cloud protection level, ASR rule configuration, tamper protection state, and real-time protection status. Combined with checks for Sysmon, ScriptBlock logging, and Credential Guard, the attacker has a complete security posture assessment within 60 seconds. Section 0.10 covers the four reconnaissance checks.
The attacker must assume strong defenses and use evasion techniques regardless of the output c
Sophisticated attackers may use evasion by default, but most adjust their tradecraft to the target. Default-configured endpoints allow faster, noisier, more reliable techniques. Well-defended endpoints force slower, stealthier, more complex approaches. Knowing the defense level shapes operational decisions. Section 0.10 covers how the reconnaissance output changes attacker behavior.
The security configuration is irrelevant — MDE's built-in detections will catch any known attack tool d
MDE's built-in detections catch known tool signatures but leave gaps for modified or custom tooling. Without ASR rules, the prevention layer is absent. Without custom detection rules, organization-specific attack patterns generate no alerts. Built-in detections are a floor, not a ceiling. Section 0.1 covers the gap between built-in and engineered detection.
Scenario 7. Your incident response team investigates a ransomware event. They find that the attacker used PowerShell to stage and encrypt files. The team cannot determine which specific PowerShell commands were executed because only Event IDs 400 and 403 are in the logs. Which forensic readiness gap caused this?
Sysmon was not deployed — Sysmon captures PowerShell command content a
Sysmon Event ID 1 captures the PowerShell process creation with command-line arguments, but not the full script content of dynamically generated code. ScriptBlock logging captures the actual decoded script content — including Invoke-Expression output and dynamically assembled commands. Sysmon complements ScriptBlock logging but does not replace it. Section 0.3 covers the forensic readiness layer.
Advanced audit policies were not configured — process creation auditing captures PowerShell content b
Process creation auditing (Event ID 4688 with command-line logging) captures the PowerShell command line — the arguments visible when the process starts. It does not capture the script content executed within the PowerShell session, including decoded commands, Invoke-Expression output, or dynamically generated code blocks. The command line might show "powershell.exe -enc [base64]" but the decoded content requires ScriptBlock logging. Section 0.3 covers this distinction.
PowerShell ScriptBlock logging was not enabled — without Event ID 4104, the actual script content is not recorded c
Correct. ScriptBlock logging (Event ID 4104) captures the full content of every PowerShell script block at execution time, including decoded commands, Invoke-Expression results, and dynamically assembled scripts. Without it, the investigator sees engine start/stop events (400/403) and possibly the initial command line (4688), but not what the script actually did. A 200-line credential harvesting and encryption script executed via Invoke-Expression leaves zero content evidence without ScriptBlock logging. Section 0.3 identifies this as the most common forensic readiness gap.
MDE's Advanced Hunting should contain the PowerShell content — the gap is in the retention period d
MDE captures process creation events and some command-line content in DeviceProcessEvents, but the full decoded script content captured by ScriptBlock logging is a separate data source. MDE's telemetry and ScriptBlock logging complement each other. The 30-day Advanced Hunting retention may also be a factor, but the primary gap is the absence of ScriptBlock logging content. Section 0.3 covers the distinction between MDE telemetry and local forensic evidence.
Scenario 8. NE's MDE deployment shows 780 of 865 endpoints onboarded with active sensors. The remaining 85 are not reporting. Your team wants to begin deploying ASR rules. What should you do about the 85 non-reporting endpoints first?
Proceed with ASR deployment — the 85 endpoints will receive rules when they come online a
ASR rules deploy through Intune, not MDE — they apply regardless of sensor status. But without MDE telemetry, you cannot see ASR audit or block events from those devices. If an ASR rule breaks a legitimate application on an unonboarded device, you have no visibility to diagnose the problem. The user reports "my application stopped working" with no security telemetry to explain why. Section 0.7 covers why onboarding must precede enforcement.
Delay all ASR deployment until 100% of endpoints are onboarded b
Delaying protection for 780 endpoints because 85 are not reporting is disproportionate. The correct approach remediates the 85 non-reporting endpoints in parallel with ASR audit deployment on the 780 healthy endpoints. Both workstreams proceed simultaneously. Section 0.7 covers parallel deployment tracks.
Exclude the 85 endpoints from ASR rules using an Intune device group filter c
Excluding the non-reporting endpoints from ASR rules leaves them unprotected and does not solve the underlying onboarding problem. The 85 endpoints without MDE telemetry are security blind spots — they may already be compromised. Excluding them from protection makes the blind spot worse. Section 0.6 covers why onboarding gaps represent the highest-priority remediation.
Investigate the 85 endpoints — identify why sensors are inactive, remediate the onboarding issues, and begin ASR audit on the 780 healthy endpoints in parallel d
Correct. The 85 non-reporting endpoints need investigation: are they offline (expected for travel laptops), have sensors failed (reinstall needed), or have they been tampered with (potential compromise indicator). Remediate each category. Simultaneously, deploy ASR rules in audit mode on the 780 healthy endpoints to begin collecting the audit data needed for enforcement decisions. Both workstreams produce results — the onboarding gap closes while ASR audit data accumulates. Section 0.7 covers the onboarding-first deployment principle.
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.