Naming a Workstation From NetFlow and a Fast Clock

Step 1 - normalise to UTC. 2025-03-09 is the US spring DST transition: clocks jump from 02:00 EST to 03:00 EDT. So 03:47:12 local is EDT (UTC−4) = 07:47:12 UTC. Note that local times between 02:00 and 03:00 on that date do not exist - if any log line falls in that window, the device's timezone handling is wrong and every other timestamp from it is suspect.

Step 2 - find the NAT session. Search the firewall log for the public IP:port of the outbound connection in a window of a few minutes around 07:47:12 UTC. NAT maps internal-IP:port to public IP:port. The port matters more than the IP: a busy host holds many concurrent sessions.

Step 3 - correct the DHCP clock. An 8-hour lease recorded at time T on a server 7 minutes fast was actually granted at T−7min. Convert before comparing.

Traps: eight-hour leases mean the address may have been reassigned earlier the same day, so you need the lease that covers the moment, not the nearest one; the /24 may also be shared with a VPN pool, so the IP may map to a remote worker rather than a desk; a reverse proxy or load balancer in front of the web server changes the source IP you see; and 1-minute NetFlow active timeouts give you coarse bounds only.

State bounds, not false precision. The tightest defensible statement combines the server timestamp (accurate to NTP), the NAT log (accurate to NTP, granularity of the log write), and the DHCP lease (accurate to ±7 minutes until corrected, then bounded by lease boundaries).

A defensible formulation: between 07:46 and 07:49 UTC on 2025-03-09, internal address 10.20.30.x held the NAT binding for the session that delivered the request; under the DHCP lease in force at that time, 10.20.30.x was assigned to MAC aa:bb:…, inventoried as workstation WKS-0141.

What could still make it wrong:

• MAC spoofing or a statically configured address that bypasses DHCP.
• Address reuse across a lease boundary within your uncertainty window.
• The mapped-drive or VPN pool sharing the same subnet, attributing a session to a desk that was empty.
• A rogue device behind the same NAT (a personal hotspot or a second machine on the same switch port).
• Log ingestion delays: the firewall may write the NAT record at session teardown.
• Clock drift outside NTP sync on any one of the three sources.

Say which of these you tested and which remain open. An attribution with a stated uncertainty and named residual risks survives cross-examination far better than a confident single IP address.

What NetFlow cannot tell you: payload, URLs, user identity, filenames, whether a transfer succeeded, or what was in it. It gives five-tuple, byte and packet counts, and start/stop times - enough to say a host talked to an address at a time for roughly a volume of bytes, not enough to say what was exchanged. A byte count is also not a file size: retransmissions, headers, and TLS overhead inflate it, so any 'they exfiltrated X MB' claim needs care.

The retention gap is itself a finding. You have 7 days of flow and 30 days of firewall logs. The earliest flows are already gone; anything between 7 and 30 days ago can only be reconstructed from firewall NAT records, which give the session but not the volume, and from host-side or server-side logs.

Report it:

• State the coverage window explicitly, with the date flows stop being available.
• Note that the absence of a flow for a period before that date is a collection limitation, not evidence that no communication occurred.
• Request preservation immediately for everything still retained - flow, firewall, proxy, DNS, and endpoint logs - and record that request with a timestamp, because the loss of data after a preservation request is a very different problem from its loss beforehand.