Minutes before a planned containment cut, appliance egress spikes and an inbox rule is deleted. What do you conclude?

## Read each record for exactly what it proves **The flow export.** A NetFlow or IPFIX record carries the five-tuple (source and destination address, ports, protocol), byte and packet counters and timestamps. It carries no payload. So the burst above supports a strong, narrow claim: roughly six gigabytes left an internal address toward 203.0.113.44 over ten minutes, against a baseline two orders of magnitude lower. It does not support the claim that six gigabytes of customer data were stolen. If the traffic was TLS, a passive sensor could have recorded the SNI and the certificate subject, but not the body; without a sensor you have volume and destination only. Say this out loud in an interview — overclaiming from flow data is one of the most common wrong answers in the domain. **The audit entries.** The mail platform recorded the rule being created on 2 March and removed at 17:52 on 14 March, minutes before your cut. Two things follow. First, the deletion does not erase the creation: you still hold the rule's name and its parameters because that record was written and exported when it happened, so you can still describe what the rule did. Second, the deletion is itself evidence, and it is timestamped. Rule creation and rule deletion are both audited operations in a mail platform's trail, which is why this pair is such a useful joined view. ## The inference: they know A dormant persistence being tidied up at the same moment egress spikes is not a coincidence. The reasonable conclusion is that the adversary has learned they are being hunted and is compressing their plan: take what is staged, then remove what proves they were there. This is the escalation and destruction pair of reactions arriving together, and ATT&CK describes the removal half as Indicator Removal (T1070) and the mail rule itself as an email forwarding rule (T1114.003). The important consequence is not emotional but operational: an assumption your plan rested on — that they had not noticed — is now false, and every other assumption built on it deserves a second look. In particular, if they knew far enough in advance to prepare this burst, they may have prepared a fallback you never enumerated. ## What you do about it **Do not pause the cut.** Every minute of hesitation is a minute of transfer at three gigabytes per five-minute bin. The reaction is an argument for cutting now, not later. **Preserve before you remediate.** The appliance is about to be rebooted, reflashed or replaced, and your own remediation will destroy its volatile state and possibly its local buffer. Capture what you can — configuration, running state, the logs already centralised — before the destructive step. The same applies to the mail platform: export the audit records covering the rule's life now, while you still have a case, rather than relying on a retention window you have not checked. **Measure the loss honestly.** Report volume, destination, duration and the fact that content is unknown. If you have proxy or sensor data that names the destination host, add it. If you have file-access telemetry on the systems that fed the appliance, that is what narrows 'six gigabytes' into 'these repositories'. Resist converting bytes into a record count without a basis; that number will end up in a notification. **Work backwards to the tip-off.** The 17:52 timestamp is your anchor. What did you do in the hours before it? A password reset, a query against the appliance's management interface, a message sent over a channel they can read, a firewall change staged early? Identifying the tip-off matters for this incident because it tells you what else they might have inferred, and it matters afterwards because it is a concrete, teachable finding. **Reassess scope.** Add the missed-foothold hypothesis explicitly to the case: if there is a third home, the cut will not remove it, and the post-cut watch is what will surface it. ## The trap in this question The trap is to declare that the intrusion is now understood because you can see it moving. You can see bytes and you can see an operator tidying up. You cannot see contents, you cannot see everything they hold, and a visible reaction on two surfaces says nothing about a third.