More ZeroAccess!

I previously posted about using Redline and OpenIOC to detect a system infected with ZeroAcces. I recently as reading through the postings on the Emerging Threats Signatures list and saw there was recently two signatures added for ZeroAcces.

2015474 – ET TROJAN ZeroAccess udp traffic detected

2015482 – ET TROJAN ZeroAccess Outbound udp traffic detected

I wondered  if these signatures would work with what the variant  I previously posted about. I decided to give it a shot and deployed the great tool SecurityOnion by Doug Burks to implement full packet capture on my esxi server. I created a new vswitch with no attached physical adapters, deployed a vm running pfSense for a firewall connected to the new vswitch and the default vswitch to gain internet access. A  Windows XP system and security onion for monitoring. This is what my ESXi layout looks like:

ESXi vswitch0ESXI Layout

Following the easy installation for security onion I was up and running in a few minutes with just a few clicks. I then decided it was time to run the malware I used in my previous post. With in a few milliseconds I had hits in the sqgil console that looked interesting.

Sguil Hits

I started to review the alerts and started with the first hit “ET Policy IP Geo Location Request” I had sguil provide me a transcript of the session and here is what was provided. Note, I have removed all the location based data in the response hence the blank fields.

GeoIP Transcript

I then looked into the “ET TROJAN ZeroAccess udp traffic detected” hit and reviewed the packet data in sguil note the highlight portion in the data section is what caused the IDS rule to fire.

ET TROJAN ZeroAccess udp traffic detected

I then went and looked at the ET TROJAN ZeroAccess Outbound  udp traffic detected, again the highlighted portion in the data field is what caused the IDS rule to fire. With in a few seconds the count for this rule was increasing and the destination ip’s were all different and continues to increase so the rule is quite noisy.

ET TROJAN ZeroAccess Outbound udp traffic detected

At this point the recent ZeroAccess signatures from Emerging Threats hit, they show a DNS query associated with the malware when first run, and the attempted communications outbound to the ZeroAccess P2P network. At this point you could say based on network evidence the system was compromised. However, you could take it a step further and use the IOC previously discussed and check the suspect system to see if there any other hits to confirm the compromise at the host level.

I decided to let the malware run a little longer and saw some other interesting hits. Obviously, the malware is involved in some click fraud.

Other interesting hits

I never used the system after running the malware I just watched and it sure looks like it was busy. Here is all the alerts it generated in sguil after running for about an hour. Note the number in the CNT column for the ET Trojan ZeroAccess Outbound UDP detected and you will see why I mentioned it was noisy.

1 hour of alerts

You could dig more into the traffic and find the click fraud traffic but that is beyond the scope of this post 🙂

As always happy hunting!


One Response to More ZeroAccess!

  1. Charles says:

    Can you please explain how you FW works to keep the malware traffic within vswitch1? Is the FW vm essentialy have two nics, one tied to vswitch0 and the other tied to vswitch1? Any insight would be great, I am trying to replicate what you are doing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: