Skip to main content

Carbon Black Response: CBR Chrome

Github: https://github.com/tstillz/cbr-chrome 

 In this blog post, I’m releasing a Chrome extension I wrote to help responders and analysts perform quick lookups on key information in Carbon Black Response such as a hostname, ip address, mac address, binary name, md5 hash and a binaries internal name. The results are returned in a nice scrollable results pane. I’ve used this tool during many engagements to quickly research what the hostname or IP address was of a given asset accessed by an attacker. This extension is far from perfect but it’s very simple and extensible. Feel free to modify as you see fit. 

 To install the Chrome extension, go to chrome://extensions in your chrome browser address bar and ensure Developer mode is enabled:
After you update the config.json file with your Carbon Black Response URL and API token (found under your Profile > API Token page), you can load CBR-Chrome extension clicking the Load Unpacked button. This will bring up a dialog box. Locate the extensions directory on your system and click Select. If successful, you should see the following extension show up in your extensions list.
Once loaded, you should also see an icon in the top right corner of your browser.


 Inside the input box, you can type in any hostname, ip address, mac address or even parts of an ip/mac address or hostname to see all matching items. The image below shows a partial hostname search.  
 

Next, we show a partial ip address search below.

I also added in the ability to search key binary terms, currently limited to md5, name and internal (binaries internal name). The images below show an example for each search prefix.




I hope this extension is helpful 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

Post a Comment

Popular posts from this blog

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 Tomcat* tomcat*.exe/tomcat* .jsp/.jspx Web shells 101 To better understand web shells, let’s take a look at a simple eval web shell below: <?php
Post a Comment
Read more

Web shell hunting: Meet the web shell analyzer

 In continuation of my prior work on web shells ( Medium / Blog ), I wanted to take my work a step further and introduce a new tool that goes beyond my legacy webshell-scan tool. The “webshell-scan” tool was written in GoLang and provided threat hunters and analysts alike with the ability to quickly scan a target system for web shells in a cross platform fashion. That said, I found it was lacking in many other areas. Allow me to elaborate below… Requirements of web shell analysis In order to perform proper web shell analysis, we need to define some of the key requirements that a web shell analyzer would need to include. This isn’t a definitive list but more of a guide on key requirements based on my experience working on the front lines: Static executable: Tooling must include all dependencies when being deployed. This ensures the execution is consistent and expected. Simple and easy to use: A tool must be simple and straightforward to deploy and execute. Nothing is more frustrating
Post a Comment
Read more

RDP Over Tor

Happy Tuesday, everyone! Recently, I encountered a threat actor leveraging Tor to establish Remote Desktop Protocol (RDP) sessions from a victim system to an attacker-controlled server. The best part of this is, because the threat actor was using Tor, all encrypted communications were sent over port 443. Therefore, there wasn’t any evidence of RDP (port 3389) being used on the network illegitimately. In fact, we could have closed port 3389 on their firewall and the attacker would have still had access to the system via RDP. I found this very sneaky by the threat actor, but realized how simple it was to configure it and thought I would share it with everyone. In this blog post, we will cover the basics of proxying RDP traffic over TOR and how to set it up, with tips to avoid being detected. Before We Get Started For those of you who are unfamiliar with Tor, it’s a free and anonymous network that provides anonymity when browsing the Internet. Also known as “The Onion Router”, user
Post a Comment
Read more