Thread by @CraigHRowland

A recent supply chain attack against Arch leveraged a piece of malware with an eBPF rootkit to hide. It also had a very aggressive credentials harvester along with Tor C2. In this thread I'll cover some of the more interesting things it does.

It deploys an eBPF rootkit that hides the main process and Tor client. It also hides network activity. If you are running @SandflySecurity we de-cloak the processes plus other threats without any upgrades. The main process is random, but the Tor process is a bogus dbus-daemon.

The main process name is again random, and it also will pick a bogus name to masquerade as. I presume this is to allow it to hide just in case the eBPF rootkit cannot deploy. Here it is with a bogus "kworker" name to impersonate a kernel thread.

Looking at the process forensics you can see the padding used to stomp the actual name here. The secondary "dbus-daemon" is the Tor client and doesn't appear to change its name.

If the eBPF rootkit deploys, it will immediately hide itself and the Tor process. In the example here it started as PID 764. A ps listing doesn't show it running.

The process is hiding its entry in the /proc file system. When you do a listing you won't see our PID 764 listed. In the blog post at the end I show you some command line tricks you can use to de-cloak it by hand to confirm it is running though.

This variant parks the binary under /var/lib with the random name directory and matching binary name. You can see the full path in the /proc/PID/exe link when you go into it.

You can retrieve the process binary by hand like below, or you can cheat and use our upcoming Sandfly 5.8 release to grab it for you from the UI. To grab by hand:

cp /proc/PID/exe /tmp/recovered_bin

Here are the connections from the Tor client. The malware is trying to hide these connections, but you can see something is wrong because when you run "ss -tupna" it doesn't show the process owner info for the connection which it should. These clearly do not want to be seen.

The main process has very direct links to eBPF usage and if you dig around you can see this activity. Here I run this command and see some bad news. More again covered in the blog.

bpftool link show

More traces are under /sys/fs/bpf where it creates a directory and makes three very obviously named eBPF pinned references:

hidden_pids
hidden_inodes
hidden_names

One thing I haven't seen discussed yet is in addition to aggressive credential harvesting, it also drops a trojan sudo script to grab passwords from local users. We found this under /usr/bin/.local/sudo and /root/.local/bin/sudo The script in part is below.

The malware did a bunch of other things such as systemd persistence and very aggressive credential harvesting for tokens, SSH keys, passwords, etc. If you got this on your system, you must rotate every single secret that was on it then burn the box to the ground.

I recommend reading the blog post below which has more details and command line tricks you can use to help investigate a host. The commands would also work for other eBPF style rootkits investigations as well.

sandflysecurity.com/blog/linux-sca…