Beam Me Up, Luke: A Review of Teleport Attack Scenarios - Adam Chester | Black Hat USA 2026

Adam Chester, Senior Offensive Security Consultant (SpecterOps) – 40 min, Oceanside D

‹ ›

1 / 6

A post-compromise tour of Teleport. Chester’s framing is that you have already landed on a host somewhere in the estate, and the question is what the access proxy hands you next. The answer, repeatedly, is more than it should.

Reconstructed from slide photos. The room recording transcribed poorly, so the write-up below sticks to what the slides state directly.

The Shape of a Teleport Cluster

Teleport brokers access to SSH servers, Kubernetes clusters, databases and Windows desktops, and records the sessions while it does it. Users authenticate to a proxy server, the auth server issues short-lived certificates, and agents on the target hosts expose the backend services.

Research was done against v18.6.1, covering both the open source and enterprise builds.

Everything Rides on ALPN

The proxy exposes a single TCP port and routes everything behind it using application layer protocol negotiation. The ALPN value you present decides which internal service you reach — teleport-auth for the auth server, teleport-mysql for a MySQL backend, teleport-reversetunnel for the tunnels agents dial out on, teleport-mcp for an MCP server.

Teleport calls this multiplexing and it is the default routing method. Chester’s point is that it makes the whole surface awkward to poke at by hand, which is why the research needed custom tunnelling tooling before it could start.

The Certificate Is the Authorization

The proxy server can be stateless because every fact needed to approve or deny a connection travels inside the certificate. The subject field carries the username, the target resource, and the restrictions that apply.

That is an elegant design, and it cuts both ways. Anyone who obtains a certificate can read off exactly what access it grants without touching the auth server. Worse, a compromised certificate does not have to expire on schedule — the GenerateUserCerts API can be used to periodically extend it.

The same pattern shows up one layer down, in how backend service agents are trusted to mint certificates for the resources they front. That behaviour falls under the system role permissions issue below, so the specifics are held back here.

Over-Provisioned Agent Credentials

The consequence worth planning around is that a single compromised agent is not contained to itself. Access earned on one host reaches other identities and other resources in the same cluster, which makes agent hosts a higher-value target than their individual scope suggests, and makes “this node only ran a database service” a weaker statement than it appears during incident response.

One related finding has shipped a fix: node credentials were not scoped to their own sessions, so a single compromised agent could enumerate and play back session recordings from across the cluster — turning the audit trail into an intelligence source. That is resolved in 18.7.4 and 17.7.26.

Smartcards Without the PIN

Teleport’s Windows desktop access uses IronRDP with a virtual smartcard holding the user’s certificate. Chester found the PIN check and the cryptographic operation are not bound together: the general authenticate step does not verify that PIN validation actually succeeded. Patching the Windows smartcard API in-process so PIN verification always returns success is enough to skip it, which turns LDAP-level access into use of a logged-on user’s smartcard.

Disclosure and Fixes

Chester opened this section by thanking Teleport for triaging and prioritising immediately on disclosure. Status at the time of the talk:

Tooling

The tooling built for the research was released as the Teleport Attack Kit at github.com/xpn/TAK.

Back to Black Hat USA 2026 – All Talks