Dissecting TriangleDB, a Triangulation spyware implant

Over the years, there have been multiple cases when iOS devices were infected with targeted spyware such as Pegasus, Predator, Reign and others. Often, the process of infecting a device involves launching a chain of different exploits, e.g. for escaping the iMessage sandbox while processing a malicious attachment, and for getting root privileges through a vulnerability in the kernel. Due to this granularity, discovering one exploit in the chain often does not result in retrieving the rest of the chain and obtaining the final spyware payload. For example, in 2021, analysis of iTunes backups helped to discover an attachment containing the FORCEDENTRY exploit. However, during post-exploitation, the malicious code downloaded a payload from a remote server that was not accessible at the time of analysis. Consequently, the analysts lost “the ability to follow the exploit.”

In researching Operation Triangulation, we set ourselves the goal to retrieve as many parts of the exploitation chain as possible. It took about half a year to accomplish that goal, and, after the collection of the chain had been completed, we started an in-depth analysis of the discovered stages. As of now, we have finished analyzing the spyware implant and are ready to share the details.

The Operation Triangulation infection chain

The implant, which we dubbed TriangleDB, is deployed after the attackers obtain root privileges on the target iOS device by exploiting a kernel vulnerability. It is deployed in memory, meaning that all traces of the implant are lost when the device gets rebooted. Therefore, if the victim reboots their device, the attackers have to reinfect it by sending an iMessage with a malicious attachment, thus launching the whole exploitation chain again. In case no reboot occurs, the implant uninstalls itself after 30 days, unless this period is extended by the attackers.

Meet TriangleDB

The TriangleDB implant is coded using Objective-C, a programming language that preserves names of members and methods assigned by the developer. In the implant’s binary, method names are not obfuscated; however, names of class members are uninformative acronyms, which makes it difficult to guess their meaning:

In some cases, it is possible to guess what the acronyms mean. For example, osV is the iOS version, and iME contains the device’s IMEI.

The strings in the implant are HEX-encoded and encrypted with rolling XOR:

The rolling XOR algorithm implemented in the implant for string decryption

C2 communications

Once the implant launches, it starts communicating with the C2 server, using the Protobuf library for exchanging data. The configuration of the implant contains two servers: the primary and the fallback (contained in the lS and lSf configuration fields). Normally, the implant uses the primary server, and, in case of an error, it switches to the fallback server by invoking the -[CRConfig swapLpServerType:] method.

Additionally, the sent and received messages are encrypted with symmetric (3DES) and asymmetric (RSA) cryptography. All messages are exchanged via the HTTPS protocol in POST requests, with the cookie having the key g and a value that is a digit string from the pubKI configuration parameter.

The implant periodically sends heartbeat beacons that contain system information, including the implant version, device identifiers (IMEI, MEID, serial number, etc.) and the configuration of the update daemon (whether automatic downloads and installations of updates are enabled).

Heartbeat beacon snippet, implant v1.7.0.5 running on iOS 15.3.1

TriangleDB commands

The C2 server responds to heartbeat messages with commands. Commands are transferred as Protobuf messages that have type names starting with CRX. The meaning of these names is obscure: for example, the command listing directories is called CRXShowTables, and changing C2 server addresses is handled by the command CRXConfigureDBServer. In total, the implant we analyzed has 24 commands designed for:

• Interacting with the filesystem (creation, modification, exfiltration and removal of files);
• Interacting with processes (listing and terminating them);
• Dumping the victim’s keychain items, which can be useful for harvesting victim credentials;
• Monitoring the victim’s geolocation;
• Running additional modules, which are Mach-O executables loaded by the implant. These executables are reflectively loaded, with their binaries stored only in memory.

One of the interesting commands we discovered is called CRXPollRecords. It monitors changes in folders, looking for modified files that have names matching specified regular expressions. Change monitoring is handled by obtaining a Unix file descriptor of the directory and assigning a vnode event handler to it. Whenever the implant gets notified of a change, the event handler searches for modified files that match the regex provided by the attacker. Such files are then scheduled for uploading to the C2 server.

The parameters of this command are as follows:

Below, we describe the implant’s commands, specifying the developer-assigned command names along with their numerical identifiers when possible.

Odd findings

While researching the TriangleDB implant, we found a lot of curious details:

• The developers refer to string decryption as “unmunging” (as the method performing string decryption is named +[CRConfig unmungeHexString:] );
• Throughout the code, we observed that different entities were given names from database terminology, which is the reason why we dubbed the implant TriangleDB:
  

  Entity	Developer-used terminology for the entity
  Directory	Table
  File	Record
  Implant module
  Process	Schema
  Keychain entry	Index, row
  C2 server	DB Server
  Geolocation information	DB Status
  Heartbeat	Diagnostic data
  Process of exchanging data with C2 server	Transaction
  Request to C2 server	Query
  iOS application	Operation

• While analyzing TriangleDB, we found that the class CRConfig (used to store the implant’s configuration) has a method named populateWithFieldsMacOSOnly. This method is not called anywhere in the iOS implant; however, its existence means that macOS devices can also be targeted with a similar implant;
• The implant requests multiple entitlements (permissions) from the operating system. Some of them are not used in the code, such as access to camera, microphone and address book, or interaction with devices via Bluetooth. Thus, functionalities granted by these entitlements may be implemented in modules.

To be continued

That’s it for TriangleDB, a sophisticated implant for iOS containing multiple oddities. We are continuing to analyze the campaign, and will keep you updated with all details about this sophisticated attack.

TriangleDB indicators of compromise

MD5      063db86f015fe99fdd821b251f14446d
SHA-1    1a321b77be6a523ddde4661a5725043aba0f037f
SHA-256  fd9e97cfb55f9cfb5d3e1388f712edd952d902f23a583826ebe55e9e322f730f