Egress That Doesn't Add Up

Why the two numbers can legitimately differ

• Flow records count bytes at L3/L4 for all egress, including TLS handshake/retransmit overhead and any traffic that never reaches the proxy.
• Proxy logs only record sessions the client actually sent to the proxy. A PAC-file bypass, a non-proxy-aware application, or a direct-to-internet rule on that VLAN produces flows with no proxy log at all.
• Double counting is possible if the collector exports both ingress and egress directions of the same session.

Test order (cheapest discriminating test first)

1. Query the proxy for the exact destination IP and for the SNI/hostname. If the destination never appears, the traffic bypassed the proxy - which is the worse finding, not a logging bug.
2. Check the firewall session table / L3 rule set for that VLAN: is there a permit to any external destination that skips the proxy?
3. Only then consider flow accounting artifacts (direction duplication, sampling multiplier misconfigured on the exporter).

Judgement Do not assume 'proxy is just missing data.' A 4.3 GB gap on a host with no EDR is a possible exfiltration, and the proxy being silent is evidence of a bypass, not an alibi for the host. Escalate on the flow data, and treat the proxy's silence as a second finding about egress control.

1. Isolate at the network layer, do not power off. Disable the switch port or apply a deny ACL. Powering down destroys RAM, which is the only volatile evidence on a host with no EDR, and if the disk is not encrypted you also want a clean image. Isolation first also stops any live C2 while preserving state.

2. Acquire memory, then a disk image, before remediation. Memory gives you process lineage, injected code, and any in-memory key material the malware used. Disk comes second because imaging is slow and you already have containment.

3. Resolve the business dependency separately from the incident. The reconciliation workbook is a business-continuity question, not a forensic one. Pull the last known-good copy from the file server or backup, verify it with Finance, and give the analyst a clean loaner. Do not let a 36-hour deadline pressure you into returning the original host to service.

Reasoning Ordering puts containment before collection (stop the bleeding, but preserve state rather than destroy it) and separates 'restore the business function' from 'investigate the host' so the two don't get traded against each other under time pressure.

Match each question to the source that can actually answer it

• Who else talked to this destination? NetFlow, but you only have 7 days. Query by destination IP, then by /24 and by ASN, since infrastructure rotates.
• Who else resolved the new domain? DNS gives 14 days - a longer horizon than flow, so use DNS to generate candidate hosts and then check whether flow confirms them inside its window.
• Who else beaconed with periodicity? Flow only, 7 days. Compute inter-arrival intervals per host; low-and-slow beacons may be invisible at this retention, so state that limitation explicitly rather than reporting 'no other hosts.'
• Who was on which address? DHCP at 90 days, because 10.20.14.87 may have belonged to a different machine three weeks ago.

Judgement Retention asymmetry means your negative findings are weak. Report conclusions with the window they were drawn from ('no other internal hosts contacted this /24 in the last 7 days of flow'), and use the DNS and DHCP longer windows to hunt for a broader campaign. Escalate the retention gap as a control finding: 7 days of flow is not enough to investigate a 30-day dwell time.