I recently came across the awesome cookie crimes repository by @defaultnamehere. This handy tool will extract cookies from Google Chrome, however it is a python script (with the option to use pyinstaller to package it as an executable), but what I really wanted was a .NET assembly that I can run in memory down C2 through tools such as PoshC2 using
run-exe or CobaltStrike beacon's
To that end I decided to rewrite it in .NET, and the result is SharpCookieMonster. All credit for the original work goes to @defaultnamehere.
Simply pass the site name to the binary.
SharpCookieMonster.exe [https://sitename.com] [chrome-debugging-port] [user data dir]
An optional first argument sepcifies the site that chrome will initially connect to when launched (default https://www.google.com).
An optional second argument specifies the port to launch the chrome debugger on (by default 9142).
Finally, an optional third argument specifies the path to the user data directory, which can be overridden in order to access different profiles (default %APPDATALOCAL%\Google\Chrome\User Data).
As you can see, it can be used to extract session, httpOnly and secure cookies down a C2 channel all in memory. It has also been added to PoshC2 as a module and with Autoloads and Aliases set up, so it can be simply run using the
sharpcookiemonster. Under the hood this uses PoshC2's
This also works with CobaltStrike's beacon however using
It's also worth noting that you don't need any sort of privileged access to do this, just code execution in that user's context on the computer where the sessions are stored.
How does it work?
Under the hood this works by first launching Google Chrome as a headless process. We start by enumerating any running chrome.exe processes in order to pull out it's image path, but if that fails then we default to C:\Program Files (x86)\Google\Chrome\Application\chrome.exe. We then launch that executable, setting the approriate flags and redirecting that process' output to our stdout, so that we can see if it errors even when running it down our C2 channel.
--headless flag means that chrome.exe will essentially run without any user interface, but can be interacted with using its APIs. For a red teamer this is perfect, as it will only appear as another (genuine) chrome.exe process but will not present anything to the user. Remote debugging is then enabled for this process via the
--remote-debugging-port flag, and we point the data directory to the user's existing data directory using
Once this is launched we then check if the process is running and wait for the debugger port to be 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 through an API over websockets, giving us the full power of those devtools. All this is done locally on the victim's machine, as that's where both this binary is being run, and the headless Chrome process is running.
We can then issue the request to retrieve all the cookies in the cache for that profile, and return them to the operator.
@defaultnamehere's original blog post on the topic goes into some more detail and is an excellent read for those wanting to know more.
Building the binary
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 in order to be compatible with victims with older versions of .NET installed. However in order to use WebSockets to communicate with Chrome the WebSocket4Net package was added.
If you want to run this down C2 such as using PoshC2's
sharpcookiemonster command or via CobaltStrike's
execute-assembly then use ILMerge to merge the built executable with the dependency 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