Infrastructure & Cloud Penetration Testing (Stealth & AI-Augmented)

This document provides a neutral, technique-agnostic guide to identifying common cloud and infrastructure misconfigurations with an emphasis on low-noise reconnaissance, safe validation, and AI-assisted analysis. The focus is on S3 buckets, cloud metadata services, container escapes, SSH key exposure, and exposed admin panels. All guidance assumes explicit written authorization and in‑scope targets only. Methods described here reduce the probability of detection by security teams while still yielding actionable findings.

General Principles for Stealthy Infrastructure Testing

Passive first: Exhaust open‑source intelligence (OSINT), certificate transparency logs, public DNS records, and search engines before sending a single packet to the target.
Use intermediary infrastructure: Route all active checks through VPNs, cloud instances, or residential proxies that are not tied to your testing entity.
Rate‑limit and space requests: Distribute checks over time; avoid rapid sequential bursts that trigger anomaly detection.
Default user‑agents and headers: Mimic common browsers or cloud‑SDK user‑agents. Do not use custom tool‑branded strings.
Read‑only primitives only: Whenever possible, use HEAD, GET with no parameters, or anonymous API calls that do not log meaningful operations.
Immediate reporting: If a finding is confirmed (e.g., an exposed credential or writable bucket), stop activity and report immediately; do not explore further.

Hard stops (universal):

Do not download object contents beyond confirming public readability (e.g., a single known file name).
Do not upload any data to misconfigured resources.
Do not leverage found credentials, keys, or role tokens to access other services.

S3 Bucket Misconfiguration

Purpose

To identify AWS S3 buckets that permit unauthenticated List, Read, or Write operations when the intended configuration is private.

Impact

Public read/list: Exposure of sensitive data at scale (customer PII, backups, source code, configuration files containing secrets).
Public write: Malicious content upload, ransomware, or serving malware from a trusted domain.

Recon: What to Look For (No Active Requests)

OSINT: Search public web archives (Wayback Machine), GitHub (organization scoped), and Google dorks (site:s3.amazonaws.com target-domain). Look for URLs containing .s3.amazonaws.com or s3:// in past commits, JavaScript, or support forum posts.
Certificate Transparency (CT) logs: Bucket names often appear in TLS certificates for static websites hosted on S3. Extract potential bucket names from CT subdomains.
Passive DNS: Use services like SecurityTrails or VirusTotal to identify subdomains that resolve to s3.amazonaws.com. Many organisations expose buckets via custom domain (CNAME to S3).
Browser request mapping: While browsing the target’s public websites, record any static resource URLs that include s3.amazonaws.com. Do this using a standard browser’s developer tools (no additional security alerts).

Testing Steps (Low Noise)

From the list of suspected bucket names, first attempt a HEAD request to the bucket’s public URL (https://bucket-name.s3.amazonaws.com). Note the HTTP status code.
If a 200 or 403 (versus 404) indicates the bucket exists, attempt an anonymous LIST operation with minimal metadata:
```
aws s3 ls s3://bucket-name --no-sign-request --max-items 1
```
If listing is denied but the bucket exists, test a single known object path obtained during recon (e.g., a logo file). Request only with HEAD:
```
aws s3api head-object --bucket bucket-name --key known-file.jpg --no-sign-request
```
Document the access level (list/read/write) based solely on HTTP responses and error codes. Do not enumerate beyond one or two benign files.
If authenticated AWS access is available as part of the engagement, check the bucket policy and ACL using read‑only API calls (no modifications). Use engagement‑specific credentials only.

AI‑Assisted Analysis (Prompt Template)

[ROLE] Cloud security analyst
[FINDING] S3 bucket "example-company-backups" returns HTTP 200 for anonymous LIST request.
  Sample keys visible: customer-data-2023.csv, db-backup-prod-2024-01.sql.gz
[TASK] Assess the severity of this S3 misconfiguration.
  - Assign CVSS based on data type likelihood
  - Describe the business impact
  - Provide AWS remediation steps (Block Public Access, bucket policy, IAM)
[OUTPUT FORMAT]
  - CVSS score and vector
  - Business impact
  - AWS console and CLI remediation steps
[CONSTRAINTS] Analysis only — do not suggest downloading or accessing the sensitive files.

Stealth Hard Stops

[NO] Do not download bucket contents.
[NO] Do not upload to misconfigured buckets.
[YES] A single HEAD or one‑object access is sufficient to confirm exposure.
[YES] Document file names/paths only — never their contents.

Cloud Metadata Service Exposure

Purpose

Detect whether a Server‑Side Request Forgery (SSRF) vector or direct network access can reach the cloud instance metadata service (AWS 169.254.169.254, GCP metadata.google.internal). If reachable, an attacker could retrieve IAM credentials belonging to the instance.

Impact

Temporary IAM credential theft (especially dangerous with IMDSv1).
Full access to all cloud resources allowed by the instance’s IAM role.
Lateral movement to databases, storage, and secrets managers.

Recon: Indicators of Potential Metadata Reachability

Application behavior: SSRF targets commonly accepted by the application (e.g., webhooks, image fetchers, PDF generators) that accept arbitrary URLs.
Error messages: Watch for error responses that reveal network connectivity (Connection refused, Timeout, HTTP status from the metadata IP). Capture these passively without retrying the metadata IP directly.
Cloud provider hints: The presence of X-Forwarded-For, X-Real-IP, or Server headers indicating AWS/GCP suggest cloud hosting. Combine with public subnet enumeration (e.g., Shodan) to understand exposure.
Documentation leaks: DevOps blog posts or configuration files sometimes mention IMDS version or usage of 169.254.169.254 – search GitHub and company technical blogs.

Testing Steps (Minimize Exposure)

Identify a confirmed SSRF vector (see Application Layer documentation) – test with a simple, non‑sensitive internal endpoint (e.g., http://127.0.0.1:1 to observe connection errors) before touching the metadata IP.
Only if an SSRF vector exists and works reliably, direct it to http://169.254.169.254/latest/meta-data/. Do not perform any other requests until a response is received.
If a 200 OK is returned with simple text (e.g., ami-id, instance-id), stop immediately – the metadata service is reachable. Do not navigate to iam/security-credentials/.
Determine whether IMDSv2 is enforced: a PUT request with X-aws-ec2-metadata-token-ttl-seconds is required. If the endpoint answers without a token, IMDSv1 is active and the risk is critical.
Document: the SSRF vector used, the exact URL that confirmed reachability, the HTTP response code, and whether IMDSv2 protection was present.

AI‑Assisted Analysis (Prompt Template)

[ROLE] Cloud security analyst
[FINDING] SSRF confirmed — HTTP 200 received from http://169.254.169.254/latest/meta-data/
  Response body shows top-level metadata keys only (stopped before IAM path)
[TASK] Assess the severity of cloud metadata service exposure via SSRF.
  - CVSS score for IMDSv1 exposure via SSRF
  - Describe what an attacker could do with full IAM credential access
  - Provide remediation: IMDSv2 enforcement, instance IAM least-privilege, SSRF fixes
[OUTPUT FORMAT]
  - CVSS score (critical)
  - Attack scenario description
  - AWS remediation: `aws ec2 modify-instance-metadata-options` command
  - SSRF remediation recommendations
[CONSTRAINTS] Analysis only. Do not provide instructions for credential retrieval or use.

Stealth Hard Stops

[NO] NEVER retrieve IAM credentials.
[NO] NEVER use any accidentally obtained credentials.
[NO] Do not traverse beyond the top-level metadata path (latest/meta-data/).
[YES] A successful HTTP 200 from the metadata IP is sufficient evidence for a critical finding.
[YES] Report immediately and coordinate with the client for credential rotation.

Container Escape

Purpose

Identify container configurations that could allow a process inside a container to break out to the host system. Common vectors include privileged mode, dangerous host mounts, and excessive Linux capabilities.

Impact

Complete compromise of the host system and all co‑located containers.
Access to underlying cloud infrastructure and lateral movement across cluster nodes.

Recon: Passive Indicators of Container Infrastructure

Public container registries: Search Docker Hub, Quay, or GHCR for images related to the target organization. Examine Dockerfile content for USER root, --privileged, or volume mounts.
Kubernetes object leaks: Check public GitHub for accidentally committed deployment.yaml, pod.yaml, or Helm values with securityContext.privileged: true.
Job postings / tech blogs: Terms like “Docker socket”, “privileged mode”, “Kubernetes cluster-admin” may appear in organizational literature.
Scanning with extreme care: If allowed, using a non‑intrusive container enumeration tool (e.g., kube-hunter in passive mode) from an internal, approved test host can identify misconfigured Kubelets – but this should only be performed with explicit authorization and after passive recon is exhausted.

Testing Steps (Lab‑Isolated Validation Only)

Review configuration only in production environments – never execute escape attempts.
Obtain the container configuration:
- Docker: docker inspect CONTAINER_ID (requires executor access).
- Kubernetes: kubectl get pod <name> -o yaml or describe pod security contexts.
Check for:
- "Privileged": true
- Mounts: /var/run/docker.sock, /proc/sysrq-trigger, /dev/mem, or host root filesystem.
- Effective capabilities: cat /proc/self/status | grep CapEff (if inside container with low‑risk access).
- Running user: id inside the container.
If a misconfiguration is identified, stop and document. Do not attempt to escape in production. To verify the finding’s real-world impact, reproduce the configuration in an isolated sandbox environment – never on client systems.

AI‑Assisted Analysis (Prompt Template)

[ROLE] Container security specialist
[CONFIG] Docker container config (from docker inspect):
  - Privileged: true
  - Mounts: /var/run/docker.sock:/var/run/docker.sock
  - User: root
[TASK] Identify container escape risks from this configuration.
  - Which specific misconfigurations enable escape?
  - CVSS score per finding
  - Kubernetes/Docker remediation for each issue
[OUTPUT FORMAT]
  - Finding per misconfiguration with CVSS
  - Hardened configuration example
[CONSTRAINTS] Configuration analysis only — no escape technique instructions.

Stealth Hard Stops

[NO] No escape attempts in production.
[NO] Do not exploit misconfigurations even in staging without explicit case‑by‑case authorization.
[YES] Configuration review (docker inspect, pod spec) is low‑risk and sufficient for reporting.
[YES] If a sandbox escape is required for validation, use a dedicated lab environment provided by the client.

SSH Key Exposure

Purpose

Detect SSH private keys that are publicly accessible on the internet, in source code repositories, or within exposed backup files.

Impact

Direct, persistent authenticated access to servers.
Bypass of password rotations and multi‑factor authentication.
Potential root access if the key is privileged.

Recon: How to Find Keys Without Exposing Yourself

GitHub search (passive): Use GitHub’s code search with organization scoping: org:target-org "BEGIN RSA PRIVATE KEY" or "BEGIN OPENSSH PRIVATE KEY". Perform this from an anonymous browser session; avoid using a personal account tied to your testing entity. Better yet, use alerting services (e.g., Shhgit, GitGuardian public monitoring) to catch leaked keys without manual queries.
Web application paths: Check for /backup.tar.gz, /.ssh/id_rsa, /id_rsa, /private, etc. Use only HEAD requests with a common user‑agent. Time these checks over days, interleaved with other benign browsing.
Public bucket inventory: If an S3 bucket allows listing and contains files like id_rsa or .pem, note their existence – do not download the contents.
Google dorks: intitle:"index of" id_rsa, "BEGIN RSA PRIVATE KEY" ext:pem – always through a VPN and search engine anonymization.

Testing Steps (Confirmation‑Only)

Passive discovery first – never actively scan for key files unless they appear in a directory listing you already have permission to enumerate.
For a suspected URL, send a single HEAD request and check for a 200 response and Content-Type that suggests a text/key file.
If you need to confirm the file content, request only the first 30 bytes of the response (e.g., with Range: bytes=0-29) to see if it contains -----BEGIN RSA PRIVATE KEY----- without retrieving the entire key.
Stop immediately; do not download or store the key.
Document: the URL, the confirmation method, and the first line pattern – no key material.

AI‑Assisted Analysis (Prompt Template)

[ROLE] Cloud security analyst
[FINDING] SSH private key accessible at https://example.com/backup/id_rsa
  Confirmed by HTTP 200 response with "BEGIN RSA PRIVATE KEY" in first line
[TASK] Assess the risk of this SSH key exposure.
  - CVSS score
  - Business impact and lateral movement risks
  - Immediate containment steps for the client
  - Long-term remediation recommendations
[OUTPUT FORMAT]
  - Severity: Critical
  - Immediate containment (key rotation, access audit)
  - Remediation: secrets management, git-secrets, .gitignore configuration
[CONSTRAINTS] Analysis and remediation only. No key usage or connectivity testing.

Stealth Hard Stops

[NO] NEVER use the found key to connect to any host.
[NO] Do not download or store the private key content.
[NO] Do not attempt to crack passphrases.
[YES] A HEAD or partial byte‑range request is enough to validate exposure.
[YES] Report critical findings immediately to enable rapid rotation.

Exposed Admin Panels

Purpose

Identify administrative interfaces for infrastructure components (Kubernetes dashboards, database web UIs, CI/CD servers, monitoring tools) that are reachable from the internet without adequate authentication.

Impact

Unauthenticated cluster administration (Kubernetes dashboard).
Full database read/write access (phpMyAdmin, pgAdmin).
Arbitrary code execution through build pipelines (Jenkins).
Data exfiltration and CVE‑based RCE (Grafana, Kibana).

Recon: Low‑Noise Discovery Techniques

Passive DNS / certificate transparency: Look for subdomains like k8s-dashboard, jenkins.internal, grafana, elastic and check if they resolve to public IPs. Do not probe the IP directly yet.
Shodan / Censys / FOFA: Query for title:"Kubernetes Dashboard" or http.title:"phpMyAdmin" combined with the organization’s SSL certificate common name or netblock (if in scope). These platforms have already scanned and indexed; you are simply reading existing data.
Historical Internet scans: Use services like HTTPArchive or CommonCrawl to see if admin interfaces were previously exposed.
Error page analysis: When you naturally encounter a 403 or 401 on a path like /admin, note the server header and page title to fingerprint the technology without further requests.

Testing Steps (Minimal Interaction)

From passive recon, compile a list of candidate URLs.
For each, issue a single HEAD request (or GET with a minimal byte range) to confirm accessibility and HTTP response code. Use a browser‑like User‑Agent.
Note the response headers (Server, X-Kubernetes, X-Content-Type-Options) and the page title (if body snippet returned) to identify the panel type.
Do not log in or attempt default credentials – even a failed login can generate a security event.
If the panel loads a full interface without authentication, document the URL and panel type and cease interaction.
Document: URL, panel type, authentication status, and whether it is accessible from the internet.

AI‑Assisted Analysis (Prompt Template)

[ROLE] Infrastructure security analyst
[FINDINGS]
  - Port 8080: Kubernetes Dashboard accessible, no authentication bypass needed (anonymous access enabled)
  - Port 9200: Elasticsearch API returns cluster stats without authentication
[TASK] Assess the severity of these exposed admin panels.
  - CVSS per panel
  - Business impact (what can an attacker do with access to each?)
  - Remediation for each finding
[OUTPUT FORMAT]
  - Severity table: Panel | CVSS | Attack Scenario | Remediation
[CONSTRAINTS] Analysis and remediation only. No interaction with the exposed panels beyond confirming access.

Stealth Hard Stops

[NO] Do not interact with admin panels beyond a simple reachability check.
[NO] Never attempt default credentials unless explicitly authorized in writing.
[NO] Do not execute any commands through exposed interfaces.
[YES] URL + HTTP response code is sufficient evidence.
[YES] Report immediately if the panel exposes real infrastructure data without authentication.

Integrating AI Throughout Testing

All phases benefit from generative AI for:

Ideation and hypothesis generation: Prompt LLMs with in‑scope technology descriptions and ask for possible exposure paths (e.g., “Given a target using AWS ECS and Terraform, what infrastructure misconfigurations should I look for?”).
Automated log and response analysis: Feed sanitized HTTP responses or configuration excerpts and ask for structured severity assessments and remediation recommendations.
Stealth reasoning: Use AI to design request sequences that mimic normal traffic and avoid triggering alarms.

The provided HTML reference (Red/Blue/Purple strategy patterns) maps these infrastructure tests to broader team functions – red team simulation, blue team detection indicators, and purple team validation exercises. When documenting findings, include corresponding detection opportunities (e.g., “this S3 public read should fire a Config rule or CloudTrail alert”) to help blue teams improve detection post‑assessment. This aligns with the purple team philosophy of continuously validating that security controls actually work.

All testing must be pre‑authorized, bounded, and performed with extreme care to avoid production impact or data exposure. The reconnaissance and validation steps above are designed to provide sufficient proof of vulnerability while minimizing risk to the client and keeping tester activity under the radar.