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.
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
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.
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
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.
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:
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:
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
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
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:
I ran the new IOC through Redline again and this time I got more hits but only in the files section:
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 forensicsartifacts.com 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!