Using IIS logs for fun and malware profit!

On an intrusion I was investigating last year, I was given access to IIS logs of a public facing web server that was comrpomised via sql injection and that sql injection was used as a pivot point for the intruder (more on this in another post)

I wanted to start reviewing the IIS logs so the first thing I did because the logs had a lot of encoded traffic was to run the logs through this simple python script to unqote all the logs to make it a little easier to investigate:

#!/usr/bin/env python
import urllib
log = open("/home/investigate/case111/weblogs//iislogs.txt","rb")
log_unquoted = open("/home/investigate/case111/weblogs/iislogs_unquoted.txt","wb")
for line in log:
log_unquoted.write(urllib.unquote(line))

While manually  reviewing the unquoted logs I saw a entry that contained the following:
exec master.dbo.xp_cmdshell ‘echo gg=^”4D5A … ^”_>> C:\dir\fg.vbs’;exec …

First you might see a xp_cmdshell – yup this host was vulnerable to sql injection and xp_cmdshell was enabled (yes, I know its bad but hey I was the responder don’t shoot the messenger)
You might notice that 4D5A is the hex header for the magic number of DOS Executables. To me this looked like the attacker was uploading a exe through the webserver. I wondered if we would be able to extract through the logs what the attacker uploaded.

I decided to grep for any line in the file that contained fg.vbs and write it to a text file
cat iislogs_unquoted.txt| grep “fg.vbs” > fg.vbs.txt
I then used awk to show me the 11th field of the logs which had the hex data for the exe they were attempting to upload.

cat fg.vbs.txt | awk ‘{print $11}’ > fg.txt

I then used a global search and replace in vi  to remove the following characters ^” from the begining and ^”_ from the end.
This gave me a text file full of hex, I then copied the hex and pasted it into a hex editor and saved the results as fg.exe.

I then copied fg.exe over to a vm I use for testing suspicious files. I then ran the following fg.exe /?

fg.exe usage

fg.exe usage

Looks like a password dumper lets run it with out any switches:

Results of fg.exe

Results of fg.exe

After seeing this was successful I looked for any other entries in the logs that looked like the attackers where uploaded an executable. I was able to also recover a 32 bit and 64 bit version of windows credential editor.

Being able to carve these files out of IIS logs was very helpful and eye opening and allowed us to confirm what the attacker was able to run.  Who would have known that IIS logs could be used to carve malware and not be used generally for web site usage statistics.

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.

MRI SCORE

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

Ports:

IOC Port Hit

Processes:

 Processes IOC Hit

Explorer.EXE Hit:

Explorer.EXE IOC Hit

svchost.exe Hit:

svchost.exe IOC Hit

Registry:

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 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!