ES0.13 Check My Knowledge

Defender AV blocks the .NET assembly because cloud protection sends it for analysis — cloud protection at default level catches all unknown files within 10 seconds.

AMSI may detect the PowerShell script content if it matches known patterns, but if the script is sufficiently obfuscated or uses an AMSI bypass, the in-memory .NET assembly executes without detection. Default cloud protection 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 AV scanning does not apply. Detection depends on whether MDE's EDR behavioral correlation identifies the process chain as suspicious — but with no custom detection rules and default AIR, the response may be limited to a medium-severity alert that waits for analyst triage.

Defender AV blocks the download because network protection prevents connections to the download URL.

The attack is completely undetectable by any Defender component until a full forensic investigation is performed.

Certutil and rundll32 are legitimate, signed Microsoft binaries that the operating system depends on. They cannot be blocked by signature — blocking them would break Windows functionality. The malicious behavior is not the binaries themselves but HOW they are used: certutil for base64 decoding (intended for certificate management) and rundll32 for loading an untrusted DLL. Detecting this attack requires behavioral analysis — identifying that certutil is being used for decoding rather than certificate operations, and that rundll32 is loading a DLL from an unusual path. This is why EDR and ASR rules exist: they analyse behavior, not binary identity.

AV could block this if the signature database were updated more frequently — the delay in signature distribution is the issue.

AV should be able to block the decoded DLL when it is written to disk — the decoding step creates a file that can be scanned.

This attack is only possible because tamper protection is not enabled — tamper protection would prevent misuse of system binaries.

Detection layer — the custom detection rules should have included file access monitoring.

Prevention layer — Controlled Folder Access should have prevented the file access.

Forensic readiness layer. Object access auditing (Advanced Audit Policy → Object Access → Audit File System) must be explicitly configured to generate Event ID 4663 for file access attempts. MDE's DeviceFileEvents captures file creation, modification, and deletion but does not comprehensively record file reads in the same way. Sysmon Event ID 11 captures file creation, not file reads. Without object access auditing configured, no log source records which files the attacker opened and read. The gap is in the forensic readiness configuration — a specific audit policy that was not enabled.

Response layer — the containment should have included a full memory dump before isolation to capture file access artifacts.

Nothing is wrong — understanding the threat landscape through detection before deploying prevention is a valid approach.

The reasoning inverts the priority. Every attack that a prevention control would have blocked but did not (because prevention was deployed after detection) generates: an alert that an analyst must triage, an investigation that an analyst must perform, a containment action that must be executed, and potentially a successful compromise that must be remediated. Prevention eliminates the incident entirely — no alert, no triage, no investigation, no remediation. ASR audit mode (Phase 1) provides the "understanding what attacks we face" data that the colleague wants — without allowing those attacks to succeed. The correct sequence: deploy ASR in audit mode (visibility), analyse the audit data, move to block mode (prevention), THEN build custom detections for the techniques that bypass prevention. Detection handles the remainder. Prevention handles the majority.

Custom detection rules require Sentinel integration which takes longer to configure than ASR rules — the ordering is purely about technical dependencies.

Detection rules generate false positives that distract the SOC, so they should always be deployed last.

The user is blocked from Exchange Online because the compliance policy reports the device as non-compliant, and the conditional access policy enforces the compliance requirement.

It depends on the CA policy configuration — specifically, whether the CA policy actually references device compliance as a grant control. At NE, the description states that compliance policies EXIST but do not enforce CA — no conditional access policy references the compliance state. The user accesses Exchange Online normally because no CA policy blocks them. Compliance policies and conditional access policies are separate configurations: the compliance policy evaluates the device, but only a CA policy that references compliance as a grant control enforces access decisions based on that evaluation. This is the most common integration gap in M365 environments.

MDE automatically quarantines the non-compliant device, preventing all network access including Exchange Online.

The user can access Exchange Online via browser but not via the Outlook desktop app, because compliance only applies to managed applications.

Level 2 (Baseline). You meet all Level 2 criteria: 100% onboarded, AV at High+, ASR in block (at least safe set), LAPS deployed, compliance enforcing CA. You meet SOME Level 3 criteria (custom detections, AIR configured) but fail others: no Sysmon, no PowerShell logging, no hunting cadence. The maturity model requires ALL criteria at a level before advancing. Three missing Level 3 criteria keep you at Level 2. The priority fixes: deploy Sysmon, enable PowerShell ScriptBlock logging, and establish a monthly hunting cadence. These three actions advance you to Level 3.

Level 3 — the custom detections and AIR configuration meet the detection requirements even without Sysmon.

Level 1 — without complete forensic readiness, the environment is still fundamentally ad hoc.

Level 2.5 — partial credit should be given for the Level 3 criteria that are met.

No change — the attacker uses the same techniques regardless of the endpoint security configuration because they cannot know for certain which techniques will be detected.

The attacker proceeds with standard tradecraft: Mimikatz or comsvcs.dll for LSASS credential dumping (not blocked by ASR audit mode), Office→PowerShell chains for execution (not blocked), WMI for persistence (not blocked), and standard Cobalt Strike malleable C2 profiles (no Sysmon to record detailed process chains). Anti-forensics are optional because default audit policies provide minimal evidence. In contrast, if ASR were in block mode and Sysmon active, the attacker would need: alternative credential access (Kerberoasting, DCSync) instead of direct LSASS dumping, AMSI bypass and in-memory execution instead of standard PowerShell, process injection or migration to evade EDR hooks, and timestomping or log manipulation to reduce the Sysmon evidence trail. Each workaround is more complex, slower, and generates additional detection opportunities. The configuration difference transforms the attack from 4 straightforward steps to 8+ complex steps with multiple detection surface exposures.

The attacker aborts the operation because ASR in any mode (including audit) indicates the organisation is security-aware.

The attacker focuses on disabling Defender entirely since tamper protection is the only control that actually matters.

Deploy Sysmon — forensic readiness enables the IR team to respond effectively to any future incident.

Build 10 custom detection rules — detection is the foundation that tells you what attacks are happening.

Deploy LAPS and enable the LSASS ASR rule in block mode. These two controls together close the single most dangerous compound gap: without LAPS, every endpoint shares the same local admin password. Without the LSASS ASR rule, the attacker can dump that password from any compromised endpoint. Together, these gaps enable a single-endpoint compromise to become an environment-wide breach with zero additional attacker effort. LAPS (unique password per endpoint) eliminates credential reuse for lateral movement. The LSASS ASR rule (block mode) prevents the credential dump that starts the lateral movement chain. Both have low blast radius: LAPS affects only scripts that use the shared local admin password (which should be updated anyway), and the LSASS ASR rule rarely triggers on legitimate software. High security impact, low production impact — the optimal single-month investment.

Raise AV cloud protection to High+ — this is the simplest change with the broadest malware detection improvement.