Episode ini membedah NTLM sebagai protokol autentikasi warisan: mekanisme challenge-response, perbedaan NTLMv1 dan NTLMv2, risiko pass-the-hash dan relay attack, cara mendeteksi pemakaian NTLM, hingga strategi menonaktifkan NTLM lewat Group Policy dan alternatif penggantinya.

Di episode 13 kita membedah Kerberos — protokol autentikasi modern berbasis tiket yang menjadi standar AD. Sekarang saatnya menghadapi sisi lain yang tidak bisa diabaikan: NTLM, protokol warisan yang masih hidup di hampir setiap lingkungan Windows, meskipun kita semua ingin ia pensiun.
Mengapa masih relevan dipelajari? Karena selama masih ada perangkat atau aplikasi lama yang belum mendukung Kerberos, NTLM akan tetap menjadi jalur autentikasi yang tersedia — dan setiap jalur yang tersedia adalah permukaan serangan. Anda tidak bisa mematikan sesuatu yang tidak Anda pahami, dan Anda tidak bisa mengamankan lingkungan yang tidak Anda sadari masih memakai NTLM.
Bayangkan NTLM seperti pintu darurat yang dipasang puluhan tahun lalu. Ia dulu satu-satunya pintu, sekarang sudah kuno dan mudah di-bypass, tapi beberapa penghuni gedung masih memakainya karena nyaman. Tugas kalian sebagai admin AD adalah memetakan siapa yang masih memakai pintu itu, mendorong mereka pindah ke pintu utama yang aman, lalu mengunci pintu darurat itu untuk selamanya.
Berbeda dari Kerberos yang berbasis tiket, NTLM memakai mekanisme challenge-response — semacam teka-teki yang harus dijawab. Alurnya tiga langkah:
Yang krusial: yang dikirim bukan password, melainkan hash dari password (NT hash) yang dipakai sebagai kunci enkripsi. Di sinilah letak kelemahan terbesar — karena hash inilah yang sebenarnya bisa dicuri dan dipakai ulang, sebagaimana akan kita lihat sebentar lagi.
Klien --> Server : NEGOTIATE (saya mau autentikasi NTLM)
Server --> Klien : CHALLENGE (ini nonce acak untuk anda)
Klien --> Server : AUTHENTICATE (response = hash(nonce, NT hash password))
Server : verifikasi dengan hash yang dimilikinyaNTLM hadir dalam dua versi utama. Keduanya bermasalah, tapi tidak sama parahnya:
| Aspek | NTLMv1 | NTLMv2 |
|---|---|---|
| Era | Windows NT awal | Sejak Windows 2000 |
| Kekuatan response | Rentan terhadap brute-force dan cracking cepat | Lebih sulit di-crack |
| Timestamp server | Ada kelemahan pada format NT hash | Melindungi integritas response dengan session security |
| Status | Wajib dinonaktifkan | Harus diminimalkan |
NTLMv1 dianggap rusak parah — kuncinya terlalu pendek dan teknik cracking modern (misalnya dengan GPU) bisa membongkarnya dalam hitungan menit. NTLMv2 jauh lebih baik, tetapi tetap mewarisi kelemahan struktural keluarga NTLM: tidak ada mutual authentication dan kredensial yang bisa disalahgunakan.
Masalah NTLM bukan hanya soal kriptografi — ia membuka beberapa teknik serangan yang paling populer di dunia penyerang AD:
1. Pass-the-Hash. Penyerang yang mencuri NT hash (misalnya dari memory dump di satu mesin) tidak perlu tahu password aslinya. Ia cukup memakai hash itu langsung untuk login ke sistem lain yang menerima NTLM. Hash adalah "salinan kunci" yang bisa dipakai berulang kali — dan karena NTLM hanya memverifikasi hash, password asli tidak pernah dibutuhkan.
2. NTLM Relay Attack. Alih-alih memakai hash, penyerang meneruskan challenge-response yang sah. Bayangkan penyerang berdiri di tengah dan menyambungkan dua ujung percakapan: ia meminta mesin A mengautentikasi ke dirinya, lalu meneruskan bukti itu ke mesin B. Mesin B mengira penyerang adalah mesin A. Tanpa mutual authentication, tidak ada pihak yang bisa mendeteksi kepalsuan ini.
3. Tidak ada mutual authentication. Server palsu bisa berpura-pura menjadi layanan sah untuk menangkap kredensial — persis yang dicegah Kerberos dengan AP-REP.
4. Kriptografi lemah. NTLMv1 bisa di-crack; NTLMv2 pun hanya sekuat hash NT yang dikirimkan, yang tidak punya proteksi salt seperti hash modern.
Semua serangan ini adalah alasan di balik setiap rekomendasi yang kita bahas di episode 12 — Protected Users menonaktifkan NTLM, dan matikan NTLM di lingkungan.
Sebelum menonaktifkan NTLM, kalian harus tahu siapa yang masih memakainya. Kebijakan audit NTLM di GPO menyediakan tiga mode yang berfungsi seperti semafor:
Lokasi pengaturannya di Editor GPO: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options, pada pengaturan yang dimulai dengan Network security: Restrict NTLM....
Saat audit aktif, peristiwa NTLM terekam di event log. Cara cepat membaca catatan itu lewat Get-WinEvent:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=8004} -MaxEvents 20 |
Select-Object TimeCreated, MessageEvent 8004 menandakan klien berhasil mengautentikasi lewat NTLM (tidak semua event ini berbahaya — beberapa aplikasi modern masih memakainya untuk skenario tertentu, misalnya logon interaktif ke mesin tanpa domain trust). Peristiwa 8001, 8002, dan 8003 memberi konteks serupa untuk berbagai jenis klien dan server. Kumpulkan data selama satu sampai dua minggu di lingkungan nyata sebelum mengambil keputusan.
Menonaktifkan NTLM bukanlah saklar sekali jalan — ia proses bertahap dengan jalur rollback. Urutan yang disarankan:
Deny domain accounts, lalu awasi breakage. Jika bersih, lanjut ke Deny all.Important
Jangan menonaktifkan NTLM untuk semua akun secara membabi buta. Beberapa skenario yang sah masih bergantung padanya — misalnya autentikasi ke server yang tidak bergabung ke domain, atau beberapa versi SQL Server/Exchange yang belum dimigrasi. Gunakan pengecualian yang sespesifik mungkin (per user, per host, per layanan), bukan pengecualian seluruh domain.
Jika sebuah sistem tidak bisa memakai Kerberos, bukan berarti kalian harus menyerah pada NTLM selamanya. Beberapa jalur alternatif:
Dalam kebanyakan lingkungan, migrasi ke Kerberos adalah jawaban untuk 90 persen pemakaian NTLM. Sisanya — perangkat dan aplikasi legacy yang tak tergantikan — dikurung dalam segmen jaringan terisolasi dengan pengecualian minimal dan monitoring ketat.
Tip
Salah satu kebiasaan yang baik: catat semua keputusan NTLM. Kapan audit dimulai, host mana yang ditemukan, aplikasi mana yang dimigrasi, dan pengecualian apa yang diberikan beserta alasan dan tanggal review. Dokumentasi inilah yang menyelamatkan kalian ketika setahun kemudian seseorang bertanya "kenapa host ini masih bisa NTLM?"
Pada episode ini kita telah membedah NTLM secara menyeluruh: mekanisme challenge-response yang menjadi inti protokolnya, perbedaan NTLMv1 yang rusak parah dengan NTLMv2 yang lebih baik tapi tetap lemah, serta risiko nyata berupa pass-the-hash, NTLM relay, dan tidak adanya mutual authentication. Kita juga mempelajari cara mendeteksi pemakaian NTLM lewat audit dan event 8004, strategi menonaktifkan NTLM bertahap lewat Group Policy, dan alternatif penggantinya.
Inti dari episode ini: NTLM adalah protokol yang sudah waktunya pensiun — dan proses pensiun itu dimulai dari kesadaran (audit), bukan dari larangan mendadak. Semakin sedikit permukaan NTLM di domain, semakin sempit ruang gerak penyerang.
Di episode 15 selanjutnya, kita berpindah dari siapa yang boleh masuk ke apa yang boleh dilakukan setelah masuk: Access Control & Permissions — NTFS dan share permissions, ACL, inheritance, hingga delegasi izin di dalam Active Directory itu sendiri. Pastikan tetap semangat!