StillzTech: Information Security

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

Github: https://github.com/tstillz/cbr-timeliner Incident Response is a challenging career. As responders, we must do our best to keep up to date with the latest attack trends, malware and forensic techniques. Throughout my career as a responder, i’ve had the privilege to use many third party solutions to aid in responding. One of these solutions i’ve spent the last 3+ years working with, developing new tools and push the limits of has been Carbon Black Response. A few main reasons this is possible is due to their awesome developer network and their extensive APIs, including documentation. As a responder, time is everything. From the moment you get a phone call at 2am about a customer being compromised, to the first indicator of compromise identified. Being able to respond quickly, at scale without melting endpoints while ensuring data integrity and security are a must with any IR toolset. It is because of these reasons I write scripts that leverage the CBR APIs to aid in my respo

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