Polymarket Supply Chain Attack: $2M+ Stolen via Hijacked Sessions — Detection and Response Guide for Defenders

More than $2 million was siphoned from Polymarket traders after attackers injected malicious code linked to a website monitoring tool — code that was purpose-built to hijack already authenticated user sessions and drain funds directly from victims' accounts. This is not a phishing campaign and it is not a credential-stuffing event. It is a client-side supply chain compromise: a trusted third-party script, loaded in the context of a legitimate site, turned hostile and abused the session material sitting in users' browsers.

For defenders, this incident matters well beyond the prediction-market niche. Any organization whose web properties embed third-party JavaScript — analytics, tag managers, session replay, uptime monitoring, chat widgets, A/B testing — is one compromised vendor away from the same outcome. If your users hold financial balances, crypto assets, or privileged sessions in the browser, your third-party script inventory is your attack surface. This post breaks down how the attack worked, what you can actually observe on the endpoint and network, and the concrete hardening steps that reduce the blast radius of the next one.

Technical Analysis

What happened

Per the SecurityWeek reporting, malicious code associated with a website monitoring tool was delivered to users visiting Polymarket while logged in. Rather than stealing passwords, the injected code targeted the live session: it operated inside the authenticated browser context, which means it inherited every permission the user's session already had — including the ability to initiate transactions and move funds. Over $2 million was drained from affected traders before the activity was identified and disrupted.

No CVE has been assigned to this incident as of publication, and none should be expected — this is a supply chain integrity failure and a malicious-code injection, not a patchable memory corruption bug. The vulnerability class is trust: arbitrary JavaScript from a third-party vendor executed with first-party privileges in the victim's DOM.

Attack chain (defender's view)

1. Initial vector — third-party script compromise. The monitoring vendor's hosted JavaScript (or its delivery pipeline) was modified to serve malicious payloads. Because the script is referenced by URL, the attacker gains the ability to change behavior for every downstream consumer simultaneously, with zero interaction with the victim organization.
2. Execution in authenticated context. When a logged-in user loaded the affected page, the injected code executed with full access to the DOM, localStorage, non-HttpOnly cookies, and — critically — the ability to issue same-origin requests carrying the user's session cookies. HttpOnly mitigates direct cookie exfiltration via document.cookie, but it does nothing to stop the script from simply making authenticated API calls inline.
3. Session hijack and fund movement. For a platform like Polymarket, where trading and withdrawal actions are driven by API calls from the browser, a script running in the session context can enumerate balances and submit transactions as the user. On-chain transfers are irreversible — which is why the losses here are absolute, not chargebacks.
4. Conditional delivery. Supply chain scripts of this type are typically gated — checking geolocation, wallet balance, or session state — to limit exposure and delay detection. Expect the malicious payload to have been served selectively, which complicates reproduction and vendor-side forensics.

Exploitation status

• Confirmed active exploitation in the wild with quantified financial impact ($2M+).
• Not applicable to CISA KEV (no CVE, not a software vulnerability in the traditional sense).
• Technique maps to MITRE ATT&CK T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain), T1185 (Browser Session Hijacking), and T1059.007 (JavaScript execution).

Why traditional controls missed it

• The script was served over TLS from a vendor domain that was already on allowlists.
• No malware touched disk in the initial phase — the payload lived in the browser process and memory.
• Network egress to attacker infrastructure can ride legitimate-looking HTTPS beacons indistinguishable from analytics telemetry.
• Session-based attacks generate valid application logs — the transactions were authorized by a real session, which defeats server-side anomaly controls keyed on authentication anomalies.

Detection & Response

Detection for a client-side supply chain attack is hard, but not hopeless. The observable artifacts concentrate in four places: (1) non-browser processes touching browser credential/session stores on endpoints where commodity follow-on tooling lands, (2) browser processes exhibiting injection-adjacent behaviors, (3) egress from workstations to vendor script domains that changed recently or serve rarely-seen payloads, and (4) application-side transaction anomalies. The detections below are tuned to be useful, not noisy — deploy them in audit mode first and baseline against your environment.

SIGMA Rules

---
title: Non-Browser Process Accessing Browser Cookie or Session Databases
id: 3f8a2c71-9b4e-4d5a-a6c2-7e1f0d9b3a44
status: experimental
description: Detects non-browser processes reading browser cookie/session databases, consistent with session token theft tooling that commonly follows client-side compromise of financial-platform users.
references:
  - https://attack.mitre.org/techniques/T1539/
  - https://attack.mitre.org/techniques/T1185/
