[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](http://www.disa.mil/) 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](http://www.infoworld.com/article/2616322/security/cached-windows-passwords-sound-risky----but-aren-t.html).

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