Recently, BPFDoor – a malware was brought to light after years under the radar. It allows a threat actor to backdoor a system for remote code execution.
It does not require any open ports to penetrate the victims’ system. The firewall is a dead giveaway considering the malware starts to work internally.
The researchers also discovered that this BPFDoor is installed in organizations throughout the various places. These organisations include government systems, postal and logistic systems, education systems and more.
“Operators have access to a tool which allows communication to the implants, using a password, which allows features such as remotely executing commands. This works over internal and internet networks.
Because BPFDoor doesn’t open any inbound network ports, doesn’t use an outbound C2, and it renames its own process in Linux (so ps aux, for example, will show a friendly name) it is highly evasive.” Says the report given by Kevin Beaumont.
“Inside those organisations I believe it is likely present on thousands of systems. The implant appears to be for surveillance purposes.” Predicts Kevin.
TECHNICAL ANALYSIS OF “BPFDOOR” BY SANDFLY SECURITY TEAM
The BPFDoor source is small, focused and well written. It is written specifically for Linux Platform and if improved it could be ported to other platforms as well.
It doesn’t matter how or where the binary gets to the host as it takes care of moving itself to a suitable area once run to remain resident. However, the binary does need root permissions to run.
Initialization sequence of the Binary,
- Copy binary to the /dev/shm directory (Linux RAM disk).
- Rename and run itself as /dev/shm/kdmtmpflush
- Fork itself and run fork with “–init” flag which tells itself to execute secondary clean-up operations and go resident.
- The forked version timestomps the binary file /dev/shm/kdmtmpflush and initiates packet capture loop.
- The forked version creates a zero-byte dropper file at /var/run/haldrund.pid to mark it is resident and prevent multiple starts.
- The original execution process deletes the timestomped /dev/shm/kdmtmpflush and exits. Making the recovery harder.
- The forked version remains resident and monitors traffic for magic packet to initiate attacker operations such as a bindshell.
BPF- PACKET FILTER
A Berkeley Packet Filter (BPF) sniffer is loaded to efficiently watch traffic and work in front of any locally running firewalls to see the packets.
Upon receiving a special packet, it will modify the local firewall to allow the attacker IP address to access resources such as a spawned shell or connect-back bindshell. This is an important point to understand. As the implant uses /dev/shm – RAM disk on Linux and is void after every reboot.
For Persistence Reasons, the implant will need to be somewhere else on the host to survive reboots or be inserted again remotely. If the main binary is hidden/encrypted on the device for persistence it would be very hard to find.
Follow for latest news like this –
The interesting part of the implant is that, it sets a bogus time to timestomp the binary before deletion. The date is set to 1225394236 seconds from epoch which translates to: Thursday, October 30, 2008, 7:17:16 PM (GMT).
The interesting part is the timestomp happens by the forked process before the main process tries to delete the binary. This is assumed to be a failsafe mechanism.
After the binary deletes itself, recovering a deleted process binary is trivial. The deletion is mainly to avoid detection by malware scanners. The binary is simply not on the disk to be scanned.
In Linux, any process deleting its binary after running is extremely suspicious and has high chances of being malicious.
The binary swaps its name to look like common Linux system daemons. This masquerading tactic has been around for a while.
Lastly, the implant before going fully resident wipes out the entire process environment. After clearing itself out, the binary goes into packet capture loop function that loads the BPF. It operates as a very efficient pre-filter and only passes likely valid packets for review to the implant.
Even though the code does not reveal much about the authors, their intention to remain undetected is clear.
INDICATORS OF COMPROMISE
Using the hashes to find this malware is worthless. In Linux, Hashes are not that effective in finding malware as the binaries are easily re-compiled and changed.