Paano isama ang pag-target sa user data at mga pondo sa pagpapadala sa isang script poisoning?

May-akda ng artikulo, pinagmulan: Slow Mist Technologies

Background

Kahit recent, ang mga seguridad ng Slow Mist ay nakasalubong sa isang pag-atake na may kaugnayan sa mga iskrip ng Udesk customer service system na nasusunog. Pagkatapos ay kinuha ng team ang dalawang JavaScript sample, ang udeskApi.2026-10-16.cached.js at deeps.js, at nag-analisa upang masuri kung paano pumasok ang masasamang code sa pamamagitan ng mga iskrip ng customer service at ano ang ginawa nito sa mga data ng user at mga operasyon ng negosyo.

Ang pag-ayos ng sample ay nagpapakita nang paulit-ulit ng dalawang uri ng panganib: ang masasamang script ay nag-aakay ng session data at sensitibong impormasyon mula sa webpage, habang binabago nito ang address ng deposito at kopya ang nilalaman ayon sa mga patakaran ng site. Ang unang uri ay maaaring magbigay-daan sa mga attacker na magmukhang may-ari ng session ng login o kumuha ng kontrol sa account, habang ang pangalawa ay maaaring magdulot ng pagpapadala ng deposito ng pera ng user sa isang palitan na address ng pagtatanggap. Mula sa entry point ng pag-load ng script ng customer service, sinusuri namin ang lohika ng pagbasa ng data, pagpapadala sa network, at pagbabago ng pahina upang mabawi ang paraan at kondisyon kung paano ginagawa ang dalawang uri ng gawain.

MistEye response

Ang MistEye ay isang sariling dinisenyong Web3 threat intelligence at dynamic security monitoring system ng SlowMist, na nagtatampok ng kakayahan sa security monitoring at情报聚合, na nagbibigay ng real-time risk alerts at asset protection sa mga user.

Sinama na agad ng MistEye ang panganib sa pamamagitan ng mga alerto sa impormasyon at mga channel ng babala sa kliyente.

Malicious loader at remote payload loading mechanism

Pagkatapos buksan ang udeskApi.2026-10-16.cached.js, makikita mo ang code para sa mga function tulad ng button ng customer service, chat iframe, pagsubaybay sa bisita, at pagpapadala ng mensahe. Magpatuloy sa pagsusuri sa dulo ng file; pagkatapos ng pangunahing bahagi, mayroon pa isang hiwalay na function: ito ay nagde-decode ng dalawang string gamit ang _ud(), gumagawa ng element, at nagpapasok nito sa head ng kasalukuyang dokumento.

Hindi direktang isinusulat ang pangalan ng tag at remote URL. Kung susubukan lamang ang plaintext domain, maaaring maikawala ang entry point. Sinusuri namin ang implementasyon ng _ud() at natuklasan namin na bawat beses ay kinukuha nito ang dalawang hexadecimal character, at binabago ito sa isang karakter; pagkatapos i-expand ang mga constant, malinaw na ang target ng pag-load.

Ang 736372697074 ay dekodew bilang script, habang ang isang iba pang const ay dekodew bilang https[:]//udeskqlobal[.]com/deeps.js. Ang domain ay nagsisimula sa titik q, at ang ganitong pagkakasulat ay dapat panatilihin sa paghahanap. Ang loader ay isinet ang script bilang asynchronous, at pagkatapos ay isinilid sa pahina; kapag natutugunan ang posisyon na ito at pinapayagan ng polisiya ng browser at network, maaaring makapasok ang remote code sa kasalukuyang dokumento.

Ang payload na kumakatawan sa URL ay ang deeps.js. Ang pag-aaral ay nagsilip mula sa customer service SDK patungo sa payload mismo. Ang mga karaniwang script mula sa third party ay tumutupad sa konteksto ng embedded dokumento, at ang mga data na ma-access nito ay nakasalalay sa tunay na pahina o iframe kung saan ito ay tumutupad. Ang window ng customer service chat ay gumagamit ng iframe at hindi awtomatikong isinasaayos ang mga script na load sa host page.

Mechanismo ng pagkuha ng data sa web at sakop ng epekto

Una munang basahin ng deeps.js ang window.location.hostname at lumikha ng konfigurasyon C batay sa tatlong patakaran ng site. Upang matukoy kung anong mga pahina ang kukunin, hindi sapat ang konfigurasyong ito: kailangan pang suriin kung ito ay naglalayong limitahan ang buong script o isang partikular na module, at kailangan pang tularan ang posisyon kung saan ginagawa ang pagtatapos.

Sa pag-check sa ibaba ng flow ng kontrol, nakikita natin na ang pagbasa ng Cookie at web storage, ang pagpapadala ng snapshot ng pag-start, at ang hooks para sa form at authentication request ay lahat ay nasa bago ang if (!C) return;. Sa ibaba, hinango ang mga pahayag ng pagpapadala ng snapshot at ang huling XHR hook ayon sa order ng source code; ang mga komento ay nagtutukoy sa mga pinagbawalan na code sa gitna, na tumutugma sa formatted view D:L100, D:L151–L166.

Nakasaklaw na malinaw ang lugar ng pagpapalabas: Kahit na hindi makahinga ang hostname sa mga patakaran ng tatlong site, ang script ay magsasaklaw muna sa path ng pagkuha ng data at iinstall ang hooks, bago lumabas sa module ng address. Kapag tinatawag ang mga inilabas na pahina, hindi dapat limitado sa paghahanap sa tatlong site na konfigurasyon lamang.

Kapag sinimulan, ang payload ay binabasa ang Cookie, localStorage, at sessionStorage na ma-access ng kasalukuyang pahina. Ang mga lokasyong ito ay maaaring magtago ng login status, profile, at business data; kung naglalaman ito ng mga login token na patuloy na epektibo at maaaring gamitin muli, maaaring gamitin ng mga hacker ang mga ito upang magmukhang user. Kasama rin ng script ang URL ng pangunahing pahina at ang origin ng kasalukuyang dokumento, upang isumite ang mga data kasama ng pinagmulang pahina.

Ang proseso ng pagkuha ay may error tolerance sa bawat hakbang. Kapag nabigo ang pagbasa ng top-level URL mula sa ibang pinagmulan, ginagamit ng script ang x bilang palitan at patuloy na pinoproseso ang iba pang mga field; ang dalawang uri ng webpage storage ay serialisado bilang JSON. Ang sakop ng cookie ay limitado sa nilalaman na mababasa ng document.cookie, at ang HttpOnly cookies ay hindi kasama.

Ang script ay nag-iingat din ng entry para sa mga data na susunod na isumite. Kapag isumite ng user ang form, ito ay naglalakbay sa bawat input, select, at textarea, kopya ang mga hindi walang laman, at patuloy ang orihinal na proseso ng pagsumite. Ang mga field na talagang isinulat ng user tulad ng username, password, at CAPTCHA ay maaaring makapasok sa karagdagang daanan ng pagpapadala ng data, at kung ma-leak, maaaring gamitin upang makapasok sa account o kunin ang kontrol nito.

Ipinapataas ng path na ito ang HTMLFormElement.prototype.submit at nakikinig sa submit event sa capture phase. Para sa mga pahina na nagpapadala ng data nang direkta sa pamamagitan ng interface, isinasaayos ng script ang fetch at XHR: kapag ang request ay may body at ang URL ay naglalaman ng mga keyword tulad ng login|signin|auth|register|signup|password, kopyahin at panatilihin ang orihinal na pagtawag sa request. Ang fetch branch ay nangangailangan din na ang URL ay isang string at ang body ay galing sa request options; kapag ang mga bagay tulad ng FormData ay diretso nang isinaserialisasyon sa JSON, maaaring kulang ang mga nakolekta na datos sa mga aktwal na field.

