{
	"id": "07996015-be33-438b-8f7b-767ecde4a8ba",
	"created_at": "2026-04-06T00:21:26.759632Z",
	"updated_at": "2026-04-10T13:11:48.789389Z",
	"deleted_at": null,
	"sha1_hash": "f703701ef2957033dd82b18a3760a809691c99e3",
	"title": "The outstanding stealth of Operation Triangulation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 401339,
	"plain_text": "The outstanding stealth of Operation Triangulation\r\nBy Georgy Kucherin\r\nPublished: 2023-10-23 · Archived: 2026-04-05 14:26:06 UTC\r\nUPD 23.04.2025: MITRE created a page for Operation Triangulation as part of its ATT\u0026CK framework.\r\nIntroduction\r\nIn our previous blogpost on Triangulation, we discussed the details of TriangleDB, the main implant used in this\r\ncampaign, its C2 protocol and the commands it can receive. We mentioned, among other things, that it is able to\r\nexecute additional modules. We also mentioned that this operation was quite stealthy. This article details one\r\nimportant aspect of this attack – the stealth that was exercised by the threat actor behind it. Along the way, we will\r\nalso reveal more information about the components used in this attack.\r\nValidation components\r\nIn our previous blogposts, we outlined the Operation Triangulation infection chain: a device receives a malicious\r\niMessage attachment that launches a chain of exploits, and their execution ultimately results in the launch of the\r\nTriangleDB implant. In more detail, the infection chain can be summarized with the following graph:\r\nApart from the exploits and components of the TriangleDB implant, the infection chain contains two “validator”\r\nstages, namely “JavaScript Validator” and “Binary Validator”. These validators collect various information about\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 1 of 11\n\nthe victim device and send it to the C2 server. This information is then used to assess if the iPhone or iPad to be\r\nimplanted with TriangleDB could be a research device. By performing such checks, attackers can make sure that\r\ntheir 0-day exploits and the implant do not get burned.\r\nJavaScript Validator\r\nAt the beginning of the infection chain, the victim receives an invisible iMessage attachment with a zero-click\r\nexploit. The ultimate goal of this exploit is to silently open a unique URL on the backuprabbit[.]com domain. The\r\nHTML page hosted on that URL contains obfuscated JavaScript code of the NaCl cryptography library, as well as\r\nan encrypted payload. This payload is the JavaScript validator. This validator performs a lot of various checks,\r\nincluding different arithmetic operations like Math.log(-1) or Math.sqrt(-1), availability of components such as\r\nMedia Source API, WebAssembly and others.\r\nAnd, as we already mentioned, it performs a fingerprinting technique called Canvas Fingerprinting by drawing a\r\nyellow triangle on a pink background with WebGL and calculating its checksum:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\ncontext.bufferData(context.ELEMENT_ARRAY_BUFFER, l, context.STATIC_DRAW);\r\ncontext.useProgram(C);\r\ncontext.clearColor(0.5, 0.7, 0.2, 0.25);\r\ncontext.clear(context.COLOR_BUFFER_BIT);\r\ncontext.drawElements(context.TRIANGLES, l.length, context.UNSIGNED_SHORT, 0);\r\nC.L = context.getAttribLocation(C, Z('VE'));\r\nC.W = context.getUniformLocation(C, Z('Zv'));\r\ncontext.enableVertexAttribArray(C.L);\r\ncontext.vertexAttribPointer(C.L, 3, context.FLOAT, !1, 0, 0);\r\ncontext.uniform2f(C.W, 1, 1);\r\ncontext.drawArrays(context.TRIANGLE_STRIP, 0, 3);\r\nvar h = new Uint8Array(262144);\r\ncontext.readPixels(0, 0, 256, 256, context.RGBA, context.UNSIGNED_BYTE, h);\r\ndata['xT'] = h[88849];\r\ndata['jHWOO'] = h[95054];\r\ndata['aRR'] = h[99183];\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 2 of 11\n\n17\r\n18\r\n19\r\n20\r\ndata['ffJEi'] = h[130012];\r\nfor (var p = 0, _ = 0; _ \u003c h.length; _++)\r\np += h[_];\r\ndata['WjOn'] = p;\r\nCode drawing the triangle\r\nThe drawn triangle\r\nThis triangle is, in fact, why we dubbed this whole campaign Operation Triangulation.\r\nAfter running the validator, it encrypts and sends all collected information to another unique URL on\r\nbackuprabbit[.]com in order to receive (or not) the next stage of the infection chain.\r\nBinary Validator\r\nAs we see from the infection chain graph, this validator gets launched prior to deployment of the TriangleDB\r\nimplant. As opposed to the JavaScript Validator, which is a script, this validator is a Mach-O binary file (hence the\r\nname Binary Validator). When launched, it decrypts its configuration using AES. This configuration is a plist:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n\u003ckey\u003esco\u003c/key\u003e\r\n  \u003carray\u003e\r\n      \u003cstring\u003eDeleteLogs\u003c/string\u003e\r\n      \u003cstring\u003eDeleteArtifacts\u003c/string\u003e\r\n      \u003cstring\u003eProcessList\u003c/string\u003e\r\n      \u003cstring\u003eInterfaceList\u003c/string\u003e\r\n      \u003cstring\u003eJailbreakDetect\u003c/string\u003e\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 3 of 11\n\n8\n9\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n22\n23 EnableAdTrackingDeviceInfoInstalledAppssdasdfsdisdkc99218578c03cfe347fababc838dd9f23d527800ad9418b025340775eaf6454c07d2143cea9fe70f7a0fcc653a002403c66cc1d90cce4e9cb6b631e063c83d61 This plist contains a list of actions (such as DeleteLogs, DeleteArtifacts, etc.) that have to be performed by the\nvalidator. Specifically, it:\nRemoves crash logs from the /private/var/mobile/Library/Logs/CrashReporter directory that could have\nbeen created during the exploitation process;\nSearches for traces of the malicious iMessage attachment in various databases, such as ids-pub-id.db or\nknowledgeC.db, and then removes them. To be able to do that, the validator’s configuration contains 40\nMD5 hashes of Apple IDs that are used for sending the malicious iMessages. We managed to crack the\nmajority of these hashes, thus obtaining a list of attacker-controlled Apple ID email addresses:\nmailto:travislong544[at]yahoo.com\nmailto:norsarall87[at]outlook.com\nmailto:jesteristhebestband[at]gmail.com\nmailto:christineashleysmith[at]gmail.com\nmailto:homicidalwombat[at]yahoo.com\nmailto:nigelmlevy[at]gmail.com\nmailto:tinyjax89[at]gmail.com\nmailto:nonbaguette[at]yahoo.com\nmailto:slbrimms96[at]outlook.com\nmailto:costamaria91[at]outlook.com\nmailto:hyechink97[at]gmail.com\nmailto:greatoleg9393[at]mail.com\nhttps://securelist.com/triangulation-validators-modules/110847/\nPage 4 of 11\n\nmailto:supercatman15[at]hotmail.com\r\nmailto:shannonkelly404[at]gmail.com\r\nmailto:superhugger21[at]gmail.com\r\nmailto:parkourdiva[at]yahoo.com\r\nmailto:naturelover1972[at]outlook.com\r\nmailto:sasquatchdreams[at]outlook.com\r\nmailto:trunkfullofbeans[at]yahoo.com\r\nmailto:danielhbarnes2[at]gmail.com\r\nmailto:patriotsman121[at]gmail.com\r\nmailto:wheelsordoors[at]yahoo.com\r\nmailto:janahodges324[at]gmail.com\r\nmailto:mibarham[at]outlook.com\r\nmailto:popanddangle[at]outlook.com\r\nmailto:maxjar90[at]mail.com\r\nmailto:chongwonnam[at]gmail.com\r\nmailto:wopperplopper1[at]aol.com\r\nmailto:bajablaster101[at]gmail.com\r\nmailto:carlson31773[at]outlook.com\r\nmailto:fsozgur[at]outlook.com\r\nmailto:soccerchk835[at]gmail.com\r\nmailto:stephamartinez122[at]gmail.com\r\nmailto:popcornkerner[at]gmail.com\r\nmailto:pupperoni1989[at]outlook.com\r\nmailto:biglesterjames5[at]gmail.com\r\nGets a list of processes running on the device, as well as a list of network interfaces;\r\nChecks whether the target device is jailbroken. The validator implements checks for a wide range of\r\njailbreak tools: Pangu, xCon, Evasion7, Electra, unc0ver, checkra1n and many more;\r\nTurns on personalized ad tracking;\r\nCollects a wide range of information about the victim, such as username, phone number, IMEI and Apple\r\nID;\r\nRetrieves a list of installed applications.\r\nWhat is interesting about these actions is that the validator implements them both for iOS and macOS systems:\r\nWe also found that the validator implements an unused action, which was dubbed PSPDetect by the attackers.\r\nThis action retrieves a list of files from the validator’s configuration (this list was empty for the validator\r\nconfigurations that we analyzed), checks if they are present in the file system and produces a list of found files as\r\noutput.\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 5 of 11\n\nThe abbreviation PSP in the name of this action may mean “personal security product,” or, in simpler terms, a\r\nsecurity solution. It is thus possible that this action may be launched on macOS devices in order to detect installed\r\nantivirus products.\r\nHaving executed all these actions, the validator encrypts and sends the obtained data (list of processes, user\r\ninformation, etc.) to the C2 server. In response, the server returns the TriangleDB implant, which we described\r\nbefore.\r\nLooking for traces in logs, again\r\nThe threat actor behind Operation Triangulation exercises stealth not only by introducing two validators in the\r\ninfection chain. In fact, they perform all operations with the TriangleDB implant very carefully. This can be\r\nobserved from our analysis of commands sent by the attackers to the infected devices via this implant.\r\nAfter the implant establishes communication with the C2 server and sends a heartbeat, it receives multiple\r\nCRXShowTables and CRXFetchRecord commands from the C2 server. These commands are related to retrieval of\r\nlogs that might show traces of the infection chain and/or the malware itself. Some of the files that are retrieved\r\nare:\r\nCrash log files (e.g. those in the /var/mobile/Library/Logs/CrashReporter);\r\nDatabase files (e.g. /private/var/mobile/Library/IdentityServices/ids-gossip.db). These database files may\r\ncontain the Apple ID used by the attackers to send the malicious iMessage.\r\nOnce the attackers receive these files, they delete them from the device, so that the victim can’t examine them and\r\npotentially find signs of compromise. Having completed log collection and deletion, the attackers send multiple\r\nCRXPollRecords commands to the implant, instructing it to periodically exfiltrate files from the /private/var/tmp\r\ndirectory. The names of the files to be uploaded to the C2 server should match one of the following regular\r\nexpressions:\r\nRegular expression Type of data\r\n^(kng|dky).+\\.dat$ Location data\r\n^adr3.+\\.dat$ SQL-related data\r\n^sr6d.+\\.(dat|srm)$\r\nMicrophone-recorded data\r\n^S5L.+\\.kcd$ Keychain data\r\n^ntc.+\\.db2$ Unknown\r\n^(\\w[247F][023A][24BC]|\\w[4AEF][349B][169D]){2}-\\w[05AF][3468][124C]-4[123A]\r\n[09AD][356A]-[89AB]\\w\\w\\w-(\\w[126A][24CE][348B]|\\w[29DE][168D][156D]){3}$\r\nUnknown\r\nThe files with these names contain execution results produced by modules. These modules are uploaded to the\r\ninfected device through the CRXUpdateRecord and CRXRunRecord commands – we describe them below.\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 6 of 11\n\nMicrophone recording\r\nOne of the most privacy-invading modules is the microphone-recording module, which goes by the name of\r\n“msu3h” (we believe 3h stands for three hours, the default recording duration). Upon execution, it decrypts (using\r\na custom algorithm derived from GTA IV hashing) its configuration, but it performs further actions only if the\r\nbattery is more than 10% charged.\r\nThe configuration file itself contains typical configuration data, such as how long to record for and the AES\r\nencryption key used to encrypt recordings, but also more menacing parameters, such as:\r\nsuspendOnDeviceInUse: sets whether recording should be stopped if the device screen is turned on;\r\nsyslogRelayOverride: sets whether audio should be recorded when system logs are being captured.\r\nThe recording takes place using the Audio Queue API, and sound chunks are compressed using the Speex codec,\r\nthen encrypted using AES. Apart from sound data, each recording contains diagnostic messages, which have a\r\nfour-byte type identifier, which can either be:\r\nIdentifier Message\r\n0x6265676E recording started\r\n0x736C726E recording stopped because of syslog monitoring\r\n0x6465766E recording stopped because device screen got turned on\r\n0x6964736E recording stopped because of insufficient disk space\r\n0x656E646E recording finished\r\nKeychain exfiltration\r\nFor an unknown reason, the attackers decided to add an additional keychain exfiltration module, despite such\r\nfunctionality already being present in TriangleDB. This keychain module has the same logic as that in\r\nTriangleDB, but is largely based on code from the iphone-dataprotection.keychainviewer project.\r\nSQLite stealing modules\r\nMany apps on iOS use SQLite to store their internal data. It is thus of no surprise that the attackers implemented\r\nmodules capable of stealing data from various SQLite databases. All these modules have the same codebase, and\r\ncontain different SQL queries to be executed. Again, they have a configuration that is encrypted. When this is\r\ndecrypted, only standard variables such as file path, AES key, query string, etc. can be found.\r\nThe code of these modules is quite peculiar. For example, the attackers implemented a wrapper around the fopen()\r\nfunction, adding the Z flag (indicating that a created file should be AES-encrypted and zlib-compressed) used in\r\ncombination with the standard w (write) flag, as can be seen in the image below.\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 7 of 11\n\nWhat is also interesting is that the SQLite stealing modules contain three branches of code for different iOS\r\nversions: lower than 8.0, between 8.0 and 9.0, and 9.0 and later.\r\nEach module that we found performs different SQL database queries. For example, there is a module that\r\nprocesses application usage data from the knowledgeC.db database. Another module extracts photo-related\r\nmetadata, such as whether a child is in the picture or not, if the person is male or female (see image below) and\r\ntext that was automatically OCRed from media files.\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n...\r\nEND AS 'Face(s) Detected',\r\nCASE face.ZAGETYPE\r\n    WHEN 1 THEN 'Baby / Toddler'\r\n    WHEN 2 THEN 'Baby / Toddler'\r\n    WHEN 3 THEN 'Child / Young Adult'\r\n    WHEN 4 THEN 'Young Adult / Adult'\r\n    WHEN 5 THEN 'Adult'\r\n    else 'Unknown'\r\nEND AS 'Subject Age Estimate',\r\nCASE face.ZGENDERTYPE\r\n    WHEN 1 THEN 'Male'\r\n    WHEN 2 THEN 'Female'\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 8 of 11\n\n14\r\n15\r\n16\r\n17\r\n    else 'Unknown'\r\nEND AS 'Subject Gender',\r\nperson.ZDISPLAYNAME AS 'Subject Name'\r\n...\r\nIt should also come as no surprise that the attackers expressed interest in WhatsApp, SMS and Telegram messages\r\nas well – we found modules exfiltrating this data too.\r\nLocation-monitoring module\r\nThis module runs in a separate thread and tries to impersonate the bundle that is authorized to use the location\r\nservices specified in the configuration (e.g. /System/Library/LocationBundles/Routine.bundle). Apart from using\r\nGPS to determine the location, it also uses GSM, retrieving the MCC (MobileCountryCode), MNC\r\n(MobileNetworkCode), LAC (LocationAreaCode) and CID (CellID) values through the CoreTelephony\r\nframework.\r\nOne reason for using GSM-related data is to estimate the victim’s location when GPS data is not available.\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 9 of 11\n\nConclusion\r\nThe adversary behind Triangulation took great care to avoid detection. They introduced two validators in the\r\ninfection chain in order to ensure that the exploits and the implant do not get delivered to security researchers.\r\nAdditionally, microphone recording could be tuned in such a way that it stopped when the screen was being used.\r\nThe location tracker module may not use standard GPS functionality if this is unavailable, but rather metadata\r\nfrom the GSM network.\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 10 of 11\n\nThe attackers also showed a great understanding of iOS internals, as they used private undocumented APIs in the\r\ncourse of the attack. They additionally implemented in some modules support for iOS versions prior to 8.0. Recall\r\nthat these were widely used before 2015, which gives an indication of just how long the code of the modules has\r\nbeen in use.\r\nLast but not least, some of the components used in this attack contain code that may indicate that they are\r\ntargeting macOS systems as well, although, as of the publication date, no Triangulation traces have been\r\nencountered on macOS devices.\r\nEven though Operation Triangulation was executed with a high degree of stealth, we were still able to extract the\r\nfull exploitation chain, as well as the implant and its plugins. If you want to find how we managed to circumvent\r\nall the protections introduced by the attackers, we encourage you to attend the SAS conference, where Igor\r\nKuznetsov will present a talk entitled “Operation Triangulation: Сonnecting the Dots” and the story of how this\r\nlong-lasting attack was put to a stop. If you are not able to make it to Phuket, you can read the blogpost\r\nsummarizing this talk that we will release shortly after SAS.\r\nIndicators of Compromise\r\nKeychain module\r\nMD5 527bb38d4716c019b65da64d0f851a70\r\nSHA-1 a468613d31c90ac94bbd313bc70c5c6638c91603\r\nSHA-256 64f36b0b8ef62634a3ec15b4a21700d32b3d950a846daef5661b8bbca01789dc\r\nLocation module\r\nMD5 da5d3c0d3ad8df77ff6f331066636e42\r\nSHA-1 a5a93e8d48fdef8c02066b9020445b50ebc81a8f\r\nSHA-256 7e779a019f250d8cec9761d1230296236a8b714743df42c49ce8daf818d542e7\r\nSMS-stealing module\r\nMD5 adb9e4b7a75eccc37f6941a5cbc7685b\r\nSHA-1 6e9cd17fcc8b14cc860ce980c5e919494a10eec9\r\nSHA-256 c2393fceab76776e19848c2ca3c84bea0ed224ac53206c48f1c5fd525ef66306\r\nMicrophone module\r\nMD5 ac2444e7f7b0a4b084ad8c9ae8ac26c8\r\nSHA-1 10509067ba5d9d985e932ea77f089491dee1611d\r\nSHA-256 ff2f223542bbc243c1e7c6807e4c80ddad45005bcd78a77f8ec91de29deb2f6e\r\nSource: https://securelist.com/triangulation-validators-modules/110847/\r\nhttps://securelist.com/triangulation-validators-modules/110847/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"ETDA",
		"Malpedia",
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://securelist.com/triangulation-validators-modules/110847/"
	],
	"report_names": [
		"110847"
	],
	"threat_actors": [
		{
			"id": "ad08bd3d-e65c-4cfd-874a-9944380573fd",
			"created_at": "2023-06-23T02:04:34.517668Z",
			"updated_at": "2026-04-10T02:00:04.842233Z",
			"deleted_at": null,
			"main_name": "Operation Triangulation",
			"aliases": [],
			"source_name": "ETDA:Operation Triangulation",
			"tools": [
				"TriangleDB"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "113b8930-4626-4fa0-9a3a-bcf3ef86f595",
			"created_at": "2024-02-06T02:00:04.14393Z",
			"updated_at": "2026-04-10T02:00:03.578394Z",
			"deleted_at": null,
			"main_name": "Operation Triangulation",
			"aliases": [],
			"source_name": "MISPGALAXY:Operation Triangulation",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434886,
	"ts_updated_at": 1775826708,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f703701ef2957033dd82b18a3760a809691c99e3.pdf",
		"text": "https://archive.orkl.eu/f703701ef2957033dd82b18a3760a809691c99e3.txt",
		"img": "https://archive.orkl.eu/f703701ef2957033dd82b18a3760a809691c99e3.jpg"
	}
}