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 1) a given endpoint is compromised by malware with local admin authority and 2) 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.
Here are some example scenarios:
a) Admin logs onto endpoint with a privileged account; endpoint then compromised by malware that harvests credential artifacts from memory or registry
b) On a given endpoint, admin remotely logs on to another system with privileged account, later malware harvests credential artifacts left behind
c) Endpoint already compromised; admin logs on locally or accesses another system with privileged account; 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 Account Management and Privileged Session Management are often touted as the solution to this. 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 through/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 thus it’s 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 push back, hinders adoption and encourages circumvention.
In this webinar 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:
1) Implement a parallel environment of workstations and servers simply for the use of admins. This creates all kinds of expense, complication and inconvenience
2) 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 help us out, showing how their PowerBroker Privileged Access Management Platform accomplishes #2 without changing how admins work.
Please join me for this real training for free event that not only gets into the interesting technical risks, but provides solid, practical solutions for addressing them.