Detecting Automated Reconnaissance Scans In Cloud VPC Flow Logs

📅 November 7, 2026  |  🏷 Cyber Security  |  Cyber Security, Information Security, Threat Management

A single misconfigured security group can generate over 40,000 unsolicited connection attempts within the first 72 hours of exposure — and most organizations discover this only after reviewing logs that are days old. Automated reconnaissance scans are the opening act of virtually every significant cloud breach, yet the telemetry to detect them is already flowing through your environment in the form of VPC Flow Logs. The challenge isn’t data availability; it’s knowing precisely what patterns to hunt for and how to operationalize detection at scale before an attacker pivots from scanning to exploitation.

Understanding Automated Reconnaissance in Cloud Environments

Automated reconnaissance differs fundamentally from opportunistic scanning because it is systematic, persistent, and increasingly evasive. Modern scanning frameworks — Masscan, Shodan crawlers, Censys probes, and bespoke botnet tools — can fingerprint an entire cloud subnet in under four minutes. What makes cloud VPCs a particularly attractive target is the perception of elastic, potentially misconfigured resources that cycle IP addresses unpredictably, creating brief but exploitable exposure windows during provisioning.

How Reconnaissance Scan Traffic Manifests

Reconnaissance scan traffic leaves a distinctive behavioral footprint in flow logs. The canonical signature involves a high ratio of REJECT or RST responses to SYN packets across multiple destination ports from a single source IP, or inversely, a single source systematically sweeping a wide destination IP range on a fixed port. In AWS VPC Flow Logs, this translates to log records where the action field reads REJECT and the protocol field indicates TCP (6) or UDP (17), with a fan-out pattern across destination addresses or ports within a compressed time window.

Google Cloud’s VPC Flow Logs and Azure Network Security Group (NSG) Flow Logs present similar structures. Azure NSG logs, for instance, encode traffic decisions as “A” (allow) or “D” (deny), with tuple data capturing source IP, destination IP, source port, destination port, and protocol. Any analytical pipeline that ignores the deny records is effectively blind to the reconnaissance phase entirely — a gap that persists in a surprising number of SIEM configurations.

The Threat Intelligence Context

According to Palo Alto Networks’ Unit 42 Cloud Threat Report (2025), the median time between a cloud resource being exposed to the public internet and its first scan is under 10 minutes. This isn’t a threat you have the luxury of detecting at 24-hour review cycles. Infrastructure exposed during maintenance windows, blue-green deployments, or Terraform apply operations faces an almost immediate reconnaissance response from automated systems continuously sweeping major cloud CIDR ranges.

“The sophistication gap between attack automation and defensive telemetry processing is the defining vulnerability of modern cloud architectures.” — Unit 42 Cloud Threat Report, 2025

Architecting VPC Flow Log Collection for Threat Detection

Detection quality is directly proportional to log fidelity. A common failure mode is enabling VPC Flow Logs only at the VPC level with 10-minute aggregation intervals and default fields, then wondering why behavioral analytics produce high false-negative rates. For reconnaissance detection specifically, granularity is non-negotiable.

Recommended Log Configuration Parameters

For AWS environments, enable flow logs on individual subnet or ENI (Elastic Network Interface) resources rather than relying solely on VPC-level aggregation. Set the aggregation interval to 1 minute (the minimum available) and enable the custom format that includes the following non-default fields: pkt-srcaddr, pkt-dstaddr, flow-direction, traffic-path, and tcp-flags. The tcp-flags field is especially critical — it allows you to distinguish SYN-only packets (flag value: 2) from established connection traffic, isolating pure probe activity without established sessions.

Log destination also matters for latency. Routing flow logs directly to a streaming pipeline (AWS Kinesis Data Firehose → S3 + Athena, or GCP Pub/Sub → BigQuery) rather than relying on batch SIEM ingestion reduces detection-to-alert latency from hours to minutes. Organizations using real-time streaming pipelines for flow log analysis report mean-time-to-detect (MTTD) for port scan activity that is 83% lower than those relying on scheduled SIEM queries, based on internal benchmarking data published by the SANS Institute’s Cloud Security curriculum (2026).

