So does DirectAuthorize totaly eliminates PTH attack posibility?

Showing results for 
Search instead for 
Do you mean 
Advisor II
Posts: 55
Registered: ‎12-18-2015
#1 of 2 1,205
Accepted Solution

So does DirectAuthorize totaly eliminates PTH attack posibility?

HI. I saw here and there on the blog articles mentions about PTH attack in context of privilege elevation, but i still did not grasp the final idea. So do i get things rights. that since Centrify relies on Kerberos, this means that it can help to remove posibility to execut PTH attack, since during privilege elevation a user does not generates any local password hashes, but just using Kerberos tikets to pass authorisation mechanism of operating system?

Centrify Guru I
Posts: 2,415
Registered: ‎07-26-2012
#2 of 2 1,187

Re: So does DirectAuthorize totaly eliminates PTH attack posibility?

[ Edited ]



Welcome back.

Personal comment:  I am loving the questions we are seeing in the community lately.


I need to contextualize this correctly because mitigating the risk of  "advanced Windows credential theft" techniques are more about discipline and balance between people-process-technology, than what most people want to hear (technology solves my problem and I forget about it). 


Also note that attacks like PtH have been around for a long time and infrastructure leads and security practitioners still "don't get it" and continue to perpetuate poor habits that contribute to these attack tools being effective in the hands of threat agents.


We have covered this topic before here (in the context of MS ESAE/Red Forest):

The Basics - A 10,000 foot view of a breach:  Blue vs. Red.

In your classic Blue vs. Red team scenario, assuming the Red team is your threat agent and the Blue team wants to defend their infrastructure, the strategy of the Red team is as follows:

  • Red team wants to move North (internet)-South (inside the blue network) and gain control of a node.
    The most common way to do this is a combination of social engineering and malware.  Our CEO @TomK has done a great job at providing awareness of the targeting of CEOs for fraud.
  • Once a node is breached, the Red team wants to move laterally (East-West) and deploy different techniques to get to the crown jewels.  As you know, the most common attack vector is privileged accounts (because they guarantee freedom of lateral movement and privileges to do what they want).
  • Finally, they reach the asset they want and decide to either clear their tracks or set a back door for future access.

Note how everything is predicated on breaching a node and in Windows, to breach a node nowadays (unless you have a zer0-day exploit in your arsenal like highly-motivated and resourced threat agents have), you must run the malware in Administrative context.


Issues and habits that contribute to node breaches

The main issues that contribute to node breach in Windows environments are the following:

  • Prevalence of older (or unpatched) operating systems - if you have tried to copy mimikatz in Win16 or Win10 you know that newer OSs do a better job than older ones.  Some of them don't stand a chance (like Win 2008); but unfortunately we still have organizations running OSs as old as Windows 2003.  A data point is that we are announcing the deprecation of Windows 2003 AD forest/domain mode and getting push back.  Same with 32-bit OSs.  Sometimes we get push-back from less mature organizations that simply say "your software requires an updated version of .NET, we can do this because our application teams will kill us";
    All these "push-back" items are about organizational maturity.  Sometimes not having the right org chart (e.g. CISO reporting to finance or IT) or simply organizations that don't have incentives to care deeply about IT security.

  • Poor Habits... many Windows administrators still:
    • Log in to "client" systems with their privileged accounts.  Since these systems tend to have access to email or internet, this makes the likelyhood of node breach a catastrophic event.  E.g. if you get the hash of a Domain Admin, you own everything.  There are two problems here
      a) They are not separating their 'regular user' vs. 'privileged user'
      b) They are using privileged credentials in internet-connected systems (not in secure workstations exclusively).
      c) They tend to "always" have assigned memberships to administrative groups, instead of making this on demand.
    • Tend to continue to use "shared infrastructure accounts"  (e.g. the same local admin user/password combination).  The problem with this is that when you get the hash for this account, you pretty much can use it on any other system.  This also makes lateral movement very easy, and not only that, each node becomes brached too because most likely that 'localadmin' is an Administrator.

      I must say, as a former Windows administrator, these things are not done intentionally, they are done because of the need to maintain productivity.  The challenge here is a cognitive gap (perhaps not addressed by training and security policy), plus lack of security maturity.   Remember, security pratitioners are chartered to to implement controls that minimize incidents like user error, and poor habits (like not using secure workstations) - these are elements that may have a causal relatinonship to data breaches.
  • Complexity - when things are complex (you are using 25 products with different maturity levels, different dashboards, different design paradigms), this makes things harder.
  • "Check the box" syndrome:  (take this as a personal opinion), unfortunately many IT practitioners think about security in terms of a checkbox.  I see it every day.  Folks worry more about "the report"; "the SIEM feed" (which proves to my boss that I did my job) than the effectiveness of the controls.


Your Answer

Let's dissect your statement.  Starting with the subject line:

So does DirectAuthorize totaly eliminates PTH attack posibility?


The answer to this statement is it depends.  Let's start with the premise that makes attacks like PtH possible:  a breached node.  If the node is already breached (unintentional, but scary statements coming)

  • If you log in to a system (by means of Password, MFA, Smart Card, whatever), that's it the password hash has been captured and there's nothing you can do about it other than changing the password.
  • If you use the "Run As" function, your password hash is captured.
  • If you use a vault (that injects the password to log in or to elevate) - the privileged credential's password hash is captured.
  • Many other methods that I won't mention.

Notice the pattern here?  If a node has been breached, you have no chance against an advanced threat even if you have DirectAuthorize.


OK that being said, let's realign the rest of your post:

So do i get things rights. that since Centrify relies on Kerberos, this means that it can help to remove posibility to execut PTH attack, since during privilege elevation a user does not generates any local password hashes, but just using Kerberos tikets to pass authorisation mechanism of operating system?


It's different than that.  In PtH, what you don't want is to inject the password because the hash of it will be captured.  Directauthorize for Windows (in the Centrify Agent for Windows) uses token manipulation.   Let me walk you through an example: 


Lisa Simpson has a DirectAuthorize role assigned on a Windows system called WIN10:



The Windows Admin Role, consists of a single right.  The ability to run an Administrative Desktop as a member of the local Administrators group:


Most importantly, in WIN10 - Lisa is NOT a member of the local administrators.
That in itself contributes to less likelihood of node breach, because should lisa click on some malware, it won't be executed with administrative rights (note that this does not mean that the malware can't give information to the attacker about the network.  Attacking a nework works with a lot of data gathering.  Maybe all I needed was access to Lisa's documents that may contain a spreadsheet with some router passwords - see my note about discipline later).




Now let's test Privilege Elevation in a demo.



Note what happened here, the user logs in without any privileges and is able to

a) perform their duties as an administrator

b) decrease the likelyhood of lateral movement
in the likelyhood of node breach, her credential is restricted in terms of elevation and lateral movement

c) when you combine this with Centrify zones, this further limits lateral movement.
you contain the movement of the red team member.

d) Finally, you can use Centrify zones to force Windows administrators to only be able to log in to specific systems.


Conclusion:  It's about discipline

I must caution and repeat that protecting against some of these attacks is a question of discipline.   It's quite common that we see these bad habits when visiting prospects and customers.


For example, there's also the possibility for someone to do a "poor design" and implement the wrong control.  Note the checkbox next to the Desktop right:

If this control is in place, just when you log on, use run as, start a service, etc your password has to be put in, and in a breached node....(yes, like you suspected) your password hash is captured. 

This is why discipline and deep understanding of what the problem is are the foundations required to protect against these methods.


Some resources

Microsoft has a good hub for resources here:


In this article:, we outline 10 principles:


Summarized Principles to Mitigate Credential Theft in Windows Environments

  • Principle #1 (P1)  Perform the basic steps to secure your Active Directory
    • Reduce the number of Administrators and manage security group membership.
    • Establish administrative workstations (or servers).
    • Protect Domain Controllers and maintain them up-to-date.
    • Monitor your environment.     
  • Principle #2 (P2) Have a plan to migrate applications and services that depend on NTLM.
  • Principle #3 (P3)  Separate user accounts vs admin accounts.
  • Principle #4 (P4)  Implement distinct admin passwords per workstation.
  • Principle #5 (P5)  Use "Privilege Access Workstations" for administration.
  • Principle #6 (P6)  Control the privileges of service accounts.
  • Principle #7 (P7)  Don't allow regular users to have administrative rights in endpoints (desktops, laptops, etc.)
  • Principle #8 (P8)  Embrace Temporary Access Controls (JIT, on-demand).
  • Principle #9 (P9)  Deploy an administrative forest (Red Forest) with a selective one-way trust and limit upwards administration in the corporate side.
  • Principle #10 (P10) Use critical thinking - MS ESAE is complex and may not work in all instances

Centrify can help you implement controls around all these principles and simplifies the overhead of doing a full MS ESAE with MIM/PAS.


Keep the discussion going!



Want to learn more about practical Centrify examples? Check out my blog at
Follow Centrify: