#11 LLMNR/NBT-NS Security: Name Resolution Poisoning, Detection dan Hardening

Di network Windows, satu typo kecil kadang menghasilkan cerita yang jauh lebih panjang daripada yang kita inginkan. User bermaksud membuka sebuah file server, nama host salah ketik, DNS tidak menemukan jawabannya, lalu mekanisme name resolution alternatif ikut bekerja. Dari sisi user mungkin cuma terlihat seperti resource yang gagal dibuka. Dari sisi security, kondisi seperti ini bisa membuka peluang name resolution poisoning.

Artikel #11 dalam Red Team Cheat Sheet Series membahas risiko yang sering diasosiasikan dengan Responder, tetapi fokus kita bukan membuat resep credential interception. Kita akan memahami mengapa LLMNR/NBT-NS menjadi attack surface, evidence apa yang dapat dicari Blue Team, bagaimana mengaudit exposure dengan aman, dan bagaimana mematikan jalur yang sebenarnya tidak lagi dibutuhkan.

Gunakan seluruh aktivitas validasi hanya pada lab, sistem milik sendiri, atau environment yang secara eksplisit masuk scope security assessment. Untuk production, prioritaskan passive observation, configuration review, dan controlled validation.

Kenapa Topik Ini Masih Relevan?

Windows modern sangat bergantung pada DNS, tetapi pada environment tertentu masih ada mekanisme name resolution alternatif atau legacy. LLMNR (Link-Local Multicast Name Resolution) memungkinkan host pada link lokal melakukan name resolution tanpa DNS server. NBT-NS (NetBIOS Name Service) merupakan mekanisme lebih lama yang berkaitan dengan NetBIOS over TCP/IP.

Masalahnya bukan bahwa protocol tersebut otomatis jahat. Masalahnya adalah model kepercayaannya.

Ketika client bertanya ke network lokal, kurang lebih pertanyaannya menjadi:

"Ada yang tahu alamat FILESRV-01?"

Jika jawaban authoritative dari DNS tidak tersedia dan fallback mechanism digunakan, perangkat lain pada segment dapat ikut merespons. Inilah alasan name resolution poisoning masuk dalam MITRE ATT&CK T1557.001 — Name Resolution Poisoning and SMB Relay.

MITRE menjelaskan bahwa adversary dapat merespons traffic LLMNR, NBT-NS, atau mDNS seolah-olah merupakan sumber authoritative sehingga victim berkomunikasi dengan sistem yang dikendalikan adversary. Authentication material kemudian berpotensi ikut terkirim atau direlay tergantung protocol dan konfigurasi.

Singkatnya: kalau client bertanya ke seluruh ruangan, jangan berasumsi hanya orang baik yang akan menjawab.

LLMNR, NBT-NS, mDNS, dan DNS: Jangan Dicampur Jadi Satu

DNS

DNS adalah mekanisme name resolution utama yang seharusnya menjadi fondasi environment enterprise yang sehat.

LLMNR

LLMNR menggunakan multicast pada local link dan lazim diasosiasikan dengan UDP 5355. Ia dapat digunakan ketika conventional DNS resolution tidak memberikan hasil.

NBT-NS

NBT-NS merupakan bagian dari NetBIOS name resolution dan lazim menggunakan UDP 137. Banyak environment modern sebenarnya tidak lagi membutuhkan ketergantungan luas terhadap NetBIOS.

mDNS

mDNS menggunakan multicast, umumnya UDP 5353, dan banyak ditemukan pada discovery perangkat atau service lokal. Kebutuhannya harus dinilai berdasarkan environment; jangan mematikan protocol secara membabi buta tanpa inventory.

Poin pentingnya bukan menghafalkan nomor port. Poin pentingnya adalah memahami fallback path yang terjadi ketika DNS gagal.

Di Mana Responder Masuk?

Responder dikenal sebagai tool yang dapat berinteraksi dengan berbagai mekanisme name resolution dan authentication pada network lokal. MITRE ATT&CK mencatat Responder sebagai software S0174 dan memetakannya antara lain ke T1557.001 serta Network Sniffing.

Dari perspektif pembelajaran, nilai terbesar Responder bukan pada jumlah credential yang dapat dikumpulkan. Nilainya adalah menunjukkan satu fakta arsitektural:

Client bisa mempercayai jawaban name resolution dari sumber yang tidak seharusnya dipercaya.

Kalau assessment berhenti pada screenshot tool, kita kehilangan pelajaran terpentingnya.

Temuan yang matang seharusnya berbunyi lebih dekat ke:

"Endpoint masih menggunakan fallback name resolution yang memungkinkan unauthorized responder memengaruhi tujuan komunikasi."

Itu jauh lebih actionable untuk infrastructure team.

Model Risiko Sederhana

Bayangkan workstation CLIENT-01 ingin mengakses:

\\fileserver\finance

Tetapi user salah mengetik:

\\filesrever\finance

DNS tidak menemukan filesrever.

Pada environment yang masih mengizinkan fallback tertentu, client dapat melakukan query lokal. Unauthorized responder pada segment yang sama berpotensi memberikan jawaban palsu.

Alurnya secara konseptual:

User / Application
      ↓
DNS query gagal
      ↓
Fallback name resolution
      ↓
Broadcast / multicast query lokal
      ↓
Unauthorized responder menjawab
      ↓
Client berkomunikasi ke tujuan yang salah
      ↓
Authentication / network exposure berpotensi terjadi

Perhatikan bahwa root cause-nya bukan typo user. Typo hanya pemicu.

Root cause sebenarnya adalah trust model dan fallback protocol yang masih tersedia.

Setup Lab yang Aman

Untuk mempelajari topik ini, kita tidak membutuhkan production network.

Gunakan environment terisolasi, misalnya:

LAB VLAN

Windows Client   10.10.50.20
Windows Server   10.10.50.10
Monitoring Host  10.10.50.30

Tujuan lab:

1. melihat apakah endpoint masih mengirim LLMNR/NBT-NS;
2. mengamati traffic pada packet capture;
3. mengubah policy;
4. mengulangi test;
5. memastikan fallback traffic tidak lagi muncul bila memang dinonaktifkan.

Untuk latihan defensif, kita bahkan tidak perlu menangkap credential. Traffic behavior dan configuration state sudah cukup untuk membuktikan exposure.

Cheat Sheet Defensif #11

Cheat sheet kali ini sengaja berorientasi audit dan detection.

LLMNR
Protocol/port umum : UDP 5355
Pertanyaan audit   : Apakah endpoint masih mengirim query LLMNR?

NBT-NS
Protocol/port umum : UDP 137
Pertanyaan audit   : Apakah NetBIOS over TCP/IP masih diperlukan?

mDNS
Protocol/port umum : UDP 5353
Pertanyaan audit   : Service apa yang benar-benar membutuhkan mDNS?

Windows Policy
Path umum          : Computer Configuration > Network > DNS Client
Policy             : Turn off multicast name resolution

MITRE ATT&CK
Technique          : T1557.001
Detection Strategy : DET0462

Microsoft mendokumentasikan policy Turn off multicast name resolution. Ketika policy tersebut diaktifkan, LLMNR dinonaktifkan pada network adapter yang tersedia pada DNS client.

Nama policy-nya memang sedikit menjebak: untuk mematikan LLMNR, kita enable policy bernama Turn off multicast name resolution. Windows Group Policy kadang mengajarkan kita bahwa grammar dan security tidak selalu berteman.

Audit Pertama: Apakah Kita Masih Membutuhkannya?

Sebelum hardening, lakukan inventory.

Tanyakan:

• Apakah organisasi mempunyai aplikasi legacy yang masih bergantung pada NetBIOS?
• Apakah endpoint modern menggunakan DNS secara konsisten?
• Apakah ada perangkat non-Windows yang membutuhkan mDNS?
• Apakah printer, meeting-room device, atau IoT menggunakan local discovery?
• Apakah network segment berbeda mempunyai kebutuhan berbeda?

Security control yang bagus tidak dimulai dari "disable semuanya". Ia dimulai dari understand dependency → remove unnecessary trust → validate impact.

Audit Kedua: Cari Traffic yang Seharusnya Tidak Ada

