Wednesday, January 2, 2013

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.

No comments:

Post a Comment