Detecting T1102 Web service

Why T1102 Web service blends into normal web traffic

For a SOC lead, the core difficulty with T1102 Web service is that it hides inside traffic the business expects. Most organizations allow outbound HTTP and HTTPS almost everywhere, to search engines, code repositories, cloud storage and collaboration tools, so a connection to a legitimate web service rarely looks suspicious on its own. MITRE places this technique under Command and Control (TA0011), which ATT&CK defines as: "The adversary is trying to communicate with compromised systems to control them." This page targets ATT&CK 20.0, so every detection mapping and technique ID should be checked against that version before it reaches production. The ATT&CK tactic page for TA0011 is the natural starting point for the tactic definition.

T1102 has three sub-techniques. At a high level, they differ in how the web service is used. In one pattern, the compromised system reads content that was staged in advance on a public service. In the others, the service carries exchanges in one direction or in both directions. The distinction matters for detection because each pattern leaves a different shape in logs, from a small set of repeated requests to a steady, two-way exchange. Confirm the exact sub-technique names and descriptions against the ATT&CK 20.0 entry for T1102 in your own tooling, since wording can change between releases.

The decision in front of the SOC lead is which web services each host class is allowed to reach, and whether that baseline is visible in telemetry. Start by inventorying the web services that servers and workstations legitimately use, then identify systems that should rarely or never reach public web services, such as hypervisor hosts and many back-end Linux servers. Ask your sensor and SIEM team whether network connection and HTTP content records can be tied to a process, user and host, because the same domain can be ordinary for a browser and suspicious for a service account. Those per-host baselines are what separate business use from control traffic.

Which telemetry reveals T1102 Web service

This table maps the four data components most relevant to T1102 Web Service to the signal each one gives a defender and the open-source collector that typically produces it. Read it as a starting point for choosing sensors, then confirm the exact data components in the ATT&CK version your detection content targets, since v18 deprecated data sources and reorganized data components.

Data component	Signal for T1102	Open-source collector
Network Connection Creation (DC0082)	Endpoint process opening outbound connections to well-known web services, such as a sensitive host reaching a public code-hosting or paste site it does not normally use	Sysmon for Windows, Wazuh agent on Linux and macOS
Network Traffic Flow (DC0078)	Flow metadata showing repeated, periodic sessions from one host to the same web service endpoint, including destinations that do not match business use	Zeek connection logs, Security Onion
Network Traffic Content (DC0085)	Visible HTTP host headers, TLS server names and request paths that identify the web service, where traffic is not encrypted or inspection is in place	Zeek HTTP and SSL logs, Suricata rules and alerts
Process Creation (DC0032)	Non-browser binaries or scripts starting and making web requests, which often marks the process that uses a web service as a command channel	Sysmon for Windows, Wazuh process monitoring, Velociraptor hunts
Mapping version check	Confirm the DC IDs and data source names in the ATT&CK version you target, since v18 deprecated data sources and updated data components	Document the version in each Sigma or Wazuh rule you ship

Detection logic for T1102 Web service in words

T1102 Web Service covers adversaries who hide command and control traffic inside legitimate web services. The ideas below work together: each one narrows a different signal, and each needs a baseline built from the host's normal behavior before thresholds mean anything. Tune every threshold in your own environment and test it in a cyber range before production use.

Rare destinations from non-browser processes

Build a baseline of the domains each non-browser process normally contacts over HTTP and HTTPS, using Network Connection Creation records that include the process name and destination. Flag a process that reaches a destination it has never contacted, especially a command-line tool, script host or service account process. Set the threshold as a count of first-seen destinations per process per day, and tune it against your update and monitoring schedules. Expect false positives from package managers, endpoint agents, sync clients and SaaS integrations, so maintain an approved destination list per process.

Periodic timing over web protocols

Beaconing shows up as regular intervals between connections to the same destination, even when payloads look ordinary. Compute the interval between successive Network Traffic Flow records for each host and destination pair, then score how consistent those intervals are. Use a jitter tolerance you set from observed baselines rather than a fixed value, and require a minimum number of connections before alerting. Expect false positives from health checks, heartbeat APIs, telemetry agents and scheduled sync jobs, which also repeat on fixed intervals.

Header and user agent consistency

Compare the user agent and request headers a process sends against the values it sent during its baseline period. A process whose user agent changes, or that sends headers no other instance of the same software sends, deserves review. Network Traffic Content gives visibility into these fields only where your sensors decrypt or log them, so confirm that coverage before writing the rule. Expect false positives after software upgrades, proxy changes and SDK updates, so correlate changes with change records.

First-seen web service domains per host

Track the first time each host resolves or connects to a web service domain, and alert on new domains that are not explained by the host's role. Pair this with domain age or reputation feeds where your organization has them, and treat a first-seen domain on a server with no business reason for browsing as a higher priority. Set the look-back window to match how often your fleet changes. Expect false positives from new SaaS tenants, vendor onboarding and cloud service regions that go live without notice.

Web service access outside an approved list

Maintain an approved list of web services by system class, such as which servers may reach cloud storage, paste sites or code hosting. Alert when a host in a restricted class reaches a service outside its list, and log the attempt even when a proxy blocks it, since blocked attempts still show intent. Review the list with application owners on a fixed schedule and tie exceptions to a documented approval. Expect false positives from legitimate new vendors and shadow IT, which the list review should surface.

How the three sub-techniques differ across ESXi, Linux, macOS and Windows

The main difference across platforms is where the signal lives. On ESXi management hosts, there is seldom a legitimate reason to reach a general-purpose public web service, so any outbound request from a hypervisor or its management network deserves attention. ESXi usually offers limited local telemetry, so the dependable view comes from the network side: firewall flow records and Zeek or Suricata sensors on the management VLAN. On Linux servers, the emphasis shifts to process-to-socket correlation. Ask which binary opened the connection, under which account, and whether a server that normally talks only to internal services has started fetching content from a public web host. Confirm which fields your audit and sensor stack records before you write any rule.

On macOS endpoints, users browse all day, so a web request alone tells you little. The useful question is which non-browser process made it. Endpoint telemetry should record the parent process of outbound connections from scripting interpreters, launch agents and unsigned binaries, then compare their destinations against a baseline of what those processes normally contact. On Windows endpoints, Network Connection Creation events paired with Process Creation events give the same process-level pairing. Where an inspecting proxy sits in the path, Network Traffic Content adds request metadata that helps separate ordinary browsing from automated retrieval. Confirm which of these fields your EDR or sensor exposes, since coverage differs by product and version.

Across all four platforms, the three sub-techniques differ mainly in traffic shape, and that shape determines what to baseline. A dead drop pattern shows a short, infrequent retrieval from a public service. A bidirectional pattern shows repeated request and response cycles with a service that also accepts uploads, which Network Traffic Flow can expose through regular timing between sessions. A one-way pattern shows outbound posting with little return traffic. Confirm the exact sub-technique names and descriptions in the enterprise-attack 20.0 bundle before you map them to rules, because names and scope can change between ATT&CK versions. Agree a baseline period with your SOC for one host per platform, and record the results against the version you target.

How to validate that the T1102 detection fires

This sequence proves, in a private cyber range, that the T1102 Web Service detection logic fires on benign web service traffic from a test host, and that each alert can be traced to a host, destination and rule ID. It turns a written detection into evidence that can be shared with the security operations team and assessors.

Agree scope and rules of engagement
The detection owner, the SOC lead and the cyber range operator agree in writing which test hosts, network segments, web services and time windows are in scope. They also agree who may start an emulation, how it is stopped, and which alerts are expected to be suppressed afterward. The step is done when the signed rules of engagement name the ATT&CK version the detection targets, the sub-techniques under test, and an owner for stopping the exercise.
Select a benign web service emulation
The red team or range operator chooses a benign emulation that produces web service traffic from a designated test host to a controlled destination, covering the sub-techniques agreed in scope. The traffic should use only lab-owned endpoints and contain no payloads or real command content. The step is complete when the emulation plan maps each behavior to the sub-technique it represents and records the expected network path, so the SOC can judge whether an alert is correct.
Confirm telemetry reaches the platform
The engineering team checks that network connection, network traffic flow and network traffic content records from the test host and sensor reach Wazuh or Security Onion before the emulation starts. They confirm that timestamps are synchronized and that the host identifiers in the logs match the asset inventory. The step is done when a baseline query returns the test host's sessions for the exercise window, with no gaps in the sensor or agent feeds.
Run the emulation and watch the alert queue
The operator runs the agreed emulation while the SOC monitors the alert queue in Wazuh or Security Onion. The observer notes when the emulation starts and stops, so alerts can be matched to actions. The step is complete when the emulation has finished and the observer has logged every action that should have produced an alert, along with any action that did not.
Check alert fidelity against expected behavior
The detection engineer compares each alert with the emulation log to decide whether it is a true positive, a false positive or a miss. For each alert, the engineer checks that the logic matched the intended sub-technique and not unrelated web traffic from the same host. The step is done when every alert is classified, and any false positives have a documented tuning proposal that the SOC lead reviews.
Record timestamps, host, destination and rule ID
The analyst records, for each confirmed alert, the event timestamp, the source host, the destination, the rule ID or detection strategy reference, and the ATT&CK version the rule targets. These fields are stored with the exercise report so results can be compared across runs. The step is complete when the record can be reproduced from the platform's stored data without relying on memory or screenshots.
Close the exercise and schedule re-tests
The exercise lead reviews the results with the detection owner, confirms the rules of engagement are closed, and removes any temporary suppression or allow-list entries created for the exercise. The team decides which findings require tuning and when the detection will be re-tested after changes. The step is done when the report is filed, every open finding has an owner, and the re-test is recorded on the detection backlog.

Preventive controls that reduce T1102 exposure

These four mitigations form the preventive layer against T1102 Web service, where an adversary uses a legitimate web service to relay command and control traffic. Each one constrains a different point on that path: the inline traffic inspection, the web destinations users may reach, the network paths allowed between segments, and the encrypted content visible on the wire. Each also maps to other Command and Control techniques, so one control change can reduce exposure across several detections.

Network intrusion prevention

Network Intrusion Prevention (M1031) inspects traffic and can block sessions that match signatures or protocol rules before they reach a workstation or server. For T1102, it can stop known beacon patterns and malformed web requests, but it cannot judge a request to a popular cloud service that looks like ordinary browsing. Confirm whether your product runs inline or monitor-only, which rule sets cover web protocols, and whether blocking is tuned so that business traffic is not disrupted.

Restrict web-based content

Restrict Web-Based Content (M1021) limits which websites, categories and web services hosts can reach, usually through a secure web gateway or proxy policy. It shrinks the set of destinations an adversary can use as a relay, especially sites and services that no business process requires. It cannot see inside sanctioned services, so an approved file sharing or collaboration platform remains a possible channel. Ask whether the product supports allow-listed services, category blocking, per-group exceptions and logging of both blocked and allowed requests for your monitoring pipeline.

Filter network traffic

Filter Network Traffic (M1037) covers the rules on perimeter firewalls, host firewalls and cloud security groups that decide which destinations and ports a system may open connections to. For T1102, it removes outbound web access from servers and segments with no business reason to reach public web services, such as database tiers and management networks. It does not inspect content, so it cannot separate a benign request from a beacon sent to an allowed endpoint. Check for default-deny egress, named rule owners for each segment and logging of rule changes.

SSL/TLS inspection

SSL/TLS Inspection (M1020) decrypts outbound HTTPS at a controlled point so that request paths, headers and content can be evaluated by inspection and logging tools. This is the control that makes Network Traffic Content visible for web-hosted channels, which otherwise look like ordinary encrypted sessions. It adds certificate trust management, privacy review and legal considerations, and it does not help with applications that use certificate pinning or traffic that bypasses the inspection point. Confirm the certificate deployment process, the exemption list for regulated categories and the CA rotation procedure before enabling it.

Triage and response when a T1102 alert fires

The first decision on a T1102 Web service alert is whether the traffic is a sanctioned integration or an adversary using a legitimate website or web API as a command channel. Start by confirming the process that opened the connection, its parent process, the account it ran under and the host's role. Check whether the destination belongs to a service the organization has approved for that host or user group, and compare the outbound pattern against what the process normally does. Ask the application owner or the endpoint owner to confirm the business purpose within a window you set in advance, because an unanswered question is not an approval. Record each answer in the case notes so the decision can be audited later.

Pull the destination history before deciding on containment. Review every host that has contacted the same domain or API endpoint over the retention period your Wazuh or Security Onion deployment holds, and look for the same process name, user or request interval on other systems. A single host with an unusual process is a different case from a fleet-wide pattern. If the process is not approved, or if the account, parent process or timing is suspicious, isolate the host from the network through your endpoint or network control while keeping it powered on, so volatile memory and running processes remain available. Preserve evidence before anything is rebooted or cleaned, using Velociraptor or a comparable collection tool to capture process listings, network connections, DNS cache, relevant logs and the binary involved, with hashes recorded and chain of custody maintained. Blocking the destination at the proxy or firewall is a separate decision. Block it when the service has no approved business use, and confirm with the owner first when a shared SaaS platform could break legitimate workflows.

