Bill Marczak

It also indicates that Apple has a MAJOR blinking red five-alarm-fire problem with iMessage security that their BlastDoor Framework (introduced in iOS 14 to make zero-click exploitation more difficult) ain't solving.

Phone logs show that (at least some of) the iOS 13.x and 14.x zero-click exploits deployed by NSO Group involved ImageIO, specifically the parsing JPEG and GIF images. ImageIO has had more than a dozen high-severity bugs reported against it in 2021.

BlastDoor is a great step, to be sure, but it's pretty lame to just slap sandboxing on iMessage and hope for the best. How about: "don't automatically run extremely complex and buggy parsing on data that strangers push to your phone?!"

Also, (3) as @AmnestyTech observed and we @citizenlab can confirm, NSO Group's Pegasus spyware delivered via 0-click exploits is no longer "persistent" in the strict sense of the word (i.e., doesn't come back when you reboot). Persistence is achieved via firing the 0-click again

Because the 0-clicks they're using appear to be quite reliable, the lack of traditional "persistence" is a feature, not a drawback of the spyware. It makes the spyware more nimble, and prevents recovery of the "good stuff" (i.e., the spyware and exploits) from forensic analysis

(4) One of the other interesting bits here is just how much of pain it is to do phone forensics. @AmnestyTech couldn't do much w/ Android (as a lot of logs that are easy-to-access are wiped on device reboot), and the highest-signal iPhone analysis was limited to DataUsage.sqlite

DataUsage.sqlite is a file in an iTunes backup that records process names accessing the mobile data, as well as bytes uploaded and downloaded. Information can persist in here for *years* unless cleaned up. So, in around 2019, NSO Group decided to try their hand at cleaning it up.

Most of the information is in two tables, ZLIVEUSAGE and ZPROCESS. Entries in ZLIVEUSAGE reference an implicit foreign key in ZPROCESS, but there is no formal DB constraint, nor is there an ON DELETE CASCADE. Sooo... NSO deleted entries from ZPROCESS but not ZLIVEUSAGE.

This leaves an implicit inconsistency in the database which can be observed. Oh, and also you can just run "strings" on the DataUsage.sqlite file and find the deleted entries...

Another bit (5), is the fact that @AmnestyTech (and also @citizenlab) were able to trace NSO's "version 4" domain names, which NSO was using for command-and-control thru mid-2020, and for exploit/payload delivery thru early-2021. So how did this mapping work?

I'm not going to burn @citizenlab's exact process here, but I *do* want to relate a really fascinating story. Previously, we used to detect most of these through IP-based Internet scanning. But NSO threw three new major wrenches into our process here in 2018.

Since NSO (or clients) control the DNS servers for the 3rd-level domain (e.g., *.f15fwd322[.]regularhours[.]net), they respond to the lookup, and have the chance to open the appropriate port on the infection server.

Wrench #3: The infection servers' domain names no longer appeared in SMSes. Instead, NSO created "URL shortener servers" hosted on shared-IP hosting that redirected to these bizarre 4th-level subdomains. Shared-IP hosting means scanning by IP will *not hit* the infection servers.

These three wrenches were a direct challenge to the IP-based Internet scanning methodology we used in 2018. However... what NSO taketh away, NSO also giveth :).