Wi-Fi: security in depth

Wireless security without the gloss: how WPA2’s handshake and WPA3 (SAE) really work, PMF, enterprise 802.1X/EAP authentication, captive portals and NAC, real attacks (evil twin, deauth, handshake capture, KRACK, WPS) and defense (WIPS, rogue-AP detection, monitoring, segmentation).

Lesson 1: Why Wi-Fi needs more

The attacker is in range

From course 11 you know the key tax of wireless: a radio signal does not stop at your wall – it spills into the hallway, the street and the parking lot. That flips the whole logic of security. With a cable an attacker has to physically plug in, pass reception, run a cable. With Wi-Fi it is enough to be in range: they sit with a laptop in a car outside and are already ‘on the wire’ – listening to the air passively, transmitting nothing, so you have no way to detect them. And since the air is a shared medium, anyone nearby can capture every frame to a file and analyze it later at home in peace. This course therefore takes Wi-Fi security in depth: not ‘turn on WPA2 and done’, but what really happens during the handshake, why a shared password is not enough in a company, and what real attacks and defenses look like. The simulator does not model these attacks (they are conceptual, like advanced security in course 8) – but everything we show builds on what the simulator can do: guest VLANs, firewall zones, IDS/IPS.

Step by step

Every frame from the phone flies through the air – and a radio signal does not stop at the wall.
Anyone in range listens passively and records the air to a file – transmits nothing, cannot be caught.
So Wi-Fi needs multiple layers of defense – encryption, authentication, isolation and detection. That is this course.

What a shared password doesn’t solve

WPA2-PSK from course 11 has one quiet weakness you overlook at home but which matters greatly in a company: everyone shares one password. Think about what that means in practice. When twenty people know the password, practically anyone knows it – an employee leaves and takes it along; it gets stuck on a monitor; it is sent over chat. Revoking it works only one way: change it for everyone at once and redistribute it to all devices – a pain nobody does, so the password stays unchanged for years. Worse: a shared password tells you nothing about who actually connected. The log says ‘someone who knew the password’ was on the network – not whether it was Anna, Peter, or a stranger’s laptop with a leaked password. You cannot revoke access for one person, nor give them a different VLAN than a colleague. A shared password thus solves only ‘let in whoever knows the secret’ – and nothing more. A company needs identity per person: individual accounts, the ability to revoke one, and a trail of who was connected when. That is exactly what 802.1X brings (lesson 3).

Step by step

WPA2-PSK: one password for everyone. Twenty people know it → practically anyone knows it.
The log does not tell who was on the network – just ‘someone who knew the password’. You cannot revoke one.
A company needs an account per person: revoke one, give them their own VLAN, keep a who/when trail. That is 802.1X (lesson 3).

The layers of Wi-Fi defense

Before we dive into details I want to give you a map, so in the coming lessons you know where things belong. Wi-Fi security is not one switch but several independent layers, each addressing a different kind of attack – so they are not interchangeable. (1) Encryption (WPA2/WPA3) protects the content of frames against eavesdropping in range. (2) Authentication (PSK or 802.1X/EAP) decides who may enter and how strongly they prove it. (3) Management-frame protection (PMF) prevents forged deauth attacks. (4) Isolation and segmentation (guest VLAN, client isolation – from courses 3 and 11) limits where a connected device can reach. (5) Detection and operations (WIPS, logs, monitoring) watches what happens in the air and reports a rogue AP or an attack. The key idea of this whole course: no single layer is enough. Strong encryption will not help if the client joins a fake AP; great authentication will not stop eavesdropping if PMF is missing. Secure Wi-Fi = the layers together, exactly like defense in depth from course 8.

Step by step

Encryption (WPA2/WPA3) hides frame content from eavesdropping in range. That is lesson 2.
Authentication (PSK or 802.1X) decides who may enter. PMF protects management frames. Lessons 2 and 3.
Isolation (guest VLAN, client isolation from courses 3/11) limits where a connected device reaches. Lesson 4.
Detection (WIPS, logs) watches the air. The point: no layer alone suffices – only all together. Lessons 5 and 6.

▶ Open in the simulator

Lesson 2: Encryption in depth

WPA2: the four-way handshake

When course 11 said ‘the password is cracked from a captured handshake’, you may have wondered: what is that handshake? Let us take it step by step, because half of the attacks rest on it. First, from your password and the network name (SSID) a slow function, PBKDF2, derives the PMK (Pairwise Master Key) – a master key that is always the same for a given password+SSID. The password itself never travels over the air. Instead a four-way handshake runs: (1) the AP sends the client a random number, the ANonce; (2) the client generates its own SNonce, computes the PTK (Pairwise Transient Key – a key just for this session) from the PMK + both nonces + MAC addresses, and sends the SNonce together with a MIC (a check signature proving it knows the PMK); (3) the AP computes the same and confirms; (4) the client replies with an ACK. Only then does the PTK encrypt the real traffic – and it is different for every connection, even though the password stays the same. The beauty is the password is never sent; the ugliness is the whole handshake flies in the open and an attacker can capture it. Why that matters is shown by the next module.

Step by step

From password and SSID, PBKDF2 derives the PMK. The password itself never flies over the air.
Message 1: the AP sends the client a random ANonce. The handshake begins.
Message 2: the client computes the PTK (from PMK + nonces + MACs) and sends SNonce with the MIC signature.
Messages 3 and 4: the AP confirms, the client ACKs. From now the PTK encrypts traffic – different per connection.

Capturing the handshake and the offline attack

Now the thrilling part: why is capturing the handshake enough for an attacker? Recall what flies in it – the ANonce, SNonce, MAC addresses and above all the MIC (a signature proving knowledge of the PMK). An attacker sitting in range sees and stores it all. They do not know the password, but they have an idea: guess it offline. Take a word from a dictionary, compute its PMK, from the PMK and the captured nonces/MACs compute the PTK, from that build a MIC – and compare it with the captured one. A match? The password is guessed. No match? Try the next word. And here is the point: this runs on their computer, without the AP – so at millions of tries a second, on a GPU easily billions. No AP stands in the way, no ‘three wrong and it locks’. A short password (‘summer2024’) falls in seconds; a dictionary word too. What does not fall? A long, random, meaningless password – there the attacker would compute longer than the universe lasts. An even worse, client-free variant is the PMKID attack: on some APs the attacker requests the needed material by starting an association themselves and gets it straight from the AP’s first frame – without any legitimate client having to be on the network. Takeaway: with WPA2-PSK the length and randomness of the password decide, nothing else.

Step by step

The handshake (nonces, MACs, MIC) flies through the air in the open. An attacker in range stores it to a file.
At home the attacker tries passwords offline – computes a MIC and compares. Without the AP → millions of tries a second.
A short or dictionary password falls in seconds. The PMKID attack manages even without a legitimate client.
The only WPA2-PSK defense: a long random password. With 16+ random characters it would take the attacker longer than the universe lasts – practically never.

WPA3 and SAE

The offline attack from the last module has one cause: from a single captured handshake you can try arbitrarily many passwords at home on a computer. WPA3 cuts this cause at the root. It replaces the old PSK handshake with the SAE key exchange (Simultaneous Authentication of Equals, nicknamed Dragonfly). The essence: every attempt to guess the password requires a fresh live interaction with the AP – it cannot be computed blindly at home. So the attacker must try online, through the AP, which cuts them off and slows them after a few wrong tries. Ten million guesses a second turns into a few tries a minute – the difference between ‘over a weekend’ and ‘in a thousand years’. WPA3 also adds forward secrecy: even if the attacker obtains the password later (say someone leaks it), previously captured traffic stays unreadable – each session had its own separate key you cannot re-derive from the password – the key is built not just from the password but also from a one-time random exchange between the two sides, which never repeats. In fairness: the Dragonblood research (2019) found in SAE not only specific vendors’ bugs but also side-channels in the then-current design (the ‘hunting-and-pecking’ method leaked the password through timing and cache). So it was neither purely the principle nor purely the vendors – part was in the specification and was fixed only by moving to a newer method (hash-to-element). The lesson: even a good principle needs to mature; today’s WPA3 is patched. The practical advice stays from course 11: WPA3 where possible, otherwise WPA2 with a long password.

Step by step

Reminder: with WPA2 a single captured handshake lets passwords be tried at home without limit.
WPA3 (SAE): each password attempt needs a live interaction with the AP → offline cracking is gone.
Forward secrecy: even if the password later leaks, previously captured traffic stays unreadable.
Dragonblood (2019): besides vendor bugs, also a side-channel in the then-current SAE design – fixed by a new method (hash-to-element).

PMF: protecting management frames

So far we encrypted data. But Wi-Fi also sends management frames – ‘I am joining’, ‘I am leaving’, beacons – and those were historically unencrypted and unsigned. That is a hole one of the most common attacks leans on: deauthentication. The attacker sends a forged management frame ‘the AP is disconnecting you’ with the AP’s address spoofed – and the client obediently drops off Wi-Fi, because it has no way to tell the frame was not from the AP. Repeat it every second and the victim is permanently cut off; or it forces a reconnect during which a fresh handshake is captured (a link to the last lesson) or the victim is pushed onto the attacker’s fake AP (lesson 5). The fix is PMF (Protected Management Frames, 802.11w): it cryptographically signs robust management frames – deauth, disassoc and robust action frames – so a forged deauth is discarded by both AP and client, having no valid signature. Mind the boundary: PMF does not protect beacons and probe responses (they fly before a client is even associated); those are covered by Beacon Protection in WPA3. WPA3 enforces PMF (mandatory), WPA2 supports it optionally (and it should be turned on). Without PMF the deauth attack is trivial; with PMF it stops working. It is a small layer with a big impact – exactly why it belongs in the ‘layers of defense’ from lesson 1.

Step by step

Wi-Fi also sends management frames (join, leave). Historically they fly unsigned.
Deauth attack: the attacker forges an ‘AP disconnects you’ frame – the client drops. It can cut off or force a reconnect.
PMF (802.11w) signs robust management frames – a forged deauth has no valid signature, the client discards it. (Beacons are covered only by WPA3 Beacon Protection.)
WPA3 enforces PMF, WPA2 supports it optionally – and you should turn it on. A small layer, a big impact.

▶ Open in the simulator

Lesson 3: Enterprise authentication: 802.1X and EAP

802.1X and RADIUS

In lesson 1 we said a company needs identity per person, not a shared password. The tool that does it is 802.1X – a general framework for port-based authentication (it works the same on a switch’s wired port and on Wi-Fi). It has three roles, memorize them, they will recur: the supplicant (the applicant = your laptop/phone), the authenticator (the doorman = the AP or switch) and the authentication server (the referee = the RADIUS server, where the accounts live). The trick is that the AP itself does not decide who may enter – it only relays the login between the client and RADIUS and waits for the verdict. Until the verdict arrives it keeps the port closed: it passes only the authentication itself, nothing else (no DHCP, no data). The authentication messages are carried by the EAP protocol – think of it as an envelope: EAP itself just transports the authentication, the concrete way of proving identity (the ‘method’) is chosen inside – methods are the next module. When RADIUS says ‘yes, it is Anna’, the AP opens the port and only then comes the classic DHCP and traffic. The advantage over PSK is huge: the account is per person (if Anna leaves, you just delete her account, no password change for anyone), and the RADIUS log has who/when connected. This mode is called WPA2/WPA3-Enterprise (as opposed to -Personal, which is PSK).

Step by step

The supplicant (client) contacts the authenticator (AP). But the AP does not decide – it keeps the port closed.
The AP only relays the login (EAP) to the RADIUS server and waits for the verdict. It judges nothing itself.
RADIUS verifies the account and returns ‘yes, Anna’. Only now does the AP open the port.
Port open → classic DHCP and traffic. The account is per person → the log has who/when. This is WPA2/3-Enterprise.

EAP methods: TLS, PEAP, TTLS

802.1X says ‘authenticate via RADIUS’, but with what does the client prove itself? Here comes EAP – not one method but a whole family; you must know three. EAP-TLS is the strongest: both sides have a certificate (client and server) and prove to each other – no passwords, just cryptography. The price for the strength is PKI: you must issue and manage a certificate on every device, which is demanding. So PEAP or EAP-TTLS are often chosen: only the server has a certificate, and inside an encrypted TLS tunnel the client logs in with a username and password (typically via MSCHAPv2). The advantage: passwords deploy easily (users know them), certificates are handled only on the server. That is the key difference: EAP-TLS = a certificate on both sides; PEAP/TTLS = a certificate on the server + a password in the tunnel. But mind the trap we cover in the next module: with PEAP/TTLS everything hinges on the client verifying the server’s certificate – otherwise it sends the password to anyone posing as the server. In practice: large firms aim for EAP-TLS (most secure but costly to manage), smaller ones pick PEAP/TTLS for simplicity – always, though, with server verification set up correctly.

Step by step

EAP-TLS: client and server both have a certificate and prove to each other. Strongest – no passwords.
The price of strength: PKI – a certificate must be issued and managed on every device. Demanding.
PEAP/TTLS: only the server has a certificate, the client sends username+password inside an encrypted TLS tunnel. Easier to deploy.
The PEAP/TTLS trap: all hinges on the client verifying the server certificate – else it sends the password to a fraud (next module).

Verifying the server’s identity

This module is short but the most important in the whole lesson – it is the most common real mistake in enterprise Wi-Fi. With PEAP/TTLS the client proves itself with a username and password inside a TLS tunnel. The tunnel is safe only if the client builds it to the right server. And here is the catch: if the client does not verify the certificate of the RADIUS server (or has ‘accept any’ ticked), it builds the tunnel to anything posing as the server. So an attacker sets up a fake AP + fake RADIUS with the same SSID, the client connects, opens a tunnel to the attacker’s server and sends it the username and password (or the MSCHAPv2 challenge the attacker cracks offline). This is called the PEAP attack and it is frighteningly effective, because the victim notices nothing – the login ‘succeeds’ normally. The defense is clear and must be enforced centrally: the client must be set to know which specific certificate (which CA and which server name) it trusts – and refuse any other. It must not depend on a user ‘clicking away a warning’. That is why with EAP-TLS (where both sides verify by certificate) this problem does not arise – and why large firms aim there. Remember: with PEAP/TTLS, server verification is not optional, it is the entire security.

Step by step

Correct: the client verifies the RADIUS certificate and builds the tunnel only to the right server. Then the password is safe.
The attacker sets up a fake AP and RADIUS with the same SSID. A client not verifying the server connects to it.
The client opens a tunnel to the attacker’s server and sends it the username and password. It notices nothing – the login ‘succeeds’.
Defense: the client has it centrally enforced which CA and server name to trust – refusing others. Not up to the user.

Dynamic VLANs and accounting

802.1X can do two more things that make it an operational tool, not just a doorman. The first is dynamic VLAN assignment. Recall course 3: VLANs separate worlds (employees, guests, IoT). With PSK you would have to broadcast a different SSID per VLAN. With 802.1X one SSID suffices, and RADIUS, along with the verdict ‘yes, it is Anna’, also returns ‘and she belongs to VLAN 10 (employees)’, while a temp is sent to VLAN 30. The AP places the client straight into the right segment – by identity, not by the network they joined. That is elegant: one Wi-Fi, yet everyone ends up where their role belongs. The second thing is accounting: RADIUS keeps a record of who, when, from where and how long they were connected and how much data they moved. That is gold for operations and security – in an incident (lesson 6) you pinpoint exactly which account and device was on the network at the time, and you feed the data into a SIEM (course 8) for correlation. All of this is beyond a shared password – which is why 802.1X is the enterprise standard. The simulator does not model dynamic VLANs via RADIUS, but you build the VLANs themselves and their isolation exactly as in course 3.

Step by step

RADIUS returns not just ‘yes’ but also a VLAN by identity: Anna → VLAN 10, a temp → VLAN 30.
The AP places the client into the right segment by role – one SSID suffices. You know VLANs and isolation from course 3.
RADIUS keeps accounting: who, when, from where, how long, how much data. Gold for incidents and SIEM (course 8).

▶ Open in the simulator

Lesson 4: Guest, captive portal and NAC

Guest isolation in depth

You know the guest VLAN from courses 3 and 11: a guest reaches only the internet, not your devices. Now let us take it in depth, because ‘I have a guest SSID’ does not yet mean ‘I have it secured’. The first layer is separation into its own VLAN/segment – the guest cannot see the NAS, printer, cameras. The second is client isolation: guests cannot see each other either (so a stranger’s infected laptop does not infect the laptop at the next table). But there is a third, often forgotten: the guest VLAN itself needs its own firewall rules. If you merely ‘separate’ it but let it out to anything, a guest can scan the internet, send spam from your IP, or reach the management interfaces of your devices if they are reachable from outside. So the guest segment is treated as an untrusted zone (exactly the logic of course 5): default-deny everywhere except ‘out to the web (and only the ports the guest needs)’, no access to internal zones, ideally also a bandwidth limit so a guest cannot grab the whole line. A practical bonus: IoT belongs apart too (smart bulbs, cameras) – they often have leaky firmware and there are many of them, making them an ideal stepping stone. In the simulator you build this isolation literally: a guest/IoT segment + firewall zones + rules, and verify by ping that a guest cannot reach internal devices.

Step by step

Layer 1: the guest is in its own VLAN and cannot see internal devices (NAS, printer, cameras) (Course 3).
Layer 2: client isolation – guests cannot see each other. A stranger’s infected laptop cannot infect a neighbor.
Layer 3: the guest segment = an untrusted zone (Course 5). Default-deny, only out to the web, ideally a bandwidth cap.
Bonus: IoT belongs apart too – cameras and bulbs have leaky firmware and there are many. Verify by ping in the simulator.

Captive portal and the walled garden

You know it from a hotel or airport: you connect to Wi-Fi and a login page pops up – accept the terms, room number, email. That is a captive portal, and it is worth knowing what it really does and does not. Technically it works as a walled garden: until you log in, the network lets you reach only a few places – DNS and the portal itself – and any other site is redirected to the login page. After you log in, the firewall opens the way out for your device. The key warning: a captive portal is NOT encryption. It controls only access (who may go out), but does not protect the content of your traffic in the air – that is the job of WPA2/WPA3, or HTTPS one layer up. A portal on an open network = a neighbor can still eavesdrop on you. The second risk mirrors the evil twin from lesson 5: a fake captive portal is ideal phishing – an attacker sets up a ‘Hotel-WiFi’ network, shows you a faithful login page, and you type in an email and password (or a card number for ‘premium access’). Takeaway: never type a real account password into a captive portal, and as an operator combine the portal with encryption – the portal for access control, WPA/HTTPS for content protection.

