Security researchers have uncovered a severe vulnerability affecting the Microsoft Telnet Client, which allows remote attackers to harvest user credentials without any interaction from the victim. This “0-Click Telnet Vulnerability” exploits the MS-TNAP authentication mechanism built into Telnet, a legacy protocol still presents on many Windows systems.
Exploiting Microsoft Telnet Through MS-TNAP
The vulnerability exists in the MS-TNAP (Microsoft Telnet Authentication Protocol), a feature of the Microsoft Telnet Client. The attack method involves luring a victim into connecting to a rogue Telnet server, either via telnet.exe or a telnet:// URI link. If the server is within a Trusted Zone or configured for silent authentication, the Telnet client will automatically send NTLM credentials to the attacker without displaying any warning to the user.
This silent transmission of credentials makes the attack particularly effective in internal networks or environments where IP addresses have been incorrectly added to Trusted Sites or the Intranet Zone without protocol specificity.
As the proof-of-concept (PoC) reveals, an attacker can complete the MS-TNAP authentication process and intercept sensitive NTLM authentication material. These stolen hashes can then be used for NTLM relay attacks or subjected to offline password cracking using tools like Hashcat.
Zones and Silent Credential Leakage
Microsoft Windows utilizes zone-based security settings to determine how authentication prompts are handled when connecting to a remote server. While servers in the Internet Zone will prompt the user with a clear warning message— “You are about to send your password information to a remote computer in the Internet zone. This might not be safe. Do you want to send anyway (y/n):” —Servers in the Intranet Zone or Trusted Sites Zone may trigger no prompt at all.
This becomes a major security concern when organizations configure zone settings using generic IP addresses like 192.168.1.1 rather than specifying http://192.168.1.1, unintentionally applying trust to all protocols, including Telnet. Since the Microsoft Telnet Client checks trust based on the full protocol and host combination (telnet://host), using protocol-specific entries in zone configuration is vital to prevent silent authentication.
Real-World Demonstration and Exploit Use
The PoC, developed by Hacker Fantastic of Hacker House, simulates a malicious Telnet server that listens on port 23 and logs NTLM authentication data from connecting clients. Detailed debug outputs showcase the entire exchange of NTLM Type 1, 2, and 3 messages, including domain names, usernames, hostnames, and encrypted responses.
Captured hashes are saved in formats compatible with tools like Hashcat. An example cracking session showed successful recovery of credentials at a speed of over 11,000 hashes per second using NetNTLMv2 mode (-m 5600), resulting in full credential disclosure such as:
ADMINISTRATOR::WIN-ROTQIHG6IIG:317c02ac078a3c43:…:Password1
These logs confirm the ease with which credentials can be harvested, all without requiring the user to click anything beyond the initial telnet:// link—hence the “0-click” designation.
Conclusion
To mitigate the critical 0-Click Telnet vulnerability, Microsoft administrators should disable the Telnet Client unless necessary and, if used, disable NTLM authentication via the registry. Avoid adding IPs without protocol specifiers to Trusted or Intranet Zones, and replace Telnet with SSH for secure communication.
Regular audits of security settings are essential to prevent risks. In corporate environments, attackers can exploit Telnet to leak credentials, highlighting the need for strict security controls around authentication and network trust zones. Given the exploit’s stealth and ease, organizations must prioritize addressing this vulnerability to protect network integrity.
