Signature Detection with CrowdResponse

CrowdResponse is a free tool written by Robin Keir from CrowdStrike. Robin has a long history of developing excellent tools for the community including SuperScan, BinText, Fpipe, and CrowdInspect. The goal of CrowdResponse is to provide a lightweight solution for incident responders to perform signature detection and triage data collection. It supports all modern Windows platforms up to Server 2012 and is command-line based making it easy to deploy at scale. Version 1.0 focuses on signature detection, with a powerful YARA scanning engine. It ships with a very detailed user manual but since only a few actually read such things, I thought it would be interesting to show the tool in action.

Running YARA Scans

YARA, or Yet Another Regex Analyzer, has become one of the leading tools for describing and detecting malware. A YARA rule consists of a series of strings tied together by a Boolean condition. It facilitates searching with text, hex, Unicode, wildcards, case-insensitivity, and regular expressions. Combining these options allows construction of complicated tests to limit false positives. As an example, consider this YARA rule:

        

rule CrowdStrike_Shamoon_DroppedFile
{ meta:
description = “Rule to detect Shamoon malware.”
strings:
$testn123 = “test123” wide
$testn456 = “test456” wide
$testn789 = “test789” wide
$testdomain = “testdomain.com” wide
$pingcmd = “ping -n 30 127.0.0.1 >nul” wide
condition:
(any of ($testn*) or $pingcmd) and $testdomain
}

In preparation for the Hacking Exposed “Day of Destruction” talk at RSA 2014, our team was playing with all kinds of destructive malware and thought it would be fun to attempt Shamoon detection using CrowdResponse. This particular YARA rule identifies the malware dropper. After pasting the rule into the CrowdResponse config.txt file (you can also point to a folder or URL containing rules), we executed the following command line:

CrowdResponse -v -i config.txt -o “%ip%_%nm%_%tm%.xml”

A scan of a system infected with Shamoon returned the output in Figure 1.

Shamoon Dropper

Figure 1: YARA signature detection on a file and process named trksrv.exe

Note that we received two hits for the same file: trksrv.exe. The first is a result of a YARA hit for the file located in the C:\Windows\system32 folder. The second alert is a result of memory scanning, identifying a hit within process ID 788. This is a key point – the CrowdResponse YARA module facilitates scanning of both files and processes in memory. Specifically, the @yara plugin can:

    • Scan all running processes
    • Scan on-disk image binaries
    • Scan loaded DLLs
    • Scan arbitrary files and folders
    • Limit scanning by regular expression
    • Download rules from a URL and use rule masks to limit selections

You may recall that Shamoon is famous for rendering its victims unusable. The payload consists of a wiper that proceeds to overwrite user profiles, system directories, and ultimately the disk MBR. You can see several of the wiper targets in this next YARA rule.

rule Crowdstrike_Shamoon
{ meta:
description = “Rule to catch Shamoon version A wiper.”
strings:
$del1 = “dir \”C:\\Documents and Settings\\\” /s /b /a:-D 2>nul | findstr -i download 2>nul >f1.inf”
$del2 = “dir \”C:\\Documents and Settings\\\” /s /b /a:-D 2>nul | findstr -i document 2>nul >>f1.inf”
$del3 = “dir C:\\Users\\ /s /b /a:-D 2>nul | findstr -i download 2>nul >>f1.inf dir C:\\Users\\ /s /b /a:-D 2>nul | findstr -i document 2>nul >>f1.inf dir C:\\Users\\ /s /b /a:-D2>nul | findstr -i picture 2>nul >>f1.inf dir C:\\Users\\ /s /b /a:-D 2>nul | findstr -i video 2>nul >>f1.inf dir C:\\Users\\ /s /b /a:-D 2>nul | findstr -i music 2>nul >>f1.inf dir \”C:\\Documents and Settings\\\” /s /b /a:-D 2>nul | findstr -i desktop 2>nul >f2.inf”
$del4 = “dir C:\\Users\\ /s /b /a:-D 2>nul | findstr -i desktop 2>nul >>f2.inf dir C:\\Windows\\System32\\Drivers /s /b /a:-D 2>nul >>f2.inf”
$del5 = “dir C:\\Windows\\System32\\Config /s /b /a:-D 2>nul | findstr -v – isystemprofile 2>nul >>f2.inf”
$del6 = “dir f1.inf /s /b 2>nul >>f1.inf dir f2.inf /s /b 2>nul >>f1.inf”
$del7 = { 64 69 72 20 22 43 3A 5C 44 6F 63 75 6D 65 6E 74 73 20 61 6E 64 20 53 65 74 74 69 6E 67 73 5C 22 20 2F 73 20 2F 62 20 2F 61 3A 2D 44 20 32 3E 6E 75 6C}
condition:
($del1 and $del2 and $del3 and $del4 and $del5 and $del6) or $del7 }

Shamoon does a good job of destroying the operating system, and you would typically only detect this signature on a system where something prevented the malware from successfully executing. In Figure 2, we see this rule hit for a file named msinit.exe.

Shamoon Wiper

Figure 2: YARA signature hit on msinit.exe

Gathering Additional Information

Once you have detected signature matches on a given system, the next step is to verify those hits. The CrowdResponse modules @pslist and @dirlist provide detailed information on a system’s files and running processes. A subset of their capabilities follows.

@pslist

  • List all processes
  • Collect PE header data
  • Verify digital signatures
  • Hash image binary
  • Provide command line
  • Show loaded DLLs
  • Identify imports/exports
  • Detect code injection

@dirlist

  • Recursive file list with regex masks and recursion limits
  • Verify digital signatures
  • Compute MD5/SHA256 hashes (quick hash capable)
  • Collect resource info
  • Timestamp collection (Standard Information)

Since you may only get one shot at volatile data collection, I recommend running these plugins at the same time as the @yara plugin. While all options are available for use on the command-line, a configuration file allows for more granular data collection and simplifies running multiple modules (see Figure 3).

Config File Example

Figure 3: Sample configuration file for CrowdResponse

CRconvert

CrowdResponse returns output in XML format, making it easy to manipulate into whatever form you desire. Depending on the number of systems and modules employed, it can return a healthy amount of data. The first three modules released (@yara, @pslist, and @dirlist) have 40 different output options and nearly 100 possible data points. CRConvert builds CSV and HTML reports from this output. As an example, the command below converts native XML output into a series of HTML reports:

CRconvert  -v  -h -f .xml

Figure 4 shows the HTML version of the output returned by the YARA module.

YaraReport

Figure 4: HTML output for @yara module showing three hits

In this example, it appears two files and a process on the system JIMMY278F hit on two different YARA rules. Looking at the CrowdResponse @pslist report provides further information on the suspect process including PID, binary size, command line, threads injected, PE information, etc.

Pslist Report

Figure 5: @pslist module providing details for suspicious process

Finally, we can use the @dirlist report to learn more about the files identified via the YARA scans. Here we can see file size, timestamps, digital signature verification, hashes, and more. The information provided by @pslist and @dirlist should be more than enough to validate YARA signature detects and make a determination as to whether it is necessary to acquire memory or disk images of the system.

Dirlist Report

Figure 6: @dirlist module providing details for file identified by YARA

Next Steps

CrowdResponse provides some excellent capabilities in its first version. This post serves as only a brief introduction to its capabilities. There are many other options under the hood such as lowering CPU priority, uploading output files via SSL, and a self-destruct mechanism that solve particular issues in enterprise deployments. It has a modular design and CrowdStrike plans to continue building and releasing new capabilities for the tool. If you have feedback, questions, or feature requests, please post them in the online forum.

Note: This post originally appeared on the SANS Forensics blog