Case Study 1 — The Incognito That Wasn't

A departing research associate exfiltrates client data on their last afternoon, using private browsing the whole time and telling HR there would be "nothing to find." The persistent profile is indeed clean. The six recorders below and around the browser reconstruct the entire session anyway — a sibling to the chapter's anchor case, won not from history but from everything history is not.

Background

A contract research organization (CRO) runs assays for pharmaceutical clients under strict confidentiality terms. A research associate gives two weeks' notice to join a competitor. On the associate's final Friday, a data-loss-prevention alert fires late — a large outbound transfer over the lunch hour — but the on-host browser history for the relevant account shows an ordinary, unremarkable afternoon. When confronted, the associate is calm: "I only ever used a private window. There's nothing to find." The CRO's general counsel, who has read this book's chapter on insider matters, is unmoved and engages you for an internal investigation.

Crucially, the responding analyst followed the order-of-volatility discipline from Chapter 15 — Live Response and Triage: before the workstation was powered down, they captured a RAM image and a live triage set (DNS cache, SRUM, prefetch), then imaged the disk and hashed it per Chapter 14 — Forensic Acquisition. That sequence decides this case. The question for the examination is narrow: did this account move client data off the machine during the lunch hour, despite the clean history?

The investigation

You begin with the persistent profile and confirm the associate's claim — as far as it goes. The Chromium History, Cookies, Cache, and autofill stores for the account show nothing during the 12:00–13:00 window. This is not a failure of evidence; it is private browsing working exactly as designed. Incognito runs the session against an in-memory profile that is discarded when the last private window closes, and it never writes to the databases you just opened. The clean history is consistent with guilt and with innocence alike. It is also irrelevant, because the session left its mark on six layers the browser does not control.

The OS DNS resolver cache was captured live. It still listed three domains resolved during the lunch hour: wetransfer.com, a personal mail.proton.me, and a consumer file-locker. Private mode does not touch the operating system's resolver — the machine looked up those names on the associate's behalf and remembered them until the next reboot or TTL expiry.

Get-DnsClientCache (captured live, 12:58 local) — excerpt
Entry                 Data              TTL
wetransfer.com        104.x.x.x          41
api.wetransfer.com    104.x.x.x          38
mail.proton.me        185.x.x.x         112

SRUM turned "something happened" into a quantity. The System Resource Usage Monitor database SRUDB.dat, parsed with SrumECmd, holds per-application, per-user network totals. For the associate's SID, msedge.exe recorded roughly 2.3 GB sent in the 12:00–13:00 bucket, against a multi-week daily baseline of about 30 MB. A fifty-fold spike, attributed to one application and one user, in one hour, is not an artifact you can wave away.

Memory was the private session's transcript. Analyzing the RAM image per Chapter 22 — Memory Forensics, you recovered, straight from the browser process heap, the full WeTransfer upload URL, the recipient address (the personal Proton account), and a list of 23 filenames matching client protocol and result documents by naming convention. The "private" session existed in plaintext in RAM the entire time it ran; the capture simply read it out.

strings over the carved chrome/msedge heap (excerpt, redacted)
https://wetransfer.com/downloads/<id>/<key>
to: <associate>@proton.me
Assay_<ClientA>_Protocol_v3.docx
Results_<ClientA>_2024-Q1.xlsx
... (23 client-document filenames total)

The pagefile corroborated memory on disk: strings over pagefile.sys recovered URL fragments and several of the same filenames, RAM that had been paged out earlier in the session. Favicons added a quiet confirmation — the persistent Favicons database still held an icon fetched from wetransfer.com, because favicon caching wrote to the persistent store even though the page itself did not. And the network never forgot: the egress proxy's own log recorded a 2.3-GB HTTPS POST to wetransfer.com from the workstation's address, timestamped inside the same window, matching SRUM to within the minute (Chapter 23 — Network Forensics).

Assembled, the layers tell one story:

CRO-WS — RECONSTRUCTED "PRIVATE" SESSION (local time)
12:04  DNS resolves wetransfer.com / mail.proton.me        [live DNS cache]
12:05  msedge.exe begins large upload                       [SRUM bucket start]
12:0x  HTTPS POST 2.3 GB → wetransfer.com                   [proxy log]
12:4x  23 client filenames + upload URL in browser heap     [RAM image]
12:50  msedge.exe upload tapers; ~2.3 GB sent this hour     [SRUM]
--     persistent History / Cookies / Cache: clean          [profile — incognito]

Before writing, you separate finding from inference exactly as the anchor case demands. You can state, with sourcing, that during the lunch hour the associate's account uploaded approximately 2.3 GB to a personal file-transfer service, that the browser's memory held 23 filenames matching client documents, and that the destination was a personal Proton address. You can not state, from these artifacts alone, that the contents of those uploads were the client files rather than identically named decoys — the upload payload itself is not on the machine — and you say so. This is the sibling of the chapter's anchor case (the engineer who ran CCleaner on WS-ENG-04): one suspect cleared history, the other used incognito; both believed they had silenced the machine, and both were undone by the recorders they did not know to address. As theme three puts it, turning off one recorder does not silence the other six.

The analysis

  1. Incognito protects the profile, not the system. The clean History was private browsing working as designed — and therefore proved nothing either way. The case lived entirely in the layers the browser does not control.
  2. Order of volatility decided solvability. Because the analyst captured RAM and the DNS cache before power-off (Chapter 15), the two richest sources survived. A cold shutdown would have erased both, leaving only SRUM and the proxy log.
  3. SRUM quantifies what history cannot. Per-application byte counts converted a vague DLP alert into "2.3 GB, fifty times baseline, msedge.exe, this user, this hour" — a number a fact-finder can weigh.
  4. Memory is the private session's transcript. The upload URL, recipient, and filenames lived in the browser heap in plaintext; the RAM image read the session the persistent profile never recorded.
  5. Correlate independent recorders. DNS cache, SRUM, memory, pagefile, favicons, and the proxy log agree. Any one is a lead; six that converge is a finding — and the disagreement of none is itself reassuring.

Discussion questions

  1. List the six layers from this chapter that survive a private-browsing session, and state which two were decisive here and why.
  2. Explain how the order-of-volatility decision in Chapter 15 determined whether this case was solvable. Which two artifacts would a straight power-off have destroyed?
  3. SRUM gave a byte count but no filenames; the memory image gave filenames but is volatile and was nearly lost. Explain how each source compensates for the other's weakness, and why neither alone would have been as strong.
  4. ⭐ The associate's counsel argues the 2.3 GB was a legitimate personal cloud backup of non-client data. Using only artifacts in this case, construct the rebuttal — then name the single additional artifact that would most strengthen the exfiltration finding.
  5. Distinguish precisely what you can report as a finding versus an inference about whether client trade secrets were exfiltrated, and tie your answer to the report discipline of Chapter 26 — The Forensic Report.