Abusing Microsoft Edge Preferences for Stealthy Persistence

TLDR: Modern Chromium-based browsers like Microsoft Edge store user settings in clear-text JSON files that are trivial to modify once an attacker gains local file system access. By recalculating the HMAC-based integrity hashes, an attacker can inject malicious startup URLs, force-install extensions, or trigger legacy Java applets to maintain long-term persistence. This technique bypasses standard UI-based security warnings and allows for persistent code execution that survives browser restarts.

Browser security models often assume that the local user is the primary threat, but they rarely account for the ease with which an attacker can manipulate the underlying configuration files. When you have local access to a Windows machine, you aren't just a user; you are the system administrator of that user's profile. The research presented at BSides London 2025 highlights a critical oversight in how Chromium-based browsers, specifically Microsoft Edge, manage their internal state.

The Anatomy of the Preferences Files

Chromium browsers store user settings in two primary files located within the user's AppData directory: Preferences and Secure Preferences. While the Preferences file is a standard JSON object containing user-defined settings, the Secure Preferences file acts as an integrity-protected mirror. The browser calculates an HMAC for each setting and stores a master super_mac to ensure that no unauthorized modifications have occurred.

The fatal flaw here is that the "secret" key used to calculate these HMACs is effectively static or non-existent for the purpose of preventing local tampering. As demonstrated in the research, an attacker with local access can simply read the Secure Preferences file, modify the desired settings, and then recalculate the necessary hashes. Because the browser does not use a hardware-backed secret or a per-user unique key that is inaccessible to the user, the integrity check is essentially a speed bump rather than a security barrier.

Weaponizing the Configuration

Once you can modify these files, the attack surface for persistence is massive. The most straightforward method involves manipulating the startup_urls setting. By injecting a URL pointing to a malicious site, you can ensure that every time the user launches their browser, they are greeted by your payload.

"session": {
    "restore_on_startup": 4,
    "startup_urls": ["http://attacker-controlled-site.com"]
}

Beyond simple redirects, the research demonstrates how to force-install browser extensions. By adding an extension ID to the extensions dictionary in the Secure Preferences file, you can force the browser to load an extension that you have placed on the disk. Even if the extension is not signed by the official store, you can bypass the "developer mode" warnings by modifying the dev_mode_warning_snooze_end_time value to a date far in the future. This effectively silences the browser's complaints about unsigned or sideloaded extensions.

The Legacy Vector: Java Applets

Perhaps the most creative aspect of this research is the revival of Java Applets as a persistence mechanism. While modern browsers have largely deprecated applet support, Microsoft Edge’s IE mode provides a bridge to this legacy technology. By configuring the browser to open a specific URL in IE mode, an attacker can force the execution of a Java applet.

If the applet is signed or if the user has been tricked into trusting the publisher, the applet can break out of the standard Java sandbox. This grants the attacker the ability to execute arbitrary code on the host system with the privileges of the logged-in user. This is a classic Broken Access Control scenario where the browser's trust in legacy configuration settings is exploited to facilitate a full system compromise.

Real-World Implications for Pentesters

During a red team engagement, this technique is a goldmine for maintaining access. Most EDR solutions focus on process injection or suspicious binary execution. They rarely monitor the integrity of browser configuration files in the user's profile. If you have already achieved initial access, modifying these files is a low-noise way to ensure you don't lose your foothold when the user reboots their machine.

When testing, look for opportunities to pivot from file system access to browser manipulation. If you find yourself on a machine where the user is a heavy Edge user, check the Secure Preferences file. If you can automate the hash recalculation, you can turn a simple file write into a persistent, cross-session execution vector.

Defensive Considerations

Defending against this requires a shift in how we view browser configuration. Organizations should prioritize Extension Management policies to strictly control which extensions can be installed. Furthermore, monitoring for unauthorized modifications to the Secure Preferences file should be part of any host-based detection strategy. While you cannot easily change how Chromium handles these files, you can certainly alert on the behavior of processes that touch these sensitive JSON files.

Ultimately, this research serves as a reminder that the browser is an operating system in its own right. We spend so much time hardening the kernel and the network stack that we often forget the browser is a massive, complex application that stores its entire state in files that are just waiting to be edited. Stop treating browser settings as static data and start treating them as a critical component of your host's attack surface. If you haven't audited your organization's browser policy recently, now is the time to do it.