We're preparing for a scenario when one of the accounts in a domain gets compromised—what to do next?

Disabling the account would be my first go-to answer, but we had pentesters here a few weeks ago and they were able to use hashed logins of an admin user who left a couple of months ago.

Our two answers so far are:

  1. Delete the account and recreate it (creates new SID but also more drama for the user and work for us)
  2. Change the password at least 3 times and disable the account

What would your method be, or what would you recommend?

  • 1
    If it's an admin account that was compromised, then go about creating more admin accounts for your own purpose. If it's a low priv (normal user) account, perform network scans and go find an Admin account to go compromise. Owning a regular user gets your foot in the door to perform more "targeted" attacks. – blaughw Dec 19 '16 at 23:45
  • 4
    Are you saying that the account of the admin user who left a couple months ago wasn't disabled on that person's departure? I guess I don't see how that example speaks to the effectiveness or ineffectiveness of disabling accounts. What's the rationale for changing the password 3 times rather than once? – Todd Wilcox Dec 20 '16 at 2:35
  • @ToddWilcox the account was disabled right when the person left and groups removed (that's a standard practice when people leave) yet they claimed they were able to gain access using it. – JurajB Dec 21 '16 at 2:58
  • So it wasn't removed correctly - you want tokens to be expired and access for that account removed on all systems – Rory Alsop Dec 22 '16 at 14:17

If only a standard user account is compromised, then changing the password once and leaving the account enabled should be fine. A hash will not work once the password has changed. It also won't work if the account is disabled. As a pen-tester myself, I wonder if the pen-testers were using Kerberos tickets. Under certain circumstances these can carry on working if a password is changed, or if an account is disabled OR even deleted (see links for the mitigation).

If a domain administrator account has been compromised, then it is literally game over. You need to bring your domain offline, and change EVERY password. Also the krbtgt account password would need to be changed twice, otherwise the attackers will still be able to issue valid Kerberos tickets with the information they have stolen. Once you have done all that, you can bring your domain back online.

Implement an account lockout policy, so that changed passwords can't be guessed. Don't rename your accounts. Attackers can easily find out login names.

Another important point is to train your users. They probably did something unwise that meant the account got compromised. The attacker might not even know the password, they may just be running processes as that account. For example, if you open a malware attachment that gives an attacker access to your machine, they will be running as your account. They don't know your password. They can't get your password hash, unless you are an administrator. Don't let users run as local admins on their workstations. Don't let domain admins log in to workstations with domain admin rights - ever!

Links for further info/mitigations:




  • What if you work in a relatively permissive environment, like academia? You might be dealing with users who have tenure and aren't willing to be "trained," and because they have tenure you're not allowed to get rid of them or reduce their privileges. – Katherine Villyard Dec 20 '16 at 0:08
  • 3
    I always recommend best practice. There will always be some types of organisations who can't implement it 100% Some people see themselves as above the law, and some organisations see tenure/egos as more important than fairly and uniformly applying policies/security. Those people and organisations will have to take responsibility for the consequences of their actions. Let's hope those academic organisations are not looking after important research which would be of value to foreign interests..... – bao7uo Dec 20 '16 at 0:13
  • 1
    I've done a few MVA courses on the golden ticket and pth mitigation but my understanding was that it remembers 2 passwords, hence you need to change it at least twice, not just once. Even the script for krbtgt does it twice. – JurajB Dec 20 '16 at 0:40
  • 1
    can't edit the above so adding: Even the script for krbtgt does it twice. Wouldn't then the best choice (for user account) be to change the password twice and then disable the account? – JurajB Dec 20 '16 at 0:41
  • 2
    You need to bring your domain offline. That may work for a small office, but it is unlikely that a large company can just take their domain/forest offline. – Greg Askew Dec 20 '16 at 0:49

they were able to use hashed logins of an admin user who left a couple of months ago.

Stolen credential hashes don't work for accounts that are disabled, unless it is on a computer that is not connected to the network. The process still needs to request a ticket or authenticate with a domain controller. Can't do that if the account is disabled.

You need to disable administrative accounts for ex-employees when they leave.

  • How does stolen credential hashes help the attacker? If they don't have the actual password, there's no way to get the password back from the hash (except for getting small passwords using rainbow tables), correct? Not sure what I'm missing here. – Chirag Bhatia - chirag64 Dec 20 '16 at 5:39
  • 1
    @ChiragBhatia-chirag64 You are assuming that the authentication schemes are replay resistant. They may not be, in which case the hashes are all you need to authenticate. – Jonas Schäfer Dec 20 '16 at 10:59
  • Can you give an example where the Windows authentication scheme uses the actual hash instead of the text password? Sorry if this sounds like a stupid question, I've never seen such an implementation before (or maybe I misunderstand Windows authentication mechanism) – Chirag Bhatia - chirag64 Dec 20 '16 at 11:20
  • 3
    @ChiragBhatia-chirag64 en.m.wikipedia.org/wiki/Pass_the_hash – Greg Askew Dec 20 '16 at 12:44
  • @GregAskew thanks, I had no idea this was a thing in Windows authentication. Kind of surprising they don't use something like SSL to send the password instead. This seems like a huge security issue to me. – Chirag Bhatia - chirag64 Dec 20 '16 at 16:30

Assuming a standard user account, you might want to consider:

  1. Change the password.
  2. Disable the account.
  3. Rename the account (username-suspect) and create a new account for the affected user.
  4. Add the suspect account to a "Disabled/Compromised users" security group.

For #4, already have in place a group policy that does the following:

  • Deny access to this computer from the network: "Disabled/Compromised users"
  • Deny log on through Remote Desktop Services: "Disabled/Compromised users"
  • Deny log on locally: "Disabled/Compromised users"

For a domain admin account, your entire network is toast.

  • why do you suggest changing the password more than once? – bao7uo Dec 19 '16 at 23:50
  • if a domain admin account was compromised then that means every user account is compromised. would you have them rename every user account? – bao7uo Dec 20 '16 at 0:02
  • 1
    @PHPaul: Depending on the incursion, if an account is still in use, renaming may be a valid tactic. And of course they aren't recommending to rename every account. – Greg Askew Dec 20 '16 at 1:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.