Wireless Network Security practice questions

The access point broadcasts a unique SSID that does not match company policy.

Why it fails: Broadcasting a non-company SSID typically indicates a standard rogue AP, such as a user bringing in a home router. While this is a policy violation, it does not necessarily constitute an Evil Twin attack, which specifically requires mimicking a legitimate network to intercept client traffic.

The device has DHCP enabled and is assigning IP addresses from a private range.

Why it fails: Most consumer-grade routers default to DHCP, so this behavior is common for many types of rogue devices. It does not provide specific evidence of an Evil Twin attack, which is defined by the intentional spoofing of a legitimate network's identity to perform interception or credential harvesting.

The access point is connected directly to the corporate Ethernet drop.

Why it fails: A device connected to a corporate Ethernet drop is a significant security risk, but it does not define an Evil Twin attack. This is usually categorized as an unauthorized rogue AP that bridges the corporate network to the wireless medium, increasing the attack surface significantly.

WPA2-Personal with a 64-character PSK.

Why it fails: WPA2-Personal relies on a shared secret. If that secret is leaked, anyone can join the network. Increasing the length of the PSK does not change the fact that it is shared, meaning it fails to meet the requirement of preventing access upon credential disclosure.

MAC address filtering via a centralized database.

Why it fails: MAC filtering is not a robust security control because MAC addresses are easily spoofed. An attacker can simply sniff the airwaves for a legitimate, connected device and clone its address, successfully bypassing this control regardless of the network authentication or encryption being used.

Wireless Intrusion Prevention System (WIPS).

Why it fails: A WIPS is designed to detect and block threats, not to manage user authentication. While it can detect rogue devices, it does not provide the primary control mechanism for determining who is allowed to connect to the network, which is the function of the authentication protocol.

The unauthorized AP is likely causing a channel overlap.

Why it fails: While channel overlap is a performance issue, it is not the primary security risk suggested by an unauthorized AP in an office environment. The existence of a 'Public Wifi' SSID in a secure facility is an intentional attempt to attract users, posing a significant security threat.

The AP is failing to authenticate via RADIUS.

Why it fails: The log entry does not indicate a RADIUS failure; it indicates the detection of an unauthorized access point. RADIUS authentication is a feature of WPA2-Enterprise networks, whereas this rogue AP is likely using an open or insecure configuration to maximize its appeal to unsuspecting users.

The AP is performing a brute-force attack on the SSID.

Why it fails: Brute-force attacks are typically performed against WPA2-PSK passwords, not the SSID itself. The SSID is a broadcast value that is intentionally visible. The risk here is not about the SSID's security, but rather the rogue infrastructure being deployed to deceive employees into connecting to it.

WPA2-Enterprise with EAP-TTLS and a RADIUS server.

Why it fails: WPA2-Enterprise with EAP-TTLS does provide individual credentials and encrypts the inner authentication, but it requires a server certificate for the outer tunnel and client configuration. While it meets the requirement of not transmitting credentials in cleartext, it may be more complex and is not the most direct answer if the requirement is simply individual credentials and unique session keys. However, it is a valid option, but the question asks for the method that ensures unique per-user and per-session keys, which is also provided by EAP-TLS. The key differentiator is that EAP-TTLS can use various inner methods, but it does not inherently provide per-user keys unless configured with individual credentials. Still, it is a strong contender, but the best answer is EAP-TLS because it uses certificates for mutual authentication, ensuring unique credentials and keys.

WPA2-Personal with a pre-shared key (PSK).

Why it fails: WPA2-Personal with a PSK uses a shared secret for all users, so it does not provide individual credentials. The PSK is used in the four-way handshake to derive session keys, but the same PSK is used by all clients, violating the requirement for unique per-user credentials. Additionally, if the PSK is weak, it can be cracked offline, and it is not transmitted in cleartext but does not meet the individual credential requirement.

WPA3-Personal with Simultaneous Authentication of Equals (SAE).

Why it fails: WPA3-Personal with SAE provides stronger protection against offline dictionary attacks and forward secrecy, but it still uses a shared password (though not a PSK in the traditional sense) for all users. It does not provide individual credentials per user, as all users share the same password. Therefore, it fails the requirement for individual credentials and unique per-user session keys derived from individual authentication.

Enable Opportunistic Wireless Encryption (OWE) for transitional clients.

Why it fails: OWE is designed for open networks to provide encryption without authentication, and it is not part of WPA3-Enterprise 192-bit mode. It is used in transition mode for public hotspots. Enabling OWE does not satisfy the Suite-B cryptographic requirements and may actually conflict with enterprise authentication. It is irrelevant to the 192-bit mode configuration.

