Carbon Black & VMware Announce Expanded Partnership to Secure the Software-Defined Data Center (SDDC) Learn more

Partners Using Carbon Black: Combing Through Endpoint Data to Detect Threats

red canary logo Partners Using Carbon Black: Combing Through Endpoint Data to Detect Threats
Hex_Honeycomb
June 16, 2015 / Editorial Staff

(Editor’s note: This post originally appeared on Red Canary’s website. Red Canary is a Bit9 + Carbon Black partner. To learn more about our partnerships, click here.)

By Keith McCammon, Red Canary

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. Recently, 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. It is important to point out that OS-level visibility is a prerequisite for this process and is exactly why we use the Carbon Black endpoint sensor to collect that data. Every detection we send customers contains a timeline that visually details the progression of the attack–this is what I’ll be walking through. As you will see, this level of visibility makes it extremely difficult for an attacker to do something that is unseen.

(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.

rec1

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 and 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.

rec2

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.

rec3

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.

rec4rec5

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 simplest 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 enrichmentscan 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.

 

TAGS: bit9 / Carbon Black / detection / malware / Partners / Red Canary / Response / threat detection

Related Posts