Mimikatz Detected on Endpoint [CHK-3026]
This ticket is opened when Microsoft Defender detects Mimikatz, or a tool derived from it, on a device in your environment. Attic MDR raises it as a high-priority finding. The affected device, the account involved and the actions Attic has already taken are written into the ticket by the MDR pipeline.
Rationale
Mimikatz is the best-known credential-dumping tool in existence. It extracts passwords, hashes, Kerberos tickets and certificates directly from the memory of the Windows LSASS process, and it is the reference implementation for techniques such as pass-the-hash, pass-the-ticket and Golden Ticket attacks.
Its presence on a device is significant for two reasons. First, running it requires administrative privileges, so an attacker who is executing it has already escalated. Second, it is used at a very specific moment in an intrusion: the attacker has a foothold and now wants credentials to move sideways to more valuable systems. Detection therefore usually means an intrusion is already in progress rather than beginning.
Mimikatz has almost no legitimate use outside a controlled penetration test or a security training exercise. It is occasionally embedded in other tooling, so the detection may name a derivative rather than Mimikatz itself. The implication is the same.
Follow-up
Follow these steps to adequately address this detection:
- Establish whether this is authorised testing. Check whether a penetration test, red team exercise or security training was running at that time, on that device, with that account.
- If no (not authorised): Treat this as an active intrusion and act on the assumption that credentials have already been taken:
- Isolate the device immediately in Microsoft Defender. Do not shut it down: isolation preserves memory and the investigation timeline.
- Reset the passwords of every account that has signed in to that device, not only the account that ran the tool. Mimikatz takes what is in memory, which includes cached and service credentials.
- Revoke all active sessions for those accounts in Entra admin center, and rotate any service account and application credentials involved.
- Reset the krbtgt account twice if the device was domain-joined and domain credentials may have been exposed. This is what invalidates any Golden Ticket the attacker may have created.
- Look for lateral movement from that device around and after the detection time: remote logons, service creation, scheduled tasks, remote PowerShell.
- Escalate to IR. Contact Attic for incident response support. Credential-dumping activity on a live network warrants hands-on investigation.
- If yes (authorised testing): Confirm the details before closing:
- Verify the tester, the scope and the time window against the engagement documentation.
- Confirm the test credentials used are rotated at the end of the engagement.
- Record the confirmation on the ticket so the same detection is not re-investigated.
- If no (not authorised): Treat this as an active intrusion and act on the assumption that credentials have already been taken: