APTish Attack via Metasploit – Part Two – Splunk

Welcome back for Part II where I will cover a bit of log analysis using a Splunk's cloud based SIEM solution.

I'm going to assume you have read Part I of this series.

I decided to write the Splunk log analysis section before I dive into memory or file system forensics because chances are you're not going to dump memory or take a hard drive image if you don't suspect something in the first place. You're more than likely going to see something "suspicious" via your logs, and then go investigate further.

Logon Activity

  • EventID=4624 ProcessName="*winlogon.exe" |table _time, TargetUserName, IpAddress2, LogonType

We see here that the user logged into the machine interactively based on the logon type 2. It was logged in locally from its IpAddress, the Username was malware_win7x86, and it looks like they logged in a couple times. Once at 8am and once at 10:32, maybe after a reboot.

Silvrback blog image

Windows Firewall   * host=hostnamegoeshere EventID="502" OR EventID="503" NOT EventID="5038" NOT EventID="5039"

This is a quick one that I will sometimes do. The windows firewall logs run from 5020 - 5037, which is why I filtered on 5038 and 5039. I knew this wouldn't produce any firewall results, but I wanted to run it anyway. I didn't have windows firewall running at the time.
  Recent Executions

  • host=hackingwin7 LogType=WindowsEventLog (EventID=4688 OR EventID=592) NewMD5="True" Recent="True" |dedup BaseFileName | table CreatorProcessName,BaseFileName,NewProcessName,Signed,MD5

I highlighted some items below that are interesting after running this search. I like to run this search to see what kind of things were executed recently. You would be surprised at some of the stuff you will find. You will also get good at filtering "normal" activity so you can reduce the amount of hits you have to go through. I left out the filters as not confuse people.

In this case we found some interesting stuff while looking at our victim box. These should pop out at you really quickly. If you have been around computers you should realize that these aren't common processes, with the exception of svchost.

Silvrback blog image

More Details

Here we will take a deeper look at the executables we found in our recent execution search.


The creator process for 7za.exe was notepad? That doesn't make sense. It also shows that 7zip is located in C:\Windows\System32, which doesn't make sense either considering that I didn't have 7zip on this machine (proper configuration management is a smart thing to do), and the fact that the 7zip standalone console doesn't install itself to System32 by default. Not mentioning the fact that it's a standalone version, which shouldn't install itself period.

  • 7za.exe |search NOT isnull(CreatorProcessName) |table BaseFileName,CreatorProcessName,FileDescription,Signed,CompanyName

Not much new here from the recent executions query we ran above. It just shows us that it was run more than once, and by multiple creator processes. This is something to keep in mind.

Silvrback blog image


I also like to take a look at exe files that are executed from TEMP directories. In this case we found tior.exe. I searched Google with the tior.exe md5 has, and luckily I got a couple hits referencing Win7Elevate [2]. I then found a reference to TIOR on a metasploit bitbucket site. [3]

Here is the portion of code on the bitbucket site where I found it referenced, "Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TIOR", "TIOR\TIOR.vcxproj", "{B36517F4-984C-422C-ADF9-85D5ACD4E30B}""

It also makes reference to Win7Elevate, which is used to bypass Windows User Access Control (UAC) [4].

Other than that there was only one mention of tior.exe in the entire set of 10,091 logs.

Maybe we can find out more about this when we start looking at memory forensics. Maybe it's still located in the temp directory as well and we can extract it from the HDD image if we can't get a working copy of the process dumped from memory.

Looking at AntiVirusUpdate2012.exe should raise some flags. We can see that the creator process was Explorer, which makes sense after validating the NewProcessName section and seeing that it was launched via the Desktop.

  • * AntiVirusUpdate2012.exe

I did a general search of all the logs for "AntiVirusUpdate2012.exe" so I could quickly figure out when the application was first run. I highlighted a couple things here since it's a bit messier than the other ones.

Silvrback blog image

Let's now run a more specific search on the time frame and back up a couple minuets so we can see if we can figure out how this piece of software got onto the system.
I ran this first because I wanted to get an idea of what happened a few minuets before the AntiVirusUpdate2012.exe was executed. We can see from above the process exited around 0949.
This is telling Splunk to give us everything between these two time constraints. This will help us narrow things down even further.

  • * earliest="11/14/2012:09:42:15" latest="11/14/2012:09:50:00"

This second search is to reduce the noise a bit:

  • * NOT isnull(Application) NOT isnull(DestAddress) earliest="11/14/2012:09:30:15" latest="11/14/2012:09:50:00" |search NOT DestAddress=""| search Application="*iexplore.exe" |dedup DestAddress |table _time,Application,DestAddress,DestPort

Here is another way to reduce the noise and get a clear picture as to what's going on here (send me an email if you want the XML code for this):

Silvrback blog image

This is a filtered down search using only DestAddress="", which we identified above that it's communicating quite a bit over port 443. 443 communication isn't suspicious in itself  but it is a malware favorite, and when it's coupled with some suspicious looking executables it's worth it to take a closer look.

You can see how we are further reducing the overall data-set down to specific ports and specific ip addresses. There is such a thing as too much information.

Silvrback blog image

And then this third query brings it all home and gives us something to really work with:* |search DestAddress="" |dedup Application |dedup DestPort |table _time,Application,DestAddress,DestPort

As you can tell this is a "smoking gun" rolled up into four lines. This gives us a decent timeline of events.

  • User going out to via port 80
  • AntiVirusUpdate2012.exe talking back to via 443
  • svchost.exe talking back to via port 8043
  • We see hotdfs.exe talking back via port 4444.

Silvrback blog image

Another interesting thing is we found a couple more items that I didn't originally consider to be suspicious off the bat. We will have to review them in more detail with memory analysis and/or file system forensics. The svchost.exe and the hotdfs.exe executable might be malicious. You will see here the point I mentioned above about being able to see the command line information.

  • hotdfs.exe | table CreatorProcessName,BaseFileName,CommandLine,DestAddress,DestPort,MD5

Silvrback blog image

Obviously we have more to look at with this. Looking at this in conjunction with the $MFT will help I think.


Although not malicious by itself it is interesting to see notepad.exe create the 7za.exe process so we will look at this in a bit more detail later. It's quite possible that malware was injected into that process. Memory analysis well help with this one hopefully (later post).

  • notepad NOT isnull(CommandLine) |table _time,CommandLine

Here we see notepad creating some files. This seems like user activity, but we will keep this in mind.

Silvrback blog image


Based on the logs I reviewed it's safe to say that we need to review this box in more detail. Specifically memory and the file system. I will have two more posts. Part III will be Memory forensics and Part IV will be file system forensics.

If you want a copy of these logs let me know and I can send you a Dropbox link to them. That way you can play along if you care to.


[1] http://www.sophos.com/en-us/threat-center/threat-analyses/adware-and-puas/Win7Elevate.aspx [2]https://bitbucket.org/jrossi/metasploit/src/aaff79eaa6f4/external/source/exploits/bypassuac/Win7Elevate.sln?at=default [3]http://technet.microsoft.com/en-us/library/cc709691(v=ws.10).aspx [4]http://msdn.microsoft.com/en-us/library/windows/hardware/gg463267.aspx [5]http://community.spiceworks.com/scripts/show/1071-powershell-dns-reverse-lookup-script-using-system-net-dns-object