Cara Memilih Titik Restore yang Bersih Setelah Server cPanel Dibobol

Setelah server cPanel dibobol, refleks pertama biasanya sederhana: ambil backup terbaru, restore, beres. Masalahnya, backup terbaru justru yang paling besar kemungkinannya ikut tercemar. Kalau penyerang masuk lewat celah seperti CVE-2026-41940 beberapa hari sebelum ada yang sadar, setiap backup yang jalan di rentang itu ikut menyimpan apa pun yang mereka tinggalkan. Jadi pertanyaan yang benar bukan "backup mana yang paling baru", tapi "backup mana yang dibuat sebelum penyerang pertama kali masuk".

Kenapa backup terakhir belum tentu aman

Ambil contoh sederhana. Server menjalankan backup harian otomatis tiap dini hari. Penyerang berhasil masuk hari Senin siang, lalu membuat akun tersembunyi, memasang cron job (tugas terjadwal yang jalan otomatis), dan menyisipkan beberapa file PHP di folder upload. Rabu, situs mulai redirect ke halaman aneh. Kamis, baru ada yang komplain dan masalahnya ketahuan. Backup Selasa, Rabu, dan Kamis semuanya sudah memuat backdoor itu. Backup Senin dini hari kemungkinan besar bersih, karena dibuat sebelum penyerang masuk. Kalau kita restore backup Rabu karena "itu sebelum situs redirect", kita cuma mengembalikan server ke kondisi saat penyerang sudah duduk manis di dalam, tinggal menunggu mereka aktif lagi. Intinya ada dua tanggal yang sering tercampur: kapan penyerang masuk, dan kapan masalahnya ketahuan. Titik restore dipilih berdasarkan tanggal pertama. Jarak antara keduanya bisa beberapa jam, bisa juga berminggu-minggu, tergantung seberapa lama penyerang memilih diam. Perlu diingat juga, sistem backup tidak menilai isi. Ia menyalin apa adanya. File backdoor, cron jahat, atau user admin palsu di database akan ikut tersimpan dengan rapi, lengkap dengan tanggal backup yang terlihat meyakinkan. Di meja support, ini salah satu hal yang paling sering perlu dijelaskan ke pemilik situs. Permintaan "restore backup kemarin saja" masuk akal dari sudut pandang mereka, tapi kemarin belum tentu sebelum penyerang masuk.

Menentukan waktu kompromi dari log cPanel

Menurut informasi yang beredar, CVE-2026-41940 adalah celah authentication bypass dengan skor CVSS 9.8 yang sudah dieksploitasi di lapangan. Penyerang yang tidak punya kredensial bisa melewati proses login. Konsekuensinya penting buat investigasi: jangan berharap menemukan ratusan percobaan login gagal sebelum akses berhasil. Yang lebih mungkin terlihat adalah sesi yang valid dari IP yang tidak dikenal, langsung melakukan hal-hal yang biasanya hanya dilakukan admin. Log cPanel dan WHM ada di /usr/local/cpanel/logs/. Beberapa file yang biasanya relevan:

login_log mencatat percobaan login ke cPanel, WHM, dan webmail.
session_log mencatat pembuatan dan penutupan sesi.
access_log mencatat request ke cpsrvd, yaitu layanan yang melayani antarmuka cPanel dan WHM.

Yang kita cari adalah jejak paling awal: sesi root atau reseller dari IP asing, pembuatan akun baru yang tidak dikenali, perubahan password, atau akses ke fitur cron dan file manager di jam yang tidak wajar. Begitu satu IP mencurigakan ketemu, telusuri mundur. IP itu muncul pertama kali kapan? Apakah ada IP lain dengan pola yang mirip di hari-hari sebelumnya? Beberapa hal yang bikin langkah ini lebih rumit dari kelihatannya: Pertama, log dirotasi. Kalau jejak paling awal ternyata sudah lewat masa simpan log, kita tidak bisa memastikan kapan penyerang masuk. Dalam kondisi begitu, anggap saja waktunya lebih awal dari yang terlihat, lalu pilih backup secara konservatif. Kedua, penyerang yang sudah punya akses root bisa mengedit atau menghapus log. Tidak ada jejak bukan berarti tidak ada aktivitas. Cocokkan dengan sumber lain, misalnya log SSH di /var/log/secure atau /var/log/auth.log (tergantung distro) dan waktu modifikasi file mencurigakan. Ingat juga, waktu modifikasi file bisa dipalsukan dengan mudah, jadi jangan dijadikan satu-satunya patokan. Ketiga, perhatikan zona waktu. Log, jadwal backup, dan laporan dari pelanggan bisa memakai zona waktu yang berbeda. Selisih beberapa jam cukup untuk membuat kita salah memilih backup. Begitu batas waktu paling awal sudah ketemu, beri jarak aman. Penyerang sering melakukan probing atau pengujian sebelum aktivitas yang jelas terlihat. Backup yang dibuat beberapa hari sebelum jejak pertama biasanya lebih bisa dipercaya daripada backup yang dibuat beberapa jam sebelumnya. Berikut contoh pemeriksaan read-only. IP, tanggal, dan path di bawah hanya contoh, jadi sesuaikan dengan server kamu:

BASH

