An incident lead wants the payload of an implant's mirrored TLS session - what do you tell them?
answer
- never existed, not merely not retained
- give them what the copy does support
- bound the window, name the host
- plaintext lives at the endpoint
- no evidence observed is not nothing left
basics
~20 sThe plaintext never existed anywhere on the network path, so no retention setting or budget recovers it. Give them what the copy does support - volume, direction, destination, timing - and point the payload question at the endpoint.
solid answer
~50 sSay the hard part first and say it precisely: this is not `we did not keep it`, it is `it was never readable at any point on the wire, and no budget or storage change recovers it`. Leads make containment and disclosure decisions on that distinction, so leaving it fuzzy is worse than saying no. Then give them what the mirror genuinely supports: which virtual NIC, to which address, how many bytes each way, when it started, when it stopped, and what the timing pattern looks like - which is often enough to bound the window and scope the hunt. Then redirect the payload question to where plaintext actually lives: the workload itself, its process state and application logs. Finally, make sure the report never turns `no readable payload` into `no data was lost`. Those are different claims and only one of them is supported.
go deeper
Know the difference between evidence you did not keep and evidence that never existed, and never promise a decryption that the protocol forecloses.
Be able to list the specific fields the mirrored record supports and translate them into a scope and a time window for the responders.
Demonstrate that you can deliver bad news precisely under pressure, redirect the payload question to the endpoint, and police the wording of the finding.
Own the consequence at the organisation level: what the estate can and cannot evidence about egress becomes a disclosure posture, and it should be decided before an incident, not during one.
## Why the wording matters more than it looks An incident lead hearing *we do not have the payload* will reasonably ask three follow-ups: can you get it, can you get it if we pay, and can you get it for the next few hours. If your answer is loose, all three get asked repeatedly during the worst hours of an incident and each one burns time. The precise statement closes them at once: the session used forward-secret key exchange, so the plaintext existed only inside the two endpoints, one of which is the adversary's. Nothing on the network path - mirror, sensor, capture store - ever held a readable copy, and nothing bought later reconstructs one. It is a property of the traffic, not a choice your team made about retention. ## What you can assert from the mirrored record Be generous with what you *do* have, because it is more decision-relevant than people expect: - **Scope by source.** The mirror names the virtual NIC, so you know which workload, which subnet and which owner. - **Scope by destination.** One external address, or many; whether other workloads talked to the same address, which turns one host into a candidate blast radius. - **Volume and direction.** Tens of megabytes outbound against a trickle inbound is a different shape from a control channel, and that shape guides whether you are chasing a data-loss question or a persistence question. - **A time window.** First flow and last flow bound the exposure period, which is what scoping, log pulls and legal timelines all hang on. - **Pattern.** Regular small sessions with jitter read as scheduled check-ins; a single long transfer reads as a staged push. ## What you must refuse to assert The copy cannot tell you what the bytes were, which process produced them, whether they were encrypted a second time before leaving, or whether the SNI names the party that received them. It also cannot tell you that nothing sensitive left. This is the direction-of-claim trap the domain punishes hardest: *no readable payload* is a statement about your visibility, not about the adversary's take. A report sentence like `no evidence of data exfiltration was observed on the network` is defensible; `no data was exfiltrated` is not, and if it reaches a regulator or a customer on your say-so, you own it. ## Where the plaintext does exist One endpoint of the session is inside your estate, and that is where you redirect the lead. Before it entered the socket, the data was in the workload's memory, on its filesystem, in whatever staging area produced it, and it may be described in the application's own logs. The host-side investigation belongs to the incident team and its forensics practice, but you are the one who has to point at it, and you should point early - the mirror's residue is what tells them *which* host and *what window* to look at, so the two halves complement each other rather than substitute. ## The emergency-decryption ask Expect this: *turn on decryption for the rest of the incident*. Three things to say. It recovers nothing about the session already gone, because forward secrecy is retroactive protection. Standing up a terminating position under time pressure puts a new device in the production traffic path mid-incident, with an outage risk that lands on someone who did not plan for it. And it is not quiet - an adversary whose client suddenly sees a substituted certificate chain learns that you are watching and that you have moved, and a pinned client simply fails, taking a business flow with it. The right time to have that argument was the design review, and the right thing to do now is put it on the list for one. ## What good looks like Hand the lead three artefacts: the flow residue as a timeline, an explicit written statement of what the network position can and cannot evidence, and a named pivot for the payload question. Then, when the incident closes, make sure the lesson recorded is the architectural one - the estate has no readable egress payload by design - rather than a vague action item about buying more capture.
- The lead asks whether keeping full packets from the start would have changed the answer.No. Full capture stores the same ciphertext; it improves your ability to re-derive metadata you did not extract at the time and to prove exactly what crossed the wire, but the records stay opaque. It is worth buying for reconstruction and for disputes about what was sent, never as a route to plaintext.
- What sentence do you insist on in the incident report?Something of the form: network telemetry evidences an outbound transfer of roughly N megabytes to address X between T1 and T2 from host H; the session was encrypted with forward secrecy and no content is recoverable from network sources; any determination of what was transferred must come from host-side evidence. It states the finding, its limit, and the pivot.
- Another team says the flows look like normal backup traffic. How do you settle it?Not from the flow record alone, because volume and shape are exactly what a backup agent produces. Settle it at the source: which process owned the socket, whether the destination is a sanctioned service, and whether the client fingerprint matches the backup software's usual stack. The mirror gives you the question and the host gives you the answer.
saying these in an interview costs you the question
- Promises to decrypt the capture later with the right key
- Says we did not retain it instead of it was never readable
- Lets no readable payload become no data was lost
- Proposes standing up interception mid-incident to see the past
- Offers only the limitation and none of the residue