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 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...
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?
This is reasonably standard functionality for backbone routers. They have to parse the TCP headers in hardware anyway, and can track common endpoints with O(1) state.
Of course, on the other end of the spectrum, the NSA has tapped into core internet links, is recording everything it possibly can, and is keeping it forever.
True, but Wireshark will highlight dodgy TCP frames (retransmits, dups, etc) which should give a small clue to look further. I agree that it is necessary to understand how TCP works (or have access to someone who does) in order to run Internet services.
For example, IP routers often peek at UDP/TCP port numbers to calculate ECMP flow hashing. This is technically naughty but it's read-only and it's only an optimization that isn't required for correct forwarding.
High end firewalls will monitor ICMP and can restrict the size of the payload. They'd probably also notice the large number of ICMP packets.
Big corporate places can completely restrict things and prevent any traffic from internal hosts to the internet. You can use proxying for web browsing etc. and then monitor that to check for any unauthorised traffic.
I'd think, in theory the ECMP router could keep track of the MTU on a per IP basis (rather than per TCP connection) based on it having received the ICM unreachable packet. And from that moment on, sending a spoofed ICMP packet back whenever one of the servers it's routing for sends a packet the router knows won't reach the host.
But even if that works, I'm by no means a network engineer, your solution of simply broadcasting the packets is probably more efficient in the real world.
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.
> 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'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 :)
reply