Blue Team Basics: Active Directory Security Assessments

Want to annoy script kiddie hackers who rely on pressing buttons in Mimikatz? Then give this blog post about AD and Windows security basics! We’ll be going over some key techniques for safeguarding your network against common attack vectors, such as privileged account exposures, Pass-the-Ticket (PTT) attacks, and SID injection. We'll also provide some powerful PowerShell commands to help you test for these vulnerabilities and protect your organization from cyber threats. Let's dive in!

 

 

Block the Hack: Keeping Your Network Safe from Privileged, Delegated Admin, Service, and Network Session Enumeration

So, you've got Active Directory (AD), the brain of many organizations' network, storing important information about user accounts, groups, computers, and other network resources. Unfortunately, once an attacker breaches your perimeter defenses and gets a foothold within your network, they can use various techniques to enumerate AD objects and identify those juicy privileged, delegated admin, service, and network sessions.

Privileged accounts, the big shots of user accounts, have more permissions than your average Joe account. Delegated admin accounts have specific permissions to manage resources or perform specific tasks within AD. Service accounts are the go-to for applications and services to run with specific permissions and access network resources. Network sessions are the connections established between different systems on the network.

Now, these attackers can use tools like PingCastle and/or BloodHound (I mean, I definitely do during pentests) to enumerate AD objects and discover the accounts and sessions they want to exploit. But fear not! You can stop them by implementing some techniques, like:

• Implementing strict access controls: Control who has access to AD and limit the query power to only authorized personnel. Use firewalls to restrict inbound and outbound traffic.
   
• Monitoring for suspicious activity: Keep an eye on those AD logs for any funny business, like unusual account activity or excessive failed login attempts.
   
• Deploying deceptive domain accounts: Use honey pots, decoy accounts and credentials to waste their time. 
   
• Using endpoint detection and response (EDR) tools like Defender for Endpoint.
   
• Security information and event management (SIEM) and Security Orchestration, Automation, and Response (SOAR) - and of course I recommend Sentinel.
     

And also try out these PowerShell commands you can use to check for suspicious activity:

Shows you failed login attempts.

Get-EventLog -LogName Security | where {$_.EventID -eq 4625} 

 

And this will show you when a user is granted special privileges.

Get-EventLog -LogName Security | where {$_.EventID -eq 4662} 

 

Find and Secure High-Risk Privileged Accounts

Picture this: users storing their credentials on their workstations, either accidentally or willingly, for the sake of convenience. Attackers are like sharks smelling blood in the water, and they know that those stored credentials can be their ticket to the network environment. They'll try their hardest to escalate their privileges and access further.

That's where privileged account exposures come in. These are vulnerabilities that attackers can use to gain access to sensitive information and resources. But don't worry, you can stop them by identifying and remediating these exposures.

One of the best ways to do this is by conducting regular audits and assessments of your network environment to identify any privileged account exposures. Once you've identified them, you can remediate any misconfigurations and remove any saved credentials, shared folders, and other vulnerabilities that could be used by attackers to gain access.

But it's not just about identifying and remediating these exposures. You also need to take proactive steps to prevent them from happening in the first place. This can include implementing policies that prohibit the use of shared credentials, enforcing strong password policies, and providing regular security awareness training to users.

It's important to remember that privileged account exposures can be a significant threat to your organization's security. By identifying and remediating these vulnerabilities, you can reduce the risk of a security breach and protect your sensitive information and resources from attackers.

With this PowerShell snippet, you can easily find out who has the keys to the kingdom in an AD environment. It checks for users with admin privileges by looking at specific AD groups and lists their names along with the names of the groups they belong to, all laid out neatly in a table.
 

$AdminGroups = "Domain Admins", "Enterprise Admins" # Add additional groups as needed
$AdminUsers = foreach ($Group in $AdminGroups) {
    
    Get-ADGroupMember -Identity $Group |
    Where-Object { $_.objectClass -eq "user" } |

    Select-Object Name, @{Name="AdminGroup"; Expression={$Group}}
}

$AdminUsers | Format-Table

 

This gets a list of who has access to a specific file or folder, then shows all the different permissions given to them. It even filters out the built-in admin and SYSTEM accounts, so you can see if any regular users or groups have access that they shouldn't.

Get-Acl -Path "C:\ExampleFolder" | Select-Object -ExpandProperty Access | Where-Object { $_.IdentityReference -notlike "BUILTIN\Administrators" -and $_.IdentityReference -notlike "NT AUTHORITY\SYSTEM" }

 

Uncover Hidden Threats: Identifying Accounts with Secret Privileged SIDs

Think of attackers like they’re burglars trying to break into your house, but instead of breaking in through the front door, they're sneaking in through the windows. One of the ways they do this is through the Windows Security Identifier (SID) injection technique. By exploiting the SID "history" attribute, they can move laterally within your AD environment, all while remaining undetected. This is like the burglar sneaking through your home, moving from room to room without anyone noticing.

But don't worry, there are ways to protect yourself! Namely by regularly checking out your AD environment for accounts with unexpected SID history attributes. These are the hidden windows that attackers exploit.

Specifically, you should be on the lookout for well-known privileged SIDs like "S-1-5-18" (Local System) or "S-1-5-20" (Network Service). By checking for these vulnerabilities, you can stop attackers from gaining elevated permissions and moving laterally throughout your network. You can do this manually, or with the help of automated tools that scan your network for potentially vulnerable accounts.

For a deeper dive, have a look at these other two posts I wrote:

Security Identifiers (SIDs) and Object Permissions in Windows [Part 1]

Security Identifiers (SIDs) and how to understand them [Part 2]
 

 

AdminSDHolder ACL and Unprivileged Users

Alright, so let's talk about something super important for keeping your network secure: protecting your privileged users and groups in Active Directory. One way to do this is through the AdminSDHolder object, which has a special Access Control List (ACL) that controls who has permission to access certain built-in privileged AD groups. If attackers get access to this object, they can add their own unprivileged accounts and gain the same privileged access as the protected accounts, which is definitely not good. Attackers can exploit this to move laterally within your network, potentially causing major damage. 

Protecting your privileged users and groups is very, very, very important, and the AdminSDHolder object and its ACL are key players in that game. Keep an eye on them, use tools, and make sure only the right people have access to keep your network safe and sound. Like these (replace CN=AdminUser,CN=System,DC=lab,DC=local"  with your details):
 

Lists the security principals that have been granted permissions in the AdminSDHolder object:

Get-Acl -Path "CN=AdminUser,CN=System,DC=lab,DC=local" | Select-Object -ExpandProperty Access
 

This identifies any users or groups that have been added to the AdminSDHolder object's ACL:

Get-Acl -Path "CN=AdminUser,CN=System,DC=lab,DC=local" | Select-Object -ExpandProperty Access | Where-Object {$_.IdentityReference -notmatch "S-5-21"}
 

And this lists all users who are members of any built-in privileged AD groups:

Get-ADGroupMember -Identity "Domain Admins" -Recursive | Get-ADUser | Select-Object -Property SamAccountName, DistinguishedName

 

Defend Against the Notorious "Golden Ticket" and "Silver Ticket" Attacks"

Kerberos is a fancy word for a system that helps keep our computer networks safe. One cool thing about Kerberos is that it doesn't need to remember anything about the people using the network. This makes it easier to use and helps keep things running smoothly. Instead of remembering who you are, Kerberos uses secret codes to make sure you're really you when you ask to use something on the network. 

But now you've got attackers trying to move laterally throughout your network and escalating their privileges using Pass-the-Ticket (PTT) attacks. PTT attacks can be tricky to spot because they don't involve stealing passwords. This means that attackers can remain hidden for long periods of time while they use your credentials to move laterally within your network and do some serious damage.

But don't panic! You can take steps to protect and detect these attacks. It starts with detecting vulnerable Kerberos Ticket Granting Ticket (TGT) and service accounts, as well as probing for misconfigurations that could potentially lead to PTT attacks. 

Golden ticket attacks are when an attacker gets into the authentication data of a Windows domain's Key Distribution Center (KDC) and makes a fake ticket-granting ticket (TGT) that lets them access any service in the domain with top-level access. They don't need a legit password or even a network connection to the domain controller.

Silver ticket attacks are when an attacker gets their hands on the authentication data of a certain service account and creates a fake service ticket that lets them access that particular service with the powers of the hacked account.

And to get you started on probing for these vulnerabilities, here are some PowerShell commands you can use:

This retrieves all Active Directory service accounts and displays their name, distinguished name, and enabled status. It can be used to identify any service accounts that may be vulnerable to PTT attacks.

Get-ADServiceAccount -Filter * | Format-Table Name, DistinguishedName, Enabled
 

Displau the Ticket Granting Ticket (TGT) cache for the current user. When a user logs into a Kerberos-authenticated system, a TGT is issued that serves as a "master key" for accessing network resources. So that means ot can be used to check for any forged tickets that may have been issued by attackers.

klist tgt
  

 

Find all enabled Active Directory user accounts that have a non-expired password and returns their last logon date and password last set date. One use for this is to identify any accounts that may be vulnerable to a password-based attack.

Get-ADUser -Filter "Enabled -eq `$true -and PasswordNeverExpires -eq `$false" -Properties "LastLogonDate", "PasswordLastSet"

 

 

 Oh! And here’s related post you can check out! Credential Guard: Protect Windows from pass-the-hash and pass-the-ticket attacks

 

Identify Unsafe Access Delegation on Critical Objects

Critical objects are the foundation of your AD network. Domain administrator accounts, security groups, and privileged service accounts that provide access to critical resources like LoB apps. The list goes on.

Delegation is a powerful feature in Active Directory that allows one user or computer account to impersonate another. It's a handy feature that makes it easy for users (or service accounts) to access resources hosted on different servers without having to log in multiple times. However, it can also be very, very dangerous.

The problem with delegation is that any domain computer with unconstrained delegation enabled can impersonate user credentials to any other service on the domain. This means that attackers can use delegation to move laterally throughout the network and escalate their privileges, potentially causing significant damage.

With constrained delegation, you are essentially setting up an access control mechanism that only grants permissions to authorized users or computers. This helps ensure that sensitive information is kept secure and only accessible to those who have been granted permission while preventing unauthorized access.

Have a closer look at it in the Active Directory Users and Computers console on the domain controller. Right-click the user or computer account that requires delegation and select "Properties." and you'll see the "Delegation" tab.

In the "Add Services" window, select the specific services or resources to which the account needs access, and then click "OK."

Play around with these commands to view lists of Active Directory objects with unconstrained delegation enabled, 

Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo | Format-Table Name, msDS-AllowedToDelegateTo

Get-ADUser -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo | Format-Table Name, msDS-AllowedToDelegateTo

Get-ADComputer -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo | Format-Table Name, msDS-AllowedToDelegateTo