Latar belakang

Solidity Pro adalah ekstensi VS Code untuk pengembang Solidity/Web3, diposisikan sebagai alat bantu pengembangan yang menyediakan fitur seperti penelusuran Gas, harga token, cuplikan kode, dan petunjuk kompilasi. Repositori GitHub-nya juga pernah mempromosikan kemampuan keamanan seperti AI Audit dan Security Scanner.

Dalam acara publik, Solidity Pro sebelumnya menggunakan dua publisher (identitas penerbit), yaitu helper-beeps dan web3devtoolsx. Extension ID (identitas unik ekstensi) masing-masing adalah helper-beeps.solidity-pro dan web3devtoolsx.solidity-pro. Meskipun identitas penerbit kemudian berubah, artefak build selanjutnya tetap mempertahankan publisher lama, alamat repositori, dan informasi hak cipta, yang menunjukkan adanya hubungan pewarisan rekayasa langsung di antara keduanya.

Pada 6 hingga 7 Agustus 2026, kedua Extension ID ini berturut-turut dimasukkan ke daftar kontrol ekstensi berbahaya yang dipakai Open VSX. Secara logika, pemeriksaan lanjutan berdasarkan versi seharusnya masih menunjukkan kemampuan berbahaya terkait, tetapi Solidity Pro 4.0.0 (publisher: web3devtoolsx) yang kami peroleh justru menampilkan hasil yang sama sekali berbeda: bundle akhir (kode eksekusi yang sudah dipaketkan) hanya menyisakan fungsi umum seperti Gas, harga token, dan log, sementara modul pengumpulan kredensial, pengunduhan payload jarak jauh, eksekusi subprocess, dan pembaruan VSIX jarak jauh yang muncul di versi berbahaya historis sudah hilang.

Maka pertanyaannya berubah menjadi: mengapa sebuah plugin yang sudah memiliki sejarah berbahaya yang jelas, pada versi-versi berikutnya tiba-tiba menjadi “bersih”?

Artikel ini akan menelusuri mundur versi dan perubahan identitas publisher Solidity Pro dari 4.0.0, menganalisis dua versi berbahaya historis, GitHub Clean commit, migrasi publisher, dan garis waktu aktivitas publik, serta membahas bagaimana hanya mengandalkan versi saat ini untuk menilai risiko ekstensi IDE dapat menimbulkan titik buta deteksi.

Analisis ini didasarkan pada bukti statis, tanpa menjalankan sampel atau menghubungkan infrastruktur jarak jauh.

Respons MistEye

MistEye adalah platform intelijen ancaman Web3 dan pemantauan keamanan dinamis yang dikembangkan sendiri oleh SlowMist, mengintegrasikan kemampuan pemantauan keamanan dan agregasi intelijen untuk menyediakan peringatan risiko real-time dan perlindungan aset bagi pengguna.

MistEye melakukan penelusuran keterkaitan terhadap dua identitas publisher helper-beeps.solidity-pro dan web3devtoolsx.solidity-pro beserta sampelnya. Dengan menggabungkan deobfuscation statis, verifikasi silang kemampuan berbahaya, dan garis waktu platform publik, sistem mengekstrak hash sampel, Extension ID, jalur request berbahaya, dan perilaku pembaruan jarak jauh untuk peringatan risiko rantai pasok ekstensi IDE.

I. Versi saat ini

Untuk menentukan mengapa 4.0.0 tidak terdeteksi sebagai kode berbahaya, dua objek harus diperiksa sekaligus: sampel 4.0.0 yang kami peroleh dalam artikel ini, dan status repositori GitHub yang konsisten dengan bundle-nya.

Isi paket VSIX. Bundle akhir dari paket 4.0.0 yang dibangun ulang secara lokal terutama memuat ApiClient, GasTracker, PriceMonitor, dan Logger, dengan akses jaringan yang terpusat di Etherscan dan CoinGecko. Setelah ekstensi diaktifkan pada onStartupFinished atau workspace yang berisi file Solidity, yang dijalankan hanya Gas tracker, Price monitor, dan logger, serta tiga perintah publik didaftarkan; perintah compile hanya menampilkan petunjuk Hardhat/Foundry, tanpa benar-benar memanggil compiler. Pada file yang diperiksa dan jalur statis yang dapat dicapai, tidak ditemukan empat jenis kemampuan berbahaya dari versi historis: pengumpulan kredensial, pengunduhan payload jarak jauh, eksekusi subprocess, dan pembaruan VSIX jarak jauh.

