Cara Audit Akun Administrator WordPress Asing Setelah Website Diretas

Menemukan administrator WordPress dengan nama atau alamat email yang tidak dikenal adalah alasan untuk menyelidiki—tetapi belum cukup untuk memastikan siapa yang membuatnya atau kapan akses diperoleh. Akun tersebut bisa dibuat penyerang, agensi lama, developer, proses migrasi, atau instalasi otomatis dari hosting. Menghapusnya seketika dapat menghilangkan bukti, memutus pemilik sah, atau membuat konten tidak punya penulis.

Jawaban singkatnya: simpan salinan database dan log, cocokkan seluruh akses berhak tinggi dengan pemilik yang sah, periksa role/capability serta token dan sesi, lalu cabut akses yang terbukti tidak sah dan tutup jalur masuknya. Jangan berhenti pada daftar Users: akses dapat bertahan lewat application password, plugin, akun hosting, atau integrasi lain.

Panduan ini membahas audit akun administrator WordPress saat ada dugaan peretasan. Untuk proses penanganan insiden yang lebih luas, lihat urutan pemulihan website kena hack. Jika Anda hanya melihat komentar atau post spam, pastikan dulu apakah ada user asing atau perubahan sistem; panduan spam komentar WordPress membantu membedakan dua situasi itu.

Jangan menyamakan akun asing dengan bukti lengkap peretasan

WordPress menyimpan profil pengguna, role, waktu pendaftaran, dan konten yang terkait. Namun, instalasi standar tidak menyediakan audit trail lengkap yang selalu menunjukkan siapa yang membuat akun, alamat IP pembuat, waktu setiap perubahan role, atau login terakhir. Data tersebut mungkin tersedia dari plugin audit yang memang sudah dipasang sebelumnya, log hosting, WAF, SSO, atau catatan organisasi—tetapi tidak selalu.

Karena itu, periksa beberapa sumber dan tandai tingkat kepastian. Tanggal user_registered hanya menunjukkan waktu pendaftaran akun yang tersimpan, bukan bukti tunggal waktu penyerang memperoleh akses. Email yang berbeda, nama acak, role administrator, atau post yang mencurigakan adalah sinyal investigasi, bukan atribusi pelaku.

Buat inventaris awal:

• ID, username, nama tampilan, email, role dan capability efektif, tanggal registrasi;
• pemilik yang mengaku menggunakan akun serta alasan aksesnya;
• post, page, media, perubahan plugin/theme, atau opsi yang berkaitan;
• sesi aktif dan application password yang terkait;
• log hosting, login panel, SFTP/SSH, WAF/CDN, SSO, serta notifikasi yang tersedia;
• perubahan yang baru terjadi, disertai waktu dan zona waktu.

Bandingkan dengan daftar staf, vendor, akun layanan, akun migrasi, dan akun darurat yang didokumentasikan. Bila suatu akun dibuat oleh proses hosting atau integrasi, identifikasi pemilik proses sebelum mengubahnya.

Langkah 1: simpan bukti dan kendalikan risiko aktif

Ambil backup file dan database, serta ekspor log yang masih tersedia sebelum menghapus user, plugin, atau catatan. Simpan salinan dalam lokasi terpisah dengan akses terbatas; jangan unggah dump database ke layanan publik karena isinya dapat memuat data pribadi dan hash kredensial. Catat siapa yang mengambilnya dan kapan.

Jika akun tak dikenal sedang menambah halaman, mengubah konfigurasi, atau membuat administrator lain, pembatasan akses tidak boleh ditunda demi investigasi tanpa batas. Setelah salinan minimum dan pemilik situs diberi tahu, nonaktifkan atau cabut akses lewat mekanisme yang disetujui; bila host mengelola insiden, ikuti koordinasi mereka. Jangan mengirim password atau rahasia ke pihak yang belum diverifikasi.