author: Security Arsenal
date: 2026/04/10
tags:
  - attack.credential_access
  - attack.t1539
  - attack.t1185
logsource:
  category: file_event
  product: windows
detection:
  selection_paths:
    TargetFilename|contains:
      - '\Google\Chrome\User Data\'
      - '\Microsoft\Edge\User Data\'
      - '\BraveSoftware\Brave-Browser\User Data\'
  selection_files:
    TargetFilename|endswith:
      - '\Network\Cookies'
      - '\Cookies'
      - '\Login Data'
      - '\Web Data'
  filter_browsers:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\brave.exe'
      - '\firefox.exe'
  condition: selection_paths and selection_files and not filter_browsers
falsepositives:
  - EDR and DLP agents scanning browser profiles (tune by Image hash, not path)
  - Backup/endpoint management software
level: high
---
title: Script Interpreter Reading Browser Session Stores via Command Line
id: 6c1d9e02-4f7b-4a38-b8e5-2a9c0f6d1e77
status: experimental
description: Detects PowerShell or command shell invocation referencing browser cookie, Local Storage, or session paths — behavior associated with in-browser session hijack follow-on activity and cookie theft staging.
references:
  - https://attack.mitre.org/techniques/T1539/
  - https://attack.mitre.org/techniques/T1059.001/
author: Security Arsenal
date: 2026/04/10
tags:
  - attack.credential_access
  - attack.t1539
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
  selection_cli:
    CommandLine|contains:
      - '\Network\Cookies'
      - 'Local Storage\leveldb'
      - 'User Data\Default\Sessions'
      - 'login-data-v2'
      - 'dpapi'
  condition: selection_img and selection_cli
falsepositives:
  - Legitimate DFIR collection scripts — scope by execution context and parent process
level: high
---
title: Outbound Connection to Polymarket Typosquat or Lookalike Domain
id: 9e4b7a13-2c6d-4e19-a3f8-5b7d2c9e0a31
status: experimental
description: Detects proxy/DNS connections to domains containing the polymarket string that are not the legitimate polymarket.com domain, a common post-compromise lure and exfiltration pattern targeting session-hijacked crypto users.
references:
  - https://attack.mitre.org/techniques/T1071.001/
  - https://attack.mitre.org/techniques/T1566/
author: Security Arsenal
date: 2026/04/10
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: proxy
detection:
  selection:
    c-uri|contains: 'polymarket'
  filter_legit:
    c-uri|contains:
      - 'polymarket.com'
  condition: selection and not filter_legit
falsepositives:
  - Legitimate subdomains or CDN aliases — maintain an explicit allowlist of verified Polymarket infrastructure
level: medium

A note on tuning: the cookie-database rule is the highest-fidelity of the three. In mature environments, non-browser processes reading Network\Cookies are almost exclusively EDR agents or malware — baseline your security tooling by file hash and deploy. The typosquat rule catches the lure and exfil phase; it will not catch the inline session abuse itself, which happens same-origin.

KQL — Microsoft Sentinel / Defender

The following hunt joins endpoint file access telemetry against browser session stores with process lineage, then pivots to network egress for workstations that accessed crypto-platform domains in the same window. Run it over a 7–14 day lookback if you suspect exposure during the campaign window.

// Hunt: Non-browser processes accessing browser cookie/session stores on endpoints
// that also browsed to crypto/prediction-market domains — session theft triage pivot
let Lookback = 7d;
let BrowserProcs = dynamic(["chrome.exe","msedge.exe","brave.exe","firefox.exe","opera.exe"]);
let SuspiciousCookieAccess =
    DeviceFileEvents
    | where TimeGenerated > ago(Lookback)
    | where FolderPath has_any ("\\Network\\Cookies", "\\Local Storage\\leveldb")
       or FileName in~ ("Cookies","Login Data","Web Data")
    | where InitiatingProcessFileName !in~ BrowserProcs
    | where InitiatingProcessFileName !in~ ("MsMpEng.exe","MsSense.exe","SenseIR.exe") // baseline your own EDR/AV
    | project CookieAccessTime=TimeGenerated, DeviceName, DeviceId,
              AccessingProcess=InitiatingProcessFileName,
              AccessingCmd=InitiatingProcessCommandLine,
              AccessingSHA256=InitiatingProcessSHA256,
              TargetFile=FolderPath, AccountName;
