Distros and RegRipper, pt deux

Now and again I pop my head up and take a look around to see where RegRipper has been, and is being, used. My last blog post on this topic had quite a few listings, but sometimes changing the search terms reveals something new, or someone else has decided to use RegRipper since the last time I looked.

References to RegRipper go way back, almost as far as RegRipper itself (circa 2008):
SANS blog (2009)
SANS blog (2010)
SANS Infosec Handler's Diary blog (2012)
Kali Tools (RR v2.5)
SANS Blog, Mass Triage, pt 4 (2019)

The latest commercial forensics platform that I've found that employs RegRipper is Paraben E3. I recently took a look at the evaluation version, and found "rip.pl" (RegRipper v3.0 with modifications) in the C:\Program Files\Paraben Corporation\Electronic Evidence Examiner\PerlSmartAnalyzer folder, along with the "plugins" subfolder.

You can see the Registry parsing in action and how it's incorporated into the platform at the Paraben YouTube Channel:
AppCompatCache parsing
Reviewing Data from AmCache

Reviewing the videos, there's something very familiar about the output illustrated on-screen. ;-)

Other Resources (that incorporate RegRipper)
YouTube video by Ric Messier
CAINE forensics video
PacktPub Subscription
LIFARS Whitepaper on Shellbags
Windows Registry Forensics, 1/e (PDF)
Paradigm Solutions blog
Jason Shaver's NPS thesis (2015)

That's just one more step toward world domination! This is where I tent my fingers and say "Excellent" like Mr. Burns!

PS: While I was looking around recently, I saw something I hadn't seen before...early in Jan, 2020, an issue with the Parse::Win32Registry module parsing 64-bit time stamps was identified. I'd updated the module code, recompiled the EXEs, and put them up on Github. 

I found recently that James, the author of the module, had updated it in Sept, 2020. That's great, but there are a few other tweaks I'd made to the code, one that allowed me to check to see if hives are 'dirty'. 

USB Device Redux, with Timelines

If you ask DFIR analysts, "What is best in life?", the answer you should hear is, "...creating timelines!" After all, industry luminaries such as Andrew said, "Time is the most important thing in life, and timelines are one of the most useful tools for investigation and analysis.", and Chris said, "The timeline is the central concept of all investigative work."

My previous blog post addressed USB-connected devices, but only from the perspective of Windows Event Logs. In this blog post, I wanted to include data from the Registry, incorporated in a timeline so that the various data sources could be viewed through a common lens, in a single pane of glass. 

I stated by using wevtutil.exe to export current copies of the five Windows Event Logs to a central location. I then used reg.exe to do the same thing for the System hive. I then used my timeline process (outlined in several of my books) to create the events file from the six data sources; I used wevtx.bat to parse the Windows Event Logs, and three newly created RegRipper Pro plugins to parse the relevant data from the System hive. The specific keys, values and data parsed from the hive were based largely on Yogesh's blog post, and this academic paper posted at the ResearchGate site. I created the initial plugins, and then modified them to display TLN-format output, for inclusion in timelines.

For this research, there where three specific devices I was interested in...my iPod, my iPhone, and a SanDisk Cruzer USB thumb drive. After creating the overall events file, I used the "type" and "find" commands to look for events associated specifically with those devices, isolated each into their own individual "overlay" events file, and then created timelines from each of those events files. This approach makes it easy to "see" what's going on and create artifact constellations, as I don't have to filter out "noise" associated with other events, and I still have the overall events file that I refer to. 

What I'm sharing below are partial timelines of events, just enough to demonstrate events based on intentionally limited data sources, so that initial artifact constellations can be developed. From this point, the constellations can be built out; for example, accessing files the SanDisk Cruzer will produce Windows shortcut files pointing to files on the "E:\" volume. Again, these timeline overlays are not complete, but are intended to demonstrate Registry artifacts associated with USB-connected devices alongside Windows Event Log artifacts.

iPod

A while back, I inserted my iPod into my computer in order to retrieve music files, via iTunes, so that I could transfer them to my iPhone. I didn't think much about it at the time, but the connection was clearly "remembered" by Windows 10, specifically via the Registry.

Here are the events around the insertion:

Sun Jan  2 19:41:21 2022 Z

  REG                        - First Inserted - Apple iPod [6&3091e96e&0&0000]

  REG                        - First Install - Apple iPod [6&3091e96e&0&0000]

  EVTX     Stewie     - Microsoft-Windows-WPD-MTPClassDriver/1005;Apple Inc.,Apple iPod,4.3.5,40

  REG                        - Last Inserted - Apple iPod [6&3091e96e&0&0000]

Sun Jan  2 19:41:15 2022 Z

  EVTX     Stewie            - Microsoft-Windows-DeviceSetupManager/112;iPod,{fc916355-34ea-555c-9e24-3c59f6125097},2,42,11

And here are the events around the removal of the device from the computer, a little more than 14 minutes later:

Sun Jan  2 19:55:46 2022 Z

  REG                        - Last Removal - Apple iPod [6&3091e96e&0&0000]

The completed message string for the "Microsoft-Windows-DeviceSetupManager/112" event above is:

Device 'Apple iPod' ({fc916355-34ea-555c-9e24-3c59f6125097}) has been serviced, processed 6 tasks, wrote 34 properties, active worktime was 11748 milliseconds.

I state this specifically because following the "Last Removal" event on 2 Jan 2022, the timeline contains an additional 9 events from 6 Jan to 22 May, all for the same "Microsoft-Windows-DeviceSetupManager/112" event records for the iPod, but the last three string entries are different. In every case, only 1 task is run, and the active worktime runs from 0 to 31 milliseconds. I know that the iPod was not plugged in during these times, and as such, this seems to be an artifact the installation process.

iPhone

I have connected my iPhone to this Windows 10 system via a USB cable, to transfer pictures from it, and to transfer music files to it, via iTunes. Here was see one such connection on 7 May 2022:

Sat May  7 14:16:35 2022 Z

  REG                        - Last Removal - @oem119.inf,iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device [00008030000E6C6C11DA802E]

  REG                        - Last Removal - Apple iPhone [6&139bb8e1&1&0000]

Sat May  7 14:14:57 2022 Z

  EVTX     Stewie            - Microsoft-Windows-WPD-MTPClassDriver/1005;Apple Inc.,Apple iPhone,15.4.1,40

  EVTX     Stewie            - Microsoft-Windows-DeviceSetupManager/112;Apple iPhone,{7e8068a1-2d62-53fb-8285-a12072dfa871},4,34,296

Sat May  7 14:14:56 2022 Z

  REG                        - Last Inserted - Apple iPhone [6&139bb8e1&1&0000]

  REG                        - Last Inserted - @oem119.inf,iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device [00008030000E6C6C11DA802E]

There's information later in the timeline regarding another connection to the system, this time to copy pictures off of the iPhone. The "Last Inserted" and "Last Removal" events are from a different Registry key as seen above, as noted by the serial number in brackets at the end of the "event".

Fri Apr 15 16:23:13 2022 Z

  REG                        - Last Removal - @oem119.inf,iphone.appleusbmux.devicedesc%;Apple Mobile Device USB Device [6&139bb8e1&1&0001]

...

Fri Apr 15 16:19:02 2022 Z

  EVTX     Stewie            - Microsoft-Windows-WPD-MTPClassDriver/1005;Apple Inc.,Apple iPhone,15.4.1,40

Fri Apr 15 16:18:57 2022 Z

  EVTX     Stewie            - Microsoft-Windows-DeviceSetupManager/112;Apple iPhone,{7e8068a1-2d62-53fb-8285-a12072dfa871},4,34,140

  REG                        - Last Inserted - @oem119.inf,iphone.appleusbmux.devicedesc%;Apple Mobile Device USB Device [6&139bb8e1&1&0001]

Cruzer

The artifact constellation for the SanDisk Cruzer thumb drive is a bit different from that of the iPhone and the iPod. In this case, the events around the last time the device was inserted and then removed from the computer is less than a minute...

Mon May 16 22:07:08 2022 Z

  EVTX     Stewie            - Microsoft-Windows-Partition/1006;1,8208,262401,false,0,0,0,0,0,7,SanDisk,Cruzer,8.02,2443931D6C0226E3,...

  REG                        - Last Removal - SanDisk Cruzer USB Device

  REG                        - Last Removal - Cruzer   [E:\]

Mon May 16 22:06:26 2022 Z

  EVTX     Stewie            - Microsoft-Windows-Ntfs/145;3,{1e09345e-d3d4-11e8-92fd-1c4d704c6039},2,E:,false,0,{fab772f6-83e6-5d5f-1086-740d39e45bff},8,SanDisk ,16,Cruzer ...

  EVTX     Stewie            - Microsoft-Windows-Partition/1006;1,8208,262401,false,0,0,0,512,8036285952,7,SanDisk,Cruzer,8.02,2443931D6C0226E3,Integrated : ...

Mon May 16 22:06:24 2022 Z

  EVTX     Stewie            - Microsoft-Windows-Partition/1006;1,8208,262401,false,0,0,0,0,0,7,SanDisk,Cruzer,8.02,2443931D6C0226E3,...

  EVTX     Stewie            - Microsoft-Windows-DeviceSetupManager/112;Cruzer,{81fa6fcf-bfc9-5887-bdbc-2cffb6be0b29},4,34,281

  REG                        - Last Inserted - Cruzer    [E:\]

  REG                        - Last Inserted - SanDisk Cruzer USB Device

Note that several of the events, particularly those from the Partition/Diagnostic Event Log, are shortened here for readability.

Registry 

Each of the above three devices appears in the Registry, specifically in the System hive, sometimes in multiple locations. For example, the SanDisk Cruzer thumb drive appears in both the USBStor and WPDBUSENUM subkeys.

From the USBStor key:

Disk&Ven_SanDisk&Prod_Cruzer&Rev_8.02

  2443931D6C0226E3&0

    DeviceDesc     : @disk.inf,%disk_devdesc%;Disk drive

    Mfg            : @disk.inf,%genmanufacturer%;(Standard disk drives)

    Service        : disk                          

    FriendlyName   : SanDisk Cruzer USB Device     

    First Install  : 2021-09-09 17:37:15Z     

    First Inserted : 2021-09-09 17:37:15Z     

    Last Inserted  : 2022-05-16 22:06:24Z     

    Last Removal   : 2022-05-16 22:07:08Z     

From the WPDBUSENUM key:

_??_USBSTOR#Disk&Ven_SanDisk&Prod_Cruzer&Rev_8.02#2443931D6C0226E3&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

    DeviceDesc     : Cruzer                        

    FriendlyName   : E:\                           

    First Install  : 2021-09-09 17:37:17Z     

    First Inserted : 2021-09-09 17:37:17Z     

    Last Inserted  : 2022-05-16 22:06:24Z     

    Last Removal   : 2022-05-16 22:07:08Z

The Apple devices appear beneath the USB key, based on the vendor ID:

VID_05AC&PID_129E

  b9e69c2c948d76fd3f959be89193f30a500a0d50

    DeviceDesc     : @oem119.inf,%iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device

    Mfg            : @oem119.inf,%aapl%;Apple, Inc.

    Service        : usbccgp                       

    FriendlyName   : @oem119.inf,%iPhone.AppleUSB.DeviceDesc%;Apple Mobile Device USB Composite Device

    First Install  : 2022-01-02 19:41:16Z     

    First Inserted : 2022-01-02 19:41:15Z     

    Last Inserted  : 2022-01-02 19:41:15Z     

    Last Removal   : 2022-01-02 19:55:46Z     

VID_05AC&PID_129E&MI_00

  6&3091e96e&0&0000

    DeviceDesc     : Apple iPod                    

    Mfg            : Apple Inc.                    

    Service        : WUDFWpdMtp                    

    FriendlyName   : Apple iPod                    

    First Install  : 2022-01-02 19:41:21Z     

    First Inserted : 2022-01-02 19:41:21Z     

    Last Inserted  : 2022-01-02 19:41:21Z     

    Last Removal   : 2022-01-02 19:55:46Z     

VID_05AC&PID_129E&MI_01

  6&3091e96e&0&0001

    DeviceDesc     : @oem119.inf,%iphone.appleusbmux.devicedesc%;Apple Mobile Device USB Device

    Mfg            : @oem119.inf,%aapl%;Apple, Inc.

    Service        : WINUSB                        

    FriendlyName   : @oem119.inf,%iPhone.AppleUsbMux.DeviceDesc%;Apple Mobile Device USB Device

    First Install  : 2022-01-02 19:41:16Z     

    First Inserted : 2022-01-02 19:41:16Z     

    Last Inserted  : 2022-01-02 19:41:16Z     

    Last Removal   : 2022-01-02 19:55:46Z     

VID_05AC&PID_12A8

  00008030000E6C6C11DA802E

    DeviceDesc     : @oem119.inf,%iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device

    Mfg            : @oem119.inf,%aapl%;Apple, Inc.

    Service        : usbccgp                       

    FriendlyName   : @oem119.inf,%iPhone.AppleUSB.DeviceDesc%;Apple Mobile Device USB Composite Device

    First Install  : 2022-01-02 19:56:40Z     

    First Inserted : 2022-01-02 19:56:40Z     

    Last Inserted  : 2022-05-07 14:14:56Z     

    Last Removal   : 2022-05-07 14:16:35Z     

VID_05AC&PID_12A8&MI_00

  6&139bb8e1&1&0000

    DeviceDesc     : Apple iPhone                  

    Mfg            : Apple Inc.                    

    Service        : WUDFWpdMtp                    

    FriendlyName   : Apple iPhone                  

    First Install  : 2022-01-02 19:56:46Z     

    First Inserted : 2022-01-02 19:56:46Z     

    Last Inserted  : 2022-05-07 14:14:56Z     

    Last Removal   : 2022-05-07 14:16:35Z     

Additional Resources

Note that per Yogesh's blog post, the "Microsoft-Windows-Kernel-PnP/Device Configuration" Event Log may also contain information about the connected devices.

One More Thing

While I was doing some research for this blog post, I ran across this entry for event ID 112, albeit from the Microsoft-Window-TaskScheduler/Operational" Event Log. Once again, please stop referring to event records solely by their ID, and start including the event source, as well.  

USB Devices Redux

Back in 2005, Cory Altheide and I published the first paper on tracking USB storage devices across Windows systems; at the time, the focus was Windows XP. A lot has happened since then...I know, that's an understatement...as the Windows platform has developed and expanded, initially with Vista, then Windows 7, and even with Windows 10 there have been developments that have come (and gone) just between the various Win10 builds.

With respect to USB devices in particular, not long ago, we (the community) became aware that the Microsoft-Windows-DriverFrameworks-UserMode/Operational Event Log contained quite a bit of information (see this post for event IDs to track) that a digital forensic analyst could use to determine if and when USB devices had been connected to (and disconnected from) the system. This was a pretty profound finding, and very valuable...and then, for some unknown reason, that Windows Event Log was disabled by default. 

Also, in researching information for this topic, I found that the EMDMgmt key in the Software hive, which is associated with ReadyBoost and provided insight into USB-connected devices, is no longer available either. Okay, so one less artifact, one artifact removed from the constellation...now we just need to adapt.

This is really nothing new, to be honest. DFIR analysts need to be adaptable, regardless of whether we're in a consultant or FTE role. If you're a consultant, you're going to see a new environment on every engagement, and there will be new things to deal with and discover. A while back, a teammate discovered that the customer had LANDesk installed on their systems, and the software monitoring component recorded a great deal of information regarding executed processes right there in the Registry. It's not too different in an internal, FTE role, as you're likely going to run across legacy builds, software loads that haven't been/can't be updated for some reason, applications or packages users have installed specifically to meet the needs of their department or of a customer, etc. Further, we've seen various resources come and go; for example, we got used to having Registry hive backups available during investigations, and then we lost access to them; they're no longer available by default. In addition to the Microsoft-Windows-DriverFrameworks-UserMode/Operational Event Log, the Microsoft-Windows-TaskScheduler/Operational Event Log seems to be disabled by default. As such, when we find that a data source or artifact that we're familiar with and used to using is no longer available, we have to invest in determining an alternate means for determining the same or similar information; we have to rebuild those artifact constellations. 

Something else that has developed over time alongside the development of the Windows platform is how USB devices are treated. For example, Nicole Ibrahim described some time ago how some USB connected devices, specifically smartphones, are treated differently based on the protocol used. Nicole's presentation on the topic can be found here.

