Protected Extensible Authentication Protocol (PEAP)

Protected Extensible Authentication Protocol is the outer layer that carries enterprise Wi-Fi authentication. It establishes a TLS tunnel between the client and the RADIUS server, and everything else in the EAP exchange happens inside it. In WPA2 and WPA3-Enterprise deployments, PEAP with MSCHAPv2 as the inner method remains the most widely deployed configuration in the world.

It is also the enterprise wireless weakness that persists longest, because the fix is a PKI project rather than a patch. Before going further, one disambiguation that resolves most confused threads on this topic: there are two distinct PEAP threats and they are routinely conflated. One is a set of authentication weaknesses in PEAP-MSCHAPv2 that an attacker exploits with a rogue access point. The other is a cluster of memory-safety CVEs in Microsoft’s PEAP implementation on the RADIUS server. They require completely different responses: architecture in the first case, patching in the second.

This information is provided for general awareness and defense purposes only. It is not intended to be a complete description of the functionality or risks of the identified tools.

Quick Facts

• What it is: The protected outer layer of enterprise EAP authentication, establishing a TLS tunnel inside which the inner authentication method runs.
• The dangerous configuration: PEAP with MSCHAPv2 as the inner method. PEAP-TLS and TEAP carrying EAP-TLS do not share these weaknesses.
• What actually protects credentials: server-certificate validation on the client, not the tunnel encryption.
• If MSCHAPv2 is captured: treat it as cracked. It reduces to DES over the NT hash, recoverable with a success guarantee in about a day.
• Relay attacks skip cracking entirely, and they work because cryptobinding is optional in the specification and off by default on many clients.
• WPA3-Enterprise does not fix this. It hardens the handshake, not the choice of inner authentication method.

How the PEAP Handshake Works

EAP is a framework of more than forty authentication methods, and PEAP is the most common way they get carried. Bastille CTO Dr. Brett Walkenhorst walks through the exchange in this excerpt from our Wi-Fi Vulnerabilities webinar.

The sequence, with the access point acting as a pass-through in the middle:

1. Outer identity. The client supplies an identity to begin the exchange. This travels in the clear, which is why an anonymous outer identity is often used.
2. PEAP start and server certificate. The RADIUS server begins the PEAP process and presents its certificate.
3. TLS tunnel. Client and server negotiate a symmetric key and establish the tunnel. Everything after this point is encrypted.
4. Inner identity exchange. A second identity exchange happens inside the tunnel, so the client’s real identity is never exposed in the clear.
5. Challenge and response. The inner method, usually MSCHAPv2, runs its challenge-response exchange.
6. Success and teardown. On success the tunnel is torn down and the server tells the access point the client is authentic.
7. Four-way handshake. The access point runs the familiar four-way handshake, but here it only establishes session keys, because authentication already happened.

That last step carries the detail that makes the relay attack possible. In enterprise mode the pairwise master key is not derived from a shared password. It comes from the symmetric key established during the TLS tunnel setup, which then generates the pairwise transient key used for the session. The outer tunnel produces the keying material; the inner authentication only produces a yes or no.

Why the Tunnel Does Not Save You

The most common misconception about PEAP is that TLS protects the credentials. It protects them in transit against a passive listener. It does nothing when the client willingly builds the tunnel to an attacker’s server.

The only thing standing between a client and a rogue RADIUS server is server-certificate validation: the client checking that the presented certificate chains to a trusted CA and matches an expected server name. Where that validation is disabled, misconfigured, or left to end users to set up by hand, an attacker stands up a rogue access point with the corporate SSID, terminates the tunnel, and receives the inner exchange directly. Tooling for this has been mature and public for years.

This is why the honest answer to “is PEAP-MSCHAPv2 broken or just not best practice” is that it is a real, exploitable threat whose exploitability depends entirely on client configuration you may not fully control.

Three Escalating Outcomes

Once a client tunnels to an attacker, there are three distinct payoffs, and the security community routinely muddles the first two.

Credential capture, then offline cracking

