Houston We’ve Had a Problem – Wow64

This is a piggyback post to an issue Harlan has been raising about the Wow64 issue. His most recent post on the subject Wow64Node: Registry Redirection goes into detail about what Wow64 is, it’s impact on registry analysis, and contains links to great resources. After giving some thought to this issue I’m in full agreement with Harlan when he said “this is huge”. Computing is moving on from 32-bit to 64-bit platforms. I am already witnessing the transition since the majority of the systems I see running Windows 7 are 64-bit. We are entering a 64-bit world and as this transition occurs systems will run both 64-bit and 32-bit applications. This is where Wow64 comes into play and I wanted to follow up Harlan’s post with a few more examples about why we should be aware about this issue. I’m not only expanding on what Wow64 is but I’m highlighting issues with our processes and tools to demonstrate why this is an important issue.

What Is Wow64

In addition to the links provided by Harlan, the Windows Internals book contains information about Wow64. It states “Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permits the execution of 32-bit x86 applications on 64-bit Windows”. Part of the emulation involves redirecting a 32-bit application in both the file system and registry.

Windows Internals states the following about file system redirection:

“To maintain application compatibility and to reduce the effort of porting applications from Win32 to 64-bit Windows, system directory were kept the same. Therefore, the \Windows\System32 folder contains native 64-bit images. Wow64, as it hooks all the system calls, translates all the path-related APIs and replaces the path name of the \Windows\System32 folder with \Windows\Syswow64. Wow64 also redirects \Windows\LastGood to \Windows\LastGood\syswow64 and \Windows\Regedit.exe to \Windows\syswow64\Regedit.exe. Through the use of system environment variables, the %PROGRAMFILES% variable is also set to \Program Files (x86) for 32-bit applications, while it is set to \Program Files folder for 64-bit applications."

The file system redirection occurs transparently when a 32-bit application tries to access the System32 or LastGood folders. Something similar happens when 32-bit applications access the registry. Windows Internals mentions:

“the registry is split into two portions: Native and Wow64. By default, 32-bit components access the 32-bit view and 64-bit components access the 64-bit view”. “To implement this, Wow64 intercepts all the system calls that open registry keys and retranslates the key path to point it to the Wow64 view of the registry. Wow64 splits the registry at these points: HKLM\Software and HKEY_CLASSES_ROOT”. “Under each of these keys, Wow64 creates a key called Wow6432Node. Under this key is stored 32-bit configuration information. All other portions of the registry are shared between 32-bit and 64-bit applications (for example, HKLM\SYSTEM)."

The Win32 emulation on 64-bit Windows impacts our DFIR work because there are now additional locations we need to know about and examine. If we don’t Christian Wojner sums up the end result when he said

“In the worst case this can lead to an entirely wrong interpretation of a case/situation”

Wow64 Impact on Our Processes and Tools

Wow64 is one of the topics that have not been discussed extensively within our community. Harlan has been on his soapbox trying to raise awareness about its impact on our work and he provided examples how it affects registry analysis. Both Christian Wojner in his paper The “Wow-Effect” and Lenny Zelster in his post Incident Response on 64-Bit Windows Using 32-Bit Tools highlighted the impacts of file system redirection. Basically, the authors were demonstrating that an analyst may not be getting the whole picture when running 32-bit applications on a 64-bit system. The 32-bit applications were redirected to the \Windows\Syswow64 folder and were incapable of seeing the files located in the Windows\System32 folder. The “Wow-Effect” paper mentioned there are more situations and scenarios where the “Wow-Effect” can impact DFIR. He even suggested the reader could instantly come up with a lot more scenarios. I came up with a few and they impact: live, malware, and post-mortem analysis.

Wow64 Impact on Live Analysis

Both of Christian and Lenny's articles illustrated the Wow64 issue when performing live analysis. Wow64 introduces another wrinkle when performing live analysis besides running 32-bit executables on a 64-bit system. Indicators of Compromise (IOCs) are becoming more mainstream within enterprise environments. It appears more and more people are trying to leverage IOCs to determine if their organization is compromised. The wrinkle Wow64 throws into the process is on the way people use IOCs. IOCs are written by an author based on their systems and their environment. If a user downloads an IOC and runs it in their environment without knowing about the author's environment then the user may reach a false conclusion if the IOC performs a file and registry check.

There are very few public IOCs on the Internet. To illustrate my point I selected the publicly available Skyipot/Wyksol Trojan IOC. The IOC does a check on the following key:

Registry Path contains SOFTWARE\Microsoft\Windows\CurrentVersion\Run

If a user were to download this IOC and run checks against a 64-bit system they may encounter an issue and not even know about it. The Run key in the IOC is either for a 32-bit Skyipot/Wyksol Trojan on a 32-bit system or a 64-bit Skyipot/Wyksol Trojan on a 64-buit system. If a 64-bit system was infected with a 32-bit Skyipot/Wyksol Trojan then the Run key of interest will be located underneath the HKLM\ SOFTWARE\Wow6432Node. The current registry check in the Skyipot/Wyksol IOC will miss it. As more and more organizations start to use IOCs it will be critical for them to make sure they are using IOCs that are compatible with their 64-bit/32-bit environments. Otherwise the IOCs won't be as effective as they should be.

Wow64 Impact on Malware Analysis

Practical Malware Analysis defines malware analysis as "the art of dissecting malware to understand how it works, how to identify it, and how to defeat or eliminate it". At times when reversing malware dynamic analysis is performed to see how the malware behaves as it executes. This is an excellent technique to identify what changes are made to the system such as file creation or registry modification. The intelligence gained by identifying these changes can be used to write IOCs, provide others will indicators to look for, or to perform checks on other systems to determine if they are infected. The Wow64 issue comes into play when doing malware analysis; both if it is done using an online service or your own platform.

Online malware analysis services provide an easy method for people to perform dynamic analysis on a piece of malware. There are numerous free online services to choose from and I randomly selected ThreatExpert. Unfortunately, a good number of these services don’t provide detailed information about the systems the malware executes on so the information they provide may not be complete. To illustrate let’s use the Wow64 issue to see what we can find out about the systems on ThreatExpert. The Run key I mentioned before (it’s also the same one Harlan mentioned) is a popular location for malware to maintain persistence on a system. Searching the ThreatExpert site shows numerous malware reports with this registry key (Google search had 10,400 results). Now let’s search for the same key but taking Wow64 into account by searching for this key.

SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

The Google search resulted in two hits; seriously only two hits. This demonstrates the majority of the ThreatExpert analysis is not running 32-bit malware on a 64-bit system to reveal all artifacts. ThreatExpert is not the only service where this occurs; happens at Anubis (419 Google Results vs. Zero Google Results) and antivirus sites such Symantec (8,800 Google Results vs. Zero Google Results).

Side note: to perform the Google search use the site: operator to point it at the website. My attempts to included the links to the search results didn't work.

Wow64 has the same impact on those who perform malware analysis themselves as opposed to online services. Are 32-bit malware being executed on 64-bit systems? If not, then the end result will be similar to the antivirus and automated analysis sites.

Wow64 Impact on Post-mortem Analysis

Harlan did an outstanding job highlighting the impact Wow64 has on registry analysis. There are a lot more autostart locations beneath the Wow6432Node then just the Run key. These locations are not getting parsed by numerous registry analysis tools. From open source tools to really expensive software such as the one that starts “En” and ends in “Case” (I’m running v6.X). Side note: as Harlan mentioned RegRipper is getting updated to account for Wow64. There are other important registry keys that have a 32-bit equivalent beneath Wow6432Node that has nothing to do with malware or autostart locations.

