Case Study 2 — The IP Address That Accused the Wrong Person

A security team flags an employee for stealing data, builds the accusation on an IDS alert and a flow record, and gets someone suspended within a day. The technical "evidence" never carried the claim — the IP was shared, the upload was sanctioned, and no capture existed to prove content. A confident report, built on the chapter's exact mistakes, harmed an innocent person and exposed the company.

Background

A financial-services company runs a large non-persistent virtual desktop infrastructure (VDI) farm for its contractors. Dozens of contractor sessions share a small pool of network-address-translation egress addresses — 203.0.113.10 through 203.0.113.13 — so that, from the perimeter's point of view, many different humans appear to the outside world as the same handful of IPs. There is no authenticated forward proxy in the contractor path; web traffic egresses straight through the firewall's NAT. Monitoring consists of a Suricata sensor and NetFlow exported to a collector, with flow sampled at 1-in-1000 to save space, and a 24-hour rolling full-capture buffer that almost never gets reviewed.

One Monday, the security operations team sees a Suricata alert — ET POLICY class, "Mega.nz file-sharing in use" — on a flow from egress IP 203.0.113.11, alongside a NetFlow record showing roughly 2.3 GB outbound to a Mega IP over the weekend. A junior analyst maps 203.0.113.11 to a named contractor by consulting a DHCP lease table that, unbeknownst to anyone, is both stale and irrelevant to the NAT pool. Within hours a two-page memo concludes that the contractor exfiltrated 2.3 GB of client data to a personal cloud account over the weekend. The contractor is suspended that afternoon and walked out of the building. The memo reads, on its face, like the chapter's anchor exfiltration case. It is, in fact, the anchor case run backwards through every limitation the chapter warns about.

What the analysis got wrong

The findings were not invented; they were mis-attributed, over-interpreted, and unverifiable — and each flaw maps to a named pitfall from this chapter.

Error 1 — An IP address treated as a person. The entire accusation rested on equating 203.0.113.11 with one human. But 203.0.113.11 was a shared NAT egress address for the VDI pool: at any moment, ten or more contractor sessions were multiplexed behind it. The flow record's "source" was the egress IP, which identifies a network exit point, not a person. Worse, the analyst's IP→person mapping came from a DHCP lease table that governed the office LAN, not the NAT pool — so even the one link in the chain that was checked was checked against the wrong source. There was no authenticated proxy username to attribute the session — the very layer that, in the chapter's worked example, made the jrivera attribution sound was simply absent here.

WHAT THE MEMO ASSUMED              WHAT THE NETWORK ACTUALLY SHOWED
"203.0.113.11 = the contractor" -> 203.0.113.11 = a SHARED NAT egress for the
                                    VDI pool; 10+ sessions behind it at once;
                                    no authenticated username on the flow
"2.3 GB uploaded = client data  -> a 2.3 GB outbound transfer to a Mega IP
 stolen"                            occurred; flow carries NO content, so WHAT
                                    moved is unknown from the wire

Error 2 — An IDS alert reported as a finding. The Suricata signature was an ET POLICY rule — a policy-class alert that fires whenever Mega.nz is contacted at all. It is designed to flag a policy condition, not to prove malice or theft, and it false-positives by construction every time anyone legitimately touches the service. The memo presented "the IDS alerted" as if it established exfiltration. An alert tells you where to look; it is never, by itself, the conclusion (Chapter 27 — Expert Testimony is where that shortcut gets dismantled).

Error 3 — Flow volume inflated into content. NetFlow proved that ~2.3 GB went outbound to a Mega IP. It cannot, by its nature, prove what the bytes were. The memo's leap from "2.3 GB to a cloud service" to "2.3 GB of client data" asked a metadata-only record to carry a content claim it can never hold. No file was carved, no object reconstructed, no hash matched — because, as the next error shows, the data to do any of that was already gone.

