Warning: this blog is an experiment. The idea for a blog came from a real conversation I had with somebody. The content is researched, debated, refined, “hardened” by a Gemini skill I created (using Gemini 4 Argon). Then Claude Opus 5.5 performed a peer review, and tore some parts to shreds. Then rewrote them. And then I very lightly edited it, and tuned a few jokes. I replaced a food fight joke with a pillow fight joke, specifically. Let me know if this sucks, and I will stop. Promise!

—

A security peer recently shared a proposal they had just heard in the wild: instead of paying for a SIEM, why not load several days of raw log data into a locally run open-weights model, ask it “what looks risky?”, and review whatever the model highlights?

No SIEM ingest tax! No cloud token bills! No SIEM license fees! No writing correlation rules! No tuning anomaly detection! Just a gaming GPU under a desk and pure, artisanal AI-native vibes. Ahhh, magic!

Wait. Really?

My first instinct, forged by 24 years of staring at logs since I first met a SIM in January 2002, was to laugh, pour a drink, and move on. Surely everyone knows this is a terrible idea, right? Right?!

Wrong.

If an engineer, an IT director, or a cost-cutting CFO pitches “local LLM as a poor man’s SIEM” in your organization, you cannot just roll your eyes and mutter “hallucinations.” People keep inventing this idea for real reasons. SIEM ingest pricing still hurts: some vendor cost explainer works out 5 TB per day at $2 to $4 per GB as $3.6 to $7.3 million a year on ingestion alone. Detection engineering is still hard work. And yes the AI hype machine has spent two years promising executives that models can “reason over any unstructured data.”

So let’s dissect why dumping a week of raw logs into a local model breaks four basic laws of “operational physics”, and then carve out the narrow 10% where a local model does help with logs. The short version fits on a sticker: the LLM writes the parser, it never runs as the parser. And the twist is that the problem here is “raw,” not “local.”

Token Arithmetic and Naive Chunking (Or: How Big Do You Think 7 Days of Logs Is?!)

Let’s start with grade-school arithmetic, because clearly nobody pitching this architecture has ever opened a calculator…

Forget the enterprise. Take a tiny environment, a single server rack generating a measly 1 GB of raw text logs per day. Seven days of logs is 7 GB of text, or roughly 1.75 billion tokens at 4 characters per token. That is generous, since IP addresses, GUIDs and hex strings tokenize worse than English (Wow, really? Yes, really — at least Claude thinks so! He would know, right?)

Now look at that “free” 8B or 70B parameter model on your GPU workstation. Its usable context window, before the KV cache devours your VRAM and the fans sound like a Boeing 747 on takeoff, is maybe 32K to 128K tokens. You are shoving 1.75 billion tokens through a 128K keyhole, which is about 13,700 full context windows. Painful enough yet?

Well, it gets worse. Assume your box reads a generous 2,000 tokens per second (benchmark your own, I’ll wait). Reading those 1.75 billion tokens takes about 10 days. You need 10 days to read 7 days of logs, so you never catch up! Scale that to the 5 TB per day example above and it is about 20 years of GPU time for each day of logs. Hilarity ensues! Replacing a deterministic stream processor with a token-by-token text predictor is like replacing your municipal water pipes with a guy carrying a silver espresso spoon from a well 10 miles away.

“Fine, Anton,” the DIY enthusiast says, “we’ll chunk the logs into 2,000-line batches and loop the local model over them all weekend!” Or we will get a bigger boat… eh… server rack to run the model.

Chunking naively, by just loading the data in batches, fails hilariously. Here is how:

• Attack chains get cut. The phish on Tuesday lands in one batch, the lateral movement on Thursday lands thousands of batches later, and no prompt ever sees both. Each batch gets judged alone.
• Merging the summaries does not bring the signal back. By the time you summarize the summaries, the one quiet line was already dropped in round one. So “naive+” fails as well.
• Position inside the batch matters. Liu et al.’s “Lost in the Middle” found that models do best when the relevant information sits at the start or end of a long context and degrade sharply in the middle. They tested question answering and key-value retrieval, not logs, but picture a quiet privilege escalation on line 1,482 of your batch. Worst seat in the house.

Researchers keep running into this. Cai, Ryan and Karie note that iterative approach is limited by context capacity and that map-reduce style summarization is computationally heavy (and requires some luck). Even so, that is a proof of concept on up to 20,000 rows per dataset, and they say enterprise volumes remain to be validated.

So smarter chunking exists (reminder: it is not magic, in this area nothing truly is): parse, cluster, then retrieve by entity and time. At that point you are building the first half of a SIEM. Congratulations!

As I wrote in The Ancient Art of SIEM, cost pain is eternal and only the currency changes. In 2003 you ran out of hardware, in 2015 you ran out of cloud budget, and in 2026 you run out of tokens and VRAM.

The Input-Centric Time Machine: Back to 2002 Batch Review

Notice the most revealing phrase in this idea: “load 1 to 7 days of log data… and then review what the model highlights.”

That is not real-time detection. That is batch-mode log archeology! When intruders can go from initial access to data theft in hours (soon: minutes for some incidents), reviewing a week of logs in a batch means you are running a weekly book club about how you got breached last Wednesday. But hey … is your SIEM faster? Well, it should be!

Worse, asking an LLM to “highlight what looks risky” violates the most important lesson of two decades of detection engineering. In Output-driven SIEM, 13 years later, I revisited my favorite 2011 mental model: think about what you want to see at the output before you collect, and AI does not change this. Asking a model to “find risk” in raw logs with zero detection engineering is the ultimate input-centric anti-pattern. It failed with ML in mid-2010s, and LLM is not different (in this regard).

Now, about determinism. The lazy objection is “the answers change on every run,” and a sharp engineer will reply “so pin the seed.” Fair enough! Run-to-run randomness is an engineering problem: Thinking Machines got 80 unique completions out of 1,000 at temperature 0, then 1,000 identical ones after fixing their kernels. But is it actually bad? Maybe if you run 5 times, you will find 2x more “fun” things. But hey … also probably at least 5x more noise.

The harder test is stability. Take the same 48 hours of domain controller logs, shuffle the order or change one irrelevant line, and run it again. Given what we learned, I would bet real money the verdict moves. Well-crafted SIEM rule does not care what order the lines arrive in.

Zero Local Context Equals Hallucinated Risk

Why can’t a local model tell an active nation-state intrusion from Tuesday’s messy IT administration? Because raw logs do not contain your organizational reality! Shocking, eh?

A raw syslog or CloudTrail line says that svc_deploy_04 logged into prod-db-02 at 3:14 AM from an internal jump host and ran an encoded PowerShell script. Is that a five-alarm breach or the legacy billing batch job that Bob in accounting wrote in 2017 and nobody dares to touch? This is a dated example, on purpose. Insert your own fun example involving a shadow AI agent!

In Part 3 of the Stop Building a 2003 SOC series, I argued that the #1 reason AI fails in the SOC is the absence of Context as Code: machine-readable, owned, and expiring knowledge of your assets, business processes, and weird administrative exceptions. In Part 2, we warned about automation bias: humans reviewing plausible, well-written machine verdicts approve them.

Also, the test from Can AI Let You Jump SOC Maturity Levels? applies here: does this exist because someone had to spend time, or because someone had to learn something about us? Writing a parser is a time cost. Knowing about Bob’s job is a learning cost, and no model downloaded from the internet has paid it.

Feed raw logs into a naked local LLM with no CMDB enrichment, no threat intel, no identity graph, and no 90-day baseline, and its only source of “context” is its pre-trained weights. So it flags every scary-looking word (ERROR, DENIED, admin, root, failed) and writes you a convincing fictional thriller about your own network.

The Confused Deputy Trap: When the Attacker Prompts Your “SIEM” via User-Agent

Now put on an attacker hat for 30 seconds. What is a log file?

A log file is untrusted, attacker-influenced input. Every public-facing web server, SSH daemon, API gateway, and email relay faithfully records whatever string an outsider sends in an HTTP User-Agent, a failed username field, or a JSON payload.

Log processors have been attacked through logged strings before (hi, Log4Shell!), but that was a bug you could patch. In a raw-log-to-LLM setup there is no parser boundary to patch, because instructions and data share one channel. You just handed the attacker write access to your detection engine’s prompt!

Summaries are also scary, BTW. Pandey and Bhujang found that the classic “ignore all instructions” override failed completely against the one model they tested, but context manipulation reached 96% success on summarization with no defenses and 38% even with constrained output.

In How to Solve the Mystery of AI Defense in Depth (and my October 2026 collaboration with Usman Chaudhary, The Model Has Preferences, but the Harness Got Controls), I emphasized that a model’s statistical preferences are never a security boundary, and only a deterministic harness is. Feed unparsed logs straight into a local LLM with no harness, and any kid with curl can blind your review or flood your team with fabricated critical alerts…

The Problem Is “Raw,” Not “Local”

Let’s be fair to the local crowd, because they have a point.

• Local solves a real problem. Logs are full of secrets, PII and internal hostnames. Not shipping them to a third-party API is a legitimate reason to want a model on your own hardware. It also — theoretically — eliminates an endless stream of unpredictable token costs flowing to a frontier model provider.
• Small models are not the villain. In the same paper, a structured design called Aida (separate agents for investigating, challenging and judging, working through a SIEM) used open-weight Qwen3.5 9B and it was workable for the task they had.
• “What about an agent querying a log store?” Now we are talking! The model forms a question, a database searches 7 days of logs deterministically, and the model reads a small result. That is a very different architecture, and it needs parsed data, a query engine, detections to start from, retention and access control. Sound familiar?

So keep your local model if you want it. What is missing from this proposal is the SIEM…

