In March 2026, Intego Antivirus Labs investigated a macOS malware campaign delivering the OSX/Amos stealer. During analysis, the infection chain led from stripped Mach-O binaries and heavily obfuscated shell scripts to an unusual final payload that appeared to be “data” rather than a standard executable.
That payload turned out to be an Electron ASAR (Atom Shell Archive) — a growing trend in macOS threats. Instead of shipping compiled binaries, attackers increasingly trojanize legitimate cross-platform Electron applications by replacing the core ASAR archive with a weaponized version that contains malicious logic.
In this case, the trojanized app masqueraded as Ledger Live. It combined a TLS validation bypass with a convincing phishing overlay designed to capture cryptocurrency wallet Secret Recovery Phrases and exfiltrate them to attacker infrastructure.
This write-up walks through a practical triage workflow to identify an ASAR payload, unpack it, locate the execution entry point, and extract actionable C2 infrastructure.
When a suspicious file doesn’t present obvious magic headers, the fastest path forward is reading raw bytes. A quick hexdump revealed an Electron ASAR signature:
hexdump -C -n 100 payload_file
The key signal is a 16-byte header followed immediately by a JSON structure beginning with {“files”:{…}. That combination is an unmistakable ASAR fingerprint.
Electron apps package internal source code (JavaScript/HTML/CSS) and assets into ASAR archives. The JSON block acts as a file allocation table mapping the virtual directory structure, followed by the raw bytes of each bundled file.
Why this matters: If the payload is an ASAR, you’re likely looking at the core logic of a trojanized Electron application — including the code responsible for credential theft, UI overlays, and outbound network communication.
To analyze the JavaScript logic, the ASAR must be unpacked. In many analysis environments, npx asar extract isn’t available, so it helps to have a second option.
npx asar extract app.asar unpacked_asar
If you have Python available, you can use the asar module to extract the archive.
Once extracted, you should end up with a directory that resembles a Node/Electron project (including package.json and bundled Webpack output).
In an unpacked Electron app, the first stop is package.json. This file acts as the roadmap and dictates which code executes first.
cat unpacked_asar/package.json
The critical field is:
This tells you exactly where to start hunting for injected logic.
In trojanized Electron bundles, threat actors often:
In this sample, inspecting the start of the main bundle exposed the core compromise:
head -c 1000 unpacked_asar/.webpack/main.bundle.js
The “smoking gun” was the presence of an explicit TLS validation bypass:
There is no legitimate reason for a production cryptocurrency wallet application to globally disable TLS certificate validation.
Stealer operators often rely on cheap, fast-changing infrastructure (expired, mismatched, or self-signed certificates). Without a TLS bypass, background exfiltration requests can throw certificate validation errors, crash the app, or create visible breakage that alerts the victim.
This makes the bypass a practical “reliability layer” for malicious traffic — and a useful detection clue for defenders.
Once the TLS bypass is identified, the next step is determining:
In this case, the .webpack/ directory contained suspicious overlay HTML files such as:
These files hijack the UI and prompt the user to “verify” their 12- or 24-word Secret Recovery Phrase.
To locate the drop zone, focus on data-sending primitives in the overlay files (fetch, XMLHttpRequest, submit, action=).
grep -E -i -o ‘.{0,40}(action=|fetch\(|XMLHttpRequest|submit).{0,40}’ \
unpacked_asar/.webpack/recovery-step-*.html
Then extract URLs from the specific file(s) of interest and filter out known legitimate namespaces.
This workflow revealed the C2 endpoint used as the exfiltration drop zone:
When the victim submits the final recovery step, the overlay sends the seed phrase to attacker infrastructure — and it succeeds silently because the TLS bypass prevents certificate failures from blocking the request.
This isn’t an isolated technique — it reflects a maturing macOS Malware-as-a-Service ecosystem. Trojanizing wallet applications by:
has become a repeatable playbook across multiple stealer families.
Attackers are also diversifying distribution. Beyond fake updates and cracked installers, recent campaigns have included novel delivery mechanisms designed to trick users — and in some cases, automated tools — into running the initial downloader.
Even without full reverse engineering, defenders can quickly identify high-signal indicators in trojanized Electron apps:
| Name | SHA-256 | Context |
| ASAR payload | eeb14ff7262367f8911 68268ca8d64a306968e57 9be1136cbd7a481076 98f405 |
Trojanized Ledger Live app.asar containing overlay + TLS bypass |
| Type | Indicator | Context |
| C2 endpoint | https://main.mon2gate.net/ modules/wallets |
Exfiltration drop zone for stolen Secret Recovery Phrases |
| Filesystem | .webpack/recovery-step-*.html | Phishing overlay HTML injected into the application bundle |
| VT collection | https://www.virustotal.com/ gui/collection/fcdb78d87 f1e094d4d4a6dacaa70 38f3274291448704e 7913c390d6492002 11e/summary |
Curated indicators and artifacts |
Trojanized Electron apps are a reminder that macOS malware analysis increasingly requires web-application triage techniques — not only executable reversing. Being able to unpack ASAR archives, trace package.json entry points, and spot environment manipulations like TLS bypasses is key to extracting actionable IOCs quickly.
For responders, the highest-value workflow is often: identify ASAR → unpack → find entry point → hunt injected logic → extract C2 from overlay/exfil code.
