Engineer's AWS Lab Experiment Reveals How Easily Threat Analysis Can Go Wrong

A developer deliberately exposed a PostgreSQL database on the public internet within an AWS lab environment to simulate a cyberattack, piping VPC Flow Logs into Splunk for a partner to monitor from a security operations perspective. When reviewing the flow logs months later, the engineer discovered 28 source IP addresses in the dataset but had only documented one in the incident report — and misidentified it. The flagged IP, 10.0.1.179, was actually an internal RFC 1918 private address originating from within the engineer's own network, while a genuine external scanner at 136.35.186.87 conducting multi-port probes was overlooked entirely. Beyond the misidentification, 25 other external addresses had quietly probed 29 distinct ports — including Redis, VNC, Kubernetes, and NetBIOS — within minutes of the public IP going live, none of which were captured in the incident report. The exercise highlighted three common analytical blind spots: misreading IP address context, drawing conclusions flow logs cannot support such as authentication outcomes, and over-focusing on high packet counts while ignoring low-volume background scanning activity.