# Network Forensics Summary — August 5, 2026

## What happened

At approximately 1:50 AM PDT on August 5, 2026, the operator (Q) observed a sustained, encrypted STUN session flowing from her MacBook Pro (M5) to an Amazon Web Services endpoint. The traffic was growing — 1.2 MB and climbing — with no obvious explanation. She initiated a forensic investigation. What started as a single suspicious network connection turned into the discovery of a coordinated Wi-Fi attack against her home network.

## The investigation

### Phase 1: Identifying the STUN traffic

The initial STUN session was traced to Slack Helper (PID 936), which was maintaining a WebRTC TURN relay connection to an EC2 instance in AWS us-east-1. The upload:download ratio was 23:1, which initially appeared alarming — far too asymmetric for normal network behavior.

After Q confirmed she was on an active Slack video call with both cameras on, the asymmetry was explained by Slack's split-transport architecture: outbound video travels via UDP through a TURN relay server, while inbound video arrives via TCP through CloudFront. Examining both channels together showed roughly balanced media exchange (~1.4:1), consistent with a two-way video call.

**Verdict: Accounted for.**

### Phase 2: The VS Code mystery

Q provided a VS Code output log showing extensive git activity at 01:38 AM — repository scanning, branch comparison, and diff operations against the Ares repository. She hadn't used the device to code since May 22.

Investigation revealed that VS Code (PID 648) had been running as a background process since the last system boot on May 24 — 73 days earlier. The machine had never been rebooted. When Q opened the Claude Code extension to start this investigation, VS Code's extension host restarted, triggering the built-in git extension to perform a full scan of the workspace. The log activity was from this session.

**Verdict: Accounted for — VS Code was a zombie process, and the git activity was triggered by this conversation.**

### Phase 3: Mapping the network

A full sweep of the Styx LAN (192.168.10.0/24) initially surfaced several unidentified devices. Systematic identification using port scanning, HTTP/SSH banner grabbing, Bonjour discovery, and ARP/NDP analysis resolved all of them:

- 192.168.10.135 — **Dragon** (Tetramorph apparatus, "The Ismenian Dragon, Eagle Face"), Debian 13
- 192.168.10.212 — **Synastry** (RISC-V sovereign git host), Ubuntu
- 192.168.10.220 — **JetKVM** (KVM-over-IP console for rack management)
- 192.168.10.222 — **Quartz** (Tetramorph apparatus, "The Rose Quartz Witness, Ox Face"), Debian 13
- 192.168.10.194 — **ARES** (M2 MacBook), confirmed via Bonjour as `ares.local`
- 192.168.10.241 — **iPhone** (Q's primary phone)

One device remained unexplained: **192.168.10.165**.

### Phase 4: The mystery device at .165

This device exhibited unusual behavior:
- Responded to ARP (present at Layer 2) but dropped all ICMP pings
- No Bonjour/mDNS advertising
- Not in the Styx router's DHCP lease list
- All common ports closed except **62078** (Apple's lockdownd / Wi-Fi sync service)
- Used a randomized/private MAC address (`4a:21:74:3b:11:b2`)
- Apple's rapportd daemon on M5 had an active TCP connection to it

Port 62078 confirmed it was an iPhone. Q physically located the device: her old iPhone 12 Pro Max, plugged in and always on, connected to Venus 5.0 (the 5 GHz AP). It was signed into her own secondary Apple ID (AresTheAI@iCloud.com). The DHCP hostname "iPhone" (default) vs. the device name "Ares's iPhone" was explained by iOS Private Wi-Fi Address mode, which sends a generic hostname to prevent network fingerprinting.

The M5's lockdown directory (`/var/db/lockdown/`) was empty — no iPhone had ever been paired with the M5 for Wi-Fi sync. The phone was paired with a different Mac. The 70 pkt/sec traffic was attributed to iCloud sync and broadcast noise on a busy 8-device LAN.

**Verdict: Q's own device. Accounted for.**

### Phase 5: The cameracaptured anomaly

A system daemon, `/usr/libexec/cameracaptured` (PID 547), was discovered consuming 15-17% CPU continuously — and had been doing so for the entire 73-day uptime. It had accumulated 2,089 hours of CPU time (more than one full core's worth sustained), yet had **zero open file descriptors**, zero network connections, and produced zero log entries. Its process status was `Rs` (actively running, not sleeping), and it was holding a power assertion preventing the machine from sleeping.

Three processes had Apple's CoreMediaIO camera framework loaded: Slack (active video call), Google Chrome (WebRTC-capable), and avconferenced (Apple's system conferencing daemon, idle). The camera daemon entered a spin loop at some point after boot when an application opened the camera and disconnected without properly releasing the session. Boot-week logs had been pruned after 73 days, making it impossible to determine the original trigger.

**Verdict: macOS daemon bug. Not a security threat, but burning ~17% CPU and preventing sleep for 73 days.**

### Phase 6: The AzureWave probe

Q discovered Styx router hostapd logs showing a device with MAC `e8:fb:1c:65:20:73` repeatedly attempting to authenticate to Venus 5.0 on **August 2, between 1:33 PM and 7:16 PM PDT**. Eight failed attempts over six hours. The device did not have the correct Wi-Fi password.

OUI lookup identified the manufacturer as **AzureWave Technology Inc.** — a company whose Wi-Fi modules are used in laptops and USB adapters, including models popular for penetration testing due to monitor mode and packet injection support. The MAC was factory-assigned (globally unique), not randomized — meaning it was real hardware, not a phone doing casual probing.

Venus 5.0 operates on 5 GHz with 80 MHz channel width. Effective range through walls is approximately 15-30 meters. Whoever was probing was physically close to Q's apartment.

### Phase 7: The deauthentication attack

ARES netwatch alerts revealed that on the night of August 4-5, three of Q's devices were forcibly disconnected from Venus 5.0 in rapid succession:

- **11:56:16 PM** — iPhone disassociated, reassociated 1 second later, disassociated again 4 seconds after that
- **2:53:43 AM** — M5 disassociated, reassociated 1 second later
- **2:54:02 AM** — iPhone 12 disassociated, reassociated 4 seconds later

Q confirmed she did not initiate any of these disconnections. The pattern — disassociation followed by automatic reassociation in 1-4 seconds, across multiple devices in one night — is the textbook signature of a **802.11 deauthentication attack**. The attacker sends forged deauth frames spoofing the AP's BSSID, forcing clients off the network. When the clients automatically reconnect, they perform a fresh WPA 4-way handshake, which the attacker captures with a monitor-mode adapter.

### Phase 8: Proving the MAC was spoofed

Claude on the M2 MacBook identified the AzureWave MAC as belonging to **Quartz's onboard Wi-Fi adapter** (wlan0, brcmfmac driver). This was confirmed via `ip link show` and `iw dev` on Quartz. An initial conclusion that the probes were simply Quartz misconfigured was challenged: MACs can be spoofed.

Six diagnostic commands were run on Quartz. The results were decisive:

1. Quartz's Wi-Fi radio was **administratively disabled on July 31 at 11:08 UTC** by user `aphroqite` (via `systemctl disable --now wpa_supplicant` and `ip link set wlan0 down`).
2. The radio is **still down today**.
3. Quartz's syslog archive covering August 2 is complete (no retention gaps) and contains **zero wireless entries** for that date.
4. Quartz's auth.log for August 2 shows no one interacted with wlan0.

The Styx router's clock was verified against M5 — both synchronized to the second, both in PDT. No timezone offset, no drift. The August 2 timestamps in the hostapd logs are genuine.

**Quartz's radio was provably down when the probes occurred. The MAC was spoofed.**

### Phase 9: How the MAC was harvested

Before July 31, Quartz's Wi-Fi adapter had been failing to associate with Venus 5.0 in a continuous loop for approximately seven weeks. The syslog archives recorded **4,290 failed association attempts**, each one broadcasting Quartz's MAC (`e8:fb:1c:65:20:73`) in the clear in probe request and association frames.

The BSSID that Quartz was targeting (`BE:D6:CF:14:8A:25`) was verified against the Styx router's wireless configuration — it matches Venus 5.0's actual 5 GHz BSSID exactly. So Quartz was hitting the real AP, broadcasting its real MAC, thousands of times, for weeks. Anyone with a passive Wi-Fi receiver within radio range could have captured the MAC trivially.

The attacker chose this MAC because it had a plausible history: if anyone investigated probes from `e8:fb:1c:65:20:73`, they would find it belongs to a device on Q's own network that had a documented history of probing Venus 5.0. A cursory investigation would conclude "misconfigured apparatus" and close the case. This is exactly what nearly happened.

## The full attack chain

| Date | Activity | Phase |
|------|----------|-------|
| Jul 12 – Jul 31 | Quartz broadcasts `e8:fb:1c:65:20:73` 4,290 times in failed Venus 5.0 association attempts | MAC harvestable by passive listener |
| Jul 31 | Quartz's radio disabled. MAC goes silent. | Adapter killed |
| **Aug 2, 1:33–7:16 PM** | **Spoofed MAC probes Venus 5.0. 8 failed auth attempts over 6 hours.** | **Reconnaissance under cover** |
| **Aug 4, 11:56 PM** | **iPhone deauthed from Venus 5.0 twice in 5 seconds** | **Handshake capture** |
| **Aug 5, 2:53 AM** | **M5 deauthed from Venus 5.0** | **Handshake capture** |
| **Aug 5, 2:54 AM** | **iPhone 12 deauthed from Venus 5.0** | **Handshake capture** |

## Current risk

The attacker likely holds up to three captured WPA 4-way handshakes. The PSK protecting both Venus 5.0 and Mars 2.4 is 10 characters, uppercase alphanumeric — approximately 3.6 trillion combinations (36^10). This is within reach of offline GPU-based cracking with tools like hashcat. Venus 5.0 uses `sae-mixed` encryption (WPA2/WPA3 transitional mode), which permits WPA2 fallback; any handshake captured during a WPA2 exchange is vulnerable to offline attack.

Additionally, Quartz's wpa_supplicant service is still running against the downed interface, and the Venus 5.0 netplan configuration (including credentials) remains on disk. If the interface is ever brought back up, the broadcast storm resumes and the MAC becomes harvestable again.

## What was not found

- No remote access tools (TeamViewer, AnyDesk, VNC, etc.) on M5
- No suspicious launch agents or login items
- No unauthorized logins to M5 (continuous session since May 24)
- No unknown processes or unexpected network connections on M5
- All devices on the Styx LAN were identified and accounted for
- DNS resolution confirmed through Q's own Sovereign Door DNS server