Detecting T1682 Query public AI services

How T1682 Query public AI services shows up before an intrusion

Public AI services are now a routine place for staff to draft, summarize and research, so a SOC lead who sees traffic to these services cannot judge intent from the destination alone. For an adversary, T1682 Query public AI services is a way to gather information they can use to plan future operations. That purpose is the definition ATT&CK gives the Reconnaissance tactic (TA0043). For defenders, the practical question is whether a given session fits the role, business context and timing of the account that made it, and whether it resembles the work that account normally does.

In the reconnaissance phase, the adversary's activity happens before any intrusion and largely outside the victim's environment, so the organization sees it only indirectly. The signals that matter are on the organization's own side: egress from managed endpoints, proxy and DNS records, identity activity and any data the organization already holds about its public-facing staff and systems. This page targets ATT&CK v20.0. Before you write or tune any mapping, confirm the technique description and its tactic assignment on the ATT&CK page for that version, because ATT&CK release notes show that releases can rename, deprecate or revoke techniques.

The decision for the SOC lead is to agree which AI services are sanctioned, which account groups may use them, and what counts as an unexpected pattern for each group. Confirm with your own logging team which of these sources you collect, how long you keep them and whether they carry enough context to tie a session to a user and a role. Where those sources are thin, record the gap as a risk, because a detection built on incomplete telemetry will look reliable on a dashboard while missing much of the activity.

Which telemetry reveals T1682 and which open-source tool collects it

This table maps each candidate telemetry source to the T1682 signal it can show, the ATT&CK data component to confirm against the v20.0 detection strategy, and the open-source collector that gathers it. Read each row as a question to answer in your own environment, because encrypted sessions hide content and some sources exist only where you operate a logging proxy. The main takeaway is that DNS, TLS metadata and flow records give the broadest early coverage, while response content needs deliberate logging. Confirm every mapping against the current enterprise-attack bundle before you build rules.

Telemetry source	Signal for T1682	Data component to confirm	Open-source collector
Proxy and web gateway logs	Outbound requests to public AI service domains from hosts or service accounts that should not call them	Network Traffic Content (DC0085)	Squid or web proxy access logs shipped to Wazuh or Security Onion
DNS query records	Lookups for public AI service domains from unexpected hosts, subnets or servers	Network Traffic Content (DC0085)	Zeek dns.log or Suricata DNS events
Network flow metadata	Connections to AI service address ranges, with volume, timing and source host	Network Traffic Flow (DC0078)	Zeek conn.log or Suricata flow records
TLS handshake metadata	Server name fields showing AI service hostnames inside encrypted sessions, without payload	Network Traffic Content (DC0085)	Zeek ssl.log or Suricata TLS logging
Endpoint and application logs	Service account or client activity calling AI service APIs, or browser and CLI use on sensitive hosts	Application Log Content (DC0038)	Wazuh agents collecting application and system logs
Response content at your own gateway	Returned content from AI services, visible only where an in-house proxy or API gateway logs bodies	Response Content (DC0104)	Gateway body logging with privacy controls, forwarded to Wazuh
Cloud or SaaS audit logs	Administrative or API events for AI service integrations in your tenants, where the provider exposes them	Confirm with the provider and the bundle	Log export to Wazuh through provider connectors, where available

Detection ideas for public AI service queries, described in words

T1682 Query public AI services is hard to see because a request to a public AI endpoint looks like any other web call. The cards below combine baseline, first-seen, volume, role and correlation logic so that no single noisy signal has to carry the detection alone.

Build a baseline of normal AI traffic

Start by recording which hosts, user groups and service accounts already reach public AI services through the proxy or secure web gateway, and for what purpose. Map those destinations to approved tools so that sanctioned use becomes the expected pattern. Review the baseline with business owners before alerting on anything, because an incomplete baseline turns every new tool into an incident. Tune the baseline window by watching how stable the set of users is across weeks, and ask the team to confirm which domains belong to sanctioned products.

Alert on first-seen AI destinations

Raise an alert when a host or account contacts an AI service domain it has never contacted before, especially one outside the approved list. The logic is a first-seen check over proxy or DNS logs against the baseline. Set the lookback window and the grouping level (per host, per user or per department) as tuning inputs, and start with a short window that you widen once alert volume is understood. False positives come from newly approved tools, browser extensions, developer SDK updates and security vendor sandboxes that call AI endpoints on their own.

Flag volume and timing outliers

Compare request counts, payload sizes and session timing to each user's or host's own history rather than a fixed global limit. A burst of requests at an unusual hour, or a sudden jump in outbound bytes toward an AI domain, can indicate bulk querying. Use flow data where proxy logs are missing, and set thresholds as percentiles of historical behavior, adjusted by a tuning review each month. Expected false positives include scheduled batch jobs, model evaluation runs, and staff preparing large documents for approved summarization tools.

Watch servers and service accounts

Servers, build agents and service accounts should rarely browse the open web, so any AI service request from them deserves review. Define the expected egress list for each server role and alert on requests outside it. Check the process or parent application where endpoint telemetry allows, since an automation account reaching an AI endpoint may reflect a misconfigured integration or a compromised credential. Expected false positives include approved AI-assisted developer tooling and CI steps that were added without a change record, so confirm ownership before escalating.

Correlate with earlier reconnaissance

Look for AI service queries that follow other reconnaissance indicators from the same source, such as scanning, open-source searches on the organization, or reconnaissance-focused phishing reports. Join these events by host, account or time window in your SIEM, and rank combined alerts above isolated AI traffic. Correlation windows and the set of earlier indicators should be tuned against your own incident history. Expected false positives include security teams running their own research against the organization, so keep an allowlist of authorized testing sources.

How to build a baseline before any AI service alert is trusted

Start by accepting that public AI service use is common and often sanctioned, so a rule that fires on any request to a generative AI domain will flood the queue within days of going live. Before tuning any alert for T1682 Query public AI services, build an inventory of the AI tools your organization has approved, including browser extensions, desktop clients, API keys issued to developers and AI features embedded in existing SaaS products. For each entry, record a business owner, the teams and user groups allowed to use it, the managed hosts or identity groups where it is expected, and the data classifications that may be sent to it. Ask the owners to confirm these facts rather than assuming the procurement record is current, because shadow adoption often outruns the register.

With that inventory, separate sanctioned traffic from unknown traffic in your telemetry. Map each approved service to the domains, TLS server names and API endpoints it uses, and keep that mapping in version control so changes are reviewed. Traffic that matches an approved service from an expected host and identity becomes a known baseline pattern, while requests to AI endpoints from unmanaged hosts, service accounts with no documented purpose or unapproved tools become the population you investigate. Confirm with your network and endpoint teams which telemetry, such as proxy logs, DNS records or Network Traffic Content captured by your sensors, actually shows the destination and payload size, since the answer determines which signals you can trust.

Treat the baseline as a living control and review it on a fixed cadence that your change board agrees, with an extra review whenever a new AI tool is approved, a vendor changes its domains or an incident involves AI traffic. Each review should compare observed destinations against the register, retire entries nobody uses, and record exceptions with an expiry date. Also check the ATT&CK version your detection mappings target, since releases can rename or revoke techniques and T1682 may change its wording, sub-techniques or related data components between versions. Only after a baseline has survived a few review cycles should an alert on unknown AI service traffic be allowed to page anyone.

How to validate that the T1682 detection fires

This sequence turns the T1682 detection from a rule on paper into evidence that it fires on the expected telemetry, with clear sign-off from asset owners and a record that feeds the detection register. It is run in a private lab or cyber range, against a benign emulation of the behavior only.

