Insights

Unique Windows Registry data in Fast Boot hibernation and hive transaction logs

I was asked to take a recent flurry of Tweets and turn them into an Insights post with more detail. So, here goes!

We have spent some time at Arsenal looking at particularly important Windows Registry keys which are sometimes only found, in their most recent state, within Fast Boot hibernation and/or Registry hive transaction logs. In other words, these are important Registry keys that you may not find in their most recent state within active hives. We focused on important keys because it makes the situation more relatable to our colleagues in digital forensics. In this Insights post, we are further focusing on the following key from the SOFTWARE hive:

Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

Profiles subkeys represent particular networks, and the information they contain is quite useful for digital forensics practitioners. For example, the “DateLastConnected” value provides a SYSTEMTIME date/time which indicates when the system last connected to that network. You can see more Profiles subkey values in Registry Recon’s “Recon View” from sample SANS evidence in the following screenshot:


Now let’s move on to an actual case. When did our suspect’s laptop last connect to a (very important) network represented by GUID 8DF661DF-89AC-4762-A343-4D099E63BBAF? We could use lots of words to describe the situation, but let’s use a concise spreadsheet instead:

Some of our takeaways from analysis of important Registry keys generally, and Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\{8DF661DF-89AC-4762-A343-4D099E63BBAF} in this case specifically, include:

  1. A digital forensics practitioner looking only at the active SOFTWARE hive may conclude the suspect’s laptop last connected to a very important network on 4/26 (and, be wrong)
  2. A digital forensics practitioner also looking at the SOFTWARE hive carved from Fast Boot hibernation may conclude the suspect’s laptop last connected to a very important network on 5/2 (and, still be wrong)
  3. A digital forensics practitioner looking at the active SOFTWARE.log1 hive transaction log may conclude the suspect’s laptop last connected on 5/3 (and, be right)
  4. Maybe obvious to some, but not to others – Registry updates may not be pushed from the hive transaction logs to active hives not for seconds, minutes, or hours – but days
  5. Incorporating active and backed-up hive transaction log data into Registries rebuilt by Registry Recon is near the top of our development queue
  6. Fast Boot hibernation should not be ignored. More on that, and upcoming Hibernation Recon functionality, soon…

On a parting note, since we know digital forensics practitioners are curious folks who may be interested in recent Windows startup/shutdown activity on the computer in question:

I hope you enjoyed this Insights post! Please let us know if there are any topics you would like addressed in the future.

 

Integrating Arsenal Image Mounter Source Code and APIs

Arsenal Image Mounter was born when we found existing disk image mounting technology lacking during the development of our premier digital forensics tool Registry Recon. Since we now have quite a bit of experience being in a position where a powerful disk image mounter would take our project to the next level, we offer the Arsenal Image Mounter source code and APIs to commercial projects with an appropriate license and to open source projects royalty free.

Many disk image mounting solutions mount the contents of images in Windows as shares or partitions (rather than complete disks), which limits their usefulness. Arsenal Image Mounter mounts the contents of disk images as complete disks in Microsoft Windows® by including a virtual SCSI adapter (via a unique Storport miniport driver) which allows users to benefit from disk-specific features in Windows like integration with Disk Manager, access to Volume Shadow Copies, and more. As far as Windows is concerned, the contents of disk images mounted by Arsenal Image Mounter are “real” SCSI disks.


 

 

 

 

 

 

 

 

In addition to core functionality mounting raw, forensic, and virtual disk images, Arsenal Image Mounter offers the following features to digital forensics, electronic discovery, virtualization, and many other types of developers:

  • High performance
  • Temporary write support
  • “Fake” disk signatures
  • Removable disk emulation
  • Volume Shadow Copy (VSC) mounting (for commercial licensees)

Developers may also be interested in the fact that Arsenal Image Mounter provides both .NET and non-.NET APIs, its Storport miniport driver is written in C, and its user mode API library is written in VB.NET, which facilitates easy integration with .NET 4.0 applications.

We get lots of feedback from end-users involved in digital forensics and electronic discovery who appreciate Arsenal Image Mounter’s functionality when it comes to mounting encrypted drives, accessing VSCs, and more. Occasionally we also get feedback from end-users outside the realm of digital forensics:

