Detecting Bincrypter Linux Malware Obfuscation

A new Linux script from THC will encrypt and obfuscate any executable or script to hide from on-disk detection. It then launches the code in a way to not leave traces on the disk as a fileless attack. It's a pretty slick utility, but we're going to show you how to detect it with command line tools in this article along with Sandfly. The source for this tool is here:

THC Bincrypter Linux Encryption and Obfuscation Tool

Here's the breakdown of features from the package:

First thing to understand is this tool only encrypts the binary at rest on disk. It is not encrypting the running process. Encrypting the binary on disk will evade legacy file scanning with YARA or traditional anti-virus very easily. This is why we never recommend these methods for finding Linux malware. The running process however has no encryption so that is our detection target.

The second thing to understand is the binary is executed by loading it into a memfd socket which means it can execute without being on the disk. This allows the original payload binary to be removed which will also evade file scanning detection. If you want to read more about using memfd to hide and detect malware, see our article below:

Detecting Linux memfd_create() Fileless Malware with Command Line Forensics

For demonstration, we encrypted a netcat binary using this tool. Below we see the directory of encrypted and unencrypted binaries. Notice the size, and also notice we gzipped the binaries. Encrypted binaries do not compress well. This is a cheap "Is this encrypted or not?" check. If the size after gzip is nearly identical to the original, the file is either a compressed executable (also suspicious), or encrypted.

Running our encrypted netcat as a listener we see it here in the process listing. Again, once running the encrypted protection is gone and we will focus our efforts there for our investigation. The original payload dropper can be removed from the system and no traces will be left. It is all memory resident at this point.

We'll go to the /proc/PID directory and do a quick investigation. A simple 'ls' directory listing gives us our first clue with the weird link of the exe to memfd:. Binaries should not be running out of a memfd: socket unless they are hiding.

Substitute the process ID for PID below to go to the directory you wish to investigate:

cd /proc/PID
ls -al 

Since the running binary is not encrypted, we'll grab it from memory so we can analyze it off the host at our leisure. It doesn't matter if the binary has been deleted from the disk as part of the payload delivery. Recovery is very easy even if in a memfd socket by just copying it to a new file from the /proc directory like below:

cp /proc/PID/exe /tmp/malicious.bin

We can also inspect the file descriptors of a suspicious process by going to /proc/PID/fd and listing the directory. With the fileless memfd attacks, the file descriptors will tell you what kind of file is being stored. A binary (ELF) file in a memfd: socket is bad news. The command to do this is:

cd /proc/PID/fd
file -L file_descriptor_number

If you want the easy button, Sandfly identifies this attack automatically as a Linux ELF type in memfd socket below, generates the alert, and gets all forensic artifacts for you.

We can see also if the suspicious process is network enabled even if hiding this kind of thing from system tools like netstat or ss by looking at the /proc/PID/stack file. The accept() call references are a dead giveaway it's likely a backdoor/server waiting for connections.

cat /proc/PID/stack

The lsof command shows a condensed snapshot that may also be useful of many other process attributes like open files, sockets, network ports, and more.

lsof -p PID

The encrypted file can also be found if you check for high entropy scripts/binaries hanging around. We have a free tool to help with this called sandfly-entropyscan below you can use to find these kinds of files:

Sandfly Entropy Scanner

If you use this tool, you can see high entropy files across your file system. The bincrypter tool makes them in a script type, but you can limit search to ELF for other kinds of packed/encrypted utilities that may also be used by other attackers.

The attack generates many alerts in Sandfly as a process running from a memfd socket is virtually always malicious. Here's some of what we find if this tool is being used.

Overall, bincrypter is a neat tool to protect a payload on disk from traditional file scanning detection, but exposed once running.

At Sandfly we believe that traditional anti-virus file scanning on Linux is largely a waste of time as it is easily bypassed with techniques like this and much more. Hunting for compromise tactics like Sandfly does works better and provides more opportunities to detect new attack methods. Please reach out to find out how how our agentless Linux security platform can find this and many more kinds of threats instantly.