Detection Of Backdating The System Clock In MacOS

by Oleg Skulkin & Igor Mikhaylov

Recently we 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 it. 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:

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.


Get The Latest DFIR News

Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month.

Unsubscribe any time. We respect your privacy - read our privacy policy.


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. Its 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 show you the exact date and time the clock has been backdated to! Look at the following figure:

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:

As you can see in 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:

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 log, and these logs may be a source of backdating evidence too:

/.DocumentRevisions-V100/.cs/ChunkStoreDatabase

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

We are forensicating CSChunkTable. As you can see in the figure, the first record in the 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:

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. Let’s look at Secrets.rtf:

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 online 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.

Leave a Comment