I think it's just that most scanning tools aren't trying to unwrap a TCP packet inside a TCP packet, so it bypassed their naive filters. Once a researcher spotted it, it was trivial to unwrap, but automated tooling would just see it as the outer TCP packet with some opaque data inside of it.
I would assume that the attacker's destination IP would show up on some dashboards somewhere though...
Unless I missed something in the article, I'm not sure this is odd or malicious behavior. The NTP servers know your IPs because you sent packets to them from those IPs. So you basically told them what your big random 128-bit IPv6 address is.
And the fact that they sent packets back to you (after you sent them packets) is not surprising either. However, if you can show that a full-blown port scan occurred after you sent them packets, then that would be odd. I did not see evidence of that in the article... did I miss that?
They can see that anyway if they intercept the traffic anyway, since the IP will be in all packets. Even better, the TCP connection will end up creating routing tables on all hops along the way.
I work for an ISP. I fired up a capture one day out of curiosity and instantly saw thousands of packets per second destined for 23/TCP across our address space. There's a LOT of these compromised devices out there that are just constantly scanning the entire IPv4 address space.
Nod, I remember it not being as effective/easy to hide as exfiltration over UDP/DNS too, as there was always less background noise to hide in. That said, I found this with a quick search - https://github.com/utoni/ptunnel-ng for those who still want to do it. A number of hotels and captive portals still let pings through relatively unmolested even if they play tricks with UDP/TCP.
Any significant data over ICMP will always stick out though if anyone is doing analysis. Which isn’t often, frankly, in situations like I described, but…
I don't get it. It is impossible to identify who receives the packets but TCP/IP requires an acknowledgement that the packets have been received before sending more packets. Surely the C&C could be tracked from this acknowledgement? Or were they using UDP?
It wasn't inadvertent. It was by design. Lets get that straight. If, for example, you're running tcpdump(1) with a packet capture size of 1500 (I don't know if G was doing that, but I'm giving an example), then you can't claim that you captured the packets' contents inadvertently.
Many years ago, when writing web crawlers was the cool thing to do, I wrote one (like an idiot, I wanted to see how deep the web was). Unfortunately, I didn't have a good synchronization scheme, so it ended up beating on a poor website for too long. The operator of that site sent a stern email to our DNS contacts, complaining. And we shut the crawler down. Today, I fear I'd be indicted for "wire fraud"!
Right? That would be much more interesting, and I wonder why they didn't show packet data. They already went through the work of setting up wireshark, might as well peek into the packet data to see what's going on.
> Packet sniffing and hardware inspection both instantly disprove...
I'm under the impression that packet sniffing is useless with end-to-end encryption, but I could be wrong. I.e., you can tell that something is being sent, but you can't know what.
Among many other methods (such as the deep packet inspection devices that have been common for quite a while), one particularly easy attack would be checking the TCP initial sequence numbers for changes in randomness[1].
Similarly, port number and usage can also be an easy tell when you see sockets opening on a pattern like this over time: [ ..., 15001, 15002, 15005, 9004, 9005, 15006, 9006, ...]
Often IPmasq/NAT doesn't help either, as it can exhibit its own distinct pattern of port/etc usage often due to how router maintains its statefulness.
I'm not sure about `tcptraceroute` but `traceroute -T` seems to be using SYN packets with tweaked TTL value [1].
There is an even more interesting technique - injecting packets with modified TTL into a currently running and valid TCP/IP connection. This often can be used to detect network setup behind NAT on the server side. I think the most famous attempt was 0trace by Michal Zalewski [2] but there are many implementations. Oh boy, one day I even created an Nmap script to do this [3], those were the days :)
> make educated guesses that it might be iptables rule, or continue delving deeper to figure out what those hooks are etc
Would it be a good idea to let pwru dig into the iptables detour to provide the whole view of the packet's journey - or is iptables at a different layer whose observability is best left to another tool ?
I would assume that the attacker's destination IP would show up on some dashboards somewhere though...
reply