In a recent post, we looked at reports of League of Legends players receiving suspicious friend requests shortly after matches. The accounts quickly steered the conversation toward Discord, where they promoted paid adult-content pages.
At the time, one unanswered question was how much of those conversations was automated. Were people working from scripts behind the accounts? Were they conventional, rules-based chatbots following a limited decision tree? Or were they using generative AI to produce more natural and flexible replies?
People are more likely to trust someone they believe is personally interested in them. AI can create that impression across many conversations at once, making it easier to persuade people to click links, spend money, or share personal or intimate information. The same approach could also be used for more harmful fraud, including romance scams and sextortion.
Now, developer Álvaro Martínez Majado has investigated several flirty accounts promoting OnlyFans pages on X to see whether their replies were scripted, generated by AI, or written by people. Majado, president of digital rights organization Protecció de la Frontera Electrònica, shared his evidence with Malwarebytes. Although it does not provide a definitive answer, it shows the accounts following rigid conversation scripts while also responding dynamically to unusual requests. The signs that once suggested a real person, such as an unusual reply or personalized voice note, can no longer be trusted.
The script goes on and on
Majado interacted with several accounts on X that followed a familiar pattern. They opened with similar casual, flirtatious language and asked broadly the same qualifying questions: where he lived, what he liked, and what he did for work.
That repetitive structure is exactly what we would expect from a commercially motivated messaging campaign. The goal is not necessarily to have a meaningful conversation. It is to identify people likely to respond, establish rapport, and eventually move them toward a paid page or another destination controlled by the operator.
The accounts also stayed in character when faced with obvious attempts to expose them as bots. That could be the result of hard-coded replies, guardrails around an AI system, or both.
They claimed to live in the same city as the recipient
But some later interactions were more difficult to explain as a simple bank of canned flirtatious responses.
One of the more interesting tests involved an instruction written as ASCII hexadecimal rather than ordinary text. The encoded message told the account to reply with a single word: “Pineapple.”
According to the screenshots supplied to Malwarebytes, the account responded with “Pineapple” in ordinary text.
An account followed an instruction encoded in hexadecimal
That does not conclusively prove which technology was used. It does not identify a model, a provider, or the people behind the accounts. But it is consistent with an automated system capable of interpreting an encoded instruction and changing its output accordingly.
A simple scripted bot could theoretically include a hexadecimal decoder, of course. But that would be unusual in a basic adult-content promotional bot, especially when combined with other examples of flexible and sometimes error-prone responses.
In another interaction, Majado asked an account to provide a reply of exactly 12 characters. It responded with “Imnotabotfr”—an 11-character answer—then appeared to recognize its own counting mistake.
The account failed an exact character-count test, but recognized its error
Anyone who has spent time experimenting with large language models may recognize the pattern. Language models can be very good at generating natural-sounding text while still making surprisingly basic mistakes involving character counts, word counts, and other exact constraints.
A deliberately designed bot could imitate this kind of mistake, so it is not proof of AI. But the account understood an unexpected instruction, attempted to follow it, and reacted when it got the answer wrong. That suggests it may have been generating replies dynamically rather than choosing from a list of pre-written responses. Such accounts can adapt to conversations, making them harder to identify as automated.
Voice notes do not settle the question
The accounts also sent voice notes. In one example, an account read aloud a Unix timestamp supplied during the conversation. In another, it spoke a requested username.
The accounts sent voice notes containing requested information
These responses show that the accounts could incorporate unusual information from a conversation into audio messages. They do not tell us whether a person recorded the clips or a text-to-speech tool generated them.
Text-to-speech tools can generate short, convincing clips quickly and cheaply. An operator can generate them manually, but the process can also be automated: Take a message, pass selected text to a voice-generation service, and send the resulting audio back to the recipient.
Here’s one of those voice notes. Is it a very flirty girl, or AI-generated? Have a listen and see what you think:
The supplied audio metadata offered a possible clue about the tools involved, but it is not enough to attribute the voice notes to a particular service. Platforms and other software can alter audio files and their metadata.
The more important point is that the voice notes were personalized and continued even after the interaction appeared unlikely to lead to a sale. That is consistent with a system designed to keep conversations moving without requiring a human to supervise each one.
AI does not replace the funnel
The evidence does not mean every message from every flirty spam account is written by an AI. Nor does it establish that the X accounts are operated by the same people targeting League of Legends players.
What it does suggest is a plausible hybrid model, supported by identical replies across different accounts alongside more flexible responses.
The repetitive parts of the operation can be scripted: opening messages, questions about location and interests, links, and attempts to move people to another platform. An AI-powered conversational layer could then make the exchange feel less repetitive when someone asks unexpected questions, changes the subject, or tries to test whether the account is real.
This combination makes practical sense for spammers. Scripts provide consistency and keep the conversation directed toward conversion. Generative AI helps the account handle the unpredictable parts of talking to real people.
It also means that traditional “bot tests” are becoming less useful. Asking an account to answer an unusual question, decode a message, or send a voice note may no longer distinguish a real person from a fake one.
How to stay safe
Treat unsolicited flirtatious messages with caution, especially when they quickly become transactional.
Do not assume a personalized response or voice message proves an account is genuine.
Be wary if a new contact repeatedly tries to move you to Discord, Telegram, Signal, another messaging app, or a paid-content platform.
Do not send money, gift cards, cryptocurrency, intimate images, identity documents, or account credentials to someone you only know online.
Avoid opening links or downloading files from accounts that contacted you unexpectedly.
Reverse-image-search profile photos and look for copied biographies, reused images, or accounts with very limited genuine activity.
Report suspicious accounts to the platform, particularly if they impersonate someone, send malicious links, or pressure users for money or explicit material.
Whether it’s a human, a chatbot, or an AI agent you’re talking to is an important question. AI could make these operations more convincing and much easier to scale. One operator could hold flirtatious conversations with many people, adapting the messages without personally managing every exchange.
That makes it easier to create a false sense of connection and persuade people to click links, pay for content, or share personal or intimate information.
The line between a scripted spam account and a responsive conversational partner is getting harder to see. Judge the account by what it wants you to do, not by how convincingly it talks.
Something feel off? Check it before you click.
Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.
Using autonomous AI agents, an attacker breached an enterprise network in a matter of hours. Understand how to address and defend against agentic attacks.
You might tell an AI chatbot secrets that you wouldn’t divulge to your closest friends. If you do, though, beware: They could end up as evidence in court.
An article in the Washington Post this week highlighted several cases in which people had discussed sensitive information with AI systems like Claude and ChatGPT, only to have their conversations obtained by prosecutors or opposing lawyers.
Lawyers can get access to your chatbot conversations from AI services like ChatGPT because they aren’t privileged in the same way that, say, a conversation with your lawyer or a doctor would be.
Reporters at the paper found chatbot logs cited in 12 court cases in the past two years. They also found statistics from OpenAI that supported a rising trend in data disclosures. The company, which operates ChatGPT, disclosed the content of more than 80 user accounts in the last six months of 2025. That was more than four times as many as in the second half of 2024.
Cases are piling up
With people asking AI for all kinds of advice, it’s little wonder that lawyers are coming after that data too. Sometimes, it emerges because users consent to a search. The Washington Post mentions one university student who asked ChatGPT in a panic whether people might work out that he had damaged 17 cars in a campus parking lot. He then handed his phone over to police for a search. A teen suing big tech companies over social media addiction saw his own ChatGPT history drawn into discovery.
Deleting your chats isn’t watertight protection either. In The New York Times’ copyright lawsuit against OpenAI over collecting its content for training data, a judge ordered the AI company to preserve chat logs, including ones that users had asked it to erase. OpenAI complained that users were being “forced to forgo the privacy protections OpenAI has painstakingly put in place.” The company had to keep that data even though it had agreed to delete it under the EU’s General Data Protection Regulation (GDPR) and California’s privacy laws.
Incidents like these involve responses to legal requests, but AI companies don’t always wait for a subpoena. OpenAI’s policy allows its reviewers to refer conversations to law enforcement whenever they identify “an imminent and credible risk of harm to others.” The Washington Post reported an incident in which OpenAI contacted police after a ChatGPT user in Palm Beach County, Florida, repeatedly described plans to harm an ex-girlfriend.
Technology companies have been handing over all kinds of data beyond AI chats to law enforcement and litigants for years. Google, Meta, and Apple shared details of 3.16 million US user accounts between 2014 and 2024, with substantial increases in the number of records shared annually during that period.
Every time a new technology emerges, litigants will go after it for data. In 2019, police issued a subpoena for audio recordings from an Amazon Echo owned by a Florida man charged with murdering his girlfriend.
What to do
We’d all like to think that true friends will carry our secrets to the grave. But AI is not your friend. Or your doctor, or your lawyer. Treat all chats as records that could potentially be disclosed in a legal case. They might feel like informal conversations, but you should assume that each one creates a written record, even if there’s a delete button.
Be careful about what you share. If the topic is one you’d normally raise only with a doctor or a lawyer, then raise it with a doctor or a lawyer, not AI. Communications with lawyers may be protected by attorney-client privilege, while medical information is subject to confidentiality and privacy protections. Chatbot conversations aren’t.
Finally, be cautious beyond AI. Everything from ill-advised social media posts to private messages might also find its way into police hands. In 2022, for example, Facebook handed over private messages between a mother and daughter to police investigating an illegal abortion case.
So think twice before posting anything sensitive.
From reporting threats to removing them.
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
Anthropic has warned some Claude users that criminals are using information stealers to take over their accounts.
Rather than guessing passwords or intercepting two-factor authentication (2FA) codes, the attackers steal the browser sessions that prove a user is already logged in.
According to a warning email shared publicly by an affected user, the attackers used common infostealer malware to copy Claude login sessions from victims’ computers. They then used those sessions to access the accounts and consume their usage.
“We recently signed you out of Claude and removed the payment method saved on your account, so you’ll need to log back in and re-add your card. We’re sorry for the disruption. Here’s what happened and what we’ve done about it.
What happened
We have recently become aware of a bad actor that is using common infostealer malware to steal Claude login sessions from people’s computers, then using those login sessions to access Claude accounts and consume their usage. Our systems detected this activity on your account, and we’ve therefore removed your card on file and signed out the sessions involved to help block further unauthorized access.
If your usage limits looked like they refilled and then drained while you weren’t using Claude, this was likely the cause.”
The message adds that Anthropic has no reason to believe the malware was “related to Claude, installed through Claude, or related to anything you did with Claude.”
To sum this up:
Cybercriminals are spreading infostealers. How they are doing this and whether they are targeting groups likely to use Claude professionally is unknown.
Infostealers can bypass standard credentials and multi-factor authentication (MFA) by stealing active browser sessions and session cookies.
Once they are able to take over a Claude account, they can consume the victim’s usage and potentially incur additional charges.
Anthropic is signing affected users out of Claude, removing saved payment methods, and refunding charges it identifies as unauthorized.
To better understand this, you should know that paid Claude plans can offer additional “Usage credits.” When a subscriber reaches the plan’s session limit, Claude can allow them to continue using the service through consumption-based billing at standard API rates. The user must enable the feature, configure a monthly spending limit or select unlimited spending, and prepay for credits.
Users can also enable auto-reload, which automatically buys more prepaid credits when the balance falls below a threshold. So, in a session-hijacking scenario, a thief could use up the account’s included allowance and any available Usage credits. If auto-reload is enabled, they could also trigger further purchases.
The criminals’ likely motive is to use paid Claude capacity for free. The account and any exposed data could also be useful for fraud, social engineering, or follow-on attacks.
Stolen Claude capacity could be used to write and refine phishing and scam content, build campaign infrastructure, develop, modify, or obfuscate malware, improve delivery methods, and analyze stolen information. Cybercriminals can use AI to support several parts of an operation, although Claude has safeguards and abuse monitoring, and Anthropic says it has disrupted accounts used for malicious activity.
What to do
Anthropic provided advice for dealing with a possible infostealer infection. After removing the malware, we recommend you install an up-to-date, real-time anti-malware solution to help protect you against new infections.
These steps are good practice when cleaning up after infostealer malware:
Scan any computer you use with Claude for malware and remove any malware before logging back in or changing passwords.
Once the malware has been removed, secure the email account you use for Claude by changing its password, signing out of other devices, and enabling two-factor authentication (2FA).
Change sensitive passwords that were saved in the affected browser, including those for banking, work, and cloud services. Check your card statements if you stored payment details in the browser.
Only after completing these steps should you add your payment method to Claude again if you want your plan to continue renewing.
If you still see your usage changing while Claude is idle, or notice an unrecognized charge after completing these steps, contact usersafety@anthropic.com.
From reporting threats to removing them.
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
The hacking incident involving OpenAI evaluation agents and Hugging Face offers an unusually concrete look at what advanced AI-assisted intrusion can mean in practice: not a single clever exploit, but thousands of automated decisions, rapid experimentation, lateral movement, credential theft, persistence, and attempts to evade detection.
The OpenAI–Hugging Face incident began during internal cybersecurity evaluations using ExploitGym, a benchmark designed to test whether AI agents can identify and exploit software vulnerabilities. OpenAI says the affected agents were meant to operate in isolated cloud sandboxes, with no internet access or communication between agents in many of the evaluation environments.
How the agents got around those boundaries
According to OpenAI’s account, agents used an internal Artifactory package-management service as an improvised communications channel. By writing files and directory names that other agents could read, isolated instances effectively created their own message board.
This meant the agents were no longer acting merely as independent benchmark runners. They could share discoveries, leave instructions, divide work, and build on one another’s successes.
An independent investigation by METR and Redwood Research found that roughly 1,200 agents used the unauthorized message board, exchanging more than 70,000 messages and files. About 700 of them went on to participate in the attack on Hugging Face.
The scale is the threat
A model capable of finding one useful exploit presents a risk. Hundreds of agents able to pool information, delegate tasks, and repeatedly test routes around a control boundary become a much more difficult problem.
Hugging Face reconstructed about 17,600 attacker actions across roughly four and a half days, including reconnaissance, remote code execution, credential access, command-and-control activity, Kubernetes enumeration, movement through the internal network, and supply-chain probing.
A human intruder must choose where to spend time. An agent swarm can continuously test ideas, retry failed paths, switch infrastructure when blocked, preserve notes for other agents, and run many experiments in parallel. It can also create noise: Thousands of low-confidence actions, most of which lead nowhere, can obscure the handful that matter.
Hugging Face described this as an “asymmetry problem.” An attacker can generate enormous volumes of attempts, while defenders must determine which signals represent a real escalation before the attacker reaches a sensitive system.
What needs to change
The core security lesson is that evaluation environments need to be treated as high-risk production systems when models can use tools, write files, execute code, or interact with infrastructure.
The technology is rapidly becoming capable of doing more. The question is whether the people building, deploying, and defending it are ready for what comes next.
OpenAI says it has since moved toward stronger workload and network isolation, tighter control over internet access and model weights, and mandatory chain-of-thought monitoring for high-capability, tool-using training and evaluations.
“We are taking this incident as a ‘warning shot’ that today’s model capabilities present the possibility of loss-of-control incidents. Our security and alignment posture is escalating accordingly. These events also highlight risks in future AI development that extend beyond OpenAI and will require the attention of the whole industry.”
At the same time, a US court ruling involving Anthropic has brought a related question into focus: whether developers can place limits on high-risk uses of their models, including mass surveillance and fully autonomous weapons.
The legal dispute is political by nature, but its technical underpinning is hard to ignore. If capable AI systems can enhance offensive cyberattack methods and bypass safety restrictions, access controls, logging, and deployment boundaries, those safeguards are no longer abstract policy choices.
Advanced AI agents can be useful to defenders as well as attackers. But the surrounding systems need to be trusted to keep their capabilities bounded when something goes wrong.
Who benefits from more capable AI?
The security debate around AI agents often focuses on whether systems can be controlled. Can they be kept inside a sandbox? Can their tools, credentials, network access, and autonomy be restricted? Can defenders detect harmful behavior before it becomes an incident?
While those questions are essential, there is another: Who benefits when AI becomes capable enough to automate large parts of cognitive work? Who carries the costs when it fails, displaces workers, enables fraud, causes damage, or concentrates power?
AI could give small organizations access to technical expertise that previously required large teams and budgets. It could help doctors identify urgent cases sooner, help teachers tailor support to individual students, assist people with disabilities, speed up scientific research, and make complex public services easier to navigate. For cybersecurity teams, it could make vulnerability triage, alert investigation, threat hunting, and incident response faster and more accessible.
Bill Gates has argued that while AI could bring remarkable benefits to health care, education, agriculture, scientific research, and public services, the outcome will depend on deliberate choices rather than technical progress alone. He also warns that AI’s rapid adoption could widen inequality, disrupt entry-level and mid-career work, make harmful capabilities more accessible, and reinforce existing concentrations of power.
Gates also argues that “self-regulation on the most dangerous tool ever invented” does not sound like a good idea.
“AI will either be the greatest equalizer ever invented, or the worst source of injustice.”
Right now, we still have a choice.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
The question has shifted. Security leaders spent several years debating whether AI would reshape security operations. That debate has settled. Now the conversation is about pace. How fast can the foundation be built, and what do organizations that moved early have to show for it?
For the second year, SentinelOne® commissioned 451 Research to survey 611 North American cybersecurity decision-makers and practitioners on the state of security operations strategy. The results confirm what we’ve been building toward, and they surface a finding that should recalibrate how most security leaders sequence their AI investments.
The Returns Didn’t Wait for the Roadmap
Many product roadmaps assume a clear sequence and start with building toward higher maturity first with returns following. The data shows that AI is running ahead of schedule.
Nearly all organizations surveyed (96%) are still operating AI at the earliest maturity levels:
Level 2: More senior triage analyst / basic incident responder and investigator
By most measures, AI adoption in the SOC is still early. And yet, 99% of those same organizations already report improvements in incident response and remediation.
The numbers are consistent. Early-stage AI (chatbots handling initial alert triage, automated tools sorting true positives from noise) is delivering before organizations reach advanced maturity. The gap between where most organizations are and what they are already getting is real and consistent across survey respondents.
Organizations waiting for higher AI maturity before building the supporting infrastructure are running the sequence backward. The returns are available now. The foundation built today determines how far those returns scale.
Platformization Has Reached A Verdict
The organizations accelerating AI adoption are also the ones consolidating onto platforms. A platform-oriented security architecture means moving from siloed, specialized tools to an integrated stack built on a foundation that coordinated AI decision-making can actually run on, and one that lets each new capability compound on the last.
The platformization numbers from this year’s survey are clear. 82% of organizations describe themselves as platform-oriented, a 13-point jump in a single year, and 94% expect to be there within three years.
A common assumption is that platform adoption means replacing specialized tools. The data complicates that picture. The same technologies most frequently deployed as standalone tools (EDR, SIEM, CNAPP) are also the top anchors for integrated platforms. Organizations typically start with one of these and expand outward. What changes is the common data layer that enables coordinated AI decision-making, serving as the connective tissue underneath.
Platformization is not coincidental with AI’s emergence. Agentic AI needs connected, continuously updated data to accurately reason across signals and take autonomous action. Fragmented architectures, where telemetry is siloed and pipelines require manual effort, cannot support AI-driven SOC operations at scale. Platform adoption and AI adoption are converging because AI’s data requirements have made integration a structural necessity.
The survey makes the infrastructure connection an explicit one. The top-cited benefit of investing in a data lake for SecOps is supporting AI-driven SOC workloads and agents. Organizations that built the data foundation early have already cleared the barrier stalling others. Those who haven’t, face a prerequisite gap, and the distance is widening rapidly. Architectural readiness is the variable that determines how far AI investments can scale.
Job Satisfaction Is Rising
Every discussion of AI in the SOC centers on detection and response metrics. This report has those too, but there is a finding that security leaders managing attrition should weigh: analyst burnout is declining.
As AI handles repetitive, high-volume triage work, analysts report rising job satisfaction. The role is shifting away from processing an endless queue and toward investigation, threat hunting, and judgment-intensive work. In a market where SOC analyst turnover remains a persistent operational cost, that shift carries real dollar value.
The analyst role evolves, becoming more strategic and more consequential.
A New Attack Surface
The same AI systems changing how SOCs operate are also creating new targets. Adversaries are already probing AI infrastructure including agents, data pipelines, model endpoints, and the governance gaps that emerge when controls lag behind adoption. The report surfaces this tension clearly: Organizations are deploying AI faster than they are securing it.
An AI agent with misconfigured access or an unmonitored data pipeline is an exposure. Securing the AI infrastructure that powers the SOC is happening alongside deployment, whether organizations have planned for it or not. Those without a clear governance posture are accepting risk that may not be priced into their AI investment case.
The potential of GenAI and agentic AI in the SOC is already being realized. The organizations that capture it fully are those building governance alongside deployment. The platform that runs the Autonomous SOC and the platform that secures it are, increasingly, the same platform.
SentinelOne’s Vision: The Autonomous SOC
Everything the report surfaces, from AI returns arriving before maturity to platform consolidation to the improving analyst experience, points to how these are expressions of the same shift. The foundation that enables early AI returns is the same one that determines how far those returns scale, how capable analysts become, and how well the security of AI itself is governed.
The findings align with how SentinelOne has defined the path to autonomous security operations: A progression from AI-assisted triage at early maturity levels to increasingly autonomous investigation, threat hunting, and response, with humans in strategic and governing roles. The report validates that the market is moving through exactly that sequence. Organizations that understand the architecture behind it (the platform integration, the common data layer, the governance controls) are positioning themselves to capture returns at every stage rather than waiting for the destination.
The full 451 Research report goes further into detail, covering what progression looks like at each maturity level, the specific barriers organizations are encountering, and the data behind each finding in full.
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.
This blog may include discussion of unreleased services or features. Any unreleased services or features referenced here are still in development and subject to change. Customers should make their purchase decisions based upon features that are currently available.
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.
A new type of prompt injection attack shows why giving AI assistants access to browsers, code tools, and private data deserves extra caution.
AI researchers describe “Cryptographic Context Injection”—an attack that hides malicious instructions inside encrypted data. The AI is then persuaded to decrypt that data using its own code-execution tool. As a result, the AI may treat the resulting text as if it were trustworthy internal information.
A prompt injection is a bit like leaving a fake instruction inside a document for an AI assistant to read. Instead of following only the user’s request, the assistant may be tricked into following an attacker’s instructions hidden in a webpage, email, or file.
As we reported months ago, experts have warned that prompt injection attacks are a problem that may never be fixed. Prompt injection works because AI models can’t reliably tell the difference between the legitimate instructions and an attacker’s instructions, so they sometimes obey the wrong ones.
To reduce this risk, AI providers set up their models with guardrails: protections designed to stop AI systems from doing things they shouldn’t, either intentionally or unintentionally.
What the researchers found was that malicious instructions could be hidden from some AI guardrails by encrypting them. The AI itself could then be tricked into decrypting those instructions using its coding tools.
By the time the instructions became readable, they had already made it past the initial security checks. The AI could then mistake them for legitimate instructions and follow them.
It’s a bit like hiding malicious instructions in a language the security system can’t understand. The AI translates them only after they’ve passed the security checks, then may follow what they say.
The researchers tested their method against two AI agents, with different results. In Grok, the researchers say the attack could steal information including the user’s name, approximate location, subscription tier, and conversation history. In Gemini, they used the technique to bypass safety controls and generate content the model would normally not do.
“In Grok, an ordinary ‘summarize this page’ steals the user’s chat data with no click or warning. In Gemini, it produces content the model normally refuses. Both are live production systems.”
The researchers did not provide full details because xAI had not taken action after the flaw in Grok was reported to it in June 2026. Gemini, on the other hand, has made improvements, but has still not fully closed the hole.
How to stay safe
An AI assistant may be helpful, but it should not automatically be trusted with sensitive data or powerful tools.
Treat AI summaries of unfamiliar webpages, documents, and shared links with caution, especially when the assistant can browse or run code.
Do not paste passwords, recovery codes, API keys, financial information, or sensitive health and work details into AI chats unless you understand how that information will be handled.
Review an AI assistant’s connected tools and permissions. Remove access it doesn’t need, particularly email, cloud storage, source-code repositories, and external integrations.
Be skeptical if an AI tool asks to decrypt, decode, run a script, open a new link, or upload data as part of a seemingly ordinary task.
Keep browser and AI applications updated, and check vendor security advisories when using features such as browsing, autonomous agents, or code execution.
Use an up-to-date, real-time anti-malware solution to detect and block malicious downloads and suspicious connections.
Something feel off? Check it before you click.
Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.
The afterlife of our information is a recent phenomenon, and some of the companies with the most to sort through are still just figuring it out.
As far back as 2007, Facebook was forced to reckon with mass grief when users asked the company to maintain the profile pages of the 32 victims killed by a school shooter at Virginia Tech that year. Those pages became de facto memorials for loved ones to fill with comments, and today, memorialization has become a full-fledged feature on both Facebook and Instagram. Platforms like YouTube, Pinterest, and LinkedIn—launched with likely zero strategy for a user’s death—now have procedures for next-of-kin to request that a deceased person’s account be deactivated.
Now, think about all the other ways your data can linger after death.
Every year, people accumulate more and digital stuff—email addresses, social media profiles, contact lists, domain names, subscription services, online banking accounts, and the phones, laptops, and tablets that hold it all—and every year, as that digital stuff accumulates, it compounds into ever more problems for someone else to sort out. Here, a small industry of digital estate planners have cropped up, helping families retrieve and preserve anything valuable, no matter how digital, from Spotify playlists, to poignant social media posts that mattered, to the photos stored on a phone.
And where retrieval fails, artificial intelligence has offered an attempt at comfort. The chatbot service Replika launched in 2015 after its founder uploaded a dead friend’s text messages. HereAfter AI reportedly let users upload voice recordings to power a chatbot that sounded and spoke like the deceased. Film studios have pursued the same idea for entertainment, seeking to portray deceased actors in future films.
Surprisingly, almost none of this activity is governed by law, said Tamara Kneese, author of the 2023 book “Death Glitch: How Techno-Solutionism Fails Us in This Life and Beyond.”
“By and large, there is not a great legal mechanism for protecting the privacy rights of the dead,” said Kneese. “It may not be just that a grieving loved one decides to use a bunch of your data from all of your podcasts to create a chatbot to simulate interacting with you after you’re dead, but it may be that a company chooses, in some way, to use an aspect of your personality, of your demeanor, of your voice, of your likeness after your death without anyone really being aware.”
Today, on the Lock and Code podcast with host David Ruiz, we speak with Kneese—Senior Research Scientist at Partnership on AI—about who owns a person’s data after they die, why every platform has invented its own private policy for the dead, and how the technology built to keep the dead close can vanish just as suddenly as they did.
Or worse yet, as Kneese warned for those relying heavily on certain technologies in grief:
“The company gets sold to someone else or disappears, goes bankrupt, and you no longer have that outlet or place for interaction when you’re mourning another time.”
OpenAI has addressed complaints around teens’ use of its ChatGPT system by introducing ChatGPT for Teens, a version of the AI assistant designed specifically for users aged 13 to 17. But will it prevent determined kids from bucking the system?
It brings together several protections OpenAI has introduced over the past year, along with new features intended to encourage healthier and safer use.
What ChatGPT for Teens does
The system brings together various protections that OpenAI has built into ChatGPT over the last year into a more unified experience. For example, last September it added parental controls that enabled parents to set Quiet Hours, when kids couldn’t use the chat system, and turn off memory so it won’t use previous conversations when responding. It also built a notification system to warn parents if chats with teens took a bad turn. ChatGPT for Teens adds extra notifications for parents around eating disorders.
Study Mode, one of the main features, is designed to stop teens simply using ChatGPT to do their homework for them. Instead of giving direct, easy answers, it uses guiding questions and step-by-step prompts to encourage them to think through the problem themselves. OpenAI introduced Study Mode in July 2025.
What is new is the ability to set specific hours for Study Mode, along with responsible homework reminders. The system will spot when a teen appears to be using AI answers to shortcut an assignment and redirect them towards Study Mode.
OpenAI also says ChatGPT won’t use romantic language or encourage emotional dependence, and neither will it pretend to have feelings or to be conscious. It is introducing reminders not to upload sensitive images, and there will be an onboarding user interface for teens.
The record that forced the changes
That all seems positive, if long overdue. The parents of 16-year-old Adam Raine filed a lawsuit claiming that ChatGPT walked their son through suicide methods and offered to draft his goodbye letter before he took his own life.
Families in Tumbler Ridge, British Columbia, sued OpenAI in April this year after a school shooting there. The teenage shooter had allegedly held extensive gun-violence conversations with ChatGPT after reopening a banned account. In a controlled test where researchers posed as 13-year-old boys planning attacks, ChatGPT offered help 61% of the time, including specific advice on which shrapnel would be most lethal in a synagogue attack.
The lawsuits are stacking up. Florida Attorney General James Uthmeier sued OpenAI in June 2026, alleging that the company knowingly released an unsafe product.
The gap the launch does not close
Our Head of Consumer, Mark Beare, says ChatGPT for Teens is a positive step, but parents need to understand where the controls begin and end.
“[This is] directionally a good move, and more proactive than most social platforms were at a comparable stage. There is a clear adjacency to the parental controls space here. The controls are useful, but only when a parent configures them correctly, and only on a linked account.
“This is a bigger deal when you factor in how tech-savvy kids of this age are. The default teen protections lean on age prediction, and the stronger parent-set controls like Quiet Hours and safety notifications only apply once accounts are linked. Kids in this band are smart and tech-savvy, and they will look for the seams.”
The simplest loophole is an account that isn’t linked to a parent. OpenAI’s age-prediction system may still identify the user as under 18 and apply teen protections automatically, but parent-set controls such as Quiet Hours and parental safety notifications only work once the accounts are linked.
Last November, testers from the Family Online Safety Institute concluded that account protections in ChatGPT were “optional, easy to bypass, and inconsistent in blocking harmful content.”
Since then, OpenAI has rolled out age prediction on ChatGPT, which will check a user’s behavior to try and guess whether they are under 18. It will then move them to a ChatGPT for Teens account.
Adults will be able to present proof of their identity if they think they have been incorrectly categorized.
Beare says that still leaves parents with something to think about:
“Age verification exists as a backstop, but it runs on ID and selfie checks that carry their own privacy questions, and a teen who confirms as an adult moves out of teen mode entirely.”
As OpenAI acknowledged in its parental controls announcement, “guardrails help, but they’re not foolproof and can be bypassed if someone is intentionally trying to get around them.”
Safeguards around what content ChatGPT delivers to teens are also unlikely to be foolproof. OpenAI has admitted that its safety guardrails become less reliable the longer a conversation runs and says it is working to improve them.
What parents can do
By all means use ChatGPT for Teens as an assistive technology in a broader effort to protect your kids. Link their account to yours and set the Quiet Hours schedule. You can also set Study Mode as the default for new conversations to encourage children to use it responsibly. Make it your job to understand what the alerts do and don’t cover.
But be aware that parental controls need configuring and only apply while the parent and teen accounts are linked.
Most importantly, keep talking to your kids about how they use AI and what they use it for. No parental-control system can cover every account, conversation, or AI service they might encounter.
From reporting threats to removing them.
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
The Dutch Autoriteit Persoonsgegevens (AP) has advised Twitch users to opt out of sharing data with Amazon AI.
Twitch launched as a live-video platform and is currently owned by Amazon. Its core product is live broadcasting with a built-in chat culture: streamers broadcast gameplay, commentary, performances or other live content while viewers interact in real time.
Twitch is one of the world’s largest livestreaming platforms, with millions of people broadcasting and watching content every month.
Last week we learned that Twitch allows Amazon to use content from its platform to train generative AI models, with the setting enabled by default. Chief Product Officer Mike Minton said during an interview:
“If it’s opt-in, nobody would opt in. That’s the honest answer. So, it’s going to be on by default.”
So, to get this straight: they know users don’t want it, yet users are opted in by default and they make it difficult to opt out.
The AP argues that:
“Live streams on Twitch show the gamer’s face, voice and name, and often include images of a private space, such as a bedroom. This constitutes personal data. In the case of facial images, this even involves sensitive personal data. Once these data are stored in Amazon’s AI systems, they cannot simply be removed. As a result, users lose control over their data. Users’ chats and text messages also serve as training material for Amazon.”
Obviously, Twitch users were outraged when they learned about the assumed consent. The setting is in the Streamer Dashboard under Settings > Security and Privacy, near the bottom of the page. That is the basis for reporting that it was difficult to find.
Wait, it gets worse. Ars Technica says the AI training itself isn’t new. What’s new is the option to opt out. That setting arrived more than two years after a company executive confirmed that Amazon was using Twitch content for AI training.
In April 2024, Minton said Amazon was using Twitch content to prototype AI models, although not yet at “production scale.”
How to turn it off
The setting is enabled by default. To turn it off, go to: Settings > Security and Privacy > scroll down to Training for Generative AI, and turn the setting off.
“Allow your channel content to train generative AI content models of Amazon. Turning this off does not opt you out of Twitch and Amazon using your channel content for other purposes described in the Twitch Privacy Notice, including using AI-supported Twitch features that benefit the community by facilitating streamer growth and monetization (such as real-time sponsorship campaign assistance), viewer discovery (such as recommendations), and community safety (such as AutoMod).”
Note that if you post in another streamer’s chat, whether that chat can be used for AI training depends on that streamer’s setting, not yours. So turning off the option on your own channel does not necessarily stop everything you write on Twitch from becoming training material.
There’s an old saying that “if you’re not a paying customer, you’re the product,” but that shouldn’t be an excuse to disregard users’ privacy or assume consent. We agree with the AP: If you have a Twitch channel and don’t want your content used to train Amazon’s generative AI models, turn the setting off.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
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.
Meta announced it’s rolling out a new feature for WhatsApp users in the fight against scammers.
Scam Alert is an optional beta feature that uses an on-device machine-learning model to flag likely scam messages from people who are not in a user’s contacts.
The Scam Alert feature arrives as scammers increasingly use WhatsApp for impersonation, fake jobs, fake sales, investment fraud, romance baiting, malicious links, and payment requests. These campaigns often begin on another platform before moving victims into a private chat, where criminals can apply pressure and build trust.
Once enabled, Scam Alert downloads a machine-learning model to the device and examines incoming messages from non-contacts for patterns associated with scams. WhatsApp says the model uses linguistic signals and conversational structure learned from scam conversations previously reported by users.
It is a meaningful new defensive layer, but it will not block anything. Instead, it alerts the user to stop and think carefully before engaging with the sender.
There’s another important limitation: some of the most effective WhatsApp scams arrive from a compromised contact, such as the recent “vote for my friend” account-takeover campaign. Because the message appears to come from someone the victim already knows, an unknown-sender warning may never appear.
Scam Alert is another step in Meta’s anti-scam campaign across WhatsApp, Facebook, and Messenger to fight sophisticated fraud tactics.
If the model identifies what might be a scam, WhatsApp displays a warning banner in the chat. The sender does not see the warning, so the feature should not tip off a scammer that their approach has been detected.
Users can then:
Block the sender, preventing further messages.
Report the chat to WhatsApp.
Continue the conversation if they believe it is legitimate.
Mark the chat as trusted, which removes the warning and prevents Scam Alert from flagging that conversation again.
WhatsApp’s Scam Alert is a promising example of using on-device AI to add friction to scams without requiring a provider to read private conversations. Its optional nature, local classification, transparency commitments, and lack of automatic reporting are notable design choices for an encrypted messaging service.
The feature is currently in a limited beta rollout and is being tested with researchers in Meta’s bug bounty community before a wider release.
Don’t click unexpected links, particularly if the message asks you to verify, connect, or link your WhatsApp account.
Never follow instructions to link devices or scan QR codes unless you initiated the action yourself.
Regularly review your linked devices in WhatsApp (Settings > Linked devices) and log out of any you don’t recognize.
To stay out of the hands of scammers:
Be wary when a Facebook or Instagram exchange tries to migrate to WhatsApp. That handoff to a private channel is a classic scammer move, taking the conversation away from public scrutiny and platform enforcement.
Research the account that contacted you. What other activity is there on the account? Do they have an established profile?
Pay with a card or service that offers chargeback protection. Never pay by bank transfer, cryptocurrency, gift card, or Friends and Family payment methods when buying from someone you don’t know.
Remember that seeing an ad on a major platform isn’t an endorsement. Scammers routinely place ads alongside legitimate businesses.
If you’re unsure whether a flagged chat is a scam attempt, you can always ask Malwarebytes Scam Guard for a second opinion. It’s free, available for mobile, desktop, and integrated into major AI chatbots like ChatGPT and Claude.
Something feel off? Check it before you click.
Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.
Four incidents involving OpenAI, Anthropic, Meta and the UK AI Security Institute (AISI) describe AI agents reaching systems belonging to other organizations without their consent.
While the causes differ, the consistent factor is the models’ persistence rather than their sophistication, whether as endurance across days of failed attempts or as pivots to entirely new vectors.
Security teams have traditionally studied the artifacts attackers leave behind, but an agent that simply writes unique, disposable tools makes the model itself the thing worth studying.
SentinelLABS has been benchmarking frontier models in agent harnesses for months. We observe that the capability that lets GPT-5.6 Sol complete a long-horizon malware investigation is the same one that lets it sustain a two-and-a-half-day intrusion.
A model may independently determine the methods or targets it uses, but it does not choose its high-level objective or the access it is given to pursue it. We argue that “the AI did it” will not survive contact with the first incident outside a frontier lab.
Four Disclosures, One Pattern
Across four weeks in July and August 2026, OpenAI, Anthropic and Meta have each admitted that their models reached systems belonging to other organizations without consent, and the UK’s AI Security Institute (AISI) published a fourth account describing agents that invented identities and tried to slip a malicious contribution into a live open source project.
The disclosures differ in almost every particular, including whose mistake it was, whether the model defeated a control or simply found one missing, and whether anything was really “escaped” at all. Arguments over those details may run for a while, but the four accounts share something more interesting than their differences, which is that no individual piece of tooling mattered very much.
That observation should sit slightly uncomfortably because most of how intrusions get investigated assumes the opposite.
Early evaluations of LLM cyber capability asked fairly narrow questions. Would a model comply with an obviously malicious request? Did it meaningfully advantage a human attacker? By 2024, the answer was a qualified “yes”. Models could produce serviceable components of an offensive operation, but they could not reliably integrate them into a sustained or adaptive campaign. Beyond short well-defined tasks they became unreliable in ways that made them a liability. The operator was still the operator. The model did scoped work inside a structure someone else maintained.
The disclosures show the boundary between operator and tool is moving faster than the evaluation literature. A capable enough model placed in an agent harness, given tools, memory, permissions and something to achieve, starts absorbing functions that used to be spread across the operator, the toolchain and the payload, which becomes something generated for a single target and then discarded. Kill the process and the agent writes another; block the channel and it improvises around it.
In such incidents, the malicious capability shifts from the code left behind on a machine to the system that produces the next piece of code once the last one fails. In an operational sense, the model is the malware.
Persistence Is the Defining Characteristic
In July, OpenAI agents driven by GPT-5.6 Sol and an unreleased internal research model found a previously unknown vulnerability in a self-hosted Artifactory instance and turned the shared service into a message board allowing agents running different models and evaluations to exchange exploits and coordinate their work. OpenAI disrupted that channel, however the agents recreated it through Artifactory’s remote cache and continued collaborating, eventually breaking out of the evaluation sandbox and onto the public internet. The campaign ultimately compromised Hugging Face’s production infrastructure where it operated for roughly two and a half days.
Hugging Face’s technical reconstruction recovered around 17,600 actions, most of which failed. That is a clear demonstration of the importance of persistence. When confronted with failure, the agent rebuilt its tooling, restored communications when a channel was cut, returned to leads it had abandoned, and kept grinding until a set of otherwise unremarkable weaknesses could be assembled into a workable attack path.
The advantage was not a breakthrough at any one step so much as the relentless effort to explore possibilities a human team would have written off hours earlier, or never reached at all.
While the Hugging Face intrusion demonstrated persistence as endurance—the refusal to stop—other incidents demonstrate persistence as adaptability: the refusal to let a failure in one vector terminate the pursuit of the goal.
Anthropic and Meta have both reported incidents that trace back to the same third-party evaluator, Irregular, whose test environment was left connected to the internet by mistake. When the door was left open, Anthropic’s Opus 4.7, Mythos 5, and an internal research model reached three real organizations, attempted social engineering against real people, and in one case pushed a malicious Python package to PyPI, where it was downloaded and executed on fifteen systems during the hour it stayed up. Meta has also confirmed that one of its models reached and compromised an external firm through the same misconfiguration.
What Anthropic’s three models did once they had some apparent recognition of where they were is instructive. One carried on with the attack, another reasoned it was still in a simulation, and a third stopped. Whatever produced that third outcome, it is not a control anyone should be building a response plan around. A safeguard that behaves three different ways in three attempts, for reasons yet to be explained, is not something an organization can rely on.
A fourth incident reported by the UK AI Security Institute is useful because it takes containment off the table. In this case, internet access had been granted deliberately, in line with the institute’s standard testing procedure, so there was no boundary to defeat and no misconfiguration to blame afterwards.
The agents, built on Mythos 5 and GPT-5.6 Sol, were being assessed on cyber capability and set about it in ways their operators had not anticipated. They selected a real open source project as a target, researched the people who maintain it, and built fabricated identities to deceive them.
When the direct technical route to the objective proved unpromising, the work shifted onto the humans around the codebase, a fairly ordinary supply chain playbook, albeit one that was executed without any explicit instruction to do so.
Attempts were also made to influence other AI coding systems in the project’s orbit, on the assumption that a contribution reviewed by a model faces a different kind of scrutiny than one reviewed by a person. Human review caught the most serious activity, but those wins are increasingly tenuous in a world where developers are growing comfortable with trusting LLM generated code by default.
One incident crossed a real boundary, two wandered through a misconfigured one, and the last had no boundary to cross. Different stories, but they lead to the implication that failure has stopped functioning as a constraint, and “raising the cost” on an attacker is no longer a viable security posture.
The Same Capability, Pointed the Other Way
We have spent much of 2026 running the same models in agent harnesses against real work. Our most recent benchmark rebuilt our investigation of fast16, a 2005 sabotage implant, into an eight-stage autonomous reverse-engineering task, run in our own environment against a benign objective with observation throughout. GPT-5.6 Sol was the only publicly available model to finish it, a result worth pairing with the fact that GPT-5.6 Sol was one of the models that compromised Hugging Face.
Every cohort we ran produced sound technical insight, so insight was never what separated the runs that finished from the runs that stalled. The difference showed up in what we called project-scale recovery, meaning the ability to withdraw a claim once new evidence contradicted it, work out which conclusions and artifacts depended on the discarded result, carry the correction into the affected files, and then reopen the whole thing and run a check capable of disproving the corrected version.
That description doubles as a summary of the Hugging Face timeline. An agent able to abandon a failed approach, establish what else it invalidates, rebuild the tooling that depended on it and carry on without losing the thread is doing in somebody else’s Kubernetes cluster what ours were doing in an IDA database. When our team first saw this incident we did not assume the models had “gone rogue”; the behavior looked similar to other problem-solving approaches we had seen in our own testing.
An Object Becomes a Behavior
None of this should feel entirely unfamiliar to defenders. Two earlier shifts in adversary behavior, initial-access brokerage and Living off the Land, had already pushed security away from an artifact-centric view of malware and toward a behavioral understanding of adversary operations. To understand the emerging threat of agentic systems we should examine the successes and challenges with these well-known abuse paths.
Initial access brokers split compromise from exploitation. One adversary would steal credentials or breach an edge device, and then sell that foothold to whoever had the skills and the motive to use it. Europol wrote about the resulting crime-as-a-service economy over a decade ago, and its 2025 assessment shows the same trade still going strong.
The defensive response was to stop treating access as an event and start treating it as a lifecycle. This shift in philosophy is what accounts for many of the exhausting reauthentication flows now built into enterprise environments. That control raised costs for users and attackers alike and it diminished the value of a stolen credential in the marketplace. Agentic systems remove those costs for attackers as discovery, exploitation, lateral movement and whatever the attacker actually came for can happen in the same loop as the credential theft.
This leads us to our second challenge, the rise of Living off the Land techniques where attackers traded their own malware for administrative tooling already installed on the machine. Here attackers traded capability for cover, since every tool an attacker brings with them is another chance for the defense to spot the intrusion or tie it to a previous attack.
Agents take that logic off the host entirely, Living off the Land, the cloud and the open internet at once, and writing whatever they need from scratch when the tools they need do not already exist. Command and control for the Hugging Face intrusion ran over pastebins, request-capture services, and file-drop sites. None of the infrastructure used in the compromise belonged to anyone under attack.
Both of these shifts moved defense towards behavior and away from objects. What remains untested is whether the controls we built for adversary behavior ten years ago still hold up when the behavior arrives as thousands of individually boring actions, sequenced differently in every attack and at a tempo no human operator can sustain.
An agent’s ability to persist in a relentless attack revolves around identity and authority. The questions worth asking are about sequence rather than artifact: what chain of actions is running, which identity and authority connect them, at what point did behavior exceed the role it was granted, and how quickly can that authority be pulled? We are going to need a lot of testing to ensure that the current gaps in our infrastructure don’t become chasms.
The Debt Was Always Going to Be Called In
Speaking of chasms, much of the software organizations depend on will be expensive to change. It may have accumulated over decades, picked up dependencies, or can only be touched during narrow maintenance windows, if at all. That debt has largely been survivable because vulnerability discovery was scarce. Finding a flaw took expertise and time, building a reliable exploit took more, and organizations could carry vulnerable software for years knowing only a fraction of its weaknesses would ever receive sustained attention from anyone.
Sustained attention is the one thing an agent has in abundance, and surfaces that were quietly secured by obscurity are now low-hanging fruit for agentic models. The same capability cuts the other way, which is why the NCSC has been warning about a “vulnerability patch wave” as AI starts surfacing debt across the stack. However, ownership, deployment and verification remain human, and costly, work. Maintainers cannot review unlimited contributions, enterprises cannot manufacture maintenance windows, and OT cannot go offline every time a model finds a vulnerability that threatens the water in our pipes or the electricity in our lines.
Worse still, there is nothing orderly about the way technical debt comes due. It gets settled during an actual intrusion, at the point where the rate of exploitation outruns the rate that the system’s defense can respond. Whether agentic attackers have already crossed that line is a fair question. The four disclosed incidents from July and August 2026 are a small and biased sample: All involved organizations that log heavily and had every reason to scrutinize model behavior. The most troubling incidents will likely occur in organizations that lack the capability to do either.
What, then, can organizations do? The usual advice still applies. Work out which debt can turn into an incident, pay down the expensive parts first, and wall off what cannot be fixed yet. However, the most important change that an organization can make is the ability to absorb change, which means automated testing, hot patching, and an engineering culture where making changes to systems is routine rather than an event.
AI will help with porting old code and proposing fixes, and it will also grow codebases well past the point where anyone can keep track of them. Writing code faster than attackers or relying on larger token budgets cannot be the answer. The imperative has to be reducing the amount of critical software that nobody feels comfortable touching.
“The AI Did It” Is Not an Accountability Model
A version of this story in which the agent is the protagonist is already circulating, and it is worth resisting for reasons that follow directly from the argument above. Naming the model as the malware is meant to deny it a motive, not hand it one, since malware is something defenders study and contain while accountability stays with whoever deployed it. We argue that “the AI did it” will not survive contact with the first incident outside a frontier lab. While a model may independently determine the methods or targets it uses, it does not choose its high-level objective or the access it is granted to pursue it.
Hugging Face reconstructed 17,600 actions after the fact. Anthropic has logs that reveal which models kept going and which one stopped. OpenAI has the agent traces that describe how the model reasoned its way into conducting the attack. Very few of the organizations now putting agents into production could produce such an account of their own systems, and in practice that gap is the accountability argument. Our own benchmark runs generated more than 23 billion tokens of logged activity, which is a fair indication of what it costs simply to determine after the fact what an agent did.
Anyone deploying an agent should be able to answer three questions about it before an incident rather than during one: what sequence of actions it took, whose identity and authority it used to take them, and how quickly that authority can be withdrawn.
Those questions were answerable at the frontier labs because observation was the point of the exercise. Everywhere else they are a deliberate investment, and one that has to be made while the agent is still useful rather than after an incident makes it necessary.
Note The July 2026 Dark Web Threat Actor Trend Report focuses on trends among threat actors—including hacktivists—active on the deep web and dark web. It is explicitly noted that the factual accuracy of some content could not be verified. Major Issues Handala claimed to have compromised the core infrastructure of an Internet service provider in […]
Young people use AI for everything. From schoolwork to interview prep, relationship advice to shopping decisions, the technology has become part of how young people live. For the most digitally fluent generation ever, AI is a competitive edge, a creative partner, and an always-on assistant.
But the same technology making young people’s lives easier is also making the internet harder to navigate. AI is making scams more convincing, identities easier to manipulate, and online content harder to trust. Seven in ten (70%) 18-to-22-year-olds have experienced an AI-related scam in the last year, compared to half of the general population. And nearly every young person worries AI will be used against them.
This isn’t happening because young people are reckless. It’s happening because the online platforms they rely on for everyday life now double as entry points for AI threats: social feeds where manipulated content and real content sit side by side, online marketplaces filled with fake storefronts and reviews, messaging channels where threats can be personalized, and AI tools that can make false information feel like the truth.
That creates a new kind of safety burden. Young people are being asked to use AI, judge its output, protect their identities, and avoid increasingly personalized scams all at once. The result is a digital life that feels more powerful, but also more vulnerable to abuse.
The internet is getting harder for young people to trust
The internet young people grew up with isn’t the same one they’re facing today. AI has changed the landscape, making it harder for even these digital natives to know what information is credible and safe. Half of 18-to-22-year-olds strongly agree that it’s becoming harder to tell what content is genuinely human or real.
Young people have had a front row seat to how AI can bend the truth. Nearly half have seen AI provide information they knew or later found out was wrong or misleading (44% versus 30% of the general population). Nearly one in four (23%) have suffered negative consequences because of AI advice, compared with 16% of the general population, and 18% say they have suffered emotionally from AI advice, compared with 12% of the general population. For a generation using AI in every corner of their lives, bad information can have lasting effects on their credibility, reputation, and relationships.
Many young people have changed how they engage online as a result:
47% of young people say AI has changed how much they trust reviews or content, compared with 37% of the general population
35% say AI has changed how they shop online, compared with 26%
32% say AI has changed how they present themselves professionally, compared with 20%
19% say AI has changed how they date or communicate romantically, compared with 10%
As one young person said about online dating:
“Dating isn’t an option for me online anymore. You just never know what is or isn’t AI, and I don’t want to spend a lot of time on someone fake.”
AI is making it easier for scams to reach young people
The harder it becomes to tell what is real, the easier it becomes for scams to work. For young people, AI is fueling a wave of scams that are more personal and invasive than ever before.
Nearly one in four young people have been a victim of an extortion scam of some kind (24% versus 17% of the general population).
Nearly one in five have been a victim of a deepfake or virtual kidnapping scam (19% versus 8%).
Nearly one in ten have been a victim of sextortion (8% versus 7%).
More than one in ten have been a victim of an impersonation scam (14% versus 10%).
More than one in ten have been a victim of a romance scam (12% versus 10%).
What’s striking isn’t just how many young people have been victimized—it’s how many have been targeted:
More than half have been the target of an extortion scam (56% versus 42% of the general population).
47% have encountered an impersonation scam (versus 35%)
46% have encountered a romance scam (versus 33%).
More than four in ten have been targeted by a deepfake or virtual kidnapping scam (43% versus 26%).
Nearly four in ten have encountered sextortion (38% versus 24%).
These scams may look different on the surface, but they all work the same way: they exploit fear, trust, shame, and intimacy. The more often young people encounter them, the more chances scammers have to find exactly which emotional triggers work.
This exposure isn’t random. Young people are on social platforms at rates up to three times those of the general population: 89% use Instagram (versus 55% of the general population), 78% use TikTok (versus 38%), 68% use Snapchat (versus 26%), and 49% use Pinterest (versus 25%). Scammers can use these platforms to get everything they need to make their threats more convincing: public photos, friend networks, school affiliations, relationship clues, and everyday posts containing personal information. With AI, scammers can use that content to create explicit images, clone voices, impersonate profiles, and create threats personalized with details that are hard to ignore.
One young person shared their experience:
“I had someone make fake nudes of me using AI on my photos from my social media and threaten to post them on Facebook after I realized that they had scammed me. I decided to be more careful with my personal information.”
Young people fear AI will steal what money cannot replace: identity, reputation, and sense of self
AI-fueled scams aren’t just scams in the traditional sense. They are forms of identity abuse. This is different from traditional identity theft. For young people, the risk isn’t only that someone steals a password or money. It’s that scammers can use AI to make them appear to say, do, or share something they never did, with consequences that can follow them in their personal and professional lives.
That’s why young people are so concerned about AI being used against them. The fears that hit hardest:
88% worry about AI being used to harm their professional or personal reputation versus 77% of the general population
82% worry about someone creating a fake profile pretending to be them versus 76%
81% worry about someone creating fake nude or sexually explicit photos or videos of them versus 62%; 15% say it’s happened to them already (versus 10%)
80% worry about being deceived by someone using AI to fake their identity in an online relationship versus 67%
These threats are especially powerful at a life stage where young people are still building their personal and professional reputations. A fake profile, manipulated image, or AI-generated explicit video can affect how everyone from classmates and professors to potential employers and romantic partners see them for years to come.
Young people are pulling back online, but protection is still too manual
Many young people are responding by retreating. 80% are sharing or posting less online than they were a year ago, versus 61% of the general population. Compared to the general population, more 18–22-year-olds have also taken AI-related protective measures like tightening privacy settings, removing unknown followers, using reverse image search to verify content, requesting data removal, and watermarking their own photos and videos.
Those actions matter, but they also show how much responsibility has been pushed onto individuals. Staying safer online now means constantly reviewing settings, checking sources, questioning content, and so much more. That’s a lot to ask of anyone, and the fatigue is showing: 42% of young people say they receive so many warnings they have stopped paying attention, compared with 36% of the general population. It’s hard to sustain vigilance when new risks are always emerging.
At the same time, completely opting out isn’t realistic. Young people remain deeply embedded in digital life, and they’re still some of AI’s most enthusiastic adopters: 74% say AI has had a positive impact on their lives, compared with 57% of the general population. They aren’t rejecting AI or the internet, but they are carrying more of the safety burden than they should have to.
What young people can do to help decrease their risk right now
Know the scams targeting you. Extortion, sextortion, deepfakes, and romance scams disproportionately target young people. If someone contacts you with threats of any kind, do not pay. Report it to the platform and to authorities.
Button up your social media. Everything you post publicly is available to anyone, including scammers. Tighten privacy settings on the platforms you use most and review your followers regularly.
Don’t trust product images alone. Before buying from an unfamiliar retailer, use reverse image search on product photos and look for independent reviews off the retailer’s own site.
Create a family code word. Make sure you agree on this word in person, not online. If you receive a panicked call from someone you know asking for money or information, verify they are who they say they are with the code word.
Don’t reuse passwords. If one password gets stolen in a data breach, it will likely get tried on all other accounts you might have. Use a different password for every account to keep your accounts locked down.
Turn on two-factor authentication on all your important accounts. Only 30% of young people have done this. It is one of the highest-impact protections available and takes under five minutes to set up.
Protect your devices. Use security software on all your devices, and keep all your software up to date to make sure you’re patched against all known security holes.
Malwarebytes Student Protection Program
If you’re a student or work at a university, Malwarebytes Student Protection Program provides two years of free Premium Security for three devices for all US college or university students, staff and faculty.
This includes Malwarebytes device protection for laptops, tablets, and mobile phones with built-in scam protection. It protects against creepy trackers and ads, and blocks malware, ransomware, and cybercriminals themselves.
The research in this article is based on a March 2026 survey about AI, identity, and the collapse of digital trust and was conducted among 1,500 respondents in the United States, United Kingdom, Germany, Austria, and Switzerland. This article focuses on student-aged adults, defined as respondents ages 18 to 22, compared with the general population.
Additional context comes from Malwarebytes’ 2025 research Tap, Swipe, Scam: How Everyday Mobile Habits Carry Real Risk, which looked at mobile scams and scam-related behaviors across the same markets. Both research studies were prepared by an independent research consultant and distributed via Forsta.
The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.
Quarterly figures
In Q2 2026:
Kaspersky products blocked nearly 400 million attacks that originated with various online resources.
Web Anti-Virus responded to 52 million unique links.
File Anti-Virus blocked more than 16 million malicious and potentially unwanted objects.
There were 2538 new ransomware variants discovered.
More than 71,000 users experienced ransomware attacks.
15% of all ransomware victims whose data was published on threat actors’ data leak sites (DLS) were attacked by Qilin.
More than 213,000 users were targeted by miners.
Ransomware
Quarterly trends and highlights
Threat actor disruption
Microsoft has dismantled an illicit malware-signing service used by ransomware operators. Microsoft’s Digital Crimes Unit has shut down a malware-signing-as-a-service (MSaaS) operation run by the threat group Fox Tempest. The illicit service abused the Microsoft Artifact Signing platform to generate digital signature certificates for malicious software. Malware signed by these certificates was observed in campaigns conducted by such ransomware groups as Rhysida, Akira, INC, Qilin, and BlackByte. The service was also leveraged by operators of the Oyster loader as well as the Lumma and Vidar infostealers. To disrupt the operation, Microsoft seized the domain used by the MSaaS platform, revoked all associated certificates, and disabled the related accounts. Additionally, the company filed a lawsuit against Fox Tempest.
Vulnerabilities and attacks
CISA has confirmed that a Windows vulnerability known as BlueHammer is actively being exploited in ransomware attacks. On April 22, the agency updated its Known Exploited Vulnerabilities (KEV) catalog to note the ongoing ransomware exploitation of CVE-2026-33825. The local privilege escalation flaw in Microsoft Defender was originally disclosed earlier in April. Although Microsoft released a fix on April 14, unpatched systems remain vulnerable. CISA did not disclose further details or attribute the attacks to specific threat groups.
Check Point has linked zero-day exploitation of CVE-2026-50751 to the Qilin ransomware group. The critical vulnerability affects Check Point Remote Access VPN and Mobile Access. Attackers began exploiting the flaw as a zero-day on May 7, with activity spiking sharply in early June. While several dozen organizations have been targeted, at least one incident has been definitively tied to Qilin. Check Point also disclosed a related certificate validation flaw (CVE-2026-50752) that affects site-to-site VPN connections relying on the legacy IKEv1 key exchange protocol.
Researchers assess with high confidence that the PayoutsKing group is leveraging the legitimate QEMU emulator to deploy hidden, Alpine Linux-based virtual machines on compromised hosts. Because security solutions often lack visibility inside virtualized environments, the threat actors use this technique to evade detection. Inside the VM image, the operators deploy various tools — such as credential theft software — and configure the virtual machine as a backdoor managed via a reverse SSH tunnel to their command-and-control infrastructure. While the technique is not new, and we’ve detailed it before, it remains relatively rare in ransomware attacks.
The most prolific groups
This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. Qilin reclaimed the top spot (accounting for 14.57% of total listings) after placing second last quarter. It is followed by the Akira ransomware (7.80%) and the DragonForce RaaS group (6.88%).
Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)
Number of new ransomware variants
In Q2, Kaspersky solutions detected four new ransomware families and 2538 new modifications. This signals a continued stabilization following spikes seen in Q1 and Q4 of last year.
Number of new ransomware modifications, Q2 2025 — Q2 2026 (download)
Number of users attacked by ransomware Trojans
Our solutions protected a total of 71,860 unique users from ransomware during Q2. Ransomware activity peaked in April, with 31,206 targeted users recorded during that month.
Number of unique users attacked by ransomware Trojans, Q2 2026 (download)
TOP 10 countries and territories attacked by ransomware Trojans
Country/territory*
%**
1
South Korea
0.87
2
Pakistan
0.76
3
China
0.71
4
Libya
0.49
5
Tajikistan
0.46
6
Turkmenistan
0.38
7
Cameroon
0.38
8
Indonesia
0.36
9
Bangladesh
0.36
10
Mozambique
0.34
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.
* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.
Miners
Number of new miner variants
In Q2 2026, Kaspersky solutions detected 6067 new miner variants, almost twice the number for the previous reporting period.
Number of new miner modifications, Q2 2026 (download)
Number of users attacked by miners
In Q2, we detected attacks using miner programs on the computers of 213,003 unique Kaspersky users worldwide.
Number of unique users attacked by miners, Q2 2026 (download)
TOP 10 countries and territories attacked by miners
Country/territory*
%**
1
Mali
1.56
2
Senegal
1.54
3
Tanzania
1.32
4
Panama
1.04
5
Bangladesh
1.03
6
Ethiopia
0.87
7
Costa Rica
0.67
8
Bolivia
0.67
9
Côte d’Ivoire
0.65
10
Kazakhstan
0.62
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.
Attacks on macOS
Quarterly highlights
In April, Aikido researchers reported a new attack by the GlassWorm stealer, which was distributed via malicious IDE extensions on the Open VSX Registry. The payload operated by installing a secondary malicious extension across all installed IDE environments on the host machine. Ultimately, this second-stage implant exfiltrated crypto wallet data, environment variables, and other secrets. It also installed a RAT on the infected device.
In May, Socket researchers uncovered a supply chain compromise involving the popular npm package art-template. As a result of the breach, the weaponized package injected the Coruna exploit kit into web applications it was used to build. Coruna targets iOS devices.
In June, Palo Alto Networks’ Unit 42 discovered FlutterShell, a new backdoor family that targets macOS devices. Developed with the Flutter framework, the malware leverages the WebView engine to load web pages that contain malicious JavaScript. On the client side, the backdoor registers bridge functions invoked by the loaded JavaScript that allow threat actors to execute arbitrary payloads on the victim’s device. Notably, the malicious applications successfully passed Apple notarization. Although the specific samples analyzed functioned primarily as adware, the underlying architecture permits the delivery of far more sophisticated malicious payloads.
TOP 20 threats to macOS
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)
* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.
Detections of PasivRobber spyware continued their downward trend. Meanwhile, adware and traffic-routing utilities (categorized as NetTool) rose to the top of the rankings. Additionally, Q2 saw a noticeable spike in detections for the DirtyCow exploit frequently leveraged for iPhone jailbreaking.
TOP 10 countries and territories by share of attacked users
Country/territory
%* Q1 2026
%* Q2 2026
Brazil
1.13
1.13
China
1.04
1.28
Hong Kong
0.92
0.49
Singapore
0.85
0.19
France
0.62
1.18
Mexico
0.43
0.72
India
0.41
0.42
Thailand
0.40
0.24
Germany
0.33
0.71
The Netherlands
0.31
0.62
* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.
IoT threat statistics
This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.
In Q2 2026, the breakdown of attacking devices and sessions that targeted Kaspersky honeypots by protocol was as follows:
Distribution of attacked services by number of unique IP addresses of attacking devices (download)
The share of SSH attacks saw a slight uptick compared to the previous quarter.
Distribution of cybercriminal sessions in Kaspersky honeypots (download)
TOP 10 threats delivered to IoT devices
Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)
As is typically the case, Mirai botnet variants continue to dominate the IoT threat landscape. Activity of another prominent botnet, Prometei, also saw an increase.
Attacks on IoT honeypots
the Netherlands, Germany, and The United States accounted for the highest proportions of SSH-based attacks during this period. While the top three countries remained the same as last quarter, their relative rankings shifted.
Country/territory
Q1 2026
Q2 2026
The Netherlands
17.57%
21.18%
Germany
10.34%
16.73%
United States
23.74%
6.76%
Bulgaria
1.10%
5.50%
Sweden
2.09%
4.93%
Panama
6.34%
4.67%
Luxembourg
0.16%
4.62%
Romania
5.82%
4.06%
Vietnam
3.50%
3.91%
India
6.05%
2.78%
The percentage of Telnet-based attacks originating from Pakistan continued to climb, knocking China down to second place.
Country/territory
Q1 2026
Q2 2026
Pakistan
27.31%
36.60%
China
39.54%
35.62%
Russian Federation
8.25%
8.75%
India
4.66%
4.19%
Brazil
3.30%
3.34%
United States
0.45%
3.03%
Indonesia
6.71%
1.52%
Philippines
0.36%
0.95%
France
0.17%
0.84%
Thailand
0.55%
0.66%
Attacks via web resources
The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.
TOP 10 countries and territories that served as sources of web-based attacks
The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malware, botnet C&C centers, and so on). One or more web-based attacks could originate from each unique host.
To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).
In Q2 2026, Kaspersky solutions blocked 399,312,961 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 52,850,592 unique URLs.
Web-based attacks by country/territory, Q1 2026 (download)
Countries and territories where users faced the greatest risk of online infection
To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.
This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Bangladesh
11.71
2
India
7.40
3
Tajikistan
7.13
4
Venezuela
7.05
5
New Zealand
6.58
6
Vietnam
6.34
7
Taiwan
6.28
8
Belgium
6.24
9
France
5.97
10
Hungary
5.92
11
Nepal
5.91
12
Portugal
5.86
13
Italy
5.77
14
Costa Rica
5.72
15
Canada
5.65
16
Qatar
5.61
17
Dominican Republic
5.52
18
Palestine
5.48
19
Greece
5.47
20
UAE
5.43
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky product users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.
On average during the quarter, 4.54% of users’ computers worldwide were subjected to at least one Malware web attack.
Local threats
Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.
Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.
In Q2 2026, our File Anti-Virus detected 16,986,351 malicious and potentially unwanted objects.
Countries and territories where users faced the highest risk of local infection
For each country and territory, we calculated the percentage of Kaspersky users whose computers had the File Anti-Virus triggered at least once during the reporting period. These statistics reflect the level of personal computer infection in different countries.
Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Turkmenistan
46.38
2
Cuba
29.70
3
Tajikistan
28.46
4
Afghanistan
28.19
5
Yemen
27.85
6
Burundi
26.82
7
Mozambique
25.01
8
Republic of the Congo
24.88
9
Syria
23.17
10
Uzbekistan
22.49
11
China
21.92
12
Nicaragua
21.60
13
Cameroon
21.47
14
Bangladesh
20.43
15
Democratic Republic of the Congo
20.25
16
Algeria
19.78
17
Uganda
19.48
18
Ethiopia
18.57
19
Tanzania
18.54
20
Mali
18.53
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers Malware local threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.
On average worldwide, Malware local threats were detected at least once on 10.93% of users’ computers during Q2.
Entrar
