Google Guide! How to Detect Browser Data Theft Using Windows Event Logs

In the ever-evolving cybersecurity landscape, Google is continually striving to protect user data from malicious actors. In a recent blog post, the tech giant revealed a novel method to detect browser data theft using Windows Event Logs.

This approach aims to make data theft more observable, thereby enabling antivirus software, endpoint detection agents, and system administrators to flag and thwart such attempts.

Chromium’s Sandboxed Process Model

Chromium, the open-source browser project that forms the basis of Google Chrome, Microsoft Edge, and other browsers, employs a sandboxed process model to defend against malicious web content.

This model isolates different browser processes, such as rendering, scripting, and networking, to prevent a single compromised process from affecting the entire system.

However, there are limits to how well an application can protect itself from malware already present on the computer.

Cookies and other credentials remain high-value targets for attackers, and Google is tackling this ongoing threat through multiple strategies.

Integrate ANY.RUN in Your Company for Effective Malware Analysis

Are you from SOC, Threat Research, or DFIR departments? If so, you can join an online community of 400,000 independent security researchers:

• Real-time Detection
• Interactive Malware Analysis
• Easy to Learn by New Security Team members
• Get detailed reports with maximum data
• Set Up Virtual Machine in Linux & all Windows OS Versions
• Interact with Malware Safely

If you want to test all these features now with completely free access to the sandbox:

Try ANY.RUN for FREE

Browser Data Theft Detection

One of the methods Google is exploring involves using Windows Event Logs to detect when a process other than the browser itself is attempting to access protected browser data.

According to Wills Harris from the Google Chrome security team, this approach is based on the fact that browsers use the Data Protection API (DPAPI) to encrypt and secure sensitive information such as cookies, passwords, and authentication tokens.

When a process attempts to decrypt DPAPI-secured data, it generates a specific event in the Windows Event Log. Monitoring for these events can detect when a malicious process is trying to steal browser data.

The DataDescription field, for instance, indicates the type of data being decrypted. Since each Chromium-based browser tags its data with the product name (e.g., Google Chrome or Microsoft Edge), it is possible to distinguish browser data from other DPAPI-secured data.

When a process attempts to decrypt browser data, two key events are generated in the Windows Event Logs:

1. Event 16385: This event indicates that a process is decrypting a specific browser’s key, identified by the “DataDescription” field (e.g., “Google Chrome”).
2. Event 4688: This event provides information about the process performing the decryption, including the process ID.

The event generated by the decryption attempt, Event ID 16385, contains several pieces of information that can be used to identify the nature of the attempt.

By correlating these two events, system administrators or endpoint detection agents can determine whether the decryption attempt is legitimate (i.e., performed by the browser itself) or potentially malicious (i.e., performed by an unauthorized process).

Google has tested this method using a public script to decrypt passwords taken from a public blog.

The script generated two events, as expected: the 16385 event, showing that a process was decrypting the “Google Chrome” key, and the 4688 event, which revealed the process ID of the script.

The provided content outlines a method for enabling system logging to detect unauthorized access to DPAPI (Data Protection API) activities, specifically targeting the decryption of browser data like passwords.

Here’s a concise summary of the steps involved:

Enable Logging:

Activate “Audit DPAPI Activity” within the system’s security settings to log DPAPI events, particularly event ID 4693 in the Security Log and a new event ID 16385 in the Debug channel.

The 4693 event looks like:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{...}" />
    <EventID>4693</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13314</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2015-08-22T06:25:14.589407700Z" />
    <EventRecordID>175809</EventRecordID>
    <Correlation />
    <Execution ProcessID="520" ThreadID="1340" />
    <Channel>Security</Channel>
    <Computer>DC01.contoso.local</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-21-3457937927-2839227994-823803824-1104</Data>
    <Data Name="SubjectUserName">dadmin</Data>
    <Data Name="SubjectDomainName">CONTOSO</Data>
    <Data Name="SubjectLogonId">0x30d7c</Data>
    <Data Name="MasterKeyId">0445c766-75f0-4de7-82ad-d9d97aad59f6</Data>
    <Data Name="RecoveryReason">0x5c005c</Data>
    <Data Name="RecoveryServer">DC01.contoso.local</Data>
    <Data Name="RecoveryKeyId" />
    <Data Name="FailureId">0x380000</Data>
  </EventData>
</Event>

A 16385 event looks like this:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Crypto-DPAPI" Guid="{...}" />
    <EventID>16385</EventID>
    <Version>0</Version>
    <Level>4</Level>
    <Task>64</Task>
    <Opcode>0</Opcode>
    <Keywords>0x2000000000000040</Keywords>
    <TimeCreated SystemTime="2024-03-28T20:06:42.1772585Z" />
    <EventRecordID>826993</EventRecordID>
    <Correlation ActivityID="{777bf68d-7757-0028-b5f6-7b775777da01}" />
    <Execution ProcessID="1392" ThreadID="57108" />
    <Channel>Microsoft-Windows-Crypto-DPAPI/Debug</Channel>
    <Computer>WIN-GG82ULGC9GO.contoso.local</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <EventData>
    <Data Name="OperationType">SPCryptUnprotect</Data>
    <Data Name="DataDescription">Google Chrome</Data>
    <Data Name="MasterKeyGUID">{4df0861b-07ea-49f4-9a09-1d66fd1131c3}</Data>
    <Data Name="Flags">0</Data>
    <Data Name="ProtectionFlags">16</Data>
    <Data Name="ReturnValue">0</Data>
    <Data Name="CallerProcessStartKey">32651097299526713</Data>
    <Data Name="CallerProcessID">97964</Data>
    <Data Name="CallerProcessCreationTime">133561300019253302</Data>
    <Data Name="PlainTextDataSize">32</Data>
  </EventData>
</Event>

Collect Events:

• Focus on collecting two specific event types from the logs:
• Event 16385 from the Debug log, detailing DPAPI operations.
• Event 4688 from the Security log, indicating process creation.

Write Detection Logic:

Develop logic to map process IDs from event 4688 to active processes and cross-reference these with the process IDs from event 16385. This helps identify unauthorized applications attempting to decrypt data.

Test the System:

Implement a test scenario using a known script (e.g., a Python script for password stealing) to ensure the system correctly logs and identifies unauthorized DPAPI access attempts.

This method leverages detailed event tracking and logging to safeguard sensitive data against unauthorized access and potential theft.

On-Demand Webinar to Secure the Top 3 SME Attack Vectors: Watch for Free