Detecting Port Scanning in AWS VPC Flow Logs

Why this matters

VPC Flow Logs record the metadata of every accepted and rejected connection in your VPC — not the payload, just who talked to whom, on which port, and whether it was allowed. That’s exactly the right level of detail to catch port scanning, which by definition is about connection attempts, not content. A scan against a well-defended VPC produces almost entirely REJECT records, which is the signal itself.

Indicators to look for in VPC Flow Logs

• A single srcaddr generating REJECT records against many distinct dstport values on the same dstaddr in a short window
• Sequential or evenly-spaced destination ports, consistent with automated scanning tools rather than normal application traffic
• A scan that pivots from internal reconnaissance (scanning other instances in the same VPC) after an initial single-host compromise
• A small number of ACCEPT records mixed into a sea of REJECTs — those are the open ports the attacker found, and the ones worth investigating first
• Traffic from source ranges with no legitimate business reason to be probing your VPC at all (most scans fall in this category)

How LogTriage detects this

The VPC Flow parser handles the dynamic header across flow log versions v2 through v5, normalizing ACCEPT/REJECT decisions into standard status codes so the same scoring pipeline used for HTTP logs applies here too. NODATA/SKIPDATA records (capacity or internal Amazon traffic) are filtered out automatically so they don’t dilute the signal.

Detection / evidence checklist

• List every distinct destination port the source IP attempted, sorted by accept/reject
• Identify which ACCEPTed ports correspond to services that shouldn’t be reachable from that source
• Check whether the scan originated externally or from an already-compromised instance inside the VPC
• Tighten security group rules for any port that was reachable but didn’t need to be
• Cross-reference the source IP/ASN against threat intelligence — persistent internet-wide scanners are common and usually lower priority than a scan specifically targeting your IP range