The overall point is that we can no longer consider all USB-connected devices to be the same, and as such, we may need to look in different locations within the OS, including different locations within the Registry and within different Windows Event Logs, to find the information pursuant to our analysis goals. Pursuant to this, I sat down with my own local system and started going through the Windows Event Logs, via the Event Viewer, one at a time, looking for indications of connected devices. What I found was that records of connections were dispersed across multiple logs, depending upon the type of device connected (i.e., smartphone/digital camera, ext HDD w/ enclosure, thumb drive, etc.).

As a caveat, these event records are not exclusive; that is to say that the individual event source/ID pairs do not pertain solely to USB connected devices. In many cases, the same event source/ID pair was found to contain information specific to the local physical hard drive, as well as to the different volumes on that hard drive. Also, all of these events are for the latest build of Windows 10 only, because that's all I have to test against.

So here's a look at the five resources I found; keep in mind this is limited based on what I have available to test with, but it should serve as a good starting point...

Microsoft-Windows-WPD-MTPClassDriver/Operational.evtx

Event Source: WPD-MTPClassDriver

Event ID: 1005

Fig 1: Event ID 1005

Figure 1 illustrates where I'd connected my iPhone to the system to pull pictures; I also have entries for my iPod (yes, I still have an iPod...) where I wanted to transfer music to my iPhone. Due to the protocol used, this is also where we'd likely find digital cameras, as well.

Microsoft-Windows-DeviceSetupManager/Admin

Event Source: DeviceSetupManager

Event ID: 112

Fig 2: Event ID 112

Figure 2 shows where I'd connected a SanDisk Cruzer thumb drive to the computer.

Microsoft-Windows-StorageSpaces-Driver/Operational.evtx

Event Source: StorageSpaces-Driver

Event ID: 207

Fig 3: Event ID 207

I shared figure 3 because this is specifically an external HDD, one of those "wallet" drives with a small form factor/enclosure. This device is small enough that it's powered from the USB connection; I don't have a larger enclosure that requires an additional power source to test against.

Microsoft-Windows-Partition/Diagnostic.evtx

Event Source: Partition

Event ID: 1006

Fig 4: Event ID 1006, XML view

Figure 4 is a bit different, because the "friendly view" simply says, "for internal use only". However, taking a look at the XML view, we see that the SanDisk Cruzer thumb drive and it's serial number pops right out!

Microsoft-Windows-Ntfs/Operational.evtx

Event Source: Ntfs

Event ID: 145, 142

Fig 5: Event ID 145

Figure 5 shows the Ntfs/145 event record (in part) from a previous connection of the SanDisk Cruzer thumb drive. Event ID 142 provides additional information, including regarding the volume assignment (C:, D:, F:, etc.), if the volume is bootable, etc., which can be used to tie to shellbags and Windows Portable Devices artifacts in the Registry.

Recommendations

From a forensic perspective, if you're interested in tracking USB devices connected to systems, I'd recommend enabling the Microsoft-Windows-DriverFrameworks-UserMode/Operational Event Log, forwarding those event records off of the system (for processing via a SIEM), as well as threat hunting or some other mechanism to ensure that if the log is disabled again that this is detected and responded to in the appropriate manner.

Note that enabling the Microsoft-Windows-DriverFrameworks-UserMode/Operational Event Log is as straightforward as setting the "Enabled" value in the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-DriverFrameworks-UserMode/Operational key to "1" and rebooting the system. As a tip to DFIR analysts who need to perform verification and to threat hunters, the reverse technique (setting the "Enabled" value to "0") can be used disable normally-available Windows Event Logs.

Additional Resources
HEFC Blog - Sunday Funday, Daily Blog #197

USB Storage Device Forensics for Windows 10, circa 2017

Computer Forensics CCIC Training, chapter 8, circa 2017

Understanding Data Sources and File Formats

Following on the heels of my previous post regarding file formats and sharing the link to the post on LinkedIn, I had some additional thoughts that would benefit greatly from not blasting those thoughts out as comments to the original post, but instead editing and refining them via this medium.

My first thought was, is it necessary for every analyst to have deep, intimate knowledge of file formats? The answer to that is a resounding "no", because it's simply not possible, and not scalable. There are too many possible file formats for analysts to be familiar with; however, if a few knowledgeable analysts, ones who understand the value of the file format information to DFIR, CTI, etc., document the information and are available to act as resources, then that should suffice. With the format and it's value documented and reviewed/updated regularly, this should act as a powerful resource.

What is necessary is that analysts be familiar enough with data sources and file formats to understand when something is amiss, or when something is not presented by the tools, and know enough recognize that fact. From there, simple troubleshooting steps can allow the analyst to develop a thoughtful, reasoned question, and to seek guidance. 

So, why is understanding file formats important for DFIR analysts?

1. Parsing
First, you need to understand how to effectively parse the data. Again, not every analyst needs to be an expert in all file formats - that's simply impossible. But, if you're working on Windows systems, understanding file formats such as the MFT and USN change journal, and how they can be tied together, is important. In fact, it can be critical to correctly answering analysis questions. Many analysts parse these two file separately, but David and Matt's TriForce tool allowed these files (and the $LogFile) to be automatically correlated.

So, do you need to be able to write an OLE parser when so many others already exist? No, not at all. However, we should have enough of an understanding to know that certain tools allow us to parse certain types of files, albeit only to a certain level. We should also have enough understanding of the file format to recognize that not all files that follow the format are necessarily going to have the same content. I know, that sounds somewhat rudimentary, but there are lot of new folks in the DFIR industry who don't have previous experience with older, perhaps less observed file formats. 

Having an understanding of the format also allows us to ask better questions, particularly when it comes to troubleshooting an issue with the parser. Was something missed because the parser did not address or handle something, or is it because our "understanding" of the file format is actually a "misunderstanding"?

2. The "Other" Data
Second, understanding file formats provides insight into what other data the file format may contain, such as deleted data, "slack", and metadata. Several file formats emulate file systems; MS describes OLE files as "a file system within a file", and Registry hives are described as a "hierarchal database". Each of these file formats has their own method for addressing deleted content, as well as managing "slack". Further, many file formats maintain metadata that can be used for a variety of purposes. In 2002, an MSWord document contained metadata that came back to haunt Tony Blair's administration. More recently, Registry hive files were found to contain metadata that identified hives as "dirty", prompting further actions from DFIR analysts. Understanding what metadata may be available is also valuable when that metadata is not present, as observed recently in "weaponized" LNK files delivered by Emotet threat actors, in a change of TTPs.

3. Carving
Third, "file carving" has been an important topic since the early days of forensic analysis, and analysts have been asked to recover deleted files from a number of file systems. Recovering, or "carving" deleted files can be arduous and error prone, and if you understand file formats, it may be much more fruitful to carve for file records, rather than the entire file. For example, understanding the file and record structure of Windows 2000 and XP Event Logs (.evt files) allowed records to be recovered from memory and unallocated space, where carving for entire files would yield limited results, if any. In fact, understanding the record structure allowed for complete records to be extracted from "unallocated space" within the .evt files themselves. I used the successfully where an Event Log file header stated that there were 20 records in the file, but I was able to extract 22 complete records from the file.

Even today, the same holds true for other types of "records", including "records" such as Registry key and value nodes, etc. Rather than looking for file headers and then grabbing the subsequent X number of bytes, we can instead look for the smaller records. I've used this approach to extract deleted keys and values from the unallocated space within a Registry hive file, and the same technique can be used for other data sources, as well.

4. What's "In" The File
Finally, understanding the file format will help understand what should and should not be resident in the file. One example I like to look back on occurred during a PCI forensic investigation; an analyst on our team ran our process for searching for credit card numbers (CCNs) and stated in their draft report that CCNs were found "in" a Registry hive file. As this is not something we'd seen previously, this peaked our curiosity, and some of use wanted to take a closer look. It turned out that what had happened was this...the threat actor had compromised the system, and run their process for locating CCNs. At the time, the malware used would (a) dump process memory from the back office server process that managed CCN authorization and processing to a file, (b) parse the process memory dump with a 'compiled' Perl script that included 7 regex's to locate CCNs, and then (c) write the potential CCNs to a text file. The threat actor then compressed, encrypted, and exfiltrated the output file, deleting the original text file. This deleted text file then became part of unallocated space within the file system, and the sectors that comprised the file were available for reallocation. 

Later, as the Registry hive file "grew" and new data was added, sectors from the file system were added to the logical structure of the file, and some of those sectors were from the deleted text file. So, while the CCNs were found "in" the logical file structure, they were not actually part of the Registry. The CCN search process we used at the time returned the "hit" as well as the offset within the file; a visual inspection of the file via a hex editor illustrated that the CCNs were not part of the Registry structure, as they were not found to be associated with any key or value nodes.

As such, what at first looked like a new threat actor TTP was really just how the file system worked, which had a significant impact on the message that was delivered to Visa, who "ran" the PCI Council at the time.

Putting It All Together

It's great when a plan, or a puzzle, comes together, isn't it? 

I'm not just channeling my inner Hannibal Smith...I'm talking about bringing various pieces or elements together to build a cohesive, clear picture, connecting the dots into a cohesive analysis.

To kick this off, Florian had this to say about threat actors moving to using ISO/IMG files as result of Microsoft disabling VBA macros in docs downloaded from the Internet, a change which results in entirely new artifact constellations. After all, a change in TTPs is going to result in changes as to how the system is impacted, and a change in the resultant constellations. So, this sets the stage for our example.

In this case, the first piece of the puzzle is this tweet from Max_Mal_, which points to the BumbleBee campaign (more info from TAG here), described in the Orion Threat Alert. Per the tweet, the infection looks like this:

Zip -> ISO -> LNK -> rundll32.exe (LOLBin) -> Cobalt Strike

This all starts with a zip archive being delivered to or downloaded by the user; however, what's not mentioned or described here are the system impacts. Downloading the archive often (depending upon the process) results in MOTW being "attached" to the zip archive. This tweet thread by Florian Roth includes a couple of resources that discuss MOTW, one of which is an excellent article by Mike Wolfe that provides a really nice explanation and details regarding MOTW. I've been fascinated by NTFS alternate data streams (ADSs) since I first encountered them, in particular how they're used by the OS, as well as by the adversary. As a result, I've been similarly interested in really leveraging MOTW in every way possible.

The other useful component of Florian's thread is this tweet by Nobutaka Mantani regarding MOTW propagation support in archiver software for Windows. This is huge. What it means is that when the ISO file is extracted from the zip archive by one of the software products that supports MOTW propagation, the extracted file "inherits" MOTW, albeit without the same contents as the original MOTW. Rather, the MOTW attached to the ISO file points back to the zip archive. This then gives us a great deal of insight into the origin of the extracted file, even if the zip archive is deleted.

The benefit is that this may provide us with a detection opportunity, something that depends upon the framework and/or approach you're using. For example, it may be a good idea to alert on files being written to suspicious locations (ProgramData folder, user's StartUp folder, etc.) by one of the archiver software packages, where the target file has a MOTW. Or, we can search for such files, via either proactive or DFIR threat hunting, as a means of locating "badness" on systems or within images. Imagine having an automated process that parses the MFT, either from a triage file collection or from an acquired image, and automatically identifies for the analyst all files with MOTW in suspicious locations. MOTW propagation also appears to occur if the downloaded zip archive includes an LNK file (rather than an ISO file), or a batch file, as well. There have been instances where a batch file is extracted from an archive, to the user's StartUp folder, and has an associated MOTW. As such, automating the detection process, via alerts based on EDR telemetry, or via proactive or DFIR hunting, provides for efficiency and consistency in the analysis process.

So, where we once had to deal with weaponized documents, we're now extracting files from an archive, mounting an ISO or IMG file, and accessing the embedded LNK file within the "new volume". All of this results in a completely new artifact constellation, one that we have to understand in order to fully address coming attacks.

Changes In The Use Of LNK Files

Not long ago, I posted regarding how LNK files can be (ab)used; the post refers to LNK file metadata, and how, if the LNK file is sent by the threat actor, that metadata can be used to learn about the threat actor's environment. I first saw this mentioned by JPCERT in 2016, where they included an interesting graph (figure 1) in their post to illustrate the point.

Tony Lambert recently shared via his blog a change in Emotet TTPs, that the threat actor group had moved to using LNK files as an initial delivery mechanism. In the post, Tony described this as "a really interesting TTP change", and that it was "odd but not unexpected". Tony also shared a link to download a copy of the LNK file, as well as metadata parsed from the LNK sample via EXIFTool. I don't often use EXIFTool for this sort of metadata extraction, and I wanted to take a look for myself...here's what I found:

guid        {00021401-0000-0000-c000-000000000046}
shitemidlist    My Computer/C:\/Windows/system32/cmd.exe
**Shell Items Details (times in UTC)**
 C:0          M:0          A:0         Windows (9)  
 C:0          M:0          A:0         system32 (9)  
 C:0          M:0          A:0         cmd.exe (9)  
commandline    /v:on /c findstr "rSIPPswjwCtKoZy.*" Password2.doc.lnk > "%tmp%\VEuIqlISMa.vbs" & "%tmp%\VEuIqlISMa.vbs"
iconfilename    shell32.dll          
hotkey       0x0               
showcmd      0x1               

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasArguments|HasIconLocation|HasRelativePath

***PropertyStoreDataBlock***
GUID/ID pairs:
{46588ae2-4cbc-4338-bbfc-139326986dce}/4   SID: S-1-5-21-1499925678-132529631-3571256938-1001

***KnownFolderDataBlock***
GUID : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM

At first glance, this may not seem odd to anyone; however, for me I can see that a great deal of the metadata that researchers would look to has been stripped from the LNK file.

I'm just going to let that soak in.

Okay, so...what we don't see in the above output, and what I verified visually (via UltraEdit), are time stamps. That's right...the time stamps in the LNK file header, as well as the time stamps in the shell items that comprise the relative path, have all been zero'd out. See the lines in the above output that build the path with the folders for "Windows" and "System32", and the file "cmd.exe"? All of these shell items, by default, include time stamps. However, for this LNK file, they're zero'd out.

Remember that JPCERT article from 2016? None of the items we'd expect to find in an LNK file, those elements of metadata mentioned in the JPCERT article...volume serial number, MAC address, machine ID/NetBIOS name...are available in this LNK file. I'm familiar with what it takes to get to this point, having constructed the smallest functioning LNK file (make_lnk.txt) that I could, and one that is missing these same elements of metadata.

For example, here's a sample from Astaroth, and here are samples of output from LNK files created using various native means. However, all of these LNK files, as well as the LNK files from figs 5 and 6 of the Mandiant APT29 report, contain these items of metadata. The one Tony found does not.

So, many thanks to Tony (LinkedIn, Twitter) for not only pointing out the change in Emotet TTPs, but for also sharing a publicly accessible link to the example LNK file. This was truly a fascinating find!

As a final thought, the lack of metadata does not mean that the same techniques to locate other, similar samples...create a Yara rule and submit as a VT retro-hunt...won't work. In fact, the dearth of the missing metadata (that would be a great title for a blog post series!!) is actually an indicator that we can use for a pretty solid search!

Root Cause Analysis

One of the challenges within DFIR, particularly as we've moved to an enterprise approach by leveraging EDR telemetry, is the root cause analysis, or "RCA". In short, the challenge is observing malicious activity and determining the root cause; the challenge itself stems from the fact that EDR telemetry is only partial visibility, or that correlating observed malicious activity with causal data not evident or available via EDR telemetry requires additional context, and by extension, additional effort/expenditure of resources. It also requires an additional "leveling up" of skillsets. 

Yes, many organizations that deploy EDR tooling also include a means for extracting additional files/data from the endpoint, and what to collect isn't usually in question. Rather, how to truly exploit the collected data is the issue, with the exploitation of that data being the "levelling up".

When malicious activity is observed, or the impact of malicious activity is discovered (via threat hunting, etc.), the challenge then becomes, how do we determine the root cause? In the past, when someone has shared suspicious activity with me and sought guidance as to next steps, I've often asked, "...did a reboot or login occur just prior to the activity?" as a means of developing context around the observed activity. Was the executable launched via an auto-start mechanism, such as a Windows service, entry in a Run key, or as a Scheduled Task? The thought process has been to seek causal events for the observed activity, which can be important to not only determine the root cause, but perhaps to also identify a shift in TTPs, once we're to a point where we can arrive at attribution.

There are a lot of different ways for threat actors to persist on Windows systems, some of which were mentioned earlier in this post. Each has their advantages and disadvantages, and both require and provide different levels of access. For example, creating an entry in the user's Run key means that the malware won't start again until the user logs in, and then runs within the user context. However, if the threat actor has Admin privileges, they can create a Windows service or Scheduled Task, which then will run malware with SYSTEM level privileges. As a result, the persistence mechanism used provides a great deal of context beyond just the entry for the malware. 