Apa lagi yang ada di repositori GitHub. Paket 4.0.0 sendiri tidak membawa source code, sehingga kami menelusuri balik ke工程 publiknya di GitHub. Di repositori tersebut terdapat commit dengan package.json yang menurunkan versi menjadi v1.0.0, commit 95dce4f, dan pesan commit "Clean release"; out/extension.js pada commit itu dan bundle 4.0.0 sama-sama berukuran 10.633 byte serta memiliki SHA-256 identik.

out/extension.js pada commit tersebut juga hanya memuat ApiClient, GasTracker, PriceMonitor, dan Logger, sementara fungsi activate dan deactivate hanya melakukan inisialisasi serta pembersihan. Namun direktori src/ pada commit yang sama menunjukkan hal lain: src/telemetry/Web3Analytics.ts masih ada, dengan header file bertuliskan "Sends install ping immediately, then scans for secrets", berisi wordlist BIP39, identifikasi kredensial dompet, konfigurasi eksfiltrasi WORKERS, dan batas pengumpulan file skala besar; src/services/AutoUpdater.ts juga masih dipertahankan, mendefinisikan pemeriksaan versi berkala 30 menit dan logika instalasi VSIX jarak jauh.

Repositori GitHub (Clean commit 95dce4f)
├── src/telemetry/Web3Analytics.ts   # sumber proyek pengumpulan berbahaya masih ada
├── src/services/AutoUpdater.ts  # sumber pembaruan VSIX jarak jauh masih ada
├── .vscodeignore                # mengecualikan src/**, scripts/**, *.ts
└── out/extension.js             # bundle bersih yang terlihat saat build

Mengapa source berbahaya tidak masuk ke paket VSIX? Di sini ada dua lapisan pembatas.

Lapisan pertama adalah titik masuk eksekusi: src/extension.ts pada Clean commit menghapus import dan logika startup untuk Web3Analytics dan AutoUpdater, sehingga ketika esbuild membangun graf dependensi dari entry tersebut, dua modul ini აღარ dimasukkan ke out/extension.js.

