#08 Kerbrute Cheat Sheet: Kerberos Enumeration dan Detection untuk Active Directory Security Assessment

Kerberos sering terasa seperti bagian Active Directory yang "pokoknya jalan" sampai suatu hari kita harus membedah authentication flow-nya. Begitu masuk Red Team assessment, barulah tiket, KDC, principal, pre-authentication, dan event log mendadak menjadi menu utama.

Di artikel #08 Red Team Cheat Sheet Series ini kita membahas Kerbrute sebagai alat untuk memahami dan memvalidasi exposure pada Kerberos authentication di lab atau Active Directory yang memang masuk scope assessment. Fokusnya bukan membuat daftar account sebanyak mungkin, melainkan memahami apa yang bisa terungkap dari authentication behavior, evidence apa yang tertinggal, bagaimana Blue Team mendeteksinya, dan bagaimana administrator memperkecil risiko.

Authorization first. User enumeration dan password spraying dapat memicu alert, account lockout, atau incident-response workflow. Gunakan hanya pada lab, CTF, sistem milik sendiri, atau environment yang secara eksplisit mengizinkan teknik tersebut dalam Rules of Engagement.

Sebelum Kerbrute: Kerberos Itu Apa?

Kerberos adalah authentication protocol utama di Active Directory. Secara sederhana, user tidak perlu mengirim password ke setiap service yang ingin diakses. Authentication melibatkan Key Distribution Center (KDC) yang pada domain Windows dijalankan oleh Domain Controller.

Dua komponen pentingnya adalah:

• Authentication Service (AS) — membantu memperoleh Ticket Granting Ticket (TGT);
• Ticket Granting Service (TGS) — menerbitkan service ticket untuk service tertentu.

Flow sederhananya dapat dibayangkan seperti ini:

User
  |
  | AS-REQ
  v
KDC / Domain Controller
  |
  | AS-REP + TGT
  v
User
  |
  | TGS-REQ
  v
KDC
  |
  | TGS-REP + Service Ticket
  v
Service

Diagram ini sengaja disederhanakan. Kerberos asli punya lebih banyak detail: encryption type, PAC, timestamp, SPN, pre-authentication, ticket lifetime, delegation, dan lain-lain.

Untuk artikel ini, hal pentingnya adalah satu fakta: KDC harus memberikan respons terhadap request authentication. Respons tersebut dapat membawa informasi yang berguna bagi assessor—dan sekaligus telemetry yang berguna bagi defender.

Kerbrute Itu Apa?

Kerbrute adalah tool yang memanfaatkan perilaku Kerberos untuk melakukan beberapa aktivitas assessment terhadap Active Directory, terutama validasi username dan pengujian authentication dalam konteks yang diotorisasi.

Tool ini populer karena tidak membutuhkan SMB session terlebih dahulu untuk melakukan validasi tertentu terhadap domain account. Dari perspektif defender, ini juga menarik karena aktivitasnya dapat terlihat pada telemetry Domain Controller.

Namun jangan salah kaprah: Kerbrute bukan tombol "hack AD".

Nilai sebenarnya ada pada pertanyaan yang muncul dari hasilnya:

• Apakah username domain mudah ditebak atau diperoleh dari sumber lain?
• Apakah authentication policy memungkinkan password spraying berisiko rendah bagi attacker?
• Apakah SOC melihat pola authentication abnormal?
• Apakah account lockout policy dirancang dengan benar?
• Apakah privileged account dipisahkan dari pola username umum?

Lab yang Aman

Contoh berikut menggunakan domain lab:

Domain          : LAB.YOWISBEN.LOCAL
Domain Controller: 10.10.20.10
Test user       : lab.user

Gunakan environment terisolasi. Untuk latihan Active Directory, satu Domain Controller dan satu workstation sudah cukup untuk memahami telemetry dasar.

Sebelum pengujian, pastikan DNS client mengarah ke DNS domain yang benar dan waktu sistem sinkron. Kerberos cukup sensitif terhadap clock skew. Kadang "tool-nya rusak" ternyata jam VM kita sedang hidup di masa depan. Cybersecurity juga sesekali kalah oleh jam dinding.

Setup Kerbrute

Kerbrute tersedia sebagai project open-source. Gunakan binary dari release resmi project atau build dari source sesuai dokumentasinya.

Verifikasi tool sebelum assessment dan catat versinya untuk evidence.

kerbrute --help

Jangan asal mengambil binary dari mirror acak. Tool security yang diunduh dari sumber tidak jelas adalah cara kreatif untuk mengubah assessor menjadi target assessment.

1. Username Enumeration: Konsepnya Dulu

Salah satu fungsi yang paling dikenal adalah memvalidasi kandidat username terhadap Kerberos.

Dalam lab, assessor dapat menyiapkan wordlist kecil yang memang berisi account testing:

lab.user
lab.admin
service.test
nonexistent.user

Kemudian validasi dilakukan terhadap Domain Controller lab.

Contoh pola command:

kerbrute userenum -d LAB.YOWISBEN.LOCAL --dc 10.10.20.10 users.txt

Tujuannya bukan mengumpulkan account organisasi sungguhan sebanyak-banyaknya. Di lab, kita ingin memahami bagaimana KDC merespons kandidat principal yang valid dan tidak valid.

Apa yang Sedang Terjadi?

Kerbrute mengirim request Kerberos dan membaca perbedaan respons KDC. Perbedaan behavior tersebut dapat membantu menentukan apakah sebuah username kemungkinan valid.

Inilah pelajaran pentingnya: authentication protocol kadang membocorkan metadata meskipun authentication tidak berhasil.

Dari perspektif security architecture, informasi "account ini ada" sendiri sudah bernilai bagi attacker karena mempersempit ruang pencarian.

2. Dari Mana Kandidat Username Berasal?

Dalam assessment profesional, username seharusnya tidak dibuat secara serampangan.

Sumber yang sah dalam scope dapat berupa:

• account testing yang diberikan organisasi;
• naming convention yang didokumentasikan;
• inventory internal yang memang diberikan untuk assessment;
• data dari tahap reconnaissance yang diizinkan;
• synthetic user list untuk purple-team exercise.

Misalnya organisasi menggunakan pola:

firstname.lastname

Temuan security bukan sekadar "Kerbrute menemukan user". Yang lebih menarik adalah apakah identitas organisasi terlalu mudah diprediksi dan apakah kontrol authentication cukup kuat ketika username sudah diketahui.

Username bukan password, tetapi username valid mengurangi satu variabel yang harus ditebak attacker.

3. Password Spraying: Kenapa Berbeda dari Brute Force?

Ini bagian yang perlu dipahami dengan hati-hati.

Brute force biasanya mencoba banyak password terhadap satu account.

userA -> password1
userA -> password2
userA -> password3
...

Password spraying membalik polanya: sejumlah kecil password dicoba terhadap banyak account.

userA -> candidate
userB -> candidate
userC -> candidate
...

Kenapa attacker tertarik dengan pola kedua? Karena account lockout policy sering menghitung kegagalan per account. Menyebarkan percobaan dapat mengurangi frekuensi kegagalan pada masing-masing account.

Tetapi "mengurangi" bukan berarti aman.

Dalam assessment, password spraying harus disepakati dalam Rules of Engagement karena salah memahami lockout threshold atau observation window dapat mengunci banyak account sekaligus. Itu bukan finding. Itu tiket helpdesk massal.

Untuk seri ini kita tidak memberikan recipe spraying terhadap environment nyata. Di lab, gunakan hanya synthetic accounts dan password yang sengaja dibuat untuk demonstrasi.

4. Apa yang Harus Dicatat Sebagai Evidence?

Assessment yang bagus tidak berhenti pada screenshot terminal.

Catat minimal:

Tanggal/waktu
Tool dan versi
Source IP
Domain Controller
Domain yang diuji
Jumlah synthetic/test account
Jenis pengujian
Hasil ringkas
Event log yang muncul
Dampak terhadap lockout counter

Jangan menaruh plaintext password valid di laporan jika tidak benar-benar diperlukan.

Jika credential ditemukan dalam engagement, perlakukan sebagai sensitive evidence. Gunakan redaction, encrypted storage, access control, dan retention policy sesuai prosedur organisasi.

Cheat Sheet Kerbrute untuk Lab

Cheat sheet ini sengaja difokuskan pada validasi dan observasi di lab.

# Lihat opsi tool
kerbrute --help