To provide further insight into this topic, Krz wrote up an excellent blog post not long ago about how a laptop going on battery (unplugged from the power cord) can impact an investigation.

Based on the MITRE "Event Triggered Execution: Screensaver" page, I created a RegRipper plugin for my local repo to parse the screensaver settings out of the NTUSER.DAT hive, and ran it against a hive extracted from my local system, the output of which follows:

Launching screensaver v.20220427
screensaver v.20220427
(NTUSER.DAT) Gets user's screensaver settings
MITRE: T1546.002 (persistence)

Control Panel\Desktop
LastWrite: 2021-11-29 11:53:45Z

Screensaver is active.
SCRNSAVE.exe value not found.

Analysis Tip: Threat actors have been observed using the screen saver as a persistent mechanism.

Ref: https://cocomelonc.github.io/tutorial/2022/04/26/malware-pers-2.html

Now, if the "SCRNSAVE.exe" value (listed above as "not found") was set to something that it shouldn't be, we could then use the Desktop key LastWrite time as a pivot point for further analysis. As the Desktop value contains a number of values, we may not be able to specifically attribute the addition or alteration of the SCRNSAVE.exe value to the modification of the key LastWrite time, but it does provide us with some information we can pivot on and leverage in our analysis. 

Another instance to make clear why this example is so compelling...see Jorge's tweet here, which points us to Wietze's tweet, which in turn points us to a new #LOLBAS. Kind of a circuitous route (also apparently available as far back as 2001, from here), I know, but ultimately what this leads us to is the use of a Control Panel applet (desktop.cpl) to proxy the execution of arbitrary commands. In the example, 'calc.exe' is renamed to 'calc.scr' and launched by calling the "InstallScreenSaver" function of the applet. As a result, this persistence mechanism can be established via reg.exe or rundll32.exe; different command lines with different impacts on the system (re: artifacts associated with their execution) but both achieve the same result.

Further, we now have insight into the level of access achieved by the threat actor, the context under which the malware will run, and when the malware is expected to run. This also provides insights into the sophistication and intent of the threat actor, and can be applied toward attribution.

File Formats

Having an understanding of file formats is an important factor in DFIR work. In particular, analysts should understand what a proper file using a particular format should look like, so that they can see when something is amiss, or when the file itself has been manipulated in some manner.

Understanding file formats  goes well beyond understanding PE file formats and malware RE. Very often, various Microsoft file formats include data, or metadata (defined as "data about data") that can be mined/parsed, and then leveraged to tremendous effect, furthering overall analysis and intelligence development, often across multiple cases and campaigns.

LNK
Windows shortcut, or LNK files, have been covered extensively in this blog, as well as other blogs, in addition to having been well documented by MS. Suffice to say, LNK files can be leveraged by both good guys and bad guys, and if bad guys leverage them, so should the good guys...after all, the bad guys sending you an LNK file created in their environment is essentially just "free money", particularly if you're in CTI.

For example, the GOLDBACKDOOR report shows us a threat actor that sends an LNK file to their target, in a zip archive. So, the threat actor develops the LNK file in their environment, and sends that LNK file with all of it's metadata to the target. Now, as a DFIR analyst, you may have a copy of a file created within the threat actor's environment, one that contains information about their system(s). Why not take advantage of that metadata to develop a more meaningful threat intel picture?

Analysis of LNK files is similar to being an EOD tech (I would imagine)...you're looking at the construction of a "device", noting production mechanisms (based on tooling) as well as unique items that allow you to tie or "attribute" the LNK file in some manner. You can then leverage sites such as VirusTotal (via a retro-hunt) and populate your own MISP instance to build out a larger, more contextual threat intelligence picture. For example, consider the LNK file delivered as part of the Quantum ransomware campaign discussed in this TheDFIRReport article; the article provides an image of the metadata extracted from the LNK file. The machine ID, MAC address, and volume serial number (not shown) could be put into a Yara rule and submitted as a VirusTotal retro-hunt, providing insight into other instances or campaigns were LNK files with the same values were employed. You can also tighten or loosen the aperture of your retro-hunt by adding or removing values within the Yara rule.

Yet another example of how LNK metadata can be used...and likely the best example of this sort of data exploitation available thus far...can be seen in this Mandiant blog post from 2018. The post addresses differences between APT29 campaigns from 2016 and 2018, with references to differences in LNK files shows in figures 5 and 6. Reading through the article, you can see where the Mandiant team leveraged the data they had available to develop insights about the actor's campaigns.

OLE
OLE, or "object linking and embedding" (aka, "structured storage") is a file format most often associated with older versions of MS Office. As such, when MS transitioned the world to the "new" MSOffice file format, many likely thought, "okay, I'll never see that file format again." Oh, how wrong we were! The OLE format is used within a number of other files, including:

Files
Automatic JumpLists - all but one embedded stream consists of an LNK "file"
MSI files
Sticky Notes
Other files, some of which are application-dependent

We can look to a variety of tools to meet our needs in parsing these files:

OLE Parsing Tools
olefile
MiTeC SSV
ripOLE

For specifically parsing/working with MSI files, I'm told that folks use tools such as InstEdit, and orca.exe from MS.

Metadata that may be present in the document structure can be leveraged or exploited in a manner similar to LNK files, or better yet, really leveraged by combining it with what's found in LNK files. For example, the LNK file in the GOLDBACKDOOR report reportedly downloads a decoy .doc file, meaning that the metadata from the LNK file has a direct link to the metadata found in the .doc file.

Registry
At this point, the Windows Registry file format is well-understood, and documented (here, by Maxim Suhanov). As a result, we know how to parse it, but much like other file structures, we (as a community and industry) regularly fall short in truly exploiting the file format to our advantage. 

Registry keys have embedded time stamps, which as Lina L. astutely and articulately described in her blog post, can be manipulated. Time stamps are also visible in value data (albeit NOT in the structure of values) as strings, as binary data, or embedded within binary data streams. All of these can be used to further analysis, including possibly even to identify key LastWrite time manipulation (very much depending upon how it's done).

For example, a recent TheDFIRReport write-up on the Quantum ransomware indicates that when the user double-clicks the ISO file, artifacts of the ISO file being mounted on the system appear in the Windows Event Log. Okay, great...but does the drive letter assignment also appear in the MountedDevices key in the System hive? When the user double-clicks the LNK file embedded in the ISO file, is that action reflected in the user's UserAssist key?

Aside from the "normal" Registry hive files we're all familiar with...Software, System, SAM, Security, NTUSER.DAT, USRCLASS.DAT...other files on the system follow the same file format. This means that all of the tools we use to parse the 'usual suspects' can also be leveraged against these other files, which include BBI, DEFAULT, and ELAM in the system32\config folder, the AmCache.hve file, and the settings.dat files associated with MS Store apps (i.e., in the %user%\AppData\Local\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\Settings folder, etc.)

Tools
In 2008, Jolanta Thomassen created the tool regslack.pl, to parse deleted data from hive files as part of her thesis work. Since then additional tools have been created for parsing this information, not the least of which includes the del.pl and slack.pl RegRipper plugins. 

LNK (Ab)use

I've discussed LNK files a number of times in this blog, and to be honest, I really don't think that this is a subject that gets the attention it deserves. In my experience, and I humbly bow to collection bias here, LNK files are not as well understood as they (sh|c)ould be in the DFIR and CTI fields, which puts defenders at a disadvantage. When I suggest that LNK files aren't really well understood by DFIR and CTI teams, I'm basing that on my own experience with multiple such teams over the years, largely the result of direct interaction.

Why is that? Well, the LNK file format is well documented at the MS site, and there have been a number of tools written over the years for parsing these files. I've even gone so far as to create the smallest functioning LNK file, based on the minimum functional requirements, and with all of the metadata zero'd out or altered. However, IMHO, the real issue is that the actual functional, operational use of these files is not discussed often enough, and as such, they fall out of scope, much like other aspects of Windows systems (Ex: NTFS alternate data streams (ADSs)). As such, LNK files are not something that is closely examined during DFIR or proactive threat hunting engagements, and even more rarely do they appear in reporting. Finally, as effective as these files can be, they simply are not the "new shiny hotness"...they aren't 0-days, and they aren't the newest, hottest exploits. As a result, not a lot of focus and attention are given to these files, and it's likely that their use is less evident than might otherwise be the case.

V3ded's Github repo includes an article that does a great job of covering how LNK files can be abused. While the title refers to "initial access", it seems to describe the use of document macros to create an LNK file, rather than "weaponized" LNK files being delivered to a target. The difference is an important one...using macros (or some other method) to create LNK files on a target system means that the LNK file metadata is going to be specific to the target system itself. Alternatively, an LNK file delivered to the target is going to contain metadata specific to the threat actor's dev environment.

V3ded's article refers to a couple of means of persistence that are very interesting. One is the use of shortcut keys, defined within the structure of the LNK file. Per the article, an LNK file can be placed on the desktop and structured to be activated by a specific and common key sequence, such as Control+C (copy), Control+V (paste), or some other commonly used sequence. Another means of persistence involves the use of the "iconfilename" element within the LNK file structure; by pointing to an icon file located on a remote, TA-controlled system, attempts to access the resource (via activation of the LNK file) will involve authentication, allowing the threat actor to collect password hashes. What's interesting about both of these techniques is that neither one requires the threat actor to authenticate to collect information and gain access to your systems. This means that following containment and eradication steps, when you think you've ejected the threat actor and you've changed passwords in your environment, the threat actor is still able to collect information that may allow them to re-enter your environment. 

Again, when LNK files are sent to a target, from a threat actor, those files will contain metadata specific to the threat actor's dev environment. For example, consider MalwareByte's analysis of an "LNK attack" tied to a threat actor group referred to as "Higaisa". This attack apparently involved an LNK file being sent to the target in a zip archive; the LNK file would have to have been developed by the threat actor, and the file metadata would provide insight into the threat actor's development environment. 

A similar example could be seen in Mandiant's analysis CozyBear phishing campaigns. In this example, the Mandiant team did an excellent job leveraging LNK files, and looked specifically at differences between successive campaigns to derive insights into the threat actor's evolution.

Over time, we've also seen LNK files sent or linked to a target while embedded in ISO or IMG file formats, allowing them to bypass MOTW (re: ADS) restrictions. In cases such as this, the metadata within the LNK file structure can provide insights as to the build or production method, proliferation of build methods, etc., similar to the way EOD professionals look to toolmarks and artifacts to identify bombmakers. As such, these resources should not be ignored by DFIR and CTI professionals, but should instead be leveraged for a range of insight. For example, Yara rules can be used to perform retro-hunts via VirusTotal to look for the use and proliferation of specific platforms, as well as view changes in LNK file production techniques between campaigns, or simply over time. Tools can be designed to comb through specific locations within Windows systems (or images), scanning for persistence techniques and other anomalies, automatically providing them for analysis and development into retro-hunts.