Chromium-based browsers, including Chrome, Edge, and Brave, manage installed extensions via JSON preference files stored under %AppData%\Google\User Data\Default\Preferences (for domain-joined machines) or Secure Preferences (for standalone systems). 

Synacktiv research indicates that by directly altering these files, attackers can make the browser load any extensions without the user’s consent or involvement from the Chrome Web Store.

A successful compromise involves three technical prerequisites: pre-calculating the extension ID, generating valid Message Authentication Codes (MACs) for both the extension entry and the developer_mode flag, and bypassing enterprise policy controls. 

Extension IDs are deterministically derived from the extension’s public key or installation path via a SHA-256 hash truncated to 32 hex characters and mapped to a custom alphabet (a–p). 

Chromium’s integrity checks use an HMAC seeded with a static value extracted from resources.pak specifically resource file 146 to sign critical JSON keys. 

Attackers reverse this HMAC algorithm to compute valid MACs for extensions.settings.<crx_id> and extensions.developer_mode, enabling silent registration of their backdoor extension.

Bypassing Chrome Extension GPO Controls

Enterprise environments commonly deploy GPOs to whitelist or blacklist extensions through policies like ExtensionInstallAllowlist and ExtensionInstallBlocklist. 

Three advanced evasion methods undermine these controls:

Synacktiv stated that by reusing the RSA public key of a corporate-approved extension (e.g., Adobe Acrobat Reader for Chrome), an attacker generates a matching extension ID. 

They then inject a malicious unpacked extension under that ID, bypassing hash-based allowlists.

When an unpacked extension and a store-installed extension share the same ID, Chromium prioritizes the unpacked version. This collision allows attackers to override trusted plugins stealthily.

Windows applies policies in LSDOU order. Although Chrome policies reside under HKCU\Software\Policies\Google\Chrome, a local administrator can delete or modify the registry entries, removing allowlists or blocklists to sidestep policy enforcement entirely.

Leveraging these techniques, threat actors can deploy extensions that intercept network traffic, scrape session cookies, execute background service workers, and inject content scripts into targeted web pages. 

A proof-of-concept toolkit from Synacktiv demonstrates remote SMB-based deployment alongside a custom C2 server, enabling JavaScript execution within the browser process and undermining protections such as App-Bound Encryption.

Securing against this vector requires monitoring for unauthorized changes to preference files, validating registry policy integrity, and detecting anomalous extension registrations. 

Without such detection mechanisms, “phantom extensions” offer a stealthy, persistent route to enterprise-wide data exfiltration and lateral movement.

Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.

The post Hackers Can Compromise Chromium Browsers in Windows by Loading Arbitrary Extensions appeared first on Cyber Security News.

A sophisticated technique that allows attackers to execute malicious code directly in memory is gaining traction, posing a significant challenge to modern Endpoint Detection and Response (EDR) solutions.

This method, which involves an in-memory Portable Executable (PE) loader, enables a threat actor to run an executable within an already trusted process, effectively bypassing security checks that primarily monitor files written to disk.

According to a user with the alias G3tSyst3m, the technique highlights a critical blind spot in some security postures, allowing secondary payloads to be deployed stealthily after initial access is gained.

This “fileless” attack vector is particularly dangerous because it operates under the radar. An EDR solution may validate and approve an initial application, deeming it safe to run.

However, once that trusted process is active, it can be manipulated to download and execute another PE file, such as a remote access trojan or info-stealer, entirely within its own memory space.

Because the malicious executable never touches the file system, traditional antivirus and EDR tools that rely on file scanning and disk-based heuristics may fail to detect the threat.

In-Memory PE Loader Leveraged

The attack begins by leveraging the legitimate process to download a PE file from a remote source, such as a GitHub repository.

Using standard Windows APIs like InternetOpenUrlA and InternetReadFile, the code fetches the executable and stores it in a memory buffer.

This initial step is often mistaken for delicate network activity, allowing the payload to be smuggled onto the target system without raising alarms. Once the PE file resides in memory as a byte array, the loader meticulously reconstructs it for execution.

This reconstruction process manually emulates the functions of the Windows operating system’s own loader. At a high level, the loader performs several critical steps:

• Parses PE Headers: It reads the DOS and NT headers of the downloaded file to understand its structure, including its sections and dependencies.
• Allocates Memory: It uses VirtualAlloc to reserve a new block of memory within the host process to map the executable image.
• Maps Sections: The loader copies the PE headers and sections (like .text for code and .data for variables) from the buffer into the newly allocated memory space according to their virtual addresses.
• Resolves Imports: It loads any required Dynamic-Link Libraries (DLLs) and resolves the addresses of external functions the PE needs to run. This is done by using LoadLibraryA and GetProcAddress.
• Applies Relocations: It adjusts any hardcoded addresses in the code to ensure they point to the correct locations in memory.

After successfully mapping the PE file and resolving its dependencies, the final steps involve adjusting memory permissions and triggering execution.

The loader uses VirtualProtect to set the appropriate permissions for each section, for instance, marking the code section as executable and the data section as readable/writable.

This mirrors the behavior of a legitimately loaded program and is crucial for the code to run without crashing the process. With the memory correctly prepared, the loader simply calls the PE file’s entry point, launching the malicious code.

This method has proven effective in red team engagements and has been observed bypassing prominent EDR solutions like Microsoft Defender for Endpoint (XDR) and Sophos XDR.

While not entirely foolproof, especially against advanced AI and machine learning-based detection that can flag anomalous process behavior over time, custom-built PE loaders remain a potent tool for evading detection.

The technique underscores the need for security solutions that can perform deep memory inspection and behavioral analysis, moving beyond a reliance on file-based threat intelligence.

Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.

The post Hackers Can Bypass EDR by Downloading Malicious File as In-Memory PE Loader appeared first on Cyber Security News.