Mac OS Daily Logs


I recently attended the awesome SANS DFIR, Mac and iOS Forensics and Incident Response course with Sarah Edwards. This has obviously given me lots of great inspiration on how to negotiate Mac analysis in general and to take a closer look at some of those system files that we covered in training.

I’ve spent a little bit of time digging through the log files on my MacBook (Mojave 10.14.2). I’m sure this isn’t new to most practised Unix beards but for those who aren’t aware, there’s a really great little log file called daily.out in /var/log. I had previously given little credence to this log but realised it can be used to determine a whole wealth of useful information. I also reviewed the weekly.out and monthly.out files but these were, in my case, far less granular.

At a high level daily.out contains information relating to disk usage and networking, this file is written at least daily and the configurations for all three of the periodic logs are stored in plist files in the following location:


After reviewing the content of this file, it made me consider how this might assist in some of my casework?

Disk Usage

Firstly, I borrowed some grep skills from a very knowledgeable and tall colleague on my team to see if we could parse out just some specific information from the daily.out file. We extracted the lines only containing the dates, followed by the lines which related specifically to disk usage.

grep -E -e "\w{3} \w{3} .\d (\d\d\:){2}" -e "(/dev/disk|Disk status|iused)" daily.out

From this, we were able to find entries dating back as early as 3 months, and that the log contains:

  • Logical volumes mounted at the time entries are written
  • Size of volumes
  • Space used on volumes

As you can imagine, disk volume information will be highly valuable in showing drives or images which were attached when the log was written and especially if you know the volume name used by a device you’re looking to prove access to.

We can also ascertain some other information from this log which is quite valuable.


Screen Shot 2018-12-11 at 9.37.25 am


You may have an instance where a suspect, subject or general bad person is saying they have never used their Bootcamp install, however, you can see from the Bootcamp disk usage that the volume is being written to and from regularly. Perhaps a big chunk of data has been deleted before a date of interest?


Another interesting piece from the daily.out file is that it will show uptime of the system when the log entries are written. This could help prove whether or not the system was switched on and in use over a specific period.

This may also show some interesting information about account usage on the computer. As Mac computers generally tend to be used by individuals, this means there’s usually only ever one account logged on at any time. If you have an experienced user who is elevating to root every day, then seeing multiple accounts logged on may not be uncommon. Although, if an inexperienced user who has no knowledge of the root account, is logged on many times when another account is logged on, it may be suspicious or warrant further analysis.

Again, we extracted the lines from the daily.out file we are interested in using a simple grep command:

grep -E -e "\w{3} \w{3} .\d (\d\d\:){2}" -e "Local system status" -e "load averages" daily.out

As you can see we can pull some interesting information about computer and account usage:

  • Shows uptime of the system at the point in which the daily.out entry is written
  • Also shows the number of users logged on, remember this is usually going to be one

There are also some very useful network interface statistics listed in this file which are probably more relevant to IR investigations but we may look at these another time.


Click to access summit-archive-1493741667.pdf

Notifiable Data Breach Statistics

If you’ve been working in Digital Forensics or Incident Response in Australia then you should be aware of the new legislation relating to notifiable data breaches by the Office of the Australian Information Commissioner (OAIC).

In amongst the OAIC’s website, there is some very useful information for incident responders as well as companies who are unsure as to whether they need to disclose when they’ve have had a data breach. You may already work for a mature organisation that has had appropriate legal and technical council in relation to this but if it’s all new to you then I suggest now is a very good time to start reading.

The OAIC outlines a data breach as so:

A data breach occurs when personal information that an entity holds is subject to unauthorised access or disclosure, or is lost.

Personal information is information about an identified individual, or an individual who is reasonably identifiable.[1] Entities should be aware that information that is not about an individual on its own can become personal information when it is combined with other information, if this combination results in an individual becoming ‘reasonably identifiable’ as a result.

A data breach may be caused by malicious action (by an external or insider party), human error, or a failure in information handling or security systems.

Examples of data breaches include:

  • loss or theft of physical devices (such as laptops and storage devices) or paper records that contain personal information
  • unauthorised access to personal information by an employee
  • inadvertent disclosure of personal information due to ‘human error’, for example an email sent to the wrong person
  • disclosure of an individual’s personal information to a scammer, as a result of inadequate identity verification procedures.

The OAIC has recently released quarterly statistics and there are some interesting points which have come out of this.

1: The highest number of individuals affected were 1,000 or fewer across 107 different breaches.

2: It would seem that healthcare organisations are still top of the list for all sorts of targetted attacks in Australia. This comes as no surprise and a statistic that is common in most developed countries.

Investment in security and infrastructure are clearly still lacking in this area since the WannaCry outbreak hit so many systems worldwide.

3: The number of breaches being reported has gradually increased since the start of 2018. Presumably, this will continue to increase.

4: The largest amount of data loss relates to contact information such as names, addresses, email addresses. This is closely followed by financial details. This reflects the businesses which are predominantly targeted (health and finance).

This is also a clear indicator that the low hanging fruit is going to be the most leveraged by attackers. It should come as no surprise that we should expect to see just as many, if not a marked increase in targetted phishing campaigns.

5: Human error still accounts for 36% of data breaches, this indicates there is still a major gap in staff awareness across all industries. Interestingly, the most accidental disclosures happened by PI being sent to the wrong email address but the largest amount of affected individuals was due to loss of paperwork or storage device.

6: 59% of breaches were due to malicious or criminal attacks. Again, this clearly shows there needs to be further investment in education and security.

The highest of these types of malicious or criminal breaches were classed as Cyber Incidents and the breakdown of this can be seen as such:

Compromised credentials being the highest at 34%
Phishing at 29%

I think we know where this is going… Investment in education, training and security.

Some final observations:

  • Questions from clients and their insurers are gravitating more so than ever around what went out the barn door, rather than what led to the door being opened.
  • Phishing is still a huge problem for all industries.
  • Ransomware is largely going unreported. I suspect this may be due to the assumption by many IT vendors when responding is that all ransomware outbreaks are ‘smash and grab’ attempts.
  • Understanding how credentials are compromised and how they are being compromised is still largely unknown in most industries.
  • Reporting is on the increase, this can only be a good thing for the general populous

For further reading:

Click to access notifiable-data-breaches-quarterly-statistics-report-1-april-30-june-2018.pdf

Windows 10 Timeline – Initial Review of Forensic Artefacts

As you may be aware, there is already a plethora of forensic tools available for producing system timelines, all with their own capabilities and some with limitations. From Sleuth Kits FLS/Mactime, Plaso/Log2timeline, XWF, Axiom, Encase and more recently Timeliner for Volatility.  I’m sure many more have performed this function to varying degrees over the years but Microsoft hasn’t been one, until now.

Last patch Tuesday, Microsoft released Windows 10 update (1803) which has brought along a number of new features including a new Timeline function, which allows users to look back in time at their previous activities.

This got me thinking.

A built-in Windows utility which shows linear recent activity (within thirty days) on a computer system and runs under user context.

Very interesting… Let’s take a look!

File Creation/Opening

First I had to find out where Windows tracks all of this activity. A simple keyword search for a sample document name ‘This is a test document.docx’ exposed the following file as a potential area of interest:


Now, SQL is not my forte so I had a pretty rudimentary poke around by parsing it out to csv to see what I could find. The database file contains a number of tables and of initial interest, I would highlight the ‘Activity’ and ‘Activity_PackageID’ tables for a first look to interrogate this file.

Windows 10 Timeline

Windows 10 Timeline


In the ‘Activity’ table under ‘AppID’, Microsoft Word can be seen as the application used to open the file.

Screen Shot 2018-05-05 at 10.10.29 pm

From the ‘Payload’ entry you can identify further display options for the Timeline entry, including ‘Word’ and the display text being the filename.



Other notable entries found in the Activities Cache database are the associated timestamps. For our test document mentioned above, you can see the following timestamps which are stored in Unix format within the ActivitiesCache.db file:

Last Modified: Tue, 1 May 2018 20:28:18

Expiration Time: Thu, 31 May 2018 20:28:18

Start Time: Tue, 1 May 2018 20:28:18

Last Modified on Client: Tue, 1 May 2018 20:28:18

After some testing, I identified that the expiration time is as expected, thirty days from the entry start time. The timestamps do not appear to be updated after a file is deleted although the deleted file will remain visible in the Timeline (presumably for up to thirty days or when the database is purged). Timestamps do not appear to be updated within a twenty-four hour period, after modification to files.

Program Execution

The ‘Activity_PackageID’ table contains entries for applications which include paths for executables, executable names and also the expiration time for these entries. This activity not only shows applications that were executed within the last 30 days but by backdating the expiration timestamp, you may be able to identify a time when that application was run and by which user. This can obviously be correlated with other artefacts such as prefetch.


This is just some initial testing and there is a wealth of further information in this file which will need further analysis to decode fully. It’s certainly nice to see some new functionality in Windows which not only serves a meaningful purpose for the end user but also provides examiners with another artefact showing user interaction, web browsing activity, program execution, file opening and creation.


Eric Zimmerman has written a tool now to parse this database and you can find that along with all his other amazing tools, here: