Tag Archives: pass the hash

Working With Windows Local Administrator Accounts, Part III

Working With Windows Local Administrator Accounts, Part III

One point to keep in mind in this series is that we’re trying to limit the powers that are inherent in Administrator accounts. In short: use the Force sparingly. In the last post, we showed it’s possible to remove the local Administrator account and manage it centrally with GPOs. Let’s go over a few things I glossed over last time, and discuss additional ways to secure these accounts.

Restricted Groups: Handle with Care

In my Acme environment, the Restricted Groups GPO is used to push out a domain-level group to the local Administrators group in each of the OUs: one policy for Masa and Pimiento, another for Taco. It’s a neat trick, and for larger domains, it saves IT from having to do this through scripts or spending time performing this manually.

To refresh memories, here’s how my GPO for Restricted Groups looked:

Replaces local  Administrators groups with Acme-IT-1.

By using the “Member of this group” section, I’m forcing the Group Policy Manager to replace, not add, Acme-IT-1 to each local Administrators group in my OU. The problem is you may overwrite existing group members, and you don’t know what services or apps depend on certain local accounts being there.

You’ll likely want to evaluate this idea out on a small sample. This may involve more work— local scripts to re-add those accounts, or possibly creating new domain level accounts that can be added into the above.

Or if you prefer, you can use Group Policy Preferences (GPP). It has an update option for adding a new group (or user) under a local Administrator account (below). We know not to use GPP to reset local Administrator account passwords, right?

With GPP, you can add Acme-IT-2 to the local Administrators groups.

Even More Secure

There is, sigh, a problem in using Restricted Groups and centrally managed domain-level Administrator accounts. Since all users by default,  are under Domain Users, it means that local Administrators can be exploited through Pass-the-Hash (PtH) techniques — get NTLM hash, and pass to psexec — to log on to any other machine in the network.

This was the conundrum we were trying to grapple with in the first place! Recall: local Administrators are usually given simple — easily guessable or hackable — passwords which can then be leveraged to log on to other machines. We wanted to avoid having an Administrator-level local account that can be potentially used globally.

As I mentioned in the second post, this security hole can be addressed by creating a GPO – under User Rights Assignment — to restrict network access all together. This may not be practical in all cases for Administrators accounts.

Another possibility is to limit the machines that these domain-level Administrator accounts can log into. And again we make a lifeline call to User Rights Assignment, but this time enlisting the “Allows log on locally” property, adding the Acme-IT-1 Administrators group (below). We would do the same for the other OU in the Acme domain, but adding the Acme-IT-2 group.

This GPO prevents accounts from logging on to machines outside the specified domain. So even if a clever hacker gets into the Acme company, he could PtH with Administrator account but only within the OU.

It’s a reasonable solution. And I do realize that many companies likely already use this GPO property for ordinary user accounts, just for reasons I noted above.

Additional Thoughts

In writing this brief series, you quickly come to the conclusion that zillions of IT folks already know in their bones: you’re always trying to balance security against convenience. You won’t have a perfect solution, and you’ve probably erred on the side of convenience (to avoid getting shouted at by the user community).

Of course, you live with what you have. But then you should compensate for potential security holes by stepping up your monitoring game! You know where this is going.

One final caveat goes back to my amazing pen testing series where I showed how delegated Administrator groups can be leveraged to allow hacker to hop more freely around a domain—this has to do with accounts being in more than one Active Directory group. Take another look at it!

Working With Windows Local Administrator Accounts, Part II

Working With Windows Local Administrator Accounts, Part II

Before we delve into Restricted Groups, I thought it might be worthwhile to take a closer look at how hackers take advantage of Administrator passwords. For Pass-the-Hash fans, this post will show you how hashes can be used even with local accounts. I also had a chance to try Windows Local Administrator Passwords Solution or LAPS. Spoiler alert: LAPS scares me a little.

Passing Local Hashes

After writing the first post, I realized that you don’t necessarily need hashes of domain accounts. In fact, Windows also stores the hashes of local accounts in its Security Accounts Manager (SAM) database. Hash dumping tools such as crackmapexec and mimikatz let you view these hashes.

This leads to a more direct lateral movement tactic. As I pointed out last time, it is not unusual for local Administrator accounts to have exactly the same password on more than one machine. This would also mean the NTLM hashes would be the same as well.

Let’s say a hacker gains access to a server, and assuming he has enough privileges, then uses mimikatz to see if a local Administrator account is available. He can then try an experiment and pass the Administrator hash into, say, psexec to pop a shell on another server and gain Administrator privileges there as well.

You see what I’m getting at?  If you assume that Administrator passwords are the same on different machines, then you’re no longer dependent on a domain-level user to have left a hash in the LSASS memory of that box. This post explains more about LSASS if you’re confused by the last sentence.

On the other hand, the local user hashes are always there! Being a hacker or pen tester means that you’re always testing different ideas and playing the odds. So let’s go for broke!

Back in my Acme domain, I set the same local Administrator password on both my Masa and Taco servers – Taco is also my domain controller. In this scenario, I’m already on Masa, I’ve uploaded mimikatz and psexec.

By the way, both these tools have source code, so it wouldn’t be that difficult to make them fully undetectable after a few tweaks.

I was now flying under the radar on Masa, but couldn’t find anything interesting there. To begin my lateral move, I loaded mimikatz and dumped the hashes with the lsadump::samcommand.

Assuming that Taco also has the same Administrator password, I then use sekurlsa:pth to launch psexec and gain a shell on Taco (below).

Just try passing-the-hash with the local Administrator account. What do you have to lose?


When I changed the Taco Administrator’s password, this ploy didn’t work, and psexec was unable to pop a shell.

Lesson learned: it’s good idea to have different Administrator passwords.

LAPS and Aspirin

If you’re going to keep the local Administrator passwords, then you need to manage them. As I wrote about last time, these accounts can be disabled, and Restricted Groups can be used to delegate Administrator privileges to domain-level accounts.

In any case, people still want these local accounts. Microsoft apparently heard the collective cry of IT administrators, and in 2015 they released their Local Administrator Passwords Solution. It’s described with these words: “…solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolves this issue by setting a different, random password for the common local administrator account on every computer in the domain.”

Seems simple. However as we’ve noted before,  Microsoft never, ever does anything nice and easy.

The first tip off was the LAPS architecture (see below).

Plans for the invasion of Mars.

Hmm, there is a client and server side to this. The documentation also indicates PowerShell scripts have to be run, and then there’s something about changing the Active Directory schema.

I boldly took the LAPS challenge and went as far as I could with the installation before the pounding in my head got to me.

This is not an easy install. LAPS is loaded onto your domain controller as well as on client computers that you want managed. Yeah, you use the Group Management Console to push out LAPS to the clients.

If you do the installation correctly, you’ll see the following interface pop up when you navigate in the GPO editor to Computer Configuration>Administrative Templates>LAPS.

I was afraid to pull the trigger on this. In theory, LAPS generates random passwords that are now centrally located on Active Directory in a new attribute as plaintext — that’s why you needed to update the AD schema.

Some security pros have pointed out that LAPS may, ahem, have its own problems. Essentially, you’re shifting the problem from local computers to Active Directory.

Back to Restricted Groups

After returning from my LAPS detour, I began to see Restricted Groups as the most practical way to manage local Administrator accounts. I started on this process in the previous post when I created a new AD group called Acme-IT, which then was pushed out and placed under the local Administrators group for each machine in the Acme domain

It’s a neat trick, and Restricted Groups allow IT to centrally control local Administrator access.

It would even be neater if I could segment my domain so that one group of users would be local Administrators for a subset of machines, and another group would control a different subset –creating as many sub-groupings as needed.

Otherwise, I’d fall into the trap of allowing a small group of users to have local Administrator access to the entire domain! No bueno.

And that’s where Organizational Units (OUs) come into play. It’s a way to divide up the domain so that you can associate specific GPOs with each OU subgroup.

You first set up these OU sub-divisions in Active Directory Users and Computer (below). For each OU, I assigned a subset of the domain’s computers. In my scenario, Acme-1 is associated with the Masa and Pimiento servers, and Acme-2 is associated with Taco, the domain controller.

Two new OUs join the Acme domain: Acme-1 and Acme-2.

I also had to remember to create Active Directory groups that will be associated with each of these OUs — Acme-IT-1 and  Acme-IT-2.

Now when I’m back in the Group Management Console, these OUs show up under the Acme domain (below). I added a Restricted Groups policy under each OU, making sure that the appropriate AD groups were used.

The OU payoff: segmented GPO policies!

It’s simpler than it sounds. In short: I’m enabling members of Acme-IT-1 to be an Administrator for Masa and Pimiento, and Acme-IT-2 members for Taco.

We’ll finish up this incredibly exciting topic in the next post and, as always, I’ll have a few closing thoughts. In the meantime, take a few aspirins for getting this far in the series.


Continue reading the next post in "Working With Local Administrator Accounts"

Pen Testing Active Directory Environments, Part V: Admins and Graphs

Pen Testing Active Directory Environments, Part V: Admins and Graphs

If you’ve survived my last blog post, you know that Active Directory group structures can be used as powerful weapons by hackers. Our job as pen testers is to borrow these same techniques — in the form of PowerView — that hackers have known about for years, and then show management where the vulnerabilities live in their systems.

I know I had loads of fun building my AD graph structures. It was even more fun running my breadth-first-search (BFS) script on the graph to quickly tell me who the users are that would allow access to a file that I couldn’t enter with my current credentials.


The “Top Secret” directory on the Acme Salsa server was off limits with “Bob” credentials but available to anyone in the “Acme-Legal” group. The PowerShell script I wrote helped me navigate the graph and find the underlying users in Acme-Legal.

Closing My Graphs

If you think about this, instead of having to always search the same groups to find the leaf nodes, why not just build a table that has this information pre-loaded?

I’m talking about what’s known in the trade as the transitive closure of a graph. It sounds nerdier than it really needs to be: I’m just finding everything reachable, directly and indirectly, from any of the AD nodes in my graph structure.

I turned to brute-force to solve the closure problem. I simply modified my PowerShell scripts from last time to do a BFS from each node or entry in my lists and then collect everything I’ve visited. My closed graph is now contained in $GroupTC (see below).



Before you scream into your browsers, there are better ways do this, especially for directed graphs, and I know about the node sorting approach. The point here is to transcend your linear modes of thinking and view the AD environment in terms of connections.

Graph perfectionists can check this out.

Here’s a partial dump of my raw graph structure from last time:


And the same information, just for “Acme-VIPs”, that’s been processed with my closure algorithm:


Notice how the Acme-VIPs list has all the underlying users! If I had spent a little more time I’d eliminate every group in the search path from the list and just have the leaf nodes — in other words, the true list of users who can access a directory with Acme-VIPs access control permission.

Still, what I’ve created is quite valuable. You can imagine hackers using these very same ideas. Perhaps they log in quickly to run PowerView scripts to grab the raw AD group information and then leave the closure processing for large AD environments to an offline step.

There is an Easier Way to Do Closure

We can all agree that knowledge is valuable just for knowledge’s sake. And even if I tell you there’s a simpler way to do closure than I just showed, you’ll still have benefited from the deep wisdom gained from knowing about breadth first searches.

There is a simpler way to do closure.

As it turns out, PowerView cmdlets with a little extra PowerShell sauce can work out the users belonging to a top-level AD group in one long pipeline.

Remember the Get-NetGroupMember cmdlet that spews out all the direct underlying AD members? It also has a –Recurse option that performs the deep search that I accomplished with the breadth-first-search algorithm above.

To remove the AD groups in the search path that my algorithm didn’t, I can filter on the IsGroup field, which conveniently has a self-explanatory name. And since users can be in multiple groups (for example, Cal), I want a unique list. To rid the list of duplicates, I used PowerShell’s get-object –unique cmdlet.

Now for the great reveal: my one line of PS code that lists the true users who are underlying a given AD Group, in this case Acme-VIPs:


This is an amazing line of PowerShell for pen testers (and hackers as well), allowing them to quickly see who are the users  worth going after.

Thank you Will Schroeder for this PowerView miracle!

Commercial Break

It’s a good time to step back, take a deep breath, and look at the big picture. If you—IT security or admin team—don’t do the work of minimizing who has access to a directory, the hackers will effectively do if for you. I’ve just shown that with PowerView, they have tools to make this happen.

Of course, you bring in pen testers to discover these permission gaps and other security holes before the hackers.

Or there is another possibility.

Our blog’s generous sponsor, Varonis Systems, has been making beautifully crafted data access and governance solutions since Yaki Faitelson and Ohad Korkus set up shop in 2004. Their DatAdvantage solution has been helping IT admins and security pros find the underlying users who have access to files and directories.

Varonis: For over ten years, they’ve been saving IT from writing complicated breadth-first-search scripts!

Taking the Derivative of the Admin

Back to our show.

Two blog posts ago, I began to show how PowerView can help pen testers hop around the network. I didn’t go into much detail.

Now for the details.

A few highly evolved AD pen testers, including Justin Warner, Andy Robbins  and Will Schroeder worked out the concept of “derivative admin”, which is a more efficient way to move laterally.

Their exploit hinges on two facts of life in AD environments. One, many companies have grown complex AD group structures. And they often lose track of who’s in which group.

Second, they configure domain-level groups to be local administrators of user workstations or servers. This is a smart way to centralize local administration of Windows machines without requiring the local administrator to be a domain-level admin.

For example, I set up special AD groups Acme-Server1, Acme-Server2, and Acme-Server3 that are divided up among the Acme IT admin team members — Cal, Meg, Rodger, Lara, and Camille.

In my simple Acme network, I assigned these AD groups to Salsa (Acme-Server1), Avocado (Acme-Server3), and Enchilada (Acme-Server2) and placed them under the local Administrators group (using lusrmgr.msc).

In large real-world networks, IT can deploy many AD groups to segment the Windows machines in large corporate environments — it’s a good way to limit the risks if an admin credential has been taken.

In my Acme environment, Cal who’s a member of Acme-Server1, uses his ordinary domain user account to log into Salsa and then gain admin privileges to do power-user level work.

By using this approach, though, corporate IT may have created a trap for themselves.


There’s a PowerView command called Get-NetLocalGroup that discovers these local admins on a machine-by-machine basis.


Got that?

Get-NetLocalGroup effectively tells you that specific groups and users are tied to specific machines, and these users are power users!

So as a smart hacker or pen tester, you can try something like the following as a lateral move strategy. Use Get-NetLocalGroup to find the groups that have local admin access on the current machine. Then do the same for other servers in the neighborhood to find those machines that share the same groups.

You can dump the hashes of users in the local admin group of the machine you’ve landed on and then freely jump to any machine that Get-NetLocalGroup tells you has the same domain groups!

So once I dump and pass the hash of Cal, I can hop to any machine that uses Acme-Server1 as local admin group.

By the way, how do you figure out definitively all the admin users that belong to Acme-Server1?

Answer: use the one-line script that I came up with above that does the drill-down and apply it to the results of Get-NetLocalGroup.

And, finally, where does derived or derivative admin come into play?

If you’re really clever, you might make the safe assumption that IT occasionally puts the same user in more than one admin group.

As a pen tester, this means you may not be restricted to only the machines that the users in the local admin domain group of your current server have access to!

To make this point, I’ve placed Cal in Acme-Server1 and Acme-Server2, and Meg in Acme-Server2 and Acme-Server3.



Lateral movement by exploiting hidden connections in the Acme network.

If you’re following along at home, that means I can use Cal to hop from Salsa to Avocado. On Avocado, I use Meg’s credentials to then jump from Avocado to Enchilada.

On the surface it appears that my teeny three-machine network was segmented with three AD groups, but in fact there were hidden connections —Cal and Meg — that broke through these surface divisions.

So Cal in Acme-Server1 can get to an Acme-Server3 machine, and is ultimately considered a derivative admin of Enchilada!

Neat, right?

If you’re thinking in terms of connections, rather than lists, you’ll start seeing this as a graph search problem that is very similar in nature to what I presented in the last post.

This time, though, you’ll have to add into the graph, along with the users, the server names. In our make-believe scenario, I’ll have adjacency lists that tell me that Salsa is connect to Cal; Avocado is connected to Cal, Meg, Lara, and Roger; and Enchilada is connected to Meg and Camille.

I’ve given you enough clues to work out the PowerView and PowerShell code for the derivative admin graph code, which I’ll show next time.

As you might imagine, there can be lots of paths through this graph from one machine to another. There is a cool idea, though, that helps make this problem easier.

In the meantime, if you want to cheat a little to see how the pros worked this out, check out Andy Robbins’ code.

Continue reading the next post in "Pen Testing Active Directory Environments"

Penetration Testing Explained, Part V: Hash Dumping and Cracking

Penetration Testing Explained, Part V: Hash Dumping and Cracking

In the previous post in this series, I guessed a local password and then tried various ways to move laterally within my mythical Acme network. But what happens if you can’t guess the password?

In my pen testing scenario, there’s a beer motif in all the naming of the servers and the local admin passwords. It’s not completely unheard of for busy IT people to sacrifice security for convenience. “I’m on the miller server, so I know my admin password is admin-miller.” Hackers of course are ready to jump on these weaknesses.

But let’s say you land in an environment where your inspired password guessing is not succeeding. That’s where a hash-based approach can pay dividends.

I’ve been writing about Pass the Hash (PtH) on and off over the last year. But before we dive into that technique, let’s first focus on a simpler idea: cracking password hashes.

There Be Hashes

On a Windows system, plaintext passwords are never stored. That would be a very bad thing to do.

Instead, in Windows the hash of the password — more explicitly the NLTM hash — is kept. You know from reading our posts (and our amazingly informative ebook) that the hash is used as part of the Windows challenge-response authentication protocol. Essentially, users prove their identity by encrypting some random text with the NTLM hash as the key.

Where does Windows store these hashes? From my own research, it appears that Windows keeps local user account hashes in the Security Accounts Manager (SAM) database, which is part of the Local Security Authority (LSA). You can read more about these topics in this technet article.

The first question for pen testers is whether they can access the hashes. Once we have the hash, we can then try few a standard cracking techniques to derive the actual password.

The answer is yes: there are few tools available can that read the SAM and dump the hashes. I chose fgdump — you can find this easily through a Google search — to do my dumping. Pwdump7 is another possibility.

Sure you need to have elevated privileges to run these tools, but it’s not unusual for a hacker to get lucky with a power user who falls for a well-crafted phish.

Anyway I tried fgdump on one of the servers in my Acme IT environment that I set up for this series. You can see the results in the screen shot below:fgdump-hashes

So I now have the NTLM hashes for what looks like two local admin accounts — that’s the long sequences at the end of the line. By the way, the “NO PASSWORD” indicated that fgdump didn’t find the older and far more crackable LM hash. And that’s a good thing: you should never enable LM hashing unless you absolutely have to for compatibility!

Cracking the Hash

One common approach to cracking hashes is to use a dictionary-based attack. That is, take a huge set of common English words, add in, say, an existing set of real world passwords, and pre-compute the NTLM hashes, thereby forming a reverse-lookup dictionary.

So the task of cracking now reduces to finding a matching hash and returning the associated plaintext password.

Thankfully, you don’t have to re-invent the wheel since there are services like this one that have already done the heavy lifting.


In my pen testing, I fed the hash for “admin2” into the cracking service, and it speedily returned the answer, which is “daisy” (see above).

It’s true that Windows enforces password complexity standards, and this simple password would never have been accepted in many installations.

However, a password can still be somewhat complex but crackable through a brute force attack. Or perhaps on your system there are legacy local accounts created before Windows started forcing you to come up with longer sequences.

The Ripper

For a better test, I tried the cracking service on the more complex password from the admin account on the miller server, which is “miller1234;”.

After a few days of brute force computing, the service couldn’t find a match.

Never say die!

I then learned about this fellow, John the Ripper, a very crafty password cracking tool. It’s too sophisticated a program to write about in the remainder of this post.

In brief, it’s very smart about how it does its brute force attacks. JtR has a special mangling language that takes an existing set of dictionary words that you can specify, and re-arranges them based on the rules you set up. The rules can be quite cryptic to look at, but are very powerful — here’s a digestible overview on the mangling language.

You can set up rules, for example, to append various numeric sequences to the existing dictionary words.  I think you see what I’m getting at.

If you have an inkling that beer names are used in passwords followed by some simple alphanumeric code, you feed the John the Ripper app a beer name word list and then configure rules to try out lots of sequence suffixes.

Enter Hash Passing

I agree that cracking the NTLM hashes ain’t easy.

Rather than trying to crack the hash, PtH will slip the hash directly into the NLTM challenge-response protocol. You’re authenticated without having to derive the plaintext.

It’s a very cool and powerful idea.  Although Microsoft has been making this harder to do in recent releases, and with Windows 10 perhaps even impossible to do in the future.

We’ll take all this up in the next post.

Continue reading the next post in "Penetration Testing Explained"

Windows 10 Authentication: The End of Pass the Hash?

Windows 10 Authentication: The End of Pass the Hash?

Over the last year, Microsoft had been dropping lots of hints it would be reworking its authentication system in Windows 10. Multi-factors, support of FIDO, and the use of virtualization technology to secure credentials were all slated to be in its latest and greatest OS. With the general release of Windows 10 late last month, we now get to see what’s in the sausage.

Hardened Authentication

For starters, you should read the July 28 announcement on their blog. In the very first bullet point, they announce Windows Hello, which is Microsoft’s take on password-free authentication, using either facial, thumbprint, or iris recognition for validation. Hello will support the FIDO open-standard as well.

Also in that first bullet point is a reference to something called Credential Guard. It’s described as a way to “protect corporate identities by containing them in the hardware-based secure execution environment.”

Ok, Credential Guard must be using the virtualization technology they had been yakking about for the last few months— for example, see this presentation by Microsoft’s Nathan Ide at this year’s RSA conference.

To find out more, I searched the TechNet portion of the Microsoft website and came across this overview article on Credential Guard. As I read more, it was beginning to look like this was the long awaited PtH messiah.

For those who’ve been following along with us, Pass the Hash (and Pass the Ticket for Kerberos) is a way for hackers to directly exploit user credentials that are kept in memory. The hash of the password — remember hashing? — is at the core of Windows NTLM challenge and response authentication protocol.

If you have the hash, it’s the same as having the password: you just pass or feed it into the NLTM protocol to gain entry. Once inside a system, hackers love PtH because they don’t have to crack hashes to take over a user’s identity.

Great news, for hackers. So how do they get the hash?

The answer: Windows keeps hashes in LSASS memory, making it available for Single Sign On or SSO. In an SSO environment, the computing world most of us live in, you enter passwords once when logging in to your corporate laptop. When you need to access other services, Windows just dips into LSASS to pull out the credential — the hashed password — so you don’t have to re-enter it.

It’s a user convenience that we all take for granted, but it has the side effect of giving hackers a huge opening to exploit.

Pen test tools like Mimikatz, for example, access LSASS memory, thereby allowing cyber thieves to pull out credentials (preferably of users with elevated privileges) and take on multiple identities as they traverse the target system.

Bottom Line: Hashes Will Be Really Hard to Get

Mr. Softee has known about PtH for many, many years. To its credit, it sort of recognized the problem and has given very good advice on how to reduce the risks of credential stealing — see this paper.


Source: Microsoft

And that’s where Credential Guard finally comes in. In Windows 10, the designers reworked the LSASS process so that it lives in its own virtualized container. Yeah, it’s using similar ideas and techniques to those found in virtual machines that enable a host operating system to run various guest operating systems.

These guest operating systems are sort of like their own min-universes, separate from each other, except through some well-defined worm holes — I’ll get to that in a second.

So what’s going on in Credential Guard?

Last month at Black Hat, Microsoft heavy weights, Seth Moore and Baris Saydag, gave a presentation, Defeating Pass-the-Hash, that explained the implementation details.

It gets gnarly, but the LSASS address space is now really, really separated from other user processes so that apps like Mimikatz can’t peek into it. You’ll have to read the paper to understand the fine points — note the use of the words hypervisor and ring levels.

But here’s the speedy executive overview based on my current understanding. The developers left the LSASS programming logic intact to continue supporting credential processing as before. The memory space, though, is walled off from other apps with Credential Guard acting as the gateway.

Neat Wormhole Technology

System and other apps, of course, still need to verify the credentials of users, but now they do so through a well-protected and authenticated connection to Credential Guard. So you can think of Credential Guard as the guardian of the wormhole between its special memory space and everything on the other side.

I know this post is starting to sound like Interstellar. Nevertheless, the technology is quite interesting and really does seem to finally close off PtH.

I’d like to think that Pass the Hash will eventually become a problem of the past as companies migrate to the Windows 10 Enterprise Edition — the only version that Credential Guard runs on.

Of course, you shouldn’t discount hackers’ power to find weaknesses and zero-day exploits.

So the wiser security view to take is that the cost to play Pass the Hash has gone up immensely. It may still be possible in the future, but it will require a far more sophisticated effort than is currently the case.

A Closer Look at Pass the Hash, Part III: How NTLM Will Get You Hacked (and...

A Closer Look at Pass the Hash, Part III: How NTLM Will Get You Hacked (and What You Should Do About It)

This article is part of the series "A Closer Look at Pass the Hash". Check out the rest:

I was about ready to wrap up this series of posts on PtH and make my larger point, which is that you should assume hackers will break into your system and then I learned new information about credential stealing that amplifies this warning by a factor of 10.

The most important takeaway about PtH is that the password hashes that are stored in memory (and grabbed by hackers) are a feature of Single Sign On. Most organizations can’t live without SSO, so they’re stuck with PtH risks. I already blogged about ways to reduce these risks, but they can’t altogether be eliminated.

More Features to Worry About

There’s another underlying feature that also has to be taken into account. Existing Windows authentication protocols, which directly use the password hash, have had a long history of problems. As of January 2013, Microsoft’s official line on NTLM, their workhorse logon authentication software, is that you should not be using version 1—the newer v2 is better (but still has some vulnerabilities).

By all means, if feasible, jump from NTLM to Kerboros, which will greatly reduce your security exposure. But many IT groups can’t completely cut their ties to NTLM—mostly because lots of client apps (email, browsers, VPN, file sharing) still depend on it. And then there’s SAMBA, a suite that provides Windows file and print services for UNIX/Linux, which also uses NTLM.

Bottom line:  NTLM has deep hooks into Windows.

But even more troubling—and here’s one piece of new information I learned from security blogger Mark Gamache—is that there’s  an enormous security exposure because of all the XP out there—at least 20% of all computer based on W3 data.  And these legacy clients’ can only  default authentication is—you guessed it—NTLM version 1.

A Little NTLM

To understand what’s wrong with NTLM, we need to know a little more about how its challenge-response works.

Rather than write out a geeky protocol syntax, the interaction (for version 1) can be roughly summarized by the following dialogue:

Server:  Hi. I know you’re claiming to be user XYZ, but you’ll need to prove it. But don’t tell me the password out loud—someone will overhear! Instead, I want you to take this challenge: encrypt “swordfish”, and then tell me the results. You can use DES.

User: And what key should I use for DES?

Server: The MD4 hash of your password—use that.

Client:  Ok, I’ve encrypted “swordfish” with the password hash and I have weird 24-byte string. Is that what you want?

Server: Yes

Client tells server the encrypted string. And server compares with its encryption of swordfish, which matches.

Server:  You are worthy, please enter!

The most important improvement in NTLMv1 over an even earlier Windows authentication method, known as LM, was not directly sending the password over the wire. Instead, encrypting the challenge with the hash of the password is proof that the user is who he/she claims to be.

The initial version of NTLM dates back to pre-internet NT systems—it stands for NT LAN Manager. Certainly, a more innocent time—circa  1990s—where the assumption that no one could get into an office LAN and launch crafty relay or man-in-the-middle exploits was a good one.

That was then. NTLMv1 eventually became susceptible to a style of attack wherein users were redirected to connect to a rogue server—you can read more about that here. The server would send a challenge for which it had already pre-computed the hashes for zillions of passwords and stored the encrypted challenges in a giant dictionary.

If the fake server finds a match, it then automatically has the password hash for that user.

NTLM Is Really Broken

In response, Microsoft improved the challenge-response protocol in NTLMv2 to prevent these server-based dictionary attacks. However, it still left open the possibility of man-in-the-middle exploits, as well as PtH.

But up until recently, you could make a case for staying with v1.

In 2012 some astonishing news came out of a Defcon conference. Using special purpose-built hardware, security researchers had succeeded in cracking the DES encryption used in the NLTMv1 challenge-response exchange.

In other words, by watching the wire and grabbing the packets containing the challenge text from the server and the encrypted DES response, hackers could, through a brute force approach, work out the key— i.e., the underlying password hash. Yikes! And then some researchers made this DES cracking capability available as a service, known as OnlineHashCrack, for penetration testers!

I don’t want to get too much into the weeds about the fatal flaw in  NTLMv1. In short:  NTLMv1 doesn’t use the full 128-bit output of the MD4 hash as a DES key, but smaller 56-bit groupings, thereby making the client response amenable to being cracked by a powerful computing device. By the way, NTLMv2 uses a longer key but with a different encryption algorithm, HMAC-MD5—technically a one-way hash function.

And Going Forward

This crypto-news eventually made its way to Microsoft, which then issued the NTLMv1 warning I mentioned earlier.

So what’s a reasonable next step considering all this?  The first action for IT is to review current LAN authentication levels (in GPO or within Local Security Policy).  It’s not unusual to have set NTLMv2 as default, but still allow clients to negotiate NTLMv1 or the still older LM. If it’s feasible, they should set the “refuse LM and NTLM” option. ntlm-authentication

NTLMv2 is—as far as we know and assuming you’re not dealing with the NSA—immune to cracking. The caveat here is that user passwords are long enough—at least 8 characters—otherwise even this new version may be vulnerable to brute force approaches. So another ‘to do’ on your list is to really enforce a strong password policy across the organization.

The v2 challenge-response protocol can still, though, be tricked by sneaky servers getting in the middle and relaying credentials from a client to an authenticating app. And v2 doesn’t do anything to prevent PtH attacker from grabbing credentials.

Here’s a simple rule of thumb based on all this: assume the hacker will get in.

You therefore need a solid ‘Plan B’ defense strategy. In my previous PtH post, I recommended disabling remote access rights for ordinary users to prevent hackers from harvesting credentials by hopping on to other machines. It’s a good idea, and even more so considering all this new information.

Your final defensive wall should, of course, be business-as-usual data governance practices—monitoring, alerting, etc.

And you do that, as the Metadata Era has pointed out on many occasions, by finding where PII and other sensitive data is located, determining the true data owners, making sure the owners limit access to those who truly need it as part of their job or role, monitoring use and using automation to detect possible abuse.  So when the hackers enter the site, they’re not coming in as if they “own the place” since they no longer have easy access to troves of sensitive data.