Most TLS libraries support a concept known as a key log file or “SSLKEYLOGFILE”. This feature allows users to deliberately log the session secrets securing a TLS connection to a file. Applications that use TLS like browsers can then be used as normal, but the underlying session secrets of the encrypted transport are recorded. If you then capture the encrypted TLS traffic, it is possible to load the key log file into Wireshark to perform decryption and reveal the application data.

This support of logging TLS session secrets to a key log file is a by design feature that has long been used by developers, penetration testers, malware researchers, and other tinkerers to gain visibility on what traffic is being sent by software with communications protected by TLS. However, this functionality doesn’t seem to have ever gotten wide spread use as a post-exploitation technique by red teamers or real adversaries. Consequently, abuse of this functionality has also been largely overlooked by blue teams as it is not prevalent in the wild.

This blog post walks through practical approaches of using key log files in a post-exploitation scenario to steal cookies from web browsers like Chrome. Stealing cookies is a common post-exploitation task that can be achieved using several well-known techniques. However, the use of key log files to achieve this goal does have some benefits over the more well-known techniques. There is no direct reading or writing of the Cookies file, no starting Chrome with debugging enabled, no malicious browser extensions, no process dumping, and no DPAPI decryption. This might be a useful technique if you are faced with a mature blue team that has detection for the popular approaches, and you need a weird way to steal cookies or perform other browser post-exploitation.

Enabling Key Log Files

SSLKEYLOGFILE Environment Variable

Enabling key log files is simple, you just create an SSLKEYLOGFILE environment variable and point it where you want the log to go like SSLKEYLOGFILE=/tmp/ssl.log. Then once you start any application built with a TLS library that supports key log files, you will see the TLS session secrets start to be logged. This is operating system and application agnostic, it works anywhere that a TLS library is being used that supports this environment variable. The only “gotcha” is this won’t affect any applications that are already running.

You can then start capturing network traffic using something like Wireshark, and go about using a browser like Chrome to visit websites protected with HTTPS. Your packet capture will start to fill up with TLS traffic that you can’t read. Once you have captured TLS packets, decrypting them is as simple as configuring the protocol preferences in Wireshark to point to the key log file.

Chromium Command Line Flag

Setting an environment variable to configure SSLKEYLOGFILE is definitely the most common method to get applications to record a key log file. However, this approach has the downside that it affects every application on the system and you will get key logs from all of them. An alternative with Chromium based browsers like Chrome is to use the --ssl-key-log-file command line flag like:

google-chrome --ssl-key-log-file=/tmp/ssl.log

This command line flag lets you enable key logging just for the browser without affecting any other application on the system. You will of course still need to restart the browser process with this flag, as it won’t affect any already running browser processes.

Capturing Browser Traffic

Once you have key log files enabled, the next step is to capture browser traffic. If you are in an elevated content then you could simply perform packet capturing. However, there’s a good chance you are not in an elevated context during a post-exploitation scenario. A simple option is to configure a proxy at either the system level or the browser level. This could be an HTTP or SOCKS proxy server, and you could be running it either on a remote server or locally (i.e. tunnelling it over C2). If you are already adding a command line option to enable key log files, then you might append a proxy option like:

google-chrome --ssl-key-log-file=/tmp/ssl.log --proxy-server="socks5://127.0.0.1:8080"

You can then perform packet capturing on your proxy server instead of directly on the target system, avoiding the need for elevated privileges.

Cookie Theft Examples

User Already Has Cookies For Target Site

If you know the user is already authenticated to the target site (i.e. has valid cookies), then you may opt to immediately steal cookies. The process to perform this looks like:

  1. Kill their current Chrome process (the user may notice this).
  2. Start a new invisible Chrome process that browses to the target site (with key logging enabled and a proxy configured).
  3. Optionally restart a normal Chrome process afterwards.

A well-known way to start an invisible Chrome process is via launching it in headless mode while pointing to the existing Chrome profile (i.e. because this doesn’t get loaded by default in headless mode):

google-chrome --ssl-key-log-file=/tmp/ssl.log --proxy-server="socks5://127.0.0.1:8080" --headless --disable-gpu --user-data-dir="C:\Users\<username>\AppData\Local\Google\Chrome\User Data\" https://www.example.com

An alternative option for a less visible (but not invisible) Chrome process without using --headless is:

google-chrome --ssl-key-log-file=/tmp/ssl.log --proxy-server="socks5://127.0.0.1:8080" --content-shell-hide-toolbar --window-size=0,0 https://www.example.com

Waiting For The User To Login To The Target Site

If the user isn’t currently logged in to the target site, then you have a few options:

  1. You can just wait for them to login and use the same approach described above to kill Chrome and relaunch it to steal cookies.
  2. You could pre-emptively kill Chrome and relaunch it with options to record TLS keys and traffic for the rest of the sessions.
  3. You could backdoor the launcher for Chrome to relaunch it with options to record TLS keys and traffic for the rest of the sessions. This can be achieved by methods like editing shortcuts on Windows or .desktop files on Linux. However, this is less feasible for MacOS where most methods to do this can look a bit messy to the user (e.g. replacing the Chrome app on the dock with a script that launches Chrome with options).

In all of these cases you would be running Chrome with options like:

google-chrome --ssl-key-log-file=/tmp/ssl.log --proxy-server="socks5://127.0.0.1:8080

Detection & Mitigation

There are several ways this technique can be detected:

  • Watch for the SSLKEYLOGFILE environment variable being set.
  • Watch for Chromium browsers being launched with the —ssl-key-log-file command line flag.
  • Watch for Chromium browsers being launched with other flags that may be unusual in your environment like --headless, --proxy-server, and --window-size.

Chromium Warning Banner

The Chromium team are definitely aware of the possibility for abuse of key log files, and back in 2019 the browser did briefly display a warning banner if key log files were enabled. However, this decision was soon reversed and the warning was removed.