Escalate to the incident response lead and, where regulated data may be involved, to privacy and legal counsel when the process is unapproved, when other hosts show the same behavior, or when the traffic carries data that leaves the environment. Close the loop by recording whether the alert was a true positive, a benign business use or an approved but undocumented tool. For benign results, tune the detection by adding the specific process, destination and time pattern to an allowlist with an owner and review date, rather than suppressing the rule broadly. For true positives, update the Sigma rule or Wazuh rule so it names the ATT&CK version you target, and rehearse the updated logic in your private cyber range with DeployOpen before relying on it in production. Confirm the retention and evidence-handling requirements with your legal and compliance teams, since they set how long triage records must be kept.

Rehearsing T1102 detection in a private cyber range

A private cyber range for T1102 needs hosts that represent the operating systems in scope, a monitored egress path that resembles production, and sensors that see both host and network activity. The range should include ESXi, Linux, macOS and Windows endpoints, with a controlled outbound route through a proxy or firewall where Zeek and Suricata observe traffic. Wazuh agents on the endpoints supply host telemetry, and the team should confirm that each sensor receives the data components the detection strategies expect.

Host coverage: Include at least one representative system for each platform in scope, so detections are tested where they will run.
Monitored egress: Route outbound web traffic through a single inspected path so Zeek and Suricata see the same flows the production design would produce.
Sensor placement: Confirm Zeek logs and Suricata alerts are forwarded to the Wazuh manager or SIEM with consistent timestamps.
Isolation: Keep the range disconnected from production networks and from the public internet except through the controlled egress path.
Version pinning: Record the Wazuh, Zeek and Suricata versions, and the ATT&CK version the detections target.

Before the first exercise, confirm with your platform team that every sensor reports the expected telemetry from each host type.

Questions SOC leads ask about T1102 Web service

How do we separate sanctioned SaaS use from T1102 abuse?

Start from an inventory of approved web services, then treat anything outside it as a question to answer, not an automatic alert. Sanctioned SaaS still needs visibility, because T1102 Web Service describes adversaries using legitimate platforms such as cloud storage, code repositories or social media as a relay for command and control. Build allow lists by business owner, destination and expected behavior, such as which hosts should reach a given API and at what volume. Then look for the signals that separate normal use from abuse: a service contacted by a process that has no business reason to use it, unusual beaconing intervals, or access to a platform from a server that normally never browses the web. Confirm each list with the business owners and record the decision, so the exceptions remain auditable.

Can we inspect TLS traffic to web services without full decryption?

Yes, you can get useful signal without decrypting everything, although some detections will be weaker. Network metadata from Zeek or Suricata, such as server names, certificate fields, connection timing and byte counts, often reveals repeated polling of one service from one host. Pair this with endpoint telemetry that shows which process opened the connection, which is usually stronger evidence than the payload. Full SSL/TLS Inspection is a separate mitigation (M1020) with its own privacy, legal and operational costs, so decide it as a policy choice with your legal and privacy teams. Where you do inspect, scope it to specific destinations and document the purpose. Confirm with your platform team exactly which fields your sensor exports before writing rules that depend on them.

How should we tune baselines for web service traffic?

Tune baselines per host group and per process, not across the whole estate. A developer workstation, a build server and a domain controller will reach web services in very different patterns, so one global threshold produces either noise or blind spots. Begin with a learning window long enough to capture normal business cycles, such as month-end or release days, and record the destinations, frequencies and processes seen during that window. Review new destinations weekly during the first phase, then move to exception-based review. Keep a change log for every tuning decision so an analyst can see why an alert was suppressed. The length of the learning window depends on your environment, so confirm it with your own operations team rather than adopting a generic figure.

Do ATT&CK version changes affect our T1102 detection rules?

They can, so every rule should name the ATT&CK version it targets. MITRE releases ATT&CK updates on a regular schedule, and releases can rename, deprecate or revoke techniques and sub-techniques. The recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Since v18, detection content in technique pages has moved to detection strategies and analytics, and data components have been revised, so check whether your rule mappings still point at current identifiers. Store the mapping in version control, compare it against the STIX bundle for your target version each release, and review the release notes for changes to T1102 and its sub-techniques before you upgrade your detection content.

How do we measure detection coverage for T1102?

Measure coverage by mapping what you can actually observe to each sub-technique, then testing whether the detection fires. Coverage on paper is not enough. Start by listing the data sources in use, such as network connection creation, network traffic flow and network traffic content, and note which hosts and platforms each source covers, including ESXi, Linux, macOS and Windows. For each sub-technique, record the detection logic, the required data component and the test that proves it works. Track the results in a matrix that names the ATT&CK version and the date of the last validation. Gaps should become tickets with owners. Rehearse the tests in a private cyber range so the results do not depend on production activity.

Can our own team build and rehearse these detections, or do we need a partner?

Your team can build and maintain these detections if it has the staff, skills and time, and many organizations do. The work breaks into four parts: data collection on your sensors and endpoints, detection logic in your SIEM or Wazuh deployment, validation in a controlled environment, and ongoing tuning as ATT&CK changes. Each part needs an owner. A fixed-scope engagement from DeployOpen can cover one part, such as implementing the open-source platform, building the detection content or running rehearsal exercises in a private cyber range, with scope, deliverables and timelines agreed in writing before work starts. Ask any provider to show how detections are validated and how they will be handed over to your team.

Where to read the authoritative T1102 definitions

Before you commit detection logic or a control mapping to T1102 Web Service, read the definition from MITRE rather than relying on a summary, including this page. Start with the MITRE ATT&CK tactic page for Command and Control, which defines the tactic that T1102 belongs to (TA0011) and frames the adversary goal as communicating with compromised systems to control them. Use it to confirm that T1102 is listed under this tactic in the version you target, and to check which related techniques share the same tactic so your coverage review does not miss neighbours that abuse the same channel.

Next, check the MITRE ATT&CK updates page for the release history. ATT&CK releases can rename, deprecate or revoke techniques and sub-techniques, and the three sub-techniques of T1102 are the most likely place for a change to surface. Record the ATT&CK version your detection rules, data source inventory and mitigation mapping were written against, and compare that version to the latest release before each audit cycle or rule review. A mapping that names its version is far easier to defend to an assessor than one that simply says "ATT&CK."

For the machine-readable definition, use the enterprise-attack 20.0 STIX bundle in the mitre-attack/attack-stix-data repository. Each domain and version is published as its own STIX 2.1 bundle, so you can script queries for T1102, its sub-techniques, the data components it references and the mitigations mapped to it, and diff the results between releases. Ask your detection engineering team to confirm that the bundle they parse matches the version named in their rule metadata, and treat any difference in data component or mitigation IDs as a change to review before you update dashboards.

How DeployOpen builds T1102 detections and range exercises

DeployOpen works on T1102 Web service as a fixed-scope engagement inside the client's own environment, with the scope agreed in writing before work starts. The output is a detection set, a validated test plan and a range exercise the client's team can repeat.

How we scope

Confirm which ESXi, Linux, macOS and Windows hosts send network and process telemetry into the existing logging pipeline
Record which web services the organization allows, so legitimate use of cloud storage and collaboration sites is not flagged
Agree the ATT&CK version the detections will target, such as v20.0, and the three T1102 sub-techniques in scope

How we build

Write detection logic in Sigma and map it to the Network Connection Creation, Network Traffic Flow and Network Traffic Content data components
Deploy rules to Wazuh or Security Onion, tuned to the client's proxy, DNS and egress logs without inventing baselines
Document the Network Intrusion Prevention and Restrict Web-Based Content controls that gate the web services in scope

How we hand over

Deliver a written detection record per sub-technique, with data sources, logic, known false positives and the ATT&CK version
Run a private cyber range exercise that replays benign and simulated web service traffic so the team can verify each alert
Provide response runbooks that name the triage steps, evidence to preserve and the owner for blocking decisions

How we support

Offer ongoing support as a retainer to review rule drift when ATT&CK releases rename, deprecate or revoke technique content
Schedule repeat range exercises after major changes to proxy policy, endpoint tooling or permitted cloud services
Confirm with the client's auditors which control evidence they need, since DeployOpen prepares evidence but does not issue assessments

T1102 Web service