Sandfly 2.8.0 is released and features a major new upgrade allowing users to automatically respond to detected Linux attacks agentlessly. In addition to this we have made large performance upgrades to the backend server and added in new checks for policy threats that could compromise security of your hosts.
Agentless Active Response for Linux
Sandfly now has the ability to respond to detected process attacks on Linux agentlessly. Users can select to either kill or suspend a process that is detected by Sandfly as malicious. Let’s explain what this means.
Two Process Response Options: Kill or Suspend
With version 2.8.0 of Sandfly we are introducing two response options for process attacks: kill or suspend. You’ll notice that the suspend options is unique to Sandfly. Most of the time the first instinct of administrators when they see something malicious is to kill it immediately. However we actually recommend you don’t do this until you have had a chance to investigate the process. The problem with killing malicious processes on Linux is that you lose forensic data in memory and have no chance to recover the binary for further offline analysis.
Instead what you can do with Sandfly is suspend the process. This has advantages over simply killing a process:
- You preserve the process in memory for further analysis.
- You can recover the malicious binary, even if deleted from the disk.
- It gives you time to isolate the host and know the malicious activity has been halted while you work data preservation and backups.
- You can more easily see the open files, network connections and other artifacts the malware is using to run.
- If the malware is automated it may try to reload itself if it sees it has been killed. Suspended processes look to most automated malware that all is OK and it won’t try to re-infect while you implement containment procedures. This buys you time in the event you are dealing with a rapidly spreading and aggressive piece of malware.
Under the Sandfly listing you can see the new response options available on the process tab. The default is to do nothing and you can select either suspend or kill as you want.
When a response is activated we will tell you what happened in the alert explanation. Additionally there are boolean values under a new response section in the forensic JSON. These flags can be easily searched and analyzed inside your external database or SIEM tools you use to process Sandfly events. You can also pass them to a SOAR tool to take other actions based on what we did (e.g. Automatically isolate the host until incident response teams can investigate it.).
In the example below we found a process calling itself swapoff which was actually being used as a network enabled backdoor. We suspended this process and show the usual forensic details along with what we did in the explanation text.
Custom Sandfly Response for Incidents
In addition to using responses for built-in security checks, you can use them for custom checks you’ve created. This can be used for a variety of tasks in helping to contain an incident. Below we created a check for a suspicious process cryptographic hash and told Sandfly to check all systems and suspend the process if found. This enables incident responders to quickly go onto all systems and do a rapid system check without loading agents.
Kill If You Want
Of course you can also kill a process if you want. This would be a useful option if you know for certain what is going on and want to try to remediate a bunch of systems with a known problem instantly. Sandfly can quickly go onto your hosts and kill the process with the parameters you supply. You can have Sandfly hunt for process names, environment variables it’s using, username of who started it, network connections it has open, etc. Any parameter can be used. When we get a match on these parameters we will kill the process (or suspend) as you’ve instructed.
More Response Options Coming
Expect many more new and interesting response options for Sandfly in the coming updates. We have a lot of plans for this new capability to take automated Linux incident response to the next level.
New Sandfly Category: Policy Checks
We have added a new type of check category called “policy.” Policy checks are not necessarily compromise checks, but are often serious mis-configurations that could result in compromise. Or, they could be leftover from Linux malware that altered a system to ensure it is persistent or can return and bypass security controls.
We have moved checks that looked for dangerous permissions on important directories to this new policy area whereas before they were under incident response areas or normal system scans. This gives you the ability to better control how and when they are run. They are disabled by default but we recommend you investigate what they are to see if they could help you spot serious system problems. These checks will grow out in the future to cover many more areas where malware likes to operate on Linux.
You can also schedule policy checks to keep an eye on systems to make sure nothing changes that could be risky. For instance we check a variety of SSH configuration options that could enable dangerous tunnelling operations that could bypass firewalls and other network controls. These and other checks can be enabled to make sure your systems are not altered by users in dangerous ways.
Enhanced Host Operating System Details
We have enhanced the details we collect from remote systems. We now include many more details about the host operating system including easy to read distribution names, architecture names, etc.
Below we see the new columns showing distribution name, architecture, uptime and load. Also the new os_release fields in the detailed data showing information about the remote system. This information is collected automatically and will be added to existing hosts without users needing to make any changes.
Customers can now start scanning nodes and tell them to use the remote system RAMDisk (/dev/shm) for Sandfly operations and not a user’s home directory. This instructs the node to not write anything to the disk of the remote system and keep it all in RAM. This is useful for embedded device applications where users wish to limit write operations to SD memory cards. It’s also useful for deployments where you don’t want the potential for anything to be written to the disk. This option can be enabled in the start_node.sh start-up script by uncommenting the option.
IP Range Lists Scanning
You can now add in a list of IP ranges to scan and Sandfly will iterate and scan over all of them. Prior versions allowed you to only put in a single IP range at a time. Sandfly is able to scan very large IP ranges quickly and tell you what hosts it finds there. Many organizations don’t know all their Linux hosts that may be operating. Sandfly let’s you figure this out quickly.
More Sandfly Checks
Of course we’ve added in more security checks this release. Some of them include enhanced anti-forensics detection such as immutable history files, plus much more.
How to Upgrade Sandfly
Sandfly is easy to upgrade. Please follow the instructions here:
Over 850 Sandfly Checks and Growing
Sandfly 2.8.0 has now brought the number of compromise and incident response checks we do on Linux up to over 850. We can spot a tremendous amount of Linux malware, rootkits and intruder activity without loading any agents on your endpoints and without disruptive updates. Our agentless response capability gives you the ability to discover and remediate Linux incidents quickly and effectively.
Thank you for using our product.