Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

github.com

Post reply on HN
Print view View original

31–40 of 56 posts

Re: Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

#31

Post by pogue »

GoblinSlayer wrote: post #28
pogue wrote: post #9

Earlier quoted context omitted.

>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 Shoda…

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.

Re: Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

#32

Post by geocar »

bmenrigh wrote: post #22

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 serv…

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

Re: Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

#33

Post by stackskipton »

Gathering6678 wrote: post #15

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

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

Re: Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

#34

Post by janwillemb »

compsciphd wrote: post #26
bmenrigh wrote: post #22

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 serv…

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…

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.

Re: Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

#35

Post by mr_mitm »

bmenrigh wrote: post #22

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 serv…

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

Re: Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

#37

Post by bmenrigh »

mr_mitm wrote: post #35
bmenrigh wrote: post #22

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 serv…

> 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 t…

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.

Re: Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

#38

Post by mr_mitm »

bmenrigh wrote: post #37
mr_mitm wrote: post #35

Earlier quoted context omitted.

> 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 t…

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…

Oh, sorry, I guess I should have read more carefully. I don't really see the point of this either, then.

Re: Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

#39

Post by Gormo »

mr_mitm wrote: post #35
bmenrigh wrote: post #22

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 serv…

> 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 t…

> 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?

Re: Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

#40

Post by bmenrigh »

Gormo wrote: post #39
mr_mitm wrote: post #35

Earlier quoted context omitted.

> 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 t…

> 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 bidirection…

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.

Post reply on HN