Process Injection: Malware Lurking in the Shadows of Legitimate Programs (Part 2)

In part 1 of this series, we delved into a basic understanding of what process injection is and the different mechanisms by which it can be carried out. If you missed that post, you can find it here.

So what do we do about it? How do we detect this kind of activity in an environment and more importantly, how do we stop it?

Characterizing/detecting process injection

Process injection itself is action taken on a host or endpoint, so assessing network traffic will only be of use if the analyst is trying to determine whether or not the endpoint in question has any suspicious network callouts, such as communicating to a known-bad domain or IP address.

In the event that a network indicator like such is what brought the analyst to investigate the host, a simple netstat -b command is a good place to start and take a look. For additional documentation regarding netstat and its parameters, please reference the Microsoft documentation.

Running this command will show which processes have network connections and give the analyst a better idea of what process to dissect in the event that process injection is taking place. In the previous post, we opened with "explorer.exe" having an external network connection. It is usually not benign if processes such as explorer.exe, lsass.exe, csrss.exe, among others have external network connections and could be a strong indicator of an injected process.

So you found the process...

Upon identifying the process responsible for suspicious call outs, the next step would be to isolate the host and start conducting a forensic analysis of that particular process. In the event that you are already working with a memory image of the host in question (as opposed to directly on the box, which is less preferred), a command-line framework such as Volatility would offer you useful tools to further dig into your investigation. Using the "dlllist" plugin would allow you to dump all of the DLLs being loaded by the target process. If you were to identify a questionable DLL, the "dlldump" plugin would then allow you to write the DLL to local disk for further forensic analysis.

If a malicious DLL is not the culprit, using the "procmemdump" plugin will allow you to further assess the memory space of the process in order to characterize the activity.

Note that volatility is not the only memory analysis tool available on the market; a simple Google search will bring up a plethora of open-source and commercial tools that provide analysts with a broad set of capabilities to dissect memory scrapes.

Additionally, SANS provides some helpful videos from previous DFIR summits regarding the benefits of memory images for forensic analysis, one of them being linked here.

The logical train of thought when characterizing a potential process injection can be framed by the following questions, in sequence:

1) What process is responsible for this behavior/indicator of compromise?

2) Is the file hash for this process a known good or bad hash?

3) If the file hash is known good, what is causing the process to behave suspiciously?

What if a suspicious network callout isn't happening?

Notice that we framed the majority of this post around a network indicator bringing the analyst's attention to the suspicious activity. I'll admit from years of experience that, that's a somewhat generous assumption. It won't always be that easy to just point at a network indicator and say "that's bad!" like some sort of scripted (pun intended) magic trick. It may sound like a cop out, but we've transcended into an era of digital forensics and incident response to where tools and monitoring are needed to augment (not replace) the analyst's capabilities.

In order to detect process injection earlier in the cyber kill chain, you'll need endpoint detection and response (EDR) software that is able to monitor for activity such as:

• API system calls such as CreateRemoteThread() (referenced in Part 1)

• Anomalous process behavior (processes like explorer.exe, svchost.exe trying to establish outbound comms, or other processes using ports they wouldn't normally use)

• Lack of or unusual command-line arguments

A tool that can provide an additional layer of visibility into process injection is Sysmon. Sysmon is a persistent Windows system driver and provides detailed insight into process behavior. You can read more on this tool in the documentation provided by Microsoft.

Conclusion

Process injection is not a new technique in the cyber landscape, however it remains prevalent and successful because of how blind to the "naked eye" it can be. Thousands of unmonitored and vulnerable systems remain susceptible to a variety of access, installation, and persistence techniques, and process injection is not an exception.

No EDR solution is foolproof. There are blind spots within these solution that don't quite catch every process injection mechanism; however that doesn't mean that the tool itself is useless. Defense in depth by way of using several solutions (pending they don't "collide" in their detection and prevention efforts) has proven to reduce the adversary attack surface and therefore reduce the risk of an attack on an environment being successful.

Additional Reading

• Process Injection (Red Canary)

• Process Injection Detection with Sysmon (LetsDefend Blog)

• Memory Forensics for Incident Response (Video) (SANS)

• Process Injection Technique Details (MITRE)

• Case Study: Use of Process Injection by Turla Group (ESET)