“Credentials still exposed in destination server even with PAM”
“TGT Tickets are still valid even after changing and managing passwords with PAM”
-Unidentified news source
Many cyber security experts believe the most effective solutions to secure your domain are Privileged Account Management and Jump Servers. Vendors of protection products claim that their solutions can stop attackers from stealing credentials and using them to move laterally in your enterprise domain environment. Unfortunately, these claims are unfounded. Attackers can bypass these protection mechanisms using Kerberos, pass-the-ticket, and token manipulation.
How Privileged Account Management works
Privileged Account/Identity Management, also known as PAM or PIM (correspondingly).
The main purpose of PAM/PIM is to rotate your privileged admins’ account passwords and service accounts with complex passwords that will be harder to guess or crack. Once your accounts are managed, users won’t have to log in with their managed password. Instead, they’ll authenticate through the system user interface and receive an active session; they are now logged on with the managed accounts or a one-time password (though it’s still possible to receive the real clear-text password). PAM/PIM also manages supported service account passwords in applications with an active agent or WMI to set the account’s new password after it changes.
Password management and vault storage, integrated in their PIM product.
How Jump Servers work
When you’re connecting via RDP to a remote server, you won’t log in directly to the remote server. Instead, you will be forwarded to a secure Jump Server, from which you will open a new RDP inside the Jump Server session into the remote server. So you actually have an RDP session inside an RDP session.
As a result, the credentials won’t be exposed on your source workstation (the endpoint you are connecting from), but they will still be exposed in your destination server (the server you are connecting to).
The truth is now revealed
Considering all of the circumstances where these solutions are applied—which are also very hard to deploy and implement—are they enough to stop credential theft?
Credentials still exposed in destination server
When logging in using a jump server, your credentials are left exposed in the memory of the destination remote server. Even if it’s a managed account, there is still a risk that an adversary steals the credentials and uses them to create privileged domain persistency that isn’t managed by the PIM.
TGT tickets are still valid even after changing passwords
Once authenticated using Kerberos, you receive a TGT ticket from your Domain Controller.
This TGT indicates an already authenticated token that doesn’t need to revalidate the associated account’s credentials. This ticket has its own lifetime that expires according to your domain configuration (GPO Policy), which is 10 hours by default. Consequently, even if your PIM/PAM solution has changed your password, an attacker who possesses your TGT ticket will still be able to use your “Managed Account” credentials for as long as it is defined in your GPO Policy, regardless of the vault intervention.
Pass-The-Ticket attack using Mimikatz, towards the DC
Cracking service accounts is still a risk
Even if your service accounts are managed, attackers can crack their credentials using a technique called “Kerberoasting”. Because your Service Accounts are associated with TGS tickets that can be requested by anyone in the domain, they are encrypted with the account’s NTLM hash password. The hash is encrypted using an old, simple-to-crack method like RC4-MD5. It can be cracked offline without interaction with a Domain Controller.
Unless the service account’s password is enrolled very frequently, there is still a risk that these tickets will be cracked, and as a result, the password of your service accounts will be exposed.
Token manipulation
Let’s say that (1) your PIM and jump server are fully deployed and your entire Domain Accounts, Service Accounts, applications, and services are managed, (2) all of your admins are using the jump server to interact with remote endpoints and services, (3) you have Red Forest Domain Design, (4) you’re using the protected users group for powerful accounts, and (5) the kerberos ticket validation policy is set to minimal exposure—you are still open to compromise.
Assuming all of these conditions are met (highly unlikely), attackers will still be able to hijack live sessions of your admins with methods like “token manipulation”, or by using “RDP / TS Session Hijack” implemented in the Mimikatz tool. The exposure will be minimal but still possible.
Elevating Token to domain admin in 1 command using Mimikatz
Major services cannot be managed by PIM and jump servers, and they will stay exposed to all attack vectors
Your applications still rely on the ability of your PIM and jump servers to manage and support them fully. The problem is that this information is publicly known, so an attacker will know whether a service is supported by your solution or not. He will then hunt these exposed services and evade the usability of your solution. As a result, your major services will be exposed to all of the known domain attack vectors.
Hunting your PAM admins to compromise the domain
From now on, the crown jewel of your domain isn’t only the Domain Controller. Finding vulnerabilities, or even just hunting the PIM/PAM server and operators, will benefit attackers and impose a big security risk to your network. You have just added another attack vector and persistence mechanism inside your environment that is more concealed than the Domain Controllers.
If an attacker managed to reach one of your PAM administrators, he basically compromised the entire domain. Logging into the web console with 2FA isn’t enough to protect you from the attacker.
It only takes one valid credential to compromise the domain
PIM/PAM only reduces the risk of your privileged account’s credentials from being stolen; it doesn’t provide a comprehensive solution for credentials theft. Attackers only need one valid credential to compromise your domain. Even if it manages to reduce the risk of credentials theft, it won’t be able to detect the actual intrusion and patient zero.
*Protected - 99.34% chance for detection and mitigation on attacker’s first move, contingent applying 50x multiplier on AD mask.
If you would like more information about AD|Protect, please get in touch: [email protected]
Comments