URL Discovery dari Arsip (Wayback/GAU) + Robots/Sitemap: Panduan Teknis (2025)

Admin Agustus 22, 2025 Comment

Admin

Mengapa “URL Discovery dari Arsip” tetap krusial di 2025

Buat security research, DFIR, competitive intel, kita butuh peta URL yang lengkap—bukan hanya yang “terlihat” hari ini. Arsip web menyimpan jejak struktur lama, sedangkan sitemap/robots memberi daftar resmi dari pemilik situs. Menggabungkan keduanya menghasilkan inventaris URL yang kaya konteks dan bisa ditindaklanjuti.

Sumber data & apa yang kita tarik atau kita cari

1) Wayback Machine (CDX API)

CDX API mengembalikan indeks tangkapan (capture) dengan filter fleksibel: pola kecocokan (domain/prefix/host), rentang waktu, status HTTP, format JSON, serta fitur collapse untuk kurangi duplikasi. Ideal untuk memetakan evolusi struktur URL per domain yang ada sekarang maupun yang sudah lama untuk melihat perbandingan atau melihat kemungkinan tulisan non-publik terekspos.

curl 'https://web.archive.org/cdx/search/cdx url=*.example.com/*&matchType=domain&from=2015&to=2025&filter=statuscode:200&output=json&collapse=urlkey'

Catatan: pola wildcard dan matchType sama-sama didukung; jangan set keduanya bertentangan.

2) GAU (GetAllUrls)

GAU mengumpulkan URL dari beberapa sumber publik: AlienVault OTX, Wayback Machine, Common Crawl, dan URLScan. Cocok untuk seed collection cepat sebelum disaring/dinormalisasi.

go install github.com/lc/gau/v2/cmd/gau@latest

printf 'example.com' | gau --subs --providers wayback,commoncrawl,otx,urlscan --o gau_raw.txt

Referensi paket & opsi bawaan tersedia di dokumentasi GAU.

3) Robots.txt & Sitemap (daftar resmi)

robots.txt: mendefinisikan izin crawl berbasis path (Allow, Disallow). Lokasi harus di akar host: https://example.com/robots.txt.
Sitemap: format XML standar (<urlset>, <url>, <loc>, opsional <lastmod>). Bisa dideklarasikan via baris Sitemap: di robots.txt atau diserahkan melalui Search Console.

4) Common Crawl (opsional)

Indeks Common Crawl bisa diquery untuk riwayat fetch berskala besar; ada klien & API indeks untuk mengambil daftar URL terkait domain tertentu.

5) Memento (opsional, versi per waktu)

Protokol Memento (RFC 7089) menyediakan datetime negotiation, TimeGate, dan TimeMap untuk mengambil representasi halaman di waktu tertentu—berguna untuk verifikasi kontekstual.

Workflow praktis: dari pengumpulan sampai siap pakai.

1. Tarik historis via CDX API

Mulai dari cakupan domain atau host.
Filter status (mis. statuscode:200) dan batasi rentang tahun agar fokus.
Gunakan collapse=urlkey untuk deduplikasi awal.

2. Gabungkan dengan GAU

Jalankan --subs untuk menyertakan subdomain.
Gunakan --providers untuk transparansi asal data.
Saring ekstensi biner non-prioritas (gambar/font) agar hemat proses.

3. Tarik daftar resmi dari sitemap

Ambil lokasi sitemap dari robots.txt (Sitemap:).
Unduh semua sitemap (termasuk sitemap-index), parse <loc>, gabungkan.

4. Normalisasi & deduplikasi

Samakan skema (prefer https), lowercase host, hapus fragmen #, urutkan query param jika diperlukan.
Sort-unique untuk hilangkan duplikasi.
Simpan sumber asal per-URL (CDX/GAU/Sitemap) untuk traceability.

5. Skoring prioritas (rekomendasi)

Konsensus lintas sumber: URL yang muncul di CDX+GAU+Sitemap > prioritas.
Kebaruan: jadikan timestamp capture Wayback terbaru sebagai sinyal.
Kedalaman path: path terlalu dalam sering bernilai lebih rendah untuk tahap awal.

6. Validasi bertahap & enrichment secukupnya

Liveness check dengan rate limiting ketat.
Pencarian teknologi hanya pada sampel prioritas dan patuhi robots saat melakukan active crawl.

Masalah umum & cara antisipasi

Duplikasi berlebihan → pakai collapse di CDX, normalize agresif, dan source vote.
Sitemap tidak ditemukan → cek robots.txt; jika kosong, coba lokasi umum /<sitemap>.xml atau submit via Search Console.
Perbedaan interpretasi robots antar crawler → tetap uji pada crawler target; sintaks bisa ditafsirkan berbeda.

Menggabungkan Wayback/CDX, GAU, dan robots.txt/sitemap menghasilkan peta URL yang jauh lebih lengkap dibanding crawling biasa. Banyak endpoint warisan dan jalur tersembunyi yang muncul, sementara pendekatannya tetap pasif, terukur, dan mudah direplikasi.

Nilai kunci ada di traceability: tiap URL punya asal-usul yang jelas (arsip vs daftar resmi), dari waktu ke waktu, dan frekuensi kemunculan lintas sumber. Dengan normalisasi, deduplikasi, dan skoring (konsensus lintas sumber, kebaruan, kedalaman path), hasilnya bukan sekadar daftar, melainkan inventaris siap aksi—mulai dari liveness check, review konfigurasi, sampai prioritisasi pengujian.

Secara praktis, jadikan proses ini pipeline berkala: tarik data (CDX/GAU/sitemap), bersihkan dan beri skor, simpan bersama metadata, lalu audit batch berisiko tinggi lebih dulu. Attack surface map tetap aktual mengikuti perubahan situs, sambil menjaga etika: rate-limit, hormati robots saat crawl aktif, dan dokumentasikan parameter. Hasil akhirnya: kerja security/SEO lebih presisi, lebih cepat, dan lebih bertanggung jawab.

GitHub Dork untuk Artefak Publik: Pola Pencarian Repo/Issue/Release (2025)

Admin Agustus 20, 2025 Comment

Admin

Kenapa GitHub Dork Penting

Banyak organisasi menempatkan dokumen publik di GitHub: SECURITY.md, CHANGELOG, ROADMAP, CONTRIBUTING, workflow CI/CD, hingga issue/PR bertema rilis. Dengan GitHub dork (pencarian lanjutan di GitHub), kita dapat:

Memahami arsitektur dan keputusan teknis (ADR, Architecture).

Melihat timeline rilis, deprecations, dan kebijakan integrasi (API/SDK) yang dipublikasikan resmi. Menganalisis proses (review, CODEOWNERS, linting, matrix build) tanpa menyentuh data sensitif.

Dasar-Dasar Pencarian Lanjutan (Qualifier yang Stabil)

Qualifier	Fungsi	Contoh singkat
`org:`	Batasi ke organisasi	`org:example`
`user:`	Batasi ke pengguna	`user:exampledev`
`repo:`	Batasi ke satu repo	`repo:example/app`
`in:`	Bidang (`name`, `description`, `readme`, `title`, `body`)	`in:readme "API reference"`
`path:`	Filter direktori	`repo:example/app path:docs/`
`filename:`	Nama file tepat	`filename:SECURITY.md org:example`
`language:`	Bahasa pemrograman	`language:Go org:example`
`extension:`	Ekstensi file	`extension:md path:docs/`
`is:`	`issue`, `pr`, `open`, `closed`, `merged`, `archived`	`is:pr is:merged org:example`
`label:`	Label issue/PR	`label:security org:example`
`author:` `assignee:` `mentions:`	Berdasar aktor	`author:alice is:pr org:example`
`created:` `updated:` `pushed:`	Filter waktu	`updated:>=2025-01-01 org:example`
`topic:`	Topic repo	`topic:sre org:example`
`stars:` `forks:` `size:`	Opsional kurasi	`stars:>100 org:example`

Tips akurasi:

Gabungkan qualifier untuk presisi (org + path + filename).

Gunakan updated:/pushed: untuk kebaruan.

Untuk issue/PR, tambahkan is:open/is:closed/is:merged sesuai kebutuhan.

Area artefak yang “aman” atau harus dicek:

