Skip to content

SC-032: Wireless Network Attack — Operation Air Bridge

Scenario Header

Type: Network / Healthcare  |  Difficulty: ★★★★☆  |  Duration: 3–4 hours  |  Participants: 4–8

Threat Actor: RADIO FALCON — red team simulation / malicious insider conducting wireless network attacks against healthcare infrastructure

Primary ATT&CK Techniques: T1557.002 · T1078 · T1040 · T1557.001 · T1021.001 · T1083

Facilitator Note

This scenario simulates a wireless attack against a hospital network, escalating from evil twin AP deployment to PHI (Protected Health Information) access. Participants should include network security engineers, wireless infrastructure administrators, SOC analysts, and HIPAA privacy/compliance officers. The scenario highlights the unique challenges of wireless security in healthcare environments where availability directly impacts patient safety. All data is synthetic. All organizations, IPs, and indicators are fictional.


Threat Actor Profile

RADIO FALCON represents a skilled insider threat — a contracted biomedical equipment technician with physical access to MedCore Regional Hospital's facilities. The technician, frustrated over a contract dispute and facing financial pressures, decides to exploit wireless network vulnerabilities to access and exfiltrate patient health information (PHI) for sale on dark web marketplaces. Their physical access to clinical areas, mechanical rooms, and network closets provides ideal positioning for wireless attacks.

The insider has intermediate wireless security knowledge gained from publicly available penetration testing courses and tools. They understand WPA2-Enterprise authentication, RADIUS protocols, and common wireless attack frameworks (hostapd-wpe, Eaphammer). Their physical presence in the hospital provides a critical advantage: they can deploy rogue access points in locations with strong signal coverage to clinical areas, and their presence does not raise suspicion because they are authorized to be in technical spaces.

Motivation: Financial — PHI records sell for $250–$1,000 per record on dark web markets (significantly more than credit card data). Secondary motivation: retaliation against the hospital for the contract dispute. Estimated target: 5,000+ patient records with a potential black market value of $1.25M–$5M.


Scenario Narrative

Scenario Context

MedCore Regional Hospital is a 350-bed regional hospital serving a metropolitan area of 400,000 residents. The hospital operates on a converged network infrastructure supporting clinical systems (EHR, PACS, lab systems), medical devices (infusion pumps, patient monitors, ventilators), and corporate IT (email, HR, finance). Wireless infrastructure uses WPA2-Enterprise with PEAP-MSCHAPv2 — employees authenticate with Active Directory credentials via a RADIUS server (10.10.1.50). The wireless network supports approximately 2,800 connected devices: 800 staff devices (laptops, tablets), 1,200 medical devices (IoT), and 800 guest/patient devices. The hospital's IT security team is 4 people; they conduct annual wireless assessments but do not have wireless intrusion detection/prevention (WIDS/WIPS) deployed. The biomedical engineering team manages 1,200+ networked medical devices, many running legacy operating systems (Windows 7/XP Embedded) with manufacturer-imposed restrictions on patching.


Phase 1 — Wireless Reconnaissance (~30 min)

RADIO FALCON begins passive wireless reconnaissance during normal working hours, using a laptop with an external wireless adapter (Alfa AWUS036ACH) concealed in a backpack. As a biomedical technician, carrying a laptop and equipment through clinical areas is unremarkable. The reconnaissance is entirely passive — no packets are transmitted — making it undetectable by the hospital's network monitoring.

The technician maps the wireless environment over 3 days, cataloging access points, SSIDs, authentication methods, client devices, and signal coverage patterns. Key findings:

  • Corporate SSID: MedCore-Staff — WPA2-Enterprise, PEAP-MSCHAPv2 — 47 APs
  • Medical Device SSID: MedCore-IoT — WPA2-PSK — Pre-shared key (unchanged for 2+ years)
  • Guest SSID: MedCore-Guest — Open (captive portal) — Internet-only, VLAN-isolated
  • Legacy SSID: MedCore-Legacy — WPA2-PSK — Used by older medical devices that do not support Enterprise auth

