19 11 2012

Welcome back for Part II where I will cover a bit of log analysis using cloud based SplunkStorm logging system.

I’m going to assume you have read the first post in this series. If not, you can find it here. This will give you a frame of reference as to where I am going with this.

INTRO:

I decided to write the Splunk log analysis section first 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.

The key to log analysis is to review them often. It sounds easy, but people simply don’t do it. I’ve heard of companies that “punish” people by making them review logs if they are late for work. That’s not good if that’s the stance you take on log analysis. It should be looked at as something important. Something that you want to do because you want to find the bad guys. Something you try to make better each week.

Automation you ask? Sure, I use automatic alerting all the time. If you don’t you’re crazy. However, I also have a set of queries that I run manually. I try not to let more than 2 days go by without personally looking through my manual search results. The automated ones are running in realtime 24/7.

One thing to note is that I have full auditing enabled on this victim box. Some people argue that it’s not possible to do this in an Enterprise environment and I partly agree. Sure, it might not be possible to run full auditing on all 1k – 10k+ client machines, but you can’t tell me it’s not possible to run full auditing on the servers that house your company secrets.

Protect the important stuff REALLY well, and treat everything else like collateral damage. In all seriousness, it’s unreasonable to assume you will keep 100% of your systems from being owned. As long as you keep 100% of the most critical systems safe then you should be, ok. Or…at least better off.

In either case, let’s get started. The Splunk searches are in red.

LOGON ACTIVITY:

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

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.

I use a custom logging agent that does some nice things. It will take an md5 of any process that’s executed, keep records of that so I can see if a process has been executed using multiple md5 hashes, which might or might not raise alarms. I can see if an exe has been executed in more than one located, which might or might not be common for malware after it executes. For instance, if you execute malware on the desktop and then it moves itself into the system32 folder. I can also verify whether or not an executable that executed was signed. I also have the capability to see the command line that was used to execute the process. These are all very important indicators when doing log analysis. Unfortunately I don’t think basic Windows logs are enough these days. You should create your own logging agent, or use something like Carbon Black in addition to windows event logs. I did a blog post about CarbonBlack here. It’s cheap too.

A MORE DETAILED LOOK AT EACH OF THE “SUSPICIOUS” EXECUTIONS:

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

7ZA.EXE: 
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

TIOR.EXE: 
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.

ANTIVIRUS_UPDATE_2012.exe: 
Looking at AntiVirus_Update_2012.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.

* AntiVirus_Update_2012.exe

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.

This is telling Splunk to give us everything between these two time constraints. This will help us narrow things down even further.

* NOT isnull(Application) NOT isnull(DestAddress) earliest=”11/14/2012:09:30:15″ latest=”11/14/2012:09:50:00″ |search NOT DestAddress=”127.0.0.1″| 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):

This is a filtered down search using only DestAddress=”192.168.81.128″, 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.

And then this third query brings it all home and gives us something to really work with:* |search DestAddress=”192.168.81.128″ |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.

First we have the user going out to 192.168.81.128 via port 80 -> Then we have AntiVirus_Update_2012.exe talking back to 192.168.81.128 via 443 (known communication channel for malware) -> Then we have svchost.exe talking back to 192.168.81.128 via port 8043 -> Lastly we see hotdfs.exe talking back via port 4444.

Splunk and Metasploit, Splunk Windows Security

APTish Attack via Metasploit – Part One of Four APTish Attack via Metasploit – Part III – Memory Analysis