This tool will extract cookies from Google Chrome and is a .NET assembly that can be used in the C2 via tools like PoshC2 or CobaltStrike's commands.
run-exe execute-assemblyThe project address is SharpCookieMonster .
Usage
Simply enter the site.
SharpCookieMonster.exe [https://sitename.com] [chrome-debugging-port] [user data dir]The optional first parameter separates the website that chrome will initially connect to when it starts (defaults to https://www.google.com).
The second optional parameter specifies the port used to start the chrome debugger (9142 by default).
Finally, the optional third parameter specifies the path to the user data directory, which can be overridden to access a different profile (defaults to %APPDATALOCAL%\Google\Chrome\User Data).
As you can see it can be used to extract session, httpOnly and transfer cookies via C2. It has also been added to PoshC2 as a module, with autoloading and aliasing set up, so it can be simply run with sharpcookiemonster.
This also applies to CobaltStrike's, which can use execute-assembly.
It's also worth noting that you don't need any privileged access to do this, just execute code in that user context on the machine where the session is stored.
How does it work?
In the background, this is achieved by first launching Google Chrome. We first enumerate any running chrome.exe process to extract its mirror path, but if that fails, it defaults to C:\Program Files (x86)\Google\Chrome\Application\chrome.exe. We then start the executable, set the appropriate flags and redirect the output of the process to our stdout so we can see if it errors out even when running it on the C2 channel.
The --headless flag means that chrome.exe will actually run without any user interface, but can interact using its API. This is perfect for red team members as it will just appear as another chrome.exe process and not show anything to the user. Then, enable remote debugging for this process via the --remote-debugging-port flag, and then point the data directory to the user's existing data directory with --user-data-dir .
After launching
, we will check if the process is running and wait for the debugger port to open.
We can then interact with the API on that port to get the websocket debugger URL. This URL allows programs to interact with Chrome's devtools via APIs over websockets, giving us the full functionality of these devtools. All of this is done locally on the victim's computer because the binary is running and the interfaceless Chrome process is running.
We can then make a request to retrieve all cookies in that profile's cache and return it to the operator.
Compilation
If you want to build the binary yourself, just clone it and build it in Visual Studio.
The project has been set up to be compatible with .NET 3.5 for compatibility with victims who have older versions of .NET installed. However, in order to communicate with Chrome using WebSockets, the WebSocket4Net package was added.
If you want to run this command on C2 (such as using PoshC2's sharpcookiemonster command or via CobaltStrike), execute-assembly uses ILMerge to merge the resulting executable with the dependent libraries.
For example, first rename the original binary, then run:
ILMerge.exe /targetplatform:"v2,C:\Windows\Microsoft.NET\Framework\v2.0.50727" /out:SharpCookieMonster.exe SharpCookieMonsterOriginal.exe WebSocket4Net.dll SuperSocket.ClientEngine.dll