Kaspersky has shared more details of a novel iOS spyware that it discovered earlier this year when its own devices came under attack in a campaign dubbed Operation Triangulation.
Dozens of Kaspersky employees are understood to have been affected by the advanced persistent threat (APT) campaign, which employed a “sophisticated method” of distributing zero-click exploits via iMessage in the service of taking over the device and surveilling it.
Kaspersky said that the vulnerability exploited in the attack was one of “the most glaring gaps in system protection” and “one of the most potent we’ve encountered to date”.
The malicious implant, called TriangleDB, is deployed after the threat actor first obtains root privileges on the target device two chained vulnerabilities, but because it is deployed in memory it is erased if the device is rebooted, in which case the attackers have to start over.
It communicates with a command-and-control (C2) server once launched, pinging it from time to time with “heartbeat” data such as system information, device identifiers and so on, to which the C2 server responds with various commands using the open source Protobuf data interchange format developed at Google.
These commands perform various functions including creating, modifying, exfiltrating and removing files, interacting with device processes, dumping keychains for credential harvesting, location monitoring, and loading and running additional executables.
Stealthy campaign
In their latest update, Kaspersky’s Georgy Kucherin, Leonid Bezvershenko and Valentin Pashkov revealed how the threat actor behind TriangleDB deployed some exceptionally stealthy methods to cover their tracks.
Of particular interest are two validator stages identified by the researchers. These are referred to as JavaScript Validator and Binary Validator and work together prior to the delivery of the malware implant to assess if the iPhone or iPad under attack could possibly be a research device, in such a way that the attacker can beat a hasty withdrawal if there is a chance that their zero-day and exploits don’t get burned “by mistake”.
The first, JavaScript Validator, works thus. In the first stage of the campaign, the victim receives the invisible iMessage attachment containing the zero-click exploit, which silently opens a unique URL on the backuprabbit domain. This malicious HTML page contains obfuscated JavaScript code of the NaCl cryptograhy library and an encrypted payload, the validator itself.
Once downloaded, the validator conducts several checks and employs a fingerprinting technique known as Canvas Fingerprinting – in this case, it draws a yellow triangle on a pink background (hence the name TriangleDB) using WebGL then calculates its checksum. It then encrypts and sends all the information collected to a another backuprabbit URL in order to receive the next stage of the infection chain.
The Binary Validator then arrives in the form of a Mach-O binary file – not a script – which when launched decrypts its configuration using AES. The configuration is a plist that contains a list of actions for the validator to perform, specifically to remove crash logs from the device that could already have been created, and search for traces of the initial malicious iMessage attachment in various device databases and get rid of them. To do this, the validator’s configuration contains multiple hashes of Apple IDs used by the APT actor, which use email addresses provided by services including Gmail, Hotmail, Outlook and Yahoo – the researchers have published these addresses in their write-up.
The validator further obtains a list of processes running on the device and a list of network interfaces, checks whether or not the device is jailbroken, turns on personalised ad tracking, collects victim information including username, phone number, IMEI identifier and Apple ID, and compiles a list of installed applications. Once this information gets returned to the C2 server, the TriangleDB implant is delivered.
But the sneakiness does not stop there, said Kucherin, Bezvershenko and Pashkov. They found that the TriangleDB implant itself contains multiple safeguards to obfuscate its attack chain and presence, including retrieving device logs that may offer clues to researchers and deleting them from the device.
“The adversary behind Triangulation took great care to avoid detection. They introduced two validators in the infection chain in order to ensure that the exploits and the implant do not get delivered to security researchers,” said the team.
“Additionally, microphone recording could be tuned in such a way that it stopped when the screen was being used. The location tracker module may not use standard GPS functionality if this is unavailable, but rather metadata from the GSM network.
“The attackers also showed a great understanding of iOS internals, as they used private undocumented APIs in the course of the attack. They additionally implemented in some modules support for iOS versions prior to 8.0. Recall that these were widely used before 2015, which gives an indication of just how long the code of the modules has been in use.
“Last but not least, some of the components used in this attack contain code that may indicate that they are targeting macOS systems as well, although, as of the publication date, no Triangulation traces have been encountered on macOS devices,” they added.
Attribution unlikely
Kaspersky rarely if ever makes firm attributions of threat activity, and has kept quiet as to who may have been behind Operation Triangulation.
However, in June of this year, the Russian federal security agency, the FSB, claimed that the US intelligence services were behind the intrusion, and operated with Apple’s full knowledge and support.
None of these claims have been verified, and it is important to note that Apple released patches for the two zero-day vulnerabilities, CVE-2023-32434 and CVE-2023-32435, that Kaspersky’s researchers identified as being used in the TriangleDB infection chain, on 21 June.
An Apple spokesperson said: “We have never worked with any government to insert a backdoor into any Apple product, and never will.”