Detection Logic: Building Signatures for Automated Scan Behavior

The analytical core of reconnaissance detection lives in four primary behavioral patterns. Each can be operationalized as a query, detection rule, or machine learning feature depending on your security tooling maturity.

Pattern 1 — High Reject Ratio Port Sweep

A source IP contacting more than 15 distinct destination ports on a single target within a 60-second window, where greater than 80% of connections result in REJECT or no response, is a high-confidence port scan signature. In SQL-based log analytics (Athena, BigQuery), this translates to a GROUP BY on source IP and destination IP with COUNT DISTINCT on destination port, filtered by action = REJECT and a time window function.

The following pseudologic illustrates the core detection query structure:

• SELECT srcaddr, dstaddr, COUNT(DISTINCT dstport) AS distinct_ports, SUM(CASE WHEN action=’REJECT’ THEN 1 ELSE 0 END) AS reject_count
• FROM vpc_flow_logs
• WHERE start_time BETWEEN [window_start] AND [window_end]
• GROUP BY srcaddr, dstaddr
• HAVING distinct_ports > 15 AND (reject_count / COUNT(*)) > 0.80

Pattern 2 — Horizontal IP Sweep (Ping Sweep / Single-Port Sweep)

This pattern inverts the port sweep: a single source contacts many distinct destination IPs on the same port (commonly 22, 3389, 443, 8080, or 6379 for Redis). A threshold of 50 distinct destination IPs within 5 minutes from a single source is a reasonable starting point, calibrated downward in environments with low expected east-west traffic. This signature is particularly effective for detecting credential-stuffing infrastructure reconnaissance and cloud-native service enumeration targeting common managed service ports.

In a documented incident response case from Q3 2026 (anonymized, shared via the Cloud Security Alliance’s incident sharing program), a threat actor used a rotating pool of 200 compromised residential IPs to sweep an organization’s entire /16 CIDR range on port 6379 within 18 minutes. Each individual IP contributed fewer than 400 probes, staying below per-IP thresholds. Detection only succeeded through aggregate behavioral clustering — grouping all source IPs that contacted the same destination IPs within the same time window, revealing the coordinated sweep through statistical co-occurrence analysis.

Enrichment and Triage: Separating Signal from Noise

Raw flow log detections without enrichment produce alert fatigue. Security teams at mid-market enterprises with 50–500 cloud resources can receive hundreds of scan-related alerts daily, the vast majority originating from benign internet scanners (Shodan, Censys, security researchers) or internal monitoring tools with overly broad permission scopes.

Threat Intelligence Enrichment Pipeline

An effective enrichment pipeline layers the following data sources against detected source IPs before alert promotion:

1. Autonomous System Number (ASN) reputation — ASNs associated with known hosting providers frequently used for scanning infrastructure (AS14061/DigitalOcean, AS16509/Amazon when unexpected, AS396982/Google Cloud when unexpected) warrant elevated scrutiny.
2. Threat intelligence feeds — Commercial feeds (Recorded Future, CrowdStrike Intel) and open-source feeds (AbuseIPDB, Emerging Threats IP blocklists) provide IP-level reputation scoring.
3. Geolocation anomaly — Traffic from geolocations inconsistent with your organization’s established baseline (vendors, users, contractors) increases signal confidence.
4. Historical communication baseline — Has this source IP ever appeared in allowed traffic to your environment? First-time sources with high reject ratios warrant immediate escalation.
5. Target resource context — Is the scan target a public-facing resource, an internal microservice, or a data tier resource that should never receive direct inbound traffic? The latter represents a critical severity indicator regardless of scan volume.

Integrating with SOAR for Automated Response

Detection without automated response is half a capability. Security Orchestration, Automation and Response (SOAR) platforms (Palo Alto XSOAR, Splunk SOAR, Torq) can operationalize graduated responses based on enriched alert confidence scores. A source IP scoring above a defined threat confidence threshold can trigger automatic Security Group rule insertion, WAF IP block, or GuardDuty threat list update — all within the same execution cycle as the detection, typically under 90 seconds end-to-end.

