Could your organization detect malware infections if your EDR/XDR tools disappeared tomorrow? The answer for most organizations is a hard, bold, and underlined “no.” Even with their precious EDR/XDR tools, many organizations couldn’t track down malware infections past the “x process was quarantined and killed” message they receive- let alone conduct full-fledged incident response efforts. Thankfully, as long as your organization is ingesting SIEM logs, there’s a free and widely accepted answer for this problem.
Sysinternal’s Sysmon (link) is to a security analyst as a helmet is to a race car driver. While it’s not explicitly required (depending on your track), it is absolutely in your best interest to pick it up. If you’re unfamiliar with Sysmon, let me offer a TL;DR: Sysmon is a Microsoft Sysinternals tool that enhances Windows’ native logging capabilities. From process creation to DNS requests, Sysmon adds thirty new event IDs for the Windows operating system. We’ll use Sysmon, mixed with SwiftOnSecurity’s Sysmon configuration file (link), as the foundation for this demonstration’s logging efforts.
As for the malware technique we’ll analyze, let’s reference the MITRE ATT&CK Enterprise matrix (link). T1055 refers to Process Injection, a common parent technique involving injecting something into a valid process. Specifically, we’ll examine T1055.002 (Portable Execution Injection), commonly called “code injection” (link). This technique attempts to inject shellcode (compiled assembly code) into a process’s memory space and execute it. Before you click off this article exclaiming, “My EDR solution would catch something as trivial as code injection…” consider this. If Process Injection was good enough for the C2 operations of a Russian nation-state attacker in the 2015 Ukraine Electric Power Attack (link), it likely deserves another five minutes of your attention. WhitehatWays’ articles aim to empower the reader to follow along, so instead of custom coding this technique using the Win32 API, we’ll utilize a fan-favorite- Red Canary’s Atomic Red Team (link). Atomic Red Team allows analysts/security personnel to quickly and efficiently map adversarial techniques to an environment’s detection capabilities.
That was quite the long introduction, let’s get our hands dirty!
We’ll start by utilizing Atomic Red Team’s T1055-9 test, “Remote Process Injection with Go using CreateRemoteThread WinAPI.” As a quick overview, this test utilizes Golang to call native Win32 API functions, such as CreateRemoteThread, to inject malicious code into a valid process’s memory space.
If execution is successful, the text above and the Windows calculator application will appear. Let’s open Event Viewer and see what Sysmon has recorded for us. If you’re unfamiliar with the Sysmon event logs, we’ll want to monitor for any suspicious instances of event IDs 8 (CreateRemoteThread) and 10 (ProcessAccess). Locating event ID 8 shouldn’t be too tricky as not many processes natively operate this way. Below is our first clue from our atomic test:
Note: We’re purposely ignoring the event ID 1 (Process Creation) below this event for WerFault.exe as it isn’t necessarily a required step in this technique.
This event log shows us that the CreateRemoteThread.exe program (part of the atomic test) spawned a new thread from a non-standard system directory, a valuable indicator. The target PID is 8440, referencing an instance of WerFault.exe. Even if you aren’t familiar with WerFault.exe’s behavior, this should begin to raise some eyebrows.
Directly after this remote thread creation, we receive an event ID 1 (Process Creation) referencing the parent process as our victim process, WerFault.exe. The image spawned in this demonstration is the Windows built-in calculator, but this is a valuable indicator outside this example. Additionally, Sysmon provides us with the application’s working directory, several hashes for data enrichment/reference, and the command line arguments used to spawn this new process.
One more event ID could help us investigate this code injection: event ID 10 (ProcessAccess). If you’ve executed the same atomic test, you’ll notice you likely don’t see it either. The answer lies within our default SwiftOnSecurity Sysmon configuration. To prevent log overload, Event ID 10 is disabled by default. Below is the updated configuration to enable event ID 10 for WerFault.exe and the malicious process access.
<RuleGroup name="" groupRelation="or">
<ProcessAccess onmatch="include">
<TargetImage condition="is">C:\Windows\System32\WerFault.exe</TargetImage>
</ProcessAccess>
</RuleGroup>
Event ID 10 contains several key indicators for determining the validity of an action. SourceImage shows us that a non-standard path is accessing a System32 executable, GrantedAccess displays the granted permissions of the injected code (link), and CallTrace glances at the process’s memory stack. While turning event ID 10 on globally would be too verbose for an analyst to monitor, fine-tuning alerts for ProcessAccess could further an analyst’s view of a potential malware event.
While I don’t expect this quick and dirty demonstration to have you ditching your EDR/XDR provider tomorrow, it’s essential to understand how our tools work and employ defense in depth- remember that from your Security+? Ingesting Sysmon data into your SIEM enables another avenue of detection/alerting separate from your EDR/XDR and provides proper historical logs for “Lessons Learned” discussions or incident response processes. All that functionality within a free, industry-standard offering certainly makes it tough to dismiss.