Error 4 — No coverage, so nothing could be verified. By the time anyone tried to confirm the memo, the wire had forgotten. The 24-hour full-capture buffer covering the weekend had long since rolled over, so there was no PCAP to reconstruct the transfer or read whatever metadata survived. The flow was sampled at 1-in-1000, meaning the "2.3 GB" was a statistical estimate, not a measurement, and the per-session detail needed to separate one contractor's traffic from another's behind the shared NAT had never been recorded at full fidelity. The accusation was, quite literally, unfalsifiable — there was no evidence left to test it against, which is itself a reason it should never have been asserted.

When the contractor's representative pushed back, a senior examiner was brought in to actually verify the claim — and it dissolved. The internal VDI session-broker logs (the one source nobody had consulted) showed that during the weekend window, the session that egressed via 203.0.113.11 and reached Mega belonged to a different contractor account entirely, and that the transfer was a sanctioned project-data backup to the company's own enterprise Mega tenant, performed under an approved change ticket. The accused contractor had not even been logged in that weekend. The honest finding the original team could have written — a 2.3 GB outbound transfer to a cloud-storage service occurred from a shared VDI egress IP over the weekend; attribution to a specific user is not possible from network data alone and requires the VDI session logs; content is unknown because no capture covering the window survives — would have been unremarkable, accurate, and harmless. The memo that was written instead got an innocent person suspended, triggered a credible wrongful-suspension and defamation exposure for the company, and forced a formal apology and a review of the entire insider-threat process. The real cost was borne by a person who did nothing wrong (theme #6, the human cost is real).

The analysis

  1. An IP address is a locator, not an identity. NAT, CGNAT, shared VDI egress, VPNs, and proxies all sever the IP→person link. Behind one shared egress address sit many people; an IP identifies, at best, a network exit point at a moment. Tying activity to a person requires the layers the memo skipped — internal NAT/session logs, an authenticated account, and endpoint corroboration.
  2. A policy-class IDS alert is the start of an inquiry, not its conclusion. ET POLICY rules fire on a condition (a service was contacted), not on proven wrongdoing. Reporting "the IDS alerted, therefore theft" inverts the burden the signature was ever meant to carry.
  3. Flow proves volume and endpoints, never content. "2.3 GB to a cloud service" is not "2.3 GB of client data." Without a carved, hashed object, the nature of the bytes is unknown — and sampled flow makes even the volume an estimate, not a measurement.
  4. No coverage means no verification — and an unverifiable accusation should not be made. When the capture has aged out and the flow is sampled, you cannot reconstruct what happened. The professional response is to say so, not to fill the gap with the worst-case story.
  5. A confident report built on shortcuts harms real people. This is the mirror image of Case Study 1: there, disciplined corroboration across attacker-unreachable sources produced a finding that held; here, a single-source leap mis-attributed sanctioned activity to an innocent person. Same discipline, opposite outcome — and in this discipline you are paid to be defensible, because the cost of being carelessly wrong is borne by someone else.

Discussion questions

  1. Rewrite the memo's central sentence ("the contractor exfiltrated 2.3 GB of client data to a personal cloud account") into a finding the senior examiner could defend — preserving whatever the data genuinely supports while stating every limit.
  2. List, in order, the verification steps the original team should have taken before anyone was suspended. Which single source (consulted last, by the senior examiner) would have prevented the entire error, and why was the network data alone never going to be enough?
  3. Contrast this case with the chapter's worked anchor example, where attribution to user jrivera was sound. What specific architectural difference (present there, absent here) made attribution defensible in one case and baseless in the other?
  4. ⭐ Sampled flow (1-in-1000) and a 24-hour capture buffer both contributed to the failure. Design a monitoring posture for the VDI environment that would make a future exfiltration both detectable and attributable, and name the one log source that does the attributing work an egress IP cannot.
  5. The harm here fell on an innocent person and exposed the company to legal liability. Connect this outcome to the examiner's ethical duty in Chapter 28 — Ethics: what obligation does an analyst owe to the subject of an investigation before converting a lead into an accusation that triggers real-world consequences?