What next after a Windows domain account has been compromised?

Solution 1:

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.

Solution 2:

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:

https://blogs.microsoft.com/microsoftsecure/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/

http://www.infosecisland.com/blogview/23758-A-Windows-Authentication-Flaw-Allows-DeletedDisabled-Accounts-to-Access-Corporate-Data.html

https://mva.microsoft.com/en-us/training-courses/how-to-avoid-golden-ticket-attacks-12134

---

Solution 3:

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.