Cleartext HTTP/2 auth traffic exposed cookies at Black Hat Asia

At a glance

What this is: This is a threat-hunting write-up showing how unusual cleartext HTTP/2 traffic to an authentication endpoint revealed cookies and client headers in the open.

Why it matters: It matters because identity-adjacent traffic can fail open in ways that bypass normal encryption assumptions, leaving session material exposed and making detection depend on hunting, not alerts.

Context

Threat hunting depends on comparing expected network behaviour with the small set of events that do not fit. In this case, the anomaly was not a loud intrusion but cleartext HTTP/2 traffic over port 443 to an authentication endpoint, which is the kind of pattern that can hide inside otherwise routine conference network activity.

The governance gap is a failed-open client path. When a client SDK or service path downgrades transport security instead of terminating the session, credentials, cookies, and headers can traverse the network in a form that defenders usually assume is encrypted. That makes the problem both a network-security issue and an identity-security issue, because the exposed material can represent authenticated access rather than simple metadata.

Key questions

Q: What breaks when authentication traffic falls back to cleartext on a trusted port?

A: The security model breaks because operators and tools often assume the port implies encryption, while the application may still transmit cookies, headers, or tokens in readable form. That creates a false sense of safety and can expose session material that is sufficient for account or session abuse. The control failure is usually in downgrade handling, not in the mere presence of traffic.

Q: Why does rare protocol usage matter in threat hunting?

A: Rare protocols often reveal paths that normal baselines ignore, especially when they appear in combinations that should not exist together. A small number of odd events can expose a systemic control gap if the same behaviour repeats across multiple clients or services. Hunting works best when unusual protocol patterns are treated as leads that must be expanded into scope, not as anomalies to dismiss.

Q: How should teams verify that secure transport failures are handled safely?

A: Test the full client-to-service path under failure conditions and confirm that the application terminates rather than downgrades the session. That means checking TLS negotiation failures, fallback logic, proxy behaviour, and SDK error handling. If any path continues and still carries identity material, the control is not actually enforcing secure transport.

Q: What should security teams do when cookies appear in plaintext network traffic?

A: Treat the finding as a possible session exposure event and scope it immediately across logs, clients, and related endpoints. Focus on what identity material was carried, how many clients were affected, and whether the same request path appears elsewhere. If the traffic is tied to authentication, the concern is not just confidentiality but unauthorised reuse of session state.

Technical breakdown

Why cleartext HTTP/2 on port 443 stands out

HTTP/2 normally runs over TLS in browsers and most enterprise clients, so cleartext HTTP/2, also called h2c, is unusual on an internet-facing service. Seeing h2c on port 443 is even stranger because that port strongly implies encrypted transport to most monitoring tools and operators. In the article, the traffic also carried client headers and cookies, which means the transport layer and the application layer were making conflicting claims about protection. That mismatch is exactly why hunters focus on protocol expectations as much as payload content. It often signals an error path, downgrade path, or misimplemented fallback rather than ordinary user behaviour.

Practical implication: Treat cleartext HTTP/2 on 443 as a transport-control anomaly and investigate whether the client or service is failing open.

How failed-open downgrade logic exposes identity material

A failed-open design means a client or service continues the transaction even after security negotiation breaks down. In this case, the article describes an error path in a client SDK that appears to have moved from encrypted behaviour to plaintext HTTP/2 when the secure path did not hold. That matters because authentication flows often carry cookies, session identifiers, and other secrets that are sufficient to impersonate the user or session. The issue is not limited to confidentiality at the transport layer. It is also about the identity-bearing data that rides inside the request and whether the application refuses to proceed when encryption is absent.

Practical implication: Block any auth flow that cannot prove secure transport and validate that fallback logic fails closed.

Why threat hunters use rarity as a signal, not just volume

The article’s method was to compare the common traffic patterns with the least common ones, then use DNS and connection logs to determine whether the anomaly was isolated or systemic. That is a classic hunt approach: rare protocol combinations, unusual header content, and small counts can matter more than large volumes of ordinary traffic. The hunt progressed from three initial HTTP/2 events to 57 unique clients and then to 71 confirmed instances, which shows why rarity is a starting point, not a conclusion. Investigators need to move from one odd event to a population view before deciding whether the issue is a one-off or a repeatable exposure path. See the Threat Hunting Guide.

Practical implication: Build hunts that pivot from rare events into fleet-wide scope checks before dismissing an anomaly as isolated.

Threat narrative

Attacker objective: Expose or capture authentication material carried in plaintext requests so that a session or identity flow can be abused.

