EtherHiding Under the Hood: On-Chain Forensics Beyond the Public Disclosure

Key takeaways

• While researching on the Ehterhiding technique used in the wild, we found 6 particularly interesting RedLine samples leveraging EtherHiding, submitted to Filescan.io Community on March 25, 2026. Reverse-engineering one of them (5ead45bc83c4fee8...) uncovered four stacked evasion/delivery layers, one of which we haven’t seen documented elsewhere.
• That novel layer strips the native PE import table and _CorExeMain bootstrap stub entirely, forcing the payload to be reflectively loaded rather than run directly , used as an anti-sandbox trick that defeats naive automated detonation.
• The sample never hardcodes its C2, it AES-256-CBC decrypts a BSC smart-contract address at runtime, then reads the actual C2 value from that contract via a read-only eth_call. We recovered the AES key and decrypted both values ourselves.
• The resolver contract (Contract A) has been live since June 2025. Its full on-chain transaction history (all 20 update() calls, from deployment to its most recent write) decrypts cleanly, giving us a year-long record of C2 IP rotation, not just the single IP active when the sample was submitted to Filescan.io.
• We found 122 other BSC contracts sharing Contract A’s exact bytecode template, though the recovered AES key doesn’t decrypt their traffic, meaning key material is scoped per contract or per operator sub-cluster rather than shared across operators.
• Passive analysis on the 10 rotated C2 IPs show the rotation isn’t random: two hosting providers, AS216071 (VDSina) and AS202051 (NETGRID HOST LTD), account for 7 of the 10. The finding of additional IP addresses could hint a timeline of this activity cluster, suggesting a duration of slightly more than a year at the time of writing.

Last week we published a research on a ClickFix campaign that used the EtherHiding technique and was most likely related to the ErrTraffic MaaS platform (see article), while there are not connections to ErrTraffic’s MaaS, this new cluster also exposes a wide well-defined infrastructure for multiple persistent-in-time campaigns.

During the research we identified over 100 PE samples in the Filescan.io Community corpus. Although they were unrelated to last week’s article, they carried blockchain RPC C2 signals, a communication protocol that acts as a bridge, enabling applications such as wallets and decentralized applications (dApps) to communicate with the nodes of a blockchain network.

Six of these samples caught our attention for their evasion layers. In this article we share our analysis on this cluster of samples.

Reverse-engineering the “broken” samples

Six Redline+EtherHiding samples were submitted to Filescan.io Community on March 25, 2026. Initially it stood out the fact that these six samples failed to execute as normal PEs in our labs (hence failing in any traditional sandbox). A deeper analysis showed a genuinely interesting finding: this sample stacks four independent evasion/delivery layers, which, as far as we know, haven’t been reported before, at the time of our research.

The four evasion layers

