Terraform State File Exposure: Extracting Infrastructure Secrets from Public S3 Backends

Why This Matters

In 2020, security researchers scanning public S3 buckets discovered hundreds of .tfstate files belonging to real organisations. These files contained plaintext AWS access keys, RDS database master passwords, private SSH keys, Kubernetes cluster CA certificates, and complete network topology maps — including VPC CIDR ranges, subnet IDs, security group rules, and every resource ARN in the infrastructure. Terraform state is arguably the most sensitive artifact in a cloud infrastructure deployment: it is the ground truth of what exists, how it is configured, and — critically — what credentials were used to create it. A single exposed state file can provide an attacker with everything needed to move laterally across an entire environment.

Core Concept

Terraform state is a JSON file (.tfstate) that records the current state of all resources managed by Terraform: their IDs, attributes, relationships, and the input variable values used to configure them. Terraform needs this file to compute the diff between desired configuration and current reality on every plan and apply operation.

State files contain secrets for several unavoidable reasons: - Provider credentials embedded during provisioning are sometimes written into resource attributes. - Generated secrets: resources like aws_db_instance with manage_master_user_password = false write the generated password attribute into state in plaintext. - random_password resources store the generated value in state so subsequent plans can reference it. - Certificate private keys generated by tls_private_key resources are stored in state. - sensitive variable values: Even marking a variable sensitive = true in Terraform only suppresses console output — the value is still written to state in plaintext.

State backends determine where state is stored. Local state (the default) writes terraform.tfstate to disk — a critical finding if the repository is public. Remote backends (S3+DynamoDB, Terraform Cloud, Azure Blob, GCS) are more secure but require correct access controls. An S3 backend bucket without Block Public Access or with an overly permissive bucket policy exposes state to anyone who can reach the bucket.

State file enumeration is a standard step in cloud infrastructure reconnaissance: search for S3 buckets matching patterns like terraform-state-*, tf-state-*, *-tfstate-*, or *-infrastructure; check for .tfstate objects; download and parse for sensitive values.

Technical Deep-Dive

# Search for S3 buckets that may contain Terraform state
aws s3api list-buckets --query 'Buckets[*].Name' --output text | 
  tr '  ' '
' | grep -Ei 'terraform|tfstate|tf-state|infra'

# List objects in a suspected state bucket
aws s3 ls s3://terraform-state-company-prod/ --recursive | grep '.tfstate'

# Download a state file
aws s3 cp s3://terraform-state-company-prod/env/prod/terraform.tfstate /tmp/state.json

# Extract all sensitive values from state — resources with password/key/secret attributes
python3 << 'PYEOF'
import json, re, sys

with open("/tmp/state.json") as f:
    state = json.load(f)

sensitive_keys = re.compile(
    r'(password|passwd|secret|private_key|api_key|token|credential|certificate_pem|'
    r'client_secret|db_password|master_password|access_key|secret_key)',
    re.IGNORECASE
)

def recurse(obj, path=""):
    if isinstance(obj, dict):
        for k, v in obj.items():
            recurse(v, f"{path}.{k}")
    elif isinstance(obj, list):
        for i, v in enumerate(obj):
            recurse(v, f"{path}[{i}]")
    elif isinstance(obj, str) and obj and sensitive_keys.search(path):
        print(f"{path}: {obj[:80]}{'...' if len(obj) > 80 else '}")

for res in state.get("resources", []):
    for inst in res.get("instances", []):
        recurse(inst.get("attributes", {}),
                f"{res['type']}.{res['name']}")
PYEOF

# Attempt anonymous access (checks if bucket is publicly readable)
aws s3 ls s3://terraform-state-company-prod/ --no-sign-request

# Check the state bucket's own security configuration
aws s3api get-public-access-block --bucket terraform-state-company-prod
aws s3api get-bucket-versioning --bucket terraform-state-company-prod
aws s3api get-bucket-encryption --bucket terraform-state-company-prod
aws s3api get-bucket-logging --bucket terraform-state-company-prod

Security Assessment Methodology

1. Enumerate S3 buckets for state file patterns. List all buckets and filter by name for common Terraform state naming conventions. Also check for .tfstate objects in all readable buckets — state files are sometimes stored in application buckets rather than dedicated state buckets.
2. Check state bucket access controls. Verify Block Public Access, bucket policy, ACL, and encryption settings. Unencrypted state in a publicly readable bucket is a critical finding. Even private, unencrypted state is a high finding.
3. Download and parse state files. Use the Python script above to extract all attribute values matching sensitive key names. Prioritise aws_db_instance, aws_iam_access_key, tls_private_key, random_password, and aws_secretsmanager_secret_version resource types.
4. Check for state in source control. Search the application repository for *.tfstate or *.tfstate.backup files: git log --all --full-history -- "**/*.tfstate". State files committed to git history persist even after removal from the current working tree.
5. Enumerate older state versions. If bucket versioning is enabled (it should be), older state versions may contain credentials for resources that have since been deleted. Use aws s3api list-object-versions to retrieve all versions.
6. Remediate by migrating to a remote backend with SSE-KMS encryption, enabling Block Public Access and bucket versioning, restricting access to the state bucket via bucket policy (only Terraform execution roles), and rotating all credentials found in exposed state files.

Common Assessment Errors

• Only checking the current state version. S3 bucket versioning for state backends means all historical state versions are retained. Previous versions may contain credentials for resources that were removed from the current state but whose secrets were never rotated.
• Missing local state files in CI/CD pipelines. If Terraform runs in a CI/CD pipeline that uses local state (no remote backend configured), the .tfstate file may be written to the pipeline's artifact storage or left in the workspace. Check CI/CD platform artifact stores.
• Ignoring sensitive = true as security. Sensitive variables are masked in terraform plan output but are written to state in plaintext. Do not report a variable as "protected" because it is marked sensitive — check the state file directly.
• Missing the outputs section. Terraform state includes a outputs section that contains the values of all output blocks. Outputs that expose database connection strings, IP addresses, or credentials are high-value findings that are easy to overlook by only scanning resource attributes.
• Not correlating found credentials with CloudTrail. When credentials are found in state, immediately check CloudTrail (or equivalent) for API calls using those credentials from unexpected IP addresses or principals — confirm whether the exposure was exploited.

NICE Framework Alignment

Further Reading

• Terraform Security Best Practices — HashiCorp Documentation (developer.hashicorp.com/terraform/language/state/sensitive-data)
• Attacking the State: Terraform State File Security — Scott Piper, Summit Route blog
• Infrastructure as Code Security — Checkov Documentation, Terraform State Checks (checkov.io)