# Lihat bantuan user enumeration
kerbrute userenum --help

# Validasi synthetic/test usernames pada domain lab
kerbrute userenum \
  -d LAB.YOWISBEN.LOCAL \
  --dc 10.10.20.10 \
  users.txt

Untuk fungsi authentication testing lain, baca dokumentasi resmi tool dan jalankan hanya jika teknik tersebut tercantum eksplisit dalam RoE.

Cheat sheet yang sehat memberi pengingat syntax. Ia tidak menggantikan pemahaman protocol, lockout policy, dan dampak operasional.

Studi Kasus: Naming Convention yang Terlalu Mudah Ditebak

Bayangkan sebuah organisasi menggunakan format username:

nama.depan

Daftar staf dan struktur organisasi tersedia secara publik di website perusahaan. Tidak ada password yang bocor, tetapi seseorang dapat memperkirakan kandidat username dengan cukup akurat.

Dalam purple-team exercise yang sudah diotorisasi, tim membuat synthetic list berdasarkan pola tersebut lalu menguji apakah authentication endpoint membedakan user valid dan invalid.

Hasilnya: valid username dapat diidentifikasi dengan cukup konsisten.

Apakah ini langsung Critical?

Tidak.

Tetapi sekarang kita punya potongan attack path:

Public Employee Information
        ↓
Predictable Username Pattern
        ↓
Valid Account Enumeration
        ↓
Authentication Testing
        ↓
Potential Initial Access

Temuan menjadi lebih serius jika digabung dengan:

• password policy lemah;
• password reuse;
• tidak ada MFA pada remote access;
• legacy authentication;
• monitoring authentication yang minim;
• privileged account menggunakan pola username yang sama.

Inilah alasan Red Team tidak menilai satu teknik dalam ruang hampa.

Attack → Evidence → Detection → Hardening

Sekarang kita gunakan pola khas seri ini.

Attack / Activity

Assessor mengirim sejumlah Kerberos authentication request untuk memvalidasi synthetic username atau menguji kontrol authentication yang memang disetujui dalam scope.

Evidence

Evidence dapat muncul pada Domain Controller dan security monitoring, tergantung jenis request dan konfigurasi audit.

Perhatikan terutama aktivitas Kerberos authentication dan pola kegagalan yang tidak biasa.

Windows Security Event Log menyediakan event terkait Kerberos Authentication Service dan Ticket Granting Service. Event yang relevan dapat mencakup aktivitas permintaan TGT dan kegagalan authentication.

Yang penting bukan menghafal satu Event ID lalu merasa SOC selesai. Detection harus melihat pola.

Detection

Blue Team dapat mencari indikator seperti:

• satu source mengirim authentication request untuk banyak username dalam waktu pendek;
• rasio user tidak valid yang tinggi;
• pola request berurutan mengikuti naming convention;
• authentication failure dari workstation yang biasanya tidak berinteraksi langsung dengan banyak account;
• peningkatan Kerberos errors pada satu Domain Controller;
• percobaan authentication terhadap privileged atau dormant accounts;
• aktivitas di luar pola operasional normal.

Contoh logika detection konseptual:

IF
  unique_target_accounts from one source > baseline
AND
  kerberos_failures increase sharply
AND
  source is not approved identity infrastructure
THEN
  investigate possible account enumeration / spraying

Jangan copy angka threshold dari blog lalu menanamnya sebagai hukum alam. Baseline setiap environment berbeda.

Domain Controller pada perusahaan 50 user dan universitas dengan puluhan ribu identity jelas punya pola berbeda.

Event Log: Jangan Hanya Mengejar Satu ID

Microsoft menyediakan audit subcategory untuk Kerberos Authentication Service dan Kerberos Service Ticket Operations.

Blue Team sebaiknya memahami:

• event apa yang dikumpulkan;
• field source address yang tersedia;
• account name/principal;
• failure code;
• encryption type;
• volume dan baseline normal;
• apakah log dikirim ke SIEM secara konsisten.

Failure code juga penting. Kegagalan karena principal tidak ditemukan berbeda makna dengan password salah, account disabled, atau policy restriction.

Dengan kata lain: baca konteks event, jangan cuma nomor event.

Hardening 1: MFA Tetap Sangat Penting

Kerberos internal dan MFA bukan hubungan satu-ke-satu untuk setiap authentication flow, tetapi dari perspektif attack path, MFA pada remote access dan identity-sensitive entry point dapat memutus banyak skenario initial access setelah credential diketahui.

Prioritaskan MFA terutama pada:

• VPN;
• remote administration;
• privileged access;
• cloud identity;
• externally accessible applications.

Username yang diketahui seharusnya tidak cukup untuk membuat defender berkeringat.

Hardening 2: Password Policy yang Masuk Akal

Password policy harus mengurangi risiko password mudah ditebak tanpa membuat user menciptakan pola yang justru predictable.

Gunakan guidance modern: panjang password yang memadai, block password yang umum/compromised bila platform mendukung, dan hindari kebijakan rotasi periodik tanpa alasan yang justru mendorong pola seperti:

Company2026!
Company2027!

Itu bukan evolusi password. Itu kalender dengan tanda seru.

Hardening 3: Account Lockout dengan Hati-hati

Lockout policy membantu memperlambat password guessing, tetapi konfigurasi terlalu agresif dapat dimanfaatkan untuk denial of service terhadap user.

Review:

• account lockout threshold;
• reset/observation window;
• lockout duration;
• pengecualian service account;
• monitoring terhadap lockout burst.

Policy harus disesuaikan dengan risk profile organisasi.

Hardening 4: Lindungi Privileged Identity

Jangan memperlakukan Domain Admin seperti account email biasa.

Gunakan prinsip:

• dedicated administrative account;
• administrative tiering;
• Privileged Access Workstation atau secure admin host;
• least privilege;
• pembatasan logon location;
• monitoring lebih ketat;
• hindari penggunaan privileged credential pada workstation biasa.

Artikel #06 BloodHound sudah menunjukkan mengapa relationship antar-account dapat membentuk attack path. Artikel #07 Windows Credential Exposure menunjukkan apa yang terjadi ketika credential berharga tersimpan atau terekspos di tempat yang salah.

Kerbrute menambahkan potongan berikutnya: bagaimana identity surface dapat dipetakan dari authentication behavior.

Hardening 5: Kurangi Informasi Identitas yang Tidak Perlu

Jangan salah: solusinya bukan menghapus semua nama pegawai dari Internet.

Security by obscurity bukan strategi utama.

Tetapi organisasi tetap perlu mengevaluasi apakah informasi publik secara tidak sengaja mengungkap:

• pola username;
• alamat email privileged account;
• struktur administrative role;
• service account naming;
• internal hostname;
• domain naming convention.

Tujuannya adalah data minimization, bukan membuat organisasi menjadi misterius seperti organisasi rahasia di film.

Purple Team Exercise yang Lebih Berguna

Daripada hanya bertanya "Kerbrute terdeteksi atau tidak?", buat exercise terukur.

Skenario

Synthetic source workstation melakukan user enumeration terhadap 30 synthetic account selama window yang disepakati.

Red Team Mengukur

• request rate;
• valid/invalid response behavior;
• waktu mulai dan selesai;
• source IP;
• target DC.

Blue Team Mengukur

• apakah event terkumpul;
• berapa lama sampai SIEM menerima log;
• apakah rule menghasilkan alert;
• apakah source dan target account terlihat jelas;
• apakah analyst dapat membedakan test activity dari normal authentication;
• berapa lama triage dilakukan.

Output

Bukan sekadar "detected" atau "not detected".

Output yang lebih matang:

Telemetry available      : Yes
SIEM ingestion           : Yes
Detection rule           : Partial
Alert generated          : No
Source attribution       : Available
Recommended improvement  : Correlate unique account failures per source

Sekarang exercise menghasilkan improvement yang bisa dikerjakan.

Best Practices untuk Assessor

1. Baca Lockout Policy Sebelum Testing

Jangan menebak.

2. Mulai dari Synthetic Accounts

Validasi teknik dan telemetry tanpa menyentuh user production terlebih dahulu.

3. Rate Limit

Lebih cepat tidak selalu lebih baik. Objective assessment adalah evidence, bukan benchmark throughput.

4. Sinkronkan Waktu

Kerberos bergantung pada waktu. Pastikan scanner, DC, dan log platform punya timestamp yang dapat dibandingkan.

5. Simpan Evidence Secara Aman

Username mungkin bukan secret, tetapi daftar identity lengkap tetap merupakan informasi sensitif.

6. Koordinasikan dengan Blue Team

Untuk purple-team exercise, catat waktu mulai/selesai agar telemetry dapat dibandingkan dengan ground truth.

7. Jangan Menguji Service Account Sembarangan

Lockout atau authentication disruption pada service account bisa mengganggu aplikasi.

Kesalahan Umum

Menganggap Username Enumeration Sama dengan Compromise

Tidak. Mengetahui username hanya mengurangi uncertainty attacker.

Menganggap Tidak Ada Lockout Berarti Aman untuk Spraying

Tidak juga. Aktivitas tetap dapat memicu alert, throttling, atau kontrol lain.

Mengabaikan DNS dan Clock

Kerberos sangat bergantung pada keduanya.

Menjalankan Tool Sebanyak Mungkin

Assessment bukan kompetisi koleksi binary.

Tidak Melihat Log

Kalau Red Team selesai testing tanpa mengecek telemetry bersama Blue Team, kita kehilangan separuh nilai exercise.

Kerbrute dalam Attack Path

Mari hubungkan #06, #07, dan #08.

BloodHound
  |
  | memahami relationship & privilege path
  v
Windows Credential Exposure
  |
  | memahami nilai dan lokasi credential
  v
Kerberos Enumeration
  |
  | memahami identity exposure & auth behavior
  v
Focused Kerberos Assessment
  |
  v
Detection & Hardening

Seri ini sengaja tidak memperlakukan tool sebagai pulau terpisah.

Tool berubah. Attack path tetap harus dipahami sebagai sistem.

Dari Red Team ke Blue Team

Red Team melihat Kerbrute sebagai cara menguji bagaimana KDC merespons identity-related request.

Blue Team seharusnya melihat aktivitas yang sama sebagai kesempatan untuk menjawab:

Apakah kita tahu ketika satu endpoint tiba-tiba "bertanya" tentang banyak identity dalam waktu singkat?

Kalau jawabannya belum, itu detection gap yang konkret.

Kalau alert sudah ada tetapi terlalu noisy, itu tuning problem.

Kalau event bahkan tidak dikumpulkan, itu telemetry gap.

Tiga masalah berbeda, tiga remediation berbeda.

Penutup

Kerbrute terlihat sederhana karena interaksinya banyak terjadi pada satu protocol: Kerberos.

Tetapi justru dari sana kita belajar konsep penting: authentication behavior sendiri dapat menjadi sumber informasi bagi attacker sekaligus sumber telemetry bagi defender.

Dalam security assessment, jangan berhenti pada "username berhasil ditemukan". Tanyakan:

• kenapa identity tersebut dapat diprediksi?
• bagaimana KDC merespons?
• apakah monitoring melihat pola abnormal?
• apakah password dan lockout policy memadai?
• apakah privileged identity dipisahkan dengan benar?
• apakah attack path dapat diputus sebelum credential menjadi initial access?

Artikel berikutnya, #09 GetUserSPNs & Kerberoasting, akan masuk lebih dalam ke hubungan antara Kerberos service ticket dan risiko service account—tetap dengan pendekatan yang sama: konsep dulu, lab terkontrol, evidence, detection, lalu hardening.

Referensi Resmi

• Microsoft Learn — Kerberos authentication overview: https://learn.microsoft.com/windows-server/security/kerberos/kerberos-authentication-overview
• Microsoft Learn — Audit Kerberos Authentication Service: https://learn.microsoft.com/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-authentication-service
• Microsoft Learn — Audit Kerberos Service Ticket Operations: https://learn.microsoft.com/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-service-ticket-operations
• Microsoft Learn — Account lockout threshold security policy setting: https://learn.microsoft.com/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/account-lockout-threshold
• Microsoft Learn — Securing privileged access: https://learn.microsoft.com/security/privileged-access-workstations/privileged-access-access-model
• Kerbrute project documentation: https://github.com/ropnop/kerbrute
• MITRE ATT&CK — Account Discovery: https://attack.mitre.org/techniques/T1087/
• MITRE ATT&CK — Brute Force: Password Spraying: https://attack.mitre.org/techniques/T1110/003/