Bagaimana serangan skrip toksik boleh menargetkan data pengguna dan dana penghantaran secara serentak?

Penulis artikel, sumber: Slow Mist Tech

Latar belakang

Baru-baru ini, ahli keselamatan SlowMist semasa penggalian maklumat ancaman harian mereka memantau satu aktiviti serangan yang melibatkan skrip yang berkaitan dengan sistem pelanggan Udesk yang telah diracuni. Pasukan kemudian memperoleh dua sampel JavaScript, udeskApi.2026-10-16.cached.js dan deeps.js, dan melakukan analisis untuk mengikuti bagaimana kod jahat memanfaatkan skrip pelanggan untuk memasuki laman web, serta apa yang dilakukannya terhadap data pengguna dan operasi perniagaan.

Pemeriksaan terhadap sampel secara bertahap mengungkap dua jenis risiko: skrip jahat yang mengumpulkan data sesi dan informasi sensitif yang diserahkan pengguna dari halaman web, sambil memodifikasi alamat setoran dan menyalin konten mengikut peraturan laman web. Yang pertama mungkin membolehkan penyerang menyamar sebagai sesi log masuk atau mengambil alih akaun, manakala yang kedua mungkin menyebabkan pengguna menghantar dana setoran ke alamat penerima yang telah ditukar. Kami memulakan dari titik masuk pemuatan skrip sokongan, mengikuti logik bacaan data, penghantaran rangkaian, dan modifikasi halaman, untuk memulihkan cara dan syarat pemicu kedua-dua perilaku ini.

MistEye respons

MistEye ialah sistem intelijen ancaman Web3 dan pemantauan keselamatan dinamik yang dikembangkan secara mandiri oleh SlowMist, yang menggabungkan kemampuan pemantauan keselamatan dan agregasi intelijen untuk memberikan amaran risiko serta perlindungan aset secara real-time kepada pengguna.

MistEye telah menyegerakan menyelaraskan risiko melalui saluran pemberitahuan cerdas dan amaran pelanggan.

Malware loader dan mekanisme pemuatan beban jarak jauh

Setelah membuka udeskApi.2026-10-16.cached.js, anda dapat melihat kod untuk fungsi butang perkhidmatan pelanggan, iframe perbualan, pelacakan pelawat, dan komunikasi mesej. Seterusnya, semak bahagian akhir fail; selepas bahagian utama berakhir, terdapat satu fungsi tersendiri: ia menghuraikan dua rentetan melalui _ud(), mencipta elemen, dan memasukkannya ke dalam head dokumen semasa.

Bahagian ini tidak menulis secara langsung nama tag dan URL jauh. Jika hanya mencari domain teks biasa, pintu masuk pemuatan mudah terlepas. Kami mengikuti implementasi _ud() dan mendapati bahawa ia mengambil dua digit heksadesimal setiap kali, kemudian menukar kepada karakter; selepas mengembangkan pemalar, tujuan pemuatan menjadi jelas.

736372697074 didekodkan sebagai script, manakala pemalar lain didekodkan sebagai https[:]//udeskqlobal[.]com/deeps.js. Domain tersebut bermula dengan huruf q, dan ejaan ini harus dikekalkan semasa carian. Loader menetapkan skrip sebagai asinkron, kemudian menyisipkannya ke dalam halaman; apabila eksekusi sampai ke kedudukan tersebut dan dasar peramban serta rangkaian membenarkan, kod jauh boleh memasuki dokumen semasa.

Beban yang sepadan dengan URL ini ialah deeps.js. Fokus penyiasatan berpindah dari SDK sokongan pelanggan kepada beban itu sendiri. Skrip klasik pihak ketiga dijalankan dalam konteks dokumen yang disematkan, dan data yang boleh diaksesnya bergantung pada halaman atau iframe yang sebenarnya dijalankan. Tetingkap sembang sokongan pelanggan menggunakan iframe dan tidak secara automatik mengasingkan skrip yang dimuatkan dalam laman induk.

Mekanisme pengumpulan data laman web dan lingkungan kesan

deeps.js mula dengan membaca window.location.hostname, dan menghasilkan konfigurasi C mengikut tiga peraturan laman web. Untuk menentukan halaman mana yang akan dikumpul, konfigurasi ini sahaja tidak mencukupi: ia membatasi keseluruhan skrip atau hanya modul tertentu, perlu diteruskan untuk melacak lokasi penilaian keluar.

Semasa mengikuti aliran kawalan ke bawah, kita melihat pembacaan Cookie dan penyimpanan web, penghantaran gambaran awal, serta hook permintaan borang dan autentikasi semuanya muncul sebelum if (!C) return; Berikut adalah petikan pernyataan penghantaran gambaran awal dan hook XHR di akhir; komen menandakan kod yang dihilangkan di tengah, yang sepadan dengan paparan diformat D:L100, D:L151–L166.

Lokasi keputusan keluar telah dinyatakan dengan jelas: walaupun hostname tidak memenuhi tiga peraturan laman web, skrip akan memasuki laluan pengumpulan data dan memasang hook terlebih dahulu sebelum keluar dari modul alamat. Semasa mengesan laman web yang terdedah, anda tidak boleh hanya mencari berdasarkan konfigurasi tiga laman web ini.

Semasa dimulakan, beban membaca Cookie, localStorage, dan sessionStorage yang boleh diakses oleh halaman web semasa. Lokasi-lokasi ini boleh menyimpan status log masuk, profil pengguna, dan data perniagaan; jika mengandungi token log masuk yang masih sah dan boleh digunakan semula, penyerang yang mendapatkannya boleh menyamar sebagai sesi pengguna. Skrip juga menyertakan URL halaman atas dan origin dokumen semasa, supaya data ini diserahkan bersama dengan halaman sumber.

Proses pengumpulan mengandungi ralat per langkah. Apabila pembacaan URL teratas dari sumber silang gagal, skrip menggantikannya dengan x dan meneruskan pemprosesan medan lain; dua jenis penyimpanan halaman diserialkan sebagai JSON. Lingkungan cookie dibatasi kepada kandungan yang boleh dibaca oleh document.cookie, dan cookie HttpOnly tidak termasuk di dalamnya.

Skrip juga menyediakan entri untuk data yang akan diserahkan seterusnya. Semasa pengguna menghantar form, ia mengitari input, select dan textarea, menyalin kandungan yang bukan kosong, kemudian meneruskan proses penghantaran asal. Medan yang sebenarnya diisi di halaman seperti nama pengguna, kata laluan, dan kod pengesahan boleh masuk ke laluan penghantaran data tambahan, dan apabila bocor, boleh digunakan untuk log masuk ke akaun atau mengambil alih akaun.

Laluan ini diimplementasikan dengan membungkus HTMLFormElement.prototype.submit dan mendengar peristiwa submit pada fasa penangkapan. Untuk halaman yang menghantar data secara langsung melalui antaramuka, skrip juga membungkus fetch dan XHR: apabila permintaan membawa badan, URL mengandungi kata kunci seperti login|signin|auth|register|signup|password, kandungan yang berkaitan disalin sambil mengekalkan panggilan permintaan asal. Cabang fetch juga memerlukan URL menjadi rentetan, dan badan berasal daripada pilihan permintaan; objek seperti FormData yang diserialisasi secara JSON terus mungkin kehilangan medan sebenar.

Mekanisme kebocoran data dan saluran simpanan

Pintu pengumpulan di atas akhirnya memanggil fungsi _send() yang sama. Dengan meneruskan pelacakan fungsi ini, dapat dilihat bahawa penerima tetap ialah https[:]//udeskqlobal[.]com/c.php. Snapshots awal menggunakan medan s, o, c, l, ss untuk membawa alamat laman, sumber semasa, Cookie yang boleh dibaca, dan dua jenis penyimpanan laman web; formulir dan permintaan pengesahan seterusnya akan dihantar semasa setiap pemicu berlaku.

Fungsi memisahkan parameter selepas tanda tanya dalam URL dan memasukkannya ke dalam badan POST asinkron, menetapkan Content-Type: application/x-www-form-urlencoded. Di bawah ini adalah fungsi penghantaran yang disimpan sepenuhnya (D:L45–L60):

Laluan penghantaran juga mengandungi cadangan permintaan gambar: apabila XHR gagal atau berlaku anomali sinchronisasi semasa penghantaran, skrip mencipta objek Image, menetapkan URL dengan parameter ke src, dan mencuba menghantar data semula melalui GET. URL dipotong kepada 8,000 aksara JavaScript pertama, dan kandungan yang lebih panjang mungkin tidak lengkap.

Semasa memahami laluan ini, perlu dibezakan antara "permintaan dihantar" dan "respons dibaca". Skrip tidak membaca respons c.php; POST lintas sumber yang memenuhi syarat permintaan mudah boleh dihantar terlebih dahulu, kemudian pembacaan respons dibatasi oleh pelayar, oleh itu ralat CORS boleh berlaku serentak dengan penghantaran permintaan. Semakan log perlu memeriksa badan POST dan parameter GET gambar, manakala strategi keluaran perlu mengesahkan connect-src dan img-src secara berasingan. Form biasa yang menyebabkan navigasi dokumen juga boleh mempengaruhi keberjayaan permintaan asinkron.

