Recently, Kaspersky published a research about how a russian APT group use hijacked satellite links to anonymise their malware command-and-control (C&C) servers (Satellite Turla: APT Command and Control in the Sky). As they say in their blog post, I researched and published how to abuse satellite DVB-S/2 internet communications, the technique used during the Epic Turla operation.
Short explanation
Satellite DVB-S/2 connections are, sometimes, unencrypted so with cheap hardware and some free software the downlink can be sniffed. By using the satellite as the downlink of an Internet connection, an attacker can use another connection which let to spoof IP address as a uplink and then have a hijacked IP from the satellite provider to use as a normal one and almost completely anonymous.
One good thing about this technique is to have an anonymous broadband connection directly to the attackers base/home/server/laptop without proxies/bouncers – if you have ever used TOR, you’ll probably realise know how useful these characteristics can be.
In summary, the attackers were using satellite link to anonymise their activities and prevent them being tracked. In this blog post I’ll show some ideas to track malicious agents trying to hide behind satellite links.
The anonymous connection
What to do when these connections are being used for “bad things”? I have also tried to research about different ways to locate these rogue connections. Here are a few ideas on how to solve this challenge:
The attacker connection is also vulnerable to attacks
If an attacker is using a connection vulnerable to sniffing and “Man-In-The-Middle” attacks, the communication stay vulnerable, so we can attack these:
Hijack communications with the systems the attacker is connecting with.
If the attacker navigate through HTTP, in some circumstances we can inject HTML or JavaScript code to get information of the target system.
Sometimes we can inject fake executable, ActiveX or Applets and try to cheat the attacker.
If the attacker system is configured as I proposed in my talk, that system can be reached with an satellite IP address, we can try to attack it.
Definitely these attacks can provide us information about the attacker but, most probably, not an address or a name.
Attack the network
Let’s redraw again the network diagram:
Here I draw R1 and R2, which are the routers of the ISP the attacker is using as the uplink channel of the hijacked satellite-based connection.
It’s not possible to get an IP address of the attacker because it is configured with the hijacked IP address, but, is it possible to get the IP address of R1 or R2? Getting that information can be really useful in the hunting of an attacker, remember that the target must use a local internet connection as uplink.
How can we get router IP addresses?
We can wait till the attacker do a traceroute, that can be a lot of time. We can´t control the TTL of an IP packet leaving the target host so let´s think in other way.
Record route
Another option is to ping the target and activate the record route option on IP, you can do that using hping:
# hping3 -1 IPsat -G
The record route option provides a means to record the route of an Internet packet. When an Internet module routes a packet it checks to see if the record route option is present. If it is, it inserts its own Internet address as known in the environment into which this packet is being forwarded into the recorded route.
We have it? No, this option must be activated in all routing devices, from you to the target and back, and usually this option is disabled – in a lot of years doing pentesting, I have only seen it work in a small fraction of cases.
ICMP errors
Another option I found with possibilities is to create IP traffic rejected by the uplink ISP routers (R1 or R2), and sniff the ICMP Destination Unreachable packets to get the IP of R1 or R2.
For example, pinging the satellite IP of the target from an internal address, the remote system will respond to the private IP echo with a ICMP echo response. If the traffic to that internal subnet is rejected by the uplink ISP routers, and usually it is, the routers will send an ICMP error to the satellite IP from the router own IP, so we can sniff that ICMP packet and get the IP address:
- We send a ping request spoofing the source address:
# hping3 -1 IPsat -a 10.30.16.41
- The target system send a ping response to 10.30.16.41:
- Traffic to 10.30.16.41 is not allowed so the packet is rejected by R1 to IPsat, so we can sniff that packet and know the IP of R1:
Some problems we find to use this technique:
What private IP addresses are rejected? We have to send several packets to the IP of the target, 69781, one packet per private C range or 17891228 which is the number of all private IP addressed.
What if the private IP addressed are filtered and not rejected? Bad luck.
The target host filter packets which come from private IP addresses via satellite interface? Bad luck.
What if the target host have filtered the ICMP ping? Please…
The idea of the target sending traffic to internal IP addresses can be exploited from several angles, for example, injecting malicious JavaScript on the targets browsers if he use it. Imagination! Imagination! Imagination!
Conclusion
So, if the attacker who is hijacking the satellite Internet connection is clever enough, this kind of connections are still anonymous. But, as I thought some attacks to break the anonymity, sure you people can follow this way.