July 19, 2012 1 Comment
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:
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.
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.
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.
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.
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.
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.
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!