Rootkit eBPF di Linux: Ketika Malware Bersembunyi di Dalam Kernel Tanpa Memuat Modul, Serta Panduan Forensik dan Deteksi untuk Tim IT Indonesia

Server Linux adalah tulang punggung hampir semua infrastruktur digital di Indonesia, mulai dari aplikasi perbankan, layanan pemerintah, platform e-commerce, hingga kluster container. Karena itu, para pembela biasanya berinvestasi pada pengerasan kernel: menandatangani modul, mengaktifkan kernel lockdown, dan memantau pemuatan Loadable Kernel Module (LKM). Masalahnya, ada kelas rootkit yang tidak memerlukan LKM sama sekali. Rootkit berbasis eBPF menumpang pada fitur resmi kernel untuk menyembunyikan proses, memanipulasi data yang dibaca aplikasi, bahkan mengelabui alat pemeriksa. Artikel ini membahas cara kerjanya dan, yang lebih penting, bagaimana tim IT dan forensik digital di Indonesia dapat mendeteksinya.

Mengapa eBPF menarik bagi penyerang

eBPF (extended Berkeley Packet Filter) adalah mekanisme di kernel Linux yang memungkinkan program kecil dijalankan secara aman di dalam kernel tanpa mengubah kode kernel atau memuat modul. Teknologi ini dipakai luas untuk observabilitas, jaringan, dan keamanan, sehingga keberadaannya di server produksi adalah hal yang wajar. Justru di situlah letak masalahnya: kemampuan yang sama yang membuat eBPF berguna bagi pembela juga berguna bagi penyerang.

Menurut analisis teknis yang dirangkum Forensic Focus pada 12 Oktober 2026, rootkit eBPF dapat menyembunyikan proses dan menaikkan hak akses tanpa memodifikasi tabel syscall. Hal ini membuat detektor yang dirancang untuk mencari rootkit berbasis LKM menjadi kurang efektif. Datadog Security Labs, dalam publikasi 27 Juli 2026, juga membahas bagaimana rootkit seperti VoidLink, LinkPro, dan Atomic Arch menyalahgunakan helper eBPF untuk bersembunyi, dan menekankan pentingnya mendeteksinya pada saat program dimuat, sebelum sempat beraksi.

Anatomi teknik: titik kait, helper, dan peta

Titik kait (attach point)

Program eBPF dipasang pada titik tertentu di kernel. Contoh yang umum adalah tracepoint pada pemanggilan sistem seperti getdents64 (pembacaan isi direktori), openat, dan read. Jenis lain yang tersedia antara lain kprobe/kretprobe, uprobe, XDP, tc, dan BPF-LSM. Seluruhnya sah digunakan oleh produk observabilitas, tetapi juga dapat disalahgunakan.

Helper yang berbahaya

Program eBPF tidak bebas melakukan apa saja; ia hanya boleh memanggil fungsi bantu (helper) yang disediakan kernel. Beberapa helper menjadi sorotan dalam analisis rootkit:

• bpf_probe_write_user() menulis ke memori ruang pengguna. Penyerang memakainya untuk mengubah buffer yang akan dibaca aplikasi, misalnya menghapus entri tertentu dari daftar direktori atau mengubah isi yang terbaca dari sebuah berkas.
• bpf_override_return memaksa nilai kembalian tertentu. Analisis yang dirujuk menyebut kemampuan ini dapat dipakai untuk menyembunyikan aktivitas bahkan dari bpftool.
• bpf_send_signal mengirim sinyal dari dalam kernel, yang dapat dipakai untuk mematikan alat penelusur seperti strace.

Peta dan pinning

Keadaan program eBPF disimpan dalam map, bukan di memori kernel biasa. Dengan pinning ke /sys/fs/bpf, program, peta, dan tautan dapat tetap hidup meskipun proses pemuatnya sudah berhenti. Persistensi ini hanya berlaku selama sistem belum dihidupkan ulang; agar bertahan setelah reboot, penyerang perlu meninggalkan artefak pemuat ulang, misalnya unit systemd dengan nama yang dibuat tampak wajar seperti "System Telemetry Helper".

Contoh konkret: modul dalam bad-bpf

Untuk memahami dampaknya, proyek riset terbuka bad-bpf sering dipakai sebagai rujukan edukatif. Beberapa modulnya menggambarkan pola serangan yang realistis:

• pidhide menyembunyikan PID dari ps, pgrep, dan daftar /proc dengan mengait getdents64.
• sudoadd memberi hak sudo tanpa kata sandi dengan menulis ulang buffer yang dibaca dari /etc/sudoers, sehingga berkasnya sendiri tidak berubah.
• textreplace mengganti teks pada berkas virtual di /proc dan /sys.
• exechijack, writeblocker, dan bpfdos masing-masing membajak execve, menjatuhkan operasi tulis secara diam-diam, dan mematikan pengguna ptrace.

Poin pentingnya: banyak manipulasi terjadi pada data yang dibaca aplikasi, bukan pada berkas di disk. Karena itu pemeriksaan integritas berkas biasa bisa tampak bersih padahal perilaku sistem sudah menyimpang.

Panduan deteksi dan forensik

1. Ambil snapshot status BPF dan bandingkan dengan baseline

Bagi tim yang menjalankan incident response di Linux, langkah paling praktis adalah mengenumerasi apa yang sedang dimuat di kernel, lalu membandingkannya dengan kondisi bersih yang sudah didokumentasikan.

sudo bpftool prog show -j > prog_$(hostname)_$(date +%F).json
sudo bpftool link show -j > link_$(hostname)_$(date +%F).json
sudo bpftool map show  -j > map_$(hostname)_$(date +%F).json
sudo find /sys/fs/bpf -type f

Bandingkan program berdasarkan tag-nya, bukan ID, karena ID berubah pada setiap pemuatan. Curigai program yang menempel pada getdents64, read, openat, atau panggilan bpf itu sendiri, serta program yang masih berjalan tanpa proses pemilik yang jelas.

2. Bedah instruksi program yang mencurigakan

sudo bpftool prog dump xlated id <ID> | grep -E "probe_write_user|override_return|send_signal"

Kemunculan helper tersebut pada program yang tidak dikenal merupakan indikator kuat yang perlu ditindaklanjuti, walaupun beberapa alat pemantauan dan debugging yang sah juga dapat memakainya. Selalu verifikasi asal-usul program sebelum menyimpulkan.

3. Cari ketidaksesuaian perilaku

• Proses tidak muncul di ps tetapi direktori /proc/<pid> masih dapat diakses langsung.
• Hak sudo berlaku padahal /etc/sudoers tidak berubah (periksa dengan sha256sum dan bandingkan hasilnya).
• Koneksi pada ss yang tidak memiliki proses pemilik.

4. Pantau pemuatan, bukan hanya hasilnya

Audit panggilan bpf() dan beri peringatan jika pemuat berasal dari induk proses di luar baseline, misalnya shell interaktif atau sesi pasca-eksploitasi. Perhatikan juga operasi BPF_OBJ_PIN dan jalur di bawah /sys/fs/bpf. Elastic menyediakan aturan deteksi bawaan yang membaca pesan syslog kernel yang menyebut bpf_probe_write_user (dipetakan ke MITRE ATT&CK T1014 Rootkit dan T1547.006), dengan catatan potensi false positive dari alat debugging dan keamanan yang sah.

5. Jangan lupakan jejak persistensi

Karena program eBPF hilang saat reboot kecuali ada pemuat ulang, pantau perubahan pada /etc/systemd/system, /etc/cron.d, dan /etc/rc.local, serta tinjau unit layanan baru dengan nama yang terlalu "ramah". Periksa pula /proc/sys/kernel/tainted dan dmesg sebagai pembanding untuk kasus LKM.

Pertimbangan forensik

Memori dan keadaan kernel adalah bukti yang mudah hilang. Jika dugaan rootkit eBPF muncul, dokumentasikan keluaran bpftool sebelum mematikan atau mem-reboot mesin, hitung hash seluruh hasil ekspor, dan catat siapa yang mengambilnya serta kapan. Pertahankan rantai penguasaan barang bukti (chain of custody) agar temuan tetap dapat dipertanggungjawabkan, baik untuk investigasi internal maupun proses hukum. Ingat bahwa jika pemeriksaan dilakukan langsung pada host yang sudah dikompromikan, hasil perintah itu sendiri bisa dimanipulasi oleh rootkit; bila memungkinkan, ambil citra disk dan memori lalu analisis secara offline. Standar seperti ISO/IEC 27037 (identifikasi, pengumpulan, dan preservasi bukti digital) dapat menjadi acuan prosedur.

Pengerasan: batasi siapa yang boleh memuat program BPF

• Pemuatan program eBPF memerlukan CAP_BPF atau CAP_SYS_ADMIN. Batasi capability ini, terutama pada container; hindari kontainer privileged.
• Tetapkan daftar pemuat yang dikenal berdasarkan jalur eksekusi, dan beri peringatan untuk yang lain.
• Pahami keterbatasan: penandatanganan modul dan kernel lockdown menahan LKM yang tidak bertanda tangan, tetapi tidak otomatis menghentikan eBPF, sehingga kontrol tambahan diperlukan.
• Sentralisasi log audit ke SIEM di luar host agar penyerang tidak mudah menghapus jejak.

Konteks hukum dan tata kelola di Indonesia

Insiden semacam ini bukan sekadar masalah teknis. Bagi penyelenggara sistem elektronik yang memproses data pribadi, kompromi pada server dapat berimplikasi pada kewajiban pelindungan data berdasarkan UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi, termasuk penanganan dan pelaporan kegagalan pelindungan data. Pemberitaan terbaru juga menyoroti penguatan pengawasan keamanan siber dan pelindungan data di sektor publik, meskipun rincian aturannya perlu diverifikasi langsung pada sumber hukum resmi. Di sisi lain, praktik forensik dan pengujian harus tetap berada dalam batas hukum: lakukan hanya pada sistem yang Anda miliki atau berwenang untuk menelitinya, dan perhatikan ketentuan UU ITE tentang akses tanpa hak.

Penutup

Rootkit eBPF mengingatkan kita bahwa "tidak ada modul mencurigakan" tidak sama dengan "kernel aman". Pertahanan yang efektif menggabungkan tiga hal: visibilitas atas apa yang dimuat ke kernel, baseline yang terdokumentasi, dan prosedur forensik yang disiplin. Mulailah dari yang sederhana: jalankan bpftool pada server kritis hari ini, simpan hasilnya sebagai baseline, dan jadikan perbedaan di masa depan sebagai sinyal untuk diselidiki. Tim Siberindo siap membantu organisasi Anda menyusun baseline, aturan deteksi, dan alur respons insiden untuk lingkungan Linux dan container.

Sumber rujukan: Forensic Focus DFIR News (12 Oktober 2026), analisis eBPF rootkit oleh bloo.io, Datadog Security Labs (27 Juli 2026), dokumentasi aturan deteksi Elastic Security.