Detecting T1573 Encrypted channel

How T1573 Encrypted channel hides command and control in normal TLS traffic

Encrypted traffic is now the default, so command and control hidden inside it is hard to see. T1573 Encrypted Channel describes adversaries who protect their communications with compromised systems using encryption, so commands and results travel inside a session that looks like ordinary TLS. This sits under the Command and Control tactic (TA0011), which MITRE defines as: "The adversary is trying to communicate with compromised systems to control them." (MITRE ATT&CK tactic TA0011). Encryption gives the adversary confidentiality, so a sensor that only reads headers cannot see what is being sent, and the session blends into the large volume of legitimate HTTPS that the business already generates.

The adversary gains mainly concealment. Message content is unreadable to network sensors without a decryption point, and the session can imitate browsers, updaters or SaaS clients that already leave the network. T1573 has two sub-techniques, T1573.001 for symmetric cryptography and T1573.002 for asymmetric cryptography, which differ in how the keys protecting the session are established. For the SOC lead, the practical consequence is that a clean-looking TLS flow proves very little on its own. Detection has to rest on context: which process owns the connection, which destination it reaches, how the certificate and timing behave, and whether the host normally talks to that destination at all.

This page targets MITRE ATT&CK Enterprise v20.0, so detection mappings, data component references and sub-technique names should be checked against that version before they go into production, because ATT&CK releases can rename, deprecate or revoke techniques. Confirm in your own environment which servers, workstations, containers and network devices are permitted to open TLS sessions to unmanaged or newly registered destinations. Also confirm which decryption points, proxy logs, certificate records and flow metadata you already collect. Those two answers decide which of the detections described later on this page are feasible for your estate.

Telemetry that reveals encrypted channels and the tools that collect it

This table maps each data component ATT&CK references for T1573 to the signal it can give a defender, the open-source collector that produces it, and what encryption hides. Read it as a coverage checklist: no single source sees the whole channel, so confirm each row against your own sensor placement before relying on it.

Data component	Signal it can provide	Open-source collector	Limits of encrypted visibility
Network Connection Creation (DC0082)	Source and destination, ports, and the host that opened each connection, which helps match outbound sessions to a process	Wazuh agent, Velociraptor, Zeek conn logs	Shows that a session exists, not what it carries; hosts on unmonitored segments may be missing
Network Traffic Flow (DC0078)	Byte counts, packet counts, session duration and timing regularity that can suggest beacon-like behavior	Zeek conn and connection history logs, Suricata flow records	Timing and volume remain visible under encryption, but jitter, padding or long sleeps can make periodic patterns hard to separate from normal traffic
Network Traffic Content (DC0085)	TLS handshake metadata such as JA3 or JA4-style client fingerprints, server name indication, certificate subject, issuer and validity period	Zeek ssl and x509 logs, Suricata TLS logging and rules	Payload is unreadable without SSL/TLS Inspection; handshake fields can be copied or rotated, and TLS 1.3 reduces what certificates expose in plaintext
Process Creation (DC0032)	Process ancestry, command-line context and the binary that owns an outbound connection, which can show an unexpected program speaking TLS	Wazuh agent (Sysmon events on Windows, auditd on Linux), Velociraptor artifacts	Shows who started the process, not the content it sends; coverage depends on agent deployment and on whether auditing is enabled
Certificate and domain metadata	Newly observed domains, self-signed or short-lived certificates, and certificates reused across unrelated hosts	Zeek x509 and ssl logs, Suricata alerts with TLS keywords	Certificate fields are only as current as your threat intelligence; confirm how your feeds are updated before treating a match as conclusive
Network devices and appliances	Encrypted sessions crossing segment boundaries, including traffic from ESXi management paths and network equipment	Zeek or Suricata on mirrored or tapped links, device flow exports	Traffic inside the same hypervisor or switch may never reach a sensor; confirm mirror coverage with your network team
Decryption point (where SSL/TLS Inspection is deployed)	Full request and response metadata for inspected sessions, enabling content-based rules	Zeek or Suricata behind an approved inspection proxy	Only applies where legal, privacy and certificate-trust requirements allow inspection; pinned applications may fail and must be documented

Detection ideas for encrypted C2 that a SOC can tune

Encrypted channels hide payloads, so detection shifts to the metadata around the session: who opened it, how the handshake looks, how often it repeats and where it goes. Each pattern below starts from a baseline of normal traffic, then tunes a threshold against known benign software before alerts reach analysts.

