Attacking Windows Credential Manager
Windows Vault and Credential Manager
Credential Manager is a feature built into Windows since Server 2008 R2 and Windows 7. Thorough documentation on how it works is not publicly available, but essentially, it allows users and applications to securely store credentials relevant to other systems and websites. Credentials are stored in special encrypted folders on the computer under the user and system profiles (MITRE ATT&CK):
%UserProfile%\AppData\Local\Microsoft\Vault\%UserProfile%\AppData\Local\Microsoft\Credentials\%UserProfile%\AppData\Roaming\Microsoft\Vault\%ProgramData%\Microsoft\Vault\%SystemRoot%\System32\config\systemprofile\AppData\Roaming\Microsoft\Vault\
Each vault folder contains a Policy.vpol file with AES keys (AES-128 or AES-256) that is protected by DPAPI. These AES keys are used to encrypt the credentials. Newer versions of Windows make use of Credential Guard to further protect the DPAPI master keys by storing them in secured memory enclaves (Virtualization-based Security).
Microsoft often refers to the protected stores as Credential Lockers (formerly Windows Vaults). Credential Manager is the user-facing feature/API, while the actual encrypted stores are the vault/locker folders. The following table lists the two types of credentials Windows stores:
Web Credentials
Credentials associated with websites and online accounts. This locker is used by Internet Explorer and legacy versions of Microsoft Edge.
Windows Credentials
Used to store login tokens for various services such as OneDrive, and credentials related to domain users, local network resources, services, and shared directories.
It is possible to export Windows Vaults to .crd files either via Control Panel or with the following command. Backups created this way are encrypted with a password supplied by the user, and can be imported on other Windows systems.
C:\Users\sadams>rundll32 keymgr.dll,KRShowKeyMgrEnumerating credentials with cmdkey
We can use cmdkey to enumerate the credentials stored in the current user's profile:
C:\Users\sadams>whoami
srv01\sadams
C:\Users\sadams>cmdkey /list
Currently stored credentials:
Target: WindowsLive:target=virtualapp/didlogical
Type: Generic
User: 02hejubrtyqjrkfi
Local machine persistence
Target: Domain:interactive=SRV01\mcharles
Type: Domain Password
User: SRV01\mcharlesStored credentials are listed with the following format:
Target
The resource or account name the credential is for. This could be a computer, domain name, or a special identifier.
Type
The kind of credential. Common types are Generic for general credentials, and Domain Password for domain user logons.
User
The user account associated with the credential.
Persistence
Some credentials indicate whether a credential is saved persistently on the computer; credentials marked with Local machine persistence survive reboots.
The first credential in the command output above, virtualapp/didlogical, is a generic credential used by Microsoft account/Windows Live services. The random looking username is an internal account ID. This entry may be ignored for our purposes.
The second credential, Domain:interactive=SRV01\mcharles, is a domain credential associated with the user SRV01\mcharles. Interactive means that the credential is used for interactive logon sessions. Whenever we come across this type of credential, we can use runas to impersonate the stored user like so:
Extracting credentials with Mimikatz
There are many different tools that can be used to decrypt stored credentials. One of the tools we can use is mimikatz. Even within mimikatz, there are multiple ways to attack these credentials - we can either dump credentials from memory using the sekurlsa module, or we can manually decrypt credentials using the dpapi module. For this example, we will target the LSASS process with sekurlsa:
[!Note] Some other tools which may be used to enumerate and extract stored credentials included SharpDPAPI, LaZagne, and DonPAPI.
UAC Bypasses
https://redfoxsec.com/blog/windows-uac-bypass/
MSCONFIG UAC Bypass
Payload
Write the payload:
Registry Hijack
Trigger (from mcharles shell)
Then we go to Tools and select Command Prompt to open one up as Admin:
Bypass using Fodhelper
In this scenario, we will take a look at fodhelper.exe, which is a Windows default executable that is required for managing optional Windows features, additional languages, etc. It is also an automatically executable program. This means that the administrator will not be prompted by UAC to perform elevated tasks. Unlike the above case of using msconfig, we can performed if there are restrictions to GUI.
Start Run and type “fodhelper.exe” to open Fodhelper.
When we open fodhelper.exe, Windows will check the registry keys and values to exactly know which application to use to open it.
For example, say if we are opening a html file. The windows will go to registry > HKEY_CLASSES_ROOT to check for which client application is must be used to open it. The command is defined in shell\open\command subkey i.e., the iexplore.exe.
We can then change the data of the value named DelegateExecute in the registry within the HKCU\Software\Classes\ms-settings\Shell\Open\command for the fodhelper to replace with our own script to get a reverse shell. Let’s say an attacker managed to attack the machine and get an administrator level account, but if UAC is restricting from performing an elevated execution.
We can create a malicious script to provide a reverse shell back to the attacker machine and store it in an Environment variable.
Create an empty value named DelegateExecute inside the registry key HKCU\Software\Classes\ms-settings\Shell\Open\command.
So that the system-wide association can be used at HKLU (HKEY_LOCAL_USER) instead of user-specific association based at HKCU (HKEY_CURRENT_USER). In other words
We can check by running Registry Editor in windows to check if the key values are updated in HKCU\Software\Classes\ms-settings\Shell\Open\command.
Finally, add the shell code value to the registry key. Go to the attacker’s machine and open up a reverse shell.
At the attacker’s side: