Given the right tools, can you fairly easily crack a Windows domain account’s cached credentials on a modern Windows computer? Note: Not accounts in local SAM database, and not resetting Administrator account, or any of those classics, but the password of the account stored in Active Directory (but cached locally after login, and logout).
Say the scenario of a Windows Server 2008-based Active Directory account once used on a Windows 7 laptop, with password of eight characters long, and “complex”, as in Jo*öLk32.
The password strength makes it extremely difficult without a rainbow table. I don’t know how improved it is in Vista/7/2008, but it was trivial to pull weak passwords out of the domain cache thing in XP SP2 at least. I’m not on the cutting edge of cracking though. I just wanted to install a printer at work.
fgdump provides the tools to dump the local and cached passwords. Then you would need to use a rainbow table tool (oftcrack or similar) to attack those. However, given your password requirements, I wouldn’t be too confident - you are looking at something like a 1.3Tb Rainbow table for NTLM passwords that long with special characters as specified. YMMV.
Rainbow tables involve a memory/time tradeoff to decrease the size of the table. Hash tables get really big, really quickly (linear growth) when you increase the length of the hash and the number of characters possible. Rainbow tables are more expensive to compute and use, but are smaller for a given password length/character set.
Thanks for answering (to everybody for that matter), but I don’t get this last sentence. If you would take the time, please elaborate/clarify. Don’t hesitate to go technical on this, I have all the background knowledge to follow you. For instance, you specifically mention NTLM; why is that, when Kerberos is the preferred authentication protocol?
**
The background **to this question is, that I’ve been an IT pro and part time trainer for ten years, and a few years back I spent a lot of time on Windows security, and found that every time someone talked about “cracking Windows passwords”, it was always local accounts and/or very simple passwords; I never saw a way to actually crack a domain user (cached) account’s fairly long/complex password, upon closer examination. I fooled around with Jack the Ripper and so forth, but never got to actually crack “real life” accounts/passwords, and settled with that. Now, however, I’ve heard from otherwise trustworthy sources that it is a piece of cake, nothing to it. I’m simply wondering if that is true or if the demonstrations are sort of rigged. Of course, I could spend my working hours experiment with it, but I don’t have the time. Hence the dopers.
NT4 used to store passwords as NT-LAN Manager format - broken into 8-character segments. This was incredibly stupid, as the time to crack 8-character passwords (even just by trying all combinations) has shortened from months to hours with modern processors.
I once ran a Lophtcrack against the SAM of the domain at a place I worked (I was admin), and something like 50% of passwords were revelaed in 5 minutes (start with elementary dictionary lookup plus 2 numbers) and 75% within an hour, even back in the P90 days. Passwords were not as secure as they thought.
Plus, when you crack a password halfway, and the guy’s name is Mike Westfield (fictional example), userid is mwestfield, and the second 8 character chunk of his password is ld123, guess what the first 8 are? Depending on capitalization, possibly 4 choices but likely 2 choices.
I assume the stupid 8-char segments fot NTLM are gone now?
Kerberos won’t get used in certain situations. For example, if the Windows client is authenticating to a stand-alone Windows server (as opposed to a domain server), the client will use NTLM (or NTLMv2) as a default, depending on what OS versions client and server are using. Actually, Kerberos only gets used if both client and server are domain members; if either is not a member of the domain, then NTLM is used. Kerberos also requires a fair number of open ports between client and server (88/tcp/udp, 464/udp, 749/tcp, 750/tcp). If a firewall between client and server doesn’t permit that traffic, NTLM may get used.
NTLM is very vulnerable to rainbow tables. A quick search will find several pre-computed rainbow tables for BitTorrent download, complete up to 14 characters (including all special characters) available. I’ve even seen websites set up where you can feed an NTLM hash to a form and have the site spit back the plaintext result.
NTLMv2 uses a stronger hash, but the best way to defeat this completely is simply a longer password. I know of no way to return the plaintext value of a 21-character password if all you have is the NTLMv2 hash.
Kerberos is a network authentication protocol providing secure authentication over an insecure network - it does not change the actual password hashes, which are still NTLM.
The size of a rainbow table depends on the number of password characters included, and the maximum password length. Your example password has upper and lower case alphanumerics, plus some special characters. It is also 8 characters long. A quick search for NTLM rainbow tables that met those requirements gave me a 1.3Tb table that cost about $500 on hard disk. But I was not sure about the “ö”. Including those sorts of modified letters could drive the size of the rainbow table up to exceedingly massive proportions. And even then, the success rate will not be 100%
Thanks. Basically everything encrypted is crackable, I reckon – it’s a matter of time and CPU power. - Do you know how long it would take to crack such a password (eight characters and complex), in a broad estimation, given the tools you mention and say a fast, modern desktop?
PS. I’m Swedish, I didn’t throw in an “ö” for any particular reason, it was just one of the random characters I wrote as an example.
IIRC in the Pentium-90 days, Lophtcrack trying every character/number/punctuation search for 8 characters (NTLM) took about a month. Machines are about 40 times faster today, might have 4 or 8 cores or more working in parallel, and the microcode execution, lookahead and such is much more efficient; hardly a burdensome task if you absolutely need to crack something.
Of course, a lot of the time issue was whether the passsword started with A or Z…?
Thanks, md2000. What I’ve recently heard by two different persons, who both saw a demonstration independent of each other (though the demo guy was the one and same, at least from the same organization), insisted that cracking the domain account’s cached credentials was done in seconds and that you’re “screwed” and so forth; there’s nothing to it. I don’t find this believeable given a fairly complex password and so on, but I might be wrong.
A month seems reasonable, though I certainly would have guessed longer than that. Things might have improved quite a lot since I studied these issues.
If the demo used rainbow tables, it would take seconds. Rainbow tables preload the work - it takes months of compute time to build the initial rainbow table (particularly if you use complex characters and upper/lower case). That is why people can charge $500 for the table on disc. But if you tried to brute-force it, it could take a very long time indeed. Some brute-force crackers claim 150 Mhashes/s using 4 cores @ 3.2Ghz. For an 8 char password out of a pool of 62 characters, it could take ~17 days (62^8/150x10^6 seconds).
Yeah. I tried using Lophtcrack on NT4 Domain SAM database about 10 years ago. It looked to take a month, but…
You need admin access to get the SAM database.
IIRC, the NTLM stored the UPPER CASE ONLY password, so it was much easier to crack. This was a P90; today it should be 40 to 160 times faster. The NTLM database also split the passwords into 8-charcter chunks to encode.
Lophtcrack started with a dictionary plus 2 numbers test, and so for example “Hidden99” would crack almost immediately. 50% of passwords cracked in 5 minutes. Most people were not very imaginateive, especially when they needed a new password every 3 months. Like Jan123, Feb123, etc.
Rainbow tables were impractical when 40MB was a big disk. When 1TB is $100 or less, just create a lookup table ahead of time.
Yes, as I said earlier I fooled around quite a bit several years ago with similar results. Since then I’ve read about rainbow tables, which changes things around a bit, but I never took the time to experiment with it myself.
What I do find a little bit surprising is that Microsoft hasn’t met that threat. Contrary to popular belief they are very security focused and has been very successful in that field lately. But perhaps this is something technically very difficult to protect oneself against, when the hacker “owns” the data (the computer on which the data is stored).
I guess BitLocker on laptops would make it not 100% safe (nothing is, huh), but a lot harder to “own” the data? I mean, if you for conveniance sake would allow users to log in with cached credentials (you can turn it off with policies), you’d have to complement the complex password with a disk encryption solution?
Just to clarify - md2000 is talking about old LanMan passwords, not NTLM (NTLMv2 uses the same hash as NTLM - some other aspects of the protocol have changed). These days in a post Windows 2000, LM passwords are not stored alongside the NTLM hash, and hashes are not passed across the network in a sniffable format.
Cached credentials are a risk, but you need Admin access to get at them. The other thing to prevent rainbow table attacks is the use of salt. This is a character (or several) added to the password before hashing. This increases the difficulty to crack via rainbow tables (because you need a bigger rainbow table), as long as the salt stays secret. Unix systems use salt, but Windows systems generally do not (there are third party systems like HP Password Protect that add salt (as well as other password protection features).
In general, good password policies and system administration should protect systems. Oftcrack and rainbow tables may be useful in some circumstances for a systems administrator, but is somewhat less useful for a cracker if they cannot get access to the hashes.
So given that the builtin Administrator account is disabled by default these days, you would first need to identify a local account with administrative privileges, reset that password with known procedures, and then go to work with the rainbow table on the cached domain account’s password?
My understanding is that it does, but only for across the wire challenge/response authentication. The hash stored in the SAM is still NTLMv1 (MD4). NTLMv2 is hardened against sniffing (really only LanMan authentication was sniffable), but if you can get the SAM, you have something you can attack.
As with anything, physical access to the system in question gives you the ability to do pretty much what you want with it, unless you use full system encryption.