Skip to content
HackIndex logo

HackIndex

IMAP Weak Authentication Testing

3 min read Mar 29, 2026

IMAP authentication weaknesses expose credentials to network interception when AUTH mechanisms are available on port 143 without requiring STARTTLS first. The RFC-defined control for this is the LOGINDISABLED capability — its presence on port 143 means the server blocks login commands before TLS. Its absence means plaintext authentication is permitted. Run these checks after IMAP enumeration confirms the available capabilities.

LOGINDISABLED Absent on Port 143

The absence of LOGINDISABLED in the CAPABILITY response on port 143 means the server accepts LOGIN commands in plaintext:

┌──(kali㉿kali)-[~]
└─$ printf 'a0 CAPABILITY\r\na1 LOGOUT\r\n' | nc -nv $TARGET_IP 143 | grep -iE 'capability|logindisabled|starttls|auth' 
* CAPABILITY IMAP4rev1 SASL-IR STARTTLS AUTH=PLAIN AUTH=LOGIN

STARTTLS is advertised but LOGINDISABLED is absent — the server does not enforce TLS before login. AUTH=PLAIN and AUTH=LOGIN are available in plaintext context. Confirm by attempting a login without STARTTLS:

┌──(kali㉿kali)-[~]
└─$ printf 'a1 LOGIN testuser wrongpassword\r\na2 LOGOUT\r\n' | nc -nv $TARGET_IP 143 | grep -E 'a1|NO|OK' 
a1 NO [AUTHENTICATIONFAILED] Authentication failed.

An authentication failure response — rather than a rejection saying TLS is required — confirms the server processed the LOGIN command over plaintext. A correctly hardened server would respond with something like NO [PRIVACYREQUIRED] Plaintext authentication disallowed.

No TLS Available at All

When port 993 is closed and STARTTLS is absent from CAPABILITY on port 143, all IMAP traffic is permanently plaintext:

┌──(kali㉿kali)-[~]
└─$ nmap -sV -p 143,993 $TARGET_IP | grep -E 'open|closed|filtered' 
143/tcp open   imap
993/tcp closed imaps
┌──(kali㉿kali)-[~]
└─$ printf 'a0 CAPABILITY\r\na1 LOGOUT\r\n' | nc -nv $TARGET_IP 143 | grep -i starttls

No STARTTLS in CAPABILITY and port 993 closed confirms no TLS path exists. Every credential sent to this server and every message downloaded is visible in plaintext on the network.

Weak Mechanisms Only

Check whether only weak AUTH mechanisms are available — PLAIN and LOGIN carry credentials in base64, trivially reversible. Compare what is offered before and after STARTTLS:

┌──(kali㉿kali)-[~]
└─$ echo "Port 143 (plaintext):"; printf 'a0 CAPABILITY\r\na1 LOGOUT\r\n' | nc -nv $TARGET_IP 143 2>/dev/null | grep -i auth
┌──(kali㉿kali)-[~]
└─$ echo "Port 993 (TLS):"; printf 'z0 CAPABILITY\r\nz1 LOGOUT\r\n' | openssl s_client -connect $TARGET_IP:993 -crlf -quiet 2>/dev/null | grep -i auth 
Port 143 (plaintext):
AUTH=PLAIN AUTH=LOGIN
Port 993 (TLS):
AUTH=PLAIN AUTH=LOGIN AUTH=NTLM AUTH=SCRAM-SHA-256

Only PLAIN and LOGIN on port 143 while port 993 offers SCRAM-SHA-256 confirms stronger mechanisms exist but the plaintext port is not hardened. The server should enforce STARTTLS before advertising or accepting any AUTH mechanisms.

Verify STARTTLS Is Not Bypassed

Some servers advertise STARTTLS but still allow AUTH before the upgrade. Test explicitly by sending AUTH immediately without STARTTLS:

┌──(kali㉿kali)-[~]
└─$ printf 'a1 AUTHENTICATE PLAIN\r\na2 LOGOUT\r\n' | nc -nv $TARGET_IP 143 | grep -E 'a1|\+' 
+ (base64 challenge)

A + challenge response to AUTHENTICATE PLAIN on port 143 without STARTTLS first confirms the server accepted the AUTH initiation in plaintext. This is the misconfiguration — STARTTLS is advertised but not enforced before AUTH. Move to credential attacks to exploit this surface.

References