May | 2016 | Count Upon Security

Let’s continue our digital forensics journey and start where we left off. To contextualize the reader, the posts below are the previous articles on this series:

We now want to find traces of the DLL – CLB.DLL – that was invoked from the wrong directory and understand what happened e.g., was it deleted by the attacker? To support our quest we need to look deep into the NTFS file system.

One of the first articles I wrote on this series was a brief explanation about the NTFS metadata and the Master File Table – which might give you more background on the topic below. To summarize, the Master File Table (MFT) is a special system file that resides on the root of every NTFS partition. The file is named $MFT and is not accessible via user mode API’s but can been seen when you have raw access to the disk e.g, forensic image. This special file is a hierarchical database and inside you have records that contains a series of attributes about a file, directory and indicates where it resides on the physical disk and if is active or inactive. The size of each MFT record is usually 1024-bytes. In the last post we reviewed three relevant attributes of the MFT records ; the $STANDART_INFORMATION, the $FILENAME and $DATA. The first two are rather important because among other things they contain the file time stamps..

In this article we will look at the MFT records for directories (further down we will also look at the NTFS Journaling).

Why? Because the MFT records for directories contain a special attribute called $I30. This attribute contains information about file names and directories that are stored inside a particular directory. This special attribute is also known as $INDX and consists of three attributes, the $INDEX_ROOT, $INDEX_ALLOCATION and $BITMAP.

So, What? Well, this attribute stores information in a B-tree data structure in order to keep data sorted so the operating system can perform fast searches in order to determine if a file is present. In addition, this attribute grows in size in order to keep track of file names inside the directory. However, when you delete a file from a directory the B-tree re-balances itself but the tree node with metadata about the deleted file remains in a form of slack space until it gets reused. This means we can view the $I30 attribute contents and we might find evidence of files that once existed in a particular directory but are no longer there. The contents of the $I30 attribute contain the file name, the MACE time stamps from the $FILE_NAME, the file size and the MFT entry number for the file and parent directory.

How can we see the $I30 contents for a particular directory? We will cover two different methods. First method, is a manual approach using the tools available in The Sleuth Kit to extract it and then we use the INDXParser.py tool from Willi Ballenthin to parse its contents. The second method is faster and we will use the tool LogFileParser from Joakim Schicht.

Let’s cover the first approach using the SIFT workstation. You can view the $INDX contents in four steps:

Use fls against a disk image or ls against a mounted imaged to get the MFT entry number for the directory we want to analyze. In this case the Windows directory.
Use istat to get the identifier number for the $I30 attribute. You can also verify if it contains resident data.
Use icat to dump the $INDX contents into a file.
Use INDXParser.py to parse its contents and view file names, size and MACE timestamps.

The image below illustrates the first step where we use fls to read the EWF disk image and get the its contents.

The image below illustrates the second step where we can view the MFT record properties for the entry number 506.

In our case the Windows folder is stored in the MFT entry number 506 and the identifier we are looking is the 160 which points to the contents of the $INDX. The identifier 144 points to the root node. With this information, we can dump the data using icat. Then we execute INDXParser.py with the suffix –d in order to search in slack space.

Unfortunately, in this case we could not find traces of our DLL. This might occur due to the B-tree nodes of the $I30 data structure being reused. This happens due to the normal file system activity. Normally, there is good chance to find evidence about deleted files in the $I30 attributes using the first method. But if for some reason we couldn’t find any traces we could try the second method.

The second method relies on LogFileParser.exe to parse a different NTFS metadata file which is called $LOGFILE. Before we try this method let’s review what is the $LOGFILE. NTFS has been developed over years with many features in mind, one being data recovery. One of the features used by NTFS to perform data recovery is the Journaling. The NTFS Journal is kept inside NTFS Metadata in a file called $LOGFILE. This file is stored in the MFT entry number 2 and every time there is a change in the NTFS Metadata, there is a transaction recorded in the $LOGFILE. These transactions are recorded in order to be possible to redo or undo file system operations. After the transaction has been logged then the file system can perform the change. When the change is done, another transaction is logged in the form of a commit. The $LOGFILE allows the file system to recover from metadata inconsistencies such as transactions that don’t have a commit. The size of the $LOGFILE can be consulted and changed using chkdsk /l and per default is 65536 KB.

Why would $LOGFILE be important for our investigation? Because the $LOGFILE keeps record of all operations that occurred in the NTFS volume such as file creation, deletion, renaming, copy, etc. Therefore, we might find traces of our file here.

Now, let’s use our second method. We had to give you context about the $LOGFILE because the LogFileParser.exe is able to parse $INDX attributes based on information available in the transaction logs. We will now use the powerful, granular tool developed by Joakim Schicht called LogFileParser. For those who are not familiar with Joakim Schicht, he is a brilliant engineer and researcher who has enormously contributed to the Forensics community with many powerful tools. This tool -LogFileParser – is a fantastic tool for low level analysis of the NTFS. It runs on Windows and we can point it to our mounted evidence in the SIFT workstation.

The output is quite verbose and you can read about its capabilities and meanings in the README file. The parsing won’t take long and then we can analyze the output by just grepping for our file.

When searching for our missing and malicious DLL across the LogFileParser output files we found evidence of it on INDX attributes and transaction logs.
Based on the transaction operations recorded on the $LOGFILE we can see evidence that the CLB.DLL file was created on the WINDOWS folder at 22:43:58 and seconds after the file was renamed to CLB.DLLBAK and finally deleted. This time stamp matches the Prefetch and Shimcache artifacts.. We can see it was created on the Windows folder because of the parent MFT entry number 506 which matches the Windows MFT entry we were analyzing in the beginning. Quite fascinating facts that we observed by looking at the $INDX attribute and the $LOGFILE from NTFS metadata.

That’s it! In this article we reviewed NTFS metadata and different tools and techniques that we can leverage to view artifacts about evidence of deleted files . The INDX attribute which is used to store metadata about files inside directories and the $LOGFILE which keeps record of all operations that occurred in the NTFS volume. Both this artifacts can give us a great amount of information and detail about attacker activity and should be part of your forensic toolkit. We now have another piece of our investigation that we can put into our SuperTimeline.

If you want to read more about $INDX attributes there is a great article written in 2011 by Chad Tilbury here. In addition William Ballenthin & Jeff Hamm wrote a four part blog post series with great detail about the $INDX attributes.

References:

Windows Internals, Sixth Edition, Part 2 By: Mark E. Russinovich, David A. Solomon, and Alex Ionescu
File System Forensic Analysis By: Brian Carrier
https://github.com/jschicht/LogFileParser

Tagged Digital Forensics, LogFileParser, NTFS $I30, NTFS INDX, NTFS Metadata, UsnJrnl

May 24 2016

Digital Forensics – DLL Search Order

Following our series of posts on Digital Forensics we will continue our journey about analyzing our compromised system. In the last two articles we covered Windows Prefetch and Shimcache. Among other things, we wrote that Windows Prefetch and ShimCache artifacts are useful to find evidence about executed files and executables that were on the system but weren’t execute. While doing our investigation and looking at these artifacts, the Event Logs and the SuperTimeline, we found evidence that REGEDIT.EXE was executed. In addition, from the Prefetch artifacts we saw this execution invoked a DLL called CLB.DLL from the wrong path. On Windows operating systems CLB.DLL is located under %SYSTEMROOT%\System32. In this case CLB.DLL was invoked from %SYSTEMROOT%.

However, when we looked inside the %SYSTEMROOT% folder and we could not find any traces of the CLB.DLL file. This raised the following questions:

How did this file got loaded from the wrong PATH?
Did file got deleted by the attacker?

Let’s answer the first question.

Inside PE files there is a structure called Import Address Table (IAT) that contains the addresses of the library routines that are imported from DLL’s. When an application is launched the operating system will check this table to understand which routines are needed and from which DLL’s. For example, when I execute REGEDIT.EXE the binary has a set of dependencies needed in order to execute. To see this dependencies, you can look at the IAT. On Windows you could use dumpbin.exe /IMPORTS or on REMNUX you could use pedump as illustrated below.