One of my initial steps in any case is to profile the system to get a better understanding about what I’m facing. One of the areas I consider when profiling is the installed software on a system. It tells me a lot about what type of data and artifacts I should expect. Harlan mentioned in a previous post how the Uninstall key beneath the Wow6432Node contained references to software not listed in the 64-bit Uninstall registry key. Well, I just looked at my system and I’m seeing the same thing. If I don’t take into account the Wow64 issue when profiling a system then I won’t see the complete picture.

Summary

Despite how the phrase is constantly misquoted: “Houston, we have a problem”. The proper quote and one that more closely resembles the Wow64 issue is “Houston, we’ve had a problem”. As in past tense, as in the problem has already occurred. The Wow64 issue is a significant problem and in the near future it will only become worse as the computing environment continues to move from the 32-bit to 64-bit world. Those of us who are aware about Wow64 can adjust to account for this when faced with 64-bit systems. Those who aren’t aware; well the misquote will apply to them. They will have a problem and it could lead them to “an entirely wrong interpretation of a case/situation.”

In closing, I wanted to say thank you to Harlan. Thanks for being consistent with trying to bring this issue to the forefront and making the community more aware about its significance.

Read More

NTOSBOOT Prefetch File

Knowing the programs that executed on a system can answer numerous questions. The answers can help on a range of cases from acceptable use policy violations to investigations to intrusions to malware. One program execution artifact is prefetch files which have been well documented including in the article Decoding Prefetch Files for Forensic Purposes and on the Prefetch Wiki page. The purpose of this post is to explore the NTOSBOOT prefetch file and how it is relevant for malware investigations.

What is the NTOSBOOT Prefetch File

The Windows operating system enables prefetching to make system boots or applications startups faster. Windows Internals, Part 2: Covering Windows 2008 Server R2 and Windows 7 states “the prefetcher tries to speed the boot process and application startup by monitoring the data and code accessed by boot and application startups and using that information at the beginning of a subsequent boot or application startup to read in the code and data”. Prefetch files are what store the information required for faster startups.

The NTOSBOOT prefetch file stores the information related to the boot process. The information in this prefetch file reflects the files accessed during system startup. Specifically, the files accessed, according to the Windows Internals, “from system start through the 30 seconds following the start of the user’s shell (typically Explorer) or, failing that, up through 60 seconds following Windows service initialization or through 120 seconds, whichever comes first”.

Relevance for Malware Investigations

The NTOSBOOT prefetch file stores information about the files accessed during the boot process and in some cases 30 seconds following a user logging onto a system. Remember the Rootkit Paradox, malware wants to hide but it must run. If a piece of malware runs during the boot process then there will be a reference for the malware in the NTOSBOOT prefetch file. To illustrate this point I examined a NTOSBOOT prefetch file to show how it contains traces of malware execution. (side note: to view the file handles in prefetch files one could use Strings or Harlan’s pref.pl)

The NTOSBOOT prefetch file in question came from a system I infected last year by opening the attachment in a NYS Department of Motor Vehicles Uniform Traffic Ticket email. Looking through the file handles for any unusual file paths (files in temporary folders, unusual file names, etc) I came across three suspicious files as shown below.

The first file 17F7FFF4.COM was suspicious since the file was located in the All Users temporary folder. The second file KB961710.exe was suspicious because Windows updates are not stored in the application data folders. The last file SVCHOST.EXE was suspicious since not only was it located in a temp folder but the svchost.exe file is normally located in the Windows\System32 folder. I located these files by solely reviewing the file handles referenced in the NTOSBOOT prefetch file and the screenshot below confirms my suspicions.

Summary

Program execution artifacts are vital when examining a system infected with malware. Despite malware’s best efforts to hide on a system at some point for them to do their jobs they have to run. When malware eventual runs there will be traces of its execution left on a system which can be used to find its hiding spot. The NTOSBOOT prefetch file is one such artifact and the file handle information will reveal what’s hiding on a system.

Read More

Different Take on the Rootkit Paradox

Jesse Kornblum’s paper “Exploiting the Rootkit Paradox with Windows Memory Analysis” explains the predicament Rootkits find themselves in. The predicament is:

        1. They want to remain hidden.

        2. They need to run.

Jesse’s paper goes into detail about this paradox so I won’t. The main point is Rootkits want to remain hidden on a system but they need to run on an operating system. If an operating system can find the Rootkit then so can an examiner. The paradox applies to all kinds of malware from data stealers to remote access Trojans to droppers.

I’ve been thinking about the Rootkit Paradox and there is another aspect to it that is important for examiners to understand. The second predicament is:

        1. They need to run.

        2. They want to remain hidden

In this case the “they” in the need to run is a piece of malware while the “they” in the want to remain hidden are Rootkits. Basically, a program needs to run in order to hide a Rootkit on a system. The program could be the Rootkit itself or a different piece of malware such as a dropper or installer. When a program runs on the system it creates artifacts showing it executed. An examiner could then look at those artifacts along with changes made to the file system (files/folders creations and modifications) to determine where the Rootkit or its components are hiding. Again this predicament applies to all kinds of malware.

The Rootkit Paradox is alive and well, and can be leveraged to find malware hiding on a system.

Read More

Finding An Infection Vector After IT Cleaned the System

Almost every “CSI” episode begins the same way. An attack took someone’s life, first responders secured the crime scene, and then the main characters show up to start processing a well preserved scene. The technological equivalent of this is the following: an attack compromises a system, first responders image the system’s memory before immediately powering the system down, and then a forensicator shows up to process the scene. This is an ideal situation but life is not always ideal. Actions taken by users and first responders do not always leave a well preserved scene. Anti-virus scans are ran, files are deleted, temporary folders are emptied, programs are installed/removed, system restore points/volume shadow copies are deleted, or the system is left running resulting in data being altered. Only after all these actions is the forensicator consulted and asked to figure out how the compromise occurred. Needless to say conducting the analysis is more difficult and time consuming but it is not impossible. There still may be artifacts left on the system providing clues to what happened.

In order to demonstrate this, I setup a simulation where I purposely infected a Windows XP system and then I mimicked actions someone would take to remove the infection. Afterwards I examined the system to see what artifacts I could find. I wanted to simulate a real life scenario so I performed the following common troubleshooting techniques administrators do when trying to “clean” a system and get it back into working order as quickly as possible.

        • McAfee antivirus scans were conducted and any detections were cleaned
        • All temporary folders’ contents were deleted
        • All prefetch files were deleted
        • All recycle bins were emptied
        • All system restore points were deleted
        • Avast! was installed and a scan was conducted

The actions may be common troubleshooting techniques but I picked them for a different reason. All of those actions potentially destroy vital information that could help determine how an infection occurred. Antivirus software deleting malware not only removes the suspicious files from the system but it also destroys their filesystem metadata. This metadata can narrow down the timeframe to when the infection occurred. Deleting the files in the Windows\Prefetch folder makes it harder to determine what programs executed on the system. Deleting files in the Windows temporary, user profiles’ temporary, and Internet browser folders removes any secondary artifacts –such as exploit artifacts – that can provide additional information about an event. Emptying the recycle bin ensures the files are actually deleted from the system. Windows System Restore Points are an interesting artifact because they contain backup copies of registry hives and Windows system files. Deleting the System Restore Points destroys the historical information they contain. Lastly, installing and running additional anti-virus software makes more changes to the system and potentially alters or deletes information beneficial to an analysis.