Unusual TLS fingerprints from non-browser processes

Compare the TLS client fingerprint (such as JA3 or JA4 hashes produced by Zeek or Suricata) against the processes that normally generate it. A fingerprint that matches no browser, but appears under a process that should never make outbound HTTPS calls, is a strong signal. Build the baseline per host group for two to four weeks, then alert on fingerprints seen on fewer than a set number of hosts. Expect false positives from software updaters, package managers, VPN clients and monitoring agents, which use custom TLS stacks. Maintain an allowlist keyed on process path, signing certificate and destination, not on hash alone.

Self-signed or newly issued certificates

Flag TLS sessions where the server certificate is self-signed, issued by an unknown internal or public CA, or issued within a short window before first contact with the destination. Threshold: certificate age under a value your team sets after reviewing a baseline of normal issuance. Check the destination against your own asset inventory and DNS history before escalating. Legitimate sources include internal services, vendor appliances, lab systems and some SaaS integrations, so keep an allowlist of expected issuers. Pair this rule with a count of distinct destinations per host to reduce noise from one-off vendor connections.

Periodic connection intervals

Beaconing shows up as connections repeating at near-regular intervals with small variation in packet sizes. Use Zeek connection logs or Suricata flow records to compute the interval spread per source, destination and port, and alert when the jitter falls under a tuned percentage across a minimum number of sessions. Set the minimum observation window and session count from your baseline, not from a vendor default. Expect false positives from health checks, NTP-like polling, endpoint agents, update checkers and monitoring probes. Document each recurring job so analysts can clear it quickly.

Long-lived sessions to low-reputation hosts

Measure session duration and bytes transferred for encrypted flows to destinations with low reputation, newly observed domains or no prior history in your environment. Alert when a session stays open beyond a duration threshold while transferring small, steady volumes in both directions. Reputation feeds vary in coverage and freshness, so confirm what your provider covers before relying on them. Legitimate false positives include remote support tools, VPN tunnels, database replication and cloud sync clients, so group these by application and review them with the owning team.

Certificate-to-host name mismatches

Compare the Server Name Indication sent by the client and the subject alternative names in the server certificate. A mismatch, or a certificate whose names do not match the resolved domain, suggests a session that is trying to look like a trusted service. Tune by excluding known CDNs, load balancers and reverse proxies, which legitimately present shared certificates. Log both fields with Zeek's SSL logs or Suricata TLS events so the rule can be written in a Sigma-style format and replayed against historical data. Validate the rule against your baseline before enabling alerting.

Why detection shifts from payload inspection to behavior and metadata

When a channel is encrypted, the payload stops being a reliable detection surface, so detection for T1573 Encrypted channel has to rest on what remains visible: who connected to whom, when, for how long, how much data moved in each direction, which process owned the socket, and what the session's certificate looked like. Network Connection Creation (DC0082), Network Traffic Flow (DC0078) and Process Creation (DC0032) carry most of that signal. Build your analytics around baselines for each host role, such as flagging a server that has never opened outbound TLS sessions to a new external destination, and confirm that your sensors can attribute connections to processes on the hosts where that matters.

Certificate attributes and session timing are the next layer. Review which certificate authorities issue certificates your fleet trusts, how long-lived or self-signed certificates are handled, and whether a destination's certificate changes unexpectedly. Ask your Zeek or Suricata team whether TLS metadata such as server name, certificate subject and issuer, and JA3 or JA4 style client fingerprints are logged and retained, and for how long. Confirm this in your own environment, since log schemas and retention depend on your sensor versions and storage budget.

SSL/TLS Inspection (M1020) restores payload visibility, but only where legal, privacy and technical conditions allow it. Decryption requires a managed trust chain on endpoints, exclusions for regulated traffic such as banking, health or employee personal services, and clear governance over who can read decrypted content. Inspection also changes what the sensor sees: pinned applications may fail, some protocols will not decrypt, and the inspected session looks different from the original. Treat inspection as one input to your detection design rather than a replacement for metadata analytics, and document which traffic classes are excluded so that a gap is a known decision and not a surprise during an investigation.

How to validate that the T1573 detections fire

This sequence proves, in a private cyber range, that each T1573 detection fires on the intended encrypted-channel behavior, produces the expected telemetry at every collector, and is recorded against the ATT&CK v20.0 mapping before it is accepted. Results are kept as evidence for detection engineering and for compliance readiness reviews.

Define the encrypted channel behavior to emulate
The detection engineering lead writes a short emulation plan that names the encrypted channel behavior to simulate for each in-scope sub-technique, the ESXi, Linux, macOS and network device hosts involved, and the success criteria. The plan states which behavior is benign baseline traffic and which is the adversary-like pattern, so later false positive notes have a reference. The plan is approved by the security operations lead before any traffic is generated. Done means the plan is versioned and names the ATT&CK v20.0 technique and sub-techniques it targets.
Confirm the sub-technique scope and ATT&CK mapping
Before the range is built, the team confirms the two T1573 sub-techniques and their current titles in the Enterprise ATT&CK 20.0 data, using the MITRE ATT&CK STIX bundle for that version rather than a copied list. They also check the data components referenced by the detection strategies, such as Network Connection Creation, Process Creation and Network Traffic Flow, and note any deprecated or renamed objects. Done means each detection rule in scope carries a written reference to the v20.0 technique and sub-technique IDs.
Document expected telemetry at each collector
For every host and sensor in the range, the engineer records what should appear: connection records for the endpoints, process creation events for the host that initiates the channel, and flow metadata from the network sensor. The table states the collector, the log source, the field that should match and the timestamp source. Clock sync across collectors is checked so events can be correlated. Done means a reviewer can look at the table and predict which alert should fire on which collector.
Run the emulation and capture raw telemetry
The red or purple team operator runs the approved emulation inside the isolated range, and the blue team observes without tuning in real time. Raw events are preserved from the SIEM, the endpoint agent, and the network sensor, with exact timestamps and the identifiers of the test session. Done means each planned behavior has a matching raw record on every expected collector, or a written note explaining the gap.
Record alerts, rule IDs and false positives
The detection analyst logs, for each run, the rule identifier, the alert count, the time from behavior to alert, and the affected host. Benign baseline activity that triggers an alert is recorded as a false positive with its cause, such as a legitimate VPN or management tunnel. Missed behaviors are recorded as detection gaps. Done means the results sheet covers every planned behavior, including negative controls, and each row has a timestamp and a rule ID.
Tune the rule and re-run the emulation
The engineer adjusts thresholds, allowlists or correlation logic where the false positive or gap notes justify it, and each change is versioned with a reason. The same emulation plan is then re-run against the tuned rules, with the same session structure, so before and after results are comparable. Done means the re-run shows the intended detections firing, the false positives reduced or explained, and the change log linked to the results sheet.
Confirm ATT&CK v20.0 mapping and accept
Before acceptance, a second reviewer checks that every rule still points to the correct v20.0 technique and sub-technique IDs, and that no mapping has been deprecated or revoked by a later ATT&CK release. The reviewer signs off on the results, the tuning log and the open gaps. Any open gap is either accepted with an owner or scheduled for the next cycle. Done means the detection is accepted with a dated record, and the team knows which ATT&CK version the acceptance applies to.

Preventive controls that reduce encrypted C2 exposure

ATT&CK maps several preventive mitigations to Command and Control techniques, and four of them matter most for T1573 Encrypted channel. Intrusion prevention and TLS inspection act on the traffic itself, while traffic filtering and segmentation limit where an encrypted session can go. Each control depends on conditions in your environment, so confirm those conditions before counting on the control.

Network intrusion prevention (M1031)

Network Intrusion Prevention (M1031) is the mitigation ATT&CK maps most directly to encrypted C2 traffic. Signature and behavioral rules can still match on metadata that encryption does not hide, such as destination reputation, connection timing, certificate attributes and unusual JA3-style client fingerprints where your sensor exposes them. Check whether your sensor sees TLS handshakes at all, whether it can block (not only alert) on those rules, and how the vendor updates rule sets. Ask the vendor which TLS metadata fields the product logs and retains, because those fields define what you can detect without decrypting anything.

SSL/TLS inspection (M1020)

SSL/TLS Inspection (M1020) lets a proxy or inline sensor decrypt, inspect and re-encrypt sessions, which exposes payload content that is otherwise invisible. It introduces real operational risk: certificate trust chains must be deployed to managed endpoints, pinned applications will break, and decrypted data becomes sensitive material that needs its own access controls and retention rules. Confirm your legal and privacy position on decryption, document the exclusions for banking, health and personal traffic, and test how the inspection point behaves under load and failover before you rely on it for blocking decisions.

Filter network traffic (M1037)

Filter Network Traffic (M1037) restricts which destinations, ports and protocols hosts can reach, so an encrypted channel to an unapproved endpoint fails at the network layer. For T1573 this is often the most effective control, because it does not depend on reading the payload. Build allowlists from observed business traffic rather than from assumptions, and review egress rules for outbound TLS on ports that are not used by any approved application. Confirm which firewalls or proxies enforce the policy, whether egress rules cover DNS and cloud workloads, and who owns exception requests.

Network segmentation (M1030)

Network Segmentation (M1030) limits how far a compromised host can reach and where it can establish an outbound session. Segments that hold servers, ESXi management interfaces and industrial or clinical systems should have no general internet egress, so an encrypted channel from those zones has to pass through a controlled gateway. Confirm that the segmentation is enforced in the network, not only documented, and that management networks and backup networks are included. Test the boundary by attempting a controlled outbound connection from a lab segment during rehearsal.

What to do in the first hours after an encrypted channel alert

Treat the first hours after an encrypted channel alert as a triage exercise, not a containment exercise. Before anyone isolates a host, the response owner should confirm three things: which host is involved, which process initiated the encrypted session, and where the session was going. Pull the destination, port, and TLS handshake details from the network telemetry and compare them with the process that owns the socket on the endpoint. Then check the certificate subject, issuer, validity dates and fingerprint against what the organization expects for that destination. A self-signed certificate, a recently issued certificate on a newly registered domain, or a certificate whose fingerprint has been seen across unrelated hosts all warrant closer review. Confirm these details with your own threat intelligence sources and SSL/TLS inspection logs, because the fields available depend on whether inspection is in place for that path.

Correlate the alert before you act on it. A single encrypted session to an unfamiliar address is not proof of compromise, since software updaters, cloud SDKs, and monitoring agents all produce TLS traffic that looks unusual out of context. Look for companion signals on the same host within the same window: beaconing intervals in Zeek connection logs, DNS lookups for the same destination, rare parent-child process relationships, new scheduled tasks or services, and other alerts tagged with related Command and Control techniques such as T1071 Application layer protocol or T1568 Dynamic resolution. If the host is in a segment with business-critical services, document the business impact of isolation before the decision is made, not during it. The incident plan should already name who decides on isolation, who executes it, and who can authorize blocking a destination across the estate. Name those roles in advance, record them in the runbook, and rehearse them in the cyber range. Preserve volatile memory and the relevant network captures before isolation or reimaging, and record the hash of each artifact. Decide on blocking last, once the destination is confirmed, and log the block with a review date so that a false positive does not become a permanent gap.

Rehearsing T1573 detection in a private cyber range

Build the range as a small set of Linux server images on an isolated segment, with a monitored egress path through a sensor that performs TLS inspection where policy allows it, and a Wazuh or Security Onion collector gathering host and network telemetry. Keep a separate benign administration network so that routine encrypted traffic from management tools is present in the baseline. The Linux tab focuses on Network Connection Creation paired with Process Creation, so analysts can tie an outbound encrypted session to the process that opened it.

Benign injects: scheduled backup jobs, package updates and administrator SSH sessions to a jump host, so analysts learn what normal encrypted traffic looks like on the segment.
Emulated injects: a described process that opens a long-lived outbound encrypted session to a non-standard destination on a schedule, with traffic in the TLS handshake that does not match the expected application profile.
SOC detection: an alert that correlates the session with the owning process, its parent, the destination reputation and the certificate attributes, and that fires on the combination rather than on encryption alone.
SOC response: analysts pivot to the host, capture the process metadata with Velociraptor, confirm whether the process is authorized, and document the scope before isolating the host.
Validation: record which alerts fired, how long triage took, and whether the Sigma rule mapped to the target ATT&CK version still matched after tuning.

Check whether your sensors can see process ownership for encrypted sessions, since this tab depends on it.

Questions from SOC leads and detection engineers about T1573

How do we separate command and control traffic from legitimate TLS traffic?

No single field reliably separates them, so combine several weak signals and score them together. Useful inputs include destination reputation and age, how new the certificate is, whether the server name matches the destination, beacon-like regularity in connection timing and packet sizes from Network Traffic Flow, and whether the process that opened the connection should normally be talking to the internet at all. Start with hosts that have no business reaching external TLS endpoints, then widen the rule set. Test each rule against a baseline of normal traffic from your own environment before you alert on it, because legitimate update clients and monitoring agents produce the same patterns.

