Combing Through Endpoint Data to Detect Threats

I’m always combing through detections that we produce in search of exemplars. My tendency is to look for unique malware, attack vectors, or lateral movement techniques. Today I encountered a detection that at a glance is far from novel—commodity crimeware delivered via email as a .scr (Windows screensaver) file—but is actually a terrific example of the power of endpoint telemetry for threat detection.

We’ll look at the sequence of events flagged by Red Canary’s Threat Detection Engine and confirmed by our analysts. Alongside each I’ll highlight some of our observations as well as opportunities that exist to detect each stage of the attack. Every detection we send customers contains a timeline that visually details the progression of the attack—this is what I’ll be walking though.

A note about terminology and process: When I say “what we detect” I am calling out actions that our engine explicitly flags as potentially threatening and for analyst review.

Delivery

Archive files are used as an obfuscation layer, keeping the malicious payload at least one step removed from filtering or antivirus systems. This process of origin is noted for the benefit of the customer, to provide a complete accounting of the software leveraged during the course of the attack.

How we detect attacks at this stage:

• Compression utility execution. This can be noisy, but we strongly prefer this level of visibility because of the frequency with which malicious payloads are packaged within archives. These events are more useful for context than detection, but their correlation to other process-level events makes for compelling detection and efficient analysis.

Exploitation & Installation

Here we observe the first stage being extracted and executed. The .scr extension is associated with a Windows screensaver file, which is conveniently a Windows Portable Executable (PE). We actually have a number of detection opportunities here.

How we detect attacks at this stage:

• Newly observed binary. If a binary file—executable or otherwise—unknown to Red Canary is observed being written or executed on an endpoint, we want our analysts to take a closer look. Again, this can be noisy, but is the most effective backstop against previously unseen tools. To aid decision-making, our engine subjects every new binary to a battery of analysis tools and processes.
• Execution from a user space path. Because many users can execute anything within %APPDATA% without tripping User Account Control (UAC), binaries and their corresponding processes are always scrutinized.
• A process derived from a file with something other than a .exe extension. This happens from time to time, and .scr files are one of several legitimate use cases. However, the frequency with which extensions are obfuscated makes these worth a look.

Persistence

After gaining execution, the second stage is dropped and a reference to this file placed within a registry key to provide persistence.

What we detect at this stage:

• Newly observed binary. Again, because chrome.scr is unique based on its hash.
• Use of a persistence mechanism. There are a number of persistence mechanisms available, and this case one of the many registry-based run keys is used. There are over 150 such keys, to say nothing of the various file system paths into which a shortcut can be placed. We monitor them all.

Action: Exfiltration

We already keyed in on chrome.scr as it was written. Upon execution, we see it leverage the trusted system process svchost.exe.

It’s important to note that we now have two pieces of malware executing, having bypassed mail filtering mechanisms and up-to-date antivirus. While these samples have since made their way into the public domain* (not through us, as we do not share customer data with third parties), at time of detection neither our intelligence holdings nor any antivirus vendor identified these files as malicious.

What we detect at this stage:

• Execution from a user space path.
• A process derived from a file with something other than a .exe extension.
• Untrusted process with child process svchost.exe. The svchost.exe process is trusted implicitly by the operating system, and is thus a favorite of malware authors when they need outbound communications. Whenever this sequence of events occurs, we want to know.

What we detect at this stage:

• svchost.exe with untrusted parent process. This is the inverse of the condition above. In theory this is duplicative, and that’s fine with us.
• Suspicious IP address based on threat intelligence. Taken on its own, a malicious domain or IP can be difficult to disposition analytically. However, when married with process-level context, these data points can corroborate other findings or provide some level of attribution.

As this illustrates, a number of detection opportunities exist at each stage of even the most simplistic attack. Attackers are rapidly evolving and reliance on a narrow set of behaviors or signatures will eventually break down. This is countered by looking at every available element in a comprehensive set of endpoint data. Some of the inspection criteria will be narrow, but it is also critical that systems be designed to look efficiently at very broad criteria as well (i.e., analyze and then show me every new binary that appears within my environment).

To deliver this depth of detection, three things are needed:

1. Visibility: We rely on Carbon Black as our sensor of choice and you should, too! Product plug aside, this methodology can be applied to any system where this level of process activity is captured.
2. Modeling & Correlation: Many of the potentially threatening events we detect occur frequently in the course of normal system operation. It is only when modeled with  additional context and enriched that some of these benign events become high specificity indicators of suspicious or malicious activity.
3. Feedback: Analysts must have a means through which events including context and enrichments can be abstracted, codified and used to either prioritize or suppress future occurrences. The importance of doing this well cannot be understated, as without a feedback mechanism the analyst is quickly fatigued, and detections missed. The Red Canary team has nearly two years of statistics on what context and intelligence is useful to make accurate and timely decisions, and we are merely scratching the surface in terms of process optimization.

How exactly we do this, by incorporating a variety of technologies and processes, is for another post entirely—or a quick demonstration if you are interested in learning more. Until then, good hunting and may the Schwartz be with you . . .

*First stage with MD5 054d3d728876c4ce0e2792ac082a6171 via VirusTotal. And the second with MD5 755fb1f428a78174ac8c2388f63b39bc via VirusTotal as well.