Potential Artifacts

The common troubleshooting techniques destroyed some of the information I look for when faced with a malware infected system. Despite those actions there is still data left on a system providing clues about how the infection occurred. Based on the actions taken, four potential areas containing information are:

        1. Host Based Logs
        2. NTFS Artifact
        3. Registry Artifacts
        4. System Timeline

Host Based Logs

Antivirus software typically records installation and other system activities in text logs. The location of these text log files is specific to each antivirus product. One method used to identify the installed antivirus products is the Uninstall Registry key in the Software hive[1]. Afterwards, Google searches on the products can show the where the folders containing logs are located. I reviewed the Uninstall Registry key on the infected system using RegRipper and found the following:

Sun Apr 8 04:49:07 2012 (EDT)
      avast! Free Antivirus v.7.0.1426.0

Sat Apr 7 10:52:52 2012 (EDT)
      McAfee VirusScan Enterprise v.8.6.0

The above information showed there were two installed antivirus products; they were McAfee antivirus and Avast!. The Google searches I performed showed me where both products store their logs on a Windows XP system. In addition to these logs, antivirus products activity may also be recorded in the Windows events logs. I examined both the antivirus and Windows events logs looking for any information about the infection.

The McAfee logs are located in the DesktopProtection folder located under “Documents and Settings\All Users\Application Data\McAfee\”[2]. Two specific logs of interest were the OnAccessScanLog and OnDemandScanLog. The OnAccessScanLog log records information regarding McAfee continuously monitoring a system. The second log – OnDemandScanLog – records information regarding scans conducted against a system. The OnAccessScanLog did not contain any entries for the malware. However, the OnDemandScanLog contained entries outlining what had been deleted, cleaned, or quarantined by McAfee. Below were some entries found:

• 4/8/2012 4:06:46 PM (EDT) Deleted corey C:\SYSTEM VOLUME INFORMATION\_RESTORE{3F806DB1-464B-46B0-B724-4376EC868222}\RP6\A0003833.EXE BackDoor-AMQ(Trojan)

• 4/8/2012 4:06:46 PM (EDT) Deleted corey C:\SYSTEM VOLUME INFORMATION\_RESTORE{3F806DB1-464B-46B0-B724-4376EC868222}\RP6\A0003834.COM BackDoor-AMQ(Trojan)

• 4/8/2012 4:06:49 PM (EDT) Deleted corey C:\WINDOWS\SVCHOST.EXE BackDoor-AMQ(Trojan)

• 4/8/2012 4:06:50 PM (EDT) Deleted corey C:\WINDOWS\MSAGENT\MSQGIX.COM BackDoor-AMQ(Trojan)

• 4/8/2012 4:06:50 PM (EDT) Deleted corey C:\WINDOWS\SYSTEM32\MSMHXY.COM BackDoor-AMQ(Trojan)

The Windows Application Event log - AppEvent.Evt – collaborated the information in the OnDemandScanLog log. There were numerous Event IDs 258 showing McAfee deleted numerous files detected as BackDoor-AMQ (Trojan) on 4/8/2012 4:06:50 PM (EDT). The OnDemandScanLog and Windows Application Event logs revealed that the “corey” user account conducted a McAfee On-demand scan around 4/8/12 4:06 PM (EDT). The scan deleted the files svchost.exe, msqgix.com, and msmhxy.com from different locations in the Windows folder while files with the same extensions were deleted from a System Restore Point. The last piece of information indicated that McAfee detected the files as the BackDoor-AMQ Trojan. I searched McAfee’s website for additional information about BackDoor-AMQ[3] but it wasn’t useful without having access to the actual malware or their hashes.

I proceeded to examine the Avast! logs located in the Log folder under “Documents and Settings\All Users\Application Data\AVAST Software\Avast”. I was looking at the names of the files in the folder when I noticed one named Setup.log. The Setup.log shows the information related to installation of Avast! and the log’s first entry stated “Started: 08.04.2012, 16:46:02”. Later on in the Setup.log I found an entry showing Avast! antivirus was installed at 4/08/12 4:49:06 PM (EDT). I wanted to correlate the information with the Windows event log. The System Event log - SysEvent.Evt – Event ID 7035 showed at 4/08/12 4:48 PM (EDT) the Windows installer started. The first entries for the Avast! in the System Event log occurred one minute later (4:49 PM (EDT)) when numerous Avast! services were started (Event IDs 7035). Something I found interesting was that the Avast! services were started under the context of the local administrator user account.

I continued looking at the other Avast! text log files in the folder and noticed that the logs starting with asw were the ones containing the results of any scans conducted against the system. The Avast! logs did not contain any entries related to files being deleted, cleaned, or quarantined on the test system.

The examination of the host based logs provided some indicators about what occurred on the system. There were numerous suspicious files (svchost.exe, msqgix.com, and msmhxy.com) located within the Windows folder. These files were detected as BackDoor-AMQ Trojans followed by being deleted when the “corey” user account conducted a McAfee antivirus scan. I knew my best bet at finding artifacts showing how the system was infected was to identify when those files first appeared or executed on the system. I turned my attention to the NTFS artifacts to see what information was available.

NTFS Artifact

When antivirus products delete or quarantine files the filesystem may still maintain metadata about those files. One piece of information that can be pulled from this metadata is timestamps; this can be valuable to the analyst, as it helps identify the timeframe of when the system first became infected. One NTFS artifact[4] that may shed light about an infection after a system is cleaned is INDX files.

INDX files contain records for each file within a directory. Each record contains information about the file including: filename, file size, and timestamps[5]. The records in INDX files may remain after files are deleted from a system[6]. This behavior makes INDX files an excellent artifact to provide information about files deleted from the system in attempts to remove malware. An analyst can use Willi Ballenthin’s INDXParse python script to parse these artifacts. On the test system the McAfee antivirus logs indicated the following files were deleted:

        • A0003833.EXE and A0003834.COM from RP6 (System Restore Point)
        • SVCHOST.EXE from the C:\Windows folder
        • MSMHXY.COM from the C:\Windows\System32 folder
        • MSQGIX.COM from the C:\Windows\MSAGENT folder

I was interested to see if either the Windows, System32, or Msagent folders’ INDX files contained any timestamps for the svchost.exe, msmhxy.com, and msqgix.com files. I examined the Windows and System32 folders’ INDX files but it didn’t provide any information about the timestamps I was looking for. However, the Msagent folder’s INDX file contained timestamps for the msqgix.com file.

        • Filename: msqgix.com (slack at 0x5c0)
        • Modified Time: 2012-04-08 4:06:50.390625 PM (EDT)
        • Accessed Time: 2012-04-08 4:06:50.328125 PM (EDT)
        • Changed Time: 2012-04-08 4:06:50.390625 PM (EDT)
        • Created Time: 2004-08-04 12:00:00

Correlating the above timestamps to the information I learned from examining the host based logs shows the timestamps are around the time when McAfee deleted the file. I also checked the Prefetch folder’s INDX file hoping to find information about program execution but it did not provide any useful information about the attack. This time around the INDX files did not provide any new information about how the attack occurred but it is an NTFS artifact to keep in mind with respect to files that may have been deleted.

I still needed to identify the timeframe of when the infection occurred since I didn’t get the information from the host based logs and INDX files. I know when malware executes it may change system configuration settings in the Registry which is where I looked next.

Registry Artifacts

When an administrator takes actions to remove malware from a system not only are important files deleted but many times, those files’ metadata is lost as well. Not having access to the metadata makes it tougher to identify the timeframe of when the system was initially infected. However, if the malware makes changes to the Registry then the Last Write times associated with modified registry keys modify can help fill in some of these gaps. Different methods can be used to locate the information stored in the Registry, from checking common keys used by malware to performing keyword searches. The McAfee log file provided names of three files of interest that were used in a keyword search. The following list provides the results of these searches.

1. C:\Windows\SVCHOST.EXE Search Hit 1
     a. Last Write Time: 2012/04/08 3:06:31 PM (EDT)
     b. Key: HKLM\System\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
     c. Data: C:\Windows\svchost.exe


2. C:\Windows\System32\MSMHXY.COM Search Hit 1
     a. Last Write Time: 2012/04/08 3:06:33 PM (EDT)
     b. Key: HKLM\Software\Microsoft\Active Setup\Installed Components\{42CE4021-DE03-E3CC-EA32-40BB12E6015D}
     c. Name: Stubpath
     d. Data: C:\Windows\System32\MSMHXY.COM


3. C:\Windows\MSAGENT\MSQGIX.COM Search Hit 1
     a. Last Write Time: 2012/04/08 3:06:33 PM (EDT)
     b. Key: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
     c. Name: COM Service
     d. Data: C:\Windows\MSAGENT\MSQGIX.COM


4. C:\Windows\MSAGENT\MSQGIX.COM Search Hit 2
     a. Last Write Time: 2012/04/08 3:06:33 PM (EDT)
     b. Key: HCU\ntuser-corey\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
     c. Name: COM Service
     d. Data: C:\Windows\MSAGENT\MSQGIX.COM

I found the Registry keyword searches enlighten because it showed the changes the malware made when it executed. The earliest timestamp - 2012/04/08 3:06:31 PM (EDT) – is when the firewall configuration was changed to make the svchost.exe file an authorized application. The search hits also identified how the malware remains persistent; the msqgix.com file was added to the Run key in the Software and "corey" user account hives. In the past, I’ve seen when malware infects a system it adds a persistence mechanisms to both the logged on user account NTUSER.DAT and to either the System or Software hives. It appears the malware did this by adding entries to two different Run keys. I thought the “corey” user account was not only involved with running the McAfee antivirus scan but might have been logged on when the infection occurred. Lastly, all the Registry keys Last Write times were 04/08/2012 3:06 PM (EDT) and this provided me with the first indicator to when the infection may have occurred.

I wanted to see if any programs were run by the “corey” user account around the 3:06 PM (EDT). I ran RegRipper with the userassist plug-in against the “corey” user account’s NTUSER.DAT hive which showed the following activity (I adjusted the time from Coordinated Universal Time to Eastern Daylight Time).

Sun Apr 8 3:06:21 2012 PM (EDT)
     UEME_RUNPATH:\\XP-SP3-SHARES\Main_Share\Software\npp.6.0.0.Installer.exe (1)

The Userassist registry key[7] showed that the “corey” user account ran a program called “npp.6.0.0.Installer.exe” at 4/08/12 3:06:21 PM (EDT) from the “Main_Share” network share. 10 seconds later the svchost.exe file was added to the firewalls authorized applications list which was immediately followed by persistence mechanisms being set for the msqgix.com file. I identified the timeframe of interest as 4/08/12 3:06 PM (EDT). Next I needed to see what other activity was occurring on the system so I decided to create a timeline.

System Timeline

System timelines can provide a good deal of context about data found on a system. Timelines can reveal what other activity was occurring on the system around the time when an event (i.e. malware infection) occurred on the system. This other activity can help answer questions with respect to “how did the compromise happen?” This type of question can still be answered even if someone took actions to clean the system and in the process destroyed the best artifacts available. The registry artifacts provided indications that the “corey” user account might have been responsible for the malware infection. As a result, I wanted my timeline to include the Last Write times of every Registry key in the “corey” user account NTUSER.DAT hive to help see what the account was doing and what changes the malware made to the hive. The only other timeline information I wanted initially was the filesystem metadata since it shows activity on the system. My timeline consisting of just filesystem metadata and the “corey” NTUSER.DAT Registry hive metadata showed the following activity occurring around 4/08/2012 3:06 PM (EDT). The table below illustrates some entries from the timeline.

The timeline revealed a great deal of information about the activity on the system around the time the Registry was modified to include references to the malware. Specifically, the “corey” user account accessed a network share named Main_Share on the XP-SP3-Shares computer followed by executing a program named “npp.6.0.0.Installer.exe”.

How the Compromise Occurred

The information I obtained from the host based logs, Windows Registry, and a system timeline was enough to determine how the how the infection occurred.

The “corey” user account launched a program named "npp.6.0.0.Installer.exe" from the Main_Share on the computer XP-SP3-Shares. Within 15 seconds there were multiple indicators in the Registry showing when malware first executed on the system. Those indicators involved three files names (svchost.exe, msqgix.com, and msmhxy.com) that were eventually detected by McAfee antivirus as BackDoor-AMQ (Trojan) prior to being deleted.

The information I obtained from the artifacts left on the system confirmed how I purposely infected the system. I Trojanized a Notepad ++ installer[8] which drops malware when executed[9].

Summary

There are some instances when the “CSI” main characters show up to a crime scene that appears to be spotless. There is no victim, blood spatter, knocked over furniture, or anything else to indicate a crime took place. What happened was someone cleaned the crime scene before the characters arrived. When faced with a clean crime scene they do not throw their hands up in the air and say the cleaning prevents them from investigating what happened. Instead they search the scene looking for clues the cleaning might have missed. Areas get sprayed with Fluorescein and then a UV light reveals where blood existed, cracks in objects are checked for blood, or the drains in showers are checked for any evidence. Digital forensics is no different; when a “cleaned” system is encountered then the examination needs to find any information in the artifacts left on a system.

Sometimes there might not be the original malware samples, their metadata, Prefetch files, temporary files, or historical information. It is still incumbent upon us to find any remaining artifacts whether they are host based log files, NTFS artifacts, registry artifacts, or timelines. There are even additional remaining artifacts I didn’t discuss such as ones showing program execution and file access. The Registry contains more information about program execution including the MUICache[10] and the Shim Cache[11] Registry keys. There are artifacts showing what folders and files were accessed by a user account including: Shellbags Registry keys[12], Windows LNK files[13], or Internet Explorer browser history.

The common troubleshooting techniques administrators do when trying to "clean" a system and get it back in working order makes it more challenging for us to perform our analysis. What artifacts the administrators destroy will be different from system to system. However, it’s up to us to find what articles remain and how they can be pieced together to explain what happened.

References

1. The full path to the registry key is HKLM\Software\ Microsoft\Windows\CurrentVersion\Uninstall

2. McAfee outlines the log file locations in their knowledge base https://kc.mcafee.com/corporate/index?page=content&id=KB51377

3. McAfee write-up for BackDoor-AMQ http://vil.nai.com/vil/content/v_100037.htm

4. Refer to Brian Carrier’s File System Forensic Analysis book for additional information about NTFS and the artifacts available

