Detecting An Attacks on Active Directory with Azure
Next year will be 20 years since the creation of the Active Directory directory service. During this time the service has acquired functional, protocols, various clients.
But the need to maintain compatibility with a number of obsolete clients forces you to have default settings that are interoperable. Administrators often do not change them, and this creates a big risk. In this article, we’ll look at detecting attacks that can lead to domain dominance.
What is common between the attacks on Active Directory and Azure? On March 1, 2018, Azure Advanced Threat Protection was released. This service, which is a cloud analog of the local product Advanced Threat Analytics. Unlike the local version, the cloud does not have artificial limitations for machine learning and is updated regularly, like any cloud services. With it, you can detect both typical attacks and abnormal user behavior.
- You can register a trial subscription to get started.
After the initial settings, you will need to download and install the gateway to collect data on all domain controllers in the enterprise network. This completes the configuration.
Now, we propose to consider an example of an attack in the following scenario: an insider employee who has acquired administrator rights on the local machine, plans to increase his privileges in the domain.
To begin with, the employee will need to understand what account he needs to compromise in order to gain privileges in the domain. He is interested in Domain Admins. To discover the Domain Admins members, it makes a request on the command line:
net group “Domain Admins” /domain
Having discovered the users of the group, it is now necessary to find out on which machine there are active sessions of one of the users. Let us dwell on the user trainer.
To discover the sessions, we’ll use the Bloodhound tool known among the pentester tools. As you can see in the diagram, the user trainer has an active session on the W10-notGuarded workstation, which is also available to the attacker.
Let’s go to the Azure ATP portal and see the new warnings. Requests for the discovery of groups and sessions were detected.
Let’s return to the attacker. By connecting to a workstation, an attacker can dump the lsass process using the task manager (or from the command line using procdump). This operation requires a debug privilege.
Having received the dump, the attacker can copy it to his workstation and analyze it with the help of Mimikatz.
Copy the dump into one folder with Mimikatz, run Mimikatz and connect the dump for analysis
Sekurlsa::minidump lsass.dmp
Output the results in a text file
Log
Let’s extract the contents of the dump
Sekurlsa::logonpasswords
By opening the text file Mimikatz.log, you can find the credentials of the user trainer. We are interested in the NTLM hash of the password. The values in the screenshot are hidden for privacy purposes.
The hash operation is irreversible, so you can not extract the password from the hash. If the password was simple, then there is the likelihood of matching through rainbow tables. Suppose that we were unlucky and could not find the password by hash. Then the Pass-the-Hash attacks enter the game.
Before considering attacks, it briefly works as Kerberos authentication works in Active Directory to understand, due to what this attack is possible. For an Active Directory client to access a specific resource, it will require a TGS ticket. Receiving a ticket TGS “on the fingers” is as follows:
- The client sends the current date and time to the domain controller, encrypting them using a common secret.
- The domain controller, having received and decrypted the request, sends a TGT ticket to the client, which contains information about the user, the member of which groups he is, and so on
- When a client needs access to a resource, he turns to the controller, presents a TGT ticket and receives a TGS ticket
- With this ticket, it is authenticated on the required resource
At what stage is the attack possible, related to the NTLM hash we have? An NTLM hash is the same general secret that a client and a domain controller have. Accordingly, knowing the NTLM-hash, you can get the TGT-ticket is almost legitimate.
- To perform the attack, we need a workstation on the same network as the domain controller and Mimikatz. The workstation itself does not need to be part of the domain.
We will switch to the domain workstation behind which the jdoe user is running. We check that we do not have access to the desired resource, but it should be from the user trainer.
We will open Mimikatz and raise the privileges before debugging.
Privilege::debug
Then we will indicate the command:
Sekurlsa::pth /user:trainer /domain:contoso.com /ntlm:<ntlm-хэш пользователя trainer>
A new command line was opened. we check access to the file – access is granted. In doing so, I’m still a jdoe user, but we have Kerberos tickets from the user trainer.
This attack is called Overpass-the-Hash and is the exploitation of the features of the Kerberos protocol. Preventing attacks is possible with the help of competent configuration and detection.
- Let’s go back to the Azure ATP portal and see what was discovered.
One alert is Unusual Protocol Implementation. This is the detection of “atypical” authentication.
The second is the Encryption Downgrade Activity. Discovering a Kerberos ticket request using Mimikatz.
Thus, we quickly discovered one of the attacks on the Kerberos protocol.
It is important to note that detecting attacks do not exclude the need to carefully configure Active Directory security in accordance with best practices.