The technician also identifies that the corporate RADIUS server certificate is self-signed (CN=MedCore-RADIUS, O=MedCore Hospital) and that several client devices are configured to not validate the server certificate — a common misconfiguration when IT deploys PEAP-MSCHAPv2 without certificate pinning.

Evidence Artifacts:

Artifact Detail
Wireless Survey (attacker notes) 47 APs mapped — 4 SSIDs — Channel utilization: 2.4 GHz 78%, 5 GHz 42% — Coverage gaps: mechanical room B3, parking garage level 2
SSID Configuration MedCore-Staff: WPA2-Enterprise, PEAP-MSCHAPv2, RADIUS 10.10.1.50MedCore-IoT: WPA2-PSK — MedCore-Legacy: WPA2-PSK — MedCore-Guest: Open/captive portal
Client Device Inventory 2,800 devices — 400+ medical devices on MedCore-IoT — 147 devices on MedCore-Legacy — Multiple devices with RADIUS cert validation disabled
Badge Access Log Technician badge scans: Building A (clinical wing) — 06:45, 10:22, 14:15 — Building B (mechanical/IT) — 07:30, 11:45, 15:30 — Normal pattern for biomedical tech
Physical Access Technician has key card access to: all clinical floors, mechanical rooms, network closets (for medical device maintenance), biomedical workshop
Phase 1 — Discussion Inject

Technical: The hospital has 4 separate SSIDs with different security levels. The MedCore-IoT and MedCore-Legacy SSIDs use PSK authentication — why? (Answer: many medical devices do not support 802.1X/Enterprise authentication.) What compensating controls should protect PSK-authenticated medical device networks? Consider: MAC filtering (weak), network segmentation, dedicated VLANs with strict ACLs, and NAC (Network Access Control).

Decision: The RADIUS server uses a self-signed certificate, and many clients do not validate it. Deploying a CA-signed certificate and enforcing certificate validation on all clients would take 3–4 weeks and risk disrupting clinical workflows. Do you prioritize this remediation, accepting the short-term disruption risk? Or do you accept the risk and schedule it for the next maintenance window (6 weeks out)?

Expected Analyst Actions:

  • [ ] Review current wireless security architecture — SSIDs, authentication methods, segmentation
  • [ ] Audit RADIUS server certificate configuration — identify self-signed certificate risk
  • [ ] Assess client device RADIUS certificate validation settings — identify devices with validation disabled
  • [ ] Review medical device network segmentation — verify IoT VLAN isolation from clinical systems
  • [ ] Check if WIDS/WIPS is deployed — assess wireless monitoring capability
  • [ ] Review physical access logs for unusual patterns in network closet or mechanical room access

Phase 2 — Evil Twin Deployment & Credential Capture (~45 min)

RADIO FALCON deploys an evil twin access point using a Raspberry Pi 4 with a high-gain antenna, concealed inside a medical equipment case in a mechanical room on the 3rd floor. The mechanical room is accessible with the technician's badge, is rarely visited by other staff, and has an electrical outlet. The device is configured using hostapd-wpe (hostapd with WPE patches for credential harvesting).

The evil twin broadcasts SSID MedCore-Staff on channel 6 (same as the nearest legitimate AP) with higher power output, causing nearby client devices to preferentially associate with the rogue AP. When clients connect and attempt PEAP-MSCHAPv2 authentication, the evil twin presents its own RADIUS certificate. Clients configured to not validate the server certificate complete the authentication handshake, transmitting MSCHAPv2 challenge-response hashes that can be cracked offline.

Over 8 hours (overnight shift, fewer staff to notice connectivity issues), the evil twin captures MSCHAPv2 hashes from 34 unique devices/users. The technician retrieves the Raspberry Pi the following morning during a routine maintenance visit.

Evidence Artifacts:

Artifact Detail
Rogue AP Configuration SSID: MedCore-Staff — BSSID: AA:BB:CC:DD:EE:01 (not matching any legitimate AP) — Channel: 6 — Power: 25 dBm (higher than legitimate APs at 20 dBm) — Auth: WPA2-Enterprise (PEAP-MSCHAPv2 with rogue certificate)
Captured Credentials 34 unique MSCHAPv2 challenge-response pairs — Captured: 2026-03-15T22:00Z to 2026-03-16T06:00Z — Users include: nurses, physicians, IT staff, administrators
Credential Cracking HashCat with –m 5500 (NetNTLMv1/MSCHAPv2) — 28/34 passwords cracked within 4 hours — Cracked accounts include: n.johnson (RN, ICU), dr.ramirez (Physician, Emergency), t.nakamura (IT Admin), a.foster (Finance Director)
Wireless Controller Log 2026-03-16T02:14:00Z — AP AP-3F-EAST (channel 6) — Client disassociation rate: +340% vs. baseline — 12 clients roaming unexpectedly — Anomaly not alerted (no WIPS)
Helpdesk Tickets 2026-03-16T06:30Z — 3 tickets: "WiFi keeps disconnecting on 3rd floor" — Resolved as: "interference, will monitor" — Not escalated to security
Phase 2 — Discussion Inject

Technical: MSCHAPv2 hashes were captured because clients did not validate the RADIUS server certificate. What is the attack chain: client connects → evil twin presents rogue cert → client ignores cert → MSCHAPv2 handshake completes → hashes captured. How does EAP-TLS (mutual certificate authentication) prevent this attack? Why is PEAP-MSCHAPv2 without certificate pinning considered insecure?

Decision: 3 helpdesk tickets reported WiFi disconnections on the 3rd floor overnight. The helpdesk resolved them as "interference." What process would ensure that wireless connectivity issues are evaluated as potential security incidents? Should all helpdesk tickets containing keywords like "WiFi," "disconnect," "slow connection" be auto-flagged for security review?

Expected Analyst Actions:

  • [ ] Investigate the 3rd floor WiFi disconnection reports — correlate with wireless controller logs
  • [ ] Check wireless controller for unknown BSSIDs on the MedCore-Staff SSID
  • [ ] Analyze client disassociation/roaming anomalies during the overnight window
  • [ ] Physical inspection of mechanical rooms and network closets for unauthorized devices
  • [ ] Review badge access logs for the 3rd floor mechanical room during the attack window
  • [ ] Assess whether any captured credentials have been used from unusual sources

Phase 3 — Network Access & Lateral Movement (~40 min)

Using the cracked credentials for t.nakamura (IT Admin), RADIO FALCON connects to MedCore-Staff from a personal laptop. The IT admin account has elevated privileges: local admin on workstations, VPN access, and read access to several file shares including the IT department share (\\fs-01.medcore.example.local\IT$). The technician connects from the hospital cafeteria during lunch — an area with legitimate wireless coverage.

From the wireless network, the attacker discovers that network segmentation between the MedCore-Staff VLAN (10.10.10.0/24) and the MedCore-IoT VLAN (172.16.50.0/24) is enforced by a firewall — but the IT admin VLAN (10.10.1.0/24) has a management ACL permitting access to all VLANs for device management purposes. Using t.nakamura's credentials, the attacker pivots through the IT admin VLAN to reach the medical device network.

The attacker enumerates the medical device network and identifies:

  • EHR Application Server: 10.10.5.20 (Epic Hyperspace) — contains patient records
  • PACS Server: 10.10.5.30 (medical imaging) — contains radiology images and reports
  • SQL Database Server: 10.10.5.40 — backend database for the EHR system
  • 147 medical devices on 172.16.50.0/24 — infusion pumps, patient monitors, ventilators

Evidence Artifacts:

Artifact Detail
Wireless Auth Log 2026-03-17T12:15:00Z — RADIUS auth: t.nakamura — MAC: 11:22:33:44:55:66 (not registered corporate device) — AP: AP-CAFE-01 — Result: SUCCESSt.nakamura's corporate laptop MAC: AA:BB:CC:11:22:33 (different)
DHCP Log 2026-03-17T12:15:05Z — Lease: 10.10.10.147 → MAC 11:22:33:44:55:66 — Hostname: kali-laptop (!) — VLAN: MedCore-Staff
Firewall Log 2026-03-17T12:22:00Z10.10.10.14710.10.1.1:3389 (IT admin gateway) — PERMIT — Rule: IT_ADMIN_ACCESS — Credential: t.nakamura
Network Scan (attacker) 2026-03-17T12:30:00Z — nmap scan from 10.10.10.147 — Targets: 10.10.5.0/24, 172.16.50.0/24 — 487 hosts discovered — 14 with open SMB, 3 with open RDP, 1 SQL Server
AD Security Log (DC-01) EventID 4624 Type 3: t.nakamura from 10.10.10.1472026-03-17T12:18:00Z — Followed by EventID 4672 (special privileges assigned)
EDR Alert 2026-03-17T12:30:44ZMEDIUM: Network scan detected from 10.10.10.147 — 487 connection attempts in 60 seconds — Source: unknown device — Alert acknowledged but not investigated for 4 hours
Phase 3 — Discussion Inject

Technical: The DHCP server assigned an IP and recorded the hostname as kali-laptop — a strong indicator of malicious activity. Is DHCP hostname a reliable detection signal? (Answer: partially — it can be spoofed, but many attackers forget to change it.) What other DHCP-level indicators are useful? Consider: MAC OUI (manufacturer) mismatching corporate device policy, rapid DHCP requests, and correlation with NAC posture assessment.

Decision: The EDR alert for the network scan was acknowledged but not investigated for 4 hours. During that time, the attacker accessed the EHR database. Your SOC has 2 analysts covering a 600-alert/day volume. How do you reduce alert fatigue while ensuring high-fidelity alerts like network scans from unknown devices get immediate attention? What is the correct alert priority for "network scan from unregistered device on clinical network"?

Expected Analyst Actions:

  • [ ] Investigate DHCP lease for 10.10.10.147 — identify unknown device with hostname kali-laptop
  • [ ] Correlate RADIUS auth for t.nakamura with device MAC address — flag MAC mismatch
  • [ ] Review network scan alert — escalate immediately as potential active compromise
  • [ ] Check firewall logs for cross-VLAN traffic from 10.10.10.147 — identify lateral movement
  • [ ] Verify t.nakamura's current location and device — confirm or rule out legitimate activity
  • [ ] Assess whether NAC would have blocked the unregistered device from connecting

Phase 4 — EHR Access & PHI Exfiltration (~40 min)

Using t.nakamura's IT admin credentials, the attacker accesses the EHR SQL database server (10.10.5.40) via SQL Server Management Studio (installed on an IT workstation accessed via RDP). The IT admin account does not have direct access to the EHR application, but it has db_datareader permissions on the SQL backend — a legacy configuration from a database migration project 18 months ago that was never cleaned up.

The attacker executes SQL queries to extract patient demographics, diagnoses, medications, Social Security numbers, and insurance information. Over 2 hours, 5,247 patient records are exported to CSV files on the IT workstation, then exfiltrated via HTTPS to a cloud storage endpoint (storage.cloud-upload.example.com) using the hospital's guest WiFi network (which has unrestricted internet access).

Evidence Artifacts:

Artifact Detail
SQL Server Audit Log 2026-03-17T13:00:00Z — Login: t.nakamura from 10.10.2.15 (IT workstation via RDP) — Database: EHR_Production — Permission: db_datareader — 47 SELECT queries against Patient_Demographics, Patient_Diagnoses, Patient_Medications, Patient_Insurance
SQL Query Sample SELECT TOP 5000 PatientID, FirstName, LastName, SSN, DOB, DiagnosisCode, Medication FROM Patient_Demographics d JOIN Patient_Diagnoses dx ON d.PatientID = dx.PatientID — Executed: 2026-03-17T13:15:22Z
RDP Session Log t.nakamura10.10.2.15 (IT-WS-03) — 2026-03-17T12:55:00Z — Session duration: 2h 15m — Files created: C:\Users\t.nakamura\Desktop\export_1.csv through export_5.csv
File Transfer 10.10.2.15storage.cloud-upload.example.com:443 — HTTPS POST — 5 files, total 127 MB — 2026-03-17T14:30:00Z to 2026-03-17T14:45:00Z — Via MedCore-Guest VLAN (internet-unrestricted)
DLP Alert NONE — No Data Loss Prevention solution deployed — No content inspection on outbound HTTPS — Guest network has no egress filtering
Data Exfiltrated 5,247 patient records — Fields: Name, SSN, DOB, address, diagnosis codes (ICD-10), medications, insurance policy numbers, provider names
Phase 4 — Discussion Inject

