StillzTech: Information Security

Github: https://github.com/tstillz/cbr-stack In this blog post, we will cover how we perform stacking using Carbon Black Response and how we can use this methodology to find anomalies in your environment. In reality, an awesome threat hunter would like to have the following data at their disposal: Type Code Details Real Time RT Real time process executions and its context Forensic FZ Live forensic data such as prefetch, appcompat, registry keys, etc.. Network NT PCAP and extracted metadata Logs LG Endpoint, firewalls, proxies, AV, Web logs, etc.. Binaries BIN Executables collected in real time or on-demand Memory MEM Real time inspection or dumping of processes/system memory For this blog post, we will focus on Real Time ( RT) process executions within Carbon Black Response. The concept of stacking is simple, we start with collecting data of the same type and choose specific fields in which we want to perform frequency analy

Github: https://github.com/tstillz/cbr-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

In my previous blog post, we covered how to extract raw network connections from real time process executions using the Carbon Black APIs. After extracting out each network connection, we enriched the network data with some GeoIP information to aid in detecting suspicious network connections. The downside to this method is you need to specify the processes you wish to analyze. This means you may miss events if you fail to specify the correct process; you also miss out on key metrics that, by themselves may point to something suspicious. Let’s take a looks at how we can use some AWS resources and the Carbon Black Event Forwarder to handle all network connections. For reference, the event schema can be found at the following link below: https://developer.carbonblack.com/reference/enterprise-response/event-forwarder/event-schema/ While the content below is far from perfect (prototyping an idea), it shows how we can use AWS resources to handle any JSON object containing an IP addre