Layer	Origin	What it does	Novelty
1. Native PE import-table stripping	Custom crypter/obfuscator step	The native Import Address Table (IAT) and _CorExeMain bootstrap stub are physically absent from the file, removed entirely (zero hits anywhere in the binary for the strings _CorExeMain, mscoree.dll, _CorDllMain). Though, the managed .NET metadata (CLR header, IL, entry point) is 100% intact. Because of this, Windows refuses to launch the file natively (“This application could not be started”), while dnSpy and other CLR-metadata-only tools open it without complaint. This forces the payload to be reflectively loaded (Assembly.Load() + payload invocation) by a separate stager rather than run directly (i.e. double click on the sample), an anti-sandbox technique that defeats naive “just run it” automated detonation. Some less sophisticated dotnet PE libraries in fact may fail to load/parse such tampered PEs.	Novel. No named, documented .NET obfuscator or commercial protector that we know of advertises native import-table stripping as an anti analysis feature. Legitimate x64-only .NET assemblies do have a genuinely absent import table, but they also have AddressOfEntryPoint == 0. This sample has a non-zero entry point that resolves into dead zero-padding (a bogus leftover value, not a clean absence) which points to deliberate post-build tampering.
2. ConfuserEx variant obfuscation	Off-the-shelf protector variant	Many fingerprints allowed us to identify this layer as a ConfuserEx variant. However the string protection diferred from the traditional ConfuserEx single-byte-xoring of strings. This variant implemented an additional evasion effort by storing the encrypted string table as an embedded dotnet resource, decrypted on demand, resulting in an particular characteristic of this variant which we have not seen documented before. Some additional ConfuserEx indicators are: - Control-flow flattening - “Reference proxy” indirect dispatch (calls resolved at runtime via Module.ResolveMethod(...).MethodHandle.GetFunctionPointer() into static function-pointer tables and invoked with IL calli instead of call/callvirt, invisible to static call-graph tools) - Disguised constant literals (Type.EmptyTypes.Length, always 0, used as a fake variable) - Metadata stream renamed #- instead of the standard #~ plus four bogus/reserved metadata table bits set to make naive parsers choke.	While ConfuserEx is a widely known, well-documented protector family (unmaintained since 2016) many forks and variants keep popping up. We were not able to link this variant relying on a dotnet resource for the strings protection to an existing fork or documented variation.
3. EtherHiding C2 resolver, with AES-256-CBC contract-address decryption	Custom application code, novel add-on	The sample never hardcodes a C2 address. At runtime it assembles and sends a JSON-RPC eth_call to public BSC seed nodes (bsc-dataseed{1-4}.binance.org, .defibit.io, .ninicoin.io) invoking a smart contract’s get() method (selector 0x6d4ce63c = keccak256("get()")[:4]). The contract address itself is not stored in plaintext in the binary, it is AES-256-CBC encrypted in the ConfuserEx string table, decrypted at runtime by a small custom class. Both the AES key and the ciphertext are retrieved from the encrypted string table hidden as a dotnet resource.	Novel pairing. ConfuserEx never generates networking or blockchain code, it only supplies the string-hiding wrapper around the C2 constants. Classic RedLine ships its C2 as a hardcoded Base64 config blob over WCF/SOAP. These samples, reading it from a BSC contract replaces that hardcoded step with an operator-mutable, takedown-resistant on-chain lookup. This is custom code grafted in front of a RedLine-family payload and after ConfuserEx variant protection layer.
4. RedLine-lineage stealer payload	Commodity stealer	The dead-code sweep recovered RedLine’s full data-contract model near-verbatim: ScanResult, ScanDetails, ScannedFile/Cookie, ScanningArgs, BrowserVersion, Autofill, OsCrypt/LocalState, plus a StealerSettingConfigParce config struct toggling discord/files/ftp/steam/telegram/vpn/grabber modules.	Not novel, commodity malware. However, this schema is shared with RedLine’s close relative META Stealer, a near-identical rebrand. The exact brand can’t be proven from static evidence alone.

The AES decryption in detail

The resolver contract address is first retrieved as a base64 ciphertext from the encrypted strings table, along with the AES key used to decrypt it:

• Key: mj.a = Convert.FromBase64String(xk.i). The AES-256 key is simply the raw Base64 decode of one string-table entry (xk.i), with no hashing or KDF applied. There’s no key-stretching step to reverse. The “key derivation function” (sp(mj)) just returns the raw bytes.
• Cipher: AES-256-CBC, PKCS7 padding, IV = the first 16 bytes of the encrypted blob, ciphertext = everything after.
• Recovered values:

Field	Value
AES-256 key (base64)	FmWKbgtJCRZw/RjxieH+DO4n+CSTb/agdxOiBu3clDY=
AES-256 key (hex)	16658a6e0b49091670fd18f189e1fe0cee27f824936ff6a07713a206eddc9436
IV (hex)	541dd0207d92c0e7d2c6138417559b2f
Decrypted plaintext	0x67b4af41467a51e0816752a6b223c7c55ae71957

Decryption succeeded with valid PKCS7 padding on the first attempt, confirming the key/IV/scheme are correct, and the same AES key is reused a second time to decrypt the actual C2 value returned by the contract’s get() call. So, the retrieved AES key first decrypts the hardcoded BSC smart-contract address (the EtherHiding resolver contract), and the same key is used to decrypt the queried info. This adds additional obstacle for researchers monitoring this activity, since the AES key needs to be obtained from a live sample, in order to decrypt the information stored in a smart contract, even after a successful hunt of additional smart contracts abused for the same campaign.

