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
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.
People are asking me to post hashes about this Linux malware we came across. No. Using hashes for finding Linux malware doesn't work and are easily altered. Look for tactics instead. Here are some tactics to use in this thread.
Can you see the /etc/ld.so.preload file? Can you read it with /bin/cat or see it with the /bin/ls command? If you are being stopped from doing this then you have ld preload malware stopping you.
Can you read the root SSH authorized_keys file? This malware stops you from doing that. Is the file set to immutable as seen with the "lsattr" command? If you didn't set it immutable, then the malware probably did to hang around.
Modified /etc/ld.so.preload to point to a malicious library to intercept system calls. The file was /lib/libcurl.so.2.17.0 and was not known by VirusTotal. The /etc/ld.so.preload file contents was being hidden from system commands. It was marked immutable to make removal harder.
We unmasked the file contents here. You can see the path and creation dates.
You see a weird openssl command running on one of your Linux systems. Here's how to investigate whether it's a bindshell backdoor operating on the box and hiding traffic inside an encrypted tunnel. Thread. #DFIR
The server and client to run the attack. The reverse bindshell causes openssl to connect back to us and is encrypted so network monitoring is blind to what is going on. Need to look at the host to figure it out.
We log into the host after seeing the weird outbound connection and need to investigate. Run ps -aux and lsof -p <PID> to see the process. Throw in netstat for good measure. We see openssl and /bin/sh -i running that look strange.
@SandflySecurity was able to spot this malware very quickly and with multiple serious alerts. Let's have a walk-through about what it was up to and de-cloak it. #DFIR#sandflysecurity
Virus total shows very few results. But we saw many serious compromise tactics in use on this Linux system hit with the malware.
The top and ps commands show some odd things. Top is showing 100% of the CPU in use, but no process claiming responsibility. The ps listing shows nothing unusual. Something is hiding. Let's de-cloak it. #DFIR
Malware will name itself with [brackets] to impersonate a Linux kernel thread. Bracketed names mean no cmd line argument. Kernel threads almost always are in brackets.
Use ps with tree view to find our candidates for investigation:
Any #Linux process that looks like a [kernel thread] should have an empty maps file. If you look at the maps file for a process and it has data in it, it's not a kernel thread:
cat /proc/<PID>/maps
Our suspect below has entries under maps. Bad news.