Active Directory is an essential application within an organization, facilitating and centralizing network management through the creation of domains, users and objects, as well as user authentication and authorization. Active Directory doubles as a database, storing usernames, passwords, permissions, and more. Active Directory is a perfect example of a double-edged technological sword. While such a centralized application can streamline IT operations, it is also an irresistible target for attackers. And unfortunately, it may be easier to access Active Directory than you think.
In this series, we’ll walk through four different scenarios based on actual penetration testing engagements that sought to compromise Active Directory, each highlighting important considerations that show how to better anticipate attacks and protect this vital application. For this first scenario, we will demonstrate why no attack vector should be ignored.
A weak link in the chain: misconfigured printers
There are many paths an attacker can take to compromise infrastructure. Since printers are not regularly used by attackers, security teams tend to ignore these devices as well. However, printers have become increasingly sophisticated and versatile over the years and are essentially specialized computers 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 do this, many organizations provide these devices with corporate domain credentials. For example, username “printer1” and password, “printprintprint”. Unfortunately, sometimes printers are only configured during initial setup and then left behind, often without updates or patches. This makes Printers a great place to attempt a first breach.
A Case for Never Reusing Passwords
In this engagement, we researched and discovered two printers that had domain credentials and exposed certain HTTP SOAP APIs on TCP ports. Any user with administrative privileges or administrative credentials for the printer could interact with the server and retrieve configured FTP and SMB usernames and passwords. There is both a Core Impact module and some GitHub projects that can be used to easily perform this checkout. This revealed three different sets of credentials. Two were invalid, meaning their passwords were no longer in use. The last was a domain user account, which would have been ideal, but the account was disabled.
However, during such engagements, it is important to maintain an attacking mindset. Skilled and experienced attackers will always try to use what is available to them, even if it requires 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 can get both a normal user account and a privileged account.
Although this is theoretically a security measure so that the employee only uses the account with the least privileges necessary to complete a task, it can also be a security weakness. There are often trivial, easy-to-guess naming conventions for usernames, and it’s not uncommon for employees to make the mistake of using the same password for all of their different accounts.
This was the case for this engagement. John Doe’s disabled domain account password worked for logging into his regular user account, which was still enabled. We were able to use this account, conduct a password spray attack, and gain local administrator privileges on seven different hosts.
Setbacks and Successes: Stealth and Security Checks
Following the success of the 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 out of these efforts, so we then decided to access the host’s process memory to try and extract credentials that would hopefully have broader privileges . However, before we could complete this task, our account was disabled by the defense team.
Despite this, we were far enough along in the process to have other options we could turn to. Having previously retrieved the contents of the hosts’ SAM databases, we decided to test all NTLM password hashes of the default administrator account RID 500 on all hosts in the domain. In the end, this gave us local administrator privileges on four new hosts.
We repeated the process of recovering SAM databases and LSA secrets. However, we were again caught and a host, which appeared to be a file server, was isolated from the network to restrict access. Since file servers often have privileged user credentials in memory, we thought it was worth waiting for it to come back online, which would probably be in a few hours, because the File servers are so essential to carry out regular organizational activities.
The isolation was indeed temporary, but the security team had changed the password for the RID 500 user account and also disabled it. Despite having basic security controls in place, the initial security weaknesses we exploited gave us enough information to keep moving forward.
Shutdown: Using a Kerberos service ticket to take control
We had previously retrieved all information from the SAM database in the second set of hosts, including the file server that we no longer had access to. Therefore, we were still monitoring the NTLM password hashes of computer accounts. Typically, computers change their passwords every 30 days, unless they are prompted to do so sooner. This reset was not triggered, so we were able to continue.
We used the NTLM password hash of the file server computer account to create a Kerberos service ticket to access any service as a user, allowing a domain administrator to access the SMB service.
As can be seen above, our fake ticket allowed us to access the LSASS memory from which we were able to extract the domain and administrator credentials. Using these credentials, we could log into the domain controller and run operating system commands, thus completing our goal.
Conclusions: the need for large surveys
This engagement illustrates how a few simple misconfigurations ultimately led to taking full control of the domain. Moreover, it shows the need to remain vigilant once an attack is detected. Our focus for this engagement was not stealth, so it’s likely that our password spray attack raised some flags, initially notifying the security team of our unusual activity. While it’s great that the security team caught us red-handed not once, but twice, it’s worth noting the fact that the penetration testing team still had enough information to continue to advance. Until you are sure an attacker has been thwarted, security teams should remain on high alert.
