ARTEX, Cairn, PentAGI Consoles Exposed: What to Hunt

#artex #cairn #pentagi #agentic-ai #ai-security #threat-intelligence #rst-cloud #detection-engineering #threat-hunting #security-leadership #news

November 4, 2026 · PlayCISO · Updated Nov 4, 2026

TL;DR · the short version

On 2 November 2026 RST Labs (RST Cloud) published passive internet-scan counts of three open-source AI pentest harnesses: 1,341 unique IPs verified across Shodan and Netlas on that date (Cairn 56, ARTEX 834, PentAGI 459). RST says the counts are lower bounds, that many consoles likely belong to testers, and that exposure is not proof of misuse. Its argument is that recent intrusions are distinguished by tempo, not technique, a view that matches Microsoft (privileged cloud access in under three hours), CrowdStrike (200+ organisations from 17 October) and ReliaQuest (server takeover in under 24 hours). Defenders should plan for hours, close EDR gaps, hunt behaviour, and keep their own harness consoles off the internet.

Put it into practice

Could you contain an intrusion that moves in hours?

Score your readiness for machine-speed intrusions, get a prioritised fix list and a short summary for your board.

Open the readiness scorecard

This post references: https://www.rstcloud.com/hunting-ai-harnesses-cairn-artex-pentagi/

On 2 November 2026, RST Labs (the research arm of RST Cloud) published "Tempo, not technique", a passive count of internet-exposed consoles for three open-source AI pentest harnesses: Cairn, ARTEX and PentAGI. RST Labs reports 1,341 unique IP addresses verified on that date. It is explicit that this is a floor, that many consoles probably belong to legitimate testers, and that an exposed console is not proof of malicious use. Its main argument is that today's AI-driven intrusions are defined by speed rather than new technique.

Who this is for: CISOs, SOC and threat-hunting leads, identity and cloud teams, and anyone who runs a red team.

Based on RST Labs' article of 2 November 2026 and the primary reports it cites, which we opened on 4 November 2026. We use our own words and do not reproduce RST's tables or screenshots. PlayCISO is not affiliated with any vendor named. We do not publish ways to locate consoles or to run any harness.

Confirmed vs not yet known

RST Labs reports 1,341 unique IPs verified across Shodan and Netlas on 2 November 2026 (Cairn 56, ARTEX 834, PentAGI 459), collected passively with no console accessed. Censys alone, counted separately and not deduplicated, tags roughly 1,800 hosts.

Microsoft says Storm-0940 used ARTEX to attempt sign-ins to more than 2,250 tenants, and that in multiple instances the time from initial targeting to privileged access was under three hours. CrowdStrike reports ARTEX use against more than 200 organisations from 17 October. ReliaQuest says a Cairn-assisted attacker took full administrative control of a server in under a day.

Not established: who runs most of the exposed consoles. RST says many are likely testers and its outside view cannot tell them from attackers. An exposed console is not an intrusion, and tool presence is not attribution.

Also unclear: RST's per-harness counts add up to 1,349, not 1,341. The article does not explain the gap; hosts running more than one harness being counted once in the total is a plausible reason, but that is our guess, not RST's statement.

What RST Labs argues

RST Labs' thesis is that recent campaigns did not need a new exploit. Open-source orchestrators plan the work, hand it to LLM agents and keep going, so the change is how quickly a foothold becomes privileged access. It compares the situation to Cobalt Strike: a dual-use tool used by red teams, researchers and criminals alike, where forks multiply and takedowns change who maintains the code rather than who can run it. For our own explanation of what ARTEX is and how Google GTIG saw it behave, see ARTEX and friends: what GTIG found; this post does not repeat that.

How fast, according to the people who measured it

Who reports it	What they say	Read with care
Microsoft	Storm-0940 used ARTEX to attempt sign-ins to more than 2,250 tenants; multiple instances where initial targeting to privileged access took under three hours	Sign-in attempts, not confirmed compromises. A separate spray against 327 accounts at eight organisations (10 to 14 October) produced no successful authentication, token issuance, Graph call or directory change
CrowdStrike	From 17 October the actor it tracks as VAPOR PANDA used ARTEX against more than 200 organisations worldwide	The detailed case studies cover far fewer organisations, and the post presents the wider figure as a count of targets
Google GTIG	Individual ARTEX execution sequences ran in bursts of roughly 2 to 25 seconds	Describes seconds-level cadence inside a longer intrusion, not time to compromise
ReliaQuest	Full administrative control of a server in under 24 hours, from one unauthenticated job-submission feature, with a live Cairn dashboard on the address that created the malicious jobs	ReliaQuest says Cairn's public source does not contain the incident's output wrappers or chunking logic, so it does not attribute those details to Cairn itself
VULONE	One operator ran 66 projects against government targets in Vietnam, Taiwan, Indonesia and India; an estimated 36.7 billion LLM tokens	VULONE calls the operator China-linked, Chinese-speaking and financially motivated and says it found no evidence of state sponsorship in the artifacts examined. It also warns that language signals can be manufactured

These numbers measure different things (first contact to privilege, burst length, time to server takeover), so do not add them up or read them as one benchmark. What they share is the unit: hours, not weeks.

How the exposed consoles were counted, and why the number is soft

RST Labs says it collected data passively from Shodan, Netlas and Censys, counted unique IP addresses, and accessed no console. A host counted only when a harness-specific match found it, or a broader match was corroborated by a harness-specific marker in stored content; lookalike pages were removed by hand. A targeted Netlas scan of selected ranges added hosts the public crawls had missed. RST reports these cautions:

Scanners disagree. The same console title returned very different host counts on different engines, so any single-source number undercounts.
Titles mislead. RST says a search on the word "Cairn" returned 407 hosts, of which 56 were Cairn. Forks and localised builds carry other titles, and some ARTEX hosts show nothing but an authentication challenge.
Stronger signals exist. At category level, RST ranks title as the weakest signal, then port, favicon and certificate, with code in the page itself the strongest and the most resistant to forks. It deliberately withholds those durable fingerprints so fork authors cannot evade them; we follow that choice and point you to its article for the method.
Concentration. RST says roughly 300 ARTEX consoles sit in one network block, with a smaller PentAGI cluster in another, and that the US hosts the largest share of each family. Country is where the server is, not where the operator is.
Reputation does not help. RST found VirusTotal scores did not separate hunted hosts from stock consoles; higher scores tracked shared or abused hosting. A zero means unreported, not safe.
Testers are in the mix. RST states plainly that many exposed consoles likely belong to legitimate testers, and some have a login page. Since its scans do not sign in, a login page does not stop the console being found.

Forks and copies

RST names derivatives, among them ScopeWeaver (a Korean and English ARTEX localisation), BaaRai's ARTEX fork and VulnFlow IoT, and says the BaaRai fork adds a browser extension that captures authenticated sessions for reuse after a single MFA prompt (an RST statement we did not verify in the repository). GTIG likewise names ScopeWeaver and a commercial "ARTEX PRO". On 4 November 2026 we saw the following on the repositories' own pages; star and fork counts move, so treat them as a snapshot at that date:

oritera/Cairn: public, about 4.8 thousand stars and 927 forks, AGPL-3.0.
cskwork/scopeweaver: public, 883 stars and 731 forks, described as an English and Korean localisation of ARTEX.
BaaRai/ARTEX: public, about 1.3 thousand stars and 495 forks, described as an English translation of ARTEX.
The original ARTEX repository address returned "not found". GTIG says its creator removed it because of abuse; RST says it was hidden after abuse reports.

The point for defenders is that popularity and forks mean any name-based list ages in days.

More vendors, and claims we could not confirm

Confirmed at a primary page (4 November 2026). Besides Microsoft, CrowdStrike and GTIG, Palo Alto Networks' Unit 42 timely threat intel note of 30 October 2026 describes intrusion attempts against multiple targets that it assesses used ARTEX or an ARTEX-derived framework between 24 September and 27 October 2026. It reports more than 700 denied attempts against internal applications, about 50 MB of API data read from one production web application through self-registered accounts, and no successful account compromise at the identity providers it saw probed. Unit 42 says attribution is behavioural, it did not observe the model used, and ARTEX use alone does not identify an actor. A vendor's social post pointed to this note through a short link; that link resolves to the Unit 42 page.

AhnLab's ASEC has a series on ARTEX infrastructure. Its part 4, "The Birth of Copy Cat" (15 October 2026) says that after the original repository disappeared, rebranded and customised copies appeared, and it describes one ARTEX-based environment with signs of exploitation activity and several LLM backends. That page does not mention Korean financial institutions. The claim that AhnLab confirmed ARTEX in attacks on Korean financial institutions is therefore reported by a researcher; not verified here. CrowdStrike's separate 7 October report on South Korean finance is covered in our GTIG post.

Claimed, not confirmed

Mass deployment. A researcher on social media says hundreds of ARTEX instances are appearing across several VPS providers, with large clusters on certain registered ranges, and suggests a distributed attack network. RST Labs' own data differs in detail: its largest ARTEX cluster, about 300 consoles, sits in a network whose WHOIS record names one carrier but which that carrier does not announce, which RST reads as a reseller or VPS provider. Which provider hosts them is unresolved, and hosting on a provider says nothing about that provider's conduct. We could not verify the social-media claim, and a cluster of consoles does not show one operator.
One shared build. The same researcher says instances share identical response headers, which would suggest one image or template. That is an inference; we do not print the values, because they would help locate consoles. A shared build does not show a single operator, since anyone can deploy a published image.
A backdoor in the ARTEX repository. One unnamed poster says the repository contains a backdoor and promises more details. We found no evidence for this, and we do not speculate on any mechanism. If anyone in your organisation ran code from a copy of the repository or from a fork, review it as untrusted code, run it only in isolation and rotate any credentials it touched.

If you find an attacker's open directory. Researchers report that exposed attacker directories often hold agent artefacts: agent project folders, session transcripts, generated reconnaissance reports and configuration files that contain LLM API keys. A threat-intel platform user has shared hunting queries over a dataset of such captures; we do not reproduce them, because the same patterns find other people's exposed credential files. If you come across such material, treat the contents as sensitive evidence, report it to the hosting provider or owner and to your national CERT, and never use or log any credentials you see.

Hijacked consoles: the exposure risk for your own team

NorForge reports that attackers inserted malicious tasks into at least 17 exposed Cairn panels, from about 20 October. It describes two provisional clusters, AIA0009 and AIA0010, says it found no conclusive evidence they are one actor, and says tasks tried to harvest secrets including AI model API keys, to place an SSH key, and, in the AIA0009 case, to fetch a Poseidon implant that the panel's agent in several cases ran. NorForge shows secret-hunting tasks; it does not document a confirmed API key theft. The takeaway holds without the detail: a harness console on the internet is a remote-control surface for whoever reaches it, and an agent with shell access to your jump host will follow instructions.

Blocklist feeds you can ingest: ThreatBook's ARTEX and CSAI lists

ThreatBook publishes two plain-text address lists, ARTEX.txt and CSAI.txt, each with a "last updated" line and one address:port per line. When we downloaded them on 4 November 2026 (stamped 11:02:14, timezone not stated), ARTEX.txt held 336 entries on 272 unique addresses and CSAI.txt held 938 entries on 838 unique addresses. The files do not say what each list covers, how an entry was verified, how long it stays listed, or whether the hosts belong to attackers or to testers. We do not know what "CSAI" stands for: ThreatBook has publicly associated itself with other AI pentest agents, but the file says nothing, so we do not guess. We also do not reproduce the addresses here: they are ThreatBook's data, change often, and a list of live consoles is more useful to a scanner than to a reader.

What the shape suggests. The ARTEX list is mostly web ports (443 and 80 account for 235 of the 336 entries). The CSAI list is dominated by a few alternative ports, 8080 and 8444 above all, and includes runs of consecutive addresses in the same range, which fits a block of rented servers. That is our reading of the file, not ThreatBook's statement.
Use them as a lead, not a verdict. RST Labs says many exposed consoles belong to legitimate testers, and an address can change hands within days. Match them against your outbound logs, proxy and DNS data to find who in your estate talks to these hosts, then triage; do not auto-block production traffic on a single-source list without a review step.
Handle them as a snapshot. Re-fetch before each use, keep the timestamp with any detection that uses them, and check ThreatBook's terms of use before redistributing the files.
Cross-check. An address on both a vendor list and RST's passive counts is a stronger lead than an address on one. Neither source publishes a full list we can compare, so this is a manual step.

Timeline

Date	Event	Source
24 Sep to 14 Oct 2026	Operation window VULONE describes for the Cairn operator who ran 66 projects	VULONE
7 Oct 2026	ReliaQuest publishes its Cairn-linked server takeover case	ReliaQuest
10 to 14 Oct 2026	Password-spray campaign against 327 accounts at eight organisations, with no successful sign-ins	Microsoft
17 Oct 2026	CrowdStrike says VAPOR PANDA begins using ARTEX against 200+ organisations	CrowdStrike
18 to 19 Oct 2026	VULONE publishes its report (the page shows two dates)	VULONE
About 20 Oct 2026	NorForge says hijacking of exposed Cairn panels starts in earnest, possibly earlier	NorForge
21 Oct 2026	Microsoft publishes its Storm-0940 and ConnectWise analysis	Microsoft
29 Oct 2026	CrowdStrike publishes the VAPOR PANDA report	CrowdStrike
30 Oct 2026	GTIG publishes "ARTEX and friends"	Google GTIG
2 Nov 2026	RST Labs publishes its exposure counts and hunting guidance	RST Labs

What to hunt: behaviour, each with the source that reported it

Machine cadence. Bursts of seconds between steps and self-correcting retries: GTIG, who also reports probe markers in file and account names. ReliaQuest warns that cadence is a signal to combine with others, not a detector on its own.
Machine-formatted output and fixed-size retrieval. ReliaQuest saw data retrieved through error messages in fixed 1,800-byte chunks across hundreds of requests. RST lists fixed-size exfiltration chunks and VULONE an ASCII-only payload rule as behaviours.
Sign-in, then directory enumeration. Microsoft lists python-urllib and python-requests user agents performing sign-ins and Graph activity on customer environments using ConnectWise apps, plus extensive SharePoint enumeration through Graph.
An application that gives itself a role. Microsoft describes an application adding itself to a high-privilege role, and has Defender alerts for self-assigned privileged roles and high-privilege application roles on a service principal.
Callbacks to public webhook services from servers that have no business with them. GTIG reports 491 rotating webhook.site URLs for command-and-control.
Hosts without EDR. CrowdStrike quotes one operator instruction to find Windows machines without Falcon, which it reads as concentrating follow-on activity on unprotected hosts. It presents this as an observed instruction rather than a rule for every case, and recommends EDR on servers not reachable from the internet too.
Tool-name strings. CrowdStrike lists "artx" or "artex" in command lines and cloud role names; GTIG lists "artex-probe" files and "ArtexProbe" accounts. These are cheap to search and cheap for an operator to change, so keep them as a bonus.

Practise telling machine from human activity in the agent defense evasion hunt and build the plan in hunt plan review.

What security leaders should do this week

Plan for hours. Agree who may disable an identity and revoke its sessions without a meeting, and automate containment for password-spray and Graph-enumeration patterns. Test it in the agent kill-switch drill lab.
Close EDR gaps. List Windows servers and workstations with no sensor, starting with those on the same network as internet-facing systems.
Hunt the behaviours above in sign-in, Graph and cloud audit logs for the last 30 days, and write each as a detection that survives a rename.
Review service principals. Alert on any application that assigns itself a role, and on python user agents in sign-in logs from apps that should not use scripts.
Never expose your own red-team console. If your testers use an AI harness, require that its console sits behind a VPN or an authenticating proxy, that it runs on an isolated host with scoped credentials, and that model API keys are not stored on it. The agent environment readiness check and the local vs managed AI agents guide cover the isolation questions.
Watch your own exposure. Ask your attack-surface vendor or tester to confirm that none of your address space answers with a harness console, including in cloud projects and short-lived VPS instances.
Limit egress. Block or alert on servers talking to public webhook services; practise in the agent egress containment lab.
Score yourself with the Agentic Attack Readiness Scorecard.

For background on PentAGI, one of the three families, see our PentAGI explainer.

Frequently asked questions

How many AI pentest harness consoles are exposed on the internet?

RST Labs reports 1,341 unique IP addresses on 2 November 2026 that it verified as running a Cairn, ARTEX or PentAGI console, using passive data from Shodan and Netlas (Cairn 56, ARTEX 834, PentAGI 459). Censys, counted separately and not deduplicated, tags roughly 1,800 hosts. RST calls every figure a lower bound, and says many of the consoles probably belong to legitimate testers.

Does an exposed ARTEX, Cairn or PentAGI console mean the owner is a hacker?

No. These are dual-use open-source tools. RST Labs says red teams, researchers and CTF players run the same code as criminals and state actors, that exposure is not proof of misuse and that tool presence is not attribution. An exposed console is a risk to its owner either way, because NorForge reports attackers taking over exposed Cairn panels.

How fast are AI-harness intrusions?

Microsoft says Storm-0940 reached privileged cloud access in under three hours in multiple instances after initial targeting. ReliaQuest says an attacker with a Cairn dashboard took full administrative control of a server in under 24 hours. GTIG says individual ARTEX execution sequences ran in bursts of roughly 2 to 25 seconds. These are the reporters' own measurements and different starting points, so they are not directly comparable.

How do you detect an AI pentest harness in your environment?

Hunt behaviour rather than tool names. Reporters describe machine-cadence bursts, self-correcting retry sequences, fixed-size data retrieval chunks, python-urllib and python-requests user agents in sign-in and Graph activity, an application that signs in and then assigns itself a privileged role, callbacks to public webhook services, and operator-chosen markers such as "ArtexProbe" accounts. CrowdStrike also reports hosts without EDR being picked first.

Is the original ARTEX repository still online?

GTIG says its creator took the original repository down in October 2026 because of abuse, and RST Labs says it was hidden after abuse reports. When we opened the original address on 4 November 2026 it returned "not found". Community copies and forks remain, including ScopeWeaver, a Korean and English localisation, and an English translation under another account. Takedown changed who maintains the code, not who can run it.

Should my red team run ARTEX, Cairn or PentAGI?

That is a risk decision for your own governance, not something this article recommends. If a harness is used, RST Labs' advice is to keep its console off the public internet, behind a VPN or an authenticating proxy, because NorForge documents attackers inserting tasks into exposed Cairn panels to steal secrets and run malware. Treat the harness host like any other privileged jump box.

Is ARTEX being mass deployed?

Not established. A researcher on social media says hundreds of ARTEX instances are appearing across several VPS providers and suggests a distributed attack network; we could not verify that. RST Labs' passive counts show many ARTEX consoles (834 verified on 2 November 2026) with about 300 in one network block, but RST says many consoles likely belong to testers and does not say they are one operation. Vendor reports (Microsoft, CrowdStrike, Unit 42, GTIG) confirm ARTEX in live attacks, which is a different claim from mass deployment by one party.

Does an identical response header prove one operator?

No. A researcher on social media says many instances return identical HTTP response headers; if true, that suggests a shared build, such as one published image or template. A shared build does not show a single operator, because anyone can deploy the same published code. Treat it as a clue for grouping hosts, not as attribution.

Is there a public blocklist of ARTEX hosts?

ThreatBook publishes two plain-text address lists, ARTEX.txt and CSAI.txt, which on 4 November 2026 held 336 and 938 entries (272 and 838 unique addresses). The files give no explanation of scope, verification or expiry, and many listed hosts may belong to testers, so use them as a lead to check against your outbound logs rather than as an automatic block. Re-fetch before each use and keep the timestamp.

Why not just block the harnesses by name or title?

RST Labs says titles are weak evidence: a search on the word "Cairn" returned 407 hosts, of which only 56 were Cairn, and forks and localised builds appear under other titles. RST also withholds its durable fingerprints so fork authors cannot evade them. For defenders the practical lesson is to track forks and behaviour, not product names.

Sources

Could you contain an intrusion that moves in hours?

Score your readiness for machine-speed intrusions, get a prioritised fix list and a short summary for your board.

Open the readiness scorecard

Breach Index

Microsoft: breach history and security posture →CrowdStrike: breach history and security posture →