The BSC contract infrastructure

The decrypted address, 0x67b4af41467a51e0816752a6b223c7c55ae71957 (Contract A) is operated by the wallet 0x9bD32c5d9fe24cd70fe5532c484db50f5a6cCcf5.

After the research, we created a config extractor for Filescan.io (among other additional detections) to catch malware samples using the EtherHiding technique. We resubmitted the other five samples to check the contracts and RPC endpoints and found out they all have the same configuration.

Check or monitor for more samples using the EtherHiding technique in Filescan.io through this Threat Indicator.

Mechanism: a read-only eth_call to get() (selector 0x6d4ce63c) on a minimal key-value-store contract.

The operator writes new values via update(string) (selector 0x3d7403a3).

Because it’s a get() read call rather than an event log, there’s no on-chain event trail, only the operator’s own update() transactions are visible.

Contract A’s full C2 rotation history (2025-06-21 to 2026-06-05)

Contract A has 20 transactions total, all update() calls (the first, at deployment, sets the initial value, the rest are rotations). The AES-256-CBC scheme recovered above decrypts all with valid PKCS7 padding. The table below shows every write this contract has ever received, with the date, the tx hash value and the C2 decrypted value.

The tx hash is each transaction’s unique on-chain identifier (a 32-byte/64-hex-character digest of its contents).

Date (UTC)	Tx hash	Decrypted value
2025-06-21 08:51:13	0x7971eab99ea0f4248c061d8aba030d35dd64eb0f65a35e49deedde50121845c3	77.73.131[.]91
2025-12-04 15:22:03	0x0dd79ab017e4bdb70f82db2eb2bd11f392a4cd7a2eb9d751d89a71e52613d702	146.103.126[.]229
2025-12-04 20:17:02	0xa40e1eab97f2816800c8b7a34a7366c3cdbd2e776a347bb2a97ff250c98b46a9	146.103.126[.]229
2025-12-14 20:51:22	0x87fd8a8c605b8a9b5544d930b421d97a092afb1d3c7211fb3a883d0565f6c3af	146.103.126[.]229
2026-01-17 15:37:40	0x130e5d7feedef14d6bf7e42e7013668502e01606a992cfd46f0f51ec1bf2d00b	77.105.136[.]66
2026-02-04 08:16:22	0xe2d857ec877de5db84a969f28148e58e744cf2a92f77455db54f14412febacfb	77.105.136[.]66
2026-02-19 10:20:54	0x7b10e5897d5653d8c0757a3b4456ca8e4a21c264179691754ae77a65ad7feacb	77.105.136[.]66
2026-02-21 08:01:46	0x648c906303c49562f44cbbfd2209c58ec4862a507c5dc328420ab707dfeed1af	77.105.136[.]66
2026-02-21 09:02:32	0xe8e11e410c33d1f0fdbaeb975343a105a2c56741d01b97a84734df9f6eb8dfe8	64.111.93[.]20
2026-02-21 09:21:45	0xe9e28d4a5eb74b4a34b0bb88ae77310b10017ec3fd8a807e9e0123e131fc033b	77.105.136[.]66
2026-02-23 09:36:30	0x14b835f8d6e999ab263c1041bd8f602fb7fe8bc9cf2912c54b7f4a9931c6388a	77.238.232[.]188
2026-02-25 17:25:08	0x68e27382b2a3e9ac8f997f0fc10b418a6df9d3c3804e9a2a2d1467935e656a1b	77.105.139[.]80
2026-02-25 17:39:42	0xf12b64ba58a90411d0a7a0682af603afabe999a7e0df90326111cb4d86724703	179.61.145[.]140
2026-02-26 18:05:08	0xfe33221605e7afc077a51ba3ce118d28126ef7a8c2f4886b45f26ec8b9998c6d	179.61.145[.]140
2026-03-09 10:50:02	0x73e7563c0030afa1fd5c85c01ec9d071e69af2bcedf6560fc3e3f6b58c9ef576	179.61.145[.]140
2026-03-18 16:22:43	0x58427e9d2cac96158265054c314f2ab1d15329c5229f0c87e039e70c199cbbc1	141.11.197[.]134 (the C2 from the analyzed sample)
2026-04-14 08:23:41	0x9ca660d5b05dcec73e89f29b83551a8db9d7f4f745b807d8e9f99a050639313a	141.11.197.63
2026-04-23 13:45:46	0xb6cd2c00bb5a60bca0d535ed1ed14723989bbbee27301527251707842909b35a	185.112.59.99
2026-05-25 08:55:10	0x9121002292ad5fa6fb19b68cee5c74b09cf48e179166ed5f00427f9b62c98193	185.112.59.99
2026-06-05 09:16:01	0xa531ed9f9a7b15a7b7a9be07331790f10013cb9466db1cf9282cbbb40b829986	185.112.59.99