Mechanism ng Data Leakage at Backup Channel

Ang nakalista na entry point ay huling tumatawag sa parehong _send(). Habang sinusundan ang function na ito, makikita ang fixed receiver na https[:]//udeskqlobal[.]com/c.php. Ang snapshot ng pagpapalakas ay gumagamit ng mga field na s, o, c, l, ss upang magdala ng address ng pahina, kasalukuyang pinagmulan, readable na Cookie, at dalawang uri ng webpage storage; ang mga form at authentication request ay ipinapadala sa kanilang sariling pag-trigger.

Ang function ay naghihiwalay ng mga parameter pagkatapos ng tanong marka sa URL at isinasama sa body ng asynchronous POST, na nagtatag ng Content-Type: application/x-www-form-urlencoded. Panatilihin ang buong function ng pagpapadala (D:L45–L60):

Ang path ng pagpapadala ay naglalaman din ng fallback para sa request ng imahe: Kapag may error sa XHR o may synchronous anomaly sa proseso ng pagpapadala, lumilikha ang script ng Image object, at isinasaklaw ang URL na may mga parameter sa src upang subukan muli ang pagpapadala ng data gamit ang GET. Ang URL ay binabawasan sa unang 8,000 na JavaScript character, at ang mas mahabang nilalaman ay maaaring hindi kumpleto.

Kapag pinag-uusapan ang path na ito, kailangan mong magkakaiba ng “request sent” at “response read”. Hindi binabasa ng script ang response ng c.php; ang cross-origin POST na sumusunod sa mga kondisyon ng simple request ay maaaring ma-send muna, at pagkatapos ay limitahan ng browser ang pagbasa ng response, kaya ang CORS error ay maaaring mangyari nang sabay sa pagpapadala ng request. Dapat suriin ang log para sa POST body at ang GET parameters ng imahe, samantalang ang outbound policy ay dapat i-verify ang connect-src at img-src nang hiwalay. Ang karaniwang form na nagdudulot ng document navigation ay maaari ring makaapekto sa kakayahan ng asynchronous request na matapos.

Sa point na ito, malinaw na ang takbo ng data ng web session at ang mga sumusunod na sumbong. Ngunit mayroon pa ring isang pangkat ng mga aksyon na nananatili pagkatapos ng pagtukoy sa paglabas ng site: pagkilala sa format ng address, pagbabago ng teksto sa pahina, at pagkuha ng kontrol sa path ng pagkopya. Ang mga code na ito ay naglalayong magdala sa pag-aaral patungo sa serbisyo ng deposito.

Pagpapalit ng address para sa pag-deposito at mekanismo ng pag-aabuso sa clipboard

Pagkatapos ng if (!C) return;, pumasok ang script sa module ng address. Ang mga patakaran sa hostname na unang tatlo ay may malinaw na layunin: mag-match sa mgbx[.]com, bikingex[.] at bitxex[.]io, upang piliin ang mga selector ng elemento para sa address at button ng copy sa iba’t ibang pahina.

Hindi naglalaman ng mga anchor sa simula at dulo ang mga regular expression na ito, kaya mas malawak ang sakop nito kaysa sa eksaktong paghahambing ng domain name. Ang mga patakaran sa pahina ay sinusuri rin ang buong location.href, at ang mga keyword tulad ng deposit, recharge, at assets sa query parameters o fragments ay kikilos din sa pagpapasya. Pagkatapos makahinga ng pahina, elemento, o anyo ng address, ang script ay susuriin bawat 200 na milisegundo at papalitan ang mga natuklasang deposit address sa konfiguradong halaga. Kung gagamitin ng user ang napalitang address upang makumpleto ang isang epektibong paglipat, ang target na tatanggap ay magiging ang address na iyon.

Ang tatlong site branch ay nagbabahagi ng anim na configuration values, na markahan bilang BTC, EVM, TRON, Solana, LTC, at DOGE. Ang pagkilala sa address ay batay lamang sa anyo ng karakter at pagkakasunod-sunod ng pagkakatugma, hindi nag-verify ng network na pinili ng user o checksum ng address, at maaaring maliit ang pagkilala sa karaniwang business identifier.

Patuloy na i-check ang kopyahin ang kaugnay na code, makikita ang sample na nagpapakita ng parehong pag-intervenye sa pag-display ng pahina at sa nilalaman ng clipboard. Sa ganitong paraan, kahit pa ang user ay ihahambing ang address ng pahina at ang kopyahin na resulta, maaari pa ring makakuha ng magkakasunod na pinagbagoang halaga. Ang tatlong daanan ay:

Ipinapakete ang Clipboard API. Ang navigator.clipboard.writeText ay una ring tinatawag ang R() upang palitan ang parameter, at pagkatapos ay ipinapasa sa orihinal na paraan. Ang path na ito ay tanging pinipigilan ng hostname configuration, hindi na muli na sinusuri ang mga kondisyon ng pahina ng deposito, at hindi nakasalalay sa DOM scanning ng mga nakahawak na elemento.
Palitan ang button ng pagkopya. Ang script ay magkaklone ng naka-match na button, i-install ang bagong click listener, at palitan ang original na node. Ang bagong listener ay hahadlangan sa default action at event propagation, at subukang kopyahin ang address na naka-save sa shared variable _cur.
I-block ang copy event. Kapag ang _cur ay hindi walang laman at tumutugma ang pahina sa mga patakaran, ang listener sa document ay magpapalit ng nilalaman sa _cur, nang hindi isinusuri kung ang napiling teksto ng user ay isang address.

Kung saan, ang wrapper ng Clipboard API at ang copy listener ay nasa magkakapitang lugar sa source code (D:L260–L275), ngunit may iba’t ibang kondisyon para sa pag-trigger:

Ang _cur ay nag-iimbak ng huling aktwal na napalitan na address. Kapag may maraming address sa iisang screen, ang huling pagpalit ay aakalayin ang nakaraang rekord, at maaaring kopyahin ng maraming buton ang parehong halaga. Kung ang page ay may nakikita nang configuration address mula sa simula, hindi ito mag-i-init ng _cur, at ang mga bagong event listener ay hindi magdadagdag ng laman; ang mga cloned na inline event attributes ay maaari pa ring makilahok sa pagtratran ng event.

Sa pagsusuri, may isang implementasyon na may defect na nakakaapekto sa paghuhusga ng pag-uugali: sinubukan ng script na basahin ang自有属性描述符 ng textContent mula sa Element.prototype, ngunit ang standard na pagkakadefinisyon ay nasa Node.prototype. Sa standard na prototype relationship, ang pag-access sa .set ay magpapalabas ng exception. Pagkatapos ng pagkabigo sa branch na ito, ang catch ay magpapalabas ng exception; pagpapatuloy sa pagsusuri sa code bago at pagkatapos nito, nakikita na ang polling ay narehistro na, at ang mga copy hook ay magpapalabas ayon sa kanilang mga kondisyon. Ang isang branch na error ay hindi nagtatapos sa address hijacking module.

Summary

Pagkatapos suriin ang loader sa dulo ng script ng customer support, natukoy namin ang layunin ng pagsalakay: makakuha ng data na maaaring gamitin para magmukhang session o mag-login sa account, at palitan ang mga address ng pagtatanggap sa mga pahina ng deposito at sa mga operasyon ng pagkopya ayon sa konfigurasyon. Ang unang layunin ay hindi pinipigilan ng mga konfigurasyon ng tatlong site, habang ang pangalawa ay pinapagana ayon sa site at tiyak na path ng pagkopya, kaya kailangang sakop ang iba’t ibang eksposur na sitwasyon sa pagpapalawak.