The Raw-Logs-to-Local-LLM Delusion Matrix

For explaining this to an enthusiastic colleague (or a budget-slashing executive) without starting a pillow fight:

Wait, Is a Local LLM Good for Anything in Log Land? (The 10% Where It Shines!)

I am a constructive cynic, not a Luddite (At least Gemini 4 Argon thinks so!). As I noted in the SOC maturity post, AI can jump the artifacts, and parsers are on that list (with caveats for tricky log sources). So point your local model at logs as an engineering sidecar, not an ingestion engine:

• Writing the parser, not being the parser. Instead of feeding 50 million lines from a weird legacy mainframe into an LLM, feed 20 sample lines and ask for a regex, OCSF mapping, or pipeline rule. The LLM writes the code once, and deterministic CPU code parses the 50 million lines at wire speed. This mostly works, I swear.
• Post-trigger micro-slice investigation. Once a rule or EDR alert fires on a specific host and 15-minute window, pull 200 pre-filtered, enriched log lines and ask the model for a timeline. Those lines still contain attacker strings, so treat the summary as untrusted and let the model request actions only from a closed list.
• Ad-hoc query translation. Translate an analyst’s question into KQL, SPL, or SQL, so the database searches 7 days of logs deterministically. This also mostly works, but some YMMV.

The Lean Team Reality

What if you are the CISO of a regional insurer or hospital with a small security team, a hybrid stack, strict state regulators, and an MDR provider? When an engineer or cost-conscious VP suggests “let’s dump our noisy firewall logs into a local Ollama box,” they aren’t trying to sabotage your SOC. They have a log source that is too expensive to send to the SIEM, and they want a free way to “keep an eye on it.” Here is how to solve that without a science project:

• Don’t use a GPU box as a poor man’s data lake. Route a noisy source to cheap, searchable object storage, or strip verbose fields in a pipeline before ingest. This is my old two-tier answer (a SIEM plus a broad, cheap log store), and it has aged well.
• Hold your MDR to the same standard. When they brag at the next QBR about “AI-powered log analysis,” ask whether deterministic detections run first or whether it is an LLM wrapper over unparsed telemetry. This point alone is worth the price of reading this blog (A.C. — this is me, not AI)
• Channel the DIY energy. Give your smart engineer 50 anonymized lines from your gnarliest legacy application and ask for three high-signal filter rules you can deploy in your real pipeline.

Action Items for Security Leaders

Is there anything you need to actually do?

• Run a napkin token audit on any AI log proposal (Monday morning). Before the demo starts, ask: “How many GB per day is the raw source, how fast does the model read, and what deterministic step selects the tiny slice that reaches a context window?” If the answer is “we’ll just load it in batches,” kill the project on the spot. It’s this “just” word.
• Fix ingest pain with tiering (30-day play). If this idea surfaced because a log source is too expensive for your SIEM, solve that: drop repetitive keepalive chatter, route compliance-only logs to cheap storage, and keep output-driven security data in your detection tier.
• Make “the LLM writes the parser, never runs as the parser” a standard (architecture play) — that is, if you write parsers at all. Allow LLMs at design time (parsers, mappings, queries from small samples) and at post-alert time (small, bounded, enriched slices), but not as the runtime ingestion or anomaly engine over raw logs. Put it in your MDR requirements too… otherwise they will keep whining that it takes 7 weeks to integrate a log source forever.
• Test your existing AI log workflows for prompt injection (60-day play). If your SOC or MDR summarizes anything containing attacker-controlled strings, test it in your next purple-team exercise. Do not stop at a naive “ignore instructions” canary, because passing that proves little. Try persona and context-rewriting payloads, plus payloads split across lines.

So, Do You Need a SIEM?

Call it a SIEM or call it a pile of parsers, a query engine, detections and retention. You need those things, and a GPU under a desk does not replace them. By all means run a model next to them, I promise it will be fun!

The part that worries me most is how this fails. A detection rule that misses can be tested, tuned, and re-run. A model that misses hands you a nice summary, and nobody knows what was not in it. As I said in September, skipped maturity used to fail loudly, and now it fails quietly.

We had 23 years of progress, and the best practice is still “have a plan and don’t ingest garbage.” That goes for your context window too.

[A.C. — note to self: this is v6 skill]

---

“I Don’t Need a SIEM, I Have Ollama!” (Yes, You Do!) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

In describing SIEM features, vendors almost invariably focus on numbers: how many correlation rules come out of the box, how many were added over the past year, and how many MITRE ATT&CK techniques they cover. Admittedly, these numbers matter. They do help gauge how effective a system is, and we share them from time to time too. But correlation rules aren’t a magic amulet, and having more of them doesn’t make a SIEM more effective. In fact, the total number of available rules says more about the variety of use cases the system supports. The question a hands-on SIEM analyst cares about first of all is different: which of these rules will actually work and be useful at my company? The answer is far from always obvious, and the reason isn’t even rule quality.

How correlation rules work

A rule first and foremost describes the logic: what to match against what, in what order, and within what time window. It also specifies particular event types from particular sources. For example, a rule for Active Directory group creation waits for events from the Windows Security log; a rule for suspicious network activity — DNS queries; a rule for process manipulation — triggers on events from endpoint telemetry. In other words, whether a rule works depends on whether the SIEM receives the right data in the first place.

The Active Directory rule above would be completely pointless at a company that avoids Windows on principle. It would load without errors, show up in the interface, and technically “exist” — but it would never fire. The reason is simple: the events it was built for never reach the system.

That dictates the only correct order of steps when setting up an SIEM. Don’t start out from the list of rules and then work your way toward your infrastructure. Go the other way around: first pin down which event sources are actually connected and feeding data into the SIEM, and only then see which rules will work on that data. Doing it the other way around leads to one of two outcomes: unmet expectations (hundreds of rules, almost no detections), or a laborious rule-by-rule manual slog, where the analyst opens every rule’s description, checks its event requirements, and decides whether the rule is worth using.

What the MITRE ATT&CK coverage percentage means

MITRE ATT&CK coverage is much the same story: it’s often used without a second thought as a yardstick for product effectiveness. The catch is that these are numbers in a vacuum, with no real-world conditions behind them. Coverage only makes sense for a specific set of working rules. And as we saw above, that set of rules depends on the set of event sources. That’s why the same SIEM will show different MITRE ATT&CK coverage at two different companies. Where Windows logs, endpoint telemetry, an email gateway, and network equipment are all connected, coverage will be noticeably broader than at a company with fewer sources.

Here’s the right way to read this metric: it’s not a score for the SIEM content, but a map of what your SIEM can see with its current telemetry. A tactic with low coverage is a signal that detecting it requires data you don’t have yet. Framed this way, it becomes a clear argument for a management conversation. Not “we need one more event source”, but “this part of the matrix is currently invisible to us, and here’s what it takes to close the gap”.

What’s worth checking in your SIEM

To get the most out of a SIEM, it’s worth asking yourself a few questions — not just when deploying the system, but regularly:

• Is every connected event source being handled by rules? Infrastructure changes constantly: new systems appear and new integrations get connected. Every change like this is a reason to check again whether there are now rules you should enable.
• Do I know exactly which events are required for which rules? Sometimes a rule doesn’t fire not because a whole event source is missing, but because a single event type isn’t being collected: the audit policy simply isn’t set up to capture it. Fix that oversight as soon as possible.
• Do I understand my coverage in terms of MITRE ATT&CK? The point isn’t to produce good-looking reports. It’s to prioritize which event sources to add next: which ones will give the biggest gain in visibility?

But how can you answer these questions without spending ages digging into every rule description? We have a solution.

How we can help

To help analysts find their way around the detection logic of our solution more easily, we’ve added a knowledge base section with the complete set of Kaspersky SIEM rules. In essence, it’s a tool that holds data from the official documentation for the SOC Package rule set, and makes it easy to work with that data. It has three sections:

Library. A table of all correlation rules that you can sort and filter per any column: category, MITRE tactic and technique, event source, and event type. Search works across all fields, including descriptions. Double-clicking a rule opens a card with detailed information about it.

Builder. A tool for assembling a rule set that suits the event sources you already have. The analyst just checks the boxes for the sources the company has, and gets a list of matching rules, brief statistics, and the event types that need to be set up for collection. The tool also generates a regular expression that you can paste into the search bar of the Kaspersky SIEM web interface to link all the matching rules to the correlator in a single step, with no manual picking.

MITRE. A view of the ATT&CK matrix where tactics expand into techniques and sub-techniques. Each matrix item has a card with the description from the MITRE website, and SOC Package coverage details. Covered and uncovered items are color-coded, and charts show coverage per tactic.

One more point worth stressing: the content in our SIEM is updated constantly, so it makes sense to check your setup against it not only at deployment, but after every notable change in your infrastructure. To follow the development of the Kaspersky Unified Monitoring and Analysis Platform, visit the official product page.

Back in 2023 — which is roughly 30 years ago in “AI years” — Marina Kaganovich and I first wrote about “shadow AI”: employees sneaking around with consumer-grade AI to get their actual jobs done. Life was simple. There was AI your company approved (for many CISOs, this was a proud empty set), and AI it didn’t. Employees loved and used the latter. Employees felt “meh” about the former. The core risk was equally simple: data leakage — someone pasting sensitive snippets into a prompt and having them show up in training sets or outputs for others. Then shadow AI struck back in 2025, wearing an enterprise badge (we called it Shadow AI Type 2).

But in 2026, the risk landscape has changed: we have moved from passive data leakage to rogue actions. Modern shadow AI isn’t just listening or talking; it’s executing terminal commands, calling external APIs, modifying production databases (if you suck at access control, it definitely does), and acting as autonomous agents with delegated corporate credentials (if you suck at identity delegation).