Configure WPA3-SAE for the enterprise network.

Why it fails: WPA3-SAE (Simultaneous Authentication of Equals) is used in WPA3-Personal, not Enterprise. It provides a password-based authenticated key exchange resistant to offline dictionary attacks. Enterprise networks use 802.1X/EAP. Configuring SAE for an enterprise network is a mismatch and does not enable 192-bit mode, which relies on EAP-TLS with strong ciphers.

Use a 64-character pre-shared key for the enterprise network.

Why it fails: WPA3-Enterprise does not use a pre-shared key; it uses 802.1X/EAP authentication. A PSK is used in WPA3-Personal. Supplying a PSK in an enterprise deployment is technically invalid and does not contribute to 192-bit mode. This option confuses Personal and Enterprise modes and is not a requirement.

Open authentication with a captive portal and client isolation.

Why it fails: Open authentication provides no over-the-air encryption, so guest traffic is sent in cleartext. A captive portal may provide authentication but does not encrypt the wireless traffic. Client isolation prevents peer-to-peer communication but does not protect against eavesdropping. Therefore, this combination fails to meet the encryption requirement, even though it may restrict access.

WPA2-Enterprise with EAP-TLS and a separate guest VLAN.

Why it fails: WPA2-Enterprise with EAP-TLS provides strong encryption and access control, but it requires issuing client certificates to guests, which is operationally impractical for a guest network. The scenario seeks a practical solution for guests. While it would meet the technical requirements, it is not suitable due to the overhead of certificate management for transient users.

WPA3-Personal with SAE and a guest VLAN.

Why it fails: WPA3-Personal with SAE provides strong encryption and is resistant to offline dictionary attacks. However, it still uses a shared password. While it could work for guests, the scenario does not specify WPA3 support on all guest devices. WPA2-Personal is more universally compatible. Additionally, the question asks for a combination that ensures encryption and isolation; WPA3-Personal is valid but not the most appropriate given typical guest device compatibility.

Deploy server certificate validation on the RADIUS server and require clients to validate the server certificate.

Why it fails: Requiring clients to validate the RADIUS server certificate prevents them from authenticating to a rogue AP that presents a self-signed or untrusted certificate. However, the scenario explicitly states the client supplicant configuration must remain unchanged, and this control depends on client-side trust configuration. It also does not change the fact that MSCHAPv2 challenge-response can be captured and cracked if a client is tricked into connecting to an attacker-controlled AP.

Enable RADIUS accounting and log all authentication attempts to a central syslog server.

Why it fails: RADIUS accounting records session start, stop, and interim updates, and logging authentication attempts provides visibility into access patterns. Neither control prevents an attacker from capturing the MSCHAPv2 challenge-response exchange over the air from a rogue AP. Logging may help detect an incident after the fact, but it does not mitigate the credential capture risk described, so it fails to meet the stated security objective.

Enable Protected Management Frames (802.11w) on the WLAN controller and all access points.

Why it fails: Protected Management Frames protects unicast and broadcast management frames such as deauthentication and disassociation, which mitigates forged disconnects and some DoS attacks. It does not protect the inner EAP authentication exchange or prevent an attacker from capturing MSCHAPv2 challenge-response data. Since the requirement is to stop credential capture from a malicious AP, this setting does not address the core MSCHAPv2 weakness and leaves the rogue-AP credential theft risk intact.

Implement MAC address filtering on all wireless access points.

Why it fails: MAC filtering is ineffective as a security control because attackers can easily spoof legitimate MAC addresses using simple software tools. It provides no encryption or authentication, only a weak form of access control that is easily bypassed by anyone performing basic wireless traffic analysis or network reconnaissance.

Increase the PSK complexity to a 64-character alphanumeric string.

Why it fails: While complex pre-shared keys are harder to brute-force, they do not solve the fundamental problem of credential sharing. If an employee shares the PSK, the security of the entire network is compromised. Furthermore, complex keys are difficult to manage and update across large fleets of mobile devices.

Enable hidden SSIDs to prevent unauthorized discovery.

Why it fails: Hiding the SSID is a form of security through obscurity and does not prevent unauthorized connections. Attackers can easily discover hidden SSIDs by monitoring 802.11 management frames, such as probe requests or association frames, making this an ineffective control for protecting enterprise wireless network access.

Channel 1 selection is a performance concern.

