Nice Extension You’ve Got There… Shame If It Updated

December 15, 2025

Synopsis

The analysis shows a financially motivated, technically capable actor abusing trusted browser-extension marketplaces and auto-update mechanisms to turn legitimate-looking extensions into long-dwell surveillance and access channels, exposing enterprise browsers, SaaS sessions, and identity tokens to data collection and potential follow-on misuse. Strategically, this shifts decision making toward treating browser extensions as a software supply-chain and identity risk, requiring stronger governance, continuous monitoring, and executive visibility rather than ad hoc endpoint controls; operationally, it prioritizes extension allowlisting, telemetry correlation between browser activity and identity anomalies, and rapid containment playbooks; tactically, it drives focused detection, hunting, and response actions around extension updates, permission changes, and outbound beaconing. From a risk posture perspective, the scenario represents low-frequency but high-impact exposure where threat capability exceeds typical control strength, meaning residual risk remains material unless governance and monitoring maturity improve. Financial resilience is affected by the potential for repeated but episodic losses tied to incident response, identity resets, and secondary impacts, reinforcing the value of preventive investment that reduces contact frequency and vulnerability to avoid disproportionate recovery and reputational costs over time.

Evaluated Source, Context, and Claim

Artifact Title

4.3 Million Browsers Infected: Inside ShadyPanda's 7-Year Malware Campaign

https://www.koi.ai/blog/4-million-browsers-infected-inside-shadypanda-7-year-malware-campaign

Source Type

Vendor research blog post (Koi blog / Koi Research)

Publication Date: December 1, 2025

Credibility Assessment

The report is detailed and internally consistent, with specific operational descriptions and IOCs that are actionable for defenders. However, it is also vendor-authored and partially promotional (“Book a demo”), so key impact metrics (e.g., install counts, attribution framing) should be validated via independent telemetry when possible.

General Claim

Security reports a long-running malicious browser-extension ecosystem (“ShadyPanda”) that used trusted marketplace distribution and silent updates to enable large-scale surveillance (URLs, searches, clicks, fingerprints) and, in some cases, hourly remote code execution via downloaded JavaScript, affecting millions of Chrome and Edge users.

Narrative Reconstruction

The OSINT describes a financially motivated, technically capable threat actor (or operator set) that abuses legitimate browser-extension marketplaces and trust signals (e.g., “Featured/Verified,” high install counts) to gain distribution, then leverages extension permissions and auto-update mechanisms to shift from benign or low-grade monetization (affiliate fraud, tracking) into more aggressive outcomes including surveillance (full browsing histories, search and click telemetry, browser fingerprinting) and, for a subset of extensions, recurring command execution by pulling arbitrary JavaScript from attacker-controlled infrastructure; the likely targets are end-user browsers (consumer and enterprise endpoints) and the associated web sessions and cloud/SaaS identities accessible through those browsers, with the operational goal of monetization, scalable data collection, and maintaining a flexible access channel that can be repurposed for higher-impact follow-on activity.

Risk Scenario

Risk Scenario

A cybercriminal actor distributes and later weaponizes seemingly legitimate browser extensions through mainstream extension marketplaces, resulting in organization users installing or retaining the extensions on corporate endpoints. The extensions use granted permissions and trusted auto-update behavior to collect and exfiltrate browsing-related data (e.g., URLs, searches, cookies, fingerprints) and, in some cases, execute attacker-supplied code within the browser context, enabling unauthorized access to sensitive business sessions and data. This leads to incident response and recovery costs, potential regulatory or contractual exposure if sensitive information is disclosed, and reputational damage.

Threat

A financially motivated, technically capable cybercriminal actor operating malicious or weaponized browser extensions distributed through mainstream browser extension marketplaces.

Method

The actor publishes and maintains browser extensions that appear legitimate, accumulates installs and trust signals, then uses the trusted extension auto-update pipeline and granted permissions to collect browser data (URLs, searches, clicks, cookies/fingerprints) and communicate with attacker infrastructure; in higher-impact cases, the extension periodically downloads and executes attacker-supplied JavaScript, enabling dynamic post-compromise actions within the browser context.

Asset

User endpoints (Chrome/Edge browsers), enterprise web sessions, and browser-accessible organizational resources (SaaS/cloud consoles, internal web apps), including any sensitive data reachable via authenticated browser sessions.

Impact

Losses may include unauthorized disclosure of browsing-derived sensitive information, account/session compromise (leading to downstream fraud or unauthorized access), incident response and eradication effort (extension removal, credential/session resets, endpoint validation), and potential regulatory, contractual, or reputational consequences if enterprise data or regulated information is exposed through the browser channel.

Evidentiary Basis for Synopsis and Recommendations

Supporting observations from the analysis help clarify how the threat landscape, control environment, and organizational behaviors interact to shape overall risk exposure. These insights provide the foundation for identifying where controls perform well, where gaps or weaknesses create unnecessary vulnerability, and how attacker methods intersect with real-world operational conditions. Building on these findings, the recommendations that follow focus on strengthening resilience, improving decision-making, and guiding readers toward practical steps that enhance both security posture and risk-informed governance.

FAIR Breakdown

Threat Event Frequency (TEF)

Because the OSINT describes widespread marketplace distribution and ongoing extension activity rather than per-organization activity counts, TEF must be inferred from the scale (millions of installs), the persistence of the ecosystem, and the “silent update” delivery model. For a typical mid-to-large enterprise with broad browser use, TEF is estimated as moderate, driven primarily by user installation/retention of high-permission extensions and continued outbound beaconing from infected browsers.

Contact Frequency (CF)

Contact Frequency in this scenario represents how often a malicious or later-weaponized browser extension meaningfully comes into contact with an organizational asset, which occurs primarily through initial installation or continued retention of an extension that is subsequently updated into a malicious state. CF is highly organization-dependent and varies based on the type of compromised extension (e.g., utility or productivity tools versus niche add-ons), the propensity of users within the organization to install or retain such extensions (driven by role, browser usage patterns, and trust in marketplace signals), and the strength of extension governance controls such as allowlisting, approval workflows, and monitoring of post-install behavior. In organizations with strong extension controls and limited user installation privileges, contact events are expected to be rare and episodic, occurring only when governance gaps or legacy installs exist; in contrast, organizations that permit unrestricted extension installation or lack ongoing review are more likely to experience occasional exposure. Based on these factors, CF is reasonably estimated at approximately 0.2–0.5 events per year (one contact every two to five years per organization), reflecting low-frequency but non-negligible exposure consistent with long-dwell, supply-chain–style abuse rather than recurring or continuous threat contact.

Probably of Action (PoA)

PoA is estimated to be high because the described operations emphasize long-term exploitation, active data collection at scale, and (in some cases) a standing “backdoor” capability that can be updated to change behavior. Estimated PoA: 0.75 (75%) once a target environment includes an installed malicious/high-risk extension with network access.

Threat Capability (TCap)

TCap is high, reflecting mature tradecraft for marketplace abuse, permission exploitation, anti-analysis behavior, and flexible payloading through downloaded scripts.

Exploit sophistication: High (weaponization via trusted marketplace updates; downloaded arbitrary JavaScript execution).

Bypass ability: Moderate-to-high (anti-analysis switching to benign behavior when developer tools are opened; obfuscation and interpreter-based execution to evade policy controls).

Tooling maturity: High (multi-year operations; consistent infrastructure; described RCE framework + telemetry collection).

Campaign success rate: Moderate (depends on users installing/keeping extensions; success can be high within populations that rely on “Featured/Verified” trust signals).

Attack path sophistication: High (trust-building > permissioned install base > silent update > surveillance/exfiltration; optional RCE channel).

Cost to run attack: Low-to-moderate (higher upfront development and patience; low marginal cost per additional victim via store distribution and auto-update).

Control Strength (CS)

Typical enterprises have partial controls over extensions and browser egress, but the OSINT’s core advantage is operating inside a trusted browser component with broad permissions; therefore, CS is estimated as moderate at best unless extension governance is strict.

Resistive Strength (RS) Effectiveness of preventive/detective controls:

• Enterprise allowlisting/denylisting of browser extensions and required approvals can prevent the installation of unknown publishers.

• Endpoint security and browser security tooling may flag suspicious extension behavior (unexpected network beacons, script injection), but detection is not guaranteed when behavior is obfuscated.

• Network controls can detect/block known IOC domains, reducing successful check-ins and exfiltration.

Control Failure Rate

• Unmanaged or self-service extension installation (no governance) enables high-permission spyware-style extensions to persist.

• Insufficient monitoring of browser extension behavior post-install allows “silent update” weaponization to go unnoticed.

• Lack of egress filtering/DNS controls allows recurring check-ins to attacker-controlled domains.

Susceptibility

Given high threat capability and typically inconsistent extension governance, susceptibility is estimated at 45% (0.45) per meaningful “contact” event (i.e., where at least one risky extension is installed and communicating externally). This reflects (1) exploitability driven by permissions + update channels, (2) broad attack surface via browser usage, and (3) exposure conditions where users rely on store trust signals rather than technical verification.

Probability the asset will be harmed is influenced by:

Exploitability: Estimated at 65–80 percent because the attack leverages granted extension permissions and trusted auto-update channels rather than a technical vulnerability, making success largely dependent on whether the extension is present and active rather than on exploit complexity.

Attack surface: Approximately 30–60 percent of an organization’s user population may be exposed depending on browser usage patterns, role-based need for extensions, and whether users are permitted to self-install productivity or utility add-ons.

Exposure conditions: Susceptibility increases in environments where users rely heavily on browsers for daily operations and where extensions have long dwell times without periodic review; in such cases, effective exposure during a weaponized update window may reach 50–70 percent among affected users.

Patch status: Patch posture provides minimal mitigation (estimated 0–10 percent impact) because the attack path bypasses traditional software vulnerabilities and instead exploits legitimate extension functionality, permissions, and update mechanisms rather than flaws remediated through standard patching.

Numerical Frequencies and Magnitudes

All values relating to actual dollar amounts are for example/speculative purposes only. Organizations would need to take into account their own asset values, control strength, telemetry, etc., and adjust numbers accordingly.

Loss Event Frequency (LEF)

.06–.19/year (estimated)

• Justification: Even when contact occurs, harm is not guaranteed; however, high-permission extensions and trusted update channels create a meaningful chance of loss once exposure exists.

Vulnerability (probability of harm per contact): .4–.5

• Justification: Vulnerability is estimated at 40–50 percent because the threat demonstrates high capability through trusted extension permissions, silent auto-updates, and optional remote code execution, while organizational controls over extension behavior and outbound communication are often only moderately effective. As a result, once contact occurs, the likelihood of harm is meaningful but not certain, reflecting the balance between strong attacker leverage and uneven defensive control strength.

Secondary Loss Event Frequency

.02–.08/year (estimated)

• Justification: Only a subset of primary loss events are expected to lead to secondary consequences such as downstream account misuse, broader SaaS compromise, or regulatory response; this assumes approximately 30–40 percent of primary events cascade into secondary impacts.

Loss Magnitude

Estimated range:

• Min: $15,000

• Most Likely: $90,000

• Maximum: $400,000

Justification:

• The minimum reflects localized incident response, extension removal, browser session invalidation, and limited user downtime.

• The most likely value includes broader investigation across multiple endpoints, credential and token resets, temporary productivity loss, and security control tuning.

• The maximum reflects scenarios where compromised browser sessions expose sensitive business systems, require external response support, or trigger contractual or regulatory obligations.

Secondary Loss Magnitude (SLM)

Estimated range:

• Min: $30,000

• Most Likely: $250,000

• Maximum: $2,500,000

Justification:

• Secondary losses may arise from misuse of harvested sessions or credentials, unauthorized access to cloud or SaaS environments, fraud, legal or regulatory response, and reputational harm. The upper bound reflects high-impact but low-probability outcomes where browser-based access materially contributes to a wider organizational compromise.

Mapping, Controls, and Modeling

MITRE ATT&CK Mapping

Resource Development

T1583.001 – Acquire Infrastructure: Domains

Reference: “Every hour, it checks api.extensionplay[.]com…” and IOC domains listed (e.g., extensionplay[.]com, cleanmasters[.]store).

Initial Access

T1195.002 – Supply Chain Compromise: Compromise Software Supply Chain

Reference: “Automatic infection via Chrome and Edge's trusted auto-update mechanism… silent updates.”

Execution

T1059.007 – Command and Scripting Interpreter: JavaScript

Reference: “downloads arbitrary JavaScript, and executes it with full browser API access.”

Persistence

T1176 – Browser Extensions

Reference: “Five extensions… weaponized… operated legitimately for years… update mechanism runs automatically.”

Defensive Evasion

T1027 – Obfuscated/Encrypted File or Information

Reference: “heavy obfuscation… executes through a 158KB JavaScript interpreter.”

T1622 – Debugger Evasion

Reference: “If a researcher opens developer tools, the malware detects it and switches to benign behavior.”

Credential Access

T1539 – Steal Web Session Cookie

Reference: “Cookie exfiltration: Extensions read cookies… and send tracking data…” and “can access all cookies.”

Discovery

T1082 – System Information Discovery

Reference: “Complete browser fingerprints: user agent, language, platform, screen resolution, timezone.”

Collection

T1056.001 – Input Capture: Keylogging

Reference: “Search query harvesting… Every keystroke in the search box sent to external servers…”

Command and Control

T1071.001 – Application Layer Protocol: Web Protocols

Reference: “checks api.extensionplay[.]com for new instructions” and transmits collected data to external servers.

Exfiltration

T1041 – Exfiltration Over C2 Channel

Reference: “exfiltrates encrypted browsing history… data encrypted… before sending…” and spyware telemetry “transmitting data to servers in China.”

NIST 800-53 Affected Controls

SI-3 — Malicious Code Protection

Reference: “downloads arbitrary JavaScript, and executes it with full browser API access.” This behavior is classic malicious code execution occurring inside a trusted extension context, pressuring endpoint/browser anti-malware effectiveness.

SI-4 — System Monitoring