But from where will this DLL’s be loaded from? The operating system will locate the required DLL’s by searching a specific set of directories in a particular order. This is known as the DLL Search Order and is explained here. This mechanism can and has been abused frequently by attackers to plant a malicious DLL inside a directory that is part of the DLL Search Order mechanism. This will trick the Windows operating system to load the malicious DLL instead of the real one. The DLL Search Order by default on Windows XP and above is the following:

The directory from which the application loaded.
The current directory.
The system directory.
The 16-bit system directory.
The Windows directory.
The directories that are listed in the PATH environment variable.

Not all DLL’s will be found using the DLL Search Order. There is a mechanism known as KnownDLLs Registry Key which contains a list of important DLL’s that will be invoked without consulting the DLL Search Order. This key is stored in the registry location HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs.

Throughout the years Microsoft patched some of the problems with DLL Search Order mechanism and also introduced some improvements. One is the Safe DLL Search Order Registry which changes the order and moves the search of “The Current Directory” to the bottom making harder for the attacker without admin rights to plant a DLL in a place that will be searched first. This feature is controlled by the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode.

Bottom-line, this technique is known as DLL pre-loading, side-loading or hijacking and is an attack vector used to takeover a DLL and escalate privileges or achieve persistence by taking advantage of the way DLL’s are searched. This technique can be pulled off by launching an executable that is not in %SYSTEMROOT%\System32 – like our REGEDIT.EXE – or by leveraging weak Directory Access Control Lists (DACLS) and dropping a malicious DLL in the appropriate folder. In addition, for this technique to work the malicious DLL should contain the same exported functions and functionality has the hijacked DLL or work as proxy in order to ensure the executed program will run properly. The picture below shows the routines that are exported by the malicious DLL. As you could see these are the same functions like the ones required by REGEDIT.EXE from the CLB.DLL.

To further understand the details, you might want to read a write-up on leveraging this technique to escalate privileges described by Parvez Anwar here and to achieve persistence described by Nick Harbour here. Microsoft also gives guidance to developers on how to make applications more resistant to this attacks here.

Considering the REGEDIT.EXE example we can see from where the DLL’s are loaded on a pristine system using Microsoft Windows debugger like CDB.EXE. Here we can see that CLB.DLL is loaded from %SYSTEMROOT%\System32.

We have now a understanding about how that DLL file might have been loaded. DLL sideloading is a clever technique that load malicious code and is often used and abused to either escalate privileges or to achieve persistence. We found evidences of it using the Prefetch artifacts but without Prefetch e.g., a Windows Server, this won’t be so easy to find and we might need to rely on other sources of evidence like we saw on previous articles. Based on the evidence we observed we consider that the attacker used DLL sideloading technique to hijack CLB.DLL and execute malicious code when invoking REGEDIT.EXE. However, we could not find this DLL file on our system. We will need to look deeper and use different tools and techniques that help us find evidence about it and answer the question we raised in the begging. This will be the topic of the upcoming article!

References:
Luttgens, J., Pepe, M., Mandia, K. (2014) Incident Response & Computer Forensics, 3rd Edition
Carvey, H. (2014) Windows Forensic Analysis Toolkit, 4th Edition
Russinovich, M. E., Solomon, D. A., & Ionescu, A. (2012). Windows internals: Part 1
Russinovich, M. E., Solomon, D. A., & Ionescu, A. (2012). Windows internals: Part 2

Tagged Digital Forensics, DLL Hijacking, DLL Search Order, DLL Side-loading

May 18 2016

2 Comments

Digital Forensics and Incident Response, Incident Handling and Hacker Techniques

Digital Forensics – ShimCache Artifacts

