Getting Inside the Mind of an Attacker Part 4: Additional Internal Attack Techniques

Authored by: Julio Sanchez

In part 3 of this series, we examined a penetration testing engagement that the Core Security Services team performed, simulating an insider attacker with low-level credentials escalating their privileges with Kerberos tickets and pass-the-hash attacks. In this final scenario, we’ll explore another insider attack engagement, demonstrating how different techniques can be used in similar situations. We’ll also learn more about Kerberos tickets and review more ways you can reduce your risk.

The Scenario: Insider Attack on an Enterprise Organization

For this scenario, an external to internal breach was once again assumed, and we were provided with a non-privileged, regular domain account, and granted internal network access through a direct connection of our attack laptops to a wired ethernet port.

The organization we were attacking was quite large, with several offices across the country. Its environment featured heavy network segmentation and many different types of devices. There were multiple domains that each housed multiple servers. Three of the Windows domains created a Forest Hierarchy with bidirectional trust relationships between the root and the leaves. Finally, there was a PCI domain, without a relationship to the main forest.

Step 1: Initial Assumptions

Before beginning the attack, we were informed that a group of employees had smart cards, which have an embedded chip that can be used as authentication for a more secure login process. This was especially worth noting as we were also running a client-side pen test at the time to see how vulnerable employees were against phishing. Users that opened an email and clicked on a link were taken to spoofed website and asked for their login credentials. Certain users provided us with the code generated by the smartcards in the password field.

Knowing the organization was using smart cards, the first assumption an attacker could make is that not every domain account could have been provided with them. For example, service or machine accounts cannot use them. Since smart cards are more difficult to bypass, the most logical area to focus the attack would be analyzing the security of the accounts that did not use them.

When thinking about service accounts, another observation an attacker could have made is that given the large size of the organization, there would have to be a high number of services, servers and, of course, service owners.

Additionally, an attacker would note the protections in place against cross protocol NTLM relay attacks, which would prevent them from attempting this type of privilege escalation attacks, as was previously described in part 2.

Finally, the last observation concerned the administration of the internal DNS. In this case, it was not managed by the default active directory solution, ADIDNS, but was instead managed by a BIND server. Not using a default solution can easily impact an attacker’s strategy.

Step 2: Enumerate Information from the Domain

As we did in part 3, we began by enumerating all the information possible from the domain, which can be done with a variety of open source tools. For example, in Linux terminals, LDAPDomainDump, a tool based on Python, is commonly used. In this scenario, we used a Windows tool based on PowerShell scripts called ADRrecon.

Step 3: Perform a Kerberoast Attack

We also followed the Kerberos based approach we used in the previous scenario, obtaining service accounts and crackable service tickets. Using a technique known as Kerberoast, an attacker can request service tickets for each service owner account in the domain, forcing them to be encrypted with the weak RC4 encryption algorithm.

From there, we obtained around 200 Kerberos tickets which were then submitted to offline cracking. As a reminder, ticket cracking is a very slow process, especially with such a large amount of tickets. Coming up with an intelligent, efficient cracking method is critical to staying efficient. First, we validated if we had any high privileged accounts, such as a domain admin used as a service account. Unfortunately, we did not.

Then, we considered Kerberos delegation, which will be discussed in detail later on. Briefly, service accounts which are enabled to perform delegation can impersonate high privilege users depending on certain conditions. Since we didn’t have any high privileged accounts available, we instead prioritized the delegation enabled accounts.

We then moved onto designing an effective cracking strategy. We opted for multi-case variations of the customers' names, followed by a series of one to six characters, including letters, numbers, and special characters. Using this approach, we were able to obtain the credentials for one account that had unconstrained delegation privilege.

Step 4: Hijack an Impersonation Ticket

We designed an attack in which we attempted to hijack an impersonation ticket from a domain administrator account. Completing such an attack requires thorough preparation. First, certain requirements need to be met. The first requirement was that we should be able to control the Service Principal Name (SPN) field of the compromised service account, in order to register our own attack laptop as a service. Second, the SPN field should be filled in with the fully qualified domain name of our laptop. Since Kerberos relies on DNS for host identification, only identifying our machine by its IP address would not work.

Fortunately, our service account had enough rights to write its own SPN field, so we were able to complete the first requirement using the Sysinternals AD Explorer tool. The second requirement of DNS entry wasn’t quite as straightforward. In a pure Active Directory environment, the DNS would be managed by ADIDNS, which would give any domain account the chance of adding a new registry to identify hosts. In this scenario, DNS was managed by BIND. In order to be in a position to make these changes, we would have first needed to compromise the BIND server.

However, in this case, the organization had solved this for us, as our machine was assigned a fully qualified name in the Forest, after we physically connected to the wired network. Having met these requirements, we moved onto the next step, which was setting up an SMB listener in our attack laptop. For this we used a krbrelay tool, a variation of NTLM relay, which allowed us to receive the authentication and capture the impersonation ticket.

Step 5: Launch Printerbug

