mimikatz: reading Windows credentials out of process memory

A learning project that found a real job

The readme opens with an unusual framing for a tool with more than twenty thousand stars on GitHub. mimikatz is something its author made to learn C and to run experiments with Windows security. Benjamin Delpy describes it as a little tool to play with Windows security, and the tone matters, because the experiments turned up something with lasting consequences. The readme says outright that mimikatz is now well known to extract plaintexts passwords, hash, PIN code and kerberos tickets from memory, and that it can also perform pass-the-hash, pass-the-ticket or build Golden tickets.

The repository is C, and it is not archived. The last push landed on 2026-04-17, so the default branch still receives work. The tagged releases tell a slower story: the newest is 2.2.0 from 2022-09-19, named for a Djoin parser and a Citrix SSO extractor, with two 2021 tags below it about fixes for Windows 365 web passwords. A branch that moves and a release line that stopped three years ago is a normal pattern for a personal research tool, and it matters if you plan to pin a version.

The licence is CC BY 4.0, which the readme links directly, even though the repository metadata does not carry a licence field. For a tool that inspects other people's machines, that choice of licence is worth understanding rather than skimming past.

Every session opens with privilege::debug

The quick usage section is two lines long, and both of them matter:

log
privilege::debug

`log` is the entry point that brings up the module list. The banner at the top of the console in the readme shows what a session looks like once it is running: mimikatz 2.0 alpha (x86) release "Kiwi en C", dated Apr 6 2014, with 13 modules loaded. That banner is the same string readers see on almost every screenshot of this tool in a training course, an engagement report or a conference talk, which is a good reminder of how long it has been in circulation.

`privilege::debug` is the command that makes almost everything else possible. It asks Windows to grant the process the SeDebugPrivilege, and the readme's sample output shows the answer as `Privilege '20' OK`. Without it, the commands that read another process's memory fail, because the credential material lives inside LSASS and the operating system will not hand that over to an unprivileged handle.

So the practical order is always the same: launch, gain the privilege, then pick a module. Anything else tends to fail in a way that looks like a bug in the tool rather than a permission boundary.

sekurlsa reads what LSASS already holds

The `sekurlsa` module is the one most people mean when they say mimikatz. It walks the logon session structures that the security account manager keeps in memory and prints what it finds:

sekurlsa::logonpasswords
sekurlsa::tickets /export
sekurlsa::pth /user:Administrateur /domain:winxp /ntlm:f193d757b4d487ab7e5a3743f038f713 /run:cmd

The first command dumps plaintext passwords, LM and NTLM hashes and SHA1 hashes per authentication Id, plus whatever sits in the `tspkg` credential provider. In the readme's example output those blocks appear under a `msv` heading, which is the Windows credential provider that most interactive logons use.

The third line is the pass-the-hash form: supply a user, a domain and an NTLM hash and mimikatz spawns a process with those credentials without ever needing the plaintext. `sekurlsa::tickets /export` covers the Kerberos side by writing tickets to disk.

The design point is that none of this is a clever trick. It is a process with debug privilege reading documented-in-practice memory that the system already populated because the user logged in interactively. That is also the limit: a credential that was never materialised in memory cannot be recovered this way, which is why a locked or rebooted workstation behaves very differently from an active desktop session.

Kerberos and directory replication attacks

Active directory gets its own module. The readme lists ticket listing, ticket injection and golden ticket creation:

kerberos::list /export
kerberos::golden /admin:administrateur /domain:chocolate.local /sid:S-1-5-21-130452501-2365100805-3685010670 /krbtgt:310b643c5316c8c3c70a10cfb17e2e31 /ticket:chocolate.kirbi

A golden ticket is forged from the krbtgt account's hash, which is why the command takes both a SID and a krbtgt value: the krbtgt hash lets you mint a ticket that the real Key Distribution Centre would otherwise be the only party able to sign. The output goes to a `.kirbi` file, the same extension used by the well known Kerberos attack tooling.

The `lsadump` module goes after the directory side instead, with the cache and secret exports and the DCSync primitive:

lsadump::sam
lsadump::secrets
lsadump::dcsync /user:domain\krbtgt /domain:lab.local

DCSync is the one that shows up most often in real incident response write-ups, because it replicates directory data from a domain controller the same way a legitimate domain controller would, and therefore looks legitimate in the logs. The readme credits the DCSync and DCShadow functions in `lsadump` to Vincent LE TOUX, which is a useful pointer if you want the original description of how those primitives work.

Token manipulation rounds out the credential story, with `token::elevate` and `token::revert` for adjusting what an existing token claims it can do.

Crypto, certificate and key operations

The `crypto` module covers the Windows cryptography APIs, and the readme splits it into two entry points:

crypto::capi
crypto::cng

Those correspond to the older CAPI and the newer CNG provider set, and running each dumps the providers the machine exposes. The practical reason to care is key export, which the readme lists separately:

crypto::certificates /export
crypto::certificates /export /systemstore:CERT_SYSTEM_STORE_LOCAL_MACHINE
crypto::keys /export
crypto::keys /machine /export

The `/systemstore` flag selects a particular store, and the local machine store is the one holding machine-level certificate material rather than a per-user store. The `/machine` flag on the key export is the same kind of switch, moving from user context to machine context.

There is also a `Terminal Server` module in the readme's list of what the project covers, alongside Crypto, Terminal Server and Events. The readme sends readers to the GitHub wiki and to the author's French blog for the details of those, which is where the documentation actually continues. The console reference in the readme is a good index rather than a manual.

Building it means a Visual Studio solution from 2013

mimikatz is not distributed the way most tools are. It is a Visual Studio solution plus an optional Windows driver, and the readme is explicit about the prerequisites: Visual Studio 2010, 2012 or 2013 for Desktop for mimikatz and mimilib, and Windows Driver Kit 7.1 for the driver, the mimidrv target and the ddk2003 platform. The readme notes that 2013 Express for Desktop is free and supports both x86 and x64.

You do not need the driver for the main operations, and the readme says so in the same breath as the build instructions, including the specific failure you can expect without WinDDK 7.1: an `MSB3073` error about `build.cmd` and `mimidrv`. mimikatz and mimilib build fine regardless.

Source control is unusual here too. The project says it uses SVN and is now available with GIT, and it lists both endpoints plus a ZIP archive:

https://github.com/gentilkiwi/mimikatz.git
https://github.com/gentilkiwi/mimikatz/trunk

The `trunk.lst` and `notrunk.lst` files at the repository root are that SVN history left visible in the tree, and `kiwi_passwords.yar` is a Yara rule for finding password patterns, which tells you something about the intended workflow. Build status runs on AppVeyor through `appveyor.yml`.

The architecture targets are x86 and x64, with ARM64 described as possible if you are lucky, and `mimicom.idl` in the tree is the interface definition for the driver communication. For a modern 64-bit Windows 11 target, the project builds, but the toolchain age is the first thing to budget for. The ddk2003 platform exists for people who want smaller binaries with no runtime dependencies, at the cost of pinning older Visual Studio versions.

Editorial conclusion

mimikatz is still the most direct way to look at what a Windows session has in memory, because it goes after the structures the credential providers already built rather than rebuilding a separate mechanism. It is also a 2010-era codebase with an old toolchain requirement, which suits a workstation under your control far better than a managed fleet. Start with `privilege::debug` and `sekurlsa::logonpasswords` on a lab machine, read the wiki for the modules you need, and treat the readme as the quick reference rather than the documentation.

Frequently asked questions

Official sources

1. gentilkiwi/mimikatz on GitHub
2. Issues
3. Project website
4. README
5. Releases