Sandfly 5.1.1 is released and includes an important bug fix which will improve database efficiency. It also includes new yescrypt support for our agentless password auditing, plus new detection modules for debugger attacks, thread masquerading, host system information, and more.

The database bug fix offers significant performance improvement and we recommend you read that section carefully before upgrade.

We recommend you do "Delete All" results in the UI before you do the upgrade. If you do not need the results this will ensure an instant upgrade happens. Deleting all results is shown in our documentation:

Deleting Results

We sponsored the open source porting of the Yescrypt password algorithm to Go and made this available in our agentless password auditor.

Sandfly is unique as we work as a Linux EDR, but also can do things on remote systems to be proactive about security. One of our proactive features is our ability to audit users directly on endpoints and find weak and custom passwords agentlessly that will lead to immediate compromise.

Newer Linux distributions have moved to using the Yescrypt algorithm by default. Yescrypt is a modern hashing algorithm with protections in place to make dedicated hardware brute forcing much harder. We worked with the designers of Yescrypt over at Openwall to implement the algorithm for use in Sandfly. We also sponsored this work as an open source project so others can make use of the algorithm in their own Go code.

Sandfly can now audit passwords on modern systems running Yescrypt to legacy distributions using older SHA512, MD5 and other algorithms. This includes extremely difficult to monitor embedded systems what very often have default passwords creating a significant security risk to organizations.

We have added in many new detection capabilities detailed below.

OS Identify Signatures and Custom Detection

Sandfly always runs our os_identify module when we connect to a host. This modules pulls over all basic operating system information such as hardware, distribution versions, CPU details, memory, disk mounts, network interfaces, performance data, plus much more. It functions as an asset inventory. Now, customers can build sandfly modules against any of these parameters such as kernel versions, CPU bugs, hardware types, and more to generate alerts.

We have included the following modules to provide an example of the capability to customers:

policy_cpu_bugs_meltdown - A sample template to show you how to search for specific CPU bugs you want to know about. This demonstrates searching for the Meltdown CPU bug, but can be altered to search for any or all bugs. This is not enabled by default, but can be used to build custom sandfly modules for your needs.

policy_kernel_version_notable - Another template to allow you to search for specific kernel versions of interest operating in your environment.

policy_kernel_version_release_2_or_older - A policy module that will show you any system running old 2.x Linux kernels. Disabled by default.

policy_kernel_version_release_3 - Another policy module that will show you any Linux kernels that are version 3. Disabled by default.

These modules demonstrate this new capability which can be cloned and used by teams to search for any attribute we collect in the os_identify data. We collect extensive data and are here to assist customers if they need any help in customizing them for their needs.

Threat Detection

We have improved and added in new detections for the following:

process_masquerade_kernel_thread_flag_mismatch - A process is running that is trying to impersonate a kernel thread. This builds on our existing threat detection modules for this attack by leveraging new Linux kernel flags present in 6.x kernels.

process_running_debugger_anti_debugging - Spots a process that has attached a debugger function to itself to prevent other debuggers from being used against it. This is often done for anti-debugging in malware to prevent runtime analysis.

process_running_debugger_attached - A process is running with an active debugger attached. This could indicate someone is trying to steal confidential data such as passwords, cryptographic keys, or confidential data from a process.

process_running_debugger_attached_state - Like previous, another way to detect a process is running with a debugger attached.

process_shell_running_ssh_command_invocation - A shell was invoked directly from ssh instead of using the normal user login shell. This is a suspicious way to invoke a shell and often is done to prevent command history and other auditing. This check is disabled by default due to false alarm risk on older CentOS systems. For modern systems it can be enabled and provides reliable detection of this problem.

recon_process_list_root_gid - Get a recon listing of all processes running with the root group ID (GID). Useful for drift detection profiling if you want to spot new root owned processes running.

recon_process_list_root_uid - Like above, but recon list for the root user ID (UID) running a process. Again, useful for drift detection of new root owned processes running on a host.

process_match_groupname_status - A template to allow you to find any process running with a specific group name. For instance, finding all processes running under a web server group. This template provides examples of how to do this search for custom sandfly use.

When a banned is seen inside a SSH Security Zone, the zone will show a new Banned Key Violation tag even if the key is tagged as authorized in that zone.

Get a Free License Today

If you have not tried Sandfly, get your free license below:

Get Sandfly

Upgrading Sandfly

All customers are encouraged to upgrade to receive the important database bug fix, plus new password auditing and detection modules.

We are here to help with any questions. Please see our documentation on the new features and capabilities:

Sandfly Documentation

Customers wishing to upgrade can follow the instructions here:

Upgrading Sandfly

If you have any questions, please reach out to us.

Thank you for using Sandfly.