Following our last article about the Prefetch artifacts we will now move into the Windows Registry. When conducting incident response and digital forensics on Windows operating systems one of the sources of evidence that is normally part of every investigation is the Windows Registry. The Windows Registry is an important component of the OS and applications functionality, maintains many aspects of its configuration and plays a key role on its performance. As written by Jerry Honeycutt on his books the Windows Registry is the heart and soul of modern Windows operating systems. The Windows Registry is a topic for a book on its own, either from a systems or a forensics perspective. One great example is the book “Windows Registry Forensics 2nd Edition“ from Harlan Carvey.

In any case, from a forensics perspective, the Windows registry is a treasure trove of valuable artifacts. Among these artifacts you might be looking at System and Configuration Registry Keys, Common Auto-Run Registry Keys, User Hive Registry keys or the Application Compatibility Cache a.k.a. ShimCache.

In this article we will look into the Application Compatibility Cache a.k.a. ShimCache. When performing Live Response or dead box forensics on Windows operating systems one of the many artifacts that might be of interest when determining which files have been executed and were accessed is the ShimCache. In our last article we mentioned the Prefetch where you could get evidence about a specific file being executed on the system. However, on Windows Servers operating systems, the Prefetch is disabled by default. This means the ShimCache is a great alternative and also a valuable source of evidence.

Let’s start with some background about the ShimCache. Microsoft introduced the ShimCache in Windows 95 and it remains today a mechanism to ensure backward compatibility of older binaries into new versions of Microsoft operating systems. When new Microsoft operating systems are released some old and legacy application might break. To fix this Microsoft has the ShimCache which acts as a proxy layer between the old application and the new operating system. A good overview about what is the ShimCache is available on the Microsoft Blog on an article written by Tim Newton “Demystifying Shims – or – Using the App Compat Toolkit to make your old stuff work with your new stuff“.

The interesting part is that from a forensics perspective the ShimCache is valuable because the cache tracks metadata for binary that was executed and stores it in the ShimCache. Nevertheless, it wasn’t until 2012 when Andrew Davis wrote ” Leveraging the Application Compatibility Cache in Forensic Investigations” and released the ShimCache Parser tool that the value of this evidence source came widely known. This was a novel paper because Andrew made available a tool that could extract from the registry information about the ShimCache that is valuable for an investigation. The paper outlines the internals of the ShimCache and where the data resides on the different Windows operating systems.

On Windows XP this data structure is stored under the registry key HKLM\CurrentControlSet\Control\Session Manager\AppCompatibility\AppCompatCache. On recent Windows the ShimCache data is stored under the registry key HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache

In the ShimCache we can obtain information about all executed binaries that have been executed in the system since it was rebooted and it tracks its size and the last modified date. In addition the ShimCache tracks executables that have not been executed but were browsed for example through explorer.exe. This makes a valuable source of evidence for example to track executables that were on the system but weren’t executed – consider an attacker that used a directory on a system to move around his toolkit.

On Windows XP the ShimCache maints up to 96 entries but on Windows 7 and earlier the ShimCache can maintain up to 1024 entries. Using the ShimCache Parser we can parse and view its contents. We only need to point to the SYSTEM registry hive file on our mounted evidence as illustrated below.

Nonetheless, the ShimCache as one drawback. The information is retained in memory and is only written to the registry when the system is shutdown. This impacts the ability of getting this source of evidence when conducting live response. To address this limitation Fred House, Claudiu Teodorescu, Andrew Davis wrote a Volatility plugin to read the ShimCache from memory. The plugin supports Windows XP SP2 through Windows 2012 R2 on both 32 and 64 bit architectures. This plugin won the volatility plugin contest of 2015. A write-up about it is available here and here. The plugin can be downloaded from the Volatility Community plugins page. The picture below illustrates the usage of Volatility with the ShimCacheMem plugin against the memory of the analyzed system.

By looking at the ShimCache either directly from memory or by querying the registry after system shutdown we can – in this case – confirm the evidence found in the Prefetch artifacts. On a Windows Server system because by default the Prefetch is disabled the ShimCache becomes a more valuable artifact.

Given the availability of this artifact across all Windows operating systems, the information obtained from the ShimCache can be valuable to an investigation. In this case, the ShimCache supported the findings of Prefetch on regedit.exe and rundll32.exe being executed on the system.

