S1216: TriangleDB
TriangleDB is an Objective-C written implant deployed after Binary Validator and after root privileges are obtained during Operation Triangulation’s infection chain. Upon execution, TriangleDB communicates with the C2 server, relaying information about the victim device.[1]
Analyst context for executives and security teams
TriangleDB matters because it represents a post-compromise iOS implant used after root privileges are obtained in the Operation Triangulation infection chain. For leaders, the practical issue is not just malware presence; it is whether high-value mobile devices can be investigated for discovery, local data access, keychain collection, location tracking, and command-and-control behavior when the official ATT&CK object provides no ready-made detection guidance.
Executive priority
Prioritize this as a mobile executive-risk and incident-readiness scenario. The supplied ATT&CK relationships point to behaviors that can expose credentials, device context, local sensitive data, location information, and network configuration. Security leaders should ask whether mobile fleet telemetry, MDM controls, incident response procedures, and evidence retention are sufficient for iOS devices used by executives, administrators, legal, finance, engineering, or other sensitive roles.
Technical view
TriangleDB is listed as an Objective-C iOS implant that communicates with a C2 server and relays victim device information after Binary Validator and root privilege acquisition. ATT&CK maps it to mobile discovery, local data collection, keychain access, cryptographic C2 concealment, ingress tool transfer, out-of-band data, and related behaviors. SOC and IR teams should validate whether they can observe suspicious iOS network communications, unexpected device/app/process/file enumeration, access to local data and keychain-related artifacts where available, location access, transferred files, and deletion or cleanup activity. Because official detection text is not provided, detections should be built from the mapped behaviors and local baselines rather than from ATT&CK-provided signatures.
Likely telemetry
- MDM or mobile EDR inventory for iOS device posture, installed applications, and process/app activity where available
- Mobile network telemetry showing unusual outbound communications, encrypted sessions, or connections to untrusted infrastructure
- Device forensic artifacts for file and directory enumeration, local data access, transferred files, and deletion activity
- iOS keychain-related access evidence where available through approved forensic or enterprise tooling
- Location service access records or privacy permission changes where available
Detection direction
- Start with coverage validation: confirm what telemetry is actually available from managed iOS devices, because many mobile behaviors are not visible through standard endpoint logging.
- Build behavior-based hypotheses around the mapped techniques: software discovery, file and directory discovery, process discovery, network configuration discovery, local data collection, keychain access, ingress tool transfer, encrypted C2, location tracking, out-of-band communications, and file deletion.
- Tune detections against known-good mobile management, backup, security, and productivity apps to reduce false positives from legitimate inventory, sync, encryption, and location features.
- Correlate mobile network anomalies with device state, app inventory, privilege or jailbreak/root indicators, and any incident timeline involving Binary Validator or Operation Triangulation context supplied by ATT&CK.
- Treat lack of official detection guidance as a control gap to document: detection engineering should produce local analytics, test data sources, and IR collection procedures rather than assuming ATT&CK supplies coverage.
Mitigation priorities
- Prioritize hardened management of sensitive iOS devices, including device enrollment, patch posture, application control, and rapid isolation procedures where supported by enterprise tooling.
- Validate least-privilege and credential-risk controls for mobile users, especially where keychain or local data access would affect cloud, VPN, Wi-Fi, or privileged service credentials.
- Ensure incident response plans include mobile forensic acquisition, preservation, and escalation paths for iOS devices, not only traditional endpoints.
- Review network egress monitoring for managed mobile devices and define how encrypted or out-of-band communication concerns will be triaged without relying on payload inspection alone.
- Use the mapped behaviors to drive audit evidence: show which mobile controls, telemetry sources, and response playbooks address discovery, collection, C2, and cleanup behaviors.
Analyst notes and limits
The strongest decision value is in using TriangleDB as a mobile post-compromise readiness test. The object is iOS-focused and tied to Operation Triangulation’s infection chain after root privileges are obtained. One related technique, File Deletion T1630.002, is described in the supplied relationship context with Android platform text, so analysts should be careful not to overstate iOS-specific details from that relationship without local or additional source confirmation.
Official ATT&CK detection guidance is not provided. Tactics are not specified in the supplied object. The supplied fields do not justify claims of current exploitation, specific victim exposure, attribution beyond the Operation Triangulation context, or guaranteed detection. Local device management, network, and forensic visibility will determine practical coverage.
TriangleDB
TriangleDB is an Objective-C written implant deployed after Binary Validator and after root privileges are obtained during Operation Triangulation’s infection chain. Upon execution, TriangleDB communicates with the C2 server, relaying information about the victim device.[1]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1544 | Ingress Tool Transfer | TriangleDB has loaded additional modules stored in memory.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1521.001 | Symmetric Cryptography Sub-technique | TriangleDB has encrypted data using 3DES.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1644 | Out of Band Data | TriangleDB has used the Protobuf library for command and control communication.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1634.001 | Keychain Sub-technique | TriangleDB has extracted the device’s keychain.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1630.002 | File Deletion Sub-technique | TriangleDB has deleted an implant module or specified files.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1418 | Software Discovery | TriangleDB has obtained a list of installed applications.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1430 | Location Tracking | TriangleDB has monitored the device’s geolocation, which includes coordinates, altitude, bearing and speed.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1424 | Process Discovery | TriangleDB has collected a list of running processes.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1420 | File and Directory Discovery | TriangleDB has obtained a list of files using the `fts` API and has obtained files that match a specified regular expression.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1521.002 | Asymmetric Cryptography Sub-technique | TriangleDB has encrypted data using RSA.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1422 | System Network Configuration Discovery | TriangleDB has collected and sent information on the device’s IMEI, MEID, serial number and other device information.CitationSecureList OpTriangulation 21Jun2023 |
| Mobile | T1533 | Data from Local System | TriangleDB has collected and exfiltrated files.CitationSecureList OpTriangulation 21Jun2023 |
Groups, software, and campaigns
C0054: Operation Triangulation
Operation Triangulation is a mobile campaign targeting iOS devices.[1] The unidentified actors used zero-click exploits in iMessage attachments to gain Initial Access, then executed exploits and validators, such as Binary Validator before finally executing the TriangleDB implant.
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | d9d21b41cef5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
SecureList OpTriangulation 21Jun2023
Kucherin, G., et al. (2023, June 21). Dissecting TriangleDB, a Triangulation spyware implant. Retrieved April 18, 2024.
Open source URL -
[2]
mitre-attack S1216Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.