Our commitment to user safety is a top priority for Android. We’ve been consistently working to stay ahead of the world’s scammers, fraudsters and bad actors. And as their tactics evolve in sophistication and scale, we continually adapt and enhance our advanced security features and AI-powered protections to help keep Android users safe.

In addition to our new suite of advanced theft protection features to help keep your device and data safe in the case of theft, we’re also focusing increasingly on providing additional protections against mobile financial fraud and scams.

Today, we’re announcing more new fraud and scam protection features coming in Android 15 and Google Play services updates later this year to help better protect users around the world. We’re also sharing new tools and policies to help developers build safer apps and keep their users safe.

Google Play Protect live threat detection

Google Play Protect now scans 200 billion Android apps daily, helping keep more than 3 billion users safe from malware. We are expanding Play Protect’s on-device AI capabilities with Google Play Protect live threat detection to improve fraud and abuse detection against apps that try to cloak their actions.

With live threat detection, Google Play Protect’s on-device AI will analyze additional behavioral signals related to the use of sensitive permissions and interactions with other apps and services. If suspicious behavior is discovered, Google Play Protect can send the app to Google for additional review and then warn users or disable the app if malicious behavior is confirmed. The detection of suspicious behavior is done on device in a privacy preserving way through Private Compute Core, which allows us to protect users without collecting data. Google Pixel, Honor, Lenovo, Nothing, OnePlus, Oppo, Sharp, Transsion, and other manufacturers are deploying live threat detection later this year.

Stronger protections against fraud and scams

We’re also bringing additional protections to fight fraud and scams in Android 15 with two key enhancements to safeguard your information and privacy from bad apps:

• Protecting One-time Passwords from Malware: With the exception of a few types of apps, such as wearable companion apps, one-time passwords are now hidden from notifications, closing a common attack vector for fraud and spyware.
• Expanded Restricted Settings: To help protect more sensitive permissions that are commonly abused by fraudsters, we’re expanding Android 13’s restricted settings, which require additional user approval to enable permissions when installing an app from an Internet-sideloading source (web browsers, messaging apps or file managers).

We are continuing to develop new, AI-powered protections, like the scam call detection capability that we’re testing, which uses on-device Gemini-Nano AI to warn users in real-time when it detects conversation patterns commonly associated with fraud and scams.

Protecting against screen-sharing social engineering attacks

We’re also tightening controls for screen sharing in Android 15 to limit social engineering attacks that try to view your screen and steal information, while introducing new safeguards to further shield your sensitive information:

• Automatically Hidden Notifications and One-time Passwords (OTPs): During screen sharing, private notification content will be hidden, preventing remote viewers from seeing details in a user's notifications. Apps that post OTPs in notifications will be automatically protected from remote viewers when you’re screen sharing, helping thwart attempts to steal sensitive data.
• Safer Logins: Your screen will be hidden when you enter credentials like usernames, passwords and credit card numbers during a screen-share session.
• Choose What You Share: Currently available on Pixel, other Android devices will also have the ability to share just one app's content rather than your whole screen to help preserve your screen privacy.

Having clear content sharing indicators is important for users to understand when their data is visible. A new, more prominent screen indicator coming to Android devices later this year will always let you know when screen sharing is active, and you can stop sharing with a simple tap.

Advanced cellular security to fight fraud and surveillance

We’re adding new advanced cellular protections in Android 15 to defend against abuse by criminals using cell site simulators to snoop on users or send them SMS-based fraud messages.

• Cellular Cipher Transparency: We’ll notify you if your cellular network connection is unencrypted, potentially exposing voice and SMS traffic to radio interception, and potentially visible to others. This can help warn users if they’re being targeted by criminals who are trying to intercept their traffic or inject a fraud SMS message.
• Identifier Disclosure Transparency: We’ll help at risk-users like journalists or dissidents by alerting them if a potential false cellular base station or surveillance tool is recording their location using a device identifier.

These features require device OEM integration and compatible hardware. We are working with the Android ecosystem to bring these features to users. We expect OEM adoption to progress over the next couple of years.

More security tools for developers to fight fraud and scams

Safeguarding apps from scams and fraud is an ongoing battle for developers. The Play Integrity API lets developers check that their apps are unmodified and running on a genuine Android device so that they can detect fraudulent or risky behavior and take actions to prevent attacks and abuse. We’ve updated the API with new in-app signals to help developers secure their apps against new threats:

• Risk From Screen Capturing or Remote Access: Developers can check if there are other apps running that could be capturing the screen, creating overlays, or controlling the device. This is helpful for apps that want to hide sensitive information from other apps and protect users from scams.
• Risk From Known Malware: Developers can check if Google Play Protect is active and the user device is free of known malware before performing sensitive actions or handling sensitive data. This is particularly valuable for financial and banking apps, adding another layer of security to protect user information.
• Risk From Anomalous Devices: Developers can also opt-in to receive recent device activity to check if a device is making too many integrity checks, which could be a sign of an attack.

Developers can decide how their apps respond to these signals, such as prompting the user to close risky apps or turn on Google Play Protect before continuing.

Upgraded policies and tools for developers to enhance user privacy

We’re working to make photo permissions even more private for users. Starting this year, apps on Play must demonstrate that they require broad access to use the photo or video permissions. Google Play will start enforcing this policy in August. We’ve updated photo picker, Android’s preferred solution for granting individual access to photos and videos without requiring broad permissions. Photo picker now includes support for cloud storage services like Google Photos. It’s much easier to find the right photo by browsing albums and favorites. Coming later this year, photo picker will support local and cloud search as well.

Always evolving our multi-layered protections

Android's commitment to user safety is unwavering. We're constantly evolving our multi-layered user protections – combining the power of advanced AI with close partnerships across OEMs, the Android ecosystem, and the security research community. Building a truly secure Android experience is a collaborative effort, and we'll continue to work tirelessly to safeguard your device and data.

Google and Apple have worked together to create an industry specification – Detecting Unwanted Location Trackers – for Bluetooth tracking devices that makes it possible to alert users across both Android and iOS if such a device is unknowingly being used to track them. This will help mitigate the misuse of devices designed to help keep track of belongings. Google is now launching this capability on Android 6.0+ devices, and today Apple is implementing this capability in iOS 17.5.

With this new capability, Android users will now get a “Tracker traveling with you” alert on their device if an unknown Bluetooth tracking device is seen moving with them over time, regardless of the platform the device is paired with.

If a user gets such an alert on their Android device, it means that someone else’s AirTag, Find My Device network-compatible tracker tag, or other industry specification-compatible Bluetooth tracker is moving with them. Android users can view the tracker’s identifier, have the tracker play a sound to help locate it, and access instructions to disable it. Bluetooth tag manufacturers including Chipolo, eufy, Jio, Motorola, and Pebblebee have committed that future tags will be compatible.

Google’s Find My Device is secure by default and private by design. Multi-layered user protections, including first of its kind safety-first protections, help mitigate potential risks to user privacy and safety while allowing users to effectively locate and recover lost devices. This cross-platform collaboration — an industry first, involving community and industry input — offers instructions and best practices for manufacturers, should they choose to build unwanted tracking alert capabilities into their products. Google and Apple will continue to work with the Internet Engineering Task Force via the Detecting Unwanted Location Trackers working group to develop the official standard for this technology.

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:

1. Enable logging on the computer running Google Chrome, or any other Chromium based browser.
2. Export the event logs to your backend system.
3. 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:

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:

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:

The important part here is the NewProcessId, in hex 0x17eac which is 97964.

A 16385 event looks like this:

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.

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:

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.

A safe and trusted Google Play experience is our top priority. We leverage our SAFE (see below) principles to provide the framework to create that experience for both users and developers. Here's what these principles mean in practice:

• (S)afeguard our Users. Help them discover quality apps that they can trust.
• (A)dvocate for Developer Protection. Build platform safeguards to enable developers to focus on growth.
• (F)oster Responsible Innovation. Thoughtfully unlock value for all without compromising on user safety.
• (E)volve Platform Defenses. Stay ahead of emerging threats by evolving our policies, tools and technology.

With those principles in mind, we’ve made recent improvements and introduced new measures to continue to keep Google Play’s users safe, even as the threat landscape continues to evolve. In 2023, we prevented 2.28 million policy-violating apps from being published on Google Play¹ in part thanks to our investment in new and improved security features, policy updates, and advanced machine learning and app review processes. We have also strengthened our developer onboarding and review processes, requiring more identity information when developers first establish their Play accounts. Together with investments in our review tooling and processes, we identified bad actors and fraud rings more effectively and banned 333K bad accounts from Play for violations like confirmed malware and repeated severe policy violations.

Additionally, almost 200K app submissions were rejected or remediated to ensure proper use of sensitive permissions such as background location or SMS access. To help safeguard user privacy at scale, we partnered with SDK providers to limit sensitive data access and sharing, enhancing the privacy posture for over 31 SDKs impacting 790K+ apps. We also significantly expanded the Google Play SDK Index, which now covers the SDKs used in almost 6 million apps across the Android ecosystem. This valuable resource helps developers make better SDK choices, boosts app quality and minimizes integration risks.

Protecting the Android Ecosystem

Building on our success with the App Defense Alliance (ADA), we partnered with Microsoft and Meta as steering committee members in the newly restructured ADA under the Joint Development Foundation, part of the Linux Foundation family. The Alliance will support industry-wide adoption of app security best practices and guidelines, as well as countermeasures against emerging security risks.

Additionally, we announced new Play Store transparency labeling to highlight VPN apps that have completed an independent security review through App Defense Alliance’s Mobile App Security Assessment (MASA). When a user searches for VPN apps, they will now see a banner at the top of Google Play that educates them about the “Independent security review” badge in the Data safety section. This helps users see at-a-glance that a developer has prioritized security and privacy best practices and is committed to user safety.

To better protect our customers who install apps outside of the Play Store, we made Google Play Protect’s security capabilities even more powerful with real-time scanning at the code-level to combat novel malicious apps. Our security protections and machine learning algorithms learn from each app submitted to Google for review and we look at thousands of signals and compare app behavior. This new capability has already detected over 5 million new, malicious off-Play apps, which helps protect Android users worldwide.

More Stringent Developer Requirements and Guidelines

Last year we updated Play policies around Generative AI apps, disruptive notifications, and expanded privacy protections. We also are raising the bar for new personal developer accounts by requiring new testing requirements before developers can make their app available on Google Play. By testing their apps, getting feedback and ensuring everything is ready before they launch, developers are able to bring more high quality content to Play users. In order to increase trust and transparency, we’ve introduced expanded developer verification requirements, including D-U-N-S numbers for organizations and a new “About the developer” section.

To give users more control over their personal data, apps that enable account creation now need to provide an option to initiate account and data deletion from within the app and online. This web requirement is especially important so that a user can request account and data deletion without having to reinstall an app. To simplify the user experience, we have also incorporated this as a feature within the Data safety section of the Play Store.

With each iteration of the Android operating system (including its robust set of APIs), a myriad of enhancements are introduced, aiming to elevate the user experience, bolster security protocols, and optimize the overall performance of the Android platform. To further safeguard our customers, approximately 1.5 million applications that do not target the most recent APIs are no longer available in the Play Store to new users who have updated their devices to the latest Android version.

Looking Ahead

Protecting users and developers on Google Play is paramount and ever-evolving. We're launching new security initiatives in 2024, including removing apps from Play that are not transparent about their privacy practices.

We also recently filed a lawsuit in federal court against two fraudsters who made multiple misrepresentations to upload fraudulent investment and crypto exchange apps on Play to scam users. This lawsuit is a critical step in holding these bad actors accountable and sending a clear message that we will aggressively pursue those who seek to take advantage of our users.

We're constantly working on new ways to protect your experience on Google Play and across the entire Android ecosystem, and we look forward to sharing more.

Notes