Before anyone attacks your AI, they can learn a great deal about it from papers, preprints, blogs and internet scan databases, without sending a single packet to you. MITRE ATLAS records this as AML.T0000 Search Open Technical Databases, a Reconnaissance (AML.TA0002) technique rated Realized, with four sub-techniques: Journals and Conference Proceedings, Pre-Print Repositories, Technical Blogs and Scan Databases. The last was added in September 2026 and covers services such as Shodan and FOFA that index exposed AI infrastructure. This page explains each sub-technique, the ATLAS case studies that show it in use, and what defenders control: what they publish, what they expose, and how quickly they find their own exposure. It is for AI platform owners, research and communications leads, attack surface management teams and AI red teams.
Key takeaways
- Two very different kinds of reconnaissance share one ID. Three sub-techniques are about research publications that reveal how you use AI; Scan Databases is about finding your exposed AI services on the internet.
- It recurs across ATLAS case studies. Researchers used public papers, talks and patents to plan attacks on malware detectors, translation services and GPT-2 replication.
- Scan databases now feed agent-driven attacks. In ATLAS case study AML.CS0070, an AI agent queried FOFA and got records for 84 exposed Langflow instances and 647,017 n8n results before attempting exploitation.
- You cannot detect the search itself. Reading arXiv or querying Shodan leaves no trace in your logs, so measure exposure and use decoys (AML.M0039) to see what follows.
- ATLAS maps two mitigations. AML.M0000 Limit Public Release of Information for publications, and AML.M0039 AI Honeypots for scan-database discovery.
What the technique covers
ATLAS describes adversaries searching publicly available research and technical documentation to learn how and where AI is used within a victim organisation, to pick targets or tailor an attack. It notes that organisations often run open-source architectures trained on additional proprietary data, so knowing the base architecture helps an adversary build a realistic proxy model (AML.T0005 Replicate AI Model Behavior). Adversaries can also search publications by authors employed at the victim organisation. The technique mirrors ATT&CK T1596 Search Open Technical Databases.
| Sub-technique | Maturity | What the adversary learns |
|---|---|---|
| AML.T0000.000 Journals and Conference Proceedings | Feasible | Detailed methods, published for reproducibility, often from commercial labs |
| AML.T0000.001 Pre-Print Repositories | Demonstrated | An up-to-date view of what researchers at the victim organisation are working on, including notes and technical reports |
| AML.T0000.002 Technical Blogs | Feasible | Practical detail: frameworks and technologies used, sometimes API access and use case |
| AML.T0000.003 Scan Databases | Realized | Exposed AI services: IP addresses, hostnames, open ports and service banners, with no direct contact with the target (mirrors ATT&CK T1596.005) |
ATLAS separates Scan Databases from AML.T0006 Active Scanning: scan databases rely on third-party data, active scanning touches your systems. Results from one often lead to the other, and then to AML.T0049 Exploit Public-Facing Application. Related reconnaissance techniques have their own pages: AML.T0001 Search Open AI Vulnerability Analysis, AML.T0003 Search Victim-Owned Websites and AML.T0095 Search Open Websites/Domains.
How it shows up in real cases
ATLAS links AML.T0000 or its sub-techniques to many case studies. A representative set:
| Case study | Sub-technique | What was searched |
|---|---|---|
| AML.CS0000 Evasion of Deep Learning Detector for Malware C&C Traffic | Pre-Print Repositories | A machine learning approach to malicious URL detection (URLNet) found on arXiv, used as the representative target |
| AML.CS0003 Bypassing Cylance's AI Malware Detection | Parent technique | Public talks and patent submissions describing the detector |
| AML.CS0005 Attack on Machine Translation Services | Parent technique | Published papers to identify datasets and model architectures used by the target services |
| AML.CS0007 GPT-2 Model Replication | Parent technique | Public documentation giving dataset, architecture and training hyperparameters |
| AML.CS0048 Exposed ClawdBot Control Interfaces Leads to Credential Access and Execution | Scan Databases | Shodan search for the control interface page title, finding hundreds of exposed instances |
| AML.CS0070 Threat Actor Uses a DeepSeek-Powered Hermes Agent in Langflow and n8n Exploitation Attempts | Scan Databases and parent | FOFA queries for Langflow and n8n deployments |
ClawdBot (January 2026): according to the ATLAS case study, a security researcher searched Shodan for the title of ClawdBot's web control interface (the product is now OpenClaw) and found hundreds of instances exposed on the internet, some without authentication. On those instances the researcher could read configuration holding credentials for connected services, including model provider API keys, Telegram bot tokens, Slack OAuth credentials and Signal device-linking URIs, and in at least one case reach root in the container through the agent's shell skill.
Hermes agent (reported July 2026): Unit 42 described a Chinese-speaking actor operating DeepSeek through the open-source Hermes Agent framework. The agent queried FOFA for Langflow by page title (84 instances) and surveyed deployment counts for n8n (647,017 globally, 25,209 in China), then sampled and probed candidates. ATLAS notes these were exposure records, not confirmed vulnerable systems. Unit 42 reports the autonomous attempts did not achieve full compromise because of target-side configuration, and that the actor also used a custom FOFA search skill and an MCP server that turned natural-language requests into FOFA queries. See AML.T0116 Autonomous Reconnaissance.
The Langflow CVE-2025-3248 Exploitation 2025 breach page shows the same pattern at scale: Trend Micro assessed that the Flodrix operators likely found targets through Shodan or FOFA before using a public proof of concept.
Where your exposure comes from
- Research output: papers and preprints that describe the exact architecture, data sources or defences of a production system, with author affiliations that link them to it.
- Engineering blogs and talks: posts naming the model family, orchestration framework, vector store or gateway in use.
- Patents and model cards: often more specific than marketing material, and searchable.
- Exposed services: notebook servers, agent control panels, low-code AI workflow tools, model servers and vector databases reachable from the internet, with banners or page titles that identify them. See AML.T0132 Misconfigured or Publicly Exposed AI Services.
Mitigations
| ATLAS mitigation | Applies to | What it means in practice |
|---|---|---|
| AML.M0000 Limit Public Release of Information | AML.T0000 | Limit the connection between publicly disclosed approaches and the data, models and algorithms used in production. ATLAS also suggests limiting organisational detail, such as researcher names, locations and department structures, from which technical detail can be inferred |
| AML.M0039 AI Honeypots | AML.T0000 and AML.T0000.003 | Decoy AI services are catalogued by the same scan databases attackers query, so engagement with them reveals discovery activity, source details, tooling and prompts |
Publishing research is valuable and often required, so AML.M0000 is about review rather than silence: a pre-publication check that asks whether a paper or post identifies the production system, its stack or its defences more precisely than the reader needs. For scan databases, the control that matters most sits outside ATLAS's mapping: do not expose AI services that do not need to be public, and require authentication on everything that is. ATLAS's AML.M0039 then gives you a way to see who is looking.
Implementation steps
- Search yourself first. Query scan databases for your own IP ranges, domains and the page titles or banners of the AI tools you run. Record every AI service found and its owner.
- Close or protect what you find. Move management interfaces behind VPN or identity-aware proxies, turn on authentication, and remove default or shared credentials. Verify the fix by re-checking the scan record after the next crawl.
- Add AI services to attack surface monitoring. Include AI-specific fingerprints (agent control panels, notebook servers, workflow tools, model servers) in your external monitoring. See the Attack Surface Management Guide.
- Introduce a publication review. Before papers, preprints, talks and blogs about production AI are published, check for stack details, defence specifics and links between authors and production systems. Keep the review light so researchers use it.
- Deploy decoys where they will be found. Place monitored AI decoys in external address space that scan databases index, with no business function, and route all interactions to the SOC. See Honeypot deployment.
- Feed results back. Turn decoy telemetry and new exposure findings into detection rules and patch priorities.
Detection and measurement
The search itself is invisible to you. What you can observe is what comes next: probes against newly indexed AI services, connections to decoys, and authentication attempts on management interfaces shortly after they appear in scan results.
| Metric | Why it matters |
|---|---|
| Number of internet-exposed AI services found in scan databases, and the share with authentication | Direct measure of AML.T0000.003 exposure |
| Median time from an AI service appearing in a scan database to remediation | Shows how fast you close the window |
| Share of AI-related publications that went through security review | Coverage of AML.M0000 |
| Decoy interactions per month and share traced to known scanning infrastructure | Visibility into who is searching for your AI |
| AI services in the inventory with a named owner | Unowned services are the ones left exposed |
Where identity fits
The ClawdBot case shows why exposure and credentials go together: an exposed agent control panel gave access to the API keys and OAuth tokens the agent held for other services. Every AI service that might be indexed should hold only scoped, rotatable credentials, kept in a secrets manager rather than readable configuration, so that discovery does not become credential theft. See AML.T0083 Credentials from AI Agent Configuration.
Common failure patterns
- Self-hosted AI tools launched with management interfaces open to the internet for convenience during a pilot, then forgotten.
- Distinctive page titles and banners left at defaults, which make one search enough to list every instance.
- Papers and blogs that name the exact production model, data source and defence, giving an adversary what AML.CS0005 and AML.CS0007 researchers gathered from public documents.
- Attack surface monitoring that ignores AI tooling because it was deployed by data science teams outside normal change control.
- Assuming an exposure is unimportant because no one has attacked it yet. In the Langflow case, honeypots saw scanning about two days after public exploits appeared.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.TA0002 Reconnaissance; AML.M0000, AML.M0039 | Technique tactic and mapped mitigations |
| MITRE ATT&CK | T1596 Search Open Technical Databases; T1596.005 Scan Databases | Enterprise equivalents named by ATLAS |
| NIST SP 800-53 Rev 5 | CM-8 System Component Inventory; SC-7 Boundary Protection | Knowing and limiting exposed AI services |
| NIST SP 800-53 Rev 5 | PM-16 Threat Awareness Program | Tracking what adversaries can learn about you |
| NIST CSF 2.0 | ID.AM-02; DE.CM-01 | Inventory of systems and services; monitoring network services |
Practitioner checklist
- Search scan databases for your own ranges and AI tool fingerprints every month.
- Put every exposed AI management interface behind authentication or remove it from the internet.
- Give every AI service an owner and an inventory record.
- Add AI-specific fingerprints to external attack surface monitoring.
- Run a light security review on papers, preprints, talks and blogs about production AI.
- Keep agent credentials in a secrets manager, scoped and rotatable.
- Deploy monitored AI decoys in indexed address space and route alerts to the SOC.
Standards and references
- MITRE ATLAS: AML.T0000 Search Open Technical Databases
- MITRE ATLAS: AML.M0000 Limit Public Release of Information
- MITRE ATLAS: AML.M0039 AI Honeypots
- MITRE ATLAS: AML.CS0048 Exposed ClawdBot Control Interfaces Leads to Credential Access and Execution
- MITRE ATLAS: AML.CS0070 Threat Actor Uses a DeepSeek-Powered Hermes Agent in Langflow and n8n Exploitation Attempts
- MITRE ATT&CK: T1596 Search Open Technical Databases
- Unit 42: Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks
Related NHI Mgmt Group resources: MITRE ATLAS Guide · AML.T0006 Active Scanning · AML.T0049 Exploit Public-Facing Application · Flowise and Langflow Security Guide · MITRE ATLAS Mitigations Guide