ARTEX AI Pentesting Tool Usage Spreading Beyond Known Campaigns: Censys Findings and Defender Playbook

Censys published findings this week that should recalibrate how defenders think about AI-assisted offensive tooling. Their internet-wide visibility shows that ARTEX — an AI-driven penetration testing framework that has become popular with threat actors — is active across a footprint far larger than the publicly reported campaigns in which it was first observed. In plain terms: the tool's adoption has outrun our attribution. Campaigns we tracked as discrete incidents now look like the visible tip of a much broader operational base.

For defenders, the significance is not the novelty of AI in offense — it is the industrialization of reconnaissance and exploitation. Tools like ARTEX lower the skill floor for running continuous, automated attack-surface discovery, vulnerability probing, and exploit chaining against internet-facing assets. If the tool's deployment is broader than reported, then the pool of organizations being scanned, fingerprinted, and queued for exploitation is also broader than your threat intel feeds currently indicate. The correct response is not to wait for a CVE or an IOC list. It is to assume your perimeter is being enumerated by automated AI-driven tooling right now and to verify that your detection and exposure management hold up under that assumption.

Technical Analysis

What ARTEX Is and Why It Matters

ARTEX belongs to the emerging class of AI-augmented offensive security frameworks: tooling that chains together reconnaissance, service fingerprinting, vulnerability identification, and exploitation with machine-assisted decision-making about which path to take next. Rather than an operator manually running Nmap, then Nikto, then an exploit module, these frameworks automate the kill chain end-to-end and adapt based on what they find. Threat actors favor them because they scale — one operator can prosecute hundreds of targets in parallel — and because the output of an "AI pentest" against your perimeter looks, in your logs, remarkably like a legitimate authorized assessment.

That last point is the crux of the Censys finding. Because ARTEX-style tooling generates traffic patterns similar to sanctioned scanning (security researchers, bug bounty hunters, your own vendors' EASM platforms), its true prevalence is easy to undercount. Censys's internet-wide telemetry cuts through that by observing infrastructure and exposure at scale, and their conclusion is that activity consistent with ARTEX extends well beyond the campaigns researchers had previously documented.

Affected Products and Platforms

There is no single vulnerable product here — ARTEX is a tool, not a vulnerability. Its targets are your internet-facing estate:

• Perimeter and remote access infrastructure: VPN concentrators, firewalls, remote desktop gateways, and reverse proxies
• Web applications and APIs: login portals, admin panels, forgotten staging subdomains, exposed CI/CD interfaces
• Cloud and SaaS control planes: misconfigured storage, exposed management interfaces, dangling DNS
• Unpatched edge devices: the exact class of assets that automated tooling excels at matching against known-exploited vulnerability signatures

The risk profile is highest for organizations with poor external asset inventory — shadow IT, orphaned subdomains, legacy VPN portals, and test environments reachable from the internet. AI-driven tooling finds these faster than your annual pentest does.

Attack Chain (Defender's View)

1. Passive and active reconnaissance: certificate transparency mining, subdomain enumeration, banner grabbing, and service fingerprinting against your netblocks and domains.
2. Vulnerability correlation: discovered services are matched against known vulnerability signatures and exploit modules — this is where AI-assisted tooling accelerates, prioritizing exploitable paths without human triage.
3. Automated probing and exploitation: credential attacks against login surfaces, exploit delivery against identified vulnerable services, and webshell or implant staging on success.
4. Post-exploitation handoff: access is either monetized directly (ransomware affiliates, data theft) or brokered as initial access.

Exploitation Status

There is no CVE associated with this story — the threat is the tooling and its operators, not a discrete vulnerability. Per the Censys report, ARTEX-consistent activity is confirmed active in the wild and broader than previously reported campaigns. This is not theoretical. Treat external reconnaissance and automated exploitation attempts as an ongoing background condition, and treat any new spike in scan-sourced probing against a specific technology you run as a leading indicator that a working exploit path exists for it.

Detection & Response

The honest challenge with detecting AI-driven offensive tooling is that you will not detect "ARTEX" — you will detect its behaviors: scan-sourced reconnaissance, scanner fingerprints in web logs, exploitation tool execution on endpoints, and anomalous authentication patterns following recon bursts. The detections below target those behaviors and are tuned to avoid the noise floor that gets rules disabled.

SIGMA Rules

The first rule catches common scanner/automation fingerprints hitting web infrastructure — AI pentest frameworks routinely wrap or invoke the same open-source engines (Nuclei, Nikto, sqlmap, Gobuster) that your WAF already sees, but many organizations never alert on them. The second targets offensive tooling executing on servers where no authorized assessment is underway — a high-fidelity signal that automated exploitation succeeded and a human (or agent) is now on the box. The third catches rapid enumeration of web server content consistent with automated directory brute-forcing.

---
title: Offensive Scanner User-Agent Detected Against Web Infrastructure
id: 3f8a1b72-5c64-4e29-b7d1-9a2e4f6c8d10
status: experimental
description: Detects HTTP requests with user agents associated with automated scanning and exploitation frameworks frequently wrapped by AI-driven pentest tooling. Tune against your authorized scanner source IPs.
references:
  - https://www.infosecurity-magazine.com/news/artex-activity-exceeds-reported/
  - https://attack.mitre.org/techniques/T1595/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.reconnaissance
  - attack.t1595.002
logsource:
  category: webserver
detection:
  selection:
    c-useragent|contains:
      - 'nuclei'
      - 'sqlmap'
      - 'nikto'
      - 'gobuster'
      - 'dirbuster'
      - 'masscan'
      - 'hydra'
      - 'wpscan'
      - 'acunetix'
      - 'nessus'
  filter_authorized:
    c-ip|contains:
      - 'AUTHORIZED_SCANNER_IP_1'
      - 'AUTHORIZED_SCANNER_IP_2'
  condition: selection and not filter_authorized
falsepositives:
  - Authorized vulnerability scanners and EASM vendors - maintain an allowlist of their source IPs
  - Security researchers and bug bounty traffic
level: medium
---
title: Offensive Security Tool Execution on Server Systems
id: 8c2d4e61-7a93-4f18-9b25-3d6e8a1c5f07
status: experimental
description: Detects execution of common reconnaissance and exploitation tools on servers where such tooling has no legitimate presence. High-fidelity indicator of successful intrusion or unauthorized testing.
references:
  - https://www.infosecurity-magazine.com/news/artex-activity-exceeds-reported/
  - https://attack.mitre.org/techniques/T1588.002/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.resource_development
  - attack.t1588.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\nmap.exe'
      - '\sqlmap.exe'
      - '\nuclei.exe'
      - '\mimikatz.exe'
      - '\masscan.exe'
      - '\hydra.exe'
      - '\nc.exe'
      - '\ncat.exe'
  selection_cli:
    CommandLine|contains:
      - 'sqlmap.py'
      - 'nuclei -u'
      - 'masscan -p'
  condition: 1 of selection_*
falsepositives:
  - Authorized penetration tests - correlate against your engagement calendar before escalating
  - Red team operations
level: high
---
title: Automated Web Content Enumeration Burst From Single Source
id: 5e1f9a34-2b87-4d56-8c19-7f3a6b2e4d09
status: experimental
description: Detects a high volume of 404 responses served to a single source IP in a short window, consistent with automated directory and file brute-forcing by offensive tooling.
references:
  - https://www.infosecurity-magazine.com/news/artex-activity-exceeds-reported/
  - https://attack.mitre.org/techniques/T1595.003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.reconnaissance
  - attack.t1595.003
logsource:
  category: webserver
detection:
  selection:
    sc-status: 404
  condition: selection | count(c-ip) by c-ip > 200
  timeframe: 5m
falsepositives:
  - Misconfigured applications generating broken links at scale
  - Legitimate crawler traffic with stale sitemaps
level: low

KQL — Microsoft Sentinel / Defender

The following hunt correlates reconnaissance behavior against your web edge with subsequent authentication anomalies — the pattern to watch for when automated tooling transitions from scanning to access attempts. It assumes web/proxy logs are ingested via CommonSecurityLog (CEF) or a custom table; adjust the table name to your ingestion pipeline.

// Hunt: Scanner fingerprints and recon bursts followed by auth failures
// Lookback: 7 days | Tune AuthorizedScanners dynamic list to your environment
let AuthorizedScanners = dynamic(["10.0.0.10", "10.0.0.11"]);
let ScannerAgents = dynamic(["nuclei","sqlmap","nikto","gobuster","masscan","hydra","wpscan","acunetix"]);
let ReconSources =
    CommonSecurityLog
    | where TimeGenerated > ago(7d)
    | where RequestUserAgent has_any (ScannerAgents)
       or (RequestURL has_any ("/wp-admin","/.git","/.env","/phpmyadmin","/actuator","/console")
           and DeviceAction == "blocked")
    | where not(SourceIP in (AuthorizedScanners))
    | summarize ScanRequests=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
                SampleURLs=make_set(RequestURL, 10), SampleAgent=any(RequestUserAgent)
              by SourceIP
    | where ScanRequests > 50;
ReconSources
| join kind=leftouter (
    SigninLogs
    | where TimeGenerated > ago(7d)
    | where ResultType != 0
    | summarize AuthFailures=count(), TargetAccounts=make_set(UserPrincipalName, 10) by IPAddress
  ) on $left.SourceIP == $right.IPAddress
| project SourceIP, ScanRequests, FirstSeen, LastSeen, SampleAgent, SampleURLs, AuthFailures, TargetAccounts
| order by ScanRequests desc

For endpoint-side hunting — scanner and post-exploitation tooling landing on servers:

// Hunt: Offensive tooling execution on server endpoints
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName in~ ("nmap.exe","sqlmap.exe","nuclei.exe","mimikatz.exe","masscan.exe","hydra.exe","nc.exe","ncat.exe")
   or ProcessCommandLine has_any ("sqlmap.py","nuclei -u","masscan -p","sekurlsa::")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, AccountName, InitiatingProcessFileName, SHA256
| order by TimeGenerated desc

Velociraptor VQL

Use this artifact across your server fleet to sweep for offensive tooling artifacts and unexpected outbound connections characteristic of automated exploitation frameworks:

-- Hunt: Offensive tooling processes and suspicious outbound connections on servers
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(nmap|sqlmap|nuclei|mimikatz|masscan|hydra|ncat|nc\.exe)'
   OR CommandLine =~ '(?i)(sqlmap|nuclei -u|masscan -p|sekurlsa)'

-- Hunt: Servers with high-fan-out outbound connections (scan-sourced lateral movement or callback)
SELECT Pid, Name, Status, LocalAddr, LocalPort, RemoteAddr, RemotePort
FROM netstat()
WHERE Status =~ 'ESTABLISHED|SYN'
  AND NOT RemoteAddr =~ '^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.|127\.)'
ORDER BY Pid

Exposure Verification and Hardening Script

Since there is no patch for "an AI tool is scanning you," the remediation action is verifying your external exposure matches what you think it is. This Bash script inventories listening services, checks web logs for scanner fingerprints, and validates that management interfaces are not internet-exposed:

#!/bin/bash
# Security Arsenal - External Exposure & Scanner Activity Audit
# Run on perimeter hosts and log aggregation points. Requires sudo for ss.

echo "=== [1] Listening services (compare against approved baseline) ==="
ss -tulpn | awk 'NR>1 {print $1, $5, $7}' | sort -u

echo -e "\n=== [2] Scanner user-agent hits in web logs (last 7 days) ==="
LOG_DIRS="/var/log/nginx /var/log/apache2 /var/log/httpd"
for d in $LOG_DIRS; do
  if [ -d "$d" ]; then
    find "$d" -name '*access*log*' -mtime -7 -type f | while read -r f; do
      zgrep -ihE 'nuclei|sqlmap|nikto|gobuster|dirbuster|masscan|hydra|wpscan|acunetix' "$f" 2>/dev/null \
        | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
    done
  fi
done

echo -e "\n=== [3] Sensitive paths probed (potential enumeration) ==="
for d in $LOG_DIRS; do
  if [ -d "$d" ]; then
    find "$d" -name '*access*log*' -mtime -7 -type f | while read -r f; do
      zgrep -ihE '/\.git|/\.env|/wp-admin|/phpmyadmin|/actuator|/\.svn|/backup|/config\.' "$f" 2>/dev/null \
        | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -20
    done
  fi
done

echo -e "\n=== [4] Management interfaces bound to 0.0.0.0 (review immediately) ==="
ss -tulpn | grep -E '0\.0\.0\.0:(22|23|3389|5900|8080|8443|9200|15672|27017)' || echo "None found - OK"

echo -e "\n=== Audit complete. Investigate any scanner source IPs not on your authorized assessment list. ==="

For Windows perimeter and web hosts, the equivalent verification:

# Security Arsenal - Windows Perimeter Exposure & Scanner Activity Audit
# Run elevated on web/edge servers.

Write-Host "=== [1] Listening services vs approved baseline ===" -ForegroundColor Cyan
Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalAddress -in @('0.0.0.0','::') } |
  Select-Object LocalPort, OwningProcess,
    @{N='Process';E={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
  Sort-Object LocalPort -Unique | Format-Table -AutoSize

Write-Host "=== [2] Scanner user-agent hits in IIS logs (last 7 days) ===" -ForegroundColor Cyan
$scannerPattern = 'nuclei|sqlmap|nikto|gobuster|dirbuster|masscan|hydra|wpscan|acunetix'
Get-ChildItem 'C:\inetpub\logs\LogFiles' -Recurse -Filter '*.log' -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } |
  Select-String -Pattern $scannerPattern |
  ForEach-Object { ($_.Line -split ' ')[8] } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

Write-Host "=== [3] Management ports exposed on all interfaces ===" -ForegroundColor Cyan
$mgmtPorts = 22,23,3389,5900,5985,5986,8080,8443
$exposed = Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalAddress -in @('0.0.0.0','::') -and $_.LocalPort -in $mgmtPorts }
if ($exposed) { $exposed | Format-Table LocalPort, OwningProcess -AutoSize
  Write-Host 'WARNING: Management services bound to all interfaces. Restrict via host firewall.' -ForegroundColor Red
} else { Write-Host 'None found - OK' -ForegroundColor Green }

Write-Host "=== [4] Quick containment: block a hostile scanner IP (example) ===" -ForegroundColor Cyan
Write-Host 'New-NetFirewallRule -DisplayName "Block-Scanner-203.0.113.50" -Direction Inbound -RemoteAddress 203.0.113.50 -Action Block'

Remediation

There is no vendor patch and no CISA KEV deadline here — the remediation is architectural and operational. Prioritize the following:

1. Establish continuous external attack surface management (EASM). The Censys finding is fundamentally a visibility story: adversary tooling sees more of your estate than you do. Deploy continuous external discovery (Censys, Shodan, or commercial EASM) against your own domains, netblocks, and cloud tenants. Reconcile discovered assets against your CMDB weekly. Anything internet-facing that nobody owns is your highest-risk asset.

2. Kill the exposed management plane. VPN admin portals, firewall management UIs, RDP gateways, CI/CD consoles, and cloud management interfaces should never be reachable from the general internet. Enforce allowlisting, move them behind identity-aware proxies, or take them offline. Automated exploitation tooling feasts on exactly these surfaces.

3. Patch edge devices on an accelerated cadence. AI-assisted tooling correlates discovered services against known-vulnerability signatures at machine speed. Your 30-day patch cycle for perimeter appliances is an eternity. Move internet-facing devices to an emergency patch SLA (24–72 hours for critical CVEs) and subscribe to CISA KEV as your prioritization feed.

4. Enforce phishing-resistant MFA everywhere external. Automated credential attacks are a standard module in these frameworks. MFA on all remote access, and particularly FIDO2/passkeys for administrative access, blunts the highest-volume exploitation path.

5. Baseline your authorized scanner inventory and alert on everything else. Maintain a written list of every vendor, pentest firm, and EASM platform authorized to scan you, with source IPs. Everything outside that list hitting your perimeter with scanner fingerprints gets blocked and investigated — that is the practical enforcement of the detections above.

6. Rate-limit and tarpit enumeration. Configure WAF/reverse-proxy rules to throttle sources generating high 404/401 volumes, block requests carrying scanner user agents, and alert on bursts. This raises the cost of automated reconnaissance and generates high-signal telemetry.

7. Rehearse the assumption of scanning. Update your threat model to treat continuous AI-driven reconnaissance as a given. Your detection engineering should assume any newly disclosed vulnerability in technology you run will be probed against your estate within hours.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub