The FBI reports that some intrusions using ARTEX progressed from initial targeting to privileged access in less than three hours. The techniques were recognizable: stolen supplier credentials, exposed application secrets, vulnerable web services and excessive cloud permissions. ARTEX automated the work of testing those openings and moving between them. [1, pp. 1–5]
The November 13 FLASH brings together activity observed since at least August 2026. It describes how attackers checked the permissions of credentials they had obtained, added new credentials to existing applications, and used legitimate interfaces to reach mail, databases and cloud storage. For responders, closing the initial entry point is only part of the job: they also need to establish what the attacker changed after getting in.
ARTEX is a framework for coordinating penetration testing agents and tools through external language models. Its legitimate testing purpose does not prevent malicious use. The original repository was removed in October, but copies and forks remain available. The FBI’s report covers several campaigns; its examples should not be read as one intrusion or attributed to one operator.
What attackers did with cloud credentials
The most useful technical detail in the FLASH is the testing of effective permissions. After obtaining credentials, attackers used small operations to find out what those credentials actually allowed. In Azure, the FBI lists SAS tokens, service principals, Kudu credentials and storage account keys. The probes included test blob writes and deletes, checks completed in fractions of a second, and Azure Resource Manager deployment validation. In AWS, attackers tested compromised IAM user permissions with DryRun requests. [1, p. 3]
These operations can resemble deployment or administration activity when examined individually. A storage test becomes more significant when the same identity also validates deployments against several resource types or starts changing credentials. Investigators need the sequence, its source and the identity involved.
Credentials obtained
Azure SAS tokens, service principals, Kudu credentials and storage account keys.
Permissions tested
Blob writes and deletes; ARM deployment validation. AWS IAM checks using
DryRun.Access extended
Additional OAuth application credentials, new SSH keys and cloud instances with privileged roles.
Techniques reported across several intrusions, grouped here for investigation. [1, pp. 3–5]
The persistence mechanisms deserve a separate review. An attacker who adds a credential to an existing OAuth application has created another way to authenticate as that application. Rotating the credential originally stolen does not remove the additional one. The FBI also records web shells, new accounts, SSH keys and abuse of Kudu administrative APIs to execute commands. Recovery has to account for those changes, not just the vulnerable service or leaked secret that started the incident.
ConnectWise: 2,250 tenants does not mean 2,250 confirmed breaches
The FLASH cites the ConnectWise Cloud Backup campaign as a major example of supplier access being used against customer environments. Its summary uses broader language about access to more than 2,250 tenants. Microsoft’s underlying investigation describes attempted authentication against that number of tenants and explicitly cautions that even successful authentication does not, on its own, establish data access or exfiltration. We retain that narrower interpretation. [2]
For organizations investigating that campaign, the FBI’s instructions are specific:
- Find affected applications by application ID, not display name. Include tenants where the integration was previously authorized, even if it is no longer in use.
- Review successful and failed service principal authentication separately, starting from at least October 1, 2026. Extend the review earlier if related activity appears.
- Inspect application and service principal credentials, owners, consent grants, application roles and privileged role assignments.
- Preserve Entra, Purview, SIEM and previously configured Graph records. Do not wait for every export to finish before containing confirmed unauthorized access.
- Keep connections affected by the incident disabled until ConnectWise provides formal restoration instructions. Deleting the enterprise application first can remove configuration needed for the investigation.
Those instructions come from the FLASH’s response section. They concern the Cloud Backup campaign, which is separate from the ScreenConnect RMM+ investigation. The two cases have different scopes and recovery guidance. [1, pp. 10–11]
The entry point may be a secondary application
The FBI describes unsigned SAML assertions, anonymous file uploads, missing API authentication, SQL injection and administrator passwords embedded in browser JavaScript bundles. It also lists partner federation and trust between cloud accounts. These are different entry conditions; there is no single ARTEX vulnerability or patch.
The report repeatedly points to systems outside the main application: partner portals, mobile backends, old employee services, sales tools and supplier integrations. Their credentials and permissions may connect them to more sensitive resources. An assessment focused only on the main website can miss those connections.
Kudu/SCM publishing endpoints are one concrete example. The FLASH recommends restricting them to approved management networks or deployment infrastructure, disabling basic publishing authentication when unnecessary, and controlling access to publishing credentials. It also recommends scanning application configuration, build artifacts, repositories and deployment pipelines for embedded secrets. [1, pp. 3–4, 9–10]
Which records help establish what happened
The FLASH includes network indicators, but warns that cloud IP addresses can be reassigned. An address from an October incident is not a permanent identification of the attacker. The same caution applies to model API traffic: a connection to an AI provider can belong to an approved application. Neither should be treated as proof without corroborating activity.
| Environment | Records to collect |
|---|---|
| Microsoft applications |
|
| Azure and AWS |
|
| Customer portals |
|
| AI services and proxies |
|
The FBI also asks for failed attempts and duplicate requests, including cases where agents appeared to overwrite each other’s work. Those details matter: the activity was not uniformly successful. The FLASH records lateral movement blocked by endpoint protection, and Google documents a failed cloud escalation attempt involving invalid instance profile identifiers. [1, pp. 5, 8–9] [3]
What to review before the next incident
Application permissions. List the integrations that can read mail, retrieve customer records, modify deployments or create credentials. Confirm who owns each integration, why it needs those permissions and how responders can revoke them. A user password reset is not a substitute for reviewing application credentials and grants.
Administrative exposure. Check publishing interfaces, backup platforms, hypervisors and cloud administration alongside web applications. The FBI recommends approved networks, private connectivity or dedicated administrative access for these services. Removing unnecessary public access reduces the number of places an attacker can test directly.
Bulk operations. Enforce authorization for each customer record, restrict returned fields, and apply limits appropriate to the function. The FLASH names recipient limits for notifications, transaction thresholds and alerts for abnormal volumes. A valid session should not automatically permit an unrestricted export. [1, pp. 9–10]
Containment. With an authorized test identity, verify that responders can revoke an integration’s access and confirm that subsequent requests fail. Record the time required and any permissions that remain. This is Oktsec’s proposed test, based on the access and persistence problems in the report; it is not a test the FBI performed on Oktsec.
What the report does not establish
Less than three hours is an observation from some intrusions, not an average or a deadline that applies to every organization. The approximately 67,000 people cited in the FLASH belong to reported campaigns against South Korean financial institutions, not a worldwide victim count. The report also combines observations from different researchers and periods.
One numerical discrepancy remains unresolved: the FBI cites more than 1,600 exposed ARTEX consoles in early November, while the Censys article it references reports 1,465 hosts at its November 4 measurement. Neither number establishes how many deployments were malicious or how many organizations were compromised. [1] [4]
For teams deploying their own agents, the relevant check is equally concrete: can the agent’s credentials create another credential, grant a role or export data beyond the assigned task? Test those permissions at the API, using agreed test data and scope. Our earlier ARTEX analysis covers the associated cloud and identity controls in more detail.
Sources
- FBI, Threat Overview of ARTEX Autonomous Penetration Testing Framework. FLASH-20261113-001, November 13, 2026. TLP:CLEAR. Primary source for the techniques and response guidance discussed here.
- Microsoft Security Research and Threat Intelligence, ARTEX and the ConnectWise application compromise, October 21, 2026. Source for the distinction between authentication attempts and confirmed data access.
- Google Threat Intelligence Group and Mandiant, ARTEX and Friends: Enter Agentic Offensive Frameworks, October 30, 2026.
- Censys, ARTEX: Agentic Asbestos, November 5, 2026; measurement dated November 4.
Reviewed November 13, 2026. Oktsec analyzed the public reports and did not investigate the underlying intrusions.