Excellium services newsletter October 2018 The Ghosts in the Forest, part I

The Cyber Kill Chain, developed by Lockheed Martin, is probably the intrusion-based framework the most referred by cyber security players when it comes to describe 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 story telling reports. Blue teams, on the other hand, will focus on each steps of the Kill Chain to implement specific counter-measures in an attempt to detect, thwart or at least slow down attacks at its different stages.

by adidionxlm

Excellium services newsletter October 2018 The Ghosts in the Forest, part I

The Cyber Kill Chain, developed by Lockheed Martin, is probably the intrusion-based framework the most referred by cyber security players when it comes to describe 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 story telling reports. Blue teams, on the other hand, will focus on each steps of the Kill Chain to implement specific counter-measures in an attempt to detect, thwart or at least slow down attacks at its different stages.

by adidionxlm

by adidionxlm

The Cyber Kill Chain, developed by Lockheed Martin, is probably the intrusion-based framework the most referred by cyber security players when it comes to describe 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 story telling reports. Blue teams, on the other hand, will focus on each steps of the Kill Chain to implement specific counter-measures in an attempt to detect, thwart or at least slow down attacks at its different stages.

Introduction

The Cyber Kill Chain, developed by Lockheed Martin, is probably the intrusion-based framework the most referred by cyber security players when it comes to describe 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 story telling reports. Blue teams, on the other hand, will focus on each steps of the Kill Chain to implement specific counter-measures in an attempt to detect, thwart or at least slow down attacks at its 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 a 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 request 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 securable object, which means they 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 to 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 group 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 kind of container are used to group objects together. For example, people can be grouped by department, or geographical location. One of this 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

Even if multiple factor authentication becomes more popular and more implemented, passwords remain most of the time, the unique mean used to prove user authentication. Coveted by the attackers since this is a key to everything, it should therefore be handled securely.
A password audit gives an effective measure of the security of the passwords and the possible password policy improvement. However, weak passwords cannot be easily solved only by a technical countermeasure. It requires both a policy hardening but also user awareness. In order to change the user perception of a good password, you have to explain them what weakens the security of their password. They will often be very implied in such trainings as it also applies to their personal digital life, outside their work environment.

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 users, 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, theKRBTGT. The DC will use this account password hash to create and encrypt tickets for the users.
Similarly, when a user need to access a network service in the domain, another request will be sent to the DC with the initial ticket. The DC will validates 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

 

ne of the main issue 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 lead 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 way to keep persistence in Active Directory, but there are ways to detect them, and the changing the KRBTGT account’s password regularly is a proven method to invalidate them.

 

Silver tickets

 

Prior to have 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 is called silver tickets to gain access to remote services or account. 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 accounts 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.

Top