Off the Clock: Catching Insider Data Exfiltration in IPDR and Proxy Logs

A pharmaceutical company suspected an employee had exfiltrated a clinical trial dataset before resigning, but a forensic review of his company laptop showed no unusual local file activity — because the employee had reportedly used a personal device on the guest Wi-Fi network to perform the upload, bypassing endpoint monitoring on his managed laptop entirely.

• IPDR logs from the corporate ISP for the guest Wi-Fi subnet (14-day window)
• Proxy server logs (forced web proxy on the corporate network)
• Guest Wi-Fi DHCP lease logs
• Cloud storage provider access logs (obtained via legal request)

• Python (pandas) for log parsing and timeline correlation
• Splunk (log aggregation and search)
• Wireshark (spot-verification of retained packet samples)

• Because the corporate network used Carrier-Grade NAT (CGNAT) for guest Wi-Fi, individual devices shared a small pool of public IP addresses; IPDR records alone could not identify a specific device without the corresponding NAT port-translation table.
• Obtained the router/firewall's NAT session logs, which recorded the internal private IP and source port alongside the translated public IP and port for every session — the critical link IPDR alone does not provide.
• Joined IPDR public-IP/port/timestamp records against the NAT session log on (public IP, public port, timestamp) to resolve each session back to an internal private IP address.
• Cross-referenced the resolved private IP against DHCP lease logs to identify the MAC address and, from the device's user-agent string in proxy logs, fingerprinted it as a personal Android device rather than an issued corporate asset.
• Filtered proxy logs for that internal IP for large-volume, sustained upload sessions rather than typical browsing traffic, isolating a single 40-minute session with several hundred megabytes of outbound data volume.
• Matched the destination domain in the proxy logs to a personal cloud-storage provider's upload endpoint, then used a legal request to that provider to confirm an account matching the employee's personal email had received a file upload at the corresponding timestamp.
• Built a single second-by-second timeline correlating DHCP lease start, NAT session creation, proxy upload volume, and the cloud provider's server-side upload confirmation to remove any ambiguity about device attribution.

• A NAT session log entry linking the flagged public IP/port/timestamp combination to a specific internal private IP and MAC address
• A DHCP lease record tying that MAC address to a personal Android device, with a hostname string set by the employee that included his own first name
• A 380 MB outbound proxy session to a personal cloud-storage upload endpoint, 41 minutes long, ending six minutes before the employee's last office-door badge swipe that day
• Cloud-provider server logs confirming a matching file upload to an account registered under the employee's personal email

• IPDR alone was a dead end without the NAT session table — this is the single most common failure mode in IPDR-based investigations, and the case only progressed once the NAT logs were specifically requested rather than assumed to be part of a standard IPDR production.
• The guest network's IPDR and DHCP logs were retained on a rolling 14-day window; the request had to be made urgently to avoid the specific session aging out of retention.
• The employee's personal device was never seized, so all findings relied entirely on network-side and cloud-provider-side records — this had to be clearly documented as network-derived evidence rather than device-derived evidence in the final report.

The correlated timeline was sufficient to support both an internal disciplinary finding and a referral for a civil trade-secret misappropriation claim. The cloud provider's records, obtained through legal process, independently corroborated the network-side findings.

IPDR without NAT session logs is frequently insufficient to identify an individual device — always request NAT/port-translation tables alongside IPDR from the outset. Insider threats increasingly route around managed endpoints entirely, making network- and cloud-side evidence collection a first-class part of the investigative toolkit, not a fallback.