I recently found two very interesting Linux binaries uploaded to Virustotal.
I call this malware 'GTPDOOR'.
GTPDOOR is a 'magic/wakeup' packet backdoor that uses a novel C2 transport protocol: GTP (GPRS Tunnelling Protocol), silently listening on the GRX network (1/n) 🧵
One version uploaded from 🇨🇳 has zero detections on VT. The other, uploaded from 🇮🇹 has just one detection.
These were uploaded 4 to 5 months ago.
(2/n)
As they binaries were not stripped, they contain some artifacts that give us an idea of the intended platforms they were to be run on - Very outdated Red Hat Linux machines.
Someone hasn't been keeping their systems up to date .. 🤔
(3/n))
When run, the first thing GTPDOOR does is process-name stomps itself - changing it's process name to "[syslog]" - disguised as syslog invoked from the kernel.
It supresses child signals and then opens a raw socket.
(4/n)
The raw socket will allow the implant to receive UDP messages that hit the network interfaces.
It then matches those with destination port of 2123. This is the 3GPP standard port for the GTP-C protocol.
It then looks for only those that are of GTP_ECHO_REQUEST.
(5/n)
Before moving further, the message is authenticated - `idkey` must be supplied and correct. It's hardcoded, but as we will see later, it can be dynamically updated at runtime.
(6/n)
The payload of the message is then decrypted with the same key. This is a simple XOR cipher.
(7/n)
Next the message command type is read. There are different message types depending on the binary.
This is all documented in a blog post I've just whipped up.
The packet format is something like this. IP/UDP/GTP/GTPDOOR.
For example, the tailing bytes (MESSAGE DATA) will contain a command to execute remotely.
Why use GTP for the C2 communications?
(9/n)
This implant looks like it is designed to sit on compromised hosts that directly touch the GRX network - these are the systems that communicate to other telecommunication operator networks via the GRX.
Examples include the 2/3G: eDNS, GGSN, SGSN,STP, 4G: PGW, DRA and more (10/n)
Let's cut the chase. This is almost certain to be attributed to the threat actor UNC1954 (Mandiant) or LightBasin (CrowdStrike).
This actor has used GTP-U (traffic plane / PDP Context) for covert tunnelling.
With this implant, the use the GTP port associated not with traffic plane (GTP-U), but control plane (GTP-C).
GRX firewalls have to allow these protocols to some of the systems described earlier, so the C2 traffic blends right in with other mobile network traffic. (12/n)
Again:
What makes magic / wakeup / port knocking backdoors so stealthy as they don't need to listen on any service.
These backdoors have been around since the 90s but they still are used because they are effective.
No listening services / open ports - just a process idle sitting and waiting for it's magic packet.
BPFDOOR was a recent one. It was also found in telco networks (although attributed to a different actor).
An interesting feature in one version of GTPDOOR a second raw socket that pulls in all TCP packets off the interface to inspect.
The implant beacons out a very particular TCP message to the source IP of every TCP message - except those listed in a defined ACL. WEIRD!
(14/n)
The TCP packet it beacons out has no data / payload. Just the TCP RST/ACK flags are set.
No data? Look closely. Super stealthy.... 🕵️🕵️♀️🕵️♂️
(15/n)
My best guess on what's going on here is this:
You send a TCP packet to ANY port on an infected host's GRX interface address.
Any beacon reply = confirmation implant running +
TCP urgent ptr flag == 1? dst port was open
TCP urgent ptr flag == 0? dst port was closed
They are hiding a message inside a TCP header. I think I read about this first in some old hacking book from the early 2000s. Was it "Counter Hack"?
Now there are some conditions for this beacon to be sent - An ACL "deny list" needs to be set - possibly to prevent beacons hitting the target network infrastructure.
If my theory is right here, then it could be possible to scan the entire GRX to find compromised servers / telco network operators?🤔
(16/n)
Here is a tcpdump capture of the probe message sent to port 22 which is open (SSH running).,
The received beacon TCP RST/ACK message has the urgent flag set.
This actor is known for it's stealth, and this is the perfect example.
(17/n)
I think I'll wrap this up now. A YARA rule can be found on my blog post on this backdoor for all you threat hunters.
I'm sure someone will come up with a much better one real soon.
The Chinese APT contractor leak contained a few interesting files; namely:
- CDRs (Call Detail Records)
- LBS (Location Based Services) db records
Threat actors compromise telcos with the aim to obtain subscriber metadata to support IC objectives.
Some background: (1/5)🧵
CDRs are primarily used for postpaid billing and reporting purposes. They are generated in various network elements and consolidated in mediation systems.
It's these central databases that are often targeted. Data for a subscriber is generated in many systems:
(2/5)
Looking at the leak data: For example, this one is from old school circuit switched 2G voice calls.
What's of value from an intelligence perspective is is who talked to who and from where. Origin of data likely from MSC CDRs.
With the (fake) toothbrush botnet story still fresh, Colgate's connected Bluetooth toothbrush caught my eye on discount at the local supermarket.
"Hi there, let's get to know each other"
Sure, let's do this. What will we learn? (1/n) 👇
Happy to see that the Android app has responsibly requested the minimum permissions for BLE scanning. I kind of was expecting it to request my location for this which it didn't. (2/n)
Pulling the .apk off the device, the AndroidManifest.xml indicates a few permissions that warrant further investigation. Let's assume (for now) location perms (when granted) are only for BLE scanning on older Android releases.
A friend asked me to find out why his connected lightbulb app was asking for his location, so I ducked out to Australia’s favourite hardware store, Bunnings, and grabbed one to check out.
The Android grid connect app has 500k+ downloads.
Let’s take a quick look! 🧵
(1/n)
The app has a feature where it can auto discover your BLE devices. Is locations permission needed here? It depends. From Android API SDK v31 things have improved where fine location is not needed for BLE scanning.
The app is forcing this even though we are on v31.
(2/n)
Let's allow it "for science". The device is paired. We also have the option to enter our Wifi credentials. I assume this is so the light can be remotely controlled over the Internet. It's automatable too. One condition is "when location changes". Let's not touch these.