1. Entry occurred when clients sent authentication traffic over a protocol path that should have been encrypted but was not.
2. Credential exposure followed as cookies and client headers travelled in cleartext over port 443.
3. Impact was the potential disclosure of session material sufficient to support unauthorised access or session impersonation.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Failed-open transport is an identity control failure, not just a network misconfiguration. When authentication traffic can continue after security negotiation breaks down, the session layer inherits the risk even if the packet itself looks routine. The article shows why defenders must treat transport fallback as part of identity governance, because cookies and headers are often the real access tokens in practice. Practitioners should review where secure transport assumptions are enforced and where they are merely preferred.

Rare-protocol hunting is one of the few reliable ways to catch hidden exposure paths. The most valuable signal here was not packet volume but mismatch: cleartext HTTP/2 on a port associated with encrypted traffic, plus headers that contained secrets. That is exactly the sort of low-frequency, high-meaning pattern that exposure management should surface before it becomes a repeatable exposure path. Practitioners should build detections around expectation gaps, not only known bad indicators.

Protocol downgrade exposure is the named failure mode this article illustrates. The failure is not simply “unencrypted traffic exists.” It is that a client or service path preserved the transaction after encryption disappeared, turning an auth request into a secret-bearing plaintext exchange. That distinction matters for remediation because the root issue sits in fallback behaviour, not only in logging or packet inspection. Practitioners should test whether auth paths fail closed when transport security is lost.

Conference and guest networks can surface production-grade failures in miniature. The environment was temporary, but the pattern mirrors real-world enterprise risk: an identity-bearing application path that assumes encryption and then leaks session data when the assumption breaks. That makes the incident useful beyond the event itself, because the same failure mode can appear in mobile clients, SDKs, and edge services. Practitioners should treat ephemeral-network findings as indicators of systemic application behaviour, not event-only noise.

Read next: Exposure Management and CTEM Guide

What this signals

Protocol expectation gaps are an underused detection surface. A service that appears normal by hostname or port can still be insecure if the request semantics do not match the transport guarantees. Practitioners should watch for auth flows that preserve user state while silently losing encryption, because that is where exposure can travel unnoticed.

Identity-bearing traffic deserves the same scrutiny as credential stores. Cookies, headers, and tokens are not peripheral metadata when they govern access. When those fields move in cleartext, the issue becomes an access-control failure as much as a transport failure, and that should change how investigations are triaged.

For practitioners

• Review authentication flows for failed-open transport paths Trace every auth endpoint and client SDK path that can downgrade from encrypted to cleartext behaviour, then verify that the request is terminated when transport security is unavailable.
• Search for secrets in application-layer headers Inspect request headers, cookies, and query parameters on uncommon protocol paths so that session material is not assumed safe just because the connection uses a familiar port.
• Pivot rare events into population-level hunts Use DNS, connection, and service logs to determine whether a single odd request is isolated or part of a broader pattern across multiple clients and addresses.
• Validate client SDK fallback behaviour Test whether mobile and desktop clients preserve authentication state when secure negotiation fails, and reject any code path that continues in plaintext.

Key takeaways

• The article shows a hidden failure mode where authentication traffic continued in cleartext and exposed session material that defenders would normally assume was protected.
• The hunt expanded from a few odd requests to 71 instances across 16 clients, which is a strong signal that the exposure pattern was repeatable.
• The right control response is to fail closed when secure transport is unavailable and to hunt for rare protocol combinations that reveal hidden downgrade paths.

Related NHI Mgmt Group resources: Exposure Management and CTEM Guide · Threat Hunting Guide · Permission-Aware RAG Guide

Key terms

• Cleartext HTTP/2: HTTP/2 traffic sent without TLS encryption, often called h2c. It is unusual on internet-facing services because most clients and browsers use HTTP/2 only over TLS, so its appearance can indicate a downgrade path, misconfiguration, or failing security control.
• Failed-Open: A failure mode in which a system continues to operate even after a security control has broken or cannot be verified. In identity and transport workflows, failed-open behaviour is dangerous because it can preserve the transaction while silently removing the protection that the transaction depends on.
• Session Material: Session material is the data that keeps an authenticated browser session alive, such as cookies, bearer tokens, and other reusable authentication artifacts. In NHI governance, session material matters because stealing it can bypass password and MFA controls without needing the original login flow.
• Threat Hunting: Threat hunting is the proactive search for signs of compromise that bypassed normal detection controls. It combines logs, telemetry, and investigator judgement to find hidden attacker behaviour before it becomes a larger incident or disrupts recovery.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore the course when your programme needs stronger governance over machine identities, secrets, and access paths.