<?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>Windows Error Reporting — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/windows-error-reporting/</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/products/windows-error-reporting/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><item><title>Potential Windows Error Manager Masquerading</title><link>https://feed.craftedsignal.io/briefs/2024-01-werfault-masquerading/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-werfault-masquerading/</guid><description>Adversaries may masquerade malicious processes as legitimate Windows Error Reporting processes (WerFault.exe or Wermgr.exe) to evade detection by establishing network connections without arguments, thus blending into normal system activity.</description><content:encoded><![CDATA[<p>Attackers may attempt to evade defenses by masquerading malicious processes as legitimate Windows Error Reporting (WER) executables, specifically <code>WerFault.exe</code> or <code>Wermgr.exe</code>. These executables are responsible for handling application crashes and reporting errors to Microsoft. This technique involves launching these executables without command-line arguments and then establishing outgoing network connections. By mimicking the behavior of legitimate WER processes, adversaries can potentially bypass detections that focus on suspicious child process activity or command-line arguments, effectively blending their malicious network activity with normal system operations. This technique has been observed in conjunction with malware campaigns, highlighting the importance of detecting deviations from the expected behavior of WER processes.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to the system through an unspecified method.</li>
<li>The attacker deploys a malicious payload onto the compromised system.</li>
<li>The attacker executes <code>WerFault.exe</code> or <code>Wermgr.exe</code> without any command-line arguments. This is an attempt to mimic legitimate WER process behavior.</li>
<li>The masquerading WER process initiates an outgoing network connection to a command-and-control (C2) server. The specific protocol used is not specified.</li>
<li>The C2 server issues commands to the compromised system through the masquerading WER process.</li>
<li>The attacker executes malicious commands on the system, potentially including data exfiltration, lateral movement, or further payload deployment.</li>
<li>The attacker attempts to maintain persistence on the compromised system, potentially through registry modifications or scheduled tasks.</li>
<li>The attacker achieves their final objective, such as data theft, system disruption, or establishing a foothold for future attacks.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A successful masquerading attack can lead to a prolonged period of undetected malicious activity. Victims may experience data breaches, system compromise, and potential financial losses. The targeted systems could be incorporated into a botnet, used for cryptocurrency mining, or further exploited for lateral movement within the network. The lack of command-line arguments makes detection more challenging, allowing attackers to operate with a lower risk of detection.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Monitor process creation events for instances of <code>WerFault.exe</code> or <code>Wermgr.exe</code> executed with a single argument and an unusual command line, using the &ldquo;Potential Windows Error Manager Masquerading&rdquo; Sigma rule to detect such events.</li>
<li>Investigate network connections originating from <code>WerFault.exe</code> or <code>Wermgr.exe</code>, especially when the process is launched without arguments.</li>
<li>Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging to provide the necessary data for the Sigma rule.</li>
<li>Correlate process creation and network connection events to identify suspicious sequences, as outlined in the attack chain.</li>
<li>Implement network segmentation to limit the potential impact of compromised systems and restrict lateral movement.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>defense-evasion</category><category>masquerading</category><category>windows</category></item></channel></rss>