Sudah cukup lama saya tidak menulis di blog ini. Bukan karena kehabisan topik, justru sebaliknya. Semakin lama saya bekerja di dunia keamanan, semakin sering saya merasa bahwa apa yang ingin saya tulis tidak lagi sesederhana “temuan dan mitigasi”.
Sebagai “penetration tester”, saya terbiasa hidup di dunia yang rapi. Ada scope, ada metodologi, ada temuan, ada proof of concept, dan ada rekomendasi. Semuanya terstruktur. Semuanya bisa dijelaskan secara teknis. Namun, semakin sering saya terlibat dalam pengujian dan diskusi pasca-insiden, semakin terasa bahwa ada sesuatu yang selalu tertinggal dari laporan-laporan itu.
Sesuatu yang tidak tercapture oleh scanner.
Sesuatu yang tidak muncul di hasil pentest.
Sesuatu yang tidak punya CVE.
Sesuatu itu adalah manusia.
Ketika Sistem Sudah Terlihat Aman
Saya pernah berada di situasi di mana sebuah sistem, setidaknya di atas kertas, terlihat solid. Autentikasi berlapis, konfigurasi cukup ketat, dan tidak ada celah teknis signifikan yang bisa dieksploitasi secara langsung. Jika dilihat dari sudut pandang teknis murni, sistem ini “baik-baik saja”. Namun ketika insiden terjadi, jalurnya tidak melalui celah teknis. Tidak ada exploit canggih. Tidak ada bypass autentikasi. Yang ada hanyalah serangkaian keputusan kecil yang, pada saat itu, terasa masuk akal bagi orang-orang yang terlibat.
Permintaan yang terdengar wajar.
Konteks yang familiar.
Sedikit urgensi yang membuat verifikasi terasa seperti hambatan.
Dan di situlah saya mulai benar-benar menyadari bahwa keamanan tidak pernah berdiri sendiri sebagai sistem teknis. Ia selalu hidup berdampingan dengan sistem sosial.
Social Engineering Bekerja Karena Ia Masuk Akal
Ada kecenderungan untuk melihat social engineering sebagai bentuk manipulasi kasar. Seolah-olah serangan ini hanya berhasil karena seseorang lengah atau ceroboh. Dalam pengalaman saya, narasi ini tidak adil dan juga tidak akurat. Social engineering jarang berhasil karena kebohongan yang ekstrem. Ia justru berhasil karena terlihat masuk akal. Karena selaras dengan cara organisasi bekerja. Karena sesuai dengan ekspektasi peran. Karena tidak terasa seperti “serangan”.
Manusia tidak membuat keputusan dalam ruang steril. Kita mengambil keputusan sambil menavigasi tekanan waktu, hierarki organisasi, tanggung jawab pekerjaan, dan kebiasaan yang sudah terbentuk bertahun-tahun. Dalam konteks seperti ini, verifikasi tambahan sering kali terasa bukan sebagai pengamanan, tetapi sebagai gangguan.
Di titik inilah banyak kontrol keamanan mulai melemah. Bukan karena tidak ada, tetapi karena tidak dirancang untuk realitas manusia.
Kegagalan Awareness yang Jarang Dibicarakan
Saya sering melihat security awareness diperlakukan sebagai kewajiban administratif. Ada materi, ada sesi, ada checklist yang harus diselesaikan. Pesannya biasanya benar, tetapi pendekatannya sering terlalu ideal. Masalahnya bukan karena orang tidak tahu apa yang seharusnya dilakukan. Masalahnya adalah karena keputusan penting jarang diambil dalam kondisi ideal. Ia diambil saat lelah, saat multitasking, atau saat merasa bertanggung jawab agar pekerjaan tetap berjalan.
Di sinilah saya mulai merasa bahwa kita terlalu sering mengajarkan aturan, tetapi jarang mengajak orang mengalami bagaimana aturan itu runtuh di dunia nyata.
Dari Pentesting ke Keraguan
Sebagai pentester, saya terbiasa memetakan attack surface, trust boundary, dan data flow. Namun seiring waktu, saya mulai bertanya pada diri sendiri: di mana kita memetakan alur keputusan manusia? Ketika sebuah prosedur dilewati tanpa eksploit teknis, apakah itu berarti sistemnya aman? Atau justru kita gagal memahami bagaimana sistem itu benar-benar digunakan?
Pertanyaan-pertanyaan inilah yang perlahan membentuk fondasi Pretexta.
Sebuah Takeover yang Dimulai dari Percakapan
Ada satu temuan yang benar-benar mengubah cara saya memandang relasi antara kerentanan teknis dan social engineering. Temuan ini bukan berawal dari exploit, bukan dari scanning masif, dan bahkan bukan dari bug yang “menarik” secara teknis. Ia berawal dari sebuah subdomain yang tampak mati.
Secara teknis, kondisinya sederhana. Subdomain tersebut mengarah ke layanan pihak ketiga dan merespons 404. Dalam banyak kasus, kondisi seperti ini dianggap biasa. Ia terlihat seperti sisa aset lama, tidak aktif, dan sering kali diabaikan.
Namun di sinilah ceritanya mulai berbeda.
Saya menemukan bahwa subdomain tersebut terhubung ke sebuah platform pihak ketiga. Platform ini memungkinkan pengguna menambahkan dan memverifikasi subdomain sebagai bagian dari layanannya. Artinya, secara teoritis, jika relasi kepemilikan subdomain itu dilepas, maka subdomain tersebut bisa diklaim ulang.
Secara teknis, ini masih belum takeover.
Yang ada hanyalah potensi.
Langkah berikutnya bukan eksploitasi, melainkan interaksi.
Saya mendaftarkan akun di platform tersebut dan mencoba menambahkan subdomain yang sama. Statusnya jelas: subdomain sudah diklaim oleh pemilik lain. Secara normal, cerita seharusnya berhenti di sini.
Namun saya menghubungi customer support platform tersebut.
Dalam komunikasi itu, saya tidak mengeksploitasi sistem, tidak memalsukan bukti teknis, dan tidak memanipulasi mekanisme verifikasi otomatis. Yang saya lakukan adalah membangun konteks. Saya memperkenalkan diri sebagai pihak yang masuk akal dalam ekosistem tersebut: seorang vendor baru yang bekerja untuk pemilik subdomain, dengan alasan yang terdengar wajar mengapa akses perlu dipindahkan.
Percakapan itu berjalan seperti banyak percakapan support lainnya. Tidak ada alarm. Tidak ada red flag teknis. Tidak ada proses yang dilanggar secara eksplisit.
Dan pada akhirnya, pihak platform melepaskan klaim subdomain tersebut dari pemilik aslinya.
Di titik itu, barulah aspek teknis mengambil alih. Subdomain yang sebelumnya tidak bisa diklaim, kini bebas. Saya menambahkannya kembali ke akun saya.
Dan takeover pun terjadi.
Jika dilihat dari laporan akhirnya, ini adalah subdomain takeover. Kerentanan yang sudah dikenal, dengan dampak yang jelas. Namun jika ditarik mundur, takeover itu tidak akan pernah terjadi tanpa social engineering.
Secara eksplisit, ini adalah cerita tentang: sebuah subdomain, layanan pihak ketiga, customer support, dan klaim yang berpindah tangan. Namun secara implisit, ini adalah cerita tentang kepercayaan. Tentang bagaimana asumsi, peran, dan konteks sosial bisa menjadi lapisan keputusan yang lebih menentukan daripada mekanisme teknis itu sendiri.
Tidak ada celah di kode customer support.
Tidak ada bypass sistem otomatis.
Yang ada hanyalah manusia yang membuat keputusan masuk akal berdasarkan informasi yang terasa konsisten.
Dan di situlah saya benar-benar memahami bahwa banyak kerentanan teknis tidak berdiri sendiri. Mereka sering kali menunggu interaksi manusia yang tepat untuk akhirnya terbuka. Dari pengalaman inilah Pretexta mulai terasa bukan sekadar ide, tetapi kebutuhan.
Pretexta Bukan Tentang Mengajarkan Serangan
Pretexta lahir bukan sebagai alat untuk mengajarkan cara melakukan social engineering. Sejak awal, saya sadar bahwa ada garis etika yang tidak ingin saya lewati. Tujuan Pretexta bukan menciptakan attacker yang lebih baik, melainkan defender yang lebih memahami realitas.
Pretexta tidak saya bangun sebagai konsep abstrak. Ia berkembang sebagai lab yang terus saya eksplorasi dan dokumentasikan secara terbuka. Bagi yang ingin melihat bagaimana Pretexta dibentuk dan dikembangkan, dokumentasi proyek ini tersedia secara publik di GitHub.
https://github.com/dalpan/Pretexta
Di dalamnya, yang diuji bukan kemampuan teknis, tetapi cara berpikir.
Pretexting sebagai Cara Membaca Sistem Sosial
Salah satu konsep kunci dalam Pretexta adalah pretexting. Saya melihat pretexting bukan sebagai teknik menyamar, tetapi sebagai cara membaca sistem sosial. Ia memaksa kita memahami bagaimana organisasi bekerja, bagaimana peran saling bergantung, dan bagaimana kepercayaan dialirkan dari satu titik ke titik lain.
Jika threat modeling berfokus pada bagaimana data mengalir di dalam sistem, maka pretexting berfokus pada bagaimana kepercayaan mengalir di dalam organisasi. Keduanya sama-sama penting, tetapi yang terakhir sering diabaikan.
Bias Kognitif sebagai Celah yang Tidak Pernah Dipatch
Dalam banyak simulasi, saya melihat pola yang sama muncul berulang kali. Ada momen-momen di mana logika manusia mulai bergeser, bukan karena niat buruk, tetapi karena bias yang sangat manusiawi.
Ketika permintaan datang dari figur yang terlihat berwenang, resistensi menurun. Ketika ada tekanan waktu, verifikasi terasa opsional. Ketika situasi terlihat familiar, kewaspadaan melemah. Jika ini terjadi di kode, kita akan menyebutnya bug. Ketika terjadi pada manusia, kita menyebutnya human error, lalu bergerak tanpa benar-benar memahaminya.
Pretexta mencoba berhenti sejenak di titik itu.
Implikasi Teknis yang Tidak Bisa Diabaikan
Meski Pretexta bersifat reflektif, implikasinya sangat teknis. Ia menantang cara kita merancang kontrol keamanan, prosedur verifikasi, dan bahkan incident response. Ia memaksa kita bertanya apakah kontrol yang kita bangun benar-benar bisa bertahan di bawah tekanan sosial, atau hanya kuat di atas kertas.
Bagi saya, ini bukan pengganti pentesting teknis, tetapi pelengkap yang selama ini hilang.
Pretexta sebagai Cermin
Saya tidak melihat Pretexta sebagai solusi instan. Ia bukan framework ajaib. Ia adalah cermin. Cermin yang memperlihatkan bahwa sistem yang aman secara teknis tetap bisa rapuh ketika bertemu dengan realitas manusia.
Dan mungkin, dari refleksi inilah diskusi keamanan yang lebih jujur bisa dimulai.
Penutup
Kita bisa terus membangun sistem yang semakin canggih, semakin aman, dan semakin kompleks. Namun selama sistem itu digunakan oleh manusia, maka manusia akan selalu menjadi bagian dari threat model.
Pretexta adalah upaya kecil saya untuk mengingatkan hal itu. Bahwa keamanan bukan hanya tentang menutup celah, tetapi tentang memahami mengapa celah itu bisa terbuka, bahkan ketika semuanya terlihat sudah benar.
