<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Wepw — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/wepw/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Fri, 26 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/wepw/feed.xml" rel="self" type="application/rss+xml"/><item><title>LSASS Credential Dumping via Windows Error Reporting (WER) Abuse</title><link>https://feed.craftedsignal.io/briefs/2024-01-26-lsass-shtinkering/</link><pubDate>Fri, 26 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-26-lsass-shtinkering/</guid><description>Attackers can enable full user-mode dumps system-wide via registry modification to facilitate LSASS credential dumping, allowing extraction of credentials from process memory without deploying malware.</description><content:encoded><![CDATA[<p>The LSASS Shtinkering attack involves abusing Windows Error Reporting (WER) to dump the memory of the LSASS process, which contains sensitive credentials. By enabling full user-mode dumps system-wide, attackers can fake a crash on LSASS, causing WER to generate a dump file. This setting is not enabled by default and requires modifying the registry. The DeepInstinct researchers publicized this attack at Defcon 30, demonstrating a method to access credentials without directly injecting malware into the LSASS process. This technique allows attackers to bypass traditional endpoint detection mechanisms that focus on malware signatures, making it a stealthy approach to credential theft. Defenders should monitor for registry modifications related to WER dump settings to detect and prevent this attack.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker gains initial access to the system, potentially through phishing or exploitation of a vulnerability.</li>
<li>The attacker modifies the registry key <code>HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\DumpType</code> to the value <code>2</code> or <code>0x00000002</code> to enable full user-mode dumps system-wide.</li>
<li>The attacker triggers a crash or fakes a crash of the LSASS process.</li>
<li>Windows Error Reporting (WER) generates a full user-mode dump file of the LSASS process.</li>
<li>The dump file is stored in the location specified in the registry, typically <code>C:\ProgramData\Microsoft\Windows\WER\ReportQueue</code>.</li>
<li>The attacker accesses the generated dump file.</li>
<li>The attacker extracts credentials from the LSASS dump file using tools like Mimikatz or custom scripts.</li>
<li>The attacker uses the stolen credentials to move laterally within the network or access sensitive resources.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation can lead to the compromise of domain credentials and other sensitive information stored in LSASS memory, such as NTLM hashes and Kerberos tickets. This can enable attackers to move laterally within the network, escalate privileges, and access critical systems and data. A single compromised system can lead to a widespread breach affecting numerous users and systems. The sectors most vulnerable are those handling sensitive data or critical infrastructure.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &ldquo;Full User-Mode Dumps Enabled System-Wide&rdquo; to your SIEM to detect suspicious registry modifications related to Windows Error Reporting (WER).</li>
<li>Examine process execution logs to identify any suspicious processes that may have triggered the dump, especially those not matching the legitimate <code>svchost.exe</code> process with user IDs <code>S-1-5-18</code>, <code>S-1-5-19</code>, or <code>S-1-5-20</code> as described in the rule&rsquo;s investigation guide.</li>
<li>Monitor for access to WER dump files located in <code>C:\ProgramData\Microsoft\Windows\WER\ReportQueue</code> using file monitoring rules.</li>
<li>Review and update endpoint protection configurations to ensure they can detect and block credential dumping techniques as mentioned in the rule&rsquo;s response and remediation steps.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>credential-access</category><category>windows</category><category>lsass</category><category>wepw</category></item></channel></rss>