Excellium Services Newsletter December 2018 The Ghosts in the Forest, part III

Finally, it is time to open the final chapter of this newsletter about persistence in Active Directory. In the first two parts, we have focused mainly on attacks against Windows authentication. This last part covers some of the various ways in which the attackers can abuse legit tools to persist undiscovered inside your infrastructure. We will also describe methods used to steal the Domain Controllers data, and take a detour on the way out of the Forest to have one last look at the Securable Objects and their Access Control Lists.

by adidionxlm

Excellium Services Newsletter December 2018 The Ghosts in the Forest, part III

Finally, it is time to open the final chapter of this newsletter about persistence in Active Directory. In the first two parts, we have focused mainly on attacks against Windows authentication. This last part covers some of the various ways in which the attackers can abuse legit tools to persist undiscovered inside your infrastructure. We will also describe methods used to steal the Domain Controllers data, and take a detour on the way out of the Forest to have one last look at the Securable Objects and their Access Control Lists.

by adidionxlm

by adidionxlm

Finally, it is time to open the final chapter of this newsletter about persistence in Active Directory. In the first two parts, we have focused mainly on attacks against Windows authentication. This last part covers some of the various ways in which the attackers can abuse legit tools to persist undiscovered inside your infrastructure. We will also describe methods used to steal the Domain Controllers data, and take a detour on the way out of the Forest to have one last look at the Securable Objects and their Access Control Lists.

Introduction

Finally, it is time to open the final chapter of this newsletter about persistence in Active Directory. In the first two parts, we have focused mainly on attacks against Windows authentication. This last part covers some of the various ways in which the attackers can abuse legit tools to persist undiscovered inside your infrastructure. We will also describe methods used to steal the Domain Controllers data, and take a detour on the way out of the Forest to have one last look at the Securable Objects and their Access Control Lists.

Group Policy – One GPO to rule them all

Managing an Active Directory Forest is a challenging task. The older the company is, the wilder it can become if domain administrators are not careful about it. There are hundreds to thousands of objects to manage between user and service accounts, workstations, servers, each with its own settings. Without a common way to manage them, it would be a real conundrum to keep track of all them.
The tech-savvy among our readers already know that administrators rely on Group Policy to assist them during their daily tasks, a feature that allows centralized management and configuration of Active Directory objects. These policies, stored as Group Policy Objects (GPO) on the Domain Controllers, make it possible for the administrators to schedule tasks or push software on servers or workstations, configure security settings or modify groups… An attacker with sufficient permissions can exploit these same functionalities to achieve persistence.

Constrained delegations – And in the Forest bind them

Let’s backtrack a bit and take a closer look on delegations. In the previous chapter, we described this mechanism in Windows that allows objects in the domain to impersonate others. Our example, based on an unconstrained delegation, showed that if an attacker manages to compromise the server, it will take only a little patience or a bit of social engineering to steal a domain administrator token and recover access to the domain with full privileges.
Obviously, it did not take long for Microsoft to realize that this might not be the most secure way to achieve a smooth integration of services. Hence, constrained delegations were introduced, with which the target account is only trusted for delegation for the specified services. As far as the domain administrators are concerned, the concept seems safe and sound, as they are the only ones able to configure constrained delegations, thanks to a user right that exists in the Default Domain Controllers GPO,SeEnableDelegationPrivilege.
Now think of a group of attackers who want to retain persistence, without being a member of the domain administrators group. If they have full control over the account, one option would be to modify the GPO mentioned above, and when the time is right for them, trust this account for delegation to a sensitive service. They can then impersonate anyone in the domain, including administrators, and compromise it at will.

Windows native tools – Blending in the woodwork

In order to retain persistence, attackers will attempt to minimize their footprints. Each modified file, each executed command might leave forensic evidences. Sooner rather than later, skilled defendants might follow these breadcrumbs and come down on the attackers. There is always the possibility for them to work from memory only, but it is an altogether different matter. Besides, it does not bode well for maintaining persistence, as the whole setup would be at the mercy of a casual reboot.
Facing this dilemma, attackers took up the challenge and came up with new tactics based on fileless malwares. Before diving into some of these most recent threats, we need to clarify this concept. Originally,fileless malwares were indeed referring to code existing only within the memory of the target computers. From a forensic perspective however, it is slowing gaining new interpretations, as attackers manage to abuse Windows built-in components to piggyback their malicious code.

