Ketika Nama Tepercaya Dipakai untuk Menyisipkan Malware

Versi yang terdampak tersedia selama kira-kira tiga jam. Google Threat Intelligence Group mencatat aktivitas antara pukul 00.21 dan 03.20 UTC pada 31 Maret, sementara laporan lain menggambarkan jendela paparan sekitar dua hingga tiga jam. Axios merupakan dependensi berdampak besar; sejumlah laporan memperkirakan penggunaannya mencapai sekitar 80 juta hingga lebih dari 100 juta unduhan per minggu di npm, meski angkanya berbeda menurut sumber.

Bagaimana akun pengelola disalahgunakan?

Laporan publik terkuat mengarah pada pengambilalihan akun npm, bukan kerentanan bawaan pada Axios. Salah satu laporan menyebut penyerang menggunakan token akses npm berumur panjang milik pengelola utama. Laporan lain menjelaskan insiden tersebut secara lebih umum sebagai kompromi akun pengelola atau kredensial penerbitan.

Perbedaan ini penting. Serangan tersebut menembus batas kepercayaan antara kewenangan penerbitan milik pengelola dan sistem rilis npm. Karena rilis berbahaya diterbitkan melalui akun yang sah, pengembang dan sistem otomatis memiliki lebih sedikit alasan untuk menganggapnya mencurigakan.

Apa yang dilakukan dependensi berbahaya itu?

plain-crypto-js@4.2.1 disamarkan sebagai dependensi biasa, tetapi tujuan utamanya adalah menjalankan skrip postinstall. Skrip tersebut menghubungi server command-and-control (C2), lalu mengambil muatan tahap kedua yang disesuaikan dengan sistem operasi perangkat.

Artinya, pengembang tidak harus mengunduh berkas executable yang jelas-jelas mencurigakan. Pemicu serangan dapat berupa pembaruan dependensi biasa, proses build CI, atau

npm install

Apakah BlueNoroff berada di balik serangan Axios?

Atribusi serangan ini belum sepenuhnya disepakati dalam materi yang tersedia. Sejumlah laporan mengaitkannya dengan aktor yang berhubungan dengan Korea Utara, termasuk BlueNoroff atau klaster terkait. Microsoft, di sisi lain, mengatribusikan kompromi tersebut kepada Sapphire Sleet.

Penilaian tersebut tidak seharusnya diperlakukan sebagai satu kesimpulan yang sudah terkonfirmasi. Kemiripan kode, infrastruktur, dan cara operasi dapat menjadi petunjuk atribusi, tetapi belum cukup untuk membuktikan kelompok mana yang melakukan serangan. Kesimpulan yang paling dapat dipertanggungjawabkan adalah bahwa kompromi Axios melibatkan pengambilalihan akun pengelola, rilis yang telah diracuni, dan RAT lintas platform. Identitas pelakunya masih diperdebatkan dalam berbagai penilaian publik.

Cara SilverFox menyebarkan aplikasi Claude palsu

SilverFox menggunakan jalur yang berbeda untuk memasuki organisasi: menyebarkan aplikasi Claude palsu untuk Windows, macOS, dan Linux. Kampanye ini menyasar organisasi di sektor industri, konsultasi, perdagangan, dan transportasi di India, Indonesia, Afrika Selatan, serta Rusia.

Aplikasi tersebut merupakan tiruan merek Claude milik Anthropic, bukan installer Claude resmi. Keberhasilannya bertumpu pada skenario yang masuk akal di tempat kerja: seorang karyawan mencari alat produktivitas berbasis AI, mengunduh aplikasi yang tampak familiar, lalu tanpa sadar memasang malware. Laporan Kaspersky menggambarkan kampanye ini sebagai bagian dari aktivitas SilverFox yang berlangsung dalam beberapa gelombang sejak Desember 2025.

Dari phishing bertema pajak ke umpan AI

Kampanye itu juga melanjutkan pola phishing bertema pajak. Pada Januari dan Februari 2026, peneliti mencatat lebih dari 1.600 email berbahaya yang menyamar sebagai pemberitahuan pemeriksaan pajak resmi atau mengaku berisi daftar pelanggaran pajak.

Metode pengirimannya berubah, tetapi sinyal kepercayaannya tetap sama. Pemberitahuan pajak memanfaatkan kesan mendesak dan otoritas, sedangkan asisten AI bermerek memanfaatkan relevansi dan kemudahan. Keduanya dapat mendorong pengguna membuka lampiran, mengunduh arsip, atau memasang perangkat lunak sebelum memeriksa sumbernya.

SilverFox menggunakan model pengiriman bertahap dengan infrastruktur terpisah untuk fase-fase intrusi yang berbeda. Segmentasi seperti ini dapat menyulitkan tim pertahanan untuk memblokir atau mengenali seluruh rantai serangan hanya dari satu domain atau indikator.

Pelajaran utamanya: kepercayaan adalah bagian dari permukaan serangan

Serangan Axios dan SilverFox menyasar hubungan kepercayaan yang berbeda:

• Kepercayaan pada pengelola: Rilis Axios tampak diterbitkan melalui penerbit npm yang berwenang.
• Kepercayaan pada dependensi: Manajer paket memperlakukan dependensi berbahaya sebagai bagian dari jalur instalasi normal.
• Kepercayaan pada merek: Installer Claude palsu meminjam identitas produk AI yang mudah dikenali.
• Kepercayaan pada alur kerja: Pengembang dan karyawan hanya menjalankan tindakan rutin—memperbarui dependensi atau memasang perangkat lunak produktivitas.

Kasus Axios menunjukkan mengapa jendela paparan yang singkat tetap dapat berbahaya. Instalasi paket dan pekerjaan CI bisa berjalan otomatis, sehingga jumlah sistem yang terjangkau tidak terbatas pada orang yang sempat memeriksa rilis secara manual. Kasus SilverFox memperlihatkan prinsip yang sama dari sisi endpoint: kategori perangkat lunak yang diadopsi dengan cepat, termasuk alat AI, memberi penyerang umpan baru yang terasa masuk akal.

Langkah yang perlu dilakukan organisasi

Untuk insiden Axios, periksa lockfile, manifest paket, log build, cache, serta inventaris dependensi guna mencari axios@1.14.1, axios@0.30.4, dan plain-crypto-js@4.2.1. Setiap mesin yang memasang versi terdampak selama jendela paparan perlu diselidiki untuk mencari muatan yang diunduh, mekanisme persistensi tanpa izin, dan kredensial yang mungkin terekspos. Penasihat keamanan secara khusus merekomendasikan agar instalasi yang terdampak diperlakukan sebagai berpotensi telah disusupi.

Untuk perangkat lunak AI, organisasi sebaiknya mewajibkan karyawan memperoleh aplikasi desktop melalui kanal yang disetujui, memeriksa penerbit dan domain unduhan, serta memblokir atau mengarantina installer yang tidak diizinkan. Dalam penerbitan paket npm, autentikasi multifaktor yang tahan phishing, kredensial berumur pendek atau dengan cakupan ketat, provenance rilis, lockfile, dan peninjauan perubahan dependensi dapat mengurangi risiko satu akun yang dibajak berubah menjadi insiden supply chain.

Pengendalian yang lebih luas adalah melakukan verifikasi di setiap batas kepercayaan. Nama paket yang familiar bukan jaminan bahwa setiap versinya aman, dan nama produk yang terkenal bukan bukti bahwa setiap installernya asli.