At the bottom of this post will be the CSV file that RSA FirstWatch uses to identify known ZBot activity within our Massive Malware Database. Each IP address identified to be participating in ZBot beaconing gets added to the FirstWatch C2 IP Feeds, which is available via Live. But this feed breaks out the IP addresses into distinct variant types. It should also be noted that many IP addresses will repeat within this feed, however, these IPs have been spotted participating in multiple ZBot campaigns, sometimes simultaneously.
ZBOT BACKGROUND
It helps to understand how we detect ZBot in our environment, where we have thousands of virtualized machines chewing on different malware samples. ZBot almost always shows up on a network as an unknown protocol communicating via UDP to an unusual high port. We have automated reports that will hunt these down for us so we can include them in our feeds.
That said, we don't want to identify anything that we have already identified in the past. New and unknown is the name of the game for FirstWatch. Repeated analysis of the same malicious IP addresses would be time consuming. We really only look at traffic that is not already identified by either ourselves or one of our Threat Source partners.
Our Rule
FirstWatch uses a capture rule and Reporter rule to identify this traffic in an automated fashion. It needs to be noted here that our rule will not work in your environment unless you have already normalized all of the other service type 0 traffic on your enterprise. The rule is shown here to demonstrate our methodology.
The real crux of our hunting rule is to look for:
alert !exists && threat.desc !exists && service=0 && org.dst exists && udp.dstport exists
This means we are looking for traffic where we don't already have a predefined alert. Since all threat sources write meta to the threat.description key, and we are only looking for new and unknown traffic, we eliminate that as well. We know we are looking at unknown protocols, so service type 0 is needed. We look for the existence of a destination organization to focus on outbound traffic to a UDP destination port.
What we get are several instances of malware runs that beacon to the same IP address on the same UDP Highport. This was from Friday's report:
We notice that several internally infected hosts attempted to contact 213.203.175.12 via UDP port 3159. A simple search of VirusTotal produced this sample with similar behavior. From the bottom of the behavior tab, we see we have a match:
So chances are very likely that this traffic is ZBot related. Each IP address listed above gets added to our known C2 IP feeds. With no real agreement among AV vendors as to which flavor ZBot this might be, the FirstWatch team would typically resort to naming this threat generically along with a date stamp of when it was seen. For instance, I would call this one "Zbot 01152014."
And we would add that meta to the internal feed we use to identify known variants, whcih is what we are going to share with you now.
As you review the feed below, keep our naming conventions in mind when wondering how we came up with the name of the ZBot variant. Most are mapped back to Sophos, which seems the best at incrementing ZBot version types. Others are simply labeled with initials and a date stamp. But each IP address is known malicious.
If you implement this feed, keep in mind that it should not be a false positive if the service type is Zero via a UDP port. Go ahead and download the CSV attached below, and follow the screenshots below to upload this feed to your SA instance. As stated in our post about malicious User-Agent strings, it helps if you are indexing values on your feed meta keys.
First go to Live and Select Feeds. You want to create a new AdHoc feed. Name it Zbot Beaconing via Service Zero or something similar. Browse to find your local CSV that you downloaded from this post. If you ever want to add to this feed on your own, you simply download the file from the decoder via the download link. Click Next.
Now you pick which decoders will house your feeds. Then click next.
This is where the real configuration of the feed happens. Match yours to the one pictured. It is IP based, indexing field 1, where the values reside. The other three columns are feed.name, feed.category and feed.description.
Then click next to review, and finally click finish. The feed will push to the decoders, and will begin to populate the feed key if you have any internal infections.
In our malware environment, it looks like this:
And if it looks like this in your environment, I feel sorry for your Incident Response Team.
Feedback as always is welcome! Good luck and Happy Hunting!
