LDAP Credential Theft: Peta Lengkap Serangan yang Merambat ke Seluruh Domain

Kamu punya SIEM mahal, tim SOC 24/7, alerting pipeline yang sudah di-tuning berbulan-bulan. Tapi satu credential LDAP yang bocor, attacker bisa merambat ke seluruh forest tanpa kamu sadari. Bukan karena tools kamu jelek. Bukan karena tim kamu kurang jago. Tapi karena cara attacker memanipulasi LDAP dan Kerberos itu diam-diam, lambat, dan terlihat seperti traffic normal.

Artikel ini bukan sekadar “jaga password kamu baik-baik”. Kita akan bedah peta lengkap bagaimana credential theft LDAP berpropagasi jadi domain compromise, kenapa Kerberos delegation jadi amplifier paling berbahaya, dan framework 4-layer yang bisa kamu pakai untuk mendeteksi sebelum attacker mencapai forest trust.

Key Takeaways

• Credential theft LDAP bukan akhir, tapi awal. Satu kredensial yang jatuh membuka pintu enumerasi AD tanpa trigger alert.
• Kerberos delegation adalah amplifier. Dari satu service account, attacker bisa impersonate user lain dan lateral movement tanpa password.
• Forest trust adalah jembatan tersembunyi. Attacker tidak perlu crack password lagi, cukup pivot lewat trust relationship yang sudah kamu konfigurasi sendiri.
• Deteksi butuh behavioral baseline, bukan signature. LDAP query yang terlihat normal bisa jadi reconnaissance phase dari attack chain panjang.

Mengapa Credential Theft LDAP Berbeda dari Serangan Biasa

Banyak tim keamanan memperlakukan credential theft sebagai insiden isolated. Password ketahuan di dark web, di-reset, selesai. Tapi LDAP credential theft di konteks Active Directory itu berbeda fundamental.

LDAP bukan sekadar protokol autentikasi. LDAP adalah peta lengkap infrastruktur kamu. Setiap user, group, computer object, service principal name, dan permission tersimpan di sana. Ketika attacker punya credential LDAP, mereka tidak hanya bisa login. Mereka bisa baca struktur domain kamu.

Inilah yang sering terlewatkan. Tim deteksi fokus pada failed login attempt, brute force, atau password spray. Tapi LDAP enumeration dengan credential valid? Traffic-nya terlihat sama persis dengan admin yang lagi kerja normal. Tidak ada anomali di volume. Tidak ada pattern yang mencurigakan di first glance.

Hasilnya: attacker punya waktu berhari-hari, bahkan berminggu-minggu, untuk memetakan seluruh AD sebelum melakukan move berikutnya.

Tahap 1: Pencurian Kredensial di Titik Entry

Sebelum attacker bisa enumerasi AD, mereka butuh credential. Ada beberapa vektor yang paling sering muncul di lapangan:

• Phishing dengan halaman login palsu. User masukin credential, attacker dapat plaintext. Klasik tapi masih efektif.
• Credential stuffing dari breach eksternal. User pakai password yang sama di LinkedIn breach dan di AD perusahaan. Attacker tinggal coba-coba.
• Pass-the-hash dari endpoint yang sudah terkompromi. Attacker sudah ada di jaringan, ambil hash dari memory, pakai untuk autentikasi LDAP.
• Kerberoasting. Request TGS untuk service account, crack offline. Kalau password service account lemah, selesai.

Di tahap ini, deteksi masih mungkin. Tapi kuncinya bukan di LDAP-nya, melainkan di sumber credential leak. Endpoint detection, email security, dan password policy yang kuat adalah garis pertahanan pertama.

Tahap 2: Enumerasi Active Directory yang Tak Terdeteksi

Inilah tahap yang paling sering dilewatkan tim deteksi. Attacker sudah punya credential. Mereka tidak langsung lateral movement. Mereka belajar dulu.

Dengan akses LDAP, attacker bisa:

• Mendaftar semua user dan group membership. Siapa admin? Siapa yang punya akses ke server kritis?
• Melihat computer objects. Server apa saja yang ada? OS-nya apa? Kapan last logon?
• Membaca Service Principal Names (SPN). Service account mana yang punya delegation privilege?
• Mengidentifikasi GPO dan permission inheritance. Jalur mana yang paling sedikit resistensi?

Semua query ini menggunakan protokol LDAP standar. Port 389 atau 636. Enkripsi TLS kalau LDAPS. Dari perspektif network monitoring, ini traffic yang normal.

