IEF and Google Translate Browsing History

In working a recent forensics investigation for Sibertor, I ran into something I hadn't noticed before - Google Translate URLs.  I ran into these while sifting through Internet Evidence Finder (IEF) output from the hibernation file pulled from the image of my subject's primary machine. As usual, IEF carved some really cool gmail fragments, rebuilt facebook pages and Internet browsing history.  Since the subject worked at an organization that required a great deal of translating as part of his daily job, a good chunk of the Firefox browsing history was Google Translate URLs.  It really was cool to see exactly what was being translated in the URL. As an example, and sadly not related to the investigation, here is one of my favorite conversations translated to Malay (Hello to my friends in Malaysia!):

http://translate.google.com/#en/ms/Justin%20Bieber%20threw%20up%20on%20stage

Since it was relevant to my investigation, I paid special attention to the language that the text was being translated to - in this example the "ms" stands for malay.  In my case, "it" was used to translate the text by the user to Italian.  What is also notable here, and a point of interest to some, is that unlike Google searches, which have been sent encrypted by default for logged in users since October 2011 and all users since September 2013, the Google translations requests are sent in the clear, regardless of whether a user is logged in.

This is good stuff - definitely something that relates to our employee investigations module in SANS FOR526: Windows Memory Forensics In-Depth. The application of memory forensics in employee investigations have yielded some serious wins for me and it sounds like other internal forensics teams are pulling memory more frequently as well. 

Case Closed: Memory-Only Analysis

I recently presented the SANS@Night “Have No Fear, DFIR is Here” with Rob Lee, Chad Tilbury & Lenny Zeltser at SANS CDI.  The premise of the four-examiner presentation was to analyze and properly scope the involvement in the Stark Research Labs(SRL) intrusion of the “Natasha Romanoff” Windows 7 x86 system.  This scenario is known quite well by FOR508 alumni who have served as members of the SRL CIRT during the Day 6 Challenge. In FOR526: Windows Memory Forensics In-Depth, we take memory analysis a step deeper, diving into Windows Memory Structures in order to understand how the tools work and how to extract smoking guns from a system memory image.  My goal during my 20 minutes of presenting with the “All-Star Forensics Team” was to prove to my fellow instructors (and @Night attendees) that I didn’t need their file system forensic analysis at all.  In fact, all of the questions pertaining to the intrusion and this system’s involvement could be answered through the analysis of the memory image. 

Our mission: Determine the initial vector of infection for the Romanoff system, find all malicious code present on the system and show signs of execution.  In addition, we were asked to answer the typical questions customers asked in an incident response scenario, “What credentials were compromised?” “How did they get in and how long have they been here?” and of course, “What did they take?”. 

Most digital forensic examiners know of the Volatility Framework, an open source python project supported by a forward-leaning team of developers.  Yet, there are other tools we can bring to bear while performing memory analysis.  I included Mandiant’s Redline, Simson Garfinkel’s Bulk Extractor and page_brute in my tool arsenal, as I unraveled the story of the Romanoff machine in the SRL intrusion. 

Process Enumeration

We cover a six-step process in malicious process identification in our FOR526 Windows Memory Forensics In-Depth class that begins with process enumeration.  By running through a couple of Volatility plugins “pslist” and “psscan”, I identified some curious processes.

 love pslist output purely for the reason that it is chronological – great for doing fast timeline analysis of what took place on the system since that last reboot.  We can see from this pslist output that:

1.) Based on the “Start Time” for the System/SMSS.exe Processes, the system last rebooted at 2012-04-04 11:47:29 UTC.

2.) With two csrss.exe processes (PIDs 412 & 2132) seen in this output, we can ascertain there were two active sessions at the time the image was created (specific to Windows 7 & later).

3.) With the start of the explorer.exe process (PID 296), we know a user logged into the system at 2012-04-04 14:45:45 UTC.

4.) With the presence of rdpclip.exe (PID 2408), we know that this logon was a remote desktop session via terminal services.

5.) A quick hierarchical analysis (Parent/Child surveying), we can identify some potentially anomalous processes to include:

            a.) svchost.exe processes (PID 3612 & 6404) whose PPID is 2100 – not expected since svchost.exe is typically spawned by services.exe (PID 564).

            b.) PSEXESVC.EXE (PID 2100) – notable due to the fact that it is the parent of the late starting svchost.exe, but also typically associated with the execution of psexec, the SysInternals tool used for remote execution.

            c.) terminated processes, a.exe (PID 3264 &  5008) & spinlock.exe (3796 & 1208)

Of course, our next step in this analysis, seen in the next blog post, will be to further investigate each notable process, attempting to enumerate the process parameters, to include identifying the command line (how each process was instantiated). 

We will continue the domination of the digital forensics world via memory in the next few posts.