BHIS Webcast and Podcast
This post accompanies BHIS’s webcast recorded on August 7, 2018, Active Directory Best Practices to Frustrate Attackers, which you can view below. The podcast version is available here.
Also, the slides are available here: https://blackhillsinformationsecurity.shootproof.com/gallery/7214618/
Active Directory out of the box defaults aren’t enough to keep your network safe. Here’s the word on the street about frustrating attackers in your Active Directory environment.
It’s easy to make things hard. But it’s not hard to make things easy.
Spin that how you will, running Active Directory efficiently isn’t necessarily easy, but it certainly can be easy to make things hard for attackers in your environment. Here are some baseline things you can do to make your Active Directory environment frustrating for attackers. Attackers’ main resource is time, and if you can slow them down and frustrate them, you have a better chance of making attackers look for easier targets or at least more time for your response team to identify and protect your assets.
Remember, don’t do anything in Active Directory without first considering what you are doing.
Play with Active Directory!
Amazon now offers turn-key Active Directory environments that you can build and manipulate configuration and settings to your will. Determine what will and what will not work for your environment by using isolated sandboxes that you can spin up at will.
A few clicks below and a couple of passwords and in an hour you have a functional AD environment running the latest and greatest: https://aws.amazon.com/quickstart/architecture/active-directory-ds/
Naming Conventions & Functions
It’s ironic that we talk about naming conventions while discussing how to frustrate attackers. I might suggest that you should obscure everything, but nay. The efficiency that naming conventions and well thought out plans can bring to your Support Desk and IT Infrastructure groups far outweighs the benefit an attacker will have knowing that security groups start with sec_.
Email Addresses & Usernames
That said, email addresses are a great thing for communication. They are less great for security though when used not only for email delivery but also for usernames. There are multiple ways to go about making email addresses not the same as usernames. I like the idea that usernames are something relatively common and similar to an email address but then tack-on a code only the user themselves need to remember. Example:
Email address: [email protected]
Email username: [email protected]
This will ensure that even if someone does find the email address, any assumption that it is the username would be incorrect. It also means that Sally doesn’t need to know Rick’s username to send him email.
Make groups easy for your Support Team, but be sure to understand the different types of groups in Active Directory and how they all play together. Remember the JUGULAR to assign groups based of common characteristics of employment down to the Access Control Lists (ACL) of a specific resource. Doing this prevents long term legacy problems with abandoned SIDs in ACL’s and data objects with lost owners.
Don’t assign users to resources, assign groups to resources and users to groups!.
Group Policy, File Shares, Printers, and all the rest
Have a well thought out plan on how you name your Group Policies, File Shares, Printers, etc. Remember that according to Jugular, your resources’ ACLs should identify a security group (Domain Local group) which should identify either Universal Groups, Global Groups, or occasionally direct users. Group Policies should be named according to their function. File Shares should indicate a department or contextual information about why the data is important to someone, for example, “Accounting”, “Accounts Receivable”, “Onboarding Forms”, etc. Printers can be named geographically to help users. Printing is always a pain, don’t make it worse by making printers that much harder to find.
Separate User and Admin Accounts
Are you an admin? Operate 99% of your day to day activities with an unprivileged normal-user account. Only use your second account, your admin account, when you need to make administrative changes. Make those changes either from a jump host or limited access system/network where you don’t use your unprivileged account. Or: Use “Run (application) as…” instead of utilizing a full desktop for your admin user. Limiting your admin account to only administrative changes (and not for things like checking email) reduces the exposure of the admin account to the rest of your day-to-day activities and click-happiness.
A few things to remember about Group Policies:
Active Directory Group Policy Defaults are not enough to protect you sufficiently.
- Password Policies (age, length, complexity, etc)
- Account Lockout (attempts, duration, thresholds)
- Windows Firewall/Defender (Future Blog post, lookout!)
GPP & Passwords – Don’t save passwords in Group Policies or Scripts in SysVol
LSD-OU – Remember LSD-OU for Group Policy Application
Other Must Do’s That Frustrate and Slow Down Attackers:
- How and Why you want to Disable LLMNR:
Password Length – more than 15 characters minimum!
- 2016/Win10 1803+: Group Policy Updated to support 20 Character Minimum Password Length
- Pre-2016: How to Increase the Minimum Character Password Length (15+) Policies in Active Directory
LAPS: Local Admin Password Solution!
- Microsoft LAPS Security & Active Directory LAPS Configuration Recon
- Local Administrator Password Solution (LAPS) Now Available
- Implement AppLocker Rules in Windows Server 2016
Enable Host-Based Firewalls
- Windows Defender Firewall with Advanced Security
- Watch out for an upcoming BHIS blog post on Windows Defender & Firewall Best Practices!
Powershell and CMD Restrictions
- Disabling PowerShell with Group Policy
- Been asked to disable PowerShell
Sysmon to Find All the Things
- sysmon-config | A Sysmon configuration file for everybody to fork
Get Rid of Old Sessions!
- Interactive logon: Machine inactivity limit
- Automatic logout after inactivity/idle
Last Minute Things:
- Get a pentest. Scan, Cleanup, Repeat.
Ask [email protected] if you need help.
- Don’t disclose internal network knowledge externally. Not Exchange, not SSL, not Web Services. The more an attacker knows, the more they have to use against you.
- Bitlocker all the things.
- Vera-Crypt the things you can’t.
- Empower Your Support Team/Help Desk. They are your constant out-of-band eyes and ears on network and infrastructure security.
- Train your helpdesk about social engineering, IT security, and hacking in general. Ask them if they were tasked with breaking into your organization, how might they do it. Your helpdesk will tell you exactly where the security flaws are in your Active Directory infrastructure configuration if they are allowed and enabled with the knowledge to identify them.
- Policies and Procedures! Have a process that requires password management requests to contact the employees supervisor or direct report. The supervisor can identify if the password change request is legit. And… making the employee talk to their supervisor might help them remember their password!
For more information, check out the links above or listen to our Webcast/Podcast on Active Directory Best Practices to Frustrate Attackers.