> These days, I think the best thing to disguise as is HTTPS. There is so much variety in HTTPS traffic and such a huge volume of it, that spotting hidden tunnels is very hard.

I'd assume this project is meant for scenarios in which this isn't an option.

In a pentest scenario, you sometimes have a shell on a system which has no route to the internet, and you lack permissions for a web proxy or you don't have access to one.

Your next best bet is probably tunneling over DNS with Iodine or something similar. Many internal DNS servers resolve external host names.

There might be scenarios in which DNS tunneling doesn't work and you have access to an internal SMTP server which you can then use to exchange data with your C2 server. These are exceedingly rare in my experience, and as you say running an entire SOCKS proxy over them would probably raise all kinds of alerts. I'd be very selective in what I would transfer.

> In a pentest scenario, you sometimes have a shell on a system which has no route to the internet, and you lack permissions for a web proxy or you don't have access to one.

How would using a proxy masquerading as SMTP be any more viable in this situation than a proxy masquerading as HTTPS?

> Your next best bet is probably tunneling over DNS with Iodine or something similar.

DNS typically does not involve bidirectional transfer of large volumes of encrypted traffic. Doing this over DNS would stick out like a sore thumb to anyone doing traffic analysis, whereas this is exactly what you'd expect to see over HTTPS.

> Many internal DNS servers resolve external host names.

Sure, but the internal DNS in this scenario would typically be either forwarding external DNS requests to an outside resolver determined by its own configuration, or is itself hosting a full DNS table. How would you be able to use your own proxy masquerading as DNS in this situation?

Your pentest scenario where you have an internal host without outbound access is an entirely different situation than what this SOCKS masquerading as SMTP code addresses. The posted code can't speak SMTP to an internal server and have the traffic relayed outside. The SMTP server the code provides is nothing more than a SOCKS proxy that pretends to speak SMTP for a few packets before the TLS connection starts and then everything inside the TLS session stops being SMTP.

A SOCKS-over-SMTP relay tool for your pentest scenario would be much more interesting (though with the way email works, probably not entirely realistic, much less stealthy). But there should be more work put into relaying tools to establish bidirectional traffic with the outside on highly restricted internal network. DNS is great but comes with a lot of limitations. Surly there are other common services available in companies that could be used.