Why it fails: While Channel 1 might suffer from co-channel interference if other APs in the vicinity are using it, it is not a security vulnerability. Channel selection is a radio frequency management task that affects throughput and latency, not the cryptographic integrity of the wireless network connection.

WPA2-PSK is insufficient for modern enterprise needs.

Why it fails: While WPA2-PSK is less secure than WPA2-Enterprise, it is not the most significant risk in this specific configuration. The enabled WPS feature provides a direct, known exploit path to bypass the WPA2 encryption entirely, which is a much higher priority for immediate remediation than the PSK protocol.

Management Frame Protection is disabled.

Why it fails: Disabling MFP prevents protection against de-authentication attacks, which is a concern for availability. However, WPS is a more critical vulnerability because it leads to full network compromise and persistent credential theft, whereas MFP issues are limited to service disruption via denial-of-service attacks on the wireless client.

Enable SSID hiding to conceal the network.

Why it fails: SSID hiding is not a valid security control as network names are easily discovered through passive packet capture. Relying on this gives administrators a false sense of security, while doing nothing to stop unauthorized access or reconnaissance by attackers who understand how 802.11 management frames operate.

Use WEP for legacy hardware compatibility.

Why it fails: WEP is cryptographically broken and should never be used. Its implementation of RC4 is fundamentally flawed, allowing attackers to recover the key in seconds by capturing a small amount of traffic. Any network using WEP is effectively unencrypted and fully exposed to any local attacker monitoring traffic.

A standard re-keying process defined by WPA2 standards.

Why it fails: WPA2 re-keying happens periodically and is part of the normal operation of the protocol. It does not manifest as active, manual de-authentication of clients by spoofed MAC addresses, nor does it cause mass connectivity issues for users unless the key rotation process is severely misconfigured.

An automated load balancing mechanism on the AP.

Why it fails: Load balancing might cause an AP to suggest that clients connect to a different radio, but it would not involve spoofing MAC addresses or mass de-authentication of clients. This is an intentional administrative function, not a malicious action designed to disrupt client connectivity and intercept data.

A probe response flood from an adjacent network.

Why it fails: A probe response flood is a different type of wireless attack aimed at overwhelming client devices with network discovery information. It does not involve the de-authentication of already-connected clients, which is a distinct technique used to terminate existing sessions and force client re-authentication or roaming.

WPA3 is fully backward compatible with all WEP-based devices.

Why it fails: WPA3 is not backward compatible with WEP, which is a legacy protocol that has been deprecated for years due to its extreme insecurity. WPA3 requires modern hardware that supports the more robust cryptographic protocols defined in the 802.11ax and 802.11ac standards.

WPA3 removes the requirement for 802.1X authentication entirely.

Why it fails: WPA3 still supports Enterprise mode, which relies on 802.1X for centralized authentication. The standard does not eliminate the need for enterprise-grade authentication; rather, it improves the underlying encryption and key management processes for both Personal (SAE) and Enterprise (802.1X) modes of operation.

WPA3 encryption is strictly limited to 64-bit keys.

Why it fails: WPA3 uses modern, robust encryption algorithms, such as GCMP-256 in the Enterprise mode, which is far more secure than the 64-bit keys used in legacy WEP. The standard is designed to meet modern security requirements, not to limit key lengths to weak, easily crackable standards.

A rogue access point broadcasting a duplicate SSID to lure clients.

Why it fails: A rogue AP broadcasting a duplicate SSID would appear as a separate BSSID and would not flood the network with management frames spoofed as the legitimate AP's MAC address. While an evil twin may be used in conjunction with a deauthentication attack, the flood itself is the deauthentication, not the rogue AP. The scenario specifically describes management frames with the legitimate AP's MAC, indicating spoofing.

A KRACK key reinstallation attack against the WPA2 four-way handshake.

Why it fails: KRACK exploits vulnerabilities in the WPA2 four-way handshake by manipulating retransmissions of message 3, not by flooding management frames. The scenario describes unencrypted management frames with a spoofed AP MAC, which does not match KRACK's manipulation of encrypted EAPOL key frames. KRACK would require a client to be within range and would not produce a flood of management frames.

A WPA3 Dragonblood downgrade attack forcing the use of WPA2.

Why it fails: Dragonblood vulnerabilities target WPA3's SAE handshake and can enable downgrade attacks, but they do not involve flooding management frames with a spoofed AP MAC. The observed high rate of unencrypted management frames is not consistent with a downgrade attack, which typically manipulates the handshake process rather than broadcasting deauthentication frames.

Deploy Protected Management Frames (PMF) on all access points.

