Hardening your Windows Client

It has been a while since I wrote a good blog post. So the time has come for me to write a little about Windows security from a Penetration tester perspective. Hope you like it.

There is probably a tons of guides and blog posts on how to hardening your Windows clients. In this post however I will focus on what a Penetration tester looks for and tests. Remember that a Penetration tester often wants to test how far he can get in a network, but a real hacker often stops when he gets what he wants. A hacker can often be satisfied by getting a shell running as the logged on user.

I always hear as long as you get physical access to the machine you own it. And that is somehow true, but you still need to hack it to get in. So this will take this statement to a test.

In this post, the goal of the Penetration tester is to get as far as he can get. The ultimate goal is domain admin on a domain controller. This is of course often scenario based for a penetration tester. So I will describe 2 scenarios and how I tested them, then I will explain mitigation factors to prevent this in the future.

Scenario 1 is that I somehow get my hands on a computer inside a organization. (breakin ,social engineering etc.)
– This computer is not bitlocker encrypted.
– The domain user using this machine is not a local admin.
– The Local administrator account is disabled.
– The machine has all normal physical ports – USB,PCMCIA,HDMI,Firewire etc.
– The Windows Firewall is configured opened for 445, ICMP and WinRM from all hosts within the domain.

Scenario 2 is also a computer that I get my hands on inside a organization. (breakin ,social engineering etc.)
– The computer is bitlocker encrypted without PIN.
– The domain user that uses this machine is not a local administrator.
– The Local administrator account is enabled.
– There was also a domainhelpdesk user cached on the machine
– The machine has all normal physical ports – USB,PCMCIA,HDMI,Firewire etc
– The Windows Firewall is configured opened for 445, ICMP and WinRM from all hosts within the domain.

The big difference in these 2 scenarios is the fact that scenario 1 includes bitlocker encryption and that scenario 2 has cached credentials for a helpdesk account. Okay, lets start the walkthrough of the scenarios.

Scenario 1:
First goal is to get local admin access. How can we do that?? In many ways basically. The easiest way I know of is to change binaries. Let me explain.
In Windows there is almost an EXE/DLL file behind every thing you click on. For example the “ease of access” or “Sticky Keys” (5 times on SHIFT). There is also the Windows+P to change display that launces a EXE file (displayswitch.exe). I will not go into detail on how to find out what EXE files that is used on different action, but the key tool is Process monitor by Mark Russinovich.

The exe file behind “ease of access” is named utilman.exe and “Sticky keys” is named sethc.exe. So what I want to do is to change these binaries with cmd.exe. How do I do this? I boot up on a Windows Installation Media and hit SHIFT+F10. (You can of course use any boot cd you want)

This will launch a command prompt from where I can Issue the following command:
copy c:windowssystem32cmd.exe c:windowssystem32utilman.exe (answer Y to confirm the overwrite)
copy c:windowssystem32cmd.exe c:windowssystem32sethc.exe (answer Y to confirm the overwrite)

Then we are done with the binary inject attack. Boot up the computer as normal and hit either the “ease of access” button or use 5x Shift key to launch “sticky keys”.

So as you can see on the screenshot you can now get a shell in 2 ways ( I could do the same with displayswitch.exe and using Windows+P to get a shell). Each resulting in you running shell as system. So whats next. Thats right, create accounts…..
Run the following command in either of the shells:
net user msitpros H4ck3r4L1fe /add
net localgroup administrators msitpros /add

Then you need to reboot the computer in order for the new account to be active. After the boot we can log on as .msitpros and password H4ck3r4L1fe and we are now a local admin. This was I see it phase 1 in the test. Next phase is finding NTLM hashes on the box in order to user the Pass-the-hash attack so we can harvest other hashes.

So how to we dump the NTLM hashes? Well, there are several ways of doing this. My “new” favorite way of doing this is by using a Powershell script(what else??). In order to dump hashes from Powershell we need to run it as the SYSTEM account. So how do we do that excactly? Easy, download a copy of pstools from Mr. Mark Russinovich (great guy). It can be found here: http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx
Extract it and run the following command from within the PSTools folder:
.psexec -i -s powershell.exe

This should then launch a powershell command window. You can now run the whoami command to verify your identity.

Next up is executing this well written script :
Source: http://truesec.com/Content/SiteContent/Tools/Get-TSLocalHash.txt (Kudos to Truesec)
This will show you the NTLM hashes that is present on the machine.

And getting the hashes is like getting access to the users password. So, lets try to use them for something fun, maybe connect to another machine for instance.
For my next “trick” I am using a tool called “Windows Credential Editor” or WCE. This tool can be downloaded from here:
X86: http://www.ampliasecurity.com/research/wce_v1_3beta.tgz
X64: http://www.ampliasecurity.com/research/wce_v1_3beta_x64.tgz
(In order to extract this using 7-zip you need to extract the extracted file once more)

Okay, so you got the tool in place. Let’s use it to pass the hash to another machine. Let take the Hash to “Tro Jan” and pass it to another box to see if it works. This is the syntax for launching another command using this hash:
wce.exe -s <user>:<domain>:<LM hash>:<NT hash> -c cmd.exe
or with values:
wce -s “Tro Jan”:Win7-Target:aad3b435b51404eeaad3b435b51404ee:e19ccf75ee54e06b06a5907af13cef42 -c cmd.exe
‘ note that Win7-Target must be the machine name of the target machine when using local accounts, otherwise use domain name.

This should now launch another cmd. And when you try to use for example “net use \win7-targetc$” from the new cmd it will not ask you for username or password. It sends your crafted Hash to the other machine. (Evil laughter time – Mohahaha)
So now I just have to bounce around the machines until I find one with a domain admin account. I will then use the same method to access the domain controllers and then gain the ultimate goal.

Scenario 2:

This computer has as you remember bitlocker, fortunate for me it does not have a startup pin. So how far can I get in this scenario? I got no username or password. If I try to use a offline media I will not get into the disk, because of the bitlocker encryption. So a cool hack is to use the firewire exploit. I know this might be very old information to many of you, but as long as it is still valid I choose to use it and describe it. If you have never heard of anything like a firewire exploit, then let me explain it to you. Firewire is a technology that get’s direct access to the memory of the machine (its a feature, not a bug….). It is designed to have very high speed, and in order to achieve this they found out that direct memory access was the way to go.

Okay, so then I use Inception ( a cool tool that can bypass winlogon with firewire by patching MSv1_0.dll in memory) in order to hack my way into the local admin account.

*source: http://www.breaknenter.org/projects/inception/

If you want to see the attack and how it works take a look at this video:
http://www.youtube.com/watch?v=tsb6ojxa3ik

Fortunate for me the administrator account is enabled. So I will just launch the attack from Inception and be logged on as administrator, and the create another user with local administrator rights.
I will then logg on with my new account and use Pass-the-hash attack as described in scenario 1 with the helpdesk account as described in the scenario overview. I will do this until I find a domain admin account and then move onto the domain controllers. And there we are….King of the castle…..
Another approach could be to crack the hash to the helpdesk account using rainbow tables. (more on that in a later post)

Mitigation:

So what is the lesson learned here? First of all, it is important to think about security at all places, not just only the servers.

In order for bitlocker to have an effect you must at least disable Firewire. And not just disable it in BIOS. If you just disable the Firewire port itself you will not prevent anyone from using a PCMCIA card with Firewire. What I am trying to say is that we need to restrict the setup class GUID. Microsoft has described this problem and the solution here: http://support.microsoft.com/kb/2516445/en-us

– Bitlocker would have helped a lot in scenario 1, but not without disabling Firewire.
– Disabling local adminsitrator accounts would have helped a lot in scenario 2.
– Blocking communication between clients would have stopped the Pass-The-Hash against other workstation and not letting me to harvest hash’es
– If both scenarios had PIN on the bitlocker I would get nowhere. So a good mitigation factor is to implement bitlocker with PIN and not just TPM.
– After enabling PIN on bitlocker I would also make sure that the machines are going to Hibernation rather than standby.

To sum it all up: disable local admin accounts, do not give anyone local admin rights, disable firewire, enable bitlocker with TPM and PIN, block client-to-client communication and remove debug priviliges

In my next post I hopefully will write about how to escalate privileges using different techniques and of course how to prevent them.