A national CERT says one of your public IPs attacked another company at 02:11 UTC — what do you establish first?

## What an outside notification is, and what it proves An outside notification is somebody else telling you that your estate did something you never saw. It arrives from a national CERT, a law-enforcement contact, an upstream provider or another victim, and it usually arrives with less evidence than you want, because the reporter is protecting a source, an ongoing operation or another victim's confidentiality. Get the direction of the claim right before you do anything else. The tip proves that **an outside observer saw traffic that they attribute to an address of yours**. It does not prove you were compromised, it does not prove which host was involved, and it certainly does not prove what the traffic contained. Equally, the fact that no detection of yours fired proves nothing: your rules only cover what you collect, and an outbound session to an address nobody had flagged is exactly the shape of activity a mature SOC still misses. Both errors — treating the tip as a verdict, and treating your own silence as a refutation — are the standard way this scenario is failed in an interview. ## The five fields that make the report actionable Ask for these explicitly, and ask in writing: - **Timestamp and timezone.** Reporters frequently send local time, or send UTC without saying so. An hour's error moves you past a DHCP lease boundary or a NAT table rollover and you map the wrong host. - **Your public address**, and confirmation of the window it was observed in. - **The source port.** This is the field juniors skip, and it is the one that makes the mapping possible: many hosts share one public address, so the NAT translation is only unique on the combination of address, port and time. - **The destination address and port**, and the protocol. - **The direction** — were you the source of the connection or the destination? A report that your address *attacked* someone means outbound sessions from your estate, which is a very different search from inbound scanning against you. ## Resolving a public address inward The records that answer this are boring perimeter records, not detections: - **Edge firewall / NAT gateway session logs.** These carry the pre-translation internal address and port alongside the post-translation public address and port. Matched on source port and second, they identify the internal address. - **Proxy logs**, if egress is proxied — these additionally give you the requesting host and often the user and the URL. - **DHCP leases** or a static inventory, to turn the internal address into a named host at that time. On a wireless or VPN pool the lease is short and the mapping is time-sensitive. - **Cloud address-assignment history**, if the public address is an elastic or NAT-gateway address: those get reassigned between accounts and workloads, so confirm which resource held it at 02:11 and not merely which holds it today. - **Address allocation records**, to confirm the range was still yours in that window. Reassigned ranges produce a surprising number of false reports. ## What the record you find does and does not say Suppose you find the session. A flow or firewall session record carries the five-tuple, byte and packet counts, and timestamps — and no payload at all. It tells you bytes moved between two endpoints; it does not tell you what they were, which process opened the socket, or which human was at the keyboard. The firewall has no user attribution unless identity-aware policy is in place. So the honest conclusion at this stage is: *a session matching the report originated from host X at 02:11 UTC.* To go further you pivot to the host: endpoint process telemetry for that window (which process held the socket, its parent, its command line), interactive logon records for who was on it, and scheduled-task or service state. If the host is a jump box or a management server, that pivot usually matters far more than the traffic itself. ## What not to do in the first hour Do not reimage or reboot the identified host — you would destroy the memory and process state that answers the next question. Do not contact the destination organisation directly. Do not close the ticket because your SIEM has no hits; that finding belongs in the write-up, not in a verdict. And preserve immediately: put a legal-style hold or an export in place for the firewall, proxy and endpoint data covering that window, because the default retention on perimeter logs is often days and the report is often weeks old.