Technical: The attacker exfiltrated data via the guest WiFi network — which has no egress filtering or content inspection. Why is guest network isolation insufficient if an attacker can simply connect a device to the guest network for exfiltration? What controls should apply to the guest network? Consider: content filtering, bandwidth limitations, client isolation, and monitoring.

Decision: 5,247 patient records containing SSN, diagnoses, and insurance data have been exfiltrated. Under HIPAA, this is a reportable breach affecting more than 500 individuals — requiring notification to HHS OCR, affected individuals, and prominent media outlets within 60 days. Your legal team wants to "investigate further before reporting." What are the risks of delayed reporting vs. premature reporting? What is the HIPAA Breach Notification Rule timeline?

Expected Analyst Actions:

  • [ ] Review SQL Server audit logs for unusual query patterns — bulk SELECTs against PHI tables
  • [ ] Identify the db_datareader permission on t.nakamura as a legacy misconfiguration — remediate
  • [ ] Trace the exfiltration path: RDP to IT workstation → file export → guest WiFi → cloud storage
  • [ ] Identify the cloud storage destination — contact provider for data preservation/takedown
  • [ ] Determine exact scope of PHI exposure — 5,247 patients, specific data elements
  • [ ] Engage HIPAA privacy officer and legal counsel for breach notification assessment

Phase 5 — Detection & Investigation (~30 min)

The attack is detected when the IT security team investigates the 4-hour-old EDR network scan alert. During investigation, they discover the MAC mismatch on t.nakamura's wireless authentication (personal device vs. corporate device), the cross-VLAN lateral movement, and the SQL database access. The investigation escalates rapidly when SQL audit logs reveal bulk PHI queries.

Simultaneously, t.nakamura (the real IT admin) reports to the helpdesk that his account was locked out after multiple failed password attempts — he has been on vacation for 3 days and has not logged in. This confirms credential compromise.

Evidence Artifacts:

Artifact Detail
Detection Timeline EDR alert (network scan): 2026-03-17T12:30Z — Alert acknowledged: 2026-03-17T12:45Z — Investigation started: 2026-03-17T16:30Z (4-hour gap) — MAC mismatch discovered: 2026-03-17T16:45Z — SQL access discovered: 2026-03-17T17:00Z — CISO notified: 2026-03-17T17:15Z
t.nakamura (real user) Helpdesk ticket: 2026-03-17T18:00Z — "Account locked, I've been on PTO since March 14" — Last legitimate login: 2026-03-14T16:00Z — Current location: out of state (confirmed)
Account Lockout t.nakamura locked after attacker's session — 3 failed attempts from 10.10.10.147 at 2026-03-17T14:50Z (post-exfiltration, likely accidental)
Badge Access Correlation Biomedical technician badge scans: 3rd floor mechanical room — 2026-03-15T21:45Z (evil twin deployment) — 2026-03-16T07:15Z (retrieval) — Cafeteria: 2026-03-17T12:10Z (attack execution)
Raspberry Pi (recovered) Found in 3rd floor mechanical room power outlet — Raspberry Pi 4 + Alfa wireless adapter + 64GB SD card — hostapd-wpe logs: 34 captured credential hashes — Power connected: 8 hours
Phase 5 — Discussion Inject

Technical: The evil twin Raspberry Pi was physically recovered from the mechanical room. What forensic data can be extracted? Consider: hostapd-wpe logs (captured hashes), SD card forensics (OS image, configuration files, SSH keys), MAC address of the device, and any network connections the Pi made during operation. How do you correlate the Pi to the specific insider?

Decision: Badge access logs show the biomedical technician accessed the 3rd floor mechanical room at the exact times of evil twin deployment and retrieval. This is strong circumstantial evidence but not definitive proof. How do you proceed with the insider investigation? Do you (A) confront the technician immediately, risking evidence destruction, or (B) covertly continue the investigation with HR and legal, potentially allowing continued access?

