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.

That's an interesting protocol choice, especially given the purpose. SMTP is probably the most filtered protocol on residential networks, SMB being a runner-up.

SMTP isn't filtered it's port 25 that is. And from a short look at the readme it looks like it's using the transmission port 587 which shouldn't be filtered.

Any decent firewall these days is layer 7 aware. The port doesn't make a difference

I was thinking this too. I'm assuming it doesn't look like an SMTP server from the outside? Because if it does, that would absolutely land your IP up on many, many DNSbls very quickly if it started getting probed.

Interesting idea though, spoofing other protocols than HTTP/HTTPS are probably a good idea for censorship evasion in countries with incredibly strict national firewalls.

TECHNICAL.md lays it out a bit more, but it claims to be RFC 5321 compliant with a realistic initiation sequence so it should somewhat look like a real SMTP server for the first bit.

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.

>SMTP traffic on port 587 (submission) is expected and normal

Any residential dynamic or static IP with this port opened is definitely going to get flagged. Most ISPs already prevent these ports from being open, either by policy or by residential routers.

It would probably very quickly end up on something like SpamHaus's PBL, which looks for this kind of thing.[1]

I would imagine you would also find yourself on Shodan pretty quickly getting hit with constant nmap & login attempts from malicious actors. Spam bots are always looking for insecure servers to send emails from.

I feel like ssh, SFTP, or even a secure DNS server would probably make more sense as something to hide traffic from DPI than an SMTP server.

[1] https://www.spamhaus.org/blocklists/policy-blocklist/

Again, unless you're actually planning on sending "real" SMTP traffic to other "real" SMTP servers from your own "real" SMTP server operating on the same address, then getting put on SpamHaus (or other DNSBLs) for having the port open w/o rDNS or etc configured is irrelevant. Like you say, there is a decent chance your ISP just blocks the port anyways and makes such a setup unfeasible though, but that's why the readme says to host this on a VPS which allows the port.

Any time you have any externally open TCP port (home or VPS) you should expect to get scanned to shit by Shodan and millions of other bots. It doesn't matter if it's the default port for SFTP, DNS, SMTP, HTTP, Minecraft, or whatever - all of them are great targets for malicious actors and as soon as the bots detect one open port they'll scan everything on that IP harder. I once forgot to disable certain default enabled login types and failed connection/authentication logging when exposing SSH/SFTP externally and ended up with GBs of logs in just one week.

Spamhaus blocks port 25, not 587. If they blocked port 587, they would blanket ban all email clients.

SpamHaus lists IPs to blocks, not ports.

Sure but from your link

>The PBL detects end-user IP address ranges which should not be attempting to directly deliver unauthenticated SMTP email to any Internet mail server. All the email originated by an IP listed in PBL is expected to be submitted - using authentication - to a SMTP server which delivers it to destination

Means in practice port 25 (unauthenticated) and port 587 (authenticated)

> Any residential dynamic or static IP with this port opened is definitely going to get flagged.

That's not what the referenced website says and it does not make sense at all.

What would you reach for out of curiosity?

For me RTP+rateless erasure codes come to mind, but I’m feeling Rube Goldbergy today.

All boils down to the kind of DPI you're trying to work around, but generally the most common encrypted or otherwise difficult to process protocols strike me as the most preferable.

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.

I think HTTP web sockets would be an interesting tunneling protocol.

Tor has a transport using exactly that.

https://blog.torproject.org/introducing-webtunnel-evading-ce...

You don't need websockets, just Connection: Upgrade to anything you want. You can upgrade directly to ssh protocol and just pass on decrypted data from https socket to local port 22 from then on with no further processing.

Proper DPI can tell that wouldn't be acting like a typical HTTP stream, encrypted or not.

IP over Avian Carriers

This seems daft to me as it would be trivial to identify on a network. Real SMTP will have significant data flow in one direction towards the destination, will close the connection fairly quickly once it's transferred (so no pauses) and has very little traffic being returned. It's hard to think of a worst protocol to try to hide a proxy in.

So many comments explaining this is a bad idea while OP just asked claude code to write this and probably doesn't even know the difference between TCP and IP.

Quite a few things use STARTTLS. I imagine the same technique could be applied to those other protocols, giving users some options as they fight hostile networks.

Clever

Just curious - how much of this was AI generated? The readme has crazy emojis & the code was all checked in at once, which is usually my telltale for these kinds of things. Didn't see anything crazy in the source files.

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.

High emoji use is something I've noticed a certain generation/subgroup of developers just default to. Keeps things informal/quirky. The AI had to steal that style from someone, after all. This repo is actually very low on the emoji side.

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.

It's a fair question but I had a bit of a chuckle at the idea having a shit ton of emojis in your GitHub readme was the first flag it might be AI. Mostly because I always assumed the opposite - that GitHub readmes were a big part of the emoji ridden listicle training data (the other being slop "news" site/social media listicles) for AIs in the first place. After all, they are decently well written and come with grabbing the code to train from anyways.

Before the rise of AI, I had not seen much GitHub content with emojis at all, much less overused; I suspect their source is actually the latter of what you noted. Either way, it's a negative signal.

I suppose it would be trivial to simply block or severely throttle high-volume SMTP traffic?

Additionally, this will make it look like you're a spammer.

You could block SMTP on almost all end user networks with no one noticing. 99.9+% of email client submission is HTTPS.

I doubt it's that much but with the same logic you could also ban HN, SSH and basically any protocol thats not https "with no one noticing" because 99.9+% doesnt use it.

Source:

Back in the 90s, I ran telnet on the POP3 port so I could IRC in the lab during high school. The more things change, the more they stay the same.

How does this get past firewalls that would block the alternative, of SOCKS5 traffic tunneled through port-443 HTTPS with keepalives?

(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).)

Here's a similar project that uses IMAP instead of SMTP: https://github.com/x011/imap-tunnel-proxy

Get yourself an IP with Port 443 free and just use that.

SMTP is blocked by a lot of firewalls by default. All cloud providers do that and you need to request opening them up.

It would be great if it also worked as SMTP server