Confirm the ATT&CK version and expected telemetry
Start by stating which ATT&CK version the detection targets, using the Enterprise v20.0 mapping for T1682 Query public AI services. Record the expected data components from that mapping, such as the network and application log content the detection strategy relies on, and list the log sources your environment should produce for them. The step is done when the detection owner signs a one-page note naming the version, the data components and the log sources, and the note is filed with the detection in the register.
Agree test scope and approval with asset owners
Before any test, the detection owner, the owners of the assets in scope, and the SOC lead agree in writing what will be exercised, in which range or lab segment, which accounts or hosts are involved, and who can stop the test. Confirm that no production user or live AI service is affected unless the owner has approved it. The step is complete when the signed scope document names the approvers, the rollback contact and the stop conditions.
Run a benign emulation of the behavior
A tester runs a benign emulation of the T1682 behavior inside the range, following the approved scope and without using payloads or live adversary tooling. The tester logs the start and end times, the test account or host, and the observable actions taken, so the activity can be matched to telemetry later. The step is complete when the tester hands the timed activity log to the detection owner and the range is returned to its baseline state.
Verify expected events reach the SIEM with correct fields
Search the SIEM for the events produced by the emulation, comparing them with the telemetry defined in step one. Check that the events arrived within the expected window, that the source identifies the range host or account, and that the fields the rule depends on are populated and parsed correctly. Note any gaps, such as missing fields, dropped sensor traffic or delayed ingestion. The step is complete when each expected event is either confirmed present with its fields or logged as a gap with an owner assigned.
Record alert time, fidelity and analyst notes
Check whether the detection produced an alert, and record the time between the emulated activity and the alert, the alert severity, and whether the alert contained enough context for triage. Ask the analyst who handled the alert to note what they could and could not determine from it. The step is complete when the alert record, timing and analyst notes are stored with the test identifier, so the result can be compared across runs.
Tune the rule and document the change
Where the test showed false negatives, missing fields or noisy matches, adjust the rule logic or the log parsing and write down what changed and why. Keep the original rule version so the before and after results can be compared. The step is complete when the change is peer reviewed and the rule version in the register matches the version deployed to the SIEM.
Repeat the test and update the detection register
Rerun the same emulation against the tuned rule, then compare the new evidence with the earlier run. Record the outcome for each check (telemetry present, fields correct, alert fired, alert timing, analyst notes) and the date of the test. Schedule the next repeat whenever ATT&CK releases a change that affects the mapping, the data components or the log sources. The step is complete when the detection register shows a dated entry with both runs, the tuned rule version and the owner's sign-off.

Preventive controls that reduce T1682 exposure

ATT&CK maps Pre-compromise (M1056) to the Reconnaissance techniques, and T1682 should be confirmed against the v20.0 mapping before you cite it in an assessment. The controls below act on the same question from different layers: what staff send to public AI services, what servers can reach, and what the organization publishes about itself.

Acceptable-use rules for approved AI tools

Write a short policy that names which public AI services are approved, which data classes may never be entered into them, and who may request an exception. Staff are the most common path into these services, so the policy has to say what to do with source code, customer records and unreleased financial data. Confirm that the rules are published, that staff acknowledge them, and that the approved list is reviewed on a set schedule. An assessor will ask for the policy, the acknowledgment records and the review history. Policy text alone is not enough without evidence that people were told.

Outbound web access controls on servers

Servers rarely need to reach public AI services, so default-deny egress from production and build hosts limits what can be sent from them. Use a proxy or firewall policy that allows only named destinations for each server role, and log every blocked and allowed request. Check that the rules cover direct IP connections and alternate DNS paths, not only the proxy. Evidence an assessor will ask for includes the egress rule set, change records for exceptions and a sample of denied-request logs.

Browser and endpoint enforcement for staff

On managed endpoints, control which browser extensions, desktop clients and web categories are permitted, so the acceptable-use policy is backed by configuration. Confirm that unmanaged devices cannot reach corporate data stores that are restricted to the approved tools. Ask the endpoint team for the policy export, the list of permitted extensions and the exception approvals. Keep the enforcement layer separate from the policy document so a reviewer can test each one.

Public exposure review of the organization

Adversaries can query public AI services about an organization's people, systems and suppliers, so limiting what is published reduces the material available to ask about. Review public websites, job postings, technical blogs, documentation and open repositories for details such as internal hostnames, architecture diagrams, vendor contracts and org charts. Record the review scope, the owner for each source and the remediation tickets. Repeat the review after major releases or reorganizations.