Jika situs sedang mengirim phishing, malware, atau redirect, batasi paparan dengan bantuan host/CDN. Untuk tanda dan containment yang lebih luas, lanjutkan ke panduan malware website WordPress. Hindari menguji login asing atau mengirim email ke alamat yang mungkin dikendalikan penyerang.

Langkah 2: daftar seluruh user dan akses berhak tinggi

Pada dashboard, buka Users → All Users dan periksa semua akun, bukan hanya yang tampak baru. Dokumentasi WordPress Users Screen menjelaskan cara daftar pengguna dikelola. Catat akun dengan role Administrator, tetapi periksa juga role kustom dan capability yang diberikan plugin. Role bawaan WordPress bukan satu-satunya cara sebuah user dapat memperoleh kemampuan istimewa.

Dengan WP-CLI, perintah wp user list menampilkan akun ber-role Administrator dan kolom penting untuk pencocokan:

wp user list --role=administrator --fields=ID,user_login,display_name,user_email,user_registered,roles

Jalankan hanya pada instalasi yang benar dan akses yang sah. Untuk multisite, tentukan site yang sedang diperiksa dan audit juga Network Admin → Users serta daftar Super Admin; pengguna jaringan dapat memiliki akses yang tidak tampak pada satu situs saja. Jangan berasumsi semua akun dengan label Administrator berlaku di seluruh network.

Perhatikan juga akun yang rolenya pernah diubah, akun lama yang kembali aktif, akun dengan alamat email yang dialihkan, dan user yang tidak lagi punya pemilik internal. Bandingkan akses efektifnya dengan tugas sebenarnya. WordPress menjelaskan role dan capability bawaan dalam dokumentasi resmi roles and capabilities; plugin dapat menambahkan capability sendiri.

Langkah 3: cocokkan aktivitas tanpa mengarang riwayat yang tidak tersedia

Untuk setiap akun berisiko, cari bukti silang:

• Apakah pemilik organisasi, staf, agensi, atau developer mengenali username/email dan kebutuhan role-nya?
• Apakah waktu registrasi selaras dengan kontrak, migrasi, pembuatan situs, atau tiket dukungan?
• Apakah akun menjadi author post/page asing, mengubah email administrator, memasang plugin/theme, atau mengubah pengaturan?
• Apakah log hosting atau WAF menunjukkan login, perubahan file, atau permintaan aneh pada rentang waktu yang sama?
• Apakah perubahan dapat berasal dari integrasi, single sign-on, backup restore, atau proses otomatis yang dikenal?

WordPress core tidak mencatat “last login” yang dapat diandalkan pada layar Users. Jangan memasang plugin audit secara tergesa-gesa lalu menganggap plugin itu dapat membuktikan apa yang sudah terjadi sebelumnya. Plugin baru hanya dapat mencatat kegiatan setelah aktif dan bisa memperluas permukaan serangan. Ambil bukti dari sistem yang memang sudah punya log dan pertahankan retensinya.

Jika bukti tidak cukup, tandai akun sebagai “belum terverifikasi”, bukan otomatis “penyerang”. Lanjutkan investigasi file, database, dan kredensial terkait. Kepastian yang dilebih-lebihkan membuat keputusan hapus akun lebih berisiko.

Langkah 4: audit sesi, application password, dan akses non-dashboard

User dan password utama bukan satu-satunya kredensial. WordPress application passwords memungkinkan autentikasi integrasi ke REST API; dokumentasi REST API authentication menerangkan mekanismenya. Inventarisasikan nama aplikasi, pemilik, tanggal dibuat, dan apakah integrasi masih digunakan. Jangan menyalin atau membagikan nilai secret.

WP-CLI dapat membantu memeriksa kredensial aplikasi dan mengakhiri sesi. Contoh di bawah bersifat tindakan administratif; pastikan backup, user ID, site, dan target sudah diverifikasi sebelum menjalankan perintah:

# Daftar application password untuk user ID tertentu
wp user application-password list 42

# Akhiri semua sesi WordPress milik user tersebut
wp user session destroy 42 --all

