Asset Inventory Web: Domain, Subdomain, Org & ASN

Tujuan dari asset inventory di fase recon adalah membangun peta permukaan yang akurat: apa domain resminya, subdomain apa saja yang benar-benar hidup, siapa organisasi/AS (Autonomous System) yang “memayungi” alamat IP-nya, dan bagaimana semua itu saling terhubung. Tanpa peta ini, pengujian berikutnya cenderung boros waktu, noise, dan berisiko melewati batas. Dengan peta yang benar, kita bisa memutuskan di mana harus melanjutkan uji—secara aman dan tepat sasaran.

1) Menentukan “seed” yang valid

Semua berawal dari seed: domain utama yang in-scope beserta variasi brand yang wajar. Praktisnya, mulai dari beranda, dokumen legal, dan catatan WHOIS/RDAP untuk memastikan nama entitas hukumnya. Ini membantu menghindari salah sasaran (misalnya domain mirip yang ternyata milik pihak ketiga). Kalau ada TLD/ccTLD lain yang sah (contoh: .com, .id, .co.id), masukkan ke daftar seed, tetapi tetap tunduk pada scope tertulis.

Catatan etika: seed harus datang dari scope/izin. Jangan memperluas ke pihak ketiga (CDN/vendor) tanpa hubungan yang jelas.

2) Mengumpulkan subdomain secara pasif

Langkah berikutnya adalah menarik sinyal dari sumber publik. Certificate Transparency (CT) biasanya “mesin waktu” paling kaya, karena setiap sertifikat memuat nama host yang pernah divalidasi. Tool modern seperti subfinder dan amass bisa mencari banyak sumber (CT, DNS pasif, direktori web) tanpa interaksi agresif.

Contoh jalur pasif yang aman untuk satu domain:

# 1) Tarik kandidat subdomain dari berbagai sumber pasif

subfinder -d example.com -all -silent -o sub_raw.txt

# 2) Tambah sumber CT melalui amass (mode intel pasif)

amass enum -passive -d example.com -o amass_raw.txt

# 3) Gabung & deduplikasi

sort -u sub_raw.txt amass_raw.txt > subs_candidates.txt

Di sini belum ada “sentuhan” HTTP ke host. Kita baru menyusun kandidat dari arsip/inventaris publik.

3) Validasi resolusi DNS (konservatif)

Kandidat harus dibedakan antara “pernah ada di arsip” dan “masih aktif/alive hari ini”. Validasi minimal dilakukan di tingkat DNS, bukan HTTP. dnsx (ProjectDiscovery) atau massdns berguna untuk melakukan pengujian, asalkan laju dan tidak agresif. Tujuannya hanya mengetahui apakah sebuah nama host resolving—bukan memindai layanan.

# 4) Validasi DNS (apex & A/AAAA/CNAME) dengan laju pelan atau konfigurasi non-agresif

dnsx -silent -retry 1 -rl 50 -l subs_candidates.txt -o subs_resolved.txt

Parameter pentingnya adalah rate-limit (-rl) dan retry rendah. Kita sedang memverifikasi liveness, bukan melakukan discovery agresif. Hasilnya memberi dua kelas: nama yang resolusi DNS-nya valid, dan nama yang sekadar “jejak arsip publik”.

4) Liveness & fingerprint (optional, konservatif)

Bila benar-benar diperlukan untuk pemetaan teknologi permukaan, lakukan probing HTTP ringan pada host yang sudah terverifikasi resolusi DNS-nya. Batasi request ke arah HEAD/GET dengan User-Agent yang jelas, mengikuti redirect seperlunya, dan menyimpan header sebagai bukti. httpx memudahkan ini, selama kita disiplin dengan laju.

# 5) Cek liveness HTTP + beberapa sinyal aman

httpx -l subs_resolved.txt \

-silent -follow-redirects -mc 200,301,302,403,401 \

-title -tech-detect \

-H "User-Agent: EHAcademyRecon/1.0 (+contact: security@example.com)" \

-rl 25 \

-o http_lite.txt

Output dari https yang tersimpan berisi status, judul halaman, sedikit indikasi teknologi (fingerprint dari respons), dan URL final setelah redirect. Itu saja sudah cukup untuk mengisi peta dan menyusun prioritas—tanpa menyentuh area privat atau aksi state-changing.

5) Memetakan Organisasi & ASN (siapa di balik IP)

Setelah nama host terverifikasi, kita perlu memahami siapa yang mengelola alamat IP-nya. Di sinilah ASN dan prefix BGP dilakukan. Pada praktiknya, ada tiga tahap kecil:

1. Ambil IP dari host yang resolving (hasil dnsx/httpx).

2. Lakukan RDAP/WHOIS IP untuk mendapatkan Org, ASN, dan prefix (CIDR).

3. Kelompokkan host berdasarkan Org/ASN supaya terlihat pola kepemilikan (mis. on-prem, cloud region tertentu, atau CDN).

Tool untuk tahap ini adalah amass intel (punya mode organisasi/ASN) atau utilitas khusus seperti asnmap. Amass bisa mengekstrak ASN dari nama organisasi dan sebaliknya:

# 6) Dari nama entitas hukum → temukan ASN yang relevan

amass intel -org "Example Inc" -whois -o asn_by_org.txt

# 7) Dari domain → intel lanjutan (prefix/ASN yang sering muncul)

amass intel -d example.com -whois -o intel_by_domain.txt

Kalau ingin sangat eksplisit, kamu bisa memakai RDAP per-IP (via whois/rdap/API publik) lalu menulis skrip kecil untuk menormalkan kolom: ip, asn, org, prefix, cc, rir. Hasil akhirnya adalah tabel hubungan: “host A berada di ASN X (Org Y) pada prefix Z”—sangat berguna untuk memisahkan mana yang dikelola langsung vs. milik CDN/cloud.

Batas etika di tahap ASN: kita sekadar mencatat kepemilikan jaringan. Jangan langsung memindai seluruh prefix/ASN dengan pemindaian; itu sudah masuk wilayah scanning, bukan recon/enum.

6) Struktur data & bukti yang dapat diulang

Agar hasil inventory mudah dipakai ulang, simpan model data kecil per entitas seperti di bawah ini:

host: api.example.com

first_seen: 2025-08-16T09:30:12Z

last_seen: 2025-08-16T09:31:55Z

dns: A/AAAA ok

ip: 203.0.113.42

asn: AS64500

org: Example Inc (Cloud Region ap-southeast-1)

prefix: 203.0.113.0/24

http:

status: 200

final_url: https://api.example.com/v1/

title: "Example API"

notes: "tech-fingerprint: cloudfront?, hsts: present"

reason: "host aktif, kandidat prioritas uji API nanti"

Struktur ringkas seperti ini memudahkan triage, audit, dan delta tracking (misal: host yang tadinya aktif lalu tidak resolving lagi). Semua timestamp tersimpan dalam UTC, rapihkan folder per tanggal, dan setiap file perlu diberi nama deterministik agar rekan bisa mengulang atau tim kerja.

7) Otomasi basic yang aman

Bila proyeknya panjang, otomasi ringan /basic membantu—asal tetap konservatif. Rangkaian subfinder → dnsx → httpx adalah jalur minimal yang cukup. Semua tool itu mendukung rate-limit dan header kustom, sehingga tidak perlu agresif . Untuk organisasi besar, amass intel menghemat waktu saat memetakan ASN/prefix dan domain yang berafiliasi.

Satu contoh pipeline sederhana yang bisa di pakai dalam lab:

export UA='EHAcademyRecon/1.0 (+contact: security@example.com)'

subfinder -d example.com -all -silent \

| dnsx -silent -retry 1 -rl 50 \

| tee alive_hosts.txt \

| httpx -silent -follow-redirects -rl 25 -H "User-Agent: $UA" -title -tech-detect \

> http_inventory.txt

Pipeline ini tidak melakukan crawling masif, tidak menebak kredensial, dan tidak menyentuh metode state-changing. Cukup untuk menyusun peta permukaan dan prioritas uji.

8) Kesalahan umum yang sebaiknya dihindari

Dua hal paling sering mengacaukan inventory adalah kecepatan berlebihan dan pencampuran fase. Kecepatan membuat signal-to-noise turun dan berisiko dianggap mengganggu layanan. Pencampuran fase—misalnya tiba-tiba melakukan directory brute atau fuzzing—mendorong pekerjaan ke wilayah scanning sebelum peta/daftar selesai. Pegang lagi prinsipnya: peta dulu, daftar kemudian, uji belakangan.

Tentu dalam melakukan aktivitas seperi ini memerlukan pemahaman yang mendalam terkait dengan fundamental dalam melakukan recon agar tetap berada pada batas yang aman dan tidak mengganggu kesepakatan dengan organisasi atau perusahaan dengan memperhatikan etika dan mindset yang ada - Baca Juga Mindset dan Scope Recon.