The key architectural principle: automated blocks should target the network layer (Security Group DENY) rather than application-layer controls alone, since reconnaissance tools frequently rotate user agents and TLS fingerprints to evade application-layer signatures.

Advanced Techniques: Behavioral Baselining and ML-Assisted Detection

Threshold-based detection rules are necessary but not sufficient against sophisticated, low-and-slow reconnaissance campaigns. Adversaries familiar with common detection thresholds deliberately operate below them — scanning 10 ports over 10 minutes rather than 50 ports over 1 minute, for instance.

Establishing Traffic Baselines for Anomaly Detection

Effective anomaly detection requires a minimum of 21 days of historical flow log data to establish statistically meaningful baselines for inbound connection attempt rates, reject ratios by subnet, and new source IP introduction rates. These baselines exhibit strong weekly periodicity in most enterprise environments, requiring time-of-week normalization before anomaly scoring is applied.

The specific features that most reliably distinguish automated scan traffic from legitimate but unusual access patterns include:

• Inter-packet arrival time variance — Automated scanners exhibit extremely low variance in timing; human-initiated connections do not.
• Port sequence ordering — Automated tools often scan ports in sequential or well-known-service-ordered sequences rather than random order.
• TCP flag anomalies — Christmas tree packets (all flags set), NULL packets (no flags), and FIN-only packets with no preceding SYN are exclusively associated with scanner tool fingerprinting.
• Payload size patterns — Reconnaissance probes typically have minimal or zero payload bytes; the bytes field in flow logs being consistently 0 or 40 (header-only) is a strong indicator.

AWS GuardDuty’s ML-based findings (specifically Recon:EC2/PortProbeUnprotectedPort and Recon:EC2/Portscan) represent a managed implementation of this logic, though security teams should understand that GuardDuty’s detection scope is limited to your monitored resources and does not provide the customization flexibility needed for high-fidelity enterprise detection programs.

Operationalizing Continuous Monitoring: Metrics and Governance

Reconnaissance detection is not a one-time configuration task. The threat landscape, your cloud architecture, and attacker tooling all evolve continuously. Sustainable detection programs require defined operational metrics and governance checkpoints.

Key Performance Indicators for Recon Detection Programs

Track these KPIs on a weekly cadence with executive reporting on a monthly basis:

Detection Rule Lifecycle Management

Reconnaissance detection rules require quarterly review against emerging scanner tooling. The 2026 proliferation of IPv6-capable scanning infrastructure exposed a significant gap in many organizations’ detection programs — existing rules were written for IPv4 CIDR-based thresholds and failed to trigger against IPv6 source addresses conducting identical sweep behavior. Maintaining a rule changelog with associated threat intelligence rationale and last-validated date prevents detection drift over time.

Additionally, conduct red team exercises specifically targeting your flow log detection pipeline at least twice annually. Engage operators who are familiar with sub-threshold scanning techniques, distributed scan architectures, and cloud-native service enumeration (targeting instance metadata endpoints, cloud storage enumeration via DNS, and SSM parameter store probing) — attack vectors that generate minimal traditional flow log signatures but represent genuine reconnaissance value to adversaries.

Key Takeaways

• Reject records are your primary reconnaissance signal. Any SIEM or analytics configuration that filters out denied/rejected flow log records is functionally blind to the scanning phase of cloud intrusions.
• Granularity is non-negotiable. Enable 1-minute aggregation intervals and custom field formats including tcp-flags, pkt-srcaddr, and flow-direction to support behavioral pattern analysis beyond simple connection counts.
• Threshold-only detection fails against distributed, low-and-slow campaigns. Supplement signature-based rules with behavioral baselining, aggregate clustering across source IPs, and ML-assisted anomaly scoring to cover sophisticated adversary tradecraft.
• Enrichment before escalation is operationally essential. Integrating ASN reputation, threat intelligence feeds, geolocation context, and resource sensitivity into the alert
  

  ---

  💡 Enjoyed this article?

  Subscribe for more expert insights delivered to your inbox.

  Follow us or subscribe below xe2x80x94 free, no spam.