Di balik halaman 404: apa yang disembunyikan loader sebuah botnet IoT

Pada 9 Oktober 2026 kami menulis tentang server botnet, 85.137.53[.]167, yang terus membalas honeypot kami dengan halaman error. Beberapa mesin terus login ke honeypot Telnet kami dan meminta skrip loader dari server itu, dan server itu terus menjawab "not found". Kami tetap menemukan server perintahnya, lewat bot lama yang dikumpulkan peneliti lain.

Sehari kemudian server itu mulai menjawab. Tulisan ini membahas apa yang dikirimnya, apa yang dilakukan bot saat kami jalankan, dan kenapa loader-nya terasa familiar. (Diperbarui 12 Oktober: server perintahnya kini pindah ke balik terowongan; lihat pembaruan di bawah.)

Loader akhirnya datang

Pukul 16:12 UTC tanggal 10 Oktober, sebuah mesin di 45.153.34[.]18 login ke honeypot kami lewat Telnet sebagai root dengan kata sandi vizxv, salah satu kata sandi bawaan pabrik yang dicoba Mirai pada kamera dan perekam video murah sejak 2016. Mesin itu mengunduh skrip pendek bernama wget.sh dari 85.137.53[.]167 lalu menjalankannya. Sembilan menit kemudian ia melakukan hal yang sama dengan kata sandi pabrik lain yang sudah lama dikenal, xc3511.

Honeypot kami mencatat apa yang diunduh penyerang tetapi tidak pernah menjalankannya. Jadi kami menjalankan skrip itu sendiri, di lab terisolasi kami, dengan lab hanya boleh menjangkau satu server itu dan tidak ada yang lain.

Apa yang dilakukan loader

Skripnya sekitar 80 baris. Ia mencari tahu jenis prosesor perangkat, memilih satu dari 19 build bot yang cocok (ARM, MIPS, x86, PowerPC, RISC-V dan lainnya), mengunduhnya, lalu menjalankannya di latar belakang. Jika build yang tepat tidak tersedia, ia mencoba delapan build umum secara bergantian.

Skrip itu juga membuang unduhan apa pun yang lebih kecil dari 4 KB. Detail ini menjelaskan halaman error tadi: di perangkat korban sungguhan, halaman 404 yang kami terima akan ditolak dan loader akan lanjut ke build berikutnya. Error itu bukan jebakan untuk peneliti. Servernya memang belum siap.

Di lab kami, loader mengambil akuma_x64, bot untuk PC dan server 64-bit. Belum ada yang mengunggahnya ke MalwareBazaar, perpustakaan malware publik, jadi kami yang mengunggahnya.

Bot menghubungi markasnya

Setelah berjalan, bot menyalin dirinya ke /var/tmp/systemd-network-helper, nama yang dipilih agar terlihat seperti bagian dari pengelola layanan Linux. Bot itu juga membawa file layanan siap pakai dengan nama yang sama, ditambah skrip startup untuk router dan perangkat Android, supaya bisa hidup kembali setelah reboot.

Lalu ia mencoba menghubungi server perintahnya: mesin yang sama, 85.137.53[.]167, tetapi di port 25565. Bot lama yang kami tulis sebelumnya memakai port 3169. Port 25565 adalah port bawaan server Minecraft, pilihan yang mungkin membantu lalu lintasnya berbaur di jaringan tempat orang bermain game.

Kami membiarkan bot menjangkau satu alamat itu selama lima menit. Server langsung menerima koneksinya. Bot memperkenalkan diri dengan jenis prosesornya dan sebuah label, telnet.akuma, yang memberi tahu operator lewat jalur mana bot itu masuk. Setelah itu kedua pihak bertukar pesan dua byte "masih di sini" setiap menit. Tidak ada perintah serangan selama kami amati, jadi kami tidak bisa mengatakan untuk apa botnet ini sedang dipakai.

Skrip yang familiar

Untuk membantu pihak lain mendeteksi loader ini, kami menulis aturan YARA dan menjalankannya pada semua yang pernah dikumpulkan honeypot kami. Hasilnya cocok dengan dua file: loader ini, dan satu yang kami tangkap pada 4 Oktober dari server lain, 143.20.154[.]42.

Kedua skrip itu memakai templat yang sama: struktur sama, pemeriksaan 4 KB sama, pesan error sama, dengan nama bot yang diganti dan beberapa jenis prosesor tambahan. Keduanya juga dikirim oleh kelompok mesin Microsoft Azure yang sama, yang menjalankan skrip dengan kata telnet sebagai argumennya. Namun bot di balik skrip 4 Oktober adalah program yang berbeda dan jauh lebih kecil, dengan server perintahnya sendiri.

Bacaan kami: satu operator, atau satu kit yang berpindah tangan, mempertahankan loader dan mesin penyebarnya lalu mengganti bot-nya. Dari yang kami lihat, kami belum bisa memastikan yang mana.

Pembaruan 12 Oktober: server pindah ke balik terowongan

Sehari setelah tulisan ini terbit, build bot-nya berubah. Server itu kini membagikan build terpisah untuk tiga jalur, Telnet, Android dan satu jalur baru untuk perekam video (DVR), dan sering membangunnya ulang.

Kami menjalankan build terbaru di lab kami. Build itu tidak lagi menghubungi 85.137.53[.]167 sama sekali. Sebagai gantinya, bot terhubung ke 5.tcp.eu[.]ngrok[.]io di port 16747. ngrok adalah layanan terowongan yang sah: operator menjalankan program kecil di samping server aslinya, dan server bersama milik ngrok meneruskan koneksi ke sana. Alamat server aslinya tetap tersembunyi.

Kami membiarkan satu bot menjangkau terowongan itu selama lima menit. ngrok menerimanya, dan bot memperkenalkan diri sebagai akuma.dvr, jadi labelnya kini menyebut nama jalurnya. Server di balik terowongan tidak menjawab saat itu.

Artinya dalam praktik: memblokir 85.137.53[.]167 tidak lagi memutus bot-bot ini. Jangan juga memblokir alamat ngrok, karena ribuan pengguna sah memakainya bersama. Awasi koneksi keluar ke terowongan TCP ngrok di port 16747, dan pertimbangkan apakah jaringan Anda memang perlu menjangkau terowongan ngrok. Aturan deteksi kami di GitHub sudah diperbarui untuk label baru dan terowongan ini.

Apa yang bisa dilakukan tim keamanan

• Tutup Telnet dan ganti kata sandi bawaan pabrik. Setiap langkah di sini dimulai dari login Telnet dengan kata sandi yang sudah publik selama sepuluh tahun.

• Cari penyamarannya. File di /var/tmp/systemd-network-helper, atau layanan bernama systemd-network-helper.service, bukan bagian dari Linux. Anggap perangkat itu sudah terinfeksi.

• Blokir servernya. 85.137.53[.]167 (semua port, terutama 3169, 24380 dan 25565), 143.20.154[.]42 dan 91.92.47[.]97.

• Pakai aturannya. Kami menerbitkan aturan YARA untuk loader dan bot, aturan Suricata untuk check-in bot, dan aturan Sigma untuk file yang ditinggalkannya. Aturan YARA itu tidak cocok dengan file lain dari sekitar 92.000 tangkapan honeypot dan 142 sampel malware IoT terbaru.

Indikator utama

Semua indikator, dalam bentuk defanged, ada di iocs.csv temuan ini. Tulisan teknis lengkapnya memuat linimasa, perbandingan kedua loader, byte check-in dan aturan deteksinya.

Cara kami bekerja

KSI Digital menjalankan umpan WordPress dan honeypot SSH/Telnet Cowrie yang merekam serangan dan menyimpan file yang diunduh penyerang. Kami menganalisis sampel di lab terisolasi yang secara bawaan offline. Saat pemeriksaan live diperlukan, hanya tujuan yang kami tentukan yang bisa dijangkau, selama beberapa menit, dan semua upaya lain dari sampel diblokir. Kami menerbitkan temuan di halaman riset kami dan di GitHub dengan lisensi CC BY 4.0, serta melaporkan server ke feed ancaman publik dan ke penyedia yang meng-hosting-nya.