Single Target Distributed Reconnaissance (GCP)

Single Target Distributed Reconnaissance leverages Google Cloud Platform infrastructure to perform efficient, scalable network reconnaissance on a single target by distributing the workload across multiple partitions. This approach significantly reduces the time required for comprehensive scans of large port ranges while maintaining high efficiency and scalability.

GCP architecture diagram showing the flow from Heph4estus through Cloud Workflows, Pub/Sub, GKE, and monitoring services

Architecture diagram showing GCP services integration for Single Target Distributed reconnaissance

GCP Workflow Overview

1. Scan Initiation

  • User runs Heph4estus which triggers a producer application that uses the GCP SDK
  • Input includes a single target, desired number of partitions, and scan options

2. Port Partitioning

  • Producer calculates port ranges based on partition count
  • For 3 partitions across full port range (1-65535):
    • Partition 1: ports 1-21845
    • Partition 2: ports 21846-43690
    • Partition 3: ports 43691-65535
  • Each partition becomes a separate scan task

3. Producer Processing

  • The producer application packages partitioned data for the target
  • Creates a unique scan ID to track all partitions of this scan
  • Triggers a Cloud Workflow with the scan details and partition count

4. Workflow Orchestration

  • Cloud Workflows executes the scanning workflow
  • Manages the parallel execution of all partitions
  • Tracks completion status of each partition

5. Message Publishing

  • For each partition, a message is published to a Cloud Pub/Sub topic
  • Messages contain:
    • Target information
    • Specific port range for this partition
    • Scan options
    • Unique scan ID to correlate results

6. Container Execution

  • Messages trigger GKE pods through a Pub/Sub subscription
  • Each pod runs with the scanner image from Artifact Registry
  • Pods are configured with appropriate resources for their port range
  • VPC Service Controls restrict network access to authorized sources

7. Consumer Processing

  • Each GKE pod processes a single partition
  • Extracts target and port range from the Pub/Sub message
  • Executes Nmap with the port-specific parameters

8. Result Storage

  • Each partition's results are uploaded to Cloud Storage
  • Naming convention includes scan ID and partition information
  • Example: scans/{scan_id}/example.com_partition1.json
  • Object metadata includes target, timestamp, and partition details

9. Task Completion

  • Pods publish completion messages to a "scan-complete" Pub/Sub topic
  • Messages include scan ID and partition number
  • The workflow tracks how many partitions have completed

10. Results Aggregation

  • When all partitions complete, workflow triggers final aggregation step
  • Combines results from all partitions into a comprehensive report
  • Final report stored in Cloud Storage with the same scan ID

11. Error Handling

  • Retry logic built into the workflow for transient failures
  • Error reporting captures and alerts on application errors
  • Comprehensive logging enables detailed troubleshooting