Thursday, June 30, 2016

Metasploit's RealVNC authentication bypass module for CVE-2006-2369 is pretty fun because it's one of those that is way too easy. If a victim has a RealVNC server which is earlier than 4.1.2, or a LibVNCServer VNC server earlier than 0.8.2, a customized VNC client can send 'Type 1 - None' as the authentication type and completely bypass authentication. Metasploit does this for you.

This vulnerability was discovered by Steve Wiseman by accident while coding his own VNC software, so that's a fun fact. This is of course a very old vuln, but still exists out there, unfortunately. Here are the commands to exploit using msfconsole:

Saturday, May 28, 2016

In an internal pen test, there are cases where you have pulled a list of domain usernames but are still looking to get the password for one of these accounts. One possible technique for accomplishing this would be to use Metasploit to identify any passwords which are the same as the username. Below are steps to use the Metasploit console (msfconsole) to perform this particular type of password attack. And here's a pretty picture of a test box performing such an attack on itself, just as an example:

Example attack

Instructions:

1. Put your list of usernames into a text file with one username per line, and place the file in the Metasploit directory.

2. Open the Metasploit console and run: use auxiliary/scanner/smb/smb_login

3. Pick one domain workstation to test against and set it in MSF (Metasploit): set RHOSTS <ip-address>

4. Tell MSF the domain name: set SMBDomain <domain>

5. Tell MSF the name of the file containing the usernames: set USER_FILE <filename>

6. Tell MSF to use the username as the password: set USER_AS_PASS true

7. For some reason MSF doesn't like to run USER_AS_PASS unless you explicitly specify another password or password list, as well. If you don't do this, it will run the exploit but not actually test the username as the password. Just pick a random weak password to also test for perhaps, like this: set SMBPass password123

8. If you know the password policy will allow three login failures without causing a lockout, consider also testing for blank passwords: set BLANK_PASSWORDS true

9. Then run the exploit with: run

One of the things I like about this method, is that it's not as loud as a full brute force. As long as you keep below the lockout policy, you may be able to stay under the radar completely, while still testing every single domain user. When the test is complete, you can see what kind of creds you got with this command: creds

To export the creds as a file, you can use: creds -o <filename.txt>

To get help with the creds command, use: creds -h

To list all possible options for the attack, use: show options

After getting a domain user's creds, the next step will often be to authenticate with these creds to various computers and run mimikatz. If you run mimikatz on enough workstations, you're bound to eventually find one that will yield domain admin creds, resulting in red team happiness.

Monday, April 4, 2016

For whatever reason, when performing a P2V on a Windows 7 machine, you are very likely to experience a BSOD, even if you use VMware Converter. There is a painless workaround, however, using a combination of Sysinternals Disk2vhd and Starwind V2V Converter. In my case, after using these tools, I also had to make some registry edits with an offline registry editor in order to resolve the BSOD. The steps are actually quite easy, though it took me a while to figure them out.

Before I give you the how-to, I want to say I'm very thankful to thesetwo bloggers for the information on the aforementioned tools, and also thankful to various forum posters from whom I got the needed registry settings. Today's post is meant to gather the various information I used into one resource and relate my experience. Also, the offline registry edit I did from a live (virtual) CD may be useful information to some. Here are the steps I used to P2V my Windows 7 Pro 64-bit machine so that it could be used in VMware Workstation Player:

1. Download and run Disk2vhd on the Windows 7 physical machine you want to convert.

2. The Disk2vhd interface is very simple. Just be sure to set it to be vhd (not vhdx which would be for Windows 8) and let it do it's thang.

3. Download, install and run StarWind V2V Converter. (They make you fill out a contact form and then they send you a download link. Or, you may be able to get this link to work, so you don't have to. :) )

4. Use StarWind V2V Converter to convert your vhd to a vmdk and copy the resulting vmdk to your host machine. It has very simple interface.

5. Open VMware Workstation Player and create a new Windows 7 virtual machine. Before powering it on, however, remove the hard drive and replace it with the vmdk created above.

6. Power on the VM. In my case, at this point I still got a BSOD and was considering giving up. If this is you, read on...

7. You're going to have to make some offline registry edits on your unbootable system. You could do this by connecting your virtual hard drive of your VM to another Windows VM (google it), but my preference was to boot the VM to AVG Rescue CD. Just download AVG Rescue CD and boot your VM to the ISO.

8. Choose the registry editor in the AVG Rescue CD menu under Utilities.

9. Navigate to HKLM\SYSTEM\ControlSet[001]\services\

10. For me, I was able to fix the problem by editing each of the following to be a value of 0:

However, reading online, it appears that some users with different drivers had to make other registry changes under HKLM\SYSTEM\ControlSet[001]\services\. Here are some of the other edits I saw on various forums:

Wednesday, September 16, 2015

In some scenarios, an attacker may have been able to extract Active Directory password hashes but has not been able to successfully crack some or all of them. In this case, it may be possible to perform authentication by merely passing the hash itself, instead of the password. The specific focus of this post, is a pass-the-hash attack on a website which uses NTLM authentication.

(click to zoom)

Under normal circumstances, a user might pull up Internet Explorer and browse to the website which uses NTLM authentication. At that point, if this user is not a domain user, they would typically get a prompt for a username and password. If the user who is logged into the computer is a domain user, they would potentially be automatically logged in using the Windows credentials of the current login session. In the attack, our scenario involves an attacker who has already extracted the victim user's password hash (but not the actual password) and will use it for login. The attacker is logged into Windows with credentials which do not allow them access to the website in question. However, the attacker passes the hash to the current Windows session in order to impersonate the victim user. The attacker then browses to the website using Internet Explorer and is able to automatically authenticate without ever needing the password itself - only the hash. This attack can take place from any computer which is able to access the website. If the website is only accessible internally, as many such NTLM pages are, then the attacker would need to have access to a computer located on the LAN. However, if the website is accessible from the Internet, the attacker could perform the pass-the-hash attack from a remote location outside the network, depending on the individual circumstances. Below are the details on the attack.

Steps:
1. Log onto the Windows computer which will be used for the attack
2. Configure Internet Options:
a. Security>Custom level for the zone>Automatic logon only in intranet zone
b. Add website to Local Intranet sites
3. Run wce, give it the hash and tell it to call IE: wce -s <UserName>:<DomainName>:<LMHash>:<NTHash> -c "C:\Program Files\Internet Explorer\iexplore.exe"
4. Browse to the website for the automatic login

As you can see, the attack is very simple. Here are the wce command line switches in use:

-s Changes NTLM credentials of current logon session. Parameters: <UserName>:<DomainName>:<LMHash>:<NTHash>.
-c Run <cmd> in a new session with the specified NTLM credentials.

Hmm...Maybe it's time to re-think that Sharepoint NTLM authentication.

Wednesday, September 9, 2015

The best way to crack the password on a Microsoft Office file is by first extracting the hash of the actual password itself. But how to do that? The script office2john.py is really useful for this. It extracts the password hash and converts it to a format that John the Ripper can handle. This is not a tutorial on John, so you'll have to hit up google for that. But I'll give you the basic commands to get the job done. This should work on files from pretty much any version of Office, including xls and xlsx, etc. (Office 2003-2013).

Depending on your cracking strategy, you will likely also need a dictionary file for the attack. I will be using a dummy dictionary file as PoC, but there are lots out there and I won't go into that as a part of this post.

You'll of course also need John installed (google it) and will need a target Office file. I'm doing this from Kali 2.0 on an Excel 2013 test file which I encrypted with a password from Excel. Here are the files/names I used:

--session=An optional identifier for you to manage the John session, in case you have multiple sessions. You can make the string after the equals sign be whatever you want.--rulesEnables wordlist rules--wordlist=The dictionary file to use for the attack.[filename]The last parameter is the text file containing the extracted hash.

It should show the password when it completes, if your cracking was successful. You can also run the following to show the cracked password, after it completes: john --show test-crack-hash.txt

Now you should be able to open the Office file using the password you cracked. It goes without saying, that this should only be used for ethical purposes, so don't do evil stuff!

Sunday, August 30, 2015

I like to use YUMI to maintain a USB thumb drive with various live operating systems and installers, including Kali. I generally prefer this over the dd image method. From time to time, I run into trouble with operating systems which aren't immediately compatible, but can often find a resolution. This was the case with Kali 2.0. I could boot into the installer, but the installer itself would fail to detect the installation media. This caused the installer to fail completely. Here are the screenshots - you can click to zoom.

Here's the fix I came up with. I went back to the menu and chose Execute a Shell. Using the shell, I deleted /cdrom and created a new symlink to /cdrom from the appropriate directory of the installation media. (Fyi, in this particular chassis, I don't have a CD-ROM drive at all.)

This tricked the installer into thinking the files on the USB thumb drive were located on an installer CD. The issue was immediately resolved and the installer was able to proceed past the point it was stuck at.

Lamer Disclaimer

Although this blog is not designed to assist you in breaking the law or accidentally hosing you/your friends computer, you should not do ANYTHING you read about on this blog because you may indeed end up with a broken computer/friend's computer or in jail -- or all of the above. This blog is purely for informational and research purposes and I will not be held liable for you using or misusing something you learned from this blog. Anything you try from this blog is at your own risk!

Oh, and also this blog is not in any way affiliated with or officially sanctioned by my employer. (Duh.) Nothing on this blog is to be interpreted as reflecting or not reflecting the views or positions of my employer. (Duh again.)