Dialogues about Impacket-secretsdump
“You are a sleeping genius whose degree of awakening depends on the amount of your conscious actions.”
Introduction
Good day to all! Often, it turns out that there is no need to reinvent your wheel, and it is much more convenient to take someone else’s ready-made solution, and even more so if this solution “passed through fire, water, and copper pipes”. At the same time, there is a great temptation to use it without wasting time on understanding the principle of operation, guided by the truth: “I won’t get under the hood, I still don’t understand anything about it! Works? So that’s great!”
In today’s article, we will talk about the familiar utility from the package Impacket entitled secretsdump. Of course, this article will not reveal all theoretical aspects of this script, but aimed at increasing awareness when using this utility! In any case, there is no limit to perfection, and, if you wish, you can further deepen your knowledge by starting to figure it out on your own! (we will assume that this is a “kind of” springboard)
Below is a link to the project itself, in case you suddenly have an irresistible interest in digging into the lines of the program code!
https://github.com/SecureAuthCorp/impacket/blob/master/impacket/examples/secretsdump.py
And why do we need all this?
“The utility allows you to dump hashes from a remote Domain Controller without running any agents on it.” Of course, this is not the only utility to achieve a similar result. But secretsdump is loved and used around the world, for the opportunity remote dump sensitive information from a domain controller!
Below is a link to a galaxy of methods for dumping hashes with Windows
https://pentestlab.blog/2018/07/04/dumping-domain-password-hashes/
After correct operation impacket-secretsdump we have the opportunity to carry out attacks: Pass-the-Hash (for Lateral Movement), Golden Ticket (by ticking the “perform persistence” checkbox) and in general, in fact, take control of the domain and “feel at ease”.
And what is being done?
-
SAM and LSA secrets + cached creds are read from the registry, then “registry hives” [hives – о боже как я не хочу переводитьJ] are stored on the target system in the %SYSTEMROOT%\\Temp folder, and all the remaining data is read from there.
-
Optional with NTDS.dit:
2.1) Extract domain usernames and their password hashes + Kerberos keys using [MS-DRDS] calling the DRSGetNCChanges() procedure, while only the attributes we need are replicated (more on that below)
2.2) Extract NTDS.dit with vssadmin [подробнее по той самой ссылочке про методы дампа хэшей]while it is launched using smbexec.
What is the output?
Now it’s time for a detailed analysis of the “output” after the (successful) operation of this utility!
First, the boot key of the target machine is extracted. He is in SYSTEM hive in HKLM\SYSTEM. Of course, if we want to perform this action manually, then for this we simply execute the command reg save HKLM\SYSTEM after which we copy it from the target machine in any way available to us. The download key is required to decrypt the file ntds.dit later.
Next, a dump of the SAM file located in HKLM/SAM. The Security Account Manager (SAM) is a registry file that stores passwords of local computer users. They are stored, of course, in encrypted form.
When a domain user authenticates to a domain controller at logon, their credentials are stored on the local computer by default (Cached Credentials:username:hash). This allows the user to log in with his account to a computer from the domain even if the Controller is not available (a network problem, or the DC is turned off)
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon
In this case, 10 is the number (by default) of logons, without access to a domain controller under domain (cached) credentials.
LSA secrets
LSA secrets are a special secure repository of sensitive information that is used by the Local Security Authority (LSA) in Windows. LSA is designed to manage the local security policy of the system, audit, authorization, user login to the system, and storage of private data. Sensitive user and system data is kept secret. Only the system has access to all secret data.
HKLM/Security/Policy/Secrets
It is these registry branches impacket-secretsdump successfully extracted and decrypted.
It is worth saying that they are encrypted on the system bootkey.
In this case, it’s the machine account secret, which is rotated every 30 days. It is possible to use the machine account hash in delegation-related attacks.
DPAPI is used to protect user credentials stored on a Windows host.
DPAPI is used to protect the following personal data:
Passwords and form autofill data in Internet Explorer, Google Chrome
·Mail account passwords in Outlook, Windows Mail, Windows Mail, etc.
Built-in FTP manager account passwords
·Passwords for accessing shared folders and resources
Wireless account passwords and keys Encryption keys in Windows CardSpace and Windows Vault
Remote Desktop Connection Passwords, .NET Passport
File Encryption System (EFS) private keys, S-MIME mail encryption, other user certificates, SSL/TLS in Internet Information Services EAP/TLS and 802.1x (VPN and WiFi authentication)
Network passwords in Credential Manager
·Personal data of any application that is programmatically protected using the CryptProtectData API function. For example, Skype, Windows Rights Management Services, Windows Media, MSN messenger, Google Talk, etc.
The list is amazing, isn’t it?!)
We can use the extracted DPAPI key, for example, to decrypt passwords saved in Google Chrome.
The NL$KM secret contains the encryption key for cached domain passwords.
In addition to LSA secrets, Kerberos keys are also dumped.
NTDS.dit?
Well, we have reached the dump of the ntds.dit file, which is a database that stores information about domain objects, and contains, among other things, usernames + password hashes.
I think that everyone already understands that we we can do with NT hash, so I just wanted to shed some light on the DRSUAPI method. As noted earlier, in fact, what impacket-secretsdump does is commonly called domain controller replication, and in the context of an attack on a domain, DCSync.
I will just say in a nutshell how DCSync works:
1) The domain controller is detected by the domain name (since we specified the ip address, the search is not long)
2) A request is made to replicate user credentials to a domain controller via the GetNCChanges function [используя Directory Replication Service (DRS) Remote Protocol]
“An organization’s network infrastructure often needs to have more than one domain controller for Active Directory. Thus, for the full functioning of two or more domain controllers, it is necessary that AD objects can be replicated to all domain controllers”
The replication process is entrusted to the DRS Remote Protocol. DRSUAPI is a Microsoft API that implements the replication process. Like any API, it has a number functions.
In this case, we will focus only on the DSGetNCChanges() function. The client DC sends a DSGetNCChanges request to the server when the first wants to receive updates to AD objects from the second. The response contains a set of updates that the client should apply to its NC replica. In the event that the set of updates is too large for a single response message, then multiple DSGetNCChanges requests and responses are executed. This process is called the replication cycle, or simply the cycle.
You can read more about DCSync here and here
Conclusion
Thus, having dealt with the output, and having gone a little deeper into what each character means, we can now appreciate the functionality that the creators put into secretsdump. There is no absolute knowledge, and I may have missed certain things in this article (I tried to provide abundant links to useful resources for further study).
