Malware Analysis BPFDoor

upnorth

Moderator
Thread author
Verified
Staff member
Malware Hunter
Well-known
Jul 27, 2015
4,984
Quote: " BPFDoor is interesting. It allows a threat actor to backdoor a system for remote code execution, without opening any new network ports or firewall rules. For example, if a webapp exists on port 443, it can listen and react on the existing port 443, and the implant can be reached over the webapp port (even with the webapp running). This is because it uses a BPF packet filter.

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. I swept the internet for BPFDoor throughout 2021, and discovered it is installed at organisations in across the globe— in particular the US, South Korea, Hong Kong, Turkey, India, Viet Nam and Myanmar, and is highly evasive. These organisations include government systems, postal and logistic systems, education systems and more. Inside those organisations I believe it is likely present on thousands of systems. The implant appears to be for surveillance purposes.

Per PwC: " We also identified that the threat actor sends commands to BPFDoor victims via Virtual Private Servers (VPSs) hosted at a well-known provider, and that these VPSs, in turn, are administered via compromised routers based in Taiwan, which the threat actor uses as VPN tunnels. Most Red Menshen activity that we observed took place between Monday to Friday (with none observed on the weekends), with most communication taking place between 01:00 and 10:00 UTC. This pattern suggests a consistent 8 to 9-hour activity window for the threat actor, with realistic probability of it aligning to local working hours. "

The implant has been in use for many years — over 5 — and has flown under the radar. "

" PwC plan to present their findings in June "

 

upnorth

Moderator
Thread author
Verified
Staff member
Malware Hunter
Well-known
Jul 27, 2015
4,984
At a high level, it does the following:
  • Goes memory resident and deploys anti-forensics and evasion to hide.
  • Loads a Berkeley Packet Filter (BPF) sniffer allowing it to efficiently watch traffic and work in front of any locally running firewalls to see packets (hence BPFDoor).
  • 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.
  • Operations are hidden with process masquerading to avoid detection.
While the malware takes steps to evade casual observation, it is easily seen if you know where and how to look. We'll review the above and provide detection tips.
The BPFDoor source is small, focused and well written. While the sample we reviewed was Linux specific, with some small changes it could easily be ported to other platforms (a Solaris binary reportedly exists). BPF is widely available across operating systems and the core shell functions would likely work across platforms with little modification.

Statically linked it would grow to about 1MB, but the dynamically linked version would likely work on most modern Linux distributions. Cross compiling for various CPUs is also possible so this implant would likely work on embedded Linux devices as well. The binary itself just needs to be downloaded onto the victim and run. It doesn't matter how or where it 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.
After the binary starts, it deletes itself making recovery harder. However, recovering a deleted process binary on Linux is trivial once it is running (see our article on how to do it). But the main thing deletion does is allow the binary to avoid detection by malware scanners that rely on file scanning. The binary is simply not on the disk to be scanned and if the main binary is hidden/encrypted on the device for persistence it would be very hard to find.
Once the implant has done its anti-forensics and evasion housekeeping, it goes into the packet capture loop. The packet capture function loads a BPF filter (hence the name). BPF is a highly efficient way to filter packets coming into a system which massively reduces CPU load by preventing all packets from needing to be analyzed by the receiver. It effectively operates as a very efficient pre-filter and only passes likely valid packets for review to the implant.

With BPFDoor they have taken a BPF filter and converted it to BPF bytecode. This keeps the implant small and less reliant on system libraries that may need to parse a human readable BPF filter, and allows for filters that the normal expression syntax cannot represent.

We have reverse engineered the bytecode below to show you what it is doing. It does basically two things:
  • Grabs either an ICMP (ping), UDP or TCP packet.
  • Sees if it has magic data value. If not then reject.
The relevance of the BPF filter and packet capture is that it is sniffing traffic at a lower level than the local firewall. This means that even if you run a firewall the implant will see, and act upon, any magic packet sent to the system. The firewall running on the local host will not block the implant from having this visibility. This is an important point to understand.

Further, if you have a network perimeter firewall, but it allows traffic to a host on ICMP, UDP or TCP to any port, then the implant can see it. Any inbound traffic to the sever can activate the magic packet check and initiate a backdoor. For instance, if you run a webserver and lock it down so only port TCP 443 can be accessed, the attacker can send a magic packet to TCP port 443 and activate a backdoor. Same for any UDP packet or even a simple ICMP ping.

Full source: