In this section
Check My Knowledge
Scenario 1. An attacker runs Mimikatz on a compromised endpoint where the ASR rule "Block credential stealing from LSASS" is in block mode. The attacker has local administrator privileges. What happens when Mimikatz attempts to dump credentials?
The ASR rule blocks the handle acquisition before Mimikatz can read LSASS memory a
Correct. The ASR rule intercepts the OpenProcess call when the target is LSASS and the calling process is not Microsoft-signed, blocking the call before any memory read occurs. The credential dump fails entirely. An ASR block event is generated in DeviceEvents (ActionType: AsrLsassCredentialTheftBlocked). The attacker must find an alternative path — Kerberoasting, DCSync, or token theft — each of which targets a different OS component and generates different telemetry. Section 1.2 covers the four-layer LSASS protection architecture.
Mimikatz bypasses the ASR rule because SeDebugPrivilege overrides ASR restrictions for LSASS access b
SeDebugPrivilege allows opening handles to any process, but the ASR rule operates at a different enforcement layer. The ASR rule intercepts the OpenProcess call regardless of the calling process's privileges. SeDebugPrivilege would be relevant without the ASR rule, but the ASR rule blocks the handle acquisition step that SeDebugPrivilege would otherwise enable. Section 1.1 covers the relationship between privileges and handle access.
The ASR rule allows the handle but blocks the memory read operation c
The ASR rule blocks at the handle acquisition step, not the memory read step. There is no separate interception at ReadProcessMemory. The architectural principle: block as early in the attack sequence as possible. If the handle is blocked, the memory read never executes. Section 1.2 explains why the handle step is the correct interception point.
The ASR rule blocks Mimikatz from executing because it is a file-based block on known attack tools d
ASR rules are behavioral, not signature-based. The LSASS ASR rule blocks any non-Microsoft process from opening LSASS with specific access rights — it does not identify Mimikatz by filename, hash, or signature. A completely custom tool that performs the same handle acquisition would also be blocked. Section 1.2 explains why behavioral controls are more durable than signature-based ones.
Scenario 2. A Sysmon Event ID 8 (CreateRemoteThread) shows: SourceImage = C:\Windows\Temp\svcupdate.exe, TargetImage = C:\Windows\System32\svchost.exe. Your SOC analyst asks whether this is suspicious. What do you tell them?
Not suspicious — svchost frequently receives remote threads from system services during normal Windows operations a
While svchost does receive legitimate remote threads, they originate from known system locations (System32, Program Files) — not from Temp directories. The source location is the critical signal. A remote thread from a system path is likely legitimate. A remote thread from Temp is suspicious regardless of the target. Section 1.1 covers why source process context matters for injection detection.
Highly suspicious — the source binary is in a Temp directory and is injecting into a high-value system process b
Correct. Three indicators converge: the source is in C:\Windows\Temp (unusual for legitimate executables), the target is svchost.exe (a high-value injection target with network access and trusted status), and the filename is designed to appear legitimate ("svcupdate.exe"). Investigate the binary's signature (likely unsigned), check the parent process that created it, examine the MDE device timeline for related activity, and check whether the injected svchost is making unusual network connections. Section 1.1 covers why process injection targets svchost specifically.
It depends on whether svcupdate.exe is signed by Microsoft — signed binaries creating remote threads is always legitimate c
A Microsoft signature does not guarantee legitimacy — attackers use signed Microsoft binaries (LOLBins) for malicious purposes. More importantly, a binary in Temp with a generic name is unlikely to be a real Microsoft binary. The location, name, and behavior together form the assessment. Section 1.1 covers how code signing relates to process trust.
Sysmon Event ID 8 produces too many false positives to be actionable — this event type should be excluded d
Event ID 8 does generate volume, but the correct response is filtering (exclude known legitimate source-target pairs) rather than disabling. Removing CreateRemoteThread monitoring eliminates visibility into the primary process injection technique. Section 1.1 explains why tuning detection sources is preferable to disabling them.
Scenario 3. An attacker patches the EtwEventWrite function in ntdll.dll within their Cobalt Strike beacon process. MDE's kernel-mode driver uses PsSetCreateProcessNotifyRoutine. What visibility does MDE retain?
MDE loses all visibility into the beacon process because ETW is the only telemetry source a
MDE uses both user-mode ETW consumers and kernel-mode callbacks. The kernel callbacks operate independently of ETW — they are registered directly with the kernel's notification mechanism. Patching ETW in user mode does not affect kernel callback delivery. Section 1.4 covers the dual-mode architecture and why it provides defense in depth against ETW tampering.
MDE retains full visibility because tamper protection prevents all ETW modifications b
Tamper protection prevents modification of MDE's own configuration and sensor, but does not prevent an attacker from patching ntdll.dll in their own process's address space. The patch is process-local — it does not modify MDE's files or services. Tamper protection and ETW patching operate at different levels. Section 1.4 explains the specific scope of each protection mechanism.
MDE retains kernel-callback visibility (process creation, network connections, handle operations) but loses user-mode ETW data (script content, AMSI results) for the beacon process c
Correct. Kernel callbacks (PsSetCreateProcessNotifyRoutine, network callbacks) continue reporting because they are independent of user-mode ETW. MDE sees the beacon's process creation, child processes, network connections, and file operations through kernel telemetry. MDE loses the user-mode ETW events from the beacon: PowerShell ScriptBlock content, AMSI scan results, and some API-level detail. The practical impact: MDE sees what the process does but may not see the script content that drives the actions. Section 1.4 covers this architectural separation in detail.
MDE detects the ETW patch immediately and auto-remediates by restoring the original function bytes d
MDE does not automatically restore patched ETW functions. Some behavioral detections may fire on the memory modification pattern, but automatic restoration of ntdll functions is not a documented MDE capability. The defense against ETW patching is defense in depth (kernel callbacks, Sysmon, HVCI) rather than automatic repair. Section 1.4 covers the layered approach to ETW integrity.
Scenario 4. Credential Guard is enabled on a Windows 11 endpoint. An attacker with SYSTEM privileges dumps LSASS memory using a custom tool that bypasses the ASR rule. What credential material do they obtain?
All credentials — SYSTEM privileges override Credential Guard a
Credential Guard uses VBS to isolate secrets in a separate virtual trust level. Even the NT kernel — and therefore SYSTEM-level code — cannot access the isolated virtual machine. The hypervisor enforces the boundary. No privilege level within the main OS can override VBS isolation. Section 1.2 covers the VBS architecture.
No credentials at all — Credential Guard empties the LSASS memory entirely b
LSASS still contains some credential material with Credential Guard enabled — cached domain credentials in DCC2 format, logon session metadata, and material for protocols not protected by Credential Guard. The primary secrets (NTLM hashes, Kerberos TGTs) are moved to LSAIso, but LSASS is not completely empty. Section 1.2 covers what remains in LSASS after Credential Guard activation.
Only Kerberos tickets — Credential Guard protects NTLM hashes but not Kerberos material c
Credential Guard protects both NTLM hashes and Kerberos ticket-granting keys. Both are moved to LSAIso. The attacker obtains neither the primary NTLM hash nor the Kerberos TGT from the LSASS dump. Section 1.2 covers the scope of Credential Guard protection.
Limited material — cached domain credentials in DCC2 format and session metadata, but not the primary NTLM hash or Kerberos TGT d
Correct. Credential Guard moves the primary NTLM hash and Kerberos ticket-granting keys to LSAIso, inaccessible from the main OS. The dump contains: DCC2-format cached credentials (crackable offline but not usable for pass-the-hash), logon session metadata, and credential material for unprotected protocols. The attacker cannot perform pass-the-hash or pass-the-ticket with the extracted material — the most dangerous credential theft techniques are neutralized. Section 1.2 covers the four-layer LSASS defense architecture.
Scenario 5. On a Linux server, you find a SUID binary at /tmp/.hidden/escalate that is not in the standard RHEL installation. The binary is owned by root. What is the correct assessment and immediate action?
Likely a legitimate administration tool compiled locally — check with the server administrator a
A SUID-root binary in a hidden directory under /tmp is never legitimate. System binaries belong in /usr/bin or /usr/sbin. Admin tools belong in /opt or /usr/local. A hidden directory in /tmp with a SUID binary is a textbook privilege escalation persistence mechanism. Waiting to check with the administrator delays response to a likely compromise. Section 1.7 covers SUID abuse patterns.
This is a privilege escalation persistence mechanism — remove the SUID bit immediately and investigate the server as compromised b
Correct. A SUID-root binary in a hidden /tmp directory is T1548.001 (Setuid and Setgid). Immediate actions: remove the SUID bit (chmod u-s), investigate the binary (file, strings, sha256sum for hash lookup), check who created it (stat for timestamps, correlate with auth.log), and treat the server as compromised. The exception would be if /tmp is mounted with nosuid (the SUID bit has no effect) — but even then, the binary's presence indicates attacker activity. Section 1.7 covers SUID defense including nosuid mount options.
The SUID bit has no effect in /tmp because systemd automatically mounts /tmp with nosuid c
Not all Linux distributions mount /tmp with nosuid by default. RHEL does not enable nosuid on /tmp by default unless specifically configured. Even if nosuid is enabled, the binary's presence indicates an attacker has been on the system — the investigation is still required. Section 1.7 covers nosuid as a hardening control, not a default configuration.
SUID binaries are automatically cleaned by the systemd-tmpfiles-clean service at the next cycle d
systemd-tmpfiles-clean removes old files from /tmp based on age, but it does not specifically target SUID binaries and may not run for days. The attacker's binary persists until cleaned — and the attacker has likely already used it for escalation. Waiting for automatic cleanup is not a security response. Section 1.7 covers why proactive SUID auditing is necessary.
Scenario 6. A signed and notarized macOS application from a phishing email passes Gatekeeper and executes. The application attempts to access the user's browser cookies. Which macOS security mechanism should prevent this access?
Gatekeeper — it should perform deeper behavioral analysis before allowing execution a
Gatekeeper validates code signing and notarization status — whether the application is allowed to execute. It does not analyze application behavior after execution or restrict resource access. A signed, notarized malicious application passes Gatekeeper by design. Gatekeeper controls WHETHER an app runs. TCC controls WHAT a running app can access. Section 1.8 covers the distinction.
SIP — System Integrity Protection prevents applications from accessing browser data directories b
SIP protects system directories (/System, /usr, /bin) from modification, even by root. Browser cookies are stored in user-space directories (~/Library/), which SIP does not protect. SIP is a system integrity mechanism, not a user data access control. Section 1.8 covers the specific scope of SIP protection.
TCC — the application needs Full Disk Access or specific app permissions to read browser cookie storage c
Correct. Browser cookies are stored in TCC-protected locations. An application without Full Disk Access cannot read them. If the user did not grant Full Disk Access to the phishing application, TCC blocks the access. If the user clicked "Allow" on the TCC prompt, TCC functioned correctly but the user made a poor security decision. The enterprise defense: MDM-managed TCC profiles that restrict Full Disk Access to approved applications only. Section 1.8 covers TCC as the post-execution access control layer.
The Endpoint Security Framework — Defender for macOS should block the cookie access through ES Framework integration d
The ES Framework provides event notifications to security tools — it does not block application behavior. MDE for macOS can detect suspicious access patterns and generate alerts, but the prevention mechanism for resource access is TCC, not the ES Framework. Section 1.8 covers the ES Framework's role as a telemetry source rather than an enforcement point.
Scenario 7. You are prioritizing endpoint security controls for a 500-endpoint environment. Threat intelligence indicates the most likely attack chain is phishing → macro → PowerShell → LSASS dump → PsExec lateral movement. Which three controls, deployed in sequence, interrupt the most phases?
ASR "Block Office child processes" + ASR "Block LSASS credential theft" + ASR "Block PsExec/WMI process creation" a
Correct. Three ASR rules address three distinct attack phases: execution (macro→PowerShell blocked at phase 2), credential access (LSASS dump blocked at phase 4), and lateral movement (PsExec blocked at phase 5). Each rule is an independent interception point — the attacker must bypass all three to complete the chain. If the first rule blocks the macro, phases 3-5 never execute. If it is bypassed, the second rule stops credential access. If both fail, the third stops lateral movement. Prevention controls provide more value than detection controls because they eliminate subsequent phases entirely. Section 1.9 covers the prioritization framework.
Sysmon deployment + PowerShell ScriptBlock logging + KAPE pre-staging b
These are forensic readiness and detection controls — they improve investigation capability but do not prevent any attack phase. The attack chain completes while generating better evidence. Prevention controls should be deployed before detection controls for the same technique. Section 1.10 covers the prevention-before-detection principle.
Credential Guard + LAPS + device isolation playbook c
Credential Guard and LAPS address phases 4 and 5 (credential protection and lateral movement), but nothing interrupts phase 2 (macro execution). The attacker achieves code execution and persistence before any control activates. The ASR Office rule stops the chain at the earliest possible point. Section 1.9 covers why earliest-phase prevention provides the highest return.
Cloud protection High+ + custom PowerShell detection rule + Sentinel analytics rule d
These improve detection but do not prevent the attack. Cloud protection may catch the downloaded payload, but if it does not, the remaining controls only detect — not prevent — subsequent phases. The attack chain may complete before the analyst reviews the alert. Section 1.10 covers why the internals-informed engineer deploys prevention before detection.
Scenario 8. Your team is writing a custom detection rule for process injection. An analyst proposes querying DeviceProcessEvents for the injected code. Why is this the wrong table?
DeviceProcessEvents only captures Windows events — process injection on Linux requires a different table a
DeviceProcessEvents captures events from all platforms where MDE is deployed, including Linux. The table choice issue is not about platform — it is about what the table records. DeviceProcessEvents records process creation, not thread creation within existing processes.
Process injection does not create a new process — it creates a thread inside an existing process, which DeviceProcessEvents does not capture b
Correct. CreateRemoteThread-based injection creates a new thread inside an existing process — no new process is created, so DeviceProcessEvents (which records process creation) has no record of the injection. The correct sources are DeviceEvents (ActionType containing RemoteThread or ProcessInjection patterns) and Sysmon Event ID 8 (CreateRemoteThread). DeviceImageLoadEvents provides complementary data — DLL injection causes a new image load in the target process that Sysmon Event ID 7 captures. Section 1.1 covers why injection operates at the thread level, not the process level.
DeviceProcessEvents is deprecated — all process data now flows through DeviceEvents c
DeviceProcessEvents is not deprecated. It remains the primary table for process creation events in MDE Advanced Hunting. DeviceEvents captures a broader set of event types including some that overlap with other Device* tables. Both tables serve different purposes and are actively maintained.
DeviceProcessEvents only captures events from MDE — Sysmon data requires a separate Sentinel table d
When Sysmon data is forwarded to Sentinel through the Windows Event Forwarding or Log Analytics agent, it appears in the Event table or SecurityEvent table — not in DeviceProcessEvents. But the table choice issue for injection detection is about what kind of OS operation injection performs (thread creation, not process creation), not about which data source populates the table.
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.