A Series of Unfortunate Events

by {"login"=>"averagesecurityguy", "email"=>"stephen@averagesecurityguy.info", "display_name"=>"averagesecurityguy", "first_name"=>"", "last_name"=>""}

When people demonstrate penetration testing they always show the easy exploits like MS08-067 or the Apache Tomcat WAR upload, both of which are in Metasploit. While I still see these exploits available in the networks I pentest, most of the time exploitation is a lot more difficult than simply "popping a shell." One of my recent pentests shows this clearly.

Unauthenticated NFS Access

First, I scanned the network with Nessus and did not find any easily exploited vulnerabilities but I did find a medium-risk vulnerability showing unauthenticated access to multiple NFS shares (Nessus ID 42256). Browsing the shares I found a backup copy of the client's public web site, which was developed using Visual Studio. Visual Studio stores database connection strings, including plaintext passwords, in .config files. Using the command grep -r connectionStrings= * at the root of the source directory, I found multiple connection strings that used three different database passwords.

Windows SMB Null Sessions

The Nessus scan also identified two machines that allowed unauthenticated user enumeration using the host security identifier (SID) (Nessus ID 56211). Using this medium-risk vulnerability, I determined the local administrator account had been renamed.

Password Reuse

Next, I used Metasploit's smb_login auxiliary module, use auxiliary/scanner/smb/smb_login, along with the local administrator account and the three passwords identified in the web application source code to identify any instances of password reuse. Luckily, there were two machines that allowed local administrator access with one of the passwords I found.

Complete Trust in AV

Next, I used Metasploit's psexec exploit module, use exploit/windows/smb/psexec, along with the local administrator username and password to attempt to get meterpreter access to the box. When I tried to run the exploit, I lost the network connection to the box. After a few minutes, the network connection was restored and I was able to try to exploit the box again. I determined the client's AV was flagging my attack and temporarily blocking my network connection.

For my second exploit attempt, I created a custom executable using msfvenom, this was also caught by the client's AV. Since I was unable to bypass the AV with msfvenom, I resorted to using a custom Python shell that I keep for such occasions. I modified the script to fit my situation and used PyInstaller to compile the script to an executable. Then I used the EXE::Custom option with the psexec module to run my executable on the machine. First, I had to setup a netcat listener to catch my reverse shell, nc -l -p 4445. My custom executable ran successfully and I had shell access to the box, but I wanted meterpreter access. So, I disabled the AV on the system and ran the psexec module again with the default meterpreter payload.

Lessons Learned

For Pentesters

• Rooting a box often requires more than running a Metasploit/Core Impact/$Vendor module.
• Sometimes you need custom code to bypass AV, learn to write some code or become friends with someone who can.

For Defenders

• Unauthenticated access gives an attacker a foothold into your network, eliminate it anywhere you can.
• Antivirus is not a silver bullet, it is too easy to bypass AV software.

In the interest of offering solutions and not merely pointing out problems, I would love for some of the defenders that read this blog to leave comments describing the techniques used to catch and/or stop these types of attacks.