Journey Into Incident Response

The NTFS change journal ($UsnJrnl) is not a new artifact and has been discussed before by others. The file's importance may have been overlooked since it wasn’t available in Windows XP by default. As more and more systems running newer Windows operating systems cross our desks it is crucial to know about the $UsnJrnl file. This is because starting with Windows Vista and continuing into Windows 7 the operating systems use the change journal. The $UsnJrnl file contains a wealth of information about file system activity which can provide more context about what occurred on a system. The information can even counter anti-forensics techniques leveraged by malware to subvert post-mortem examinations. Read on to get reacquainted with this NTFS artifact.

What is the $UsnJrnl File?

According to the book File System Forensic Analysis, the change journal “is a file that records when changes are made to files and directories”. The change journal is located at $Extend\$UsnJrnl and the actual journal entries are stored in the $UsnJrnl:$J alternate data stream. The Windows Internals Part 2: Covering Windows Server 2008 R2 and Windows 7 book details the information contained in each entry:

     - Time of change
     - Reason for the change
     - File/directory’s name
     - File/directory’s attributes
     - File/directory’s MFT record number
     - File record number of the file’s parent directory
     - Security ID
     - Update Sequence Number of the record
     - Information about the source of the change

Others have already highlighted the $UsnJrnl file’s forensic significance. One of which was Bugbear over at the Security Braindump. In his post Dear Diary: AntiMalwareLab.exe File_Created he not only goes into detail about the $UsnJrnl file structure but he even shared how the artifact was beneficial on a case. The change journal’s significance is not limited to malware type cases; it’s relevant to any type of case where it is important to know what changes occurred to the NTFS file system. Case in point, on a fraud case the $UsnJrnl file showed how a user performed a mass deletion of financial files.

Malware Anti-Forensic Techniques

There are various definitions explaining what anti-forensics is. The one I tend to prefer is Marcus Rogers where he stated anti-forensics are “attempts to negatively effect the existence, amount and/or quality of evidence from a crime scene, or make the analysis and examination of evidence difficult or impossible to conduct”. The Rootkit Arsenal 2nd Edition goes on to explain that the goal of anti-forensics is to “minimize the quantity of useful trace evidence that’s generated in addition to ensuring that the quality of this information is also limited (as far as a forensic investigation is concerned).” Malware can leverage anti-forensics to undermine examinations conducted post mortem and live as well as against the malware itself. As it relates to post mortem examinations, two anti-forensic strategies are data hiding and data destruction; both of which can be countered using the information in the $UsnJrnl file.

Data Hiding in Obscure Location

As the name implies, data hiding is a technique to store data where it is unlikely to be found. Remember the Rootkit Paradox and the first part of the predicament; they want to remain hidden. One area malware tries to hide is in obscure locations on the system with hopes that people won’t notice it.

Some ZeroAccess Trojan variants (i.e. MD5 3dbb09aa9b6eff5a180b3412b54e9862) use the recycle bin as a hiding location. The best way to illustrate this is to use a hypothetical scenario where an IDS alert provided the lead to use when examining the $UsnJrnl:$J file. Hypothetically, let’s say an IDS alert went off around 12/14/2012 15:38 UTC for Zeroaccess Outbound UDP traffic. The $J file was parsed with TZwork’s Windows Journal Parser (command used was: jp64.exe –file $J) and the output showed the following at the time of interest:


The output shows at 15:38:30 the following items were created: $5da39e9580074308c6cfbcce61795d0d, L, U, @, and n. The $J file entries only contain file/directory names but the MFT entry can be used to obtain the full file path. The first item of interest is $5da39e9580074308c6cfbcce61795d0d and its MFT entry is 0x00000000a477 (converted to decimal the value is 42103). Locating the MFT record 42103 in the parsed $MFT showed the following:


The item’s full path was /$Recycle.Bin/S-1-5-21-2793522790-2301028668-542554750-1000/$5da39e9580074308c6cfbcce61795d0d. Correlating the MFT entries listed in the $J file for the L, U, and @ files shows they were located inside the $5da39e9580074308c6cfbcce61795d0d directory. The information in the $J file was able to reveal the hiding spot used by this ZeroAccess variant.

Data Destruction

Data destruction is a technique where data is deleted to limit the amount of forensic evidence left on a system. The technique makes it more challenging to determine what happened. Two data destruction techniques to thwart post-mortem forensics are self deleting droppers/downloaders and overwriting file system metadata.

Self Deleting Droppers/Downloaders

A dropper is a type of program when executed will install malicious components. Typically, the malicious components are embedded within the dropper itself. A downloader on the other hand is a program when executed will download and install malicious components. One anti-forensic technique leveraged by droppers and downloaders is to delete the initial executable after its done its job. By deleting the executable it removes evidence about the initial infection vector. One issue faced with self deletion is that Windows does not allow for a process to delete itself. To get around this issue malware can use a self dissolving batch script or another type of shell script. Basically, the malicious process will spawn a new shell process (such as the command prompt) and the shell process will perform the deletion. The ZeroAccess Trojan MD5 3dbb09aa9b6eff5a180b3412b54e9862 is a self deleting dropper and the image below is the portion of the $J file where the Trojan (9862.exe) was deleted.


The change journal logged the 9862.exe file being deleted followed by the cmd.exe prefetch file being modified. The most interesting thing is over time the MFT record for the 9862.exe file will be reused and the cmd.exe prefetch file will change; both of which may limit the ability to determine the 9862.exe file was self deleting. However, the change journal may still maintain entries showing what occurred on the system when other artifacts no longer do.

Overwriting File System Metadata

The timestamps stored in the NTFS metadata are crucial when trying to determine what happened on a system. The metadata includes timestamps which are used to construct a timeline of activity showing how the events unfolded that resulted in a compromise. One anti-forensic technique leveraged by malware is to overwrite the timestamps making it harder to build a timeline. The ZeroAccess Trojan MD5 b437274492e215c25f96711d04b44050 uses two different methods to over write timestamps.

The $MFT maintains two sets of timestamps for files and directories; the Standard Information (SIA) and Filename Attribute (FNA). Most times when timestamps are overwritten it only impacts the SIA timestamps leaving the FNA timestamps intact. Comparing the FNA timestamps to the SIA timestamps is an effective way to determine if timestamps have been altered. To illustrate the following are the timestamps from the file /Users/lab/AppData/Local/{5da39e95-8007-4308-c6cf-bcce61795d0d}/n

Standard Information Attribute

Creation:       7/13/2009 23:11:59 UTC
Access:         7/13/2009 23:11:59 UTC
Modification:  7/14/2009 1:17:52 UTC


Filename Attribute

Creation:       12/6/2012 22:18:00 UTC
Access:         12/6/2012 22:18:00 UTC
Modification:  12/6/2012 22:18:00 UTC

The n file’s timestamps have been altered making it appear as if the file was created and last modified back in 2009. The $J file provides another method to determine if a file’s timestamps were altered since it records when items are created. The image below shows the $J file entry when the n file was created.


As can be seen, the entry reveals the n file was created on 12/6/2012 at 22:18:00 UTC as opposed to 7/13/2009 23:11:59 UTC which was reflected in the SIA timestamp . To detect timestamp manipulation the file/directory’s creation date can be compared to its record in the $J file.

     File System Tunneling

When I was looking at the artifacts associated with the ZeroAccess Trojan levering the NTFS Extended Attributes I quickly noticed how the malware altered its files’ timestamps. I even found the activity in the $J file showing the services.exe file being modified. However, the activity didn’t become clear until I shared the $MFT file with Harlan. Harlan was parsing the $MFT file when he noticed the Trojan used file system tunneling to alter the services.exe timestamps. Jason Hale over at The Digital Forensics Stream post File System Tunneling in Windows does an outstanding job demonstrating how file system tunneling works. Microsoft’s explanation about file system tunneling in Windows is to:

“enable compatibility with programs that rely on file systems being able to hold onto file meta-info for a short period of time. This occurs after deletion or renaming and re-introducing a new directory entry with that meta-info (if a create or rename occurs to cause a file of that name to appear again in a short period of time).”

File system tunneling means if a file is renamed or deleted and then if a file with the same name is created in the same directory then the new file will retain the timestamps from the old file. The $UsnJrnl file contains entries showing file system tunneling was used and this is what became clear after Harlan told me what he saw.


The entries show that the original services.exe file was renamed and within a fraction of a second a new services.exe file was created in the same directory. As shown below the new services.exe file retained the timestamps from the original:

Standard Information Attribute

Creation:       7/13/2009 23:11:26 UTC
Access:         7/13/2009 23:11:26 UTC
Modification:  7/14/2009 1:14:36 UTC


Filename Attribute

Creation:       7/13/2009 23:11:26 UTC
Access:         12/6/2012 22:18:06 UTC
Modification:  12/6/2012 22:18:06 UTC

Both the SIA and FNA timestamps indicate the services.exe file was created back in 2009 but the entries in the $J file shows otherwise. The services.exe was actually created on 12/6/2012 and file system tunneling was used to alter its timestamps.

Summary

The $UsnJrnl file contains a wealth of information about file system activity and its worthy for us to re-introduce ourselves to this artifact. This re-introduction shouldn’t be viewed in the same light as when Jay Z reintroduced himself. Jay Z was saying he was the top MC when he said “allow me to re-introduce myself. My name is Hov’, OH, H to the OV”. The $UsnJrnl is only one of the available NTFS artifacts; it’s not even the only artifact that logs file system activity. The $Logfile is another NTFS artifact with entries recording activity. David Cowen has been releasing information about the $Logfile and the program he wrote to parse it. A few posts include: Updates and DFIR Conferences discussing what the NTFS $Log Parser is and PFIC 2012 Slides & Bsides DFW containing a link to his slide deck where he breaks down the $Logfile. I highly recommend reading what David posted if you haven’t already. The $Logfile is another artifact that contains a wealth of information. The limited testing I did showed it contains information which wasn’t present in the $MFT and $UsnJrnl files. And vice versa about the $UsnJrnl compared to the $Logfile and $MFT. To get an accurate picture about file system activity then all the artifacts ($MFT, $Logfile, and $UsnJrnl) should be examined. Combining the information inside each artifact will counter anti-forensics techniques leveraged by malware to thwart post-mortem examinations.

Tools are defined as anything that can be used to accomplish a task or purpose. For a tool to be effective some thought has to go into how to use it. I have a few saws in my garage but before I try to cut anything with them I first come up with a plan on what I’m trying to accomplish. Timeline tools are no different and their usage shouldn’t solely consist of running commands. The post Building Timelines – Thought Process Behind It discusses an approach to develop a plan on the way timeline tools will be used. This post is the second part where the tools to build timelines is discussed.

There is not a single tool for building timelines since tools vary based on the DFIR practitioner’s needs and preferences. When I first started learning about timeline analysis I read as much as I could about the technique and downloaded various tools to test their capabilities to see what worked best for me. I’m discussing my current method and a few tools that I build timelines with. The method is different from what I was doing last month and will probably change down the road as tools are updated, new tools are released, and my needs/preferences vary.

I’m trying to show different ways timelines can be built in addition to building my own timeline for an infected Windows XP SP3 test system. The artifacts selected for my timeline are:  event logs, Internet Explorer history, XP firewall logs, prefetch files, Windows restore points, select registry keys, entire registry hives, and the file system metadata. The user specific artifacts (ie history and registry keys from the NTUSER.DAT hive) only need to be parsed for the administrator user account. The extraction of the timestamps from those artifacts will be accomplished in the following activities:

        -  Artifact Timestamps
        -  File System Timestamps
        -  Registry Timestamps

