Sandfly 1.1.14 – Linux File Masquerading, Encrypted Malware Detection, and More

Product Update

Date
June 05, 2018
Author
The Sandfly Security Team

The latest Sandfly release has new features for file classification and file entropy scanning. We can now spot files that are trying to masquerade as something they aren’t, and spot files that may be packed or encrypted in a way that looks suspicious and is usually done by malware. We also have methods to spot executable files that are suspicious in other ways.

File Masquerading Checks

File Masquerade Example

File masquerading checks for files that are trying to be something they aren’t. So for instance an executable that is named with a .gz extension trying to look like an archive. Or .jpg that is really an executable, etc.

We search primary malware target directories for these files such as /dev, /lib, /tmp and other system locations. Masqueraded files in these areas are very suspicious and commonly done by exploits and malware. The standard sandflies are enabled by default and you should run them with your scheduled scans.

We also have an ability to search an entire volume for masquerading files (sandfly_file_masquerade_type_mismatch_anywhere). Note that this may have some small false alarms on some versions of Linux due to sometimes they put down rpm files that are really text, etc. Because of this we don’t recommend you run this as part of the scheduler. However, this is a really good check if you want to quickly assess a file system for malware hiding under other filenames. A quick manual review of any alarms will usually show you whether it’s of concern or not so this would be a great tool for incident responders assessing a compromised host.

The new sandflies of this type are below:

sandfly_file_masquerade_type_mismatch_anywhere — Looks for files masquerading as one type when they are really another type anywhere on the file system.
sandfly_file_masquerade_type_mismatch_in_dev_dir — Looks for files masquerading as one type when they are really another type in a dev directory.
sandfly_file_masquerade_type_mismatch_in_etc_dir — Looks for files masquerading as one type when they are really another type in the /etc directory.
sandfly_file_masquerade_type_mismatch_in_lib_dir — Looks for files masquerading as one type when they are really another type in a library directory.
sandfly_file_masquerade_type_mismatch_in_root_dir — Looks for files masquerading as one type when they are really another type in the top level / directory.
sandfly_file_masquerade_type_mismatch_in_system_dir — Looks for files masquerading as one type when they are really another type in in /boot, /sys or /lost+found directory.
sandfly_file_masquerade_type_mismatch_in_tmp_dir — Looks for files masquerading as one type when they are really another type in a temp directory.

File Entropy Checks

File entropy checks example

Next we have file entropy scanning. This is a method where we look at files for very high entropy. High entropy is an indicator that the file appears to be random. This can happen if an executable packer is being used, or if there is malware using a self-encrypting or polymorphic methods to hide itself from signature scanners.

Malware that is packed or encrypted is doing so to avoid detection and analysis. While packed binaries and high entropy can happen on Linux with executable packing tools like UPX, files with very high entropy in system areas like /tmp or /dev are typically associated with malware and rarely are legitimate.

Again, these standard sandflies are enabled by default and you should run them with your scheduled scans.

Just like the masquerade check, Sandfly can search the entire volume for encrypted binaries as an option outside the regularly scheduled checks (sandfly_file_binary_encrypted_anywhere). Again though there are some legitimate software packages that will cause this sandfly to activate, but on many Linux hosts this is uncommon. Additionally, this full volume scan can cause high CPU and disk loads so we recommend you don’t run it as part of a scheduled scan unless you do so infrequently to avoid system impacts.

The new sandflies of this type are below:

sandfly_file_binary_encrypted_anywhere — Looks if there is an encrypted or packed binary anywhere on the file system.
sandfly_file_binary_encrypted_in_dev_dir — Looks if there is an encrypted or packed binary in system dev directories.
sandfly_file_binary_encrypted_in_etc_dir — Looks if there is an encrypted or packed binary in system etc directories.
sandfly_file_binary_encrypted_in_run_dir — Looks if there is an encrypted or packed binary in system run directories.
sandfly_file_binary_encrypted_in_system_dir — Looks if there is an encrypted or packed binary in system /boot, /lost+found, and similar directories.
sandfly_file_binary_encrypted_in_tmp_dir — Looks if there is an encrypted or packed binary in system temp directories.
sandfly_file_binary_encrypted_in_var_spool_dir — Looks if there is an encrypted or packed binary in system /var/spool directories.

Executable Binary In Suspicious Areas Checks

Executable binary in suspicious areas checks example

We now have checks that look for executable files in unusual locations like /dev, /etc, and /tmp. On Linux systems most executables tend to be loaded in known system binary areas like /bin, /sbin, /usr/local/bin, /opt and others. Having an executable lying around in a temp or dev directory is unusual and again normally associated with malware or exploits. We also check the /var/spool directory to spot some common malware/exploit binaries that will hide in these areas for persistence with Linux cron.

These new sandflies are below:

sandfly_file_exec_in_dev_dir – Looks for executable files in system /dev directory.
sandfly_file_exec_in_etc_dir – Looks for executable files in system /etc directory.
sandfly_file_exec_in_tmp_dir – Looks for executable files in system temp directories.
sandfly_file_exec_in_var_spool_dir – Looks for executable files in system /var/spool directory.

Hidden Executable Binary Checks

Hidden executable binary checks example

Finally, we have sandflies that check for hidden executable files. There is rarely a legitimate reason to have a binary executable that is hidden (e.g. /bin/.hidden_exec). In almost all cases someone hiding an executable file is up to no good. Sandfly will search common system areas for executable files that are hidden and alert you to them.

And once again, the standard sandflies are enabled by default and you should run them with your scheduled scans.

We also again have a recon sandfly that will search your entire volume for hidden executables (sandfly_file_hidden_exec_anywhere). This rarely ever false alarms and can provide you with really good information about a hidden binary buried deep in a file system. We recommend you don’t schedule this sandfly to run frequently, or just use it for manual scans and incident response:

sandfly_file_hidden_exec_anywhere – Looks for executable files hidden anywhere on the filesystem.

sandfly_file_hidden_exec_in_bin_dir – Looks for executable files hidden in system binary directories.

sandfly_file_hidden_exec_in_dev_dir – Looks for executable files hidden in system /dev directory.

sandfly_file_hidden_exec_in_lib_dir – Looks for executable files hidden in system lib directories.

sandfly_file_hidden_exec_in_root_dir – Looks for executable files hidden in the top level directory.

sandfly_file_hidden_exec_in_tmp_dir – Looks for executable files hidden in system temp directories.

More Advanced File Forensics Capabilities Coming

These new file forensics capabilities are going to be used in some innovative ways to spot other signs of compromise and malware in the near future. We recommend you upgrade your Sandfly systems to support these new features.

Let Sandfly keep your Linux systems secure.

Learn More