Thursday, November 28, 2019

ActivitesCache.db vs NTUSER.DAT

I recently had an opportunity to work with the data available in the Windows 10 Activity Timeline, or ActivitiesCache.db file.  I'd seen a number of descriptions of the file contents, as well as descriptions of tools, but few of these are from the perspective of a DFIR analyst/responder, and none that I could find provided a view of how the data from the database stands up alongside other data sources an analyst might examine.

First, I grabbed a copy of my own ActivitiesCache.db file:

esentutil /y /vss \ActivitiesCache.db /d ActivitiesCache.db

Then I grabbed a copy of my NTUSER.DAT hive:


I used Eric Zimmerman's WxTCmd tool to parse the database; from the output, I got two CSV files (as described in Eric's blog post for the tool), one for the Activity table.  I then wrote a Perl script to translate elements of the Activity table into the 5-field TLN timeline format that I use for analysis.  This way, I was able to do something of a side-by-side comparison of data from the NTUSER.DAT hive with the contents of the ActivitiesCache.db database. Specifically, I created a timeline using the TLN variants of the UserAssist, RecentDocs, Applets, MSOffice and RecentApps RegRipper plugins, and then added the Activity table data to the events file before parsing it into a timeline.

What I found was pretty interesting.

For one, the data from the Activities table illustrated some interesting activity.  For example, here's what the data looks like for when I opened a PDF document from my desktop:

Wed Nov 20 23:04:15 2019 Z
  TIMELINE                   - End Time:Program Files x86\Adobe\Reader 11.0\Reader\AcroRd32.exe 

Wed Nov 20 23:04:14 2019 Z
  TIMELINE                   - End Time:C:\Users\harlan\Desktop\WRR.exe 

Wed Nov 20 23:00:51 2019 Z
  TIMELINE                   - Start Time:C:\Users\harlan\Desktop\WRR.exe 

Wed Nov 20 22:58:07 2019 Z
  TIMELINE                   - Start Time:Program Files x86\Adobe\Reader 11.0\Reader\AcroRd32.exe C:\Users\harlan\Desktop\A_Forensic_Audit_of_the_Tor_Browser_Bundle4.pdf
  TIMELINE                   - Start Time:Program Files x86\Adobe\Reader 11.0\Reader\AcroRd32.exe

I was doing some research into a particular Registry value, and a search had revealed a hit within the PDF.  I opened the PDF, and while it was open, also opened the MiTeC Windows Registry Recovery (WRR.exe) tool.

Another interesting finding is illustrated below:

Wed Nov 20 22:50:02 2019 Z
  REG                        - RegEdit LastKey value -> Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\TaskFlow
  TIMELINE                   - End Time:Windows\regedit.exe 

Wed Nov 20 22:49:11 2019 Z
  TIMELINE                   - Start Time:Windows\regedit.exe 

Wed Nov 20 22:49:07 2019 Z
  REG                        - [Program Execution] UserAssist - {F38BF404-1D43-42F2-9305-67DE0B28FC23}\regedit.exe (1)
  REG                        - [Program Execution] UserAssist - {0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\Administrative Tools\Registry Editor.lnk (1)

I opened RegEdit, navigated to a specific key, and that key was in focus when I closed RegEdit.  With respect to the LastKey value, we're aware that's the context of the data...the key that was in focus with RegEdit was closed.  What this clearly illustrates is "humanness"...human-based actions occurring and being recorded in these data sources.  We can see from the UserAssist data how RegEdit was opened, we can see how long it was open (in this case, ~50 sec or so), and which key was in focus when it was closed.  Looked at together, these artifacts provide a clear illustration of human activity.

Here's another example of what correlating the two data sources can look like:

Wed Nov 20 21:11:29 2019 Z
  TIMELINE                   - End Time:C:\Users\harlan\Desktop\WRR.exe 

Wed Nov 20 21:10:01 2019 Z
  REG                        - RecentDocs - Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs - local
  REG                        - RecentDocs - Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.dat - NTUSER.DAT
  REG                        - RecentDocs - Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\Folder - local

Wed Nov 20 21:09:45 2019 Z
  TIMELINE                   - Start Time:C:\Users\harlan\Desktop\WRR.exe 
  REG                        - [Program Execution] UserAssist - C:\Users\harlan\Desktop\WRR.exe (1)

In this particular case, I'd opened WRR and loaded an NTUSER.DAT file from a folder called "local".

Here's an example of how correlating the two data sources can provide additional insight and context into accessing files:

Wed Nov 20 20:20:56 2019 Z
  REG                        - RecentDocs - Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.doc - Armor of God.doc
  TIMELINE                   - End Time:Program Files x86\Microsoft Office\Office14\WINWORD.EXE 

Wed Nov 20 20:09:29 2019 Z
  REG                        - Word File MRU - C:\Users\harlan\Desktop\Armor of God.doc
  REG                        - Word Place MRU - C:\Users\harlan\Desktop\

Wed Nov 20 20:09:28 2019 Z
  TIMELINE                   - Start Time:Program Files x86\Microsoft Office\Office14\WINWORD.EXE 
  REG                        - [Program Execution] UserAssist - {7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\Microsoft Office\Office14\WINWORD.EXE (5)

In this particular case, I was preparing for Bible study and had a Word document open.  The data from the Activity Timeline database showed that MSWord had been opened, but it took data from the NTUSER.DAT hive (RecentDocs and MSOffice plugins) to provide information about which file had been opened.  In this case, the data illustrates that I'd had the file open approximately 11 minutes.

I could go on with the examples but suffice to say that the ActivitiesCache.db data provides context and validation to data from other sources; in this case, from data from the NTUSER.DAT hive associated with user activity.  Adding additional data from other sources, such as Automatic JumpLists would not only provide additional context, but would be extremely valuable in the face of anti-forensics efforts.  Getting a good view of what constitutes artifact clusters will also help us seen when elements from those clusters are missing, potentially through deletion efforts.

Further, the correlation of multiple data sources gives us a better view not only of artifact clusters, but also of past activities.  As I went through the timeline data, I was references to files and applications that no longer existed on my system. I also saw references to files on external data sources (F:\, G:\, etc.), as well.

Something else I found as a result of this exercise was that the first entry in the database table appears to be dated 20 Jun 2019.  Based solely on the data available, it would appear that an update was applied, as I'm also seeing all of the LastWrite times for RecentDocs subkeys set to the same time shortly before the first entry in the database.  A quick query via WMIC reveals that a security update was installed on that day, for KB4498523.  The finding is reminiscent of what Jason Hale discussed in his blog post regarding shellbags and a Win10 feature update.

Going Deeper
A while back, Mari had written a tool to parse deleted entries from a SQLite database, so I thought I'd give it a shot.  I downloaded the CLI version of the tool, and after running it, got a TSV file that I opened up in Excel.  There were a total of 630 rows, not all of which seemed to have much data, let alone much data of value.  However, many of the rows contained what looked like extensive JSON-formatted data.  A number of these contained references to files I'd opened in Notepad++, including the full path to the file, as well as the following:


So, much like other data sources, it appears that deleted items from this database file can provide additional insight and context, as well.

Additional Resources:
GroupIB writeup
Salt4n6 writeup
CCLGroup LTD writeup
Journal of Forensic Science paper article - lists descriptive resources, and tools, including Mark McKinnon's Autopsy plugin
PureInfoTech article - disabling the Timeline Activity feature (be sure to look for this being used for anti-forensics, or check the value if you're not finding the ActivitiesCache.db file)

kacos2000 - WindowsTimeline
forensicMatt - ActivitiesCacheParser
Eric Z's Tools site
TZWorks - Timeline ActivitiesCache parser
Mari's SQLParser tools

Saturday, November 02, 2019

More Regarding LNK Files

My recent post regarding LNK files got me thinking about other uses of LNK files.  That previous post really illustrated how some analysts are following Jesse Kornblum's adage of "using every part of the buffalo", in that they made use of everything (or as close to it as they could) they had available in order to develop a #threatintel picture.

This got me to thinking...taking a step back, how else can LNK files be used?

DFIR Analysis
Some DFIR analysts are aware of the fact that when analyzing Windows systems, you're going to find Windows shortcut/LNK files in a number of locations.  For example, there're the user's desktop, the user's Recent folder, etc.  In addition, Automatic JumpList files are OLE structured storage format files, and all but one of the streams follow the LNK file format. So, the file format is widely used on Windows systems, and the location of the file or stream provides some useful context that can also be applied to the content.

LNK files contain a good bit of metadata, as they contain shell items (as do other artifacts, such as shellbags), which are blobs of binary data that describe various objects on Windows systems.  In the case of folder objects, specifically, one of the elements found to be embedded within the metadata is the MFT reference number for that folder object.  This reference number is comprised of the record number (i.e., location within the MFT), as well as the sequence number (in short, "...this is the nth time this record has been used.") what?

Well, when it comes to artifacts of use, or more specifically, file access, the LNK files created as a result of user activity can remain on the system long after the files and applications with which they're associated have been removed or deleted.  Say that you're investigating access to a particular file (by name or folder path) and your goal is to illustrate that the user had knowledge of that file.  If the user accessed the file by double-clicking on it, an LNK file will have been created, and that file will persist well beyond the deletion of the target file itself.  These artifacts will also persist beyond the removal of the associated application, as well.

This can be useful to us because it gives us something of a historical view of the file system. For example, let's say that the per the MFT, record number 2357, with sequence number 5, points to a folder on the user's desktop called "Personal Stuff".  Now, suppose we find a LNK file that points to the fact that the user opened a file that was located in a folder named "Hacker Tools", and the MFT reference number extracted from the LNK file is 2357/4, or 2357/3.  This provides us with a view of what the file system used to look like, giving us something a historical "smear" of the file system.

Also, these LNK files can provide information regarding external devices, as well.  The basic shell items are created in the user's shellbags when they use Windows Explorer to navigate folders on an external device, such as a USB thumb drive, USB-connected smartphone, etc.  Then if they open files, shell items are created to populate LNK files pointing to those files. 

Adversary Persistence
Adversaries have been observed persisting beyond password updates by modifying the iconfile name attribute of an LNK file to point to a resource that they (the adversary) control.  What happens if the LNK file is at the root of a directory is that when a user/admin browsers to the folder, Windows parses the file and attempts to load the icon from the remote resource, using the user's credentials to authenticate, first via SMB, and then via WebDAV.

Other Ways To Use LNK Files
"Using" LNK files can apply to the adversary, as well as to an analyst (DFIR, intel, etc.). There's this write-up on Kovter, describing how the adversary uses/used LNK files, and there's this BitOfHex blog post describing how to derive intel from LNK files.  There's also hexacorn's older blog post regarding the use of hotkeys and LNK files, and this USCERT alert that describes the use of the adversary persistence technique described above (not 'new' or an 'other' use, but placed here as an illustration).