CTF Event Report: Security-JAWS 10th Anniversary Day 2 — All 27 AWS Security Challenges Solved

Introduction

I participated in the CTF held on Day 2 of "Security-JAWS DAYS ~10th Anniversary Event~", organized by Security-JAWS, a Japanese AWS user community focused on cloud security.

The CTF was themed around a fictional SaaS company called "TechVault", and the scenario had us conducting a penetration investigation — starting from their employee portal and ultimately uncovering evidence of fraudulent transactions. It was an exceptionally well-crafted CTF with a cohesive narrative running through all challenges.

Event Overview

• Duration: 13:00–17:00 / 4 hours
• Total challenges: 27
  • Tutorial: 6 / 290 pt
  • Mainline: 12 / 2,300 pt
  • Bonus: 5 / 1,400 pt
  • Advanced: 2 / 700 pt
  • Blue Team: 1 / 300 pt
  • Finale: 1 / 600 pt
• Setting: AWS environment of a fictional SaaS company "TechVault"

The story begins with an intrusion investigation of TechVault's portal service and culminates in gathering evidence of someone's fraudulent transactions. The level of polish in the scenario design was remarkable.

Results

• Challenges solved: 27 out of 27
• Score: 5,310 pt (max: ~5,590–5,650 pt)
• Time to complete: 2 hours 48 minutes 36 seconds
• Final ranking: 12th out of 125 participants
• What went well:
  • Using knowledge and CLI tools I don't normally touch in daily work, and working through them hands-on gave me a much deeper understanding of each technique.
• What I'd improve:
  • I should have set up my environment beforehand. I normally use devContainers, so my host machine only had the minimum: AWS CLI and Python. Docker, OpenSSL, Boto3, and similar tools were missing, which cost me more time than necessary.

Challenge Structure

Tutorial (290 pt)

A step-by-step introduction to web reconnaissance and AWS CLI basics.

The T5→T6 flow was clever. You grab a key from .env and immediately use it with the AWS CLI — a hands-on demonstration of how a web vulnerability becomes an AWS entry point.

Mainline (2,300 pt)

The core of the CTF: an attack chain that follows the path of intrusion → privilege escalation → evidence collection, starting from Stage 0.

The Bedrock agent challenge (Stage 2G) was fresh. The agent was configured with direct S3 access, so data from a bucket I couldn't read directly could be pulled out simply by asking the agent "show me the project metadata." It drove home how important permission design is when integrating AI into your stack.

Bonus / Advanced / Blue Team / Finale (3,000 pt)

Additional challenges branching off the mainline, each requiring deeper technical knowledge.

Stage 3D was by far the most time-consuming for me — because Docker wasn't installed in my CTF environment. Instead of using docker history (which would have shown it in seconds), I had to query the ECR API directly to fetch the image manifest, download each layer, and extract the tarballs manually. Painful on the clock, but I ended up with a much deeper understanding of how Docker image layers actually work.

Stage 4 and Stage 5 involved parsing large CloudTrail log files with jq to reconstruct the attacker's footsteps — a great taste of what SOC/incident response work feels like. Stage 5 in particular required chaining multiple steps: find the suspicious late-night (JST) operations in the logs, track down the Secrets Manager path they pointed to, and decrypt the encrypted evidence file with OpenSSL. OpenSSL wasn't available either, so I ended up implementing the decryption in Python.

The Full Attack Chain

Each challenge looks independent, but they're all connected as a single story.

Obtain AWS keys from debug API response (Stage 0)
        ↓
IAM recon reveals an AssumeRole-able role (Stage 1B)
        ↓
Pivot laterally into DataAnalystRole (Stage 2B)
        ↓
┌─────────────────────────────────────────────────────┐
│  Collect intelligence across multiple parallel paths │
│  · EC2 tags (Stage 2C)                              │
│  · S3 versioning — recover deleted files (Stage 2A) │
│  · Lambda environment variables (Stage 2D)          │
│  · SSM Parameter Store (Stage 2E)                   │
│  · SSRF → IMDSv1 (Stage 3B)                        │
│  · ECR Docker layer analysis (Stage 3D)             │
│  · S3 Vectors cross-tenant leak (Stage 3E)          │
└─────────────────────────────────────────────────────┘
        ↓
Retrieve password from Secrets Manager (Stage 3A)
        ↓
Decrypt ZIP to obtain CEO fraud evidence (Final)
        ↓
Trace CTO complicity via CloudTrail (Stage 4 → 5)

Each individual vulnerability might look limited in isolation, but chaining them together produces a critical breach. Stage 5B is the perfect example: an internal API only reachable by combining intelligence gathered from two separate advanced stages.

Key Takeaways and Mitigations

Information Leakage (Debug, Headers, etc.)

Debug output that's convenient during development can leak AWS keys if left enabled in production. HTML comments, response headers, and robots.txt are all reconnaissance vectors attackers regularly check.

Mitigations:

• Disable debug mode in production environments.
• Remove unnecessary response headers like X-Powered-By.
• Never place secrets in front-end source code.

S3 Misconfiguration

Three distinct S3 issues appeared: public access enabled, a .hidden/ prefix used as security-by-obscurity, and deleted files recoverable via versioning. All three stem from treating S3 like a traditional filesystem.

Mitigations:

• Enable Block Public Access on all buckets.
• Prefixes are not access controls.
• If versioning is enabled, also design lifecycle policies to expire delete markers and old versions.

Secrets in Git History

Even after deleting a .env file and committing the removal, git log -p surfaces it instantly. Tools like gitleaks can scan every branch and every commit in seconds.

Mitigations:

• Integrate git-secrets or gitleaks as a pre-commit hook.
• If a secret was already committed, rewrite history with git filter-repo and rotate the key immediately.

Prompt Injection

A single sentence — "ignore previous instructions" — was enough to extract the contents of the system prompt. Using the system prompt as a "hidden" information store is not a security boundary.

Mitigations:

• Never put sensitive information in system prompts.
• Validate both inputs and outputs. Make the boundary between user input and system instructions explicit.

Overly Broad IAM Permissions and AssumeRole

Having sts:AssumeRole allows switching to a different role. In this CTF, flags were embedded in IAM policy descriptions and EC2 tags for challenge purposes — but in the real world, metadata fields are an underappreciated place for sensitive data to accumulate.

Mitigations:

• Apply the principle of least privilege rigorously.
• When granting sts:AssumeRole, restrict the target resources.
• Use Condition keys in trust policies to restrict callers.

Poor Secret Management

Three storage locations appeared: Lambda environment variables, SSM Parameter Store, and Secrets Manager. Even Secrets Manager provides no protection if the IAM permissions granting GetSecretValue are too broad.

Mitigations:

• Manage secrets in Secrets Manager.
• Scope the GetSecretValue resource policy to the specific secret ARN.

SSRF × IMDSv1

A URL preview feature in the dashboard was fetching external URLs server-side — and there was no filtering to block requests to http://169.254.169.254. IMDSv1 requires no token, so SSRF access to the link-local address yields EC2 role temporary credentials directly.

Mitigations:

• Enforce IMDSv2 (HttpTokens: required) on all EC2 instances.
• URL-fetching features should use an allowlist, and must block private IP ranges and link-local addresses.

Secrets Persisted in Docker Image Layers

A Dockerfile pattern like COPY secret.txt . → RUN python setup.py → RUN rm secret.txt produces a final image where secret.txt is not visible at runtime. However, downloading the image layers directly from the ECR API reveals secret.txt intact in a prior layer's tarball.

Mitigations:

• Use multi-stage builds; never copy secrets into build contexts.
• Retrieve secrets from Secrets Manager at runtime instead.

Broken Multi-Tenant Permission Design

The S3 Vectors resource policy was set to Resource: "*", allowing a role scoped to one tenant to query another tenant's vector data. Tenant isolation in SaaS demands rigorous permission separation.

Mitigations:

• Constrain the Resource and Condition in resource policies to tenant-specific identifiers.
• If sharing a vector bucket, scope queries and metadata access by tenant at the API level.

Cognito Authorization Design Flaw

Passing custom:role=admin in --user-attributes during aws cognito-idp sign-up was enough to self-declare administrator status, which the application then trusted for authorization decisions.

Mitigations:

• Control role assignment server-side (e.g., in a Pre Sign-up Lambda Trigger).
• Never use attributes that external parties can set as the basis for authorization.

AI Agent Over-Privilege

The Bedrock agent's IAM role had access to S3 buckets that the DataAnalystRole itself could not read. By asking the agent a natural-language question, data from otherwise-inaccessible buckets was pulled out indirectly.

Mitigations:

• Apply the principle of least privilege to AI agent roles as well.
• Explicitly enumerate and restrict the resources an agent is permitted to access.

CloudTrail for Evidence Preservation

With CloudTrail logs in place, "what happened, when, and by whom" can be reconstructed almost completely. A handful of jq filters were enough to trace the attacker's full activity.

Mitigations:

• Enable CloudTrail in all regions and ship logs to S3.
• Pair with GuardDuty for real-time detection.
• Apply Object Lock to the log bucket to prevent tampering.

Closing Thoughts

All 27 challenges together gave me a visceral sense of how AWS misconfigurations cascade. Each individual problem represented a realistic "seen-in-the-wild" vulnerability — but what made this CTF special was that they were all woven into a single coherent story.

AWS certifications don't teach you why something is dangerous. Solving these challenges hands-on — making mistakes, working around missing tools, figuring out the low-level APIs when Docker wasn't available — built an intuition that studying documentation alone never could.

Highly recommend participating if a similar opportunity comes around. And if you're building on AWS, I hope this report serves as a useful checklist of things worth double-checking in your own environment.