Vendor and data handling terms

Before a public AI service is approved, check its terms for data retention, training use, subprocessors and regional storage. These terms decide what a provider may do with prompts that staff submit, which affects both confidentiality and records obligations. Ask the vendor for its current data processing documents and keep them with the approval record. Legal and procurement should confirm the terms again when they change, since they can differ between free and paid tiers.

Awareness training with usage examples

Training works best when it shows concrete examples of what should not be pasted into a public AI service, such as incident data, credentials or customer details. Tie the course to the acceptable-use policy and run a short check at the end. Track completion by role, with extra content for engineering and support teams who handle the most sensitive material. Evidence to request includes the course content, completion records and the results of the knowledge check.

What changes when the detection fires in your environment

When a T1682 detection fires, the SOC lead should treat it as a reconnaissance signal, not a confirmed intrusion. Querying a public AI service is often routine: staff look up code, draft text or test prompts. The alert therefore starts a triage question, not an incident. The first decision is whether the traffic comes from an approved tool, an approved account and an expected business workflow. Analysts should be able to answer that in a few minutes from the alert itself, which means the detection record should carry the source host, the user or service identity, the destination service and the matched rule version. Without those fields, every alert becomes a manual investigation and sanctioned use gets buried among suspicious use.

The triage path depends on a baseline that someone owns. Security should not maintain the approved tool list alone. IT owns the endpoints, browser policies and network egress controls that determine what is reachable, while business owners know which teams have a legitimate need for each AI service and what data they handle. Agree in writing who approves additions to the list, who reviews exceptions and how often the list is revisited. Record those owners next to the detection so the analyst knows whom to call when an alert involves a service nobody has classified. Confirm with your IT and business leads how they will receive these requests, and whether your existing change process can absorb them without a separate queue.

Escalation should follow from the baseline, not from the alert alone. An event that matches the approved list and a known user can be closed with a note, while an unlisted service, an unusual user or a large volume from a server should move to a documented review with the owners named above. Keep the criteria for each outcome in the playbook and test them against your own logs during a cyber range exercise, because the thresholds that suit one organization may not suit another. Ask your platform and security teams to confirm which fields are available in your current telemetry before you commit to these rules, since missing context is the most common reason triage slows down.

How to rehearse T1682 detection and response in a private cyber range

The range should mirror the parts of your estate where a request to a public AI service would be visible: user endpoints, the egress path and the security monitoring stack. Use a private network with no route to production data, and use a benign AI service stand-in or an approved test endpoint that your organization has agreed to contact. No live adversary tooling belongs in the range. The goal is to generate ordinary, observable network and application activity that the detection logic must recognize.

Monitored endpoints: Include a few managed workstations and one server-side service account, each with the endpoint agent your SOC already uses.
SIEM and log pipeline: Forward proxy, DNS and endpoint logs to a SIEM such as Wazuh, and confirm the field names match your detection rules.
Network sensors: Place Zeek or Suricata where they see egress traffic, so both connection metadata and content visibility can be tested.
Egress proxy: Route outbound web traffic through a proxy that logs the destination domain, user agent and request size.
Stand-in endpoint: Confirm with the owner of any external test endpoint which domains and traffic patterns are permitted before the exercise.

Record the exact configuration version of every component so results can be reproduced after tuning.

Questions SOC leads and detection engineers ask about T1682

Why is querying public AI services hard to separate from sanctioned use?

The same domains, protocols and browsers serve approved productivity work and misuse, so a destination alone rarely decides the outcome. Separate the two by identity, device, data classification and request volume. Start with an inventory of sanctioned AI services and tenants, then alert on unsanctioned services, personal accounts on managed devices and unusual volume from service accounts or automation. Agree the baseline with the business owners of approved tools so analysts know what normal looks like before tuning. Expect false positives while the baseline forms, and record each tuning decision so the logic stays explainable to auditors.

Which telemetry should a SOC collect first to detect T1682?

