AutoSpill: How Your Mobile Password Manager Leaks Credentials to Malicious Apps

TLDR: Researchers at Black Hat 2023 demonstrated that the Android autofill framework can be exploited to leak credentials from legitimate password managers into malicious applications. By leveraging WebView controls, an attacker can trick the system into misattributing the origin of an autofill request, causing the password manager to "spill" credentials into a hostile context. This attack requires no phishing, no malicious code execution, and works on fully patched devices, making it a critical concern for mobile security.

Mobile security often feels like a game of cat and mouse where the operating system is the referee. We trust the Android autofill framework to handle our most sensitive data, assuming that the sandbox boundaries are absolute. However, the research presented at Black Hat 2023 on AutoSpill proves that our trust in these system-level abstractions is misplaced. The vulnerability lies not in a specific bug, but in the fundamental design of how Android handles the "autofill ceremony" when WebView controls are involved.

The Mechanics of the Spill

The attack flow is deceptively simple. When a user interacts with a standard login form in a native Android application, the system identifies the fields and requests credentials from the registered password manager. The password manager then presents a prompt, the user authenticates, and the credentials are injected into the fields.

The problem arises when an application uses a WebView to render web content. Because the WebView acts as a mini-browser within the host app, the Android system sometimes struggles to distinguish between the host app's context and the web content's context.

When an attacker builds a malicious app that hosts a WebView, they can manipulate the AssistStructure that the system uses to identify input fields. By crafting a specific layout, the attacker can force the password manager to associate the autofill request with the wrong domain or context. The password manager, believing it is filling a legitimate form for a trusted site, proceeds to inject the credentials directly into the attacker-controlled WebView.

Why This Matters for Pentesters

For those of us conducting mobile penetration tests, this changes the threat model for credential storage. We are no longer just looking for insecure local storage or hardcoded keys. We now have to account for the possibility that the password manager itself can be coerced into betraying the user.

During a test, you should focus on how the application handles web-based authentication. If an app uses a WebView for login, it is a potential target. You do not need to find a complex RCE to exploit this. You simply need to create a test application that mimics the structure of a legitimate login page and observe if the password manager attempts to autofill the fields. If it does, you have successfully demonstrated a credential leakage path.

The impact is significant because the user is never alerted to the fact that their credentials have been shared with an untrusted party. The password manager thinks it is doing its job correctly, and the Android system is simply facilitating the request. This bypasses the need for traditional phishing because the credentials are provided by the user's own trusted tool.

The Defensive Reality

Fixing this is not as simple as updating a library. The issue is baked into the interaction between the Android OS and the password manager's implementation of the autofill service.

Developers should avoid using WebViews for sensitive authentication flows whenever possible. If you must use them, ensure that you are not inadvertently exposing input fields to the autofill service in a way that allows for context confusion. For password manager vendors, the path forward is to implement stricter validation of the AssistStructure. They must stop blindly trusting the metadata provided by the system and instead implement a "kill switch" or a more robust verification mechanism that ensures the credentials are only ever injected into the intended, verified domain.

The research highlights a broader issue in mobile security: the complexity of modern frameworks often creates unintended side channels. As we continue to rely on automated tools for convenience, we must remain vigilant about the underlying trust assumptions. If you are auditing an Android application, take the time to inspect how it handles autofill requests. It might be the difference between a secure login and a silent, zero-effort credential theft.