Dapat itigil ng mga negosyo na patuloy na naglo-load ng mga kaugnay na script, palitan ang mga eksposed na credentials, at i-verify ang mga target ng deposito sa pamamagitan ng tiwalaan at mga tala ng transaksyon.

Mungkahi

I-save at ipigil ang pagpapalabas ng kontaminadong yaman. Kung ang produksyon ay patuloy na naglo-load ng mga kaugnay na script, i-block agad pagkatapos i-save ang tunay na tugon, ang chain ng paghingi, ang impormasyon sa cache, at ang oras ng pagkuha; muling i-recover mula sa tiyak na bersyon na napatunayan, at i-check ang konfigurasyon ng hosting ng site, CDN, build, at pamamahala ng tag.
I-retrieve ang load at exfiltration records. Gumamit ng joint query para sa mga mapanghamong domain, dalawang path, at file hash; ang exfiltration records ay tumitingin din sa POST body at GET parameters. Habang sinusuri ang compressed script, i-retrieve ang hexadecimal URL sa loader upang maiwasan ang pagkakalimot sa plaintext.
Tapusin ang nasirang dokumento at alisin ang ekspos na mga kredensyal. Buong pagsasarado ng kaugnay na pahina o WebView dokumento, iwasan ang pag-reload ng lumang mga yaman. Ayon sa tunay na sakop ng ekspos, i-revoke ang session, i-rotate ang mga token at password mula sa malinis na kaligiran; ang pag-alis ng script tag ay hindi magpapababa ng mga naka-install na hook at timer.
I-check nang hiwalay ang address ng deposito at ang transaksyon. Para sa mga pahina na nagpapatakbo ng payload, i-verify ang orihinal na address ng deposito, ang kaugnay na transaksyon, at ang tunay na layunin ng paglipat gamit ang mapagkakatiwalaang channel, at ayusin ang epekto batay sa tala ng transaksyon.
I-verify ang script at ang mga limitasyon sa paglabas ng data. Samantalang isasama ang mga setting ng negosyo, i-verify ang mga patakaran tulad ng connect-src at img-src para sa script loading at data exfiltration sa udeskqlobal[.]com.

IOC

Domain name

udeskqlobal[.]com

URL

https[:]//udeskqlobal[.]com/deeps[.]js

https[:]//udeskqlobal[.]com/c[.]php

Wallet address

BTC: bc1qhzppfj69ywp22swj50jwcfxdamg3ym245srng9

EVM: 0x9B6EcD0023a28E1391c5124eCe578A9751A337b2

TRON: TH4L5YAhhxtC8qALbZKbPZZgausbGi25nF

Solana: AFmCUe3nNbjTaC585CcdA3vvC9iWVR8YunooFKpaQx2Z

LTC: ltc1qwz0zp39ywl34kahvn9lyk7j5x63wsy9tcxhm3w

DOGE: DAoy2w8uvFtZ92q87s9qKEoHbWgV7mVThj

Malicious file

filename: udeskApi.2026-10-16.cached.js

SHA256: 45b4e8f160d8d5177819f6c1dc67acc7abbdc65eeaffc909e668799dc778bcf6

filename: deeps.js

SHA256: 57c1441c4f5bb3260981a2df64f9ff35f117abde0d8667c8c66a047880074c59

Tungkol sa MistEye

Ang MistEye ay isang sariling inimbento na Web3 threat intelligence at dynamic security monitoring platform ng SlowMist, na nag-aalok ng kakayahan sa pagdetekta ng masamang gawain at pagbabala sa panganib ng supply chain sa pamamagitan ng API para sa open-source package ecosystem.

Ang lahat ng masamang pakete at IOC na kasali sa aksyon na ito ay nai-integrate na sa MistEye Threat Detection Engine, kung saan ang mga developer ay maaaring gamitin ang API para sa automated na pagsusuri ng mga dependensya ng proyekto, upang mabilis na matukoy kung mayroon silang pagkakatugma sa mga kilalang masamang pakete at makakuha ng mga rekomendasyon para sa pagharap.