I looked at the sources for #BPFdoor and ran @SandflySecurity against the binary. We could find this since at least 1.x of our product. Here is a run down of what it is doing.
#BPFdoor uses eBPF to sniff traffic. It can bypass firewall rules to see packets. When it starts it writes to /var/run/haldrund.pid which is obfuscated as hex in the code. It also masquerades its name using a number of pre-defined command line values below:
After #bpfdoor goes resident it deletes itself from disk. The working directory is /dev/shm (Linux ramdisk). A system reboot ensures the area is wiped. You can see also where it masks the cmdline and command portions in /proc. A ps command shows the bogus name.
#BPFdoor intiates anti-forensics by removing the binary afterwards and this shows up as a deleted binary associated with a running process which is always bad news.
The /proc/<PID>/stack area of the #BPFdoor process shows some suspiciously named functions as the sniffer loop is waiting for commands.
Also, a look under /proc/<PID>/fd shows a file descriptor that is actively grabbing packet traffic. We generated an alert on on this and you can see the packet file descriptor in the raw forensic data. stdin,stdout,stderr are redirected.
The process environment is wiped out so there are no traces to review. This is unusual for most processes on Linux and is worth investigating in and of itself.
A closer look at the /proc/<PID>/cmdline and /proc/<PID>/comm forensic traces in the suspicious process below. Again, there are a number of seemingly benign name it will pick at random on startup.
Looking at the code, it has backdoor capability with encryption (RC4). It also mods iptables rules to allow access when needed. The shell also has some anti-forensics measures in place.
The code is looking for a magic packet with a user-defined password on TCP, UDP or ICMP. Once seen then various things can happen such as shell, etc.
I'll have a longer write-up this week after seeing this backdoor. The use of eBPF is not common and the backdoor is minimalist to avoid detection but get the job done. But, it can be found pretty easily if you know how to look. Thank you @GossiTheDog for the thread.
Check out our blog for many more Linux forensics articles. I'll post there about #BPFDoor when I look at it closer:
Realized I made a 1AM typo when doing this. It's BPF, not eBPF. The BPF is a packet filter to efficiently filter for magic packets to operate the backdoor when sniffing inbound traffic.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I have been in the IDS/EDR industry for almost 30 years and I will say that this problem is not unique to Mitre, but every bake-off or eval you will read about online. Let me explain how evals work in this thread...
Vendors get invited into a bake-off or evaluation by someone. They all immediately spin up the marketing teams to do the "best". By "best" we mean trying to game things to make sure they score the highest. This is not a surprise.
The way this can be done is through several means. First, find out what you will be tested on and make sure your detections focus heavily on those areas with hair triggers. Triggers that nobody would ever deploy on a live network due to false positive risk.
@Phrack had a great article on leaked North Korean APT operations, including a Linux stealth rootkit with backdoor. I took a look at this backdoor and and wanted to share detection tips. Full article at the end of this thread.
First, this rootkit is based on the khook library. This is a common rootkit base that allows full stealth for processes, network connections, files, etc. This is what @SandflySecurity sees when the rootkit is active. It's only stealthy if you aren't looking!
Like many LKM rootkits, it will be extremely fragile and needs to be built for the victim kernel version. When installed the first thing it does is drop persistence files and insert the module to hide them and itself. Here are some files in /etc and /lib it hides.
Since I apparently have so many safe fans, let's talk about my favorite safe type: Mosler Round Doors. They are absolute tanks with interesting features.
Mosler made excellent vaults and safes of superior security and design. The round doors are my favorite as they are the absolute strongest design. The door rotates and locks into lugs when you turn the T handle. The bolts just keep the door from spinning unlocked.
Here we see the open door. The strength comes from the lugs. The door lugs you see here close into the frame. When you spin the handle the entire door rotates and the door lug slips in behind the frame lugs.
I recommend placing a 24/7 monitored smoke alarm above your safe. Cutting tools make a lot of smoke and this would set off the alarm and get help dispatched while scaring off attackers. Here is a thread of burglarized safe photos I've seen or were taken by others with advice.
ISM Jeweler's safe on display floor of safe company. Attacked with oxyfuel torch. This is Hollywood tier non-sense and would never work on this type of safe.
Photo someone took of an attempted peeling attack. Safe peeling is old school method of prying at a corner to separate layers and peel the safe open. Mainly a risk to fire safes and junk gun safes which are NOT burglary safes.
The SCTP protocol on Linux provides a reliable and stealthy way to access Linux. In this thread I'm going to demonstrate a simple SCTP backdoor and how it can be missed by security teams. Then I'll show you how to look for this kind of activity.
SCTP is a protocol mainly used for telcos. It provides reliable transport like TCP, but is not TCP. Be aware that network monitoring may not be paying close attention to SCTP and packet filters can be mis-configured to not block it.
The main thing to know is that SCTP is enabled on heaps of Linux systems but it's rarely used. So if you see it being used, and you are not a telco, you need to be paying attention.
The /proc/net/packet file on Linux shows you all open raw sockets that are grabbing network traffic. I'm going to show you what is in this file and provide a script that lists all processes sniffing traffic to help find malicious sniffers.
The /proc/net directory contains files that shows protocol use on Linux. The /proc/net/packet file shows you all open raw/packet sockets which means the process is sniffing traffic. The file shows you open inodes and who owns them, but doesn't list the process doing the deed.
This file is stiched together with tools like lsof to show process data, but it can be useful to do it yourself or with a simple script to make sure you are getting the data directly and avoiding processes that may manipulate lsof, netstat, or ss output to hide.