The Cyber Kill Chain, developed by Lockheed Martin, is probably the intrusion-based framework the most referred to by cyber security players when it comes to describing the lifecycle of an attack. Red teams will often use it to plan their intrusion attempts and to translate their hit-and-miss in their final storytelling reports. Blue teams, on the other hand, will focus on each step of the Kill Chain to implement specific countermeasures in an attempt to detect, thwart or at least slowdown attacks at their different stages.
Introduction
The Cyber Kill Chain, developed by Lockheed Martin, is probably the intrusion-based framework the most referred to by cyber security players when it comes to describing the lifecycle of an attack. Red teams will often use it to plan their intrusion attempts and to translate their hit-and-miss in their final storytelling reports. Blue teams, on the other hand, will focus on each step of the Kill Chain to implement specific countermeasures in an attempt to detect, thwart or at least slowdown attacks at their different stages.
During the attack lifecycle, intruders will try to establish and then expand their foothold into the targeted organization. In a Windows domain network, their ultimate goal will be to gain enough privileges to compromise the cornerstone of the infrastructure, namely the Active Directory Domain Services (AD DS). This service holds the information about members of the Domain, including their credentials, verifies them and defines their associated access rights. Hence, once the attackers can act as the Domain Administrators, they have access to all the secrets and data of the domain.
In the real world, obtaining Domain Administrator privileges is not the end of the story. The attackers’ mission might be not timebound, so they will need to keep a low profile to avoid detection for an unknown period. Cover their tracks. All while maintaining their foothold and privileges inside the organization. The blue team, in the meantime, might start noticing discrepancies in their systems and open investigations.
This newsletter will delve into popular methods used by attackers to maintain persistence in an Active Directory, some obvious and well known, others more sneaky and difficult to uncover, and the way to counteract them.
The Usual suspects: groups and permissions
Windows permissions
Before looking at some persistence methods used by the attackers, we should take a quick glance over permissions on Windows, and more generally in an Active Directory domain. A good starting point is the notion of securable objects, which can refer for example to a file, a directory, but also a printer, a network share, or even a process. Each securable object is tagged with a security descriptor, which in turn contains at least a unique Security Identifier, the SID, generated at the object creation, and an access control list that specifies the access particular users or groups can have to the object. For example, the ACL of a folder can grant read access to some users or groups, write access to others, and explicitly deny the third population any access to it. But how does that relate to a user asking access to a network share for example?
Each time a user logs on his workstation, the system creates an access token for that user. This token contains the user’s SID, user rights, and the SIDs of the groups for which the user is a member. When a user requests access to a securable object, the system compares the access token to the security descriptor of the object to grant or not access to the object.
Group membership
We mentioned before that once attackers gain access to Domain Administrators level, the next step for them is to ensure they keep these privileges, or at least that they can quickly regain them. A simple way to do that is to grant a user account they control membership to the Domain Administrators group, as this group has the highest privileges over the AD DS. Remember, a group is also a securable object, which means it will need enough privileges to modify its security descriptor. But by being a member of this group, its SID will be added to the user access token, granting the same privileges.
However, as efficient as it might be, it is also too easily detectable. This group is likely to be monitored closely for any new suspicious member, as it should. Attackers might turn to other groups with high enough privileges to temporarily regain administrator access and then drop them shortly after. The following list of groups should also be monitored:
- Administrators
- Account Operators
- Backup Operators
- DS Restore Mode Administrator
- Enterprise Admins
- Schema Admins
- Server Operators
Of course, this does not stop at these few groups. A funny thing with groups is that they can be nested, meaning a group can be a member of another group, and so on. Furthermore, objects in Active Directory are organized in a tree-like structure, and each child can inherit or not its parent permissions. The final permissions affected to an object are called the effective permissions, and from an auditor point, are the only way to be sure of who has access to what in a domain.
AdminSDHolder
We stressed before the importance of closely monitoring some accounts and groups with high privileges. We also know that effective permissions must be considered when looking for suspicious accounts. Luckily, Microsoft has introduced the Protected Accounts and Groups in Active Directory to ensure permissions on these objects will remain consistent, and that even if someone changes them, they will revert to their default values.
The mechanism relies on a specific object in the System container of the domain, “AdminSDHolder”. This object serves as a template of permissions for the protected groups, reapplied regularly on the Domain Controllers. Unfortunately, an attacker with Domain Administrator level can abuse this mechanism to grant himself custom permissions, ensuring that they will persist even if reset by another administrator.
It is therefore mandatory to monitor the ACLs configured on the AdminSDHolder object, and all users and groups protected by it.
SID history
Let’s start exploring the forest a bit further. An instance of Active Directory is called a Forest, and can easily contain ten thousands of objects. To organize this information, several kinds of container are used to group objects together. For example, people can be grouped by department or geographical location. One of these particular container is the Domain, and a feature of Active Directory is the ability to migrate an object from one domain to another, while preserving some of its properties, such as access rights.
Take for example an organization deploying a new Windows infrastructure. To ensure a seamless migration, it is necessary that the users retain their access rights to the old infrastructure, even after they have been moved to the new one. We also know that a user account is associated to a unique SID across the whole Forest, therefore inter domains migration implies the creation of a new object, with a new SID.
To ensure a user will keep its access, Microsoft actually adds the old account’s SID to another attribute of the new account, the SID History. Now an interesting point is that this attribute can also be used in a single domain, without any migration involved. An attacker with enough privileges can inject the SID of a Domain Administrator into his account SID History, and gain administrator privileges without being a member of the Domain Admin group.
Conclusion
The VIP tickets
Windows authentication
As previously mentioned, upon logon, an access ticket is created for the user. To look deeper into that, we have to go back to the AD DS, and its authentication system. We know that it holds the credentials of every user, or more precisely, a transformed form of them called a hash. This service runs on one or several dedicated servers, the Domain Controllers (DC). When a user logs on, the DC is contacted in a secure way to verify his identity and credentials. On each DC exists a very particular account, the KRBTGT. The DC will use this account password hash to create and encrypt tickets for the users.
Similarly, when a user needs to access network service in the domain, another request will be sent to the DC with the initial ticket. The DC will validate the ticket and the request, and issue another encrypted ticket to the user, who will pass it to the service to access it.
Golden tickets
One of the main issues with the KRBTGT account is that the password is rarely ever changed. Actually, unless the administrators decide to roll out a new password, it is quite common to find a password that was never changed since the account’s creation.
The attackers found a clever way to abuse it, the infamous golden tickets: once they manage to obtain the KRBTGT account hash, they have the possibility to forge as many valid initial tickets as wanted. If forged for administrator privileges, it directly leads to open access to any service in the Active Directory. Golden tickets can be created offline, and attackers do not need high privileges to use them. This is one of the most powerful ways to keep persistence in Active Directory, but there are ways to detect them, and changing the KRBTGT account’s password regularly is a proven method to invalidate them.
Silver tickets
Prior to having access to an Active Directory, computers must be “joined” to the domain. That involves the creation of an associated computer account with a randomly generated password. If attackers manage to crack these passwords, they will be able to forge what are called silver tickets to gain access to remote services or accounts. Keep in mind that computer accounts can also be members of groups, some of them might even have administrator privileges, so the risk is real.
To be continued…
This first part was about putting the emphasis on monitoring common vectors such as group memberships and analyzing the effective permissions of every account to determine if there are paths that could lead a standard user to get high privileges.
The next session will be dedicated to other attacks against Kerberos. We will also look at various methods used to steal or inject data from the Domain Controllers, and flip through various legit tools used to maintain persistence in Active Directory.
