Arman Ridho MaulanaArman Ridho
  • Home
  • About
  • Skills
  • Experience
  • Projects
  • Certifications
  • Blog
  • Contact
Download CV
Back to Blog
August 14, 2026osintreconred-teampentest

OSINT Recon: Mapping the Target Before the First Exploit

Sebelum exploit apa pun dikirim, red teamer yang baik sudah tahu peta targetnya dari informasi publik. Artikel ini bercerita tentang bagaimana OSINT dan passive recon — dari Google dorking, Shodan, hingga Wayback Machine — berhasil membuka jalan masuk ke engagement yang tampaknya mustahil ditembus.

OSINT Recon: Mapping the Target Before the First Exploit

Banyak orang masuk ke dunia red team dengan bayangan serangan yang dramatis: exploit nol hari, shellcode, dan akses root dalam hitungan menit. Padahal, kalau gue jujur, sebagian besar pekerjaan red team yang beneran itu dimulai jauh sebelum ada satu pun paket data yang dikirim ke target. Semuanya dimulai dari proses yang membosankan, melelahkan, dan sering dianggap remeh: reconnaissance. Dan di dalam recon itu sendiri, ada satu cabang yang paling sering dilupakan padahal paling menentukan: OSINT atau Open Source Intelligence. Hari ini gue mau cerita pengalaman gue ngerjain assessment yang nyaris gagal total, dan kenapa OSINT jadi penyelamat segalanya. Bukan cuma teori kering, tapi cerita lapangan yang beneran.

Malam Sebelum Engagement

Gue inget banget malam itu. Dapet email dari project manager, isinya cuma tiga kalimat: klien mau red team assessment, scope-nya aplikasi web internal yang katanya "sangat aman", dan window waktunya cuma lima hari kerja. Nama domain yang dikasih cuma satu, plus alamat IP publik yang keliatan bersih. Tidak ada yang lain. Tidak ada VPN, tidak ada akses awal, tidak ada user story. Cuma satu domain dan satu IP.

Orang yang belum pernah ngerasain red team mungkin mikir, "yaudah tinggal scan aja kan?" Nah, ini kesalahan besar yang sering bikin engagement gagal di hari pertama. Kalau lu langsung scan IP publik tanpa persiapan, yang lu dapet cuma layer terluar: firewall, WAF, dan mungkin satu halaman login yang seakan-akan gak bisa ditembus. Lu buang waktu berhari-hari nembus pintu depan yang sebenarnya cuma umpan.

Gue memutuskan untuk gak menyentuh target sama sekali di malam itu. Sebagai gantinya, gue buka laptop, nyalain kopi, dan mulai dari apa yang bisa dilihat siapa pun: internet. Ini yang namanya passive recon, dan ini adalah senjata paling underrated yang dimiliki red teamer.

Kenapa Lu Gak Boleh Skip Passive Recon

Banyak pemula yang gak sabaran. Mereka pengen langsung scan, langsung exploit, langsung dapat shell. Padahal passive recon itu fondasinya. Ibarat mau bobol rumah, lu gak langsung congkel pintu. Lu keliling dulu, liat jendela mana yang sering kebuka, jam berapa penghuninya pergi, siapa aja yang dateng, dan apa aja yang mereka buang ke tong sampah. Di dunia maya, "tong sampah" itu adalah internet itu sendiri.

Passive recon itu penting karena beberapa alasan. Pertama, dia gak meninggalkan jejak. Lu gak nyentuh infrastruktur target, jadi blue team gak akan nemu alamat IP lu di log. Kedua, dia ngasih lu peta sebelum lu masuk. Semakin banyak yang lu tau, semakin sedikit tebakan yang lu perlu lakuin nanti. Ketiga, dan ini yang paling penting: passive recon sering ngasih lu jalan pintas yang gak akan pernah ketemu sama scanner.

Mulai dari mana? Yang pertama dan paling gampang: mesin pencari. Bukan cuma Google, tapi juga Bing, DuckDuckGo, dan kalau lu punya akses, search engine khusus kayak Shodan, Censys, atau FOFA. Lu bakal kaget berapa banyak informasi yang bocor cuma karena orang lupa ngatur visibility.

Google Dorking: Bahasa Rahasia yang Semua Orang Bisa Pakai

Oke, gue mau cerita bagian yang paling seru. Waktu itu gue disuruh nyari tahu sebanyak mungkin tentang target dari luar. Nama domain yang dikasih cuma satu, dan gue mulai dengan query-query sederhana di Google. Tapi bukan query biasa. Gue pakai teknik yang namanya Google dorking — memanfaatkan operator khusus di mesin pencari buat nyaring hasil yang gak akan muncul di pencarian normal.

Contoh paling gampang: site:targetdomain.com filetype:pdf. Query ini bakal nge-list semua PDF yang terindeks dari domain itu. Kenapa PDF penting? Karena orang sering nyimpen dokumen internal di PDF dan lupa ngelindungin. Dokumen itu bisa berisi struktur organisasi, nama karyawan, bahkan kadang password atau alamat server internal.

Lalu site:targetdomain.com intitle:"index of". Ini query legendaris buat nemuin direktori yang ke-expose tanpa proteksi. Kalau ketemu direktori listing, itu artinya ada web server yang gak dikonfigurasi dengan benar, dan di dalamnya bisa ada backup, file konfigurasi, atau source code.

Gue juga pakai site:targetdomain.com ext:sql OR ext:bak OR ext:log. File backup dan log yang keindeks itu emas murni buat red teamer. File .sql bisa berisi dump database, file .bak bisa berisi source code atau konfigurasi, dan file .log bisa berisi path internal, parameter, atau bahkan token.

Malam itu, setelah sejam main dorking, gue nemu sesuatu yang menarik: sebuah PDF laporan presentasi internal yang keindeks di Google. Isinya? Struktur tim IT mereka, termasuk nama CTO dan kepala infrastruktur. Gue catet semua nama itu. Kenapa? Karena nama adalah kunci ke tahap OSINT berikutnya: profiling orang.

OSINT Itu Tentang Manusia, Bukan Cuma Mesin

Ini pelajaran yang gue dapet dengan cara yang agak pahit. Dulu gue mikir OSINT itu cuma soal nyari server, port, dan subdomain. Ternyata salah besar. Sebagian besar keamanan sistem itu dipegang sama manusia, dan manusia itu gampang diprediksi. Nama orang yang gue dapet dari PDF itu bukan cuma info kosong. Itu titik awal buat nyusun profil.

Gue mulai nyari nama-nama itu di LinkedIn. Sekarang gue tau jabatan mereka, divisi mereka, dan yang lebih penting: berapa lama mereka kerja di perusahaan itu. Orang yang baru pindah dari perusahaan lain sering bawa kebiasaan lama, termasuk cara mereka bikin password atau cara mereka namaan server. Ini bukan tebak-tebakan receh, ini pola yang berulang di banyak engagement.

Dari LinkedIn juga gue bisa tau tech stack yang mereka pakai. Orang yang nulis di profilnya "GCP Certified" atau "Kubernetes enthusiast" ngasih petunjuk besar tentang infrastruktur perusahaan. Kalau banyak yang bangga sama AWS, kemungkinan besar mereka pindah ke cloud, dan cloud punya attack surface yang beda sama on-premise.

Gue juga cek GitHub. Ini sering dilupakan padahal sangat penting. Banyak developer yang ngasih repo publik tanpa sadar bocorin konfigurasi. Gue cari site:github.com "namadomain" dan nemuin beberapa repo yang menyebut domain target. Salah satunya adalah repo personal milik salah satu developer di sana, dan di dalamnya ada file konfigurasi lama yang masih nyimpen alamat server internal dan username database. Bukan password, tapi username plus nama database itu udah ngasih gue petunjuk gede soal apa yang ada di belakang firewall.

Wayback Machine dan Jejak Digital yang Gak Pernah Hilang

Salah satu tool favorit gue yang paling sering ngehasilin kejutan adalah Wayback Machine atau web.archive.org. Idenya sederhana: arsip internet yang nyimpen snapshot halaman web dari tahun ke tahun. Dan ini adalah harta karun buat red teamer.

Kenapa? Karena website itu berubah terus. Halaman yang sekarang udah bersih, dulu bisa jadi bocor. Parameter yang sekarang udah divalidasi, dulu bisa jadi vulnerable. Dan yang paling berharga: endpoint lama yang masih hidup tapi gak ke-link di mana-mana.

Gue buka arsip domain target dan mulai jalan mundur ke beberapa tahun lalu. Di snapshot-snapshot lama, gue nemu halaman login yang udah gak dipake, subdomain yang udah mati, dan yang paling menarik: sebuah file konfigurasi yang ke-save di arsip karena pernah ke-link dari halaman publik.

Dari situ gue juga pakai tools kayak urlscan.io dan SecurityTrails buat liat riwayat DNS. Ini penting karena DNS punya memori. Subdomain yang udah dihapus bisa aja masih nge-resolve, atau lebih bahaya lagi: subdomain yang udah gak dipake tapi masih nyala dan gak di-patch. Subdomain terlantar kayak gini adalah mimpi basah red teamer karena biasanya gak ada yang monitor, gak ada yang update, dan seringnya masih nyimpen aplikasi lama yang vulnerable.

Malam itu gue nemu satu subdomain yang menarik: dev.targetdomain.com. Di halaman utama gak ada yang spesial, cuma login page polos. Tapi yang bikin gue penasaran, subdomain itu gak muncul di daftar subdomain yang sah. Kemungkinan besar ini environment development yang lupa dihapus atau sengaja disisain. Gue catet, tapi belum gue sentuh. Passive recon dulu, semua masih aman.

Shodan: Melihat Dunia dari Perspektif Mesin

Bagian yang gak kalah seru adalah nyari tahu apa yang sebenarnya ke-expose di internet. Di sinilah Shodan berperan. Kalau Google itu search engine buat manusia, Shodan itu search engine buat mesin. Dia nge-index banner, port, dan service yang ke-expose di seluruh internet.

Gue masukin IP publik target ke Shodan dan langsung kaget. Dari luar, IP itu keliatan bersih. Port 80 dan 443 doang yang kebuka, sisanya di-filter firewall. Tapi Shodan ngasih gue info tambahan yang gak keliatan dari scan biasa: teknologi di balik web server, versi tertentu dari nginx, dan yang paling penting: certificate transparency.

Certificates itu seperti kartu identitas server. Setiap kali server bikin SSL certificate, dia harus daftar ke public log, dan log itu bisa dicari. Gue pakai situs kayak crt.sh buat narik semua certificate yang pernah diterbitkan buat domain target. Dan di dalam certificate itu ada daftar nama — termasuk nama subdomain yang gak ke-link di mana-mana. Ini cara yang sah dan pasif buat nemuin subdomain, dan seringnya jauh lebih lengkap daripada brute-force subdomain.

Dari crt.sh, gue nemu beberapa subdomain yang gak gue kenal: ada yang kayak mail, vpn, staging, dan jenkins. Jenkins! Itu menarik banget. Jenkins adalah CI/CD server, dan kalau gak dikonfigurasi dengan baik, dia bisa jadi pintu masuk ke seluruh pipeline build. Gue catet semuanya. Masih belum nyentuh apa pun.

Jangan Lupa Media Sosial dan Forum

OSINT gak cuma soal infrastruktur. Kadang jawaban datang dari tempat yang paling gak diduga: media sosial dan forum. Banyak perusahaan yang karyawannya suka curhat di forum teknis atau grup Facebook. Mereka nanya soal cara deploy, error yang mereka hadapi, atau kadang tanpa sadar nyebutin nama internal tool.

Gue cari nama domain dan nama aplikasi mereka di Twitter, Reddit, dan forum-forum IT Indonesia. Dan ternyata, ada! Beberapa bulan lalu, ada developer yang nanya di forum tentang cara ngebenerin error deployment aplikasi internal mereka, dan di pertanyaannya dia nyantumin stack trace yang bocorin path internal: /opt/company-app/config/database.yml. Gak ada password di situ, tapi gue sekarang tau struktur direktori di server mereka. Itu ngasih gue peta awal buat nanti.

Media sosial juga berguna buat verifikasi nama orang dan nemuin akun-akun yang terhubung. Kadang orang pakai username yang sama di semua platform, dan dari username itu gue bisa nyari password yang pernah bocor di breach database publik. Ini bukan soal nge-hack orang, ini soal nge-verifikasi apakah password yang sama dipakai ulang di tempat kerja. Dan jawabannya seringkali: iya.

Nyusun Semua Jadi Satu Peta

Setelah dua malam full passive recon, gue punya peta yang lumayan lengkap:

  • Struktur organisasi tim IT, lengkap dengan nama dan peran
  • Tech stack yang mereka pakai (dari profil LinkedIn dan job posting)
  • Daftar subdomain, termasuk yang gak ke-link: dev, staging, jenkins
  • Struktur direktori internal (dari stack trace yang bocor)
  • Username database dan nama aplikasi (dari repo GitHub publik)
  • Endpoint lama yang masih hidup (dari Wayback Machine)

Ini semua didapet tanpa nyentuh target sama sekali. Gak ada satu pun paket yang dikirim ke IP mereka. Blue team mereka gak akan nemu apa-apa karena gak ada apa-apa yang bisa ditemuin. Dan ini poin pentingnya: OSINT yang baik bikin engagement berikutnya jadi jauh lebih cepat dan jauh lebih mungkin berhasil.

Dari Peta ke Aksi

Hari pertama engagement resmi dimulai, dan gue gak mulai dari scan besar-besaran. Gue langsung fokus ke subdomain dev.targetdomain.com yang gue temuin dari arsip DNS. Ternyata benar, subdomain itu masih hidup dan nge-host aplikasi development yang gak diproteksi sama WAF yang menjaga domain utama.

Aplikasi dev itu punya fitur debug yang aktif, dan dari situ gue bisa liat error stack yang nge-expose path file dan versi framework. Versi framework itu ternyata udah punya CVE publik yang gampang dieksploitasi. Gue gak perlu nembus WAF, gak perlu brute-force, gak perlu exploit yang ribet. Semua karena gue tau harus liat ke mana, dan itu semua berasal dari recon pasif yang gue lakuin dua malam sebelumnya.

Engagement itu selesai dalam tiga hari, bukan lima. Laporan gue ke klien fokus ke temuan utama: environment development yang gak terlindungi, dan proses mereka yang gak nge-manage subdomain dengan baik. Klien kaget karena dari luar mereka keliatan aman, padahal ada pintu belakang yang kebuka lebar-lebar.

Pelajaran yang Gak Pernah Gue Lupakan

Kalau gue harus nyimpulin pengalaman ini dalam beberapa poin (walaupun gue benci checklist, ini penting), intinya begini:

Pertama, passive recon itu bukan pelengkap, tapi fondasi. Engagement yang paling sukses sering kali ditentukan di fase yang paling gak keliatan. Semakin banyak yang lu tau sebelum nyentuh target, semakin sedikit yang harus lu tebak, dan semakin kecil kemungkinan lu ketahuan.

Kedua, OSINT itu soal nyambungin titik-titik. Satu PDF di Google, satu profil LinkedIn, satu repo GitHub, satu stack trace di forum — masing-masing keliatan remeh. Tapi kalau disusun, mereka jadi peta yang utuh. Kemampuan nyusun puzzle ini yang bedain red teamer biasa sama yang jago.

Ketiga, manusia adalah attack surface yang paling gak diprediksi. Server bisa di-patch, firewall bisa dikonfigurasi, tapi karyawan yang suka curhat di forum atau developer yang lupa ngapus repo publik gak akan pernah di-patch. OSINT itu pada dasarnya nyari tahu gimana manusia berinteraksi dengan teknologi mereka.

Keempat, tool itu cuma alat, pola pikir yang mutusin. Shodan, crt.sh, Wayback Machine, Google dorking — semua itu cuma alat. Yang bikin beda adalah cara lu mikir: di mana info bisa bocor, siapa yang mungkin gak sadar, dan apa yang bisa disambung dari potongan-potongan kecil.

Buat Lu yang Baru Mau Mulai

Kalau lu lagi belajar red team dan ngerasa bingung mulai dari mana, gue saranin mulai dari sini. Gak perlu langsung beli tool mahal atau server khusus. Buka browser, buka Google, dan mulai dari domain yang sah buat dipelajari (yang penting punya izin, jangan asal). Latihan nyusun profil perusahaan dari info publik. Cek Shodan buat liat apa yang ke-expose. Main sama Wayback Machine buat liat sejarah website. Ini semua gratis, gak berbahaya, dan ngajarin lu cara berpikir yang bakal kepake di seluruh karir red team lu.

OSINT itu bukan skill yang keliatan keren di demo, tapi dia adalah skill yang paling sering ngebuat engagement sukses atau gagal. Lu bisa hafal semua exploit, tapi kalau gak tau targetnya di mana dan gimana, semua itu gak ada gunanya. Sebaliknya, dengan OSINT yang baik, kadang lu gak perlu exploit sama sekali. Cukup tau di mana pintu yang lupa dikunci.

Dan itu, menurut gue, adalah bentuk kecerdasan yang paling elegan di dunia red team: bukan yang paling berisik, tapi yang paling tau.

Related Posts

Aug 30, 202612 min read

Server-Side Request Forgery: When the Server Becomes Your Unwitting Courier

Gue cerita soal pengalaman nemuin celah SSRF di fitur generator laporan klien, gimana server mereka sendiri gue suruh ambil data dari dalam jaringan internal, sampai kepoin metadata cloud yang seharusnya gak boleh kemana-mana.

ssrf·red-team·web-security·pentest
Read article
Aug 17, 202610 min read

SQL Injection: From a Broken Login Form to a Full Database Dump

Cerita gue waktu pertama kali nemu celah SQL injection di form login, gimana gue manfaatin kelemahan query database buat ngeluarin data yang seharusnya tertutup rapat, plus pelajaran buat nulis kode yang nggak gampang diretas.

sql-injection·web-security·red-team·penetration-testing
Read article
A
Arman Ridho

Cybersecurity & IT infrastructure professional building secure, reliable systems in Jakarta.

Navigate
  • Home
  • About
  • Skills
  • Projects
  • Contact
Explore
  • Experience
  • Certifications
  • Blog
  • Download CV
© 2026 Arman Ridho Maulana. All rights reserved.Built with Next.js & Gravity UI