Credential artifact attacks like those made commonplace by mimikatz are tough to fight, and I maintain that trying to prevent artifacts and/or clean them up after the fact is not the right way to fight this battle. There are just too many ways artifacts get created. Mimikatz attacks like pass-the-hash, golden tickets, harvesting of cached credentials only work against privileged accounts because:
- a given endpoint is compromised by malware with local admin authority; and
- the admin has or will use a privileged account on/from that endpoint.
The sequence of #1 and #2 don’t matter – they just both need to occur on the same endpoint.
Ready to learn more? Check out my on-demand webinar "Pre-empting Mimikatz Attacks on Privileged Accounts Using Password Isolation Human Presence MFA"
watch now
Here are some examples of scenarios:
- Admin logs onto endpoint with a privileged account – endpoint is then compromised by malware that harvests credential artifacts from memory or registry.
- On a given endpoint, admin remotely logs on to another system with privileged account, later malware harvests credential artifacts left behind.
- Endpoint already compromised – admin logs on locally or accesses another system with privileged account, then malware steals password as it’s typed or derived credential artifacts from memory or registry.
How can you prevent #1 and #2 occurring on the same system? Ultimately, you can never allow the password of a privileged account to touch an endpoint that is or may be compromised. You can make up rules about password usage but when admins are under pressure some will succumb and use privileged passwords on an end-user workstation. More importantly, workstations (even admins’) get compromised – period.
Privileged access management (PAM) and
privileged session management (PSM) are often touted as the solution. And they can be, but it’s not a given. As always, the devil’s in the details. It all depends on exactly how the PAM/PSM solution works at a technical level and how you choose to implement it.
With some PAM/PSM solutions the password is revealed to the admin which means 1) you are back to depending on the admin to use the password according to the rules 2) the password obviously travels and touches the workstation. Even if the password is changed once the account is checked in, there is a sizable window of opportunity for bad guys. With other PAM/PSM solutions the password doesn’t
see or
know the password but it still travels through the memory of workstation and it’s therefore vulnerable to malware on that endpoint.
The other common problem with PAM/PSM solutions is that they change how the admin works, even forcing them to start using unfamiliar tools. This creates pushback, hinders adoption, and encourages circumvention.
In my upcoming webinar "
Pre-empting Mimikatz Attacks on Privileged Accounts Using Password Isolation Human Presence MFA", I’ll discuss all the issues in technical detail to help you really see what it takes to pre-emptively control mimikatz related risks to privileged accounts. You basically have 2 options:
- Implement a parallel environment of workstations and servers simply for the use of admins. This creates all kinds of expense, complication and inconvenience.
- Implement PAM/PSM technology that never allows passwords to touch the workstation and protects and leverages human-presence 2nd factor of authentication to ensure that intruders in control of an admin’s workstation can’t initiate privileged sessions using the admin’s non-privileged credentials.
BeyondTrust will also show how their
PowerBroker Privileged Access Management Platform accomplishes #2 without changing how admins work.
Please join me for this on-demand “real training for free” event that not only gets into the interesting technical risks but provides solid, practical solutions for addressing them.
watch now
