Who in DFIR doesn’t like a good challenge?
We had a case recently in which modifications made to a Windows XP Registry, and the impact of those changes on the environment of a particular domain account, were quite important. Digital forensics practitioners on the other side of our case developed their findings on this issue by virtualizing a forensic image obtained from the computer and logging into it with a local account, rather than the domain account in question. Why?
The issue according to the other digital forensics practitioners was that the associated network (and the domain controller attached to it) were not available to the virtual machine and that the domain account password was not stored locally, so they had to use a local account in their testing. This explanation did not sound right to us, so we got to work.
There are a number of online resources which discuss what Domain Cached Credentials (DCC) are and how to extract them. There are also a number of online resources which discuss tools for password recovery. These topics are not the focus of this article, instead we will focus on our process used to recover the password of an important domain account in our case.
The computer in question was a relic by today’s standards — running Windows XP — and had indeed been a member of a domain. The computer had a mixture of local and domain accounts. Consider the following list of accounts in our case (names have been changed):
Domain\AliceNew (The account we were most interested in)
The accounts Computer\Alice, Domain\Alice, and Domain\AliceNew appeared to be related to the same individual that we were interested in (Alice) based simply on their names. So, let’s get some password hashes.
Get the Hash
We are not going into great detail about DCC except to say:
- Where extracting local password hashes require the SAM and SYSTEM hives, password hashes for domain accounts require the SECURITY and SYSTEM hives.
- Hashes for DCC are salted with the username which means rainbow tables aren’t going to be helpful (unless you have pre-computed for that username).
We extracted the necessary hives and used creddump  to dump the hashes.
Brian’s 3 Principles of Password Recovery
Before proceeding onto password recovery, consider the following — what we’ll call Brian’s 3 Principles of Password Recovery:
- Don’t overlook the low-hanging fruit
- Your findings are speaking to you
- People tend to be predictable
Principle #1 – Don’t overlook the low-hanging fruit
We have several password recovery tools in our toolbox, but we went with hashcat  because it supports DCC. We started simple and downloaded one of our favorite wordlists ‘rockyou ’ and began a dictionary attack on the extracted hashes. A dictionary attack, simply put, reads in a list of words and checks them against the hash of each password.
Principle #2 – Your findings are speaking to you
We observed some things about the passwords recovered so far:
- Both passwords were at least 9 characters long
- Both passwords started with a capital letter
- Both passwords ended with a number
- Both passwords only contained lower-case letters aside from the first and last characters
Principle #3 – People are predictable
Now that we know something about two of the passwords, let’s see if Principle #3 holds.
One of the features of hashcat is its ability to perform mask attacks . A mask attack allows you to describe your password string as a series of symbols. For example, all upper-case letters are represented by the symbol ‘u’, all lower-case letters by the symbol ‘l’, digits by the symbol ‘d’, and punctuation by the symbol ’s’. Hashcat also allows you to create custom character sets, for example all characters used to represent hexadecimal values, but we’ll save that for another time.
Let’s go back to what we learned so far about our passwords to start building our pattern for a mask attack:
- The passwords start with a capital letter — ‘u’
- The passwords end with a number — ‘ud’
- The passwords contain lower-case letters between the first and last character — ‘uld’
- The passwords are at least 9 characters long — ‘ullllllld’
We first tried a mask attack with the pattern ‘ullllllld’ — no luck. We knew the passwords were at least 9 characters, so we added another ‘l’ in the mix ‘ulllllllld’ for a 10 character password — again no luck. We repeated this pattern at lengths 9 and 10 with two digits at the end instead of one with no luck.
Let’s remember Principle #3 — people are predictable. We know from experience that in addition to ending passwords with numbers, punctuation characters are also frequently used. What if we alter our pattern to include these characters? We substituted ’s’ for ‘d’ at lengths 9 (‘ullllllls’) and 10 (‘ulllllllls’) — again no luck here.
We also know from experience that mixing numbers and punctuation at the end of passwords can be popular, so let’s try this one more time at length 9 (‘ullllllds’) — no luck. What about at length 10 (‘ulllllllds’)?
We were ready to confirm that our work was solid. We quickly virtualized the forensic image using Arsenal Image Mounter’s  “Create VM” feature. With the VM launched, we were able to logon to the domain account using the password we recovered … and proceeded to perform testing that the other digital forensics practitioners were not able to because they were not able to access the account.
The password we were ultimately interested in was not in any of our wordlists (when we went back and looked, there was nothing even close) and a pure brute-force attack would have taken more time than we had (or cost more money than we wanted to spend). Only in drawing on a combination of approaches were we able to achieve our result as quickly as we did.
Please support us, as we work to make maximum exploitation of electronic evidence more accessible, by learning more about the powerful and unique functionality our tools provide. You can learn more about our tools at https://ArsenalRecon.com/#products . Thank you!