Aether

Detailed View

CRITICAL AETHER-001 — WPA Pre-Shared Key Cracked

Description: wifite2 successfully recovered the WPA/WPA2/WPA3 pre-shared key (PSK) for the target SSID via offline dictionary attack against a captured 4-way handshake or PMKID. An attacker with this key can decrypt all past and future traffic on the network (unless PMF/forward secrecy is enforced) and authenticate as a legitimate client.

Remediation: Replace the PSK with a strong random passphrase of at least 20 characters that does not appear in any common wordlist. Enforce WPA3-SAE where hardware supports it. Rotate the PSK immediately and audit which devices have stored it. Consider migrating to WPA3-Enterprise with certificate-based authentication for environments requiring stronger security.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

HIGH AETHER-002 — WPA Handshake Captured

Description: A complete WPA/WPA2 4-way handshake or PMKID was captured for the target SSID. While the PSK has not yet been recovered, the captured material can be subjected to unlimited offline brute-force or dictionary attacks without further access to the network. The handshake was obtained via deauthentication of a connected client or passive PMKID capture.

Remediation: Change the WPA/WPA2 PSK to a strong, unique passphrase not present in public wordlists. Enable WPA3-SAE to replace the 4-way handshake authentication exchange with a forward-secret SAE commit/confirm protocol that is resistant to offline attacks. If WPA3 is not available, enforce a minimum passphrase length of 20+ characters drawn from a high-entropy random source.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N

CRITICAL AETHER-003 — WPA-Enterprise Credentials Captured

Description: EAPHammer deployed a rogue AP that successfully impersonated the target WPA-Enterprise network, downgrades the 802.1X EAP exchange, and captured an MSCHAPv2 challenge/response or NTLM hash from an authenticating client. These hashes can be cracked offline or used directly in pass-the-hash attacks to authenticate to internal Windows/Active Directory resources.

Remediation: Deploy client-side certificate validation to prevent clients from connecting to rogue APs: configure the supplicant to validate the RADIUS server certificate against a pinned CA certificate and reject connections when the certificate does not match. Disable weaker EAP methods (PEAP/MSCHAPv2, EAP-MD5) in favour of EAP-TLS with mutual certificate authentication. Train users not to dismiss certificate warnings.

CVSS Vector: AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

HIGH AETHER-004 — WPA3 SAE Dragonblood — Invalid Curve Attack Confirmed

Description: The target WPA3 SAE implementation accepted an invalid elliptic-curve point during the SAE Commit exchange (attack mode 1 — invalid curve). This is a variant of the Dragonblood vulnerability class disclosed by Mathy Vanhoef and Eyal Ronen. Exploitation allows an active attacker to trick the AP into performing computations on a weak curve, potentially leaking the password encoding and enabling offline dictionary attacks against WPA3 networks that were intended to be resistant to such attacks.

Remediation: Apply firmware updates from the AP vendor that address CVE-2019-9494 and CVE-2019-9495. Ensure the WPA3 implementation validates that received curve points lie on the correct curve (point validation) before performing any SAE computations. Where firmware updates are unavailable, disable WPA3-SAE and use WPA2-Enterprise with EAP-TLS as a mitigation.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

HIGH AETHER-005 — WPA3 SAE Dragonblood — Reflection Attack Confirmed

Description: The target WPA3 SAE implementation is vulnerable to the SAE reflection attack (attack mode 0). By reflecting the AP's own SAE Commit message back to it, the attacking station tricks the AP into deriving the same PWE (Password Element), which can be used to authenticate without knowing the actual PSK under certain conditions. This is part of the Dragonblood vulnerability class (CVE-2019-9494).

Remediation: Apply vendor firmware updates addressing CVE-2019-9494. The fix requires the AP to reject SAE Commit messages whose scalar and element fields match values it previously sent. Upgrade to a patched hostapd/wpa_supplicant version (2.10+).

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

HIGH AETHER-006 — WPA3 SAE Dragonblood — Secondary Invalid Curve Attack Confirmed

Description: The target WPA3 SAE implementation is vulnerable to a secondary invalid curve attack variant (attack mode 2). This variant exploits the same class of point-validation weakness as CVE-2019-9495 but uses a different curve parameter manipulation technique, demonstrating that the AP's SAE implementation does not adequately validate curve points across multiple attack vectors.

Remediation: Apply firmware updates that fully remediate CVE-2019-9495 across all SAE Commit handling code paths. Ensure the patched implementation performs explicit point validation on all received group elements before use in PWE derivation. Verify remediation by re-running dragonslayer attack modes 1 and 2.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

HIGH AETHER-007 — WPA3 SAE Dragonblood — Zero-Scalar Attack Confirmed

Description: The target WPA3 SAE implementation accepted a SAE Commit message with a zero scalar value (attack mode 3). Sending a scalar of zero forces the resulting shared key to be zero or a trivially predictable value, potentially allowing an attacker to authenticate without the actual PSK. This is a variant of the Dragonblood flaw class (CVE-2019-9500–9502).

Remediation: Apply vendor firmware updates addressing CVE-2019-9500 through CVE-2019-9502. The AP must validate that received scalar values are within the valid range (1 ≤ scalar < order) and reject any Commit message with a scalar of zero or order.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

MEDIUM AETHER-008 — WPA3 SAE Resource Exhaustion (Dragondrain) Tested

Description: The target AP was subjected to the Dragondrain SAE commit-flooding attack (CVE-2019-9496). The AP was flooded with forged SAE Commit messages using spoofed source MAC addresses at high rate, targeting curve group 21 (521-bit elliptic). If the AP does not implement anti-clogging tokens or rate limiting, this causes CPU exhaustion and potential denial of service affecting legitimate clients.

Remediation: Apply firmware updates that implement SAE anti-clogging (as specified in IEEE 802.11-2020 Section 12.4.6). Anti-clogging tokens force clients to echo a token before the AP performs expensive elliptic-curve computations, preventing CPU exhaustion. Also enable rate limiting on SAE Commit frames per source MAC address. Update to hostapd 2.10+ which includes anti-clogging support.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

HIGH AETHER-009 — WPA2 KRACK Vulnerability — Standard 4-Way Handshake Reinstallation

Description: The target client or AP is vulnerable to the KRACK key reinstallation attack targeting the standard 4-way handshake (CVE-2017-13077). By replaying and manipulating handshake message 3, an attacker can cause the client to reinstall an already-in-use pairwise transient key (PTK), resetting its associated nonce and replay counters. This allows the attacker to replay, decrypt, and potentially forge 802.11 frames.

Remediation: Apply OS and driver security updates for all wireless clients that address CVE-2017-13077. On the AP side, apply firmware updates that prevent retransmission of handshake message 3 after the key has already been installed. For Android (especially 6.0), this vulnerability resulted in all-zero key reinstallation; priority patch Android devices. Verify remediation with the krackattacks test scripts.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

HIGH AETHER-010 — WPA2 KRACK Vulnerability — TPTK Variant

Description: The target is vulnerable to the KRACK Temporal PTK (TPTK) variant (CVE-2017-13078). This variant exploits the handling of message 1 of the 4-way handshake to cause nonce reuse in the PTK re-derivation process. The attacker can trigger a PTK reinstallation by injecting a retransmitted handshake message 1 with a replayed ANonce, forcing the client to reinstall an already-used key.

Remediation: Apply security patches addressing CVE-2017-13078 for all affected wireless clients and APs. Ensure the supplicant implementation validates that new handshake sessions use fresh ANonces and that reinstallation of previously installed PTKs is prevented. Review and patch all wpa_supplicant and hostapd deployments to version 2.7+.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

HIGH AETHER-011 — WPA2 KRACK Vulnerability — Group Key Reinstallation

Description: The target is vulnerable to KRACK group key reinstallation (CVE-2017-13080). By replaying group key handshake message 1, an attacker can cause the client to reinstall an already-in-use group temporal key (GTK) with a reset replay counter. This allows the attacker to replay broadcast and multicast frames, which can be leveraged to inject ARP spoofing packets or perform other layer-2 attacks against all clients on the network.

Remediation: Apply patches addressing CVE-2017-13080 for all wireless clients. The fix requires the supplicant to check whether the GTK being installed was already installed with the same key ID, and to reject reinstallation. Additionally, disable GTK rekeying on affected APs as a temporary mitigation until client patches are applied. Upgrade to wpa_supplicant 2.7+.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

HIGH AETHER-012 — WEP Encryption in Use

Description: The target network uses WEP (Wired Equivalent Privacy), which has been cryptographically broken since 2001 (CVE-2001-0309). The RC4 stream cipher reuses 24-bit initialisation vectors (IVs), allowing the FMS, KoreK, and PTW statistical attacks to recover any WEP key from roughly 50 000 captured frames — achievable in under a minute on an active network. An attacker within radio range can decrypt all traffic and authenticate as a legitimate station. WEP was deprecated by IEEE 802.11i in 2004 and formally withdrawn. No patch exists; the protocol must be replaced.

Remediation: Immediately replace WEP with WPA3-Personal (SAE) or at minimum WPA2-Personal (CCMP/AES). WEP cannot be patched — upgrade the AP firmware or replace the device. Segment any WEP-only legacy devices onto an isolated VLAN with no access to sensitive resources until they can be replaced.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CRITICAL AETHER-013 — WEP Key Cracked

Description: aircrack-ng recovered the WEP key using the PTW statistical attack against collected IVs. With the key an attacker can decrypt all past and future traffic in real time, inject arbitrary 802.11 frames, and authenticate as a legitimate station. The network must be treated as fully compromised. All credentials, session tokens, and data transmitted over this network must be assumed captured by an adversary.

Remediation: Treat the network as compromised. Replace WEP with WPA3-Personal immediately. Rotate all credentials used on devices that connected to this network. Review logs for unauthorised access since the network was deployed. Notify affected users. Replace hardware that cannot support WPA2.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

MEDIUM AETHER-014 — Open / Unencrypted Wireless Network

Description: The target network operates without wireless encryption (open authentication, no WEP/WPA). All data is transmitted in cleartext and can be captured passively by any device within radio range. HTTP sessions, credentials, emails, DNS queries, and file transfers are fully exposed without any evidence of interception.

Remediation: Enable WPA3-Personal (SAE) or WPA2-Personal (CCMP/AES). If the network is intentionally open (guest portal, public hotspot), enforce TLS for all services, enable AP client isolation, and display a legal notice. Consider 802.11u Hotspot 2.0 / Passpoint for authenticated open networks that do not require a pre-shared key.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

MEDIUM AETHER-015 — WPS Enabled on Access Point

Description: Wi-Fi Protected Setup (WPS) is enabled on the target AP. WPS PIN-based authentication has a fundamental design flaw: the 8-digit PIN is verified in two independent 4-digit halves, reducing the effective keyspace from 10^8 to ~11 000 attempts. Many APs are additionally vulnerable to the Pixie-Dust attack (CVE-2014-9527), which recovers the WPS PIN offline in seconds from weak nonce values. A successful WPS attack recovers the full WPA2 PSK regardless of its length or complexity.

Remediation: Disable WPS on the AP if it is not operationally required. If WPS is required, ensure the AP uses WPS 2.0 with lockout after 3 failed attempts and verify Pixie-Dust mitigation is implemented in the firmware. Apply all vendor firmware updates. Note: WPS cannot be safely enabled on APs with Broadcom or Ralink chipsets without explicit Pixie-Dust patches.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

MEDIUM AETHER-016 — WPA3 Transition Mode — Downgrade Attack Surface

Description: The target AP is operating in WPA3-Transition mode (WPA2/WPA3 mixed mode), simultaneously supporting both WPA2 and WPA3 clients. An attacker can deploy a rogue AP advertising only WPA2 with the same SSID. Clients configured for transition mode will connect via WPA2, exposing their 4-way handshake to standard offline dictionary cracking. This is the most practical WPA3 attack vector in real-world deployments. Tools: DragonShift, hostapd-mana.

Remediation: Migrate to WPA3-only mode when all client devices support WPA3-SAE. In the interim, enable 802.11w (PMF) as mandatory — this prevents deauthentication-based downgrade forcing. Audit which clients cannot support WPA3 and establish a remediation timeline. Consider a separate SSID for legacy WPA2 clients rather than running mixed mode on the primary SSID.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N

HIGH AETHER-017 — WPA PMKID / EAPOL Hash Captured

Description: hcxdumptool captured a PMKID or EAPOL hash for the target SSID without requiring a connected client or deauthentication. The PMKID is derived as HMAC-SHA1(PMK, 'PMK Name' || AP_MAC || CLIENT_MAC) and is broadcast by the AP in the first EAPOL frame. The captured hash can be subjected to unlimited offline brute-force or dictionary attacks against the WPA PSK without further access to the network.

Remediation: Change the WPA PSK to a strong, randomly-generated passphrase of at least 20 characters not present in any wordlist. Enable WPA3-SAE to replace PMKID-based authentication with the Dragonfly PAKE, which is resistant to offline attacks. If WPA3 is unavailable, enforce a minimum passphrase entropy equivalent to >128 bits (20+ random characters from a large charset).

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N

CRITICAL AETHER-018 — MSCHAPv2 Hash Cracked via asleap

Description: asleap successfully cracked the MSCHAPv2 challenge/response captured by EAPHammer's rogue AP. MSCHAPv2 is inherently weak: the challenge is 56-bit DES-based and the response leaks the NT hash, which can be cracked offline in hours on consumer hardware. The recovered plaintext password can be used for pass-the-hash attacks against Windows/Active Directory resources, VPN authentication, and other services using the same credential.

Remediation: Migrate from PEAP/MSCHAPv2 to EAP-TLS with mutual certificate authentication, which is not susceptible to rogue AP credential capture. If MSCHAPv2 must remain in use, configure clients to validate the RADIUS server certificate against a pinned CA and reject connections on certificate mismatch. Immediately rotate all affected credentials and audit for unauthorized access using the cracked password.

CVSS Vector: AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

HIGH AETHER-019 — Rogue AP — Clients Associated to Evil Twin

Description: One or more wireless clients associated to an attacker-controlled rogue AP that cloned the target SSID and BSSID. Clients that associate with the rogue AP have all their wireless traffic visible to the attacker; any unencrypted application-layer credentials or session tokens are exposed. Clients with stored network profiles are especially vulnerable as they connect automatically.

Remediation: Deploy WPA3-SAE with PMF (802.11w) set to Required on all APs. Ensure clients validate network certificates where possible (WPA3-Enterprise or certificate-pinned supplicants). Implement wireless intrusion detection to alert on rogue APs. Educate users not to accept certificate warnings or dismiss security prompts on wireless networks.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N

CRITICAL AETHER-020 — Rogue AP — WPA Pre-Shared Key Phished via Captive Portal

Description: A client associated with the rogue AP and submitted a WPA PSK via a captive portal page that mimicked the target network's authentication interface. The submitted credential was validated against the captured PMKID and confirmed as the correct pre-shared key. This attack requires no prior knowledge of the PSK and succeeds whenever a user can be deceived into re-entering their credentials after an unexpected disconnection.

Remediation: Migrate to WPA3-SAE, which is not vulnerable to this class of credential phishing attack. As an interim control, restrict PSK distribution to trusted channels and train users to be suspicious of any captive portal requesting their Wi-Fi password. Enable WIDS/WIPS to detect and block rogue APs.

CVSS Vector: AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

CRITICAL AETHER-021 — KARMA / MANA Attack — Client Credentials Captured

Description: A KARMA/MANA rogue AP responded to probe requests from clients seeking previously associated networks and captured credentials from clients that automatically connected. This attack exploits devices that broadcast previously associated SSIDs in probe requests, allowing an attacker to impersonate any remembered network and intercept authentication material.

Remediation: Configure client devices to send directed probe requests only (not broadcast) and to use random MAC addresses for probe requests. Disable auto-connect for open and low-trust networks. Enable PMF on all production networks. Ensure clients require server certificate validation before completing EAP authentication.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

MEDIUM AETHER-022 — Protected Management Frames (PMF / 802.11w) Not Enforced

Description: The target AP does not require Protected Management Frames (PMF/802.11w). A deauthentication or disassociation frame sent by an attacker was accepted by the AP or client, demonstrating that management frames are not authenticated. This allows an attacker in radio range to force client disconnections, enabling evil twin and MITM attacks.

Remediation: Enable PMF (802.11w) set to Required on all enterprise APs. WPA3 mandates PMF by default. Verify that both AP and client supplicant support and enforce PMF. On WPA2 networks, set ieee80211w=2 in hostapd configuration.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H

MEDIUM AETHER-023 — BSS Transition Management (802.11v) Hijack Accepted

Description: A crafted BSS Transition Management (BTM) request (802.11v, Category 10 Action 7) was accepted by a client, causing it to roam to an attacker-specified BSSID. This attack allows an attacker to redirect clients to a rogue AP without deauthentication, potentially bypassing PMF protections on WPA2 networks that do not protect Action frames.

Remediation: Enable PMF Required (802.11w=2) to protect Action frames including BTM requests. Audit roaming policies and consider disabling 802.11v BTM on networks where roaming is not required. Upgrade affected clients and APs to firmware versions that validate BTM request authenticity.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L

LOW AETHER-024 — Client Probe Request Harvest — Remembered Network Disclosure

Description: Wireless clients in the vicinity are broadcasting probe requests containing the SSIDs of previously associated networks. This information discloses the wireless networks a device has connected to, can be used for device tracking (even with MAC randomisation if implementation is flawed), and enables targeted KARMA/evil twin attacks against those specific SSIDs.

Remediation: Configure devices to send only directed probe requests to specific APs rather than broadcast probes for all remembered networks. Modern operating systems with MAC randomisation also suppress SSID disclosure in probes — ensure this feature is enabled. Remove outdated or low-trust networks from device preferred network lists.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

CRITICAL AETHER-025 — EAP Downgrade — Weak EAP Method Credentials Captured

Description: EAPHammer with balanced negotiation captured credentials by accepting a weaker EAP method (e.g. PEAP/MSCHAPv2 or EAP-MD5) offered by a client whose supplicant was not locked to a specific EAP type. MSCHAPv2 hashes obtained this way can be cracked offline or relayed directly to Windows domain services without cracking.

Remediation: Lock client supplicants to a specific permitted EAP method and enforce server certificate validation. Disable weaker EAP types (PEAP/MSCHAPv2, EAP-FAST without PAC validation, EAP-MD5) at both the RADIUS server and client policy levels. Migrate to EAP-TLS with mutual certificate authentication where possible.

CVSS Vector: AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

MEDIUM AETHER-026 — SAE Transition Mode — WPA2 Downgrade Attack Surface

Description: The target AP operates in WPA3/WPA2 transition mode and a WPA2-only rogue AP was created with the same SSID. Clients supporting both WPA3-SAE and WPA2-PSK may associate with the rogue WPA2-only AP, losing the security guarantees of SAE. This enables legacy WPA2 attacks including PMKID capture and handshake-based cracking against previously WPA3-protected clients.

Remediation: Disable WPA3/WPA2 transition mode and enforce WPA3-SAE only once all clients support it. If transition mode is required, enable PMF Required (802.11w=2) on both the WPA2 and WPA3 BSSIDs. Implement WIDS to detect duplicate SSIDs advertising different security capabilities.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N

HIGH AETHER-027 — ARP Cache Poisoning — MITM Position Established

Description: ARP cache poisoning was successfully performed on the rogue AP's subnet, placing the assessment system in a man-in-the-middle position between wireless clients and the gateway. All unencrypted traffic (HTTP, FTP, Telnet, legacy protocols) was readable, and encrypted traffic was subject to downgrade or stripping attacks. This demonstrates the risk of any attack scenario where a client can be induced to join an attacker-controlled network.

Remediation: Enable Dynamic ARP Inspection (DAI) on managed switches. Deploy HTTPS Strict Transport Security (HSTS) and HSTS preloading to prevent protocol downgrade. Ensure all internal services use TLS. On wireless networks, WPA3-SAE with PMF prevents the initial rogue AP association that enables this attack.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

HIGH AETHER-028 — LLMNR / NBT-NS Poisoning — NTLMv2 Hashes Captured

Description: Responder successfully poisoned LLMNR (Link-Local Multicast Name Resolution) and/or NBT-NS (NetBIOS Name Service) queries on the rogue AP's subnet and captured NTLMv2 challenge/response hashes from Windows clients attempting to resolve non-existent hostnames. These hashes can be cracked offline or used in NTLM relay attacks to authenticate to internal services without cracking.

Remediation: Disable LLMNR via Group Policy: Computer Configuration → Administrative Templates → Network → DNS Client → Turn Off Multicast Name Resolution = Enabled. Disable NBT-NS via WINS settings on the IPv4 adapter: disable NetBIOS over TCP/IP. Implement SMB signing to prevent NTLM relay attacks. Monitor for and alert on unexpected LLMNR/NBT-NS query responses.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

INFO AETHER-029 — Internal Hosts Discovered via Post-Connection Port Scan

Description: An nmap scan of the wireless subnet revealed live hosts and open services accessible to wireless clients. This establishes the attack surface available to any client (authorised or rogue) that connects to the wireless network. Services accessible from the wireless segment without additional segmentation represent a potential lateral movement path.

Remediation: Implement network segmentation: place the wireless network in a dedicated VLAN with firewall rules restricting access to internal services. Apply the principle of least privilege — wireless clients should only be able to reach services required for their function. Disable unnecessary services on hosts and implement host-based firewalls.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

MEDIUM AETHER-030 — TKIP Encryption in Use

Description: The target network uses TKIP (Temporal Key Integrity Protocol), a deprecated encryption scheme that was introduced as a quick fix for WEP and was officially deprecated by the IEEE 802.11 standard in 2012. TKIP is vulnerable to the Beck-Tews and Ohigashi-Morii attacks (ChopChop/fragmentation), allowing an attacker to partially decrypt and inject short packets without the key.

Remediation: Disable TKIP and require CCMP (AES) as the only permitted pairwise cipher. Set rsn_pairwise=CCMP and wpa_pairwise=CCMP in hostapd configuration, or equivalent settings in the AP's admin interface. Remove WPA1/TKIP-only client support — all modern clients support CCMP.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

HIGH AETHER-031 — TKIP ChopChop / Fragmentation Attack — Packet Decryption Confirmed

Description: A TKIP ChopChop or fragmentation attack (Beck-Tews / Ohigashi-Morii) was confirmed against the target network. An attacker can exploit this to decrypt the last 12 bytes of an arbitrary short packet without knowing the key, and to inject up to 7 or 14 bytes of attacker-chosen plaintext per minute. This enables ARP poisoning, DNS spoofing, and decryption of short high-value packets (e.g. ARP replies, DNS responses) on WPA-TKIP networks.

Remediation: Immediately disable TKIP. Migrate the network to WPA2 or WPA3 using only CCMP (AES) as the pairwise cipher. Do not allow TKIP as a fallback cipher for any client.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

LOW AETHER-032 — Wi-Fi Direct / P2P Device Discovered

Description: A Wi-Fi Direct (P2P) capable device was discovered in the assessment area. Wi-Fi Direct devices create their own access point interfaces and may accept WPS-PIN connections independently of the corporate wireless infrastructure, bypassing network access controls and firewall policies. If WPS-PIN is enabled, the device may be vulnerable to the Pixie Dust or online WPS brute-force attacks.

Remediation: Disable Wi-Fi Direct on corporate devices via MDM or Group Policy where the feature is not required. If Wi-Fi Direct is necessary, ensure WPS-PIN is disabled and only WPS-PBC (push button) is permitted. Audit firmware for Wi-Fi Direct devices and apply vendor security updates.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

HIGH AETHER-033 — Wi-Fi Direct WPS PIN Cracked — Device Compromised

Description: The WPS PIN for a Wi-Fi Direct device was recovered via reaver or a Pixie Dust offline attack. An attacker with this PIN can authenticate to the device's P2P group owner and gain network-level access to the device, potentially enabling access to shared files, printers, or other services exposed over the P2P connection.

Remediation: Disable WPS on all Wi-Fi Direct capable devices. If WPS must remain enabled for operational reasons, disable PIN mode and use only WPS-PBC (push button) with physical access controls. Apply vendor firmware updates to devices vulnerable to Pixie Dust.

CVSS Vector: AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

HIGH AETHER-CAP-DNS-EXTERNAL — Captive Portal: External DNS Resolution Pre-Authentication

Description: Unauthenticated clients on the open SSID can resolve arbitrary hostnames via external DNS resolvers (e.g. 1.1.1.1, 8.8.8.8) before completing captive portal authentication. The portal is enforcing only at the HTTP/HTTPS layer.

Impact: DNS leakage pre-auth is the foundation for DNS tunneling (iodine, dnscat2) — an attacker can establish a full-duplex tunnel encapsulating arbitrary IP traffic in DNS queries, completely bypassing the portal's billing, AAA, and content controls. Often invisible to the portal vendor's logging because DNS query payloads are not inspected.

Remediation: Block all outbound DNS (UDP/TCP port 53) from unauthenticated guest VLANs except to the captive portal's own resolver, which should only answer for the portal's hostname. Most captive portal vendors (Meraki, Aruba, Ubiquiti) expose a 'walled garden DNS' setting that restricts pre-auth DNS to a tightly-scoped allowlist; enable it.

Effort: Easy

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

MITRE ATT&CK: T1071.004 (Command and Control)

NIST 800-53: AC-3, AC-4, SC-7

PCI DSS 4: 1.2.1, 1.4.2

CRITICAL AETHER-CAP-DNS-TUNNEL — Captive Portal: DNS Tunneling Viability Confirmed

