Full control despite virus protection and modern systems – How to truly protect IT-infrastructure

Recently, codecentric's security experts were tasked with testing the IT infrastructure security of a company with several hundred employees. The clients believed they were secure: The systems were running on the latest version of Windows 11 and Windows Server 2022, and a commercial antivirus product was in use.

Nevertheless: After two days, codecentric's security experts had become domain administrators with full access to all systems without the client noticing. An attacker in this position could have exfiltrated business data and encrypted or deleted all systems. How could this happen?

Summary of the Attack

The attack was carried out as part of a so-called "assumed-breach" scenario, meaning we were provided with a normal user account without special permissions, similar to what an attacker might obtain through a phishing attack.

First, we conducted an enumeration of the domain, examining what information and data our user could access. During this process, a shared file storage was discovered through which, due to incorrect configuration, personal files of other users could be accessed. Many passwords were found in these files, including an old backup of the IT admin's password manager. A list was created from these passwords, which was then automatically tested against the available systems.

This allowed access to one of the systems on which a domain administrator was logged in. The goal was now to read the memory of the process in which the domain administrator's credentials were temporarily stored. However, the execution of malicious code was prevented by Windows Defender and the antivirus product. But using a self-developed bypass of the AMSI (Antimalware Scan Interface), this defense mechanism was also circumvented. Subsequently, the domain administrator's credentials could be extracted and finally used to log in to the domain controller.

Preventative Measures

The attack described above is a good demonstration that defending IT infrastructure on a single level is insufficient. For example, virus protection is at most a temporary obstacle for experienced attackers. A multi-layered approach is necessary, where various products and procedures are used at multiple levels. This concept is also known as Defense in Depth.

Here are some measures that would have made the attack described above more difficult:

• Hardening of the Active Directory domain so that, for example, a normal user can only query the most necessary information
• Introduction of appropriate password management, for example via LAPS, so that local administrator passwords are not used on multiple systems
• Use of Credential Guard, so that credentials cannot be easily extracted from the LSASS process

The measure that would have had the greatest impact on an attacker's chances of success in this case would be the use of tools for logging, monitoring, and alerting, also known as "Security Information and Event Management" (SIEM). The idea is to centrally collect log data from various systems, analyze them for potential attacks, and trigger alarms when detected.

This measure creates visibility into the processes on client systems and in the network and allows responding to an attack before it's too late. It makes the attackers' lives significantly more difficult, because they suddenly have to be careful not to trigger warnings or alarms. They can no longer try things arbitrarily until a security measure is bypassed. The attack described above could have been quickly noticed this way.

Technical Details of the Attack

Step 1: Enumerating the Domain

With the provided normally privileged user account, various tools were used to gather more information about the domain:

• SharpHound + Bloodhound
• adPEAS
• Various PowerShell commands

Using these tools, a detailed overview of users, computers, groups, and potential privileges was obtained.

Potential countermeasures:

• Deny AD users read access to certain objects
• Logging & Alerting (SharpHound is easy to detect)
• Make access to PowerShell in Citrix more difficult (it should be noted that completely preventing command-line calls is usually not feasible)

Step 2: Enumerating Shared Directories

The provided user had access to many shared directories. In these directories, we specifically searched for files that potentially contained credentials. Among other things, a plaintext backup of the IT admin's password manager and credentials of a user with RDP rights were found.

Potential countermeasures:

• Restrict access to shared directories
• Do not share private user data such as Desktop or Documents. The respective user directories should only be accessible to the users themselves.
• Sensitize users so that no password lists or password manager backups are stored in plaintext → Password management
• Logging & Alerting (Automated scanning is easy to detect)

Step 3: Local Administrator on the Admin Jumphost

Thanks to the domain enumeration, it was known that a computer existed on which domain administrators had valid and active sessions. Using the found credentials, authentication via the Remote Desktop Protocol was possible on this computer. The goal now was to expand the available permissions to read the credentials of the logged-in domain administrators with local administrator privileges.

For this purpose, a list of all known local administrator usernames and another list of all already identified passwords were created. Using the tool crackmapexec, all combinations of these usernames and passwords were then automatically tried against all computers in the domain. This was deliberately done only against local users and not against domain users to avoid locking domain users and thus restricting availability. Through this method, valid login credentials for an administrator jumphost server were identified, among others. Thus, a login with a local system administrator was possible here.

Countermeasures:

• Introduce appropriate password management, for example via LAPS
• Implement appropriate group policies to prevent domain administrators from logging into third-party systems (Protecting Domain Administrator Groups)
• Restrict remote desktop permissions for normal users to a necessary minimum

Step 4: Reading the LSASS Process

The hashed credentials of active users are stored in Windows in the so-called LSASS process. A local administrator has the permission to read this data. However, in this case, this was prevented by the activated virus protection. Using a so-called AMSI bypass, the virus protection could be circumvented, and the process memory could still be read using the Out-Minidump script. This dump was then transferred to the attacker systems. To read the hashes contained therein, the tool Mimikatz was used on the attacker systems.

Countermeasures:

• Use of Credential Guard. However, there are also bypasses
• Avoid active sessions and logins with domain administrators outside of domain controllers. In general, domain administrator accounts should only be used to administer the domain itself.
• Implement an appropriate Privileged Access Model for administrators

Step 5: Generating a Kerberos Ticket

Using the extracted hash, a so-called Pass-The-Key attack could be executed. For this, the getTGT.py script from Impacket was used to obtain a Kerberos ticket with the hash.

With this ticket, the permissions of a domain administrator and thus the maximum possible privileges in the network were obtained.

Countermeasures:

• Deactivate RC4 key type in Kerberos
• Logging & Alerting

Step 6: Post Exploitation

With these permissions, any actions in the domain environment of the network were now possible. Using impacket-secretsdump, we conducted a so-called DCSync attack, which provided the hashed credentials of all domain users as well as a plaintext password of the domain administrator.

Additionally, our own domain administrator with all privileges was created. From this position, an attacker with malicious intentions could have, for example, triggered encryption or deletion of all company data.

Countermeasures:

• Logging & Alerting

About Us

At codecentric, we offer extensive consulting and testing in the field of IT security. Specifically in the area of IT infrastructure, we can assist you with assessments for inventory, penetration tests for verification, or Red/Purple team exercises for training a Blue team. More information can be found here.