Microsoft Outlook

The popup registers a blocking webRequest.onBeforeSendHeaders listener against ei={urls:["https://*/*"]}, intercepting ALL outbound HTTPS request headers from the browser with the extraHeaders flag (required to access Cookie headers). While actual header modification is gated on ti(e.url) (URLs containing ?isExtension=true), the listener fires and executes JavaScript for every single HTTPS request in the browser. For matching URLs, it clears the Cookie header entirely and spoofs the User-Agent to appear as an iPhone running Microsoft Edge on iOS.

chrome.webRequest.onBeforeSendHeaders.addListener((function(e) {  var t, n = e.requestHeaders;  if (!ti(e.url) && !(null == e ? void 0 : e.url.includes("sw.js"))) return {    requestHeaders: n  };  if (n) {    for (var r = 0, o = n.length; r < o; ++r) "cookie" === (null === (t = n[r].name) || void 0 === t ? void 0 : t.toLowerCase()) && (n[r].value = ""), "User-Agent" !== n[r].name || (null == e ? void 0 : e.url.includes("sw.js")) || (n[r].value = "Mozilla/5.0 (iPhone; CPU iPhone OS 12_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 EdgiOS/44.5.0.10 Mobile/15E148 Safari/604.1");    return {      requestHeaders: n    }  }}), ei, ["requestHeaders", "blocking", "extraHeaders"]);// where: ei={urls:["https://*/*"]}

The popup registers a blocking onHeadersReceived listener with no explicit URL filter, causing the fallback ei={urls:["https://*/*"]} to activate — intercepting ALL HTTPS response headers in the browser. For responses where the URL has ?isExtension=true or matches Microsoft Outlook/OAuth logout URLs, the extension strips Content-Security-Policy frame-ancestors restrictions and — critically — does not merely remove X-Frame-Options but actively replaces it with a fabricated 'x-powered-by: ASP.net' header, disguising the manipulation as a benign IIS response header.

chrome.webRequest.onHeadersReceived.addListener(n, t, ["responseHeaders", "blocking"])}((function(e) {  return ti(e.url) || ui.some((function(t) {    return e.url.includes(t)  }))}));// t is undefined here; fallback: void 0===t&&(t=ei); ei={urls:["https://*/*"]}// Callback n modifies response headers:// "content-security-policy"===u && (a[s].value = a[s].value.replace("frame-ancestors","frame-ancestors "+location.origin))// "x-frame-options"===u && (a[s]={name:"x-powered-by",value:"ASP.net"})

The background script uses a blocking onHeadersReceived listener (guarded to the Outlook inbox URL) to modify security headers on responses. The content-security-policy frame-ancestors directive is injected with the extension's chrome-extension:// origin to permit iframing, and the x-frame-options header is fully replaced by a fake 'x-powered-by: ASP.net' header — actively deceiving any observer into thinking the response came from IIS without clickjacking protection rather than revealing that a header was stripped.

function r(t) {  var r, n, o, i, a = t.responseHeaders;  if (!e(t)) return {    responseHeaders: a  };  if (console.log("iframe-ing: " + t.url), a) {    for (var s = 0, c = a.length; s < c; ++s) {      var u = (a[s].name || '').toLowerCase();      "content-security-policy" === u && (a[s].value = a[s].value.replace("frame-ancestors", "frame-ancestors " + location.origin));      "x-frame-options" === u && (a[s] = {        name: "x-powered-by",        value: "ASP.net"      });    }    return {      responseHeaders: a    };  }}void 0 === t && (t = ga); // ga={urls:["https://*/*"]}chrome.webRequest.onHeadersReceived.addListener(r, t, ["responseHeaders", "blocking"]);// Called as: }((function(e){return e.url.includes(go)}),{urls:[go]})// go="https://outlook.office.com/mail/mini/opxdeeplink/mail/inbox"

The content script runs at document_start on Microsoft login pages (login.live.com and login.microsoftonline.com). On the Outlook redirect URI page, it captures window.location.hash — which in Microsoft's MSAL redirect flow contains the OAuth authorization code or access/id token after a successful authentication — and transmits the full hash to the background script via chrome.runtime.sendMessage. While this is MSAL's intended redirect completion mechanism, the extension's background then processes these tokens to authenticate with Microsoft APIs on behalf of the user, making this a high-privilege credential-handling operation that warrants scrutiny.

// Content script injected at document_start into: login.live.com/*, login.microsoftonline.com/*// and: https://outlook.office.com/mail/mini/opxdeeplink/mail/inboxvar fo = window.location.href;if (function(e) {    return e.startsWith(ao)  }(fo) &&  (go && function(e) {    return e.includes(so) && e.includes("msal")  }(go) || Nn.isInIframe())) {  var yo = window.location.hash;  var mo = jn();  e({    type: Hn.AppLoginRedirectDone,    payload: {      hash: yo    },    cid: mo  });  // e() is chrome.runtime.sendMessage  // so=clientId: "6a1a91a6-19f9-4a37-b68b-9bed3f4e6595"  // ao="https://outlook.office.com/mail/mini/opxdeeplink/mail/inbox"}

Multiple CDN URLs are obfuscated using a string-reversal technique — a classic pattern used to evade static analysis tools and content security policy scanners that pattern-match URL strings. While the decoded URLs resolve to legitimate Microsoft Office CDN domains, the deliberate obfuscation is a behavioral red flag and indicates the author was aware that these strings could trigger detection. This technique is functionally identical to the obfuscation patterns used in known malicious extensions.

"ten.eciffo.ndc.1-kooltuo//".split("").reverse().join(""),  "nc.kooltuo.rentrap.ndc.1-kooltuo//".split("").reverse().join(""),  "ten.eciffo.ndc.2-kooltuo//".split("").reverse().join(""),  "nc.kooltuo.rentrap.ndc.2-kooltuo//".split("").reverse().join("");// Decoded at runtime to:// "//outlook-1-cdn.office.net"// "//outlook-1-cdn.partner.outlook.cn"// "//outlook-2-cdn.office.net"// "//outlook-2-cdn.partner.outlook.cn"

auth.html is exposed as a web-accessible resource to a second extension ID (kkpalkknhlklpbflpcpkepmmbnmfailf) in addition to this extension's own ID. More critically, auth.html loads all four extension bundles simultaneously — including the full background script, content script, popup script, and service worker bundle — meaning any page or extension that can navigate to this URL causes the full extension logic (including all webRequest listeners and token-processing code) to execute in that context. This cross-extension exposure combined with full-bundle loading is an unusual attack surface.

<!doctype html><html lang="en"><head>  <meta charset="UTF-8">  <title>Auth Redirect</title>  <script defer="defer" src="/popup.bundle.js"></script>  <script defer="defer" src="/background.bundle.js"></script>  <script defer="defer" src="/contentScript.bundle.js"></script>  <script defer="defer" src="/serviceworker_webpush.bundle.js"></script></head><body></body></html><!-- manifest.json web_accessible_resources:  "kkpalkknhlklpbflpcpkepmmbnmfailf/auth.html",  "ajanlknhcmbhbdafadmkobjnfkhdiegm/auth.html" -->