Microsoft Telnet Server Flaw Lets Attackers Bypass Guest Login Restrictions

Security researchers have disclosed a series of high-risk vulnerabilities in Microsoft Telnet Server, specifically targeting the NTLM authentication mechanism within the Microsoft Telnet Authentication Protocol (MS-TNAP).

These flaws enable unauthenticated attackers to bypass login restrictions and potentially gain unauthorized access, including as the Guest account, on a wide range of legacy Windows systems.

Technical Overview

Vulnerability Summary

• Name: MS-TNAP Guest Access Restriction Bypass
• CVSS Score: 7.5 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N)
• Impacted Systems: Windows 2000, XP, Server 2003, Vista, Server 2008, Windows 7, Server 2008 R2
• Authentication Protocol: NTLM via MS-TNAP (Telnet: NT LAN Manager Authentication Protocol)
• No official patch available; disabling Telnet is strongly recommended.

Exploit Mechanism

The vulnerability arises from improper handling of NTLM Type 3 (AUTHENTICATE) messages in the Telnet server’s SSPI (Security Support Provider Interface) implementation.

By sending a specially crafted NTLM Type 3 message with empty credentials and the NEGOTIATE_ANONYMOUS flag, an attacker can force the server to map the authentication attempt to the Guest account, bypassing explicit Guest login restrictions.

Key technical details:

• The server processes NTLM messages using the following vulnerable SSPI calls: c// Credential initialization with both client and server flags AcquireCredentialsHandle( NULL, L"NTLM", SECPKG_CRED_BOTH, // Vulnerable flag NULL, NULL, NULL, NULL, &m_hCredential, &tsExpiry ); // AcceptSecurityContext with mutual auth and delegation AcceptSecurityContext( &m_hCredential, ((fDoNTLMAuthFirstTime) ? NULL : &m_hContext), &InBuffDesc, ASC_REQ_REPLAY_DETECT | ASC_REQ_MUTUAL_AUTH | ASC_REQ_DELEGATE, // Vulnerable flags SECURITY_NATIVE_DREP, &m_hContext, &OutBuffDesc, &fContextAttr, &tsExpiry );
• NTLM Type 3 Message Construction:
  • Flags: NEGOTIATE_ANONYMOUS | NEGOTIATE_NTLM (0x00000A01)
  • All credential fields (LM/NTLM responses, domain, username, workstation, session key) are empty.
• The server’s SSPI maps this message to the Guest account SID, bypassing the restriction normally enforced in password-based logins.

Authentication Flow Comparison

Exploit Usage

A proof-of-concept tool, telnetguest.exe, automates the attack. Usage example:

bashtelnetguest.exe <target_ip> [port]

• target_ip: Target Windows Telnet Server IP
• port: Optional (default 23)

If the Guest account is a member of the TelnetClients group, the attacker may gain an interactive Telnet session, though shell access may still be limited by group policy or account restrictions.

Risk and Mitigation

• Risk: Allows remote, unauthenticated attackers to log in as Guest-even if the account is renamed-bypassing intended restrictions.
• Mitigations:
  • Disable the Guest account and ensure it is not in the TelnetClients group.
  • Disable NTLM authentication or the Telnet service entirely.
  • Restrict network access to port 23 (Telnet).
  • Monitor authentication logs for suspicious Guest or anonymous logins.

Table: Affected Windows Versions

These vulnerabilities highlight the ongoing risks of maintaining legacy protocols and services.

Organizations are urged to disable Microsoft Telnet Server and migrate to more secure alternatives such as SSH.

No patch is currently available, and the exploit is publicly documented, increasing the risk of widespread attacks.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant updates