Avoid running MicrosoftEdgeUpdateCore.exe from user profile

Question

We are planning to block the execution of programs from user profiles via SRP or AppLocker as a security measure. While evaluating the SRP logs in test mode I noticed repeated executions of the file

%LocalAppData%\Microsoft\EdgeUpdate\1.3.195.61\MicrosoftEdgeUpdateCore.exe

in the currently logged in user's profile. This would of course be blocked by our envisaged policy.

Would this cause any problem?

Why must this program be run from the user profile anyway?

Is there a way to move it to %SystemRoot% or %ProgramFiles% where installed programs should be?

The answer from Q&A Assist is unsatisfactory as it does not make it plausible why MicrosoftEdgeUpdateCore.exe needs to be run from the user profile, nor offer a solution for the security concern with allowing the running of arbitrary user provided executables.

Answer 1

Hello,

Thank you for posting question on Microsoft Windows forum!

The followings are the plausible explanation to address your below queries.

1.Would this cause any problem?

• Yes, blocking MicrosoftEdgeUpdateCore.exe from running in the user profile will cause significant problems. Like No Automatic Updates for Microsoft Edge, Security Vulnerabilities and Feature Gaps and Instability.

2.Why must this program be run from the user profile anyway?

• Microsoft Edge, like many modern browsers (e.g., Chrome), uses a per-user installation model for several reasons:

1. User-Specific Settings and Permissions: Each user has their own profile, which includes browser settings, extensions, Browse history, cache, and other data. Running the updater from the user's AppData\Local directory allows it to operate with the necessary permissions and context of that specific logged-in user to manage their browser installation and updates. This avoids requiring administrator privileges for routine updates, which is a key design principle for modern browsers that update frequently.
2. Faster, Independent Updates: By keeping the update mechanism within the user's profile, Microsoft can push updates more frequently and independently of system-wide Windows updates. This ensures users get critical security fixes and new features quickly without waiting for a full OS update cycle.
3. Sandboxing and Security: While it might seem counterintuitive, running browser components and their update processes with user-level privileges can actually enhance security. If a vulnerability is exploited, the impact is confined to the user's profile, rather than gaining system-wide control.
4. Reduced Administrator Overhead: For organizations, this model reduces the administrative burden of constantly deploying browser updates via traditional methods.

3.Is there a way to move it to %SystemRoot% or %ProgramFiles% where installed programs should be?

• No, it is typically not recommended or generally possible to relocate MicrosoftEdgeUpdateCore.exe to %SystemRoot% or %ProgramFiles% and expect it to function correctly. Because of the following reasons

1. Design and Dependencies: The application is designed to run from the user's AppData\Local path, and its internal dependencies and configurations are tied to this location. Moving it would break these links, leading to the updater (and potentially the browser itself) failing to launch or update.
2. Permissions: Even if you could move it, running it from %SystemRoot% or %ProgramFiles% would likely require elevated administrator privileges for every update, which contradicts the per-user update model and would be highly disruptive.
3. Microsoft's Intentional Design: This is an intentional architectural choice by Microsoft for the reasons mentioned above. Modifying the installation path of system applications or core browser components can lead to unexpected behavior, instability, and conflicts with the application's update mechanism.

However, you can consider the following points.

1.Specific Path/Hash Whitelisting with AppLocker/SRP:

• Publisher Rules: The most robust solution is to use AppLocker (or SRP, though AppLocker offers more granular control) to create Publisher Rules. These rules allow executables to run based on their digital signature. Microsoft signs MicrosoftEdgeUpdateCore.exe and other legitimate Microsoft executables. You can create a rule that allows any executable signed by "Microsoft Corporation" to run from C:\Users*\AppData\Local*. This is generally more secure than path-based rules because it verifies the authenticity of the executable.
• Hybrid Approach: A good balance can be publisher rules for known, trusted vendors (like Microsoft) combined with more restrictive path/hash rules for other applications or specific folders.

2.Leverage Endpoint Detection and Response (EDR) / Antivirus Solutions:

• Modern EDR solutions are designed to monitor and detect malicious activity, even from seemingly legitimate paths or executables. They use behavioral analysis, threat intelligence, and machine learning to identify suspicious actions. While AppLocker/SRP prevent execution, EDR can detect and respond to threats that might bypass these policies or originate from other vectors.

3.Regular Auditing and Review of SRP/AppLocker Logs:

• Continue to use the test mode and thoroughly review logs. This will help you identify other legitimate applications that might be affected by your policies and allow you to create appropriate exceptions.

Hope the above information is helpful!

Answer 2

Blocking the execution of MicrosoftEdgeUpdateCore.exe from user profiles via Software Restriction Policies (SRP) or AppLocker could lead to issues with the automatic updates of Microsoft Edge. This executable is responsible for updating the Edge browser, and running it from the user profile allows it to operate with the necessary permissions and context of the logged-in user.

If you block this executable, users may not receive important updates, which could expose them to security vulnerabilities and bugs that are typically resolved in newer versions.

As for moving the executable to %SystemRoot% or %ProgramFiles%, this is not advisable as it is designed to run from the user profile for specific operational reasons, such as user-specific settings and permissions. Additionally, modifying the installation path of system applications can lead to unexpected behavior or conflicts with the application’s update mechanism.

---

References:

• Software Restriction Policies Technical Overview