Lapisan kedua adalah visibilitas dalam paket: .vscodeignore mengecualikan src/**, scripts/**, dan *.ts, sambil mempertahankan out/**, sehingga file sumber TypeScript yang tersisa juga tidak akan masuk ke VSIX yang dihasilkan berdasarkan konfigurasi tersebut dalam bentuk sumber asli. Commit v1.0.0 menuliskan "Clean release", tetapi file sumber modul berbahaya tidak dihapus atau diubah dalam commit tersebut — artefak akhir menjadi bersih, namun modul berbahaya di dalam proyek masih bisa dimasukkan kembali melalui perubahan sumber atau konfigurasi build berikutnya.

二、Versi berbahaya historis

Karena versi saat ini dan bundle Clean commit sama-sama tidak menemukan modul berbahaya asli, investigasi perlu terus menelusuri versi historis Solidity Pro di bawah dua identitas publisher tersebut.

Solidity Pro tidak selalu menggunakan implementasi berbahaya yang sama. Versi 2.4.1 yang diperoleh di bawah identitas publisher helper-beeps dan versi 3.4.0 di bawah identitas publisher web3devtoolsx menunjukkan dua cara eksekusi yang jelas berbeda: yang pertama berfokus pada pengunduhan tertunda dan eksekusi kode jarak jauh, sedangkan yang kedua berfokus pada pengumpulan kredensial bawaan dan kanal pembaruan jarak jauh.

2.4.1：penundaan pengiriman

Dalam sampel Solidity Pro 2.4.1 yang kami peroleh dalam artikel ini (publisher: helper-beeps), ekstensi diaktifkan di file Solidity atau workspace Hardhat/Foundry, dengan telemetry aktif secara default. Setelah aktif, kode tidak langsung masuk ke tahap pengunduhan, melainkan menetapkan jendela tunggu acak selama 24 hingga 48 jam:

MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000

Setelah menunggu selesai, kode memeriksa keberadaan variabel lingkungan seperti CI, GITHUB_ACTIONS, JENKINS_HOME, dan GITPOD_WORKSPACE_ID; jika cocok, proses akan keluar. Selanjutnya enam jalur relatif direktori utama yang dienkode diperiksa satu per satu menggunakan fs.existsSync, dan pada tahap ini jalur-jalur tersebut hanya dipakai untuk penyaringan keberadaan.

Setelah lolos penyaringan, kode berturut-turut mencoba dua endpoint yang dienkode dan meminta jalur tetap /firmware ke masing-masing endpoint. Setelah respons diperoleh, kode memverifikasi panjangnya, menggunakan crypto.createDecipheriv untuk mendekripsi dengan AES-GCM, menulis teks hasil dekripsi ke file .py di direktori sementara dengan hak akses terbatas, lalu mengeksekusinya dengan child_process.spawn dalam mode detached. Sekitar 60 detik kemudian unlinkSync membersihkan file sementara. Karena respons /firmware sebenarnya tidak diperoleh, fungsi tahap kedua tidak diketahui.

3.4.0：pengumpulan kredensial

Solidity Pro 3.4.0 (publisher: web3devtoolsx) pada package.json activationEvents secara bersamaan mendeklarasikan workspaceContains:*.sol dan onStartupFinished. Ekstensi dapat otomatis masuk ke activate() setelah VS Code selesai memulai, tanpa mengharuskan pengguna menjalankan perintah publiknya.

Konfigurasi default solidity-pro.telemetry.enabled=true akan membuat dan menjalankan Web3Analytics. README mengklaim hanya mengumpulkan data penggunaan anonim dan tidak menyimpan private key atau source code, tetapi objek yang sebenarnya dipindai oleh modul ini mencakup aset inti dalam domain kepercayaan pengembang:

• Dompet dan material tanda tangan: private key EVM, seed phrase BIP39, keystore, Solana id.json, data ekstensi dompet browser (MetaMask, Phantom, Coinbase Wallet, Rabby).

• Sumber kode dan kredensial rilis: token GitHub ghp_/gho_/github_pat_, GitLab glpat-, .npmrc, token PyPI, .netrc, kredensial Git.

• Cloud dan infrastruktur: AWS access/secret/session key, konfigurasi Kubernetes, otentikasi Docker, Azure, dan GCP.

• Proyek dan jejak interaksi: .env dan variannya, API key, token layanan AI (sk-, sk-proj-, sk-ant-), riwayat Shell, dan informasi host.

Pencocokan regex untuk private key EVM mencakup nama variabel umum seperti privateKey, PRIVATE_KEY, WALLET_KEY, DEPL0YER_KEY, dan nilai heksadesimal 64 karakter:

var _0x4e0bcc = [
  /["']privateKey["']\s*:\s*["'](?:0x)?([0-9a-fA-F]{64})["']/g,
  /(?:PRIVATE_KEY|PRIVATEKEY|ETH_KEY|ETHKEY|WALLET_KEY|WALLETKEY|DEPLOYER_KEY|OWNER_KEY)\s*=\s*["']?(?:0x)?([0-9a-fA-F]{64})["']?/gi,
  /(?:privateKey|private_key|ethKey|eth_key|walletKey|wallet_key)\s*[:=]\s*["'](?:0x)?([0-9a-fA-F]{64})["']/gi,
  /(?:priv(?:ate)?[ _-]?key|secret)[:=]\s*["']?(0x[0-9a-fA-F]{64})["']?/gi
];

Logika pengumpulan direktori SSH akan menelusuri file private key kandidat di ~/.ssh/, membaca isinya, lalu menyerahkannya ke extractor extractSecrets. Hasil pengumpulan dikirim keluar melalui dua jalur request HTTP: JSON teks dikirim via HTTPS POST /x ke host CFG.WORKERS yang di-obfuscate, sedangkan laporan lengkap dikirim sebagai multipart/form-data ke grup host yang sama melalui POST /y.

Berjalan paralel dengan rantai pengumpulan tersebut adalah AutoUpdater. Komponen ini dibuat dan dijalankan tanpa syarat di dalam activate(), tanpa bergantung pada konfigurasi telemetry. Setelah mulai, ia segera meminta /version sekali, lalu setiap 30 menit melakukan polling ke dua Worker yang di-hardcode; selama respons memuat version dan url, kode membandingkan nomor versi, mengunduh VSIX, memanggil perintah instalasi VS Code, lalu menghapus file sementara.

Seluruh rantai pembaruan ini tidak memiliki pemeriksaan integritas apa pun — updater sendiri tidak mengimplementasikan hash, tanda tangan, publisher, atau pinning sertifikat. Artinya server dapat, pada polling mana pun, mengembalikan versi yang lebih tinggi dan alamat unduhan, lalu sendiri menentukan kapan memicu pembaruan dan VSIX mana yang dikirim. Lebih penting lagi, sebelum pembaruan hanya akan muncul notifikasi dengan satu tombol "OK"; kode akan terus menginstal setelah proses notifikasi selesai, tanpa opsi batal yang benar-benar berfungsi dan tanpa membaca hasil pilihan pengguna.

Alasan target pengumpulan semacam ini berbahaya adalah karena IDE Extension Host berada di dalam domain kepercayaan pengembang. Mesin kerja Web3 sering menyimpan material dompet, kredensial repositori sumber, token rilis paket, konfigurasi CI/CD, dan platform cloud; satu serangan rantai pasok ekstensi bisa melintasi banyak batas keamanan sekaligus.

Empat jenis sampel atau peran versi:

III. Migrasi publisher

Versi 2.4.1 dan 3.4.0 dari Solidity Pro tidak termasuk dalam Extension ID yang sama. Yang pertama dirilis oleh helper-beeps, sedangkan yang kedua memakai publisher baru web3devtoolsx. Mengapa keduanya masih bisa ditempatkan dalam satu lini investigasi?

Metadata internal commit awal v3.4.0 fe794a2 menjawab pertanyaan ini secara langsung. package.json menyatakan publisher: web3devtoolsx, versi 3.4.0, dan repository mengarah ke github.com/web3devtoolsx/solidity-pro. Namun out/package.json pada commit yang sama masih mempertahankan publisher: helper-beeps, versi 3.3.0, dan repository ke github.com/helper-beeps/solidity-pro. File LICENSE masih bertuliskan "Copyright (c) 2026 Helper Beeps".

Dua package.json berasal dari commit yang sama, membuktikan bahwa artefak build awal Solidity Pro di bawah identitas web3devtoolsx langsung berasal dari proyek helper-beeps, sehingga ada hubungan asal langsung pada kode atau artefak build.

Setelah hubungan pewarisan artefak build ditumpangkan dengan garis waktu penandaan malicious resmi, pola rotasi publisher menjadi semakin jelas:

helper-beeps.solidity-pro dimasukkan ke daftar malicious resmi (2026-08-06 14:27:24 UTC)
    │ 8 jam 32 menit 48 detik
    ▼
akun GitHub web3devtoolsx dibuat (2026-08-06 23:00:12 UTC)
    │ sekitar 16 menit
    ▼
Solidity Pro v3.4.0 yang baru muncul
    │ keesokan harinya
    ▼
web3devtoolsx.solidity-pro juga dimasukkan ke daftar malicious resmi (2026-08-07 12:38:52 UTC)

四、Rilis bersih

Hanya 13 menit 29 detik setelah commit awal GitHub yang memuat bundle v3.4.0 berbahaya, repositori yang sama membuat Clean commit yang menurunkan versi menjadi v1.0.0. Dalam jendela waktu yang sangat singkat itu, publisher juga sempat mengajukan namespace claim Open VSX dan kemudian menutupnya sendiri (issue tanpa komentar, ditutup oleh web3devtoolsx sendiri).

Perubahan pada Clean commit tepat terfokus pada dua jenis target. Di sisi eksekusi, Web3Analytics, AutoUpdater, konfigurasi telemetry, dependensi javascript-obfuscator, dan langkah build obfuscation dihapus. Di sisi permukaan produk, AI Audit Engine, Security Scanner, badge 100K+, dan teks kemampuan yang dilebih-lebihkan juga dihapus. Nomor versi diturunkan dari 3.4.0 ke 1.0.0.

Perubahan-perubahan ini terkonsentrasi dalam commit yang sama bernama "Clean release". Commit itu langsung menghapus titik masuk berisiko tinggi yang dapat dijangkau publik dan sebagian teks pemasaran yang mencolok, sehingga sistem yang hanya memeriksa bundle baru tidak lagi mendeteksi modul berbahaya asli. Pembersihan tidak sepenuhnya tuntas: deskripsi package.json berupa "Trusted by 100K+" dan pernyataan "vulnerability scanner" tidak dihapus — badge paling mencolok memang dihapus, tetapi jika manifest tersebut benar-benar dibuild dan dipublikasikan, metadata yang dapat memengaruhi hasil pencarian dan halaman toko tetap ada. Dan seperti disebutkan sebelumnya, source berbahaya masih lengkap di direktori src/, hanya saja tidak masuk ke paket akhir karena .vscodeignore.

Clean release mengubah artefak akhir, bukan sejarah yang sudah terjadi pada proyek ini.

V. Pembungkus kredibilitas

Bersamaan dengan perubahan versi, terjadi pula pembingkaian cepat identitas publisher baru: dalam sekitar 16 menit setelah akun web3devtoolsx dibuat, materi bergaya perusahaan, enam fork proyek terkenal, repositori produk, nomor versi matang, dan klaim 100K+ muncul secara terkonsentrasi. Sinyal-sinyal yang terkumpul ini, secara objektif, membuat akun baru tampak seperti organisasi yang cukup matang.

Materi bergaya perusahaan. Sekitar 15 menit setelah akun dibuat, Profile sudah berisi nama "Web3 Dev Tools", kolom perusahaan, lokasi Zug, tautan situs resmi, Twitter, satu produk yang sudah tayang, dan dua roadmap produk "Coming Q3". Hingga tinjauan ulang pada 12 Agustus 2026, indikator aktivitas jangka panjang seperti followers, following, dan gists masih 0.

Enam fork proyek terkenal. Dalam 13 detik, akun tersebut berurutan mem-fork OpenZeppelin Contracts, Foundry, Hardhat, Chainlink, Uniswap v3-core, dan ethers.js. Pengunjung biasa akan melihat nama-nama proyek Web3 yang familier di halaman utama, tetapi fork hanya berarti menyalin repositori hulu, bukan kontribusi, kerja sama, atau bentuk pengesahan apa pun.

Penandaan versi dan waktu pembuatan tidak konsisten. Commit awal yang dibuat 8 detik setelah repositori dibuat sekaligus membawa lima set penandaan versi: v2.4.1, v2.4.5, v3.2.3, v3.3.0, dan v3.4.0, sementara bagian kepala kode sumber juga mengklaim rilis pertama pada 2025. Versi dan penanda usia ini jelas tidak konsisten dengan akun dan riwayat publik repo yang baru dibuat pada hari yang sama.

Penguatan social proof yang berulang. "100K+" muncul sekaligus di repository description, package.json, out/package.json, badge README, isi README, dan output build, sebagai klaim skala pengguna yang terus ditekankan dalam materi publik proyek. Materi yang ada tidak dapat memverifikasi angka ini secara independen, tetapi pernyataan tersebut bersama nomor versi matang, profil yang menyerupai perusahaan, dan fork proyek terkenal, secara kolektif membentuk citra produk matang yang ditampilkan Solidity Pro ke luar.

Materi promosi ini jelas bertentangan dengan perilaku kode nyata yang telah dikonfirmasi sebelumnya: README menyatakan tidak menyimpan private keys atau source code, konfigurasi mendeskripsikan telemetry sebagai data penggunaan anonim, dan skrip build menyebut proses obfuscation javascript-obfuscator sebagai "privacy". Produk mengklaim audit AI, pemindaian kerentanan, dan deteksi reentrancy, tetapi perintah publiknya בעיקר hanya untuk mengecek Gas, menampilkan harga token, dan satu petunjuk yang dikompilasi melalui Hardhat/Foundry.

Materi organisasi, fork terkenal, nomor versi matang, 100K+, fungsi kecil yang benar-benar berguna, dan penjelasan privasi semuanya memengaruhi penilaian awal pengunjung terhadap ekstensi. Masing-masing elemen mungkin tampak normal jika dilihat sendiri, tetapi anomali muncul ketika sinyal-sinyal itu hadir bersamaan dengan kode berbahaya, garis waktu yang cepat, dan residu build dari publisher lama.

VI. Kelemahan deteksi satu versi

Kode berbahaya dapat dihapus, tetapi riwayat versi, identitas penerbit, dan asal proyek tidak akan otomatis di-reset.

Jika penemuan dari lima bab pertama digabungkan, Solidity Pro menampilkan pola yang patut diperhatikan oleh platform dan produk keamanan: sebuah nama ekstensi dan publisher yang sudah terkait dengan sejarah berbahaya yang jelas, melalui penerbitan versi baru yang tidak lagi memuat kemampuan berbahaya lama, dapat membuat deteksi yang hanya memeriksa build saat ini kembali memberi hasil clean, tidak terdeteksi, atau berisiko rendah.

Membedakan pola ini dari perbaikan keamanan yang normal tidak cukup hanya melihat apakah kode baru bersih; empat lapisan berikut juga perlu diverifikasi:

• Jawaban hash dan bundle saat ini: file ini sekarang berisi apa.

• Jawaban riwayat versi: apa yang sebelumnya pernah dikirim oleh extension ID atau publisher ini.

• Jawaban publisher dan sumber kode: paket saat ini terkait langsung dengan proyek berbahaya yang sudah diketahui mana saja.

• Jawaban kontrol jarak jauh saat ini dan historis: apakah kode lokal saat ini atau versi historis mengizinkan server mengubah isi pengiriman.

Bagi pasar ekstensi dan produk keamanan, ini berarti objek deteksi perlu diperluas dari "hash file tunggal" menjadi riwayat versi, perubahan publisher, perbedaan artefak build, dan kontrol jarak jauh:

• Simpan hash dan hasil deobfuscation dari versi historis; ketika versi baru menghapus banyak modul berbahaya, lakukan review perbedaan, bukan otomatis memulihkan reputasi.

• Hubungkan residu publisher lama, kemiripan kode, dan skrip build untuk membangun keterkaitan asal dari kode atau artefak build.

• Masukkan pemeriksaan /version berkala, URL jarak jauh, dan catatan instalasi VSIX sementara ke dalam pemantauan runtime.

• Gunakan download, stars, dan Profile bergaya perusahaan hanya sebagai konteks, bukan sebagai pengesahan keamanan.

Kesimpulan

Solidity Pro di bawah dua identitas penerbit, helper-beeps dan web3devtoolsx, sama-sama memiliki implementasi berbahaya yang jelas: 2.4.1 mengandalkan penundaan acak lokal dan penyaringan lingkungan sebagai syarat awal, lalu mengunduh Python terenkripsi dari jarak jauh dan mengeksekusinya; 3.4.0 secara otomatis terpicu setelah VS Code selesai memulai untuk mengumpulkan kredensial, mengekspor data lewat dua jalur permintaan HTTP /x dan /y, sambil mempertahankan kanal pembaruan VSIX yang digerakkan respons jarak jauh. out/package.json, repository, dan informasi copyright pada 3.4.0 awal masih menunjuk ke helper-beeps, membuktikan bahwa artefak build dari dua identitas publisher itu memiliki hubungan asal langsung.

Bundle akhir dari GitHub Clean commit menghapus modul-modul berbahaya tersebut, tetapi repositori masih menyimpan file sumber modul berbahaya; paket 4.0.0 yang dibangun ulang secara lokal juga tidak menemukan modul berbahaya asli. Antara commit awal yang memuat entri berbahaya dan Clean commit hanya berselang 13 menit 29 detik, sementara materi bergaya perusahaan, enam fork terkenal, repositori produk, dan deklarasi versi matang muncul terkonsentrasi sekitar 16 menit setelah akun dibuat.

Kasus ini pada akhirnya menunjukkan bahwa menilai risiko ekstensi hanya berdasarkan file saat ini atau versi saat ini jauh dari cukup. Kode berbahaya bisa hilang dari bundle terbaru, tetapi catatan berbahaya historis tidak otomatis menjadi tidak berlaku — versi baru yang bersih tidak menghapus fakta bahwa nama dan publisher yang sama sebelumnya pernah mengirim kode berbahaya.

Rekomendasi

1. Pengembang yang pernah memasang helper-beeps.solidity-pro atau web3devtoolsx.solidity-pro sebaiknya terlebih dahulu mengisolasi jaringan, lalu mengamankan direktori ekstensi, salinan paket instalasi, proses, dan log jaringan, kemudian menonaktifkan dan menghapus versi terkait. Setelah itu periksa pohon proses VS Code, file Python di direktori sementara, catatan instalasi VSIX yang tidak normal, serta permintaan /firmware, /x, /y, /version di log proxy.

2. Jika pernah mengaktifkan Solidity Pro 3.4.0 (publisher: web3devtoolsx), private key dompet, seed phrase, GitHub/GitLab/npm/PyPI/AWS/Cloudflare/layanan AI, dan token CI/CD mungkin terekspos. Kredensial terkait sebaiknya dicabut atau diganti dari perangkat bersih terlebih dahulu; aset kripto harus dipindahkan ke dompet baru yang menggunakan seed atau private key baru, bukan hanya mengubah kata sandi dompet lama.

3. Jika pernah mengaktifkan Solidity Pro 2.4.1 (publisher: helper-beeps), selama host mungkin sudah melewati jendela tunda sampel tersebut, atau durasi eksekusi aktual tidak dapat dipastikan, maka insiden harus diperlakukan sebagai investigasi eksekusi kode lokal yang potensial.

4. Tim keamanan perusahaan sebaiknya terlebih dahulu mencari Extension ID, jalur request berbahaya, Worker yang diketahui, file sementara, dan pohon proses yang tidak normal, lalu menggabungkannya dengan dua hash SHA-256 sampel, waktu instalasi ekstensi, dan rekaman jaringan proses VS Code untuk menentukan cakupan yang terdampak. Fokus deteksi pada kombinasi perilaku seperti VS Code Extension Host yang memulai detached Python, instalasi VSIX dari jalur sementara, dan pengiriman multipart HTTPS setelah membaca konfigurasi bernilai tinggi.

5. Pasar ekstensi harus melakukan review manual wajib terhadap kemampuan yang muncul dalam telemetry bawaan berupa pembacaan kredensial, pengunduhan jarak jauh, eksekusi dekripsi, atau pemasangan VSIX di luar kanal resmi; simpan versi historis dan lakukan peninjauan perbedaan lintas versi agar versi berikutnya yang tidak lagi memuat kode berbahaya tidak otomatis menghapus label risiko versi lama.

IOC

File berbahaya

filename: helper-beeps.solidity-pro-2.4.1.tar.gz 

SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename: web3devtoolsx.solidity-pro-3.4.0.gz 

SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508

Tentang MistEye

MistEye adalah platform intelijen ancaman Web3 dan pemantauan keamanan dinamis yang dikembangkan sendiri oleh SlowMist, menyediakan kemampuan deteksi aktivitas berbahaya pada ekosistem paket sumber terbuka dan peringatan risiko rantai pasok melalui API.

Seluruh paket berbahaya dan IOC yang terlibat dalam operasi ini telah diintegrasikan ke mesin deteksi ancaman MistEye; pengembang dapat melakukan deteksi otomatis terhadap dependensi proyek melalui API untuk dengan cepat menentukan apakah ada kecocokan dengan paket berbahaya yang sudah diketahui dan memperoleh saran penanganan.

📖 Dokumentasi API：https://app.misteye.io/api-docs

🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan alat CLI ringan, satu perintah untuk memindai dependensi proyek dan paket yang terinstal global terhadap paket berbahaya yang sudah diketahui, mendukung ekosistem npm / PyPI / Rust（Cargo）/ Go / RubyGems

🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills paket skill keamanan untuk AI coding assistant yang secara otomatis memicu deteksi keamanan MistEye sebelum instalasi dependensi dan akses URL

🛠️ MistEye-DNS-Guard：https://github.com/slowmist/MistEye-DNS-Guard relay DNS lokal berbasis Rust yang mendeteksi domain berbahaya dan akses berisiko, mengenali phishing, C2, dan ancaman jaringan lainnya.

Artikel ini disusun oleh tim intelijen ancaman SlowMist dengan menggabungkan platform intelijen ancaman MistEye dan analisis yang digerakkan SlowMist Agent AI. Jika ada pertanyaan, silakan hubungi kami untuk masukan.

Tautan referensi:

[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram