4

[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:

  • It simply says that no-one except the user should be able to connect to the computer via network, and it explicitly states that this includes Domain Admins. So removing from the group is different as preventing loggin-in from the network. So if someone nicks Domain Admin account he can access any Desktop PC on the network, which is normally not needed and in todays time, there's policy to disable it. Domain Admins except for accessing computers on the network might be prevented from doing many other things. That page discusses only Desktop PCs and it's very decent policy. – Aria Jul 15 '16 at 19:31
  • Thanks for the comment, but the question isn't asking for opinions regarding the recommendation. – Bill_Stewart Jul 29 '16 at 16:23
4

@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.

  • 1
    @Bill_Stewart, I don't believe you're reading our answers properly. Consider an environment where this setting is in place and the standard user on WORKSTATION01 is compromised. EA/DA cannot remotely access WORKSTATION01 and have the credentials harvested (i.e. mimikatz). The setting has blocked "privilege escalation from credential theft". Just like Hollowproc mentioned. BTW, your STIG link mentions the local admin accounts. – user2320464 Jul 25 '16 at 22:10
  • @Bill_Stewart, RDP and remote PowerShell commands are blocked by this setting. – user2320464 Jul 27 '16 at 19:12
  • @Bill_Stewart, FWIW the local admin accounts are listed as All Local Administrator Accounts on the Stig Viewer page. – user2320464 Jul 27 '16 at 19:15
  • @Bill_Stewart, it most certainly works for RDP and much more. I encourage you to build a test environment. Microsoft offers temporary licenses for testing purposes like this. – user2320464 Jul 28 '16 at 16:27
  • Thanks for the feedback, but it is simply not correct that Deny access to this computer from the network blocks RDP. Also, I have updated my question to be more precise (I'm not asking for opinions about good security practices). Feel free to update your answer. – Bill_Stewart Jul 29 '16 at 17:08
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.

  • Thanks for the references. However, I confess I must not be explaining myself properly. I'm not asking for opinions about whether this setting is best practice--I agree that it has its place, but that's not what I am asking. I am pointing out that it does not prevent credential stealing on a potentially compromised host--it prevents the connection, yes, but it doesn't mean that it prevents credential exposure. (I guess I must be doing a poor job explaining the actual question, or perhaps there is a language barrier...) – Bill_Stewart Aug 14 '16 at 0:56
  • No worries -- it's a highly-technical scenario. Usually that results in a language barrier, but one I believe we've overcome! – atdre Aug 14 '16 at 1:05
  • Your comment on my answer is good in that it delineates between process and technical policy. This setting enforces good process policy, but my question is about what this setting does technically--does it actually do what the STIG says it does? The answer to this question is no; it actually does not. In other words, the STIG recommendation should be updated to explain that its purpose is process policy rather than technical policy. – Bill_Stewart Aug 14 '16 at 1:07
  • 1
    The STIG should be updated. I don't even know if CIS Benchmarks are current with what Microsoft provides in a 2012, 2012 R2, and definitely not a 2016 functional-domain level. Don't expect everyone in the world to be able to go this deep with ever-changing Microsoftisms. It's highly-specialized Red Team and/or DFIR Tradecraft – atdre Aug 14 '16 at 1:12
0

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.

  • @Bill_Stewart added content to my answer – HashHazard Jul 15 '16 at 23:00
  • 1
    What good does "owning" the network do if you can't login anywhere? And this control isn't meant to be a silver bullet it's just meant to be another layer in the security onion. – HashHazard Jul 16 '16 at 4:49
  • I have updated my question to be more precise. Deny access to this computer from the network only denies remote SMB/CIFS connections, not interactive logons. The question also isn't asking about security best practices. Feel free to update your answer. – Bill_Stewart Jul 30 '16 at 15:27
0

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.

  • 1
    @Bill_Stewart Merely taking Domain Admins out of a local Administrators group does not deny login access unless you remove members from the Domain Users group as well. The idea here is to ensure that members of the Domain Admins group don't cache their credentials on any workstations. Someone who compromises the one target system would not necessarily be able to move laterally and compromise the entire Active Directory environment. – Scott Jul 15 '16 at 20:14
  • 1
    There are hacking tools which can dump tokens and passwords of people who are logged-on. So no domain admin wants to connect to any workstation. In fact, it's best not to have workstation admins either, so only user password is used on that system. It's very good, post-snowden policy. No digging in user profiles, network storage and desktops. – Aria Jul 15 '16 at 20:33
  • And you can automate creation of dedicated admin account with dedicated password for each host, if you want to go extreme and preserve control for emergency situations, which is e.g. neutralizing compromised system. – Aria Jul 15 '16 at 20:35
  • 1
    Cached logon verifiers are absolutely relevant to the question, as they are a form of cred theft. "One important thing to note, however, is that if you are caching logins, you should never login locally to a system using a domain administrator account". I don't necessarily agree with this statement -- of all of the ways that cred material is splashed around a running machine, mscash2 is the most-difficult to crack. If the password is over about 10 characters, mscash2 won't prevent meterpreter's run cachedump module from adding the cred as loot, but will prevent hashcat from cracking anything – atdre Aug 13 '16 at 20:36
  • 1
    You are correct that I updated the question; sorry for any confusion that this caused. (This is why I invited others to update their answers). I believe you are 100% correct that this is process policy rather than technical policy. The STIG description is actually misleading in this case, and should use wording like in your answer, rather than what it says now. – Bill_Stewart Aug 14 '16 at 1:01
0

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.

  • This answer should not have any downvotes because it is complete, technically correct, and answers the specific question being asked. As there have been no comments on why this answer was downvoted, you can safely ignore any downvotes as the answer is, as noted, correct. – Bill_Stewart Mar 30 '17 at 20:25
  • Agreed, not sure why you got downvoted. – Lucky Luke Jun 25 '17 at 18:08
  • 1
    @downvoter - care to explain? – Bill_Stewart Apr 5 '18 at 16:15

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.