MITRE detection strategy DET0462, diperbarui pada 12 Mei 2026, menyarankan korelasi network traffic LLMNR UDP 5355 dan NBT-NS UDP 137 dengan unauthorized response, SMB authentication pattern, perubahan registry terkait multicast name resolution, dan service creation yang mencurigakan.

Untuk Blue Team, pertanyaan menarik adalah:

Siapa yang mengirim query, dan siapa yang menjawab?

Client yang mengirim LLMNR mungkin menunjukkan dependency atau misconfiguration. Host biasa yang tiba-tiba menjawab banyak query LLMNR/NBT-NS jauh lebih menarik.

Baseline sangat penting.

Attack → Evidence → Detection → Hardening

Mari pakai pola khas seri ini.

Attack / Exposure

Endpoint gagal melakukan normal DNS resolution lalu menggunakan local fallback name resolution. Unauthorized host pada segment merespons query tersebut dan berusaha menjadi tujuan komunikasi.

Evidence

Evidence yang relevan dapat berupa:

• LLMNR traffic UDP 5355;
• NBT-NS traffic UDP 137;
• mDNS traffic UDP 5353 bila relevan;
• respons name resolution dari endpoint yang bukan resolver yang diharapkan;
• authentication attempt yang muncul segera setelah poisoned resolution;
• konfigurasi policy yang memungkinkan LLMNR;
• NetBIOS over TCP/IP yang masih aktif tanpa business requirement;
• service atau process tidak biasa pada host yang memberikan response.

Detection

Blue Team dapat membangun detection berdasarkan kombinasi:

Name-resolution query
        +
Unauthorized responder
        +
Subsequent authentication
        +
Unexpected source host

Korelasi jauh lebih bernilai daripada alert tunggal "ada UDP 5355".

LLMNR traffic sendiri belum otomatis malicious. Yang mencurigakan adalah siapa menjawab, seberapa sering, dan apa yang terjadi sesudahnya.

Hardening

Prioritas utama:

1. gunakan DNS yang reliable;
2. disable LLMNR bila tidak dibutuhkan;
3. disable NetBIOS over TCP/IP bila dependency telah divalidasi;
4. evaluasi kebutuhan mDNS per segment;
5. enforce SMB signing sesuai compatibility dan security baseline;
6. kurangi NTLM dependency secara bertahap;
7. gunakan network segmentation;
8. monitor unauthorized name-resolution responders;
9. review service account dan credential hygiene;
10. lakukan regression test setelah policy berubah.

MITRE secara eksplisit mencantumkan disable LLMNR/mDNS/NetBIOS bila tidak diperlukan, network filtering, SMB signing, intrusion prevention, dan network segmentation sebagai mitigasi untuk T1557.001.

Mengapa DNS Reliability Adalah Security Control?

Kadang remediation ditulis sederhana:

Disable LLMNR.

Benar, tetapi belum lengkap.

Kalau DNS internal sering gagal, administrator bisa tergoda mengaktifkan kembali fallback karena "user jadi tidak bisa akses server".

Jadi hardening harus dibarengi perbaikan:

• DNS record hygiene;
• suffix search configuration;
• DHCP/DNS integration;
• stale record cleanup;
• monitoring DNS failure;
• standard naming;
• documentation aplikasi legacy.

Security yang melawan reliability biasanya kalah dalam jangka panjang.

Studi Kasus: File Server yang Salah Ketik

Sebuah organisasi mempunyai domain Windows dengan workstation modern. DNS internal sebenarnya bekerja baik, tetapi LLMNR belum pernah dinonaktifkan karena konfigurasi tersebut diwariskan bertahun-tahun.

Saat assessment, monitoring menunjukkan beberapa workstation mengirim LLMNR query ketika user salah mengetik hostname file server.

Tidak ada kebutuhan bisnis yang terdokumentasi untuk LLMNR.

Temuan

Finding:
Legacy fallback name resolution remains enabled on corporate endpoints.

Risk:
An unauthorized host on the same reachable network segment may respond to
local name-resolution requests and influence subsequent communication.

Evidence

• query UDP 5355 dari workstation;
• policy LLMNR belum dinonaktifkan;
• tidak ada aplikasi yang diketahui bergantung pada LLMNR;
• segment user memungkinkan peer-to-peer reachability lebih luas dari yang dibutuhkan.

Remediation

Tim melakukan pilot pada satu OU:

1. memperbaiki dan memverifikasi DNS dependency;
2. mengaktifkan policy Turn off multicast name resolution;
3. memvalidasi aplikasi penting;
4. memonitor helpdesk ticket;
5. memperluas policy secara bertahap;
6. meninjau NetBIOS dependency;
7. memperketat segmentation antar workstation.

Hasil assessment yang baik bukan "kami berhasil mendapatkan hash". Hasil yang lebih bernilai adalah jalur trust yang tidak perlu berhasil dihapus.

Perspektif Blue Team: Hunting Unauthorized Responder

Blue Team dapat membangun hunting question seperti:

1. Host mana yang paling sering menjawab LLMNR?

Workstation biasa seharusnya tidak tiba-tiba menjadi pusat jawaban name resolution bagi puluhan endpoint.

2. Apakah response diikuti SMB authentication?

Korelasi temporal dapat membantu membedakan noise dari behavior yang perlu diinvestigasi.

3. Apakah policy berubah?

MITRE DET0462 menyebut perubahan registry pada:

HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast

sebagai salah satu data yang relevan ketika mendeteksi re-enablement multicast name resolution.

4. Apakah ada service baru pada endpoint?

Service creation dapat menjadi context tambahan. MITRE mengaitkan Windows Security Event ID 4697 dengan service creation telemetry.

5. Dari segment mana aktivitas berasal?

Responder-style behavior dari controlled security-testing VLAN mempunyai konteks berbeda dengan behavior yang sama dari laptop user biasa.

Context, lagi-lagi, adalah segalanya.

SMB Signing: Kenapa Sering Ikut Dibahas?

Name resolution poisoning dan SMB relay sering dibahas dalam satu napas karena poisoned resolution dapat mengarahkan authentication ke sistem yang tidak diharapkan, sementara relay memanfaatkan authentication exchange tersebut dalam kondisi tertentu.

MITRE mencatat bahwa enabling SMB signing dapat menghentikan NTLMv2 relay attack pada skenario yang relevan.

Tetapi jangan menganggap SMB signing menggantikan remediation lain.

Kita tetap ingin:

• menghapus fallback protocol yang tidak dibutuhkan;
• memperbaiki DNS;
• membatasi peer-to-peer network access;
• mengurangi NTLM;
• memperbaiki identity hygiene.

Defense-in-depth bukan satu checkbox ajaib.

Network Segmentation: Blast Radius Matters

Name resolution poisoning membutuhkan network reachability tertentu.

Kalau semua workstation dapat berkomunikasi bebas dengan semua workstation lain, attacker yang berhasil berada pada satu endpoint memperoleh ruang gerak lebih besar.

Microsegmentation atau host firewall policy dapat mengurangi peer-to-peer communication yang tidak diperlukan.

Pertanyaannya sederhana:

Apakah laptop bagian accounting memang perlu menerima koneksi SMB dari laptop marketing?

Kalau jawabannya "tidak pernah kepikiran", itu justru alasan bagus untuk mulai review.

Best Practices untuk Red Team

Jangan Mengejar Credential sebagai Trophy

Tujuan assessment adalah membuktikan risiko dengan impact minimum.

Prefer Passive Evidence

Jika packet capture dan configuration review sudah membuktikan LLMNR aktif, jangan otomatis meningkatkan agresivitas test.

Tetapkan Stop Condition

Rules of Engagement harus menentukan kapan validation dihentikan.

Jangan Simpan Authentication Material Sembarangan

Jika engagement menghasilkan sensitive authentication artifact, perlakukan sebagai secret: batasi akses, enkripsi, dokumentasikan retention, dan hapus sesuai RoE.

Report Root Cause

Jangan berhenti pada nama tool.

Responder detected bukan root cause.

Root cause dapat berupa:

• LLMNR enabled;
• legacy NetBIOS dependency;
• weak segmentation;
• NTLM dependency;
• SMB signing gap;
• DNS reliability issue.

Best Practices untuk Blue Team

Baseline Sebelum Alert

Kenali host dan segment yang memang menghasilkan multicast name-resolution traffic.

Monitor Responder Behavior, Bukan Hanya Tool Name

Executable dapat diganti nama. Behavior lebih tahan lama sebagai detection strategy.

Correlate Network + Authentication + Endpoint

Satu packet jarang menceritakan seluruh cerita.

Audit Policy Drift

Hardening yang benar hari ini belum tentu tetap benar enam bulan lagi.

Prioritaskan Elimination

Detection bagus. Menghapus protocol yang tidak diperlukan lebih bagus.

Alert yang paling mudah ditangani adalah alert yang tidak perlu ada karena attack surface-nya sudah dihilangkan.

Checklist Assessment

Gunakan checklist ini saat review environment Windows:

[ ] DNS internal reliable dan terpantau
[ ] LLMNR requirement terdokumentasi
[ ] LLMNR disabled bila tidak diperlukan
[ ] NetBIOS dependency telah diinventarisasi
[ ] NetBIOS disabled pada segment yang tidak membutuhkan
[ ] mDNS requirement dievaluasi
[ ] SMB signing posture direview
[ ] NTLM dependency diinventarisasi
[ ] Peer-to-peer workstation traffic dibatasi
[ ] Unauthorized LLMNR/NBT-NS responder dimonitor
[ ] Policy drift dimonitor
[ ] Security testing mempunyai RoE dan stop condition

Hubungan dengan Artikel Sebelumnya

Artikel #06 BloodHound menunjukkan bagaimana relationship membentuk attack path Active Directory.

Artikel #07 membahas Windows Credential Exposure.

Artikel #08 membahas Kerberos Enumeration dan Detection.

Artikel #09 membahas SPN dan Kerberos Service Account Security.

Artikel #10 masuk ke Active Directory Certificate Services.

Sekarang #11 menunjukkan sesuatu yang sedikit berbeda: credential risk tidak selalu bermula dari database password atau certificate template. Kadang jalurnya dimulai dari cara workstation mencari nama host yang tidak ditemukan DNS.

Inilah alasan security architecture harus melihat identity dan network sebagai satu sistem, bukan dua dunia terpisah.

Penutup

Responder terkenal karena menunjukkan betapa berbahayanya local name-resolution trust yang terlalu longgar. Tetapi pelajaran terpenting bukan cara menjalankan tool tersebut.

Pelajaran sebenarnya adalah:

Mengapa endpoint kita masih bersedia mempercayai jawaban dari network lokal ketika DNS gagal?

Kalau LLMNR, NBT-NS, atau mekanisme discovery lain memang diperlukan, dokumentasikan, segmentasikan, dan monitor.

Kalau tidak diperlukan, hilangkan.

Security sering terdengar rumit karena kita membicarakan EDR, SIEM, attack graph, AI detection, dan segala macam singkatan tiga huruf. Tetapi kadang hardening terbaik tetap sederhana: jangan menyediakan fallback trust yang tidak kita butuhkan.

Pada artikel #12 kita melanjutkan seri ke Evil-WinRM dan Windows Remote Management Security: bagaimana remote administration seharusnya dibatasi, dimonitor, dan dipisahkan dari user network.

Sumber Resmi

• MITRE ATT&CK — T1557.001 Adversary-in-the-Middle: Name Resolution Poisoning and SMB Relay — https://attack.mitre.org/techniques/T1557/001/
• MITRE ATT&CK — Responder S0174 — https://attack.mitre.org/software/S0174/
• MITRE ATT&CK — DET0462 Detect LLMNR/NBT-NS Poisoning and SMB Relay on Windows — https://attack.mitre.org/detectionstrategies/DET0462/
• Microsoft Learn — ADMX_DnsClient Policy CSP / Turn off multicast name resolution — https://learn.microsoft.com/windows/client-management/mdm/policy-csp-admx-dnsclient
• MITRE ATT&CK — Service Creation Data Component DC0060 — https://attack.mitre.org/datacomponents/DC0060/