Active Directory: Protecting the crown gems I

This month, I have been working on getting better defenses for Active Directory. I was surprise when some of these tools and configuration changes weren’t applied earlier, taking into consideration the effort it takes and the benefit it gives. In this blog, I will write about the importance of Active Directory for security, configuration changes from inside Active Directory, configuration changes using other tools and some tools to assess your security.

• Active Directory: the crown gems
• Configuration changes
• Tools for configuration changes
• Assessing and correcting

Active Directory: the crown gems

Active Directory, in a great part of business, is used to store configuration and objects that help user access resources on an environment. This is manage using domains, forests, that help organize the objects. Thus, it helps use set policies for our users, like passwords requirements, access permissions, privileges, and others. In case of computer objects, it can deploy software or scripts, logging capabilities, access policies, etc.

Lets imaging that an attacker manage to get access to our domain and manage to get domain admin privileges, this would be catastrophic. The attacker could delete users like the security team to make them unable to do their job, he/she could deploy a custom script to deploy ransomware in all the domain, he/she could disable the AV or other security tools, etc. The first case is something that LAPSU$ said on their telegram chat and that make me worry of the consequences of losing control over Active Directory, and the second is something some ATPs have done before.

We can realize that Active Directory is the crown gems, and we want to protect this as good as we can. Luckily we can strengthen our defenses with little money (yeah, budget can be problematic).

Configuration changes

Passwords - Yes good old passwords

A basic but powerful change is the password requirements, but if we are not careful we can bring our users to use weak passwords. For instance, if we put a password length of 20 characters, users will most likely forget their password and write it on a piece of paper. I recommend a password of at least 10 characters for groups of users without privileges, 15 for administrator accounts, 20 for service accounts.

We can accomplish this using Fine Grained Password Policies, here is a little tutorial. For these changes you will need to put the precedence of users without privileges on a high number, for administrator accounts 20 or less I believe is ok and for service accounts 5 or less. Sometime, this password lengths can be overwhelming for some users, find a middle point, but remind that this is a risk they are taking.

This change will force users to change their usual behavior, but won’t prevent users to input weak passwords. For instance, let’s say we work at an energy plant, I can sure you that some users will put Energy2022$ as their password or maybe Company2022#. These are the type of passwords the attackers will use against you when trying to get initial access.

For this, I will write about another tool on a next blog that will help you show the state of passwords on your AD environment.

LAPS - Local Administrator Password Administrator

LAPS solves the problem of having weak local administrator passwords, this is a excellent blog that explain the problem and gives other advice. Another good resource that will guide you for almost all the setup is this Microsoft blog.

Hey, before you start I would recommend disable the local Administrator and Guest account as this will be targeted by some automated scripts. This will give you a little advantage, and you can personalize a local admin account, for instance to a name or some random characters. Remember that this account has to have the same name on all computers.

Before, disabling the accounts, I consider that it is better to create the new local administrator account on your domain. You can do this using the following script, remember to change the accountName, accountFullName and accountComment. I’ve removed some lines as we are going to disable the accounts using GPO.

# The name of the account
$accountName = 'LocalAdmin'
$accountFullName = 'Local Administrator'
$accountComment = 'Backup Local Administrator Account'

# Set up some Event Log stuff
$sourceName = "$($MyInvocation.MyCommand.Name).ps1"
New-EventLog –LogName Application –Source "$sourceName" –ErrorAction SilentlyContinue –WarningAction SilentlyContinue

# If the account already exists, exit
if ((Get-WmiObject Win32_UserAccount –filter "domain = '$Env:COMPUTERNAME' and Name = '$accountName'") -ne $null) { 
    Write-EventLog –LogName Application –Source $sourceName –EntryType Information –EventId 1 –Message "$accountName already exists" –ErrorAction SilentlyContinue –WarningAction SilentlyContinue
    exit
    }

# Create the account
cmd.exe /c "net user $accountName `"$([guid]::NewGuid().guid)`" /add /y /comment:`"$accountComment`" /fullname:`"$accountFullName`""

# Add the account to the Administrators group
cmd.exe /c "net localgroup Administrators $accountName /add"

# Try and write an event to the Event Log
Write-EventLog –LogName Application –Source $sourceName –EntryType Information –EventId 2 –Message "Created local administrator account: $accountName" –ErrorAction SilentlyContinue –WarningAction SilentlyContinue

To disable this accounts using a GPO, configure using: Computer Policy > Windows Settings > Security Settings > Local policies > Security Options > Accounts: Administrator account status setting and Accounts: Guest Account Status. Enable the policy and disable the account.

Now you can go ahead and deploy LAPS, use 15 or more characters for the password and 30 days or less for the age of the password.

USB the spread of chaos

I hate USBs, this small devices can cause a lot of pain as we don’t know what they are carrying. If you work on a more modern company and your company doesn’t use USBs you can disable this and avoid this problem. Users won’t be able to use removable media, so infected devices won’t connect to your infrastructure.

You can disable using GPO: User Configuration > Policies > Administrative Templates > System > Removable Storage Access > All removable storage classes: Deny all accesses. Now you are a little safer than before.

Just a little anecdote. When I started to work, an alert from our antivirus pop on my mail at 3 AM. I didn’t notice, as this was just one alert. I continue sleeping as new alerts started to pop up on my phone, and so I decided to take a look. All the alerts said basically the same: Virus was blocked. Over 15 alerts of this, all from the same computer.

The file was ImportantStuff.doc.exe [Redacted] well, this show me that the user was attempting to open a file that hide as a Word document. On further analysis I discover that the complete path was E:\External\Documents\ I got a copy of the file and started analyzing it, it was a worm that started to replace all files with a payload and the user was executing this worm because the file didn’t open.

Then, what happened? The user needed to print some files, use a public printer, and the USB got infected. Well, we contained and eradicated/re-image. This could have been avoided if we had the GPO in place.

I think this is a great start, but there are a lot more of changes you can do. Like disabling NTLM if you run a modern environment, disabling interactive logons for service accounts, enabling audit policies, etc. The main point of this blog is to say: “There is a lot to do, if you look a little on your environment you will find things that can be done better.”