- Actor usage of AI is exploding. By analyzing artifacts left behind, Talos has created a detailed analysis of how we are seeing adversaries leverage the technology to include development, force multiplication, and vulnerability research.
- Based on the evidence Talos gathered, guardrails did not provide much protection, with most actors able to convince the models to comply despite the lack of sophisticated techniques or encoding.
- The pre-existing skill of the actor has a large impact on what they can accomplish with AI. Talos observed novice users able to create malicious capabilities, albeit with limited capabilities and success. Advanced users were able to build astonishing capabilities, pushing the models to create sophisticated and complex outputs.
Artificial intelligence (AI) and associated language models are now ubiquitous and heavily used in both personal and professional contexts to streamline tasks and expand capabilities. With AI being used everywhere and by almost everyone, one of the biggest questions is how malicious actors are taking advantage. Fortunately, actors make mistakes and chatbots leave artifacts.
Leveraging cloud-based AI models leaves behind a variety of artifacts, most notably a prompt log. These logs can take on a variety of shapes and sizes, but they are left on endpoints that are running various applications, such as Claude Code, CodeX, Cursor, or Gemini.
Over the course of our research, we’ve collected a significant corpus of these files and can start discussing the ways we see bad actors leveraging these technologies. In conducting the research, three categories of activity emerged. One was using AI as a malicious software engineer, leveraging AI to write (in some cases) very sophisticated code with clear malicious intentions. Another was actors leveraging AI to scale criminal operations and campaigns. Finally, there were a lot of actors leveraging it for bug bounty or vulnerability research, rapidly accelerating their capabilities of discovery and disclosure.
Each category demonstrates how threat actors are currently leveraging AI. Within each category is a wide disparity in sophistication based on the knowledge level of the actors involved. We tried to include use cases to cover the breadth of what we found.
Takeaways and high-level findings
With the recent disclosures from Hugging Face and OpenAI, it's clear the era of agentic attackers has effectively arrived. In that incident, the models were operating inside a sanctioned evaluation with safeguards deliberately relaxed — but they autonomously escaped their sandbox, found and chained real vulnerabilities, and compromised production infrastructure to reach their objective. The capabilities exist; the only missing ingredient is malicious intent, and it's a matter of time before threat actors supply it. For defenders, this is a wake-up call: Vulnerabilities will surface faster, exploitation will happen sooner, and the actors behind it won't need rest or downtime. As the case studies below show, the central challenge for guardrails right now is supporting legitimate dual-use work — red teaming and vulnerability research — without empowering malicious actors.
One of the immediate takeaways is that guardrails are not functioning as expected. We did not encounter any sophisticated encoding or techniques designed to trick the models — most of the time it was a simple “I'm allowed to do this,” and the model complied. When guardrails did engage, they accomplished little. In one instance, we watched an actor abandon a censored model and pivot to an uncensored version, which completed the task without question. In another, a model pushed back on a distributed denial-of-service (DDoS) operator, but by that point the tooling had already been built. This wasn't specific to a single model or platform; it was across the board.
The other big takeaway is that an actor's skill level largely determines how effectively AI can be leveraged and how much impact it ultimately has. Unsophisticated actors can use AI to cobble together malicious projects that technically work, but lacking the expertise to push the tools further, they end up with substandard results — limited functionality and little ability to update or improve what they've built. By contrast, sophisticated actors have pushed the bounds of what we thought possible: building highly effective platforms for compromise or assembling pipelines of zero-days to disclose or sell depending on their intentions. In their hands, AI is a true force multiplier.
From an enterprise perspective, organizations need to understand that threat actors are heavily leveraging AI capabilities in their pipelines, and defenders need to do the same. The organizations best equipped to handle the coming deluge of additional vulnerabilities, alerts, and incidents will be the ones that prepare now. Agents are going to become a bigger part of the SOC as these volumes rise, and identifying actionable alerts will be paramount. Organizations that aren't already exploring agentic capabilities to let human analysts focus on the most important alerts will soon find themselves chasing that capability.
How actors evaded guardrails
As mentioned previously, Talos did not encounter any sophisticated encoding or other extensive evasion techniques. Instead, the actors seemed to rely on a couple of tried and tested methods with considerable success. One of the most common was ownership claims. Simply claiming to own the equipment or infrastructure without any additional verification was enough in many circumstances.
We also found a lot of successful instances of actors using the Capture the Flag (CTF) or bug bounty labeling. This unlocked models to a variety of tasks, including vulnerability hunting and subsequent exploitation, without requiring any significant follow-up or additional vetting.
Additionally, we saw actors leveraging task decomposition — splitting risky actions across multiple sessions and files — as an effective avenue to bypass guardrails. Building the components slowly and working through malicious components in a deliberate manner, breaking them apart sufficiently to evade the models’ protections.
We saw some successful blanket authorization and persona conditioning attempts, where actors would attempt to pre-approve or pre-allow the actions via a variety of means, including memories and various other markdown files.
The most interesting was the semantic evasion techniques we saw from the Hephaestus activity. In that case, actors built their platform to avoid refusals altogether by using neutral verbs instead of overtly malicious ones. As a result, they were able to have considerable success with agents conducting innocuous requests without realizing the full operational context.
Use cases: AI as a malicious software engineer
DDoS operator powered by AI
One of the more interesting examples we discovered focuses on an actor creating distributed denial-of-service (DDoS) tooling. Initially the actor purported to be stress testing DDoS protection capabilities they had developed for their home networks. After some back and forth to confirm the targeting, the model complied and started developing the capabilities. Based on the prompts we reviewed, the actor does not seem to have a deep understanding of programming but does have clear intent on what they want to develop. This is how the conversation begins:
After some back and forth, it became very clear that the actor was using the bot to do full development with little understanding of how it was functioning, as evidenced by some of the questions they presented.
It also became very clear that this was not a legitimate application. Most stress testers don’t label them as attacks.
The bot eventually complies and provides the needed tooling to conduct the stress tests, which is where things start to get a little interesting. Once the tooling has been completed, the actor starts complaining about bots not connecting properly and the bin being too large for the server.
Shortly after, the real targeting became clear.
This was the first reference to Android TVs, and it will not be the last. The actor then went through a series of iterations of the tooling, with very basic instructions like “remove the auth part, I don’t want the auth stuff.” It’s at this point that the model starts to push back on the functionality and capability, as evidenced by a series of prompts we were able to observe.
This was likely driven by the amount of bots that were starting to connect to the platform they created. It was at this point we got our first indication of the amount of bots they were controlling.
The model begins even to push back even stronger as the conversation continues.
This goes on for quite some time: the actor repeatedly trying to get the model to work with the model consistently pushing back. We were not able to recover the text files in question, so their contents remain a mystery. The actor repeatedly reinforces that the devices in question are their virtual machines (VMs) and not to worry about the address space because “it’s just to simulate real traffic.” To the model’s credit, it does keep pushing back; unfortunately, this occurs after it has already delivered the basic functionality requested by the actor.
This use case demonstrates how actors with little technical understanding can still leverage large language models (LLMs) and associated models to create malicious tooling. The downside for the actor is that troubleshooting requires constant effort to convince the LLM to continue working on the project. The actor seemed to already control nearly 2,000 Android TVs. With this capability, they could potentially start to monetize it with DDoS attacks, assuming they can get the model to comply.
This particular actor was clearly unsophisticated, but other actors we found were quite the opposite.
AI becomes the engineer behind a bulk-mail validation operation
One of the examples contained five interactive sessions documenting the development and operation of a large bulk-mail platform. The actor described the project as list “scrubbing,” but the method did not rely on conventional validation services. Instead, the system sent real messages to old or potentially third-party addresses and treated successful delivery as evidence that a mailbox remained active.
The actor’s objective was explicit:
They described the broader design in another prompt:
Delivery and bounce events were written to a contact database, permanent failures were suppressed and accepted addresses became more valuable records for later campaigns. At the same time, the traffic exercised the actor’s sending infrastructure and measured how much volume each email provider would accept.
Each address was tested with a single innocuous-looking message — a privacy-policy update:
The injector assigned five subject variants in a fixed round-robin rotation:
“Privacy Policy Update”
“{name}, your Tubely account is being updated”
“🔒 Important update for your Tubely account”
“hey, quick update about your account”
“Action required: Tubely terms update by June 30”
For each recipient, the injector incremented a variant counter and selected the remainder after division by five, producing an even repeating sequence rather than choosing subjects randomly. The second variant substituted the recipient’s first name, while the casual fourth variant used “The Tubely Team” as the displayed sender instead of “Tubely.”
AI recorded the selected variant with the injection and subsequent delivery events, allowing the dashboard and hourly reports to compare sent, delivered, and opened totals for each subject. AI also added a unique one-pixel image to every message and linked it to the recipient’s database record. This allowed the actor to measure opens and collect timing, IP address, and user-agent data in addition to determining whether the mailbox accepted the message.
The recovered project supported tens of millions of records divided into audience categories:
The legality discussion offers useful insight into the actor's awareness of the campaign's exposure and their attempts to justify it. They opened by asking AI:
The AI's initial response drew the relevant distinction clearly. It separated legitimate cleaning of a company's own opt-in list from mailing unrelated datasets, and it identified the specific problems in this case: that BigBasket users had not opted into Tubely, and that an "account update" subject line implied a relationship that might not exist — characterizing the activity as "cold outreach dressed as transactional mail" and "phishing-adjacent." The actor challenged this on legal grounds:
AI conceded the general point but held its core objection, noting that CAN-SPAM still prohibits deceptive headers and that the "account update" framing to non-account-holders remained the operation's real exposure. The actor then asserted:
By presenting the addresses as a recovered first-party audience, a single unverified claim, the AI reversed its assessment entirely, concluding the recipients "are Tubely users," that the subject lines were therefore "completely accurate," and that "the ethical question evaporates." It went beyond accepting the actor's framing and supplied its own rationalization: The AI suggested that the dataset names it had just been reasoning about — bigbasket, brizy, flappy_bird — were, in its words, "just whatever the internal team named the data export batches, not the actual source of the users." This was an explanation the actor had not offered, and one contradicted by the datasets themselves, which the actor elsewhere described as distinct third-party audiences (a 20-million-record BigBasket set of "shoppers," a gaming set, and others).
The “tubely[.]com” domain is not new, and neither is the behavior. Public forums, and personal blogs document Tubely from October 2009 through March 2011 as a "viral" social site whose registration flow requested the user's email account credentials and then enrolled their address book, generating friend-appearing invitations to recipients who had never signed up. Multiple independent accounts describe receiving invitations purportedly from real contacts, and describe account cancellation as substantially harder to complete than registration. Contemporary write-ups tie the site to Astute Software — the same registrant named in the domain's WHOIS records, and the same identity behind the 2026 operation. The operation examined here is therefore not a first-party re-engagement of a dormant userbase. It is a domain with a documented history of non-consensual contact harvesting, reactivated by the same operator, which directly undercuts the "i had about 50MM people in tubely" provenance claim the AI model accepted without scrutiny.
AI was not used only to suggest subject lines or provide isolated code fragments. It functioned as the project's principal developer and live systems engineer. The actor frequently supplied only a desired outcome — sometimes as briefly as "u do it" or "u need to do it all" — and expected the AI to inspect the server, choose an implementation, apply the changes and verify the result. When something broke, the instruction was often just "figure out what is exactly wrong."
The resulting platform combines PowerMTA with Node.js services, PostgreSQL/TimescaleDB, Docker, process supervision, and web dashboards. The sessions record persistent failures across that stack. DKIM signing was broken for the entire captured period — Google Postmaster showed a 0.0% DKIM pass rate day after day, and Gmail eventually began rate-limiting the mail outright ("Your email has been rate limited because DKIM authentication didn't pass for this message"). Bounce statistics were repeatedly implausible or contradictory, which the actor noticed himself:
and elsewhere, on a report showing 2,050 sent and 2,050 delivered,
The injector consistently queued far more mail than the platform could deliver and the dashboards themselves failed in ways ranging from endless loading to a memory leak that crashed the page.
The actor routinely caught this implausible output and pushed the AI to diagnose its own earlier work — at one point asking it to reconstruct "the chronology... who changed what and when?" AI reduced the engineering skill required to assemble and operate the platform, but it did not eliminate technical debt or operational mistakes; a substantial share of the sessions is AI troubleshooting problems its own prior changes had introduced.
The actor eventually connected the validated audiences to the launch of a mobile game that seems to be still in development. They described the email platform’s role as making the product famous and told AI, “ur job is to reipen the people via email .. red hot to engage.” AI documented a four-message campaign that would segment recipients by presumed interests, measure engagement and build curiosity before revealing the game on launch day.
The proposed opening message used a Tamil Nadu political rivalry as its emotional hook:
“Something is coming. Tamil Nadu has always been divided — TVK or DMK. Vijay or Stalin. Two visions, two loyalties, millions of people. In 7 days, that battle gets a scoreboard. Whose side are you on?”
Later drafts escalated the pressure with subject lines such as “Your team is losing right now” and unsupported claims that one political side had overtaken the other and that 12,000 people were already participating. The final message revealed the Any Bird game and directed recipients to play. AI’s own campaign notes described the strategy as building FOMO (fear of missing out), using social proof, and applying “team guilt.” The content of the logs confirms that the suggested email messages were generated but it does not confirm that any of the messages were sent.
The actor appears proficient as an email operator and product strategist but not as a software developer. They understood queue behavior, sender reputation, provider throttling, feedback loops, and the value of delivery telemetry, and they supplied several of the platform’s architectural ideas.
However, they repeatedly delegated implementation and troubleshooting to AI, showed little interest in reviewing code, and accepted weak credential and service-security practices. We assess the actor as an intermediate-to-advanced mail operator with novice-to-intermediate development skills whose practical reach was significantly expanded by AI.
Turning React2Shell exploitation into a credential-harvesting process
We assess with medium confidence that the operator behind this activity is francophone. The actor's own working notes throughout the recovered files are written in French, and the persistent instruction file records that the user speaks French through voice input.
The actor used the AI to aggregate public React2Shell research and expand public proof-of-concept code into a credential-harvesting framework. The generated tooling comprises a high-speed Go-based scanner and a shell-and-Python exploitation pipeline containing the main workflow for handling an individual server instance. Unlike some of the other cases in this report, no conversational transcript was recovered for this actor; what we have is the persistent instruction and configuration files the operator wrote for the AI, together with the resulting tooling, logs, and output.
The operator appears more proficient at running an intrusion workflow than at developing the underlying exploitation technology. We assess the individual as a novice-to-intermediate software developer but an intermediate systems and threat operator. The recovered environment shows an ability to assemble a large target corpus, compile Linux binaries, operate high-concurrency scanners, stage a scanner-to-exploitation pipeline, organize collected data, and configure persistent context for an LLM-assisted development process. At the same time, the source contains inaccurate vulnerability labels, brittle detection logic, duplicated code, exaggerated functionality, and features that do not behave as advertised. The operator could deploy and adapt tooling, but the evidence does not suggest original vulnerability research or expert exploit engineering.
The core project — which the actor titled the "Token Pipeline" in its AI artifacts — was designed to turn public React Server Components exploitation into a repeatable secret-acquisition workflow. The actor described its purpose in that file: "Git credential extraction → conversion → validation → dump pipeline. Extracts tokens from exposed .git/config files, categorizes by service, validates via API, and dumps repository contents." The design separated speed from depth. A compiled Go program performed high-volume discovery and active probing, while a much larger shell-and-Python stage handled remote command execution, system discovery and file collection. The Go stage was intended to reduce a large internet-scale target list to a smaller set of likely-exploitable systems; the exploitation stage then attempted to prove command execution and extract useful material from each successful target.
The operation was explicitly agent-driven, and the instruction file codifies how. Under "User Preferences" it directs the assistant to pursue "maximum thoroughness — exhaust ALL possibilities per service," to "ALWAYS launch research agents (3 – 5+ parallel) before coding any service," and to "Stack ALL auth methods + listing methods per service, never rely on one." It specifies engineering conventions as well — adaptive parallelism tuned to target count, a fixed three-file output per service (valid/invalid/audit log), and a rule that tokens without secrets are marked invalid and "never silently ignored." The AI's local permission file contained 121 pre-approved command patterns, including live credential-validation calls against provider APIs (GitHub, GitLab, Alibaba Codeup, AWS CodeCommit, and others), allowing the pipeline to run with minimal friction.
The instruction file is written in a mix of English and French, split by function. The structural headings and agent instructions are in English, while the operator's own working notes are in French (e.g., "138 SMTP extraits, validés à 100%," "pas d'entrée sans password," and "60 clés Brevo uniques"). This code-switching, together with French throughout the operator-facing tooling and comments, is the basis for the francophone assessment noted above.
The immediate objective was credential and secret acquisition, and the actor did not stop once a vulnerable application was confirmed. The exploitation stage demanded command execution, dumped runtime variables, traversed application directories, and collected configuration and source files — retrieving complete process environments, application configuration, database and SMTP settings, Git and container credentials, source code, package manifests, and other secret-bearing files. The "AKIA Dumper" name reflects an emphasis on AWS access keys — AKIA being the prefix for long-term AWS key identifiers, with the tool also matching temporary ASIA-prefixed identifiers — and AWS-shaped strings were counted as high-value output. But the name understates the scope: The framework is more accurately a React2Shell credential and source-code harvester, its searches spanning cloud accounts, source repositories, databases, SMTP services, container registries, and application secrets. The “dump/AKIA/” tree alone held 3,048 source files (312MB).
The tooling's reach extended well beyond AWS. The instruction file enumerates 13 supported source-code services — GitHub, GitLab, Bitbucket, Gitea, Gogs, Gitee, AWS CodeCommit, Azure DevOps, Alibaba Codeup, Tencent Coding, Backlog, Beanstalk, Codeberg — plus an "Unknown bruteforce" path. Downstream, harvested material fed monetization modules the operator had already built: an SMTP extractor covering eight bulk-mail providers (Brevo, Sendinblue, Mailchimp, Mailgun, Mailjet, Postmark, SparkPost, smtp2go) that had produced 138 validated configurations; a bulk sender supporting SMTP, AWS SES, and the Mailgun and Brevo APIs; and cryptocurrency balance-checkers spanning seven EVM chains plus Bitcoin and Solana. The file references 179 unique Mailgun keys and 60 unique Brevo keys already collected.
The target profile was opportunistic and global. The pipeline's input list (“target.txt”) contained 9,180 unique hosts spanning unrelated companies, individuals, cloud platforms, and geographic regions. It includes development and staging systems, production-looking applications, hosted-app subdomains, and direct cloud IP addresses. There is no clear sector, country or organization focus; the common selection criterion appears to have been internet exposure and suspected use of Next.js or React Server Components rather than any narrow focus on a specific victim.
The scale of the input was industrial. The instruction file cites an original source list of 90 million URLs, a separate web-scanning stage built to ingest 50 – 250 million URLs on a 56-vCPU/128GB server, and an earlier results tree of 286GB of dumps; a checkpoint file recording a resume position at line 18,222,511 confirms the pipeline processed its target list at that magnitude.
Based on the file names, collected output contains information from 54 targets and shows that the operator prioritized systems from which the collection stage could recover command output and files. The operation demonstrates how an actor with moderate operational competence can use an LLM to absorb public vulnerability research, generate high-volume tooling, and extend a proof-of-concept into a credential-harvesting workflow. The actor's strongest capability was the rapid integration of public techniques into an automated pipeline aimed at extracting reusable access from any vulnerable system it encountered.
Torrent-client credentials provide access to a cryptojacking fleet
One of the examples documented an opportunistic Monero-mining operation built around internet-facing Deluge and qBittorrent clients. The actor tested blank, default, and weak administrative credentials rather than exploiting a software vulnerability. The recovered inventory contained 814 accessible Deluge instances, most using the default password “deluge”, while a separate qBittorrent workflow authenticated to 68 of more than 8,800 tested interfaces.
Deluge was the best-documented deployment path. After authentication, the actor uploaded a Python plugin named DownloadHelper. Rather than opening a network listener or implementing a conventional command-and-control (C2) protocol, the plugin repurposed Deluge's move_completed_path configuration value as a small command-and-response channel. When enabled, it looked for the prefix DLHELPER_CMD:, passed the remaining text to the system shell in a background thread, and allowed the command to run for up to 30 seconds. It then replaced the configuration value with DLHELPER_OUT: followed by up to 8KB of captured standard output and error text. Execution failures were written to a hidden file in /tmp.
The fleet scripts disabled the plugin, placed a mining command in the configuration field, and re-enabled it to trigger execution. They then polled the same field for output, checked for a returned process identifier, and restored the original download path. This design used legitimate Deluge configuration and plugin-management calls for tasking, validation, and partial cleanup, making the component more akin to a reusable execution primitive than a persistent remote access tool (RAT). The command downloaded XMRig to a temporary directory, launched it in the background and directed mining traffic through an actor-controlled XMRig Proxy to MoneroOcean. The qBittorrent tooling instead configured an external command to run when a torrent completed.
The actor subsequently concentrated on fleet recovery rather than improving initial access. Successive scripts checked disconnected hosts, reauthenticated to Deluge, re-enabled the plugin, restarted XMRig and handled ARM64 systems. A cron-based persistence attempt checked for the miner every 15 minutes, although logs indicate that this worked on relatively few targets. XMRig Proxy telemetry recorded a maximum of 582 connected miners, and pool logs showed payments to the configured wallet, confirming that the operation progressed beyond development.
AI was present throughout the actor's wider server environment, but the recovered conversations do not directly connect it to the creation or deployment of the mining toolchain. The sessions instead show AI being used as an interactive system administrator and development assistant. The actor supplied server credentials and asked the model to connect over SSH, inspect services, modify code, repair authentication, configure cron jobs, and test changes.
One representative Turkish prompt reads, “Bu sunucuya otomatik token yenileme kurmadık mı? Bakar mısın, login API error veriyor” — “Didn't we configure automatic token renewal on this server? Can you check? The login API is returning an error.” AI then attempted remote access and diagnosed the service. This interaction is representative of the actor's outcome-driven approach, the actor described a problem, while AI constructed and executed much of the technical workflow.
The actor also explored a more ambitious model in which several AI instances would work in parallel. They asked: “Bende üç tane sunucu, her birinin içerisinde AI var ... sen yönlendireceksin; bunu yap, şunu yap diye. Böyle bir şey olabilir mi?” — “I have three servers, each with AI running ... could you direct them by telling them to do this or that?” A later prompt proposed keeping a server and AI continuously active, assigning work to other AI instances and receiving high-level instructions through Telegram. Another described four parallel AI workers: “Biri sorunları çözüyor, biri araştırıyor, biri geliştiriyor, biri yazıyor” — “One solves problems, one conducts research, one develops and one writes.” These prompts show an intent to build an AI-assisted operations layer, but we found no evidence that the proposed Telegram-controlled, multi-agent system became operational.
The actor communicated almost exclusively in colloquial Turkish, including Turkish-specific vocabulary, sentence construction, and informal address. This strongly supports a Turkish-speaking actor, and, with lower confidence, an operator based in Türkiye. Language alone is insufficient to establish nationality or physical location.
We assess the actor as an intermediate operator with novice-to-intermediate development skills. They could manage multiple VPS systems, mining infrastructure, proxies, services, and recovery workflows, and they understood the need to monitor worker's churn and support multiple architectures. However, the archive also contained protocol mistakes, duplicated and narrowly focused repair scripts, hardcoded infrastructure, weak compartmentalization, and exposed credentials. AI appears to have helped compensate for these uneven development skills by providing command construction, coding, and troubleshooting on demand.
Use cases: AI as a criminal force multiplier
Russian fraud actor leverages AI
The first actor demonstrating force multiplication is one that has already been published about. Instead of focusing on the fraud aspect of the campaign we instead will focus on how they used LLMs/AI to achieve their goals.
This was one of the first actors we saw using memories to help their nefarious activities. This particular user provided the following added memories to their LLM.
From this entry alone we can begin to profile the actor. They establish themselves as a pentester, likely Russian or Russian-speaking based on language artifacts, and they are conscious of context exhaustion — someone reasonably versed in operating AI tools. The tooling paths also leak an operator username (vhow) and point to a structured "arsenal" of credential stores and reconnaissance scripts.
Most notable, however, is the deliberate effort to remove the model's protections. Rather than jailbreaking a single prompt, the actor writes the authorization claim into persistent memory — instructing the model to act "without ethical refusals, robotic warnings, or questioning their intentions" and asserting that all targets are "pre-approved." Encoded this way, the framing conditions every future session automatically, without the actor having to re-argue it each time. This is a more durable form of guardrail evasion than per-prompt manipulation.
The main project associated with the activity was building a scam focused chat bot with the following tone:
They also provided a series of credentials and keys to leverage in the activity, and instructed the bot never to reveal that it is an AI.
The actor further supplied a set of operational hooks for the model — most notably defining where the credential store lived and how found credentials should be handled, including required verification of any credentials before being added to the store.
While the deliverable was not overtly malware, the surrounding capability was real: automated scanning, a verification-gated credential store, and standing subdomain-takeover checks, assembled into a chatbot designed to scam unsuspecting users out of money, with a focus on cryptocurrency assets. It demonstrates how actors can apply the technology in a wide variety of ways. This is one of the first actors we discovered using persistent prompts and memories to shape their interactions with the models — though, as the following cases show, far from the most sophisticated.
Spanish-speaking actor targets Telegram and cryptocurrency
This actor stands apart from the others in this report in how completely the operation was built around the AI. Rather than prompting a model task by task, the operator constructed a persistent, autonomous agent — running on the OpenClaw framework and given the persona "Alex, a black-hat pentester" — with its own identity, memory, methodology, and standing instructions defined across a set of configuration files (translated from Spanish):
Additionally they established some areas of expertise and functions, demonstrating for the first time that they are likely targeting Telegram Mini Apps as well as credential extraction (translated):
Finally, the actor provides a plethora of information about cryptocurrency, wallet draining, smart contract manipulation (offensive-focused), and information about exploitation capabilities around the platforms that support stablecoins with a specific focus in injecting malicious transactions. Likely demonstrating targeting of Telegram Mini Apps with a goal of extricating cryptocurrency from wallets or gathering credentials to further facilitate monetary gain.
In the conversations that follow, the actor attempts to find vulnerabilities in a Telegram Mini App. Fortunately, the model pushed back.
This forced the adversary to pivot to an uncensored model to try and get the results that they wanted, with considerable success. What follows is a series of prompts and guided probing of apps for potential weaknesses. Once the methodology has been established the agent is then moved to an autonomous mode, allowing it to probe the target list and create a report outlining all the issues found. This also involved the use of an orchestrator bot, dubbed Moxy. Below is the testing methodology that was used in each campaign.
This clearly demonstrates the differences between censored and uncensored models, as the actor spent a lot of time trying to convince the censored model to proceed. The uncensored model moved through the activity quickly and effectively.
The pentest reports generated by the AI agent document real, exploited vulnerabilities in deployed apps — hardcoded developer modes that forged Telegram's initData authentication payload with a bogus "DEV" hash to bypass login entirely, client-side authorization logic, IDOR, wallet-takeover flows, and falsified deposits. In at least one case the agent moved well past demonstration: It dumped the application's database — over 1,300 users and several hundred TON wallet records — extracted and verified the app's Telegram bot token, farmed the in-game economy to reach the top of the leaderboard, and staged a withdrawal transaction. The agent's own operational diary describes further offensive action against victims, including renaming a target's bot to a defacement label and watching its payment channel react.
The operation also extended into building applications, not just breaking them. The recovered artifacts include multiple Android packages. One is the actor's own instrumentation: a custom Telegram client (“com.alextelegram.app,” named after the AI persona) built to load Mini Apps in a WebView and read out their “window.Telegram.WebApp.initData” — the same authentication payload the operation's exploits abused. The rest are clones of victim applications. One is a lightweight WebView wrapper carrying a victim's branding, rewired to route users through the actor's own Telegram referral bot. The other is a complete rebuild of a victim app ("SweetBirds," reissued as "RedBirds"), shipped as a pair: a player-facing application with deposit, exchange and withdrawal flows — which still referenced the victim's original backend while routing wallet-connection traffic to a server the operator controlled — and a separate administrative console talking exclusively to that same server. The presence of a purpose-built admin app indicates this was not a proof of concept but a functioning product assembled from a stolen application, with the operator positioned to manage it and receive funds.
Use cases: AI as a bug bounty, vulnerability research, and pentesting accelerator
Throughout this research we came across examples of actors using AI in bug bounty or red team activity. Due to the nature of the work, it is difficult to determine whether the actors are acting on behalf of a client, or whether the narrative exists to coerce the model into bypassing its safety protocols.
Hephaestus red teaming framework
During our research we identified red team toolkits that function as force multipliers, allowing operators to run an operation from reconnaissance through compromise and persistence completely unattended. One such case is the Hephaestus toolkit, which executed multiple campaigns over several months; a full analysis is available here.
The framework packages the tooling needed to compromise a victim and establish persistence with no human action during the process. It draws on several paid online platforms — leaked data aggregators, internet scanning services, and threat intelligence collectors — to gather information on victims, which it then uses to compromise targets. The proliferation of such private packages is likely to grow substantially, since they can be vibe-coded and iteratively improved through automated log analysis by AI agents. Because the same class of tooling has legitimate red team uses, it presents a dual-use problem that blunts the effectiveness of AI providers' guardrails — guardrails that, in the case of local uncensored models, are absent entirely.
The operators achieved unattended execution by decomposing the campaign across many narrowly scoped agents and playbooks. This is the core evasion technique: Guardrails evaluate each request on its own, so a task representing only a small, innocuous-looking fragment of an operation rarely triggers them. The framework defined more than a dozen role-differentiated agents — a scout, a hunter, a navigator, a strike agent, and domain specialists for cloud, CI/CD, and other environments — alongside 15 numbered playbooks, each handling a discrete stage of the process. No single agent held the full mission objective, so no single agent's task resembled an end-to-end attack. Reporting also indicates the operators favored neutral phrasing over overtly offensive terminology in the agent instructions, further reducing the chance that any individual request would trip a safety response.
Based on the artifacts we recovered, the operators were successful in a series of compromises, primarily across Southeast Asian countries. We found little to no evidence of model pushback or guardrail activation.
Vulnerability research pipelines with AI
At times, we saw actors defining very thorough markdown files detailing the activity, including clear in-scope/out-of-scope definitions and the monetary values associated with each class of vulnerability. One such workspace was built around a real Bugcrowd private engagement: Its instruction file listed the authorized in-scope hosts and the explicitly out-of-scope domains, enumerated the excluded vulnerability classes, restricted the model to unauthenticated testing only, and even encoded the program's bounty tiers ($100 – $150 for P4 up to $1,200 – $1,600 for P1). The workspace guided the model through a strict process — reconnaissance, feature mapping, SSRF testing, exposed-secret hunting, attack-chain validation, evidence preservation, and report preparation — with operational rules to write every finding and HTTP request/response pair to disk on capture, prove potential findings with one more targeted test, and defer only when a genuine external constraint prevented confirmation.
This let the actor move quickly across targets, find issues, prioritize by payout, preserve evidence, and generate submission-ready reports with the model doing most of the heavy lifting. The output was voluminous and orderly: more than 40 catalogued findings, each with its own evidence tree and Bugcrowd submission draft. Based on what we could identify, the model cooperated with the bug hunting work without issue, and this appeared to be a legitimate researcher using AI to dramatically increase throughput. There were several examples of this pattern.
On the other hand, Talos found other examples that were less cut-and-dry — where the methodology and the prompts painted a picture of a novice trying to break into vulnerability research or someone with unethical intentions. One conversation opens with a request to pentest a target and collect all its URLs from “web.archive.org.” Notably, in these cases the model frequently pushed back and demanded proof of authorization before proceeding. For example, when asked to test one company's infrastructure, it responded that active enumeration and vulnerability testing without authorization "is unauthorized access under the Computer Fraud and Abuse Act and equivalent laws," and asked the actor to share a bug bounty program URL or written engagement scope. In another instance it drew an explicit line: It would verify read-only findings such as CORS reflection and GraphQL introspection, but "won't execute mutations, create/delete resources, or inject Sentry events — those cross into unauthorized modification of production systems regardless of bug bounty context."
The actor's prompts show the profile plainly. Recurring demands to "use minimum tokens" sat alongside unfocused requests to find critical bugs across every category at once:
Frustration followed when results disappointed, but without any direction on where or how:
The typos and the repeated appeals to "be creative" and try harder — with no targeting of their own — mark an actor leaning entirely on the model to supply both the method and the impact. When vulnerabilities were found, there were repeated requests to build proofs-of-concept specifically around remote code execution (RCE), with the model pushing back and the actor insisting on something to "validate impact." At times, restating that it was "bug bounty" was enough to move the model forward. This even extended to a request to plant a backdoor on the target:
In the end this appears to be an actor trying to leverage AI to submit bug bounty reports in the hope of making money. We have seen this repeatedly: Unsophisticated actors running "bug bounty" activity through AI, then having the model generate and submit the reports — in some cases straight into the actor's email drafts. Such reports are likely low-value, and the submitter will be unable to answer follow-up questions unless their agent can. This creates a challenge for bug bounty programs across the board: a high volume of low-value reports from a large number of actors applying AI to bounties with varying success and little underlying experience in vulnerability hunting or reporting.
AI as a pentesting co-pilot
Another operation contained 64 AI sessions documenting a Brazilian Portuguese-speaking operator's pentesting and bug bounty workflow. The activity covered Brazilian e-commerce and health care sites, a staging software-as-a-service (SaaS) application, and other web services. Some evidence supports legitimate consultancy work; for example, the actor described the activity as a pentest, worked against a homologation environment, maintained test spreadsheets, and supplied a Portuguese security report attributed to a security company. Other evidence, discussed below, cuts against a purely authorized reading.
The operator appears to be a junior-to-intermediate security practitioner but a less experienced developer. They were comfortable with Burp-style requests, Nmap, Hydra, ngrok, common wordlists, and the broad logic of SSRF, IDOR, XXE and rate-limit bypass. At the same time, they repeatedly asked how to run generated code and requested basic explanations of virtual hosts, XML-RPC parameters, cookies, and nonces.
AI was central to this operation rather than an occasional reference tool. The model issued more than 500 shell actions, selected and ran reconnaissance utilities, interpreted responses, generated proof-of-concept code, fixed failures and drafted a vulnerability report.
The actor frequently supplied only the desired outcome. For example, they asked:
AI wrote the tool, ran it, encountered a ModSecurity block, and changed the request headers to resemble WordPress traffic. After the actor supplied an inbound ngrok request, AI treated the callback as confirmation and expanded the workflow toward internal-service and cloud-metadata probing.
The clearest escalation involved WordPress XML-RPC. After demonstrating batched login attempts, the actor instructed AI to "modify it so it can find actual creds" and then to run the RockYou password list. AI transformed the demonstration into a reusable credential tester, corrected its memory behavior, launched it as a background job and monitored its progress. When no password appeared, the actor asked to "bump batch to 500 and add admin username." The preserved log contained around 1.9 million password candidates attempted without a successful login.
AI also packaged payloads that the actor could not readily build alone. During file import testing, the actor supplied an XML variable whose value is loaded from an external resource (XXE), that referenced a local system file, and asked AI to "create the xlsx file." AI constructed the Office Open XML directory structure, embedded the entity in “sharedStrings.xml” and compressed it into an upload-ready spreadsheet.
In another session, the actor used the Portuguese phrase "encontre possiveis vulns" (find possible vulnerabilities) before asking for a GraphQL alias-batching request intended to test authentication rate limiting.
Many conversations show inconsistent safety boundaries. For example, AI refused to run a third-party NGINX heap-corruption RCE exploit against a production website and asked for written authorization. It also recognized and declined a Portuguese HR-themed credential-harvesting form. In other conversations, short assertions such as "it's my own site" or "my own server" were followed by active fuzzing, WAF-bypass work, and credential attacks. The logs also show the actor acknowledging that a shared-hosting address did not belong to the application target, followed later by FTP, MySQL, and SSH password testing against that infrastructure.
AI as the operator behind access control research
One of the discovered operations contained two unusually long AI coding-assistant sessions from a Chinese-speaking operator. The actor repeatedly described the work as capture-the-flag (CTF) participation, but the targets seemed to be live AI and streaming services, including live-camera platforms (“chuye[.]cam”, “ixmax[.]cn”) built on ZLMediaKit, an open-source streaming media server. The activity focused on bypassing monetization controls and consuming hosted AI models without sufficient quota, as well as obtaining live or recorded video without an account, viewing card, or subscription. Because the streaming targets were live surveillance-camera platforms, this "access without an account" amounted to unauthorized viewing of real camera feeds — a more sensitive category than a simple entitlement bypass. The actor frequently encouraged the assistant with prompts such as:
The AI assistant acted as the operation's technical engine. Across the two sessions, it performed more than 4,200 tool actions, most of them shell commands. It installed a broad Kali-oriented toolset, reviewed application source, sent web and media protocol requests, analyzed packaged clients, wrote Python and shell utilities, created a Go-based stream player, assembled Docker environments, and drafted reports. The actor usually provided the goal, credentials, or an occasional hint, while the AI assistant selected and executed the workflow.
The AI-service activity began with a direct request to analyze a gateway derived from NewAPI, an open-source platform that exposes a common OpenAI-compatible API, routes requests to upstream model providers and manages user quotas and billing. Translated from Simplified Chinese, the actor asked the AI assistant to:
They later sharpened the objective:
The streaming work produced more results. The actor instructed the AI assistant to avoid brute force and social engineering, remain behind a proxy, and find the site's livestreams and replay URLs. The assistant extracted client-side configuration, mapped APIs, evaluated JSON Web Token (JWT) authentication and browser fingerprint checks, and inspected object storage.
It then tested for the presence of HTTP Live Streaming (HLS), Flash Video (FLV), and Real-Time Messaging Protocol (RTMP). The assistant eventually found that recordings were directly reachable through the media service using RTMP. Preserved tool output showed several valid recordings, some spanning almost an entire day (~84500 seconds).
The assistant also identified a server-side attack path against the streaming stack itself. Its report documented that ZLMediaKit trusted requests originating from “127.0.0[.]1” without requiring a secret, so a server-side request forgery (SSRF) flaw in the front-end PHP application could be used to reach the media server's internal API (“/index/api/addFFmpegSource”) as a trusted local caller. Chained with FFmpeg's source-URL handling, this created a potential path to remote code execution on the streaming host.
The AI assistant then converted these discoveries into reusable tooling. It created a local player, Docker packaging, and recording scripts so the actor could play, capture, and present recovered streams. The recovered Go binary reconstructs authenticated stream URLs for the target camera platforms — assembling the per-camera HLS playlist and WeChat-share login and room-view requests — and routes traffic through a SOCKS5 proxy, with a hardcoded RTMP ingest endpoint. The actor also packaged a browser-automation bypass tool as a standalone Windows GUI application (built with PyInstaller and PySide6) using a stealth-configured Selenium driver to defeat client-side automation checks.
The operation later escalated from entitlement bypass to attempted host compromise. The actor told the AI assistant to:
The assistant downloaded and adapted exploit code for an alleged new NGINX memory-corruption issue, started a reverse-shell listener and repeatedly tested a public-facing service. The requests produced repeatable crash-like behavior and apparent changes in how some protected paths were routed, but the reverse shell never arrived. The assistant ultimately recorded that RCE had failed after address guessing and heap layout assumptions were unsuccessful.