The attacker records the MSCHAPv2 challenge and response. That response is three DES operations over the NT hash, which means it reduces to NetNTLMv1. Since work presented at DEF CON in 2012, submitting the challenge-response to a DES keyspace service recovers the hash with a success guarantee in under roughly 24 hours, cheaply, regardless of password complexity. Later tooling shortcuts this further by shucking the result against an NT hash database.

The correct default assumption for a researcher or defender is that captured MSCHAPv2 equals cracked. Not maybe, and not eventually.

Live relay, where nothing is cracked at all

Published by Kruger and White in their 2018 paper on practical attacks against WPA-EAP-PEAP and implemented in publicly available tooling, the relay skips cracking entirely. The attacker forwards the victim’s live inner-authentication frames to the real network. The legitimate RADIUS server validates them and returns success, and the attacker, having completed the outer handshake with the real access point, is on the network with a valid address. No password, no hash, no offline work.

It works for the reason described above: with cryptobinding disabled, the pairwise master key derives solely from the outer TLS session, and nothing in the inner exchange is bound to it. The attacker only needs the RADIUS server to say yes. Practical constraints are that it applies to PEAP with MSCHAPv2 rather than TTLS, requires roughly three wireless adapters for the rogue access point, the relay, and the denial of service, and depends on tight timing.

Machine-account capture, and the path to domain compromise

When PEAP is configured for computer authentication, the inner exchange derives from the machine account’s NT hash. Machine passwords are long and random, which sounds reassuring and is not, because the DES keyspace approach does not care about password complexity: it recovers the hash from the challenge-response either way.

The Airstrike research, tracked as CVE-2021-28316, showed an attacker with physical access to a locked, domain-joined laptop can force it to authenticate against a rogue access point, capture the machine-account challenge-response, recover the hash within a day, and use it with the domain SID to forge Kerberos tickets. That reframes the risk from “PEAP can leak a Wi-Fi password” to “PEAP can leak a path to domain compromise.”

Cryptobinding: The Control Nobody Enables

Cryptobinding links the outer tunnel key and the inner session key so that both authentications must terminate at the same entity. It was theorized in 2002, folded into the EAP RFCs around 2004, and is specified in RFC 5281 and the Microsoft PEAP documentation. Enabled and enforced, it breaks the relay attack.

The under-reported part: cryptobinding is optional in the specification, expressed as a MAY rather than a MUST, and historically has not been enabled by default on Windows, Android, or iOS clients. Many RADIUS servers still accept unbound sessions for legacy compatibility. So the answer to “is cryptobinding on by default, and does it fully stop the relay” is no on the first count, and yes on the second only where you can enforce it and every client supports it. In FreeRADIUS this is crypto_binding = require, and it needs compatibility testing before it goes near production.

How PEAP Compares to Other EAP Methods

Method	Exposure if the tunnel terminates at an attacker	Verdict
PEAP-MSCHAPv2	Challenge-response captured and reliably cracked; live session relayable when cryptobinding is off	Migrate away
EAP-TTLS with PAP	Plaintext password exposed immediately, with no cracking step; not relayable in the same way	Worse on capture
PEAP-TLS	Certificate-based; no password or hash in the flow	Safe from these weaknesses
EAP-TLS	Mutual certificate authentication; immune to capture, relay, and the Credential Guard collision	The consensus destination
TEAP	Depends entirely on the inner method; carrying EAP-TLS is safe, carrying MSCHAPv2 inherits the exposure	Answer depends on configuration
LEAP and EAP-MD5	Trivially crackable, and EAP-MD5 provides no server authentication	Obsolete; do not deploy

Two naming clarifications the community keeps needing. PEAP-TLS is not the same thing as EAP-TLS by name, but both are certificate-based and both avoid the MSCHAPv2 problems entirely; the dangerous variant is specifically PEAP with MSCHAPv2. And “we run TEAP” is not by itself an answer, because TEAP is a tunnel like PEAP and the inner method determines the exposure.

The Microsoft PEAP Server CVEs

This is the second, separate threat. These are memory-safety and input-validation flaws in Microsoft’s PEAP handling on the Network Policy Server, exploitable by an unauthenticated remote attacker sending crafted PEAP packets, with no privileges and no user interaction required.