Expected Analyst Actions:

  • [ ] Correlate badge access logs with evil twin deployment and retrieval times
  • [ ] Forensically image the recovered Raspberry Pi SD card — preserve chain of custody
  • [ ] Review all of t.nakamura's account activity during the compromise window
  • [ ] Identify all systems accessed and data exfiltrated using compromised credentials
  • [ ] Coordinate with HR and legal for insider threat investigation procedures
  • [ ] Preserve all wireless controller logs, RADIUS logs, and DHCP logs for the attack window

Phase 6 — Containment, Eradication & Regulatory Response (~30 min)

MedCore activates its incident response plan, engaging external forensics, legal counsel, and the FBI (due to the HIPAA breach scale and insider threat component). The containment and remediation effort addresses both the immediate compromise and the systemic wireless security gaps.

Evidence Artifacts:

Artifact Detail
Containment Actions t.nakamura credentials reset + MFA re-enrolled — All 34 compromised accounts: passwords reset — Biomedical technician: badge access revoked, placed on administrative leave — Guest WiFi: egress filtering + content inspection added — MedCore-IoT PSK rotated
Insider Investigation FBI Computer Crimes notified — Technician's personal devices seized (warrant) — Cloud storage account (storage.cloud-upload.example.com) preserved via legal process — 5,247 records confirmed exfiltrated — No evidence of sale (yet) — Technician arrested: 2026-03-22
HIPAA Breach Notification HHS OCR notification: 2026-03-19 (within 60-day window) — 5,247 individual notification letters: mailed 2026-04-01 — Media notification: 2026-04-01 (>500 individuals) — Credit monitoring offered: 24 months
Remediation Plan Phase 1 (immediate): WIPS deployment, RADIUS cert upgrade, MAC-based NAC — Phase 2 (30 days): EAP-TLS migration, medical device micro-segmentation — Phase 3 (90 days): Zero trust wireless architecture, continuous posture assessment
Cost Impact Forensics & IR: $450K — Breach notification & credit monitoring: $1.2M — HIPAA fine (estimated): $500K–$1.5M — Legal fees: $300K — Wireless infrastructure upgrade: $280K — Total estimated: $2.7M–$3.7M
Phase 6 — Discussion Inject

Technical: MedCore plans to migrate from PEAP-MSCHAPv2 to EAP-TLS. What does this require? Consider: PKI infrastructure (CA, certificate enrollment for all devices), device certificate deployment (MDM integration), supplicant configuration, and the challenge of medical devices that may not support EAP-TLS. What interim controls protect the remaining PEAP-MSCHAPv2 devices?

Decision: The HIPAA fine could be $500K–$1.5M. However, HHS OCR considers "reasonable security measures in place at the time of the breach" as a mitigating factor. MedCore did not have WIPS, did not enforce RADIUS certificate validation, and allowed legacy PSK networks. How does the absence of these controls affect the penalty? What would have been the cost of implementing them before the breach vs. the total breach cost?

Expected Analyst Actions:

  • [ ] Ensure all compromised credentials are reset and MFA re-enrolled
  • [ ] Deploy wireless intrusion prevention system (WIPS) for rogue AP detection
  • [ ] Upgrade RADIUS server certificate to CA-signed and enforce client-side validation
  • [ ] Implement NAC for MAC-based device authentication and posture assessment
  • [ ] Remove legacy db_datareader permissions for IT accounts on EHR databases
  • [ ] Add egress filtering and content inspection to guest wireless network

Detection Opportunities

KQL Detection Queries

// Detect RADIUS authentication from unregistered MAC addresses
WiFiAuthLogs
| where AuthResult == "Success"
| join kind=leftanti (
    ManagedDevices | project MACAddress
) on $left.ClientMAC == $right.MACAddress
| project TimeGenerated, Username, ClientMAC, APSSID, APName, AuthResult
| extend Alert = "Successful WiFi auth from unregistered device MAC"

// Detect rogue access points (BSSID not in inventory)
WirelessControllerEvents
| where EventType == "APDetected"
| where BSSID !in (
    WirelessAPInventory | project BSSID
)
| where SSID in ("MedCore-Staff", "MedCore-IoT", "MedCore-Legacy") // spoofing corporate SSID
| project TimeGenerated, BSSID, SSID, Channel, SignalStrength, NearestAP
| extend Alert = "Rogue AP detected broadcasting corporate SSID"

// Detect bulk SQL queries against PHI tables
SQLAuditEvents
| where DatabaseName == "EHR_Production"
| where TableName has_any ("Patient_Demographics", "Patient_Diagnoses", "Patient_Medications")
| where RowsReturned > 100
| summarize QueryCount=count(), TotalRows=sum(RowsReturned) by LoginName, ClientIP, bin(TimeGenerated, 1h)
| where TotalRows > 1000
| extend Alert = strcat("Bulk PHI access: ", TotalRows, " rows by ", LoginName)

// Detect credential use while user is on PTO
let PTOUsers = HRCalendar | where Status == "PTO" | project UserPrincipalName, PTOStart, PTOEnd;
SigninLogs
| join kind=inner PTOUsers on $left.UserPrincipalName == $right.UserPrincipalName
| where TimeGenerated between (PTOStart .. PTOEnd)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
| extend Alert = "Account used while employee is on PTO — possible credential compromise"

// Detect DHCP hostname anomalies (attack tool indicators)
DHCPLogs
| where Hostname has_any ("kali", "parrot", "pentoo", "blackarch", "commando", "attack")
| project TimeGenerated, MACAddress, AssignedIP, Hostname, VLAN
| extend Alert = strcat("Suspicious DHCP hostname: ", Hostname, " — possible attack tool")

Splunk (SPL) Detection Queries

// Rogue AP detection — BSSID not in inventory
index=wireless sourcetype=wireless_controller event_type=ap_detected
| lookup wireless_ap_inventory bssid OUTPUT ap_name as known_ap
| where isnull(known_ap)
| search ssid IN ("MedCore-Staff", "MedCore-IoT", "MedCore-Legacy")
| table _time, bssid, ssid, channel, signal_strength, nearest_legitimate_ap
| eval alert="Rogue AP broadcasting corporate SSID"

// WiFi auth with MAC mismatch for known users
index=radius sourcetype=radius_auth result=accept
| lookup corporate_devices username OUTPUT registered_mac
| where client_mac != registered_mac AND isnotnull(registered_mac)
| table _time, username, client_mac, registered_mac, ap_name, ssid
| eval alert="WiFi auth from non-registered device for known user"

// Bulk PHI database access detection
index=sqlserver sourcetype=sql_audit database="EHR_Production"
action=SELECT table_name IN ("Patient_Demographics", "Patient_Diagnoses", "Patient_Medications", "Patient_Insurance")
| bucket _time span=1h
| stats sum(rows_returned) as total_rows count as query_count by login_name, client_ip, _time
| where total_rows > 1000
| eval severity="CRITICAL"
| eval alert="Bulk PHI query: ".total_rows." rows accessed by ".login_name

// Data exfiltration via guest network — large HTTPS uploads
index=firewall sourcetype=fw_traffic src_zone="Guest_WiFi" dest_port=443 action=allow
| stats sum(bytes_out) as total_bytes by src_ip, dest_ip, dest_host
| where total_bytes > 50000000
| eval mb_transferred=round(total_bytes/1048576, 2)
| eval alert="Large data transfer via guest WiFi: ".mb_transferred." MB to ".dest_host

// Cross-VLAN lateral movement from wireless client
index=firewall sourcetype=fw_traffic src_zone="Staff_WiFi"
dest_zone IN ("Medical_Devices", "Clinical_Systems", "IT_Admin")
| stats count dc(dest_ip) as unique_destinations by src_ip, src_zone, dest_zone
| where unique_destinations > 5
| eval alert="Wireless client performing cross-VLAN reconnaissance"

Incident Response Checklist

Immediate Actions (0–2 hours)

  • [ ] Reset credentials for all 34 captured accounts — force MFA re-enrollment
  • [ ] Physically sweep all accessible areas for rogue wireless devices
  • [ ] Revoke insider's badge access and place on administrative leave
  • [ ] Block the exfiltration destination (storage.cloud-upload.example.com) at the firewall
  • [ ] Isolate the compromised IT workstation (10.10.2.15) for forensic imaging
  • [ ] Engage HIPAA privacy officer and legal counsel