Tools’ Output

Before a timeline can be created one must first choose what format to use for the tools’ output. Selecting the format up front ensures multiple tools’ outputs can go into the same timeline. Three common output types are: bodyfile, TLN, and comma-separated value (csv). The bodyfile format shows file activity and separates the output into different sections. The version in use will determine what the sections are but the Sleuthkit Wiki bodyfile page explains the differences and provides an example. The TLN format breaks the data up into five sections: time, source, host, user, and description. Harlan provided a great description about his format in the post Timeline Analysis...do we need a standard? and in Appendum for the post TimeLine Analysis, pt III. The csv format stores data so it is separated by rows and columns. This format works well for viewing the timeline data in spreadsheets. However, unlike the bodyfile and TLN formats csv is not a standard format. The csv schema from tools may differ resulting in the need for additional processing for the outputs to go into the same timeline. Kristinn’s post Timeline Analysis 201 – review the timeline explains the csv schema used in his Log2timeline tool.

I mostly review timelines with spreadsheet programs so I opted for Log2timeline’s csv format. I use Log2timeline to convert other tools’ outputs into proper csv schema. My timeline in this post uses the csv format and I demonstrate how to convert between different formats.

Artifact Timestamps

I couldn’t come up with a good name when I was thinking about how to explain the different activities I do when creating timelines. What I mean when I say artifact timestamps is everything expect for the last write times from dumped registry hives and timestamps from the file system. The different tools to extract timestamps from artifacts include Harlan’s timeline tools and Log2timeline. Harlan accompanies his tools posted on the Win4n6 yahoo group with a great step by step guide about building timelines with his tools. I cover how to use Log2timeline and the following is a brief explanation about the tool’s syntax:

log2timeline.pl -z timezone -f plugin/plugin_ file -r -w output-file-name log_file/log_dir

        -z defines the timezone for the computer where the artifacts came from
        -f specifies the plugin or pluging file to run against the file/directory
        -w specifies the file to write the output to
        -r makes log2timeline work in recursive mode so the folder specified and its subfolders are all examined for artifacts

Options to Extract Timestamps with Single Plugin or Default Plugin File

Log2timeline is plugin based and the tool can execute a single plugin against a single file/directory or execute a plugin file against multiple files in directories. I prefer to use custom plugins for my timelines but first I wanted to show the single plugin and default plugin file methods. The command below will execute the evt plugin to parse the Security windows event log and the output will be written to a file named fake-timeline.csv.

log2timeline.pl -z local -f evt -w fake-timeline.csv F:\WINDOWS\system32\config\SecEvent.Evt

The single plugin method requires multiple commands to extract timestamps from different artifacts in a system. Plugin files address the multiple command issue since the file contains a list of plugins to run. Log2timeline comes with a few default plugin files and the best one that fits my selected artifacts is the winxp plugin file. The command below runs the winxp plugin file against the entire mounted forensic image (the red text highlights what is different from the previous command).

log2timeline.pl -z local -f winxp -w fake-timeline.csv –r F:\

The winxp plugin file makes things a lot easier since only one command has to be typed. However, the file parses a lot more data then I actually need. The plugins executed are: chrome, evt, exif, ff_bookmark, firefox3, iehistory, iis, mcafee, opera, oxml, pdf, prefetch, recycler, restore, setupapi, sol, win_link, xpfirewall, wmiprov, ntuser, software, and system. I only wanted to parse IE history but winxp is doing every browser supported by log2timeline. I only wanted to parse artifacts in the administrator’s user profile but the above command is parsing artifacts from every profile on the system. I wanted to limit my timeline to specific artifacts but winxp is giving me everything. Not exactly what I’m looking for.

