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!

IOC: ZeroAccess

The other night I happened across a tweet from Ken Pryor @KDProyr saying he was looking at a system that was infected and he thinks it was using P2P based on firewall logs. Well based on some things  I had seen recently at work I thought it might be a variant of  ZeroAccess.  I quickly fired off a couple of tweets to Ken asking if it was happening over a particular UDP port and from there where I thought the malware might be. Ken quickly confirmed that the malware was indeed where I said it would be. Yah! I was excited because I had provided help to someone else in the DFIR community even if it was just a small amount of help.  I then  noticed Ken mentioned he was using Mandiant’s Redline for analysis and I thought  why not try and write an Indicator of Compromise (IOC) and see if it hits. I luckily had a recent copy of a ZeroAccess variant for me to play with to create the IOC.

Mandiant’s Ryan Kazanciyan has a great blog post about using Redline and OpenIOC to build effective indicators and I used that as a starting point for creating this IOC.

I quickly loaded up a vm and did a registry snap shot and ran the malware and waited a few minutes took another registry snapshot and rebooted to see if the malware persisted. Sure enough it did so I went and ran a Redline Audit to get an idea of what was going on and to help create my IOC.

Redline quickly showed two process that based on their Malware Risk Index (MRI) score are process I should look at and a few others that I might want to take a look at as well.


Well the first one was the actual Redline agent that I ran to create the audit after a quick review I determined it wasn’t something I should look into further. I then moved on to the second process svchosts.exe

I quickly reviewed the Malware Risk Index report for svchost.exe and noticed under the Named Sections section  a few negative factors. A few that were injected into that process and two that were not signed and they looked to be in a rather odd location.

MRI Report Negative Factors svchost.exe

I attempted to copy the n file from the image above to my local workstation for further analysis and my AV quickly told me that I was looking at a variant of Sirefef which is another name for ZeroAccess

AV Alert on malicious dll

I then moved on to looking at the file handles that svchost.exe had opened and saw a few entries all from the same c:\windows\installer directory.

svchosts.exe file handles

Nothing else stuck out to me so I moved on and took a look at what ports svchost.exe had opened and one UDP port in particular stuck out as well

svchost.exe ports listing

So far I have a pretty good list of indicators but I wanted to take a look at the Explorer.EXE process as well just to see if anything there was interesting as well and sure enough in the Named Sections there was another hit that stuck out.

Explorer.EXE Named Sections

I then decided to take a look at the detailed sections  for that hit and I looked at the Exports and saw an exported function of ?GetWindows which I thought might be a good indicator. At this point my quick analysis was done and I thought I would take a look at the registry snapshot and see if any registry keys being added or changed stuck out. I decided to search for the string  235c1d10-b0b5-289f-6f20-91dd1f9a6306 since that was unique across the processes and I came across this entry in the snapshot:

HKLM\SOFTWARE\Classes\CLSID\{F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1}\InprocServer32\: “\\.\globalroot\systemroot\Installer\{235c1d10-b0b5-289f-6f20-91dd1f9a6306}\n.”

That registry key change also matched the key specified in this Sophos blog post so I took that as another indicator to use and started building the IOC.

My inital IOC looked like this I have two extra UDP ports in my IOC based on previous cases at work that had been infected with ZeroAccess:

Initial IOC

I saved the IOC and told Redline to Create a new IOC report and a few seconds later I had hits on the Files, Ports, Process and Registry indicators I used

Original File IOC Hits

Notice something on the file hits? All of the files have a created date of 2008-04-14 12:00:00Z I know that is something that can be modified by the malware author but I thought it was unique enough I should redo the indicator to include that date for file created time.

I took a look at the file hits and I also saw the files with the name n have a PE Type of DLL so I thought I should add that as an indicator as well.  Now lets look at the other hits


IOC Port Hit


 Processes IOC Hit

Explorer.EXE Hit:

Explorer.EXE IOC Hit

svchost.exe Hit:

svchost.exe IOC Hit


Registry IOC Hit

So we know the IOC works but based on my analysis I wanted to add the File Created Date and PE Type to the IOC. Now my IOC looks like this:

New IOC with more indicators

I ran the new IOC through Redline again and this time I got more hits but only in the files section:

New IOC File Hits

As you can see we found a few extra directories that were not there previously. At this point I think I have a pretty good indicator. I sent Ken a DM on twitter and asked if he would like to run my IOC through his Redline Audit to see if it worked on his infection. A little while later he sent me the report and sure enough he had hits across all the indicators, files,ports,process,registry.Yah! Glad to know it wasn’t just working on my instance of the malware,  I then had another case at work based on network traffic that appeared to be infected. We grabbed a quick Redline audit of that system and used the IOC and sure enough we had hits there to so I think I have enough confidence in it to release it to the public. I will be posting the IOC to Mandiant’s OpenIOC Forum and to shortly and will update this post with links to the IOC once they have been published.

I hope others find this useful. If you have any feedback or suggestions for modifying the IOC please let me know.

As always happy hunting!