Security, et al

Stealing Credentials with Mimikatz

Mimikatz is an open-source tool built to gather and exploit Windows credentials. Since its introduction in 2011 by author Benjamin Delpy, the attacks that Mimikatz is capable of have continued to grow. Also, the ways in which Mimikatz can be packaged and deployed have become even more creative and difficult to detect by security professionals. This has led to Mimikatz recently being tied to some of the most prevalent cyber attacks such as the Petya ransomware. Once Petya has established itself within an environment, it uses recompiled Mimikatz code to steal credentials and move laterally throughout the organization.

Using Mimikatz to harvest credentials as part of malware and cyberattacks is nothing new. Mimikatz has been linked to Samsam ransomware, Xdata ransomware, and WannaCry. The SANS Institute published a paper on detection and mitigation of Mimikatz early in 2016, but I’m not sure anybody is taking it as seriously as they should.

There are ways to protect against credential theft and abuse. The best place to start is with understanding the risks and the necessary steps to mitigate them. In this blog series, we will dive deeper into Mimikatz and look at how this open-source tool can be easily deployed as part of an attack. We will also explore various mitigations and ways that attackers are staying one step ahead of modern detection mechanisms.

What Exactly Does Mimikatz Do?

Mimikatz is primarily a post-exploitation tool, meaning it’s a way for an attacker who has found some other means onto your systems to expand their reach and eventually achieve complete control. Here are some of the ways Mimikatz can be used to do just that.

Stealing Credentials

Mimikatz has a variety of ways that it can steal credentials from a system. One simple way is through using the sekurlsa::logonpasswords command, which will output password information for all currently and recently logged on users and computers. If an attacker can compromise a single machine, then they can use this to get the password information for any other users or computers that have logged onto that machine. This is the premise of lateral movement and privilege escalation.

You can see below by issuing this command, I can retrieve the NTLM hash for the account Jeff, which I can later use to impersonate that account. 

Another clever way of stealing credentials supported by Mimikatz is using DCSync, during which the attacker will pretend to be a domain controller and ask Active Directory to replicate its most sensitive password information.

Lateral Movement

Stealing credentials is the first step, the next step is to use them. Mimikatz comes with easy ways to perform pass-the-hash and pass-the-ticket activities to impersonate the stolen credentials and move laterally throughout an organization. Using the sekurlsa::pth command, I can take that recently discovered hash and launch a process on its behalf. Here is a post from a previous series, which covers this in more detail.

Persistence

Once an attacker has successfully moved laterally to compromise a target domain, Mimikatz offers several ways to make sure they maintain their control even after detection. Golden Tickets and Silver Tickets provide effective ways to create forged Kerberos tickets that are very difficult to detect and provide attackers with unlimited access. Mimikatz also provides other powerful persistence techniques including the Skeleton Key, injecting a malicious SSP, and manipulating user passwords.

How Do Attackers Use Mimikatz?

Chances are, most attackers are not going to download Mimikatz straight from GitHub onto an infected computer and start using it. Most antivirus tools will detect that. In this series, we are going to take a look at how attackers can weaponize Mimikatz and what you can do to protect against these attacks. Here’s the lineup:

• Post #1 – Automating Mimikatz with Empire & DeathStar Read Now
• Post #2 – Lateral Movement with CrackMapExec Read Now
• Post #3 – Ways to Detect and Mitigate These Attacks Read Now
• Post #4 – How Attackers Are Bypassing These Protections Read Now

Watch this video and sign up for the complete Active Directory Attacks Video Training Series here (CPE Credits offered).

Service Account Attack #2: Extracting Service Account Passwords

In our first post, we explored how an attacker can perform reconnaissance to discover service accounts within an Active Directory (AD) domain. Now that we know how to find service accounts, let’s look at how an attacker can compromise those accounts and use them to exploit their privileges. In this post, we will explore one such method for doing that: Kerberoasting. This method is especially scary because it requires no elevated privileges within the domain, is very easy to perform once you know how, and is virtually undetectable.

