Chain Tech Catcher

What the timeline buried, caught once.

SlowMist traces data theft and deposit-address swaps to poisoned Udesk-related script

A poisoned JavaScript file associated with the Udesk customer-service system loaded a remote payload designed to collect browser-accessible data and replace cryptocurrency deposit addresses, according to SlowMist’s analysis published on October 27, 2026, at 17:51 UTC+8.

The researchers examined two files: udeskApi.2026-10-16.cached.js and deeps.js. Their findings distinguish two exposure paths: data collection that ran before site-specific restrictions, and address manipulation activated by particular hostname and page rules.

The report describes malicious code and its execution conditions, but does not establish the number of affected users, confirmed financial losses or how the original script became contaminated.

How the payload entered the page

The customer-service file contained ordinary functionality for chat buttons, an iframe, visitor tracking and messaging. After that main code, SlowMist found a separate loader that decoded hexadecimal strings, created a script element, set its source to https[:]//udeskqlobal[.]com/deeps.js, and appended the asynchronous script to the document’s head.

The spelling matters: qlobal begins with a q, not a g. Searching only for plaintext domains could also miss the loader because its URL was encoded.

If execution reached that code and browser policies and network access permitted it, the remote payload could run in the current document. A customer-service chat iframe would not automatically isolate a separate script loaded into the host page: the script’s access depended on the document or iframe in which it actually executed.

Data collection extended beyond the three hostname rules

At startup, deeps.js read the current hostname and selected a configuration using three site rules. However, SlowMist found that the script collected data and installed submission hooks before reaching if (!C) return;.

That ordering is central to the exposure assessment. A page did not need to match one of the three hostname rules to enter the data-collection path. The later check restricted the address-manipulation module, not the preceding collection logic.

The startup snapshot included:

  • Cookies accessible through document.cookie.
  • localStorage and sessionStorage, serialized as JSON.
  • The top-level page URL and the current document’s origin.

HttpOnly cookies were outside the script’s direct cookie access. When a cross-origin restriction prevented reading the top-level URL, the script substituted x and continued collecting other fields.

If the accessible data contained valid, reusable authentication tokens, their theft could enable session impersonation. That is a potential consequence, not evidence that every exposed session was taken over.

The payload also captured later submissions. It wrapped HTMLFormElement.prototype.submit and installed a capturing submit event listener to copy nonempty values from input, select and textarea elements while allowing the original submission to proceed. Depending on the page, those fields could include usernames, passwords or verification codes.

For API-based submissions, it wrapped fetch and XMLHttpRequest. Requests with a body and a URL matching login|signin|auth|register|signup|password could trigger additional collection. The fetch branch required a string URL and took the body from request options; directly JSON-serializing objects such as FormData could omit their actual fields.

Exfiltration used POST with an image-request fallback

The collection paths sent data to https[:]//udeskqlobal[.]com/c.php.

The sending function moved URL query parameters into an asynchronous POST body with the content type application/x-www-form-urlencoded. If the XMLHttpRequest encountered an error, or a synchronous exception occurred during sending, it created an Image object and assigned the parameter-bearing URL to its src, attempting a GET-based fallback.

That fallback truncated the URL to the first 8,000 JavaScript characters, so longer data could be incomplete.

SlowMist emphasized the distinction between sending a request and reading its response. A cross-origin POST that meets simple-request conditions can be sent even when the browser subsequently prevents response access. A CORS error alone therefore does not establish that data stayed in the browser.

Investigators should examine both POST bodies and image GET parameters. The report also distinguishes connect-src controls from img-src controls, and notes that a form-triggered navigation can affect whether asynchronous requests finish.

Deposit-address replacement and clipboard interception

After the configuration check, the payload’s address module used hostname patterns for mgbx[.]com, bikingex[.] and bitxex[.]io to choose page-element and copy-button selectors.

These regular expressions lacked start and end anchors, making their matches broader than exact hostname comparisons. Page checks also examined the entire URL, allowing keywords such as deposit, recharge and assets in query strings or fragments to participate in matching.

When the page, element and address-format conditions matched, the script scanned every 200 milliseconds and replaced recognized deposit addresses with configured values. A valid transfer using a substituted address would send funds to that destination.

The three site branches shared six configured addresses, labeled BTC, EVM, TRON, Solana, LTC and DOGE. Recognition relied on character patterns and matching order—not the user’s selected network or address checksums—and could misidentify ordinary business identifiers.

The payload also interfered with copying in three ways:

  1. Clipboard API wrapping: It passed text through a replacement function before calling the original navigator.clipboard.writeText. This path required a hostname configuration but did not repeat the deposit-page check or depend on a successful DOM replacement.
  2. Copy-button replacement: It cloned matching buttons, attached new click handlers and replaced the original nodes. The handlers attempted to copy the address held in the shared _cur variable.
  3. Copy-event interception: When _cur was nonempty and the page rule matched, a document-level listener replaced copied text with _cur, without checking whether the selected text was an address.

Because both displayed text and clipboard content could be altered, comparing them could produce two matching but tampered values.

The shared variable retained the last address actually replaced. Multiple displayed addresses could therefore result in several buttons copying the same value. If a page already displayed a configured address, the scan would not initialize _cur from that match; the new button handler would then write nothing, although cloned inline HTML event attributes could still participate in handling the event.

SlowMist also identified a failed attempt to hook textContent: the code looked for its own property descriptor on Element.prototype, while the standard property is defined on Node.prototype. Accessing .set would then throw under the standard prototype relationship. The exception was swallowed, but polling had already been registered and later clipboard hooks could still be installed. This defect did not disable the entire address-hijacking module.

Response priorities

SlowMist recommended preserving actual script responses, request initiator chains, cache information and collection timestamps before blocking contaminated resources. Restoration should use independently verified trusted versions, with checks of hosting, CDN, build and tag-management configurations.

Searches should cover the malicious domain, both payload paths, file hashes and the loader’s hexadecimal URL—not just plaintext indicators.

Affected pages or WebView documents should be fully closed. Removing a script element does not undo hooks and timers already installed. Based on actual exposure, sessions should be revoked and tokens or passwords rotated from a clean environment.

Deposit destinations and completed transfers should be checked through trusted channels and transaction records, rather than through the potentially altered page. Script-source and integrity controls, together with separate connect-src and img-src restrictions, should also be verified.

Indicators from the analyzed samples

Domain and paths, defanged:

  • udeskqlobal[.]com
  • https[:]//udeskqlobal[.]com/deeps[.]js
  • https[:]//udeskqlobal[.]com/c[.]php

Configured wallet addresses:

  • BTC: bc1qhzppfj69ywp22swj50jwcfxdamg3ym245srng9
  • EVM: 0x9B6EcD0023a28E1391c5124eCe578A9751A337b2
  • TRON: TH4L5YAhhxtC8qALbZKbPZZgausbGi25nF
  • Solana: AFmCUe3nNbjTaC585CcdA3vvC9iWVR8YunooFKpaQx2Z
  • LTC: ltc1qwz0zp39ywl34kahvn9lyk7j5x63wsy9tcxhm3w
  • DOGE: DAoy2w8uvFtZ92q87s9qKEoHbWgV7mVThj

File SHA-256 hashes:

  • udeskApi.2026-10-16.cached.js: 45b4e8f160d8d5177819f6c1dc67acc7abbdc65eeaffc909e668799dc778bcf6
  • deeps.js: 57c1441c4f5bb3260981a2df64f9ff35f117abde0d8667c8c66a047880074c59

Source: SlowMist’s original analysis, published October 27, 2026, at 17:51 UTC+8.