Keypoints
- 3CX Windows (.msi) and macOS (.dmg) installers were trojanized; a malicious ffmpeg library (ffmpeg.dll / libffmpeg.dylib) was added and signed within legitimate updates.
- The malicious library decodes embedded data in ICO files (hosted on GitHub) to obtain encrypted C2 URLs; AES-GCM is used to encrypt/decrypt these blobs.
- Payload retrieval requires a specially formatted HTTP request including a cookie containing the system MachineGuid; servers returned a JSON carrying shellcode plus a 64-bit DLL reflectively loaded in memory.
- The second-stage DLL (ICONICSTEALER) collects system metadata and browser history (Brave, Chrome, Edge, Firefox) and POSTs results back to C2; further payloads may be served to selected victims.
- The macOS variant stores XOR (0x7A) encoded C2 lists in the library and uses a hardcoded user-agent and specific cookie fields to request payloads.
- Attacker domains acted as proxies to upstream C2 infrastructure; some artifacts (GitHub commits) date back to December 2022, indicating early preparation/testing.
- Detection guidance includes YARA and Suricata rules and blocking the provided IOCs; affected endpoints should be isolated and secrets rotated.
MITRE Techniques
- [T1195] Supply Chain Compromise – The attacker inserted malicious code into legitimate 3CX installers: [‘endpoints with the 3CX Desktop application installed received a malicious update of this software that was signed by 3CX and downloaded from their servers.’]
- [T1574.001] DLL Search Order Hijacking – A malicious ffmpeg library is loaded by the legitimate executable and used to decode and inject payloads: [‘The library is loaded by 3CXDesktopApp.exe, and it is used to decode and inject a payload into memory.’]
- [T1055] Process Injection – The second-stage 64-bit PE is delivered with a shellcode loader and reflectively loaded into memory: [‘The next stage is expected to be a 64-bit PE that is reflectively loaded through a shellcode loader stored at the head of the file.’]
- [T1071.001] Application Layer Protocol: Web Protocols – C2 communication occurs over HTTP(S) with specially formatted headers and cookies (MachineGuid) to retrieve payloads: [‘cookie: __tutma={MachineGuid}’]
- [T1005] Data from Local System – The ICONICSTEALER DLL collects host details and browser history from multiple browsers before exfiltration: [‘The DLL retrieves the hostname, domain name, and OS version. Then, it will retrieve the browser history (title and URL) of the following browsers: Brave, Chrome, Edge, Firefox.’]
- [T1027] Obfuscated/Encrypted Files – Encrypted base64 blobs appended to ICO files are decrypted using AES-GCM and a derived key function: [‘Decrypt the base64 string using the AES-GCM encryption algorithm.’]
Indicators of Compromise
- [File Hashes] malicious installers and libraries – 3CX Windows installer SHA256: 59e1edf4d82fae4978e97512b0331b7eb21dd4b838b850ba46794d9c7a2c0983, ffmpeg.dll SHA256: 7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896, and other hashes (ICONICSTEALER SHA256: 8ab3a5ea…, libffmpeg.dylib SHA256: a64fa9f1…).
- [File Names] trojanized binaries and artifacts – ffmpeg.dll (Windows), libffmpeg.dylib (macOS), ICON files like icon0.ico, icon1.ico, and installer names (3CXDesktopApp-18.12.416.msi / .dmg).
- [Domains / URLs] C2 and staging hosts used in payload retrieval – msstorageazure[.]com, officestoragebox[.]com, msedgeupdate[.]net, pbxphonenetwork[.]com, and many others decoded from ICO files (see table of icon[0-15].ico URLs).
- [Repository] GitHub staging/storage – https://github[.]com/IconStorages/images/ (used to host ICO files with appended encrypted blobs).
- [WHOIS / Registration Emails] domain registration contacts observed – cliego.garcia@proton[.]me, remey.simpson@outlook[.]com, and other unique emails tied to domain registrations.
Volexity’s technical reconstruction shows that signed 3CX installers for Windows and macOS contained a malicious multimedia library (ffmpeg.dll / libffmpeg.dylib) which the legitimate 3CX process loads. That library scans for ICO files with appended data, extracts a trailing ‘$’ plus base64 blob, and uses a derived key function to AES‑GCM decrypt the blob; the decrypted content yields URLs pointing to staged C2 infrastructure. On Windows, the malicious library decoded and injected a payload into memory; a JSON response from C2 contained shellcode concatenated with a 64-bit DLL whose head contains a shellcode loader, and that 64-bit payload is reflectively loaded into the process.
Payload retrieval requires carefully crafted HTTP requests: the client sends specific headers and a cookie containing the system MachineGuid (e.g., “cookie: __tutma={MachineGuid}”) or, for macOS, “3cx_auth_id=%s;3cx_auth_token_content=%s;__tutma=true”, along with a hardcoded user-agent. The C2 layer used numerous proxying domains (many registered Nov–Dec 2022) and appears to forward requests upstream; a given MachineGuid only successfully retrieves a payload once, indicating single‑use provisioning and centralized upstream handling of victim keys.
The delivered ICONICSTEALER DLL gathers host metadata (hostname, domain, OS) and browser history (Brave, Chrome, Edge, Firefox — up to 500 entries) using an embedded SQLite3, then POSTs the collected data back to C2; operators may then serve additional payloads to selected targets. The macOS variant instead stores an XOR (0x7A) encoded C2 list in the library and obeys similar cookie-based retrieval logic. Detection recommendations include deploying the provided YARA and Suricata rules and blocking the listed IOCs; compromised endpoints should be isolated and secrets rotated.
Read more: https://www.volexity.com/blog/2023/03/30/3cx-supply-chain-compromise-leads-to-iconic-incident/