CVE	Disclosed	Impact
CVE-2023-21689	February 2023	Remote code execution, critical
CVE-2023-21690	February 2023	Remote code execution, critical
CVE-2023-21692	February 2023	Remote code execution, critical
CVE-2023-21695	February 2023	Remote code execution, important
CVE-2023-21691	February 2023	Information disclosure
CVE-2023-36028	November 2023	Heap-based buffer overflow leading to remote code execution, CVSS around 8.1, affecting Windows 10 through 11 23H2 and Server 2016 through 2022

The qualifier that belongs in any accurate write-up: exploitation requires that NPS is running and that a network policy allows PEAP. It is not a default-on condition. Microsoft’s own guidance is to patch and, where PEAP is not needed, to remove it as an allowed EAP type in the network policy, which closes this threat outright.

The Windows 11 Credential Guard Collision

This is the operational force finally moving organizations off MSCHAPv2, and the single largest source of confused help-desk tickets on the subject.

• Starting with Windows 11 22H2, Windows Defender Credential Guard is enabled by default on Enterprise and Education editions.
• Credential Guard isolates NTLM hashes in a virtualized secure environment. Because PEAP-MSCHAPv2 needs access to the NT hash to compute its response, Credential Guard deliberately breaks single sign-on for it.
• The symptom is users being prompted for credentials every session, or losing Wi-Fi connectivity outright after an update, with no obvious connection to the underlying cause.
• The wrong fix is disabling Credential Guard, which restores connectivity by re-exposing exactly the hashes it was protecting.
• The right fix is migrating to certificate-based authentication, which needs no password hash and is fully compatible.

Framed for a security audience: operating system security defaults are now accomplishing what a decade of researcher warnings could not, by making MSCHAPv2 operationally painful rather than merely inadvisable.

Detection: Why Your NIDS Cannot See This

The rogue access point stage of this attack is a layer 2 and RF event, which is where detection confidence tends to be misplaced.

• Network intrusion detection does not see it. Tools operating at layer 3 and above are structurally blind here. In published testing, a credential-harvesting evil twin with a captive portal was not flagged at all, because the attack lives in 802.11 management frames beneath that visibility.
• Wireless intrusion detection is the right sensor, flagging a known SSID appearing on an unauthorized BSSID, deauthentication floods, and rogue access point signatures through continuous off-channel scanning.
• Signature-based detection is evadable. ESSID stripping appends an invisible character such as a trailing space or a zero-width space, so the rogue SSID is a different string that matches no whitelist entry while looking identical to users. Public tooling automates it.
• Behavior-based detection is the counter, catching what stripping cannot hide: deauthentication spikes, a certificate that does not chain to the corporate CA, a known BSSID vanishing while a near-identical one appears on the same channel, and anomalous EAP negotiation.

So the honest answer to “will my WIDS catch it” is that a signature-only deployment may well not, and a behavior-based one is considerably harder to evade. Related coverage: rogue access points and the Wi-Fi Pineapple.

Mitigation, in Priority Order

1. Migrate to EAP-TLS. Certificate-based mutual authentication with no password or hash in the flow, immune to credential capture, relay, and the Credential Guard collision. The real cost is PKI and enrollment, which is the honest reason PEAP persists.
2. If PEAP must remain temporarily, enforce server-certificate validation and pin clients to a specific trusted CA and server name through managed configuration or onboarding, never end-user setup. Require cryptobinding where clients support it, and disable legacy methods including PAP, CHAP, EAP-MD5, and LEAP.
3. Patch NPS and RADIUS for the 2023 PEAP CVEs, and remove PEAP as an allowed EAP type where it is not needed.
4. Deploy behavior-based wireless monitoring rather than signature-only, given ESSID stripping.
5. Run a phased migration with PEAP and EAP-TLS as parallel network policies on the same SSID during rollout.
6. Do not disable Credential Guard as a workaround. Treat its breakage as the signal to migrate.

Frequently Asked Questions

What is PEAP?

Protected Extensible Authentication Protocol is the outer layer of enterprise Wi-Fi authentication. It establishes a TLS tunnel between the client and the RADIUS server using the server’s certificate, and the inner authentication method runs inside that tunnel. It is the most widely deployed EAP configuration in enterprise wireless.

Is PEAP-MSCHAPv2 actually broken, or just not best practice?

It is genuinely exploitable, not merely a compliance finding. Whether your deployment is exploitable depends on client-side server-certificate validation, which is exactly the setting most likely to be wrong on devices you do not fully manage.

If credentials are inside a TLS tunnel, how does an attacker get them?

By making the client build the tunnel to the attacker’s server instead of yours. The tunnel protects against passive sniffing, not against a client that never checks whose certificate it accepted. Once the attacker terminates the tunnel, the inner exchange arrives in plaintext to them.

We enforce server-certificate validation. Are we safe?

Safer, and not finished. Validation defeats naive evil-twin credential capture, but it depends on every client honoring it, and it does not by itself defeat the relay attack, which is addressed by cryptobinding. Validation pinned to a specific CA and server name through managed configuration is the version that holds.

What is the difference between the capture attack and the relay attack?

Capture takes the MSCHAPv2 challenge-response and cracks it offline to recover the hash. Relay forwards the live inner authentication to the real RADIUS server, which approves it, putting the attacker on the network without cracking anything at all. Relay depends on cryptobinding being disabled.

How fast can an MSCHAPv2 challenge-response be cracked?

Reliably within about 24 hours, cheaply, because MSCHAPv2 reduces to DES operations over the NT hash and the full keyspace is searchable. Password complexity does not help. Assume any captured exchange is compromised.

Is cryptobinding enabled by default?

Generally no. It is optional in the specification and historically has not been on by default on Windows, Android, or iOS, and many RADIUS servers still accept unbound sessions for compatibility. Enforcing it breaks the relay attack but requires client compatibility testing.

Why did our Wi-Fi break after upgrading to Windows 11 22H2?

Credential Guard is enabled by default from 22H2 on Enterprise and Education editions, and it isolates the NT hash that PEAP-MSCHAPv2 requires. The result is repeated credential prompts or lost connectivity. Disabling Credential Guard restores service at the cost of re-exposing those hashes; migrating to EAP-TLS resolves it properly.

Which is worse to leak, a user password or a machine-account hash?

The machine account, generally. Machine passwords are long and random, which does not matter to a DES keyspace attack, and a recovered machine-account hash combined with the domain SID enables Kerberos ticket forgery. That turns a wireless issue into an Active Directory issue.

Does WPA3-Enterprise fix PEAP?

No. WPA3-Enterprise changes the handshake and raises cryptographic floors in 192-bit mode, and it still runs whatever EAP method you configure. WPA3-Enterprise with PEAP-MSCHAPv2 carries the same inner weaknesses.

Are the Microsoft PEAP CVEs the same thing as the Wi-Fi attack?

No, and conflating them is the most common error in existing write-ups. Those CVEs are memory-safety bugs on the RADIUS server exploitable by crafted packets, fixed by patching. The wireless attack is a protocol and configuration problem fixed by architecture.

Is EAP-TTLS with PAP better or worse than PEAP-MSCHAPv2?

Worse on capture and better on relay. If the tunnel is broken, TTLS with PAP hands over the plaintext password with no cracking step, but it is not relayable in the same way. Neither is a destination; EAP-TLS is.

Can we run PEAP and EAP-TLS on the same SSID during migration?

Yes. Parallel network policies on the same SSID are the standard phased approach, letting certificate-enrolled devices move first while the remainder continue on PEAP until enrollment completes.

Does an anonymous outer identity protect the username?

Partially. It hides the real identity from a passive observer during the outer exchange, and it provides no protection once the tunnel terminates at an attacker, because the inner identity exchange is then visible to them.

How Bastille Addresses This Threat

The exploitation of PEAP begins with a rogue access point in your airspace, which is a radio event before it is a network event. Bastille monitors the RF spectrum passively from 100 MHz to 7.125 GHz with software-defined radios, observing the 802.11 activity that network-layer tooling never sees.

One boundary worth stating: RF monitoring detects the rogue infrastructure and the client behavior around it. It does not fix the authentication method, and it is not a substitute for migrating to EAP-TLS. It is what tells you an attack is underway in a layer where your other sensors are blind.

See a demo to understand what is transmitting in your environment, or explore more Bastille wireless security research.