In order to force a domain controller to connect against a listener, we abused a remote procedure call (RPC) to the SpoolService printing feature, in an attack commonly known as PRINTERBUG. While we controlled this service, whose owner has unconstrained delegation enabled, our attacker machine received a forwardable granting ticket, which is essentially the impersonation ticket for the controller’s machine account. We were able to use the machine account to invoke a domain replication operation against another domain controller, which successfully compromised the domain. Through the abuse of preexisting trust relationships, we gained control of the entire force.

Step 6: Launch a Pass-the-Hash-Attack

Finally, in order to compromise the other separated domain, we made the assumption that one of the IT administrators in charge of both domains was lazy enough to use the same credentials between domains, and performed an interdomain pass-the-hash attack. Our assumption proved correct, and we detected a domain admin reusing credentials, allowing us to complete the compromise.

How to Identify and Reduce the Risk of Insider Attacks

1. Know the Different Types of Domain Accounts.

Attackers sometimes target specific account types, so it’s important to know what makes each account type distinct.

User accounts are generally associated with a real person. Sometimes, a user account may be associated with a department. These accounts grant GUI access to a computer, and typically use easy-to-remember passwords.

Service accounts, on the other hand, tend to be generic and not directly associated to a person, as they are used to run application services. Every account with one or more registered SPNs becomes a service account. These accounts should use a randomly generated, strong password.

Lastly, machine accounts are created when a computer is set to a Windows domain. They are named after computers, and usually they have local admin privileges over them. As domain accounts, machine accounts are also protected by a password. This password is a 240 computer generated byte string that rotates every 30 days by default, making these hashes virtually impossible to crack, which is why they are not a target for Kerberoast attacks. 

2. Understand How Domain Controller Accounts Can be Abused.

Though machine accounts generally aren’t a target for Kerberoast attacks, domain controller machine accounts can be abused. Since domain controllers are essentially computers, they have a machine account associated. These machine accounts have high privileges. In particular, they have replication privileges, as they need to perform domain replication operations. 

Attackers may be able to take advantage of such an account by compromising its NTLM hash, which is stored only in domain controllers. Alternately, NTLM relay can be used, though success in this kind of attack depends on a lack of protections against it. For example, if there are no protections relating to LDAP, it may be possible to achieve a successful exploit. Finally, control of the machine account of a domain controller can be obtained through unconstrained Kerberos delegation, which is detailed in the next section.

3. Don’t Allow Unconstrained Delegation.

Unconstrained delegation was the first solution to the double hop issue, an authentication problem that occurs when a user connects to SQL Server A, which needs to grab data from SQL Server B. As its name implies, this delegation type has no constraints or restrictions in place for the use of the delegated impersonation ticket. In the previous example, the application server could use the user ticket to ask for service tickets on behalf of the user, not only for the database server, but also for any server in the domain. This is exactly what occurred during this engagement, when we captured the ticket for a domain controller account and used it to authenticate via SMB to another domain controller.

After considering this security implication, Microsoft was able to re-engineer this feature and created the much safer constrained and resource-based delegation. For example, in constrained delegation, service accounts are also able to request service tickets on behalf of other users, but only for a limited set of services. While this does not eliminate the risk, opting for this delegation scheme greatly reduces it.

You should always examine your Active Directory force to see if any of your service accounts has been granted unconstrained delegation rights and consider switching them to constrained delegation privileges. If any of these unconstrained delegation accounts are compromised, attackers would be able to dramatically escalate their privileges in your domain force.

Certain interesting accounts, like domain admins, domain controllers, or machine accounts should not be delegated at all. In order to protect them from being delegated, include them in a protected users group, which cannot be delegated by default.

4. Consider Disabling Services.

This scenario also showed the problem of unsecure configurations through the abuse of SpoolService. This RPC allows an attacker to make use of the PRINTERBUG exploit to force the Kerberos negotiation from the domain controller.

While SpoolService is a standard feature, that does not mean you are required to keep it. Your IT team should evaluate the impact of disabling the service on sensitive devices, particularly critical services. If there is no serious negative impact, disabling the service will help protect your most valuable resources. Knowing which interfaces we are exposing in our devices is a key element in order to reduce the attack surface.

5. Evaluate Your Current Security Practices.

Finally, consider the risk of your current practices. In this scenario, issuing a name in the domain to each device connected to the network really simplified the attack for the consultants. Consider if any of your current asset management or cyber security practices may introduce additional risks.

Lessons Learned from Internal Attacks

When considering the two internal attack scenarios, we see how many different tools and tactics can be used, and just how flexible threat actors can be when planning and executing an attack. Additionally, with this scenario, we also see just how important comprehensive security is. While this organization had clearly prioritized access management through the use of smart cards, our pen tests showed how many alternate avenues there were to escalating privileges and gaining control. Ultimately, regular assessments are the key to finding hidden security weaknesses.

In part 5, we’ll conclude this series with final thoughts and advice on how to stay one step ahead of attackers.