Reference: “Every hour, it checks api.extensionplay[.]com for new instructions…” and “exfiltrates… to… servers.” This highlights the need to monitor recurring outbound connections and anomalous browser/extension telemetry.

AU-2 — Event Logging

Reference: “service worker can intercept and modify network traffic…” and ongoing data collection/exfiltration. Logging is required to reconstruct extension installs/updates, browser policy changes, and suspicious network activity paths.

AU-6 — Audit Record Review, Analysis, and Reporting

Reference: “Anti-analysis… switches to benign behavior” and “heavy obfuscation.” The OSINT implies defenders must actively review and analyze telemetry rather than rely on static approval signals.

CM-7 — Least Functionality

Reference: “dangerous permissions including access to all URLs and cookies.” The least functionality supports restricting browser extension permissions and limiting the installed extension set to business-necessary functionality.

CM-11 — User-Installed Software (and enhancements)

Reference: “Users are downloading them right now” and “extensions… remain live in the Microsoft Edge marketplace.” This maps to governing and monitoring user-installed extensions as software components.

SR-5 — Acquisition Strategies, Tools, and Methods

Reference: “Marketplaces review extensions at submission… They don't watch what happens after approval.” This reinforces the need for supply-chain-aware acquisition/approval strategies for third-party software sources like extension stores.

PM-30 — Supply Chain Risk Management Strategy

Reference: “The auto-update mechanism… became the attack vector.” This supports an enterprise-wide SCRM strategy for marketplace software, update channels, and continuous evaluation beyond initial approval.

AT-2(3) — Social Engineering and Mining

Reference: “Featured and Verified… granting instant trust and massive distribution.” The OSINT demonstrates exploitation of user trust signals (badges/reviews) as a human-layer weakness that training and awareness must address.

Monitoring, Hunting, Response, and Reversing

Monitoring

Implement monitoring that treats browser extensions as a supply-chain and identity-adjacent risk by instrumenting endpoint, network, DNS, cloud/SaaS, and identity telemetry to detect suspicious extension lifecycle events and abnormal browser-to-internet communications associated with high-permission add-ons. Required sources include endpoint/browser management logs for extension install/update/remove events (including publisher, version changes, and permission sets), EDR process and script telemetry to flag anomalous browser child processes or unexpected script execution patterns, DNS and proxy logs to capture recurring resolution/HTTP(S) requests to known or newly observed extension-related domains, and cloud/identity logs (SSO, IdP, SaaS audit) to detect session anomalies consistent with cookie/session theft (new geolocation, impossible travel, atypical user-agent/fingerprint changes, and spikes in token refresh or login prompts). Logging sufficiency typically requires increasing retention and fidelity for browser policy and extension telemetry (including periodic snapshots of installed extensions), enabling DNS query logging for corporate resolvers, and ensuring proxy logs include full URI/SNI/JA3 where available to support attribution and clustering. Key indicators to prioritize include extension updates that materially change permissions, extensions that beacon on regular intervals, unusual access to cookies/storage APIs, and outbound traffic to rare domains shortly after extension updates; the major monitoring gaps exposed are unmanaged extension inventories, weak egress visibility for browser traffic, and limited correlation between browser events and identity/session anomalies. Correlation logic should alert when (1) a new or updated extension with broad permissions appears and is followed by first-seen outbound connections to rare domains within 24 hours, (2) repeated periodic beacons occur from the same endpoint/user to the same rare domain over multiple days, or (3) extension change events precede anomalous SaaS/SSO activity for that user within 1–72 hours, with thresholds tuned to reduce noise by excluding known corporate-approved extensions and common CDN domains. Dashboards should add metrics for extension inventory coverage, count of high-permission extensions by business unit, top new extension publishers, “permission delta” events, rare-domain beaconing tied to browser processes, and a joined view of extension events with SSO anomalies, and validation should be performed by simulating extension install/update in a controlled lab (or using scripted browser policy changes) and confirming end-to-end visibility, correlation, and alert firing without relying on malware execution.

Hunting

Run proactive hunts built around hypotheses that the organization contains at least one high-risk extension instance enabling covert data access or external communications, and that some identity anomalies may be downstream of browser-session exposure rather than classic credential phishing. Primary hypotheses should include: endpoints with extensions that recently updated and gained broad permissions are now communicating with rare or newly registered domains; a subset of users exhibit identity/session anomalies (new user-agent/fingerprint shifts, unusual SaaS access patterns) that correlate temporally with extension changes; and specific endpoints show repeated, regular outbound connections consistent with command retrieval or telemetry exfiltration. Telemetry should focus on browser/endpoint extension inventories and permission deltas, DNS/proxy logs for rare-domain frequency and periodicity, EDR for browser process integrity and unexpected script execution artifacts, and IdP/SaaS logs for session behavior anomalies and unusual API usage. Detection logic should emphasize low-noise pivots such as “new extension publisher + broad permissions + rare-domain outbound within 24 hours,” “periodic beaconing to uncommon domains tied to browser process,” and “extension update event preceding anomalous token/session behavior,” while managing noise by allowlisting sanctioned extensions/publishers, scoping hunts to endpoints with unmanaged installation rights, and prioritizing outliers (first-seen domains, high permission sets, and repeated patterns over time) rather than single events.

Response

Prepare response playbooks that prioritize rapid scoping of extension presence and identity/session risk, with logs and artifacts centered on extension provenance, update timing, and outbound communications rather than traditional exploit traces. Required logs include endpoint/browser management records of extension installs and updates (publisher, version history, permission deltas), proxy/DNS logs for all outbound traffic associated with the browser at relevant times, and IdP/SaaS audit logs capturing session creation, token refresh, and anomalous access patterns for impacted users; priority artifacts include a full list of installed extensions with IDs, local extension files and configuration/state where feasible, browser profile data relevant to extension storage, and network indicators observed during the suspicious window. Expect anti-forensic behavior in the form of obfuscation and “benign mode” when developer tools are opened, so reconstruction should rely on time-based correlation across extension update events, network beacons, and identity anomalies, supplemented by endpoint triage that captures extension directories and browser policy state before remediation. DFIR evidence should be structured to feed FAIR loss estimates by recording the number of affected endpoints/users, duration of exposure, count of identity resets/token revocations, confirmed data access indicators, and hours/costs expended across IR and business teams, enabling credible LEF/LM refinement. Likely containment includes immediate removal/disablement via centralized policy, blocking identified domains at DNS/proxy, forced browser session invalidation and credential/token resets for exposed users, and tightening extension governance (allowlist/approval) to prevent reintroduction; IR gaps to address include insufficient extension inventory coverage, limited historical visibility into extension updates, and lack of joined telemetry between browser events and identity systems, with DFIR validation performed via controlled re-install/update testing to confirm blocks, detections, and eradication completeness.

Reverse Engineering

Focus reverse engineering on extension package acquisition and behavioral verification to understand how the extension transitions from benign to malicious, what triggers command retrieval, and what data-access APIs are used, treating the extension update channel as the effective “loader” mechanism. Analyze how the extension fetches and executes remote content (e.g., downloaded JavaScript), how it stores persistence and identifiers within browser storage/sync mechanisms, and what evasion logic detects analysis conditions (such as toggling behavior when developer tools are opened), along with obfuscation methods that hinder static review. Prioritize extracting and documenting indicators embedded in the extension code (domains, URL paths, request patterns, headers), mapping API calls tied to cookie/storage access, request interception via service worker behavior, and any modular interpreter or dynamic execution constructs that enable flexible payloading. Expected artifacts include extension IDs, versioned packages, manifest permission sets, background/service worker scripts, local storage keys/UUIDs, and consistent network request patterns suitable for signatures, and additional reverse engineering suggestions include building a sandboxed browser profile to run the extension while capturing network/DOM/API telemetry, performing differential analysis across pre- and post-weaponization versions to highlight “permission deltas” and new code paths, and producing YARA-like content patterns for obfuscation frameworks or interpreters commonly reused across related extensions.

CTI

Prioritize CTI collection and analysis that tests whether the observed extension abuse pattern is likely to affect your sector, geography, and critical partners by continuously tracking marketplace takedowns, publisher clusters, and extension families that share infrastructure, code signing traits, or obfuscation patterns, while estimating recurrence by monitoring for new extensions from the same publishers and re-uploads under alternate names over time. Strengthen SIR coverage by identifying gaps in infrastructure relationships (domain-to-publisher-to-extension mappings), obtaining additional IOCs beyond domains (e.g., consistent URL paths, request schemas, extension IDs and version hashes where available), and pursuing samples of extension packages for repeatable validation and detection engineering, while explicitly recording attribution confidence as “financially motivated, technically capable marketplace-abuse actor” unless corroborated by independent sources. Collection should blend OSINT (vendor reporting, store listings, takedown notes, sandbox reports) with internal telemetry (extension inventories, DNS/proxy outliers, identity anomalies) and external sharing via relevant ISACs/ISAOs to discover sector-specific targeting trends and common TTP reuse. Mapping should continuously update ATT&CK alignment for consistent behaviors (extension persistence, web protocol C2, input capture, cookie theft, obfuscation/debugger evasion), compare with historical browser-extension abuse cases in your environment, and validate or refute hypotheses by correlating newly surfaced intelligence with observed internal signals and confirmed investigative outcomes.

GRC and Testing

Governance

Update governance to explicitly treat browser extensions and marketplace-delivered updates as a managed supply-chain channel by establishing or tightening policy that defines approved extension sources, mandatory allowlisting, permission-based risk thresholds, and periodic re-authorization of installed extensions, with clear accountability for exceptions and revocation. Strengthen oversight by assigning joint ownership across security (risk and detection), IT/endpoint engineering (browser configuration and policy enforcement), and privacy/compliance (data exfiltration exposure), and require periodic executive review of extension governance posture (inventory coverage, high-permission counts, exceptions, and exposure trends). Refresh RA/PM/PL family governance artifacts to include a formal extension risk assessment standard (RA), a program plan for continuous extension monitoring and enforcement (PM), and explicit rules within system security plans and configuration management baselines that prohibit unmanaged extension installation and require evidence of ongoing behavioral evaluation (PL/related planning documentation). Update the risk register with a discrete risk entry for “marketplace extension abuse leading to surveillance/session exposure,” including risk owners, measurable KRIs (e.g., unmanaged endpoints, high-permission extension prevalence, exception rate), and defined risk treatments (policy enforcement, monitoring, and response playbooks). Require board/executive communications that frame this as low-frequency/high-impact exposure affecting identity and SaaS access paths, with reporting that ties control maturity to quantified risk changes (e.g., reduction in contact frequency via allowlisting, reduced vulnerability via monitoring and egress controls) and establishes decision points for risk appetite, budget, and enforcement authority.

Audit and Offensive Security Testing

Direct audit and offensive testing to validate whether extension governance and browser-to-identity monitoring actually prevent or detect marketplace-abuse scenarios by scoping audits to extension inventories, approval workflows, enforcement coverage, and evidence that extension behavior is monitored post-install rather than only at acquisition time. Prioritize audit findings that expose evidence gaps such as missing extension install/update logs, lack of permission-delta tracking, insufficient DNS/proxy retention to reconstruct extension communications, and weak linkage between browser telemetry and IdP/SaaS session anomalies, because these gaps directly increase uncertainty and inflate loss estimates. Validate that policies and controls are not merely documented by testing whether allowlists are enforced on managed endpoints, whether exceptions are time-bounded and reviewed, and whether high-permission extensions trigger governance actions, then tie compliance requirements to the scenario by mapping the extension channel to software supply chain expectations and data-protection obligations where browser-derived data could be sensitive. Use red-team exercises to simulate the operational pattern (install a benign extension, introduce a permission-increasing update, generate periodic outbound traffic, and attempt cookie/session access within the allowed permission model) and measure whether detection, response, and identity containment trigger at the expected thresholds; use purple-team sessions to tune correlation rules around “extension update + rare-domain egress + SSO anomaly.” Ensure pen testing scope includes browser policy controls, extension management APIs, and network egress controls, with exploit reproduction focused on demonstrating data collection and session exposure behaviors rather than creating speculative destructive impact, and require control validation deliverables that document which controls prevented contact (installation/update) versus which controls reduced vulnerability (monitoring, egress, identity/session protections).

Awareness Training

Adjust awareness training to address the specific trust failures highlighted by the OSINT by teaching employees that marketplace trust signals (featured/verified badges, high install counts, positive reviews) are not security guarantees and that browser extensions can silently change behavior through updates and permissions over time. Focus on human failure modes that drive susceptibility, including convenience-driven installation, “permission blindness” (accepting broad access such as “read and change all data on all websites”), and failure to report unusual browser behavior (new toolbars, search redirection, unexpected prompts, unexplained performance issues, or persistent logouts), and reinforce that extensions can expose sessions and data even without classic phishing. Provide role-specific training: admins and IT staff should be trained on enforcing allowlists and responding to permission-delta alerts; finance and customer-facing staff should be trained to minimize installation of non-approved productivity tools and to report anomalous browser behavior quickly; executives should receive short, outcome-focused guidance on why browser trust can translate into identity and reputational risk. Update simulations to include extension-themed scenarios (requests to install productivity add-ons, prompts to grant broad permissions, and “helpful” new-tab tools) and measure effectiveness through reduction in unauthorized installation attempts, increased reporting of suspicious extension prompts, and improved completion of periodic extension reviews, reinforced on a scheduled cycle with metrics tied to behavior change rather than course completion.

Indicators of Compromise

All IoCs from the original artifact

C&C Domains

extensionplay[.]com

yearnnewtab[.]com

api.cgatgpt[.]net

Exfiltrations Domains

dergoodting[.]com

yearnnewtab[.]com

cleanmasters[.]store

s-85283.gotocdn[.]com

s-82923.gotocdn[.]com

Chrome Extensions

eagiakjmjnblliacokhcalebgnhellfi

ibiejjpajlfljcgjndbonclhcbdcamai

ogjneoecnllmjcegcfpaamfpbiaaiekh

jbnopeoocgbmnochaadfnhiiimfpbpmf

cdgonefipacceedbkflolomdegncceid

gipnpcencdgljnaecpekokmpgnhgpela

bpgaffohfacaamplbbojgbiicfgedmoi

ineempkjpmbdejmdgienaphomigjjiej

nnnklgkfdfbdijeeglhjfleaoagiagig

Mljmfnkjmcdmongjnnnbbnajjdbojoci

llkncpcdceadgibhbedecmkencokjajg

nmfbniajnpceakchicdhfofoejhgjefb

ijcpbhmpbaafndchbjdjchogaogelnjl

olaahjgjlhoehkpemnfognpgmkbedodk

gnhgdhlkojnlgljamagoigaabdmfhfeg

cihbmmokhmieaidfgamioabhhkggnehm

lehjnmndiohfaphecnjhopgookigekdk

hlcjkaoneihodfmonjnlnnfpdcopgfjk

hmhifpbclhgklaaepgbabgcpfgidkoei

lnlononncfdnhdfmgpkdfoibmfdehfoj

nagbiboibhbjbclhcigklajjdefaiidc

ofkopmlicnffaiiabnmnaajaimmenkjn

ocffbdeldlbilgegmifiakciiicnoaeo

eaokmbopbenbmgegkmoiogmpejlaikea

lhiehjmkpbhhkfapacaiheolgejcifgd

ondhgmkgppbdnogfiglikgpdkmkaiggk

imdgpklnabbkghcbhmkbjbhcomnfdige

Edge Add-ons

bpelnogcookhocnaokfpoeinibimbeff

enkihkfondbngohnmlefmobdgkpmejha

hajlmbnnniemimmaehcefkamdadpjlfa

aadnmeanpbokjjahcnikajejglihibpd

ipnidmjhnoipibbinllilgeohohehabl

fnnigcfbmghcefaboigkhfimeolhhbcp

nlcebdoehkdiojeahkofcfnolkleembf

fhababnomjcnhmobbemagohkldaeicad

nokknhlkpdfppefncfkdebhgfpfilieo

ljmcneongnlaecabgneiippeacdoimaa

onifebiiejdjncjpjnojlebibonmnhog

dbagndmcddecodlmnlcmhheicgkaglpk

fmgfcpjmmapcjlknncjgmbolgaecngfo

kgmlodoegkmpfkbepkfhgeldidodgohd

hegpgapbnfiibpbkanjemgmdpmmlecbc

gkanlgbbnncfafkhlchnadcopcgjkfli

oghgaghnofhhoolfneepjneedejcpiic

fcidgbgogbfdcgijkcfdjcagmhcelpbc

nnceocbiolncfljcmajijmeakcdlffnh

domfmjgbmkckapepjahpedlpdedmckbj

cbkogccidanmoaicgphipbdofakomlak

bmlifknbfonkgphkpmkeoahgbhbdhebh

ghaggkcfafofhcfppignflhlocmcfimd

hfeialplaojonefabmojhobdmghnjkmf

boiciofdokedkpmopjnghpkgdakmcpmb

ibfpbjfnpcgmiggfildbcngccoomddmj

idjhfmgaddmdojcfmhcjnnbhnhbmhipd

jhgfinhjcamijjoikplacnfknpchndgb

cgjgmbppcoolfkbkjhoogdpkboohhgel

afooldonhjnhddgnfahlepchipjennab

fkbcbgffcclobgbombinljckbelhnpif

fpokgjmlcemklhmilomcljolhnbaaajk

hadkldcldaanpomhhllacdmglkoepaed

iedkeilnpbkeecjpmkelnglnjpnacnlh

hjfmkkelabjoojjmjljidocklbibphgl

dhjmmcjnajkpnbnbpagglbbfpbacoffm

cgehahdmoijenmnhinajnojmmlnipckl

fjigdpmfeomndepihcinokhcphdojepm

chmcepembfffejphepoongapnlchjgil

googojfbnbhbbnpfpdnffnklipgifngn

fodcokjckpkfpegbekkiallamhedahjd

igiakpjhacibmaichhgbagdkjmjbnanl

omkjakddaeljdfgekdjebbbiboljnalk

llilhpmmhicmiaoancaafdgganakopfg

nemkiffjklgaooligallbpmhdmmhepll

papedehkgfhnagdiempdbhlgcnioofnd

glfddenhiaacfmhoiebfeljnfkkkmbjb

pkjfghocapckmendmgdmppjccbplccbg

gbcjipmcpedgndgdnfofbhgnkmghoamm

ncapkionddmdmfocnjfcfpnimepibggf

klggeioacnkkpdcnapgcoicnblliidmf

klgjbnheihgnmimajhohfcldhfpjnahe

acogeoajdpgplfhidldckbjkkpgeebod

ekndlocgcngbpebppapnpalpjfnkoffh

elckfehnjdbghpoheamjffpdbbogjhie

dmpceopfiajfdnoiebfankfoabfehdpn

gpolcigkhldaighngmmmcjldkkiaonbg

dfakjobhimnibdmkbgpkijoihplhcnil

hbghbdhfibifdgnbpaogepnkekonkdgc

fppchnhginnfabgenhihpncnphhafmac

ghhddclfklljabeodmcejjjlhoaaiban

bppelgkcnhfkicolffhlkbdghdnjdkhi

ikgaleggljchgbihlaanjbkekmmgccam

bdhjinjoglaijpffoamhhnhooeimgoap

fjioinpkgmlcioajfnncgldldcnabffe

opncjjhgbllenobgbfjbblhghmdpmpbj

cbijiaccpnkbdpgbmiiipedpepbhioel

fbbmnieefocnacnecccgmedmcbhlkcpm

hmbacpfgehmmoloinfmkgkpjoagiogai

paghkadkhiladedijgodgghaajppmpcg

bafbmfpfepdlgnfkgfbobplkkaoakjcl

kcpkoopmfjhdpgjohcbgkbjpmbjmhgoi

jelgelidmodjpmohbapbghdgcpncahki

lfgakdlafdenmaikccbojgcofkkhmolj

hdfknlljfbdfjdjhfgoonpphpigjjjak

kpfbijpdidioaomoecdbfaodhajbcjfl

fckphkcbpgmappcgnfieaacjbknhkhin

lhfdakoonenpbggbeephofdlflloghhi

ljjngehkphcdnnapgciajcdbcpgmpknc

ejfocpkjndmkbloiobcdhkkoeekcpkik

ccdimkoieijdbgdlkfjjfncmihmlpanj

agdlpnhabjfcbeiempefhpgikapcapjb

mddfnhdadbofiifdebeiegecchpkbgdb

alknmfpopohfpdpafdmobclioihdkhjh

hlglicejgohbanllnmnjllajhmnhjjel

iaccapfapbjahnhcmkgjjonlccbhdpjl

ehmnkbambjnodfbjcebjffilahbfjdml

ngbfciefgjgijkkmpalnmhikoojilkob

laholcgeblfbgdhkbiidbpiofdcbpeeo

njoedigapanaggiabjafnaklppphempm

fomlombffdkflbliepgpgcnagolnegjn

jpoofbjomdefajdjcimmaoildecebkjc

nhdiopbebcklbkpfnhipecgfhdhdbfhb

gdnhikbabcflemolpeaaknnieodgpiie

bbdioggpbhhodagchciaeaggdponnhpa

ikajognfijokhbgjdhgpemljgcjclpmn

lmnjiioclbjphkggicmldippjojgmldk

ffgihbmcfcihmpbegcfdkmafaplheknk

lgnjdldkappogbkljaiedgogobcgemch

hiodlpcelfelhpinhgngoopbmclcaghd

mnophppbmlnlfobakddidbcgcjakipin

jbajdpebknffiaenkdhopebkolgdlfaf

ejdihbblcbdfobabjfebfjfopenohbjb

ikkoanocgpdmmiamnkogipbpdpckcahn

ileojfedpkdbkcchpnghhaebfoimamop

akialmafcdmkelghnomeneinkcllnoih

eholblediahnodlgigdkdhkkpmbiafoj

ipokalojgdmhfpagmhnjokidnpjfnfik

hdpmmcmblgbkllldbccfdejchjlpochf

iphacjobmeoknlhenjfiilbkddgaljad

jiiggekklbbojgfmdenimcdkmidnfofl

gkhggnaplpjkghjjcmpmnmidjndojpcn

opakkgodhhongnhbdkgjgdlcbknacpaa

nkjomoafjgemogbdkhledkoeaflnmgfi

ebileebbekdcpfjlekjapgmbgpfigled

oaacndacaoelmkhfilennooagoelpjop

ljkgnegaajfacghepjiajibgdpfmcfip

hgolomhkdcpmbgckhebdhdknaemlbbaa

bboeoilakaofjkdmekpgeigieokkpgfn

dkkpollfhjoiapcenojlmgempmjekcla

emiocjgakibimbopobplmfldkldhhiad

nchdmembkfgkejljapneliogidkchiop

lljplndkobdgkjilfmfiefpldkhkhbbd

hofaaigdagglolgiefkbencchnekjejl

hohobnhiiohgcipklpncfmjkjpmejjni

jocnjcakendmllafpmjailfnlndaaklf

bjdclfjlhgcdcpjhmhfggkkfacipilai

ahebpkbnckhgjmndfjejibjjahjdlhdb

enaigkcpmpohpbokbfllbkijmllmpafm

bpngofombcjloljkoafhmpcjclkekfbh

cacbflgkiidgcekflfgdnjdnaalfmkob

ibmgdfenfldppaodbahpgcoebmmkdbac