Tapi ada pola yang bisa di-capture. Attacker cenderung melakukan query dalam jumlah besar dalam waktu singkat. Mereka query semua user, semua group, semua computer. Admin normal biasanya query spesifik. Behavioral anomaly di sini adalah kuncinya.

Framework deteksi yang bisa kamu bangun:

1. Baseline query volume per user. Admin IT mungkin query 50-100 object per hari. Kalau satu account query 5000 object dalam 2 jam, itu anomaly.
2. Monitor query pattern. Query berurutan ke semua group membership, lalu ke semua computer objects, lalu ke semua SPN. Ini pattern reconnaissance, bukan operational need.
3. Track source IP. LDAP query dari workstation user biasa? Itu merah. LDAP query dari jump server admin? Lebih wajar.

Tahap 3: Abuse Kerberos Delegation

Kalau attacker sudah punya peta AD, langkah berikutnya adalah escalation. Di sinilah Kerberos delegation jadi amplifier paling berbahaya di seluruh attack chain.

Kerberos delegation memungkinkan satu service untuk “berakting sebagai” user lain. Contoh: web server yang perlu akses database atas nama user yang login. Server web request ticket ke KDC, KDC issue ticket yang bisa dipakai server web untuk akses database.

Ada tiga tipe delegation yang perlu kamu pahami:

Unconstrained Delegation

Service dengan unconstrained delegation bisa request ticket atas nama user mana saja ke service mana saja. Kalau attacker kompromi service ini, mereka dapat akses ke semua user yang pernah autentikasi ke service tersebut. Ini settingan legacy yang seharusnya sudah dimatikan.

Constrained Delegation

Lebih terbatas. Service hanya bisa impersonate user ke service tertentu yang sudah didefinisikan. Lebih aman, tapi kalau attacker kompromi service account ini, mereka masih bisa lateral ke service target yang sudah di-config.

Resource-Based Constrained Delegation (RBCD)

Ini yang paling berbahaya dan paling sering disalahgunakan. RBCD memungkinkan target service yang menentukan siapa yang bisa delegation ke dia. Attacker yang punya write access ke computer object bisa konfigurasi RBCD dan memberikan diri mereka sendiri akses delegation.

Skenario attack yang umum:

1. Attacker kompromi service account dengan constrained delegation privilege.
2. Mereka request ticket TGS untuk service target (misal: file server atau SQL server).
3. Dengan ticket ini, mereka akses service target sebagai user lain (biasanya user dengan privilege lebih tinggi).
4. Dari service target, mereka lanjut lateral movement atau data exfiltration.

Yang membuat ini sulit dideteksi:整个过程 menggunakan protokol Kerberos yang valid. Tidak ada password yang di-crack. Tidak ada exploit yang di-deploy. Semuanya “legal” dari perspektif protokol.

Tahap 4: Pivoting Melalui Forest Trust

Kalau organisasi kamu punya multi-forest architecture dengan trust relationship, attacker tidak perlu berhenti di satu domain. Mereka bisa pivot ke forest lain.

Forest trust memungkinkan user di Forest A untuk akses resource di Forest B. Dari perspektif bisnis, ini memudahkan kolaborasi. Dari perspektif attacker, ini memperluas attack surface tanpa perlu credential baru.

Skenario pivot:

1. Attacker kompromi domain di Forest A.
2. Mereka identifikasi trust relationship ke Forest B.
3. Menggunakan ticket dari Forest A, mereka request akses ke resource di Forest B.
4. KDC di Forest B trust ticket dari Forest A karena ada trust relationship.
5. Attacker sekarang ada di Forest B, dengan credential yang sama.

Yang paling berbahaya: tim keamanan di Forest B mungkin tidak tahu apa-apa tentang kompromi di Forest A. Monitoring mereka terpisah. Alerting mereka terpisah. Attacker bisa masuk dari “pintu belakang” tanpa trigger apapun di Forest B.

Mitigasi yang sering direkomendasikan:

• SID Filtering. Mencegah attacker menyuntikkan SID dari domain lain untuk escalate privilege.
• Selective Authentication. Membatasi user/domain mana yang bisa akses resource tertentu di forest lain.
• Forest trust audit reguler. Pastikan trust relationship masih diperlukan. Hapus yang sudah tidak dipakai.

Framework 4-Layer untuk Mendeteksi Propagasi Serangan

Dari analisis attack chain di atas, saya menyusun framework deteksi 4-layer. Setiap layer fokus pada satu tahap attack, dengan signal dan response yang berbeda.

Layer 1: Credential Compromise Detection

Fokus: mendeteksi saat credential jatuh ke tangan attacker.

• Monitor failed login spike dari satu source.
• Alert untuk login dari lokasi/geography yang tidak biasa.
• Correlate credential breach data dari external sources dengan user database internal.

Layer 2: Enumeration Anomaly Detection

Fokus: mendeteksi reconnaissance phase.

• Baseline LDAP query volume per account.
• Alert untuk query pattern yang mencakup multiple object types dalam waktu singkat.
• Track query source dan bandingkan dengan role owner account.

Layer 3: Delegation Abuse Detection

Fokus: mendeteksi escalation melalui Kerberos delegation.

• Inventory semua account dengan delegation privilege.
• Monitor ticket request untuk service dengan delegation.
• Alert untuk ticket request dari service account ke service yang bukan target normal.

Layer 4: Cross-Forest Movement Detection

Fokus: mendeteksi pivot ke forest lain.

• Log semua authentication dari trusted forest.
• Alert untuk authentication pattern yang tidak biasa dari forest lain.
• Correlate incident di forest satu dengan activity di forest lain.

Studi Kasus: Dari Satu Credential ke Domain Compromise

Untuk membuat ini lebih konkret, mari kita lihat skenario realistis yang sering terjadi di enterprise:

Day 1: Seorang developer dapat email phishing yang mengarah ke halaman login palsu. Mereka masukin credential AD mereka. Attacker dapat username dan password.

Day 1-3: Attacker login ke LDAP dengan credential developer. Mereka query semua group membership, identifikasi bahwa developer ini member dari “Dev-Admins” group yang punya akses ke beberapa server testing.

Day 4: Attacker akses server testing. Dari sana, mereka lakukan pass-the-hash dan dapat akses ke service account yang punya constrained delegation privilege.

Day 5: Menggunakan delegation, attacker request ticket untuk akses file server yang berisi data finansial. Mereka impersonate sebagai finance manager.

Day 6: Dari file server, attacker identifikasi trust relationship ke forest partner. Mereka pivot ke forest partner dan akses resource di sana.

Day 7: Data exfiltration. Attacker sudah punya akses ke data sensitif di dua forest. Tim SOC belum dapat alert yang meaningful.

Di skenario ini, setiap tahap individual terlihat normal. Login developer? Wajar. Query LDAP? Admin juga begitu. Ticket request? Delegasi memang begitu cara kerjanya. Cross-forest access? Trust relationship membolehkan.

Tapi kalau kamu lihat correlation across layer, polanya jelas. Developer account query 3000 LDAP object dalam 2 jam, lalu ada ticket request dari service account yang tidak biasa, lalu ada cross-forest authentication ke resource yang tidak pernah diakses sebelumnya.

Inilah kenapa framework 4-layer penting. Deteksi di satu layer mungkin false positive. Tapi correlation di multiple layer? Itu signal yang kuat.

Kesimpulan

LDAP credential theft bukan insiden isolated. Itu adalah awal dari attack chain yang bisa merambat ke seluruh domain, lewat Kerberos delegation, dan pivot ke forest lain. Yang membuat ini berbahaya bukan tekniknya yang canggih, tapi fakta bahwa setiap langkah terlihat seperti traffic normal.

Kunci deteksi ada di behavioral baseline dan cross-layer correlation. Jangan hanya monitor failed login. Monitor query pattern, delegation usage, dan cross-forest movement. Bangun alert yang based on anomaly, bukan hanya signature.

Mulai dari inventory delegation privilege. Audit trust relationship. Baseline LDAP query volume. Tiga langkah ini saja sudah menaikkan detection capability kamu signifikan.

FAQ

1. Apakah LDAP enumeration bisa dideteksi tanpa behavioral baseline?
Sangat sulit. LDAP query dengan credential valid terlihat identik dengan traffic admin normal. Tanpa baseline, kamu tidak bisa bedakan antara admin yang lagi kerja dan attacker yang lagi reconnaissance. Mulai dengan logging query volume per account dan bandingkan dengan role mereka.

2. Bagaimana cara paling efektif memitigasi Kerberos delegation abuse?
Pertama, audit semua account dengan delegation privilege. Matikan unconstrained delegation kalau masih ada. Untuk constrained delegation, pastikan target service benar-benar diperlukan. Implementasi monitoring untuk ticket request dari service account dengan delegation privilege.

3. Apakah forest trust harus dihilangkan untuk keamanan?
Tidak perlu dihilangkan, tapi perlu di-manage. Gunakan selective authentication untuk membatasi akses. Implementasi SID filtering. Audit trust relationship secara berkala dan hapus yang sudah tidak diperlukan. Keamanan bukan tentang menghilangkan trust, tapi tentang membatasi dan memonitor trust yang ada.