How it works: - Client runs a local SOCKS5 proxy (127.0.0.1:1080) - Traffic is sent to server disguised as SMTP (EHLO, STARTTLS, AUTH) - DPI sees legitimate email session, not a VPN/proxy
Features: - One-liner install on any Linux VPS - Multi-user with per-user secrets and IP whitelists - Auto-generated client packages (just double-click to run) - Auto-reconnect on connection loss - Works with any app that supports SOCKS5
Tech: Python/asyncio, TLS 1.2+, HMAC-SHA256 auth
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.
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.
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?
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.
Someone watching closely might try to correlate the strangeness of the emails you receive with your candy crush habits...
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.
Interesting idea though, spoofing other protocols than HTTP/HTTPS are probably a good idea for censorship evasion in countries with incredibly strict national firewalls.
Ending up on any DNSBLs shouldn't be a problem unless you have a static home IP you plan on running an actual SMTP server from after this though.
For me RTP+rateless erasure codes come to mind, but I’m feeling Rube Goldbergy today.
RTP isn't a bad choice, especially the WebRTC flavor of it:
- it's UDP; there's no need to worry avoid the TCP meltdown
- it's most commonly used for peer-to-peer and PBX communication; packets going in and out, from and to random IPs are expected
- high bandwidth RTP traffic is normal, so are high irregularities
- it most often carries video; huge room for steganography
- WebRTC makes encryption mandatory
I've come across corporate networks that do block non-intranet WebRTC, however this probably isn't feasible at the Internet scale.
Other good choices are QUIC and WebSockets (assuming your network doesn't do MitM), and SSH, which by default comes with strong protection against MitM and actually has SOCKS5 tunneling built into the most popular implementations (try `ssh -D`). SSH is what some of my friends successfully use to bypass the Great Firewall.
That being said, the shift of client-to-server SMTP from a common part of everyday internet traffic to something rather esoteric may have created some potential for firewall misconfigurations, and those might result in it being passed with minimal inspection. All depends on your particular firewall in the end.
Clever
I think its polite to indicate AI agent usage in security related projects like this since they can have huge holes if they're just being vibe coded.
-- Edit: Intended to post this on the board root, sorry.
Looking through the code itself, I can't tell if it's AI generated or not, but I wouldn't assume the use of emoji automatically mean AI wrote the text.
(Even with complete HTTPS decryption in the firewall, the downstream traffic could look like, say, random CSV data file downloads or innocuous HTML text, and upstream traffic could look like innocuous requests (avoiding large lists of problematic keywords).)
SMTP is blocked by a lot of firewalls by default. All cloud providers do that and you need to request opening them up.