SuspiciousCookieAccess
| join kind=leftouter (
    DeviceNetworkEvents
    | where TimeGenerated > ago(Lookback)
    | where RemoteUrl has_any ("polymarket","kalshi","predictit")
       or RemoteUrl has "polymarket" and RemoteUrl !has "polymarket.com"
    | project BrowseTime=TimeGenerated, DeviceId, RemoteUrl, RemoteIP, InitiatingProcessFileName
) on DeviceId
| project CookieAccessTime, DeviceName, AccountName, AccessingProcess, AccessingCmd,
          TargetFile, BrowseTime, RemoteUrl, RemoteIP
| order by CookieAccessTime desc

Velociraptor VQL — Endpoint Hunt

This artifact enumerates installed browser extensions across all Chrome/Edge profiles on an endpoint and flags anything that is sideloaded (installed outside the official web store, indicated by a missing update_url) — the most common persistence mechanism for browser-based session hijackers and a worthwhile check after any third-party script incident affecting your users.

-- Hunt: Enumerate Chromium extensions and flag sideloaded (non-webstore) installs
-- Scope: all user profiles on endpoint; review flagged manifests for excessive permissions
LET manifests = SELECT FullPath, Data
FROM parse_jsonl(
  accessor='file',
  filenames=glob(glob='C:/Users/*/AppData/Local/*/User Data/*/Extensions/*/*/manifest.json'),
  accessor='file'
)

SELECT FullPath,
       Data.name AS ExtensionName,
       Data.version AS Version,
       Data.permissions AS Permissions,
       Data.update_url AS UpdateURL,
       if(condition=Data.update_url, then='WebStore', else='SIDELOADED - REVIEW') AS InstallSource,
       parse_file_with_accessor(filename=FullPath, accessor='file').Mtime AS ManifestModified
FROM manifests
WHERE InstallSource =~ 'SIDELOADED'
   OR Permissions =~ 'cookies|webRequest|tabs|<all_urls>'

Extensions with cookies, webRequest, or <all_urls> permissions have everything needed to replicate this attack from inside the browser — treat this hunt as a standing quarterly control, not a one-time IR action.

Response Script — Session Invalidation and Extension Audit

The highest-value immediate actions after suspected session hijack are: kill the session server-side, wipe local session material client-side, and audit for persistence. This PowerShell performs the client-side portion — enumerate extensions, snapshot browser state, and force-clear session data — for a triage sweep across affected users. Pair it with a server-side global session revocation (see Remediation).

# Polymarket supply chain incident — client-side triage and session purge
# Run per affected user workstation. Requires closing browsers before cookie wipe.
$ReportPath = "C:\IR\SessionHijack-Triage-$(Get-Date -Format 'yyyyMMdd-HHmmss')"
New-Item -ItemType Directory -Path $ReportPath -Force | Out-Null

# 1. Enumerate all Chromium extensions across all user profiles; flag sideloaded
$profiles = Get-ChildItem 'C:\Users\*\AppData\Local' -Directory -ErrorAction SilentlyContinue |
  Where-Object { $_.Name -match 'Google|Microsoft' }
$extensionData = foreach ($p in Get-ChildItem 'C:\Users\*\AppData\Local\*\User Data\*\Extensions\*\*\manifest.json' -ErrorAction SilentlyContinue) {
  try {
    $m = Get-Content $p.FullName -Raw | ConvertFrom-Json
    [PSCustomObject]@{
      User        = ($p.FullName -split '\\')[2]
      ExtensionID = ($p.FullName -split '\\')[-3]
      Name        = $m.name
      Version     = $m.version
      Sideloaded  = -not [bool]$m.update_url
      Permissions = ($m.permissions -join ';')
      Manifest    = $p.FullName
      Modified    = $p.LastWriteTime
    }
  } catch {}
}
$extensionData | Export-Csv "$ReportPath\extensions.csv" -NoTypeInformation
$extensionData | Where-Object Sideloaded | Format-Table -AutoSize

# 2. Snapshot running browser processes and their command lines (command-line
#    flags like --remote-debugging-port are a common session-abuse enabler)
Get-CimInstance Win32_Process -Filter "Name='chrome.exe' OR Name='msedge.exe'" |
  Select-Object ProcessId, Name, CommandLine |
  Export-Csv "$ReportPath\browser-procs.csv" -NoTypeInformation
