Cara Membersihkan Halaman Phishing yang Ditanam di Website WordPress

Anda menemukan URL di domain sendiri yang meniru halaman login bank, dompet digital, marketplace, atau layanan lain. Halaman mungkin berada di direktori yang tidak pernah dibuat, tidak muncul di menu, atau hanya ditemukan ketika pelanggan mengirim screenshot. Menghapus satu post dari dashboard memang dapat menghentikan satu gejala, tetapi tidak menjawab apakah halaman itu dibuat oleh pengguna, akun administrator yang dibajak, plugin rentan, atau file yang menyisipkan ulang konten.

Jawaban singkatnya: catat URL dan bukti, batasi paparan pengunjung, petakan semua salinan dan jalur yang membuat halaman, bersihkan sumbernya, lalu pastikan URL memberikan konten yang benar atau respons 404/410. Setelah itu tutup akses dan persistence, uji ulang, dan ajukan review keamanan bila Search Console melaporkan masalah. Jangan mengandalkan robots.txt atau penghapusan sementara dari Google sebagai pembersihan.

Panduan ini membahas phishing yang ditanam di WordPress. Untuk penanganan kompromi yang lebih luas, ikuti urutan penanganan website kena hack. Jika situs juga dipenuhi komentar atau post spam, lihat cara membedakan spam komentar dan kompromi WordPress.

Amankan pengunjung sebelum menguji halaman

Halaman phishing dibuat agar seseorang memasukkan informasi ke situs yang salah. Jangan membuka URL berulang kali dari ponsel pribadi, jangan mengisi formulir “untuk memastikan”, dan jangan meminta pelanggan melewati warning browser. Simpan URL lengkap, waktu dan zona waktu, screenshot yang tidak berisi data korban, serta pesan dari browser atau host. Jangan meneruskan kredensial yang dikirim pelanggan ke tiket umum.

Setelah bukti minimum diamankan, batasi akses halaman tersebut. Jika hosting menyediakan quarantine atau aturan blokir yang terdokumentasi, koordinasikan dengan host sebelum menerapkannya. Pada situs transaksi, beri tahu pemilik proses pembayaran dan kontak privasi yang berwenang bila alur bisnis atau data pelanggan mungkin terdampak; jangan membuat klaim kebocoran sebelum ada bukti. Kalau phishing masih aktif dan Anda tidak yakin cara mematikan URL dengan aman, minta host mengisolasi situs sambil menjaga salinan untuk investigasi.

Pembuatan screenshot atau scan juga dapat memicu redirect. Gunakan lingkungan pemeriksaan yang terisolasi dan tidak memiliki sesi akun penting. Tujuannya mengumpulkan fakta yang cukup tanpa memasukkan data sungguhan atau menyebarkan tautan berbahaya.

Tentukan apakah itu halaman pengguna atau kompromi

Tidak semua halaman mencurigakan masuk lewat cara yang sama. Pertanyaan awalnya: apakah situs memang menerima kiriman publik, misalnya listing, forum, profil, form, komentar, atau landing page yang dibuat oleh vendor? Jika ya, periksa pemilik konten, status moderasi, riwayat user, dan perubahan role. Halaman yang disubmit pengguna bisa menjadi penyalahgunaan fitur tanpa akses ke server—tetapi akun atau form tersebut tetap perlu diamankan.

Jika tidak ada fitur untuk membuat halaman semacam itu, atau akun administrator asing, file berubah, redirect tersembunyi, dan script tak dikenal muncul bersamaan, perlakukan sebagai kemungkinan kompromi sampai dibuktikan sebaliknya. Periksa juga apakah domain/host di URL benar-benar milik Anda atau hanya memakai nama merek Anda dalam path atau subdomain yang dikendalikan pihak lain. Halaman phishing pada domain lain memerlukan jalur pelaporan berbeda dari halaman yang disimpan di server WordPress Anda.

Catat apa yang diketahui dan apa yang masih dugaan. Alamat IP, nama file, atau waktu pembuatan konten saja mungkin tidak mengidentifikasi pelaku. Jangan menghapus log atau menghubungi pihak yang diduga membuatnya sebelum pemilik situs dan host menyetujui langkah investigasi.