# 1) Cari aktivitas dari IP mencurigakan di log cPanel (read-only)
#    203.0.113.10 hanya contoh IP
grep -h '203.0.113.10' /usr/local/cpanel/logs/login_log /usr/local/cpanel/logs/session_log | head -n 20

# 2) Lihat daftar isi backup akun beserta waktu modifikasi file, tanpa mengekstrak
#    Path backup tergantung pengaturan di WHM Backup Configuration
tar -tvf /backup/2026-10-05/accounts/namaakun.tar.gz | grep -E 'cron|authorized_keys|\.php$' | less

Perintah kedua berlaku untuk backup berbentuk arsip. Kalau backup kamu bertipe uncompressed atau incremental, isinya berupa folder biasa, jadi cukup telusuri foldernya langsung.

Memeriksa isi backup sebelum dipercaya

Tanggal pada nama folder backup cuma menunjukkan kapan backup itu jalan. Isinya tetap harus dicek. Ada beberapa tempat yang paling sering dipakai penyerang untuk bertahan di level akun:

Cron job milik akun. Di arsip backup akun, crontab biasanya tersimpan di folder terpisah. Cari perintah yang mengunduh sesuatu dari luar atau menjalankan file PHP dari lokasi yang aneh.
File PHP baru di tempat yang tidak seharusnya, misalnya folder upload WordPress atau folder cache.
.ssh/authorized_keys di home directory akun. Satu baris kunci tambahan cukup untuk memberi akses SSH tanpa password.
File .htaccess dengan rewrite rule yang disuntikkan. Pembahasan lengkapnya ada di Auditing .htaccess Files for Injected Redirects After a cPanel Server Compromise.
Database. Dump SQL di dalam backup bisa saja sudah berisi user admin WordPress baru atau opsi yang diubah. Cara paling aman untuk memeriksanya adalah me-restore dump ke database sementara, lalu cek tabel user-nya. Jangan restore langsung ke database produksi.

Cara praktis untuk menemukan perubahan adalah membandingkan dua backup: kandidat titik restore dan satu backup yang lebih tua. Kalau ada file yang muncul di backup baru tapi tidak ada di backup lama, dan tidak ada alasan jelas kenapa file itu ditambahkan, itu kandidat kuat untuk diperiksa. Kalau perlu mengekstrak, lakukan di folder terpisah yang tidak dilayani web server, jangan di atas file live. Ada batasan penting yang sering terlewat. Backup per akun hanya berisi data akun. Persistensi di level sistem tidak ikut di dalamnya, misalnya crontab root, kunci SSH root, binary sistem yang diganti, atau library yang dimuat lewat /etc/ld.so.preload. Untuk yang terakhir, ada pembahasan di Checking /etc/ld.so.preload to Confirm Hidden Malware Processes. Celah yang memberi akses ke WHM berarti penyerang berpotensi punya akses root. Jadi backup akun yang bersih sekalipun tidak membersihkan server tempat backup itu di-restore.

Kesalahan yang sering terjadi

Kesalahan paling umum adalah memilih backup sehari sebelum masalah terlihat, bukan sebelum penyerang masuk. Polanya selalu sama: situs sempat terlihat normal, lalu beberapa hari kemudian backdoor-nya aktif lagi. Yang kedua, hanya memeriksa file web. Cron job dan database sama pentingnya. User admin palsu di database tidak akan ketahuan hanya dengan memindai folder public_html. Yang ketiga, me-restore backup bersih ke server yang belum di-patch atau masih terkompromi. Celahnya masih terbuka, persistensi di level sistem masih ada, dan penyerang bisa masuk lagi dengan cara yang sama. Kalau ada indikasi akses root, pendekatan yang lebih aman biasanya adalah menyiapkan server baru yang sudah di-patch, lalu me-restore backup akun yang sudah diperiksa ke sana. Yang keempat, lupa mengganti kredensial. Backup yang bersih tetap menyimpan password lama, dan password lama itu mungkin sudah bocor. Setelah restore, ganti password cPanel, password database, API token, dan kunci SSH. Pemilik situs juga perlu mengganti password admin aplikasinya. Yang kelima, tidak menghitung data yang hilang. Restore ke backup yang lebih lama berarti pesanan, komentar, atau posting setelah tanggal itu ikut hilang. Kalau datanya penting, ada kompromi yang bisa diambil: kembalikan kode dan file dari backup bersih, lalu ambil data konten terbaru dari database setelah diperiksa dengan teliti. Cara ini lebih repot, dan risikonya tergantung seberapa teliti pemeriksaan databasenya. Keputusannya perlu dibicarakan dengan pemilik situs, bukan diputuskan diam-diam.

Urutan kerja yang masuk akal

Urutannya kira-kira begini. Cari jejak masuk paling awal di log /usr/local/cpanel/logs/ dan cocokkan dengan sumber lain. Tentukan batas waktunya, lalu mundur sedikit sebagai jarak aman. Periksa isi backup kandidat, termasuk cron, kunci SSH, file baru, dan database. Restore ke server yang sudah di-patch, lalu ganti semua kredensial. Kalau ada langkah yang tidak bisa dipastikan, misalnya log sudah dirotasi atau ada indikasi log diedit, pilih backup yang lebih tua. Kehilangan data beberapa hari memang tidak enak, tapi masih lebih mudah ditangani daripada membersihkan server yang sama dua kali.