Smartphones play an important role in our lives. With the advent of applications for smartphones, the more functionalities and services are offered to users. Online social networks (OSN) applications are the most popular applications worldwide. OSN applications, such as Facebook and Twitter, allow users to share personal information such as posts, age, gender, location, photos and videos. This valuable information saved on smartphones’ internal memory and could be used as evidence during forensic investigation. Snapchat is a popular OSN application that is available for Android and iOS devices. It allows users to share photos and videos called Snaps with predetermined time to view. Once the time expired, snaps are automatically deleted. This paper analyses artifacts saved by Snapchat application on Android smartphones and identifies their significance to the forensic investigation process.

EasyMetaData has updated FindUSBMSC. It’s a script to parse the system logs on macOS. It looks for USBMSC storage device plugins and links them back to the product information.

Digital forensics is an evolving discipline that looks for evidence in electronic devices. It is being utilised in investigating attacks and accusing cyber criminals. As in physical crimes, a cyber criminal might try every possible technique to hide responsibility about a crime. This can be done by manipulating all kinds of traces that could lead investigators to resolve cases. For example, a criminal can delete files, images, network traces, operating system log files, or browsing history. An easy procedure a criminal might follow to conceal crime activities are: 1) create a new user account; 2) commit a crime through the just-created account; 3) delete the account along with all files and directories that belong to it. To counter this kind of anti-forensic actions, this paper collects evidence from deleted user accounts. The authors seek artefacts in windows event logs, registry hives, RAM, Pagefile, and hard drive. Interestingly, this paper shows that several clues about deleted accounts can be harvested.

Sysinternals Autoruns is a great utility for defenders to discover and disable malware and adversaries’ persistence points. There are similar programs, but as the author of Autoruns says: “(Autoruns) has the most comprehensive knowledge of auto-starting locations “, therefore the focus here is on Autoruns.

In the last weeks couple of security researches (Kyle – @KyleHanslovan, Chris – @ChrisBisnett, HASHEREZADE @hasherezade) have discovered that it’s possible to evade from Autoruns when using it with a default configuration. Always remember that determined attackers will work actively on hiding their activities within your network.

To better understand these techniques, we can use two categories “Direct manipulation” and “Indirect manipulation”. Read this article to better understand these categories.

We are not sure about your labs, but our receives more and more Macs for forensic examination every month. And, of course, some of the cases require us to find forensic artefacts of external USB drives connections and files copying. We know that you guys liked our last article regarding USB forensics on Windows systems, so we decided to write another hitchhiker’s guide, this time about macOS USB forensics.

Let’s start. In our case ex-employee brought an external USB drive and stole company’s property. As that employee was involved in design, it was a bunch of AI and PSD files.

If you dealt with Macs before, you should know that you can get a lot of information from plist files, so to do macOS USB forensics, you will need a forensic tool with plists viewer. We are going to use Magnet AXIOM, but you can use a tool of your choice.

A good place to start is the Preferences folder located in /<username>/Library. It’s full of plist files, but let’s start from the following:

• com.apple.finder.plist

Open it with a plist viewer of you choice and look at “RecentMoveAndCopyestinations” value.

Image may be NSFW.
Clik here to view.

Figure 1. com.apple.finder.plist

Yes, we got the mount point of the external USB drive. Now we are going to use the Keyword Search feature to search for more artefacts using the mount point. In our case, we have found a few records showing the user downloaded some JPGs to the external USB drive from the Internet.

Image may be NSFW.
Clik here to view.

Figure 2. Evidence of files downloaded from the Internet to an external USB drive with Google Chrome

During forensic examination of the user’s profile folder we have found a very interesting subfolder – .wdc. Inside of it there are lots of files with extremely valuable pieces of information from a forensic point of view, especially inside the db subfolder.

For example, devices.tingo – you can see the contents of this file on figure 3.

Image may be NSFW.
Clik here to view.

Figure 3. devices.tingo contents

As you can see, it contains lots of extremely valuable pieces of information: drive model and serial number, its capacity, mount point, name, etc.

Looks amazing, isn’t it?!

Ok, now it would be great to collect information about files copied to this external USB drive. Let’s go back to the Preferences folder. In our case the most valuable plist was the following:

