Password and Account Security
Enforce Least User Access (LUA)
In 2008, BeyondTrust conducted research noting 92% of critical Microsoft software vulnerabilities would be prevented by the use of a limited user (no administrator rights).
Running an environment that implements the LUA philosophy would not only increase security but reduce the chances of users from installing or spreading malware. Keep in mind that if a limited user account is compromised, an attacker has one more layer to circumvent and security is all about layers (commonly referred to as defense in depth).
Remove rogue administrative accounts daily
Create a script that periodically checks administrative accounts for discrepancies. This could be done by having a list of known or valid administrative accounts and having a script periodically query administrators accounts.
Securing Administrative Accounts
Do not use domain administrator accounts to log into workstations. Domain administrator accounts should only be used to log into domain controllers and other sensitive systems. Additionally, ensure that a strict and complex password policy is implemented for all domain administrator accounts within the environment. See below for a list of password recommendations that should be enforced on all domain administrator accounts:
- Must be at least fifteen characters in length. This would prevent Windows from storing an LM hash of the password.
- Must include uppercase characters
- Must include lowercase characters
- Must include numbers
- Must include non-alphanumeric characters
- Must not contain the username/service name
- Must not contain the system’s host name
- Must not contain system details (i.e. make, model)
- Must not be dictionary-based with character substitution (i.e. an “i” swapped for a “1”)
- Must not contain character sequences (i.e. “qwerty”)
- Must not be dictionary-based with common characters appended (i.e. “Password1”)
Limiting communication and open ports
Attacks such as Pass-the-Hash and CredCrack need to interact with multiple systems within the environment. Limiting workstation to workstation communication would prevent passing hashes, CredCrack and pretty much every other attack with mass SMB logins.
First, it is recommend to disable or restrict access to NetBIOS and SMB ports (TCP: 139, 445). Today's corporate network environments do not have the need for workstations to communicate with one another for SMB and/or NetBIOS functionality. When necessary, create firewall exceptions to allow workstations to communicate outbound in order to reach any network shares on servers. While we're on the NetBIOS subject, let's also increase security by disabling NetBIOS over TCP/IP. This would prevent NetBIOS spoofing attacks, another popular attack vector.
Moving forward! Let's take a look at private VLANs. Private VLANs will give us the workstation-to-workstation segmentation we are looking for. Any workstation wanting to communicate with one would have to go out into the LAN and hit the router. This would allow strategically placed IPS/IDS systems to intercept and analyze any malicious traffic.
But wait, there's more!
Detecting Network Anomalies
Create a rule in IPS/IDS systems to detect anomalies such as mass SMB logins. It's not normal for a system to establish connections with 50 systems in a minute.
Disable Windows Digest
Implementing solely this registry setting won't do much, but it's still worthy of mentioning. Special thanks to reddit's /u/3dg3c4s3 for making this easy to find.
In system registry settings, "find security packages key in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and delete the line wdigest from the list of packages". [Source]
For Environments on Windows 8+ and Server 2012
Research and consider using the Protected Users Group on Server 2012. Users added to this group would have the following settings:
- NTLM would be forbidden. Account must use Kerberos or a third party SSP
- Windows Digest (reversibly encrypted credentials) is not cached
- Kerberos Ticket Granting Ticket (TGT) would have a shortened lifetime of 4 hours vs. 10 hours
Research and consider protecting the LSASS process:
Windows 8.1 introduces a new security feature that allows the user to mark LSASS as a protected process. Protected processes enforce greater access control and limit the available interactions from non-protected processes. When a process is protected only code signed by Microsoft may read its memory (even if the user has administrator or system rights). [Source]
The list of best practices mentioned above should do well in thwarting any of the aforementioned attacks if implemented in a network. Remember a network is not secure by how many products one purchases but the process. Be sure to create a network with defense in depth philosophy to reduce the chances of being compromised. That's all for now, if I missed anything feel free to sound off in the comment section below! Thank you!
Reddit /r/netsec and /r/sysadmin users (thank you for all the great comments!) https://support.microsoft.com/en-us/kb/172931 https://support.microsoft.com/en-us/kb/299656 https://technet.microsoft.com/en-us/library/Hh994565.aspx https://web.archive.org/web/20090311005403/http://www.beyondtrust.com/company/pressreleases/03Feb2009.aspx https://technet.microsoft.com/en-us/library/Dd277362.aspx https://www.nsa.gov/ia/_files/app/Reducing_the_Effectiveness_of_Pass-the-Hash.pdf https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_LimitingWtWCommunication_Web.pdf http://www.cisco.com/c/en/us/tech/lan-switching/private-vlans-pvlans-promiscuous-isolated-community/index.html http://info.ornl.gov/events/nlit09/Presentations/Pritecting%20operational%20division%20networks-Christopher%20Poetzel.pptx http://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating%20Pass-the-Hash%20(PtH)%20Attacks%20and%20Other%20Credential%20Theft%20Techniques_English.pdf https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_LimitingWtWCommunication_Web.pdf https://technet.microsoft.com/en-us/library/Dn408187.aspx