DFIR Next Steps: What To Do When You Find Mimikatz Was Run

Do you know what to do after mimikatz is detected on a system you are investigating?

Finding that mimikatz ran on a system is never good news, but it’s important to be able to use that artifact as a starting point for more investigation leads. For those who don’t know, mimikatz is used to get credentials of other accounts.

Our goal is to make sure you can quickly find artifacts and know what to do next. This post is going to cover mimikatz basics and outline what things you should look for after you detect it.

Scenario

You get a call from one of your clients. Their critical servers are down and encrypted. They want you to investigate what happened, and help them recover.

They are suspicious about four endpoints based on user reports and help desk tickets. You ask them to collect data from those four systems, the critical servers, and the domain controller.

The client runs the Cyber Triage Collector on those systems and the artifacts are uploaded to your S3 bucket. As they are uploaded, you start processing them.

Within 10-minutes, Cyber Triage lights up one of the hosts with malware:

Diving in, we see one of the Bad Items is mimikatz.

This is a great first clue. You now need to take advantage of this finding to understand the full scope of the attack.

Why The Attacker Dumped Hashes

First, let’s talk about what was just found. Mimikatz is one of several tools and techniques that can be used to dump credentials and gain a password or hash. Notably for accounts that have previously logged into the compromised system, which may include a domain administrator. It is an open source project on github.

Mimikatz has several methods for obtaining credentials and the details are not important for this post. The impact of the techniques are basically the same – the attacker can perform actions as another user.

Some example techniques include:

• Extracting Windows passwords or Kerberos tickets from the lsass.exe memory.
• Dumping lsass.exe memory to a file, copying the file to another system, and running mimikatz on it.
• Extracting Windows and other application passwords from on-disk structures, such as LSA and Windows Credential Manager.

How The Attacker Did This

You can use clues to learn about what happened before and after the event. Let’s first go backwards and think about what happened before mimikatz was run.

For them to get mimikatz to run (or dump lsass.exe memory), two things must have been true:

• The attacker had the ability to execute commands on the system. This has gone beyond the authorized user opening an attachment. The attacker has either interactive access to the system or can execute commands with C2 infrastructure, such as Cobalt Strike or Sliver.
• The attacker was able to execute commands with administrator or SYSTEM privileges. This may have been achieved by the initial attack vector or a later exploit.

It is also possible that Anti virus software was disabled or not present on the system as Mimikatz is detected by most AV products.

Make sure you look at this system to identify how they can execute commands and gain the permissions. That will be the topic of a future post.

What The Attacker Likely Did With Credentials

Now, let’s look forward and map out what the attacker’s next steps likely were.

Mimikatz’s main goal is to get credentials and therefore we can confidently assume the attacker was interested in escalating their privileges in order to get closer to achieving their end goal. Such as:

• Using admin credentials to log into systems that their current account is not allowed, such as a domain controller.
• Using admin credentials to create new accounts for themselves as a persistence technique.
• Using admin credentials to change the password on an existing account to minimize detection
• Using non-admin credentials to perform activities under multiple accounts and therefore harder to track.

As the attacker moves around the network with different credentials, they will look for data to exfiltrate, encrypt, etc.

What You Should Do Next

Whenever you detect that mimikatz or a similar tool has been run and it’s possible they got domain admin access, you’ll want to reset all passwords because you may never know all of the things they did.

The timing of the resets will depend on the situation, but there are other investigative steps that can take place to help scope and understand the incident. Notably:

1. Identify the accounts that were likely compromised on the system.
2. Search for logon activity by those accounts after mimikatz was run.
3. Search other systems for mimikatz execution and repeat this process on them.

Identify What Accounts Were On the System

To look for the attacker’s next steps, you’ll first need to know which accounts may have been compromised. There are several ways to do this:

• You could run mimikatz yourself on that system and see what it produces. This is perhaps the most accurate way, especially if the system has not been rebooted since it was originally run.
• Your DFIR software may show you a list of accounts. We’ll show you a Cyber Triage example in the next section.
• You can manually look at the profilelist registry key to show you both the domain and local accounts that may have had cached or stored credentials.

Note that the memory contents of the lsass process include details from accounts that have accessed the system since it started. There are additional credentials stored on disk as LSA Secrets. It can be hard to know exactly which ones the attacker accessed. So, it is safest to assume that all accounts could be compromised.

Search for Logons

Once you have a set of possibly compromised accounts and the rough time that mimikatz was run, then you can search for logon activity using the accounts. This can help you increase the scope of the investigation and identify hosts that the attacker used.

Your ability to search depends on what infrastructure exists. Options include:

• Look at the outbound logon activity on the system you are already investigating. For example, using the RDPClient Operational log.
• If you have access to the Windows Domain Controller, you can parse Kerberos and NTLM authentication events to identify activity for those accounts after the given time.
• If you have access to a SIEM that has endpoint logons, you can search that.
• If you have an EDR or another endpoint collection infrastructure, you can search them for inbound logons for the accounts.We’ll show examples of these searches in Cyber Triage at the end of this post.

If these searches identify other hosts, they should be investigated.

Look for New Accounts

The attacker may have used their admin-level credentials to create new accounts for persistence.

• Review active directory information on the domain controller for new domain-level accounts.
• Review any host that has suspicious or bad activity for new local accounts.

We’ll show an example below of looking for new accounts in Cyber Triage.

Monitor Account Logins

If you have the infrastructure, you can also monitor the accounts that you think were compromised so that you know when attempts are made to use them. This can show you what other systems that the attacker is trying to log into.

This would often be done using data from the domain controller or SIEM.

Using Cyber Triage After Mimikatz

Let’s show an example using our Cyber Triage tool. For those who do not know Cyber Triage, it’s an automated DFIR tool that can collect from hosts, analyze the data, and present bad and suspicious items to the investigator.

Mimikatz is Flagged

Going back to the original scenario, Cyber Triage flagged the mimikatz executable as bad based on malware analysis. We can see from the process information that it was run at 14:10:12 on Nov 15.

With this information, there are two directions to go: backwards and forwards in time.

How Was it Run

We can go backward to figure out how it was launched.

• First, we can observe in the above screenshot that Cyber Triage shows us that there was a 1-minute difference between the creation time of the file and when it was launched. So, the attacker was moving relatively quickly.
• In Cyber Triage, we can jump to the timeline to see what happened before the execution. Right click on the item and choose “View In Timeline”.

That will bring us to a timeline, and we can scroll up to see some Powershell and other suspicious actions.

We’ll leave the details of this scenario to you when you download the evaluation data from within Cyber Triage…

What Happened Afterwards On That Host

Once we’ve finished looking at what happened before mimikatz was run, we can look forward and focus on what accounts were compromised and look for activity.

In Cyber Triage, the Accounts area shows you what OS Accounts are in the SAM file, profilelist, and event logs. We go there and see only two accounts. A local admin and a domain account.

The Administrator account’s last activity was before mimikatz was run (based on the “Last Activity” column). The jdoe account was active during the attack.

On this host, we can also look at outbound logons to see where the attacker may have gone after they ran mimikatz. From this data, we can see outbound activity to four hosts starting at 22:07 (mimikatz was run at 14:10). We should collect data from those four hosts.

What Happened Elsewhere

The above procedure focused on one specific host. But, we also want to see where else the jdoe domain account was used.

In Cyber Triage, we can exit the host view and return to the Incident Dashboard. Choose Advanced Search and focus on all logons on Nov 15 for jdoe.

We can see from the Domain Controller data that the account was also used to log into host engineering-comp4 from host finance-comp912. Both of these computers should be collected and examined.

Conclusion

It’s important to exploit as many clues as you can during an investigation. When mimikatz or similar is found, you can focus on how it was able to be run and what new logon activity occurred.

In the example data set above, we were able to easily identify 6 other hosts to start collecting data from and analyzing. All from one clue about when mimikatz was run.

Cyber Triage’s scoring allows you to quickly identify when mimikatz was run, and its interface allows you to quickly pivot to understand the context of the attack. To try it out and use the above evaluation data set, use the Cyber Triage evaluation form.