Recently, a coworker and I were discussing customer concerns. During this conversation they brought up that a potential customer had been hit with self-destructive malware multiple times. This malware, when found via their intrusion prevention system (IPS), had its connection to the command and control servers (C&C) blocked, and would reformat the system’s hard drive. That’s not good.
But this got me thinking: “What could I do to stop that from happening?”
I started making a list:
- Pretend I never heard this and walk away.
– Yeah, right. Now I’m curious.
- Tell them not to block C&C traffic at their perimeter.
– I’m not sure the company’s executive team would totally agree with “let’s just wait and see what happens.”
- Catch it, stop it, and kill it with fire.
– Yes, this option will do nicely.
So how would I do this?
My first answer would be to run Bit9 on the system in high-enforcement mode. This would prevent unapproved binaries from running in the first place, which would avoid this whole issue.
However, let’s go down the road of the company that is not running Bit9:
The questions we need to answer are:
- How do I detect this behavior?
- How do I remediate the threat?
- How do I do this without the malware reformatting the system?
- How do I make this repeatable and easy to modify for new threats?
The quick answer to all of these questions is to run Carbon Black. Carbon Black will give us the visibility we need to detect this behavior and with Carbon Black adapting some of Bit9’s key features, we can remediate the threat within this tool without the malware reformatting the system. We can also automate these steps to be easily repeatable and modularly adaptable for new threats.
Detecting the behavior
How do I get a list of known C&C servers?
These are a few examples of open-source intelligence that you can use to create your own feeds in Carbon Black to alert you of any systems in your environment that are reaching out. The primary data you are pulling from these sources is a list of IP addresses, but you could also use many different kinds of input for feeds. (Here are some details about creating feeds tailored to your environment.)
The link above is an example script that generates a CB feed from a list of data. This feed can then be imported into the console.
You can see that in the bottom left corner of the “add feed” dialog box that I have already added the Zeus tracker that I referenced above. Now, let’s make this data into actionable information.
First, I enable the feed. I also select the “log to syslog” option because my Carbon Black data is already going to my SIEM so I can create alerts in there and use my pre-existing workflow. SIEM technology provides real-time analysis of security alerts generated by network hardware, endpoints and applications. If I don’t have a SIEM or don’t want to use one, I also could create alerts in the CB console (requires checking of console for alerts) or I can have CB send me an email for every hit. I would personally choose the email option if I didn’t have a SIEM so I can be proactively alerted on hits regardless of the time or my location.
Sample malware used:
This file was downloaded via a malicious email I received to an email server I have that only exists to catch stuff like this. The email has a zip attachment that could be decompressed into a scr (the SCR file type is primarily associated with ‘Script’) file. When I opened this file up on my VM to infect it, the sample started beaconing home.
After a few minutes of beaconing home, the malware pulled down a new binary called “sdf2wd.exe” along with a few other binaries and text files that were probably also malware, but I didn’t bother checking since I had what I wanted. This binary ended up being our suicidal malware. To confirm this, I turned off the VMware network adapter and waited. Nothing happened. So I went home for the night and when I came in the following morning, the image had been nuked by the malware. Looking at my logs it looked like the malware waited about 10 hours to format the hard drive.
This confirms that my feed works. It alerted me to a binary on a system that was beaconing home to a domain the list knew about. I could duplicate these results with different samples and lists and maintain similar results each time.
Now how do I remediate without getting nuked?
The simple answer is: Carbon Black
Below is a sample of that output:
NOTE: With the most recent release of Carbon Black, once you complete step five of banning the hashes – you can skip to step seven as it is not needed. What happens under the hood is:
1. At the next check-in the sensor will receive the updated list of banned hashes
2. It will then compare the hash to all running processes and kill any process that was spawned by that hash
3. It will then prevent that executable from MD5 from running again
Until next time, remember my motto: “Flag it, Tag it and Bag it.”