Microsoft's Three PTH Mitigations

Before I start the long and treacherous discussion of Windows Authentication, I'd like to take a another pause to actually go over the "Mitigations" that Microsoft presents in their infamous whitepaper being pimped on twitter about once a day.

I'm going to gloss over any significant technical details that are best reserved for the upcoming auth blog post and make an attempt to explain, in relatively plain language, why these mitigations are lacking.  I'm going to start with the top 3 'Mitigations' and cover the other crud in another post.

I'd like to review the definition of 'mitigation' for completeness as well as introduce a couple of new terms for discussion.


Definition :
Mitigation - The action of reducing the severity, seriousness, or painfulness of something
Synonyms : cure, alleviate

First Order Effect - The direct result of an action taken.

N-Order Effect(s) - Other effects that are a result of the action taken to achieve a first order effect.  Sometimes called side effects.  Oftentimes these effects are not considered before taking the initial action.

So, to provide an example of  a first order / n-order effects.

The situation: I'm cold.
The action I take: I light a fire.
The first order effect: I get warm.
N-order effects (in no particular order): The carpet caught on fire (2nd order).  The house caught on fire(3rd order).  I died, etc...

So, to expand my definition of what a "PTH mitigation" would be:  An action I can take whose first order effect is to reduce the impact or availability of "PTH attacks".  Make sense?

Mitigation the first, p17 (Note instead of bullets I'm using numbers to refer to the specific mitigations to make it easier to refer to specific points):
"Main objective: This mitigation restricts the ability of administrators to inadvertently expose privileged credentials to higher risk computers.

How: Completing the following tasks is required to successfully implement this mitigation:

1. Restrict domain administrator accounts and other privileged accounts from authenticating to lower trust servers and workstations.
2. Provide admins with accounts to perform administrative duties that are separate from their normal user accounts.
3. Assign dedicated workstations for administrative tasks.
4. Mark privileged accounts as “sensitive and cannot be delegated” in Active Directory.
5. Do not configure services or schedule tasks to use privileged domain accounts on lower trust systems, such as user workstations."

So, going down the row here what effect would there be if an organization implemented this suggestion on an attacker's ability to authenticate to a machine with a hash instead of a password?

1. No effect
2. No effect
3. No effect
4. No effect
5. No effect

Huh?  None of those would have any effect on using a hash to authenticate?!?  Correct, none of these recommendations have any effect on "passing the hash" to authenticate.  However, they are not worthless recommendations.  Their effect is to reduce the availability of hashes to an attacker by reducing the available tokens in memory.  This would be an 'N -order' effect.  If an attacker on a computer couldn't find an administrative token on compromised computer, then there isn't any way for the attacker to win, right?
This myth will be dispelled at a later point in time.

It also assumes that your network has been pwned and that the attackers are looking for administrative tokens.  But I digress...

Ok, let's look at numero dos (p18).  I'm quoting more to illustrate a point...

"Accounts with administrative access on a computer can be used to take full control of the computer. And if compromised, an attacker can use the accounts to access other credentials stored on this computer.

Recommendation: If possible, instead of implementing this mitigation users are advised to disable all local administrator accounts.

Main objective: This mitigation restricts the ability of attackers to use local administrator accounts or their equivalents for lateral movement PtH attacks.


How: Completing one or a combination of the following tasks is required to successfully implement this mitigation on all computers in the organization:

1. Enforce the restrictions available in Windows Vista and newer that prevent local accounts from being used for remote administration.
2. Explicitly deny network and Remote Desktop logon rights for all local administrative accounts.
3. Create unique passwords for accounts with local administrative privileges."

First off, in a paper that's "is designed to assist your organization with defending against these types of attack (p1)", Microsoft has a "recommendation" not to implement this particular mitigation and instead take a different step.  This seems like a pretty big "oh, btw..."  So what exactly is the message that somebody stuck on the wrong end of this document is supposed to get?  Do it or not do it?  I think a better way would have been to list this as an either or mitigation step.  If you can get away with "a" then "b" doesn't matter.  However, this wasn't the case and only serves to further confuse folks.

As to the soundness of the advice?  From an administrative perspective, having no local administrator account to be able to log in with and fix problems on the computer when the domain goes down seems foolish.  Remote offices have problems with connections to the mother ship all the time.  Machines can have problems where they get out of sync with the domain due to any number of reasons.  Having the ability to log in, remove the computer from the domain via local admin account, and rejoin just makes too much sense.  Or patch, or re-install an application, or any number of other mundane tasks that happens in the real world...

I wouldn't suggest it.  Just saying...

Ok, how does this list of items do with preventing an attacker from using a hash to authenticate to a computer?

1. If the hash being used is in the "administrators" group local to the computer AND the target OS is Vista, 7, 2008, 2012, or 8, then this would be effective.  A couple of caveats, however... If the target machines' OS is XP or 2003, then this wouldn't have any effect.  I mean nobody has that stuff out there right? *sarcasm*  And secondly... the UAC / network related settings are easy to override by setting a registry key / using a GPO.  
2. None, this only has an effect on the generation of administrative hashes from tokens
3. In essence this mitigation says "have a unique local admin password for each computer".  Yes this would prevent a compromise of one machine from using the same hash on another, however once somebody found the document detailing what all the passwords were elsewhere on the network it would be on like Donkey Kong...

So, under specific circumstances 2 of these mitigations would be successful at preventing somebody from authenticating with a hash.  Please just ignore any domain accounts... no seriously... 

Overall I rate this a "meh"

Third time's a charm, right?  I mean they have to have something good in store since the first couple were pretty lousy...

Here's the excerpt (p18):

"Mitigation 3: Restrict inbound traffic using the Windows Firewall

One of the most important prerequisites for an attacker to conduct lateral movement or privilege escalation is to be able to contact other computers on the network.

Main objective: This mitigation restricts attackers from initiating lateral movement from a compromised workstation by blocking inbound connections on all workstations with the local Windows Firewall.

How: This mitigation restricts all inbound connections to all workstations except for those with expected traffic originating from trusted sources, such as helpdesk, workstations, security compliance scanners, and management servers.

Outcome: Enabling this mitigation will prevent an attacker from connecting to other workstations on the network using any type of stolen credentials.

For more information on how to configure your environment with this mitigation, see the section 'Mitigation 3: Restrict inbound traffic using the Windows Firewall' in Appendix A..."

Sweet! That's what I'm talking about... start denying services to folks on the network.  "In theory" workstations should only communicate with servers and not with each other, except for help desk folks and sysads' workstations.  Ok, so this sounds like the start of something positive...  Let's check out what's in Appendix A...

Quoting from Appendix A (p. 66):

"Workstations can use Windows Firewall to restrict inbound traffic to specific services, servers, and trusted workstations used for desktop management. An organization can do this by denying all inbound access unless explicitly specified by a rule. However, because servers are typically designed to accept inbound connections to provide services, this mitigation is not typically feasible on server operating systems.

Nonetheless, using Windows Firewall to restrict inbound traffic is a very simple and robust mitigation that you can use to prevent captured hashes from being used for lateral movement or privilege escalation. This mitigation significantly reduces the attack surface of the organization's network resources to a PtH attack and other credential theft attacks by disabling an attacker’s ability to authenticate from any given host on a network using any type of stolen credentials."

And my enthusiasm has waned...  Microsoft recommends that you don't do this on servers, which sorta makes sense.  However, where is most of the data going to be that an attacker is going to be interested in? On the servers...

So you can prevent one low-valued target (workstation) from talking to another low-valued target (workstation), if and only if you have a complete grasp of what should and should not be talking on the network.  Realistically, how many environments have this level of detail?  I'm not saying they don't exist, but I'm fairly certain that most of the places I've been to wouldn't have the confidence in their setup to actively start blocking workstation to workstation communication.

Even if an org decides to implement this Windows firewall mitigation,  how does an enterprise manage the Windows firewall?  via GPO?  What ports should you block?  What protocols should you block?  (HINT: MS doesn't list ports/protocols in the whitepaper...) What about managing exceptions, quick fixes to somebody not being able to talk to whomever, etc... What a nightmare!  I certainly don't envy the admins on that network if this fresh hell was thrust upon them...

To summarize:

Mitigation 1 had nothing to do with stopping people from using a hash to authenticate, it only prevented elevated-privilege tokens from hanging around where an attacker could find them.

Mitigation 2 had some limited effect on  preventing somebody from authenticating using hashes if the OS was Vista+ (or 2008+) and UAC was enabled and a lazy administrator didn't tweak the registry to re-enable the old behavior.  It also suggested that each workstation have a different password, however I posit that this simply shifts the attacker into trying to find the spreadsheet with all the passwords on the file server. However, this would have no effect on domain accounts!

Mitigation 3 had some promise until looking at it closer it became obvious that restricting workstation to workstation really didn't have a lot of value...  Not to mention the unholy blight of Windows firewall management wrought upon the poor admins and help desk folks...

I'll look at the rest of the "recommendations" and also hopefully have an idea of when the Windows auth post will be up soon(ish)...

Microsoft's Prototypical PTH Attack Scenario

I think before we get too far along I'd like to quickly discuss the major flaw in the scenario that MS uses in their "PTH Mitigation" whitepaper.

I'm going to start by outlining what MS considers to be a typical attack (p6 - 12).

1. Attacker gains access to a workstation at the "system" level
2. Attacker attempts to gather hashes from SAM/local access tokens 
3. Attacker uses PTH to gain access to resources, searches for more tokens
4. Attacker eventually takes the Domain Controller (DC)
5. Game Over.

To quote the treatise (p. 8)  "1. An attacker obtains local administrative access to a computer on the network by enticing a victim into executing malicious code, by exploiting a known or unpatched vulnerability, or through other means."

This seems to be a popular idea of how an attack goes.  There's one gaping hole in this idea.  

They are actually missing a step.

In reality, often the first 2 steps are different.

1. Attacker gains "user" level access to a system (say phishing to be realistic)
2. Attacker privilege escalates to "system" on the workstation
3. Attacker attempts to gather hashes from SAM/local access tokens 
4. Attacker uses PTH to gain access to resources, searches for more tokens
5. Attacker eventually takes the Domain Controller (DC)
6. Game Over.

How is this significant you might ask?  Well....

More often than not, user level access is sufficient.

Inside an organization, who has access to file shares?  The intranet sites/apps?  The email?  The internal databases?  The users.  While "privileged accounts" such as domain admin or other privilege accounts might have more access, chances are all the users in the "finance dept" group have access to all the files on the "finance" file share.  There's a good chance the folks in "sales" all have access to both the files in "sales" and the CRM app.  Admins probably don't have direct access to the CRM app...

So, if an attacker is interested in stealing financial information for a company and they have access to the finance department's file share, do they really need any more access?  Better yet, they probably have access to the "sales" and the "research" file shares as well because of poor access control on the file server.  So at this point if an attacker can gain all the information they need without raising the threat level of the defense why should they?  

What sorts of things can a "user level" account do?  They can query the domain for pretty much all the information contained, such as machine names, user names, groups, group membership, etc.  What can be done with all of that info?  If an attacker had a list of all the user names, they could launch a password-guessing attack against everybody in the domain.  Or, perhaps they could send a phishing email to everybody in the "sales" group trying to gain more access.  At that point it's really a "choose your own adventure" type of setup.

This is the flaw in the threat model presented.  An attacker can usually get at most, if not all, of the critical data of an organization by compromising user accounts.  Remember folks, this is the real world, not CCDC.