Get-CimInstance Win32_Process -Filter "Name='chrome.exe' OR Name='msedge.exe'" |
  Where-Object { $_.CommandLine -match 'remote-debugging|load-extension|disable-web-security' } |
  Format-Table ProcessId, CommandLine -AutoSize

# 3. Stop browsers, then clear session cookies and site data for affected domain
#    (server-side session revocation must ALSO occur — local wipe alone is insufficient)
Get-Process chrome, msedge, brave -ErrorAction SilentlyContinue | Stop-Process -Force
$cookieStores = Get-ChildItem 'C:\Users\*\AppData\Local\*\User Data\*\Network\Cookies*' -ErrorAction SilentlyContinue
foreach ($db in $cookieStores) {
  Copy-Item $db.FullName "$ReportPath\$($db.Name).bak" -Force   # preserve for DFIR before wipe
  Remove-Item $db.FullName -Force
}
Write-Host "[+] Extension audit and session purge complete. Artifacts: $ReportPath"
Write-Host "[!] Coordinate server-side global session/token revocation before users re-authenticate."

Critical sequencing note: server-side session invalidation must happen before or simultaneously with client cleanup. If the attacker's injected code still holds a live session, wiping local cookies while the session remains valid server-side just delays re-infection until the user logs back in.

Remediation

For end users who traded on Polymarket during the exposure window

1. Assume session compromise. Log out of all sessions from Polymarket's account controls, then re-authenticate. If the platform exposes a "sign out all devices" function, use it — this invalidates server-side session tokens, which is the only action that actually severs a hijacked session.
2. Move remaining funds. Withdraw balances to an external wallet or exchange account you control before re-engaging with the platform. On-chain theft is irreversible; speed matters more than forensics for affected users.
3. Rotate associated credentials. Change the email account password used for Polymarket login (magic-link email auth means your email is your credential), and revoke any active sessions on that mailbox. Enable hardware-key or TOTP MFA on the email account.
4. Audit browser extensions. Remove anything you don't recognize; anything sideloaded; anything requesting broad cookies/tabs/<all_urls> permissions that doesn't strictly need them. Browser-based stealers piggyback on incidents like this.
5. Clear cookies and site data for the affected domain and any related third-party domains, then re-login fresh.

For security teams protecting users of financial/crypto web platforms

1. Inventory third-party JavaScript — now. Every externally-hosted script on your transactional properties is a supply chain dependency. Build the inventory from CSP reports or a crawler, assign an owner to each vendor, and establish an offboarding path for any script that fails review.
2. Enforce Subresource Integrity (SRI) everywhere it is supported. SRI pins the cryptographic hash of an external script; if the vendor's hosted file changes — as it did here — the browser refuses to execute it. Where SRI isn't possible (vendor scripts that rotate frequently), push vendors for versioned, immutable URLs or self-host a reviewed copy.
3. Deploy a strict Content Security Policy. At minimum: script-src limited to an explicit vendor allowlist (no wildcards), connect-src restricted to your own API and payment endpoints (this alone can break inline exfiltration), and report-uri/report-to enabled so violations generate telemetry your SOC can alert on. CSP reporting turns client-side injection attempts into detectable events.
4. Shorten session lifetimes and bind sessions to device posture for high-value actions. Step-up verification (passkey re-auth or signing confirmation) at the withdrawal/transfer boundary — not just login — blunts session hijack even when the browser is fully compromised.
5. Transaction-side anomaly detection. The attacker's API calls were authenticated and technically valid — the detection opportunity is behavioral: new withdrawal destinations, first-time wallet addresses, transfer velocity, and session-IP/user-agent continuity breaks. These belong in your fraud pipeline, not just your SIEM.
6. Vendor risk review for script suppliers. Website monitoring, analytics, and tag vendors should be in your third-party risk program with the same rigor as network-connected SaaS: incident notification SLAs, integrity controls on their build/deploy pipeline, and contractual SRI/immutable-URL support.

For the IR team

• Preserve browser profiles (cookies SQLite DBs, Local Storage\leveldb, extension directories) before any cleanup — the response script above backs these up for this reason.
• Pull proxy/DNS logs for the monitoring vendor's domains for the full exposure window and diff response sizes/hashes where archived — payload gating means not every request received the malicious code.
• Coordinate with the vendor for their build/deploy pipeline timeline; supply chain attribution lives in their CI/CD logs, not yours.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub