I've been noticing something lately. Organizations will go to lengths to harden a server or application, but the permimeter around that object hasn't been considered. While this post talks about Active Directory security, the same principles can be applied to most applications. The focus is essentially, don't just think about what this server does that can be compromised, but consider the infrastructure around it that has a potential path for exploitation. Some of this may be pretty basic, but this should serve as a reminder to not miss the forest for the trees. Or, as a colleague put it, don't leave the door open at Fort Knox when you go out for a smoke break.
Also, you'll notice the risk and remediation verbiage. I do primarily GRC (government regulatory compliance), so this is the jargon I use. Feel free to mentally substitute what words make sense to you if your specialization of InfoSec defines it differently.
One of the features of Windows Server Operating Systems prior to version 2012 is the ability to reset the local administrator password with a Windows installation CD. This means that anyone with physical (or virtual) access to the machine can become a local administrator. While Domain Controllers do not have a local admin password, they have a _Domain Services Restore Password, which functions the same way. Once logged in with this account, someone could add themselves to the Domain Admins Group and establish persistence. In fact, I had to do this in a few years back on the legacy domain for a client in Malaysia to resolve an Exchange Server issue, which was on a Domain Controller.
Upgrade all Domain Controllers and Servers to Server 2012 or higher, ideally to Server 2016. Alert whenever sensitive groups are modified. For example:
Do not grant Exchange local administrator privileges to administrators that are not members of “Organization Management”.
Physical security threats are somewhat replaced by virtual security threats in virtualized environments. Regardless of how vCenter or vSphere privileges are delegated, anyone with the hypervisor root password can modify and access any virtual machines on that host, including Domain Controllers. This means they could copy the vmdk, or attach it to another Virtual Machine. Once the Virtual Machine is accessible, they can pull 'ntds.dit' from the Active Directory database, the encryption key, and then crack users' passwords without maintaining persistence on the Domain Controller.
Domain Admin privileges should only be used to “administer administrators”, and as such should be used very infrequently.
Anyone with domain admin privileges should have 3 accounts: one non-admin, one admin, and one domain admin. All logons with domain admin credentials should generate an alert. Additionally, delegation should be disabled for all domain admins. Any service accounts with domain admin privileges DO NOT need this level of permissions, and effort should be made to decrease the privileges granted.
If there are any branches where physical (or network) security cannot be guaranteed for any reason, certain additional safeguards should be put in place. Hypothetically, these are not needed if the previous recommendations are implemented, but combining all of these increases security exponentially. Network security is slightly less critical due to the fact that Active Directory replication traffic is encrypted, but should still be considered.
Implement Read-Only Domain Controllers (RODCs) in these high-risk branches. This way passwords are only sent and stored as needed locally. For example, Alice’s* password would only replicate if Alice is in the local office and attempts to authenticate.
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4964)