“As a former Linux developer I miss many things under Windows. One of them is the flexible handling of loop devices and disk dumps. Arsenal Image Mounter ports this power to the Microsoft world. You know that “X:” is a virtual thumb drive residing in RAM, but Windows won’t. And that’s only one of the many possibilities with AIM.”

— Peter Schneider, Software Development Engineer, Cascade Microtech

If your commercial software could benefit by having more powerful disk image mounting, email us today! With exciting new functionality on the way in 2018, now is a good time to lock in a commercial license to integrate our source code and APIs.

 

Case Study in Successful Dash Cam Video Repair

In late December 2017 I was alerted to someone looking for help to repair a damaged video from a dash cam, a video which may have captured a horrible accident.


 

I got in touch with Erik and he gave me more detail. While Erik was driving to work, he saw a car accident a fair distance away at an upcoming intersection. After pulling over to the side of the road, he unplugged his dash cam because he was concerned about video being overwritten due to its limited memory if he left it on. Unfortunately, by unplugging the dash cam shortly after the accident he prevented the video from being written properly to the storage media inside the camera. When he tried to view the video later in the day to see if it would be valuable to the police (because he did not get a good look at what happened with his own eyes), he realized the video was damaged:

Fortunately, I work for a company that encourages pro bono work. This case seemed to be a good fit, so I asked Erik for the damaged video file and started to work on it. I also asked Erik to secure the storage media from within the dash cam, because after all we are digital forensics practitioners and we might be able to access more relevant data on the storage media itself.

I was hoping initially that the repair would be as simple as adding a footer to the partially saved video file, so we could at least view up until Erik unplugged the camera. A good resource for looking up file headers and footers is Gary Kessler’s File Signatures Table (https://www.garykessler.net/library/file_sigs.html).

Using Gary Kessler’s file signatures resource, I confirmed Erik’s video was a QuickTime movie file based on its header (in hex) of 66 74 79 70 71 74 20 20 (or, “ftypqt  ”). Great!

 

Or, maybe not so great. There was no footer associated with that header in Gary Kessler’s file signatures resource, so repairing QuickTime video files might not be as simple as I had hoped.

Next up, knowing how many different QuickTime video codecs exist (see https://www.loc.gov/preservation/digital/formats/fdd/fdd000052.shtml for starters), maybe I just needed to use the right codec to view the partially written video. I used multiple video players (VLC Media Player,  Irfanview, etc.) with a variety of QuickTime video codecs, without success.

Maybe I could carve video from the file by using PhotoRec? Again, no success.

It turns out that repairing a QuickTime video file can be complicated. See this excellent resource from Aero Quartet (http://aeroquartet.com/movierepair/fix-mov-files). At this point I chose to use a tool designed specifically for repairing damaged QuickTime video files. Stellar Phoenix Video Repair (“Phoenix”) was my first choice as it cost less than $100 USD and I’ve had some success with their other tools.

Loading the damaged video file into Phoenix and beginning the repair was easy – there are very few options to worry about. Unfortunately, the file could not be repaired. We were not out of luck however, as Phoenix includes an option for adding a reference file which leverages the reference file’s headers and other metadata to assist in the repair.

Erik provided me with a short 15 second video from his dash cam of his car pulling into a parking lot. Using this short video as a reference, Phoenix was able to repair the damaged video file and recover 2 minutes and 40 seconds of previously inaccessible dash cam footage – including a clear view of the accident involving one car running into another head on. It is worth noting that another video repair tool we used was also able to recover video from Erik’s damaged video file, but it recovered 33 seconds less video than Phoenix.

You can see for yourself why Erik wanted to turn the video over to the local Police Department.

I hope you enjoyed this Arsenal Insights case study!

 

Arsenal Consulting’s President Selected to Open the OverDrive Hacking Conference

Attendees Will Learn About Electronic Evidence Tampering that Evaded Detection by Digital Forensics Experts

Mark Spencer, President of Arsenal Consulting (ArsenalExperts.com) has been selected to open the OverDrive hacking conference in Spain with the most recent version of his award-winning presentation “High Stakes Evidence Tampering and the Failure of Digital Forensics” on April 18. The OverDrive conference is focused on enhancing the camaraderie of the worldwide hacker community by connecting people involved in many different aspects of computer security.

What is Arsenal’s Mark Spencer saying about OverDrive?

“I am honored that the OverDrive team asked me to open the conference. OverDrive was born from the efforts of students and professors at the technical school of Girona who are truly passionate about computer security. I’m looking forward to sharing our passion for digital forensics with the OverDrive attendees and connecting with Spanish law enforcement currently using our digital forensics tools.”

Why attend this presentation?

Discussions about electronic evidence tampering are often academic, which can leave participants skeptical about the practicality of various tools and techniques. Attendees of this presentation will be introduced to the tools and techniques used quite successfully by attackers in a high-profile case — from delivering documents that resulted in the imprisonment of journalists to evading detection by digital forensics experts. Mark Spencer will demonstrate Arsenal’s “Anchors in Relative Time” analysis technique which ultimately revealed that the computers in question were attacked both locally and remotely, including the use of a RAT (Remote Access Trojan) never seen before in the wild.

What are the journalists saying about Arsenal’s work?

“Arsenal’s pursuit in the technical side of our case, and your effort to show the discrepancies in the evidence, was at the heart of what shed light on how unjustly we were charged. Your investigation was vital in demonstrating to the legal community the significance of verifying the authenticity of any and all technical pieces of evidence in any legal process.” Müyesser Yıldız — Investigative Journalist, Odatv

About Mark Spencer

Mark Spencer is President of Arsenal Consulting, where he leads engagements involving digital forensics for law firms, corporations, and government agencies. Mark is also President of Arsenal Recon (ArsenalRecon.com), where he guides development of digital forensics tools which include Registry Recon. Mark has more than 15 years of law-enforcement and private-sector digital forensics experience. He has led the Arsenal team on many high-profile and high-stakes cases, from allegations of intellectual-property theft and evidence spoliation to support of foreign terrorist organizations and military coup planning. Mark has testified in cases which include US v. Mehanna and US v. Tsarnaev (the Boston Marathon bombing). Arsenal is headquartered on the Chelsea waterfront, very close to Boston Logan International Airport.

 

Windows Hibernation Infographic


Why did we design the Windows hibernation infographic?

You can imagine how many emails we get about Windows hibernation files since we released Hibernation Recon. We noticed some misconceptions being repeated in these emails, so we decided to address them in an infographic that the digital forensics community could use as a resource and help us improve. We consider the infographic we are launching today to be the first version, as we already have more than enough interesting information to include on the reverse side of our second version.

 

Subscribe to Arsenal mailing list for infographic download


 

Were we surprised by anything we learned while working on the infographic?

Well, yes. We had thought there must be some situations in which active hibernation files could be found encrypted, particularly based on some of the sample hibernation files our customers sent us which appeared to be encrypted. After enormous amounts of testing, we realized that these “encrypted” hibernation files were quite misleading – what we were actually seeing was the result of BitLocker “decrypting” zeroes from in-file TRIMming on SSDs.

 

Why did we build Hibernation Recon?

The environment in which we built Hibernation Recon in 2016 included digital forensics tools that either had absolutely no support, extremely limited support, or seriously broken support for processing Windows hibernation files. While working on multiple cases related to both domestic and international terrorism, in which maximum exploitation of electronic evidence was crucial, we could not accept the status quo. You don’t have to take our word for it, we can show you… while working on the Turkish Odatv case, we noticed nine hits (which appeared compressed) on “securedownload” within a hibernation file:

When we processed this hibernation file in multiple digital forensics tools, we searched their output for “securedownload” and found no hits:

 

When we processed this hibernation file with Hibernation Recon, we found 19 hits on “securedownload” in the output:

This was only the beginning. Beyond tools which had no or extremely limited support, we found significant bugs in popular tools which advertised support, from decompression and active memory reconstruction to an “off the table” bug that we found particularly concerning and addressed with the vendor in question. While some tools have improved their support for modern Windows (8/8.1/10) hibernation files, Hibernation Recon continues to be on the only tool that offers, for example, proper exploitation of the various levels (and types) of hibernation slack.

 

If you like how we are pushing the limits of what is possible in digital forensics with Hibernation Recon and our other tools, please support us. Testimonials and case examples from our users, letting colleagues know about our unique features, and having your organizations purchase our tools are greatly appreciated. Arm Yourself!