BrickStorm blends into normal encrypted traffic by using DNS-over-HTTPS, nested TLS and WebSockets. That means defenders cannot rely on payload inspection alone and must control allowed resolvers, inspect egress behaviour and correlate traffic with management-plane activity.
How encrypted transport hides BrickStorm’s signal
BrickStorm is harder to spot because its traffic looks like ordinary encrypted application traffic rather than a unique malware conversation. DNS-over-HTTPS, nested TLS and WebSockets all reduce the value of payload inspection, so defenders have to look at where the traffic goes, how it behaves, and whether it matches expected management or automation activity.
The important point is not that encryption is suspicious on its own. The problem is that these protocols create a normal-looking wrapper around the same operational functions attackers want: name resolution, command delivery and remote interaction. That pushes detection away from content inspection and toward traffic metadata, destination reputation, timing, session patterns and the systems that should or should not be talking to each other.
Why DNS-over-HTTPS, nested TLS and WebSockets matter operationally
DNS-over-HTTPS blends DNS lookups into HTTPS, which makes name-resolution activity much less visible to network controls that expect standard DNS. Nested TLS adds another encrypted layer, so even when one encrypted session is observed, the inner traffic remains obscured. WebSockets then keep a persistent, bidirectional channel open, which can resemble legitimate real-time services and make short bursts of command traffic look routine.
Those choices do not just obscure content, they also reduce the usefulness of simple allow-and-block rules. If a defender treats all encrypted traffic the same, the malicious flow can inherit the credibility of common enterprise protocols. If the defender is too aggressive, they risk breaking legitimate services that now depend on the same transport patterns.
What defenders must correlate instead of inspecting payloads
Once payload inspection is weakened, detection needs to move to the surrounding context. That means validating which resolvers are allowed, watching for unusual egress destinations, checking whether WebSocket use is expected for that host, and correlating the traffic with management-plane events, admin activity or automation jobs. The key question is whether the pattern fits the role of the asset, not whether the packet contents are readable.
That is why defenders usually need more than one control layer. Network telemetry can show the shape of the connection, identity and access logs can show whether a management action should have happened, and endpoint or cloud telemetry can show whether the initiating process was supposed to make that connection at all. A single control rarely gives enough confidence when the content is encrypted end to end.
Risk and Threat Considerations
Encrypted covert traffic creates a visibility gap that threat actors can exploit to move commands, maintain persistence and mask beaconing inside normal enterprise transport. The risk is highest when organisations depend on payload-based detection or allow broad egress to common encrypted services without strong behavioural baselines.
Failure mechanism: The attacker routes malicious activity through legitimate encrypted protocols, so the defender loses the content cues that would normally expose command-and-control or suspicious automation.
Impact: Detection becomes slower and less certain, malicious traffic can blend into routine service use, and responders may only notice the activity after lateral movement, credential abuse or exfiltration has already progressed.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1071 — Application Layer Protocol | BrickStorm uses DNS-over-HTTPS, TLS and WebSockets to blend command traffic into application protocols. |
| Recommendation — Map the observed protocol use to T1071 and hunt for suspicious application-layer command-and-control patterns. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | The question is about detecting covert network traffic through monitoring and behavioural correlation. |
| PR.AA-05 — Access permissions, entitlements and authorizations are managed, enforced, and reviewed | Management-plane correlation depends on tight control over which identities and systems may initiate admin activity. | |
| Recommendation — Monitor network flows and resolver behaviour for encrypted traffic that deviates from expected baselines. Review and restrict management-plane access so only expected identities can generate privileged traffic patterns. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Covert encrypted egress is a boundary-control problem because traffic leaves through allowed but suspicious channels. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Correlation with management-plane activity requires log review across network and identity telemetry. | |
| Recommendation — Enforce boundary controls that restrict and inspect outbound encrypted traffic paths. Correlate audit logs with network telemetry to spot encrypted traffic that aligns with privileged actions. | ||
Practitioner Guidance
What to prioritise: Start with egress control and resolver policy. If a host does not need arbitrary outbound DNS or broad WebSocket access, do not give it that freedom by default.
What to verify: Confirm whether the traffic is coming from a system that should legitimately use encrypted browser-like channels, or from an admin tool, service or process that should be using a more constrained management path. That distinction often separates expected automation from covert use.
Common mistake: Treating “encrypted” as equivalent to “safe” or “normal.” In practice, encrypted transport only tells you the content is hidden, not that the behaviour is acceptable.
Practitioner takeaway: For covert encrypted traffic, the decisive evidence is usually behavioural and contextual, not content-based, so detection must be built around egress policy, destination trust, and management-plane correlation.
Related resources from NHI Mgmt Group
- Why do masquerading, encrypted C2 traffic, and modular execution make this kind of malware harder to stop?
- Why do legitimate admin tools make identity attacks harder to detect?
- Why do service accounts and other NHIs make advanced threats harder to detect?
- Why do compromised accounts make email fraud harder to detect?