# Cabut hanya application password yang sudah dipastikan tidak sah
wp user application-password delete 42 UUID

Ganti 42 dan UUID dengan nilai sebenarnya. wp user session destroy ... --all akan mengeluarkan user itu dari seluruh sesi WordPress; perhitungkan dampaknya pada pemilik sah. Hapus application password satu per satu setelah mengidentifikasi integrasi yang perlu dipertahankan. Lihat dokumentasi WP-CLI untuk daftar application password dan menghancurkan sesi.

Di luar WordPress, periksa email pemulihan, akun panel hosting, SFTP/SSH, database, CDN/DNS, CI/CD, token webhook, dan akses agensi. Jika email admin atau panel diambil alih, mengganti password WordPress saja tidak menutup jalur pemulihan akun.

Langkah 5: cabut, turunkan, atau hapus akun dengan aman

Setelah backup, pemilik, dan dampak konten diperiksa, pilih tindakan paling sempit yang memulihkan kontrol:

• Akun sah tetapi akses terlalu luas: ubah role/capability ke tingkat minimum yang diperlukan dan konfirmasi tugasnya tetap bekerja.
• Akun sah yang sudah tidak dipakai: cabut akses atau hapus setelah aset, integrasi, dan kepemilikannya dialihkan.
• Akun terbukti tidak sah: cabut sesi, application password, token terkait, dan hak akses; kemudian hapus atau nonaktifkan lewat proses yang sesuai.
• Kepemilikan belum jelas: batasi akses sementara dengan koordinasi pemilik situs dan host sambil memverifikasi; jangan biarkan akun berhak tinggi aktif tanpa pemantauan jika ada aktivitas berbahaya.

Sebelum menghapus user, tinjau post, halaman, media, komentar, dan objek yang terkait. Tentukan apakah konten harus dihapus sebagai bagian cleanup atau dipertahankan dan dialihkan ke user tepercaya. Bila memakai WP-CLI, perintah wp user delete dengan --reassign=KNOWN_ID dapat memindahkan atribusi post. Untuk multisite, dokumentasi WP-CLI membedakan penghapusan dari satu site dan --network; jangan menghapus dari seluruh network kecuali pemilik jaringan menyetujuinya. Hindari menghapus satu-satunya administrator atau Super Admin tepercaya sebelum akun pengganti diuji.

Langkah 6: tutup sumber yang memungkinkan akun muncul kembali

Akun administrator asing bisa menjadi persistence, bukan akar masuk. Selidiki bagaimana ia dibuat dan periksa:

• plugin/theme rentan atau nulled, WordPress usang, file yang berubah, dan plugin must-use;
• endpoint, script, atau fitur registrasi yang dapat menaikkan hak pengguna;
• kode di theme/plugin yang membuat user saat hook tertentu berjalan;
• database, jadwal cron, konfigurasi, file upload, dan rule rewrite;
• password reuse, email pemulihan, kredensial hosting, SSH/SFTP, API, atau token deployment.

Jangan menghapus semua file berisi kata admin, eval, atau string tertentu. Cocokkan dengan paket resmi, baseline bersih, dan log. Ganti rahasia dari perangkat yang tepercaya setelah perangkat dan jalur kerja aman; rotasi juga password database atau API yang disimpan di file konfigurasi, lalu perbarui integrasi terkait. Untuk langkah pencegahan setelah pemulihan, lihat cara mengamankan WordPress untuk bisnis.

Langkah 7: verifikasi bahwa hak akses tidak kembali

Setelah cleanup dan rotasi, buat snapshot baru sebagai baseline, lalu uji:

1. Daftar administrator dan Super Admin sesuai site/network yang benar; pastikan pemilik setiap akun sudah jelas.
2. Sesi lama tidak lagi berfungsi untuk akun yang dicabut dan token yang tak sah tidak dapat memanggil REST API.
3. User asing tidak muncul kembali setelah cache dibersihkan, cron berjalan, atau situs diakses dari luar.
4. Post, form, dan halaman yang tidak sah sudah dihapus atau dikembalikan; akun sah tetap dapat menjalankan pekerjaan normal.
5. Log hosting, perubahan file, email notifikasi, dan report Search Console dipantau setelah situs aktif.

Jangan memakai satu screenshot daftar user sebagai bukti permanen. Catat waktu pemeriksaan dan ulangi setelah periode pemantauan yang ditentukan pemilik situs. Jika akun muncul kembali, hentikan penghapusan berulang dan cari kode, integrasi, atau kredensial yang membuatnya.

Kesalahan umum saat menemukan administrator asing

• Langsung menghapus akun sebelum menyimpan bukti. Anda dapat kehilangan hubungan dengan konten, waktu, atau aktivitas yang perlu ditelusuri.
• Menganggap nama aneh adalah bukti pelaku. Bisa saja ada akun layanan; cocokkan dengan pemilik dan log.
• Hanya mengganti password. Sesi, application password, akun email, dan hosting mungkin tetap aktif.
• Menghapus akun tetapi meninggalkan post penyerang. Konten berbahaya masih dapat dilayani dengan author yang berbeda.
• Mendelete semua akun administrator selain milik sendiri. Plugin, vendor, atau alur pemulihan sah dapat berhenti; cek dependency dan gunakan akses minimum.
• Menghapus user network tanpa memahami multisite. Tindakan network berbeda dari menghapus akses pada satu situs.
• Menganggap audit user sama dengan membersihkan malware. Backdoor dan akses di lapisan hosting harus diperiksa terpisah.

Kapan perlu eskalasi

Eskalasi kepada host atau spesialis keamanan jika admin baru terus dibuat, email/password pemilik berubah sendiri, Anda kehilangan akses, ada modifikasi file yang tidak bisa dijelaskan, website menjalankan pembayaran, atau situs berada dalam multisite yang Anda tidak kelola penuh. Jangan memodifikasi tabel database langsung bila belum menguasai struktur dan rollback; satu nilai role yang salah dapat membuat pemilik sah terkunci.

Rawat Web menyediakan diagnosis awal melalui Bantuan Website Darurat dan Audit Gratis. Kirim URL serta gejala yang terlihat tanpa password atau token. Jika bantuan teknis dibutuhkan, akses dan cakupan disepakati sebelum perubahan; kami dapat membantu membuat inventaris user, meninjau akses, mengamankan akun, dan memeriksa pemulihan tanpa menjanjikan hasil ranking atau waktu keputusan pihak ketiga.

Pertanyaan umum

Apakah administrator dengan email asing pasti dibuat penyerang?

Tidak. Email yang tidak dikenal adalah sinyal untuk diverifikasi, bukan bukti atribusi. Periksa pemilik situs, vendor, akun layanan, waktu pendaftaran, aktivitas yang tercatat, dan log yang tersedia sebelum memutuskan.

Apakah WordPress mencatat siapa yang membuat akun dan alamat IP-nya?

Instalasi core standar tidak selalu menyimpan audit trail lengkap tentang pembuat akun, IP, atau setiap perubahan role. Bukti mungkin ada pada plugin audit yang sudah aktif sebelumnya, SSO, WAF, log hosting, atau catatan organisasi.

Bolehkah saya langsung menghapus administrator asing?

Jika aktivitas aktif membahayakan situs, batasi akses dengan aman setelah menyimpan bukti minimum dan berkoordinasi dengan pemilik/host. Sebelum menghapus, cocokkan kepemilikan, cabut sesi dan token, tinjau konten, lalu reassign post jika perlu. Jangan menghapus satu-satunya akses tepercaya.

Apakah mengganti password administrator cukup?

Tidak selalu. Akhiri sesi lama, cabut application password dan token yang tidak dikenal, amankan email pemulihan dan hosting, tutup jalur masuk, serta verifikasi bahwa user tidak dibuat lagi.