Clipping Wings: Our Analysis of a Pegasus Spyware Sample
Black Hat Asia 2024 Preview from iVerify VP of Research, Matthias Frielingsdorf
According to Kaspersky, mobile threats now account for 40% of all detected threats. Similarly, Google’s Threat Analysis Group (TAG) recently reported that 20 out of 25 zero-days discovered in 2023 were exploited by commercial spyware vendors (CSVs). Once thought to be contained to high-risk individuals such as journalists and political dissidents, the immediate threat of mobile-first zero-days has finally hit businesses resulting in intellectual property theft, credential breaches, corporate espionage, and ransomware attacks.
One of the most commonly detected spyware in 2023 was Pegasus, developed by NSO Group and the subject of Amnesty International’s investigative journalism initiative: the Pegasus Project. Several months ago our team discovered evidence of Pegasus during an analysis of a customer’s iPhone and we were able to extract the PassKit file from the device’s backup.
This post is a preview of my briefing at the upcoming Black Hat Asia conference, where I’ll show the results of our analysis of the malware sample!
Mobile-First Zero-Days: Acknowledging Past Research
Previous studies from the research community identified several iOS vulnerabilities exploited by attacks to install Pegasus on target devices.
One of them, which was subsequently fixed by Apple was CVE-2023-41064, which allowed an attacker to craft an image to gain code execution inside of ImageIO using the WebP image format. Existing resources provide an excellent description of this vulnerability, including:
- Apple at support.apple.com/en-us/106361
- Ben Hawkes at blog.isosceles.com/the-webp-0day/
- LiveOverflow at youtube.com/watch?v=lAyhKaclsPM and youtube.com/watch?v=PJLWlmp8CDM
Additionally, CitizenLab previously released details about an exploit chain called PWNYOURHOME that used a combination of HomeKit and iMessage to attack devices. They later revealed details about BLASTPASS, an exploit discovered in the wild targeting iMessage and PassKit (Wallet).
Our analysis of an actual BLASTPASS exploit sample adds to the industry’s current body of knowledge catalyzed by these researchers and more.
Backups, Backups, Backups
For this analysis, we had access to the customer’s iTunes backups, crash logs, and sysdiagnose files. One of the best things about Threat Hunter is that we can gather these artifacts remotely without needing physical access to the device.
This was one of the rare cases where we could spot something obvious right away.
We started our analysis by reviewing the available files and directory of crash logs. To our surprise, this was one of the rare cases where we should spot something obvious right away. We found 25 crashes of the homed process occurring within a 19-minute window. As we’ve seen before, recurring crashes of the same process often suggest the presence of a nasty bug or an attempted exploit. We often see both when analyzing suspicious iPhones since iOS is far from bug-free, which you’ll notice if you routinely check your crash logs or Apple’s Security Releases.
An important note about the homed crashes we saw – they weren’t the kind of crashes we’d characterize as severe like Segmentation Fault or Null Pointer Deref. These are pretty normal crashes, but they occurred with unusual frequency.
We also noticed a couple of crashes of the MessagesBlastDoorService. BlastDoor is the tightened sandbox that Apple introduced in iOS 14 to thwart iMessage Exploitation after NSO abused it. In theory, that should have resulted in every iMessage attachment being rendered and parsed safely inside of BlastDoor. However, we saw a large number of MessagesBlastDoor crashes happening within a short period, starting approximately 30 minutes after the last crash of homed.
Could all of this be just a coincidence – a combined series of homed and MessagesBlastDoorService crashes occurring so close together?
Not likely. To understand why, let’s go back to details found in the crash logs.
Not only do we eventually find more severe crash types, we also see MessagesBlastDoorService trying to unarchive a very large or very repetitive NSKeyedArchiver. The CallStack of the crashing stack screams suspicious and other MessagesBlastDoorService crashes follow the same pattern.
Ultimately, our analysis of the crash logs revealed the following:
- 25 crashes of the homed process in under 19 minutes
- Followed by a 30-minute break
- 35 crashes of the MessagesBlastDoorService in less than 28 Minutes
Does this mean the exploit attempt was successful? Is it Pegasus or something else trying to copy NSO’s exploits? To answer these questions, we next looked at the iTunes backup. For step-by-step instructions on how to create forensic artifacts using iTunes, check out my talk from Objective by the Sea v6.0.
We started looking at the timestamps in the iTunes backup that correlated to the suspicious cash logs. However, without a good strategy, backup analysis can be very time-consuming due to the overwhelming volume of data. Going through all of the messaging data, thousands of pictures, and other databases in the backup can easily add up to thousands of lines of text for inspection.
In this blog post, we’re not going to go through all of the strategies we use, but we are sharing one that leads to the same outcome as taking the reference point from the crash logs.
To Find a Needle in a Haystack, Remove the Hay
This strategy requires an understanding of certain processes involved in the transfer of data on the device, such as IMTransferAgent, which downloads iMessage Attachments from the Apple Server. This process often occurs before attachments are stored on disk and was highlighted in Kaspersky’s analysis of Operation Triangulation.
Looking for instances of this process is a good place to start, but be mindful that iTunes backups include two sources of network behavior associated with this process: DataUsage.sqlite and OSAnalyticsADDaily. The former only stores network usage for cellular data and the latter stores the last time the process used network data on wifi or cellular. If the device does not use cellular data or is often on wifi, there won’t be much to find through this approach.
Fortunately, in this case, our search for IMTransferAgent found multiple results and one of them correlates precisely to when the MessagesBlastDoorService crashes appeared.
Because IMTransferAgent is used to transport data to and from iMessage servers, it makes sense to check if there is any file activity around the same time. The iTunes backup shows that 8 files were received shortly after the moment IMTransferAgent was used and MessagesBlastDoorService crashed. Moreover, those files did not have an identified sender; they were “Sent from None.”
The received items were all named “sample.pkpass” and they have a combined size of approximately 175 KB. As a reminder, pkpass is the file extension for PassKit Passes. There’s a nice write-up about it from Apple here. Additionally, CitizenLabs’ report also mentions that the BLASTPASS exploit chain contained a PassKit file that was sent over iMessage.
The plot thickens!
Inside the PassKit File: Findings and Conclusions
Next, let’s look inside the file. We located the sample in the iTunes backup – a possible indication that the exploit chain was unsuccessful or it was not NSO because they typically try to clean up the iMessage Attachment folder after a successful exploitation.
We started by asking file what the sample.pkpass is:
Decompressing the 175KB file expands it to a 5.9MB archive containing the following files:
Running file on all of those yields this:
Pass.json is not very interesting; it merely indicates this is a PKpass file. Yes, thank you.
Signature contains the signature of the file and manifest contains a list of the files included in the archive as well as their SHA1 hash. background.png is essentially an empty picture and not interesting for our investigation.
But logo.png is different. It's a large 5.8MB picture which is not a png, but a WebP picture, another reference to the BLASTPASS exploit chain.
Looking at the raw hex bytes with xxd confirms that we indeed have a WebP file:
The file also includes the starting header for an Apple binary plist format: bplist
That’s interesting!
Binary Plist are usually PropertyList documents based on a NSKeyedArchiver, which gives us another link between the sample.pkpass file and the MessagesBlastDoorService crashes because many of the functions in the backtrace were functions related to unarchiving NSKeyedArchiver objects!
Our analysis continued beyond this point. At this stage we suspected that NSO (or someone impersonating their playbook) first tried to use the PWNYOURHOME exploit and when that failed, shifted to BLASTPASS.
If you are interested in more details about our BLASTPASS analysis or our Threat Hunter tool, please check out my briefing at Black Hat Asia in April. We will also share more about it here on the blog!
.svg)
.svg)
.svg)
.svg)
.png)
.svg)