5. Willi Ballenthin INDXParse script webpage discussing the INDX artifact http://www.williballenthin.com/forensics/indx/index.html

6. Chad Tilbury wrote an excellent article discussing this behavior http://computer-forensics.sans.org/blog/2011/09/20/ntfs-i30-index-attributes-evidence-of-deleted-and-overwritten-files

7. For additional information about the Userassist Registry key see http://forensicartifacts.com/2010/07/userassist/

8. Virustotal scan showed 32/42 antivirus detected as malicious https://www.virustotal.com/file/84824963c0989568674f329e8dd92eb735f27609ef27e6352347288f62bf1d16/analysis/1334516889/

9. The Malwr dynamic analysis http://malwr.com/analysis/0916af77efc95add28e0abdd17b8a64c/

10. Harlan Carvey’s blog post about the MUICache http://windowsir.blogspot.com/2005/12/mystery-of-muicachesolved.html

11. Whitepaper about the forensic significance of the Shim Cache https://blog.mandiant.com/archives/2459

12. Chad Tilbury article about Windows 7 Shellbags http://computer-forensics.sans.org/blog/2011/07/05/shellbags

13. Article "Evidentiary Value of Link Files" http://www.forensicfocus.com/link-file-evidentiary-value



Article Edited By:

Harlan Carvey
Don C. Weber

Read More

From Malware Analysis to Portable Clam AV

Malware forensics can answer numerous questions. Is there malware on the system, where is it, how long has it been there, and how did it get there in the first place. Despite all the questions malware forensics can solve there are some that it can’t. What is the malware’s purpose, what is its functionality, and is it capable of stealing data. To answer these questions requires malware analysis. Practical Malware Analysis defines malware analysis as “the art of dissecting malware to understand how it works, how to identify it, and how to defeat or eliminate it”. I’ve been working on improving my malware analysis skills while at the same time thinking about the different ways organizations can benefit from the information gained by analyzing malware. One such benefit is empowering the help desk to combat malware. Everyday help desks are trying to find malware on computers using antivirus products lacking signatures to detect it. Analyzing malware can provide enough information to build a custom antivirus signature to provide the help desk with a capability to find it until the commercial antivirus signatures catch up. In this post I’m going through the process; from analyzing malware to creating a custom antivirus signature to using the signature in the portable apps ClamAV version.

The work presented in this post was originally put together for my hands on lab for a Tr3Secure meet-up. Also, the sample used was obtained from Contagio’s post APT Activity Monitor / Keylogger.

Disclaimer:

I’m not a malware analyst. I’m an information security and digital forensic practitioner who is working on improving my malware analysis skills. As such for anyone looking to be more knowledgeable on the subject then I highly recommend the books Practical Malware Analysis and the Malware Analyst's Cookbook.

Static Analysis

Static Analysis is when the malware is examined without actually running it. There are different static analysis steps to extract information; the two I’m discussing are: reviewing strings and reviewing the import table.

Reviewing Strings

Strings in malware can provide clues about the program and I find them helpful since it makes me more aware about malware’s potential functionality. However, conclusions cannot be drawn by solely looking at the strings. I usually first run HexDive on a sample to filter the strings typically associated with malware followed by running Strings to make sure I see everything.

Below is the Hexdrive command running against AdobeInfo.exe and a snippet from its output.

C:\> Hdive.exe C:\Samples\AdobeInfo.exe

CreateFileA
SetFileAttributesA
CreateDirectoryA
GetCurrentDirectoryA
GetWindowTextA
GetForegroundWindow
GetAsyncKeyState
GetStartupInfoA
[Up]
[Num Lock]
[Down]
[Right]
[UP]
[Left]
[PageDown]
[End]
[Del]
[PageUp]
[Home]
[Insert]
[Scroll Lock]
[Print Screen]
[WIN]
[CTRL]
[TAB]
[F12]
[F11]

There were numerous Windows API function names in the strings and looking the functions up in Practical Malware Analysis’s Appendix A (commonly encountered Windows functions) provides some clues. The following are three function names and why they may be relevant:

     - CreateFileA: creates new or opens existing file

     - GetForegroundWindow: returns a handle to a window currently in the foreground of the desktop. Function is commonly used by keyloggers to determine what window the user is entering keystrokes in

     - GetAsyncKeyState: used to determine whether a particular key is being pressed. Function is sometimes used to implement a keylogger

The other interesting strings were the characters associated with a keyboard such as [Down] and [Del]. The combination of the API names and keyword characters indicate the malware could have some keylogging functionality.

Below is the Strings command running against AdobeInfo.exe and a snippet from its output.

C:\>Strings.exe C:\Samples\AdobeInfo.exe

---- %04d%02d%02d %02d:%02d:%02d ----------------
\UpdaterInfo.dat
\mssvr
The Active Windows Title: %s

In addition to the strings extracted with HexDrive, Strings revealed some other text that didn’t become clear until later in the examination.

Reviewing the Import Table

“Imports are functions used by one program that are actually stored in a different program, such as code libraries that contain functionality common to many programs”. Looking at functions imported by a program provides better information about a malware’s functionality than solely relying on its strings. I used CFF Explorer to review the import table as shown in the screen shot below.

The import table showed three DLLs which were kernel32.dll, user32.dll, and msvcrt.dll. The DLLs’ functions imported matched the Windows API function names I found earlier in the strings. The functions provide the sample with the ability to: create and open files and directories, copies text from a window’s title bar, returns a handle to an active window, returns handle to a loaded module, and monitor for when a key is pressed. All of which strengthens the indication that the sample is in fact a keylogger.

Dynamic Analysis

The opposite of static analysis is dynamic analysis which is examining the malware as it runs on a system. There are different dynamic analysis steps and tools to use but I’m only going to discuss one; monitoring program execution with Capture-Bat. Below is the output from the Capture-Bat log after AdobeInfo.exe executed on the system (the entries related to my monitoring tools were removed).

"2/8/2012 15:03:27.653","process","created","C:\WINDOWS\explorer.exe","C:\Samples\AdobeInfo.exe"

"2/8/2012 15:03:40.403","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

"2/8/2012 15:03:40.481","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

"2/8/2012 15:03:40.497","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

"2/8/2012 15:04:33.419","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

"2/8/2012 15:04:33.419","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

Capture-Bat revealed when AdobeInfo.exe runs it creates a folder named mssvr in the same folder where the executable is located as well as creates a file named UpdaterInfo.dat inside the folder. Remember the suspicious strings before? Now the strings \UpdaterInfo.dat and \mssvr make a lot more sense. Looking at the UpdaterInfo.dat file closer showed it was a text file containing the captured data as can be seen in the partial output below.


---- 20120802 15:07:38 ----------------
15:07:40 The Active Windows Title: Process Explorer - Sysinternals: www.sysinternals.com [XP-SP2\Administrator]
15:07:33 The Active Windows Title: C:\WINDOWS\system32\cmd.exe
15:07:39 The Active Windows Title: Process Explorer - Sysinternals: www.sysinternals.com [XP-SP2\Administrator]
c[CTRL]y
15:07:41 The Active Windows Title: Process Monitor - Sysinternals: www.sysinternals.com
15:07:44 The Active Windows Title: Process Monitor
15:07:38 The Active Windows Title: Process Monitor
15:07:38 The Active Windows Title: API Monitor v2 (Alpha-r12) 32-bit (Administrator)
15:07:44 The Active Windows Title: Process Monitor
15:07:45 The Active Windows Title: API Monitor v2 (Alpha-r12) 32-bit (Administrator)
15:07:35 The Active Windows Title: ApateDNS


Everything in the analysis so far has identified the AdobeInfo.exe program as a keylogger that stores its captured data in a log file named UpdaterInfo.dat. All that was left was to confirm the functionality. I used Windows to create a password protected zip file then I unzipped it. A quick look at the UpdaterInfo.dat log file afterwards confirmed the functionality (note: Windows made me enter the password twice).


16:07:30 The Active Windows Title: Program Manager
16:07:38 The Active Windows Title: Add to Archive
[CTRL]
16:07:58 The Active Windows Title: Program Manager
supersecretsupersecret
16:07:58 The Active Windows Title: Compressing
16:07:59 The Active Windows Title: Program Manager
16:07:21 The Active Windows Title: Extraction Wizard
16:07:30 The Active Windows Title: Password needed
16:07:37 The Active Windows Title: Extraction Wizard
supersecret
16:07:40 The Active Windows Title: Program Manager
16:07:42 The Active Windows Title: Windows Explorer

Creating Custom AntiVirus Signature

I’m not going into detail about how to create custom signatures for ClamAV but I will point to the great references I found on the subject. The Malware Analyst’s Cookbook talks about how to leverage ClamAV for malware analysis in the recipes: Recipe 3-1 (examining existing ClamAV signatures), Recipe 3-2 (creating a custom ClamAV database), and Recipe 3-3 (converting ClamAV signatures to Yara). Another resource is Alexander Hanel’s post An Intro to Creating Anti-Virus Signatures. The ClamAV website also has information on the subject as well including the slide deck in PDF format for the webcast Writing CalmAV Signatures.

I spent some time creating different signatures: from a custom hash database to extended signature format to a logical signature. To keep the post shorter I’m only going to cover how I created a logical signature. A ClamAV logical signature is based on hex strings found inside a file and logical operators can be used to combine the hex strings in different ways. The format for the signature is below:

SignatureName;TargetDescriptionBlock;LogicalExpression;Sig0;Sig1;Sig2;

The SignatureName is self explanatory, the TargetDescriptionBlock is the type of file the signature applies to (0 means any file), LogicalExpression is how the signatures are combined using logical operators, and the Sig# are the actual hex strings. The completed signature is placed into a file with an ldb extension.

Reviewing the strings in AdobeInfo.exe provided some good candidates to create a signature for; specially \UpdaterInfo.dat, \mssvr, and [CTRL]. I used portable apps ClamAV’s sigtool to determine the hex of those strings. I ran the following command for each string:

C:\>echo \UpdaterInfo.dat | App\clamwin\bin\sigtool --hex-dump

The end result provided me with the hex for each string.

\UpdaterInfo.dat
5c55706461746572496e666f2e646174

\mssvr
5c6d73737672

[CTRL]
5b4354524c5d

I then combined the strings into a logical signature as shown next.

AdobeInfo.exe;Target:0;0&1&2;5c55706461746572496e666f2e646174;5c6d73737672;5b4354524c5d

Finally, I ran the custom signature against the AdobeInfo.exe file and was successfully able to identify it. The command to run a custom scan from the command-line in portable ClamAV is:

App\clamwin\bin\clamscan -d adobe.ldb C:\Samples\

Empowering the Help Desk

I’m done right? I was able to analyzing the malware to determine its functionality, create a custom antivirus signature to detect it, and found a way to run the custom signature using the portable apps ClamAv version. I wouldn’t be too quick to say my job is done though. Let’s be honest, going to any help desk and telling the staff from now on you have to use the command-line may not have the greatest chances of success. You need to provide options; one option most help desk staff will want is an antivirus program with a GUI that’s similar to their commercial antivirus programs. ClamAV has a pretty nice graphical user interface that can be configured to use custom signatures so we could leverage it.

The article How to create custom signatures for Immunet 3.0, powered by ClamAV explains how to write custom signatures and configure the Windows ClamAV version (Immunet) to use them. This is nice but Immunet has to be installed on a computer. A cool option would be to be able to run scans from a removable drive so when the help desk respond to a system all they need to do is to plug in their thumb drive. This is where the portable apps ClamAV version comes into play since it can run scans from a thumb drive. I couldn’t find any documentation about how to use custom signatures in the portable version but after a little testing I figured it out. All that has to be done is to copy the custom signature to the same folder where ClamAV stores it signature files main.cvd and daily.cdv. This location is ClamWinPortable\Data\db folder. I copied my adobe.ldb custom signature to the Data\db folder and was able to locate the malware sample I disguised as Notepad ++.

Read More

Malware Root Cause Analysis

The purpose to performing root cause analysis is to find the cause of a problem. Knowing a problem’s origin makes it easier to take steps to either resolve the problem or lessen the impact the next time the problem happens again. Root cause analysis can be conducted on a number of issues; one happens to be malware infections. Finding the cause of an infection will reveal what security controls broke down that let the malware infect the computer in the first place. In this post I’m expanding on my Compromise Root Cause Analysis Model by showing how a malware infection can be modeled using it.

Compromise Root Cause Analysis Revisited

The Compromise Root Cause Analysis Model is a way to organize information and artifacts to make it easier to answer questions about a compromise. The attack artifacts left on a network and/or computer fall into one of these categories: source, delivery mechanism, exploit, payload, and indicators. The relationship between the categories is shown in the image below.

I’m only providing a brief summary about the model but for more detailed information see the post Compromise Root Cause Analysis Model. At the model’s core is the source of the attack; this is where the attack came from. The delivery mechanisms are for the artifacts associated with the exploit and payload being sent to the target. Lastly, the indicators category is for the post compromise activity artifacts. The only thing that needs to be done to use the model during an examination is to organize any relevant artifacts into these categories. I typically categorized every artifact I discover as an indicator until additional information makes me move them to a different category.

Another Day Another Java Exploit

I completed this examination earlier in the year but I thought it made a great case to demonstrate how to determine a malware infection’s origin by using the Root Cause Analysis Model. The examination was kicked off when someone saw visual indicators on their screen that their computer was infected. My antivirus scan against the powered down computer confirmed there was an infection as shown below.

The antivirus scan flagged four files as being malicious. Two binaries (fuo.exe and 329991.exe) were identified as the threat: Win32:MalOb-GR[Cryp]. One cached webpage (srun[1].htm) was flagged as JS:Agent-PK[Trj] while the ad_track[1].htm file was identified as HTML:RedirME-inf[Trj]. A VirusTotal search on the fuo.exe file’s MD5 hash provided more information about the malware.

I mentally categorized the four files as indicators of the infection until it’s proven otherwise. The next examination step that identified additional artifacts was timeline analysis because it revealed what activity was occurring on the system around the time when malware appeared. A search for the files fuo.exe and 329991.exe brought me to the portion of the timeline shown below.

The timeline showed the fuo.exe file was created on the computer after the 329991.exe file. There were also indications that Java executed; the hsperfdata_username file was modified which is one artifact I highlighted in my Java exploit artifact research. I was looking at the activity on the system before the fuo.exe file appeared which is shown below.

