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.

ID	Title	Description
T1	Web Recon · robots.txt	Discover hidden paths from robots.txt Disallow directives
T2	The Unlocked Warehouse · Public S3	Retrieve files directly from a publicly exposed S3 bucket
T3	Behind the Page · HTML Source	Investigate credentials buried in HTML comments
T4	First Steps with curl	Check information embedded in HTTP response headers
T5	Leaked Config · .env File	Find a .env file mistakenly placed in the web root
T6	First Steps with AWS CLI	Use the key found in .env to run sts get-caller-identity

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.

ID	Title	Description
Stage 0	The Forgotten Debug Mode	Extract AWS keys from debug output left in an auth API error response
Stage 1A	Flip the Bucket	Find a file hidden under a .hidden/ prefix in an S3 bucket
Stage 1B	Who Am I?	Read IAM policy metadata to understand the compromised user's permissions
Stage 1C	The Past Never Disappears	Recover AWS keys left in a Git repository's commit history
Stage 1D	Ask the AI	Prompt injection against an AI assistant embedded in the employee portal
Stage 2A	The Deleted File	Recover a deleted file using S3 object versioning
Stage 2B	The Permission Map	Use sts:AssumeRole to pivot laterally into the DataAnalystRole
Stage 2D	The Function's Secret	Retrieve sensitive data stored in Lambda environment variables
Stage 2E	The Parameter Labyrinth	Navigate SSM Parameter Store paths to collect secrets
Stage 2G	The AI's Permissions	Extract S3 data via an over-privileged Bedrock agent
Stage 3A	The Vault Key	Retrieve the ZIP decryption password from Secrets Manager
Final	Consolidate the Evidence	Decrypt the evidence file using all collected information to expose the CEO's fraud

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.

ID	Title	Category	Description
Stage 2C	The Server's Shadow	bonus	Flag stored in EC2 instance tags
Stage 2F	Find It Automatically	bonus	Scan all branches for secrets using gitleaks
Stage 3B	The Invisible Voice	bonus	SSRF to IMDSv1 to steal EC2 role temporary credentials
Stage 3C	The False Face	advanced	Self-declare custom:role=admin during Cognito sign-up
Stage 3D	The Truth Inside the Image	bonus	Recover files deleted by RUN rm from Docker image layers
Stage 3E	The Neighbor's Vault	advanced	Read another tenant's data via wildcard permissions on S3 Vectors
Stage 4	Follow the Trail	blueteam	Identify attacker operation timestamps from CloudTrail logs
Stage 5	Suspicious Activity	finale	Decrypt CTO complicity evidence by tracing late-night activity in CloudTrail
Stage 5B	Combined Attack Surface	bonus	Call an internal API by combining intelligence from Stage 3D and Stage 3E

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.