How T1567 exfiltration over web service hides data in normal web traffic
If you run a SOC, the question is whether sensitive data could leave your network through web services that look like ordinary HTTPS traffic. In MITRE ATT&CK, T1567 Exfiltration over web service describes this behavior: an adversary moves data out through an existing web service instead of a dedicated command channel. It sits under the Exfiltration tactic, TA0010, which ATT&CK defines as "The adversary is trying to steal data." This page targets ATT&CK version 20.0, and you should map your detections to that version. The tactic page for TA0010 is the natural starting point for the tactic's scope and related techniques.
ATT&CK groups T1567 into four sub-techniques. This section does not describe how each one is carried out. Instead, confirm their identifiers and names in the v20.0 Enterprise content before you write any rule, because sub-technique scope can change between releases. The first practical decision is an inventory: which web services are sanctioned for business use, which are tolerated but unmanaged, and which are blocked outright. Many organizations discover that the highest-risk destinations are not the obvious file-sharing sites but general-purpose services with upload features. Document the owner and approved data classes for each service so that a later alert can be judged quickly.
Because the traffic looks normal, port and protocol checks rarely help. Detection depends on context: which process or host opened the connection, whether the destination category matches the business role, and whether upload volume departs from the device's baseline. ATT&CK's detection content for this tactic most often references Process Creation, Network Connection Creation and Network Traffic Flow, so confirm your Wazuh, Zeek or Suricata sources actually produce those fields. Also confirm that your proxy or DNS logs record the destination domain, since TLS hides the path and payload. Plan for false positives from sanctioned backup and collaboration tools, and tune those exceptions against the inventory.
Which telemetry reveals web service exfiltration
This table maps each ATT&CK data component referenced for T1567 to the signal it gives defenders, the platforms where it applies, and an open-source collector that can gather it. Read it as a starting point: the data component list comes from the ATT&CK v20.0 STIX bundle, but coverage in your own estate must be confirmed before you rely on any single source.
| Data component | Signal for T1567 | Platforms and collector |
|---|---|---|
| Process Creation (DC0032) | Launch of browsers, sync clients, scripts or utilities that push data to a web endpoint | Linux, macOS, Office Suite and ESXi where process events are available; Wazuh agents or Velociraptor |
| Network Connection Creation (DC0082) | Outbound sessions from hosts or processes to cloud storage, paste or file-sharing domains | Endpoints and servers; Zeek connection logs, Suricata flow events, or host sensors in Security Onion |
| Network Traffic Flow (DC0078) | Volume and direction of bytes sent to web services, useful for spotting unusual upload totals | Network perimeter and egress points; Zeek conn.log and Suricata flow records |
| File Access (DC0055) | Reads of sensitive directories immediately before an upload, or staging into archives | Linux, macOS and Windows file auditing; Wazuh file integrity monitoring and Velociraptor artifacts |
| Network Traffic Content (DC0085) | Content-level indicators such as upload requests, TLS server names or HTTP methods, where inspection is permitted | Requires decryption or TLS metadata policy; Zeek HTTP and SSL logs, Suricata rules |
| Command Execution (DC0064) | Shell or script commands that invoke transfer tools against web endpoints | Linux, macOS and ESXi shells; Wazuh command monitoring and Velociraptor hunts |
Detection logic for web service uploads that do not fit the baseline
Web service exfiltration rarely looks malicious on its own, because the destination is a legitimate domain and the protocol is ordinary HTTPS. The cards below describe deviations from a measured baseline that, taken together, separate suspicious uploads from sanctioned sync, backup and developer traffic. Tune each threshold against your own telemetry before alerting.
Unusual outbound volume to web services
Track bytes sent, not connections, from each host and user to web service domains over rolling windows. Compare each host against its own history and against peers in the same role, since a workstation that uploads several gigabytes in an afternoon is a stronger signal than a server that does so every night. Set the threshold per host group and review the top talkers weekly during tuning. False positives come from backup agents, cloud photo and file sync clients, large CI artifact pushes and video conferencing uploads, so exclude known agents by process and destination before alerting.
First-seen destinations for a process
Flag the first time a given process or user sends data to a web service domain that has no history for that process in the baseline period. The useful pairing is the process name with the destination domain, not the domain alone, because a browser reaching a new site is ordinary while a script reaching a file-hosting domain is not. Enrich first-seen domains with age and category data before triage. Expect noise after software rollouts, new SaaS onboarding and developer tool updates, so suppress alerts for change-managed deployments and document each approved destination.
Uploads from processes outside web use
Alert when a process that does not normally use the web, such as a database client, archive utility, scripting host or system service, opens outbound HTTPS sessions that carry large request bodies. This check depends on process creation and network connection records being correlated by process identifier. Build an allow list from the software inventory for each platform, including ESXi management components and Linux service accounts, and review entries that appear only once. False positives include package managers, configuration management agents and monitoring agents that push telemetry.
Domain category mismatches with business use
Compare the category of each destination against the business function of the sending group. A finance or engineering host uploading to a personal file-sharing or paste category, or a server with no user-facing role reaching a consumer storage service, is a mismatch worth reviewing. Confirm category sources with your secure web gateway or DNS filtering vendor, because category labels change and coverage differs by product. Expect false positives from users who sanctioned personal tools for approved work, so route these to the business owner for confirmation rather than treating them as incidents.
Upload size outliers in request bodies
Where TLS inspection or proxy logs expose request sizes, flag uploads whose bodies are far larger than the host's typical request profile, especially when they arrive in long, steady streams. Measure the size distribution per application rather than globally, since a sync client's uploads and a browser form submission differ by orders of magnitude. Confirm with your own inspection platform what is visible for encrypted traffic, because without decryption only byte counts and timing are available. False positives include scheduled backups, log shipping and large model or dataset transfers for approved projects.
How to confirm the detection fires before you trust it
This sequence turns a T1567 detection idea into evidence you can repeat, showing that the expected telemetry arrives, the alert fires and reaches the right responders, and that the results can be replayed when the targeted ATT&CK version changes.
Write the hypothesis and scope
The detection owner writes one testable hypothesis for T1567 Exfiltration over web service, naming the platforms in scope (for example Linux, macOS, ESXi or Office Suite), the sub-technique scope, the data components expected to show the behavior (Process Creation, Network Connection Creation and Network Traffic Flow) and the exact ATT&CK version the detection targets. The hypothesis is done when the security lead signs it off and it states what a passing and a failing result look like. Illustrative: a hypothesis that says a web-upload path from a server process should appear as a Network Connection Creation event within the SIEM index used for network telemetry.
Select sub-technique scope and sandbox
The team selects which of the four T1567 sub-techniques to cover in this run and confirms the target systems are inside a private cyber range or isolated lab with no route to production data or external services. The owner records the asset inventory, the operating systems, and the approved accounts used for the exercise. The step closes when the scope document lists the in-scope assets and the ATT&CK version, and an approver outside the detection team has reviewed the isolation controls. Ask your range provider to confirm the isolation design in writing before any run.
Run the emulation under change control
A named operator runs the agreed emulation steps inside the approved change window, with a second person observing and a rollback plan documented before start. The operator logs start and end times, the host and account used, and any deviation from the plan. Emulation tooling and any adversary emulation plans should be drawn from vetted, documented sources and kept within the agreed scope. The step is done when the change record is closed with the activity log attached.
Check telemetry arrival in the SIEM
Before judging the rule, the analyst confirms the raw events arrived in the SIEM or log platform, such as Wazuh or Security Onion, with the expected fields populated and timestamps in the correct time zone. The check covers agent health, collector backlog and parsing, since a missing field can make a correct rule look broken. The step is complete when each expected data component has a documented sample event with a reference to the originating host and the run identifier.
Confirm the alert fires and routes
The analyst verifies that the Sigma or native rule matched the sample events, produced an alert with the expected severity, and reached the correct queue, on-call rotation or ticketing integration. Testers should also confirm that a benign control activity, run in the same window, did not generate the alert. The step closes when the alert record, routing record and false-positive control are saved together. Confirm with your SIEM or SOAR administrator which notification paths are live in the range.
Test the response playbook path
The responder works the alert through the documented playbook, covering triage, scoping of affected hosts, data loss prevention review and containment decisions, without changing production controls. The lead records whether each playbook step was actionable with the evidence available, and notes any step that required information the telemetry did not provide. The step is done when the playbook run has timestamps for each handoff and a list of gaps.
Record results for regression testing
The detection owner writes a results record that states the hypothesis, ATT&CK version, sub-techniques covered, data components observed, alert outcome, false-positive control result and open gaps. The record is stored with the rule version and the telemetry configuration so the same run can be repeated after rule changes, SIEM upgrades or a new ATT&CK release. Re-run the test whenever MITRE changes the technique, its sub-techniques or its data component mapping, and confirm the change against the ATT&CK update notes before accepting the old result.
Preventive controls that narrow web service exfiltration
Preventive controls cannot stop every upload, but they shrink the set of destinations and content types an attacker can use to move data out through a web service. The cards below cover the two ATT&CK mitigations most directly tied to T1567, plus network controls that support them, and each one should be confirmed against the specific product in your environment.
Data loss prevention on uploads
Data loss prevention (M1057) is the ATT&CK mitigation most directly aimed at this technique. In practice, DLP products inspect outbound content at the endpoint, proxy or cloud access layer, looking for sensitive patterns such as customer identifiers, source code or classified markings, and can block or require justification when a match is found. Confirm with each vendor whether it inspects uploads to unmanaged web services, encrypted sessions, and browser-based uploads, since coverage often differs by channel and by operating system.
Restricting reachable web services
Restrict Web-Based Content is the control that limits which web services users and servers can reach at all. Allow lists for cloud storage, file sharing and paste sites, enforced through a secure web gateway or proxy, remove many exfiltration destinations before any content is inspected. Ask each vendor how its category filters are maintained, how exceptions are approved, and whether policy applies to personal accounts on sanctioned services as well as unknown domains.
Blocking traffic from servers
Servers rarely need to browse the web or sign in to consumer file services, so outbound rules for server subnets are often the cheapest reduction in exposure. Filter Network Traffic (M1037) supports this by allowing servers only to the destinations they need for updates, backups and business APIs. Document each allowed destination with its owner and review it on a schedule, because a single broad rule can reopen the channel the control was meant to close.
Intrusion prevention on exfiltration patterns
Network Intrusion Prevention (M1031) can block known malicious traffic and some anomalous transfer behavior at the network edge, but signatures rarely cover a legitimate web service used for theft. Treat it as a complement to DLP and destination controls, not a replacement. Confirm which rule sets your product ships, how often they are updated, and whether it can inspect TLS traffic under your privacy and legal constraints.
Verifying controls in a cyber range
A control that is configured but never tested gives false confidence. In a private cyber range, run an approved test upload to a permitted and a blocked web service, then confirm that the DLP, proxy and firewall logs record the decision. Record the ATT&CK version you target, since mappings can change between releases, and keep the test evidence for your compliance team.
What SOC analysts do in the first hour after an exfiltration alert
The first decision in an exfiltration alert for T1567 Exfiltration over web service is whether the destination is sanctioned. Analysts should check the domain, the tenant or account identifier, and the application against the approved list maintained by the business and IT owners of the web service. Confirm whether the traffic matches a known sync client, a sanctioned SaaS integration or an expected API consumer. Record the answer in the ticket before anything else, because it determines whether this is a policy violation, an unsanctioned tool, or a confirmed malicious transfer. Where the destination cannot be classified within a few minutes, treat it as unsanctioned and move to containment planning while the review continues.
Next, identify the user, host and process tied to the outbound session. Pull the account identity, the endpoint name, the process name and its parent, and the time window from the Process Creation and Network Connection Creation events in Wazuh or Security Onion, and correlate them with the Network Traffic Flow records in Zeek. Preserve those logs with their original timestamps and hashes before any rotation or cleanup runs. If the host is involved, collect volatile and file artifacts with Velociraptor according to your evidence handling procedure, and document who collected what and when. Confirm with the data owner which systems and datasets the user can reach, so the scope of possible data loss is understood early.
Choose containment proportionate to the evidence. Options include blocking the destination or the specific session at the web proxy or firewall, restricting the account's access to the web service, or isolating the host from the network while keeping management access open. Each option has a business cost, so document the justification and the approver. If personal data, payment data or regulated records may be involved, notify the data owner, legal and the privacy team at once, because their clock and reporting obligations may start before the investigation ends. Ask your privacy and legal teams which internal thresholds apply, and confirm them in writing before the first hour closes.
Rehearsing T1567 detection in a private cyber range
A private cyber range for T1567 needs a segmented network that resembles production closely enough for web-based transfers to behave the same way. The range should contain monitored endpoints across the platforms in scope for this technique, a web service simulator that accepts uploads and posts to represent sanctioned and unsanctioned destinations, and the open-source sensors that produce the telemetry your analytics depend on. Keep the range isolated from production networks and from the internet, and route any simulated external destinations through controlled egress points so that no real data leaves the environment.
- Segmented network: Separate the range into zones for endpoints, servers, and the simulated external web services, with firewall rules you can log and change during the exercise.
- Monitored endpoints: Install agents on Linux, macOS, and Windows hosts, and include ESXi or Office Suite test accounts where those platforms are in scope, so process and network telemetry is available on each.
- Web service simulator: Deploy a controlled service that mimics common file-hosting and messaging destinations, with allowlisted and non-allowlisted hostnames.
- Open-source sensors: Feed Wazuh agents, Zeek or Suricata network sensors, and Security Onion or Sigma-based detections from the same time source so events can be correlated.
- Baseline capture: Record a quiet period before each run so you can separate exercise traffic from normal activity.
Before the build, confirm with your team which telemetry sources each platform actually produces, because coverage gaps found in the range are cheaper to fix than gaps found in production.
Injects are the scripted data movement scenarios that the exercise team runs in the range. Each inject should use benign or synthetic data, name the destination in advance, and be labeled as either sanctioned or unsanctioned in the exercise plan. Sanctioned destinations are approved business services, such as a corporate collaboration tool that the policy allows. Unsanctioned destinations are personal or unapproved services that the policy should block or flag. Planning both lets you test whether detections fire on the behavior you care about, not only on a known bad hostname.
- Sanctioned upload: A user uploads a synthetic document to an approved service, which tests whether the detection stays quiet or is correctly tuned to expected traffic.
- Unsanctioned upload: A user sends a synthetic file to a personal file-hosting endpoint, which tests Process Creation and Network Connection Creation correlation.
- Browser-based transfer: A user moves data through a web form on an unapproved site, which tests whether Restrict Web-Based Content controls and network telemetry agree.
- Scripted API transfer: A test process posts synthetic data to a web endpoint, which tests whether Network Traffic Flow analytics catch unusual volume or destinations.
- Repeated low-volume transfer: Spread small transfers over time, which tests whether thresholds and aggregation rules hold up.
Document each inject's expected detection and expected control result before the run, so the review compares outcomes against a written plan.
A successful exercise is measured by the quality of decisions, not by how many alerts fire. Judge detections on alert fidelity, meaning whether alerts point to the injected behavior and avoid noise from sanctioned traffic. Measure time to triage, meaning how long analysts take to confirm or dismiss each alert, and record containment decisions, including whether the team blocked the destination, isolated the endpoint, or escalated. Every decision should be traceable to a documented rule or playbook step.
- Alert fidelity: Track true positives, false positives, and missed injects for each scenario, and tie each miss to a specific data source or rule.
- Time to triage: Record when the alert appeared, when an analyst acknowledged it, and when a disposition was made, then review where the time went.
- Containment decisions: Note who made each decision, the criteria used, and whether the action could be reversed without business disruption.
- Documented lessons: Produce a written after-action report with owners and due dates for each tuning change, rule update, or playbook edit.
- Retest: Rerun failed injects after changes to confirm the fix works and does not create new noise.
Set scope and rules of engagement in writing before the exercise, including which systems are in the range, who may stop the exercise, and what evidence must be retained.
Questions SOC leads ask about T1567 detection
How do I separate sanctioned SaaS sync from T1567 exfiltration?
Start by building an approved-service inventory that names each sanctioned sync client, its expected user agents, destination domains and typical data volumes per user. Sanctioned sync usually runs from managed endpoints under known process names and follows predictable schedules, while exfiltration tends to come from unexpected processes, unmanaged hosts, new destinations or unusual upload bursts. Alert on the gap between observed behavior and that baseline rather than on the mere presence of a cloud storage domain, and review exceptions with the business owner of each service. Expect the allowlist to need regular review as users adopt new tools.
Is TLS inspection required to detect exfiltration over web service?
No, TLS inspection is not strictly required, but it makes content-level detection much stronger. Without it, you can still rely on Network Connection Creation and Network Traffic Flow metadata such as destination domain, server name indication, byte counts, upload-to-download ratios and session timing, which Zeek and Suricata record without decrypting traffic. Inspection adds visibility into what was uploaded, but it brings privacy, legal and certificate-pinning trade-offs that must be approved by your governance and legal teams first. Confirm the approach with your privacy office before deploying it.
How should we tune detections when ATT&CK changes between versions?
Name the ATT&CK version each detection targets in its metadata, and check release notes before each update. ATT&CK v18 replaced detections on technique pages with detection strategies and analytics and deprecated some data sources, so rules written against older mappings may need to be re-mapped to current data component IDs. Recent releases include v19 and v20, and releases can rename, deprecate or revoke techniques. Track these changes in your detection-as-code repository so each rule records its mapping and its last review date.
How can we test T1567 detections without using production data?
Use a private cyber range with synthetic datasets that mimic your file sizes, user patterns and sanctioned services, and replay the traffic against your sensors. Generate sample files that carry clearly marked fake sensitive markers, so DLP and content rules can be verified without touching real records. Keep the range isolated from production networks, record each test with its expected alert, and compare the results with what your SIEM actually raised. Illustrative example: a test upload of a marked file to an approved test tenant should produce a single, correctly tagged alert.
How do we measure detection regression over time?
Keep a fixed library of test cases, each linked to a detection rule, an ATT&CK version and an expected outcome, and rerun the library after every rule change, sensor update or ATT&CK release. Track the rate of expected alerts that fire, the false-positive volume per sanctioned service and the time from event to alert, and trend those numbers across runs. Investigate any drop in detection before rolling changes to production. Record results as evidence so auditors can see that controls were tested and retested.
Which data sources should we confirm before writing T1567 rules?
Confirm that you collect Process Creation logs from endpoints and servers, Network Connection Creation records from firewalls or EDR, and Network Traffic Flow metadata from Zeek or similar sensors. Check that proxy or secure web gateway logs include destination domain, user, bytes sent and the requesting process where available, because these fields drive most rules. Also verify retention and time synchronization across sources, since correlating a process event with a later upload depends on accurate timestamps. Confirm each field with your own vendors and platform configuration, as capabilities vary by product.
Does DeployOpen run these tests and tuning for us?
DeployOpen plans, implements and documents open-source detection platforms inside your own infrastructure, and it runs security testing and private cyber ranges. Engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing tuning and continuous testing are available as retainers. Your team can also run these tests itself once the range and rule library are in place. Ask for a written scope that names the ATT&CK version, data sources and test cases covered.
How DeployOpen builds T1567 detections and range exercises
DeployOpen works on T1567 Exfiltration over web service as a fixed-scope engagement inside your own environment, with the scope agreed in writing before work starts. The result is a detection set, a validation plan and a cyber range exercise your team can repeat after the engagement ends.
How we scope
- Confirm which web services, SaaS platforms and endpoints in your estate are in the written scope for T1567.
- Inventory the telemetry you already collect, such as process creation, network connection and network traffic flow logs.
- Agree the ATT&CK version the detection mapping will target, since releases can rename or deprecate techniques.
How we build
- Write detection logic for each sub-technique in scope, described in plain language and mapped to the data components referenced by ATT&CK.
- Build open-source pipelines with tools such as Wazuh, Security Onion, Suricata or Zeek where your environment calls for them.
- Document the mitigations in scope, including Data Loss Prevention and Restrict Web-Based Content, with the configuration evidence an assessor would ask for.
How we hand over
- Deliver the detection logic, test results and tuning notes in a format your security engineers can maintain.
- Run a cyber range exercise that simulates web-service exfiltration in a private range and record what your team detected.
- Provide a response runbook and a list of open gaps, with owners and dates agreed with your team.
How we support
- Ongoing support, upgrades and continuous testing for T1567 detections are available as a retainer, agreed separately.
- Revalidate detections when your SaaS providers, endpoint agents or the ATT&CK version change.
- Ask any provider, including DeployOpen, to confirm in writing which retainer tasks and review cycles are included.