The timeline confirmed Java did in fact execute as can be seen by the modification made to its prefetch file. The file 329991.exe was created on the system at 1/15/2012 16:06:22 which was one second after a jar file appeared in the anon user profile’s temporary folder. This activity resembles exactly how an infection looks when a Java exploit is used to download malware onto a system. However, additional legwork was needed to confirm my theory. Taking one look at the jar_cache8544679787799132517.tmp file in JD-GUI was all that I needed. The picture below highlights three separate areas in the jar file.

The first area labeled as 1 shows a string being built where the temp folder (str1) is added to 329991.exe. The second area labeled as 2 first shows the InputStream function sets the URL to read from while the FileOutputStream function writes the data to a file which happens to be str3. Remember that str3 contains the string 329991.exe located inside the temp folder. The last highlighted area is labeled as 3 which is where the Runtime function starts to run the newly created 329991.exe file. The analysis on the jar file confirmed it was responsible for downloading the first piece of malware onto the system. VirusTotal showed that only 8 out of 43 scanners identified the file as a CVE-2010-0840 Java exploit. (for another write-up about how to examine a Java exploit refer to the post Finding the Initial Infection Vector). At this point I mentally categorized all of the artifacts associated with Java executing and the Java exploit under the exploit category. The new information made me move 329991.exe from the indicator to the payload category since it was the payload of the attack.

I continued working the timeline by looking at the activity on the system before the Java exploit (jar_cache8544679787799132517.tmp) appeared on the system. I noticed there was a PrivacIE entry for a URL ending in ad_track.php. PrivacIE entries are for 3rd party content on websites and this particular URL was interesting because Avast flagged the cached webpage ad_track[1].htm. I started tracking the URLs in an attempt to identify the website that served up the 3rd party content. I didn’t need to identify the website per say since I already reached my examination goal but it was something I personally wanted to know. I gave up looking after spending about 10 minutes working my way through a ton of Internet Explorer entries and temporary Internet files for advertisements.

I answered the “how” question but I wanted to make sure the attack only downloaded the two pieces of malware I already identified. I went back in the timeline to when the fuo.exe file was created on the system. I started looking to see if any other files were created on the system but the only activity I really saw involved the antivirus software installed on the system.

Modeling Artifacts

The examination identified numerous artifacts and information about how the system was compromised. The diagram below shows how the artifacts are organized under the Compromise Root Cause Analysis Model.

As can be seen in the picture above the examination did not confirm all of the information about the attack. However, categorizing the artifacts helped make it possible to answer the question how did the system become infected. It was a patching issue that resulted in an extremely vulnerable Java version running on the system. In the end not only did another person get their computer cleaned but they also learned about the importance of installing updates on their computer.


Usual Disclaimer: I received permission from the person I assisted to discuss this case publicly.

Read More

Combining Techniques

“You do intrusion and malware investigations, we do CP and fraud cases” is a phrase I saw Harlan mention a few times on his blog. To me the phrase is more about how different the casework is; about how different the techniques are for each type of case. Having worked both fraud and malware cases I prefer to focus on what each technique has to offer as opposed to their differences. How parts of one technique can be beneficial to different types of cases. How learning just a little bit about a different technique can pay big dividends by improving your knowledge, skills, and process that you can use on your current cases. To illustrate I wanted to contrast techniques for malware and fraud cases to show how they help one another.

Program Execution

Malware eventually has to run and when it does execute then there may be traces left on a system. Understanding program execution and where these artifacts are located is a valuable technique for malware cases. Examining artifacts containing program execution information is a quick way to find suspicious programs. One such artifact is prefetch files. To show their significance I’m parsing them with Harlan’s updated pref.pl script. Typically I start examining prefetch files by first looking at what executables ran on a system and where they executed from. I saw the following suspicious programs looking at the output from the command “pref.exe -e -d Prefetch-Folder”.

TMP77E.EXE-02781D7C.pf Last run: Fri Mar 12 16:29:05 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TMP77E.EXE

TMPDC7.EXE-2240CBB3.pf Last run: Fri Mar 12 16:29:07 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TMPDC7.EXE

UPDATE.EXE-0825DC41.pf Last run: Fri Mar 12 16:28:57 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\DESKTOP\UPDATE.EXE

ASD3.TMP.EXE-26CA54B1.pf Last run: Fri Mar 12 16:34:49 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASD3.TMP.EXE

ASD4.TMP.EXE-2740C04A.pf Last run: Fri Mar 12 16:34:50 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASD4.TMP.EXE

DRGUARD.EXE-23A7FB3B.pf Last run: Fri Mar 12 16:35:26 2010 (2)
\DEVICE\HARDDISKVOLUME1\PROGRAM FILES\DR. GUARD\DRGUARD.EXE

ASD2.TMP.EXE-2653E918.pf Last run: Fri Mar 12 16:34:27 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASD2.TMP.EXE

ASR64_LDM.EXE-3944C1CE.pf Last run: Fri Mar 12 16:29:06 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASR64_LDM.EXE

These programs stood out for a few different reasons. First I noticed the path they executed from was a temporary folder in a user’s profile. Unusual file paths are one way to spot malware on a system. The other thing I noticed is that some of the programs only executed once. This behavior resembles how downloaders and droppers work. Their sole purpose is to execute once to either download additional malware or install malware. The last dead giveaway is they all executed within a few minutes of each other. The first sweep across the prefetch files netted some interesting programs that appear to be malicious. The next thing to look at is the individual prefetch files to see what file handles were open when the program ran. The TMP77E.EXE-02781D7C.pf prefetch file showed something interesting as shown below (the command used was “pref.pl -p -i -f TMP77E.EXE-02781D7C.pf”).

EXE Name : TMP77E.EXE
Volume Path : \DEVICE\HARDDISKVOLUME1
Volume Creation Date: Fri Nov 2 08:56:57 2007 Z
Volume Serial Number: 6456-B1FD

\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS
*****snippet*****


EXEs found:

\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TMP77E.EXE
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NET.EXE
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SC.EXE
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASR64_LDM.EXE

DAT files found:

\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMPORARY INTERNET FILES\CONTENT.IE5\INDEX.DAT
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\COOKIES\INDEX.DAT
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\HISTORY\HISTORY.IE5\INDEX.DAT

Temp paths found:

\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TMP77E.EXE
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMPORARY INTERNET FILES\CONTENT.IE5\INDEX.DAT
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMPORARY INTERNET FILES\CONTENT.IE5\M20M2OXX\READDATAGATEWAY[1].HTM
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASR64_LDM.EXE

The pref.pl file handle portion to the output was trimmed to make it easier to read but I left in the intelligence provided by the script through its filters. The filters highlight file handles containing exes, dats, and temporary folders. The exe filter shows in additional to a handle to the TMP77E.EXE file there were handles to SC.EXE, NET.EXE, and ASR64_LDM.EXE. SC.EXE is a Windows program for managing services including creating new services while NET.EXE is a Windows program for doing various tasks including starting services. ASR64_LDM.EXE was another suspicious program that ran on the system after TMP77E.EXE. The file handles inside each prefetch file of interest provided additional information which is useful during a malware case.

Program execution is vital for malware cases and I saw how the same technique can apply to fraud cases. On fraud cases a typical activity is to identify and locate financial data. At times this can be done by running keyword searches but most of the time (at least for me) the actual financial data is unknown. What I mean by this is a system is provided and it’s up to you to determine what data is financial. This is where the program execution technique comes into play. The programs that ran on the system can be reviewed to provide leads about what kind of financial data may be present on the system. Using the first sweep across the prefetch files I located these interesting programs (command used was “pref.exe -e -d Prefetch-Folder”). Note: the system being looked at is not from a fraud case but it still demonstrates how the data appears.