Sampai sini, destinasi data sesi laman web dan kandungan hantaran seterusnya telah jelas. Namun, beban masih menyimpan sekumpulan operasi lain selepas penilaian keluar laman: mengenal pasti format alamat, mengubah teks laman, serta mengambil alih laluan salinan. Kod-kod ini membawa penyiasatan lebih jauh ke arah perniagaan setor.

Penggantian alamat setoran dan mekanisme perompakan papan klip

Selepas if (!C) return; , skrip memasuki modul alamat. Tiga peraturan hostname awal kini mempunyai tujuan yang jelas: memadankan mgbx[.]com, bikingex[.] dan bitxex[.]io untuk memilih pemilih elemen alamat dan butang salin yang berbeza untuk halaman yang berbeza.

Reg ekspresi ini tidak memiliki anchor awal dan akhir, sehingga lingkup kecocokannya lebih luas daripada perbandingan nama domain tepat. Peraturan halaman juga memeriksa location.href yang lengkap, dan parameter kueri atau fragmen dengan kata kunci seperti deposit, recharge, assets turut dipertimbangkan dalam penilaian. Setelah halaman, elemen, dan format alamat sesuai, skrip akan memindai setiap 200 milidetik untuk mengganti alamat deposit yang dikenali dengan nilai konfigurasi. Jika pengguna menyelesaikan transfer yang sah menggunakan alamat yang diganti, tujuan penerimaan akan berubah menjadi alamat tersebut.

Tiga cabang laman web berkongsi enam nilai konfigurasi, ditandai dalam kod sebagai BTC, EVM, TRON, Solana, LTC, dan DOGE. Pengenalan alamat hanya berdasarkan bentuk karakter dan urutan kecocokan, tanpa mengesahkan rangkaian atau kod pengesahan alamat yang dipilih pengguna, dan juga boleh mengenali pengenal perniagaan biasa secara salah.

Terus semak kod yang disalin, anda boleh melihat sampel yang mengganggu paparan laman web dan kandungan papan klip serentak. Dengan cara ini, pengguna walaupun membandingkan alamat laman web dengan hasil salinan, mungkin masih mendapat nilai yang telah diubahsuai. Tiga laluan ialah:

• Membungkus API papan klip. navigator.clipboard.writeText memanggil R() terlebih dahulu untuk mengganti parameter, kemudian menyerahkan kepada kaedah asal. Laluan ini hanya dibatasi oleh konfigurasi hostname, tidak semak semula syarat laman web setor, dan tidak bergantung pada pengimbasan DOM untuk elemen yang telah tercapai.
• Gantikan butang salin. Skrip mengklon butang yang sepadan, memasang penyengat klik baru dan menggantikan nod asal. Penyengat baru menghalang tindakan lalai dan penyebaran peristiwa, serta cuba menyalin alamat yang disimpan dalam pemboleh ubah berkongsi _cur.
• Tangkap peristiwa copy. Apabila _cur bukan kosong dan peraturan laman web berlaku, listener pada document akan menggantikan kandungan yang disalin dengan _cur, tanpa memeriksa sama ada teks yang dipilih pengguna adalah alamat.

Di antaranya, pembungkus API papan klip dan pengamat copy bersebelahan dalam kod sumber (D:L260–L275), tetapi syarat pemicu berbeza:

_cur menyimpan alamat terakhir yang digantikan secara sebenar. Apabila terdapat pelbagai alamat pada skrin yang sama, penggantian terkini akan menimpa rekod sebelumnya, dan beberapa butang mungkin menyalin nilai yang sama. Jika alamat konfigurasi sudah dipaparkan semasa pemuatan halaman, pemindai tidak akan menginisialisasi _cur, dan pemerhati butang baharu tidak akan menulis kandungan; atribut acara in-line yang disalin tetap boleh terlibat dalam pemprosesan acara.

Analisis juga mengesan satu kecacatan pelaksanaan yang mempengaruhi penilaian tingkah laku: skrip cuba membaca descriptor atribut tersendiri textContent daripada Element.prototype, manakala definisi atribut piawai berada di Node.prototype. Dalam hubungan prototip piawai, akses .set seterusnya akan menghasilkan pengecualian. Selepas cabang ini gagal, catch akan menelan pengecualian tersebut; dengan menyemak kod sebelum dan selepasnya, dapat dilihat bahawa polling telah didaftarkan, dan hook salinan seterusnya masih akan dipasang mengikut syarat masing-masing. Kesalahan satu cabang tidak menghentikan modul peralihan alamat.

