Thread by @billmarczak

NEW: Kaspersky releases full details on how they captured the “Triangulation” (suspected US Government) exploits and iPhone spyware targeting their employees. securelist.com/operation-tria…

The way Kaspersky wrote this, it's an interesting case study of defenders working out how to capture a zero-click exploit. I especially like that Kaspersky said what they tried that *didn’t work*, in addition to what did ultimately work. Let’s dive in with a thread!

If you’re a researcher who’s never captured an exploit chain from a threat actor “on the wire” recently, then you might not have run up against several “annoying roadblocks” that face a defender who sets out to complete this task.

FIRST, mobile phones like iPhones have “certificate pinning”, where ~all communications with Apple servers will fail unless they are authenticated with a specific hard-coded (pinned) TLS certificate. This means that there’s no using mitmproxy to peer into comms with Apple servers

So what if you want to capture a malicious iMessage like the one Triangulation used (sent via Apple servers)? There’s no playbook, but Kaspersky was in luck: years of iMessage hardening means most exploits are now sent via (out-of-band) attachment rather than in the iMessage body

Here’s one thing Kaspersky tried: employees whose phones were previously hacked signed into a Mac device with their iCloud accounts, hoping Triangulation would send malicious iMessage attachments to the Mac (where Kaspersky could capture them much more easily than on an iPhone)

No such luck! Why? On your iCloud account, each device (each of your iPhones, iPads, Macs, etc) has a separate “push token” (say, for the “com[.]apple[.]madrid” -- iMessage -- “APNs (Apple Push Notification Service) topic”).

It takes a bit of work, but you (or anyone with an iCloud account) can look up (say) iMessage “push tokens” by connecting to the com[.]apple[.]madrid-lookup service and specifying an email address or phone number for the iCloud account you want to look up.

It’s not necessarily immediately trivial to see which push tokens are for an iPhone (versus, say, a Mac, or iPad), but perhaps you (the attacker) can understand this through clever querying, or by “probing” different “APNs topics” on the device.

Anyway, since the destination of an APNs message (e.g. an iMessage) is a single push token, you (the attacker) simply send your exploits only to those push tokens representing the iPhone(s) you want to target, and omit the Mac Minis and everything else.

So that’s why Kaspersky’s gambit didn’t work there.. But on to the next thing they tried: as is pretty standard for messaging apps (e.g., iMessage, WhatsApp ...), attachments are transmitted out-of-band via an HTTPS link (plus a decryption key) included in the message body.

The link and the decryption key are locally recorded. BUT, of course, if the message gains code execution (when it gets processed by iMessage), then what’s the first thing it’s gonna do?? Delete these records obvi. So you need a way to get at them before they’re deleted.

What Kaspersky did here was actually pretty ingenious. They flipped a few bits of the iMessage payload on-the-wire, causing it to fail to download, but still causing the metadata (the HTTPS URL for the attachment, and its decryption key) to be recorded on the phone.

They thus guaranteed that the attachment wouldn’t get code execution. They obtained the URL and decryption key from a regular iTunes backup. Then, Kaspersky just fetched (and decrypted) the attachment at their leisure! Gotta remember this technique 😀

What was the attachment? A malicious .watchface file that forced the phone to open a browser and navigate to a malicious URL (!!!) (Would love to know how that worked). Anyway, now we're in the browser, facing a second roadblock...

SECOND, as is standard these days, ~every competent threat actor uses JavaScript (JS) to do (e.g.) a Diffie-Hellman key exchange between the browser and the exploit server before fetching further exploits/spyware, in order to evade mitmproxy.

In this scheme, a “public” and “private” key are generated; the threat actor JS sends the “public” key to the exploit server, but only the “private” key (safely ensconced in the web browser’s memory) can be used to decrypt the exploits sent back by the exploit server.

This means that a naive “just use mitmproxy to strip the TLS, bro” solution doesn’t work, you need to do more. And, by the way, you can’t dump the web browser’s memory to recover the private key (no memory dumps on phones unless you, the defender, have an exploit to do this).

So you’re stuck right? Well not exactly. As Kaspersky shows, the standard playbook here is you (the defender) use here is you use mitmproxy to modify the threat actor’s encryption code as it is downloaded to cause it to generate a keypair where you “already know” the private key

At this point, Kaspersky just kept iterating through the various stages, modifying code as it was downloaded to subvert the attacker's encryption and obtain the next stage, until they got to the final payload.

So what are the takeaways for attackers here? Well first, don’t target security researchers! There’s a *huge* advantage that defenders get in terms of capturing and burning exploits/spyware when *they are* the target (vs someone else they're trying to defend).

Second, if you must target security researchers, don’t target them “too often” with the “same” tradecraft, otherwise they’ll do exactly what Kaspersky did: learn a tiny bit from each successive attack and ultimately gain enough knowledge to fully capture your exploits/spyware.

Third, gather telemetry on your attacks, and watch it like a hawk! Victim takes 3 seconds too long to fetch the next exploit or stage of spyware? Failures on a target exceed a threshold? Then your operations room should look like the Starship Enterprise during a Red Alert