At this point I went back to the figurative drawing board and had another look at the API calls made by the AD Connect server. I loaded mcrypt.dll into API Monitor and confirmed that AD Connect still used the same functions to load the keyset. The only remaining difference was that the actual AD Connect service was running under the NT SERVICE\ADSync user, whereas my tool was running as a domain user with local administrator privileges. So which storage mechanism outside the registry would store data that is only accessible to the user who put it there? How about the Windows Credential Manager (or Credential Vault)? This is a per-user vault which uses DPAPI to encrypted the secrets stored in it. A quick way to verify this theory was to simply dump the credentials in the vault. There are multiple tools for this but since I needed to do this from the context of the NT SERVICE\ADSync user I opted for Mimikatz, that can impersonate the user by stealing a token from the running service and then access the vault:
Thanks and credits go as always to the ones that researched this topic for much longer than I have and contributed to the tools. Special thanks to Benjamin for figuring out the encryption and for Mimikatz and to Alberto Solino for building and maintaining impacket and for making all the DPAPI/Credential files one import + a few lines of code away from being parsed. Lastly of course Will for his work in this area and his blog explaining the concepts really well. His blog on this subject contains plenty of more stuff about this subject as well as good references to older research.
The Microsoft Data Protection Application Programming Interface, or DPAPI for short, is a Windows API tool for developers to enable them to store sensitive data in a way that it is encrypted but still decryptable.
It has been around since Windows 2000 which makes it more or less ancient in computer terms.
However it has since been tweaked to such an extent that it is no longer recognizable, things like RSA, AES256, SHA512 and even PBKDF2 have been added or increased in rounds.
Inside the Registry file %windir%\System32\config\SYSTEM lays a system unique DPAPI key, it is encrypted with the Syskey which is to be extracted from the %windir%\System32\config\SECURITY file. Multiple tools exist to extract these on- or offline (e.g. lsadump.py from CredDump 7).
However: for this research I adjusted and/or recreated all of the scripts from both DPAPICK as DPAPILAB and made them work on Windows and Linux, in Python3 and without the need of M2Crypto (now pycryptodome).
All next code examples are from this new and improved framework called DPAPILAB-NG, created especially for offline decryption of Windows secrets.
The following code example demonstrates two forms of encryption and decryption. First, the code example encrypts and then decrypts an in-memory array of bytes. Next, the code example encrypts a copy of a byte array, saves it to a file, loads the data back from the file, and then decrypts the data. The example displays the original data, the encrypted data, and the decrypted data.
I created a BrowserLoginData Object to be able to store the resultant decrypted credentials. The tool instanciates a new BrowserLoginData object for each decrypted set of logins and append them to a list for output to the console or a file.
Once the data is an ASN1 object as Sequences, the values required for decryption can be extracted, and the result can be checked against a hard-coded value of password-check\x02\x02 to ensure the correct password/values were used. The MasterPassword is an empty string if no password was provided as a command line argument.
The decryption key (and initialisation vector/nonce) is then created by joining two HMAC-SHA1 values which are calculated using the previously created values. The key is taken from the first 24 bytes and the IV from the last 8 bytes.
Post-exploitation in Windows environments often imply secrets collection. The collected secrets can be reused for lateral or vertical movement, making them high value assets. Most people already know the LSASS process, but other secrets such as LSA secrets and DPAPI ones could also allow privilege escalation or access to sensitive resources. This article will describe the different types of secrets that can be found within a Windows machine, and public tools that can be used to retrieve them.
This article will describe each of them, the information they contain, available tools to recover them and the existing detection risks. While no new technique will be introduced here, this summary should still help in future internal network or red team assessments. Finally, even if this listing tries to be exhaustive, some techniques or tools might be missing.
The tool supports creating an invalid memory dump to prevent antiviruses from deleting it. However, it seems the implemented techniques are nowadays blocked by most detection software. Indeed, the functions of the Windows API used to perform userland memory dumps are heavily monitored by AV products, using hooks or Event Tracing for Windows (ETW).
As the previously described tools are frequently blocked or detected by antivirus products, other tools have been developed to leverage known vulnerable drivers signed by Microsoft in order to gain read/write primitives in the Windows kernel. A website lists known vulnerable drivers that can be used for such tools:
Physmem2profit is a tool developed in C# and Python released in 2020 by WithSecureLabs. It has a client / server architecture where the client is Python-based (but Python 3.7 and later is not supported), and the server is run on the compromised host and is built in C#. The client connects to the server and mounts the WinpMem driver, offering direct physical memory access. The server will then try to find the LSASS process using rekall and reconstruct a dump.
EDRSandblast is a tool developed in C and released in 2021 by Wavestone. It compiles as an executable that has to be run on the victim's machine using RDP, WinRM or other methods. It currently supports two drivers: RTCore64 and DBUtils_2_3 but can be extended with other vulnerable drivers.
This tool uses the driver's read and write primitives to temporarily disable all antivirus hooks and/or detection mechanisms before creating a memory dump of the LSASS process. It is very reliable even if some dumps are not usable and antivirus might still catch the dump being written to the disk. Writing the dump on a network share might help preventing such detection. The tool's GitHub page details how these actions are performed if you are interested in the technical implementation.
The tool requires offsets in ntoskrnl.exe to properly work, either by providing a CSV file or using the --internet switch. This option is not advised when stealth is required. Therefore, it will be necessary to update the offsets before the tool can work.
DumpIt is a closed source tool developed by Comae and mainly used for forensic analysis, that uses a driver to dump all the physical memory into a file. Because the dumps size depends on the amount of memory available, retrieving one from a remote system is usually slow. To ease this process, MemProcFS allows mounting memory dumps, then, the minidump folder of the LSASS contains a dump that is compatible with mimikatz or pypykatz.
As for most Impacket tools, its use is often detected and blocked. For this reason, we developed SharpSecretsdump, a C# version to perform these actions on a live system. It has the following advantages:
There are not many native tools to perform DPAPI operations. The cmdkey /list command can be used to list credentials when executed in the context of a user. Moreover, Wi-Fi passwords can also be recovered with netsh:
Dpapi.py allows decrypting the majority of DPAPI secrets such as: credentials, vaults and DPAPI blobs (unprotect). The following example shows the offline decryption of a DPAPI blob retrieved with a call to CryptProtectData, in the context of a user:
We used reverse engineering techniques to understand how the credentials are decrypted by the different tools. The methods described here do not involve exploitation of vulnerabilities.
The first tool we looked at was WinSCP. It offers the option to save the credential details used to connect to remote machines via SSH. WinSCP obfuscates the credentials and saves them in the Windows registry. The credentials are not encrypted at all, and anyone who knows the algorithm used to obfuscate can gain access to the credentials.
MobaXTerm is a powerful tool to connect to remote machines using various protocols such as SSH, Telnet, RDP, FTP and so on. A user who wants to save credentials within MobaXTerm will be asked to create a Master Password to protect their sensitive data.
Developers, DevOps and IT use various tools to connect to remote machines and manage these access details. Vendors have to store this sensitive information in the most secure way. However, encryption is always on the client side, and an attacker can replicate the tool behavior in order to decrypt the credentials.
Is the natively master password really stored in the plain text? As I understand, it is stored just encrypted by DPAPI. But some tools, like KeeThief, can invoke decryption of this data by injecting a shellcode in the KeePass process.
Yes, there is an option not to store this data (that's why I added: "in the case they are kept")
b73f46f91f