Business logic: why are the expansions attacked and what does it threaten the company
A browser extension is a JavaScript code with preferred access to DOM visited sites, cookies, storage and browser API. For the attacker, this is a ready-made bridgehead: you do not need to bypass EDR or exploit the OS vulnerability - the code is already working inside the trusted process. Expansion with permissions cookies + <all_urls> reads all cookies of any domain, including HttpOnly cookies that are not available through document.cookie from the JS web page. The theft of a session session from the SSO portal is equivalent to compromising the account without a password and without MFA. Just think about it - without a password and without an MFA.
A separate vector is an insider threat. The employee puts an extension-stecker for uploading data, and the compromising the legitimate corporate extension through the supply chain gives the attacker the persistence on all the points of the ends where it is established (Browser Extensions, T1176.001, Persistence (Software Extensions)).
Typical actions of malicious extensions in terms of MITRE AT&CK:
The architecture of extensions and the surface of the attack of Chrome and Firefox
Contexts of execution and manifest.json
The extension consists of three contexts with different privileges. Understanding their boundaries is the foundation of the security analysis of browser extensions.
Background script (Service Worker in Manifest V3) - the most privileged context. Access to chrome.tabs, chrome.cookies, chrome.storage, chrome.webRequest. In MV3 blocking webRequest, it is replaced by declarativeNetRequest; webRequest is only available in the observation mode, with the exception of extensions installed via policy (force-install) - for them, the blocking webRequest is saved. DeclarativeNetRequest has its own limits: 30k static and 5k dynamic rules. Here, data is processed and requests go to external servers.
Content script - is performed in the context of a web page, but in an isolated JavaScript world: there is access to DOM, to JS-Variable pages - no. This is a key limitation and at the same time the main vector of the attack: the content script works with data from an untrusted source.
Popup - HTML/JS when clicking on the icon. A separate context communicates with background through the messaging API.
Everything is defined by the file exchangic.json: permissions, content_scripts, externally_connectable, web_accessible_resources, content_security_policy. The audit of the manifesto is the first step of the pentest. Always.
Manifest V3 and safety are not a panacea. At DEF CON 32, SquareX researchers showed that even V3 extensions are able to steal cookies, intercept live streams and extract account data (according to IIT Jammu, 2025). MV3 removed eval() and remote scripts, but content scripts still have full access to DOM, and service worker saves access to the Extension API. So if someone says “we’re on V3, we’re not afraid” – don’t believe it.
[Applicable: internal and external audit. Chromium-based browsers (Chrome, Edge, Brave) and Firefox use the common format WebExtensions - the methodology is portable between them adjusted for differences in API]
Browser Extension Entry Testing Methodology
Adjustments to the environment
• OS: Windows 10/11, Linux, macOS - cross-platform testing
• Browser: Chrome 120+ or Firefox 115+ with Developer Mode
• Tools: Chrome DevTools (embedded), Burp Suite Community/Pro to intercept traffic
• RAM: at least 4 GB, recommended 8 GB in parallel work Burp Suite
• Network: online for downloading the extension, then offline-analy analysis of unpacked code
Step-by-step analysis
Step 1. Extraction of source code. Chrome Extensions Stored in the format .crx (In fact, the ZIP archive). Windows: C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\Extensions\<ID>\<version>. Linux: ~/.config/google-chrome/Default/Extensions/<ID>/<version>. Firefox: ~/.mozilla/firefox/<profile>/extensions/. Unpack - get a manifest.json and JS-files.
Step 2. Audit of manifest.json. Look at the critical elements:
1. permissionsand host_permissions- which APIs and domains are available
2. content_scriptsc matches: [":///*"]or <all_urls>- launch on all sites
3. externally_connectable- whether an arbitrary site can send messages to expand
4. web_accessible_resources- extension files available from the context of the web page (tibertprinting vector)
5. content_security_policy- availability and severity of CSP
Red flags in permissions: <all_urls> + cookies, webRequestBlocking, nativeMessaging, clipboardRead. According to GitHub Security Lab, the combination <all_urls> c cookies allows you to expand all cookies of any domain, including HtpOnly cookies that are not available from JS web pages.
Step 3. Static analysis of JS. Grepa-patterns to search: innerHTML, document.write(), eval(), Function() - potential XSS-vectors; fetch() and XMLHttpRequest to external hosts - data leakage; chrome.runtime.onMessageExternal without validation sender - insecure passing message; secrets in localStorage - insecure storage (OWASP A08:2021, Software and Data Integrity Failures)
Step 4. Interception of traffic. Proxy through Burp Suite. Check: where the extension sends data, HTTPS or HTTP, whether cookies/tokens are transmitted. POST-queries from content scripts, which are not in the normal behavior of the site - the marker data exfiltration.
Step 5. Analysis of the repository. DevTools → Application → Storage. Check chrome.storage and localStorage tokens, passwords, API keys in open form. By OWASP Browser Extension Vulnerabilities Cheat Sheet, localStorage Instead of chrome.storage API for sensitive data - a common vulnerability (Insecure Storage). It is more common than I would like.
Step 6. Testing message passing. From DevTools Console send a message: chrome.runtime.sendMessage('<extension_id>', {payload: 'test'}). If the extension receives messages from arbitrary senders - the Extension API Injection vector.
Chrome Extensions Vulnerabilities: Typical Finds with Examples
XSS and Content Microsir Vulnerability
The most common mistake – innerHTML to insert data from DOM or user input. An example from OWASP Browser Extension Vulnerabilities Cheat Sheet:
JavaScript:
let userInput = document.getElementById('input').value;
document.getElementById('output').innerHTML = userInput; // XSS
The attacker controls the content of the web page. Content script reads data from DOM and inserts it through innerHTML - classic DOM XSS. Mititation: textContent Instead of innerHTML, DOMPurify for sanitaryization, CSP ban unsafe-inline.
Separate vector - DOM-based Data Skimming (OWASP): extension renders sensitive data (email, tokens) directly to DOM web pages, where the scripts of the pages read them calmly. Protection: display data only in popup or side panel, not in DOM.
Insecure Message Passing and Extension API Injection
Background script that processes external messages without origin checking is a direct path to Universal XSS:
JavaScript:
chrome.runtime.onMessageExternal.addListener(
(request, sender, sendResponse) => {
chrome.tabs.executeScript({code: request.code}); // MV2 only
}
);
The external site sends an extension message and forces you to perform arbitrary JavaScript through executeScript - in the context of any domain to which the extension has access. This vector is relevant for Manifest V2; in Manifest V3 transferring code string via executeScript blocked, but UXSS remains possible through chrome.scripting.executeScript with controlled arguments func/files. According to the study of GitHub Security Lab, this gives USSS, if the extension has permission in activeTab or <all_urls>.
[Restrictions: XSS content through scripts does not work if the extension does not interact with DOM. Message passing exploitation requires that externally_connectable was opened or the extension used onMessageExternal. Against extensions without external listeners, this vector is irrelevant]
Detection: monitoring of extensions in SIEM and EDR
Basic telemetry for SOC
On managed corporate endpoints, no extension should appear without the knowledge of SOC. Sources of data:
• Chrome Enterprise / GPO: Policies ExtensionInstallBlocklistand ExtensionInstallAllowlist- whitelist mode
• File Activity: Sysmon EventID 11 (FileCreate) in the Extensions directory - the emergence of a new manifest.json
• EDR: Process Requests chrome.exe/ firefox.exeto atypical domains, recording in non-standard storage areas
• DNS logs: domain resorted initiated by the browser process that is not part of the corporate baseline
Correlation rules
Alert 1. New extension outside whitelist. Trigger: Sysmon EventID 11 with \Extensions\\manifest.json, extension ID is not on the approved list. For EDR (Crowd Strike Falcon, SentinelOne, Elastic 8.x+) - FileCreate-events with a similar filter along the way. Covers T1176 - Software Extensions (Persistence) and insider script for installing the style.
Albert 2. Expansion with critical permissions. Periodic parsite script manifest.json of all installed extensions, compares permissions with baseline. Flags: <all_urls>, cookies, webRequest, nativeMessaging, clipboardRead. Implementation: PowerShell/Python script by schedule, result - in SIEM as a custom log. Yeah, it's a crutch. But so far, no EDR vendor gives this telemetry native - the crutch works.
Alert 3. Network anomaly of the browser process. chrome.exe establishes a connection to a domain outside baseline (CDN, corporate resources, well-known services). Correlation: DNS logs + netflow. POST-requests with content-type application/json unknown endpoints - marker data exfiltration through extension.
Alert 4. Massive access to cookies (insider vector). The browser process in 60 seconds accesses cookies for more than 10 unique domains. A characteristic pattern for extensions that implement Steal Web Session Cookies (T1539). For the detection, you need to monitor access to the cookie in the browser profile: Windows Security EventID 4663 (object access auditing) with a customized SACL on a cookie, or EDR-telemetry file read access.
Nuance: SACL on Cookies generates high-volume noise with chrome.exe. Filtration should go through the access mask READ_DATA from processes other than chrome.exe, or through EDR file access telemetry with a similar filter. Sysmon EventID 10 captures process access to the process rather than files; EventID 11 is only file creation. Modern Chrome Store Cookies in Network\Cookies; starting with Chrome 127+, Windows uses the App-Bound Encryption (ABE) - the encryption key of cookies is protected by SYSTEM-level DPAPI and is tied to the chrome.ex process, which seriously complicates the reading of cookies by a third-party process.
IOC and markers of malicious extensions
According to Kaspersky Lab (22) and IIT Jammu Studies (2025):
• Isoscipated JS code (T1027) - webpack/der-obfuscate is permissible, but String.fromCharCodeand atob()in the chain with eval()- red flag
• Contacting C2 at the first start - the domain does not coincide with the stated functionality
• Reading DOM-elements of authorization forms on banking and corporate websites
• Interception chrome.webRequestfor modification of HTTP headers (injection tracking parameters, cookie substitution)
A browser extension is a JavaScript code with preferred access to DOM visited sites, cookies, storage and browser API. For the attacker, this is a ready-made bridgehead: you do not need to bypass EDR or exploit the OS vulnerability - the code is already working inside the trusted process. Expansion with permissions cookies + <all_urls> reads all cookies of any domain, including HttpOnly cookies that are not available through document.cookie from the JS web page. The theft of a session session from the SSO portal is equivalent to compromising the account without a password and without MFA. Just think about it - without a password and without an MFA.
A separate vector is an insider threat. The employee puts an extension-stecker for uploading data, and the compromising the legitimate corporate extension through the supply chain gives the attacker the persistence on all the points of the ends where it is established (Browser Extensions, T1176.001, Persistence (Software Extensions)).
Typical actions of malicious extensions in terms of MITRE AT&CK:
The architecture of extensions and the surface of the attack of Chrome and Firefox
Contexts of execution and manifest.json
The extension consists of three contexts with different privileges. Understanding their boundaries is the foundation of the security analysis of browser extensions.
Background script (Service Worker in Manifest V3) - the most privileged context. Access to chrome.tabs, chrome.cookies, chrome.storage, chrome.webRequest. In MV3 blocking webRequest, it is replaced by declarativeNetRequest; webRequest is only available in the observation mode, with the exception of extensions installed via policy (force-install) - for them, the blocking webRequest is saved. DeclarativeNetRequest has its own limits: 30k static and 5k dynamic rules. Here, data is processed and requests go to external servers.
Content script - is performed in the context of a web page, but in an isolated JavaScript world: there is access to DOM, to JS-Variable pages - no. This is a key limitation and at the same time the main vector of the attack: the content script works with data from an untrusted source.
Popup - HTML/JS when clicking on the icon. A separate context communicates with background through the messaging API.
Everything is defined by the file exchangic.json: permissions, content_scripts, externally_connectable, web_accessible_resources, content_security_policy. The audit of the manifesto is the first step of the pentest. Always.
Manifest V3 and safety are not a panacea. At DEF CON 32, SquareX researchers showed that even V3 extensions are able to steal cookies, intercept live streams and extract account data (according to IIT Jammu, 2025). MV3 removed eval() and remote scripts, but content scripts still have full access to DOM, and service worker saves access to the Extension API. So if someone says “we’re on V3, we’re not afraid” – don’t believe it.
[Applicable: internal and external audit. Chromium-based browsers (Chrome, Edge, Brave) and Firefox use the common format WebExtensions - the methodology is portable between them adjusted for differences in API]
Browser Extension Entry Testing Methodology
Adjustments to the environment
• OS: Windows 10/11, Linux, macOS - cross-platform testing
• Browser: Chrome 120+ or Firefox 115+ with Developer Mode
• Tools: Chrome DevTools (embedded), Burp Suite Community/Pro to intercept traffic
• RAM: at least 4 GB, recommended 8 GB in parallel work Burp Suite
• Network: online for downloading the extension, then offline-analy analysis of unpacked code
Step-by-step analysis
Step 1. Extraction of source code. Chrome Extensions Stored in the format .crx (In fact, the ZIP archive). Windows: C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\Extensions\<ID>\<version>. Linux: ~/.config/google-chrome/Default/Extensions/<ID>/<version>. Firefox: ~/.mozilla/firefox/<profile>/extensions/. Unpack - get a manifest.json and JS-files.
Step 2. Audit of manifest.json. Look at the critical elements:
1. permissionsand host_permissions- which APIs and domains are available
2. content_scriptsc matches: [":///*"]or <all_urls>- launch on all sites
3. externally_connectable- whether an arbitrary site can send messages to expand
4. web_accessible_resources- extension files available from the context of the web page (tibertprinting vector)
5. content_security_policy- availability and severity of CSP
Red flags in permissions: <all_urls> + cookies, webRequestBlocking, nativeMessaging, clipboardRead. According to GitHub Security Lab, the combination <all_urls> c cookies allows you to expand all cookies of any domain, including HtpOnly cookies that are not available from JS web pages.
Step 3. Static analysis of JS. Grepa-patterns to search: innerHTML, document.write(), eval(), Function() - potential XSS-vectors; fetch() and XMLHttpRequest to external hosts - data leakage; chrome.runtime.onMessageExternal without validation sender - insecure passing message; secrets in localStorage - insecure storage (OWASP A08:2021, Software and Data Integrity Failures)
Step 4. Interception of traffic. Proxy through Burp Suite. Check: where the extension sends data, HTTPS or HTTP, whether cookies/tokens are transmitted. POST-queries from content scripts, which are not in the normal behavior of the site - the marker data exfiltration.
Step 5. Analysis of the repository. DevTools → Application → Storage. Check chrome.storage and localStorage tokens, passwords, API keys in open form. By OWASP Browser Extension Vulnerabilities Cheat Sheet, localStorage Instead of chrome.storage API for sensitive data - a common vulnerability (Insecure Storage). It is more common than I would like.
Step 6. Testing message passing. From DevTools Console send a message: chrome.runtime.sendMessage('<extension_id>', {payload: 'test'}). If the extension receives messages from arbitrary senders - the Extension API Injection vector.
Chrome Extensions Vulnerabilities: Typical Finds with Examples
XSS and Content Microsir Vulnerability
The most common mistake – innerHTML to insert data from DOM or user input. An example from OWASP Browser Extension Vulnerabilities Cheat Sheet:
JavaScript:
let userInput = document.getElementById('input').value;
document.getElementById('output').innerHTML = userInput; // XSS
The attacker controls the content of the web page. Content script reads data from DOM and inserts it through innerHTML - classic DOM XSS. Mititation: textContent Instead of innerHTML, DOMPurify for sanitaryization, CSP ban unsafe-inline.
Separate vector - DOM-based Data Skimming (OWASP): extension renders sensitive data (email, tokens) directly to DOM web pages, where the scripts of the pages read them calmly. Protection: display data only in popup or side panel, not in DOM.
Insecure Message Passing and Extension API Injection
Background script that processes external messages without origin checking is a direct path to Universal XSS:
JavaScript:
chrome.runtime.onMessageExternal.addListener(
(request, sender, sendResponse) => {
chrome.tabs.executeScript({code: request.code}); // MV2 only
}
);
The external site sends an extension message and forces you to perform arbitrary JavaScript through executeScript - in the context of any domain to which the extension has access. This vector is relevant for Manifest V2; in Manifest V3 transferring code string via executeScript blocked, but UXSS remains possible through chrome.scripting.executeScript with controlled arguments func/files. According to the study of GitHub Security Lab, this gives USSS, if the extension has permission in activeTab or <all_urls>.
[Restrictions: XSS content through scripts does not work if the extension does not interact with DOM. Message passing exploitation requires that externally_connectable was opened or the extension used onMessageExternal. Against extensions without external listeners, this vector is irrelevant]
Detection: monitoring of extensions in SIEM and EDR
Basic telemetry for SOC
On managed corporate endpoints, no extension should appear without the knowledge of SOC. Sources of data:
• Chrome Enterprise / GPO: Policies ExtensionInstallBlocklistand ExtensionInstallAllowlist- whitelist mode
• File Activity: Sysmon EventID 11 (FileCreate) in the Extensions directory - the emergence of a new manifest.json
• EDR: Process Requests chrome.exe/ firefox.exeto atypical domains, recording in non-standard storage areas
• DNS logs: domain resorted initiated by the browser process that is not part of the corporate baseline
Correlation rules
Alert 1. New extension outside whitelist. Trigger: Sysmon EventID 11 with \Extensions\\manifest.json, extension ID is not on the approved list. For EDR (Crowd Strike Falcon, SentinelOne, Elastic 8.x+) - FileCreate-events with a similar filter along the way. Covers T1176 - Software Extensions (Persistence) and insider script for installing the style.
Albert 2. Expansion with critical permissions. Periodic parsite script manifest.json of all installed extensions, compares permissions with baseline. Flags: <all_urls>, cookies, webRequest, nativeMessaging, clipboardRead. Implementation: PowerShell/Python script by schedule, result - in SIEM as a custom log. Yeah, it's a crutch. But so far, no EDR vendor gives this telemetry native - the crutch works.
Alert 3. Network anomaly of the browser process. chrome.exe establishes a connection to a domain outside baseline (CDN, corporate resources, well-known services). Correlation: DNS logs + netflow. POST-requests with content-type application/json unknown endpoints - marker data exfiltration through extension.
Alert 4. Massive access to cookies (insider vector). The browser process in 60 seconds accesses cookies for more than 10 unique domains. A characteristic pattern for extensions that implement Steal Web Session Cookies (T1539). For the detection, you need to monitor access to the cookie in the browser profile: Windows Security EventID 4663 (object access auditing) with a customized SACL on a cookie, or EDR-telemetry file read access.
Nuance: SACL on Cookies generates high-volume noise with chrome.exe. Filtration should go through the access mask READ_DATA from processes other than chrome.exe, or through EDR file access telemetry with a similar filter. Sysmon EventID 10 captures process access to the process rather than files; EventID 11 is only file creation. Modern Chrome Store Cookies in Network\Cookies; starting with Chrome 127+, Windows uses the App-Bound Encryption (ABE) - the encryption key of cookies is protected by SYSTEM-level DPAPI and is tied to the chrome.ex process, which seriously complicates the reading of cookies by a third-party process.
IOC and markers of malicious extensions
According to Kaspersky Lab (22) and IIT Jammu Studies (2025):
• Isoscipated JS code (T1027) - webpack/der-obfuscate is permissible, but String.fromCharCodeand atob()in the chain with eval()- red flag
• Contacting C2 at the first start - the domain does not coincide with the stated functionality
• Reading DOM-elements of authorization forms on banking and corporate websites
• Interception chrome.webRequestfor modification of HTTP headers (injection tracking parameters, cookie substitution)
