How T1700 AI-enabled exfiltration shows up in a Windows and SaaS estate
In a Windows and SaaS estate, T1700 AI-enabled exfiltration is most likely to look like ordinary application use. An employee pastes customer records into an AI assistant, a browser extension forwards document content to a third-party service, or a sanctioned integration syncs far more data than its purpose requires. The adversary gains a way to move stolen data out through channels the organization already trusts, which makes the activity easy to miss in volume-based alerting. ATT&CK places this under the Exfiltration tactic, which it describes as: "The adversary is trying to steal data." (TA0010). In an intrusion, the activity would usually follow collection and staging, when data is handed to an AI-related service rather than sent to infrastructure the attacker controls.
The useful signals sit in three telemetry sources. Process Creation shows whether a browser, Office application or sync client is launching unexpected child processes that then reach outside services. Network Connection Creation shows outbound sessions to AI service endpoints initiated by processes that normally have no reason to talk to them. File Access shows reads of sensitive directories shortly before those sessions. On the SaaS side, the equivalent evidence is in upload events, new API tokens and OAuth grants to AI applications. Decide now which AI services are sanctioned, who approves new ones, and whether your sensors capture the content needed to tell a normal prompt from a bulk transfer. Confirm that coverage before promising detections.
Before writing any rule, confirm the T1700 record, its tactic mapping and its data component mapping in the ATT&CK version you target. ATT&CK v20 was released on October 13, 2026, and releases can rename, deprecate or revoke techniques, so a mapping that held in an earlier version may have changed. Check the ATT&CK updates page for the release history, and confirm the mapping in the STIX bundle for your version. Record the version in every detection so that later reviews can tell whether a finding still applies.
Which telemetry reveals T1700 on Windows and SaaS
This table maps each telemetry signal to its ATT&CK data component, the behavior to look for in words, and the open-source collector that captures it. Read it as a starting point for coverage planning: confirm each source exists in your environment before relying on it, and treat SaaS audit coverage as a vendor question rather than an assumption.
| Signal | Data component and what to look for | Open-source collector |
|---|---|---|
| Process creation on Windows endpoints | Process Creation (DC0032). Unexpected processes launching AI-related client tools, scripts or interpreters that then read data stores or make outbound requests. | Wazuh agent with Sysmon-style endpoint logging enabled for process creation events |
| Outbound connections from endpoints | Network Connection Creation (DC0082). Destinations that are AI service endpoints not on the approved list, or unusually large upload-oriented sessions from non-browser processes. | Wazuh agent or Sysmon-style network events, correlated with Zeek connection logs at the egress sensor |
| File reads on sensitive shares and folders | File Access (DC0055). Bulk or repeated reads of documents, source code or regulated records by a process or account that does not normally touch them. | Windows object access auditing forwarded through Wazuh, with Velociraptor hunts for historical file access |
| Staging of files before transfer | File Access (DC0055) and Process Creation (DC0032). Archive or compression tools running against sensitive paths shortly before outbound connections. | Wazuh rules on process and file events, plus Velociraptor artifact collection on flagged hosts |
| AI service sign-in and API activity | SaaS application audit logs. Logins, API key creation, large prompt or upload volumes and new integrations tied to unmanaged accounts. | Export through a log pipeline into Wazuh; confirm the vendor's log schema and retention with the SaaS provider |
| Browser-based uploads to AI tools | Network Connection Creation (DC0082) and file transfer metadata at the proxy or sensor. Uploads of sensitive file types to AI domains from managed endpoints. | Suricata or Zeek at the network sensor, with TLS metadata reviewed where inspection is permitted |
| Coverage gaps to confirm | Whether SaaS audit logs expose upload size, file names or only session events, and whether endpoint file auditing is enabled on the paths that matter. | Confirm with the vendor and your own configuration before testing detections in a cyber range |
Detection logic for T1700 that SOC teams can tune
The four to six ideas below pair a behavior with a baseline to tune against and the false positives to expect. Together they cover the three places T1700 AI-enabled exfiltration tends to surface: endpoint processes reaching AI service endpoints, sensitive file reads followed by outbound transfer, and SaaS uploads into AI tools outside approved tenants. Each one should be validated in a private cyber range before it is promoted to production alerting.
Unusual volume to AI endpoints
Flag processes that send materially more outbound bytes to known AI service domains than they do in their own baseline. Network Connection Creation and Network Traffic Flow records are the main inputs, grouped by process image, user and destination. Tune the threshold per process and per host group, using a rolling baseline of at least several weeks. Expect false positives from approved developer tooling, model-evaluation pipelines and sanctioned AI assistants, so maintain an allow list keyed to signed binaries and tenant identifiers rather than to domain names alone.
Sensitive reads before outbound transfer
Alert when a process that is not a known backup, sync or editor reads files matching sensitive data labels or paths and then opens an outbound connection to an AI service within a short window. File Access records joined with Network Connection Creation by process ID and time give the sequence. Tune the window length and the label set with data owners, since a short window produces noise and a long one hides the link. Expect false positives from legitimate document assistants and from users who open reports in a browser that also loads AI features.
Uploads to unapproved AI tenants
Detect uploads, shares or pastes to AI tools where the tenant or workspace identifier is not in the approved list. Network Traffic Content and SaaS application logs should be parsed for tenant identifiers, sharing events and file upload actions. Confirm with each SaaS vendor which log fields expose tenant and file metadata, since field availability varies by product and plan. Expect false positives from sanctioned enterprise AI workspaces that use a different tenant name than the one on the list, so keep the approved register current with procurement.
Non-standard processes calling AI APIs
Flag command-line AI API clients, scripts or unsigned binaries that make outbound calls to AI service endpoints when they are not on the software inventory for that host. Process Creation records with parent process, signer and file path provide the signal. Tune against the software inventory from endpoint management, and treat first-seen binaries as lower priority unless they also touch sensitive files. Expect false positives from data science workstations and build agents, which should be grouped separately with their own baselines.
Repeated small transfers over time
Look for many small outbound requests to the same AI endpoint from one host across a day or week, where each request is below the single-event threshold but the cumulative volume is large. This pattern is harder to see with per-event rules, so aggregate Network Traffic Flow by source, destination and day. Set the cumulative threshold against the host's own history and review hosts that sit above the peer group median. Expect false positives from chat-based tools used heavily by support or analyst teams, so review these alerts with the business owner before escalating.
How to validate that the T1700 detection fires
This sequence proves, in a private cyber range, that the T1700 AI-enabled exfiltration detection fires on benign test data, produces the telemetry it depends on, and leaves a record an auditor or incident lead can trace. It is a validation exercise only, with no attack tooling or payloads involved.
Define the benign test data and scope
The detection owner and the range lead agree on a set of synthetic records that look like the sensitive data classes the organization cares about, such as marked dummy customer files and fake identifiers, held only inside the range. They also write down the Windows hosts and SaaS tenant (a range or test tenant, never production) in scope. The step is done when the data set, its labels and the in-scope assets are approved in writing and each synthetic file is recorded with a unique marker so it can be traced later.
Map expected telemetry to each data component
Before the exercise, the team lists what each data component should show for the planned benign actions: Process Creation for the process that performs the activity, Network Connection Creation for outbound connections to the test destination, File Access for reads of the marked files, and Application Log Content for the SaaS side where the platform exposes it. For each row, they note the event source, the field that should carry the marker, and the expected direction of the connection. The step is complete when this expectation sheet is reviewed and signed off by the detection engineer, because it becomes the baseline the results are judged against.
Set the time window and pass criteria
The team fixes a single, bounded time window for the run, records its start and end in the exercise log, and writes explicit pass criteria before any activity begins. Criteria should state that the expected alert appears in Wazuh or the SIEM within the agreed window, that the alert references the T1700 rule and the ATT&CK version under test, and that the alert links to the marked test data. Durations are set by the team according to its own pipeline latency, which it should measure in its environment rather than assume. The step is done when the criteria are written down and agreed.
Run the benign activity and capture raw logs
A tester performs the agreed benign actions inside the range, such as moving marked files through an approved test channel to the test destination, while a second person watches the agent and SIEM consoles without interacting with the activity. Raw events are preserved from the endpoint agents and the SaaS audit source before any tuning or filtering. The step is done when the run is closed, the window is ended and the raw telemetry export is saved with a hash or checksum recorded alongside it.
Confirm rule firing in Wazuh or the SIEM
The detection engineer searches the alert index for the marked test identifiers and the T1700 rule, then checks that the alert fired once for each expected behavior and that its fields match the expectation sheet. They confirm that the rule version and the ATT&CK version tag on the alert are the ones being validated, and they note any alert that fired for an unexpected reason. The step is complete when each pass criterion has a yes or no answer with a link to the supporting event.
Check for gaps in connection and file logging
The team compares the raw Network Connection Creation and File Access records against the expectation sheet to find missing events, delayed events, or events that lack the marker field. Gaps are classified by cause, such as an audit policy that was never enabled, a agent that stopped reporting, a log source that drops events under load, or a SaaS audit feed with a longer delay than expected. Each gap is opened as a tracked finding with an owner. The step is done when every expected event is either present or has a documented reason for its absence.
Record evidence and alert fidelity
The team writes a validation record containing the exercise window timestamps, the rule identifier and version, the ATT&CK version, the list of test data markers, the telemetry gap findings, and an alert fidelity assessment that counts true positives, false positives and missed events for the run. Each alert is labeled with whether an analyst could act on it without additional context. The record is stored with the raw exports so that a compliance assessor or the detection owner can reproduce the decision later. The step closes when the record is reviewed and the detection is marked as validated, retested or returned for tuning.
Preventive controls against AI-enabled data theft
T1700 AI-enabled exfiltration is a technique that the team should not assume is blocked by any single control. The cards below cover the ATT&CK mitigations most often mapped to Exfiltration techniques, plus application isolation, and each one limits a different part of the data path. Read them together: file permissions reduce what can be read, content inspection and network filtering reduce what can leave, and isolation reduces what a compromised process can reach.
Restrict file and directory permissions
Restrict File and Directory Permissions (M1022) limits which accounts, service identities and processes can read the data an adversary would want to collect and stage. For T1700, this means tight access to repositories, shared drives, model artifacts and exported datasets that an AI workflow touches. It does not stop a process that already runs under an identity with legitimate read rights. Check that AI service accounts have only the read scope they need, that inherited permissions are reviewed on sensitive shares, and that file access auditing is enabled so that unexpected reads leave a trail. Confirm with your platform vendor which access controls apply to its connectors and indexing components.
Data loss prevention
Data Loss Prevention (M1057) inspects content and policy at points where data leaves the organization, such as email, endpoints, web uploads and cloud storage. For T1700, it is the control most likely to catch a prompt, file or API payload that carries regulated or proprietary data to an external AI service. Its limits are content it cannot classify, encrypted or compressed payloads it cannot inspect, and traffic that bypasses the sensors. Confirm with your DLP vendor which AI endpoints and browser or agent channels it can see, and whether it can act inline or only alert.
Network intrusion prevention
Network Intrusion Prevention (M1031) blocks network traffic that matches signatures, protocol anomalies or behavior rules. For T1700, it can interrupt known patterns of bulk transfer to external destinations and suspicious tunnels from AI tooling. It is weak against novel payload shapes and against traffic over encrypted channels it cannot decrypt or inspect at the metadata level. Ask your vendor which rule sets cover outbound AI-related destinations, whether TLS inspection is in scope, and how blocking decisions are logged for later review.
Filter network traffic
Filter Network Traffic (M1037) is the egress control that defines which destinations and protocols a host or workload may reach at all. For T1700, default-deny outbound rules for AI workloads, combined with an allow list of approved model and SaaS endpoints, shrink the set of places data can go. It does not explain why an approved endpoint is being misused, so pair it with logging. Confirm that the team can apply these rules per workload, that DNS resolution for blocked categories is also controlled, and that exceptions have a named owner and expiry.
Application isolation and sandboxing
Application Isolation and Sandboxing is a mitigation the team should map to T1700 in its own ATT&CK version, and it should confirm the mitigation ID before citing it in a control register. The idea is to run AI assistants, plugins and agents in restricted containers or sandboxes so that a compromised component cannot read arbitrary files or open arbitrary connections. Its limits depend on how much access the sandbox is granted for legitimate work. Ask your platform vendor which isolation boundaries are supported, which resources the agent can reach by default, and how sandbox policy is changed and audited.
What the SOC does in the first hour after a T1700 alert
The first hour after a T1700 alert is about deciding quickly whether the activity is a genuine AI-enabled transfer of data or a benign workflow, and about keeping the options open for containment. Start by comparing the alert against the normal behavior of the host or SaaS account: which process initiated the outbound connection or API activity, which user or service identity was signed in, and whether that process has a known reason to read the data class involved. Record the process name, parent process, command context, destination, and SaaS tenant or application ID in the case file before anyone changes state. Confirm the identity's role and the owner of any AI tool or connector involved, and ask the business owner to confirm whether the workflow was approved. Because ATT&CK version 20.0 is the reference for these pages, tag the case with the detection identifier and ATT&CK version your rule targets so later tuning is traceable.
Next, determine what data was touched. Map file access events and SaaS object reads to data classes such as customer records, source code, financial data, credentials or personal data, using your data classification register rather than file names alone. Decide on containment using a short, written rule set: isolate the endpoint when a process is still transferring data or the host is shared with other sensitive activity, revoke OAuth or API tokens and suspend the SaaS session when the identity is the likely path, and do both when the evidence points to a compromised account on a managed device. Preserve evidence before you remove access: export the relevant endpoint telemetry, memory or volatile data if your playbook calls for it, SaaS audit logs for the tenant and identity, and the alert record with timestamps. Scope across endpoints and SaaS logs by searching for the same process, token, destination and time window, and widen the search only when a second source confirms the activity. If personal data may be involved, bring in legal and privacy counsel early so that any notification assessment starts from preserved, accurate records. Confirm each of these steps and tool capabilities with your own platform owners before you rely on them in the playbook.
Rehearsing T1700 detection in a private cyber range
This segment is built from a small domain with Windows workstations and one server acting as a file share, each forwarding Process Creation, Network Connection Creation and File Access events to a central collector. Benign injects are scripted to mimic an approved AI desktop tool that reads a folder of synthetic client records, packages them into an archive and sends them to an external API endpoint on a schedule. Expected detections include a new process with an unusual parent launching an uploader, a burst of reads across a sensitive share, and outbound connections to a destination not on the approved list. Blue team response is to isolate the test host, confirm the process tree, review file access scope and record which accounts were involved. Illustrative target: the first alert should appear within the latency the team has documented as acceptable for its SIEM pipeline. Confirm the logging policy and audit subcategories on your own build before the exercise, since the exact events depend on configuration.
- Telemetry forwarding: Verify that the forwarder ships events from every workstation and the file server, and record any gap in the first hour.
- Benign injects: Use synthetic records only, labeled as test data, so the exercise never touches production content.
- Expected detections: Process ancestry, file access volume and new outbound destinations should each raise an alert mapped to the relevant detection strategy.
- Response actions: Isolate, preserve volatile evidence, identify the scope of files touched and document the account chain.
- Good looks like: Correct host and user scoping, alert latency recorded, and an evidence bundle that another analyst can replay.
Before the run, confirm which Windows audit settings produce the events you expect on your build.
This tab uses a non-production SaaS tenant or a vendor sandbox where audit logging is enabled and exported to the same collector as the endpoint events. The range topology is a test workspace with a few seeded documents, a test service account and a connected AI integration that the team has approved for the exercise. Benign injects simulate an integration pulling a large set of documents, creating a share link to an outside address and exporting a report in bulk. Expected detections focus on unusual export volume, sharing with external domains and integration grants that were not in the baseline. Blue team response covers revoking the test token, reviewing sharing permissions, checking which items were accessed and confirming whether any retention or data loss controls triggered. Confirm with the vendor which audit events are available on your plan and how long they are retained, because log availability varies by product and license.
- Audit logging: Enable the tenant audit log and confirm the export path to the collector before any inject runs.
- Benign injects: Use seeded documents and a dedicated test account, with the AI integration scoped to test content only.
- Expected detections: Bulk export, external sharing and new integration consent should each generate a reviewable alert.
- Response actions: Revoke the integration token, remove external links, review the access trail and notify the test data owner.
- Good looks like: A clear record of which items were touched, a documented revocation time and no reliance on manual screenshots as evidence.
Record the exact audit event names your tenant produces, so the detection logic can be tuned to what you actually see.
This segment places a passive sensor on the egress path of the range, with Zeek or Suricata capturing connection metadata and selected protocol content from the endpoint and SaaS-facing traffic. The topology mirrors the production egress design as closely as the range allows, including the proxy or firewall the team would expect to control outbound traffic. Benign injects send structured payloads of synthetic data to an approved AI endpoint and to an unapproved one, varying size, timing and frequency so that the team can compare what the sensor sees with what it should alert on. Expected detections include flows to destinations outside the allowlist, sustained upload volume that exceeds the baseline and payloads that match a data classification rule. Blue team response is to block the test destination at the egress control, confirm that the blocked traffic is logged and correlate the flow with the endpoint and SaaS alerts. Confirm which protocol parsers your sensor version supports before you depend on content inspection for any AI API.
- Sensor placement: Mirror egress traffic from the test network and confirm that both the endpoint and SaaS-facing flows are visible.
- Benign injects: Vary payload size, timing and destination to test thresholds rather than a single fixed pattern.
- Expected detections: Destination allowlist violations, upload volume against baseline and classification matches should each produce a signal.
- Response actions: Block the destination, verify the block event, and correlate the flow identifiers with endpoint and SaaS records.
- Good looks like: Each alert ties to a flow the team can replay, with correlation time recorded and no unexplained gaps in sensor coverage.
Check how your sensor handles encrypted traffic, because visibility into payloads depends on whether you hold the keys or inspect at a proxy.
Questions SOC leads ask about detecting T1700
How do you detect AI-related exfiltration when no established pattern exists?
Start from the behavior, not from a vendor signature. ATT&CK defines the Exfiltration tactic (TA0010) as the adversary trying to steal data, so build hypotheses around data leaving the environment. Combine Network Connection Creation, Process Creation and File Access telemetry, then add Network Traffic Flow and Network Traffic Content where your sensors can inspect them. Baseline the AI services your organization already uses, and alert on large uploads of sensitive files to destinations outside that baseline. Write each hypothesis as a rule with its ATT&CK version in the metadata, and confirm the T1700 mapping against the version you target before you depend on it.
How do you tell approved AI tools from unsanctioned ones in logs?
Maintain a versioned allowlist of sanctioned AI domains, SaaS tenants and single sign-on applications, sourced from procurement and identity records rather than from memory. Match traffic on destination domain, proxy category and the tenant identifier that SaaS audit logs record. Alert on first-seen AI domains, on personal accounts signing in from managed endpoints, and on uploads to services outside the list. Review the allowlist on a fixed schedule with the business owners who approved each tool, and record every change so an auditor can trace why a destination was sanctioned at a given date.
Which logs do you need for SaaS coverage of exfiltration?
Collect identity provider sign-in and token events, SaaS administrator and audit logs, file sharing and download events, and secure web gateway or proxy logs for the destinations users reach. Add data loss prevention or cloud access security broker events if those controls already exist, and endpoint file access for managed devices so you can connect a local file to a later upload. Confirm the exact event names and retention periods in each vendor's documentation, check that all sources use synchronized time, and test that a sample exfiltration action produces an event in each source before you rely on the detection.
How do you tune Process Creation rules to reduce noise?
Scope each rule by parent process, binary path, signer and user context before adding any exclusion. Use documented automation and backup tooling as the only exclusions, and record each one with an owner, a reason and an expiry date. Prefer time-windowed thresholds over single-event matches for behavior that legitimate jobs also produce. Review false positives weekly, separate high-fidelity alerts that page someone from hunting queries that only feed a review queue, and rerun the tuned rule against a lab dataset to confirm that the detection still fires on the behavior it was written for.
How do you confirm the ATT&CK mapping when a new version is released?
Check the ATT&CK updates page for the version you target, then read the release notes for renamed, deprecated or revoked techniques. Compare the STIX bundle for your domain in the attack-stix-data repository against the bundle you used before, and update any rule whose technique or sub-technique changed. Note that ATT&CK v18 replaced detections in technique pages with detection strategies and analytics, so older mappings may need a different reference. Record the version in each rule's metadata, keep the diff in your change log, and schedule the review for every release you plan to track.
How can you test exfiltration detections without moving real data?
Test in a private cyber range with synthetic datasets and canary files that carry unique markers, and send traffic only to lab-controlled endpoints. Run each scenario, then check that the expected alert reaches your SIEM or Wazuh and Security Onion dashboards, and record the time from action to alert. Compare expected and observed results for each data source, and keep the test plan, timestamps and results as evidence for later review. Production data should never be part of the test. DeployOpen runs private cyber ranges and security testing, and the scope of any such exercise is agreed in writing before work begins.
How DeployOpen builds T1700 detections and purple team exercises
DeployOpen approaches T1700 AI-enabled exfiltration as a fixed-scope engagement inside your own environment, with detection logic mapped to the ATT&CK version you target. Each step produces documented detections, validation evidence and a rehearsal plan that your own team can run and maintain.
How we scope
- Agree in writing which Windows hosts, SaaS applications and log sources fall within the T1700 engagement.
- Confirm which ATT&CK version the detection mappings will target before any rule work begins.
- Record the telemetry you already collect for Process Creation, Network Connection Creation and File Access, and note any gaps.
How we build
- Write detection logic for T1700 in Sigma and translate it to your SIEM or Wazuh rule format.
- Map each detection to its data components and the mitigations Restrict File and Directory Permissions and Application Isolation and Sandboxing.
- Tune alert thresholds against your baseline activity so analysts receive findings they can act on.
How we hand over
- Deliver rule files, test records and a coverage matrix that names the ATT&CK version used.
- Document the response steps for each alert, including who escalates, what to preserve and when to isolate a host.
- Run a purple team walkthrough in a private cyber range so your analysts can replay the detections themselves.
How we support
- Offer ongoing support as a retainer to retune rules when your SaaS applications or log sources change.
- Review detection coverage when MITRE releases a new ATT&CK version that renames or revokes related content.
- Schedule repeat exercises in the cyber range so detection quality is tested again after platform upgrades.
