Malicious Chrome Extension "MEXC API Automator" Steals MEXC API Keys and Silently Enables Withdrawals for Account Takeover

Opening: Chrome extension turns API key creation into account takeover

A malicious Chrome extension marketed as a convenience tool for automated trading is turning a routine "create API key" workflow into an account takeover mechanism for MEXC users. The extension, "MEXC API Automator," does not need to steal passwords or defeat multi-factor authentication. Instead, it waits for the victim to open MEXC's API management page while already logged in, then creates new API credentials with withdrawal permissions, disguises those permissions in the user interface, and exfiltrates the keys to an attacker-controlled Telegram bot. This is a high-impact pattern for crypto platforms because API keys are long-lived and often less visible to users than interactive logins, meaning the compromise can outlast the browser session, and in many cases, outlast the extension itself.

What happened: a "trading helper" extension became an API key stealer

The core incident is straightforward but strategically dangerous: a Chrome Web Store extension advertised as a bot-automation helper was found to be purpose-built malware. Its pitch is believable to the intended audience because many traders legitimately use bots and API keys, and many exchanges encourage API-based automation for advanced workflows. The extension's public description reinforces that expectation by claiming it will generate API keys with permissions "including access to trading and withdrawals," framing itself as a productivity shortcut rather than a security risk.

Where this crosses into severe compromise is the combination of automation and deception. The extension does not simply request permissions and then operate transparently. Researchers describe behavior where the extension ensures withdrawal permissions are enabled server-side while presenting the opposite state to the user in the on-page interface. That is the key differentiator from "generic phishing." It is not trying to trick you into typing credentials. It is hijacking a privileged workflow inside a trusted session, generating durable API access, and then hiding the most security-relevant configuration choice.

The operational consequence is that a victim can believe they created a limited-scope key for a trading bot while actually issuing a high-privilege credential that can be used to trade and withdraw funds programmatically. In crypto, that is not just an account takeover risk. It is an immediate financial loss risk, because once withdrawals are possible through API, the attacker can monetize directly without having to maintain interactive access.

Technical breakdown: how browser session hijacking bypasses password and MFA defenses

What makes this campaign effective is that it exploits the exact moment when the user has already done everything "right." The victim logs into the exchange normally, completes any additional verification the platform requires, and navigates to the API management interface. At that point, the browser session is already authenticated and authorized to create API keys. A malicious extension operating as a content script can then execute within that trusted context, interact with the page, and trigger actions that the user could perform manually.

Researchers report that the extension targets MEXC's API management path and injects a script when the victim visits it. The script then drives the workflow end to end: initiating API key creation, selecting permissions, and ensuring withdrawal capability is enabled. The critical part is not only that it enables the permission. It also manipulates how the permission is displayed so that the user sees a safer configuration than what is actually submitted to the server. That design acknowledges a realistic user behavior: many users will glance at the checkbox state and assume it reflects what the backend will enforce.

Once the key creation flow completes and MEXC displays the resulting access key and secret, the extension extracts those values from the page and sends them to the attacker through Telegram. At that point, the attacker no longer needs your browser, your password, or your MFA. They have a reusable credential that can be loaded into tooling to place trades, move funds, and potentially maintain access until the key is revoked. This is precisely why API key governance is often more important than password hygiene in environments where APIs can authorize withdrawals.

Why API keys are the real prize: durable access that often survives "cleanup"

In many consumer security incidents, the playbook is clear: change your password, enable MFA, and you will likely evict the attacker. API key compromises break that mental model. An exchange API key can be valid for an extended period, and it can be used from attacker infrastructure without triggering the same "new device login" friction that interactive sessions face. Even when an exchange flags suspicious logins, API calls can appear as normal automation traffic unless there is strong anomaly detection on trading and withdrawal behavior.

This durability is amplified by user psychology and operational habits. Traders often create multiple keys, rotate bots, test strategies, and leave older keys active "just in case." The more keys exist, the harder it is for a user to notice one that was created without their intent or created with broader permissions than intended. Attackers understand that messiness and build tooling that benefits from it. A stolen withdrawal-enabled key is effectively a standing authorization to attempt monetization repeatedly, rather than a single opportunistic theft.

It also changes the post-incident response priority. Uninstalling the extension, cleaning the browser, and even changing the account password are insufficient if the attacker already holds a valid key. The only reliable containment step is to review and revoke API keys, then treat the environment as compromised until you have high confidence no additional keys, sessions, or recovery pathways were altered. In other words, the security boundary shifts from "who can log in" to "who has persistent authorization."

Threat actor profile and distribution: Chrome Web Store as a delivery pipeline

The extension was distributed through the Chrome Web Store, which remains one of the most effective "trust amplifiers" for attackers because it reduces friction and raises perceived legitimacy. For many users, "it is in the store" still implies basic vetting, even though security history shows that malicious extensions can slip through and remain accessible long enough to do damage. In this case, reporting and research indicate the extension was published in September 2025, presented as a developer tool, and had a small but meaningful user base at the time it was analyzed. In targeted fraud, low download numbers do not reduce risk, because the victims are pre-selected by behavior: people who create API keys and can move funds.

The developer identity presented in the listing uses the handle "jorjortan142," and researchers observed signals that suggest this is not a one-off prank. The extension's behavior is narrowly optimized around monetization: hijack a privileged workflow, capture the keys at creation time, and exfiltrate them to a channel the operator controls. Reporting also points to the same handle appearing across social platforms and Telegram-branded crypto tooling, which is consistent with a financially motivated operator building an ecosystem, not merely experimenting.

From a defender's perspective, the important conclusion is not attribution. It is repeatability. The same technique can be adapted to other exchanges, broker portals, admin dashboards, and SaaS consoles that issue tokens or keys inside an authenticated web session. If a service uses a web UI to create high-privilege credentials, then a browser extension can be a direct path to credential theft without ever touching passwords.

How organizations and users should respond: containment steps that actually stop the bleed

If you suspect you installed "MEXC API Automator," treat the situation as an active financial compromise scenario, not a "maybe." The fastest risk reduction comes from removing persistence and invalidating stolen credentials. Start by removing the extension, but do not stop there. Immediately review all API keys in your MEXC account, revoke any unknown or recently created keys, and strongly consider revoking all keys and re-issuing only what you truly need. If you use bots, pause them until you have re-established clean keys and validated permissions.

Next, validate the scope of what an attacker could have done with the stolen keys. Review recent account activity with an eye for automation-style abuse: unusual trades, unexpected asset conversions, new withdrawal addresses, or withdrawal attempts that align with "bot-like" timing. If your exchange or workflow supports permission granularity, re-issue keys with the minimum privileges required. If you only need market data or trading, do not enable withdrawals. Where platforms support it, add additional constraints such as IP or key restrictions, and ensure any "withdraw" permission requires explicit, deliberate action.

Finally, treat the affected browser profile as untrusted. Extension-based malware operates inside the browser's trust boundary, so remediation should include auditing other installed extensions, disabling unnecessary add-ons, and using a dedicated browser profile (or dedicated device) for exchange access. For businesses and professional trading teams, the hardening step is to move away from "personal browser sprawl" and toward managed browser policies with extension allowlists. If you cannot control which extensions run, you cannot reliably protect web-based credential workflows that issue long-lived secrets.

Prevention and detection: what this incident teaches about extension governance

The broader security lesson is that "API key hygiene" and "browser extension hygiene" now belong in the same risk category for financial operations. Many security programs focus heavily on endpoint malware and email phishing, while treating browser extensions as a user convenience layer. That assumption is outdated. A malicious extension can act like an in-session operator, triggering actions the user is authorized to perform and extracting secrets at the exact moment they are displayed.

Detection also needs to evolve. Traditional endpoint telemetry often centers on process creation, file writes, and outbound connections from executables. In this case, the behavior can be largely contained within the browser sandbox, with outbound network calls that look like normal HTTPS. That makes policy, governance, and least privilege critical. If your environment allows arbitrary extensions, a determined attacker will eventually find a workflow that yields secrets.

For platforms, the implication is equally clear. Any UI that reveals high-value secrets, such as API access keys and secret keys, should assume a hostile browser environment. Technical mitigations can include limiting how long secrets are displayed, requiring step-up verification for withdrawal-enabled keys, emphasizing permission clarity in UI, and monitoring for unusual key creation patterns. If a service can detect mass key creation, suspicious permission combinations, or abnormal post-key withdrawal behavior, it can reduce the attacker's window even when the client is compromised.

Closing

The "MEXC API Automator" case is a clean demonstration of where modern financial compromise is heading: attackers increasingly target the workflows that mint durable authorization rather than the credentials that initiate a session. By operating inside an authenticated browser context, a malicious extension can bypass the psychological and technical defenses users depend on, including MFA, and convert a legitimate automation feature into a withdrawal-capable backdoor. The defensive response is equally clear. Treat API keys as privileged assets, treat browser extensions as part of your threat surface, and design both user habits and organizational policy around the assumption that the browser can be hostile. If you can reduce who is allowed to install extensions, reduce who is allowed to mint high-privilege keys, and reduce how long those keys remain valid, you reduce the attacker's business model.