Obfuscated Account Names in Windows Computer Management / Groups

A few ideas:

• You could set the groups as dynamic dist groups to prevent expansion, and set them up as moderated to prevent unauthorized mail.
  • Or just set a hard filter of allowed senders if that'll fly - but, that won't work for external users without disabling authentication.
• You can strip the reply-all button off of Outlook via group policy for internal users.

Nothing here stops users who know who's in the list from just sending mail to them.. but you can prevent casual exposure of that if it's non-trivial to expand the group to its members.

I'm at a Tier 1 PCI vendor. We have something like this in place, with a few differences.

The auditors are actually attempting to describe a very real problem, but doing an incredibly poor job explaining the implications and needs analysis.

It is now more effective to compromise a system by using a hash of a password or an existing token. Put plainly, your attacker no longer needs your username and password. There are now easier ways to attack a system. Under no circumstances should you assume or conclude that this type of attack is unlikely. Hash attacks are now the defacto attack vector.

Hash attacks are actually worse with smart card accounts, which is ironic, because most people expect that implementing smart cards would increase the security of a system.

If an account is compromised due to a pass-the-hash attack, the usual response is to change the account's password. This changes the hash that is used to authenticate. Also, a normal password expiration/change may surface an incursion, due to the attacker's hash would begin to fail. However, with smart cards, the password is 'system-managed' (the user never enters the password to authenticate), so the hash never changes. That means with smart card accounts, an incursion may go unnoticed for much longer than with an account that uses a password.

Here are mitigations I would consider:

• For smartcard-enabled accounts, which many large companies use for highly-privileged accounts, change the password of the account on a frequent interval. This changes the hash. You can also change the hash by un-smartcard enabling the account, then re-smartcard enabling it. Microsoft does this every 24 hours, but you need to evaluate the potential impact this may cause in your environment, and establish a sane schedule so that you don't create additional problems.

• For workstations, I would not use domain accounts for admin purposes at all, if possible. We have a local account that can be used to elevate for UAC type operations. This satisfies 99.9% of most elevation requirements. Workstations tend to be hot attack vectors, due to the lack of regimented change control, and the existence of Java JRE and Flash.

  This approach works for us due to we have a formal mechanism for managing and enforcing the password for the local accounts and that the password is unique on each system, and that a secure method exists for someone to request the password. There are also commercial applications that can perform this function.

• If you cannot provide a local account solution for workstations, then yes, a separate domain account should be used for administrative access to workstations, and that account should not be used for administrative access to servers. Another option may be to use remote, non-interactive support management tools that use LocalSystem to perform activities, and an authentication mechanism that is separate from Windows.

• For the highest privileged accounts (Enterprise Admin, Domain Admin, etc), use only a jump server. This server would be subject to the most restrictive security, change control, and auditing. For all other type of administrative type functions, consider having a separate administrative account. The jump server should be restarted daily restarts to clear the process tokens from the LSA process.

• Do not perform administrative tasks from your workstation. Use a hardened server or a jump server.

• Consider using easily resetting VMs as your jump boxes, which can be reset to clear out memory after each session.

Further reading:

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

Microsoft Security Intelligence Report, Volume 13, January - June 2012
http://www.microsoft.com/security/sir/archive/default.aspx

Read the section: "Defending against Pass-the-Hash attacks".

Defeat dreaded pass-the-hash attacks
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753