Petakan seluruh URL phishing, bukan hanya satu contoh

Buka Security issues report di Search Console untuk properti yang mencakup domain dan subdomain terdampak. Periksa kategori security/social engineering dan contoh URL; Google menyebut URL tersebut sebagai sampel, bukan daftar lengkap. Periksa juga status situs Google Safe Browsing jika browser menampilkan warning.

Buat inventaris dari beberapa sumber:

• daftar URL dalam report Google, sitemap, dan log server;
• post, page, custom post type, draft, trash, form entry, dan user yang punya hak membuat konten;
• file dalam root WordPress, plugin, theme, must-use plugin, dan upload;
• rewrite/redirect di WordPress, .htaccess atau konfigurasi server, CDN, serta DNS/subdomain;
• halaman yang hanya muncul pada variasi path, parameter, perangkat, atau sesi anonim.

Pencarian site:domainanda.tld dapat membantu menemukan jejak di hasil pencarian, tetapi bukan crawler lengkap dan tidak membuktikan tidak ada halaman lain. Hindari menguji semua varian secara agresif dari browser biasa. Mulai dengan URL yang dilaporkan, lalu minta host atau teknisi memeriksa pattern dan access log.

Bersihkan dari sumbernya

Jika phishing adalah post, page, atau kiriman pengguna

Simpan ID, URL, tanggal, author, status, serta salinan bukti yang diperlukan. Setelah pengelola situs menyetujui containment, hapus atau karantina konten phishing dan blokir akun/fitur yang menyalahgunakannya. Periksa apakah halaman menggunakan template sah yang telah dimodifikasi, memiliki shortcode/plugin yang tidak dikenal, atau memuat file eksternal.

Jika fitur publik memang diperlukan, batasi jenis file dan URL, wajibkan verifikasi atau moderasi sebelum publikasi, kurangi izin role, gunakan proteksi spam yang sesuai, dan buat alert untuk pendaftaran atau posting yang tidak biasa. Jangan sekadar menonaktifkan moderasi sementara karena antrean terlalu penuh.

Jika halaman dibuat dari file, database, atau rewrite

Sebelum mengubah sistem, ambil backup dan minta host menyimpan log yang dapat hilang. Bandingkan file core dengan paket resmi, periksa plugin/theme dan upload, dan cari perubahan baru dengan konteks. Jangan menghapus file hanya karena berisi base64, eval, atau nama yang tampak acak; pola tersebut dapat muncul dalam kode sah maupun berbahaya. Validasi terhadap sumber tepercaya dan minta teknisi menilai temuan.

Periksa database untuk halaman, post, opsi, widget, menu, shortcode, dan aturan redirect yang tidak dikenal. Bersihkan juga script yang menyisipkan form atau mengalihkan pengunjung. Jika kode berasal dari plugin/theme rentan, perbarui atau ganti dari sumber tepercaya; menghapus satu file yang diinjeksi tanpa memperbaiki komponen akan memungkinkan penyerang mengulanginya.

Untuk pemeriksaan awal WordPress, WP-CLI menyediakan wp core verify-checksums dan wp plugin verify-checksums --all. Perintah checksum membandingkan file yang didukung dengan checksum resmi, tetapi bukan audit penuh: plugin komersial/kustom, tema, database, konfigurasi host, dan malware yang menambah file tetap perlu diperiksa dengan cara lain. Gunakan salinan/staging dan baca dokumentasi core verify checksums serta plugin verify checksums sebelum bertindak.

Pastikan URL yang dihapus memberikan respons yang benar

Hasil akhir bergantung pada apakah URL tersebut pernah punya fungsi sah:

• URL adalah halaman sah yang dirusak: pulihkan konten tepercaya dan buang form, script, atau redirect phishing. Jangan meninggalkan halaman palsu tersembunyi di template.
• URL tidak pernah sah dan tidak punya pengganti setara: hilangkan kontennya dari WordPress/server dan pastikan URL memberi respons 404 atau 410 yang nyata.
• URL memiliki pengganti yang benar-benar sepadan: gunakan redirect permanen hanya ke halaman yang relevan, bukan ke homepage semata-mata untuk menghindari error.
• Halaman berasal dari fitur kiriman pengguna: hapus kiriman, audit akun pembuat, amankan endpoint, dan uji apakah URL versi lain masih dapat dihasilkan.