Short-Term Actions (2–72 hours)

  • [ ] Deploy emergency WIPS monitoring for rogue AP detection
  • [ ] Determine complete scope of PHI exfiltration from SQL audit logs
  • [ ] Forensically image recovered Raspberry Pi — maintain chain of custody
  • [ ] Coordinate with FBI for insider threat investigation and data recovery
  • [ ] File HIPAA breach notification with HHS OCR
  • [ ] Remove legacy database permissions for IT accounts on clinical systems

Long-Term Actions (1–12 weeks)

  • [ ] Migrate from PEAP-MSCHAPv2 to EAP-TLS with mutual certificate authentication
  • [ ] Deploy NAC with device posture assessment and MAC authentication
  • [ ] Implement medical device micro-segmentation with strict ACLs
  • [ ] Add content inspection and egress filtering to guest WiFi network
  • [ ] Deploy DLP solution with PHI content inspection on all network egress points
  • [ ] Implement zero trust wireless architecture with continuous authentication

Lessons Learned

What Went Wrong

Gap Detail Remediation
No WIDS/WIPS deployed Evil twin AP operated for 8 hours without detection Deploy WIPS with rogue AP detection, alerting, and automated containment
Self-signed RADIUS certificate Clients did not validate certificate — enabled evil twin credential capture Deploy CA-signed RADIUS certificate, enforce client-side certificate validation
PEAP-MSCHAPv2 vulnerability MSCHAPv2 hashes crackable offline — inherent protocol weakness Migrate to EAP-TLS with mutual certificate authentication
No NAC enforcement Unregistered device (kali-laptop) obtained network access without posture check Deploy NAC requiring device registration, health attestation, and MAC verification
Legacy database permissions IT admin had db_datareader on EHR database from 18-month-old migration project Implement quarterly access reviews, just-in-time database access, audit all service/admin accounts
Guest WiFi unrestricted egress No content inspection or upload filtering — used for data exfiltration Add DLP, content inspection, bandwidth limits, and upload restrictions to guest network
4-hour alert investigation gap Network scan alert acknowledged but not investigated for 4 hours Implement SLA-based alert triage — network scans from unknown devices = P1 (15-min response)
Insider threat program gap No behavioral analytics, no access anomaly monitoring for contractors Deploy UEBA, implement contractor access reviews, enforce least privilege for physical access

What Went Right

Control Impact
SQL Server audit logging Provided complete record of PHI queries — enabled accurate breach scope assessment
RADIUS authentication logging Captured MAC address mismatch — key evidence for credential misuse
Badge access logging Correlated technician's physical presence with evil twin deployment/retrieval times
EDR network scan detection Detected the scan (even though investigation was delayed 4 hours)

ATT&CK Navigator Mapping

Technique ID Technique Name Phase
T1040 Network Sniffing Reconnaissance / Credential Access
T1557.002 Adversary-in-the-Middle: ARP Cache Poisoning Credential Access
T1557.001 Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning Credential Access
T1078 Valid Accounts Initial Access / Persistence
T1021.001 Remote Services: Remote Desktop Protocol Lateral Movement
T1083 File and Directory Discovery Discovery
T1005 Data from Local System Collection
T1567 Exfiltration Over Web Service Exfiltration


Scenario Debrief

Operation Air Bridge demonstrates that wireless network security remains a critical and often underestimated attack surface, particularly in healthcare environments where medical device constraints force compromises in authentication and segmentation. The insider threat dimension adds complexity: a trusted contractor with physical access can deploy attack infrastructure in locations that network-only monitoring cannot detect. The combination of evil twin credential capture, legacy database permissions, and unrestricted guest network egress created a path from wireless access to PHI exfiltration that bypassed every security layer. Defense requires WIPS deployment, migration to certificate-based authentication (EAP-TLS), NAC enforcement, database access governance, and recognition that wireless connectivity complaints may be security incidents — not just "interference."