There are more artifacts associated with this feature. In 2013, Corey Harrell wrote on his blog his findings about the Windows 7 RecentFileCache.bcf file. Essentially, this file is maintained in %SYSTEMROOT%\AppCompat\Programs\ directory and keeps metadata (PATH and filename) about executable that are new in the system since the last time the service Application Experience was run. Yogesh Khatri, continued to research Corey findings and found that on Windows 8 this file has been replaced with a registry HIVE called amcache.hve which contains more metadata. From this file you can retrieve for every executable that run on the system the PATH, last modification time & created, SHA1 and PE properties. Meanwhile, Yogesh noted that on Windows 7 you could also have the amcache.hve if you have installed KB2952664. To read the amcache HIVE you could use RegRipper or Willi Ballenthin stand-alone script.

The ShimCache has not only been used from a defensive perspective. From a offensive perspective, the ShimCache has been used several times by attacker. One of the best resources I’ve come across about the ShimCache is the website “sdb.tools” created by Sean Pierce dedicated to Application Compatibility database research and where he maintains his research and lists different tools, papers and talks.

That’s it, we went over a brief explanation on what is ShimCache, its artifacts, where to find it in memory and in the registry and which tools to use to obtain information from it. Next, we will go back to our SuperTimeline and continue our investigation.

References:
Luttgens, J., Pepe, M., Mandia, K. (2014) Incident Response & Computer Forensics, 3rd Edition
SANS 508 – Advanced Computer Forensics and Incident Response

Tagged AmCache, AppCompatCache, Artifacts, Digital Forensics, ShimCache, ShimCacheMem

May 16 2016

Digital Forensics – Prefetch Artifacts

It has been a while since my last post on digital forensics about an investigation on a Windows host. But it’s never too late to start where we left. In this post we will continue our investigation and look into other digital artifacts of interest. To summarize what we have in this series of posts:

Following the last post, based on the different Event Log ID’s across our super timeline we found evidence that someone used Remote Desktop to login into the system as Administrator. Moments after, the Administrator made a modification to a “svchosted” system service, changing it to interactive and running it. There is also evidence that this service crashed. Based on the time when all these events occurred we will look into other artifacts in our Super Timeline around the same timeframe.

The leads that were obtained from Windows Event Log’s will facilitate the analysis of our Super Timeline going forward. This allow us to reduce the time frame and narrowing it down. Essentially we will be looking for artifacts of interest that have a temporal proximity with the event of the administrator logging in. The goal is to investigate further understand what has happened and what actions did the attacker did on our system.

That being written, which artifacts should we look next? We will start with Prefetch.

Let’s start with a brief explanation about Windows Prefetch. To improve customer experience, Microsoft introduced a memory management technology called Prefetch. This functionality was introduced into Windows XP and Windows 2003 Server. This mechanism analyses the applications that are most frequently used and preloads them in advance in order speed the operating system booting and application launching. On Windows Vista, Microsoft enhanced the algorithm and introduced SuperFetch which is an improved version of Prefetch.

The Prefetch files are stored in %SYSTEMROOT%\Prefetch directory and have a .pf extension. The Prefetch settings that are enforced can be retrieved from the Windows registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters. You can read this setting easily with the brilliant tool created by Harlan Carvey called RegRipper and use the Prefetch plugin.

On Windows XP and 7, there are a maximum of 128 .pf files. On Windows 8 this value can reach a maximum of 1024 .pf files. The file names are stored using the convention <executable filename>-<Prefetch hash>.pf. Worth to mention that this mechanism is disabled by default on Server operating systems. In addition there have been cases where SSD drives have this mechanism disabled.

The internal format of windows Prefetch files have been documented extensively by Joachim Metz here. This documentation is part of libscca which is a library to access the Windows Prefetch File (SCCA) created by Joachim and can be used parse and read the Prefetch files from different operating systems. Matt Bromiley created a ready available script based on this library to read Windows 10 Prefetch files.

So, other than the Prefetch internals what is the forensic value of the Prefetch artifacts’? The answer is that the Prefetch files keep track of programs that have been executed in the system even if the original file is no longer present. In addition Prefetch files can tell you when the program was executed, how many times and from which path.

Now that we have a basic understanding about Prefetch we will go back to our Super timeline analysis. Plaso supports Windows Prefetch events which we can be corroborated with FILE events and the Windows Event Logs. From the previous blog post analysis we were able to see evidence of when the Administrator logged into the system. And we know that when a user logs into the system, the initial Session Manager (smss.exe) creates a new instance of itself to configure the new session. The new Smss.exe process starts a Windows subsystem process (csrss.exe) and Winlogon process (winlogon.exe) for the new session. This sequence of Windows Events ID 4688 – you need audit process tracking enabled to view this one – can be corroborated with the WinPrefetch and FILE artifacts based on the temporal proximity. The picture below illustrates these events that were retrieved from the Super Timeline moments after the logon events.

When combining the Events Logs, Windows Prefetch and File artifacts we start to bring together the different pieces of the puzzle and a start to form a picture of what happened. After looking at the result of the consolidated artifacts of interest in a single view and remove the noise we can conclude that: On the 9th of October, around 22:42:22 the user account Administrator was used to login into the system. The login was performed from a system with the IP 189.62.10.9 (Brazil). Then based on the Prefetch artifact we have evidence that the user Administration executed the application rundll32.exe following by regedit.exe. Next, the Windows system service FastUserSwitchingCompatibility service was changed and started. Finally a file cache.txt was created in the system. All this events are supported by evidence retrieved from our Super Timeline and can be shown in the following picture.

Now, with the consolidated view of the different artifacts we continue pursuing the investigation and looking further into those prefetch files. To determine when was the first and the most recent time the binary was executed you can use istat from The Sleuth Kit to read the NTFS metadata entry for the file to get the timestamps.

In addition, to the execution times, we still need to read the content of the Prefetch files itself. These are useful because in addition to the last execution and how many times they were run, it includes the full path and files loaded by the application in the first 10 seconds of its execution. An exception to this is the NTOSBOOT-B00DFAAD.pf which exists on all systems and keeps tracks of the files accessed during the first 120 seconds of the boot process. The full path and files are valuable because they might show evidence of files being loaded from different paths or invoking unknown binaries.

To read the contents of the Prefetch files you could run strings with little endian encoding (strings -e l) as a quick and dirty method to view its contents. A more robust method would be o use Joachim Metz libssca and create a Python script to read it.

For a readily available Python tool you could use Python script written by the researcher who uses as handler PoorBillionaire which is available here.

If you are a windows user then you could compile and use Eric Zimmerman’s Windows Prefetch parser which supports all known versions from Windows XP to Windows 10. In conjunction with the library Eric also released PECmd which is version 0.6 as the time of this writing. Another method is to use the Windows freeware tool from NIRSOFT called WinPrefetchView. With the /folder suffix you can point to the Prefetch folder of your mounted evidence and see its contents

In this case when looking at the Prefetch files from the regedit.exe we found evidence that regedit.exe invoked a DLL called clb.dll from a location that is not supposed to. This give us another lead to pursue our investigation goals.

That’s it! In this article we reviewed some introductory concepts about the Windows Prefetch files, it’s forensic value and gave good references about tools to parse it. Next step, continue the investigation and review more artifacts’.

References:
Luttgens, J., Pepe, M., Mandia, K. (2014) Incident Response & Computer Forensics, 3rd Edition
Carvey, H. (2014) Windows Forensic Analysis Toolkit, 4th Edition
SANS 508 – Advanced Computer Forensics and Incident Response

Tagged Forensic Investigation, Forensic value of Windows Prefetch, Prefetch Parser, SuperTimeline, Windows Prefetch

Count Upon Security

Increase security awareness. Promote, reinforce and learn security skills.

Monthly Archives: May 2016

Digital Forensics – NTFS INDX and Journaling

Digital Forensics – DLL Search Order

Digital Forensics – ShimCache Artifacts

Digital Forensics – Prefetch Artifacts