Cloud Asset Leak Investigation: Exposed Object Storage and Misconfigured Public Resource OSINT

forensic_file_artifacts Difficulty 1–5 30 min certifiable

Theory

Why This Matters

Cloud infrastructure has fundamentally changed what is discoverable through passive reconnaissance. Organizations that once hid their server architecture behind static IP blocks now expose it through predictable naming conventions, published IP ranges, and certificate transparency logs. Threat intelligence teams routinely map adversary cloud infrastructure to identify C2 server hosting patterns and predict new infrastructure before it is activated. Red team operators use cloud OSINT to build a complete picture of an organization's attack surface before a single packet is sent to target systems. In documented breach investigations, attackers were traced through their use of organization-named S3 buckets that appeared in certificate transparency logs before the organization's security team had inventoried them.

Core Concept

The four-pivot cloud OSINT chain begins with a domain name and systematically expands to full cloud infrastructure visibility through sequential correlation steps. Each pivot uses data that is intentionally public — either published by cloud providers themselves or disclosed through the normal operation of internet infrastructure protocols.

Pivot 1 — Cloud Provider Identification: DNS records expose which cloud provider hosts an organization's infrastructure. NS records pointing to *.awsdns-*.com, *.azure-dns.*, or ns*.cloudflare.com identify the DNS provider. The authoritative IP ranges for each major cloud provider are published as machine-readable JSON: AWS at https://ip-ranges.amazonaws.com/ip-ranges.json, Azure at Microsoft's download portal, GCP at https://www.gstatic.com/ipranges/cloud.json. Querying an organization's A records and cross-referencing the returned IPs against these published ranges confirms which cloud provider(s) host which services.

Pivot 2 — S3 Bucket Enumeration: AWS S3 bucket names follow a globally unique naming scheme and are addressable as DNS names: bucket-name.s3.amazonaws.com and bucket-name.s3.region.amazonaws.com. Organizations routinely name buckets after themselves: company-backup, company-assets, company-logs, company-prod. DNS enumeration with dig or nslookup against these predictable patterns reveals which bucket names resolve (indicating the bucket exists) versus which return NXDOMAIN. A resolving bucket name can then be checked for public read access with an unauthenticated HTTP GET.

Pivot 3 — Shodan and Censys Cloud Service Enumeration: Shodan indexes internet-facing services including those hosted on cloud infrastructure. Queries such as org:"Amazon" hostname:company.com or ssl:company.com cloud surface cloud-hosted web services, exposed APIs, and management interfaces. Censys provides similar capability with the query cloud.provider:aws AND parsed.names:company.com. Both platforms index TLS certificates, HTTP response headers, and banner data from cloud-hosted endpoints that may not appear in the organization's own DNS.

Pivot 4 — Certificate Transparency for Cloud Subdomains: Certificate Transparency (CT) logs record every TLS certificate issued by trusted certificate authorities. Cloud-hosted subdomains — often created automatically by cloud services — appear in CT logs as soon as the certificate is issued, before they are published in DNS or announced publicly. crt.sh provides a free search interface: %.company.com returns all certificates ever issued for any subdomain of company.com. Cloud management interfaces, staging environments, and internal tools with TLS certificates are all discoverable through CT logs.

Technical Deep-Dive

# Pivot 1: Identify cloud provider from NS and A records
dig NS company.com +short
# => ns-1234.awsdns-12.org. => AWS Route53
dig A company.com +short
# => 52.84.X.X

# Cross-reference IP against AWS published ranges (jq required)
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | 
  python3 -c "
import json, sys
data = json.load(sys.stdin)
target = '52.84.0.0'
for prefix in data['prefixes']:
    import ipaddress
    try:
        net = ipaddress.ip_network(prefix['ip_prefix'])
        ip  = ipaddress.ip_address(target)
        if ip in net:
            print(prefix)
    except:
        pass
"

# Pivot 2: S3 bucket name enumeration via DNS
for bucket in company-backup company-assets company-logs company-prod 
              company-data company-static company-media; do
  result=$(dig +short "${bucket}.s3.amazonaws.com" 2>/dev/null)
  if [ -n "$result" ]; then
    echo "[+] EXISTS: ${bucket} => ${result}"
    # Check public read access
    http_code=$(curl -so /dev/null -w "%{http_code}" 
      "https://${bucket}.s3.amazonaws.com/?list-type=2" 2>/dev/null)
    echo "    HTTP status (list): ${http_code}"
  fi
done

# Pivot 3: Shodan query examples (shodan CLI)
shodan search 'org:"Amazon" hostname:company.com' --fields ip_str,port,hostnames
shodan search 'http.title:"company" cloud' --fields ip_str,port,ssl.cert.subject.cn

# Censys query (censys CLI or API):
# censys search 'cloud.provider: AWS AND parsed.names: company.com' --index-type hosts

# Pivot 4: Certificate Transparency via crt.sh
curl -s "https://crt.sh/?q=%25.company.com&output=json" | 
  python3 -c "
