Self-defense for hackers. Detecting attacks in Active Directory

If an attacker managed to avoid detection at the network level and reached Active Directory with a domain user account, then you’ve lost the first round. Now the intruder can deliver dozens of deadly attacks, and most of them are quite ‘silent’.

At this point, the second (and final!) round of your confrontation begins. The internal infrastructure and, potentially, the entire company’s business are at stake. However, if the domain withstands the simplest exploits that the hacker tries in the first minutes, and the intruder has no choice but to implement ‘noisier’ attacks, then the final battle can still be won.

You will learn to hear barely perceptible noises made by the attacker who has gained a foothold in Active Directory, identified your misconfigs, and started advancing to domain controllers.

Authentication

An attacker whose goal is to capture the heart of your internal infrastructure – Active Directory -inevitably has to deal with domain accounts. In the course of advancement, the hacker can make unsuccessful authentication attempts, enter incorrect or old passwords, or try to brute-force a password.

On the domain controller, you can monitor events 4776 (8004), 4768, or 4769 in a centralized way, but this requires domain admin privileges. By contrast, authentication attempts made by all domain users can be monitored with ordinary user rights (as you remember, all the proposed defense techniques don’t require exclusive rights and can be performed by any employee).

Using LDAP, you can track changes in the lastLogon/lastLogonTimestamp attribute and see the dynamics of successful authentications; changes in the badPasswordTime and badPwdCount attributes reflect the dynamics of unsuccessful authentications; while lockoutTime shows the dynamics of blockings. All you have to do is request in a loop objects whose above-listed attributes have changed within a certain period of time.

The automation below performs all the required operations: the script writes in real time which user has successfully authenticated, which user failed and how many times, and who was locked:

defence/ad/auth.py

Under normal circumstances, it’s no surprise that users sometimes enter their passwords with typos.

In the above screenshot, the first failed authentication is immediately followed by a successful one: the user simply made a typo when entering their password for the first time, but then entered it correctly. However, the second failed authentication looks suspicious because the correct password was never entered.

The badPwdCount attribute shows the number of failed attempts so that you can conclude that somebody is guessing the password for this account.

In the above screenshot, you can see that somebody is trying to brute-force standard account names using a wordlist. Apparently, this is an echo of an attack on the external network perimeter. Services that use domain accounts for authentication can often be located there.

But in the next example, the situation is different: the usernames are definitely not taken from a wordlist.

If the attacker could find out these usernames only after penetrating into the network and connecting to Active Directory, then you can conclude with confidence: you are dealing with an internal intruder. Direct brute-forcing of domain accounts is a very rare phenomenon and, most likely, it’s a consequence of careless attacks.

However, an attacker can only try weakest passwords against a wide range of usernames without being blocked. If your company has a large number of accounts, then the attacker has a chance of success.

Such an attack can be easily detected: from the outside, it looks like a spontaneous burst of failed authentication attempts made by multiple users.

Similar activity can be detected if an attacker finds a valid password and delivers a password spraying attack in the hope that the password would work somewhere else.

In large companies, the flow of authentication events is huge, and it’s quite difficult to monitor it manually. Therefore, you can set up automatic notifications for certain users and certain events.

For instance, you can create a fictitious user so that no one is aware of its existence. Any authentication attempt performed by such a user can be considered an anomaly. Usernames obviously taken from a wordlist (e.g. guest, security, audit, testuser, test1, etc.) that aren’t used by anyone should also be considered an anomaly if they make failed authentication attempts. Finally, under normal circumstances, such standard usernames as administrator and the above-listed ones should never be blocked; otherwise, this also indicates an attack. In auth.py, this logic is described as follows:

Since the script collects the full dynamics of authentication events, it would be great to analyze it somehow. Using standard Python math capabilities, you can easily construct a chart showing trends in successful and failed authentications and blockings:

defence/ad/auth-anal.py

This analysis is as simple as ABC, but the overall picture immediately becomes clear: the company actively operates during business hours; while brute-forcing attacks occur at night time.

However, authentication events are only a small part of what’s going on in Active Directory. Some events and processes are often not monitored even by Security Operations Centers.

Changes in Active Directory objects

Many attacks on the Active Directory infrastructure leave specific traces: respective attributes of objects are created or changed. Almost all such modifications indirectly affect the whenChanged attribute that reflects changes in a given object.

Importantly, the whenChanged attribute is updated even if object’s rights have changed, which makes it possible to detect nearly untraceable ACL attacks. To track the entire dynamics in Active Directory, all you have to do is make a preliminary snapshot of all attributes for all objects, analyze their ACLs, and compare differences in changed objects:

defence/ad/changes.py

This script consists of slightly more than a hundred lines of code. However, you can run it under any (even unprivileged) domain account, and it will monitor in real time what objects were created, deleted, or modified and show what attributes have changed in them, including ACL analysis to present the results in a canonical readable form.

A single script enabling you to see almost all attacks becomes a universal Active Directory monitoring tool.

Attacks targeting users

As attacks progress, the hacker identifies various access rights misconfigs in the Active Directory infrastructure, as well as relay attacks enabling the intruder to perform actions on behalf of another account. Ultimately, such attacks result in numerous harmful actions.

If an attacker has extended rights to a user account, they can change its password – and you’ll see this immediately thanks to the pwdLastSet attribute.

Needless to say, when you monitor password change events, your top priorities are service, admin, and other important accounts.

If the attacker has write access to a user object in Active Directory, they can compromise this account more accurately by adding an arbitrary LogonScript.

And you can track such activity.

Another way to attack a user object is as follows: the attacker adds the servicePrincipalName attribute to the object and delivers a targeted kerberoasting attack to capture that user’s password hash.