1. Kebijakan & tata kelola: SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SUPPORT.md, MAINTAINERS.md.

2. Arsitektur & desain: ARCHITECTURE.md, ADR, docs/architecture/system-design.

3. Rilis & perubahan: CHANGELOG.md, PR berjudul “release notes”, migration/upgrade guide.

4. Proses & toolchain: .github/workflows/*.yml, CODEOWNERS, aturan lint/format.

5. Roadmap & RFC: ROADMAP.md, issue berlabel roadmap, PR/issue berjudul RFC/proposal.

6. API & integrasi (dokumen): OpenAPI/Swagger, rate limit, webhook signature.

Peta Kebutuhan Recon → Pola Query

Kebutuhan	Apa yang dicari	Contoh pola
Kebijakan keamanan & pelaporan	SECURITY, disclosure, bug bounty	`org:example (filename:SECURITY.md OR "responsible disclosure" in:file)`
Proses kontribusi & kode etik	CONTRIBUTING, CODE_OF_CONDUCT	`org:example (filename:CONTRIBUTING.md OR filename:CODE_OF_CONDUCT.md)`
Arsitektur & keputusan desain	ARCHITECTURE, ADR, system design	`org:example (filename:ARCHITECTURE.md OR "Architecture Decision Record")`
Rilis & perubahan	CHANGELOG, release notes, breaking change	`org:example (filename:CHANGELOG.md OR in:title "release notes") is:pr`
Deprecation & migrasi	deprecation, migration/upgrade guide	`repo:example/app updated:>=2025-01-01 in:file ("migration guide" OR "upgrade guide")`
API & integrasi	OpenAPI/Swagger, rate limit, webhooks	`org:example path:docs/ in:file ("OpenAPI" OR "Swagger" OR "rate limit" OR webhook)`
Proses CI/CD	GitHub Actions workflows, matrix	`org:example path:.github/workflows extension:yml in:file "uses:"`
Tata kelola repo	CODEOWNERS, maintainers	`org:example filename:CODEOWNERS in:file`
Roadmap & prioritas	ROADMAP, milestone, RFC/proposal	`org:example (filename:ROADMAP.md OR in:title roadmap) OR (is:issue in:title (RFC OR proposal))`

Template Query:

1) Dokumen Kebijakan & Proses

org:example (filename:SECURITY.md OR filename:CONTRIBUTING.md OR filename:CODE_OF_CONDUCT.md OR filename:SUPPORT.md OR filename:MAINTAINERS.md)

2) Arsitektur & ADR

org:example (filename:ARCHITECTURE.md OR "Architecture Decision Record" OR filename:ADR.md) path:docs/ extension:md

org:example in:readme ("architecture" OR "system design" OR "ADR")

3) Rilis, Deprecation, Migrasi

org:example (filename:CHANGELOG.md OR "release notes" in:title) extension:md

org:example in:title "release notes" is:pr

repo:example/app updated:>=2025-01-01 in:file ("deprecation" OR "breaking change" OR "migration guide" OR "upgrade guide")

4) Issue & PR untuk Insight Non-Sensitif

org:example is:issue is:open label:bug in:title (timeout OR crash OR overflow)

org:example is:issue in:title (oauth OR oidc OR "rate limit")

org:example is:pr in:title (refactor OR harden OR "security policy")

5) Proses & Toolchain (CI/CD)

org:example path:.github/workflows extension:yml in:file "uses:"

org:example filename:CODEOWNERS in:file

6) API & Integrasi (Dokumentasi Resmi)

org:example path:docs/ in:file ("OpenAPI" OR "Swagger" OR "API reference" OR "rate limit" OR "webhook")

7) Roadmap, RFC, Proposal

org:example (filename:ROADMAP.md OR in:title roadmap)

org:example is:issue in:title ("RFC" OR "proposal")

org:example in:file ("milestone" OR "Q1" OR "quarter") path:docs/

Dengan qualifier yang tepat, pola pencarian fokus artefak publik, dan disiplin validasi konteks, Anda memperoleh gambaran teknis yang mau dicapai.

Baca Juga Tentang Cyber Attack, Data Breach, Vulnerabilities

Google Dork untuk Web Recon: Panduan Etis & Efektif (2025)

Admin Agustus 20, 2025 Comment

Admin

“Google dorking” (advanced search) adalah teknik memanfaatkan operator pencarian untuk menemukan informasi publik yang relevan. Dalam konteks ethical hacking, dork digunakan untuk web recon awal: memahami struktur situs, dokumentasi, teknologi, dan artefak yang memang dimaksudkan untuk konsumsi publik. Artikel ini menyajikan operator inti, pola aman, workflow terstruktur, dan template query yang mematuhi etika: tanpa PII dan hanya pada target yang berizin (mis. program bug bounty).

Batas Etis & Legal

Selalu patuhi ToS target, ruang lingkup bug bounty, dan hukum setempat.
Tujuan Anda: memahami permukaan serangan secara pasif—bukan mengeksploitasi.

Operator	Fungsi	Contoh ringkas
`site:`	Batasi ke domain/subdomain	`site:example.com`
`inurl:`	Cari potongan kata di URL	`inurl:docs site:example.com`
`intitle:`	Judul halaman mengandung kata	`intitle:"release notes" site:example.com`
`intext:`	Isi halaman mengandung kata	`intext:"API reference" site:example.com`
`filetype:` / `ext:`	Filter tipe file	`filetype:pdf site:example.com`
`"` (kutip)	Padanan persis frasa	`"privacy policy" site:example.com`
`-` (minus)	Kecualikan kata/frasa	`site:example.com -blog`
`OR` / `()`	Kombinasi logika	`(intitle:changelog OR intitle:"release notes") site:example.com`
`AROUND(n)`	Kedekatan kata	`"API" AROUND(3) "authentication" site:example.com`
`before:`/`after:`	Rentang tanggal	`site:example.com after:2024-01-01`

Catatan: Hindari operator yang usang/inkonsisten; fokus pada daftar di atas untuk kestabilan.

Pola Aman (Tanpa PII) untuk Web Recon

Prinsip:

Batasi cakupan dengan site: dan gunakan subdomain spesifik bila perlu.
Eksklusi proaktif istilah sensitif dengan - (mis. -password, -token, -apikey, -secret, -confidential).
Fokus pada konten yang memang dirilis publik: dokumentasi, catatan rilis, kebijakan, halaman status, karier, press, blog teknis.

site:example.com -password -token -apikey -secret -confidential

Workflow Etis & Terstruktur untuk Recon Pasif

1) Pemetaan Domain & Struktur Umum

Tujuan: memahami hierarki konten, area produk, dan dokumentasi publik.

site:example.com

site:blog.example.com

site:docs.example.com

site:example.com inurl:support

2) Inventaris Konten Publik (PDF/Doc/Slides)

Tujuan: menemukan panduan, kebijakan, whitepaper, datasheet.

filetype:pdf site:example.com "privacy"

filetype:pdf site:example.com "user guide"

filetype:pdf site:example.com "architecture"

3) Dokumen Teknis & Changelog

Tujuan: memahami fitur, versi, dan perubahan yang berdampak keamanan (secara konseptual).

(intitle:changelog OR intitle:"release notes") site:example.com

"deprecation" AROUND(4) "API" site:docs.example.com

after:2024-01-01 "breaking change" site:docs.example.com

4) Identifikasi Teknologi (Non-invasif)

Tujuan: mengenali stack/kerangka kerja lewat jejak publik (bukan probing agresif).

inurl:wp- site:example.com // indikasi WordPress (publik)

intext:"powered by" site:example.com // klaim teknologi pada footer

"GraphQL" AROUND(3) "documentation" site:docs.example.com

5) Endpoint Publik & Praktik Integrasi (Hanya Dokumentasi)

Tujuan: memahami pola endpoint resmi yang terdokumentasi.

site:docs.example.com "API reference"

inurl:api site:example.com "rate limit"

"oauth" AROUND(3) "scope" site:docs.example.com

6) Aturan Penelusuran & Peta Situs (Informasi Umum)

Tujuan: melihat area konten yang diindeks/diarahkan.

site:example.com robots.txt

site:example.com sitemap.xml

7) Status Layanan & Insiden Publik

Tujuan: memantau stabilitas/riwayat (untuk risk profiling tingkat tinggi).

site:status.example.com

site:example.com "status page"

8) Monitoring Perubahan Konten

Ini bisa dilakukan dengan membuat Google Alert pada kombinasi kata kunci yang aman (mis. "release notes" site:example.com).

Berikut merupakan Template yang siap untuk di pakai atau digunakan untuk melihat cara kerja google dorking pada target dan mengukur sejauh mana query yang kita pakai bisa digunakan, karena google dorking ini juga tergantung pada proses indeks dari google search engine, dimana untuk melihat pemetaan lebih lanjut bisa dipriksa di setiap sitemap.xml pada website terget masing-masing untuk menguji kemungkinan yang bisa terindeks ke search engine selain daripada konten website.

site:example.com "privacy policy"

site:example.com (intitle:docs OR inurl:docs)

site:docs.example.com "API reference"

site:example.com (intitle:careers OR inurl:careers)

site:example.com (intitle:security OR "security policy")

site:example.com "responsible disclosure"

site:example.com "terms of service" OR "acceptable use"

site:example.com "cookie policy"

site:example.com "brand guidelines" filetype:pdf

site:example.com "release notes" after:2024-01-01

site:example.com "changelog" AROUND(4) "security"

site:example.com inurl:support "troubleshooting"

site:example.com inurl:legal

site:example.com "service level" OR "SLA"

site:example.com "data processing addendum" OR DPA filetype:pdf

site:example.com "architecture overview" filetype:pdf

site:example.com "oauth" AROUND(5) "scope"

site:example.com "rate limit" AROUND(3) "API"

site:example.com "webhook" AROUND(4) "signature"

site:example.com "deprecation" AROUND(3) "timeline"

FAQ.

Apakah Google dork sama dengan OSINT?
Dorking adalah subset OSINT yang berfokus pada optimalisasi mesin pencari. OSINT lebih luas mencakup banyak sumber lain.

Bolehkah saya menggunakan dork pada perusahaan acak?
Tidak. Gunakan hanya pada scope berizin (mis. bug bounty) dan hindari PII/sensitif.

Kenapa hasil saya berbeda-beda?
Personalisasi, lokasi, bahasa, dan tanggal memengaruhi. Tambahkan after:/before: dan kata kunci bahasa Inggris/Indonesia.

HTTP Probing & Tech Fingerprinting

Admin Agustus 18, 2025 Comment

Admin

Cek liveness, status, header, teknologi, indikasi WAF, dan sinyal versi—untuk prioritas uji yang rapi.

Recon yang baik tidak berhenti di enumerasi subdomain. Begitu kamu punya daftar host in-scope, tahap berikutnya adalah HTTP probing & tech fingerprinting: memastikan host benar-benar hidup, membaca status/redirect, mengamati header dan kebijakan keamanan, mengidentifikasi tumpukan teknologi yang tampak dari luar, dan menangkap indikasi WAF/CDN. Semua ini dilakukan konservatif—tanpa login, tanpa aksi yang mengubah state, dan tanpa “menekan” layanan. Tujuannya satu: menghasilkan peta prioritas yang akurat untuk tahap pengujian berikutnya.

Liveness & redirect:

Mulai dari satu host untuk memastikan liveness dan melihat rantai redirect yang sebenarnya terjadi.

# Liveness + header ringkas (tanpa body)

curl -I https://www.target.tld/ --max-time 8 \

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

# Liveness + ikuti redirect sampai final

curl -s -D- -o /dev/null -L https://www.target.tld/ --max-time 12 \

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

Hal yang kamu catat:

Status code konsisten (200/301/302/401/403/404).
Location: di setiap langkah redirect (http→https, apex→www, /→/home).
Keseragaman HTTPS dan canonical URL (bagus untuk SEO & keamanan).

Untuk banyak host sekaligus, gunakan HTTP toolkit yang mendukung batch dengan throttle.

# Batch probing yang konservatif

httpx -l subs_resolved.txt \

-silent -follow-redirects \

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

-rl 25 \

-status-code -title -web-server -tech-detect \

-o http_probe.txt

Catatan: opsi -rl 25 membatasi laju (≈25 req/detik total). Sesuaikan lebih rendah bila aset sensitif atau scope meminta kehati-hatian ekstra atau limit terbatas agar tidak menganggu atau tidak agresif.

Header & kebijakan keamanan: sinyal kualitas permukaan

Header sering lebih akurat daripada HTML. Beberapa yang bernilai untuk triage:

server / x-powered-by / via: indikasi upstream (nginx/Apache), app stack (Express, PHP), dan proxy/CDN.

strict-transport-security (HSTS): disiplin HTTPS (ada/tidak, max-age).

content-security-policy (CSP): kontrol resource loading; hadirnya CSP umumnya sinyal kematangan.

x-frame-options, referrer-policy, x-content-type-options: kebijakan baseline.

set-cookie: atribut Secure, HttpOnly, SameSite (tanpa menyentuh isi yang sensitif).

cache-control / vary / etag: pola caching.

Tech fingerprinting:

Fingerprints bisa di deteksi pada:

Header (mis. server: cloudflare, x-aws-apigw-id, x-akamai-*, x-github-request-id).
HTML meta (generator, framework hints).
Judul halaman (-title berguna untuk klasifikasi cepat).
Aset statis publik (nama bundel, path pattern)—cukup dicatat, tanpa mengunduh berlebihan.

Toolkit seperti httpx membantu memberi label teknologi indikatif (-tech-detect). Ingat: ini indikasi, bukan bukti final—cukup untuk memutuskan apakah host masuk High/Med/Low prioritas uji berikutnya.

Indikasi WAF/CDN:

CDN/WAF sering meninggalkan tanda:

Header khas: cf-ray, cf-cache-status (Cloudflare), x-akamai-* (Akamai), x-cache, x-amz-cf-id (CloudFront), x-sucuri-id, dll.
Perilaku: challenge page, rate-limit ringan, 403 generik yang konsisten di banyak rute.

TLS singkat (permukaan saja)

# Ambil sertifikat & info dasar (read-only)

openssl s_client -servername www.target.tld -connect www.target.tld:443 </dev/null 2>/dev/null \

| openssl x509 -noout -subject -issuer -dates

Ambil yang relevan: masa berlaku, issuer, dan cocokkan SAN dengan host final. Jika HSTS aktif kuat (di header), catat juga—ini sinyal keamanan yang baik. Hindari alat scanning agresif pada fase ini; sisakan untuk modul TLS khusus.

Model data: apa yang perlu disimpan

host: api.target.tld

checked_at: 2025-08-19T11:02:33Z

final_url: https://api.target.tld/v1/

status: 200

redirect_chain:

- http://api.target.tld/ -> https://api.target.tld/

- https://api.target.tld/ -> https://api.target.tld/v1/

headers:

server: "nginx"

strict-transport-security: "max-age=31536000; includeSubDomains"

content-security-policy: "default-src 'self'"

via: "1.1 varnish (CDN?)"

tech:

server: nginx

app_hint: "Express?" # indikasi, bukan kepastian

waf_cdn: "CDN present (via, x-cache)"

priority: High # untuk tahap uji nanti

reason: "API publik, HSTS on, ada CDN; kandidat uji input handling"

Struktur seperti ini membuat laporan clean dan memudahkan delta tracking (apa yang berubah antar sesi).

Menyusun prioritas:

Tujuan probing adalah prioritisasi. Contoh kriteria praktis:

High: endpoint API publik aktif, judul/route mengindikasikan layanan kritikal, legacy path di redirect chain; header memperlihatkan stack yang menarik untuk uji input.
Medium: aplikasi umum dengan kebijakan keamanan baseline yang cukup baik; tetap perlu uji spesifik.
Low: halaman informatif/marketing dengan CSP/HSTS solid dan sedikit permukaan dinamis.

Tulis alasannya singkat—“High karena API publik + legacy redirect + server banner.” Alasan yang jelas mempercepat handoff ke tahap pengujian.

Asset Inventory Web: Domain, Subdomain, Org & ASN

Admin Agustus 15, 2025 Comment

Admin

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.

Mindset, Scope & Etika Web Recon - Ethical Hacking Indonesia Academy

Admin Agustus 15, 2025 Comment

Admin

Mindset: Recon itu Pemetaan, Bukan Eksploit

Di dunia pengujian keamanan, web recon sering disalahpahami sebagai momen untuk “mencari celah” sejak detik pertama. Padahal recon yang benar adalah pemetaan permukaan web—usaha sistematis untuk memahami apa saja yang terlihat publik dari sebuah aset, bagaimana ia disusun, dan ke mana arah pengujian berikutnya harus dibawa. Ibarat survei lokasi sebelum membangun, kita mengukur tanah, membaca kontur, mencatat akses jalan. Kita belum menggali, belum memasang pondasi. Fokusnya adalah konteks.

Tujuan yang Tunggal dan Jelas: Peta Permukaan Web

Hasil akhir recon bukan flag, bukan proof-of-concept, melainkan peta. Peta itu memuat inventaris domain dan subdomain yang benar-benar aktif, jejak teknologi yang tampak dari luar (server, CDN/WAF, framework), rute atau endpoint yang wajar dijelajahi publik, serta prioritas awal untuk tahap uji berikutnya. Tanpa peta yang baik, pengujian mudah melebar, menyentuh area yang tidak relevan, atau—yang lebih berbahaya—menyeberang ke wilayah privat.

Dalam praktik harian, peta dibangun dari sinyal ringan. Kamu memulai dari beranda, mengamati respons, mengikuti pengalihan, menilai konsistensi HTTPS, hingga mencatat header yang mengindikasikan tumpukan teknologi. Kamu melihat sitemap dan robots untuk memahami struktur resmi, meninjau arsip publik guna menemukan rute historis, lalu membaca berkas JavaScript yang memang publik untuk mengenali pola endpoint tanpa menyentuh data sensitif. Semua ini adalah langkah-langkah pemetaan, bukan eksploitasi.

Prinsip Kerja yang Menjaga Etika dan Kualitas Hasil

Minimal interaction

Recon bertumpu pada interaksi serendah mungkin. Secara teknis, itu berarti membatasi diri pada permintaan HEAD atau GET terhadap konten publik, menghindari alur login, dan tidak melakukan tindakan yang mengubah keadaan (no state-changing). Tujuannya bukan takut—melainkan menghormati batas, menjaga kestabilan layanan, dan memastikan semua temuan bisa dibenarkan.

Contoh sederhana yang cukup informatif:

curl -I https://target.tld/ --max-time 8 \ -H "User-Agent: EHAcademyRecon/1.0 (+contact: security@example.com)"

curl : utilitas di Linux maupun Windows (Linux Default)

Satu baris ini sudah memberi banyak sinyal: status, jejak reverse proxy atau CDN di header, petunjuk cache, hingga pola pengalihan. Jika kamu butuh melihat halaman publik tertentu, gunakan GET seperlunya—tetap tanpa parameter aneh, tanpa menyentuh area yang berpotensi privat.

Passive-first

Mulailah dari sumber pasif: sitemap, robots, arsip publik, dokumentasi resmi, hingga kode klien (JS/CSS) yang terbuka. Cara ini memberi cakupan luas dengan risiko minimal. Ketika kamu menggunakan teknik seperti Google dork atau GitHub dork, perlakukan keduanya sebagai penemuan petunjuk, bukan alat untuk mengekstrak data sensitif. Begitu pratinjau menyinggung hal pribadi atau material non-publik, cukup catat indikasinya—jangan dibuka, jangan diunduh.

Reproducible

Setiap langkah harus bisa diulang dan diverifikasi. Catat URL final (setelah pengalihan), ringkas header relevan, timestamp dalam UTC, dan alasan kenapa item itu penting untuk pengujian selanjutnya. Simpan semuanya dengan penamaan konsisten—misalnya recon-web/2025-08-16/www.target.tld/headers.txt dan noted.md Tanpa reproduktibilitas, hasil recon sulit dipakai tim lain dan sulit dipertanggungjawabkan.

Batas Aman: Kapan Harus Berhenti

Recon yang sehat punya rem darurat. Berhentilah saat berhadapan dengan indikasi PII, kredensial, dump basis data, atau halaman yang jelas-jelas bukan konsumsi publik. Jangan “iseng melihat sebentar”—itu justru menggeser recon dari pemetaan ke akses yang tidak semestinya. Tindakan yang benar adalah menghentikan interaksi, menuliskan URL dan waktu, menjelaskan kenapa item ini berisiko, lalu—bila benar-benar perlu bukti visual—mengambil tangkapan layar yang ter-redaksi. Rekomendasi mitigasi sebaiknya bersifat server-side (misalnya menonaktifkan directory listing atau memindahkan arsip lama ke penyimpanan privat), karena robots tidak pernah dimaksudkan sebagai pengaman.

Seperti Apa Sesi Recon yang Baik?

Satu sesi yang ideal biasanya melewati jalur pendek ini: menyiapkan scope dan otorisasi; membaca halaman depan dan memeriksa rantai pengalihan; memotret header untuk menilai teknologi dan kebijakan keamanan di permukaan; meninjau sitemap, robots, dan arsip untuk memperkaya daftar rute; ringkas berkas JavaScript publik untuk mengenali nama endpoint atau basis URL API; Simpan dengan catatan terstruktur tentang apa yang ada, apa artinya, dan apa prioritas selanjutnya. Tidak ada brute force, tidak ada bypass login, tidak ada pengambilan file yang meragukan—hanya pemetaan yang bersih dan bisa diulang.

Perbedaan Mendasar: Passive vs Active dalam Web Recon

Dalam kerangka recon = pemetaan permukaan, “passive” dan “active” bukan dua kubu yang saling meniadakan, melainkan dua tahap kerja yang berurutan. Passive dipakai untuk membangun gambaran luas secara aman; Active (secara ringan/konservatif) dipakai untuk mengonfirmasi hipotesis dari tahap pasif—tanpa melangkah ke eksploitasi.

Apa itu Passive Recon

Passive recon mengandalkan informasi yang sudah tersedia publik tanpa (atau dengan nyaris nol) interaksi ke server target. Contohnya: membaca sitemap.xml dan robots.txt untuk memetakan rute resmi; meninjau arsip web/snapshot untuk melihat halaman yang pernah ada; mengamati berkas JavaScript publik untuk mengenali nama endpoint atau base URL API; meninjau data DNS/CT untuk indikasi subdomain.
Karakter utamanya: cakupan luas, risiko sangat rendah, jejak minimal. Kelemahannya: data bisa bersifat indikatif (kadang usang), sehingga butuh konfirmasi sebelum diprioritaskan untuk pengujian lanjutan.

Apa itu Active Recon

Active recon berarti berinteraksi langsung dengan aset—namun secara konservatif dan tetap berada di zona “pemetaan”. Tujuannya bukan menyerang, melainkan memastikan temuan pasif: apakah host benar-benar hidup, bagaimana rantai redirect berlangsung, apa header keamanan yang dipasang, apakah ada jejak CDN/WAF, dan sebagainya. Praktik aman di tahap ini umumnya dibatasi pada HTTP HEAD/GET terhadap konten publik, resolusi DNS yang wajar, serta inspeksi header/TLS yang tidak mengubah state aplikasi.
Karakter utamanya: memberi kepastian aktual (ground truth hari ini), namun punya jejak interaksi dan karenanya perlu disiplin: User-Agent jelas, rate limit pelan, timeout wajar, dan stop-conditions yang ketat.

Kenapa Mindset Ini Penting?

Karena kualitas konteks menentukan kualitas pengujian. Pemetaan yang teliti memperpendek waktu menuju temuan yang valid, mengurangi kebisingan, dan menjaga integritas proses. Di mata pemilik aset, kamu terlihat profesional: menghormati batas, tertib mendokumentasi, dan selalu menempatkan keamanan pengguna di atas rasa penasaran teknis. Di mata mesin pencari, artikel dan dokumentasi yang kamu hasilkan pun bernilai—terstruktur, kaya istilah relevan seperti pemetaan permukaan web, inventaris aset web, dan fingerprint teknologi, namun tetap natural dan informatif.