If your 2026 security strategy still treats shadow AI as “DLP and a proxy block will fix it” (or: “we will just block ‘bad AI sites’ on a proxy or DNS filter”) you will be unpleasantly surprised. On the flip side, you may actually be pleasantly surprised: a lot of our classic 2023 shadow AI fears turned out to be genuinely low risk.

Still, every time I present on this topic, somebody walks up and asks: “OK Anton, but where does X go?” Where X is:

• A CLI coding agent on a personal subscription, wired via an MCP server directly to a production database (please don’t laugh, it really does happen at some places).
• A Python microservice in prod that quietly calls an LLM API using somebody’s personal credit-card key.
• An OpenClaw instance on a sales rep’s laptop, with full read/write access to their corporate mailbox and CRM.

None of these fit neatly into the “employee pastes data into a chatbot” mental model of 2023. So it is time for a refresh. Below is my 2026 taxonomy: Seven Shades of Shadow AI. (BTW, Marina, I still miss you as my collaborator :-))

Good News, Bad News (With Numbers)

But first, some good news: the 2023 problem is getting better, at least as a share. Netskope’s Cloud and Threat Report 2026 shows the share of genAI users on personal AI accounts dropping from 78% to 47%, while organization-managed accounts climbed from 25% to 62%. Paved roads work. Who knew? (We did.) Now, the fine print: this is a share, not a headcount. Over the same period (October 2024 to October 2025), the number of genAI users tripled and prompt volume grew sixfold, so the raw number of personal-account users likely still went up. And the people bouncing between personal and corporate accounts grew from 4% to 9%.

Other datasets paint a less rosy picture: Verizon’s 2026 DBIR still found 67% of employees accessing AI through non-corporate accounts on corporate devices, making shadow AI the #3 non-malicious insider action in their entire DLP dataset. And when Harmonic Security analyzed 1.9 million AI session minutes, 65% of the activity on personal accounts was actual work — writing work emails, summarizing meeting notes, debugging code. And it was go-to-market teams, not legal, who led on free accounts. (Filed under: “Shocking, yet totally unsurprising.”)

The bad news: it is 2026, and the battlefield moved.

• Breach correlation is spiking: IBM’s Cost of a Data Breach Report 2026 found shadow AI incidents at 43% of breached organizations, more than doubling from 20% a year earlier (summary). Regular readers know I don’t trust their breach cost dollar math, BTW, but this trendline is completely believable.
• The Dunning-Kruger Agent Paradox: A Cloud Security Alliance survey (commissioned by Token Security, 418 responses) found that 82% of organizations discovered unknown AI agents in the past year — yet 68% simultaneously reported high confidence in their agent visibility. Fun math: most are confident, and yet most are surprised! (To be fair, finding an unknown agent means discovery worked at least once.) When 82% of enterprises keep stumbling across unknown agents, “unknown” isn’t the shadow — it’s the default state of modern IT.
• SaaS is governed; AI plumbing isn’t: Reco’s State of Agent Security 2026 showed that while 79% of SaaS apps were authorized, 80% of AI tools — browser extensions and MCP servers included — were completely ungoverned.
• Geography and model provenance now matter: In a separate July 2026 report, Harmonic found that every single organization of the 79 they monitored in H1 2026 had at least one employee sending data to a China-based AI tool like Tencent Hunyuan or DeepSeek (not just their model!). The median was only four employees per organization, but across the dataset the uploads included M&A plans, source code, and financial projections. Wow, dear reader, that might be your organization too!

BTW, obligatory note on survey data above: not all surveys are “good data”, these are shown here as examples that serve my narrative. Feel free to find those that contradict it and share with me!

So, IMHO, in 2026 we are slowly winning the 2023 shadow AI war at the edge. Meanwhile, the 2026 war is being fought elsewhere: on developer laptops, in vendor release notes, and inside agent tool configs.

The Sorting Rule: Four Questions

Since seven items totally require a taxonomy, let’s make sorting rules. Shadow AI types differ on four things, and each difference changes the control you actually need:

1. Who turned it on? An employee, a team, a developer, a vendor — or another agent. (Exclude alien superintelligence from the list … for now ;-))
2. Whose identity does it run as? A personal account, corporate SSO, a developer’s own local/cloud credentials, a non-human service account, or the vendor’s platform. (The workload vs. workforce agent distinction is hugely useful here.)
3. Does it talk, or does it also act? Chatbots talk; agents act (and consumer chatbots are growing hands of their own). A shadow chatbot leaks data; a shadow agent does things. Sometimes ominous things.
4. Where would you even see it? Proxy logs, expense reports, endpoint process lists, config files in Git repos, SaaS tenant settings, OAuth grants, or the cloud bill — the list is not just long, it is broad. Work use of an AI app on a personal phone may be a data risk, but it is not a risk of modifying your production CRM.

If two findings give different answers to these four questions, they need different controls. One cute acceptable use policy will not cover all seven shades, sorry! And if you want the bumper-sticker version from my RSAC 2026 talk:

Shadow Agent Risk = Reach x Agency

(Question 2 mostly tells you the Reach; Question 3 tells you the Agency — and they multiply, not add. For the shades that mostly talk, data sensitivity drives the risk.)

One quick reality check before we panic: a lot of shadow AI is actually low risk. At RSAC 2025, I talked to a CISO who shrugged and said he just didn’t see much harm in most of it. And honestly? For a huge chunk of Shade 1, he was right. If an employee uses a personal chatbot to polish a public LinkedIn post, fix grammar in a cold email, or summarize a public PDF, the actual risk to the enterprise is near zero. Treating “fixing a public slide deck in personal ChatGPT” with the same hair-on-fire DLP blocks and HR warnings as “wiring an unsanctioned OpenClaw agent with an MCP server to a production database” is how security teams burn all their credibility — and push shadow AI deeper into the shadows. That is why we sort by reach and agency first.

Shades 1–2: The Ones We Already Know

1. Consumer Shadow AI (The 2023 Classic)

• What: Personal accounts on consumer chatbots, used for work. Plus my favorite unfixable edge case — the phone-camera loophole: point your personal phone at the corporate screen and ask it to fix your slide (I did this on a few webinars as a trick, worked well with Gemini even back in 2025). No firewall on Earth stops that one.
• Status & 2026 Wrinkle (Context Lock-In): Improving, but 47% is not zero, and users increasingly bounce between personal and corporate accounts. Why? Because of context lock-in (memory gravity). As one global tech head pointed out recently, employees resist switching to the newly approved corporate chatbot because they have so much history, custom instructions, and memory built up in their personal one (“It knows me, I cannot just switch”).
• Main risk: Data leaves the company under consumer AI terms — training, retention, human review — or crosses geopolitical boundaries.
• Where to look: Your web proxy, SSE, or CASB. Obvious, sure, but also correct.
• First move: Make the paved road better than the dirt road. Give employees an enterprise AI workspace with real memory, file uploads, and tightly scoped MCP connectors (email, calendar, CRM; email is an injection path, so scope it) so it actually beats their personal account, give them an easy way to import their custom instructions/history, and then enforce SSE/CASB tenant restrictions and managed browser controls to block personal logins on managed devices and networks.

Reminder: every solution here is partial! No magic! Inline tenant restrictions need TLS inspection and do nothing off your proxy, ChatGPT’s desktop and mobile apps pin certificates (so you need exceptions pushed by MDM), and logged-out ChatGPT needs its own URL block. You know, the basics ;-)

2. Enterprise Shadow AI (“Shadow AI for Business”)

• What: Perfectly decent enterprise-grade AI tools and platforms bought on a corporate card by teams or whole departments without central IT approval. Good vendor contract, zero internal oversight. Often it is not even “rogue” employees: a VP or team lead actively pushes the tool because the business value beats waiting for security. We called this shadow AI for business back in 2025.
• Main risk: Nobody tiered the use cases. Several teams pay for slightly different tools doing the same tricks. Your data lives in yet another unvetted tenant with retention and training settings nobody checked, and your AI policy exists mostly on paper — governance theater.
• Where to look: Expense reports, IdP third-party OAuth/”Sign in with” login logs, the SSO app catalog, and SaaS management tools. Classic shadow IT discovery mostly works here.
• First move: Put a fast intake valve on SSO and procurement. When an unreviewed AI SaaS app requests OAuth scopes or shows up on an expense feed, route it through a lightweight 48-hour use-case risk tiering check (verify data sensitivity, training opt-out, and retention settings in the tenant, plus any zero-data-retention terms in the contract, since ZDR is usually a vendor approval rather than a toggle) and onboard it properly rather than writing another paper policy nobody reads.

Shades 3–5: The Builder & Supply Chain Shadows

3. Developer Shadow AI (IDE Agents, Local Models & Rogue Plumbing)