WINWORD.EXE-C91725A1.pf Last run: Tue Jul 10 16:42:26 2012 (42)
\DEVICE\HARDDISKVOLUME2\PROGRAM FILES\MICROSOFT OFFICE\OFFICE12\WINWORD.EXE

ACROBAT_SL.EXE-DC4293F2.pf Last run: Fri Jun 22 18:14:12 2012 (1)
\DEVICE\HARDDISKVOLUME2\PROGRAM FILES\ADOBE\ACROBAT 9.0\ACROBAT\ACROBAT_SL.EXE

EXCEL.EXE-C6BEF51C.pf Last run: Tue Jul 10 16:30:18 2012 (22)
\DEVICE\HARDDISKVOLUME2\PROGRAM FILES\MICROSOFT OFFICE\OFFICE12\EXCEL.EXE

POWERPNT.EXE-1404AEAA.pf Last run: Thu Jun 21 20:14:52 2012 (22)
\DEVICE\HARDDISKVOLUME2\PROGRAM FILES\MICROSOFT OFFICE\OFFICE12\POWERPNT.EXE

When I look at program execution for fraud cases I look for financial applications, applications that can create financial data, and programs associated with data spoliation. The system didn’t have any financial or data spoliation programs but there were office productivity applications capable of creating financial documents such as invoices, receipts, proposals, etc. These programs were Microsoft Office and Adobe Acrobat and this means the data created on the system is most likely Word, Excel, Powerpoint, or PDFs. The number of executions for each program is also interesting. I look to see what applications are heavily used since it’s a strong indication about what program the subject uses. Notice Adobe only ran once while Word was ran 42 times. Looking at the file handles inside individual prefetch file also contains information relevant to a fraud case. Below are a few sanitized handles I found in the WINWORD.EXE-C91725A1.pf prefetch file (the command used was “pref.pl -p -i -f WINWORD.EXE-C91725A1.pf”).

EXE Name : WINWORD.EXE
Volume Path : \DEVICE\HARDDISKVOLUME2
Volume Creation Date: Fri Aug 26 18:13:26 2011 Z
Volume Serial Number: E4DD-S23A

\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\NTDLL.DLL
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\KERNEL32.DLL
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\APISETSCHEMA.DLL
*****snippet*****
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\SANTIZED.DOCX
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\~$SANTIZED.DOCX
\DEVICE\HARDDISKVOLUME2\USERS\USERNAME\APPDATA\LOCAL\TEMP\MSO4F30.TMP
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\SANTIZED 2.DOCX
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\~$SANTIZED 2.DOCX
\DEVICE\HARDDISKVOLUME2\USERS\USERNAME\APPDATA\LOCAL\TEMP\MSO7CF3.TMP
\DEVICE\HARDDISKVOLUME2\USERS\USERNAME\APPDATA\LOCAL\TEMP\20517251.OD
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\SANTIZED 3.DOCX
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\~$SANTIZED 3.DOCX
\DEVICE\HARDDISKVOLUME4\$MFT
\DEVICE\HARDDISKVOLUME2\USERS\USERNAME\APPDATA\LOCAL\MICROSOFT\WINDOWS\TEMPORARY INTERNET FILES\CONTENT.MSO\SANTIZED.JPEG
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\SANTIZED 3.DOCX:ZONE.IDENTIFIER
*****snippet*****

The file handles shows documents stored in the folder FORENSICS\RESEARCH\Folder\ on a different volume were accessed with Word. I think this is significant because not only does it provide filenames to look for but it also shows another storage location the subject may have used. Where ever there is storage accessible to the subject then there’s a chance that is where they are storing some financial data. Also, notice in the output how the last line shows one of the documents was downloaded from the Internet (zone identified alternate data stream).

User Activity

The program execution showed how fraud cases benefited from a technique used in malware cases. Now let’s turn the tables to see how malware cases can benefit from fraud. As I mentioned before most of the times I have to find where financial data is located whether if it’s on the system or in network shares. The best approach I found was to look at artifacts associated with user activity; specifically file, folder, and network share access. My reasoning is if someone is being looked at for committing a fraud and they are suspected of using the computer to commit the fraud then they will be accessing financial data from the computer to carry out the fraud. Basically, I let their user activity show me where the financial data is located and this approach works regardless if the data is in a hidden folder or stored on a network. There are numerous artifacts containing file, folder, and network share access and one of them is link files. To show their significance I’m parsing them with TZWorks LNK Parser Utility. When I examine link files I parse both the Recent and Office/Recent folders. This results in some duplicates but it catches link files found in one folder and not the other. I’ve seen people delete everything in the Recent folder while not realizing the Office\Recent folder exists. I saw some interesting target files, folders, and network shares by running the command “dir C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent\*.lnk /b /s | lp -pipe -csv > fraud_recent.txt”.

{CLSID_MyComputer}\E:\Forensics\Research\Folder\sanatized.doc
{CLSID_MyComputer}\E:\Forensics\Research\Folder\sanitized 2.doc
{CLSID_MyComputer}\E:\Forensics\Research\Folder\sanitized 3.doc
{CLSID_MyComputer}\C:\Atad\material\sanitized 1.pdf
{CLSID_MyComputer}\F:\Book1.xls
\\192.168.200.55\ share\TR3Secure

The output has been trimmed (only shows target file column) and sanitized since it’s from one of my systems. The link files show files and folders on removable media and a network share has been accessed in addition to a folder not inside the user profile. I’ve used this same technique on fraud cases to figure out where financial data was stored. One time it was some obscure folder on the system while the next time it was a share on a server located on the network.

Tracking user activity is a great way to locate financial data on fraud cases and I saw how this same technique can apply to malware cases. On malware cases it can help answer the question how did the computer become infected. Looking at the user activity around the time of the initial infection can help shed light on what attack vector was used to compromise the system. Did the user access a network share, malicious website, removable media, email attachment, or peer to peer application? The user activity provides indications about what the account was doing that contributed to the infection. On the malware infected system there were only two link files in the Recent folder shown below is the target create time and target name (command used was “dir "F:\Malware_Recent\*.lnk" /b /s | lp -pipe -csv > malware_recent.txt”).

3/12/2010 16:17:04.640 {CLSID_MyComputer}\C:\downloads
3/12/2010 16:18:59.609 {CLSID_MyComputer}\C:\downloads\link.txt

These link files show the user account accessed the downloads folder and the link text file just before the suspicious programs started executing on the system. Looking at this user activity jogged my memory about how the infection occurred. I was researching a link from a SPAM email and I purposely clicked the link from a system. I just never got around to actually examining the system. However, even though the system was infected on purpose examining the user activity on the malware cases I worked has helped answer the question how did the system become infected.

Closing Thoughts

DFIR has a lot of different techniques to deal with the casework we face. Too many times we tend to focus on the differences; the different tools, different processes, and different meanings of artifacts. Focusing on the differences distracts from seeing what the techniques have to offer. What parts of the techniques can strengthen our processes and make us better regardless of what case we are up against. If I didn’t focus on what the techniques had to offer then I would have missed an opportunity. A chance to develop a better DFIR process by combining malware and fraud techniques; a process that I think is far better than if each technique stood on their own.

Read More