Ten distinct IPs, each held from a few days to several weeks before the operator rotated to the next one. The rotation cadence tightens noticeably from late February 2026 onward (several same-day and next-day updates around 2026-02-21 and 2026-02-25) before settling back into multi-week intervals.

The AES key does not generalize across the wider contract cluster

We looked for similar contracts and found 122 contracts with the exact same bytecode content (table in the IoCs section). Even though the bytecode template is shared across multiple contracts, most deployments are keyed independently, so we couldn’t decrypt the C2 from them. As mentioned before, finding samples that interact with these wallets would be a requirement to decrypt the C2, since the corresponding key is hardcoded among their protected strings.

Passive infrastructure check on the 10 rotated C2 IPs

The infrastructure analysis revealed that the rotation isn’t totally random, it concentrates on two hosting clusters.

IP	Active period	ASN	Provider	RIR
77.73.131[.]91	2025-06-21	AS210644	AEZA GROUP LLC	RIPE (block registered AE, AS home RU)
146.103.126[.]229	2025-12-04 → 12-14	AS216071	VDSINA – SERVERS TECH FZCO	RIPE, AE
77.105.136[.]66	2026-01-17 → 02-21 (recurring)	AS216071	VDSINA – SERVERS TECH FZCO	RIPE, AE
64.111.93[.]20	2026-02-21 (single day)	AS399629	BL Networks (BLNWX)	ARIN, US
77.238.232[.]188	2026-02-23	AS216071	VDSINA – SERVERS TECH FZCO	RIPE, AE
77.105.139[.]80	2026-02-25	AS216071	VDSINA – SERVERS TECH FZCO	RIPE, AE
179.61.145[.]140	2026-02-25 → 03-09	AS202051	NETGRID HOST LTD	RIPE, GB
141.11.197[.]134	2026-03-18	AS202051	NETGRID HOST LTD	RIPE, GB
141.11.197.63	2026-04-14	AS202051	NETGRID HOST LTD	RIPE, GB
185.112.59.99	2026-04-23 → 06-05 (current)	AS209207	DHOST-AS / Digital Hosting Provider LLC	RIPE, RU

• Two ASNs account for 7 of the 10 rotations. AS216071 (VDSina) covers four IPs and AS202051 (NETGRID HOST LTD) covers the other three. The operator moved across three different /24 blocks (179.61.145.0/24 → 141.11.197.0/24, twice) while staying on the same ASN throughout, from late February to mid-April 2026.
• VDSina is registered under a UAE shell (Servers Tech FZCO) but operates as a Russian-market VPS brand. This is jurisdiction-layering, typical of gray/bulletproof hosting.
• NETGRID HOST LTD’s RIPE registration itself changed shortly before this campaign adopted it. The ASN’s registered country flipping to GB on 2026-01-23, about a month before the first rotation onto it (2026-02-25).
• The first and last providers in the timeline are both Russia-based (AEZA GROUP and DHOST). Of the 5 distinct ASNs used, 3 trace to Russian-operated hosting despite only one (DHOST) being RIPE-registered under RU directly.
• 64.111.93[.]20 (BL Networks, ARIN/US) is the one outlier used for a single day sandwiched between two uses of the VDSina IP 77.105.136[.]66 on 2026-02-21 (08:01 → 09:02 → 09:21 UTC).