• com.adobe.mediabrowser.plist

This plist file contains most recently used (MRU) Illustrator and Photoshop files. And the number is not 10 or 20 as you usually see, but 500 (!). So it was a real gold mine!

Of course, you don’t always need to find AI and PSD files, you may want to find DOC, XLS, etc. The Preferences folder may help you with this too. There are even some tools that can help you to automate MRU finding, for example, macMRU Parser by Sarah Edwards.

Also a good technique to find not common USB artefacts is to index the whole image and search for mount point or drive name – you can find a lot.

We would be happy if you share your macOS USB forensic artefacts in the comments to this post.

Happy forensicating!

About the authors

Oleg Skulkin, MCFE, ACE, is a DFIR enthusional (enthusiast + professional) and Windows Forensics Cookbook co-author.

Igor Mikhaylov, MCFE, ACE, OSFCE, is a digital forensic examiner with more than 20 years of experience and Mobile Forensics Cookbook author.

Richard Davis continues his “Introduction to Windows Forensics” series. This video introduces the ubiquitous LNK, or “link”, file, as well as a lesser known Windows feature called Jump Lists:

Cindy Murphy from Gillware has published a very interesting post on how to reset the backup password in iOS 11. Here is an excerpt from it:

“Apple’s help page about encrypted backups got an update when iOS 11 came out. They give the following advice for people who have forgotten their backup password:

You can’t restore an encrypted backup without its password. With iOS 11 or later, though, you can make a new encrypted backup of your device by resetting the password. Here’s what to do:

On your iOS device, go to Settings > General > Reset.

1. Tap Reset All Settings and enter your iOS passcode.
2. Follow the steps to reset your settings. Resetting your settings won’t affect your user data or passwords, but it will reset settings like display brightness, Home screen layout, and wallpaper. It also removes your encrypted backup password.
3. Connect your device to iTunes again and create a new encrypted backup.”

SANS instructors Heather Mahalik and Domenica “Lee” Crognale discuss iOS 11 messages and the differences they have seen compared to older iOS versions. They walk you through their methods for testing and creating data sets for examination, as well as provide attendees with tips on how to better understand iOS 11 messages. Additionally, they will discuss procedures used for developing the query and how your mobile forensics tools might be blurring the lines on what the data represents.

This work explores the development of MemTri. A memory forensics triage tool that can assess the likelihood of criminal activity in a memory image, based on evidence data artefacts generated by several applications. Fictitious illegal suspect activity scenarios were performed on virtual machines to generate 60 test memory images for input into MemTri. Four categories of applications (i.e. Internet Browsers, Instant Messengers, FTP Client and Document Processors) are examined for data artefacts located through the use of regular expressions. These identified data artefacts are then analysed using a Bayesian Network, to assess the likelihood that a seized memory image contained evidence of illegal firearms trading activity. MemTri’s normal mode of operation achieved a high artefact identification accuracy performance of 95.7% when the applications’ processes were running. However, this fell significantly to 60% as applications processes’ were terminated. To explore improving MemTri’s accuracy performance, a second mode was developed, which achieved more stable results of around 80% accuracy, even after applications processes’ were terminated.