Step by step

Walled garden: until you log in, the network allows only DNS and the portal, redirecting the rest.
After login the firewall opens the way out. The portal controls only access – who may reach the internet.
Beware: a portal is not encryption. On an open network a neighbor still eavesdrops – content is protected by WPA/HTTPS.
A fake captive portal on an evil-twin network = phishing. Never type a real account password into it.

Enhanced Open and NAC

Open networks have an eternal dilemma: a password is annoying (a café does not want to hand it out), but without one the air is unencrypted and a neighbor eavesdrops. The fix is Enhanced Open (OWE, Opportunistic Wireless Encryption): the network stays passwordless, but the air is encrypted automatically – each client gets its own key without typing anything. That kills the neighbor’s eavesdropping. Mind the limit: OWE does not solve a fake AP (nobody authenticates, so you can still connect to an evil twin) – it solves only eavesdropping. Still, it is a clear improvement over a classic open network and belongs on every ‘free WiFi’ where devices support it. The second term for your glossary is NAC (Network Access Control) – an umbrella approach whose pieces (identity, device state, access rules) you have actually met all lesson – now they get a common name. NAC does not only ask ‘do you know the password?’ but ‘who are you and in what state?’: it verifies identity (802.1X), checks the device’s posture (updated? antivirus? a company laptop?), and accordingly assigns access – full, limited (internet only), or quarantine. It thus combines authentication, device profiling and dynamic VLANs into one policy. In practice NAC is what holds together ‘guest vs employee vs IoT vs unknown device’ – deciding where to let each. The simulator does not model NAC, but its result – segments and rules – you build exactly as in courses 3 and 5.

Step by step

Enhanced Open (OWE): a passwordless network, but the air is encrypted automatically – no more neighbor eavesdropping.
The limit: OWE does not solve a fake AP (nobody authenticates). It solves only eavesdropping – but that well.
NAC asks not only ‘do you know the password?’ but ‘who are you and in what state?’ – identity (802.1X) + device posture.
NAC then assigns access: full, internet only, or quarantine. The result – segments and rules – you build in the simulator (Course 3/5).

▶ Open in the simulator

Lesson 5: Attacks on Wi-Fi

Evil twin and deauthentication

Now let us go through the named attacks – so you recognize them when you hear about them. The king among them is the evil twin: the attacker sets up an AP with the same SSID as your network, possibly with a stronger signal, and the client connects to it – either on its own (a stronger signal wins, see roaming in course 11) or forced. Once the client is on the evil twin, the attacker sits in the middle (MITM) and sees, redirects and alters the traffic – ideal for a fake captive portal (lesson 4) or stealing a PEAP password (lesson 3). How to ‘force’ the client? Exactly with the deauth attack from lesson 2: the attacker forges an ‘AP disconnects you’ frame, the victim drops off the real network and, while searching, latches onto the stronger twin. See how the attacks form a chain: deauth knocks off → the client searches → the evil twin offers a stronger signal → MITM → phishing/credential theft. And you also see the defense you already know: PMF stops the deauth (the forged frame is discarded), server verification (802.1X) prevents password theft on a fake RADIUS, and WPA3/PMF makes the whole chain much harder. That is why the layers are not academic – this is a scenario that happens in the real world.

Step by step

Starting point: the client is on the real AP2. All fine – for now.
The attacker sends a deauth – the victim drops off the real network and starts searching. (PMF would stop it.)
The evil twin (AP1) has the same SSID and a stronger signal → the client latches on. Now the attacker is in the middle (MITM).
The chain: deauth → search → evil twin → MITM → phishing. Defense: PMF + server verification + WPA3 breaks it.

Rogue AP and KARMA

An evil twin impersonates your network. A rogue AP is a broader term: any unauthorized access point in your network or its vicinity. And mind this – the most common rogue AP is set up not by an attacker but by your own employee: ‘there is no signal in the warehouse, so I brought an AP from home and plugged it in’. That person means well, but has just bypassed your entire defense – their AP hangs on the company cabling, often with no password or WPA2-PSK ‘12345678’, and it is an open back door into the internal network, past the firewall and 802.1X. So rogue APs are hunted systematically (WIPS, lesson 6): the controller compares visible APs against a whitelist and, crucially, finds out whether a foreign AP hangs on your cabling. The second named trick is KARMA. Recall from course 11 that a client remembers known networks and actively sends probe requests (‘is Home here? is Work here? is StarbucksWiFi here?’). A KARMA AP answers ‘yes, that is me!’ to all of these – whatever the client asks for. That catches it even without knowing the SSID: the phone thinks it found its saved network. An important caveat: this reliably works mainly on open saved networks (cafés, hotels) – for a password-protected network the client would have to complete a handshake with the rogue AP, and without the password the attacker has no key, so it does not connect (there an evil twin with the real password, or handshake capture, comes into play instead). The defense? Modern clients limit probe requests and do not auto-join open networks – and you as a user should forget old open networks so your phone stops calling out for them.

Step by step

Rogue AP: most often an employee plugs it in ‘for signal’. It hangs on company cabling = a back door.
That AP bypasses your whole defense – the firewall and 802.1X. Often with no password or ‘12345678’.
KARMA: the AP answers ‘yes, that is me’ to all probe requests. The phone thinks it found a saved network.
Defense: WIPS hunts rogue APs (lesson 6); as a user forget old open networks so the phone stops calling out.

Capture and crack (handshake, PMKID, WPS)

This module ties together what you know from lesson 2 and adds the last piece. There are three ways an attacker reaches a WPA2-PSK password. (1) Handshake capture: the attacker waits (or forces via deauth) for a client to connect, captures the 4-way handshake and tries passwords offline – exactly lesson 2. (2) PMKID: on some APs they need no legitimate client at all – they start an association themselves and get the material in the AP’s very first frame, then crack it offline the same way. Both paths share one thing: the password quality decides. A short or dictionary one falls, a long random one does not. The third path is different and worth remembering: WPS (Wi-Fi Protected Setup) – that ‘convenient’ feature where you connect with an eight-digit PIN or a button press. The eight-digit PIN sounds safe, but a design flaw in WPS means it is verified in halves (the AP reveals separately whether each half of the PIN matches). On top of that the last digit is only a checksum of the others, so there are not 100 million meaningful PINs but 10 million – and the split into halves cuts that to the order of only thousands of tries, so an attacker guesses the PIN in hours regardless of how strong your WPA2 password is. That is why the industry advice is unanimous: turn WPS off. It is a textbook example of a ‘convenience feature’ breaking otherwise strong security. Summary: a long password beats (1) and (2), and (3) is fixed with a single switch – disabling WPS.

Step by step

Path 1: capture the 4-way handshake (deauth helps) and crack the password offline (lesson 2).
Path 2: PMKID – the attacker starts an association and gets the material from the AP’s first frame. Both paths are beaten by a long password.
Path 3: WPS PIN – a design flaw narrows it to thousands of tries → guessable in hours, no matter how strong your password.
Defense: a long random password against (1)(2) and turn WPS off against (3). One switch, a big difference.

KRACK and downgrade attacks

The last two attacks show that even a correctly deployed WPA2 had weaknesses – and why to move to WPA3. KRACK (2017) was a big discovery: an attack on the 4-way handshake itself, independent of how strong your password is. The essence: the attacker forces a replay of message 3 of the handshake, making the client reinstall an already-used key and reset the nonce (the counter). Reusing the same key+nonce (nonce reuse) then allows decrypting part of the traffic. An important reassurance: KRACK was a protocol flaw that vendors patched – an updated client and AP are immune. It is a reminder why updating firmware is not optional. The second type is a downgrade attack: the attacker tries to force the client onto weaker security than it supports – say from WPA3 to WPA2, or from an encrypted to an open network. Most vulnerable is transition mode, where the AP offers both WPA3 and WPA2 at once for old devices – the attacker pretends WPA3 ‘does not work’ and pushes the connection down to weaker WPA2, where it then attacks offline. That is why the target state (lesson 7) is WPA3-only: once your devices allow it, leave transition mode and keep only WPA3. The lesson from both attacks: security is not ‘set and done’ – updates and leaving old modes are part of the defense.

Step by step

KRACK: the attacker forces a replay of message 3 → the client reinstalls the key and resets the nonce. Independent of password strength.
A reused key+nonce (nonce reuse) lets some traffic be decrypted. But: patched – update your firmware.
Downgrade: the attacker pretends WPA3 fails and pushes the link down to weaker WPA2 (or open), where it attacks.
Most vulnerable is transition mode (WPA3+WPA2 at once). Defense: updates and the goal WPA3-only (lesson 7).

▶ Open in the simulator

Lesson 6: Defense and operations

Myths: hidden SSID, MAC filter, WPS

