A Proof of Concept Cobalt Strike Beacon Object File which uses direct system calls to enable WDigest credential caching and circumvent Credential Guard (if enabled).
Additional guidance can be found in this blog post: https://outflank.nl/blog/?p=1592
This PoC code is based on the following excellent blog posts:
Utilizing direct systems calls via inline assembly in BOF code provides a more opsec safe way of interacting with the LSASS process. Using direct system calls avoids AV/EDR software intercepting user-mode API calls.
Visual Studio (C++) does not support inline assembly for x64 processors. So in order to write a single Beacon Object File containing our compiled / assembled code code we must use the Mingw-w64 (GCC for Windows) compiler.
What is this repository for?
- Demonstrate the usage of direct systems calls using inline-assembly to provide a more opsec safe way of interacting with the LSASS process.
- Enable WDigest credential caching by toggling the
g_fParameter_UseLogonCredentialglobal parameter to 1 within the LSASS process (wdigest.dll module).
- Circumventing Credential Guard (if enabled) by toggling the
g_IsCredGuardEnabledvariable to 0 within the LSASS process (wdigest.dll module).
- Execute this code within the Beacon process using a Beacon object file.
How do I set this up?
We will not supply compiled binaries. You will have to do this yourself:
Clone this repository.
Make sure you have the Mingw-w64 compiler installed. On Mac OSX for example, we can use the ports collection to install Mingw-w64 (
sudo port install mingw-w64).
makecommand to compile the Beacon object file.
Within a Cobaltstrike beacon context run the
inline-executecommand and provide the path to the object
Run the Cobaltstrike
logonpasswordscommand (Mimikatz) and notice that clear text passwords are enabled again for new user logins or users who unlock their desktop session.
- This memory patch is not reboot persistent, so after a reboot you must rerun the code.
- The memory offset to the
wdigest!g_IsCredGuardEnabledglobal variable could change between Windows versions and revisions. We provided some offsets for different builds, but these can change in future releases. You can add your own version offsets which can be found using the Windows debugger tools.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64>cdb.exe -z C:\Windows\System32\wdigest.dll 0:000>x wdigest!g_fParameter_UseLogonCredential 00000001`800361b4 wdigest!g_fParameter_UseLogonCredential =
0:000> x wdigest!g_IsCredGuardEnabled 00000001`80035c08 wdigest!g_IsCredGuardEnabled = 0:000>
To detect credential theft through LSASS memory access, we could use a tool like Sysmon. Sysmon can be configured to log processes opening a handle to the lsass.exe process. With this configuration applied, we can gather telemetry for suspicious processes accessing the LSASS process and help detecting possible credential dumping activity. Of course, there are more options to detect credential theft, for example using an advanced detection platform like Windows Defender ATP. But if you don’t have the budget and luxury of using these platforms, then Sysmon is that free tool that can help to fill up the gap.