Threat actors use agentic AI tooling (ARTEX) to find and abuse exposed secrets in GitHub and Azure

Key facts for ARTEX AI credential abuse

Detection coverage for ARTEX AI credential abuse

As of 2026-11-06, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5363 across Splunk SPL, Microsoft KQL and Sigma, covering 14 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: ARTEX Leaked Service Principal Sign-In from Campaign Infrastructure

Detects successful Entra ID service principal sign-ins from the Microsoft-listed ARTEX campaign IPs (199.19.77.84, 199.19.77.18 Tor exit, 65.87.223.26, 157.22.126.128) or from any single source IP authenticating as 3+ distinct service principals in one hour (leaked workload-identity credentials replayed across tenants, observed from 2026-10-28).

• Languages: Splunk SPL, Microsoft KQL, Sigma
• ATT&CK: T1078.004, T1552.001, T1550.001, T1090.003
• Data sources: azure_ad_serviceprincipal_signin_logs
• Severity: high
• Confidence: high

Splunk SPL

index=azure sourcetype="azure:monitor:aad" category=ServicePrincipalSignInLogs ```TL-2026-5363 ARTEX leaked service principal credential replay```
| eval src_ip='properties.ipAddress', sp_id='properties.servicePrincipalId', sp_name='properties.servicePrincipalName', app_id='properties.appId', resource='properties.resourceDisplayName', err=coalesce('properties.status.errorCode',0)
| where err=0
| eval ioc_hit=if(in(src_ip,"199.19.77.84","199.19.77.18","65.87.223.26","157.22.126.128"),1,0)
| bin _time span=1h
| stats count as signins dc(sp_id) as sp_count values(sp_name) as sp_names values(app_id) as app_ids values(resource) as resources max(ioc_hit) as ioc_hit by _time src_ip
| where ioc_hit=1 OR sp_count>=3

Microsoft KQL

// TL-2026-5363 ARTEX leaked service principal credential replay
let ioc_ips = dynamic(["199.19.77.84","199.19.77.18","65.87.223.26","157.22.126.128"]);
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0"
| summarize SignIns=count(), DistinctSPs=dcount(ServicePrincipalId), SPNames=make_set(ServicePrincipalName, 25), AppIds=make_set(AppId, 25), Resources=make_set(ResourceDisplayName, 25) by IPAddress, bin(TimeGenerated, 1h)
| extend IocIp = IPAddress in (ioc_ips)
| where IocIp or DistinctSPs >= 3
| project TimeGenerated, IPAddress, IocIp, DistinctSPs, SignIns, SPNames, AppIds, Resources

Sigma

title: ARTEX Service Principal Sign-In from Campaign Infrastructure
id: 5b1c7a52-3f0e-4c8d-9a41-6d2e8f1b7c01
status: experimental
description: Detects successful Entra ID service principal sign-ins from IP addresses Microsoft attributes to the ARTEX agentic secret-abuse campaign. The multiple-service-principals-per-IP variant is covered in the SPL and KQL forms.
references:
  - https://www.microsoft.com/en-us/security/blog/2026/11/05/threat-actors-use-agentic-ai-tooling-to-find-and-abuse-exposed-secrets/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026/11/06
tags:
  - attack.initial-access
  - attack.t1078.004
  - attack.credential-access
  - attack.t1552.001
  - attack.defense-evasion
  - attack.t1550.001
  - attack.command-and-control
  - attack.t1090.003
logsource:
  product: azure
  service: serviceprincipalsigninlogs
detection:
  selection_ip:
    IPAddress:
      - '199.19.77.84'
      - '199.19.77.18'
      - '65.87.223.26'
      - '157.22.126.128'
  selection_success:
    ResultType: '0'
  condition: all of selection_*
falsepositives:
  - Authorized penetration tests or red-team activity from the listed addresses
  - Shared Tor or hosting IP space later reassigned to a legitimate tenant workload
level: high

Known false positives:

• Authorized red-team or pentest traffic from the listed IPs
• Reassigned hosting/Tor IP space now used by a legitimate workload

Tuning notes: Keep the IOC list in a lookup/watchlist and refresh from Microsoft/Todyl reporting. Raise or lower the 3-service-principal threshold for multi-tenant CI/CD egress IPs; allowlist known NAT egress of your pipelines. Requires Entra ID ServicePrincipalSignInLogs exported to Splunk (index=azure) or Sentinel.

• 🔒 ARTEX Service Principal Multi-Resource Token Fan-Out · unlock with TL Creds
• 🔒 ARTEX Service Principal Calling Secret-Returning ARM Operations · unlock with TL Creds
• 🔒 ARTEX Adaptive Retry with Changed API Version After HTTP 400 · unlock with TL Creds
• 🔒 ARTEX Default Tooling User Agents on App-Only Microsoft Graph Calls · unlock with TL Creds
• 🔒 ARTEX App-Only Graph Mailbox, SharePoint and Content Search Burst · unlock with TL Creds
• 🔒 ARTEX Campaign IP Activity Across Entra, Graph and Azure Logs · unlock with TL Creds
• 🔒 ARTEX Key Vault Secret Extraction by Service Principal · unlock with TL Creds
• 🔒 ARTEX Azure VM Run Command and AKS Credential Retrieval by Service Principal · unlock with TL Creds

Indicators of compromise for ARTEX AI credential abuse

As of 2026-11-06, Threadlinqs Intelligence tracks 14 indicators of compromise for TL-2026-5363.

Sample indicators (3 of 14)

• IP address: 199.19.77[.]84
• IP address: 199.19.77[.]18
• IP address: 65.87.223[.]26

Defanged, TLP:CLEAR. Full set of 14 indicators: unlock with TL Creds.

How ARTEX AI credential abuse works

In a blog published on 2026-11-05, Microsoft describes a campaign in which threat actors use ARTEX, an agentic AI offensive framework, to automate the path from public secret discovery to cloud credential abuse. Beginning in August 2026 the actors submitted large volumes of GitHub queries combining target organization names, secret-related terms, cloud service keywords and AI service provider references to locate exposed credentials. Microsoft does not attribute the activity to a named actor.

On October 28, 2026 Microsoft observed successful service principal sign-ins from suspicious infrastructure across multiple tenants using valid, leaked application credentials. Once authenticated, the framework targeted operations that return sensitive material (storage account keys, App Service settings, connection strings, publishing credentials, AI/ML connections), enumerated subscriptions, resource groups and permissions, performed AI model deployment reconnaissance, extracted Azure Key Vault secrets, accessed SharePoint/OneDrive files and mailbox items, searched content through Microsoft Graph, searched Azure DevOps for secrets, and enumerated Azure SQL firewall rules, Application Insights query endpoints and Azure Backup recovery resources. Follow-on activity included OAuth application abuse for token generation, Run Command execution on Azure virtual machines, and targeting of AKS user credentials.

Microsoft highlights the agentic behavior of the tooling: ARTEX adapts when requests fail, retrying with modified HTTP methods or API versions (for example an Azure Resource Manager API version change after HTTP 400 errors, with retries roughly 28 to 80 seconds later that then returned HTTP 200), and in one observed case progressed from reconnaissance to credential exfiltration in about five minutes. By default ARTEX uses Nmap, curl, wget, Python HTTP clients, the Norma SDK WebFetch and headless Chromium through Playwright, and it can change source IPs, user agents and fingerprints to evade detection.

Context from other public reporting: ARTEX is an open-source, model-agnostic penetration testing harness published on GitHub by an account named Autumn-27, whose developer announced on 2026-10-08 that public updates would stop and the project would become closed source because of misuse. Wiz and Microsoft have separately documented ARTEX use by Storm-0940 against identity providers and a ConnectWise supply chain compromise; the Microsoft post analyzed here does not attribute the GitHub secret-abuse activity to that or any actor, and its IOCs are not shared with the Storm-0940 reporting. Microsoft also references a Todyl report of credential misuse from the same IP infrastructure.

Defenders should treat exposed Azure application credentials as compromised on discovery (removal from a repository is not sufficient; rotate), move workloads from secret-based service principals to managed identities, apply Conditional Access for workload identities, and hunt for service principal sign-ins, Graph and ARM activity and Key Vault access from the listed infrastructure.

MITRE ATT&CK techniques by tactic:

Initial Access

T1078.004 Cloud Accounts

Command and Control

T1090.003 Multi-hop Proxy

Collection

T1114.002 Remote Email Collection; T1213.002 Sharepoint; T1530 Data from Cloud Storage

Discovery

T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery

Credential Access

T1528 Steal Application Access Token; T1552.001 Credentials In Files; T1555.006 Cloud Secrets Management Stores

lateral-movement

T1550.001 Application Access Token

Reconnaissance

T1593.003 Code Repositories

Execution

T1651 Cloud Administration Command

Remediation for ARTEX AI credential abuse

Immediate actions

• Block 199.19.77.84 (and the other listed IPs) via Conditional Access policies for workload identities and at the perimeter
• Revoke Entra sessions, Azure DevOps PATs and SSH keys for affected users
• Remove all client secrets, certificates and federated credentials from compromised applications and disable affected service principals if needed
• Rotate all Key Vault contents accessible to compromised applications
• Rotate any credential exposed in a repository immediately; deleting it from the repository is not sufficient

Workarounds

• Enable GitHub Secret Scanning and GitHub Advanced Security push protection (including GitHub Advanced Security for Azure DevOps) to catch secrets before and after commit
• Hunt for default ARTEX tooling signatures (Nmap, curl, wget, Python HTTP clients, headless Chromium via Playwright) and malformed user agents

Longer-term hardening

• Migrate applications from secret-based service principal authentication to managed identities
• Apply least privilege to service principals through Azure RBAC and restrict application permissions to required resources
• Set the ability for users to register applications to No and monitor application developer role assignments
• Enable Conditional Access for workload identities
• Enable Microsoft Defender for Cloud plans (Resource Manager, Storage, Key Vault, App Service, Databases) and auditing across Azure DevOps, Key Vault, Storage diagnostics and the Microsoft 365 unified audit log
• Protect backup and recovery infrastructure
• Consider honeypots, decoys and tarpits to misdirect agentic tooling

Affected and fixed versions

• Microsoft — Microsoft Entra ID (service principals / workload identities)
  Vulnerable versions: Service principals with leaked secret-based credentials
  Fixed in: Managed identities and Conditional Access for workload identities
• Microsoft — Azure (Key Vault, Storage, Resource Manager, VMs, AKS, SQL, Application Insights, Backup, AI Services)
  Vulnerable versions: Resources reachable by compromised service principals
  Fixed in: Least-privilege RBAC and rotated credentials
• Microsoft — Azure DevOps
  Vulnerable versions: Secrets and PATs reachable by compromised identities
  Fixed in: Rotated PATs with push protection enabled
• Microsoft — Microsoft 365 (SharePoint, OneDrive, Exchange mailboxes, Microsoft Graph)
  Vulnerable versions: Tenants where compromised applications hold Graph permissions
  Fixed in: Restricted application permissions
• GitHub — GitHub repositories (public secret exposure)
  Vulnerable versions: Repositories containing committed cloud credentials
  Fixed in: Secret scanning with push protection

Timeline of ARTEX AI credential abuse

• 2026-07-01 locked-ioc-10, an open-source agentic AI penetration testing framework, is published on locked-ioc-9 by the account Autumn-27 (Wiz places publication in July 2026; The Record says earlier in 2026).
• 2026-08-01 Threat actors begin submitting large volumes of locked-ioc-9 queries for exposed secrets, using target organization names, secret terms, cloud service keywords and AI service provider references (Microsoft: August 2026; exact day not stated).
• 2026-10-08 locked-ioc-10 developer announces public updates will cease and the project will go closed source because of misuse by malicious actors.
• 2026-10-28 Post-authentication activity follows: Key Vault secret extraction, Graph and ARM reconnaissance, SharePoint/OneDrive and mailbox access, Azure DevOps secret searches, OAuth app abuse and VM Run Command, with one case moving from recon to credential exfiltration in about five minutes.
• 2026-10-28 Microsoft observes successful service principal sign-ins from suspicious infrastructure across multiple tenants using leaked application credentials.
• 2026-11-05 Microsoft Security Blog publishes the analysis with IOCs, Defender detections, KQL hunting queries and mitigations; Microsoft also notes a locked-ioc-11 report of similar credential misuse from the same IP infrastructure.

Sources cited for ARTEX AI credential abuse

• Threat actors use agentic AI tooling to find and abuse exposed secrets Microsoft · Vendor report · 2026-11-05
• ARTEX in the Wild: Storm-0940 Expands Targeting of IT and Software Vendors (Wiz) Wiz · Research
• China cyber ConnectWise AI (The Record) The Record · News
• China-linked hackers use ARTEX AI (The Hacker News) The Hacker News · News
• China-linked hackers used agentic AI in attack on 2,250 Microsoft 365 tenants (CSO Online) csoonline.com · News
• Microsoft Links Storm-0940 to ConnectWise Supply Chain Attack (Dark Reading) Dark Reading · News

More in threat intel

• Praetorian Brutus: Open-Source Multi-Protocol Credential Testing Engine Expands to 14 New Protocols with People Enumeration and Credential Persistence
• ARTEX AI-Powered Pentest Platform Abused for Autonomous Cybercrime Campaigns (Apple Certificates, Crypto Draining, Gaming Credentials)
• OpenAI releases GPT-6 Cyber, an offensive-capable AI model rated Critical under its Preparedness Framework
• OpenAI Finds GPT-6 Astra Covertly Underperforming on Safety Research and Exploit Tasks
• Module Overloading: Full PE Image Placed Inside a Carrier DLL Mapping (Malware Development Technique, cocomelonc)