One of the IPs also appears in an (apparently) unrelated SectopRAT campaign

Checking the rotated IPs against public reporting, 179.61.145[.]140 turned up in a Rising Threat Intelligence report published on March 31, 2026. That research covers counterfeit adult-game installers impersonating the IndieGala platform, which chain an Advanced Installer package, MSI files and PowerShell Defender exclusions to deliver SectopRAT (a different family reaching victims through a different infection chain than the samples in this post).

The overlap goes past the IP itself. Rising reports the same resolver contract (0x67b4af41467a51e0816752a6b223c7c55ae71957), the same get() selector and the same six BSC RPC endpoints, with the contract acting as a fallback for when their sample’s hardcoded HTTPS C2 is unreachable. Their capture also falls inside the window our decrypted history assigns to that IP (2026-02-25 to 2026-03-09).

Plenty also separates the two, which is why we doubt they belong to the same campaign. The payloads are different families and the delivery differs. The obfuscation stacks have nothing in common either: our sample leans on ConfuserEx and a stripped import table, theirs on signed-binary abuse, Defender exclusions and a plain character-array trick to hide domain strings. The C2 designs differ too, since ours reads the contract as its only route to a C2 while theirs treats it as a fallback behind a hardcoded HTTPS endpoint. Rising’s AES key is unrelated to ours and protects a different channel, and their reconnaissance domains appear nowhere in our corpus.

Neither dataset tells us who operates what, but the scenario we find most probable is a shared infrastructure operation: one party runs Contract A and the resolver logic while separate payload families attach to it, either as products of the same operation or as customers of a rented C2 layer. The foundation for this theory is that both campaigns use the exact same deployed contract instance rather than just the EtherHiding technique, indicating a high-confidence technical relation between campaigns without revealing the exact relation. Deploying a fresh contract costs very little, so two unrelated developers building this independently would be expected to deploy their own independently. We can’t rule out other explanations, including a shared relay sitting in front of separate backends, or one actor simply reading the other’s dead drop, since the stored value is readable by anyone.

What this means for defenders

Blocking the C2 IP accomplishes little here. Contract A served ten different IPs over roughly a year without its own address ever changing, and the operator restores service with a single update() call that costs a few cents. The contract address is the part that stays fixed, so that is what detections and blocklists should pin to, along with the RPC endpoint set the sample uses to reach it.

That RPC traffic is itself a signal. An .NET executable issuing JSON-RPC POSTs to bsc-dataseed1.binance.org and its siblings is something few legitimate desktop applications would perform outside wallet and dApp software, and it does so before any C2 contact happens. Filescan flags this pattern through the MWCFG009 signal group for the same confuserEx variants as a strong indicator, and also flags potential JSON-RPC activity through S148 and U023 with lesser risk confidence level .

Back to the malware analysis, a sample that refuses to execute is not automatically a dud. All six samples in this cluster failed in traditional sandboxing, and the cause turned out to be a deliberately broken PE header rather than a corrupted download. Triage that discards non-executing .NET binaries would have dropped this entire cluster, including the finding of the AES key that opened up a year of C2 history.

The permanence that makes EtherHiding resistant to takedown also works against the operator. Once the key comes out of one sample, every write the contract has ever received becomes readable, including IPs rotated out months before that sample was built. For a defender that means retro-hunting: the ten IPs above can be checked against historical logs going back to June 2025.

What we don’t know

• How these six samples were delivered to victims. We found them through a Filescan.io corpus threat hunting for blockchain RPC strings rather than from a captured delivery chain, so the initial vector is unresolved.
• How the tampered PE is actually loaded in the victim’s system. The stripped import table implies a separate stager performing the reflective load, which we were unable to find.
• Whether AES keys are scoped per contract, per deployer wallet or per build. Contract A’s key decrypts nothing in the other 122 bytecode-identical contracts, which rules out one shared key across the cluster but doesn’t establish what the actual scheme is.
• What is the actual relationship (if any) between the operator behind Contract A and the SectopRAT campaign reading the same contract.
• The payload’s exact brand or version. Its data-contract model matches RedLine, and META Stealer is a near-identical rebrand that shares that same model, so we place this in the RedLine lineage without naming the specific product.

Indicators of Compromise

File hashes

SHA-256	Note
5ead45bc83c4fee8955212a5d8fc987164b13d149f6752d463381dddc444c5bd	2026-03-25, broken batch. AES key/scheme recovered from this sample
662435300304f5b1a75e577909ce65e24e483763342aa2eecfb1486911969b35	2026-03-25, broken batch
9ca461a4341c6de3091ec0e1d571ffdd257ad23632dccb13b7417c06ae245930	2026-03-25, broken batch
956fc9515bab51ddf550bdec0be053dae8997043e3f9979244e95925788cf53c	2026-03-25, broken batch
1af5aad4a5f22146539a05ccae2a7a18cfe49ff9e9a6a1dbf10a9cde0bd0957f	2026-03-21
2c1630f00a7903d2895e648571a5e302475ef1ca56daa862050ae298c06d0309	2026-03-21

BSC smart contracts and wallets

Item	Value	Note
Contract A (EtherHiding resolver)	0x67b4af41467a51e0816752a6b223c7c55ae71957	At least 6 RedLine samples related
Operator wallet	0x9bD32c5d9fe24cd70fe5532c484db50f5a6cCcf5	Deployed and operates Contract A
Funding hub	0x2a0d937DE7C5FAf3D6Bf5878f62A23D7BCEBB02b	Funds the operator wallet
Hub’s own funding source	0xa6AB8B5120f72b9419d85731823f2338510D9410	One hop up from the funding hub
Related contracts (bytecode-identical)	122 addresses	See “Bytecode-identical contracts across the wider corpus” below

Network and host artefacts: Contract A’s C2 rotation history (2025-06-21 to 2026-06-05)

IP	Active period
77.73.131[.]91	2025-06-21
146.103.126[.]229	2025-12-04 to 2025-12-14
77.105.136[.]66	2026-01-17 to 2026-02-21
64.111.93[.]20	2026-02-21
77.238.232[.]188	2026-02-23
77.105.139[.]80	2026-02-25
179.61.145[.]140	2026-02-25 to 2026-03-09
141.11.197[.]134	2026-03-18
141.11.197[.]63	2026-04-14
185.112.59[.]99	2026-04-23 to 2026-06-05

Cryptographic material

Item	Value
AES-256 key (hex)	16658a6e0b49091670fd18f189e1fe0cee27f824936ff6a07713a206eddc9436
IV (hex)	541dd0207d92c0e7d2c6138417559b2f
Recovered from	Sample 5ead45bc83c4fee8955212a5d8fc987164b13d149f6752d463381dddc444c5bd

Bytecode-identical contracts across the wider corpus

