Active Directory Attack Scenarios: The Path from Printer to Domain Admin

Active Directory is an essential application within an organization, facilitating and centralizing network management through domain, user, and object creation, as well as authentication and authorization of users. Active Directory also serves as a database, storing usernames, passwords, permissions, and more. Active Directory is a perfect example of a technological double-edged sword. While such a centralized application can streamline IT operations, it does also make for an irresistible target for attackers. And unfortunately, it can be easier to reach Active Directory than one may think. 

In this series, we’ll run through four different scenarios based on real penetration testing engagements that sought to compromise Active Directory, each of which highlight important considerations that show how to better anticipate attacks and protect this vital application. For this first scenario, we’ll demonstrate why no attack vector should go ignored.

A Weak Link in the Chain: Misconfigured Printers

There are many paths an attacker may take in order to compromise the infrastructure. Since printers aren’t regularly used by attackers, security teams also tend to overlook these devices. However, printers have become increasingly sophisticated and multi-faceted over the years and are essentially specialized computers that are well integrated into an organizational network, interacting with or exposing different services like FTP, SMB, or SMTP. For example, a user can use a printer to scan a document and email it to themselves or save it to a file server. To accomplish this, many organizations provide such devices with corporate domain credentials—for example, it could be given the username “printer1” and a password, “printprintprint.” Unfortunately, printers are sometimes only configured during the initial setup and then left behind, frequently going without updates and patching. This makes printers an ideal place to attempt an initial breach.

A Case for Never Reusing Passwords

In this engagement, we sought and discovered two printers that possessed domain credentials and exposed certain HTTP SOAP API on TCP ports. Any user with administrative privileges or administrative credentials for the printer was able to interact with the server and extract configured FTP and SMB usernames and passwords. There is both a Core Impact module and some GitHub projects that can be used to easily complete this extraction. This turned up three different sets of credentials. Two were invalid, meaning their passwords were no longer used. The last one was a domain user account, which would have been ideal, but the account was disabled.

However, during such engagements it’s important to maintain an attacker mindset. Skilled and experienced attackers will always attempt to use what’s available to them, even if it requires some workarounds. An experienced attacker is likely aware of the common practice of having employees with multiple Domain User accounts, depending on their role. For example, an IT team member may get both a regular user account and a privileged account.

Image

While this is theoretically a security measurement so that the employee is only using the account with the least amount of privilege needed to accomplish a task, it can also be a security weakness. There are often trivial, easily guessed naming conventions for usernames, and it is not unusual for employees to make the mistake of using the same password for all of their different accounts.

Such was the case for this engagement. The password for John Doe’s disabled domain account worked for his regular user account login, which was still enabled. We were able to use this account, conduct a password spray attack, and obtain local administrator privileges on seven different hosts.

Setbacks and Successes: Stealth and Security Controls

After the successful password spray attack, we accessed the Security Account Manager (SAM) databases and Local Security Authority (LSA) secrets of the discovered hosts. Nothing of interest came from these efforts, so we next moved to access the host’s process memory to try and pull credentials that would hopefully have more extensive privileges. However, before we were able to complete this task, our account was disabled by the defense team.

Despite this, we were far enough along in the process that we had other options that we could turn to. Having previously retrieved the contents within the SAM databases of the hosts, we decided to test all of the RID 500 default admin account NTLM password hash against all of the hosts in the domain. Ultimately, this gave us local administrator privileges on four new hosts.

We repeated the process of retrieving SAM databases and LSA secrets. However, we were once again caught, and one host, which seemed to be a file server, was put into network isolation to restrict our access to it. Since file servers often have privileged user credentials in memory, we thought it would be worth waiting for it to come back online, which would likely be within a few hours because file servers are so essential to complete regular organizational activities.

The isolation was indeed temporary, but the security team had changed the RID 500 user account password and also disabled it. Despite basic security controls being in place, the initial security weaknesses we exploited gave us enough information to keep moving forward.

Closing In: Using a Kerberos Service Ticket to Gain Control

We had previously retrieved all the information from the SAM database in the second set of hosts—including the file server we no longer had access to. Consequently, we were still in control of the computer accounts NTLM password hashes. Typically, computers change passwords every 30 days unless prompted to do so earlier. This reset was not triggered, so we were able to proceed.

We used the file server computer account NTLM password hash to handcraft a Kerberos Service Ticket for accessing any service as any user, allowing a domain administrator to gain access to the SMB service.

Image

As can be seen above, our forged ticket allowed us to get to the LSASS memory from which we were able to pull domain and administrator credentials. Using these credentials, we could log into the domain controller and execute operating system commands, thus completing our objective.

Conclusions: The Need for Broad Investigations

This engagement illustrates how a few simple misconfigurations ultimately led toward gaining full control of the domain. Additionally, it shows the need to remain vigilant once an attack is detected. Our goal for this engagement had not been about stealth, so it is likely that our password spray attack had raised flags, initially notifying the security team about our unusual activity. While it was great that the security team caught us in the act not once, but twice, the fact that the pen testing team still had enough information to continue moving forward should be noted. Until you’re sure an attacker has been thwarted, security teams should remain on high alert.