Botnet Mirai yang menyembunyikan servernya di DNS biasa

Botnet harus memberi tahu bot-botnya ke mana mereka melapor, dan alamat itulah titik lemahnya. Kalau sebuah IP ditanam di dalam binary, siapa pun yang menjalankan sampelnya akan menemukannya, mencatatnya, lalu membuatnya diturunkan. Kit Mirai yang kami tangkap pada 9 Oktober 2026 tidak melakukan itu. Bot-botnya mencari sebuah nama domain, tetapi alamat di jawaban DNS juga bukan servernya. Itu adalah alamat server yang diacak dengan kunci tetap. Sandbox yang menjalankan bot ini hanya melihat domainnya, tanpa petunjuk lain menuju server.

Kami memecahkan kuncinya tanpa menghubungi apa pun, mencocokkannya dengan record DNS yang aktif, lalu membiarkan bot menjangkau dua server hasil dekodenya selama beberapa menit di lab terisolasi kami. Kedua server itu belum ada di feed publik mana pun. Sekarang keduanya sudah tercatat di ThreatFox, dan kami telah melaporkannya ke penyedia hosting serta melaporkan domainnya ke registrar.

Cara bot ini sampai ke honeypot kami

Pada 9 Oktober 2026 pukul 18.07 UTC, sebuah mesin di 45.90.163[.]37 login ke honeypot Telnet Cowrie kami dengan kata sandi bawaan admin, lalu menyalurkan sebuah skrip kecil dari 176.65.139[.]40 ke shell. Skrip itu mengunduh sebelas build dari bot yang sama, satu untuk setiap jenis prosesor yang mungkin ada di router, kamera, atau server, lalu menjalankan masing-masing. Ini cara penyebaran Mirai yang khas: penyerang tidak tahu perangkat apa yang berhasil dimasukinya, jadi semua dicoba.

Honeypot kami mencatat apa yang diunduh penyerang tetapi tidak menjalankannya. Build-build tersebut sudah ada di MalwareBazaar, dikumpulkan oleh abuse.ch dari server yang sama, jadi kami mengambilnya dari sana alih-alih menyentuh mesin milik penyerang.

Bot yang mengabaikan jawaban DNS-nya sendiri

Lab kami menjalankan sampel secara offline. Setiap pencarian DNS dijawab dengan alamat lokal, sehingga bot yang mencari servernya akan membocorkan nama itu, dan saat ia mencoba terhubung kami bisa melihat tujuannya.

Bot ini berperilaku aneh. Ia memindai internet untuk mencari perangkat Telnet lain yang bisa diinfeksi, dan itu wajar untuk Mirai. Ia mencari seris[.]gd berulang kali, lebih dari sekali per detik, dan domain kedua, myrepis[.]gd, satu kali. Namun ia tidak pernah terhubung ke alamat yang diberikan. Bot yang terus bertanya tetapi tidak pernah memakai jawabannya biasanya berarti jawaban itu diolah dulu sebelum dipakai, dan alamat lokal kami berubah menjadi sesuatu yang ditolak bot.

Memecahkan kuncinya

Jadi kami hanya mengubah jawabannya. Ketika seris[.]gd diarahkan ke 198.51.100.77, alamat khusus dokumentasi yang tidak mungkin ada di internet, bot mencoba terhubung ke 33.67.234.20. Ketika diarahkan ke 203.0.113.1, bot menuju 44.112.255.88. Bandingkan angkanya byte demi byte, dan kedua pasangan itu berbeda dengan kunci yang sama: XOR dengan E7.70.8E.59. Build MIPS melakukan hal yang persis sama, jadi kuncinya tidak bergantung pada jenis perangkat.

Lalu kami melihat record aslinya melalui DNS publik:

Baris terakhir memastikannya. Domain cadangan didekode menjadi 176.65.139[.]40, server yang sama dengan asal skrip serangan tadi. Angka acak tidak akan menghasilkan itu.

Konfirmasi secara live

Selama beberapa menit kami membiarkan bot hanya menjangkau dua alamat hasil dekode itu, dengan semua tujuan lain diblokir. Kedua server menjawab. Yang pertama, 159.65.67[.]52, menerima bot pada 10 Oktober pukul 01.58 UTC dan mempertahankan koneksinya sekitar tiga menit sementara bot melapor setiap 30 detik. Yang kedua, 206.189.164[.]5, melakukan hal yang sama pada pukul 02.22 UTC. Tidak ada yang mengirim perintah selama kami amati, jadi kami tidak bisa menyimpulkan untuk apa botnet ini sedang dipakai. Setiap koneksi memakai port acak yang berbeda, jadi yang perlu diblokir adalah alamat server, bukan port.

Mengapa ini penting

Sebagian besar sandbox otomatis menjawab DNS dengan alamat lokal palsu, sama seperti lab kami secara bawaan. Untuk kit ini, sandbox semacam itu hanya akan melaporkan sebuah domain dan pemindaian Telnet, tanpa alamat server sama sekali. Sandbox dengan DNS sungguhan sedikit lebih baik, tetapi yang terlihat adalah koneksi ke alamat yang tidak pernah muncul di jawaban DNS mana pun, dan itu mudah disalahartikan sebagai pemindaian atau umpan.

Ini juga mengubah apa yang layak diblokir. Tidak ada yang pernah terhubung ke alamat yang dipublikasikan di DNS, jadi memblokirnya tidak ada gunanya. Memblokir nama domainnya berhasil, begitu pula memblokir server hasil dekode. Dan karena memindahkan botnet ini cukup dengan mengubah DNS, siapa pun yang memantaunya bisa memeriksa kedua domain itu, menerapkan kuncinya, dan melihat lokasi server terkini tanpa menjalankan malware lagi.

Apa yang bisa dilakukan tim keamanan

• Blokir domain dan server hasil dekode. Tambahkan seris[.]gd dan myrepis[.]gd ke daftar blokir DNS, serta 159.65.67[.]52 dan 206.189.164[.]5 ke daftar blokir firewall. Jangan mengandalkan record A-nya.

• Tutup Telnet. Bot ini masuk lewat Telnet dengan kata sandi bawaan. Router atau kamera yang membuka Telnet ke internet akan ditemukan dalam hitungan jam. Matikan atau pasang firewall, dan ganti kata sandi bawaan.

• Pantau pencarian DNS-nya. Perangkat di jaringan Anda yang mencari seris[.]gd atau myrepis[.]gd sudah terinfeksi.

• Perhatikan DNS sandbox Anda. Jika Anda menganalisis malware IoT, bot yang mencari domainnya tetapi tidak pernah terhubung adalah tanda untuk mencoba mengubah jawaban DNS sebelum menyimpulkan sampelnya mati.

Indikator utama

Semua hash, dalam bentuk defanged, ada di iocs.csv temuan ini, bersama laporan teknis lengkapnya.

Cara kami bekerja

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