PHP2Shell: Deteksi Tanda Kompromi dan Respons Insiden

Setelah kabar PHP2Shell, pertanyaan penting bagi administrator adalah apakah server sudah diperbarui dan apakah ada aktivitas yang perlu diselidiki. CVE-2026-109618 dan CVE-2026-109619 adalah kerentanan pada inti PHP; mengecek versi membantu menilai paparan, sementara pemeriksaan log dan host diperlukan untuk menilai kemungkinan kompromi.

Kenali batas pemeriksaan log

Log akses HTTP dapat menunjukkan lonjakan permintaan tidak biasa, pola pemindaian, atau permintaan ke endpoint yang semestinya jarang diakses. Log error PHP dan server web dapat membantu menghubungkan waktu permintaan dengan crash atau kesalahan. Namun, satu alamat IP atau satu baris log tidak cukup untuk memastikan eksploitasi. Penyerang dapat memakai alamat perantara, dan log dapat tidak lengkap.

Periksa rentang waktu sejak server pertama kali menjalankan versi yang terdampak hingga patch aktif. Korelasikan log web dengan log autentikasi, proses sistem, perubahan berkas, koneksi jaringan keluar, dan aktivitas akun layanan. Simpan salinan log secara aman sebelum rotasi atau pembersihan otomatis menghapusnya.

Indikator yang layak ditinjau

• Perubahan tak terjadwal pada berkas aplikasi, konfigurasi, atau direktori upload.
• Proses baru atau proses anak yang tidak sesuai dengan pola kerja layanan web.
• Koneksi keluar menuju host yang tidak dikenal, terutama setelah permintaan web anomali.
• Akun, kunci SSH, tugas cron, atau konfigurasi layanan yang muncul tanpa perubahan terotorisasi.
• Lonjakan error atau restart PHP-FPM yang bertepatan dengan aktivitas permintaan mencurigakan.

Indikator tersebut bukan bukti tunggal dan bisa memiliki penyebab sah. Bandingkan dengan baseline, perubahan rilis, dan aktivitas tim.

Jika ada tanda kompromi

1. Aktifkan prosedur respons insiden organisasi dan catat waktu serta tindakan yang diambil.
2. Batasi akses jaringan host yang dicurigai agar aktivitas tidak berlanjut, dengan mempertimbangkan kebutuhan menjaga bukti.
3. Ambil snapshot atau salinan forensik sesuai kebijakan, lalu lindungi log dan bukti dari perubahan.
4. Perbarui PHP dan komponen terkait dari sumber tepercaya; jangan sekadar menghapus berkas mencurigakan lalu menganggap host bersih.
5. Rotasi kata sandi, token, dan kunci yang dapat diakses proses PHP dari lingkungan yang dipercaya.
6. Bangun ulang host dari image bersih jika integritas sistem tidak dapat dipastikan, kemudian pantau lebih ketat.

Pencegahan setelah insiden

Batasi hak akses akun layanan web, segmentasikan server, tinjau rahasia yang tersedia untuk aplikasi, dan pastikan log terpusat. Catat versi PHP untuk semua lingkungan dan jadwalkan pemeriksaan advisori keamanan. WAF dan deteksi runtime berguna sebagai lapisan tambahan, tetapi tidak menjamin host yang sudah disusupi kembali bersih.

Mulai dengan checklist pemeriksaan dan pembaruan PHP2Shell. Jika server masih menjalankan versi terdampak, prioritaskan patch sebelum investigasi rutin lainnya.

Rujukan: Advisori keamanan resmi PHP, 21 Oktober 2026.

Susun garis waktu paparan

Mulailah dengan menentukan rentang waktu ketika runtime terdampak aktif dan dapat menerima permintaan. Gabungkan catatan inventaris versi, tanggal pembaruan paket, waktu restart worker, perubahan konfigurasi, serta jadwal retensi log. Catat zona waktu setiap sumber log sebelum membandingkan waktu; perbedaan UTC dan waktu lokal sering membuat urutan peristiwa tampak keliru.

Identifikasi juga jalur masuk: domain publik, API, endpoint unggah, panel admin, reverse proxy, dan layanan internal yang menerima trafik dari jaringan lain. PHP bisa dijalankan dengan beberapa handler di satu organisasi. Jangan membatasi pencarian hanya pada server produksi utama; staging, server lama, worker, dan container yang tidak aktif dalam deployment rutin juga perlu dicatat.

