Detect meek by spotting proxy-like traffic that tunnels through web-looking requests to conceal command and control. Look for unusual HTTPS patterns, repeated beaconing, and connections to infrastructure that should not be serving approved applications. Combine network inspection with endpoint telemetry to identify the underlying process making the covert connection.
What meek looks like on the wire
Meek is a traffic-shaping and tunneling pattern, not just a malware family name. It hides command and control inside requests that resemble normal web traffic, so the most useful question is whether the connection pattern makes sense for the host, the application, and the destination. If the traffic is pretending to be ordinary browsing but behaves like a steady covert channel, it deserves investigation.
A practical review starts with what should be visible at the network edge: repeated connections, stable timing, and destinations that are inconsistent with approved services or known business use. The anchor point is not the request path alone, but the combination of unusual HTTPS behavior, infrastructure novelty, and the absence of a legitimate application reason for the communication.
Meek-style tunneling is easier to miss when defenders only inspect payloads or only inspect endpoint alerts. The stronger detection model joins both: network signals show the covert channel, while endpoint telemetry identifies the process, parent process, and user context that initiated it. That pairing is what turns “odd encrypted traffic” into a traceable execution chain.
Why detection is difficult when traffic is disguised as web browsing
Meek is designed to blend into ordinary HTTPS flows, so the main failure mode is false normality. Security tools may see encrypted web traffic and treat it as routine unless they also assess session cadence, destination reputation, certificate patterns, and whether the host normally talks to that infrastructure. A proxy-shaped channel can look legitimate at a glance while still carrying adversary control.
Behavior matters more than the fact that the traffic is encrypted. Repeated beaconing, consistent intervals, and unusually uniform request patterns often matter more than any single packet feature. In practice, the question is whether the traffic is shaped like user activity or like a machine-controlled exchange built to survive inspection.
Detection also gets harder when the covert channel rides through infrastructure that sits behind common hosting services or shared cloud front ends. That can make the visible destination less informative than the surrounding context, which is why analysts should correlate DNS, SNI, certificate data, and endpoint execution. Command and Control (C2) Guide is useful here because it covers beaconing, web service C2, protocol tunneling, JA4 fingerprints, and response options that map directly to this problem.
How teams should investigate suspected meek activity
Start by building a short list of hosts that show repeated outbound sessions with no obvious business justification. Then check whether the same process, user, or service account is generating the traffic across multiple time windows. If the communication recurs at a steady cadence and points to infrastructure that should not be serving approved applications, treat it as a likely covert channel until proven otherwise.
From there, validate the endpoint side. Identify the process tree, command line, loaded modules, scheduled tasks, browser helpers, or injected parent-child relationships associated with the connection. That attribution step matters because traffic-only detection tells you there is a channel, but endpoint correlation tells you what created it and whether the compromise is still active.
For broader detection engineering and incident response mapping, it helps to compare the observed pattern against established adversary tradecraft and hunting workflows. MITRE ATT&CK Enterprise Matrix provides the best-known vocabulary for mapping beaconing, command and control, and follow-on behaviors into a huntable sequence. The operational benefit is that analysts can move from one suspicious connection to a broader hypothesis about persistence, lateral movement, or additional payload delivery.
Risk and Threat Considerations
Meek is risky because it converts ordinary-looking HTTPS into a hidden control path, which weakens perimeter assumptions and can delay detection. The practical threat is not just exposure of one host, but the persistence of a covert channel that can support command issuance, staging, and follow-on access without obvious user-facing symptoms.
Failure mechanism: The defender trusts web-like encryption and regular-looking destinations more than the underlying behavior, so beaconing, proxying, and destination abuse blend into normal traffic unless network and endpoint data are correlated.
Impact: An attacker can retain an undetected management path, continue tasking compromised systems, and use the channel to expand access or prepare exfiltration while appearing like routine outbound web use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1071 — Application Layer Protocol | Meek hides C2 inside web-like traffic, matching application-layer command and control patterns. |
| T1090 — Proxy | Meek commonly uses proxy-like relays to obscure the true controller and destination path. | |
| T1105 — Ingress Tool Transfer | Meek-style C2 often supports staged delivery or remote tasking through the covert channel. | |
| Recommendation — Map the traffic pattern to application-layer C2 and hunt for beaconing, proxying, and related follow-on activity. Look for proxy-mediated egress and correlate relay behavior with the originating host. Investigate whether the channel is also being used to move tools or payloads onto the host. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | Meek detection depends on continuous monitoring of unusual network behavior and destination patterns. |
| DE.AE-02 — Potential anomalies and events are analyzed to identify cybersecurity events | Meek is identified by anomalous timing, destination, and protocol behavior that requires analysis. | |
| Recommendation — Monitor outbound traffic for repeated beaconing and destinations that do not fit approved applications. Analyze anomalous HTTPS behavior together with endpoint telemetry to confirm covert control traffic. | ||
Practitioner Guidance
What to verify: Confirm whether the destination belongs to an approved application path, whether the timing looks automated, and whether the same endpoint process repeatedly generates the connection. A single odd request is weaker evidence than a repeating pattern with no business owner.
Decision rule: If the traffic is both web-like and unexplained, prioritize containment and process attribution before spending time on packet content alone. If you can name the process but not the business purpose, treat that as a detection gap, not an endpoint mystery.
Practitioner takeaway: Meek detection works best when teams stop asking only “is this HTTPS?” and instead ask “which process is making this connection, how often, and why is that destination reachable at all?”