15 — Wireless, Physical and Cloud Attacks
Level: Intermediate · Time: ~22 min · Prerequisites: Lesson 14 — Insider Threats and Supply Chain Attacks
Why this matters
Three attack surfaces get neglected for the same reason: none of them is the server, so nobody's checklist covers them. The WiFi network carries the same credentials as the wired one, but over radio that anyone in the car park can receive. A person standing at a desk with a bootable USB stick has more power than most remote attackers will ever have. And your cloud environment is not a protected building — it is a configuration you wrote, where one checkbox decides whether a database is on the internet. Each surface has cheap, well-understood controls. The failure is almost always that nobody applied them, and the resulting incidents look like "we assumed that was someone else's job".
The mental model: three surfaces outside the perimeter mindset
| Surface | Why it is forgotten | What the attacker gets | The good news |
|---|---|---|---|
| Wireless | it works, so it is not questioned | a copy of your traffic, or a network the client trusts by name | WPA3 plus certificate-based authentication removes most of it |
| Physical | visitors are always present and trusted | the disk, the boot process, or the unlocked screen | encryption and locked firmware make physical access survivable |
| Cloud | the provider is assumed to be securing it | data, credentials and infrastructure metered by the minute | most misconfigurations are detectable automatically, continuously and for free |
Wireless: how the standards got here
| Standard | What it did | Where it failed | Status today |
|---|---|---|---|
| WEP | first encryption for WiFi | RC4 with a short, repeating initialisation vector — recoverable in minutes | broken; if your device only offers WEP, replace it |
| WPA | stopped the bleeding with TKIP | a stopgap, cryptographically weak | obsolete, disable |
| WPA2-PSK | AES-CCMP and a shared passphrase, with a four-way handshake when a client joins | the handshake can be captured and tested offline against candidate passphrases; a weak or shared passphrase is the whole security model | still extremely common; acceptable only with a long random passphrase |
| WPA2/WPA3-Enterprise | 802.1X authentication to a RADIUS server with per-user credentials | misconfiguration (especially not validating the server certificate) opens a door | the right answer for any organisation |
| WPA3-SAE | a dictionary-attack-resistant handshake (SAE) and protected management frames | not universally supported by old devices | the target for new deployments |
Two details worth knowing because they explain the attacks. First, WPA2-PSK accepts a captured handshake offline: no rate limiting, no lockout, no log entry on your side — a bad passphrase can be tested forever on the attacker's own hardware. Second, PMKID capture removed the need to wait for a client at all, because the access point itself will hand over material derived from the passphrase. Both make the same point: for PSK networks, passphrase strength is the security control, which is why a long random passphrase that is never reused across sites is worth more than any other WiFi setting.
The attacks, and what actually defends them
| Attack | What it looks like | The defence |
|---|---|---|
| Captured handshake / PMKID, tested offline | someone with a laptop near your building; no traffic disruption required | WPA3-SAE, a long random passphrase, no passphrase reuse across sites or branches |
| Evil twin / rogue access point | a network with the same name (SSID) as yours, stronger signal, often open or with a captive portal | WIDS to detect impostor access points, certificate-based 802.1X so clients verify the network rather than the name, and no work traffic over open WiFi |
| Deauthentication / disassociation | clients repeatedly knocked off the network — a management frame anyone can send | protected management frames (802.11w), mandatory under WPA3; monitor for the disruption itself |
| Captive-portal phishing | a page that appears when you join, asking you to "sign in with your email password" | awareness: never enter credentials on a portal you did not expect, and use cellular tethering for urgent work |
| Rogue device plugged into a wall port | an unauthorised switch, access point or laptop on your wired network | 802.1X port authentication, switch port security, NAC, and physically controlling which wall ports are live |
| WPS PIN brute force | one extra feature nobody remembers enabling | disable WPS everywhere, permanently |
| Weak guest network | guests and staff on the same subnet as the servers | a separate guest VLAN with no route to internal systems (Lesson 18) |
[!TIP] The practical rule for anything portable: treat every network you do not control as hostile. Use a VPN to your own network or a trusted provider, keep HTTPS everywhere, turn off automatic joining of open networks, and forget the SSID afterwards. This costs nothing and removes the entire evil-twin category from your risk register while you wait for a proper wireless design.
Physical: why physical access usually means game over
An attacker at the machine can do things no remote exploit can match, and the reason is structural, not clever:
- Boot from external media and the operating system's access controls belong to an OS they are not running.
- Remove the disk and read it directly, bypassing every login prompt.
- Read memory from a running machine — encryption keys live in RAM while the system is unlocked, which is why a locked screen still matters and why hibernation files matter too.
- Use the reset or recovery procedure the vendor documented for lost passwords.
- Plug in a device that identifies itself as a keyboard and types commands in seconds.
That list is exactly why the durable controls are the ones that survive someone holding your laptop:
| Control | What it defeats |
|---|---|
| Full-disk encryption (BitLocker/LUKS) with a strong passphrase or a TPM plus PIN | disk removal, boot from external media, device theft |
| BIOS/UEFI password and secure boot | boot-order changes, tampered bootloaders |
| Disabled external boot and disabled unused ports | bootable USB and attached-device tricks |
| Locked cases and cable locks | casual theft and quick hardware tampering |
| Screen lock with a short timeout | the unattended laptop in a coffee shop |
The human side of physical security
| Technique | What it exploits | The control |
|---|---|---|
| Tailgating / piggybacking | politeness — nobody challenges someone carrying two coffees behind an authorised badge | badge-controlled doors that close, reception that actually stops people, a culture where asking is normal |
| Badge cloning | low-frequency proximity cards that respond to any reader nearby without user confirmation | encrypted card technology, PIN-plus-badge, or moving to a smartphone credential |
| USB drop attack | curiosity — the classic is a stick labelled with something irresistible, or "it just has my CV on it" | never plug in found media, use port blocking, restrict autorun, report the find instead of inserting it |
| Evil maid | unattended devices in hotel rooms or shared offices | full-disk encryption, secure boot, locked cases, tamper-evident seals on racks |
| Shoulder surfing | reading a screen or keyboard in a public place | privacy screens, screen awareness, no sensitive work in public transport |
| Dumpster diving | documents thrown away whole: contracts, invoices, password notes | cross-cut shredding, a locked waste process, clearing desk policy |
| Lost visitor discipline | someone wandering with a visitor badge that opens everything | visitor logging, escorted access, time-limited badges restricted to non-sensitive areas |
Cloud: shared responsibility, stated plainly
The provider secures the cloud; you secure what you put in it. That sentence is the whole model, and most cloud incidents are customer misconfiguration rather than a provider breach.
| Layer | Provider | You |
|---|---|---|
| Physical data centre, hardware, hypervisor | yes | — |
| Availability and network backbone of the platform | yes | — |
| Managed service patching (where the service is managed) | yes | — |
| Operating system and runtime (on unmanaged compute) | — | yes |
| Application code and dependencies | — | yes |
| Identity, accounts and permissions | tooling only | yes |
| Network configuration and exposure | tooling only | yes |
| Data classification, encryption decisions, key custody | tooling only | yes |
| Backups and their testing | tooling only | yes |
The misconfigurations that cause most incidents
| Misconfiguration | What it looks like | The fix |
|---|---|---|
| Public object storage | a bucket or container readable by anyone who knows the name | block public access at the account level, then review individual policies |
| Exposed database or search service | a database engine listening on a public address with no authentication | never expose it; private network only, plus authentication as defence in depth |
| Long-lived access keys | a key committed to a public repository, or embedded in a mobile app or script | remove static keys, use short-lived credentials and workload identity, scan repositories and images for secrets |
| Over-permissive roles | * actions on * resources, or a role that can modify its own permissions |
least privilege, scoped policies, permission boundaries for who can create roles |
| No MFA on the management console | one password protecting the whole environment | MFA on every console, and on every federated identity that can reach it |
| Exposed management interfaces | a container orchestrator API, an admin console or a metrics endpoint on the internet | private endpoints, authenticated access, network policy; scan your own public addresses |
| Insecure container images | an old base image, unnecessary packages, secrets baked into a layer | minimal base images, rebuild and rescan regularly, never bake secrets into layers |
| Weak or absent audit logging | nothing recorded, or logs in a single region nobody reads | enable audit logging everywhere and centralise it where it cannot be tampered with |
| Metadata-service abuse over SSRF | a web application tricked into fetching a link that returns cloud credentials (see Lesson 10) | require a hop-limited metadata request, restrict egress from workloads, fix SSRF at the application layer |
Identity in the cloud
The cloud version of Lesson 13, narrowed to what matters most:
- Root or owner account hygiene: MFA on it, no access keys for it, and used only for the handful of tasks that truly require it.
- Separate accounts or subscriptions per environment — production is not a folder inside the thing your developers experiment in.
- Permission boundaries so that identity administrators cannot grant more than they hold themselves.
- Workload identity instead of static keys: workloads authenticate with short-lived tokens from the platform's identity service, so there is no reusable secret to steal.
- Just-in-time elevation with an approval and an expiry, instead of standing administrator rights.
Defences to name, and five checks to run today
The controls: a cloud security posture management tool for continuous misconfiguration detection (open-source options include Prowler and ScoutSuite, named properly in Lesson 36); Infrastructure-as-Code scanning before anything is deployed (Checkov, tfsec, Trivy in config mode); no long-lived keys; MFA on every console; centralised audit logging; and guardrails as policy-as-code that reject a bad deployment instead of reporting it afterwards.
- Is MFA enabled on the root/owner account, and does that account have zero access keys?
- Does any object storage hold data that is publicly readable — at the bucket level and via any policy that grants public access?
- Does any security group, firewall rule or network ACL allow the world (
0.0.0.0/0) to a management port such as 22, 3389 or 5432? - Are there access keys older than 90 days, and are any secrets committed to a repository or baked into an image?
- Is audit logging enabled in every region and copied to a destination that a compromised account cannot simply delete?
If any answer is "I would have to check", that is your task list for this week.
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Offline PSK cracking | a captured handshake tested against candidate passphrases at leisure | WPA3-SAE, long random unique passphrase, no passphrase reuse |
| Evil twin | a same-named access point that clients join automatically | certificate validation in 802.1X, WIDS, VPN and TLS on untrusted WiFi |
| Deauthentication flood | forged management frames disrupt clients | protected management frames (802.11w), monitoring for the disruption |
| Rogue device on a wall port | an unauthorised device reaches the internal network | 802.1X, port security, NAC, physical port control |
| Laptop theft | the device, and everything on it, leaves the building | full-disk encryption, BIOS/UEFI password, secure boot, cable lock |
| USB drop | curiosity installs the attacker's device inside your building | never plug in found media, port blocking, awareness, report instead of insert |
| Tailgating | following an authorised person through a controlled door | door hardware that closes and counts, reception process, challenge culture |
| Public cloud storage | anyone with the URL reads your data | block public access by default, posture scanning, classification |
| Cloud key leaked in a repository | a static access key grants API access | no long-lived keys, workload identity, secret scanning, short credential lifetimes |
| SSRF to the metadata service | an application is tricked into fetching credentials | hop-limited metadata requests, workload egress restriction, SSRF fixes at the app layer |
Key takeaways
- Wireless security with a shared passphrase is passphrase security: strength and uniqueness do the work, and WPA3 plus 802.1X is what replaces guessing with authentication.
- Treat every network you do not control as hostile — VPN plus TLS, always, no exceptions for executives or urgency.
- Physical access is a full compromise unless encryption and firmware locks are in place first. Buy the disk encryption before the badge reader.
- In the cloud the provider secures the cloud and you secure everything you put in it — and your exposure is a configuration you can automate checking for.
- Most cloud incidents are misconfiguration, not breach: public storage, leaked keys, wildcard permissions, no MFA, no logs. All five are findable before an attacker finds them.
Check yourself
- Why does a weak WPA2-PSK passphrase fail even if you never see the attacker on your network?
- Someone brings a laptop into your office, plugs into an unused wall port and is on your internal network in seconds. Name two controls that prevent this and one that would have detected it.
- What does full-disk encryption actually protect you from, and what does it not protect you from?
- Which two cloud misconfigurations would you look for first in a new environment, and what tooling would you use routinely rather than once?
- A web application can be tricked into fetching an internal URL that returns cloud credentials. Which attack class from Lesson 10 is that, and what limits the damage today?