Ringkasan

Selepas mengesan pemuat di hujung skrip sokongan, kami mengenal pasti sasaran serangan sampel: mengumpul data yang boleh digunakan untuk menyamar sebagai sesi atau log masuk akaun, serta menukar alamat penerima dalam halaman setor dan operasi salin kepada nilai konfigurasi. Yang pertama tidak terbatas pada konfigurasi tiga laman web, manakala yang kedua diaktifkan mengikut laman web dan laluan salin tertentu, dan pemeriksaan perlu merangkumi pelbagai senario paparan.

Perusahaan yang masih memuat skrip berkaitan harus menghentikan pengagihan lanjutan, mengendalikan kredensial yang terdedah, dan memeriksa sasaran pengisian melalui latar belakang tepercaya dan rekod transaksi.

Cadangan

1. Sekat dan hentikan pembahagian sumber tercemar. Jika penghasilan masih memuatkan skrip berkaitan, segera sekat selepas menyimpan respons sebenar, rantai permintaan, maklumat cache, dan masa pengumpulan; pulihkan daripada versi boleh dipercayai yang telah disahkan secara berasingan, dan semak konfigurasi hos laman web, CDN, pembinaan, serta pengurusan tag.
2. Mengambil muat dan rekod eksfiltrasi. Gabungkan soalan untuk domain jahat, dua laluan dan hash fail; rekod eksfiltrasi juga memeriksa badan POST dan parameter GET. Semasa mengesan skrip mampat, cari URL heksadesimal dalam loader untuk mengelakkan kegagalan mendeteksi hanya teks biasa.
3. Tutup dokumen yang tercemar dan buang kredensial yang terdedah. Tutup sepenuhnya halaman atau dokumen WebView yang berkaitan, elakkan memuat semula sumber lama. Berdasarkan lingkungan dedahan yang sebenar, batalkan sesi, ganti token dan kata laluan dari persekitaran bersih; menghapus tag script tidak akan membatalkan hook dan timer yang telah dipasang.
4. Semak secara berasingan alamat pengisian dan transaksi. Untuk halaman yang melaksanakan beban, semak alamat pengisian asal, transaksi berkaitan, dan sasaran pemindahan sebenar melalui saluran tepercaya, serta nilaikan kesan berdasarkan rekod transaksi.
5. Mengesahkan skrip dan pembatasan eksport data. Gabungkan pengaturan perniagaan untuk mengawal sumber dan integriti skrip, serta mengesahkan polisi seperti connect-src dan img-src secara berasingan, dengan membataskan pemuatan skrip dan eksport data untuk udeskqlobal[.]com.

IOC

Domain

udeskqlobal[.]com

URL

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

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

Alamat dompet

BTC: bc1qhzppfj69ywp22swj50jwcfxdamg3ym245srng9

EVM: 0x9B6EcD0023a28E1391c5124eCe578A9751A337b2

TRON: TH4L5YAhhxtC8qALbZKbPZZgausbGi25nF

Solana: AFmCUe3nNbjTaC585CcdA3vvC9iWVR8YunooFKpaQx2Z

LTC: ltc1qwz0zp39ywl34kahvn9lyk7j5x63wsy9tcxhm3w

DOGE: DAoy2w8uvFtZ92q87s9qKEoHbWgV7mVThj

Fail jahat

nama fail: udeskApi.2026-10-16.cached.js

SHA256: 45b4e8f160d8d5177819f6c1dc67acc7abbdc65eeaffc909e668799dc778bcf6

filename: deeps.js

SHA256: 57c1441c4f5bb3260981a2df64f9ff35f117abde0d8667c8c66a047880074c59

Tentang MistEye

MistEye ialah platform intelijen ancaman Web3 dan pemantauan keselamatan dinamik yang dikembangkan secara mandiri oleh SlowMist, yang menyediakan kemampuan pengesanan aktiviti jahat dan amaran risiko rantaian bekalan untuk ekosistem pakej sumber terbuka melalui API.

Semua pakej jahat dan IOC yang terlibat dalam tindakan ini telah diintegrasikan ke dalam enjin pengesanan ancaman MistEye, di mana pembangun boleh melakukan pengesanan automatik terhadap bergantung projek melalui API untuk menentukan dengan cepat sama ada ia memenuhi pakej jahat yang diketahui dan mendapatkan cadangan tindakan.