FFUF Cheat Sheet: Content Discovery dan Web Fuzzing untuk Security Assessment

Kalau Nmap membantu kita bertanya “service apa yang hidup di host ini?”, FFUF membantu melanjutkan obrolan dengan web application: “sebenarnya ada apa saja di balik URL ini?”

Dan sering kali jawabannya lebih menarik daripada halaman depan.

Artikel #02 Red Team Cheat Sheet Series ini membahas FFUF (Fuzz Faster U Fool) untuk content discovery dan web fuzzing dalam lab atau security assessment yang memiliki authorization. Kita tidak sekadar menghafal ffuf -w ... -u .../FUZZ, tetapi memahami apa yang sedang diuji, bagaimana membaca response, kapan hasilnya menipu, dan bagaimana Blue Team dapat mendeteksi serta mengurangi attack surface yang ditemukan.

Aturan main: gunakan FFUF hanya pada aplikasi milik sendiri, lab/CTF, atau target yang secara eksplisit masuk scope assessment. Fuzzing dapat menghasilkan request dalam jumlah besar. Jangan mengubah production menjadi benchmark dadakan hanya karena lupa mengatur rate.

FFUF Itu Apa?

FFUF adalah web fuzzer berbasis Go yang dirancang cepat dan fleksibel. Kata fuzzing di sini jangan langsung dibayangkan sebagai aktivitas misterius. Secara sederhana, kita memberikan sekumpulan kandidat input—biasanya dari wordlist—kemudian FFUF memasukkan kandidat tersebut ke posisi yang ditandai dengan keyword FUZZ.

Contoh paling sederhana:

ffuf -w words.txt -u http://10.10.10.20/FUZZ

Jika words.txt berisi:

admin
login
backup
api

FFUF akan mencoba request seperti:

http://10.10.10.20/admin
http://10.10.10.20/login
http://10.10.10.20/backup
http://10.10.10.20/api

Sederhana? Ya.

Tetapi nilai FFUF bukan pada kemampuan mengganti kata FUZZ. Nilainya ada pada kemampuan kita membedakan response yang menarik dari ribuan response yang sebenarnya cuma noise.

Content Discovery Bukan Sekadar “Cari Folder Rahasia”

Istilah directory brute forcing masih sering dipakai, tetapi content discovery lebih tepat karena targetnya tidak selalu directory.

Kita mungkin menemukan:

endpoint API;
file konfigurasi yang terekspos;
backup file;
development endpoint;
halaman administrasi;
file lama yang belum dihapus;
virtual host;
parameter yang tidak terdokumentasi;
variasi extension file;
route aplikasi yang tidak muncul di navigasi.

Penting: ditemukan tidak otomatis berarti vulnerable.

Misalnya /admin memberikan HTTP 200. Itu baru evidence bahwa resource tersebut dapat dijangkau. Kita masih harus bertanya apakah authentication bekerja, apakah endpoint memang seharusnya publik, dan apakah ada exposure informasi sensitif.

Jangan sampai setiap HTTP 200 diperlakukan seperti menemukan harta karun.

Setup Lab

Untuk latihan, gunakan aplikasi web lokal atau vulnerable application yang memang dibuat untuk pembelajaran.

Contoh environment:

Attacker : 10.10.10.5
Web Lab  : 10.10.10.20
Base URL : http://10.10.10.20

Pastikan target benar-benar berada dalam lab atau scope yang diotorisasi.

Instalasi FFUF

Pada Kali Linux, FFUF biasanya tersedia melalui package manager:

sudo apt update
sudo apt install ffuf

Jika Go sudah tersedia, instalasi juga dapat dilakukan sesuai dokumentasi resmi project.

Cek:

ffuf -V

Untuk wordlist, SecLists adalah salah satu collection populer untuk security testing. Gunakan wordlist yang sesuai konteks; semakin besar wordlist bukan otomatis semakin pintar assessment-nya.

Anatomy Command FFUF

Mari mulai dari:

ffuf -w words.txt -u http://10.10.10.20/FUZZ

Ada tiga bagian utama:

`-w words.txt`

Menentukan wordlist.

`-u`

Menentukan target URL.

`FUZZ`

Menentukan posisi tempat setiap value dari wordlist akan dimasukkan.

Keyword FUZZ adalah jantung mekanisme FFUF. Dan ia tidak harus berada pada path URL. Nanti kita bisa meletakkannya pada header, parameter, host, atau bagian request lain sesuai kebutuhan assessment.

1. Basic Content Discovery

ffuf -w words.txt -u http://10.10.10.20/FUZZ

Output FFUF biasanya memberikan informasi seperti:

HTTP status code;
response size;
jumlah words;
jumlah lines;
duration;
value yang diuji.

Di sinilah kita mulai belajar bahwa status code saja tidak cukup.

Dua endpoint dapat sama-sama memberikan 200, tetapi satu memiliki response 8 KB sementara yang lain hanya 120 byte. Perbedaan ukuran dapat menjadi petunjuk bahwa response-nya berbeda.

2. Cari File dengan Extension Tertentu

Kadang kita ingin menguji kandidat file dengan extension tertentu:

ffuf -w words.txt -u http://10.10.10.20/FUZZ.php

Atau menggunakan extension list:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -e .php,.html,.txt

Gunakan extension berdasarkan teknologi yang sudah kita ketahui dari reconnaissance.

Kalau aplikasi jelas berbasis stack tertentu, wordlist dan extension dapat dibuat lebih terarah. Menembakkan semua extension yang pernah diciptakan manusia biasanya hanya menghasilkan noise dan traffic tambahan.

3. Memilih Status Code yang Ditampilkan

FFUF dapat melakukan matching berdasarkan status code.

Contoh:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -mc 200,204,301,302,307,401,403

-mc berarti match HTTP status codes tertentu.

Jangan hanya tertarik pada 200.

301 atau 302 dapat menunjukkan redirect ke resource lain. 401 berarti resource mungkin membutuhkan authentication. 403 bahkan bisa sangat menarik karena server mengakui resource tersebut tetapi menolak akses dari request kita.

Sekali lagi: menarik untuk dianalisis, bukan otomatis vulnerable.

4. Filter Noise dengan Status Code

Kalau server menghasilkan status tertentu untuk response yang tidak menarik:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -fc 404

-fc berarti filter status code.

Tetapi modern web application sering tidak memberikan 404 yang bersih. Ada aplikasi yang mengembalikan 200 OK bahkan untuk path yang tidak ada.

Contohnya:

/ini-jelas-tidak-ada-12345 -> 200 OK
/admin                    -> 200 OK

Kalau hanya melihat status code, hasil kita penuh false positive.

Di sinilah response filtering menjadi penting.

5. Filter Berdasarkan Response Size

Misalnya semua halaman yang tidak ada menghasilkan response berukuran 4242 byte.

Kita dapat memfilter ukuran tersebut:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -fs 4242

-fs berarti filter response size.

Ini salah satu trik paling berguna saat berhadapan dengan custom error page.

Sebelum scanning besar, coba request path random terlebih dahulu:

/this-should-not-exist-983472

Perhatikan status code, size, words, dan lines. Itu memberi kita baseline response untuk resource yang tidak ada.

Baseline dulu, fuzzing kemudian. Lebih hemat waktu daripada menatap 15.000 false positive sambil mempertanyakan pilihan hidup.

6. Filter Berdasarkan Words atau Lines

FFUF juga dapat memfilter berdasarkan jumlah words atau lines.

Contoh konsep:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -fw 42

atau:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -fl 12

Ini berguna ketika ukuran response berubah sedikit karena dynamic content tetapi struktur response masih relatif konsisten.

Prinsipnya bukan mencari filter sebanyak mungkin. Kita mencari karakteristik response noise, lalu menghilangkannya.

7. Auto Calibration

FFUF menyediakan auto-calibration:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -ac

-ac membantu mengkalibrasi filtering berdasarkan response target.

Fitur ini praktis, tetapi jangan menjadikannya alasan untuk berhenti membaca response secara manual. Automation membantu, bukan menggantikan reasoning.

8. Recursive Discovery

Jika ditemukan directory, FFUF dapat melakukan recursion sesuai opsi yang tersedia:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -recursion

Gunakan recursion dengan hati-hati.

Directory discovery yang semula satu level dapat berkembang menjadi request dalam jumlah jauh lebih besar. Di production, itu dapat meningkatkan beban aplikasi dan membuat log tumbuh cepat.

Tetapkan depth dan rate sesuai RoE serta kebutuhan assessment.

9. Mengatur Threads dan Rate

Kecepatan FFUF memang salah satu daya tariknya. Tetapi dalam assessment profesional, kecepatan maksimum bukan selalu target.

FFUF menyediakan pengaturan concurrency dan rate. Salah satu opsi yang berguna adalah membatasi request rate:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -rate 20

Artinya kita membatasi jumlah request per detik sesuai nilai yang ditentukan.

Mengapa penting?

Karena aplikasi production mungkin berada di belakang API gateway, WAF, rate limiter, legacy backend, atau database yang tidak senang menerima hujan request.

Red Team yang baik mencoba menemukan weakness tanpa menciptakan outage bonus.

10. Fuzzing Parameter GET

Keyword FUZZ dapat ditempatkan pada parameter.

Dalam lab, misalnya kita ingin menguji kandidat nama parameter pada endpoint yang memang termasuk scope:

ffuf -w params.txt -u 'http://10.10.10.20/search?FUZZ=test'

Tujuannya adalah menemukan apakah aplikasi merespons berbeda ketika parameter tertentu digunakan.

Di sini response comparison menjadi sangat penting karena aplikasi mungkin selalu mengembalikan 200.

Bandingkan size, words, lines, dan isi response untuk melihat apakah input benar-benar memengaruhi behavior aplikasi.

11. Fuzzing Value Parameter

Jika nama parameter sudah diketahui:

ffuf -w values.txt -u 'http://10.10.10.20/item?id=FUZZ'

Ini menunjukkan fleksibilitas FFUF: FUZZ dapat mewakili bagian input yang ingin diuji.

Namun jangan menganggap setiap perubahan response berarti vulnerability. Bisa saja kita hanya menemukan object atau route yang memang dirancang untuk diakses.

Validation tetap diperlukan.

12. Virtual Host Discovery

Pada lab atau authorized environment, FFUF juga dapat digunakan untuk menguji kandidat virtual host dengan memodifikasi Host header.

Contoh pola:

ffuf -w subdomains.txt -u http://10.10.10.20/ -H 'Host: FUZZ.lab.local'

Ini berguna ketika beberapa application menggunakan IP yang sama tetapi dibedakan berdasarkan virtual host.

Perhatikan response size dan content karena server default dapat memberikan response yang sama untuk hostname yang tidak valid.

Lagi-lagi: baseline adalah teman kita.

13. Menggunakan Request Header

Header tambahan dapat diberikan dengan -H.

Contoh pada lab:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -H 'Authorization: Bearer LAB_TOKEN'

Ini berguna ketika content discovery dilakukan pada bagian aplikasi yang memang membutuhkan authentication dan credential testing sudah disediakan dalam RoE.

Jangan memasukkan production token ke command history sembarangan. Credential hygiene tetap berlaku meskipun kita sedang melakukan security testing.

14. Menggunakan Cookie

Untuk authenticated lab session, cookie dapat diberikan sesuai opsi FFUF, misalnya melalui header:

ffuf -w words.txt -u http://10.10.10.20/FUZZ -H 'Cookie: session=LAB_SESSION_VALUE'

Authenticated content discovery sering menghasilkan attack surface yang berbeda dari anonymous discovery.

Aplikasi mungkin mempunyai route internal yang hanya muncul setelah login tetapi tetap perlu diuji authorization-nya.

15. POST Request dalam Lab

FFUF juga dapat digunakan dengan method dan request body tertentu.

Contoh sederhana pada endpoint lab:

ffuf -w values.txt \
  -u http://10.10.10.20/api/search \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{"query":"FUZZ"}'

Tujuannya bukan menembakkan payload berbahaya, tetapi menunjukkan bahwa posisi FUZZ dapat berada di request body.

Dengan begitu FFUF dapat digunakan untuk menguji input space yang jauh lebih luas daripada sekadar directory discovery.

Cheat Sheet FFUF

Berikut ringkasan command yang layak disimpan:

# Basic content discovery
ffuf -w words.txt -u http://10.10.10.20/FUZZ

# Add extensions
ffuf -w words.txt -u http://10.10.10.20/FUZZ -e .php,.html,.txt

# Match selected status codes
ffuf -w words.txt -u http://10.10.10.20/FUZZ -mc 200,204,301,302,307,401,403

# Filter 404
ffuf -w words.txt -u http://10.10.10.20/FUZZ -fc 404

# Filter response size
ffuf -w words.txt -u http://10.10.10.20/FUZZ -fs 4242

# Auto calibration
ffuf -w words.txt -u http://10.10.10.20/FUZZ -ac

# Rate limit
ffuf -w words.txt -u http://10.10.10.20/FUZZ -rate 20

# Parameter-name discovery in lab
ffuf -w params.txt -u 'http://10.10.10.20/search?FUZZ=test'

# Parameter-value fuzzing
ffuf -w values.txt -u 'http://10.10.10.20/item?id=FUZZ'

# Virtual host discovery
ffuf -w subdomains.txt -u http://10.10.10.20/ -H 'Host: FUZZ.lab.local'

# Authenticated content discovery
ffuf -w words.txt -u http://10.10.10.20/FUZZ -H 'Authorization: Bearer LAB_TOKEN'

Jangan jadikan cheat sheet sebagai mesin copy-paste otomatis. Pahami baseline dan response terlebih dahulu.

Workflow FFUF yang Lebih Rapi

Saya lebih menyukai workflow berikut daripada langsung menjalankan wordlist raksasa.

Tahap 1 — Reconnaissance

Sebelumnya, dari artikel #01 Nmap Cheat Sheet, kita sudah mengetahui bahwa web service tersedia.

Misalnya:

80/tcp  open  http
443/tcp open  https

Sekarang pindah dari network enumeration ke application enumeration.

Tahap 2 — Manual Baseline

Buka halaman normal dan path random yang jelas tidak ada.

Catat:

status code;
response size;
redirect behavior;
error template;
authentication behavior.

Tahap 3 — Wordlist Kecil dan Relevan

Mulai dengan wordlist yang masuk akal untuk teknologi target.

Jangan langsung memakai jutaan entry jika 2.000 kandidat terarah sudah cukup menjawab pertanyaan awal.

Tahap 4 — Filter Noise

Gunakan -fc, -fs, -fw, -fl, atau -ac berdasarkan karakteristik baseline.

Tahap 5 — Validate Temuan

Periksa resource menarik secara manual.

Apakah benar berbeda? Apakah membutuhkan authentication? Apakah hanya redirect? Apakah informasi yang tampil sensitif?

Tahap 6 — Dokumentasikan

Simpan command, waktu, target, wordlist, filter, dan temuan yang relevan.

Wordlist adalah bagian penting evidence karena hasil fuzzing sangat bergantung pada input yang digunakan.

Studi Kasus: `/backup` Ketemu, Lalu Apa?

Bayangkan FFUF menghasilkan:

admin      [Status: 302]
api        [Status: 200]
backup     [Status: 403]
old        [Status: 301]

Operator scanner mungkin langsung senang melihat empat hasil.

Security assessor harus melakukan triage.

`/admin` — 302

Redirect ke mana? Ke login page? Ke homepage? Redirect sendiri bukan vulnerability.

`/api` — 200

Apa response-nya? API documentation? Health endpoint? Public API yang memang seharusnya tersedia?

`/backup` — 403

Menarik. Server mengakui resource tersebut tetapi akses ditolak. Apakah directory ini memang diperlukan berada di web root? Apakah konfigurasi deployment meninggalkan artifact yang tidak seharusnya ada?

`/old` — 301

Redirect ke /old/. Apakah ini aplikasi versi lama yang masih aktif? Jika iya, lifecycle dan patch status perlu diperiksa.

Lihat polanya: FFUF memberi petunjuk. Analisis manusia mengubah petunjuk menjadi temuan.

Attack → Evidence → Detection → Hardening

Sekarang kita lihat aktivitas FFUF dari dua sisi meja.

Attack / Activity

Fuzzer mengirim banyak HTTP request dengan variasi path, parameter, header, atau input lain berdasarkan wordlist.

Evidence

Web server, reverse proxy, WAF, atau application logs dapat memperlihatkan:

banyak request dari satu source dalam waktu pendek;
banyak request menuju path yang tidak ada;
pola URI yang berubah cepat;
banyak 404, 403, atau redirect;
User-Agent yang konsisten;
request rate yang tidak sesuai perilaku manusia;
request terhadap nama file umum seperti backup atau development artifact.

Detection

Blue Team dapat membuat detection berdasarkan kombinasi:

request rate;
ratio 404/403 terhadap successful request;
jumlah unique URI per source;
akses terhadap sensitive path;
WAF telemetry;
reverse proxy logs;
source reputation dan network context.

Jangan membuat rule seperti "10 kali 404 = attacker". Developer yang sedang salah mengetik route bisa berubah menjadi incident setiap sore.

Context tetap penting.

Hardening

Temuan content discovery dapat ditindaklanjuti dengan:

hapus backup dan artifact deployment dari web root;
jangan expose development/debug endpoint;
enforce authentication dan authorization pada administrative route;
nonaktifkan directory listing jika tidak diperlukan;
pisahkan management interface dari public application;
gunakan deployment pipeline yang tidak membawa file sementara;
review route lama dan deprecated API;
gunakan rate limiting secara proporsional;
aktifkan logging pada reverse proxy/WAF;
jangan mengandalkan nama directory yang "susah ditebak" sebagai security control.

Yang terakhir penting.

/admin-super-secret-2026 bukan access control. Itu hanya URL panjang yang sedang berharap tidak ada yang menebaknya.

Best Practices Saat Menggunakan FFUF

Mulai dari Baseline

Ketahui response normal dan response error sebelum fuzzing.

Gunakan Wordlist yang Relevan

Wordlist kecil yang sesuai teknologi sering lebih berguna daripada wordlist raksasa tanpa konteks.

Batasi Rate

Production bukan arena balap FFUF.

Catat Wordlist dan Filter

Tanpa informasi ini, scan sulit direproduksi.

Validasi Manual

Jangan masukkan setiap output FFUF ke laporan sebagai vulnerability.

Perhatikan Authentication Context

Anonymous dan authenticated user dapat melihat attack surface berbeda.

Hindari Credential Leakage

Token, cookie, dan credential yang digunakan selama assessment harus diperlakukan sebagai data sensitif.

Hubungkan dengan Architecture

Resource yang ditemukan harus dilihat dalam konteks deployment, access control, dan network exposure.

Kesalahan Umum

Wordlist Terbesar = Scan Terbaik

Tidak. Kadang itu hanya cara tercepat menghasilkan log paling besar.

Hanya Melihat HTTP 200

301, 302, 401, dan 403 juga dapat memberi konteks penting.

Tidak Mengerti Custom 404

Jika semua path mengembalikan 200, Anda bisa mendapatkan ribuan false positive.

Tidak Mengatur Rate

FFUF cepat. Backend belum tentu ikut senang.

Menganggap Resource Tersembunyi = Vulnerability

Resource yang tidak ada di menu belum tentu rahasia atau vulnerable.

Tidak Melakukan Validation

Fuzzer menemukan anomali. Manusia menentukan apakah anomali itu benar-benar security issue.

FFUF dalam Red Team Workflow

Jika kita sambungkan dengan artikel sebelumnya:

Nmap
  ↓
Web Service Ditemukan
  ↓
Manual Recon
  ↓
FFUF Content Discovery
  ↓
Response Filtering
  ↓
Interesting Endpoint
  ↓
Manual Validation
  ↓
Risk Assessment
  ↓
Detection & Hardening

Ini jauh lebih sehat daripada:

Install tool
  ↓
Copy command Internet
  ↓
Enter
  ↓
Semoga ada warna hijau

Internal Linking Seri

Jika baru bergabung, mulai dari #00 Red Team Cheat Sheet: Panduan Tools untuk Ethical Hacking dan Security Assessment untuk memahami struktur dan prinsip seri.

Sebelum FFUF, baca #01 Nmap Cheat Sheet: Network Discovery dan Port Scanning untuk Security Assessment. Nmap membantu menemukan web service; FFUF kemudian membantu memahami content yang tersedia di dalamnya.

Artikel berikutnya adalah #03 Naabu Cheat Sheet: Fast Port Discovery dan Reconnaissance Pipeline.

Penutup

FFUF terlihat seperti tool sederhana: wordlist masuk, request keluar, hasil muncul.

Tetapi skill sebenarnya ada pada response analysis.

Kita harus mampu membedakan resource nyata dari custom error page, memahami redirect, membaca perbedaan size, mengatur rate, memilih wordlist yang relevan, dan melakukan manual validation sebelum menyebut sesuatu sebagai vulnerability.

Jadi ketika FFUF menemukan /backup, jangan langsung merayakan kemenangan.

Pertanyaan yang lebih berguna adalah:

Apa resource ini? Kenapa ada di sini? Siapa yang dapat mengaksesnya? Apakah seharusnya tersedia? Dan apakah defender dapat melihat aktivitas discovery yang membawa kita ke sini?

Kalau pertanyaannya sudah seperti itu, kita bukan sekadar menjalankan web fuzzer. Kita sedang melakukan security assessment.

Referensi Resmi

FFUF GitHub Repository — https://github.com/ffuf/ffuf
FFUF Wiki — https://github.com/ffuf/ffuf/wiki
SecLists — https://github.com/danielmiessler/SecLists
OWASP Web Security Testing Guide — https://owasp.org/www-project-web-security-testing-guide/
OWASP Testing for Content — https://owasp.org/www-project-web-security-testing-guide/