Single plugins and default plugin files are viable methods for building timelines. However, neither let’s me easily build a timeline containing only my selected artifacts that were tailored to the case and system I’m processing. This is where custom plugin files come into play and why I use them instead.

Extracting Timestamps for my Timeline with Custom Plugin Files

Kristinn deserves all the credit for why I know about the ability to create custom plugin files. I’m just the guy who asked him the question and decided to blog the answer he gave me. A custom plugin file is a text file that lists one plugin per line and is saved with the .lst file extension. The picture is a custom file named test.lst and it contains plugins for prefetch files, event logs, and system restore points.

Custom Plugin File Example

The custom file is placed in the same directory where the default plugin files are located. On a Windows system with Log2timeline 0.60 installed the directory is C:\Perl\lib\Log2t\input\.

I only want to parse artifacts in the administrator user profile instead of all user profiles stored on the system. At the time I wrote this post, Log2timeline doesn’t have the ability to exclude full paths (such as unwanted user profiles) when running in recursive mode. As a result I create two custom plugin files; one file parses the artifacts in a user profile while the other parses the remaining artifacts throughout the system. This lets me control what user profiles to extract timestamps from since I can run the user plugin file against the exact ones I need.

The user custom plugin file is named custom_user.lst and contains the iehistory and ntuser plugins. The other custom plugin file is named custom_system.lst and contains the evt, xpfirewall, prefetch, and restore plugins. The two commands below execute the custom_user.lst against the administrator’s user account profile and custom_system.lst against the entire drive while saving the output to the file timeline.csv.

log2timeline.pl -z local -f custom_user -w C:\win-xp\timeline.csv –r “F:\Documents and Settings\Administrator”

log2timeline.pl -z local -f custom_system -w C:\win-xp\timeline.csv –r F:\

Timeline Data Added by Custom Plugin File

Timeline Data Added by fls.exe

Timeline Data Added by $MFT

Timeline Data with Registry Keys' Last Write Times

Excel 2007 Sort Feature

Finally

As I’m writing the first paragraph of a paper for my Masters of Science program the only thought that keeps running through my mind is finally. I finally reached not only the last week of class but the last week of my master’s program. In a few days I will finally complete the MSIA program when I submit my paper and my experience -not the knowledge- will gradually become a distant memory.

The second thought to run through my mind was everything on my to do list. My list has been piling up over the months and one of the more recent items on the list is the lack of my blog posts over the past few weeks. This will hopefully change once I’m done with school and a few of the future posts will cover some of the things I’m looking at including Java vulnerability exploit artifacts, my introduction to log analysis, and possibly a new crime scene camera that people are putting into their homes.

In the meantime here are a few links about timelines.

Timeline Analysis Links

Kristinn has an excellent post about analyzing timelines which can be found here. I previously blogged about reviewing timelines with Excel (post is here) and Calc (post is here). I created the timelines using mactime and redirected the output to a csv file which I then imported into Excel. Kristinn approaches analyzing timelines with Excel a different way. Kristinn mentioned that filtering is not optimal with mactime and Excel so he uses the CSV output module in log2timeline to create the timeline. One of the limitations I found with Excel was the limit on the number of variables you can filter on using basic filters (Calc had a higher limit but it was still only eight variables). This was one of the reasons I looked into using advanced filters, Kristinn's approach is really interesting since the CSV module breaks up the description field which makes it easier to filter on using basic filters. His write-up is very informative and educational. Trying out this approach has been added to my to do list. Kristinn, thanks again for the write-up and sharing this information.

One of the downsides to being state public sector employee – especially for New York state- is the lack of funds to attend trainings and conferences. This is the main reason why I like when speakers share their conference presentation slides since it lets people who couldn’t attend the conference (aka me) to see some of the presented material. Mandiant posted their DoD Cyber Crime 2011 presentations and one of them was Rob Lee’s Super Timeline Analysis presentation. My biggest take away from Rob's slides was his research on the Windows time rules (I was already familiar with the other content in the slides since I read Rob's post on the SANs forensic blog about supertimelines and volume shadow copy timelines). The Windows time rules (slides 15 and 16) outline how the timestamps in the Standard Information Attribute and Filename Attribute are changed by actions taken against a file. For example, you can see the difference between the changes to a file's timestamps when it is moved locally as compared being moved to another volume. The charts are a great reference and thank you Rob for sharing this information.

My previous post explained why I incorporated timeline analysis into the examination of the Infected 2 system.

I created a supertimeline to help answer the second question of how did the system become infected. My examination of the timeline focused on the creation and last modified dates in order to simulate a real security incident because the last access times may not be accurate depending on the time that elapsed between the initial infection and the examination. (I doubt I will be able to preserve a system at the exact moment of infection similar to the tests I conducted). In addition to the timeline, I used Guidance Software's Encase to hash and perform a file analysis on all of the files on the system in advanced of examining them. I also used Encase to examine any files identified in the timeline.

How the system became infected?

The examination of volatile data identified the following in the Infected 2 system: rogue aaclientt.exe process, 612835656.dat opened by aaclientt.exe, svchost process with an injected DLL, and a rogue 75622830.exe process. I examined the timestamps of aaclientt.exe and 75622830.exe files in order to get a starting point to begin the timeline review. The picture below shows the timestamps for aaclientt.exe.

The arrows in the picture are highlighting a time discrepancy between the Standard Information Attribute (SIA) date creation time and the Filename Attribute (FNA) date modification time. This is an indication the timestamps could have been changed on the aaclientt.exe program. I used Lance Muller's enscript to compare the two timestamps as can be seen below.

The timeline shows on line 163833 the 75622830 folder was created at the same time as the 75622830.exe file. Continuing to work backwards, the next file created on the system is named 612835656.dat, which occurred at 03:20:13PM (line 163831). The memory examination identified that the aaclientt.exe process had this file opened. 612835656.dat was examined on the system but the contents only showed a few characters.

The next few lines (163831 to 163828) show a few registry entries being modified. The HKLM\System\ControlSet001\Services\TapiSrvALG was examined and the value name display name contained the data Telephony TapiSrvALG while the imagepath value name contained the data C:\WINDOWS\system32\aaclientt.exe srv. This service seems very similar to the Telephony service which contains the data Telephony in the display name value name. This registry key is the persistence mechanism for aaclientt.exe which starts the program as a service. Line 163827 shows a prefetch file being created at 03:20:08PM for a program named _ex-68.exe. The analysis of the system did not locate a file by this name. Another prefetch file, for wpv901264679855.exe, was modified and last accessed at 03:19:59PM (line 163824). The last line I will discuss in this picture is the creation of aaclientt.exe's prefetch file at 03:19:57PM which is shown on line 162822. At this point in the examination, aaclientt.exe's persistence mechanism was identified and there is evidence of various programs being executed on the system in addition to the aaclientt.exe and 75622830.exe programs.

The picture below is the next section of the timeline.

Lines 163821 to 163817 show evidence of more programs being executed on the system but the wpv901264679855.exe prefetch file (line 163820) is the same one mentioned from line 163824. Think back to the time discrepancy involving aaclientt.exe which indicated the timestamps may have been modified. Line 163813 shows the MFT modification of 03:19:48PM for the file aaclientt.exe and this was the real time the file was created on the system. The MFT modification time can still reveal files of interest even if the files' timestamps have been stomped on. At this point in the examination, additional programs that executed on the system have been identified and the aaclientt.exe program, which was identified in the memory image, was located.

The picture below is the continuation of the timeline.

Line 163811 shows the first unknown program, wpv901264679855.exe, was created on the system at 03:19:44PM. Wpv901264679855.exe's prefetch file was referenced on lines 163820 and 163824. This file was uploaded to Virus Total and the detection rate on 04/10/10 was 38 percent. Line 163808 shows the next unknown program, wpv791264677196.exe, was created on the system at 03:19:44PM. The examination of this file revealed it had the same hash as aaclientt.exe, which means wpv791264677196.exe and aaclientt.exe are the same file. Line 163807 shows another unknown program, wpv351269312857.exe, was also created on the system at 03:19:44PM. This file was uploaded to Virus Total and the detection rate on 04/10/10 was 25 percent. Line 163806 shows a log file was created on the system but the examination of this file determined the file's signature was invalid and the contents were only a few characters. Line 163804 shows aaclientt.exe was last accessed at 03:19:35 while line 163803 shows another unknown program, e.exe, executed on the system one second earlier (the examination did not find any files by this name on the system). Line 163802 shows the Administrator user account's Startup folder was modified at 03:19:34PM. The examination of the Startup folder identified a program named mgjwin32.exe. This file had a discrepancy between the SIA date creation time and the FNA date modification time. Similar to the aaclientt.exe program, mgjwin32.exe's timestamps were modified so the creation date appeared to be 08/04/04 08:00:00AM. The timestamp comparison showed the real creation date of the mgjwin32.exe file was 03:19:34PM. Lastly, this file had the same hash as the file ~TM4.tmp which is on line 163801. The file's extension indicates it is a temporary file but the file signature analysis determined the file is an executable. ~TM4.tmp was uploaded to Virus Total and the detection rate on 04/20/10 was 70 percent.

At this point in the examination, three of the unknown programs (wpv901264679855.exe, wpv791264677196.exe, and wpv351269312857.exe) that were executed on the system were located and confirmed as malicious. Also, wpv901264679855.exe and aaclientt.exe are the same file. Mgjwin32.exe was another program identified as malicious and this program's persistence mechanism is the Administrator user account's Startup folder. The ~TM4.tmp file is an executable and is the same file as mgjwin32.exe.

The picture below is the continuation of the timeline.

So far the examination has identified various pieces of malware on the system but these files do not directly relate to the question of how the system became infected. At 03:19:32 there was a MFT modification for a PDF file, gla[1].pdf, located in the Administrator user account's Temporary Internet Files folder (line 163800). I used Didier Stevens PDF tools to analyze this file but for this post I am using a link to Virus Total since the website uses his tools. The gla[1].pdf Virus Total report showed the detection rate on 04/10/10 was 25 percent and a Javascript is executed when the file is opened (refer to the picture below).

The gla[1].pdf file was uploaded to Wepawet to help determine if the file was malicious. The gla[1].pdf Wepawet report confirmed the file was malicious. The report identified the two vulnerabilities being targeted were CVE-2008-2992 and CVE-2009-0927, and the payload requested three websites involving hxxp://googlecounter.cn/web/load.php?id=. The next line, 163799, in the timeline shows the file gla[1].pdf was downloaded to the system from the hxxp://googlecounter.cn website. The image below shows the administrator account was used to access this website at 03:18:08 (line 163783).

I infected this test system back in April by visiting a malicious website using the Administrator user account. I obtained the website from the Contagio post March's malware links. I knew ahead of time about the malicious PDF since it was indicated next to the URL but I didn't know what the outcome was going to be when I visited the website. The examination of the Infected 2 system's volatile data and hard drive helped me understand what this outcome was.

Conclusion

The files located in memory were used as the starting point to examine the activity on the system. The examination worked backwards in time and the image below shows all of the evidence located during the examination. Not only does the image show all of the evidence identified but it also shows the activity after the 75622830.exe file was created on the system. (Note: 75622830.exe uses HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run as its persistence mechanism)

The examination of Infected 2 covered all of the initial examination steps except one which was the examination of the executable files of interest. The next blog post will examine the importance of this step and why it may be needed to fully answer the question of how the system became infected.