Before we move to real defense, I must debunk three ‘tips’ you hear all the time that give a false sense of security. All three are security by obscurity – they rely on ‘hiding’ something, but an attacker bypasses it in minutes. (1) Hidden SSID: ‘I will not broadcast the network name’. But the SSID still flies in the open in other frames every time a client connects – an attacker sniffs it trivially, and your devices additionally shout out the network name (probe requests), which is exploitable (KARMA, lesson 5). By hiding the SSID you rather hurt yourself. (2) MAC filter: ‘I will only allow my MAC addresses’. A MAC address flies in every frame unencrypted – an attacker sniffs one of yours and clones it (MAC spoofing) in seconds. The filter delays a neighbor at most, not an attacker. (3) WPS: covered in lesson 5 – the ‘convenient PIN’ is a hole, guessable in hours. The lesson: these three do not replace encryption and authentication – at best they are cosmetics. Real defense is WPA3/a strong password, 802.1X, PMF and segmentation, not eyewash tricks. Do not waste time hiding; invest it in the layers that truly hold.

Step by step

Myth 1 – hidden SSID: the name flies openly on connect anyway. Plus your phone shouts it out (KARMA).
Myth 2 – MAC filter: a MAC flies unencrypted in every frame → an attacker clones it in seconds.
Myth 3 – WPS: the ‘convenient PIN’ is a hole (lesson 5). All three = security by obscurity.
Do not waste time hiding. Real defense = WPA3/strong password, 802.1X, PMF, segmentation – the layers that hold.

WIPS and rogue-AP detection

The attacks from lesson 5 share one thing: they happen in the air, where an ordinary firewall or switch cannot see. So there is a separate discipline – WIPS (Wireless Intrusion Prevention System), or the detection-only WIDS. Think of it as security cameras for the ether: deployed sensors continuously scan all channels and report suspicious phenomena – a rogue AP, an evil twin with the same SSID, a flood of deauth frames, KARMA behavior, and clients acting strangely. The difference WIDS vs WIPS is the same as IDS vs IPS from course 8: WIDS only reports, WIPS can also act (e.g. ‘shoot down’ a rogue AP with its own deauth frames until someone physically unplugs it). The most valuable trick is detecting a rogue AP on the cabling: the controller not only hears a foreign AP in the air but checks whether it hangs on your internal network (a sensor joins the suspect AP as an ordinary client and sends a test frame – if the frame surfaces on the company switch, the AP hangs on your cabling). That distinguishes a dangerous rogue AP plugged into a socket from a harmless neighbor’s AP behind a wall. WIPS also keeps a whitelist of your legitimate APs and escalates anything outside it. The simulator does not model WIPS (it is a concept like IDS/IPS in course 8), but you already know the detection-and-response logic from course 8 – here it just runs over radio instead of packets.

Step by step

WIPS = security cameras for the ether: sensors scan channels and report rogue APs, evil twins, deauth, KARMA.
The key test: the controller checks whether a foreign AP hangs on your internal network (a test frame: does it surface on the company switch?).
WIPS keeps a whitelist of your APs. A dangerous rogue on the cabling is told apart from a harmless neighbor’s.
WIDS only reports, WIPS can also act – the same logic as IDS/IPS from course 8, just over radio.

Monitoring, logs and who/when

Detection tells you ‘something is happening’ – but to reconstruct what happened after an incident you need logs. And here 802.1X from lesson 3 returns beautifully: thanks to RADIUS accounting you have an exact record of who, when, from which device and how long was connected – not ‘someone who knew the password’ but ‘Anna, 14:03, from laptop ANNA-NB, VLAN 10’. Without identity per person (with a shared PSK) forensics is nearly impossible. To the RADIUS logs you add controller/AP logs (associations, roaming, rejected connections, deauth storms caught by WIPS). Key practice: logs must not stay scattered across individual boxes where nobody reads them and where an attacker deletes them after a breach. So they are centralized and correlated in a SIEM (from course 8): the SIEM ties together RADIUS (‘Anna logged in’), the firewall (‘suspicious traffic from her IP’) and WIPS (‘an evil twin ran nearby’) into one story. Only then do the individual fragments become an alert that makes sense. Operational minimum: keep logging on at the AP/controller and RADIUS, send it off the device (to a central server), and watch a few key events – repeated auth failures, a new AP, deauth floods. Monitoring is not a one-off audit but a running process.

Step by step

Thanks to accounting (802.1X) you know exactly who/when/from where. With shared PSK the log says only ‘someone’.
Plus AP/controller logs: associations, roaming, rejected connections, deauth storms from WIPS.
Do not leave logs in the boxes (an attacker deletes them). Send them to a central server off the device.
SIEM (course 8) correlates RADIUS + firewall + WIPS into one story. Monitoring is a running process, not an audit.

Segmentation and Zero Trust

The last layer of defense is also a bridge back to everything you know from courses 3 and 5: segmentation. Even if an attacker breaks some layer, a well-divided network limits the damage to one segment – the blast radius, as we discussed with IoT in course 3. Practical Wi-Fi segmentation: employees, guests, IoT and maybe management into separate VLANs (course 3), with firewall rules between them by zone (course 5) – IoT may not reach servers, a guest nowhere but the internet, management only from dedicated stations. On top of all this today sits the Zero Trust philosophy: ‘never trust, always verify’ – even inside the network. The classic model trusted everything behind the firewall (‘you are inside, so you are one of us’); Zero Trust removes this assumption, because it is exactly what an attacker who once gets in (via a rogue AP or evil twin) relies on. Instead every access re-verifies identity (802.1X, MFA), checks device posture (NAC) and permits only the necessary (least privilege, microsegmentation – even two devices in the same VLAN need not see each other). For Wi-Fi it is the natural culmination of the whole course: wireless is by nature an untrusted medium, so ‘verify always and everywhere’ makes the most sense here. The simulator will not build Zero Trust as a whole for you, but its building blocks – VLANs, zones, rules, isolation – you have trained since course 3.

Step by step

Segmentation: separate VLANs (Course 3) + firewall rules by zone (Course 5). Even after a breach, the damage stays in one segment.
The old model trusted everything behind the firewall. That is exactly what an attacker who once gets in relies on.
Zero Trust: ‘never trust, always verify’ – identity (802.1X), device posture (NAC) even inside the network.
Permit only the necessary (least privilege, microsegmentation). The building blocks – VLANs, zones, isolation – you train since course 3.

▶ Open in the simulator

Lesson 7: The whole defense together

Layered Wi-Fi defense

Time to assemble the whole defense into one picture. Return to the map from lesson 1 – now you can fill each layer concretely. Walk through one attack’s path mentally and notice how each layer stops it a bit earlier. The attacker in a car outside listens to the air → hits WPA3/SAE encryption, so they see only noise. They try an evil twin + deauth to steal your client → PMF discards the forged deauth and server verification (802.1X) denies them the password. They plug in a rogue AP → WIPS exposes it, because it hangs on your cabling. Say one device does get infected → segmentation (VLANs, zones) keeps the damage in one segment and Zero Trust stops it from hopping freely on. And when it is over, logs and SIEM tell you exactly who/when/from where – so you resolve the incident, not just suspect it. This is the point of the whole course and the whole security series (5, 8, 12): no single layer suffices, but stacked they form a defense an attacker cannot break with one trick. Secure Wi-Fi is not one switch – it is a discipline: strong encryption, per-person authentication, frame protection, segmentation and running detection. That is exactly what you have gone through in this course.

Step by step

Eavesdropping in range → WPA3/SAE gives only noise. The first layer holds.
Evil twin + deauth → PMF discards the forgery, server verification (802.1X) denies the password. Layers two and three.
A rogue AP → WIPS exposes it. An infected device → segmentation and Zero Trust keep the damage in one segment.
After an incident logs and SIEM tell who/when/from where. The point: no layer alone suffices – only all together.

What’s next: WPA3-only, DPP, 6 GHz

Where is wireless security heading and what to take into practice? Three directions. (1) WPA3-only: as long as you run in transition mode (WPA3 + WPA2 at once) you are vulnerable to the downgrade from lesson 5. The goal is clear – once your devices allow it, leave transition mode and keep pure WPA3 with enforced PMF. A simple decision with a big impact. (2) DPP / Wi-Fi Easy Connect: recall WPS – ‘convenient connecting’ that turned out to be a hole. DPP is its secure successor: you connect a device by scanning a QR code (or via NFC) instead of typing a password or PIN – ideal for IoT with no display, and without the WPS weaknesses. (3) 6 GHz WPA3-only: the new 6 GHz band (Wi-Fi 6E/7, from course 11) has security built in from the start – in 6 GHz WPA3 and PMF are mandatory, old insecure modes simply are not there. So the future pushes toward ‘correct’ already at the standard level. Practical summary of the whole series: encrypt strongly (WPA3), authenticate per person (802.1X), protect frames (PMF), separate worlds (segmentation), watch the ether (WIPS) and keep a trail (logs). And above all – treat security as a running process: update, leave old modes and check continuously. With this the course and the whole series on networks and their security ends. Congratulations – you have walked the path from ‘why networks exist’ all the way to defending wireless in depth.

Step by step

WPA3-only: once possible, leave transition mode (WPA3+WPA2) → the downgrade from lesson 5 is gone.
DPP / Wi-Fi Easy Connect: the secure successor to WPS – connecting via a QR code, ideal for IoT with no display.
6 GHz (Wi-Fi 6E/7, course 11) has security built in: WPA3 and PMF mandatory, old modes are not there.
Series summary: encrypt (WPA3), authenticate (802.1X), protect frames (PMF), separate (segmentation), watch (WIPS), keep a trail (logs). Congratulations – you reached the end.

▶ Open in the simulator