An international team of forensics experts helped create the SANS Investigative Forensic Toolkit (SIFT) Workstation and made it available to the whole community as a public service. The free SIFT toolkit, that can match any modern forensic tool suite, is also featured in SANS FOR508: Advanced Threat Hunting and Incident Response course (http://www.sans.org/FOR508). It demonstrates that advanced investigations and responding to intrusions can be accomplished using cutting-edge open-source tools that are freely available and frequently updated. The SANS Investigative Forensic Toolkit has become the most popular download on the SANS website. Over the past year, 20,000 individuals have downloaded the SIFT workstation and has become a staple in many organizations key tools to perform investigations. This session will demonstrate some of the key tools and capabilities of the suite. You will learn how to leverage this powerful tool in your incident response capability in your organizations. To download the SIFT Workstation please visit: http://dfir.to/SIFT-Download

IoT device forensics is a difficult problem given that manufactured IoT devices are not standardized, many store little to no historical data, and are always connected; making them extremely volatile. The goal of this paper was to address these challenges by presenting a primary account for a general framework and practical approach we term Forensic State Acquisition from Internet of Things (FSAIoT). The authors argue that by leveraging the acquisition of the state of IoT devices (e.g. if an IoT lock is open or locked), it becomes possible to paint a clear picture of events that have occurred. To this end, FSAIoT consists of a centralized Forensic State Acquisition Controller (FSAC) employed in three state collection modes: controller to IoT device, controller to cloud, and controller to controller. They present a proof of concept implementation using openHAB – a device agnostic open source IoT device controller – and self-created scripts, to resemble a FSAC implementation. Our proof of concept employed an Insteon IP Camera as a controller to device test, an Insteon Hub as a controller to controller test, and a nest thermostat for a a controller to cloud test. Their findings show that it is possible to practically pull forensically relevant state data from IoT devices. Future work and open research problems are shared.

Packt Publishing has announced the third edition of Practical Mobile Forensics by Rohit Tamma,‎ Oleg Skulkin,‎ Heather Mahalik and‎ Satish Bommisetty.

Book Description

Covering the most updated mobile platforms our book will focus on giving you the most recent techniques of investigating mobile devices. We will deep dive into mobile forensics techniques in iOS 9-11, Android 7-8 devices, and Windows 10. We will demonstrate the latest open source and commercial mobile forensics tools, enabling you to analyze and retrieve data effectively. You will learn how to introspect and retrieve data from cloud, and document and prepare reports for your investigations.

By the end of this book, you will have mastered the current operating systems and techniques to recover data from mobile devices by leveraging open source solutions.

What you will learn

• Discover the new features in practical mobile forensics
• Understand the architecture and security mechanisms present in iOS and Android platforms
• Identify sensitive files on the iOS and Android platforms
• Set up the forensic environment
• Extract data on the iOS and Android platforms
• Recover data on the iOS and Android platforms
• Understand the forensics of Windows devices
• Explore various third-party application techniques and data recovery techniques

The book is expected to be published in April 2018 and is available for pre-order here.

As a continuation of the “Introduction to Windows Forensics” series by Richard Davis, this video introduces Plaso and Log2Timeline. Log2Timeline is designed to extract forensic data from a computer system and aggregate it for analysis, and Plaso is the Python-based backend engine that powers the tool.

You’ll take a look at the major changes in Plaso Heimdall (20170930), and see the minor changes incorporated in version 20171118. Then, you’ll jump over to a Linux system and create a timeline for a Windows 10 image. Lastly, you’ll analyze the resulting Excel spreadsheet created by the tool and look at the wealth of information available to an examiner. If you’re new to forensic timelines, and/or are curious about Plaso Heimdall, you’ll quickly learn why the “super timelines” created by these tools are a critical asset to modern day forensics.

Starting with Autopsy 4.5.0, you can now determine when a file or phone number (or other artifact) was seen in a previous case. You can also be alerted when an artifact was found that was previously marked as “bad”.

These features are possible because of new infrastructure called the Central Repository. In this blog, we’ll talk about enabling the Central Repository and the corresponding Correlation Engine module.

Read more about it at Autopsy blog.

In the first post of the new year Mari Degrazia is writing about mounting APFS images in Windows. The thing is, Paragon has a free (preview) driver to mount APFS volumes in Windows! So with conjunction with our favourite Arsenal Image Mounter you can easily mount and browse APFS images with your Windows workstation.

This CSAFE webinar was presented by Dr. Padhraic Smyth from University of California, Irvine on September 28, 2017.

Description:

Time-series of user-generated events are routinely captured and logged on devices such as computers and mobile phones. This type of data is of increasing interest in forensic investigations. There has been relatively little use of statistical thinking in this context, for a variety of reasons. In this talk we will discuss recent work at UC Irvine (under CSAFE) that has begun to develop statistical techniques to answer basic questions about such data, building on methods such as marked point processes. We will outline the methodological approach and describe results to date on both simulated and real-world data. The talk will conclude with a brief discussion of challenges in this area as well as some thoughts on future research directions.

Sarah Edwards has published the second part of her “iOS Imaging on the Cheap” series. This time the post includes the jailbreaks for iOS 10.3.3 using Meridian and iOS 11 using LiberiOS. You can read the tutorial here.

Tom Sela has posted an updated version of his paper originally published in the March 2017 edition of eForensics Magazine. This article discusses two artifacts identified by the author as being significantly helpful when solving incidents: command prompt history and console output.

Yet another registry parser, or yarp, is a library and tools to deal with Windows registry files [1]. Despite the name, yarp is not a simple registry parser.

The project started as an attempt to fully implement the Windows registry file format specification [2] and to provide features important to incident responders and forensic examiners. This article will highlight one of these features – the registry file carver (the yarp-carver tool). Here, the “registry file” means a primary file for a hive, an external file for a hive (a file created with the RegSaveKeyEx function or a similar function), or a backup file for a hive (a file created by a kernel in the RegBack directory), but not a transaction log file.

Carving registry files

The carver will locate, identify, and validate registry files, including fragmented ones. When a registry file is fragmented, the carver will extract the first fragment (the truncated registry file) and identify the truncation (fragmentation) point. The yarp-print and yarp-timeline tools can be used to examine a truncated registry file.

The following steps are performed by the tool when carving registry files:

1. Search for the “regf” signature at the start of each sector (since registry files are not smaller than an MFT record, the tool does not need to try every offset possible).
2. If the signature is found, read the candidate base block (4096 bytes in length) from the same offset.
3. Validate the candidate base block: the base block must contain expected and reasonable values in corresponding fields. For example, the hive bins data size field must contain a value which is multiple of 4096 bytes, but is not too large, and the file type field must indicate a primary file.
4. If the base block is valid, move 4096 bytes forward, then read the specified (in the base block) number of bytes as the hive bins data.
5. Identify the truncation point, if the registry file is fragmented:
   • First, walk through the hive bins – all hive bins must be chained together using the offset and size fields, the first hive bin must contain the offset field set to 0, each subsequent hive bin must contain the offset value equal to the offset value of a preceding hive bin plus the size of that hive bin. A hive bin with an invalid or unexpected offset value or an invalid size (not a multiple of 4096 bytes) should be treated as a truncation point indicator. A missing hive bin should be treated as a truncation point indicator too.
   • Next, if a truncation point indicator is found, check the cells of the last valid hive bin. Since fragmentation can take place inside the last hive bin, check the last hive bin even if no truncation point indicator has been found at the previous step. To do this, walk through the cells of a given hive bin and locate an invalid cell, if it is present: an invalid cell is too large, or is crossing the hive bin boundary, or its size is not a multiple of 8 bytes.
   • If all cells of the last hive bin look valid (and no truncation point indicator was found before), then the registry file is not fragmented. If all cells of the last valid hive bin look valid, then the registry file is fragmented at a boundary of a hive bin (use the offset of the missing or invalid hive bin as a truncation point). Otherwise, the registry file is fragmented in the middle of a hive bin (use the offset of the invalid cell as a truncation point).
   • Since hive bins may contain large cells, there is an additional check: if cells preceding an invalid cell in a given hive bin contain the “regf” signature (indicator of another registry file) or the “hbin” signature (indicator of a hive bin from another registry file), use the location of that signature as a truncation point.
6. Adjust (round down) the truncation point according to the sector size (which is assumed to be 512 bytes), because fragmentation occurs at a cluster boundary (and a cluster contains one or more sectors).
7. Since the offset of the registry file and its real size (up to the truncation point, if fragmented) are known, the tool can copy the data to a file and skip to the next offset. If the base block contains the file name of the registry file, this file name will be used for the output file.

Carving registry fragments

The carver will locate and validate individual (freestanding) hive bins and individual sets of hive bins. These registry fragments can be examined using the yarp-print and yarp-timeline tools.

The following steps are performed by the tool when carving registry fragments:

1. Search for the “hbin” signature at the start of each sector.
2. If the signature is found, read the candidate hive bin header (32 bytes in length) from the same offset.
3. Validate the candidate hive bin header: the hive bin header must contain valid values in the offset and size fields (but the offset field is not required to be set to 0, because this hive bin could be located in the middle of a fragmented registry file).
4. If the hive bin header is valid, read and validate the cells (using the same approach as described above).
5. If all cells of the hive bin look valid, try to read the next hive bin right after the current one. If the next hive bin is valid and can be chained to the current one, treat these hive bins as a single registry fragment (and repeat this step to extend the current registry fragment). If the next hive bin is valid, but its offset field contains an unexpected value, treat that hive bin as belonging to a separate registry fragment (and repeat this step to extend the new registry fragment). If an invalid cell is found in the hive bin, treat this hive bin as the last one in the corresponding registry fragment; identify and adjust (round down) the truncation point using the rules defined above.
6. Copy the registry fragment to a file and skip to the next offset.

Image may be NSFW.
Clik here to view.

Carving compressed registry files and fragments

The carver will locate, identify, and extract NTFS-compressed registry files and fragments (using the LZNT1 algorithm). NTFS-compressed registry files can be found in restore points created by Windows XP.

The following layouts of compressed clusters are supported:

• Compressed clusters belonging to the same file are stored compactly, with no space between them.
• Compressed clusters belonging to the same file are stored with gaps between runs, the slack space (one or more clusters in a gap) can be allocated by another file (the number of compressed clusters in the run plus the number of clusters in the gap after this run is expected to be equal to the size of a compression unit in clusters).

The following values are assumed:

• Compression unit size: 16 clusters.
• Cluster size: 4096 bytes.

Since the “regf” signature in the beginning of a registry file and the “hbin” signature in the beginning of a registry fragment cannot be compressed, these signatures (in their literal form according to the LZNT1 algorithm) are used to locate the compressed registry data. If compressed clusters belonging to the same file are stored with gaps between runs, the carver will also examine the corresponding slack space.

When extracting a compressed registry file, hive bins and their cells are not checked. Thus, the fragmentation status of an extracted registry file is unknown.

When extracting a compressed registry fragment, only the header of the first hive bin is checked. The fragmentation point of an extracted registry fragment is unknown. An extracted registry fragment cannot be larger than a compression unit.

Reconstructing fragmented registry files

By default, the carver will attempt to reconstruct fragmented registry files. Reconstruction of NTFS-compressed fragmented registry files is not supported.

The reconstruction process is done in two stages:

• The brute-force stage (used to reconstruct registry files consisting of 2, 3, and 4 fragments).
• The incremental stage (used to reconstruct registry files consisting of 150 fragments or less).

Brute-force stage

Each truncated registry file identified and validated by the carver before is treated as the first fragment of an original registry file and concatenated with a different number of eligible registry fragments, then a resulting candidate hive is validated. All possible combinations of registry fragments are tried until the validation process succeeds for a candidate hive (this means that the reconstruction process succeeded) or there are no more registry fragments left (this means that the original registry file could not be reconstructed).

First, it is assumed that an original registry file consisted of two fragments (and the first one is already known – a truncated registry file itself), so the reconstruction process tries to find a single registry fragment to fill the missing part. Then (if the previous step did not succeed), it is assumed that an original registry file consisted of three fragments, so the reconstruction process tries to find two remaining registry fragments to fill the missing parts: one fragment is placed in the middle of a candidate reconstructed registry file, another one – at the end of that file. Finally, it is assumed that an original registry file consisted of four fragments, so the reconstruction process tries to locate three remaining registry fragments: two fragments will be placed in the middle of a candidate reconstructed registry file, while the fourth one – at the end of that file.

A registry fragment is considered eligible if it starts with a hive bin containing an expected value in the offset field. An expected value in the offset field is calculated as a value in the offset field of the last hive bin in a preceding registry fragment plus the reported size of that hive bin (taken from its offset field). If a registry fragment is going to be used in the middle of a registry file, this fragment must not reach the hive bins data size. If a registry fragment is going to be used at the end of a registry file, this fragment should reach or even exceed the hive bins data size (to account possible remnant data in the original registry file). Here, the “remnant data” means data between the end of the hive bins data and the end of the registry file (such data may be missing from a registry file, if Windows truncated this registry file during the shrinking process, when the number of allocated hive bins is being reduced by discarding hive bins at the end of the registry file).

If a registry file being reconstructed is truncated somewhere in the middle of a hive bin, a subsequent fragment is used with a margin. A margin is data located right before the selected subsequent fragment, its size is equal to the missing part at the end of the current registry fragment. This allows the reconstruction process to deal with registry files truncated in the middle of a hive bin.

The validation process involves walking through the whole tree of keys and values (if something goes wrong, the hive is considered invalid: for example, the hive is considered invalid when a child key node does not point to a proper parent key node, or when there is no valid record in a cell at a requested offset, or when there is no valid cell at a requested offset), comparing the number of allocated unreferenced cells against a threshold (to skip hives with an implausible number of allocated unreferenced cells), comparing the size of remnant data against a threshold (to skip hives with an implausible size of remnant data).

Incremental stage

The brute-force stage becomes slower when a greater number of fragments is considered. So, there should be means of reconstructing a fragmented registry file other than trying all possible combinations of registry fragments.

The incremental stage is achieving this by successively picking the largest eligible registry fragment until the hive bins data size is reached or exceeded. First, the reconstruction process will determine an expected offset for the next registry fragment; then, a list of such registry fragments is built, the largest registry fragment is chosen from that list and appended to the truncated registry file. If the hive bins data size isn’t reached at this point, the operation is repeated for the new expected offset (and a new registry fragment will be appended to the candidate registry file). If the hive bins data size is reached or exceeded, the resulting candidate registry file is validated in the same way as described above. If the hive bins data size is not reached after 149 registry fragments were applied to a truncated registry file (treated as the first fragment, so a final registry file cannot contain more than 150 fragments), the reconstruction of that registry file stops.

There is another mode of operation, which is very similar to the described above (both modes of operation are utilized by the carver). The difference is in the first iteration: when picking the second fragment (which is appended to the original truncated registry file), the second largest suitable registry fragment is chosen (instead of the largest one); other iterations remain the same.

Test results

According to the tests, approximately 10-25% of fragmented registry files can be reconstructed using the yarp-carver tool. This result includes registry files from allocated space and registry files that cannot be reconstructed at all (because of missing registry fragments).

It was found that a truncation point for a registry file fragmented within a large cell can be identified incorrectly using the validation method described above. The reason is that the validation algorithm does not examine the data stored in a cell. Such a large cell usually contains value data, thus a reconstructed registry file may occasionally contain corrupted value data. If such a large cell contains a subkeys list or a key values list and the registry file is truncated within active records of this list, then the reconstruction process for that registry file will likely fail.

Also, the carver cannot identify registry fragments that do not contain a hive bin header, such chunks of registry data cannot be extracted and used in the reconstruction process.

References

1. Yet another registry parser, URL: https://github.com/msuhanov/yarp
2. Windows registry file format specification, URL: https://github.com/msuhanov/regf

About the author

Maxim Suhanov

Independent digital forensics researcher and developer from Moscow, Russia

Recently we have received a good question from one of our DFIR mates: “How can one detect backdating of the system clock forensicating macOS?”. This is a really good question, at least for us, so we decided to research. If we are talking about Windows system clock backdating – there are a lot of information to help, for example, this SANS white paper by Xiaoxi Fan, but there is nothing about macOS.

Let’s start from macOS timestamps as they are very interesting and have a lot of evidentiary value. Let’s start from running mdls command on a sample file:

Image may be NSFW.
Clik here to view.

We must note that it’s not a simple file, it’s a Microsoft Word file, so it has even more timestamps than a regular file. If you start from the top of the figure, you may have noticed doc/docx-typical timestamps: content creation (kMDItemContentCreationDate and kMDItemContentCreationDate_Ranking) and content modification (kMDItemContentModificationDate). These timestamps are self-explanatory, so let’s go further.

Next timestamp is Date Added (kMDItemDateAdded), it’s date and time the file was added to the directory. There is also a date only timestamp – kMDItemDateAdded_Ranking.

Let’s continue with file system timestamps: content changed (kMDItemFSContentChangeDate) and created (kMDItemFSCreationDate) – pretty self-explanatory too, right?

As you may already noticed, there is another interesting timestamp – kMDItemInterestingDate_Ranking. Unfortunately, we are not able to tell you what exactly does it mean, but if you can, please post you suggestions in comments or Twitter!

Finally, there are two most valuable timestamps left: kMDItemLastUsedDate and kMDItemLastUsedDate_Ranking. These timestamps indicate the date and time or just date of file’s last usage. 

As you can see, there is a huge number of timestamps in macOS, but as you still remember, we are going to talk about detecting of backdating the system clock in macOS.

This research has been conducted on the MacBook Air running macOS High Sierra (10.13.2).

/private/var/db/timed

If you are familiar with *nix systems, you might already guessed, that timed is a macOS daemon watching the system time. It’s configuration is stored in a plist file – com.apple.timed.plist under /private/var/db/timed. But if the system clock has been backdated, there is another com.apple.timed.plist file, this time under /private/var/db/timed/Library/Preferences. Its timestamps shows you the exact date and time the clock has been backdated to! Look at the following figure:

Image may be NSFW.
Clik here to view.

As you can see, in our case the clock was backdated to 2016-11-01 09:16:51 (UTC). This piece of information may help you a lot in further search, for example, you can create a timeline with your favorite tool and look for user activity under this date.

/private/var/log/system.log

Of course, like event logs in Windows, logs in macOS, and, of course, system.log, will contain a good amount of evidence of the system clock backdating, here is an example:

Image may be NSFW.
Clik here to view.

As you can see on the figure, there is a very strange time change from January to November. And as we already know, our bad guys change the clock to this date, November, 1.

/private/var/log/install.log

Another useful log file is install.log. It’s located in the same directory as system.log, but its timestamps are even better:

Image may be NSFW.
Clik here to view.

On the figure you can see clear evidence of backdating from 01/21/2018 to 11/01/2016.

/var/db/uuidtext/

If you are into macOS forensics, you know what this folder is – unified logs! Sarah Edwards has a nice post about this type of logs, and these logs may be a source of backdating evidence too:

Image may be NSFW.
Clik here to view.

/.DocumentRevisions-V100/.cs/ChunkStoreDatabase

Another source of backdating artifacts is the ChunkStoreDatabase. It contains “chunks” used to store file’s previous version data. Look at the following figure:

Image may be NSFW.
Clik here to view.

We are forensicating CSChunkTable. As you can see on the figure, the first record in timeStamp column has “1516469407” value – it can be converted from Unix Epoch to human readable as Saturday, 20 January 2018 17:30:07 (UTC), but what about the second value? It’s “1477990845”, and can be converted to Tuesday, 1 November 2016 09:00:45 (UTC). Not good, right?

/Users/<username>/.bash_sessions

If you suspect has been using Terminal after backdating, you are likely to find some nice forensic artifacts under /Users/<username>/.bash_sessions:

Image may be NSFW.
Clik here to view.

The most interesting files here are those with .historynew extension, as they contain commands typed by the suspect in the backdated period. For example, C8CD29B6-87A1-4E02-B0F9-813E6EF05DA4.historynew has the following content:

ls -al /
cd /Users/
ls -al
cd olegskulkin/
ls -al

Timestamps

We think you have already guessed why we have started from macOS timestamps. If you know to which date and time the system clock have been backdated you can use timelining to find files and folders created, modified or used in this time period. Lets look at Secrets.rtf:

Image may be NSFW.
Clik here to view.

As you can see it was created in September 2017, but it was used and its contents were modified in November 2016. We bet this file contains or contained very valuable evidence!

Summary

Despite the fact there is a lot of information in the Web regarding detecting system clock backdating in Windows, there is no info about the same topic for macOS. With this research we have attempted to solve this problem. Of course, the list presented in this article isn’t full and may vary from version to version of macOS.

Happy forensicating!

About the authors

Oleg Skulkin, GCFA, MCFE, ACE, is a DFIR enthusional (enthusiast + professional), Windows Forensics Cookbook and Practical Mobile Forensics co-author.

Igor Mikhaylov, MCFE, ACE, OSFCE, is a digital forensic examiner with more than 20 years of experience and Mobile Forensics Cookbook author.