Comment by bmenrigh
2 days ago
Large volumes of SMTP-like traffic are a huge red flag. Competent companies an ISPs should already be looking for large volumes of outbound mail to identify abuse / spam bots / data exfiltration.
If I came across this in netflow data I'd first assume outbound spam. But a hallmark of sending mail is that the client to server byte ratio is extremely skewed towards client -> server bytes, whereas running a VPN-like service is usually more balanced but still skewed towards server -> client bytes. I'd see the large server -> client byte count and immediately know something strange was going on.
That said, very little code here is involved in looking like SMTP. The SMTP obfuscation basically boils down to a few lines of plaintext between the client and server before a STARTTLS and then everything after that has nothing to do with SMTP. You could swap out the fake stub conversation quite easily to look like many other protocols. Whether the in to out bytes ratio makes sense for those protocols is another matter.
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.
> 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?
The goto tool that practically anyone doing any DNS tunneling uses is dnscat2 (https://github.com/iagox86/dnscat2). It works fine through recursive/forwarding resolvers because those resolvers must recurse out to the authoritative nameserver for a given domain in order to resolve the name request. With dnscat2 you use the server component "hosting" a "zone" using a domain name you own / control (so that you can point the authoritative nameserver record to the dnscat2 server component). You then use the dnscat2 client to packages up TCP traffic into DNS specially crafted DNS requests to the domain you control where the server is listening. The design is very clever and has to solve a lot of tricky technical problems.
As for detection, you're entirely right that sending large volumes of traffic over DNS is both incredibly slow, and incredibly obvious to any network defenders paying attention to DNS.
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.
Oh, sorry, I guess I should have read more carefully. I don't really see the point of this either, then.
Making a dumb iphone game is a good excuse to send random HTTPS traffic, but receiving packets encoded as emails via (say) IMAP would be a good way to bring back large(ish) amounts of data.
Someone watching closely might try to correlate the strangeness of the emails you receive with your candy crush habits...
a former company I was at, didn't allow outbound ssh (which I liked to enable me to vnc into boxes at home). I installed installed a webvnc application on my home machine (protected by https / password) and was able to access it without an issue.
When I left the company they went through my outbound email and were like "why did you forward an email you got out of the company". That e-mail was a friend visiting and me getting sent their picture from the lobby telling me that I had a visitor (so figured it be cute to share the image with them). I was amused that they only bothered to ask me as I was leaving, not when it actually occurred.
I used to host an SSH server at home at port 443, for the same reason! The sysadmin of my employer was so strict that 'solutions' like this were the way of the least resistance. Security gets worse when policies get stricter.