In the first two parts of this series, we covered how attackers may attempt to gain persistence in Active Directory by forging Kerberos tickets or through domain replication abuse, and also discussed strategies to detect these methods. In this part, we’ll touch on a few more techniques: AdminSDHolder and SDProp abuse, SID History attacks, and skeleton key attacks.
AdminSDHolder Container and SDProp Abuse
The AdminSDHolder container exists in every Active Directory domain as a template to copy reconfigured permissions to protected objects, such as domain admins, administrators, enterprise admin groups, or the KRBTGT account. The access control list (ACL) of these objects, which is very restricted, will be replicated to each protected object every 60 minutes by a process called Security Descriptor Propagator, or SDProp for short.
Attackers may attempt to modify the access control list, leveraging their gained domain admin privileges to add full control privilege over protected groups to their domain accounts. From there, they could then wait for SDProp to be triggered and obtain on-demand domain admin privileges. Blue teamers won't be able to detect this strategy and uncover its root cause if they do not see the change being made to the AdminSDHolder's ACL. Luckily, monitoring audit event 4662, which indicates when an operation was performed on an object, enables security teams to detect modifications to the AdminSDHolder object.
Impatient attackers unwilling to wait for the scheduled execution of SDProp may instead manually trigger the process. They will quickly pay for acting hastily, as the execution of SDProp out of sequence can be easily detected by monitoring the audit event 4780, which indicates that the ACL was set on accounts which are members of administrator groups.
The images above show what may occur if monitoring operators are unaware of this persistent technique. An operator would only see that a user is being added to a privileged group, in this case, the Domain Admin groups. While they may later request for this to be reverted, they will likely assume the event is benign, and will not investigate any further.
However, now that your operators know about this attack, they will know to start examining other events, such as the one shown above, to detect the modification of the AdminSDHolder's ACL and identify the offending accounts. In this case, the account is in the subject field, which is the administrator domain account.
SIDHistory Attribute Abuse
Security identifier history is an attribute of every domain account that tracks previous membership to other domains. For example, if a user was a member of domain B and was then migrated to domain A, the security identifier of the user in domain B would then be added to the SIDHistory field of the migrated account. Then, if the migrated account requested access to a resource in domain B, access would be granted as long as it has the correct identifier in the SIDHistory attribute. This behavior is not only valid in an inter-domain setup, but also within the same domain. So, if a user is able to inject a domain admin security identifier within their own SIDHistory field, these privileges will be honored during access evaluation, in spite of their actual group membership.
Going one step further, if a user account includes the SID of an enterprise admin of another domain in the same forest, this will grant the user with admin rights on that domain as well. This doesn't work at the inter-forest level because of SID filtering, which is a feature created specifically to prevent this kind of attack. This feature is enabled by default, although it does have the option of being disabled.
An attacker that successfully gains domain admin privileges would be able to add any target account's SID to the SIDHistory field of another account and grant it with the same privileges as the target account. This can be tricky to pull off, as it requires modifying the domain database. In order to execute such an attack, threat actors would need to patch the NTDS file, which is locked in the domain controller at all times. This operation can only be done by patching this file in the domain controller itself. Such a modification can be easily detected by monitoring both audit event 4765, which indicates that SIDHistory was added to an account, as well as all the other events triggered by the attacker logging into a domain controller.
However, it is possible for an attacker to leverage DCShadow, a technique we discussed in part two, to propagate this change from their machine to the real domain controller in the environment. In this case, a monitoring operator may see events associated to the registration of the rogue DC, but no traces will be left of the SIDHistory attribute modification itself.
The above image shows how an attacker can use Mimikatz to prepare the changes they desire to replicate into the domain database, in this case, the addition of the SID for the Domain Admin group to a regular user.
Next, the attacker would push it to the domain controller, as can be seen above. Such an action won't produce any event associated to the modification of the SIDHistory attribute for the affected user account. Instead, there would only be logs related to the registration and deletion of the rogue domain controller.
Skeleton Key Attacks
Lastly, the skeleton key attack consists of injecting a master password in the LSASS process memory space of a domain controller, which could then be used to authenticate as an end user in the domain. A major drawback is that it requires the injection of the skeleton key in every domain controller in order for the attack to be reliable. Additionally, this technique is not particularly sneaky these days, as there are now many third-party products that monitor and prevent process injection to LSASS.
However, if an attacker did manage to pull off the injection, it could be detected by monitoring for the 4673 and 4611 events, which are both LSASS-related. Event 4673 indicates that a privileged service was called, and event 4611 indicates that a trusted logon process has been registered with the Local Security Authority. In the image above, we can see an example of the event 4673 event, triggered when an attacker logged into a domain controller and executed this attack. We can see clear indication of the privilege, the lsass.exe process, being tampered with.
Now that we’ve looked at multiple techniques that attackers may use to gain persistence, we have a better idea of what to look out for and precautionary measures we can take. In our last part of the series, we’ll conclude with some final thoughts and advice on how to ensure you can swiftly detect an attacker, before they can cause real damage.
Learn More About Active Directory Attacks
Find out how attackers initially breach Active Directory, and strategies on how to prevent it from happening to your organization in our first Getting Inside the Mind of an Attacker series.
