DET0035: Detect Bidirectional Web Service C2 Channels via Process & Network Correlation
This detection strategy matters because adversaries can hide command-and-control activity inside traffic to legitimate external web services. For leaders,...
Analyst context for executives and security teams
This detection strategy matters because adversaries can hide command-and-control activity inside traffic to legitimate external web services. For leaders, the key issue is not simply whether a domain is “known good,” but whether the organization can correlate endpoint processes with network behavior well enough to identify suspicious bidirectional web-service use from compromised systems.
Executive priority
Prioritize this as a control-validation question for command-and-control resilience: do SOC and IR teams have enough endpoint and network evidence to explain which process contacted which external web service, how often, and with what bidirectional pattern? Budget and audit discussions should focus on telemetry completeness, egress visibility, and governance of allowed web services rather than relying only on blocklists or domain reputation.
Technical view
DET0035 is a detection strategy for T1102.002, Bidirectional Communication, under command-and-control. The related technique applies to ESXi, Linux, macOS, and Windows. Detection engineering should validate process-to-network correlation: unusual or unauthorized processes communicating with legitimate web services, repeated polling or bidirectional request/response patterns, and web-service traffic that does not align with expected application behavior. Because the official detection field is not provided, local baselining and environment-specific allowlists are required.
Likely telemetry
- Endpoint process creation and process lineage telemetry
- Endpoint network connection telemetry mapped to process identity
- Proxy, secure web gateway, or firewall logs for outbound web traffic
- DNS query and response logs
- TLS/HTTP metadata where available, such as destination, SNI, user agent, method, status, timing, and byte counts
Detection direction
- Validate that endpoint and network logs can be joined by host, process, user, destination, and time.
- Tune detections around suspicious process-to-web-service pairings rather than domain reputation alone, since the related behavior uses legitimate external web services.
- Baseline approved applications and services that legitimately communicate with common web platforms to reduce false positives.
- Look for bidirectional timing and volume patterns consistent with command retrieval and output return, while accounting for normal collaboration, update, browser, and API traffic.
- Test visibility across the related platforms present in the environment: ESXi, Linux, macOS, and Windows.
Mitigation priorities
- Maintain an inventory of sanctioned external web services and the applications allowed to use them.
- Enforce controlled outbound access through monitored egress points where operationally feasible.
- Collect and retain endpoint process and network telemetry needed for incident reconstruction.
- Use least-privilege and access governance for organizational web-service accounts to limit misuse of legitimate services.
- Create response playbooks for isolating hosts and preserving endpoint plus network evidence when suspicious web-service C2 is suspected.
Analyst notes and limits
The ATT&CK object itself provides no official description, tactics, platforms, or detection text; the practical framing here is derived from the strategy name and its relationship to T1102.002 Bidirectional Communication. Treat this as a validation guide for telemetry and correlation quality, not as a complete analytic rule.
This take does not assert active exploitation, actor attribution, customer exposure, or guaranteed detection. Specific detection logic, thresholds, and allowed web-service lists must be derived from the local environment and available telemetry.
Detect Bidirectional Web Service C2 Channels via Process & Network Correlation
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1102.002 | Bidirectional Communication Sub-technique | This object detects Bidirectional Communication. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 81abeb648b34… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0035Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.