Jangan menggunakan robots.txt untuk menyembunyikan URL. Aturan itu membatasi crawling, bukan menghapus halaman; crawler bisa tidak melihat respons 404 yang diperlukan dan URL tetap dapat diketahui. Jangan melayani halaman normal untuk Google tetapi konten lain untuk pengguna, atau sebaliknya. Uji URL tanpa login, URL encoded yang ditemukan di log, versi trailing slash, redirect, dan cache setelah aturan dibersihkan.

Tutup akses dan persistence yang menciptakan phishing

Sebuah halaman dapat dibuat lagi jika aksesnya belum ditutup. Audit administrator, role kustom, user yang baru dibuat, sesi aktif, application password, email pemulihan, panel hosting, SFTP/SSH, database, API, dan akses CDN/DNS. Cabut sesi dan token yang tidak dikenal setelah pemiliknya dipastikan. Ganti kredensial dari perangkat yang aman dan perbarui secret yang dipakai aplikasi.

Tinjau plugin/theme, file upload, task cron, must-use plugin, wp-config.php, konfigurasi redirect, serta akun atau rule yang dapat membuat ulang halaman. Jika seorang user yang sah mengirim konten melalui fitur terbuka, perbaiki validasi, moderasi, dan izin—bukan hanya password administrator. Catat versi sebelum dan sesudah cleanup agar perubahan bisa diaudit.

Untuk gejala malware lain seperti halaman spam tersembunyi atau redirect khusus perangkat, gunakan daftar tanda website terkena malware. Jika perubahan muncul kembali sesudah dibersihkan, hentikan penghapusan berulang dan eskalasi; sumber persistence belum ditemukan.

Minta review keamanan setelah semua temuan selesai

Jika Security issues report mencatat social engineering atau hacked content, tangani semua temuan di seluruh situs sebelum menekan Request Review. Jelaskan kategori, URL atau cakupan yang diperiksa, sumber yang ditemukan, tindakan cleanup, perbaikan akar masalah, dan hasil uji sebagai pengunjung. Simpan konfirmasi dan tunggu keputusan melalui report/email resmi; Google dapat memerlukan waktu dan pemilik situs tidak dapat menentukan jadwalnya.

Jika pelanggan harus berhenti menemukan URL phishing di Google secepatnya, Removals tool dapat digunakan sebagai pembatasan sementara pada hasil pencarian. Tool ini tidak membersihkan server dan pemblokirannya tidak permanen; halaman harus dihapus atau diamankan di sumber. Untuk dugaan false positive, gunakan kanal pelaporan resmi setelah memverifikasi halaman, bukan sebelum cleanup.

Uji situs sebagai pengunjung setelah perubahan

Pemeriksaan akhir harus membuktikan bahwa konten berbahaya sudah tidak disajikan dan fitur sah tetap bekerja:

1. Uji setiap URL dalam inventaris, host yang relevan, variasi redirect, dan halaman tanpa login.
2. Pastikan URL palsu kembali ke halaman sah atau menghasilkan 404/410 sesuai tujuan.
3. Periksa kode sumber dan respons jaringan untuk form, script, iframe, atau tujuan redirect yang tidak dikenal.
4. Jalankan ulang pemeriksaan file, user, database, dan log; amati apakah file atau post phishing muncul lagi setelah cron/cache berjalan.
5. Uji login, form publik, notifikasi, dan transaksi penting dengan data uji yang disetujui—bukan kredensial korban.
6. Pantau Search Console, status Safe Browsing, laporan hosting, dan URL baru setelah situs dibuka.

Simpan waktu, versi, hasil status URL, nama pemeriksa, dan perubahan yang dilakukan. Jika satu URL masih menampilkan warning atau redirect, jangan menyebut insiden selesai; isolasi lagi dan cari jalur yang tersisa.

Kesalahan yang perlu dihindari

• Menghapus satu URL dan menganggap seluruh situs bersih. Halaman bisa memiliki salinan, path lain, atau redirect.
• Mengedit database produksi tanpa backup. Salah mengubah content atau option dapat merusak situs dan menghilangkan bukti.
• Mengarahkan semua URL asing ke homepage. Redirect yang tidak relevan dapat menyamarkan masalah dan memberi pengalaman buruk.
• Memblokir URL dengan robots.txt. URL tidak dihapus dari origin dan crawler dapat kehilangan akses ke status penghapusan.
• Mengandalkan hasil scanner atau checksum saja. Cakupannya terbatas; database, akun, server, dan persistence perlu ditinjau.
• Mengirim link phishing kepada rekan untuk diuji. Jangan memperluas paparan atau meminta orang memasukkan data.
• Meminta review sebelum sumber dihapus. Temuan yang masih aktif dapat menyebabkan review gagal dan cleanup perlu diulang.

Pencegahan setelah insiden

Perbarui WordPress serta plugin/theme, hapus komponen yang tak dipakai, gunakan MFA dan akun berhak minimum, tutup registrasi publik yang tidak dibutuhkan, moderasi kiriman, dan simpan backup off-site yang diuji. Pastikan pengembang dan vendor menggunakan akun individual, bukan satu administrator bersama. Batasi kemampuan upload dan akses database sesuai fungsi.

Buat baseline URL sah, daftar administrator, serta proses review perubahan. Aktifkan notifikasi Search Console dan tetapkan orang yang memeriksanya. Setelah insiden, pantau halaman baru, file berubah, redirect, dan akun pengguna secara berkala; pertahankan log sesuai kapasitas host. Panduan mengamankan WordPress untuk usaha memberi langkah lanjutan untuk melindungi akun dan komponen.

Kapan perlu eskalasi

Hubungi hosting atau spesialis keamanan jika halaman kembali setelah dihapus, akun baru muncul, ada banyak file berubah, Anda tidak dapat mengetahui apakah data pelanggan diminta oleh form palsu, atau situs transaksi terganggu. Koordinasikan dengan pemilik bisnis, host, dan kontak privasi yang berwenang; jangan mengunggah backup atau data korban ke kanal terbuka.

Rawat Web menyediakan diagnosis awal melalui Bantuan Website Darurat dan Audit Gratis. Kirim domain, URL phishing, dan gejala tanpa data korban atau password. Diagnosis awal tidak memerlukan akses. Jika cleanup dibutuhkan, kami sepakati lingkup dan biaya sebelum perubahan, lalu dokumentasikan pemeriksaan dan hasil. Kami tidak menjanjikan tanggal warning Google dicabut atau halaman hilang dari hasil pencarian.

Pertanyaan umum

Bolehkah saya langsung menghapus halaman phishing dari WordPress?

Batasi paparan segera setelah menyimpan URL, screenshot, waktu, backup, dan log yang dapat diamankan. Jika halaman aktif, koordinasikan quarantine atau penghapusan dengan host. Setelah itu pastikan sumber dan akses pembuatnya juga ditutup, bukan hanya post-nya yang hilang.

Apa status yang tepat untuk URL phishing yang dihapus?

Jika halaman itu tidak sah dan tidak punya pengganti yang setara, umumnya 404 atau 410. Jika sebuah halaman sah telah dipulihkan, URL dapat menampilkan konten sah. Redirect hanya cocok ke pengganti yang relevan; jangan mengarahkan semua URL ke homepage.

Apakah robots.txt bisa menghapus halaman phishing dari Google?

Tidak. robots.txt mengatur crawling, bukan menghapus konten dari server. Hapus atau amankan sumbernya, berikan respons yang benar, dan gunakan Removals hanya sebagai langkah sementara bila diperlukan.

Apakah menghapus satu halaman cukup untuk meminta review?

Belum tentu. Report Google hanya menampilkan contoh URL; periksa kategori dan pola di seluruh situs, tutup akar masalah, uji halaman sebagai pengunjung, dan jelaskan tindakan yang terverifikasi dalam Request Review.