Search
Close this search box.

How to Spot and Stop Active Directory Attacks Faster

Jon Belanger
Jon Belanger

Active Directory (AD) attack can happen fast. You must be faster. Once the attacker assumes an AD user account, your chances of finding them dwindles. They can gain widespread access – even that of an administrator. They can move through systems undetected and execute code as if they were the assumed user. By the time you realize something is wrong, it is often too late; the damage is done. The attacker has exfiltrated data, infected systems, or detonated ransomware. You’re left to clean up the mess.

In this blog, we will show how, through network monitoring, you can catch attackers who target Active Directory environments. The best detection techniques catch attackers in the earliest stage possible while reducing false positives. For that reason, we will focus here on catching attackers during the Reconnaissance stage, which is an early part of any attack.

LDAP Reconnaissance

By default, any normal AD user in a domain has LDAP read permissions for that domain.
Thus, an attacker who compromises a domain user (a user who is not a member of a high privileged group such as domain admins) will be able to perform domain reconnaissance for mapping the domain objects. Reconnaissance is a key part of any AD attack, as it allows the attacker to map the victim’s environment. They can then use that intelligence for lateral movement and privilege escalation. We will focus on the following LDAP attributes to catch attacker in the reconnaissance stage:

UserAccountControl

The UserAccountControl attribute within AD specifies the configuration of specific account settings. For example: UserAccountControl can indicate disabled accounts or accounts that do not require Kerberos pre-authentication when logging in.

The following list contains all the possible options for UserAccountControl:

List of possible options for UserAccountControl
Image Source: Microsoft

We will focus on LDAP queries where attackers look for the following UserAccountControl flags:
PASSWD_NOTREQD, DONT_REQ_PREAUTH, TRUSTED_FOR_DELEGATION, ENCRYPTED_TEXT_PWD_ALLOWED.

PASSWD_NOTREQD

When an AD user account has the PASSWD_NOTREQD flag, the account can have an empty password. Attackers will look for those accounts to try without a password. The attacker’s goals are to move laterally on the domain and compromise domain accounts. The faster they can achieve that objective, the less likely it is that they’ll be detected at this early stage of attack. Logging into these types of AD accounts accelerates the time to infiltration by eliminating the need to discover an account password.

We will flag the following LDAP query as suspicious:

Suspicious LDAP query

DONT_REQ_PREAUTH

When an AD user account has DONT_REQ_PREAUTH flag, the attacker can ask for an encrypted Ticket Granting Ticket (TGT) for the user without providing a password. The TGT is signed with the target user password, allowing the attacker to try brute forcing the password offline. This type of attack is known as ‘As-Rep Roasting’ (MITRE T1558.004).

We will flag the following LDAP query as suspicious:

Suspicious LDAP query

TRUSTED_FOR_DELEGATION

When an AD computer account has the TRUSTED_FOR_DELEGATION flag set, the computer will save the Ticket Granting Ticket(. An attacker who manages to compromise the computer account will be able to dump KERBEROS TGT tickets for all logged-on users. The attack is known as . In addition, attackers can use various techniques to force authentication to the victim computer account, for dumping the KERBEROS TGT tickets later.

We will flag the following LDAP query as suspicious:

Suspicious LDAP query

ENCRYPTED_TEXT_PWD_ALLOWED

When an AD user account has the ENCRYPTED_TEXT_PWD_ALLOWED flag set, an attacker who compromises the AD database gains read access to the user account password in a clear text. Typically, these passwords would appear in an NTLM hash format. The clear-text access accelerates an attack by eliminating the need to brute force the password.

We will flag the following LDAP query as suspicious:

Suspicious LDAP query

Service Principal Name
Service Account

A service account is an AD user account created to run a specific service or application.
For example, if a SQL service needs access to resources over the domain, a service account with the right access to the resources can be created and used by the service.

AD uses the service principal name (SPN) attribute to differentiate between different services.
Every service account will have an SPN defined representing the specific service it was created for.

KERBEROS Service Tickets

Upon Kerberos authentication, any logged-in user can request the Kerberos domain controller (KDC) for access to any service on the domain. The service is identified by SPN.
When an account asks for access to a service on the domain, the KDC returns a service ticket to the client. The service ticket is encrypted with the password hash of the requested domain object hosting the service. For example, when connecting using SSH to a domain computer, the service ticket is encrypted with the domain computer hash hosting the SSH service. An attacker who receives the service ticket can attempt to brute force the hashed password offline.

The password of a machine account is set randomly with a length of 120 characters, whereas passwords of user accounts are usually shorter and often follow predictable patterns. This makes a brute force attempt on a user password faster and easier than trying to crack a machine account password.

KERBEROASTING ATTACK

The fact that service account has SPN configured, and the fact that any logged-on user can ask for a service ticket in the domain, allowing an attacker who compromise a low privileged domain user to search for service users, ask for a service ticket for them and brute force their password offline. The attack is known as ‘KERBEROASTING’ (MITRE T1558.003)

An example for a suspicious LDAP query:
Suspicious LDAP query

Clear Text Passwords

The following LDAP attributes may contain passwords in clear text:

UnixUserPassword

UnixUserPassword is an LDAP attribute for UNIX based systems. Attacker can enumerate the domain for users with  UnixUserPassword configured, as it might be saved in a clear text format.

An example for suspicious LDAP query:
Suspicious LDAP query

Description
Poorly configured Active Directory environment may contain password in the description:

Active Directory Contained Password

We will flag LDAP queries who look for password in description, for example:

LDAP Query to look password

LDAP Query to look password

NT-Security-Descriptor

Active Directory uses access control list (ACL) for accounts authorizations.

ACL Authorization

Knowing the ACLs of accounts in AD will allow attackers to plan their attack for lateral movement and privilege escalation on the domain. , an open-source tool, is using ACL analysis for mapping the possible attacks on a given domain:

ACL analysis for mapping attacks on domains

AD saves the ACL of an object in ’nTSecurityDescriptor’ LDAP attribute.

The ’nTSecurityDescriptor’ is divided to 4 parts:

  • Owner – The owner of the object
  • Group SID (Security identifier) – The group associated with the object
  • DACL- Allow/Deny list for the object:

DACL- Allow/Deny list for the object

  • SACL- Auditing permissions for the object:

SACL - Auditing permission for objects

    • An attacker who compromises a low privileged AD user will not have permission to the SACL part of the security descriptor. The DACL is the most important part of the descriptor, from the attacker perspective, as it identifies authorized actions the object can perform within the domain. To get the DACL part on the security descriptor using LDAP, the attacker must specify what part of the descriptor they are interested in. LDAP uses a control named ’LDAP_SERVER_SD_FLAGS_OID’ that controls which part of the descriptor can be retrieved.

The following flags describe the different possible descriptors:

Bit Flag Name, Value and Description
Image Credit: Microsoft

To catch attacker who performs ACL analysis using LDAP, we will monitor requests for the nTSecurityDescriptor object with one of LDAP_SERVER_SD_FLAGS_OID. For example, we can identify an attacker who asks for the DACL only:

ACL analysis using LDAP

Conclusion

Threat actors continually innovate, creating new and novel techniques to gain access to confidential information. Reconnaissance is a key part of any Active Directory attack. Without mapping AD objects and their connections, the attackers will find it difficult to compromise the domain. Applying detection rules helps catch the attackers early on before any damage is done. To keep your organization safe, ensure your systems are up to date, and that you have installed an automated detection system, such as Fidelis Elevate, to proactively defend against cyber-threats and active attacks.

Subscribe to the Threat Geek blog for the latest updates, threat research, and industry insights from the professionals at Fidelis Security. To see first-hand how the Fidelis Security platforms help security teams worldwide protect, detect, respond, and neutralize even the most advanced cyber adversaries across network, endpoints, and cloud, schedule a demo now.

About Author

Share this post

Get Started

See Fidelis Security platforms in action. Learn how our fast scalable platforms provide full visibility, deep insights, and rapid response to help security teams worldwide protect, detect, respond, and neutralize against advanced cyber adversaries.

Threat Geek

Related Posts