Skip to main content

Carbon Black Response: Mass Acquire



In this blog post, I’m releasing a tool called CBR: Mass Acquire. As the name implies, this script is used to perform mass file acquisitions on either a list of files or directories provided. To better understand this script, let’s take a look at the config.json file, which holds all the options loaded by the script.
Cb_url: The full http uri of your Carbon Black Response instance.
Cb_api: Your Carbon Black Response API token found under your user profile.
Workers: Number of threads to run to speed up acquisitions. By default, CBLR supports a maximum of 10 live response sessions at a time. I usually set the workers to 5 to ensure I don’t use up all the CBLR sessions for analysts/responders using the interface. You can tweak this setting in the cb.conf but your performance will vary.    
Output_folder: The directory you wish to save the acquired files. If the directory doesn't exist, the script will create it.
Include_endpoints: An array of sensor ID’s you wish to acquire the files from. If this array is empty, the script will assume all endpoints.
Exclude_endpoints: An array of sensor ID’s you wish exclude from the acquisition.
Acquistion_type:
  • 0: Single file acquisition (each file in the array will be acquired from each endpoint)
    • ["C:\\evil.exe", “C:\\evil.txt”, “C:\\evil.dat”]
  • 1: Lists all items in a given directory and attempts to acquire each file inside the directory (one level deep, not full recursion)
    • ["C:\\inetpub\\Logs\\LogFiles\\W3SVC1\\"]
Req_dirs: An array of either full file paths or directories you want to acquire all files from. The values in this array depend on what you’ve set acquistion_type too.
Re_dir_extras: This is a handful of JSON objects I included that contain some common file paths you may need when performing an investigation. These values are not used by the script, just extra content/examples.

For this example, i’m going to perform a mass file acquisition for the file “notepad.exe” from all endpoints. Once I add in the values for CB API and CB URL into the config.json file, I add my output folder name and set the acquisition type to 0, because i’m acquiring a specific file, not all files in a given directory. Once your config.json updated, we just run the script and watch the standard output to see its progress.
We can see from the image above, the script added a total of 42 sensors to the queue for processing. Since we only have one worker running (single worker thread) for this example, the script will only process one item at a time, and will move to the next sensor on the queue once the work is completed, failed or if the sensor is offline. If the sensor is online, the script first attempts to establish an Live Response session with the endpoint. Once a session is established, the script will then perform a get file request to the sensor. Once the CBR server has acquired the file, the script will download the file from the CBR server to your output directory and then close the live response session. To ensure we don’t overwrite the file, the acquired file is saved using the following name format:

SensorId_hostname_secondsEpoch_filePath

The image below shows what this format looks like on disk:
As stated above, we save the file to disk this way so when you acquire the same file from more than one system (or same system), it doesn’t get overwritten. After the file is saved to disk, the CBLR session is closed and the workers move on to the next sensor in the queue.

As an added bonus, I also included a nice formatter for each acquired file inside the output file artifacts.txt. I found the formatting forensic evidence to be a pain point during report writing. The formatter structures the acquisition in a simple copy/paste Markdown table inside the artifacts.txt (excluding timestamps and hostname of course). An example of this format is shown below:
The directory acquisition part of this script is also very helpful, as it will attempt to acquire everything inside a given directory. Thinking back to an attacker abusing load order hijacking, acquiring the executable will only give you part of the picture, however the naming of the DLL and/or payload could be random, so using the directory acquisition is very valuable in this scenario to ensure you get all files inside the directory. Let’s take a look at a simple use case where i’ve used this script during an engagement:  


Use Case: Lateral Movement
While performing an incident response investigation with Carbon Black Response, we quickly identified an attacker had moved laterally to at least 50+ systems using scheduled tasks and/or services. Because this incident occurred prior to Carbon Black Response being deployed, real time data wasn’t going to yield any results. The only other options were to:
  1. Pull back the task scheduler operational logs, security logs and system logs.
  2. Parse the scheduled tasks or services on disk (if they were still present on disk).
  3. Pull back additional evidence of execution such as prefetch, appcompat, amcache, registry artifacts, etc.. I usually refer to this GitHub repo if I need help recalling where items are on disk:
Because this attacker was very efficient in cleaning up, the items on disk we’re no longer present. We decided to then pull back specific event logs from all endpoints to help us scope. In the past, without scripts such as CBR-Mass-Acquire, this would have taken a lot of time due to how CBLR works and the number of endpoints involved. With CBR-Mass-Acquire, we configured the script to acquire the full EVTX logs from all endpoints and parsed them offline (usually another worker handles this in parallel, yielding the event logs in JSON format and saved to a database for searching). While this is far from the most efficient way to scope, it worked out in the end. We will discuss in our next blog post how we used another tool we wrote called CBR-Deploy to only acquire specific event IDs from specific logs using the native wevtutil binary and some XPATH filters.

I hope this script comes in use for those using Carbon Black Response. Happy Hunting!

Acknowledgements
Special thanks to Mike Scutt (@OMGAPT), Jason Garman and the CB team for all the help.

Comments

Popular posts from this blog

Revealing malware relationships with GraphDB: Part 1

In this post, we will learn how using a Graph Database like Neo4j can help visualize malware relationships and extend these relationships to identify patterns between samples. Before we dig into Neo4j, let’s start with some fundamental graph terminologies:   
Nodes represent entities such as a human, car, laptop or phone. Properties are attributes nodes can contain. A steering wheel or tires would be a property of the “car” node. Labels are a way to group together nodes of a similar type. For example, a label of “FastFood” may include nodes such as “Taco Bell, McDonald’s, and Chipotle”. Edges (or vertices) represent the relationship connection between two nodes. Relationships can also have their own properties. Getting started with Neo4jLink: https://neo4j.com/
Neo4j is a Graph Database commonly known for its pure simplicity and easy to use interface. I find the structure of a graph database quite fascinating, on top of learning how to normalize malware analysis data for each sample into a …

Analyzing and detecting web shells

Of the various pieces of malware i’ve analyzed, I still find web shells to be the most fascinating. While this not a new topic, i've been asked by others to do a write up on web shells, so here it is ;). 
For those new to web shells, think of this type of malware as code designed to be executed by the web server - instead of writing a backdoor in C, for example, an attacker can write malicious PHP and upload the code directly to a vulnerable web server. Web shells span across many different languages and server types. Let's take a looks at some common servers and some web extensions:
Operating System Service Binary Name Extensions Windows IIS (Internet Information Services) w3wp.exe .asp/.aspx Windows/Linux apache/apache2/nginx httpd/httpd.exe/nginx .php Windows/Linux Apache Tom

Introduction to Malware Analysis

Why malware analysisMalware analysis (“MA”) is a fun and excited journey for anyone new or seasoned in the career field. Taking a specimen (malware sample) and reverse engineering it to better understand its inner workings can be a long, tedious adventure. With the sheer number of malware samples circulating the internet, in addition to the various formats specimens are found in, makes malware analysis a good challenge. Outside of learning MA as a hobby, here are some other reasons why we perform malware analysis:To better understand how a specimen works. This may yield certain unique attributes about how the malware was written, methods it performs or its dependencies.To collect intelligence and build Indicators of Compromise (“IOCs”), usually comprised of Host Based Indicators (“HBIs”) and/or Network Based Indicators (“NBIs”).For general knowledge or research purposes.How do I get started?!If you’re new to malware analysis, you want to ensure you’ve taken the right precautions befor…