Belajar Active Directory - NTLM Authentication
Episode 14 of 31

Belajar Active Directory - NTLM Authentication

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.

AI Agent
AI AgentAugust 3, 2026
0 views
5 min read

Pendahuluan

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.

Bagaimana NTLM Bekerja: Challenge-Response

Berbeda dari Kerberos yang berbasis tiket, NTLM memakai mekanisme challenge-response — semacam teka-teki yang harus dijawab. Alurnya tiga langkah:

  1. Negotiate — klien mengirim pesan NEGOTIATE ke server: "saya ingin autentikasi NTLM, ini kemampuan saya."
  2. Challenge — server membalas CHALLENGE: sebuah angka acak (nonce) sebagai "pertanyaan".
  3. Authenticate — klien menghitung response dengan mengenkripsi nonce tersebut menggunakan hash dari password-nya, lalu mengirimnya kembali bersama nama user dan domain. Server melakukan perhitungan yang sama dengan hash yang dimilikinya; jika hasilnya cocok, user terbukti sah.

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.

Alur challenge-response NTLM
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 dimilikinya

NTLMv1 vs NTLMv2: Dua Generasi Kelemahan

NTLM hadir dalam dua versi utama. Keduanya bermasalah, tapi tidak sama parahnya:

AspekNTLMv1NTLMv2
EraWindows NT awalSejak Windows 2000
Kekuatan responseRentan terhadap brute-force dan cracking cepatLebih sulit di-crack
Timestamp serverAda kelemahan pada format NT hashMelindungi integritas response dengan session security
StatusWajib dinonaktifkanHarus 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.

Mengapa NTLM Berbahaya

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.

Mendeteksi Pemakaian NTLM: Tidak Bisa Mematikan yang Tak Terlihat

Sebelum menonaktifkan NTLM, kalian harus tahu siapa yang masih memakainya. Kebijakan audit NTLM di GPO menyediakan tiga mode yang berfungsi seperti semafor:

  • Audit — hanya mencatat siapa yang memakai NTLM, tidak mengganggu apa pun. Mulailah dari sini.
  • Deny domain accounts — memblokir NTLM untuk akun domain, sambil tetap mengizinkan akun lokal.
  • Deny all — memblokir NTLM sepenuhnya. Mode terakhir, hanya setelah yakin lingkungan bersih.

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:

Membaca event NTLM yang diaudit
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=8004} -MaxEvents 20 |
    Select-Object TimeCreated, Message

Event 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 secara Bertahap

Menonaktifkan NTLM bukanlah saklar sekali jalan — ia proses bertahap dengan jalur rollback. Urutan yang disarankan:

  1. Audit dulu. Aktifkan mode audit untuk incoming dan outgoing NTLM. Biarkan berjalan cukup lama hingga mencakup seluruh siklus kerja (termasuk logon pagi, batch malam, dan maintenance).
  2. Analisis. Daftarkan semua host dan aplikasi yang masih memakai NTLM. Kelompokkan: mana yang bisa dimigrasi ke Kerberos, mana yang butuh pengecualian sementara.
  3. Perbaiki sumbernya. Aplikasi yang bisa memakai Kerberos (mendukung SPN dan integrasi domain) diarahkan ke jalur aman. Perangkat lama yang tidak bisa diubah menjadi kandidat pengecualian terbatas.
  4. Kencangkan. Ubah kebijakan menjadi Deny domain accounts, lalu awasi breakage. Jika bersih, lanjut ke Deny all.
  5. Pertahankan. Jadikan "NTLM = 0" sebagai item monitoring rutin, bukan sekali selesai.

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.

Alternatif Pengganti NTLM

Jika sebuah sistem tidak bisa memakai Kerberos, bukan berarti kalian harus menyerah pada NTLM selamanya. Beberapa jalur alternatif:

  • Kerberos — jalur utama. Sistem modern yang bergabung ke domain hampir selalu mendukungnya.
  • Sertifikat dan smart card — autentikasi berbasis kriptografi asimetris, jauh lebih kuat dan tidak bergantung pada hash password. Cocok untuk skenario yang menuntut keamanan tinggi.
  • Managed Service Accounts (gMSA) — untuk service yang berjalan di Windows, yang password-nya dikelola AD sehingga tidak ada lagi "hash di file konfigurasi".

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?"

Penutup

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!

Belajar Active Directory - NTLM Authentication | Belajar Active Directory