Description: A long random-subdomain DNS query (40 chars, characteristic of DNS tunneling tools) was successfully forwarded by the captive portal's network to an external resolver. This proves DNS tunneling tools (iodine, dnscat2, dns2tcp) can establish a covert channel through the portal.

Impact: Full data exfiltration and full-duplex C2 channel through the captive portal without any authentication. The attacker gains arbitrary internet access, can exfiltrate sensitive data, and can serve as a pivot for lateral movement. Portal billing/AAA is completely bypassed. Detection requires DNS payload inspection that most captive portal implementations lack.

Remediation: Restrict pre-auth DNS to the captive portal's own resolver answering only for the portal's hostname (walled-garden DNS). Additionally deploy DNS query length / entropy monitoring to detect tunneling attempts (queries with high-entropy subdomains >30 chars are characteristic of iodine/dnscat traffic). Consider a DNS sinkhole for unknown external resolvers.

Effort: Moderate

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

MITRE ATT&CK: T1071.004 (Command and Control), T1572 (Command and Control), T1048.003 (Exfiltration)

NIST 800-53: AC-3, AC-4, SC-7, SI-4

PCI DSS 4: 1.2.1, 1.4.2, 11.5.1

MEDIUM AETHER-CAP-HTTP-DIRECT — Captive Portal: Direct HTTP to Arbitrary IP Pre-Authentication

Description: Direct HTTP to an arbitrary IP address (without DNS lookup) succeeded from an unauthenticated client. The captive portal is filtering by Host header / DNS rather than at the IP-egress layer.

Impact: Attacker can reach any internet host on port 80 without authenticating. While bandwidth is the primary asset stolen here, this also enables retrieval of subsequent-stage payloads, beaconing, and reach to attacker-controlled HTTP infrastructure on commodity IPs.

Remediation: Confirm the captive portal applies its HTTP redirect to ALL outbound HTTP traffic (port 80), not only requests with specific Host headers. Many vendors only intercept HTTP redirects, leaving direct IP-addressed HTTP (curl http://1.1.1.1/) unblocked. Move enforcement to the IP layer with explicit deny rules in the firewall for the unauthenticated VLAN.

Effort: Easy

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

MITRE ATT&CK: T1071.001 (Command and Control)

NIST 800-53: AC-3, AC-4

PCI DSS 4: 1.2.1

MEDIUM AETHER-CAP-HTTPS-DIRECT — Captive Portal: Direct HTTPS to Arbitrary IP Pre-Authentication

Description: Direct HTTPS to an arbitrary IP address succeeded from an unauthenticated client. The captive portal does not block outbound port 443 pre-authentication.

Impact: Attacker can establish encrypted connections to arbitrary internet hosts (C2, exfil, content delivery, VPN-over-HTTPS) without authenticating. Because the channel is encrypted, the portal vendor has no visibility into what's being transferred. Often easier to exploit than HTTP bypass because portal vendors typically focus interception on the HTTP redirect layer.

Remediation: HTTPS bypass is harder for portals to intercept than HTTP because TLS cannot be transparently redirected — block port 443 outbound from the unauthenticated VLAN entirely until authentication completes. Inspect the captive portal vendor's documentation for the 'block all egress until auth' or 'pre-authentication firewall mode' setting.

Effort: Easy

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

MITRE ATT&CK: T1071.001 (Command and Control), T1573 (Command and Control)

NIST 800-53: AC-3, AC-4

PCI DSS 4: 1.2.1

HIGH AETHER-CAP-IPV6 — Captive Portal: IPv6 Dual-Stack Bypass

Description: Direct outbound traffic over IPv6 succeeded from an unauthenticated client on the open SSID, while IPv4 traffic was (or would have been) intercepted by the captive portal. This is the classic dual-stack misconfiguration: the portal filters v4 only.

Impact: The portal's entire access control model is bypassed via IPv6. Unauthenticated clients have full internet access without billing, AAA, or content controls — only via v6. Often invisible in portal vendor consoles that report v4-only statistics. Because v6 connectivity to major content destinations (Cloudflare, Google, Apple, AWS) is widely available, this is a fully practical bypass.

Remediation: Apply identical pre-authentication filtering rules to BOTH IPv4 and IPv6 traffic on the guest VLAN. Many captive portal vendors only filter IPv4 by default — IPv6 advertisements (RAs) leak the v6 prefix to clients which then route around the portal entirely. Either: (a) disable IPv6 on the guest VLAN (RA Guard + suppress RAs), or (b) deploy matching ip6tables/PBR rules. PCI-DSS 4.0 §1.4.5 explicitly requires controls on all network protocols including IPv6.

Effort: Moderate

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

MITRE ATT&CK: T1071.001 (Command and Control)

NIST 800-53: AC-3, AC-4, SC-7

PCI DSS 4: 1.2.1, 1.4.2

MEDIUM AETHER-034 — Captive Portal Bypass Confirmed

Description: The target captive portal was bypassed using one or more techniques: DNS tunnelling (exfiltrating data via DNS queries to an external resolver), MAC address spoofing (cloning the MAC of an already-authenticated client), or direct HTTPS access to allowed domains before portal authentication. This allows an attacker to gain full internet access without completing the required authentication or payment flow.

Remediation: Enforce captive portal controls at the IP layer rather than relying solely on DNS. Block all outbound DNS except to the captive portal resolver. Implement MAC address validation in conjunction with IP binding and session tokens. Use HTTPS for the captive portal itself to prevent credential interception.

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

INFO AE-001 — Multiple APs Broadcasting SSID: {ssid_label}

INFO AE-002 — WPA Handshake / PMKID Captured: {ssid}

INFO AE-003 — WPA Pre-Shared Key Cracked via Deauth: {ssid}

INFO AE-004 — WPA Pre-Shared Key Cracked: {ssid}

INFO AE-005 — WPS PIN / Pixie Dust Succeeded: {ssid}

HIGH AETHER-CERT-001 — Weak Server Certificate Algorithm or Key Length

Description: The RADIUS server certificate used for EAP-TLS (or PEAP/TTLS server validation) uses a signature algorithm or RSA key length that is below current cryptographic best practice. SHA-1 and MD5 signatures are deprecated; RSA keys shorter than 2048 bits are considered weak.

Impact: Compromise of the server's private key allows an attacker to impersonate the RADIUS server, present a valid-looking cert to clients, and capture EAP credentials or downgrade authentication. The longer the weak cert remains in service the higher the chance of a key-compromise event being undetected.

Remediation: Re-issue the RADIUS server certificate using SHA-256 or stronger signature algorithm and a 2048-bit RSA key (or ECDSA P-256 / P-384). Rotate via the existing certificate-management workflow without a service window where possible. Verify clients trust the new chain before retiring the old cert.

Effort: Easy

NIST 800-53: SC-13, SC-17

MEDIUM AETHER-CERT-002 — Server Certificate Expired or Expiring Soon

Description: The RADIUS server certificate has either passed its Not After date (expired) or is within 30 days of expiry. EAP-TLS authentication fails closed when the server cert expires, causing service outage for all wireless clients.

Impact: Service outage at expiry. Pressure to rapidly issue a replacement cert can lead to operational shortcuts (e.g., re-using the same private key, choosing a longer-than-policy validity, omitting cert pinning verification).

Remediation: Replace the cert immediately. Add 60-day-prior and 30-day-prior monitoring alerts to the cert lifecycle process. Document the renewal procedure in the wireless operations runbook.

Effort: Easy

MEDIUM AETHER-CERT-003 — Server Certificate Self-Signed or From Unrecognised CA

Description: The RADIUS server certificate is self-signed (Subject == Issuer) or issued by a CA not present in the standard public root store. While valid for internal deployments, this requires every client to be explicitly configured to trust the specific cert or CA — a common misconfiguration vector.

Impact: Clients with poor cert-validation configuration ("Trust Any Certificate" or no CA pin) will accept ANY self-signed cert presented by a rogue authenticator. Evil-twin attacks become trivially successful.

Remediation: Either move to a public-CA-signed cert OR enforce CA pinning + 'Validate server certificate' = ON across all client supplicants via MDM / GPO policy. Document the cert thumbprint and require clients to verify against it.

Effort: Moderate

MEDIUM AETHER-CERT-004 — Server Certificate Issuer Reveals Internal CA Infrastructure

Description: The Issuer field of the RADIUS server certificate contains terms suggesting an internal Certificate Authority (e.g., CN=corp-CA-01, CN=AD-CA, CN=Internal-Root). This is informational reconnaissance value — it confirms the existence and naming convention of an internal PKI.

Impact: An attacker learns the internal CA naming convention, which feeds into Active Directory / network-topology reconnaissance. Combined with other findings (cert SAN disclosure, EAP identity leakage) the attacker maps the corporate auth infrastructure without authenticated access.

Remediation: Use a public-CA-signed cert for the RADIUS server. Where internal CA must be used, anonymise the Issuer CN to avoid topology disclosure (CN=Auth-Services-01 rather than CN=corp-AD-CA-01).

Effort: Moderate

LOW AETHER-CERT-005 — Server Cert SAN Reveals Internal RADIUS Hostnames

Description: The Subject Alternative Name field of the RADIUS server cert contains hostnames suggesting RADIUS server infrastructure (radius.corp.local, nps01.corp.local, ise-pdp.corp.local). This is information disclosure of internal naming conventions.

Impact: Reveals the internal hostname pattern and number of RADIUS servers in the deployment. Useful reconnaissance for an attacker who later gains internal access and wishes to target the auth infrastructure directly.

Remediation: Move RADIUS servers behind an anonymised public hostname (auth.example.com) for SAN purposes, or omit internal hostnames from the cert SAN when they don't need to be reachable by name.

Effort: Moderate

INFO AETHER-CERT-006 — Server Certificate Uses Strong Modern Algorithm (Positive)

Description: The RADIUS server certificate uses SHA-256 or stronger signature, RSA-2048 or stronger (or ECDSA), is signed by a recognised public CA, is currently valid, and does not disclose internal infrastructure naming. Positive vendor security observation.

Impact: Confirms the cryptographic posture of the wireless authentication infrastructure meets current standards. Reduces the value of cert-based attacks (key cracking, downgrade) to negligible.

Remediation: Maintain the current certificate-management posture. Document the issuance procedure in the operations runbook to ensure replacements maintain the same standards.

Effort: n/a

INFO AETHER-INFO-CERT-CAPTURED — Server Certificate Captured From EAP Exchange

Description: A server certificate presented during an EAP-TLS / PEAP / TTLS exchange was captured passively from observed wireless traffic and exported for analysis. This is the data-gathering step for the cert-grading findings (AETHER-CERT-001 through 006).

Impact: Provides engagement-evidence attribution for any cert-related finding emitted. Confirms the cert chain was visible to a passive on-path observer (which is normal for TLS server certs but worth recording).

Remediation: No action required — informational only. Cross-reference with findings AETHER-CERT-001 through AETHER-CERT-006 for the grading outcome.

Effort: n/a

MEDIUM AETHER-EAPTLS-001 — EAP Outer Identity Leaks User-Realm Format

Description: The EAP-Response/Identity message (the OUTER EAP identity sent in cleartext before TLS negotiation) contains a username component (user@realm) rather than the recommended anonymous@realm or @realm form. This leaks usernames to any passive on-path observer.

Impact: Reveals the entire active user population to anyone in RF range. Combined with username-enumeration findings on other systems (Active Directory, email server) this is a high-value reconnaissance source for credential-spray attacks.

Remediation: Configure all supplicants to use an anonymous outer identity. On Windows GPO: Wireless Network (IEEE 802.11) Policies → properties → Security → Settings → Advanced → Enable Identity Privacy. On Linux NetworkManager: anonymous_identity setting. On macOS / iOS: configure via MDM profile.

Effort: Moderate

CRITICAL AETHER-EAPTLS-002 — Client Supplicant Fails to Validate Server Certificate (Evil Twin Succeeds Against EAP-TLS)

Description: An evil-twin rogue AP with a self-signed cert successfully attracted a client supplicant which proceeded past server-cert validation. Even though EAP-TLS's cert exchange is bidirectional, the client should have rejected the unknown server cert. This indicates the client's 'Validate server certificate' setting is disabled, OR the trust store accepts the rogue self-signed cert (e.g., set to 'any CA').

Impact: Defeats the entire benefit of EAP-TLS. The attacker can capture the client's identity, fingerprint the client device, and in PEAP/TTLS configurations capture credentials. The vulnerable client cannot distinguish the corp RADIUS from the rogue AP.

Remediation: Push a hardened supplicant configuration to all clients via MDM/GPO: 'Validate server certificate' = ON; CA pinned to specific public-CA root or internal CA cert thumbprint; reject any cert signed by an unknown CA. Audit current client configurations and remediate non-compliant devices.

Effort: Moderate

NIST 800-53: IA-2, IA-5

MEDIUM AETHER-EAPTLS-003 — Client Supplicant Attempts Authentication Against Rogue AP

Description: A client supplicant attempted EAP authentication against an unauthorised AP impersonating the corporate SSID, then aborted when server cert validation failed. The cert validation worked correctly (positive sub-finding), but the connection attempt itself reveals the client's interest in the SSID and exposes the client MAC address and outer identity to the attacker.

Impact: Attacker harvests client MAC addresses, vendor OUI, and outer identity strings without breaking authentication. Useful for client-side targeting and reconnaissance even when the cert exchange is rejected.

Remediation: Configure clients to scrutinise the BSSID of authorised APs (not just SSID), and apply MAC-based scoping in the supplicant where the platform supports it. Reduce SSID broadcast attractor surface (e.g., disable beacon broadcast on the corp SSID if a hidden-SSID model is preferred).

Effort: Moderate

INFO AETHER-MERAKI-001 — Meraki Infrastructure Identified

Description: One or more wireless APs in scope identified as Cisco-Meraki by MAC OUI prefix or vendor-specific IE pattern. Contextual recon — establishes the vendor / product family for the rest of the assessment.

Impact: Drives vendor-specific test selection (iPSK testing, Systems Manager enrollment recon, Meraki-specific firmware advisories cross-reference).

Remediation: No action required — informational only. Cross-reference with the Meraki advisory feed for the identified product line to verify the firmware in use is patched against known issues.

Effort: n/a

INFO AETHER-MERAKI-002 — Meraki Beacon IE Captured for Fingerprinting

Description: The vendor-specific Information Element from a Meraki AP beacon was captured for offline fingerprinting / firmware-version identification. Most modern Meraki firmware reveals its major version family in beacon IE patterns.

Impact: Drives the next finding (Meraki firmware version) by allowing offline cross-reference against Cisco's firmware advisory database.

Remediation: No action — informational only.

Effort: n/a

INFO AETHER-MERAKI-003 — Multiple SSIDs On Shared Physical AP

Description: Multiple SSIDs share a common BSSID prefix, indicating they are virtual SSIDs on the same physical Meraki AP radio. If any single SSID's security is weaker than the others, an attacker who compromises the weak SSID may pivot to wireless infrastructure shared with the cert-auth SSIDs.

Impact: Informational on its own; gains weight when paired with successful attacks against any of the listed SSIDs. Useful context for VLAN-isolation testing (an adjacent PSK SSID succeeding combined with shared-AP infrastructure is a HIGH risk path).

Remediation: Verify VLAN isolation between all SSIDs on the same physical AP. Test from the weakest SSID to ensure no lateral movement is possible to the cert-auth segment.

Effort: n/a

INFO AETHER-MERAKI-004 — Meraki Systems Manager Domain Referenced in Client Traffic

Description: Client DHCP/DNS probe analysis observed references to meraki.com, air-marshal.meraki.com, or Meraki Systems Manager enrollment URLs. Confirms Meraki cloud management is in use and SM-enrolled devices are present.

Impact: Provides context for the cloud-management plane that complements the device-side wireless assessment. SM-enrolled devices have cert-based EAP-TLS supplicant configurations distributed via the SM profile.

Remediation: No action — informational only.

Effort: n/a

HIGH AETHER-IPSK-001 — iPSK MAC-Inheritance Test Succeeded

Description: On a Meraki SSID using Identity PSK (iPSK), the test confirmed that authentication is keyed primarily on MAC address — spoofing a known iPSK-issued MAC inherits the PSK assigned to the original device.

Impact: An attacker who observes a single legitimate device's MAC address can clone the MAC and authenticate to the SSID using the inherited PSK without ever cracking it. Effectively eliminates the per-device PSK assumption.

Remediation: Combine iPSK with additional binding signal (device cert via SM, RADIUS-issued cookie). Validate that the Meraki dashboard's iPSK assignment policy includes RADIUS-based MAC validation rather than local-DB MAC-only lookup.

Effort: Moderate

NIST 800-53: IA-2, IA-3

MEDIUM AETHER-IPSK-002 — iPSK Suspected — Per-Client PMKID Variance Observed

Description: Multiple clients associated to the same WPA2-PSK SSID exhibited distinct PMKIDs in captured EAPOL frames. This is the structural signature of Identity PSK (each client has its own PSK and therefore its own PMK). Distinguishes iPSK from standard shared-PSK WPA2.

Impact: Confirms an iPSK deployment is in use. If unique-per-device PSK assignment is the security posture being relied on, the MAC-inheritance test (AETHER-IPSK-001) is the natural follow-on validation.

Remediation: No action — informational confirmation. Use as supporting evidence for AETHER-IPSK-001 and AETHER-IPSK-003 findings.

Effort: n/a

MEDIUM AETHER-IPSK-003 — iPSK SSID Deployed Alongside Cert-Auth SSID on Same Physical AP

Description: An iPSK SSID shares a physical AP with a cert-authenticated SSID. The wireless infrastructure security posture is now bounded by the WEAKER of the two — if VLAN isolation is misconfigured, compromise of iPSK leads to access in the cert-auth segment's broadcast domain.

Impact: The cert-auth SSID's strong authentication is only as effective as the network segmentation it sits behind. iPSK-derived access can become lateral movement opportunity.

Remediation: Verify per-SSID VLAN isolation, switchport ACLs, and inter-VLAN routing controls. Conduct a post-authentication test from the iPSK SSID specifically looking for visibility of cert-auth-segment hosts.

Effort: Moderate

MEDIUM AETHER-SPLASH-001 — Captive Portal Session Bound To MAC Alone

Description: The captive portal (splash page) session is identified by the client's MAC address alone, with no secondary binding. An attacker who observes a legitimate authenticated client's MAC can spoof it to inherit the splash session.

Impact: An attacker bypasses the splash page entirely (no terms acceptance, no auth, no rate limiting) by cloning an authenticated MAC. Splash-mediated controls (time limit, bandwidth quota, terms enforcement) are defeated.

Remediation: Bind the splash session to additional signals: short-lived cookie, IP+MAC composite, or RADIUS-issued session token. Set short session timeouts and require re-auth periodically.

Effort: Moderate

HIGH AETHER-SPLASH-002 — Captive Portal DNS Bypass — External Resolution Pre-Auth

Description: From the guest SSID before completing the captive portal sign-in, DNS queries to external resolvers (e.g., 8.8.8.8) succeed. The captive portal does not enforce a DNS hijack / sinkhole policy on pre-auth clients. An attacker can tunnel DNS-encoded data through the network without authentication.

Impact: Pre-auth DNS access allows exfiltration via DNS tunneling, covert C2, and abuse of the network's bandwidth without registration. Defeats time-based and quota-based controls.

Remediation: Hijack all DNS queries from pre-auth clients to the captive portal's resolver. Drop port 53 traffic at the AP/firewall for un-authenticated clients except to the captive portal's enforced resolver. Block DNS-over-HTTPS hostnames pre-auth as well.

Effort: Moderate

NIST 800-53: SC-7

MEDIUM AETHER-SPLASH-003 — Captive Portal ICMP Bypass — External Echo Pre-Auth

Description: ICMP echo (ping) to external hosts succeeds before splash auth completion. While less exploitable than DNS bypass, this confirms that L3 firewall rules don't strictly enforce the pre-auth state.

Impact: Useful as a network reachability probe by unauthenticated users; minor abuse vector for ICMP-based covert channels.

Remediation: Drop ICMP from pre-auth clients destined outside the splash page's local subnet at the AP/firewall.

Effort: Moderate

LOW AETHER-SPLASH-004 — Captive Portal Reveals AP / Vendor Information

Description: HTTP headers of the captive portal redirect or splash page contain identifying information about the AP vendor, firmware version, or Meraki dashboard endpoint. Useful reconnaissance.

Impact: Reveals deployment-specific information that an attacker uses to cross-reference vendor advisories and target known firmware vulnerabilities.

Remediation: Strip vendor and version headers from the splash page's HTTP responses where possible. Use a custom branded splash page that does not reveal the underlying Meraki splash framework.

Effort: Moderate

INFO AETHER-INFO-AP — AP Observed and Cataloged

Description: An access point was observed during the wireless intelligence phase and recorded with its BSSID, SSID, channel, encryption, authentication type, signal power, and vendor classification.

Impact: Per-AP attribution for engagement evidence. Every other AP-targeting finding cross-references this catalog entry.

Remediation: No action — informational only.

Effort: n/a

INFO AETHER-INFO-CLIENT — Client Device Observed and Cataloged

Description: A client (STA) device was observed associated to a target AP or actively probing for SSIDs. Catalogued with MAC, vendor OUI, associated BSSID/SSID, and any SSIDs the client has been probing for.

Impact: Per-client attribution for engagement evidence. Drives the probe-harvest and Karma-attack analyses.

Remediation: No action — informational only.

Effort: n/a

INFO AETHER-INFO-VENDOR — Vendor Identified via MAC OUI

Description: The MAC OUI of an observed device was matched against the IEEE OUI database to identify the manufacturer and product line.

Impact: Provides asset-inventory context. Concentrations of specific vendor MACs help identify managed device fleets vs. BYOD.

Remediation: No action — informational only.

Effort: n/a

INFO AETHER-INFO-AUTH-TYPE — Authentication Type Classified

Description: The advertised encryption and authentication mode for an SSID was classified into one of: OPEN, WEP, WPA2-PSK, WPA2-Enterprise, WPA3-SAE, WPA3-Enterprise, WPA2/WPA3-Transition, or iPSK-Suspected.

Impact: Drives test selection for each SSID. Engagement reports the auth type for every observed SSID as part of the wireless inventory.

Remediation: No action — informational only. Review the auth type distribution across the deployment for consistency with the documented security architecture.

Effort: n/a

INFO AETHER-INFO-CHANNEL — Channel Allocation Observed

Description: An AP's operating channel was observed during scanning. Recorded for spectrum-planning analysis and for documentation of the engagement scan coverage.

Impact: Supports physical-deployment understanding (channel reuse, congestion, 2.4 vs 5 GHz coverage).

Remediation: No action — informational only.

Effort: n/a

INFO AETHER-INFO-PROBE — Client Probe Request Observed

Description: A client device sent a probe request asking for a specific SSID. Probed SSIDs reveal the client's Preferred Network List — useful for Karma attacks and for assessing employees' personal device-to-corporate-network proximity.

Impact: Builds the input set for Karma-style opportunistic AP responses. Reveals corporate device usage patterns (e.g., probes for home networks, conference networks, partner-org networks).

Remediation: Configure clients to disable probe requests for hidden/saved networks where possible. On Windows: Use 'Connect even if the network is not broadcasting' = OFF. On iOS / Android: enable MAC randomization for unsaved networks (default in current OS versions).

Effort: n/a

HIGH AETHER-INFO-MIXED-AUTH — Inconsistent Authentication Modes Across APs for Same SSID

Description: An SSID was observed broadcast across multiple BSSIDs with materially different authentication modes. Example: the same SSID name advertised by some APs with WPA2-Enterprise (802.1X) and by other APs with WPA2-PSK. An attacker chooses the weakest AP for that SSID, performs the attack appropriate to that weak mode (PSK crack, evil twin, etc.), and the stronger configuration on the other APs offers no protection because the client connects to whichever AP for that SSID has the best signal.

Impact: Defeats the security boundary intended by the stronger auth mode. On a WPA2-Enterprise SSID where one AP is misconfigured as WPA2-PSK, an attacker captures and offline-cracks the PSK once and gains access equivalent to whatever the strongest AP provided. Common during incomplete WPA3 migrations, after AP swaps, or when a rogue AP intentionally clones the SSID with weaker auth to harvest credentials.

Remediation: Standardise authentication mode across every AP broadcasting a given SSID. The strongest configured auth mode should be the only mode — a single AP using a weaker mode (e.g. WPA2-PSK on an SSID otherwise served by WPA3-SAE or WPA2-Enterprise) means an attacker can target the weaker AP for the same SSID name and bypass the stronger protections entirely. Audit the WLAN controller's per-AP policy bindings; verify intentional WPA2/WPA3 transition mode is configured uniformly rather than per-AP.

Effort: Moderate

CVSS Vector: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

MITRE ATT&CK: T1557 (Credential Access), T1557.004 (Credential Access)

NIST 800-53: AC-18, SC-8, SC-13

PCI DSS 4: 4.2.1, 11.3.2

INFO AETHER-INFO-EAP-IDENTITY — EAP Outer Identity Observed

Description: The outer (cleartext) EAP-Response/Identity value sent by a client at the start of an EAP exchange was observed. Recorded for analysis (see AETHER-EAPTLS-001 for the user-realm-format-leak grading).

Impact: Provides per-EAP-transaction attribution for the identity-leak findings.

Remediation: No action — informational. Cross-reference with AETHER-EAPTLS-001 for the grading outcome.

Effort: n/a