Smogcloud: Finding the AWS Assets Your Security Team Forgot About

Hook

A Fortune 500 company discovered 47 publicly accessible RDS databases during their first Smogcloud scan—none of them were in their asset inventory. Your AWS account probably has similar blind spots.

Context

Cloud infrastructure moves fast. A developer spins up an API Gateway for testing, an SRE launches an experimental Elasticsearch cluster, a data scientist creates an S3 bucket for a one-off analysis. Three months later, these resources are still running, still exposed to the internet, and completely forgotten. Traditional asset management tools struggle with cloud environments because they're built for the static world of on-premise infrastructure where servers have physical locations and change control boards.

The AWS attack surface problem is fundamentally different from traditional IT. Resources can be created in any of 30+ regions by anyone with credentials, and each AWS service exposes endpoints differently—some using predictable patterns, others generating random identifiers. S3 buckets follow a simple naming convention, but CloudFront distributions get random alphanumeric IDs. API Gateway endpoints include region identifiers and random strings. This heterogeneity makes comprehensive discovery challenging. Smogcloud emerged from Bishop Fox's penetration testing practice where consultants repeatedly encountered the same problem: clients couldn't provide accurate inventories of their internet-facing AWS assets. The tool addresses a specific use case—rapid enumeration of exposed cloud resources using read-only AWS credentials.

Technical Insight

Smogcloud's architecture is straightforward: authenticate once, enumerate everything, output structured data. It's implemented as a single Go binary that uses the AWS SDK to systematically query service APIs across all available regions. The tool doesn't attempt to be clever with caching or stateful tracking—it's designed for point-in-time scanning where simplicity beats sophistication.

The core enumeration pattern follows a consistent structure across services. Here's how it discovers Elasticsearch domains:

// Pseudo-code representing Smogcloud's approach
func enumerateElasticsearch(sess *session.Session, region string) []Asset {
    svc := elasticsearchservice.New(sess, &aws.Config{Region: aws.String(region)})
    
    // List all Elasticsearch domains in the region
    domains, err := svc.ListDomainNames(&elasticsearchservice.ListDomainNamesInput{})
    if err != nil {
        // Fail gracefully - missing permissions shouldn't stop other enumerations
        return nil
    }
    
    var assets []Asset
    for _, domain := range domains.DomainNames {
        // Fetch detailed config to determine if endpoint is public
        desc, err := svc.DescribeDomain(&elasticsearchservice.DescribeDomainInput{
            DomainName: domain.DomainName,
        })
        if err != nil {
            continue
        }
        
        // Extract the endpoint if it exists
        if desc.DomainStatus.Endpoint != nil {
            assets = append(assets, Asset{
                Service:  "Elasticsearch",
                Region:   region,
                Endpoint: *desc.DomainStatus.Endpoint,
                Type:     "Generated",
            })
        }
    }
    return assets
}

This pattern repeats across 15+ services with variations. For S3, it's simpler because buckets are global and their public accessibility is determined by bucket policies and ACLs. For EC2, the tool must enumerate instances, identify those with public IPs, then extract Elastic IPs and their DNS names. The regional iteration is particularly important—a resource in ap-southeast-1 won't appear in us-east-1 queries.

The output categorization reveals AWS's architectural patterns. Smogcloud classifies endpoints into four types: user-provided (S3 bucket names), random identifiers (CloudFront distribution IDs), regional patterns (RDS endpoints following predictable formats), and IP addresses (EC2 instances). This taxonomy is valuable beyond just inventory—it informs how you approach asset discovery and monitoring. User-provided names are susceptible to enumeration attacks. Random identifiers provide security through obscurity. Regional patterns expose geographic distribution of resources.

Smogcloud requires relatively minimal IAM permissions because it only performs read operations. A policy granting Describe*, List*, and Get* actions across relevant services is sufficient. Here's a minimal IAM policy snippet:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation",
        "rds:Describe*",
        "elasticloadbalancing:Describe*",
        "es:ListDomainNames",
        "es:DescribeDomain",
        "apigateway:GET",
        "cloudfront:List*"
      ],
      "Resource": "*"
    }
  ]
}

The SecurityAudit managed policy AWS provides covers these permissions and more, making it the practical choice for running Smogcloud safely. This read-only approach is critical for its use case—penetration testers and security auditors can run it without risk of disrupting production systems.

One architectural decision worth examining is Smogcloud's single-threaded, synchronous execution. For each region, it calls one service API, waits for the response, processes the results, then moves to the next service. This simplicity has tradeoffs. A scan of a large AWS environment with resources across 20 regions and 15 services means 300 sequential API calls (plus additional calls for pagination and detail retrieval). In a heavily populated account, this could take 15-30 minutes. The upside is predictable behavior, easier debugging, and no concerns about rate limiting or connection pooling. For its intended use case—occasional security assessments rather than continuous monitoring—this is a defensible choice.

Gotcha

The biggest limitation is staleness. Smogcloud's last significant update was several years ago, and AWS has shipped dozens of new services since then. App Runner, Amplify Hosting, Lightsail containers, ECS Anywhere, and various specialized services aren't covered. If your organization uses newer AWS offerings, you'll have blind spots. The tool also predates some AWS API improvements—modern SDKs include better pagination handling and automatic retry logic that could improve reliability.

Output format is another pain point. Smogcloud dumps results to stdout in a basic text format that requires additional parsing for integration with other tools. There's no JSON output mode, no CSV export, no direct integration with asset management databases or SIEM platforms. If you're running this as part of an automated security workflow, you'll need to write wrapper scripts to transform the output into something machine-readable. For organizations doing weekly or monthly scans, this means building and maintaining integration code. The tool also doesn't handle multi-account AWS environments elegantly—you need to run it separately for each account with different credentials, then manually correlate results. In modern AWS Organizations setups with dozens or hundreds of accounts, this becomes operationally challenging.

Verdict

Use if: You're doing penetration testing or security assessments of AWS environments and need a quick baseline inventory of internet-facing assets. It's particularly valuable when you suspect shadow IT or want to identify forgotten resources that aren't in official documentation. The tool works well for organizations with primarily legacy AWS service usage (EC2, S3, RDS, ELB) where comprehensive coverage matters more than bleeding-edge service support. It's also useful as an educational resource—reading the code teaches you how AWS service endpoints are structured and how to query them programmatically. Skip if: You need continuous monitoring, multi-account support, or coverage of modern AWS services. Organizations with mature security programs should invest in more comprehensive solutions like Prowler or Cartography that provide ongoing visibility and integrate with security workflows. Also skip if you're heavily using container services, serverless beyond Lambda, or AWS's specialized offerings—Smogcloud won't find those assets. For one-off assessments, it's still valuable; for production security operations, it's a starting point that needs augmentation.