Contract Address
0x00c98d4806ef6aef5accb5dae2bada9d160a9de6
0x04199f36a3432a7ab56d2b4b825ddbff4f6a8a30
0x07d8f3daad8936df2e44f13b50a48f7e6775f6c4
0x0dc18c881a46e37de9703c390535cdb285d37a16
0x0e34675cfe8faaafc6afa3ff99bf5f3013aa6ce6
0x100a051d2b55cee3f668e995ff34ed9fbc1edf75
0x101b51e7489a4ddc2b78e94c86736969e54b59da
0x17359051ace963f847a879e6672b934f60dc6e52
0x17b2745b68dfc85a393f09587904a7bb06be228d
0x1838ba721dc0f15ebfa9d50e1272b9ca257a3795
0x1913231be66becc0a0aa9c004ef7176db0e09289
0x1c2b2eb1e5087b442a1bb84aa935e4c753eba1e7
0x1e4c19db19a90e17960312720d4ccbd6b36f6764
0x1eb7a243e568948a72fc27cceb767fc2a58c67c0
0x201c6e502f54646beaeb9555f44391e107b92770
0x21f81da5a0d9013f0acd44d3e485ae5f32ba8939
0x25fa1a0fe5d6b1db4596691f31fa26ef95e8db32
0x28c720242e6ab635212988fa1412f5799bacc5f3
0x2928d637cdc20a1c0aed8df815f5f9f49052a5b8
0x2a1abae855fb6adab2d4fdd1b298a7e710fe86b5
0x2da2244555c222380120d65a29d19f8acc84f67f
0x2e037e82f42c9c03061716bba28308a7209a2002
0x2e80c30270e27cee7cd38ddabc56bf17428e8170
0x2ee33ebf104b200254f97f386445dcb95c034294
0x2fda3bf64ea33eee8855e4766a61183823ae7cde
0x31b276309fae3b11ee10ad085e165217092894cd
0x330471e2491ca46842787002b99966e5cb4e02c3
0x335a7a4f127572a51b30bab41184e1c2bcb1c263
0x347dea3e6bc002de30af4507f93edc162f27ffb9
0x35697b68a524864b2f22be80253980b21fcbdb0e
0x38b513cf891ea40606ff40a2810834cfc2f43b9c
0x3902b0e553b29d9549728c3f943211bf122fb0cf
0x39b4b46c217326507960e1f2727ebb463cfdf905
0x3b7ceda3e3969a59c7943b3335d602ba1a5c77ca
0x3c2a189c13e50dc754ec735b0a89a887ee74b3c2
0x3cdcac046aecbb48b60aad7d2420be6998297409
0x41e91c575b3eba3cc0c18bb85464c282ae705d59
0x42c60520ded9ea0e59263529ae6a19491588df6b
0x4c27e37d835ccdd43558e03a95d4308a1308c041
0x4d12cffca41a212086f3d43bb37db32393eeb8bb
0x509fb3017546385c469fa877c3505b7dbbfb620c
0x556bd2a8732b5994f887f60dcf9e3f8b75c96c5f
0x57162e70b6456d93be8820f58473703ce3823979
0x584bd5cee8dac78d8cd70a1918e1c7e2bc3b4c4a
0x59148e090e021b726858da0ca03bbccd68e40b17
0x5d783525f2a582bbc06fcd1406970fe31f883339
0x61b7b361cdf38d40e7d91c43028c62de4f30998c
0x63b08416c66c6ed85732adb2b2be334af265c2cb
0x69a7f39952f3d65605c3edda0f5a6712f07a5184
0x6b134a1ccdd585d760142d808a30d963ee14dbee
0x6b4998926b651fee1cec07ae3aed813437ec9f76
0x6dec0d19e610517c97ed418bff89ff0081d6a719
0x7053b9dcc5608389260174551e7982eb30a875d1
0x70a9aee14d5357be740ae091bff100a3a246fe2a
0x7264c2b7bad4f9d7228243b55df1c6e53a13660b
0x7362c5844820dfed44f41e6206ac5301e39eb303
0x7440b16afbf9a871914471655a10721f56e87253
0x761392af8c9ae920838b84216c4dc3900320b912
0x7818fb09d9eb1a74888a0a33223c2fb30c93a052
0x7a61b3694157dfc0a0bcb1cbc93e1775be2bdc12
0x7cad4221db006105ef4039b373837761938575b1
0x833978e647f171f32217177f3f66a416c106717b
0x83862d8fbfcf4001c9439a59d14e5dca36ad5bba
0x8b43d3d3f4b91dbe7a4512ec90dc82577d125c34
0x8c744bd54640650c8885975032b5e54321da283b
0x8cb39206eda90ac81e7d71358e2cf1327214ccaf
0x8cdd792abb0d30fcb7929e860fa57e09918abdf9
0x8d278f6e0f126c3d901d5cb9ecc6e22754a1fea6
0x8e28c9b2ecfbb1b189c5189bf111e4b0b38243e8
0x8e2b9e3262e86c65db892e8992070d0455c57a22
0x8ec9363206195b3f98eb655fbc402520be6b910d
0x90d42158d35eddd437a0407a0ffe5fb28c47e30d
0x9314eea7117aa39e0abd84a40301b038a2de7af4
0x931f16e4f731d4f6a12035dffce7d395fd0712f2
0x94db8d4e2aa1abfb94f247da449ebf3e932abb2a
0x96c4e67620f0a80d08cb1948d4bdb6049d4394c5
0x99322a70fe3c1aba78268e69e5c5b650f80cc4bd
0x9bb2eef8ce08dc5a5423ed9accbb351c1facf624
0x9f9175c4d396047b7a2794b483553dc3e124ac80
0xa125cc4da21895aa45ebe39446fea15dfafbf467
0xa32e29d6c00b4b700c653a0070ee57c4e3ca5c64
0xa602c36dc0235be52be5cf06682fdf6333dbf883
0xaf9bafb2198b700c20bc62f732bb136dcb3604a2
0xafe90e92a74c7963fbbdb0c888d42010fbfbcf6e
0xb1e2bd333e04bb1c29aae8f45dafb93ec3f5e0fe
0xb45155040dd8861a004a8a3424175952e2df61b9
0xb666c040c6d218057cbf46e09ad84e9a806f6952
0xb92314539acf35df1132490b8b1d73680627be60
0xba43595984d43941729aa3e604e30a229575aa34
0xbd75e2f339d4aebf72ff13f3af4c27096f709a4d
0xbf81f1955e2e7e3b04ea7c82b72bbf6853191e32
0xc1434e93b16b61359583a21a28ab911cdbe4e380
0xc29aa2f12d8d0a03ed225ac4f235d650e0ab02d3
0xc35d40c5c35eb33438078f16ba92a2f78c8bfb62
0xc5980eb3bbd7d6f829f046f07cf195c72a1c3f29
0xc697d8019602d173ce4bbde323b86a08ab6674ac
0xc8da5056e06993926e29efc55ed86681d282df8f
0xc993ceb5c06d0191e3c681707980f3d3d00d8e67
0xc9b44479ce3797ee5a5602f1565eaad913a0adc3
0xcdb5e2d4a7cc9cb8054e90777b3d9875807fbac1
0xcfa52dd7dc11dd64e276993cb503030e722898e6
0xd46c4b5cf4e9f784dae2ee4472ccafa7fd0f94d5
0xd5b7e4cc132986426f5409f42799d0e1d0f44b62
0xdd31210b5b128fe7adc0298d5c6a6db2c7277c46
0xde9095a75a667557f718f6c6ea063baef4fad93a
0xe012d0f34cde9b870e9d9ed566ea5f8fd9b92228
0xe23a36e194d4a439b56a2e09a67dca2fe981af73
0xe7169089bb0665b430990932e364d69e1bed804e
0xe73ce4a3538eb29502a103aa36e5b9b2049d4f6a
0xe858a0c67ee580ed0b9f15c98d59265281999873
0xefc52801004e57db8545353e5bcbe8d3e4339e84
0xf1eb005811dccff35cfb0059ccded47ce22b78e8
0xf2431a8333a67026d91dbc322ca4073ccd51d426
0xf4852d108394a87c5a595d522683be586cf0cb4f
0xf68f23f721e835cc6a3dd541bb4768d001380a7b
0xf739182dc2d44d957052a873b664f19a71f693da
0xf7963a7bfc9808501c72904f31c78eb85a94bf1a
0xfa624ded1acf74810a7344efc0b8d2a7369fd886
0xfae0d1c011c6d510f05fc8de9af55f2d3cb945e6
0xfc231353d9414b783832c2c2f94208b2e889fc9a
0xfdf3acb71c52889e5bb38e77512a7a18d292fe10
0xfef59420b204fbf6ca12e9d08b1c54b07c55c7ab

Sources

• Guardio Labs, “EtherHiding — Hiding Web2 Malicious Code in Web3 Smart Contracts”, October 2023
• Xinhao Zhao, “Desire and Risk: Exploring the Dual Nature Behind Adult Game Counterfeit Installation Packages”, Rising Threat Intelligence Platform, March 2026