Splunk and Malware Fun

So I was playing with Splunk at home and was curious what it looks like when you run some malware while pulling real time data into it.

The environment I set up for this test was a simple install of Windows 2008 R2 server, which has no special services running. I had it running via VMWare. As for Splunk, it's the free edition, and I have it installed locally on the machine, and have it pulling System, Application, and Security logs only.

Let's get started. First ill grab an md5 hash of the malware:

Silvrback blog image

And here is a quick check on Virus Total. As you can see 36/43 find this to be malicious. I believe it's a Zeus variant. I forgot where I downloaded it from. I believe I downloaded it from MalwareBlacklist.com

Silvrback blog image

So now that we know we are working with a piece of malware let's execute it on our system. One note: prior to executing the piece of malware I fired up Splunk and set it to monitor real-time so I could see events come across as they happened. This obviously wouldn't be as clean in "real-life", but it should allow you to identify some areas that you can go back and search for. Once I felt like the malicious program ran its course I ended the search so I had a self contained time period that I could work with, and I didn't have to keep fighting normal system activity.

One last thing. Here is the Windows 2008 R2 auditing configuration I have set. I set it all so I could capture a whole picture. I also wasn't concerned with space, etc. I don't know how you all have your environments setup. In either case, it is simply for testing purposes.

Silvrback blog image

"In God we Trust...all others we Splunk"

As you can see our first hit is event id 4688. Event id 4688 documents each program that is executed, who the program ran as. and the process that started the process. [1] You see here that melt.exe was executed and was given a process ID of 660. This makes sense given that I personally clicked on the exe file.

Silvrback blog image

Next we see another process created via the same event id 4688. You can also see that PID 660 created it, which we see in the picture below belonged to the malicious executable file. So now we have PID 660 creating PID 1820 (0x71c). It also looks like the file dropped another exe into AppData\Roaming[randomfolder][randomname.exe], which is a signature of Zeus. Zeus randomizes the folder name and .exe file.

Silvrback blog image

Let's verify that's indeed what happened. In this picture I navigated to the AppData location and it does appear a file was created.

Silvrback blog image

So within two hits in Splunk we already have an idea (in real-time) that something bad might have just happened. Let's keep moving forward so we can see how this entire process played out. It wouldn't be fun if we stopped now.

Now this next Splunk entry had me guessing so I would appreciate some feedback. I'm going to assume that this event id is the malicious program gaining SYSTEM level privledges, or maybe it just happened to execute at the same time. It seems unlikley, and I lean more towards it being malware related, but please correct me if I am wrong.

Silvrback blog image

Next we see NT AUTHORITY\SYSTEM being assigned special privileges based off its new logon from the previous picture.

Silvrback blog image

In this screen shot we see that PID 660, which was our original PID for melt.exe. It creates another PID 1506, which is a cmd.exe.

Silvrback blog image

I thought about this for a few minuets and realized when I had originally analyzed Zeus, I came across a cmd.exe prefetch. When looking at the prefetch file it appeared that the cmd.exe file executed a bat file in order to delete itself, which makes sense given that it has already moved itself over to AppData.

Silvrback blog image

What also leads me to believe that it is indeed the cmd file used to delete the original file is that right after the cmd.exe process is created the original PID 660 is exited. You can see that here:

Silvrback blog image

So if you remember from above we now have: PID 660 Creating PID 1506 (cmd.exe) and also spawning PID 1820 (owoz.exe).

Here you will see PID 1820, which is the owoz.exe file located in the AppData directory bind an IP address to a local port. The source port is 27006 and the address is 0.0.0.0.

Silvrback blog image

So right after PID 1820 (owoz.exe) binds a port to itself you get event id 5031 triggered, which occurs when windows firewall blocks an application from accepting incoming connections on the network.

Just an FYI - I was in an isolated lab. In either case, here is the image:

Silvrback blog image

So awesome....our firewall blocked it!! Well....not so fast... It made about 3 attempts and the firewall blocked it all three times, but then here came event id 5447 to rain on our parade. As you can see PID 984 (svchost.exe, which happens to be svchost.exe appears to have added a rule in our windows firewall to allow connections via port 27006. If you remember, port 27006 was the port that PID 1820 (owoz.exe) bound to 0.0.0.0. Not looking good for us...

Silvrback blog image

And this all but confirms it. Here you will see that a change was made to the windows firewall exception list. The rule to allow 27006 was added.

Silvrback blog image

So here we see another event id 5447, where owoz.exe binds itself again via port 12224.

Silvrback blog image

This entire process (bind, blocked, add firewall exemption rule) happens four times total. It does it for ports; 27006, 12224, 24463, and 13833. All of it was captured in Splunk. You should get the idea so i'll save you some pictures.So that's pretty much it for what was capture in Splunk. AS you can see there is some valuable information to be gathered and used in your environment.

I wanted to take a closer look at the svchost.exe process that's created and did all of those modifications to the firewall. I will be using Process Hacker to look at the process.

So here you can see svchost.exe running on the machine. It's PID 984.

Silvrback blog image

As you can see in red I selected the, "Handles" tab. This handle view shows which object handles belong to the process. Per the Windows SysInternals book; "Object handles are what programs use to manipulate system objects managed by kernel-mode code, such as files, registry keys, synchronization objects, memory sections, window stations, and desktops."

You can see here that we see a process named "owoz.exe", which is PID 1820. This malicious program appears to have injected itself into svchost.exe.

Silvrback blog image

Next I decided to run strings against the process via the "Memory" tab. Here are some of the results:

These strings look interesting because of the firewall changes this specific process made:

Silvrback blog image

Here are some more strings that seal the deal. We see here the location of our favorite owoz.exe (PID 1820) smack dab in the middle of our strings search.

Silvrback blog image

To bring it full circle here are the ports that were punched through our windows firewall. I viewed this via Process Hackers Network tab.

Silvrback blog image

I hope you liked this post.