import json, sys
certs = json.load(sys.stdin)
names = set()
for c in certs:
    for name in c.get('name_value',').split('
'):
        names.add(name.strip())
for n in sorted(names):
    print(n)
" | grep -v '^*.' | sort -u
# Surfaces cloud subdomains: api-staging.company.com,
# internal-k8s.company.com, backup-us-east.company.com, etc.

# Identify AWS console phishing targets from CT subdomain list
curl -s "https://crt.sh/?q=%25.company.com&output=json" | 
  python3 -m json.tool | grep -i 'signin|console|portal|admin|mgmt'

Intelligence Collection Methodology

Begin with amass for comprehensive subdomain enumeration: amass enum -passive -d company.com -o amass_output.txt. This combines CT logs, DNS brute force, and multiple data sources into a single enumeration.
For each discovered subdomain, run dig A subdomain.company.com +short and cross-reference returned IPs against published cloud IP range JSON files (AWS, Azure, GCP) to map which cloud provider hosts which service.
Extract the cloud provider from NS records using dig NS company.com +short. NS patterns: *.awsdns-*.com (AWS Route53), ns[1-4].azure-dns.* (Azure DNS), ns-cloud-*.googledomains.com (GCP Cloud DNS).
Generate S3 bucket name candidates using recon-ng module recon/domains-hosts/brute_hosts seeded with organization name variants. Append common suffixes: -backup, -assets, -static, -media, -logs, -prod, -dev, -staging. For each candidate, query dig +short candidate.s3.amazonaws.com.
For existing buckets, use aws s3 ls s3://bucket-name --no-sign-request to test unauthenticated listing. A successful listing is a critical finding; a 403 Forbidden confirms the bucket exists but is not publicly readable.
Query Shodan for the organization: shodan search org:"Company Name". Filter results by cloud-hosted IP ranges to identify cloud-specific exposed services. Note any management interfaces (Kubernetes Dashboard, Jupyter Notebooks, Elasticsearch clusters).
Query Censys for the organization's certificates: search for parsed.subject.organization: "Company Name". This surfaces certificates on non-standard ports and cloud services not visible in DNS.
Query crt.sh for %.company.com and parse the JSON output to extract all unique subdomain names. Cross-reference discovered subdomains against the Shodan and Censys results to identify cloud management interfaces.
Document findings in a Maltego graph: domain → cloud provider → IP ranges → discovered services → certificate subjects. This link analysis reveals the full cloud attack surface.

Common Intelligence Collection Errors

Treating NXDOMAIN as proof a bucket does not exist: S3 buckets in non-default regions resolve via region-specific DNS names (bucket.s3.us-west-2.amazonaws.com). A bucket that returns NXDOMAIN for the global endpoint may still exist in a specific region. Always test multiple regional endpoint formats.
Missing cloud services not in DNS: Many cloud services — internal load balancers, private API gateways, Lambda function URLs — are not published in the organization's DNS. CT logs and Shodan certificate searches are the only passive methods to discover these services.
Confusing cloud provider of DNS with cloud provider of compute: An organization may use Cloudflare for DNS (NS records point to Cloudflare) while hosting compute on AWS. Always look up A/CNAME records (actual hosting) separately from NS records (DNS management).
Relying solely on the default S3 bucket naming pattern: Organizations also use random or UUID-based bucket names. theHarvester and GitHub code search (s3.amazonaws.com/ within organization repositories) recover these non-predictable names.
Not verifying CT log results against live DNS: Certificate Transparency logs contain historical certificates including expired, revoked, and precertificates. A subdomain appearing in CT logs may no longer be live. Always validate CT discoveries with dig before treating them as active infrastructure.
Overlooking Azure Blob and GCP Storage equivalents: The S3 enumeration methodology applies equally to Azure Blob Storage (company.blob.core.windows.net) and GCP Cloud Storage (storage.googleapis.com/bucket-name). An investigation that checks only S3 may miss significant cloud storage exposure.

NICE Framework Alignment

Code	Knowledge/Skill/Task Statement	How This Card Develops It
K0058	Knowledge of network protocols	Applying DNS (NS, A, CNAME record types), HTTP, and TLS as the underlying protocols enabling cloud infrastructure discovery
K0145	Knowledge of security assessment approaches	Executing a structured four-pivot cloud reconnaissance methodology that progressively expands infrastructure visibility
K0272	Knowledge of network security architecture	Understanding how cloud provider IP ranges, global CDN routing, and multi-region deployment affect infrastructure footprint analysis
K0427	Knowledge of encryption algorithms	Leveraging TLS certificate infrastructure (Certificate Transparency logs) as a discovery mechanism for cloud-hosted services
S0040	Skill in identifying and extracting data of interest from various sources	Extracting cloud service indicators from DNS responses, CT log JSON, Shodan results, and published cloud IP range files
T0569	Apply and utilize authorized cyber capabilities to achieve objectives	Deploying amass, Shodan, Censys, crt.sh, and AWS CLI in an authorized cloud reconnaissance engagement