Membaca Tech Stack dari Sinyal Publik

Adityo Guni Waluyo8 Oktober 202601.03

Recon pasif: peta tech stack dari subdomain, URL arsip, rekaman TXT, MX, nameserver, dan secret scan, tanpa satu paket pun ke target.

#security #dns #tooling #osint #subfinder #trufflehog #recon

Ringkasan

Jadi ini cerita soal recon pasif, cuma modal data publik tanpa nyentuh server target, udah bisa ketebakan tech stack suatu domain. Tapi hati-hati, banyak jebakan interpretasi, kayak rekaman TXT verifikasi Anthropic yang ternyata cuma bukti kepemilikan domain, bukan tanda pakai Claude. Intinya sinyal publik itu murah, disiplin bacanya yang penting, dan jangan pernah validasi secret atau nyentuh sistem.

Jam sepuluh malam, layar saya cuma menampilkan satu domain: cakradata.example, perusahaan fiktif yang saya pakai sebagai contoh sepanjang artikel ini. Nol paket dikirim ke server siapa pun. Tidak ada port scan, tidak ada request langsung, tidak ada interaksi dengan infrastruktur target. Yang ada cuma tab browser berisi data publik dan satu terminal. Dari bahan seadanya itu, saya bisa menyusun gambaran yang cukup meyakinkan soal tech stack di balik domain tersebut.

Di tengah jalan, saya nyaris terjebak satu kesimpulan yang salah. Ada rekaman TXT di DNS yang berawalan anthropic-domain-verification-. Dugaan pertama saya: perusahaan ini menjalankan Claude di produksi. Faktanya, token itu hanya membuktikan pemilik domain pernah memverifikasi kepemilikan domainnya ke Anthropic untuk alur SSO atau provisioning. WorkOS adalah penyedia domain verification untuk Anthropic, dan pelangganlah yang diminta menaruh rekaman TXT itu di DNS miliknya sendiri [1]. Kunci API untuk inferensi tidak pernah meninggalkan jejak di DNS publik. Verifikasi kepemilikan bukan bukti integrasi fungsional. Ini jebakan klasik recon pasif: kesimpulan yang dilompati satu langkah inferensi.

Peta permukaan dari sumber pihak ketiga

Langkah paling awal: subdomain. subfinder mengumpulkan subdomain dari sumber-sumber online pasif, mulai dari log certificate transparency sampai dataset keamanan, tanpa mengirim satu paket pun ke target [3]. Desain pasifnya dipasarkan sebagai kecepatan plus stealth [3], tapi bagi saya nilainya lebih sederhana: query saya mendarat di server pihak ketiga, bukan di depan pintu target.

Lapisan kedua: URL lama. gau menarik URL yang sudah dikenal dari AlienVault OTX, Wayback Machine, Common Crawl, dan URLScan untuk satu domain [5]. Jejak historis ini sering membuka endpoint staging yang terlupakan atau pola rute API yang tanpa sengaja membocorkan framework backend. OWASP WSTG mencatat kegiatan sejenis, dari discovery lewat mesin pencari sampai fingerprinting dan pemetaan arsitektur, sebagai praktik information gathering yang standar dan terdokumentasi [6]. Jadi ini bukan trik gelap; ini metodologi yang punya buku manual.

DNS: rekaman yang jujur, interpretasi yang gampang salah

Dua perintah pertama yang saya jalankan pada domain contoh:

# token verifikasi vendor dan rekaman TXT lain
dig TXT cakradata.example +short

# rute email masuk
dig MX cakradata.example +short

MX memberi sinyal vendor email yang relatif stabil. Nilai Google Workspace masa kini adalah smtp.google.com. Tapi domain yang mulai memakai Google Workspace sebelum 2023 bisa saja masih membawa set lima rekaman generasi lama yang berawalan aspmx, dan Google menyatakan nilai legacy itu masih didukung [2]. Fingerprint yang hanya mengenali nilai baru akan salah membaca domain legacy sebagai non-Google. Cocokkan kedua set dulu, baru simpulkan.

Header bisa bohong, nameserver jarang

Dari sisi HTTP, header Cf-Ray mengidentifikasi pusat data yang memproses request lewat kode tiga huruf [7]. Kedengarannya seperti tanda tangan Cloudflare yang tak terbantahkan. Bukan. Di Shopify yang CDN-nya sendiri didukung Cloudflare, header cf-ray atau server: cloudflare muncul di respons biasa dan tidak membuktikan apa pun soal pilihan infrastruktur merchant [8]. Pemeriksaan yang lebih bisa diandalkan ada di delegasi DNS:

# siapa yang mengelola zona domain ini
dig +short NS cakradata.example

Nameserver Cloudflare berarti zona dikelola di akun Cloudflare, prasyarat layanan proxying mereka [8]. Ini sinyal kuat, bukan bukti mutlak: setup partial berbasis CNAME bisa saja memakai Cloudflare tanpa memindahkan nameserver. Jadi jangan pernah menyimpulkan "tidak ada NS Cloudflare berarti tidak pakai Cloudflare".

Rahasia yang bocor dan garis yang tidak diseberangi

Artefak publik sering bocor lebih dari yang dimiliki. TruffleHog menemukan, mengklasifikasi, memvalidasi, dan menganalisis secret di git, wiki, log, object store, sampai filesystem, dengan lebih dari 800 tipe detektor [4]. Untuk postur pasif, aturannya satu kalimat: berhenti di discovery. Validasi berarti mencoba kredensial ke API vendor, dan itu aksi aktif yang meninggalkan log di sistem mereka. Begitu Anda mengirim request autentikasi memakai secret yang ditemukan, investigasi Anda bukan lagi pengamatan.

Soal etika dan hukum: kebijakan penuntutan CFAA versi DOJ menyebut penuntutan sebaiknya ditiadakan bila perilaku tergolong good faith security research, yaitu akses komputer murni untuk pengujian atau perbaikan kerentanan dengan itikad baik dan tanpa merugikan siapa pun [9]. Itu kebijakan penuntutan di yurisdiksi AS, bukan izin universal. Hormati batas scope, jangan validasi secret, dan laporkan temuan lewat kanal resmi. RFC 9116 menstandardkan security.txt supaya organisasi bisa mendeklarasikan cara pelaporan kerentanan dan peneliti mudah menemukannya [10].

Pendapat saya tegas di sini: sinyal publik itu murah, disiplin interpretasinya yang mahal. Kesalahan paling berbahaya dalam recon pasif bukan data yang kurang, melainkan kesimpulan yang dilompati satu langkah. Dan jarak antara membaca jejak dengan menyentuh sistem cuma sebesar satu request yang tidak perlu.