What should we do when TLS inspection is not possible?

Shift detection to the metadata you can still see. Without decryption, you can rely on the Network Connection Creation and Network Traffic Flow data components, along with TLS handshake fields such as the server name, certificate issuer, validity period and JA3 or JA4-style fingerprints, which Zeek and Suricata can log. Pair these with endpoint telemetry from Process Creation so you know which binary opened each session. Inspection is often blocked for banking applications, pinned mobile apps and privacy-sensitive services, so document those exceptions in writing and make sure the compensating controls cover them. Confirm with your platform team which fields your sensors actually log before you write rules that depend on them.

How should we handle certificate pinning in detection?

Pinned clients will fail inspection by design, so do not treat failed decryption as a sensor fault. Instead, log the handshake failure and the destination, and treat unexpected pinned-client behavior as a signal in its own right. A pinned application that suddenly talks to a new host, or a binary that uses pinning but is not on your approved list, deserves review. Keep an inventory of which applications pin certificates, since that list drives your exception register and tells analysts where metadata-only detection applies. Ask your application owners to confirm pinning behavior in writing, because vendors do not always disclose it.

How do we tune detections for ESXi hosts and network devices?

Treat these platforms as separate baselines. ESXi hosts and network devices have few legitimate reasons to open outbound encrypted sessions, so even small deviations matter, but their management traffic, backup agents and vendor update channels can look suspicious if you tune against a generic workstation profile. Build allowlists from observed Network Connection Creation records over a period that includes patching and backup windows. Confirm vendor update endpoints with the vendor, and label every allowlist entry with an owner and a review date. Where your sensors cannot see these hosts, record that gap as a coverage limit rather than assuming silence means safety.

How do we version T1573 detections against ATT&CK v20.0?

Record the ATT&CK version in every rule's metadata and map each detection to the technique or sub-technique IDs as they appear in the version you target. The Enterprise ATT&CK 20.0 STIX bundle, published in the attack-stix-data repository, is the reference for current IDs, and the MITRE updates pages list renames, deprecations and revocations between releases. Since ATT&CK v18 replaced detections on technique pages with detection strategies and analytics, map your rules to the detection strategy identifiers where possible. Schedule a review after each ATT&CK release, and keep a changelog so auditors can see which mappings changed and why.

How do we measure coverage for encrypted channel detection?

Measure coverage by sub-technique and platform, not as a single percentage. For each of the two T1573 sub-techniques, list the platforms in scope, the data components each detection depends on, and the sensors that supply them. Then rehearse a set of emulated encrypted channel behaviors in your private cyber range and record which detections fired, how long they took, and which ones failed silently. Gaps usually appear where TLS inspection is absent, where a sensor drops traffic under load, or where a rule was never tested against the platform it targets. Report coverage as a list of tested and untested combinations, with the date of each test and the ATT&CK version used.

How DeployOpen builds T1573 detections and range exercises

DeployOpen treats T1573 Encrypted channel as a detection engineering and validation problem inside your own environment. Work is agreed as a fixed-scope engagement, then delivered on your open-source stack with documented detections, test evidence and a cyber range exercise your team can repeat.

How we scope

Confirm which ATT&CK version the detection mappings for T1573 will target before work starts.
Agree which platforms are in scope for the two sub-techniques, including ESXi, Linux, macOS and network devices.
Record which telemetry sources exist today for network connections, process creation and network traffic flow.

How we build

Write detection logic for T1573 in Sigma and deploy it to your Wazuh or Security Onion pipeline.
Map Suricata and Zeek network sensor coverage to the Network Intrusion Prevention and SSL/TLS Inspection mitigations.
Tune rules against your normal encrypted traffic baseline to reduce noise from legitimate TLS sessions.

How we hand over

Deliver each detection with its logic in plain words, data source requirements and known blind spots.
Provide a validation record showing which test scenarios fired, which did not and why.
Run a cyber range rehearsal with your analysts and document the response steps they followed.

How we support

Offer ongoing support as a retainer to review detections when ATT&CK releases change technique mappings.
Schedule re-validation after platform upgrades, sensor changes or new encrypted service rollouts.
Confirm retainer terms, response expectations and review cadence in the written scope before any work begins.

T1573 Encrypted channel