Introduction

In the ever-evolving landscape of mobile security, hunting for malware in the iOS ecosystem is akin to navigating a labyrinth with invisible walls. Imagine having a digital compass that not only guides you through this maze, but also reveals the hidden mechanisms of iOS malware previously shrouded in mystery. This is not a tool – this is the nature of digital forensic artifacts. In this blog post, we’ll explore one particular forensic artifact that stands out for uncovering some of the most elusive malware on iOS devices and shedding more light on the traces left by the sophisticated threats endangering the trusted companions in our pockets.

In 2021 and 2022, we had the privilege of working on a few Pegasus malware infections on several iPhone devices. The iPhones were Initially given to us by our partners for general security checks before we discovered the infections.

Investigating such cases can be complicated, costly, or time consuming due to the nature of the iOS ecosystem. As a result, related threats can often go undetected by the general public. To date, the common methods for analyzing an iOS mobile infection are either to examine an encrypted full iOS backup, or to analyze the network traffic of the device in question. Both methods, however, are time consuming or require a high level of expertise, which limits their use.

Through our analysis, we discovered that the infections left traces in an unexpected system log, Shutdown.log, which is a system log file available on any mobile iOS device. Since the detection method was consistent across several infections we’ve analyzed, we thought we would dissect and understand this log file in more detail, as it could be used as another method to detect mobile malware.

Overview of an iOS artifact: Shutdown.log

Shutdown.log is a text-based log file created on iOS devices. Each reboot event is logged in this file along with multiple environment characteristics. Having looked at dozens of these log files, they can have entries going back several years, which can provide a wealth of information.

When a user initiates a reboot, the operating system attempts to gracefully terminate running processes before rebooting. If a “client” process is still running when the reboot activity begins, it is logged with its process identifier (PID) and corresponding filesystem path. The log entry notes that these processes prevented a normal reboot and that the system is waiting for them to terminate. A UNIX timestamp is provided for the system event indicating that memory buffers are flushed in preparation for a full OS shutdown.

Compared to more time-consuming acquisition methods like forensic device imaging or a full iOS backup, retrieving the Shutdown.log file is rather straightforward. The log file is stored in a sysdiagnose (sysdiag) archive.

Sysdiag can be thought of as a collection of system logs and databases that can be generated for debugging and troubleshooting purposes. The method for generating a sysdiag may differ from one iOS version to another. Nevertheless, this archive can be found in the OS general settings, specifically under “Privacy and Analytics”, although again the exact location name may differ between iOS versions.

The archive is created relatively quickly, typically taking only a few minutes. The result is a .tar.gz file about 200-400MB in size. This file can then be transferred to the analysis machine. Once the archive is unpacked, the Shutdown.log file is located within the “\system_logs.logarchive\Extra” directory.

Malware detections and lessons learned

When we first started analyzing the supposedly infected phones, we tested them with the MVT tool developed by Amnesty International. At the time, MVT identified malware indicators by parsing the DataUsage database, among other forensic artifacts.

Because mobile malware was becoming more prevalent, and detection methods were time consuming, we looked for a faster and easier method. While network traffic analysis can be a very effective lightweight method for identifying a potential iPhone infection, processing network traffic can require a high level of expertise and resources. Sysdiag dump analysis is a minimally intrusive and a resource-light method of identifying possible iPhone infections using system-based artifacts. It can serve to supplement infection identification from a different vantage point.

If we take a sample log file for a spin, it shows a known Pegasus infection trace under “/private/var/db/com.apple.xpc.roleaccountd.staging/rolexd”.

Having received the infection indicator in this log and confirmed the infection using MVT’s processing of other iOS artifacts, this log now becomes part of a holistic approach to investigating the infection. Since we confirmed the consistency of this behavior with the other Pegasus infections we analyzed, we believe it will serve as a reliable forensic artifact to support infection analysis.

While analyzing the various infections, we made several observations. One of the infected phones had infection indicators in the usual artifacts such as the DataUsage database, but there were no traces in the Shutdown.log. Further analysis revealed that the user didn’t reboot on the day of the infection. This observation makes sense, since Shutdown.log only records entries upon reboot.

Another interesting observation we made on another infected phone is that occasionally, when there’s a “sticky” process preventing a reboot such as the processes related to Pegasus, the log file will also record a notification indicating that a reboot was delayed; we’ve observed Pegasus-related processes in more than four reboot delay notices. While we did see instances of non-infected phones with two to three reboot delay notices, we consider excessive delays (more than four) to be another log anomaly that needs to be investigated.

As we continued researching sysdiag archives and Shutdown.log, we read up on CitizenLab’s analysis of Reign and spotted something we had seen before: the malware’s path.

Comparing the Shutdown.log for the Pegasus infections we analyzed and the artifacts for the Reign path above, we noticed other similarities with such infections. Malware execution originating from “/private/var/db/” seems to be consistent across all the infections we’ve seen, even if the process names are different. This is also true for another mobile malware family, Predator, where a similar path, “/private/var/tmp/”, is often used.

Since all three malware families were using a similar filesystem path, and since we confirmed from the Pegasus infection analysis that such a path can be seen in Shutdown.log, we believe that this log file may be able to help identify infections by these malware families. But there’s a BIG caveat… the user needs to reboot as often as possible. How often, you may ask? Well, it depends! It depends on the user’s threat profile; every few hours, every day, or perhaps around “important events”; we’ll leave this as an open-ended question.

Analysis scripts

To automate the analysis process, we’ve created a few Python3 scripts to help extract, analyze and parse the Shutdown.log artifact. As a prerequisite, the user needs to generate a sysdiag dump and extract the archive to the analysis machine.

Script 1: iShutdown_detect

The first script is about detecting the anomalies mentioned above, inside the Shutdown.log. The script analyzes the log file in question in the background and displays any of the anomalies. Think of this script as a lightweight method to analyze a forensic artifact for unusual entries. It’s meant to support an investigation, not as a silver bullet.

The examples below show some of the results you would expect to see:

Script 2: iShutdown_parse

We understand that there are instances where analysts and users want to share their log files and parse them for different purposes. So this script is an attempt to support that need. This script takes a sysdiag archive as an argument and extracts the Shutdown.log file from it. If instructed, it will also convert it to a CSV file, decode the timestamps, and generate a summary of the parsing that includes the source sysdiag and the extracted Shutdown.log hashes.

Script 3: iShutdown_stats

The last script can be used for various purposes, such as understanding how often or when a user has rebooted the phone. This script takes into account that you have extracted the log file in question as it takes it, and not the sysdiag archive, as an argument.

Conclusion

In conclusion, we’ve analyzed and confirmed the reliability of detecting a Pegasus malware infection using the Shutdown.log artifact stored in a sysdiag archive. The lightweight nature of this method makes it readily available and accessible. Moreover, this log file can store entries for several years, making it a valuable forensic artifact for analyzing and identifying anomalous log entries. Again, this is not a silver bullet that can detect all malware, and this method relies on the user rebooting the phone as often as possible.

We’ll continue to analyze the Shutdown.log file in more detail and on different platforms. We expect to be able to create more heuristics from the entries in it. We’d love to hear from you if you have any interesting samples that could contribute to this research. As you have seen in this blog, and can even see in your own sysdiag analysis, the Shutdown.log file does not contain any personal information, so feel free to contact us at [email protected] if you’d like to contribute.