ES1.13 Check My Knowledge

The ASR rule blocks the handle acquisition. Mimikatz cannot open a handle to LSASS and therefore cannot read its memory. The credential dump fails entirely. The ASR rule intercepts the OpenProcess call when the target is LSASS and the calling process is not Microsoft-signed, blocking the call before Mimikatz can proceed. An ASR block event is generated in DeviceEvents (ActionType: AsrLsassCredentialTheftBlocked) and appears in the MDE portal. The attacker must find an alternative credential access path that does not require opening a direct handle to LSASS.

Mimikatz bypasses the ASR rule because it uses SeDebugPrivilege, which overrides ASR restrictions for LSASS access.

The ASR rule allows the handle but blocks the memory read — Mimikatz opens the handle successfully but cannot call ReadProcessMemory.

The ASR rule blocks Mimikatz's executable from running — it is a file-based block, not a behavior-based block.

No — svchost.exe frequently receives remote threads from system services as part of normal Windows operations.

Yes — highly suspicious. The source image is in C:\Windows\Temp\ (an unusual location for legitimate executables) and is injecting a thread into svchost.exe (a high-value target for injection because it hosts critical services and has network access). Legitimate software that creates remote threads in svchost is rare and comes from known system locations (system32, program files), not from Temp directories. The filename "svcupdate.exe" is designed to appear legitimate but the Temp location is a red flag. Investigate: check the binary's signature (likely unsigned), check the parent process that created svcupdate.exe (likely part of an attack chain), check the MDE device timeline for related activity, and check whether the injected svchost instance is making unusual network connections (C2 beaconing).

It depends on whether the svcupdate.exe binary is signed by Microsoft — signed binaries creating remote threads is always legitimate.

Sysmon Event ID 8 generates too many false positives to be useful for detection — this event should be excluded from monitoring.

The malicious SSP DLL is loaded into LSASS at the next system boot (or immediately via the AddSecurityPackage API). Once loaded, the SSP receives callbacks for every authentication event — login, sudo, RDP, network authentication — and can capture plaintext credentials. LSASS loads the DLL because LSASS manages the SSPI interface and loads all registered SSPs from the Security Packages registry value. This is MITRE T1547.005 (Boot or Logon Autostart Execution: Security Support Provider). Detection: Sysmon Event ID 13 on the Lsa\Security Packages value modification, baseline the legitimate SSP list and alert on additions, Sysmon Event ID 7 showing an unknown DLL loaded into lsass.exe.

The SSP DLL is loaded by Winlogon as part of the logon UI — it captures credentials before they reach LSASS.

The SSP DLL replaces the Kerberos authentication provider — all Kerberos authentication on the endpoint is now handled by the attacker's code.

The SSP DLL is loaded by the Security Reference Monitor in kernel mode — it intercepts all access control decisions.

MDE retains kernel-callback-based visibility: process creation, thread creation, handle operations, and network connections observed by the kernel driver's registered callbacks. These operate independently of user-mode ETW. MDE loses ETW-based visibility for that specific process: PowerShell ScriptBlock content (captured via the Microsoft-Windows-PowerShell ETW provider), some user-mode event details, and AMSI scan results. The patching affects only the beacon process's user-mode ETW — other processes and MDE's kernel-mode observations are unaffected. The practical impact: MDE sees that the beacon process exists, creates child processes, makes network connections, and accesses files — but may not see the script content within the beacon's PowerShell invocations.

MDE loses all visibility into the beacon process because ETW is the only telemetry source MDE uses.

MDE retains full visibility because PsSetCreateProcessNotifyRoutine replaces all ETW functionality for security monitoring.

MDE detects the ETW patch immediately and generates a high-severity alert — the tamper protection feature prevents ETW modification.

This is almost certainly a privilege escalation persistence mechanism (MITRE T1548.001). A SUID binary owned by root in /tmp (a world-writable directory) executes with root privileges regardless of which user runs it. An attacker places this binary so that any compromised low-privilege account can escalate to root by executing `/tmp/.hidden/escalate`. The hidden directory name (dot prefix) is designed to avoid casual detection with `ls`. Immediate actions: (1) investigate the binary — `file /tmp/.hidden/escalate` to determine the type, `strings` to extract readable content, `sha256sum` for hash lookup. (2) Check who created it — `stat /tmp/.hidden/escalate` for timestamps, correlate with auth.log entries. (3) Remove the SUID bit immediately: `chmod u-s /tmp/.hidden/escalate`. (4) Investigate the compromised account that placed it. (5) Consider the server compromised and initiate incident response.

This is likely a legitimate administration tool that was compiled locally — check with the server's administrator before removing it.

SUID binaries in /tmp are automatically cleaned by the systemd-tmpfiles-clean service — this will be removed at the next cleanup cycle.

The SUID bit on a file in /tmp has no effect because /tmp is typically mounted with the nosuid option.

All credentials — NTLM hashes, Kerberos tickets, and cached domain credentials — because SYSTEM privileges override Credential Guard.

The LSASS dump contains limited credential material. Credential Guard moves NTLM hashes and Kerberos ticket-granting keys to the Isolated LSA (LSAIso), which runs in a separate virtual machine inaccessible from the main OS — even with SYSTEM privileges. The dump may contain: cached domain credentials (DCC2 format — crackable offline but not usable for pass-the-hash), logon session metadata, and credential material for authentication protocols not protected by Credential Guard (such as NTLM with certain legacy configurations). The attacker does NOT obtain the primary NTLM hash or Kerberos TGT — the pass-the-hash and pass-the-ticket attacks that enable immediate lateral movement are blocked. This is the value of Credential Guard: even when the attacker bypasses all other LSASS protections, the most dangerous credential material is isolated.

No credentials at all — Credential Guard causes LSASS to store an empty credential structure when VBS is active.

Only Kerberos tickets — NTLM hashes are still stored in LSASS because Credential Guard only protects Kerberos authentication.

TCC. Browser cookies are stored in locations that require Full Disk Access or specific app permissions under TCC. A signed, notarized application passes Gatekeeper (it is allowed to execute) but should not have Full Disk Access unless the user explicitly granted it. If the user did NOT grant Full Disk Access to the infostealer application, TCC blocks the cookie access. If the user DID grant Full Disk Access (clicking "Allow" on the TCC prompt), TCC functioned correctly but the user made a poor security decision. The defense for this scenario: user education about TCC prompts, MDM-managed TCC profiles that restrict Full Disk Access to approved applications only, and Defender for macOS real-time protection to detect the infostealer's behavior post-execution.

Gatekeeper — since the application was signed and notarized, Gatekeeper should have performed deeper behavioral analysis before allowing execution.

SIP — System Integrity Protection should prevent any application from accessing browser data directories.

The Endpoint Security Framework — Defender for macOS should have blocked the cookie access through its ES Framework integration.

DeviceProcessEvents + Sysmon Event ID 1. Process creation events show the injected code running as a new process.

DeviceEvents (ActionType containing "RemoteThread" or "ProcessInjection") + Sysmon Event ID 8 (CreateRemoteThread). CreateRemoteThread-based injection does NOT create a new process — it creates a new thread inside an EXISTING process. DeviceProcessEvents (process creation) would not capture it. Sysmon Event ID 8 specifically logs CreateRemoteThread calls with the source process, target process, and start address. MDE's DeviceEvents table captures related events with ActionTypes that indicate remote thread creation or process injection patterns. The detection query correlates: the source process (who is injecting), the target process (what is being injected into), and the context (is this source→target pair expected in this environment). DeviceImageLoadEvents (Sysmon Event ID 7) provides complementary data — DLL injection causes a new image load in the target process.

DeviceNetworkEvents + Sysmon Event ID 3. Network events show the injected process communicating with a C2 server.

DeviceRegistryEvents + Sysmon Event ID 13. Registry events show the injection being configured as a persistence mechanism.