Bagaimana meninjau log secara terarah?

Mulai dari log reverse proxy atau web server untuk melihat waktu, host, metode, status, ukuran permintaan, user agent, dan alamat sumber. Cari pola trafik yang tidak sesuai baseline, lonjakan error, permintaan yang berulang, atau aktivitas pada endpoint yang biasanya jarang digunakan. Setelah menemukan rentang waktu yang menarik, korelasikan dengan log PHP-FPM, log sistem, autentikasi, DNS, firewall, serta telemetri endpoint atau cloud.

Jangan mengandalkan satu indikator sederhana seperti HTTP 500 atau user agent tertentu. Kegagalan aplikasi normal dapat menghasilkan error serupa, sementara permintaan berbahaya dapat tampak seperti trafik web biasa. Log akses juga mungkin tidak merekam seluruh badan permintaan atau detail internal runtime. Periksa apakah logging berubah, berhenti, terhapus, atau tidak mencakup jalur yang digunakan.

Periksa host dan akun layanan

• Bandingkan berkas aplikasi dan konfigurasi dengan artefak rilis tepercaya atau repositori versi.
• Periksa berkas baru atau berubah di direktori aplikasi, upload, cache, temporary, dan konfigurasi server.
• Tinjau proses yang berjalan, proses anak dari PHP/web server, koneksi jaringan, dan penggunaan sumber daya yang tidak biasa.
• Audit akun sistem, kunci SSH, tugas cron, unit layanan, token deployment, serta kredensial aplikasi yang dapat diakses akun PHP.
• Periksa perubahan aturan firewall, DNS, proxy, dan konfigurasi penyedia cloud yang terjadi pada rentang waktu paparan.

Gunakan baseline dan pembanding dari sistem sejenis. Berkas baru atau proses yang terlihat asing belum otomatis berbahaya; deployment, backup, dan pemantauan juga menghasilkan perubahan. Catat siapa yang meninjau dan bukti yang mendukung keputusan.

Alur respons ketika ada indikator kuat

1. Aktifkan penanggung jawab insiden. Tetapkan kanal koordinasi, pemilik teknis, pencatat kejadian, dan prosedur eskalasi.
2. Batasi dampak. Terapkan isolasi jaringan atau batasi trafik masuk sesuai kebijakan. Hindari mematikan host secara tergesa-gesa jika bukti volatil masih dibutuhkan, kecuali ada risiko aktif yang mengharuskan penghentian.
3. Preservasi bukti. Salin log, snapshot disk atau VM, metadata container, konfigurasi, dan catatan cloud dengan akses terbatas. Catat waktu, sumber, dan siapa yang mengambil salinan.
4. Hentikan akses penyerang. Tutup jalur publik yang tidak diperlukan, pasang pembaruan yang telah diverifikasi, restart worker, dan blokir indikator jaringan berdasarkan analisis.
5. Rotasi rahasia. Dari perangkat yang dipercaya, ganti kredensial database, token API, kunci deployment, dan rahasia lain yang mungkin dapat dibaca proses web. Cabut sesi atau token aktif jika tersedia.
6. Pulihkan integritas. Bila tidak dapat membuktikan host bersih, rebuild dari image tepercaya, pasang patch sebelum menerima trafik, dan pulihkan hanya data yang sudah diperiksa.
7. Pantau dan dokumentasikan. Tingkatkan pemantauan setelah pemulihan, catat dampak, waktu deteksi, keputusan, dan tindakan pencegahan lanjutan.

Pelajaran setelah insiden

Setelah layanan pulih, evaluasi mengapa runtime tidak terinventarisasi atau mengapa patch tertunda. Pastikan ada daftar terpusat untuk versi PHP per situs dan container, pemberitahuan advisori yang diterima tim, jalur persetujuan emergency patch, serta rencana restart proses jangka panjang. Simpan log terpusat dengan retensi memadai agar penyelidikan berikutnya tidak hanya bergantung pada berkas lokal host.

Gunakan checklist patch dan verifikasi PHP2Shell untuk mengonfirmasi runtime telah diperbarui. Jika belum menemukan bukti kompromi, tetap dokumentasikan ruang lingkup pemeriksaan dan keterbatasan log yang tersedia; “tidak ditemukan” tidak sama dengan bukti mutlak bahwa insiden tidak pernah terjadi.