Slides available on http://asfws12.files.wordpress.com/2012/11/mimikatzasfws.pdf

Benjamin Delpy, aka GentilKiwi, presented us the sekurLSA and crypto part of his trendy and increasingly famous tool called Mimikatz. If you haven’t heard of it yet, I’m convinced that once you read this article and the slides, you’ll certainly want to try out this great tool immediately on a Windows machine and experiment with its astonishing features. The tool itself is available in two modes, either a standalone executable or combined with a DLL which does the work.

We started the presentation with several attacks available against Windows operating systems, and how we often focus on dumping hashes and the SAM. This data is than usually used for pass-the-hash or pass-the-ticket attacks, or misused to increase the carbon footprint of your computing cluster in an attempt to crack the password hashes. But Windows offers several credential authentication providers, which keep your account details in memory:

  • TsPkg is used for Terminal Server authentication
  • msv1_0 for NTLM
  • Wdigest for a proprietary Outlook Web Access authentication
  • LiveSSP (for Hotmail – especially useful for Windows 8)
  • etc.

When run with local administrator rights (or with debug privileges), Mimikatz will search the whole memory to find all used credential providers and extract data from them. For a few credential providers, APIs are provided by Microsoft to retrieve them if you know their Local User ID (LUDI), information which can be gathered by tools such as Sysinternals PsLoggedOn. The password, at this stage, isn’t in clear text but protected by the LSA “Protect Memory” function – which you can use as SYSTEM of your own to decrypt the credentials! We now have clear text passwords of all the users who are logged into this machine (or think “Citrix server”).

This is not the end of the story, but just the start of the fun. Credential Provider TsPkg gets populated not only when a logged in user connects the first time to a terminal server, but as soon as the user logs into the machine. Furthermore, Mimikatz doesn’t limit itself to user credentials, but you can also extract all the details of the machine account (each joined machine to a domain having a dedicated set of credentials).

Mimikatz doesn’t only offer nice listings of all possible credentials found on the system, but will also spawn new processes under the desired identity. It is therefore trivial to start a new process under a stolen identity, without having to bother about getting adequate and dedicated tools for exploitation on the tested box.

One obvious credential provider for Windows we haven’t talked about yet is Kerberos. Benjamin Delpy’s findings regarding this are – again ? – disturbing: while the Kerberos tickets can (almost obviously – now that we see all possibilities of the tool) be recovered from memory using the same techniques, the same applies for the Kerberos password, aka domain password. Why that? A supposition of Benjamin Delpy is that the password is used to get a new set of tickets, when all previously issued tickets expired and an issue (e.g. offline) prevented them to be renewed. This remains an assumption though, as Microsoft did not comment on this point nor explain its move.

A corollary of this Kerberos issue is that even if you own a 100% Windows 2008 domain and disable all credential providers (operation by the way unsupported by Microsoft) but Kerberos, an attacker will still be able to gather valid domain passwords on a compromised machine he was able to root.

What about SmartCard authentication? As already known, the usage of SmartCard doesn’t disable the NTLM mechanism and when you log in, you’ll always get a NTLM hash back from the server. This can then be used for a more traditional pass-the-hash attack.

Up to this point, we covered only features of sekurLSA – but Mimikatz has several other options, the second and last presented today being the crypto part.

The main idea is to have a look how certificates, especially private keys, are stored and protected in Windows. The goal of an attacker would typically be to export all private certificates of a victim, despite the “not exportable” feature of the operating system. Is this possible (well, you guess it is now…) and how?

For the standard crypto API, it’s very easy. Mimikatz just overwrites 4 octets in memory where the “not exportable” flag is set and you’re already done. Note that the standard crypto API in Windows runs in user land, meaning that for this specific attack you do NOT need to be local administrator of the machine – every user can export its own private keys despite the famous checkbox option! If you test this yourself, rely on the certutil command line tool rather than the MMC snap-in, the latter being buggy and disallowing you saving the private keys even when they were genuinely marked as exportable.

What about cryptoNG (alias Crypto New Generation), a newer implementation of Microsoft? The whole process now runs in LSASS now, so a standard user can’t mess with it anymore. But again, local administrators are free to poke around and overwriting 1 octet in the memory of LSASS is enough to export the private key this time. A concerning finding is that not only active certificates can be exported, but it turned out that left overs of presumed deleted certificates were also found on such a machine. In clear text, this means that once a private key has been imported on a machine, you need to restage it to ensure that the private key isn’t accessible to an attacker on it – just “deleting” the certificate is not enough. This also means that people handling certificates daily (e.g. a PKI admin or PKI officer) gets suddenly a very interesting target as they are likely to install and delete such entries on a daily basis.

Finally we were getting to the end of this talk, but before this the author of Mimikatz was to remind that there are other features in its tool, such as for example an AppLocker bypass. Time for questions now: asked about the position of Microsoft about all his findings, Benjamin Delpy replies that Microsoft stated this was all normal, even the storage of the password within the Kerberos credential provider. At the question how all the information was gathered, the author referred to several slides of its presentation (especially the usage of the Microsoft symbol servers and MSDN, where most of the structures are documented). At runtime, Mimikatz does lots of pattern matching in memory to identify the relevant structures. These patterns can obviously be found in the source code of the tool, available online.