Windows registry – Harvesting hives

The most prominent one being the registry, a hierarchical “database in which applications and system components store and retrieve configuration data”. The registry is a core component of Windows, with many services relying on it. Its database, structured in a tree format, loads its branches during startup from several binary files called hives. Among the interesting data that you can find in these hives is the hash for the machine’s computer account, which can be used to create Silver Tickets.
By modifying registry keys, an attacker with standard user permissions can have commands executedwhenever a user logs in. If the attacker gained local administrator rights, a backdoor can be installed with system privileges. And if, as in the case we are addressing here, the attacker managed to obtain domain administrators rights, the domain can remain compromised.
Now, this attack vector is well known and there are various tools that can help you detect and mitigatethese threats, especially if the final payload is an external binary or a red-flagged one such as PowerShell. However, by using binaries signed by Microsoft, attackers can stay inconspicuous and make it harder for the defendants to detect persistence.

Windows Management Instrumentation – Singing lullabies

Windows provides a built-in administrative framework to manage workstations and servers, Windows Management Instrumentation. For the attackers, WMI is a powerful tool to leverage during reconnaissance, lateral movement, code execution and persistence, especially as it benefits from two protocols for remote interaction, Distributed Component Object Model (DCOM) and Windows Remote Management (WinRM).
The concepts behind WMI are complex, but suffice to say that it comes with a dedicated repository in which the attacker can hide payloads, and it has the capability to react to Windows events. Which means that with some efforts, it can even serve as an agentless Remote Access Trojan (RAT). Cherry on the Christmas cake, amongst all the objects manageable through WMI is the Windows registry itself.
Furthermore, administrators are not always aware that WMI can be weaponized, even though it is already used in the wild for quite some time now (think Stuxnet or SeaDaddy for example) and is becoming more and more popular. Another reason for this fondness is that from the defendant’s side, it might be particularly hard to recognize a legitimate use from a malicious one. The usual detection patterns, such as which components execute payloads, are turned upside down when WMI is involved.

Shadow copy – Walking through twilight

The Volume Shadow Copy Service (VSS) allows administrators to make a backup of computer files or entire volumes even when they are in use, otherwise called shadow copies.
The VShadow command-line tool can manipulate those copies. Unfortunately for the attackers, it does not come preinstalled, though, due to its usefulness, it is not rare to find it present, especially on Domain Controllers. Even if it is not already installed, it is just a matter of downloading it manually on the target, which should not raise too many eyebrows, as it is a signed Microsoft binary.
Now VShadow can be used in two ways to retain persistence on a domain. The first one is pretty straightforward, and consists of exporting a backup of the Domain Controller data, which, if you remember the first episode of this newsletter series, contains all the password hashes of the directory. Including the KRBTGT account hash, therefore opening the way to Golden tickets generation.
The second persistence method relies on the not-so-common knowledge that VShadow can also execute other commands. Combined with Windows registry exploitation, it is possible to launch malicious payloads from a signed binary, hence avoid detection if the administrators do not take extra care.
There is another less known utility, diskshadow, which offers the same functionalities than VShadow, but with two immense advantages. For one, it is actually included starting from Windows Server 2008, so there will be even less forensic evidences on a compromised host. And it supports a scriptable mode, making it more versatile for an attacker.

DACLs – The skeleton keys to the kingdom

