Nessus reported the issue but gave the following output for steps to duplicate:
Nessus sent the following two commands in a single packet : AUTH TLS\r\nFEAT\r\n And the server sent the following two responses : 234 AUTH command ok. Expecting TLS Negotiation. 211-Extended features supported: LANG EN* UTF8 AUTH TLS;TLS-C;SSL;TLS-P; PBSZ PROT C;P; CCC HOST SIZE MDTM 211 ENDNow, I may not be the smartest person when it comes to telnet but I am pretty sure you are not able to pass '\r\n' into a telnet session. After making a few attempts my suspicions were confirmed and I was left wondering what it was I needed to do to get the command to execute properly.
I turned to google for help and found a forum that answered my question: control character for 'return'/'enter' = ^J. By using ^J I was able to insert a 'return' but not have the return executed until after I physically hit the return button when I was done with the commands I wanted to execute.
testing:~ hyrum$ telnet www.testsite.com 21 Trying 1.2.3.4... Connected to www.testsite.com. Escape character is '^]'. 220 Microsoft FTP Service AUTH TLS^JFEAT 234 AUTH command ok. Expecting TLS Negotiation. 211-Extended features supported: LANG EN* UTF8 AUTH TLS;TLS-C;SSL;TLS-P; PBSZ PROT C;P; CCC HOST SIZE MDTM 211 ENDBy inserting ^J after the 'AUTH TLS' it was possible to add the FEAT command which according to the rftc (rfc4217) if you pass the FEAT command to the server the server must respond with the available features:
"If a server supports the FEAT command, then it MUST advertise supported AUTH, PBSZ, and PROT commands in the reply, as described in section 3.2 of [RFC-2389]."
It ended up being that simple. Control Characters really do come in handy sometimes. So, the next time you want to pass two commands while in a telnet session don't forget about ^J.