Why it fails: PMF protects management frames such as deauthentication and disassociation from spoofing, but it does not alter the inner authentication exchange of PEAP-MSCHAPv2. The attack described captures the MSCHAPv2 challenge-response and cracks it offline because the protocol uses weak DES-based keying and no channel binding. Enabling PMF would not prevent that capture or the offline cracking, so it fails to address the root cause.

Enable 802.11w on the wireless controller.

Why it fails: 802.11w is the IEEE standard for Protected Management Frames, and it secures unicast and broadcast management frames. It does not change the EAP method or the MSCHAPv2 exchange, so an attacker can still capture the authentication handshake and crack it offline. While 802.11w is a good hardening measure, it does not mitigate the specific credential-cracking attack described.

Increase the WPA2 pre-shared key length to 64 characters.

Why it fails: WPA2-Enterprise does not use a pre-shared key; it relies on 802.1X/EAP authentication. Changing a PSK length has no effect on an enterprise deployment. The attack targets the PEAP-MSCHAPv2 inner authentication, not a PSK. This option confuses Personal and Enterprise modes and therefore cannot mitigate the offline cracking of MSCHAPv2.

Location tracking of wireless clients.

Why it fails: Location tracking helps identify where devices are physically located, which can assist in finding a rogue AP, but it does not automatically contain it. The scenario requires containment, not just location. While useful for investigations, location tracking alone does not disable the rogue AP or disconnect its clients. Therefore, it does not satisfy the automatic containment requirement.

Wireless intrusion detection with alerting only.

Why it fails: Detection with alerting only notifies administrators of the rogue AP but does not automatically contain it. The scenario explicitly requires automatic containment, not just alerting. While detection is a prerequisite, it does not fulfill the containment objective. This option would leave the rogue AP operational until manual action is taken, which does not meet the requirement.

Spectrum analysis to identify interference sources.

Why it fails: Spectrum analysis identifies non-Wi-Fi interference and helps with troubleshooting, but it does not contain rogue APs. It is a diagnostic tool, not a containment mechanism. The scenario asks for automatic containment of an unauthorized AP broadcasting the corporate SSID. Spectrum analysis would not disconnect clients or disable the rogue AP, so it is not the correct capability.

EAP-TLS encrypts the entire four-way handshake inside the TLS tunnel, so the ANonce and SNonce are never visible to a passive observer.

Why it fails: The four-way handshake occurs after 802.1X/EAP authentication completes, and its EAPOL-Key frames travel unprotected at the link layer. The TLS tunnel protects only the EAP conversation inside 802.1X, not the subsequent key-exchange frames. Consequently a passive observer does see the ANonce and SNonce, but their visibility alone does not enable PMK recovery because no password-derived material is present.

EAP-TLS relies on PEAP inner-method tunneling, which wraps the client credential exchange in a protected TLS channel so offline dictionary attacks are impossible.

Why it fails: PEAP is a separate EAP method that uses a server certificate to build a TLS tunnel and then runs an inner method such as MSCHAPv2. EAP-TLS is itself the authentication method and does not require an inner method; it performs mutual certificate authentication directly. Confusing PEAP with EAP-TLS misidentifies the mechanism that protects credentials and misstates why the capture is useless to an attacker.

EAP-TLS uses a per-session PSK that the RADIUS server generates and transmits to the client over the encrypted tunnel, so each session key is unique and unrecoverable from the capture.

Why it fails: EAP-TLS does not distribute a PSK from the RADIUS server. Keying material is derived independently by both peers from the TLS master secret negotiated during the certificate-based handshake. Because no PSK is transmitted, the premise of a server-pushed session PSK is incorrect, and that misunderstanding would lead an assessor to look for a transmitted secret that does not exist in EAP-TLS deployments.

A deauthentication flood; enabling Management Frame Protection forces the attacker's forged frames to be discarded by clients.

Why it fails: A deauthentication flood spoofs management frames to disconnect clients, which is a different attack from cloning an AP's identity to attract associations. While 802.11w Management Frame Protection does defend against forged deauthentication and disassociation frames, it does not stop a client from voluntarily associating with a rogue AP that presents a matching SSID and BSSID.

A MAC spoofing attack; deploying 802.1X with MAC authentication bypass on switch ports eliminates the rogue association.

Why it fails: MAC spoofing involves impersonating a permitted client's hardware address and is not the mechanism described, since the attacker here impersonates the access point. MAC authentication bypass is a wired or wireless onboarding fallback that authenticates devices by their MAC address, which is easily spoofed. It does not validate the AP's identity, so it fails to prevent clients from joining the evil twin.

A karma attack; disabling the SSID broadcast on legitimate APs prevents clients from probing for and joining the rogue device.

Why it fails: A karma attack exploits clients that broadcast probe requests by responding to any SSID the client seeks, which differs from cloning one specific corporate BSSID. Hiding the SSID does not prevent the evil twin scenario because clients still send directed probes for known networks, and the rogue can answer them. Suppressing beacons can also break legitimate roaming and client onboarding.

WPA3-SAE still allows offline dictionary attacks but requires more computational effort due to stronger encryption.

Why it fails: WPA3-SAE is specifically designed to prevent offline dictionary attacks. The Dragonfly handshake ensures that each authentication attempt requires interaction with the AP, making brute-force impractical. The claim that it still allows offline attacks is incorrect. Stronger encryption alone does not address the offline attack vector; the protocol design is what provides resistance. Therefore, this statement misrepresents SAE's security properties.

WPA3-SAE requires a captive portal to prevent offline attacks, as it does not encrypt management frames.

Why it fails: WPA3-SAE does not require a captive portal; it is a standalone authentication method. It also optionally supports Protected Management Frames (PMF) which can encrypt certain management frames, but PMF is not required for SAE's resistance to offline attacks. The resistance comes from the Dragonfly handshake. This option confuses unrelated features and incorrectly states a requirement that does not exist.

WPA3-SAE uses the same 4-way handshake as WPA2-PSK but with a longer key, making offline attacks infeasible.

Why it fails: WPA3-SAE does not use the same 4-way handshake as WPA2-PSK. It uses the Dragonfly handshake for authentication and key establishment, followed by a 4-way handshake for key confirmation. The security improvement comes from the SAE exchange, not from a longer key. Simply lengthening the key would not prevent offline attacks if the handshake remained vulnerable. This option inaccurately describes the protocol.

Broadcast the corporate SSID with WPA3-SAE and give customers a rotating guest passphrase that changes weekly.

Why it fails: Sharing a rotating passphrase still exposes a credential that guests can retain or share, and SAE passphrases on the corporate SSID place guests on the same logical network as internal devices unless further segmentation exists. The requirement to avoid sharing the corporate preshared key is only partially met, and isolation from point-of-sale systems is not guaranteed by the passphrase rotation alone.

Deploy the guest network on the same SSID as corporate users and rely on 802.1X to assign guests a restricted role after authentication.

Why it fails: Customers generally lack the credentials needed for 802.1X, so this design blocks the guest use case. Placing guests and corporate devices on one SSID also increases the chance of misconfiguration that grants broader access than intended. While dynamic authorization can assign roles, requiring enterprise authentication for retail guests is operationally impractical and does not meet the stated requirement.

Enable a hidden guest SSID using WEP with a shared key so customers can connect without configuration changes.

Why it fails: WEP is cryptographically broken and trivially cracked, so it provides no meaningful protection. Hiding the SSID offers no security benefit because the SSID is still discoverable in probe and association frames. This option also does nothing to isolate guest traffic from point-of-sale systems, and it would expose customer traffic to interception, making it unsuitable for any production guest network.

Enable 802.11w Management Frame Protection on the SSID to prevent capture of the four-way handshake.

Why it fails: Management Frame Protection authenticates unicast management frames such as deauthentication and disassociation, protecting against forged disconnects. It does not encrypt or hide the four-way handshake, which consists of EAPOL-Key frames rather than management frames. An attacker who passively waits for a legitimate association can still capture the handshake, so 802.11w does not increase resistance to offline dictionary attacks.

Disable the SSID broadcast and enable MAC address filtering to prevent attackers from capturing the handshake.

Why it fails: Hiding the SSID and filtering MAC addresses are obscurity controls that do not affect handshake capture. Clients still transmit the SSID in probe requests, and MAC addresses are trivially spoofed. An attacker within radio range can capture the four-way handshake whenever any client associates, regardless of these settings, so neither measure increases the computational cost of an offline dictionary attack.

Configure the AP to use TKIP instead of CCMP so that the captured handshake cannot be decrypted.

Why it fails: TKIP is a deprecated cipher with known weaknesses and does not prevent handshake capture or offline PSK guessing. The attack targets the PMK derivation from the passphrase, which is independent of the pairwise cipher. Downgrading from CCMP to TKIP weakens the network, may break WPA3 compatibility, and does nothing to raise resistance to dictionary attacks against the preshared key.