#04 Subfinder + HTTPX: Subdomain Enumeration dan HTTP Probing untuk Reconnaissance

Reconnaissance web itu kadang mirip mencari alamat rumah di kompleks yang besar. Kita sudah tahu nama kompleksnya, tetapi belum tentu tahu ada berapa bangunan, pintu mana yang aktif, dan mana yang sebenarnya cuma gudang lama yang lupa dibongkar.

Di dunia web security, situasinya mirip. Sebuah organisasi mungkin punya domain utama example.test, tetapi attack surface-nya bisa tersebar ke app.example.test, api.example.test, dev.example.test, status.example.test, sampai hostname lama yang sudah jarang diingat tim internal.

Di artikel #04 Red Team Cheat Sheet Series, kita akan menggabungkan dua tool dari ProjectDiscovery: Subfinder untuk subdomain discovery dan httpx untuk HTTP probing. Kombinasi ini berguna untuk mengubah daftar hostname mentah menjadi inventory web yang lebih mudah dianalisis.

Scope tetap nomor satu. Gunakan contoh dan command di artikel ini hanya pada domain milik sendiri, lab, CTF, atau environment yang secara eksplisit masuk authorization. Menemukan hostname bukan berarti otomatis mendapat izin menguji semuanya.

Kenapa Subdomain Enumeration Penting?

Kalau hanya melihat website utama, kita mungkin melewatkan sebagian besar web attack surface.

Organisasi modern sering punya banyak aplikasi:

www.example.test
portal.example.test
api.example.test
helpdesk.example.test
staging.example.test
status.example.test

Masalahnya, lifecycle aplikasi tidak selalu rapi. Project baru muncul, project lama ditinggalkan, DNS record masih tersisa, staging server lupa dimatikan, atau aplikasi internal tanpa sengaja terekspos.

Jadi pertanyaan reconnaissance bukan cuma:

“Website utamanya pakai apa?”

Tetapi:

“Hostname apa saja yang berhubungan dengan scope, dan mana yang benar-benar melayani HTTP/HTTPS?”

Di sinilah Subfinder dan httpx saling melengkapi.

Subfinder dan httpx Punya Tugas Berbeda

Subfinder berfokus pada passive subdomain enumeration. Ia mengumpulkan hostname dari berbagai sumber yang tersedia tanpa harus melakukan brute-force agresif terhadap target.

httpx kemudian menerima hostname atau URL dan melakukan HTTP probing untuk melihat endpoint mana yang merespons serta metadata HTTP yang relevan.

Workflow sederhananya:

Domain Scope
    ↓
Subfinder
    ↓
Hostname List
    ↓
httpx
    ↓
Live HTTP Services
    ↓
Focused Enumeration

Subfinder menjawab “hostname apa yang ditemukan?”.

httpx membantu menjawab “mana yang benar-benar berbicara HTTP dan seperti apa responsnya?”.

Jangan dicampur. Obeng dan tang sama-sama ada di toolbox, tetapi pekerjaannya beda.

Setup Lab

Untuk latihan, gunakan domain yang memang Anda kontrol. Contoh di artikel ini menggunakan:

example.test

Anggap lab memiliki beberapa hostname:

www.example.test
api.example.test
staging.example.test
status.example.test

Jika menggunakan environment lokal, Anda dapat mengatur DNS internal atau /etc/hosts. Untuk simulasi yang lebih realistis, gunakan domain lab sendiri dengan DNS record yang sengaja dibuat untuk pembelajaran.

Instalasi Subfinder

ProjectDiscovery mendistribusikan Subfinder sebagai tool berbasis Go. Ikuti dokumentasi instalasi resmi untuk versi terkini.

Setelah terpasang, cek:

subfinder -version

Lihat opsi yang tersedia:

subfinder -h

Ini kebiasaan yang bagus. Jangan menghafalkan flag dari artikel lama jika tool aktif dikembangkan. -h sering lebih jujur daripada ingatan kita sendiri.

Instalasi httpx

Setelah httpx terpasang, verifikasi:

httpx -version

Dan lihat help:

httpx -h

Perlu diperhatikan bahwa nama httpx juga digunakan project/library lain. Pastikan yang dipasang adalah httpx dari ProjectDiscovery ketika mengikuti workflow artikel ini.

1. Passive Subdomain Enumeration

Penggunaan dasar Subfinder:

subfinder -d example.test

Output dapat berbentuk:

www.example.test
api.example.test
status.example.test
staging.example.test

Pada tahap ini kita baru mempunyai candidate hostnames.

Jangan langsung menyimpulkan semua hostname aktif, dapat dijangkau, atau termasuk target pengujian mendalam. DNS dan asset lifecycle suka meninggalkan jejak masa lalu.

2. Simpan Hasil Discovery

Jangan biarkan hasil reconnaissance hanya hidup di terminal.

subfinder -d example.test -o subdomains.txt

Sekarang kita mempunyai artifact yang dapat digunakan pada tahap berikutnya.

Contoh:

subdomains.txt

File ini juga membantu reproducibility. Kalau besok hasil berubah, kita bisa membandingkan inventory lama dan baru.

3. Multiple Domains dalam Scope

Dalam assessment organisasi, scope kadang mempunyai beberapa root domain.

Daripada menjalankan command manual berulang kali, siapkan file domain sesuai scope dan gunakan kemampuan input yang tersedia pada versi tool Anda.

Prinsipnya:

scope-domains.txt
        ↓
    Subfinder
        ↓
all-subdomains.txt

Pastikan file input hanya berisi domain yang memang diotorisasi. Automation itu hebat sampai typo ikut diautomasi.

4. Dari Hostname ke HTTP Service

Sekarang kita punya daftar hostname. Pertanyaan berikutnya:

Mana yang melayani HTTP atau HTTPS?

Masukkan hasil ke httpx:

cat subdomains.txt | httpx

Atau gunakan mekanisme input file sesuai opsi versi httpx yang digunakan.

Output akan menyaring daftar menjadi endpoint HTTP yang merespons.

Misalnya:

https://www.example.test
https://api.example.test
http://staging.example.test
https://status.example.test

Nah, sekarang inventory kita mulai lebih berguna.

5. Pipeline Subfinder → httpx

Untuk reconnaissance cepat di lab:

subfinder -d example.test -silent | httpx -silent

-silent berguna untuk menghasilkan output yang lebih bersih pada pipeline.

Tetapi untuk assessment serius, saya lebih suka menyimpan hasil setiap tahap:

subfinder -d example.test -silent -o subdomains.txt
cat subdomains.txt | httpx -silent > live-web.txt

Kenapa?

Karena kita punya dua evidence terpisah:

subdomains.txt   -> hostname yang ditemukan
live-web.txt     -> HTTP endpoint yang merespons

Debugging dan reporting jadi jauh lebih waras.

6. Ambil Status Code

HTTP status code memberi konteks awal.

Dengan opsi yang sesuai pada httpx, kita dapat menampilkan status code bersama endpoint.

Secara konseptual hasilnya seperti:

https://www.example.test       [200]
https://api.example.test       [401]
https://staging.example.test   [403]
https://old.example.test       [404]

Jangan terjebak mentalitas:

200 = menarik
404 = buang

Response 401, 403, redirect, bahkan 404 yang konsisten dapat memberikan informasi tentang bagaimana aplikasi atau reverse proxy dikonfigurasi.

Status code adalah signal, bukan verdict.

7. Title dan Metadata HTTP

Page title sering membantu triage inventory.

Bayangkan kita punya 80 endpoint. Mana yang ingin diperiksa lebih dulu?

Metadata dapat membantu membedakan:

Customer Portal
Grafana
API Documentation
Status Dashboard
Development Environment

Tetapi jangan menjadikan title sebagai identitas absolut. Title mudah diubah dan kadang sama sekali tidak menggambarkan aplikasi sebenarnya.

Gunakan sebagai petunjuk untuk prioritas manual review.

8. Technology Detection: Berguna, Tapi Jangan Mabuk Fingerprint

HTTP probing dapat membantu mengidentifikasi teknologi yang tampak digunakan aplikasi.

Misalnya kita mendapatkan indikasi:

nginx
React
WordPress
Grafana

Informasi ini berguna untuk attack surface mapping.

Namun fingerprint bukan fakta final. CDN, reverse proxy, WAF, custom header, atau konfigurasi aplikasi dapat membuat hasil tidak lengkap atau menyesatkan.

Prinsipnya sama seperti Nmap:

automation menemukan petunjuk, analyst memverifikasi konteks.

9. Filter dan Triage

Begitu inventory membesar, masalah berubah.

Awalnya kita bertanya:

“Ada host apa saja?”

Setelah ratusan hasil muncul:

“Oke... mana yang harus saya lihat dulu?”

Triage dapat mempertimbangkan:

• HTTP status;
• page title;
• teknologi;
• hostname pattern;
• environment marker seperti dev, test, atau staging;
• service yang berkaitan dengan authentication;
• endpoint administratif;
• asset yang berbeda dari baseline organisasi.

Tetapi hati-hati dengan hostname seperti dev atau staging. Nama itu bukan bukti vulnerability.

staging.example.test bisa saja dikonfigurasi lebih ketat daripada production.

Kita menggunakannya sebagai prioritization signal, bukan vonis.

Cheat Sheet Cepat

Berikut workflow dasar yang aman untuk lab dan authorized assessment:

# Cek Subfinder
subfinder -version

# Lihat help
subfinder -h

# Passive subdomain enumeration
subfinder -d example.test

# Simpan hasil
subfinder -d example.test -silent -o subdomains.txt

# Cek httpx
httpx -version

# Lihat help
httpx -h

# Probe hostname hasil discovery
cat subdomains.txt | httpx -silent

# Simpan live HTTP endpoints
cat subdomains.txt | httpx -silent > live-web.txt

# Pipeline sederhana
subfinder -d example.test -silent | httpx -silent

Untuk flag metadata seperti status code, title, technology detection, redirect, JSON output, concurrency, atau rate limit, selalu cocokkan dengan httpx -h dan dokumentasi resmi versi yang digunakan.

Kenapa saya tidak menumpuk semua flag menjadi satu command monster?

Karena command 14 flag memang terlihat keren di screenshot, tetapi sering menyulitkan troubleshooting dan membuat kita lupa apa yang sebenarnya sedang diukur.

Workflow Reconnaissance yang Lebih Rapi

Mari susun pipeline yang lebih profesional.

Tahap 1 — Validasi Scope

Buat daftar root domain yang diizinkan:

example.test

Catat exclusion jika ada.

Tahap 2 — Passive Discovery

subfinder -d example.test -silent -o subdomains.txt

Tahap 3 — Review dan Normalisasi

Periksa hasil sebelum meneruskannya ke tahap aktif.

Ini penting jika assessment mempunyai batasan tertentu terhadap third-party infrastructure atau hostname yang dikelola vendor.

Tahap 4 — HTTP Probing

cat subdomains.txt | httpx -silent > live-web.txt

Tahap 5 — Enrichment

Tambahkan metadata HTTP yang relevan menggunakan opsi versi httpx yang sedang digunakan.

Tujuannya bukan mengumpulkan semua informasi yang bisa dikumpulkan. Tujuannya memperoleh data yang membantu menentukan prioritas berikutnya.

Tahap 6 — Focused Enumeration

Endpoint yang relevan baru diteruskan ke tahap berikutnya, misalnya manual review atau FFUF untuk content discovery jika termasuk scope.

Alurnya:

Subfinder
   ↓
Hostnames
   ↓
Scope Validation
   ↓
httpx
   ↓
HTTP Metadata
   ↓
Triage
   ↓
Focused Enumeration

Studi Kasus: Staging yang Terlupakan

Bayangkan assessment terhadap domain perusahaan menghasilkan:

www.example.test
api.example.test
status.example.test
staging-old.example.test

Setelah HTTP probing:

www.example.test          -> aplikasi utama
api.example.test          -> API dengan authentication
status.example.test       -> status page
staging-old.example.test  -> masih merespons HTTP

Temuan pentingnya bukan otomatis:

“Ada staging! Vulnerable!”

Belum tentu.

Pertanyaan yang benar:

• siapa owner staging-old?
• apakah asset masih diperlukan?
• apakah authentication diterapkan?
• apakah data production pernah masuk ke sana?
• apakah patching mengikuti lifecycle production?
• apakah monitoring mencakup asset tersebut?
• apakah DNS record seharusnya masih ada?

Setelah validasi, bisa saja masalah sebenarnya adalah asset lifecycle management.

Ini jauh lebih berguna daripada laporan dramatis bertuliskan “STAGING SERVER FOUND!!!” dengan tiga tanda seru.

Attack → Evidence → Detection → Hardening

Sekarang kita lihat workflow ini dari dua sisi.

Attack / Activity

Assessor melakukan passive subdomain discovery lalu HTTP probing terhadap hostname yang berada dalam scope.

Evidence

Pada sisi organisasi, HTTP probing dapat menghasilkan:

• request dari satu source ke banyak virtual host;
• request dalam interval relatif pendek;
• koneksi ke hostname yang jarang diakses user normal;
• request terhadap asset lama atau environment non-production;
• pola User-Agent atau karakteristik request tertentu tergantung tool dan konfigurasi.

Passive discovery sendiri dapat meninggalkan telemetry yang jauh lebih sedikit pada target karena data berasal dari sumber eksternal/passive. Tetapi tahap probing adalah interaksi aktif dengan service.

Detection

Blue Team dapat melihat data dari:

• reverse proxy logs;
• web server access logs;
• WAF;
• CDN logs;
• DNS telemetry;
• firewall atau NDR;
• SIEM correlation.

Detection yang matang tidak sekadar berbunyi:

“Satu IP mengakses banyak subdomain = attacker.”

Asset inventory scanner, monitoring system, uptime checker, dan vulnerability scanner bisa melakukan hal serupa.

Context tetap raja.

Hardening

Hasil reconnaissance dapat diterjemahkan menjadi perbaikan nyata:

• hapus DNS record yang tidak diperlukan;
• matikan aplikasi yang sudah end-of-life;
• pastikan staging/dev tidak terekspos tanpa kebutuhan;
• gunakan authentication yang sesuai;
• pisahkan data production dan non-production;
• terapkan patching lifecycle yang konsisten;
• masukkan seluruh public-facing asset ke monitoring;
• tetapkan ownership setiap hostname;
• review certificate dan DNS inventory secara berkala.

Attack surface yang tidak diketahui defender biasanya menjadi attack surface yang sulit dipertahankan.

Perspektif Blue Team: Coba Lakukan Hal yang Sama

Salah satu latihan Purple Team yang menarik justru sederhana:

Jalankan asset discovery terhadap domain organisasi sendiri, lalu bandingkan hasilnya dengan CMDB atau inventory resmi.

Jika Subfinder menemukan 120 hostname tetapi inventory resmi hanya mengenal 73, pertanyaannya bukan langsung “47 sisanya attacker punya”.

Pertanyaannya:

“Kenapa inventory kita berbeda?”

Kemungkinan penyebabnya bisa berupa:

• DNS record lama;
• asset vendor;
• SaaS;
• shadow IT;
• environment testing;
• hostname historis;
• inventory internal yang belum diperbarui.

Gap antara known assets dan observable assets sendiri sudah merupakan informasi security yang sangat berharga.

Rate Limit dan Operational Safety

httpx dapat melakukan probing dengan cepat. Cepat itu menyenangkan, tetapi production bukan benchmark arena.

Dalam authorized assessment:

• sesuaikan concurrency dan rate dengan Rules of Engagement;
• hindari traffic burst yang tidak diperlukan;
• pahami kapasitas aplikasi lama;
• koordinasikan assessment window;
• hentikan aktivitas jika ada indikasi service degradation.

Tujuan kita memperoleh evidence, bukan membuktikan bahwa server 2009 bisa dibuat ngos-ngosan.

Best Practices

Simpan Output per Tahap

Gunakan file terpisah:

01-subdomains.txt
02-live-http.txt
03-enriched-http.json
04-review-notes.md

Nama file membosankan tapi jelas akan menang melawan hasil-final-final2.txt setiap saat.

Jangan Hilangkan Scope Validation

Passive source dapat menemukan hostname yang berhubungan dengan third party atau infrastructure di luar scope.

Discovery bukan authorization.

Gunakan Structured Output Jika Tersedia

Untuk automation dan reporting, JSON atau structured output biasanya lebih berguna daripada parsing teks terminal secara kreatif.

Deduplicate

Recon pipeline dapat menggabungkan beberapa sumber. Normalisasi dan deduplicate sebelum tahap berikutnya agar tidak menghasilkan request berulang tanpa manfaat.

Catat Timestamp

Attack surface berubah. Host yang aktif hari ini belum tentu aktif bulan depan.

Jangan Percaya Satu Tool

Subfinder adalah bagian dari discovery process, bukan oracle DNS.

Tidak menemukan hostname bukan bukti hostname tidak ada.

Hubungan dengan Artikel Sebelumnya

Kalau mengikuti seri dari awal, sekarang puzzle reconnaissance mulai tersambung.

#01 Nmap membantu kita memahami host, port, dan service.

#02 FFUF membantu content discovery pada web application yang sudah kita ketahui.

#03 Naabu membantu fast port discovery dan kemudian meneruskan hasil penting ke Nmap untuk service enumeration.

Sekarang #04 Subfinder + HTTPX membantu menemukan subdomain dan menyaring mana yang benar-benar memiliki HTTP service.

Salah satu pipeline konseptualnya dapat terlihat seperti:

Root Domain
    ↓
Subfinder
    ↓
HTTP Probing
    ↓
Web Targets
    ↓
FFUF / Manual Review

Network Scope
    ↓
Naabu
    ↓
Nmap
    ↓
Service Enumeration

Tidak semua engagement membutuhkan semua tool. Pilih berdasarkan objective, bukan karena ingin terminal terlihat sibuk.

Kesalahan Umum

Menganggap Semua Subdomain Masuk Scope

Ini kesalahan paling berbahaya secara governance.

Selalu validasi scope sebelum active probing.

Menganggap Hostname dev Pasti Lemah

Nama environment hanyalah petunjuk.

Mengejar Quantity

Menemukan 10.000 hostname tidak berguna jika kita tidak bisa menjelaskan mana yang relevan.

Tidak Menyimpan Raw Result

Tanpa raw result, kita kehilangan kemampuan membandingkan perubahan dan memverifikasi pipeline.

Menjalankan Probing Terlalu Agresif

Fast tool tetap harus tunduk pada operational safety.

Lupa Perspektif Defender

Kalau reconnaissance menemukan asset yang tim internal bahkan tidak tahu keberadaannya, itu mungkin temuan yang lebih penting daripada versi framework yang dipakai website.

Penutup

Subfinder dan httpx adalah pasangan yang sangat berguna karena keduanya menjawab dua pertanyaan berbeda tetapi berurutan:

Apa hostname yang terlihat dari luar?

lalu:

Mana yang benar-benar memberikan HTTP response?

Dari sana kita mulai membangun web attack surface yang lebih realistis.

Tetapi jangan berhenti pada daftar URL. Reconnaissance yang matang harus berakhir pada pemahaman: siapa pemilik asset, apakah asset masih diperlukan, bagaimana exposure-nya, apakah dimonitor, dan apakah konfigurasi sesuai policy.

Karena pada akhirnya, subdomain paling menarik bukan selalu yang punya vulnerability paling keren.

Kadang yang paling menarik justru satu hostname lama yang membuat semua orang di meeting bertanya:

“Eh... itu server punya siapa?”

Dan biasanya, di situlah cerita mulai seru.

Artikel berikutnya dalam seri akan masuk ke #05 SQLMap Cheat Sheet: SQL Injection Testing untuk Authorized Security Assessment.

Sumber Resmi

• ProjectDiscovery Subfinder Documentation — https://docs.projectdiscovery.io/opensource/subfinder/overview
• ProjectDiscovery Subfinder GitHub — https://github.com/projectdiscovery/subfinder
• ProjectDiscovery httpx Documentation — https://docs.projectdiscovery.io/opensource/httpx/overview
• ProjectDiscovery httpx GitHub — https://github.com/projectdiscovery/httpx
• OWASP Web Security Testing Guide — https://owasp.org/www-project-web-security-testing-guide/