Artex in the wild: Lessons from responding to agentic AI attacks

In October 2026, S-RM responded to several severe network intrusions impacting separate organisations, all of which bore the hallmarks of an agentic AI attack using a tool called Artex. In this article, we examine what we saw across these incidents, how we identified the use of Artex, and the lessons we learned from responding to these complex attacks.

What are we seeing?

Last month, S-RM responded to a number of incidents in which we identified threat actors using Artex, an agentic AI penetration testing framework that uses agents to orchestrate conventional security tools, interpret their results, and determine the next step in the attack chain. Originally released as an open-source project, Artex was made private following reports of misuse, including its involvement in attacks against financial institutions in South Korea. However, the code had already been copied and forked multiple times and remains generally available.

Even before confirming Artex’s involvement, our investigators noted similarities across the intrusions:

• The attacks began the same way: In each case, the earliest identifiable activity was probing of internet-facing infrastructure followed by exploiting a vulnerability in a web server, either by targeting a vulnerable plugin or a misconfigured upload function. From this foothold, the Artex agents extracted credentials for the systems that hosted the web server and then attempted to break out to the management plane and other hosts.
• Intent to widen access: After gaining initial access, Artex repeatedly cycled through a process of 1) identifying an exposed credential or credentials, 2) testing it on all relevant systems, 3) then moving to the new system, Artex built up a host of compromised identities across different systems before pursuing its final objectives.
• Speed: In each case Artex operated at an incredible pace. Where attacks were once constrained by a hacker’s need to assess what they’d found and plan their next move, defenders had little opportunity to react as agents rapidly moved through the network. In one intrusion, the agents went from initial access to compromising all identity infrastructure, cloud systems, source code and perimeter firewalls in just 24 hours. In another, they pivoted from a web server to central management platforms across a sprawling network in just four hours. The ability to conduct two or three attack chains at once compounded the challenge: as defenders identified and responded to compromised systems, the agents were already active elsewhere in the environment.

What links the activity to Artex?

While the intrusions displayed typical indicators of agentic AI attacks, including self-annotated commands and the rapid parallelisation of activity across different systems, several indicators linked the activity specifically to Artex:

• Tools tagged with a counter: Scripts, VMs, keys, accounts, and other tools were tagged throughout the intrusion, usually with “i<number>”. This value represents the agent’s task and increases as the attack progresses. Artex’s GitHub repo states each AI agent’s working folder as tasks/<taskID>/i<intentID>/, matching what we observed in our investigations.
• IP address: In one incident, we scanned the threat actor’s IP address and it returned a Next.js application titled “ARTEX – Autonomous pentest console”. The TLS certificate was self-signed with subject and issuers C=CN, O=ARTEX.
• SQL accounts, jobs & strings: During SQL intrusions, Artex was a common marker in the SQL queries, such as “ARTEX' UNION SELECT 1—” and “ARTEX'/**/AND/**/2>1—".
• User agents: Artex allows operators to change the user agent, so the default artex-enrich/1.0 user agent was not seen in our cases. However, we did observe norma/0.4 user agents, which Artex’s own repo states is the tool’s web-fetch SDK user agent, alongside more generic curl and python user agents.
• Task folders: We identified the Artex agents sending local commands to their remote shells, resulting in task folders appearing on the compromised host: “/opt/artex/data/task/<task number>/i4028/i4028.asp”.
• GitHub branch names: We observed Artex creating disposable GitHub branches and titled them “artex-wtest-<number>” with readme files containing the string “probe”.
• Placeholder email addresses: The agents repeatedly used test email addresses during the intrusions which conformed to the following patterns “<taskID>@example.invalid” and “<taskname>artex<intentID>@example.com”.

What was the motive?

In all the cases we responded to, the intrusions were identified and contained before the agents could complete their intended impact. However, the attacks appeared to have various motives, including:

1. Supply chain attack. The Artex operators in one case attempted to compromise a Managed Service Provider (‘MSP’) to regain access to a company that had already contained a previous Artex intrusion. After gaining access to the MSP’s network, the agents created their own virtual machines and ran queries focused on just one of its thousands of customers. They targeted cloud and identity systems related to that customer, before attempting to hijack infrastructure to grant it access to the target company.
2. Card skimming. In another, the operators attempted to monetise the intrusion through the extraction of customer credit card information. The agents set up two credit card skimmers and placed them on the victim’s websites in an attempt to re-route credit card data back to a command and control server. Interestingly, the command and control server was used in previous credit card skimming campaigns in 2025 and 2026 which were not linked to Artex or agentic AI, suggesting the operators of that infrastructure were established cybercriminals and had evolved their tactics recently by adopting Artex.
3. Unknown but potential for mass disruption. In multiple cases, while the intent of operators using the agents was unconfirmed (they were detected and interrupted while they were still laterally moving between systems and conducting credential theft), the agents tried to get into every possible system: identity, cloud, CCTV, code repositories, databases and even physical building control systems. What the operator intended to do with this access is unclear, but the potential impact was significant.

What next?

Just a year ago, there was little evidence of cybercriminals using AI except to analyse stolen data or craft extortion communications. Fast forward to November 2026 and we are already responding to highly complex intrusions executed by AI agents. It is highly likely that Artex, and tools like it, will drive more incidents over the coming months.

• It is already being used by different threat actors. Artex is seemingly being adopted and used by threat actors with varied motives and profiles – cyber extortionists, card skimming groups, espionage groups and some with less clear motives. Reports suggest some actors have already used Artex in breaches which resulted in extortion. While we are likely still in the early adoption phase, we expect established ransomware gangs and data theft crews to incorporate Artex into their playbooks soon.
• It follows a trend of cloud and web app targeting. In our caseload, ransomware fell from 40% of cases in Q1 to 28% in Q3, while web application and cloud compromises increased more than 200% in the same period. This does not mean ransomware is disappearing: incident volumes remain broadly stable, but its share of our caseload is falling as cloud and web application compromises grow faster. Artex has proven highly capable at compromising web applications and cloud infrastructure, both of which are attractive targets: access to cloud environments can quickly lead to compromised identities, secrets, applications, source code, build pipelines and other services, while web applications present an internet-facing ingress route to access important databases or pivot into the network.
• Artex lowers the barrier to entry. Our experience suggests Artex will act as a force multiplier, simultaneously lowering the barrier to entry for less sophisticated actors while significantly increasing the capability for all threat actors to stage sophisticated attacks. Not only does Artex provide significantly improved capabilities, it also gives financially motivated actors like card skimming crews the ability to scale their operations far beyond previous constraints.

Defences will eventually adapt to meet the threat. We have seen this pattern before – each new tool or technique adopted by threat actors gives them the advantage before responders catch up: email filtering and endpoint detection to defend against malicious documents and trojans, multifactor authentication to mitigate the risk of stolen credentials, patching and attack surface management to prevent software exploits. Artex is the next step in that cycle and response teams will have to find solutions which can detect and contain activity at the same pace. The answer longer term might be security AI agents empowered to contain and recover systems at speed, but in the meantime, there is a gap. It is this gap which we assess will drive increased attacks in the short term.

Responding to Artex intrusions

1. Do not rely on IP blocks. In one intrusion, when we blocked an IP address, Artex pivoted within 10 minutes and began utilising TOR exit nodes and other VPS infrastructure across 50+ IP addresses. IP blocks alone will not stop the activity.
2. Prepare for containment actions to be decided at pace. Containment actions such as network isolation and credential resets need to take place at speed. Organisations should establish pre-approved authorisation in advance based on specific scenarios and triggers.
3. Prepare for persistence. In one case, the Artex agents regained access to the environment on three separate occasions and after each round of containment they pivoted to find another route into the network. Containment and recovery plans should account for a more persistent threat actor than human operators.
4. Create custom detection rules. Use the indicators detailed above to create custom detection logic which alerts on the creation of files matching the “i<3 to 5 digit number>” format; database queries containing artex strings; the appearance of folders matching opt/artex; and generic string matching alerts in SIEMs for ‘artex’ and ‘artx’.

The information contained herein is intended for informational purposes only. Insurance coverage in any particular case will depend upon the type of policy in effect, the terms, conditions and exclusions in any such policy, and the facts of each unique situation. No representation is made that any specific insurance coverage would apply in the circumstances outlined herein. Please refer to the individual policy forms for specific coverage details. S-RM does not assume, and shall have no liability for the control, correction, continuation or modification of any existing conditions or situation.

If you would like to discuss the implications of agentic AI attacks for your organisation, or need support responding to an intrusion, contact S-RM’s Cyber team.