In the course of this attack, the script used by the attacker quickly creates an SPN attribute, requests a TGS Kerberos ticket (containing user password hash), and deletes SPN. Accordingly, if you check objects for changes frequently enough, you’ll see the characteristic attributes.

The targetedKerberoast.py script creates and deletes SPN very quickly so that it cannot be detected. However, an attacker can change SPN manually, and the changes.py script will detect such a change.

Attacks on computers

If an attacker has write access to the computer account object, they can use RBCD or Shadow Credentials technique to gain access to the victim’s PC.

This can be detected by the appearance of a specific attribute: msDS-AllowedToActOnBehalfOfOtherIdentity/msDs-KeyCredentialLink.

Under normal conditions, such attributes as Resource Based Constrained Delegation and Shadow Credentials are rarely used in regular domains. Therefore, the appearance of these attributes deserves your close attention.

Attacks on GPO

Finally, attention should be paid to Group Policy Objects. If an attacker compromises such an object, the impact can be catastrophic, especially if this policy applies to many hosts or users.

The most valuable attribute in a group policy is gPCFileSysPath: it points to the folder where an executable script or registry branch can be stored. In any case, a redirection attempt can be detected based on changes in the respective attribute.

Important: an attacker can also compromise a group policy object on the SYSVOL network drive, and you won’t see this.

Attacks on groups

If an attacker manages to gain access to a specific group, they can add an account to that group.

To add an object to a group, the member attribute is used, an you’ll immediately see its appearance.

Changes in membership of domain groups frequently occur in actively used domains. Accordingly, special attention should be paid to critical groups (e.g. Domain Admins, Enterprise Admins, Account Operators, Server Operators, Backup Operators, Print Operators, DnsAdmins, Organization Management, etc.). In most cases, the final stage of internal network attacks involves domain compromise.

A domain admin group compromise is a pretty ‘noisy’ event. A cautious hacker would rather abstain from it. But that doesn’t mean that you shouldn’t monitor such activity.

ACL attacks

ACL attacks are even more difficult to detect. Almost all above-described examples can be consequences of misconfigured access rights (ACL). Such misconfigs can be easily detected with BloodHound, and are often used as invisible paths leading a simple domain user to high-value targets and the domain admin. But are ACL modifications really undetectable? In fact, even slightest changes in rights result in implicit modifications of the whenChanged attribute, which means that the changes.py script can be used to detect them.

Changes in ownership

If an internal attacker has the required rights (GENERIC_ALL, WRITE_OWNER), they can change the owner of an object.

As soon as this happens, object’s nTSecurityDescriptor attribute (that stores all information about rights to that object) is changed. Information contained in it is presented in binary form, but the changes.py script can parse its structure to present the data in a canonical readable form. And you can immediately see suspicious changes.

Changes in ownership aren’t frequent events, and you should pay attention to every such case. But the progress of a real attack rarely stops at this point, and, most likely, something else should happen.

Changes in permissions

If an internal attacker discovers that their permissions make it possible to change permissions (WRITE_DACL) in some object, the hacker can assign the arbitrary code execution (ACE) right to that object. Most often, this involves the delegation of full permissions (GENERIC_ALL) to the object.

In the screenshot below, the internal attacker adds an ACE with the GENERIC_ALL (full access) mask.

In real infrastructures, the path from a user to the domain admin can be very thorny, and I recommend paying attention to changes in ACL of any object if GENERIC_ALL and WRITE_DACL are involved since these access rights have the strongest impact (each in its own situation).

Attacks on ADCS

ADCS security is a separate topic: as many as 15 privilege escalation vectors involve Active Directory Certificate Services. Monitoring of ADCS events is a headache. As a result, many companies simply disable ADCS to be on the safe side.

But if the ADCS configuration is stored in LDAP, then you can monitor changes in it using the same changes.py script. ESC4 is an example of ADCS abuse: an object associated with a certificate template in Active Directory is modified. If a hacker encounters a template with incorrect access rights, they can modify it to make it vulnerable to ESC1.

At the Active Directory level, this is manifested in the addition of new attributes to the attacked object.

And since something has changed in the object, you can detect such an attack.

Generally speaking, this namespace (Configuration) isn’t ‘inhabited’ by users, and nothing changes there by itself. Accordingly, any change in it is a good reason to raise a red flag.

Conclusions

Now you’re aware of sensitive aspects that can be monitored with regular user rights. All you have to do is make special LDAP requests and track changes in certain attributes of Active Directory objects. Just two simple scripts enable you to detect traces of many popular attacks.

An attack delivered by an internal intruder who has reached Active Directory can develop very quickly and require swift reaction. A modern SOC has a fundamental problem: the wide range of events it monitors can significantly slow down analysis and decision-making. But if you know in advance what to pay attention to (i.e. aspects that almost never give false positives), then you can react much faster.

On average, it takes ten steps for a pentester to completely compromise the internal infrastructure. This means that (in theory!) you can detect the attacker ten times and have time to react.

But what if the hacker managed to make it out to their target? In such a situation, you can still do something to make bastard’s life miserable. If an attacker penetrates into your computer, most probably, they are only interested in your password. And you, as a user, can have any passwords, even those containing wildcards and dangerous commands.

If an attacker carelessly inserts a password phrase into the command line, the command ‘hidden’ there would be executed. For example, if you want to stop a hacker, you can try to implement a command that deletes all files on the disk.

In other words, you can implement RCE on the hacker’s host.

A survey conducted among hackers, pentesters, and IT professionals showed that 21% or respondents had occasionally entered incorrect passwords in the command line; as a result, their Kali systems were killed during password reuse attacks. A simple warning was able to stop one hacker out of five. There is no guarantee whether such a trick would work in your case or not, but it definitely won’t make your password weaker. So, even if you have lost both rounds, you still have a chance to deliver a fatality to the hacker.

Good luck!