Kerberoasting: Overview

Kerberoasting takes advantage of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs). If you remember, in the reconnaissance post we focused on discovering service accounts by scanning for user objects’ SPN values. Kerberoasting allows us to crack passwords for those accounts. By logging into an Active Directory domain as any authenticated user, we are able to request service tickets (TGS) for service accounts by specifying their SPN value. Active Directory will return an encrypted ticket, which is encrypted using the NTLM hash of the account that is associated with that SPN. You can then brute force these service tickets until successfully cracked, with no risk of detection or account lockouts. Once cracked, you have the service account password in plain text.

Even if you don’t fully understand the inner-workings of Kerberos, the attack can be summarized as:

1. Scan Active Directory for user accounts with SPN values set.
2. Request service tickets from AD using SPN values
3. Extract service tickets to memory and save to a file
4. Brute force attack those passwords offline until cracked

With those steps in mind, you can imagine how easy it may be to get access to a domain and begin cracking all service accounts within minutes. From there, it’s just a waiting game until you have compromised one or more service accounts.

For a better understanding of the types of access that can be garnered using Kerberoasting, look at the list of SPN values maintained by Sean Metcalf on ADSecurity.org.

Kerberoasting: How it Works

Step 1 – Obtain a list of SPN values for user accounts

We focus on user accounts because they have shorter, less secure passwords. Computer accounts have long, complex, random passwords that change frequently.  There are many ways to get this information, including:

• PowerShell and LDAP queries, as covered in my previous post.
• Active Directory Module for PowerShell
• GetUserSPNs script provided by Kerberoast toolkit
• Get-NetUser command of PowerSploit

Step 2 – Request Service Tickets for service account SPNs

To do this, you need to simply execute a couple lines of PowerShell and a service ticket will be returned and stored in memory to your system.

These tickets are encrypted with the password of the service account associated with the SPN. We are almost ready to start cracking them.

Step 3 – Extract Service Tickets Using Mimikatz

Mimikatz allows you to extract local tickets and save them to disk. We need to do this so we can pass them into our password cracking script. To do this, you must install Mimikatz and issue a single command.

Step 4 – Crack the Tickets

Now that you have the tickets saved to disk, you can begin cracking the passwords. Cracking service accounts is a particularly successful approach because their passwords very rarely change. Also, cracking the tickets offline will not cause any domain traffic or account lockouts, so it is undetectable.

The Kerberoasting toolkit provides a useful Python script to do this. It can take some configuration to make sure you have the required environment to run the script; there is a useful blog here, which covers those details for you.

The script will run a dictionary of passwords as NTLM hashes against the service tickets you have extracted until it can successfully open the ticket. Once the ticket can be opened, you have cracked the service account and are provided with its clear-text password! 

Protecting Yourself from Kerberoasting Attacks

The best mitigation for this attack is to ensure your service accounts that use Kerberos with SPN values leverage long and complex passwords. If possible, rotate those passwords regularly. Using group managed service accounts will enforce random, complex passwords that can be automatically rotated and managed centrally within AD.

To detect the attack in progress, monitor for abnormal account usage. Service accounts traditionally should be used from the same systems in the same ways, so it is possible to detect authentication anomalies. Also, you can monitor for service ticket requests in Active Directory to look for spikes in those requests.

This is the second installment in our blog series, 4 Service Account Attacks and How to Protect Against Them. To read the other installments, please click Read Now below or watch the webinar here .

Service Account Attack #1 – Discovering Service Accounts without using Privileges Read Now
Service Account Attack #3 – Targeted Service Account Exploitation with Silver Tickets Read Now
Service Account Attack #4 – Exploiting the KRBTGT service account for Golden Tickets Read Now

Watch this video and sign up for the complete Active Directory Attacks Video Training Series here (CPE Credits offered).