From the beginning of this series of unfortunate events, we have made two assumptions. First that at some point the attackers have obtained domain administrator privileges. And secondly, what they want by establishing persistence is to obtain the same rights at will. In the mind of defendants, it often comes down to attackers regaining access to a domain administrator account to commit their misdeeds. There are, however, more subtle ways to perform actions normally restricted to high privileges accounts, and the definition of what an administrator is cannot be summarized with group membership anymore.
At the heart of Windows permissions are the securable objects, which we briefly covered in the first chapter of this trilogy. These objects can be files, processes, but also registry keys, or GPOs. Each securable objects has a security descriptor that can include security information, such as a Security IDentifier, which offers a way to backdoor the Active Directory infrastructure by abusing the SID history.
The security descriptor can also contain a Discretionary Access Control List (DACL, /dˈækəl/), that specifies the access rights granted or denied to particular users or groups. The emphasis on can is important here, because if a Windows object does not have a DACL, the system allows everyone full access to it. On the other hand, an empty DACL grants no access to the object. If the DACL is neither absent nor empty, it contains one or more access control entries (ACEs).
Each ACE allows or denies a security principal, or trustee, specific access to the securable object. In this context, a trustee can be a user, a group, or even a logon session identified by an access token, and the permissions include either read, write, execute, or any other extended rights.
To add to the fun, ACEs are inheritable. Think, for example, of the permissions granted to users or groups in respect of a directory, inherited by all its subfolders. The order in which ACEs are evaluated goes as follow, and the system will stop at the first match:

  • First, any explicit deny is evaluated
  • Followed by explicit allow
  • Then, inherited deny
  • Lastly, inherited allow

The resulting permissions once the evaluation has been done are called the effective permissions. If the operating system can deal with them easily, they are excessively hard to audit on an entire host, let alone on a whole Active Directory, which is why they are potentially the most dangerous vector when it comes to persistence.
Armed with this knowledge, it is time to wraps things together. The premises are the same as usual, the attackers managed to gain domain administrator privileges. They now want to achieve persistence, using one of the previous mentioned method. Abusing Group Policies for example.
There is no real need to have domain administrator privileges to modify a GPO, the only requirement is to have the correct ACE set in the DACL of the target objects, so they can just add a one for a standard user they control, which can be used later to modify the domain policies without being administrator.
They might also want to exploit the Remote Registry, a service started by default on Windows Server, which allows remote interaction with the registry. A carefully crafted ACE set on the right key on a server will allow the same standard user to access its registry remotely. Even better, why not use a GPO to push this ACE on all Domain Controllers?
As a last treat, the attackers will also grant themselves the possibility to create services remotely on others machines via their puppet user. They simple have to add an ACE to the DACL of the Service Control Manager (SCM) or their targets. Note that they can also add a similar ACE to WinRS and DCOM, and execute WMI remotely.

Rogue DC – The Cheshire katz

It would not be fair to close this newsletter without mentioning one of the favorite post-exploitation tools of red teams and attackers alike, Mimikatz. Especially as two of its features can be used to simulate the behavior of a Domain Controller, syphon its data for later use, or worse, inject new data in the domain.
In an Active Directory Domain, there are usually several domain controllers, and they replicate their data using the Directory Replication Service Remote Protocol (MS-DRSR).The first Mimikatz feature, DCSyncabuses this protocol to get sensitive data from the domain controllers, including the KRBTGT hashes. DCSync can be executed by a standard user, the only requirements being some extended rights added in the user DACL.
The second feature, DCShadow, is a DCSync on steroids, both more subtle and more powerful, as it generates virtually no logs and can modify data. The sets of rights required is different, but again, it is only a matter of setting ACEs in the right DACLs.

Conclusion – A Christmas Carol

Those who have reached the end of this newsletter, and it was not, if you’ll pardon the expression, a walk in the woods, have by now a general idea of the tantamount of work a blue team has to do to protect an Active Directory infrastructure. Also make sure that there is no backdoor, which is actually much harder than searching for a needle in a haystack.
By three times we have explained techniques used by attackers to maintain persistence:

  • The techniques from the past, crude and based on group memberships
  • The present methods currently seen in the wild, targeting Windows authentication
  • New or yet to come attacks, abusing DACLs and therefore so much harder to detect

There is no single answer against these techniques. Blue teams must apply the standard defense in depth practices, but with fast changing paradigms, they also must rethink the way they audit their domains.

We spend a lot of energy at Excellium Services to study these new threats, and build the ad hoc detection and remediation methods. Our expertise is at your service, and we will always be your first call when it comes to IT and security, so do not hesitate to contact us if you need guidance about the topics covered in this series of newsletter.

Credits

Dominique Righetto

Top