WPA2 handshake attacks explained — how to keep your wireless network safe

Originally published in 2016 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

How the WPA2 handshake works (and why attackers target it)

When a device joins a WPA2 network, it performs a four-way handshake with the access point to derive session encryption keys from the shared passphrase. In WPA2-Personal, that passphrase is the only secret protecting the network — so the handshake is the attacker's prime target. Conceptually, the attack works like this: the attacker passively captures the handshake, then takes it offline and guesses passphrases against it at high speed. Because the guessing happens offline, the router can't slow the attacker down with rate limiting. If the passphrase is short, common, or predictable, it will fall.

Why deauthentication often accompanies handshake attacks

An attacker who wants a fresh handshake may forge deauthentication frames to force a connected client to rejoin the network, generating new handshake traffic to capture. So a handshake attack frequently starts with the disruption pattern described in our deauthentication article — client drops and reconnects clustered in time.

Signs of a handshake-capture attack in your logs

• A deauthentication flood immediately followed by client reconnects — the classic capture pattern.
• An unfamiliar client device that stays associated without normal traffic (a passive sniffer lingering nearby).
• Repeated reconnection cycles affecting a single client while others remain stable.
• WIDS alerts for deauth floods or unknown stations probing your AP.

How to defend your network

• Move to WPA3 if your hardware supports it. WPA3's SAE handshake resists offline dictionary attacks — captured handshake data is useless for guessing.
• Use a long, random, unique passphrase (20+ characters, generated not memorized) on WPA2-Personal networks. This is the single highest-impact defense on older hardware.
• Enable protected management frames (802.11w) to make the deauth-forced-reconnect trick far harder.
• Disable WPS PIN mode, which offers an independent brute-force path that bypasses passphrase strength.
• Monitor your airspace for deauth floods and rogue stations; treat repeated unexplained client drops as suspicious.
• For businesses: use WPA2/WPA3-Enterprise with 802.1X and per-user credentials, which eliminates the shared-passphrase attack surface entirely.

Authorization disclaimer

All security testing must only be performed on networks and devices you own or are explicitly authorized to assess. Capturing handshakes or attempting to recover passwords for networks you don't own is illegal in most jurisdictions.

Wi-Fi deauthentication attacks: what they are and how to protect your network

Originally published in 2016 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

What is a deauthentication attack?

Wi-Fi networks use management frames — small control messages like "deauthenticate" and "disassociate" — to manage connections between clients and access points. In older protocol versions these frames are neither authenticated nor encrypted, so an attacker within radio range can forge them. By sending spoofed deauthentication frames that appear to come from the access point (or from a client), the attacker forces devices to drop their connection, causing denial of service or repeated reconnections.

Why attackers use them

Deauthentication is rarely the end goal. Conceptually, attackers use it for two things: disruption (knocking users off a network, sometimes repeatedly, as harassment or sabotage) and facilitation — forcing clients to reconnect so the attacker can capture fresh handshake traffic or nudge users toward a rogue access point. What may look like "just kicking someone off Wi-Fi" is the same mechanism used in credential-theft attacks.

What deauth attacks look like in your logs

• A flood of deauth/disassoc frames in access point logs — far more than normal roaming would generate.
• Repeated client drops and reconnects clustered in time, especially affecting many devices at once.
• Source MACs that don't match any associated device, or frames attributed to the AP that arrive at abnormal rates.
• Wireless IDS alerts for "spoofed management frames" or deauthentication floods, if a WIDS is deployed.

How to protect your network

• Enable Protected Management Frames (802.11w) on your access points and clients — this cryptographically protects deauth and disassoc frames so forged ones are ignored. WPA3 mandates it; many WPA2 devices support it as an option.
• Deploy wireless intrusion detection (or at least monitor AP logs) so deauth floods trigger alerts instead of going unnoticed.
• Keep firmware current on routers and access points to ensure management-frame protections are actually available and patched.
• Use strong authentication (WPA3, or WPA2 with a long unique passphrase) so that even forced reconnections don't expose you to handshake-guessing attacks.
• For organizations: consider wireless IPS with automatic containment of rogue APs and RF containment policies for repeated deauth sources.

Authorization disclaimer

All security testing must only be performed on networks and devices you own or are explicitly authorized to assess. Transmitting deauthentication frames against networks you don't own disrupts other people's connectivity and is illegal in most jurisdictions.

Wi-Fi attacks explained (WEP/WPA/WPA2): how to secure your wireless network

Originally published in 2016 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Why Wi-Fi security matters

Wireless networks broadcast your data through the air. Without proper protection, anyone nearby with an antenna can listen in or attempt to join your network. The encryption protocol your router uses — WEP, WPA, WPA2, or WPA3 — determines how hard that is. Understanding each generation helps you make sure your network is on the right one.

The Wi-Fi encryption generations

WEP — broken and abandoned

Wired Equivalent Privacy (WEP) was the first Wi-Fi security protocol, specified in the 802.11b standard. It uses static encryption keys that never change, and cryptanalytic flaws in the protocol let an attacker recover the key simply by observing enough network traffic. WEP should never be used for anything — treat any device still using it as compromised.

WPA — an interim fix

WPA was introduced as a stopgap while the full 802.11i standard was finalized. It added per-packet keys via TKIP, a major improvement over WEP, but it too has known weaknesses. WPA/TKIP is obsolete and should be disabled.

WPA2 — the long-standing baseline

WPA2 implements the full IEEE 802.11i standard using AES-based CCMP encryption. It has been mandatory on new certified devices since 2006 and remains widely deployed. WPA2 with a strong passphrase is still reasonable, but weak pre-shared keys are vulnerable to offline dictionary attacks, and WPA2 alone does not protect management frames from disruption attacks (see below).

WPA3 — the current best practice

WPA3 replaces the pre-shared key handshake with SAE (Simultaneous Authentication of Equals), which resists offline dictionary attacks, and it mandates protected management frames. If your hardware supports it, WPA3 (or WPA3 transition mode) is what you should be using.

How attackers approach wireless networks, conceptually

Attackers passively capture wireless traffic and look for weak protocols (WEP, WPA/TKIP), weak passphrases susceptible to offline guessing, or client devices willing to connect to a lookalike "evil twin" access point. They may also inject management frames — such as deauthentication packets — to disrupt legitimate connections, which can cause denial of service or pressure clients to reconnect to an attacker's access point.

Signs of wireless attacks in your logs

• A surge of deauthentication or disassociation frames in access point logs or a wireless IDS (WIDS).
• An access point advertising your SSID that isn't yours (rogue or evil-twin AP).
• Clients repeatedly dropping and reconnecting, especially clustered in time.
• Unrecognized MAC addresses appearing in association logs.

How to secure your wireless network

• Use WPA3 where possible, otherwise WPA2 with AES (never WEP or WPA/TKIP).
• Use a long, unique passphrase (20+ characters) that can't be guessed; never reuse the ISP-default key.
• Disable WPS on the router — PIN-based WPS has long-standing brute-force weaknesses.
• Enable protected management frames (802.11w) if your equipment supports it, to resist deauthentication-based disruption.
• Segment your network: use a separate guest SSID with client isolation for visitors and IoT devices.
• Keep firmware updated on routers and access points to patch known protocol flaws.
• Monitor your airspace with wireless intrusion detection or at least periodic scans for rogue access points using your SSID.

Authorization disclaimer

All security testing must only be performed on networks and devices you own or are explicitly authorized to assess. Attempting to intercept or access someone else's Wi-Fi traffic without permission is illegal in most jurisdictions.

SQL injection defense, part 3: detection, logging, and ongoing protection

Originally published in 2016 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. The vulnerable-site target list this post once contained has been removed. This is the third installment of our SQL injection defense series — parts 1 and 2 covered finding and fixing injection flaws; this part covers what comes after the fix: detection, logging, and ongoing protection.

Why detection still matters after you've fixed the code

Parameterized queries eliminate SQL injection at the source — but no codebase stays fixed by accident. New code ships, dependencies change, legacy endpoints resurface, and regressions happen. A detection layer catches what secure coding misses and tells you when someone is actively probing your applications, which is intelligence worth having.

Log what matters

You can't detect what you don't record. Make sure these are captured and centralized:

• Full request details on database-backed endpoints: URL, parameters, user agent, source IP, and session identity.
• Database error events with the failing query context (logged server-side, never returned to the user): syntax errors, type-conversion failures, and permission denials.
• Query performance telemetry: execution time per query pattern. Time-based blind injection shows up as anomalous delays.
• Authentication and session events tied to the same requests, so you can correlate a probe with an account.
• WAF/edge block events — even blocked attempts are signal; a rising block rate against one endpoint means someone is working on it.

Build alerts that fire on real attacks

Turn the telemetry into detection rules in your SIEM:

• Error-rate anomalies: alert when database errors spike on an endpoint relative to its baseline — classic injection probing.
• Signature matches: flag requests containing SQL keywords, comment sequences, or stacked-query syntax in parameters that should never contain them. Tune to your application's normal input to control false positives.
• Behavioral anomalies: a single client cycling through many parameter values, unusually large result sets served to low-privilege sessions, or response-time patterns consistent with blind extraction.
• Known-bad correlation: match source IPs and request fingerprints against threat intelligence feeds of active scanners.

Ongoing protection: keep the fix fixed

• Test in legal labs continuously: DVWA, bWAPP, and WebGoat remain the right places to train your team and validate scanner coverage — never someone else's production site.
• Scan every release: integrate SAST and DAST into CI/CD so new injection flaws are caught before deployment, not after.
• Re-audit data access: periodically review database account privileges — least privilege drifts over time as features are added.
• Keep the WAF tuned: update rule sets, review what's being blocked, and investigate repeated blocks rather than ignoring them.
• Run tabletop exercises: walk through a "we're being probed" scenario so your team knows who triages the alert, who checks the code, and when to escalate to incident response.

Measure it

Track mean time to detect probing, the number of injection findings per release, and the percentage of database-backed endpoints covered by alerting. If those numbers improve quarter over quarter, your program is working.

Series wrap-up

Part 1 taught you to find injection flaws in your own applications using safe labs. Part 2 covered remediation — parameterized queries, least privilege, and layered controls. This part closes the loop: log the right things, alert on the right patterns, and keep testing so the flaw stays fixed. SQL injection is a solved problem technically; the remaining work is operational discipline.