Key Features
Tech Stack
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.
For me RTP+rateless erasure codes come to mind, but I’m feeling Rube Goldbergy today.
https://blog.torproject.org/introducing-webtunnel-evading-ce...
RTP isn't a bad choice, especially the WebRTC flavor of it:
- it's UDP; there's no need to worry avoid 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
- it can be considered high bandwidth, and is typically highly irregular in the bandwidth use too
- 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 implementations (try `ssh -D`). SSH is what some of my friends successfully use to bypass the Great Firewall.
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.
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.
>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 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.
That's not what the referenced website says and it does not make sense at all.
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.
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'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.
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.
How would using a proxy masquerading as SMTP be any more viable in this situation than an 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?
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.
Someone watching closely might try to correlate the strangeness of the emails you receive with your candy crush habits...
SMTP is blocked by a lot of firewalls by default. All cloud providers do that and you need to request opening them up.
Ah the good old days when we didn't have cybersecurity...
This sounds like it would work for modern data-heavy websites. And good bit faster than the HTTP-over-DNS proxy I wrote years ago when I was travelling and would get stuck somewhere with only captive portals demanding payment.
(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).)
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.