Legacy by Design: How Protocol Defaults and Hash Exposure Still Get Us Breached
This article is part of a series unpacking the NSA and CISA’s Top Ten Cybersecurity Misconfigurations through the lens of real-world breaches and assessment findings.
This entry continues Misconfiguration 1: Default configurations of software and applications, with a focus on legacy protocol exposure and authentication fallback paths—particularly NTLM, SMB, LLMNR, and other services that still quietly enable credential theft and lateral movement in modern environments.
TL;DR
Legacy ports and protocols like NTLM, SMBv1, LDAP, Telnet, FTP, LLMNR, and NetBIOS are still active across many networks. Often left enabled by default or retained for legacy compatibility, they quietly enable credential theft, relay, and lateral movement. This article prioritises the services most often abused in the field, starting with NTLM and account protection, and outlines practical steps for defenders to reduce exposure without waiting for perfect conditions.
NTLM Relays Are Still Relevant
NTLM remains active in almost every environment I assess. Even where Kerberos is the official authentication protocol, fallback to NTLM often persists due to legacy dependencies, configuration gaps, or application compatibility requirements. This fallback frequently happens out of sight and continues to expose credentials in ways defenders rarely monitor.
Service accounts are particularly vulnerable because they often rely on NTLM by default, use long‑lived passwords, escape rotation, and operate under legacy application logic. Once a hash is harvested, whether via Responder, Inveigh, or an NTLM relay, it can be reused against any service that accepts NTLM, especially when SMB signing is not enforced. I have repeatedly seen NTLM relay used by red teams as a quiet but effective vector, often yielding administrative access within minutes.
Even when organisations believe they are “Kerberos only,” NTLM often remains a hidden fallback. SOC teams may not be logging NTLM authentication, especially across vault or Domain Admin accounts. As a result, fallback usage continues uninterrupted, completely unobserved.
(Definitely NOT the end-all-be-all of security controls for NTLM)
The mitigation path is straightforward, but it requires intentional steps:
Add protected accounts to the Protected Users group. This removes NTLM as an option and disables weak Kerberos encryption types like RC4 or DES. However, implementation can break functionality, particularly for RDP. Client hosts must use fully qualified domain names (FQDNs) for Kerberos to succeed, service principal names (SPNs) must be configured correctly, and AES encryption types must be present on account objects. Many deployment failures occur because these prerequisites are overlooked. See Microsoft’s documentation.
Enable LSASS Protection on supported systems. This prevents untrusted binaries and processes from interacting with LSASS memory. It is enabled by default on newer versions of Windows (e.g., Windows 11 and Server 2022). See Microsoft’s documentation on how to enable.
Migrate toward Kerberos-only authentication wherever feasible. That includes auditing fallback patterns, resolving domain trust issues, fixing broken SPNs, and removing applications that force NTLM negotiation. Kerberos should not just be preferred. It should be enforced.
Enable logging and alerting for NTLM logon events, especially for high-privilege accounts. Without visibility, NTLM fallback is not just a vulnerability. It is an invisible one.
Begin disabling NTLM on systems that do not need it. A full domain-wide shutdown may be difficult, but a partial rollout can still reduce exposure. The goal is containment, not perfection.
Microsoft has committed to deprecating NTLM in future Windows versions, but attackers are not waiting for that roadmap. They continue to exploit what is still available, and in most environments, NTLM is still available until someone removes it deliberately.
SMB Misuse and the Relay Chain
Organisations might assume SMB is safe because they disabled SMBv1 after WannaCry. That was a good start. But it is not enough. SMB remains one of the most common protocols used in credential relay attacks, not because of exploits, but because of weak or inconsistent configuration. In many environments, SMB signing is enabled but not enforced. And that difference matters.
I often see environments where only the server requires signing, or only the client. In some cases, it is enabled in Group Policy but never validated in the actual session behaviour. That means SMB still accepts unsigned authentication messages, including those relayed from NTLM harvesting attacks. If Responder or Inveigh is running inside the network, or between firewall zones with low trust, NTLM hashes can still be captured and replayed directly to SMB file shares or system services that never challenge the signature.
This is not theoretical. I have watched red teams relay NTLM credentials to internal file servers that were marked “hardened” simply because SMBv1 was removed. Relay attacks work when SMB signing is optional. It must be enforced, both client and server side, for the handshake to be verified. Without that, an attacker does not need to crack the hash or escalate their privileges. They just need to be nearby and unnoticed.
In some assessments, I have also found SMB services exposed to the public internet, often tied to backup appliances, NAS systems, or printer management portals. That exposure is far less common now than it was pre-2017, but it still exists and it still allows remote enumeration or unauthenticated relay chains when signing is not enforced.]
The hardening order for SMB should prioritise enforcement:
Require SMB signing on both clients and servers through Group Policy, not just enable it.
Validate that signing is negotiated in actual session traffic, not just assumed from policy.
Remove SMBv1 completely from all systems. This protocol should not exist in modern environments under any circumstance.
Audit and block public SMB exposure, not just from the internet but across untrusted zones or hybrid network segments.
Instrument and alert on SMB logons from sensitive accounts or high-value systems, especially if they occur in unexpected zones.
The mistake most teams make is believing that removing SMBv1 was the finish line. It was the beginning. The real risk today comes from signed-looking configurations that still accept unsigned connections and the attackers who know the difference.
LDAP and the Illusion of Internal Safety
It is common to find LDAP used even in environments that claim TLS is standard, especially among IT teams who have historically grown up using unencrypted LDAP as the default. I have observed both LDAP and LDAPS traffic routinely crossing network boundaries, including between on‑premises and cloud environments, or across segmented firewall zones where internal traffic is not inspected closely. In these contexts many teams assume that internal network access is inherently safe, and they underestimate both the visibility and the potential interception of directory traffic.
Complex enterprise integrations such as Linux authentication bridges, SaaS single sign on, or directory synchronisation tools often default to plain LDAP because it is familiar or easier to configure. Teams may think that LDAPS is simply LDAP with encryption added, yet deployment of LDAPS typically requires valid certificates, properly configured ports, and matching domain names, all of which are often overlooked. Misconfigured certificate chains or incorrect mappings can silently force systems back to unencrypted LDAP without alerts.
This misconception creates risk. If a credential sync or authentication flow is using LDAP over the network, an attacker in a compromised segment or someone operating from a trusted zone can capture clear text credentials or derive session tokens. The data leakage is not just about passwords, it is about user and group metadata that can inform privilege escalation and identity mapping during an attack.
To harden this, the following practical steps are essential:
Migrate all LDAP usage to LDAPS or LDAP with TLS, particularly for traffic crossing trust boundaries or firewall zones. Any unencrypted directory queries should be considered suspicious by default. Check out Microsoft’s documentation for what is required and this older implementation guide.
Restrict plain LDAP access using firewall controls, host-based rules, or network segmentation to ensure only explicitly approved systems can broker directory lookups.
Validate certificate deployment, ensure the domain name and SAN configuration match the service identity, and test that clients are refusing fallback to unencrypted LDAP.
Deploy monitoring and alerting on unencrypted directory traffic, especially from accounts with elevated privileges or from systems that should only use secure authentication.
Educate teams on the difference between LDAP and LDAPS, emphasising that enabling TLS is not enough. Certificate validation, service identity, and client enforcement must also be part of the rollout.
LDAP often remains enabled not because teams are negligent but because legacy practice is not questioned. The belief that “internal directory traffic is safe” holds until someone intercepts it, and then the breach begins not with credentials stolen from a host, but with the very authentication stream meant to guarantee identity.
Telnet and FTP Are Still Getting Through
Telnet and FTP are often dismissed as relics, assumed to be long gone from modern networks. In reality, they still exist, sometimes hidden in plain sight, other times embedded deep within automation flows or legacy integrations. I rarely see Telnet exposed in production environments anymore, but I do still find it occasionally enabled on vendor appliances or lab systems that were never hardened. FTP, however, is a different story.
In professional services environments, especially in the legal sector, I still encounter active FTP usage for file transfers, client data handling, or backup processes. Sometimes it is wrapped into legacy job schedulers. Other times it is baked into vendor tooling. In most cases, the team using it is unaware that credentials and data are being transmitted in the clear.
These services are rarely defended because they are rarely reviewed. Telnet may be enabled but unused. FTP might be passing through a perimeter firewall that was configured years ago and never revisited. Because these are not seen as internet-facing, they are treated as low priority. But that logic assumes a compromised workstation or insider threat will never be in a position to listen. That is a dangerous assumption.
Plaintext protocols like Telnet and FTP expose cleartext credentials, unencrypted data, intercept-able commands, and lateral movement opportunities. The hardening response does not need to be complex:
Block ports 21 and 23 at the firewall by default unless specifically required
Replace FTP with SFTP, FTPS, or brokered transfer tools that enforce encryption and identity control
Inspect internal zones for open FTP or Telnet services using port scans or flow analysis, especially in environments where third party tools or scheduled transfers are in use
Where FTP is still in use, configure containerisation or directory level locking with least privilege access, ensuring that even if compromised, the account cannot move laterally beyond its intended folder or share
Review firewall exceptions and legacy NAT rules that may be quietly permitting access to these ports, internally or from vendor jump points
These protocols are not forgotten because of malice. They persist because no one thought to revisit them. But attackers do. Once they are inside the perimeter, these old defaults become new pathways.
Thanks to TCM Security for this amazing educational graphic. https://tcm-sec.com/llmnr-poisoning-and-how-to-prevent-it/
LLMNR, NetBIOS, and the Final Layer of Noise
LLMNR and NetBIOS are among the most commonly enabled attack surfaces I still find in internal environments. They are enabled by default on most Windows hosts, and in the absence of active effort to remove them, they remain functional, unused, and exploitable. In dozens of assessments, I have only seen one organisation fully disable both protocols across their estate. The rest had them running quietly in the background, often with no awareness of what they were doing or what they exposed.
Both LLMNR and NetBIOS are name resolution protocols. They exist to provide a fallback mechanism when DNS fails. That made sense twenty years ago in a flat network. It does not make sense today in environments with modern DNS, domain controllers, and segmented infrastructure. When a client fails to resolve a name through DNS, it broadcasts a request asking if any other system can help. An attacker with Responder or Inveigh can spoof a reply and intercept the connection attempt, capturing NTLM hashes in the process.
This method requires no exploit and very little skill. It can be launched from any system on the same subnet as the target. Once a hash is collected, it can be cracked offline or relayed to an internal service that accepts NTLM authentication without signing. These attacks work not because the systems are unpatched, but because the protocols are still turned on.
The reason they persist is simple. Most teams do not know what LLMNR or NetBIOS do. They see them in a scan report and assume they are legacy. They are. But they are also functional, and as long as they are enabled, they offer a pathway for early compromise. The mitigation is low effort and high reward:
Disable LLMNR and NetBIOS over TCP/IP via Group Policy or local settings. These protocols are rarely needed when modern DNS is in place.
Validate that fallback name resolution is not silently reenabled by domain join scripts, vendor tooling, or imaging pipelines.
Audit DHCP options to ensure legacy name services are not being pushed to clients automatically.
Block outbound NetBIOS traffic at the firewall wherever possible, especially between VLANs or across trust boundaries.
Confirm that internal security tooling can detect Responder-like activity or rogue name replies on local subnets.
LLMNR and NetBIOS are rarely at the centre of breach reports. But they are often the entry point. They are quiet, legacy, and forgotten—and that is exactly why they are still used.
Summary: Quiet Defaults, Loud Consequences
None of these protocols make headlines anymore. NTLM, SMB, LDAP, Telnet, FTP, LLMNR, and NetBIOS are rarely mentioned outside of audit reports or lab writeups. But in the field, they still enable credential theft, privilege relay, and lateral movement every day—not because they are unpatched, but because they are still enabled.
Attackers do not need to drop malware when the authentication stack is misconfigured. They do not need a zero day when the first three systems they scan are running plain FTP or respond to spoofed LLMNR broadcasts. These are the kinds of defaults that stop being visible to defenders after years of coexistence. But they are still visible to attackers.
What would I prioritise? Start with NTLM. Remove it where you can, and contain it where you cannot. Enforce SMB signing before worrying about version numbers. Audit LDAP flows across network boundaries and move toward LDAPS. Remove Telnet and FTP binaries entirely, and if FTP must remain, isolate it and constrain its reach. Then finally, clean up the noise disable LLMNR and NetBIOS, and shut the door on one of the oldest lateral footholds still in play. None of these fixes require new tools. They require old decisions to be revisited. Most of what gets exploited today is not new, and that is exactly what makes it so effective.
Get in touch