Active Directory Attack Scenarios Part 3: Deserializing Your Way In

In this series focusing on Active Directory attacks, we’re running through four different scenarios based on real penetration testing engagements that demonstrate the variety of techniques and tactics that can be used to compromise Active Directory. Part one showed how attackers can gain control using overlooked assets like network connected printers as attack vectors. Part two went over how to go beyond domain admin control to get access to an organization’s sensitive data. In this scenario, we’ll demonstrate the importance of ensuring your third-party applications are secure.

Intelligence Gathering and Initial Access Points

For this external penetration test, we began by mapping the attack surface, analyzing the environment to see if we could find any outward facing web applications or other points of entry that required a login.

Simultaneously, we began gathering intelligence on the organization. We used Google, LinkedIn, and Bing to find the names of current employees and figure out potential naming conventions of user logins. For example, if we found that employee Bob Vance’s email address was [email protected], this could mean that first initial.last name is the formula for designating user logins. We also searched for public leaks of credentials to see if any were associated with logins from the organization. We ended up discovering 1500 potential usernames/email addressees.

Upon completion of our attack map analysis, we found that, at least externally, the organization was relatively secure. There were only two points of interest that were worth exploring further: a Citrix portal and an LDAP directory web application. As we were more familiar with the Citrix portal, we decided to begin there.

Exploring the Citrix Portal

Since we had a long list of potential usernames, we decided to use a password spray attack to see if we could uncover any valid sets of credentials. We were able to come up with eight sets of valid credentials. However, logging in using these credentials resulted in a dead end. None of them were set up in this particular application, so there was no way to pivot into another part of the infrastructure. Despite this setback, the exercise was still valuable, as we were able to confirm that we had valid naming conventions. With this in mind, we moved on to the second possible entry point.

A Dangerously Insecure LDAP Directory Web Application

When we first approached the LDAP directory web application, we assumed we would use the same strategy of a password spray attack. However, in the process of trying out different possible credentials, we were surprised to discover a significant flaw in the application. We no longer needed to find a valid username and password—the application would allow us to create new users. Not only could we come up with our own username and password, these users were given write permissions.

These write permissions gave us pause, as they hinted that there may be some highly privileged accounts configured for this application service. This made this application worth investigating further, as having those credentials could get us that much closer to control of Active Directory.

Image

Image

Magic Bytes and Deserialization

In order to figure out how the application worked, we began by examining its network traffic. When looking through STP requests, we found that one of them contained magic bytes. Magic bytes are essentially a file signature—the first few bytes of an object that allows one to identify it. These magic bytes serve as an ideal entry point for deserialization.

Image

From there, we used the magic bytes and created a deserialized payload that would download and install a backdoor. We serialized this object using the .net version of the ysoserial project and then delivered the attack payload to be executed.

Image

Escalating Privileges with Known Vulnerabilities

While we were able to achieve remote code execution to gain a foothold, we were only able to do so on a service account. In order to get full domain control, we needed to escalate our privileges to a system account, which was fairly easy to accomplish. We were able to simply exploit a known vulnerability that had never been patched to obtain domain administrator credentials that were kept in memory.

Image

With these credentials in hand, we had full access to and control of Active Directory.  

The Importance of Securing Third-Party Software

This scenario has several big security takeaways regarding third-party applications. First, very few security measures were present on the LDAP server web application. For example, there were no limitations on the number of login attempts, which allowed us to use a password spray attacks. Even with unlimited login attempts, having multi-factor authentication would have prevented us from gaining access. While this is a weakness of the application, organizations can also layer in their own authentication requirements to make up for this shortcoming.

Additionally, the organization did not seem to have this application monitored in any way. We didn’t encounter any antivirus or endpoint detection and response (EDR) that would have thwarted us or at least flagged abnormal activity.

Ultimately, this engagement underscored that the security of third-party applications should never be taken for granted. This doesn’t mean that you need to fully transition to in-house applications, but rather that vetting both the software and the vendor is necessary before making a purchase or even renewing a license. While a tool may have all the features you need, it’s also important to verify with a vendor whether it complies with industry standards, such as running Static application security testing (SAST) and dynamic application security testing (DAST). Additionally, independent research should be conducted, such as finding out whether it has preexisting vulnerabilities and if they’ve been fixed. This way, you know that you’re purchasing a tool that doesn’t create new attack vectors to your infrastructure, but instead only adds value to your organization.