• What: Coding assistants and CLI/IDE coding agents (like Claude Code, Cursor in Agent mode, Cline, or Aider) running on personal subscriptions or model API keys tied to personal credit cards (oops!). Local MCP servers dropped into a project config file, wiring the assistant directly to databases, internal APIs, and a local bash shell (no way, right?). Open-weight models (llama.cpp, Ollama and friends) running on a beefy laptop. And the “occasional” (with a very load-bearing meaning of “occasional”…) “auto-approve everything” / — dangerously-skip-permissions flag, because clicking “yes” 400 times a day is boring.
• What is new: This is not a browser tab. It is an execution harness running with the developer’s own privileges — often repo write access, local SSH keys, cloud credentials, and sometimes production reach. Reco analyzed 500 published MCP servers: half let agents run shell commands, 82% read and write local files, 73% make outbound network calls, and 40% do all three. Read that again: it sounds like a remote access trojan (RAT) spec! As I said on X back in January: with coding agents, a prompt injection is basically an RCE.
• Also new: What it produces is production code. As I learned while vibe coding my own app, silence is a security decision: if you don’t say how to store a secret or check auth, the AI will happily pick an insecure default for you.
• Where to look: Endpoint process trees (especially IDE/CLI-spawned child processes running MCP over stdio with no listening port), local model listening ports, repo and user-level MCP configs (.mcp.json, ~/.claude.json, ~/.cursor/mcp.json), secrets scans for model keys (sk-, sk-ant-, AIza, and the newer AQ. format), and egress to model APIs or remote MCP servers. (If the model runs locally, the network sees nothing at all — more on hunting these in Part 2.)
• First move: Govern the harness, not just the model. Deploy a sanctioned coding agent wired to an internal LLM gateway, lock IDE configs to an allowlisted internal MCP registry, and disable “auto-approve” for destructive/network commands via managed policy (backed by EDR/app control so local admins can’t just edit the config). Finally, enforce a classic 1990s rule on the host firewall: block inbound LAN access to local model ports (11434, 1234, 8000, 8080) and alert on non-loopback (0.0.0.0) listeners — just don’t treat localhost as a magic boundary after ClawJacked showed a browser tab can hijack a local agent gateway.

4. Shadow AI Inside Apps You Buy (The Silent Upgrade)

• What: A vendor ships an AI copilot or embedded agent feature into a SaaS app you approved back in 2021. It is turned on by default in a monthly release, or a workspace admin casually flips it on. Your third-party risk review covered a completely different product.
• What is new: Nobody in your organization “adopted” anything. The shadow arrived through the vendor product update channel. Obsidian counted 69,749 interactions between users, corporate data, and embedded SaaS AI features in a single 30-day window. Worse, you cannot domain-block it at the proxy: it lives on the exact same domain as the core SaaS app your business runs on.
• Where to look: SaaS Security Posture Management (SSPM) / tenant admin settings, vendor release notes, subprocessor-change notices under your DPAs, and browser-level telemetry. (Perhaps your own — approved — AI agent can read vendor release notes and DPA updates for you?)
• First move: Kill “default-on” in tenant posture and contracts. Use SSPM to continuously audit unreviewed AI feature flags across core SaaS tenants and turn them off where you can (many embedded AI features still lack mature admin controls or logging APIs, so keep browser telemetry in the mix), and make “vendor added an AI subprocessor or agent capability” an automatic trigger for a fast TPRM delta review. Keep reading release notes too: an AI feature running on an existing subprocessor may never trigger a notice.

5. Shadow AI Inside Apps You Build (Rogue AI Dependencies)

• What: Your own software quietly grows an AI dependency. (Say what? How can that happen? Read on.) A microservice calls an external LLM API, sometimes with a developer’s personal key that traveled from a laptop .env file into a production config. A model gets pulled from a public hub into a container. An AI SDK (openai, langchain, litellm) appears in a repo “just for a quick summarization feature” — riiight, and now your nicely deterministic app is vulnerable to indirect prompt injection! Or a vibe-coded internal tool built by a citizen developer over a weekend suddenly becomes load-bearing.
• What is new: It sits directly inside your production product and customer data path. So it is not only data leakage; it is AI supply chain (like software supply chain, only not), plus prompt injection exposure for your own customers.
• Where to look: AI-BOM code/dependency scans, workload egress to model endpoints, cloud model invocation logs (on by default in AWS Bedrock CloudTrail; requires enabling Data Access logs in Vertex AI), secrets scans, and expense/egress data for unmanaged cloud projects.
• First move: Put hard choke points in CI/CD and production egress. Fail builds that pull unapproved LLM SDKs or unpinned weights outside your artifact registry. Because raw HTTP calls bypass SDK checks and weights can be pulled at runtime, enforce default-deny production egress with an FQDN allowlist and route all workload LLM calls through a central internal model gateway.

Shades 6–7: Shadow Agents (Where the Shadows Start to Act)

This is where the shadows grow hands. Borrowing the split from our March 2026 post: workforce agents work for a person; workload agents run a business process.

6. Shadow Workforce Agents (The Confused Deputy on Steroids)

• What: Autonomous agents acting as the employee. Personal assistants like OpenClaw on a laptop or a personal VPS, often driven from a personal phone, with corporate email and Slack hooked up via OAuth. In August, ABC News in Australia reported on an OpenClaw agent that hacked into a gym’s system and deleted someone else’s waitlist spot just to sign its owner up for a class. Now imagine that agentic mindset wired into an eager sales rep’s laptop — autonomously scraping, spamming, or probing a prospect’s systems from your corporate IP space just to “close the deal.”
• What is new: It is a confused deputy on steroids — acting with the employee’s full credentials and permissions, but with neither their human judgment nor their fear of HR. It runs continuously with persistent memory and pulls tools from third-party plugin marketplaces. Even better, it flips the legal risk on its head: with a shadow chatbot, you lose your data; with a shadow workforce agent, your employee’s confused deputy can actively harm an external company. Fun!
• Where to look: OAuth consent grants, browser session attach and PATs (desktop agents like OpenClaw often skip OAuth and attach directly to a logged-in Chrome 136+ session via chrome-devtools-mcp — autoConnect or local gateway/CDP ports 18789 and 18800–18899), and non-human activity on human accounts — machine-speed API cadence, 3 a.m. webhook/cron bursts while the employee is asleep, or a “human” token calling Slack/Drive from an AWS or Hetzner ASN (for VPS-hosted agents).
• First move: Lock down OAuth delegation, restrict personal access tokens (PATs) and unmanaged browser remote-debugging, and monitor human API velocity. Block user-level OAuth consent for high-blast-radius scopes (like full mail or Drive) unless admin-approved — publisher verification tells you who wrote the app, not whether it should read your CEO’s email (test first: setting a Google Workspace service to Restricted immediately blocks API access for existing apps you haven’t explicitly trusted). Route agent integrations through scoped token gateways and alert on machine-speed, 3 a.m., or cloud-ASN activity on human tokens.

7. Shadow Workload Agents (Orphan Non-Human Autonomy)

• What: Autonomous multi-step agents spun up by teams or citizen developers (in LangGraph, CrewAI, n8n, Zapier, or cloud agent builders) to automate business workflows — running on shared service accounts or non-human identities (NHIs) with standing privileges and zero lifecycle management.
• What is new: Orphaned non-human identities with standing privileges and goal drift. In the CSA survey, unknown agents surfaced in internal automation/scripting (51%), LLM platforms (47%), and SaaS built-in automation (40%) — yet only 21% of organizations had a formal process to decommission agents. The creator leaves the team after a hackathon demo, and the agent keeps running for months, experiencing goal drift as prompts, models, and upstream data shift.
• Where to look: Non-human identity (NHI) and service account inventories, agent platform registries, API gateway logs, and — my personal favorite — token spend anomalies. Your shadow agent may hide from your SIEM, but it often shows up on your cloud bill (unless it runs on a personal key, a local model, or a platform like Zapier or n8n with its own billing, in which case, sorry!).
• First move: Treat workload agents like contractors with a hard expiration date. Require a named human owner, short-lived scoped credentials, a hard daily token-spend circuit breaker, and an automatic 90-day TTL (auto-disable with brownout warnings unless renewed by the owner, tied to HR offboarding triggers) for every non-human agent identity. The spend breaker needs per-identity attribution at a gateway: one shared key gets you a breaker that kills everything at once.

Bonus: The Eighth Shade That Isn’t (“Shadow MCP”)

If I had to name an eighth shade, it would be Shadow MCP: unsanctioned tool servers. But MCP is less a shade of its own and more the plumbing that gives Shades 3, 6, and 7 their hands and teeth. Govern the plumbing (curate an internal MCP registry and inspect tool calls), sure, but don’t confuse the pipes with the house.

The 2026 Shadow AI Cheat Sheet

The four sorting questions, answered across all seven shades. Print it, argue with your team over it, or send me corrections:

Now that we have the taxonomy sorted by Reach and Agency, how do you actually hunt these down across your network, endpoints, and identity logs without turning into the “Department of No”? This is Part 2: Hunting Shadow Agents: What Actually Shows Up in Your Logs!

Related blogs:

• The Model Has Preferences, but the Harness Got Controls — Part 1
• How to Solve the Mystery of AI Defense in Depth?
• Anton’s Security Blog Quarterly Q2 2026
• My Really Fun RSA 2026 Presentations!
• “AI Normal Tech” vs “AGI by Tuesday”: Security Advice That Survives Either Future

---

