Why does DISA STIG recommend "Deny access to this computer from the network" for Domain Admins?

Question

[Note: This question is regarding the technical description of what the STIG is recommending. It is not asking about whether enabling the setting is a good process that enforces other technical controls.]

For Windows systems, the U.S. DISA STIGs recommend enabling the Deny access to this computer from the network for the Domain Admins and Enterprise Admins groups:

https://www.stigviewer.com/stig/windows_8/2014-01-07/finding/V-1155

The stated justification:

In an Active Directory Domain, denying logons to the Enterprise Admins and Domain Admins groups on lower trust systems helps mitigate the risk of privilege escalation from credential theft attacks which could lead to the compromise of an entire domain.

Connecting remotely to a system using only an SMB connection (this is what Deny access to this computer from the network blocks) does not expose credentials.*

Note that Deny access to this computer from the network denies only remote SMB connections; it does not prevent interactive logon or RDP access. Also, remote SMB connections do not create a cached logon verifier.

With this in mind: How does this setting mitigate a "privilege escalation from credential theft" attack, since credentials are not exposed to the potentially compromised host to which you are connecting? (In other words: How can this setting prevent credential theft on a potentially compromised host if there's no credential exposure on that host?)

[Note: I'm not asking for opinions about standard security practices. I am asking the specific question stated in the previous paragraph.]

*This is corroborated at the following resources:

• https://digital-forensics.sans.org/blog/2012/02/21/protecting-privileged-domain-account-safeguarding-password-hashes - "......a network logon will not result in domain hashes being stored on the remote machine. This is a very important fact and one that I will demonstrate shortly."
• http://www.ampliasecurity.com/research/wce12_uba_ampliasecurity_eng.pdf - page 25

Answer 1

@HallowProc has a good answer that I want to expand on more than a comment.

First and foremost, the Enterprise Admins groups should be empty and only populated for the rare administrative task.

The only location where Domain Admin credentials should be used is on the Domain Controller(s) or a dedicated administrative workstation. These systems should be of the highest trust level in the organization. Access should be restricted so administrative traffic (RDP, WinRM, etc) can only be exchanged by these trusted systems using IPsec (Server and Domain Isolation). Thus only exposing necessary services (Kerberos, LDAP, etc) to systems at a lower trust level.

Domain member systems are of a lower trust level and should never have a Domain Admin logon to the system. Further no domain account with a wide breadth of admin permissions should be allowed access. An example of this is an account with admin access on all domain member workstations. The breadth of admin access should be narrowed to a smaller subset.

By architecting Active Directory in this manner, the use of privileged accounts is limited to just a few systems. So implementing this security control achieves the following:

1. Defense in Depth - suppose there's a script that logs into the domain controllers to perform an adhoc task and there's a typo. Pointing the script to a member workstation of a lower trust level. While this should be stopped by IPsec rules and other controls, having a setting such as this would be another layer on the Defense in Depth onion. It prevents the elevated account from logging in where the credentials could be extracted and exploited.
2. Limit Lateral Movement/Containment - While your question is regarding Domain/Enterprise Admins, the actual setting also includes the local administrator accounts. This leads me to believe that the setting is aiming to mitigate exploitation related to Mimikatz (token/hash extraction --> Pass-the-Hash/Token). If Microsoft LAPS is being used (or something similar), I wouldn't be as concerned with limiting network access to local administrator accounts. As each system would have a unique password for the local administrator account. However, if a privileged account gets compromised on a workstation and attempts to access another system, the deny login event should raise an alert. Minimizing the time from exploitation to containment.
3. Process Improvement - While large enterprise environments are much better at segregating privileges, many still use Domain Admin level credentials to perform administrative duties on member systems. Having a setting like this improves the process as it directs sysadmins towards segregating permissions into multiple accounts.

In the worst case scenario where Domain Admin credentials are compromised on a low trust member workstation, containment is achievable. An alert should be raised showing successful use of those credentials followed by access denied events. Network access will be blocked to the remaining member systems (via this setting) and domain controllers (via Server and Domain Isolation).

Granted there are ways past this particular control especially when Enterprise/Domain Admin accounts are involved. However that means a much more sophisticated adversary. If that's the case, there's more to worry about then this particular setting alone. I believe this is aimed at scenarios where a low trust workstation gets worked on by helpdesk/sysadmin/one-person-shop. The adversary uses techniques such as those used with mimikatz to try and pivot with those credentials (privilege escalation).

The setting isn't perfect, but to get any more specific would be unmanageable for DISA. Every environment is different and comes with its own caveats. This setting aims to strike the balance.

I agree with your statement in regards to removing the Domain Admins group from the local administrators group. Instead, create a single Global Security group for the group of systems being administered. Something like gs-localadm-room-007. This achieves that narrowing of administrative duties so if that account were compromised, there would be no affect on other security silos.

Answer 2

Starting on Slide 81 of this presentation by Sean Metcalf of ADSecurity.org -- https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Sean-Metcalf-Beyond-The-MCSE-Red-Teaming-Active-Directory.pdf -- Sean goes over the AD Admin Tiers and the Red Forest concepts.

While Sean doesn't mention it, I think it boils down to setting up Domain Administrators once in a Tier-0 / Red Forest scenario and then using Authentication Policies and Silos to lock that concept down permanently. Mark Russinovich and Nathan Ide of Microsoft fame discuss them here -- https://www.rsaconference.com/writable/presentations/file_upload/hta-w03-pass-the-hash-how-attackers-spread-and-how-to-stop-them.pdf -- and HD Moore of MetaSploit fame (along with Joe Bialek of Microsoft and Ashwath Murthy of Palo Alto Networks) discusses them in detail here -- https://hdm.io/writing/Mitigating%20Service%20Account%20Credential%20Theft%20on%20Windows.pdf

Speaking of the metasploit-framework, it is best to test the concepts by leveraging its attack framework, or other exploitation frameworks such as PowerShellEmpire, or cross-between frameworks such as PowerSploit. By leveraging use incognito and more-recently use kiwi from meterpreter, one can get access to the test criteria necessary to see inside all of the cred stores and all of the cred traffic. After running use kiwi, the kerberos, mimikatz_command -f sekurlsa::logonPasswords -a "full", msv, livessp, ssp, tspkg, and wdigest meterpreter commands become available. You can even mimikatz_command -f crypto::listStores. Even if a user such as Domain Administrator has not logged in, you can grab their ticket by passing-the hash with the sekurlsa::pth command as well (although you need the hash from, say a NETNTLMv2 packet or service-side capture). Check out the Unofficial Guide to Mimikatz for more information.

What is interesting about this DISA STIG recommendation Deny access to this computer over the network is not that this will prevent Domain Administrators from sending NETNTLMv2 traffic by attempting to log on via SMB/CIFS (or any other protocol), but that it's a policy that they can't do so in the first place (if they keep trying to login remotely to a policy where it makes them impossible to do so, then they are merely doing the same thing over and over again expecting different results). So it's merely a technical policy representing a real-life policy and guideline: Domain Administrators shouldn't be logging or attempting to log into anything unless it's to set up domain-specific things in a special Red Forest or other Tier-0 scenario.

There's actually even more-interesting ways of capturing Domain Administrator (or other) creds, such as NetRipper, or even more with mimikatz (even more undocumented). DAT FRO-DO himself, Itai Grady, spoke about Protecting Your Browser Secrets in a Domain Environment at BsidesTlv in Tel Aviv recently -- definitely worth checking out.

Answer 3

The answer to your question:

What specifically is a "privilege escalation from credential theft" attack in this context, ...

is that a privilege escalation attack from credential theft means that higher privileged credentials are obtained (harvested) from a system that you have access to with a lower privilege set of credentials. In this case, you may have local admin to a system but if a Domain Admin were to login and you obtain his/her credentials from that system (via Mimikatz, cached credentials, etc) you now have escalated privileges by stealing Domain Admin creds.

Part 2:

and how does enabling this setting mitigate it?

By preventing Domain Admins from logging into workstations, you effectively mitigate the risk that DA credentials can be harvested from a workstation. EDIT Additionally, even if credentials are harvested from a machine, this control is designed to "decrease the risk of lateral movement resulting from credential theft attacks". So it's not just about protecting ONE workstation, it's about preventing lateral movement from one workstation.

Answer 4

While it is sometimes difficult to decipher the meaning behind some of the STIGs, I believe the main concept here is that you should not be managing computers with domain administrator accounts, given the highly sensitive nature of those accounts.

This is from the STIG itself:

For domain-joined workstations, the Domain Admins group must be replaced by a domain workstation administrator group (see V-36434 in the Active Directory Domain STIG). Restricting highly privileged accounts from the local Administrators group helps mitigate the risk of privilege escalation resulting from credential theft attacks.

However, I have not tested this particular setting, but would not be surprised if this restriction has no affect at all. Many of the STIG recommendations on rights and privileges are a bit absurd and do not have the intended effect and are automatically reverted back to the defaults.

Edit: This really needs to be tested because I don't believe you can prevent domain admin login no matter what policy you set or what group they are in. The STIGs in my experience are poorly tested and have policies that have no effect. For example taking away act as part of the operating system from the system account, which makes no sense and is automatically reverted.

Edit: Because this answer is getting downvoted, I want to clarify that my answer is that I agree with @bill_stewart that the setting in question does not prevent a credential theft attack since credentials are not directly exposed. But on top of that I am saying that the setting likely has no affect at all because you can't deny a domain administrator from logging in to a computer. My original [removed] comment about cached logins was a side note and not meant to be part of the answer itself.

Answer 5

How does this setting mitigate a "privilege escalation from credential theft" attack?

The answer to the question depends upon the precise details of how the Deny access to this computer from the network setting works. We have to understand exactly what this setting does before we can say it is useful in mitigating a potential vulnerability.

What does this setting do?

This setting is a forced "access denied" for remote SMB network connections, even if connections are allowed via other means. It is similar to a "Deny" entry in an Access Control List and is evaluated before Allow access to this computer from the network (just like with access control lists in Windows). Also, it is important to understand that this setting does not apply to RDP connections. Two common examples of SMB connections are the "Net use" command and MMC snap-ins such as the Event Viewer tool.

What is the risk of remote SMB connections?

Remote SMB connections do not expose credentials on a remote host. So this means if I connect to a compromised system with a privileged account using only a remote SMB connection (e.g., an MMC snap-in), my privileged account credentials are not exposed on the compromised system.

How does this setting mitigate the threat of credential theft?

Remote SMB connections do not expose credentials, so there's no threat of credential theft. Therefore the Deny access to this computer from the network setting is unnecessary to mitigate this threat.

Why is this setting suggested as a remediation to prevent potential credential theft?

There appears to be a fair amount of misunderstanding regarding what Deny access to this computer from the network does. Properly understood, this setting is unnecessary for mitigating credential theft because credentials are not exposed from remote SMB connections.

Explanation by way of analogy

Suppose there is a young woman named Emilia who has heard that there is a handbag shop that carries a particular handbag that she wants to buy. The shop is in a part of town known for a group of thieves stealthily stealing peoples' credit cards without their knowledge, so the shop has tried reducing some prices to increase business. This was in the days before the Internet and web sites, and she hears a commercial on the radio that they have a particular bag she wants to buy.

She wants to verify the price for herself, so she has two options: 1) Drive down to the shop and risk getting her credit card stolen, or 2) call the shop on the phone and verify the price. (She is careful and refuses to give her credit card number over the phone.)

What is the risk of her credit card number being stolen from her if she does not physically drive down to the handbag shop? Of course, there is no risk, since her credit card is never physically there to be stolen. [Remote SMB connection: Credentials are not exposed] If she drives down to the store, then there is a risk of the clever thieves stealing her credit card. [Interactive logon = potential credential theft]

So in other words, this question is asking: If Emilia only calls the shop on the phone, and does not give out her credit card number over the phone, what is the risk of her credit card number being stolen from her? The answer of course is that there is no risk in that case.

Process policy vs. technical policy

It seems that DISA recommends this setting to help organizations enforce a good process policy. This setting can be useful in that context to prevent members of Domain Admins from connecting to remote computers using SMB connections and pursue other administrative means. However, the question is asking about the technical details of this setting, not its process implications. At this time it appears that the DISA recommendation is giving an incorrect technical description of this recommendation, when in fact they should be providing a valid process recommendation.