Start with the sources that identify the destination and the client: DNS query logs, proxy or secure web gateway logs and network flow records. Add endpoint process and browser telemetry where your estate supports it, and application logs from sanctioned AI platforms, which can record tenant, user and API activity. Map these sources to ATT&CK data components such as Network Traffic Flow (DC0078) and Application Log Content (DC0038), and to Network Traffic Content (DC0085) only where lawful inspection is in place. Confirm each source records user identity, timestamp and destination. Zeek and Suricata can generate connection and protocol metadata at sensor points, which helps when proxy coverage is partial.

How should we handle encrypted traffic and DNS-only visibility for this detection?

Plan for it from the start. When only DNS or connection metadata is visible, build the detection on destination domain, timing, volume and client identity, and treat it as a lower-confidence signal that needs corroboration from endpoint or proxy data. Payload inspection of encrypted traffic depends on TLS interception, which requires legal review, employee notice and controls for privacy-sensitive content. Certificate-pinned clients may break under interception, so test each client family. Write a coverage statement that lists which networks, devices and browsers are visible, and review it whenever the sensor layout changes.

How do we keep this detection current across ATT&CK releases?

Pin every detection to ATT&CK version 20.0, the version these pages target, and record that version in the rule metadata. MITRE can rename, deprecate or revoke techniques between releases. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Read the ATT&CK updates page for each release, then compare the STIX bundle for your domain to find changes to technique IDs, data components and detection strategies. Assign a named owner to review each release, keep rules in version control so changes are auditable, and confirm how your tooling imports new bundles.

How can we test this detection without generating live adversary behavior?

Test in a private cyber range using synthetic accounts and scripted, benign traffic that reproduces the observable pattern the detection expects. Do not run live misuse of public services, and never send real company or customer data to third-party AI services during a test. Define the expected alerts before each run, then replay recorded test data against your Sigma rules. Measure three things: whether the telemetry arrived, whether the rule fired and whether the alert reached the right queue. Use isolated endpoints with Wazuh or Velociraptor agents where possible, and obtain written authorization and rules of engagement from the data owner before testing begins.

How should alerts for this technique be routed to the right owner?

Route alerts by the sanctioned status of the service and the nature of the activity. Unsanctioned use from a managed device goes to endpoint or IT operations for access review. Suspected data disclosure goes to incident response, with privacy and legal contacts added. Unusual volume on a sanctioned tool goes to the application owner. Define severity levels, response expectations and escalation contacts in a runbook before go-live, and record the owning team in alert metadata so analysts can see who acts. Confirm that each queue exists in your ticketing and on-call tools and test the handoff during a range exercise.

How DeployOpen builds T1682 detections and range exercises

DeployOpen approaches T1682 Query public AI services as a self-hosted detection engineering task inside the client's own environment. The work starts with a written scope, moves through detection content and telemetry checks, and ends with documented handover and optional ongoing support.

How we scope

Confirm which ATT&CK version the detection mapping targets before any rule is written
Inventory which AI service domains, egress paths and log sources exist in the environment
Agree in writing which data components, platforms and exercises are in and out of scope
Record assumptions about logging coverage so gaps are visible before build starts

How we build

Map detection logic to Network Traffic Content and Application Log Content where those sources exist
Write detection content for Wazuh, Zeek or Suricata based on what the client already runs
Test rules against recorded benign and simulated activity in a private cyber range
Document false positive tuning decisions so analysts can see why each threshold was chosen

How we hand over

Deliver rule files, mapping tables and configuration in a format the client's team can version
Provide a runbook for triage, escalation and evidence capture tied to T1682 alerts
Walk the client's analysts through a range exercise so they can repeat it without DeployOpen
Deliver a written validation summary that names the telemetry, rules and gaps observed

How we support

Engagements are fixed-scope, so scope, deliverables and timelines are agreed before work starts
Ongoing support, rule updates after ATT&CK version changes and repeat testing are available as a retainer
Confirm with DeployOpen during scoping which support level covers rule maintenance and range refreshes
Ask for a quote based on the written scope, since DeployOpen does not publish a price list

T1682 Query public AI services