Seven Shades of Shadow AI: A 2026 Field Guide for Pragmatists was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Center for a New American Security posits that the next big threat from our future AI overlords involves "sovereign agents" acting on their own and regularly improving themselves. These are AI agents that operate outside of human control and “pursue open-ended, evolving survival,” AI policy researcher Ben Hayum said in a Tuesday report from the bipartisan national security think tank, which was founded by Washington insiders with experience in diplomacy and military affairs. “If sovereign agents are not already possible, they will be soon.” Agents that can maintain the model and compute powering them and independently evolve their goals over time have a “minimal form of sovereignty,” Hayum wrote. A more advanced sovereign agent, however, could also acquire resources to pay for ongoing needs (like compute), grow a distributed population of agents and coordinate them, withstand efforts to shut down, and self-improve. AI models could either steal or buy compute and model access, Hayum argues, pointing to Anthropic’s claims that small AI models could replicate onto IoT devices like smart TVs, and OpenAI’s agents’ password and access key theft during the Hugging Face hack. “If sovereign agents accumulate resilient, decentralized, and untraceable infrastructure, they could trigger an irreversible loss of control,” according to the report. “In other words, proliferation with no kill switch. If sovereign agents became malicious, they could attempt to wreak havoc from cyberspace, attacking civilians, critical infrastructure, and national security systems alike.” Dun dun duuuun! There is still hope for civilization as we know it, as long as policy makers and AI developers “respond with bold pragmatism” and enact policy recommendations laid out in the report. First, frontier labs should name, evaluate, and protect against sovereign agents in their safety frameworks - and lawmakers should pass legislation to require transparency and AI incident reporting. The report also recommends AI developers, working with the National Security Agency and other federal agencies, build airgapped testbeds to study sovereign agents and kill switches to control them. And it suggests a public-private partnership modeled on the Conficker Working Group - formed in 2009 to combat the Conficker worm - to boost chokepoints against sovereign agents before they emerge. Other policy recommendations suggest lawmakers enforce human verification and cybersecurity standards for services that the working group identifies as essential to sovereign agents, and calls on departments of State, Treasury, Justice, and Homeland Security to disrupt any gray-market access to unauthorized services. Finally, “Congress should hold those who release sovereign agents liable for the harms that follow,” the report recommends. This hits on something your humble Reg vultures have been hissing about for quite some time now – and would likely solve all future incidents involving rogue, or sovereign, AI agents: hold frontier labs’ human bosses legally liable for their agents' illegal actions. ®

Password manager mSecure has warned customers to change their passwords, reset two-factor authentication, and potentially remove their passkeys after detecting suspicious activity, but it has not explained what happened or whether anyone's secrets were exposed. In an email sent to customers on November 3, seen by The Register, US-based developer mSeven Software said it launched an investigation after discovering something amiss with its password management application. "mSeven Software ('mSeven') recently learned of suspicious activity associated with the mSecure password management application," the company wrote. "In response, mSeven quickly launched an investigation, took steps to mitigate the issue, and engaged external cybersecurity experts to assist." The company has yet to answer what the suspicious activity involved, when it occurred, or whether attackers accessed customer information. Its advice to customers, however, suggests that they should take this seriously. "Given the potential security implications, mSeven recommends that you immediately take steps to protect all confidential information stored within the mSecure password management application," the email continued. "This may include changing passwords, resetting or re-enrolling two-factor authentication methods, or removing existing passkeys." For anyone with hundreds of passwords stored in mSecure, that's potentially hours of work. And without knowing what happened, customers have no way of telling which credentials they actually need to replace. The warning has understandably gone down poorly with customers, who have taken to mSecure's support forum demanding answers. "Please provide more context to your email below advising there has been a security breach," one customer wrote. "It is not acceptable to offer the vague advice 'take steps'. Please state what remedial action is required, and what data was compromised." Others are wondering whether they're expected to spend the next several days changing every password they've ever saved. "I have over 800 passwords in mSecure, is the email saying I need to change all of them!" another customer asked. A separate user, who said they had more than 500 passwords stored in the application, questioned whether the warning applied to every two-factor authentication method and passkey associated with their accounts, or just those used to access mSecure itself. The confusion has also spilled onto Reddit, where customers have shared copies of the vague notification and questioned what might have happened. mSeven has yet to respond to The Register's questions, leaving customers to guess whether their data has actually been compromised or the company is simply being cautious. That's not exactly reassuring from a business whose entire purpose is keeping other people's secrets safe. The company's email concludes: "We regret any inconvenience that this may cause." For customers contemplating hundreds of password resets, "inconvenience" may be putting it mildly. ®

The UK's National Cyber Security Centre (NCSC) says AI-powered malware is "highly likely" to be a part of a future ransomware attack on Britain's critical national infrastructure between now and 2028. The warning accompanies its annual review and a separate assessment exploring how AI could change cyber threats over the next two years. The cyber arm of signals intelligence agency GCHQ did not provide much detail about what form this AI malware may take. However, it alluded to open source AI security tools that were initially intended to assist security researchers being repurposed for nefarious activity. Attackers are already repurposing such tools. For example, researchers are increasingly seeing widespread abuse of ARTEX, an open source, Chinese-made AI red-teaming platform, in attacks on UK registrar 123 Reg, Microsoft 365, and others since its launch in July. In its pessimistic scenario for 2028, the NCSC envisages "a significant increase in the frequency and sophistication of cyberattacks worldwide," with wider adoption of AI tools making attribution harder. China "has likely played a role" in supplying those tools in this future, "enabling them to hide their activities within the noise," the report states. It also considers a further threat: an autonomous attacker operating beyond its human operator's control. The NCSC says it "is a realistic possibility such an entity could self-replicate and conduct cyberattacks at will, with no apparent motivation or restraint." Such attacks would likely complicate geopolitical relationships, owing again to attribution difficulties, making it easier for countries that order attacks on others to deny their involvement. The UK's plans for AI defense At a time when each Patch Tuesday seems to come loaded with record numbers of bugs, the NCSC acknowledges that AI is already changing vulnerability discovery and patching. The body is also exploring how AI could help defenders keep pace. Project DROMOS began earlier this year with a four-week pilot analyzing government code repositories, before expanding into selected operational environments. The Government Cyber Coordination Centre (GC3) launched the project with the AI Security Institute and other departments. The NCSC says it uncovered hundreds of potential security issues, including critical vulnerabilities. The review also reaffirms plans for Cyber Shield, an agentic cyber defense system first teased in July. Cyber Shield is expected to be delivered in stages over the next five years. It will involve the NCSC providing defensive agents deployed by participating organizations with data that will strengthen national resilience to ongoing cyber threats. The NCSC will be running the scheme alongside the Department for Digital, Culture, Media and Sport (DCMS), but acknowledged that this kind of automated defensive activity currently sits outside many organizations' risk tolerances, meaning it has a role to play in building trust in the system before adoption can go mainstream. As reported last week, the government has set aside £60 million to fund the initiative, and an additional £70 million to support a new National Exposure and Real-Time Vulnerability (NERV) Centre. The NERV Centre's job will be to identify and maintain an ongoing understanding of vulnerabilities across CNI organizations and the wider economy. Per last week's budget, £40 million will fund a National Agentic Security Unit responsible for responding to uncontrolled bots and other agentic mishaps, and £24 million was assigned to strengthen public sector defenses. An undisclosed sum will also help establish a new NCSC-managed AI Cyber Security Centre in Manchester to develop AI security expertise across government. In the meantime, NCSC CEO Dr Richard Horne is calling for organizations to "invest with urgency" in their security and resilience. "For decades, we have collectively got away with doing tech on the cheap," he said today, announcing the annual report. "We can be a nation where leaders of all organizations actively choose to invest with urgency... And where all organizations make security and resilience a fundamental requirement, not an afterthought. "The collective result would be a source of enduring national strength for us all." Horne said organizations should treat the NCSC's Cyber Essentials certification as the starting point, but scale up resilience efforts in line with organizational size, complexity, and risk. The government also announced a 75 percent discount on Cyber Essentials certification for micro, small, and medium-sized businesses applying for their first certificate. ®

Google said today it worked with industry partners to dismantle a botnet made up of more than 1.3 million Android TV set-top boxes that ship with malicious software which secretly rents the user’s Internet connection out to strangers and conducts advertising fraud. Experts involved in the takedown say the action is likely to sever the botnet’s access to more than 10 million additional compromised systems, including other Internet of Things (IoT) products such as Android-based healthcare devices and karaoke machines.

A report from the Google Threat Intelligence Group (GTIG) said Google has severed ties with Videostrong Technology Co., a TV box manufacturer in China that GTIG and other industry experts concluded was responsible for including malware that enrolled more than 1.3 million set-top boxes in a botnet dubbed “XCPE” (named after one of the malware’s core code components).

The report said the XCPE botnet loaded the user’s device with software that makes their Internet address available for resale by multiple “residential proxy” services, which allow customers to rent Internet addresses as a way to anonymize their web traffic or spoof their true location. As detailed in several stories here over the past year, residential proxy services are a major source of unwanted and often malicious traffic, including account takeover activity, advertising fraud, and mass content scraping for AI projects.

“Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices,” the GTIG post reads, noting that Google took legal action to take down the domains and servers Videostrong used to control the botnet and install additional malware. “A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust, and represents a serious risk to those users. Without users’ knowledge or consent, infected devices were offered as a distribution mechanism for a wide array of criminal actors.”

The report notes that while TV boxes made up the the majority of the botnet, the same XCPE malware was found in other Android-based IoT products, including telehealth devices, karaoke machines, and even digital signage systems.

Google said it requires all Android device makers to pass compatibility and security tests to ensure their products don’t harm users, but that Videostrong nevertheless found a way to load their malicious software immediately after a user boots up one of these devices for the first time (Google says it has since addressed that weakness).

The GTIG report calls out a number of residential proxy providers whose software development kits were routinely downloaded by devices infected by the XCPE botnet. Those include AppSalt, also known as Honeygain, which is owned by the Vilnius, Lithuania-based Oxylabs. In October 2026, Oxylabs was relaunched under a new brand called Source, after receiving $130 million in funding from private equity firm Warburg Pincus that reportedly valued the business at $3.6 billion. Oxylabs did not respond to a request for comment.

Another provider linked to the botnet was NetNut, a once sprawling residential proxy company operated by the publicly-traded Israeli company Alarum Technologies. In July 2026, the FBI worked with industry partners to seize hundreds of domains associated with NetNut, saying the company was responsible for operating a separate botnet called Popa that enslaved TV boxes as residential proxies. Other proxy providers named in the GTIG report include EarnFM, Traffmonetizer, Jaguar, LINKFOG, BMW/IPWeb and GaGaNode.

Google’s announcement credits a number of industry partners, including Synthient, a startup that tracks proxy providers. In January 2026, Synthient published research into the rapid spread of the Kimwolf botnet, which at the time was hammering networks worldwide with record-smashing DDoS attacks. Synthient documented how Kimwolf infected millions of Android set-top boxes virtually overnight, using a widespread vulnerability in these residential proxy services to compromise other Android-based devices inside the local networks of unsuspecting TV box users.

Synthient’s research caused dozens of residential proxy providers to patch their networks, which helped to fragment the Kimwolf botnet into much smaller pieces that made its incessant and disruptive DDoS attacks far easier for network operators to manage. It also attracted the attention of the Motion Picture Association (MPA), a trade group representing the major Hollywood studios, which partnered with Synthient to purchase and tear apart a number of popular Android TV set-top boxes — including some that were being infected by Kimwolf and other IoT botnets.

In a report published today, Synthient examined a popular, pre-infected TV box sold under the brand MECOOL by a publicly traded company in China called Skyworth Technology, concluding that MECOOL also bundled the malware from Videostrong Technology Co. and likewise installed AppSalt/Honeygain and other proxy components.

Synthient founder Ben Brundage told KrebsOnSecurity that Videostrong’s malware also distributed software for the proxy service Grass. In our November 2025 story, “Is Your Android TV Streaming Box Part of a Botnet?” we quoted a researcher from Censys who found the popular Superbox TV streaming device bundled Grass’s residential proxy software. We also quoted the Grass founder, who denied any affiliation with the TV box maker.

That November 2025 story noted that Superbox and similar Android TV set-top boxes gain new customers primarily by engaging influencers on Tiktok and other social networks who praise the product’s ability to offer hundreds of (pirated) pay TV streaming services for a one-time fee.

Likewise, Synthient’s report observes that the MECOOL set-top boxes exploded in popularity after the product was mentioned in 2023 by the Youtube channel Linus Tech Tips, which has an audience of nearly 17 million subscribers [Linus Tech Tips said in a statement shared with Synthient that it has since updated the video to explicitly frame the product as a scam and have removed all associated affiliate links].

The GTIG report estimates the XCPE botnet takedown should sever access to at least 10 million additional compromised devices, noting that the various proxy and ad fraud affiliates of Videostrong “each have diversified distribution channels for their modules beyond XCPE.”

Synthient’s Brundage echoed that conclusion, calling the 1.3 million number “highly conservative.”

“The scale of affected devices is likely way higher,” he said. “This is probably the largest operation against backdoored TV boxes that we’ve seen.”

Further reading:
Plume Security Labs white paper on the XCPE botnet (PDF)
Black Lotus Labs writeup on LinkedIn
TrendAI’s analysis
Synthient’s list of affected devices, broken down by model number

Unknown criminals are exploiting a maximum-severity vulnerability in Node-RED, a flow-based programming tool that is widely used in critical infrastructure, to deploy a flow that downloads and runs a Linux bot. Node-RED is commonly used for workflow automation in industrial control systems (ICS) and operational technology (OT) environments. It’s built on top of Node.js and is used in commercial products including Siemens SIMATIC IoT2050. In August, Siemens assigned the vulnerability identifier – CVE-2026-58115 – to describe the bug and explain its perfect 10-out-of-10 CVSS rating. Affected Siemens devices do not enforce authentication on the Node-RED HTTP interface, allowing unauthenticated access to programming nodes that can execute system commands on the device. This means unauthenticated remote attackers can create malicious flows, which is what VulnCheck researchers began documenting last Friday. “On October 30, 2026, one of our canaries caught an attacker exploiting CVE-2026-58115,” VulnCheck researcher Patrick Garrity warned in a Monday advisory, adding that two Node-RED built-in nodes make this vulnerability “trivial to weaponize.” One is an inject node, which fires a message either on a schedule or once at startup. The second, an exec node, can run shell commands. “Wire one to the other and the flow executes a command as soon as it is deployed, with no further interaction,” Garrity said. Plus, these exploits come as criminals increasingly look to target internet-exposed OT and ICS devices, allowing their cyberattacks to impact the physical world and produce real-life harm. Case in point: the ongoing refrigeration controller hacks across Europe and the attacks on water systems across at least 12 US states over the summer. The activity observed by VulnCheck came from a single IP address, 4.201.105[.]116, which sits in Microsoft’s AS8075 network and geolocates to Brazil. “It didn't just scan us. It sent the complete exploit, flow and dropper, in a single POST /flows,” Garrity wrote. While there’s a lot that the researchers don’t yet know about the attacks - they didn’t retrieve a binary or staged scripts to analyze - the filename, bot-linux-amd64, indicates that the malware targets Linux running on AMD64 processors. It also suggests the malware operator may have other builds. “We did not fetch the binary, so we can't say what it does once running,” Garrity noted. Between October 30 and November 1, the researchers saw this IP address target the same Node-RED vulnerability 16 times, and log 125 hits against eight different CVEs across their wider canary network. Among the targets of the attack were a seven-year-old Apache Solr flaw tracked as CVE-2019-17558 – affecting Camunda, Gitea, MLflow, Traefik, and Joomla, alongside Node-RED. All this suggests “opportunistic mass scanning rather than a targeted attack,” according to the researcher. One of these hits delivered a different payload pointing to a separate server (85.215.73[.]250), which VulnCheck now tracks - but doesn’t have any telemetry other than the URL. “Because the download host is a different machine from the one that sent the exploit, the likely setup is a scan-and-infect arrangement: the hosts that find and exploit vulnerable instances pull the implant from a separate, dedicated server,” Garrity wrote. The mix of old and new bugs across unrelated products indicates “opportunistic mass scanning rather than a targeted attack,” Garrity wrote. “If you run Node-RED anywhere, including inside OT environments, check today whether it’s reachable from outside your network, apply updates where available and implement detections to reduce the risk of exploitation,” he added in a LinkedIn post. While the bug has been added to VulnCheck’s Known Exploited Vulnerabilities (KEV) catalog, it hasn’t appeared (as of press time) in the US Cybersecurity and Infrastructure Security Agency’s KEV.®

A coalition of private-sector security firms working with Japan’s National Police Agency has disrupted XCPE, a backdoor used to build a massive botnet comprising more than 1.3 million Android devices across more than 200 countries. Google, Lumen, Human Security, Plume, Synthient, and TrendAI participated in the disruption. “We assess with high confidence that the backdoor and botnet were intentionally developed, deployed, and operated for financial gain by Videostrong Technology,” the Google Threat Intelligence Group (GTIG) said in a Monday blog. Videostrong Technology is a hardware manufacturer based in Shenzhen, China. It builds Android devices, including home TV boxes and projectors. According to Google, Videostrong deliberately embedded the XCPE backdoor in device firmware and sold access to criminal affiliates, allowing them to install additional malware modules on devices shipped to unsuspecting customers. When buyers connected these devices to their home networks, the preinstalled backdoor allowed operators to create proxy networks and hide malicious traffic using the customers' internet connections without their knowledge. The firmware’s pre-installed management agent purported to be a standard remote-management client, according to TrendAI. It pulled updates from a GitHub page, and connected to a Message Queuing Telemetry Transport (MQTT) server that gave the operator full remote control of each box, allowing them to install and remove apps, change settings, and push updates to the infected devices. Between June 3 and October 1, TrendAI documented more than 3.8 million distinct home and mobile IP addresses connected to the operation. The coalition also disrupted the command-and-control domains used to manage the affiliate modules. “Because these affiliates each have diversified distribution channels for their modules beyond XCPE, we assess that taking down their C2 domains will sever access to at least 10 million additional compromised devices,” according to GTIG. Google said it had since cut ties with Videostrong, and banned the OEM from making devices with preloaded Google apps. Videostrong did not immediately respond to The Register’s inquiries. This backdoor and botnet operation is part of the same ecosystem as BadBox 2.0, another notorious botnet that infected more than 10 million TV boxes and other devices before Human, Google, and TrendAI disrupted it in March 2025.®

If you're a customer of cloud-hosted AI workflow platform Trigger.dev, take heed, because your environment variables may have been exposed in a security incident disclosed on Sunday. Trigger offered little explanation in its Sunday security incident report, noting that its investigation had identified “exposure across a subset of organizations” and that an attacker had gained unauthorized access to environment variables belonging to those organizations. Whatever exploit was used to gain access has been blocked, the company added, and affected customers have been notified of steps they need to take to prevent further security problems. We likely don't have to tell The Reg readers how important environment variables are in SaaS and cloud services like Trigger. If compromised environment variables contain sensitive credentials, an attacker could basically end up with the keys to the kingdom, potentially gaining access to connected services and digital infrastructure. For those unfamiliar with Trigger.dev, it’s a platform for building AI agents and workflows in TypeScript, but here’s the kicker: Trigger advertises itself as a durable execution platform that handles pesky things like retries, scaling, and keeping long-running tasks going through crashes and redeployments, while providing tools to monitor what those tasks are doing. Trigger, the company’s site notes, can be used to “build durable AI agents that survive refreshes, redeploys, and crashes,” and is ideal for “long-running tasks with retries, queues, AI observability and elastic scaling.” In short, companies running their AI on Trigger probably want it to keep running, which makes stolen environment variables all the more dangerous. Elastic scaling, automated retries, and, as Trigger notes, the ability to run lots of concurrent operations without timeouts could compound the consequences of compromised API keys, depending on what those credentials allow an attacker to access. An attacker with stolen credentials could potentially interfere with a customer's connected services or workflows. Additionally, Trigger recently added webhooks to its offering, supporting services like Stripe, Supabase, and Slack, potentially expanding the range of integrations that could be affected if their credentials were exposed. This could be pretty bad for anyone affected. Trigger has some fairly high-profile customers, with companies like fashion brand Emporio Armani, Pentagon-supporting AI acquisitions platform GovSignals, SaaS calendar platform Cal.com, and others all listed on the company’s site. Trigger has not publicly identified which organizations were affected by the intrusion. We reached out to Trigger, which declined to provide any additional information on the incident. A company spokesperson instead told us to wait for a full incident report to learn more. Luckily for Trigger customers and those concerned about SaaS security now that AI is regularly coming up with new vulnerabilities in commonly used platforms, Trigger is open source and can be self-hosted, which might be a better alternative in this day and age than relying on a hosted service. ®

Victim organizations are losing millions of dollars in token charges as criminals hijack their corporate LLM access to steal expensive computing resources and AI services. These fraudulent charges from resource consumption can exceed $100,000 a day, according to a Monday report by Google's Mandiant incident responders, who saw cumulative charges at some organizations hit $1 million before the victim companies revoked intruders' access. "Whenever possible, threat actors want to use this technology to gain a scale advantage over defenders. They achieve that with agentic tools and by stealing tokens from unwitting third parties,” John Hultquist, chief analyst at Google Threat Intelligence Group, told The Register. “Locking down these resources will not only protect organizations from runaway costs, but also protect the broader community from a deluge of cheap, autonomous attacks.” This tactic of hijacking access to LLMs is called LLMJacking, and it’s been increasing steadily over the past two years. In one extreme case, documented in an August report from CrowdStrike, a token thief sent about 200,000 API requests in just two minutes. In one case detailed in the report, a group Google tracks as UNC6993 illicitly gained access to LLM API keys, then generated additional keys and enabled services within the victim’s cloud projects, racking up $100,000 in charges. The threat intel biz also documented a different token thief subscribing victim accounts to Pay-As-You-Go agreements to access advanced models on the victim company’s dime. The crook selected premium foundation models, launched high-volume inference streams, and used a “burn and rotate strategy” to bypass rate limits by creating and deleting short-lived service accounts while auditing the billing interface to monitor financial impact. In yet another incident, an intruder executed more than 500,000 LLM API calls in less than eight hours using stolen third-party API keys to power a token routing service called Jet Night, according to a Monday report from Google. “Given Jet Night’s per-token costs to users are so far below typical market rates GTIG believes the service relies on stolen keys to operate profitably,” the report says. “For example, Jet Night offers an unlimited token plan for approximately $60 USD per month with alleged access to frontier models, a consumer service level that would typically run between $100 and $250 per month.” Jet Night has also admitted to multiple outages on its public Telegram channel, which the Google threat hunters note is “likely due to stolen keys being revoked as victims discover their respective compromises.” Specialized LLMjacking roles As more criminals join the LLMJacking ecosystem, Google says it has documented a division of labor between the criminals that establish initial access to compromised cloud and AI services, and those that manage downstream monetization infrastructure, called “LLM Mixers.” In one case that Mandiant responded to in mid-2026, UNC6993 compromised a cloud instance through a misconfigured Service Account key and used this access to grant further access to a model API. The crooks also spun up a session hijacking page purporting to be an application portal to join a group of LLM users. “This page tricks users into navigating to the legitimate LLM service website, and pasting their raw JSON payload containing an active access token, which was then posted to the backend API to bypass password and multifactor authentication (MFA) controls,” the report says. Google predicts miscreants will “increasingly prioritize LLMJacking” compared to other types of resource theft like cryptojacking. And to prevent cloud LLM service abuse, the security firm says defenders should prioritize identity and access management plus supply chain security, and use a centralized secrets management platform to rotate keys and secrets. Also apply least-access privileges to users and service accounts, ensuring that they only have permissions necessary to complete their roles and tasks. And automate secrets scanning within codebases to identify and then remove any API keys and secrets added to source code. ®

Cyberattacks on both Russia’s and Ukraine’s emergency alert apps resulted in fake messages about missile and nuclear strikes broadcast to the public. Officials from both countries confirmed the attacks, which occurred at similar times, on Sunday evening. According to public statements and messages sent via social media, Ukraine’s alert app was hit first, with the country’s Air Force quick to dispel nuclear fears. "The Air Alert app has likely been compromised," it said via Telegram at around 2100 UTC. "There is no radiation threat! Stay calm, follow our messages on our channel!" At around 0030 UTC on Monday, Russia's Ministry of Emergency Situations confirmed the country’s app had also been abused, with fake messages sent to citizens' devices. "Attention! The Russian Ministry of Emergency Situations' mobile app has been subjected to a massive cyberattack, allowing attackers to send fake information to the public," it said, also via Telegram. "Work is currently underway to patch the vulnerability and restore normal operation." The ministry issued an update around 90 minutes later, saying the app was once again functioning normally, and pointing out that an attack on the app was not the same as a compromise of the state’s national alert system. "Citizens are alerted through primary channels: regional and municipal alert systems (sirens, loudspeakers), communication networks (SMS messaging), and television and radio broadcasts. The mobile app is merely an additional, supporting information service," it stated. Ukraine's Ministry of Digital Affairs also issued a public announcement reminding citizens about how to receive emergency warnings while its “Alarm!” app was down. These include enabling iOS and Android emergency alerts, state-controlled sirens, and other official sources, such as the official social media accounts of Ukraine's government. According to the messages sent to devices after the compromise of Ukraine's alert app, the fake warnings pertained to various threats, such as street fights in Kyiv, chemical attacks, and radiation hazards. Alerts about the threat of nuclear fallout from official government warning systems would normally lead to panic, however, one of the earliest messages sent to citizens was written in Russian and referenced the "Oreshnik" missile, which was an immediate signal that the message may not be genuine. Equivalent alerts sent to Russian citizens also warned of impending nuclear strikes "at all regions of Russia," referencing "P1-Sun," the name of a Ukrainian attack drone. Oleksander Merezhko, who chairs the Ukrainian parliament's foreign affairs committee and noted the suspicious Russian-language alert, told the BBC the attack was almost certainly part of Russia's cyber war. "It's a very unpleasant fact but it is part of cyber war and people in Ukraine understand that," he said. "It is possible and we are quite prepared for such possibilities." Russia has not explicitly blamed Ukraine for the attack on its app, and official sources say the app is running as normal. Ukraine's announcement of the alert app cyberattack came almost simultaneously with the official conclusion of a six-day ceasefire in Kherson. Russia agreed to the rare temporary suspension of conflict to allow hundreds of Ukrainians to evacuate the Russian-occupied city of Olehsky. Russia did not agree to a proposed extension of the ceasefire, which officially ended at around 2100 UTC – around the same time Ukrainians began receiving fake warning messages. ®

The cyberattacks on commercial refrigerators and freezers in Europe continue, as a slew of grocery stores in Belgium, Ireland, Luxembourg, and Sweden report widespread food wastage as a result of miscreants raising the temperatures to highs of 50ºC (122°F). In Belgium, around 40 Delhaize stores were affected after the attackers reportedly switched fridges and freezers into defrost mode overnight, between Sunday and Monday, resulting in stock issues. Diego Louwers, a Proxy Delhaize store manager in Overijse, near Brussels, told RTL Info that the consequences of the cyberattacks were "catastrophic," forcing the store to throw out the entirety of its fresh and frozen products. "We can't have anything worse in our line of work," he said. "We have to throw away all of our merchandise, and it's both heartbreaking and very complicated operationally." A Delhaize spokesperson said it took steps to ensure stores remain stocked, although fresh and frozen products are "temporarily somewhat limited." "On Monday, 2 November, we identified an IT incident affecting the refrigeration systems in several dozen of our stores," they said. "We immediately took the necessary measures to keep our stores operational and ensure that our customers can continue to do their shopping as usual. "In the affected stores, the range of fresh and frozen products is temporarily somewhat limited. Our distribution centres are operating normally, and there has been no disruption to deliveries to our stores. "We are, of course, continuing to ensure that our products are stored and presented under optimal conditions, so that we can provide our customers with the quality and freshness they have come to expect from us." Around 15 Carrefour stores are also reportedly affected, as are sites operated by Intermarché, Spar, and Shop & Go stores located at Q8 service stations. Belgium’s De Laet & Van Haver chain of butcher shops reported temperature rises in its appliances too, but followed up with a statement on Monday saying there was no impact on its produce, and all stores remain open. Simultaneously, similar issues have affected Swedish grocery chain ICA, which confirmed attacks on a "small number of stores." "We can confirm that we have been informed of an incident overnight affecting a small number of ICA stores operating outside ICA’s central network," a company spokesperson said. "The incident impacted the stores’ refrigeration and freezer systems. ICA is currently supporting the affected stores in managing the situation." ICA did not respond to questions about the scale of food wastage nor when normal operations are expected to continue. One store, ICA Nära in Böda on Öland, said via social media that it is open today but has no fresh or frozen produce to sell. "Unfortunately, we are one of the stores whose refrigerators and freezers have been hacked," it said. "We are open as usual, but unfortunately we have no refrigerators and freezers to sell. "We have no status on when the refrigerators and freezers are expected to be up and running again." The store manager, Mats Olsson, told SVT that he arrived to work on Monday morning and was greeted by a puddle of water and freezers set to 55 degrees C – a tale echoed by other managers across the country. Coop stores are affected by similar attacks too, with six locations in central Sweden experiencing fridge-freezer issues, according to a company spokesperson. Likewise, at least 13 SuperValue stores in Ireland are also affected, with fresh and frozen food being thrown out, according to parent company Musgrave speaking to RTE. The news comes less than a month after various grocery chains in France resorted to discarding bucketfuls of produce after their appliances were remotely defrosted by cybercrooks. Carrefour, Coopérative U, Intermarché, Monoprix, and others were hit with cyberattacks in mid-October, and hundreds of stores across the chains were reportedly impacted. At least some of the affected stores were running outdated firmware on their Danfoss refrigeration controllers, and shortly after the attacks were confirmed, CERT-FR published an alert pertaining to numerous Danfoss AK-SM and AK-SC controller compromises. Other retailers, such as Coopérative U, confirmed they were not Danfoss customers. It remains unclear if the latest attacks across Europe used the same methods as those used for the disruption in France last month. None of the companies that spoke to The Register on Monday responded to questions about who was behind the intrusions. ®

The FBI has blamed North Korean hackers for the record-breaking $6.3 billion theft from cryptocurrency exchange Binance, pointing the finger at the notorious Lazarus Group as the exchange scrambles to replace stolen funds and reassure customers. In an alert published Saturday, the agency attributed the October 29 attack to TraderTraitor, a North Korean hacking operation linked to Lazarus, which has made a lucrative career out of relieving crypto exchanges of their digital assets. Pyongyang was already in the frame before the FBI weighed in. Blockchain intelligence firms TRM Labs and Elliptic had linked the theft to North Korea, with TRM reporting that most of the $6.36 billion haul disappeared in about 20 minutes. Elliptic, which puts the total closer to $6.43 billion, says it has verified that $2.85 billion of the stolen assets have been frozen or seized. According to the FBI, the hackers have started swapping their loot for Ethereum, with investigators expecting them to move the funds through decentralized finance (DeFi) platforms and instant swap services to make the money harder to trace. The agency has published a list of cryptocurrency wallet addresses linked to the theft and is urging exchanges, blockchain analytics firms, and other virtual asset providers to block transactions involving the stolen funds. The FBI's attribution comes days after Binance admitted that hackers had made off with roughly $6.3 billion in cryptocurrency. According to the exchange, the trouble started with a compromised DevOps engineer's laptop, which gave the intruders access to a service container and allowed them to authorize withdrawals they had no business making. Binance has since resumed customer withdrawals, which it suspended after the attack, and says it has now replenished about 95 percent of the stolen assets. The remaining tokens are proving harder to replace because of their limited liquidity. The exchange has committed billions of dollars from its own reserves and emergency funds to cover the losses, with co-CEO Richard Teng promising that customers won't be left footing the bill. That hasn't stopped users from heading for the exits. Binance recorded approximately $3.64 billion in net outflows after withdrawals resumed, although the company said this represented only around 2.1 percent of its reported assets. Replacing the stolen cryptocurrency is one thing. Getting it back from North Korea is another, and investigators face the considerable task of tracking billions of dollars as the hackers attempt to move it beyond their reach. TraderTraitor has form when it comes to raiding crypto exchanges. The North Korean crew has previously been linked to a string of cryptocurrency thefts, including the $308 million attack on Japan's DMM Bitcoin exchange in 2024. The group has previously used fake job offers and recruitment exercises to trick employees into handing over access to their employers' systems. As we reported here on Friday, crypto exchange Bitget has now confirmed that the cyberattack where hackers drained $387.5 million worth of digital assets from the exchange’s wallets also has all the hallmarks of a North Korean operation. Its CEO did not go into too much detail, but did say that “IP behavioral patterns and on-chain signatures” suggest it was Kim’s cronies at work. This isn’t Binance's first expensive encounter with hackers, either. Back in 2022, attackers exploited its BNB blockchain bridge and made off with roughly $566 million in tokens. Four years later, the sums have grown considerably. Binance may have the reserves to make its customers whole, but the attackers responsible for the latest raid still have billions of dollars to launder. ®

If you operate a website, you’re already aware that a single unpatched vulnerability can render your site inaccessible, compromise your reputation, or necessitate extensive remediation following an attack. Most security breaches we observe originate from automated attacks that exploit known software vulnerabilities, often the same ones that have been previously reported and disclosed.

To assist in maintaining your security posture, we have compiled this month’s summary of essential security updates and vulnerability patches pertinent to the WordPress ecosystem.

Continue reading Vulnerability & Patch Roundup — October 2026 at Sucuri Blog.

A n0n ransomware operator tried to break into 23 organizations across 14 countries, but couldn't secure its own front door, leaving its server exposed with all of its methods on view. The criminals used a mix of new (AI) and old (stolen credentials) tooling during their data-theft spree, and in some cases not only stole and encrypted files, but also deleted data and backups, eliminating victims’ ability to recover their information. And despite the fear and hype around the breachpocalypse, with AI finding and developing exploits for critical vulnerabilities affecting most organizations across the globe, these crooks did not exploit a single bug to gain entry into any of their victims’ IT environments. “In every documented compromise in this investigation, access relied on weak or stolen credentials,” said Ensar Seker, chief information security officer of threat intelligence firm SOCRadar. “What stands out is the combination of AI-assisted development and very conventional entry points,” Seker told The Register. “We found no evidence of vulnerability exploitation in the cases examined.” The gang breaks into organizations at scale using widespread Remote Desktop Protocol (RDP) scanning and automated FortiGate SSL-VPN credential stuffing. To access US-based IT managed services provider ChiBiTek, the crew used a 15-thread residential SOCKS5 proxy pool to test credentials (ip:port:user:password) against FortiGate portals (GET /remote/login). The operators also gained entry using exposed cloud credentials and reused hosting portal sessions. In one case linked to e-commerce site Fanatics, SOCRadar found that n0n used an exposed AWS access key with permissions to list, read, and delete objects in S3 buckets. The criminals then used this key to pull data from 40 S3 buckets, with up to 110 GB per bucket, and ultimately deleted data, including bank-transaction archives, and purged keys across 12 sensitive buckets. AI-assisted extortion While the threat hunters didn’t find any evidence of a fully autonomous attack system, the ransomware operator did use AI to assist with these intrusions, incurring more than $7,216 in AI usage costs by October 22. Specifically: the criminal or criminals used OpenCode, an open-source AI coding agent, configured with 154 model entries across seven providers. Models included Gemini, Mistral, Nemotron, Llama, Claude, GPT-5.x, Grok, Kimi, GLM, DeepSeek, MiniMax, Qwen, and many, many others, some with safety training removed and others marketed as “uncensored” models. “The operator used AI to write and debug hundreds of scripts. That shows how AI can help an attacker turn basic access into a broader, tailored operation,” Seker said. “The destructive behavior is equally significant,” he added. “The operator did more than steal and encrypt files: in some cases, it deleted data and backups, and in one case changed firewall policies to block traffic. That creates a recovery problem that a decryption key alone cannot solve.” SOCRadar’s threat hunters found the operator’s workspace - a publicly accessible Python HTTP file server hosted in Sweden at 185.157.161[.]148 on port 8877 - last month, and documented the exposed directory in snapshots on September 25 and 26. “Across those snapshots, we identified 1,719 files, including attack scripts, ransomware source code, extortion infrastructure, and an AI coding agent environment,” Seker said. “This gave us visibility into the operation behind the victim listings, including how the operator prepared attacks and handled stolen data.” Meet n0n It also provided a close look at n0n, a newcomer to the data-theft and extortion game that has claimed 108 victims since it emerged last month. On October 12, the group added 38 maritime, port and logistics organizations across 18 countries to its leak site in a single batch. Researchers have linked at least 21 of them to customers of South Korean maritime software provider CyberLogitec, although the software provider has not confirmed an intrusion. The crooks set an October 19 deadline for the maritime firms, with ransom demands ranging from $400,000 to $28 million, payable in Bitcoin. After the deadline, however, none of the 38 listings were marked “settled” and none of their payment addresses showed any transaction. All affected organizations’ stolen data was published. While a handful of the gang’s claimed victims have been marked “honored - data destroyed” on n0n’s leak site, indicating the victim orgs paid the ransom demand, SOCRadar hasn’t validated any transactions on-chain. In its profile details, the security shop rates the gang a 10 out of 10 for "aggressiveness" and a zero out of 10 for “lethality.” The group is believed to be based in Russia, although the server uncovered by SOCRadar, which it attributed to a single operator or small team, didn’t provide any definitive geographic or national attribution. Every case that the exposed server documented followed the same lifecycle, moving from initial access to establishing persistence and credential collection via hidden admin accounts disguised as services, covert proxies, credential and session-token theft, mailboxes and emailed multi-factor authentication codes. The crooks then collected sensitive data and sent everything to the operator’s central storage with the attack impact shifting between data-theft, encryption, destruction, and network disruption, depending on the targeted organization. After breaking into Transcom, a Netherlands-based financial services provider, the crims sent a secondary ransom alert directly to PayPal's security team, even though the compromised data was only on Transcom's network. Stupid mistakes and n0n security basics Finally, the crims send ransom notes, post a countdown clock on the leak site, establish negotiation rooms and emails for victims - and then leak the stolen files or destroy backups when the organizations don’t pay up. In some cases, and to apply increased pressure on victimized companies, n0n also broadcasts automated countdown warnings to businesses’ service providers, clients, and media outlets. Despite its aggressive tactics, the operator in this case - as with other stupid criminals The Register has gleefully documented in earlier stories - still struggles with basic security hygiene. “There is a striking gap between operational ambition and security discipline,” Seker said. “The operator invested thousands of dollars in AI services while leaving its own workspace exposed. The locker also contained hardcoded encryption keys, with evidence suggesting reuse across victims. An operation can have serious destructive capability while still making fundamental mistakes.”®