DET0462: Detect LLMNR/NBT-NS Poisoning and SMB Relay on Windows
DET0462 is a detection strategy for identifying LLMNR/NBT-NS poisoning and SMB relay behavior associated with ATT&CK technique T1557.001 on Windows. The bu...
Analyst context for executives and security teams
DET0462 is a detection strategy for identifying LLMNR/NBT-NS poisoning and SMB relay behavior associated with ATT&CK technique T1557.001 on Windows. The business issue is that fallback name resolution can cause systems to communicate with an adversary-controlled host, creating opportunities to collect or relay authentication material. For leaders, this is an identity and Windows network resilience concern, not just a network-noise problem.
Executive priority
Prioritize this where Windows environments still rely on LLMNR, NBT-NS, mDNS, or SMB authentication paths that could expose credentials or authentication material. Ask whether the organization can prove visibility into name-resolution fallback traffic and SMB authentication flows, and whether SOC and incident response teams have a playbook for suspected poisoning or relay activity. This supports identity risk reduction, incident readiness, and audit evidence around credential-access monitoring.
Technical view
The supplied ATT&CK object has no official detection logic or platform field, but its relationship detects T1557.001, which is a Windows technique under credential-access and collection. SOC teams should validate whether they can observe suspicious responses to LLMNR/NBT-NS/mDNS traffic and correlate them with SMB communication or authentication events involving unexpected hosts. Detection engineering should focus on the full chain: name-resolution query, potentially spoofed response, connection to the responding system, and subsequent SMB authentication or relay-relevant activity.
Likely telemetry
- Network traffic for LLMNR, NBT-NS, and mDNS name-resolution activity
- SMB connection and authentication telemetry
- Windows authentication logs where available
- Network sensor or packet metadata showing responder and requester relationships
- Asset and host identity context to distinguish expected Windows name-resolution behavior from unusual responders
Detection direction
- Confirm that monitoring covers LLMNR/NBT-NS/mDNS traffic, not only DNS.
- Correlate name-resolution responses with SMB sessions or authentication attempts to the responding host.
- Tune for unusual or unauthorized systems answering name-resolution requests, while accounting for legitimate legacy Windows behavior.
- Validate visibility on Windows networks where fallback name resolution is enabled or still operationally required.
- Because ATT&CK provides no official detection text for DET0462, build and test local analytics against known environment baselines rather than assuming coverage from the strategy name alone.
Mitigation priorities
- Inventory whether Windows environments still require LLMNR, NBT-NS, or mDNS fallback name resolution.
- Where operationally feasible, reduce reliance on alternate name-resolution paths that can be abused for spoofing.
- Review SMB authentication exposure and identity controls in network segments where this behavior would be material.
- Ensure incident response procedures cover suspected name-resolution poisoning and authentication relay scenarios.
- Use detection validation results as evidence for control prioritization and compliance readiness.
Analyst notes and limits
This take is based on the DET0462 detection strategy metadata and its relationship to T1557.001 Name Resolution Poisoning and SMB Relay. The detection strategy itself does not include an official description or detection procedure, so the practical guidance is derived from the related ATT&CK technique context.
ATT&CK fields supplied for DET0462 are sparse: no official description, no official detection text, no tactics, and no explicit platform on the detection strategy object. Windows, credential-access, collection, and the LLMNR/NBT-NS/mDNS and SMB relay context come from the related technique relationship. Local architecture and telemetry are required to determine actual exposure and detection coverage.
Detect LLMNR/NBT-NS Poisoning and SMB Relay on Windows
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1557.001 | Name Resolution Poisoning and SMB Relay Sub-technique | This object detects Name Resolution Poisoning and SMB Relay. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 3d8850f0516e… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0462Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.