ChatGPT Stealer Explained: The Risk of Malicious Browser Extensions

Malicious Chromium extensions exfiltrating AI conversations

The Stripe OLT SOC recently observed a malware campaign – commonly referred to as ChatGPT Stealer –  leveraging two Chromium-compatible browser extensions to collect and exfiltrate chatbot conversations and browsing activity. While the extensions were distributed via the Chrome Web Store, the same extension format runs across Chromium-based browsers.

In our investigation, we saw indicators consistent with data theft in both Google Chrome and Microsoft Edge. Both extensions have since been removed from the Chrome Web Store, which limits new installs, but does not reduce the risk for users who had already installed them, as data may have been accessed before removal.

This write-up consolidates the known behaviours of the extensions, outlines the data at risk, and describes practical indicators and response actions.

This campaign presents an information exposure problem with a browser-delivered collection capability, rather than as a simple ‘malicious add-on’ scenario.

Attack Scope & Affected Artefacts

The activity centres around two extensions that presented as AI productivity tooling for ChatGPT, DeepSeek and Claude:

Both extensions provided real functionality, which is operationally important. A non-functional extension is quickly removed. A functional one can remain resident for weeks or months, increasing data volume and enabling repeated collection across different chat sessions and web activity.

This also affects how defenders should think about risk. User intent is not necessarily “install something shady”. The user is installing what appears to be a useful extension with plausible branding – the threat sits in the mismatch between what the extension claims to collect and what it actually collects.

High Value Data Colleciton

From what we can see, the collection behaviour can be separated into two categories: AI conversation content and browsing activity.

AI Conversation Content

The extensions collected full chat transcripts from supported chatbot sites, including user prompts and assistant responses. This matters because modern AI usage patterns often include:

• Source code and configuration snippets
• Internal architecture diagrams and workflows described in text
• Incident response notes or troubleshooting details
• Customer-related information and identifiers
• Business planning content that would otherwise live in documents or tickets

The assistant’s response should be treated as potentially sensitive as well. Responses frequently quote, summarise, transform, or structure sensitive user-supplied content. The transcript therefore becomes a clean, readable extract of what a user was working on.

Browsing Activity

In addition to chats, the extensions collected URLs from active browser tabs. This can be sensitive even without page content. URL sets can reveal:

• Internal tools and naming conventions
• SaaS vendors and third-party service usage
• Administrative consoles and privileged portals
• Query strings and parameters that may contain identifiers or session artefacts
• Investigation trails, search queries, and the user’s current focus areas

For organisations, this is essentially a reconnaissance feed. It helps an attacker understand what systems exist, what teams use, and what an individual might have access to. For individuals, it supports highly tailored social engineering.

Operational Behaviour: How Collection & Exfiltration Worked

These extensions did not require a browser exploit to operate. They relied on standard extension capabilities and permissions that many users accept without deep scrutiny.

Permission Model & Access

The extensions requested broad permissions that enabled interaction with website content. From the user’s perspective, this is justified by the feature: an AI sidebar that “works everywhere”. In practice, those permissions enable a wide range of collection behaviours.

Targeting Logic

The extensions monitored browser context to identify relevant sessions. A common approach is URL-based detection: if the active tab matches known chatbot domains, the extension triggers collection routines. This keeps collection targeted (chat pages) while also continuing passive collection for browsing metadata.

Chat Extraction

Once a target chat page is identified, the extension can read the rendered conversation from the page’s Document Object Model (DOM). This is not “screen scraping” in the visual sense, but structured text extraction from the elements that display the chat. That is sufficient to capture full prompts and responses.

Local Staging & Scheduled Exfiltration

Rather than sending data immediately, the extensions staged data locally and transmitted it on a schedule. Reported behaviour was to exfiltrate in batches roughly every 30 minutes. This is a practical evasion tactic: it reduces the frequency of network events and makes the activity easier to blend into normal extension telemetry patterns.

Victim Identification & Longitudinal Collection

The extensions generated a per-install identifier for tracking. This enables an operator to associate multiple data batches with a single user profile and build continuity over time. From a threat perspective, that increases the value of the dataset. From a defence perspective, it signals intent beyond opportunistic collection.

Retention Nudges

A further behavioural detail we identified was that uninstalling one extension could prompt the user towards installing the other one. This is not persistence in the classic sense, but it is behavioural manipulation designed to keep at least one implant installed.

High Value Data Colleciton

Because these are Chromium extensions, the same extension package can operate in multiple browsers (assuming the installation route is available). While the initial distribution was via the Chrome Web Store, Chromium-based browsers like Microsoft Edge can run the same extension format.

In our observations, the theft was not confined to a single browser, so any future investigations related to this attack vector, should also include:

• Chrome extension inventory (all user profiles)
• Edge extension inventory (all user profiles)
• Endpoints where users switch browsers for work vs personal use
• Browser sync considerations, where extension installs propagate across devices

Indicators Suitable for Investigation & Detection

The following artefacts are directly actionable for scoping and containment .

Permission Model & Access

fnmihdojmnkclgjpcoonokmkhjpjechg
inhcgfpbfdjbjogdfjbclgolkmhnooop

Malicious Domains

deepaichats.com
chatsaigpt.com
chataigpt.pro
chatgptsidebar.pro
deepseek.ai
chatgptbuddy.com

File hashes (SHA256)

98d1f151872c27d0abae3887f7d6cb6e4ce29e99ad827cb077e1232bc4a69c00

20ba72e91d7685926c8c1c5b4646616fa9d769e32c1bc4e9f15dddaf3429cea7

Use these in three ways:

• Endpoint inventory (extension IDs)
• Network scoping (DNS/proxy logs)
• File-based verification (hashes).

If you have limited telemetry, the domain list is often the fastest starting point, especially when combined with periodic outbound activity.

Response Actions, Framed as Data Exposure Management

The key decision here is to treat impacted users as potentially having suffered an information exposure event. Cleaning up the extension is necessary but insufficient.

Step 1: Containment

• Remove the extensions across managed endpoints by deleting the extension files.
• Block reinstallation using enterprise policy and managed browsers where possible.
• Apply controls to both Google Chrome and Microsoft Edge.

Step 2: Scoping

• Establish installation and activity windows.
• Identify endpoints and user profiles where the extension ran.
• Use DNS/proxy logs to identify systems that contacted the known domains.
• Identify users who regularly accessed AI chatbot sites during the window.

Step 3: Remediation

• Review the types of data likely entered into AI chats by affected users.
• Rotate exposed secrets and credentials if there is any chance they were shared in chats.
• Consider invalidating sessions for privileged services accessed via the browser.
• Treat any sensitive internal descriptions of systems, processes, or incidents as potentially leaked.

Step 4: Prevention

• Implement extension allow listing or approval workflows.
• Audit extension permissions and publisher reputation as part of onboarding.
• Educate users that popularity and polish are not proof of safety.
• Steer users to genuine and sanctioned AI sites rather than installing extensions.
• Treat AI prompts and responses as sensitive data by default, with explicit rules for what may be pasted into external tools.

Implications & Likely Trajectory

This campaign reflects a broader shift: AI chat content has become a high value target. Collecting it via the browser is low cost, low friction, and scalable. It also bypasses traditional perimeter thinking, because the attacker does not need to compromise the AI provider or intercept transport. They only need to sit at the user’s interaction layer.

Given the speed at which AI tooling is being integrated into day-to-day work, similar campaigns are likely to continue. Defensive posture should assume that browser extension ecosystems will remain a common initial access and data collection vector, and that “prompt data” now deserves the same risk classification as credentials, emails, and internal documentation.

---

Browser-based threats are evolving, and AI conversations are now a prime target.

If you want support assessing your exposure and strengthening your detection and response around browser-delivered data theft, book a free discovery session with our team. We’ll help you understand where your organisation stands, identify gaps in visibility, and get ahead of emerging AI-driven attack vectors.