2
May
2024
How 4 small businesses are using Google tools to succeed
From Google Ads to Gemini, small businesses across the country use Google tools to reach customers, grow their client base and so much more.
2
May
2024
Google Meet increases support for ultra-low latency live streaming to the first 25,000 viewers
What’s changing For Google Workspace editions that support 100,000 viewers, we’re increasing the availability of the Google Meet ultra-low latency viewing experience for live streamed meetings from the first 10,000 viewers to the first 25,000 view...
2
May
2024
4 tips on getting the most out of Pixel 8 Pro’s Video Boost
Learn more about how we developed Pixel 8 Pro’s Video Boost feature as well as tips on how to use it.
2
May
2024
Passkeys, Cross-Account Protection and new ways we’re protecting your accounts
For World Password Day, we’re sharing updates to passkeys across our products and sharing more ways we’re keeping people safe online.
2
May
2024
Your Google Account allows you to create passkeys on your phone, computer and security keys
Sriram Karra and Christiaan Brand, Google product managersLast year, Google launched passkey support for Google Accounts. Passkeys are a new industry standard that give users an easy, highly secure way to sign-in to apps and websites. Today, we announc...
2
May
2024
Available in open beta: Build AppSheet automations using Google Forms
This announcement was part of Google Cloud Next ‘24. Visit the Workspace Blog to learn more about the next wave of innovations in Workspace, including enhancements to Gemini for Google Workspace.What’s changing
AppSheet helps users automate manual work...
AppSheet helps users automate manual work...
1
May
2024
Google Ads API Resource Usage Policy Update
What's changing?
We are updating the Google Ads API resource usage policy to throttle GoogleAdsService.Search and GoogleAdsService.SearchStream query patterns that consume excessive amounts of API resources. If a particular query pattern is throttl...
We are updating the Google Ads API resource usage policy to throttle GoogleAdsService.Search and GoogleAdsService.SearchStream query patterns that consume excessive amounts of API resources. If a particular query pattern is throttl...
1
May
2024
Get ready for Google I/O: Program lineup revealed
Posted by Timothy Jordan – Director, Developer Relations and Open Source
Developers, get ready! Google I/O is just around the corner, kicking off live from Mountain View with the Google keynote on Tuesday, May 14 at 10 am PT, followed by the De...
1
May
2024
Our ongoing efforts to support mental health
May is Mental Health Awareness Month in the U.S. Here’s a look at how Google continues to support people in times of need.
1
May
2024
A new Mother’s Day gift experience on Google Search
We’re making it easier to find Mother’s Day gifts with a new shopping experience.
1
May
2024
4 new ways to enjoy reading with Google Play Books
Google Play Books celebrates reading with no-charge ebooks and digital stickers for kids, a new “Upcoming” section and audiobook previews on YouTube.
1
May
2024
May is for .dev-elopers
We’re celebrating five years since the launch of the .dev top-level domain with five exciting .dev websites and a special offer from our registrar partners.
1
May
2024
Evolving Health on Android: Migrating from Google Fit APIs to Android Health
Posted by Chris Wilk – Senior Product Manager, Android Health
At Google, we're committed to empowering developers to create innovative health and fitness experiences on Android. Over the past few years, we've been investing heavily in establishi...
1
May
2024
Configure managed iOS apps for your users using Google Mobile Device Management
What’s changing Directly from the Admin console, admins can remotely set custom configs for managed iOS apps on end-user devices for their enterprise using Google Mobile Device Management. Managed configurations are applied using XML property list...
1
May
2024
Gemini in Android Studio and more: Android Studio Jellyfish is Stable!
Posted by Paris Hsu – Product Manager, Android Studio
Android Studio Jellyfish (2023.3.1) is making waves with its official stable release! 🪼🌊 Dive into cutting-edge AI features like Gemini in Android Studio, seamless Google services integrations...
30
Apr
2024
Detecting browser data theft using Windows Event Logs
Posted by Will Harris, Chrome Security Team
Chromium's sandboxed process model defends well from malicious web content, but there are limits to how well the application can protect itself from malware already on the computer. Cookies and other credentials remain a high value target for attackers, and we are trying to tackle this ongoing threat in multiple ways, including working on web standards like
DBSC
that will help disrupt the cookie theft industry since exfiltrating these cookies will no longer have any value.
Where it is not possible to prevent the theft of credentials and cookies by malware, the next best thing is making the attack more observable by antivirus, endpoint detection agents, or enterprise administrators with basic log analysis tools.
This blog describes one set of signals for use by system administrators or endpoint detection agents that should reliably flag any access to the browser’s protected data from another application on the system. By increasing the likelihood of an attack being detected, this changes the calculus for those attackers who might have a strong desire to remain stealthy, and might cause them to rethink carrying out these types of attacks against our users.
Background
Chromium based browsers on Windows use the DPAPI (Data Protection API) to secure local secrets such as cookies, password etc. against theft. DPAPI protection is based on a key derived from the user's login credential and is designed to protect against unauthorized access to secrets from other users on the system, or when the system is powered off. Because the DPAPI secret is bound to the logged in user, it cannot protect against local malware attacks — malware executing as the user or at a higher privilege level can just call the same APIs as the browser to obtain the DPAPI secret.
Since 2013, Chromium has been applying the CRYPTPROTECT_AUDIT flag to DPAPI calls to request that an audit log be generated when decryption occurs, as well as tagging the data as being owned by the browser. Because all of Chromium's encrypted data storage is backed by a DPAPI-secured key, any application that wishes to decrypt this data, including malware, should always reliably generate a clearly observable event log, which can be used to detect these types of attacks.
There are three main steps involved in taking advantage of this log:
Enable logging on the computer running Google Chrome, or any other Chromium based browser.
Export the event logs to your backend system.
Create detection logic to detect theft.
This blog will also show how the logging works in practice by testing it against a python password stealer.
Step 1: Enable logging on the system
DPAPI events are logged into two places in the system. Firstly, there is the
4693 event that can be logged into the Security Log. This event can be enabled by turning on "Audit DPAPI Activity" and the steps to do this are described
here, the policy itself sits deep within Security Settings -> Advanced Audit Policy Configuration -> Detailed Tracking.
Here is what 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>
The issue with the 4693 event is that while it is generated if there is DPAPI activity on the system, it unfortunately does not contain information about which process was performing the DPAPI activity, nor does it contain information about which particular secret is being accessed. This is because the
Execution ProcessID
field in the event will always be the process id of lsass.exe because it is this process that manages the encryption keys for the system, and there is no entry for the description of the data.
It was for this reason that, in recent versions of Windows a new event type was added to help identify the process making the DPAPI call directly. This event was added to the
Microsoft-Windows-Crypto-DPAPI
stream which manifests in the Event Log in the Applications and Services Logs > Microsoft > Windows > Crypto-DPAPI part of the Event Viewer tree.
The new event is called
DPAPIDefInformationEvent
and has id 16385, but unfortunately is only emitted to the Debug channel and by default this is not persisted to an Event Log, unless Debug channel logging is enabled. This can be accomplished by enabling it directly in powershell:
$log = `
 New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration `
 Microsoft-Windows-Crypto-DPAPI/Debug
$log.IsEnabled = $True
$log.SaveChanges()

Once this log is enabled then you should start to see 16385 events generated, and these will contain the real process ids of applications performing DPAPI operations. Note that 16385 events are emitted by the operating system even for data not flagged with CRYPTPROTECT_AUDIT, but to identify the data as owned by the browser, the data description is essential. 16385 events are described later.
You will also want to enable
Audit Process Creation in order to be able to know a current mapping of process ids to process names — more details on that later. You might want to also consider enabling logging of
full command lines.
Step 2: Collect the events
The events you want to collect are:
From Security log:
4688: "A new process was created."
From Microsoft-Windows-Crypto-DPAPI/Debug log: (enabled above)
16385: "DPAPIDefInformationEvent"
These should be collected from all workstations, and persisted into your enterprise logging system for analysis.
Step 3: Write detection logic to detect theft.
With these two events is it now possible to detect when an unauthorized application calls into DPAPI to try and decrypt browser secrets.
The general approach is to generate a map of process ids to active processes using the 4688 events, then every time a 16385 event is generated, it is possible to identify the currently running process, and alert if the process does not match an authorized application such as Google Chrome. You might find your enterprise logging software can already keep track of which process ids map to which process names, so feel free to just use that existing functionality.
Let's dive deeper into the events.
A 4688 event looks like this - e.g. here is Chrome browser launching from explorer:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
 <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{...}" />
 <EventID>4688</EventID>
 <Version>2</Version>
 <Level>0</Level>
 <Task>13312</Task>
 <Opcode>0</Opcode>
 <Keywords>0x8020000000000000</Keywords>
 <TimeCreated SystemTime="2024-03-28T20:06:41.9254105Z" />
 <EventRecordID>78258343</EventRecordID>
 <Correlation />
 <Execution ProcessID="4" ThreadID="54256" />
 <Channel>Security</Channel>
 <Computer>WIN-GG82ULGC9GO.contoso.local</Computer>
 <Security />
 </System>
 <EventData>
 <Data Name="SubjectUserSid">S-1-5-18</Data>
 <Data Name="SubjectUserName">WIN-GG82ULGC9GO$</Data>
 <Data Name="SubjectDomainName">CONTOSO</Data>
 <Data Name="SubjectLogonId">0xe8c85cc</Data>
 <Data Name="NewProcessId">0x17eac</Data>
 <Data Name="NewProcessName">C:\Program Files\Google\Chrome\Application\chrome.exe</Data>
 <Data Name="TokenElevationType">%%1938</Data>
 <Data Name="ProcessId">0x16d8</Data>
 <Data Name="CommandLine">"C:\Program Files\Google\Chrome\Application\chrome.exe" </Data>
 <Data Name="TargetUserSid">S-1-0-0</Data>
 <Data Name="TargetUserName">-</Data>
 <Data Name="TargetDomainName">-</Data>
 <Data Name="TargetLogonId">0x0</Data>
 <Data Name="ParentProcessName">C:\Windows\explorer.exe</Data>
 <Data Name="MandatoryLabel">S-1-16-8192</Data>
 </EventData>
</Event>

The important part here is the
NewProcessId, in hex
0x17eac
which is
97964.
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>

The important parts here are the
OperationType, the
DataDescription
and the
CallerProcessID.
For DPAPI decrypts, the
OperationType
will be SPCryptUnprotect.
Each Chromium based browser will tag its data with the product name, e.g. Google Chrome, or Microsoft Edge depending on the owner of the data. This will always appear in the
DataDescription
field, so it is possible to distinguish browser data from other DPAPI secured data.
Finally, the
CallerProcessID
will map to the process performing the decryption. In this case, it is 97964 which matches the process ID seen in the 4688 event above, showing that this was likely Google Chrome decrypting its own data! Bear in mind that since these logs only contain the path to the executable, for a full assurance that this is actually Chrome (and not malware pretending to be Chrome, or malware injecting into Chrome), additional protections such as removing administrator access, and application allowlisting could also be used to give a higher assurance of this signal. In recent versions of Chrome or Edge, you might also see logs of decryptions happening in the elevation_service.exe process, which is another legitimate part of the browser's data storage.
To detect unauthorized DPAPI access, you will want to generate a running map of all processes using 4688 events, then look for 16385 events that have a CallerProcessID that does not match a valid caller – Let's try that now.
Testing with a python password stealer
We can test that this works with a public script to decrypt passwords taken from
a public blog. It generates two events, as expected:
Here is the 16385 event, showing that a process is decrypting the "Google Chrome" key.
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
 < ... >
 <EventID>16385</EventID>
 < ... >
 <TimeCreated SystemTime="2024-03-28T20:28:13.7891561Z" />
 < ... >
 </System>
 <EventData>
 <Data Name="OperationType">SPCryptUnprotect</Data>
 <Data Name="DataDescription">Google Chrome</Data>
 < ... >
 <Data Name="CallerProcessID">68768</Data>
 <Data Name="CallerProcessCreationTime">133561312936527018</Data>
 <Data Name="PlainTextDataSize">32</Data>
 </EventData>
</Event>
Since the data description being decrypted was "Google Chrome" we know this is an attempt to read Chrome secrets, but to determine the process behind 68768 (0x10ca0), we need to correlate this with a 4688 event.
Here is the corresponding 4688 event from the Security Log (a process start for python3.exe) with the matching process id:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
 < ... >
 <EventID>4688</EventID>
 < ... >
 <TimeCreated SystemTime="2024-03-28T20:28:13.6527871Z" />
 < ... >
 </System>
 <EventData>
 < ... >
 <Data Name="NewProcessId">0x10ca0</Data>
 <Data Name="NewProcessName">C:\python3\bin\python3.exe</Data>
 <Data Name="TokenElevationType">%%1938</Data>
 <Data Name="ProcessId">0xca58</Data>
 <Data Name="CommandLine">"c:\python3\bin\python3.exe" steal_passwords.py</Data>
 < ... >
 <Data Name="ParentProcessName">C:\Windows\System32\cmd.exe</Data>
 </EventData>
</Event>
In this case, the process id matches the python3 executable running a potentially malicious script, so we know this is likely very suspicious behavior, and should trigger an alert immediately! Bear in mind process ids on Windows are not unique so you will want to make sure you use the 4688 event with the timestamp closest, but earlier than, the 16385 event.
Summary
This blog has described a technique for strong detection of cookie and credential theft. We hope that all defenders find this post useful. Thanks to Microsoft for adding the DPAPIDefInformationEvent log type, without which this would not be possible.
Chromium's sandboxed process model defends well from malicious web content, but there are limits to how well the application can protect itself from malware already on the computer. Cookies and other credentials remain a high value target for attackers, and we are trying to tackle this ongoing threat in multiple ways, including working on web standards like
DBSC
that will help disrupt the cookie theft industry since exfiltrating these cookies will no longer have any value.
Where it is not possible to prevent the theft of credentials and cookies by malware, the next best thing is making the attack more observable by antivirus, endpoint detection agents, or enterprise administrators with basic log analysis tools.
This blog describes one set of signals for use by system administrators or endpoint detection agents that should reliably flag any access to the browser’s protected data from another application on the system. By increasing the likelihood of an attack being detected, this changes the calculus for those attackers who might have a strong desire to remain stealthy, and might cause them to rethink carrying out these types of attacks against our users.
Background
Chromium based browsers on Windows use the DPAPI (Data Protection API) to secure local secrets such as cookies, password etc. against theft. DPAPI protection is based on a key derived from the user's login credential and is designed to protect against unauthorized access to secrets from other users on the system, or when the system is powered off. Because the DPAPI secret is bound to the logged in user, it cannot protect against local malware attacks — malware executing as the user or at a higher privilege level can just call the same APIs as the browser to obtain the DPAPI secret.
Since 2013, Chromium has been applying the CRYPTPROTECT_AUDIT flag to DPAPI calls to request that an audit log be generated when decryption occurs, as well as tagging the data as being owned by the browser. Because all of Chromium's encrypted data storage is backed by a DPAPI-secured key, any application that wishes to decrypt this data, including malware, should always reliably generate a clearly observable event log, which can be used to detect these types of attacks.
There are three main steps involved in taking advantage of this log:
Enable logging on the computer running Google Chrome, or any other Chromium based browser.
Export the event logs to your backend system.
Create detection logic to detect theft.
This blog will also show how the logging works in practice by testing it against a python password stealer.
Step 1: Enable logging on the system
DPAPI events are logged into two places in the system. Firstly, there is the
4693 event that can be logged into the Security Log. This event can be enabled by turning on "Audit DPAPI Activity" and the steps to do this are described
here, the policy itself sits deep within Security Settings -> Advanced Audit Policy Configuration -> Detailed Tracking.
Here is what 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>
The issue with the 4693 event is that while it is generated if there is DPAPI activity on the system, it unfortunately does not contain information about which process was performing the DPAPI activity, nor does it contain information about which particular secret is being accessed. This is because the
Execution ProcessID
field in the event will always be the process id of lsass.exe because it is this process that manages the encryption keys for the system, and there is no entry for the description of the data.
It was for this reason that, in recent versions of Windows a new event type was added to help identify the process making the DPAPI call directly. This event was added to the
Microsoft-Windows-Crypto-DPAPI
stream which manifests in the Event Log in the Applications and Services Logs > Microsoft > Windows > Crypto-DPAPI part of the Event Viewer tree.
The new event is called
DPAPIDefInformationEvent
and has id 16385, but unfortunately is only emitted to the Debug channel and by default this is not persisted to an Event Log, unless Debug channel logging is enabled. This can be accomplished by enabling it directly in powershell:
$log = `
 New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration `
 Microsoft-Windows-Crypto-DPAPI/Debug
$log.IsEnabled = $True
$log.SaveChanges()

Once this log is enabled then you should start to see 16385 events generated, and these will contain the real process ids of applications performing DPAPI operations. Note that 16385 events are emitted by the operating system even for data not flagged with CRYPTPROTECT_AUDIT, but to identify the data as owned by the browser, the data description is essential. 16385 events are described later.
You will also want to enable
Audit Process Creation in order to be able to know a current mapping of process ids to process names — more details on that later. You might want to also consider enabling logging of
full command lines.
Step 2: Collect the events
The events you want to collect are:
From Security log:
4688: "A new process was created."
From Microsoft-Windows-Crypto-DPAPI/Debug log: (enabled above)
16385: "DPAPIDefInformationEvent"
These should be collected from all workstations, and persisted into your enterprise logging system for analysis.
Step 3: Write detection logic to detect theft.
With these two events is it now possible to detect when an unauthorized application calls into DPAPI to try and decrypt browser secrets.
The general approach is to generate a map of process ids to active processes using the 4688 events, then every time a 16385 event is generated, it is possible to identify the currently running process, and alert if the process does not match an authorized application such as Google Chrome. You might find your enterprise logging software can already keep track of which process ids map to which process names, so feel free to just use that existing functionality.
Let's dive deeper into the events.
A 4688 event looks like this - e.g. here is Chrome browser launching from explorer:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
 <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{...}" />
 <EventID>4688</EventID>
 <Version>2</Version>
 <Level>0</Level>
 <Task>13312</Task>
 <Opcode>0</Opcode>
 <Keywords>0x8020000000000000</Keywords>
 <TimeCreated SystemTime="2024-03-28T20:06:41.9254105Z" />
 <EventRecordID>78258343</EventRecordID>
 <Correlation />
 <Execution ProcessID="4" ThreadID="54256" />
 <Channel>Security</Channel>
 <Computer>WIN-GG82ULGC9GO.contoso.local</Computer>
 <Security />
 </System>
 <EventData>
 <Data Name="SubjectUserSid">S-1-5-18</Data>
 <Data Name="SubjectUserName">WIN-GG82ULGC9GO$</Data>
 <Data Name="SubjectDomainName">CONTOSO</Data>
 <Data Name="SubjectLogonId">0xe8c85cc</Data>
 <Data Name="NewProcessId">0x17eac</Data>
 <Data Name="NewProcessName">C:\Program Files\Google\Chrome\Application\chrome.exe</Data>
 <Data Name="TokenElevationType">%%1938</Data>
 <Data Name="ProcessId">0x16d8</Data>
 <Data Name="CommandLine">"C:\Program Files\Google\Chrome\Application\chrome.exe" </Data>
 <Data Name="TargetUserSid">S-1-0-0</Data>
 <Data Name="TargetUserName">-</Data>
 <Data Name="TargetDomainName">-</Data>
 <Data Name="TargetLogonId">0x0</Data>
 <Data Name="ParentProcessName">C:\Windows\explorer.exe</Data>
 <Data Name="MandatoryLabel">S-1-16-8192</Data>
 </EventData>
</Event>

The important part here is the
NewProcessId, in hex
0x17eac
which is
97964.
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>

The important parts here are the
OperationType, the
DataDescription
and the
CallerProcessID.
For DPAPI decrypts, the
OperationType
will be SPCryptUnprotect.
Each Chromium based browser will tag its data with the product name, e.g. Google Chrome, or Microsoft Edge depending on the owner of the data. This will always appear in the
DataDescription
field, so it is possible to distinguish browser data from other DPAPI secured data.
Finally, the
CallerProcessID
will map to the process performing the decryption. In this case, it is 97964 which matches the process ID seen in the 4688 event above, showing that this was likely Google Chrome decrypting its own data! Bear in mind that since these logs only contain the path to the executable, for a full assurance that this is actually Chrome (and not malware pretending to be Chrome, or malware injecting into Chrome), additional protections such as removing administrator access, and application allowlisting could also be used to give a higher assurance of this signal. In recent versions of Chrome or Edge, you might also see logs of decryptions happening in the elevation_service.exe process, which is another legitimate part of the browser's data storage.
To detect unauthorized DPAPI access, you will want to generate a running map of all processes using 4688 events, then look for 16385 events that have a CallerProcessID that does not match a valid caller – Let's try that now.
Testing with a python password stealer
We can test that this works with a public script to decrypt passwords taken from
a public blog. It generates two events, as expected:
Here is the 16385 event, showing that a process is decrypting the "Google Chrome" key.
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
 < ... >
 <EventID>16385</EventID>
 < ... >
 <TimeCreated SystemTime="2024-03-28T20:28:13.7891561Z" />
 < ... >
 </System>
 <EventData>
 <Data Name="OperationType">SPCryptUnprotect</Data>
 <Data Name="DataDescription">Google Chrome</Data>
 < ... >
 <Data Name="CallerProcessID">68768</Data>
 <Data Name="CallerProcessCreationTime">133561312936527018</Data>
 <Data Name="PlainTextDataSize">32</Data>
 </EventData>
</Event>
Since the data description being decrypted was "Google Chrome" we know this is an attempt to read Chrome secrets, but to determine the process behind 68768 (0x10ca0), we need to correlate this with a 4688 event.
Here is the corresponding 4688 event from the Security Log (a process start for python3.exe) with the matching process id:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
 < ... >
 <EventID>4688</EventID>
 < ... >
 <TimeCreated SystemTime="2024-03-28T20:28:13.6527871Z" />
 < ... >
 </System>
 <EventData>
 < ... >
 <Data Name="NewProcessId">0x10ca0</Data>
 <Data Name="NewProcessName">C:\python3\bin\python3.exe</Data>
 <Data Name="TokenElevationType">%%1938</Data>
 <Data Name="ProcessId">0xca58</Data>
 <Data Name="CommandLine">"c:\python3\bin\python3.exe" steal_passwords.py</Data>
 < ... >
 <Data Name="ParentProcessName">C:\Windows\System32\cmd.exe</Data>
 </EventData>
</Event>
In this case, the process id matches the python3 executable running a potentially malicious script, so we know this is likely very suspicious behavior, and should trigger an alert immediately! Bear in mind process ids on Windows are not unique so you will want to make sure you use the 4688 event with the timestamp closest, but earlier than, the 16385 event.
Summary
This blog has described a technique for strong detection of cookie and credential theft. We hope that all defenders find this post useful. Thanks to Microsoft for adding the DPAPIDefInformationEvent log type, without which this would not be possible.
30
Apr
2024
Updated keyboard shortcuts and first-letters navigation now available on Google Drive web
What’s changing Google Drive is designed to work with keyboards, screen readers, braille devices, screen magnification, and more. Today, we’re excited to improve the accessibility of Google Drive by enabling first-letters navigation. First-le...
30
Apr
2024
April 2024 update to Display & Video 360 API
Today we’re announcing the April 2024 update to the Display & Video 360 API. This update includes:
Support for additional key performance indicator (KPI) types.
Targeting support for new AppPlatform and Exchange values.
The addition of a new YouTub...
29
Apr
2024
Jetpack Compose compiler moving to the Kotlin repository
Posted by Ben Trengrove - Developer Relations Engineer, Nick Butcher - Product Manager for Jetpack Compose
We are excited to announce that with the upcoming release of Kotlin 2.0, the Jetpack Compose compiler will move to the Kotlin repository....
29
Apr
2024
How we fought bad apps and bad actors in 2023
Posted by Steve Kafka and Khawaja Shams (Android Security and Privacy Team), and Mohet Saxena (Play Trust and Safety)
A safe and trusted Google Play experience is our top priority. We leverage our SAFE (see below) principles to provide the framework ...
A safe and trusted Google Play experience is our top priority. We leverage our SAFE (see below) principles to provide the framework ...
29
Apr
2024
Google Workspace Updates Weekly Recap – April 26, 2024
3 New updatesUnless otherwise indicated, the features below are available to all Google Workspace customers, and are fully launched or in the process of rolling out. Rollouts should take no more than 15 business days to complete if launching to both&nb...
26
Apr
2024
Accelerating incident response using generative AI
Lambert Rosique and Jan Keller, Security Workflow Automation, and Diana Kramer, Alexandra Bowen and Andrew Cho, Privacy and Security Incident ResponseIntroductionAs security professionals, we're constantly looking for ways to reduce risk and improve ou...
26
Apr
2024
Workspace Data Protection rules are now available for Gmail in Beta
What’s changing Launching first to beta, we’re introducing data loss prevention rules for Gmail. Data protection rules help admins and security experts build a stronger framework around sensitive data to prevent personal or proprietary information...
26
Apr
2024
Get notified about application load failures for your Google Meet Hardware devices
What’s changing As part of an ongoing series of improvements for managing Google Meet hardware devices, we recently announced that we would begin capturing application load failures across Meet hardware devices. Beginning today, you can now opt-in...
26
Apr
2024
Import data from Slack to Google Chat using CloudFuze
What’s changingWe recently announced the ability to import data from other messaging platforms using the Google Chat API. To build upon this, we’re excited to announce a new migration solution from CloudFuze that enables you to import data from Slack i...
26
Apr
2024
Seamlessly transfer between devices during a Google Meet call
What’s changingIn today's world, getting our work done can happen from many locations, across many devices. Beginning today, you can smoothly transfer between devices while on a Google Meet call without hanging up and rejoining. For example, if you wer...
24
Apr
2024
Announcing v16_1 of the Google Ads API
Today, we’re announcing the v16_1 release of the Google Ads API. To use some of the v16_1 features, upgrade your client libraries and client code. The updated client libraries and code examples will be published next week. This version has no breakin...
24
Apr
2024
Client-side encryption can now be selected as a data loss prevention condition
What’s changing You can now use client-side encryption as a condition for a data loss prevention (DLP) rule. As with other DLP rules, you’ll be able to configure: If users are warned before sharing externally. If users are blocked from s...
24
Apr
2024
Uncovering potential threats to your web application by leveraging security reports
Posted by Yoshi Yamaguchi, Santiago Díaz, Maud Nalpas, Eiji Kitamura, DevRel team
The Reporting API is an emerging web standard that provides a generic reporting mechanism for issues occurring on the browsers visiting your production website. The re...
The Reporting API is an emerging web standard that provides a generic reporting mechanism for issues occurring on the browsers visiting your production website. The re...
23
Apr
2024
External participants can now join Google Meet client-side encrypted calls
What’s changing We’re enhancing the experience for client-side encrypted Google Meet calls to include support for inviting external participants, including users without a Google account. Admins will need to turn on access for external participant...
23
Apr
2024
Google Workspace Updates Weekly Recap – April 19, 2024
1 New updateUnless otherwise indicated, the features below are available to all Google Workspace customers, and are fully launched or in the process of rolling out. Rollouts should take no more than 15 business days to complete if launching to both&nbs...
19
Apr
2024
Now generally available: Chat interoperability between Google Chat and other messaging platforms
This announcement was part of Google Cloud Next ‘24. Visit the Workspace Blog to learn more about the next wave of innovations in Workspace, including enhancements to Gemini for Google Workspace.What’s changingAt Google Cloud Next 2023, we announced in...
18
Apr
2024
Google Chat apps can now subscribe to event notifications
This announcement was part of Google Cloud Next ‘24. Visit the Workspace Blog to learn more about the next wave of innovations in Workspace, including enhancements to Gemini for Google Workspace.What’s changingGoogle Workspace developers registered in ...
18
Apr
2024
Promote space members to space managers using the Google Chat API
This announcement was part of Google Cloud Next ‘24. Visit the Workspace Blog to learn more about the next wave of innovations in Workspace, including enhancements to Gemini for Google Workspace.What’s changingLast year, we announced the ability to cre...
18
Apr
2024
Available in beta: automatically log Google Voice calls made to Salesforce contacts
What’s changing Launching in beta, we’re introducing an integration between Google Voice and Salesforce that makes it easier to track details of calls made in Voice. When enabled: Salesforce contacts will be displayed in Google Voice. Go...
18
Apr
2024
Prevent Generative AI Data Leaks with Chrome Enterprise DLP
Posted Kaleigh Rosenblat, Chrome Enterprise Senior Staff Software Engineer, Security Lead
Generative AI has emerged as a powerful and popular tool to automate content creation and simple tasks. From customized content creation to source code generat...
Generative AI has emerged as a powerful and popular tool to automate content creation and simple tasks. From customized content creation to source code generat...
18
Apr
2024
Use annotations to enhance your presentations in Google Meet
What’s changing We’re excited to introduce annotation tools in Google Meet. Presenters and their appointed co-annotators can use these tools to highlight content or make other notations over presented content.
Annotations will be on by default wh...
Annotations will be on by default wh...
18
Apr
2024
Google Ads API v14 sunset reminder
Google Ads API v14 will sunset on June 5, 2024. After this date, all v14 API requests will begin to fail. Migrate to a newer version prior to June 5, 2024 to ensure your API access is unaffected.
Here are some resources to help you with the migration:...
Here are some resources to help you with the migration:...
18
Apr
2024
How to effectively A/B test power consumption for your Android app’s features
Posted by Mayank Jain - Product Manager, and Yasser Dbeis - Software Engineer; Android Studio
Android developers have been telling us they're looking for tools to help optimize power consumption for different devices on Android.
The new Power P...
17
Apr
2024
Launch the FigJam whiteboard app directly from Google Meet Series One Board 65 and Desk 27 devices
What’s changing Since September 2023, Workspace users have enjoyed the convenience of launching FigJam, Figma’s free online whiteboard, directly in Google Meet. We’re excited to announce that you can now launch FigJam both in and out of an active ...
16
Apr
2024
Dark mode now available in Google Drive web
What’s changingToday, we’re introducing a highly requested feature: Dark mode in Drive on web. This new setting aims to provide you with a more comfortable, customizable viewing experience for Drive. Getting started Admins: There is no admin ...
16
Apr
2024
Build a Dialogflow CX Google Chat app that understands and responds with natural language
This announcement was part of Google Cloud Next ‘24. Visit the Workspace Blog to learn more about the next wave of innovations in Workspace, including enhancements to Gemini for Google Workspace.What’s changing
Earlier this year, we intr...
Earlier this year, we intr...
16
Apr
2024
Improving Search Console ownership token management
This post discusses an update to Search Console's user and permissions to improve the
accuracy and reflect the actual state of unused ownership tokens.
16
Apr
2024
Google Workspace Updates Weekly Recap – April 12, 2024
2 New updatesUnless otherwise indicated, the features below are available to all Google Workspace customers, and are fully launched or in the process of rolling out. Rollouts should take no more than 15 business days to complete if launching to both&nb...
12
Apr
2024
The First Beta of Android 15
Posted by Dave Burke, VP of Engineering
Today we're releasing the first beta of Android 15. With the progress we've made refining the features and stability of Android 15, it's time to open the experience up to both developers and early adopter...
11
Apr
2024
Changes to displaying the “deprovisioned” status for Google Meet hardware devices
What’s changing Back in 2021, we introduced the “enrollment privilege”, which restricts who in your organization can enroll or re-enroll Google Meet hardware devices. Prior to introducing this privilege, Admins had to put devices in a “deprovision...
10
Apr
2024
Google Drive cut code and development time in half with Jetpack Compose and new architecture
Posted by Nick Butcher – Product Manager for Jetpack Compose, and Florina Muntenescu – Developer Relations Engineer
As one of the world’s most popular cloud-based storage services, Google Drive lets people do more than just store their files on...
9
Apr
2024
Protect sensitive admin actions with multi-party approvals
This announcement was part of Google Cloud Next ‘24. Visit the Workspace Blog to learn more about the next wave of innovations in Workspace, including enhancements to Gemini for Google Workspace.
What’s changingTo protect our customers from malicious a...
What’s changingTo protect our customers from malicious a...
9
Apr
2024
Introducing the AI Meetings and Messaging for Google Workspace add-on
This announcement was part of Google Cloud Next ‘24. Visit the Workspace Blog to learn more about the next wave of innovations in Workspace, including enhancements to Gemini for Google Workspace.What’s changingAs we continue to expand our Gemini for Go...
9
Apr
2024
Introducing a new AI Security add-on for Google Workspace
This announcement was part of Google Cloud Next ‘24. Visit the Workspace Blog to learn more about the next wave of innovations in Workspace, including enhancements to Gemini for Google Workspace.What’s changingAs we continue to expand our Gemini for Go...
9
Apr
2024
Control your users’ access to new Gemini for Google Workspace features before general availability
This announcement was part of Google Cloud Next ‘24. Visit the Workspace Blog to learn more about the next wave of innovations in Workspace, including enhancements to Gemini for Google Workspace.What’s changingWe’re introducing a new setting in the Adm...
9
Apr
2024
Android Studio uses Gemini Pro to make Android development faster and easier
Posted by Sandhya Mohan – Product Manager, Android Studio
As part of the next chapter of our Gemini era, we announced we were bringing Gemini to more products. Today we’re excited to announce that Android Studio is using the Gemini 1.0 Pro model ...
8
Apr
2024
How we built the new Find My Device network with user security and privacy in mind
Posted by Dave Kleidermacher, VP Engineering, Android Security and Privacy
Keeping people safe and their data secure and private is a top priority for Android. That is why we took our time when designing the new Find My Device, which uses a crowdso...
Keeping people safe and their data secure and private is a top priority for Android. That is why we took our time when designing the new Find My Device, which uses a crowdso...
8
Apr
2024
5 ways to use the new Find My Device on Android
We’re sharing a few ways to use the new Find My Device experience on Android.
8
Apr
2024
Google Workspace Updates Weekly Recap – April 5, 2024
1 New updateUnless otherwise indicated, the features below are available to all Google Workspace customers, and are fully launched or in the process of rolling out. Rollouts should take no more than 15 business days to complete if launching to both&nbs...
5
Apr
2024
Assign the audit and investigation privilege on a per-application basis
What’s changingWhen delegating admin privileges for the Audit and Investigation Tool, you can now restrict access levels to audit data on a per application basis (eg: Admin, Drive logs etc.). This change ensures that access isn’t too broadly provisione...
4
Apr
2024
Content API for Shopping: Automatic Quota
The Content API for Shopping now automatically increases your products and accounts quotas as your account grows.
Because your API quota now changes dynamically, we have removed the static chart from our published limits guide. To check your curren...
2
Apr
2024
Google Workspace Updates Weekly Recap – March 29, 2024
New updates There are no new updates to share this week. Please see below for a recap of published announcements. Previous announcementsThe announcements below were published on the Workspace Updates blog earlier this week. Please refer to th...
29
Mar
2024
Migration to OpenRTB, deprecation of the Authorized Buyers Real-time Bidding Protocol
To align more closely with industry practices and embrace OpenRTB as the standard protocol,
Authorized Buyers Real-time Bidding protocol will sunset February 15th, 2025. Following this date, bid requests will no longer be sent to endpoints configured ...
29
Mar
2024