Agentless Incident Response Sandflies and More Stealth Rootkit De-Cloaking: Sandfly 1.4.2 Released
Sandfly 1.4.2 Update
Sandfly 1.4.2 is now released. This version brings back the old “Recon” sandflies as “Incident” sandflies for use for Incident Response (IR) or those wanting to do spot checks on hosts for potential trouble
We also added a new sandfly that can completely de-cloak a running loadable kernel module rootkit that is actively trying to hide from view. We’ll now show you the exact name of the module that is hiding along with relevant directory information so you can investigate.
On top of this, we’ve added new methods to detect if someone is trying to maliciously halt a Sandfly investigation and report back the incident to the UI as an alert.
Feature list:
Incident Response Sandflies
More Stealth Rootkit De-Cloaking
Anti-Tamper Detection
Elasticsearch 6.4.0 Script Update
Incident Response Sandflies
When the initial Sandfly product was released we had a concept of “Recon” sandflies. We wanted an agentless way to look at a host that could be used for reconnaissance type operations and incident response. However, we weren’t clear about their usage and it caused some customers confusion and we pulled them out. Well, now they are back and they have a new name “Incident.”
When you now look under the Sandflies listing you’ll see the Incident tab that lists some of the new investigation modules. The modules do a variety of things with some caveats:
They may use more CPU and disk time than a regular sandfly.
They may have some false alarms.
These modules can only be selected from the manual scan and can’t be scheduled.
These sandflies are useful for teams that are willing to accept the above limitations to get a deep look into a host for trouble. The new checks are below.
Sandfly Process Listening Raw Socket
Lists out all processes that has any kind of raw network socket listening. This could be a perfectly legitimate network monitoring tool or process (e.g. systemd networking), or it could be malicious. If this sandfly flags a process you might want to take a look to make sure it is legitimate.
Sandfly Process Listening Raw Socket ICMP
Lists out all processes that has any kind of raw network ICMP or ICMPv6 socket listening. Again it could be a legitimate process like ping, fping, or other server uptime tools. But it also could be a backdoor type program depending on your system and what you have running.
Sandfly Process Listening Raw Socket TCP
Same as above but for the TCP or TCPv6 protocols.
Sandfly Process Listening Raw Socket UDP
Again, same as others but for UDP or UDPv6 protocols.
Sandfly Process Listening Raw Socket Unknown Protocol
Again like the above, but will flag any process that is not using a standard protocol like ICMP, UDP or TCP for raw socket operations.
Sandfly Dirs Hidden Suspicious Anywhere
This sandfly will scan the hard drive looking for what we consider extremely suspicious directory names anywhere on the file system. For example things like “/usr/local/etc/…” or the like. We check for this kind of activity with other sandflies, but this one crawls the entire filesystem and is extremely useful for dealing with an IR situation or just spot checks as it has a very low chance of false alarms.
Sandfly Dirs Link Count Wrong Anywhere
Many stealth rootkits will make hidden directories and instruct the kernel not to show them. This sandfly will crawl the entire filesystem looking for inconsistencies indicating a directory is being hidden on the file system.
Like the other link count sandfly checks, this one just goes further and checks the entire filesystem but may have slightly higher chances of false alarms on some system directories under certain circumstances. But overall the false alarm rate is very low and this is a very good check to run as a spot check as well.
Sandfly File Binary Encrypted Anywhere
This check will calculate entropy of executable files and is very good at digging out encrypted or packed executables. There is a chance of false alarms on some legitimate binaries, but overall this check can help find hidden malware that is encrypted on a hard drive.
Note that this check is CPU and disk intensive and can take many minutes to complete depending on how large your filesystem is when you run it.
Sandfly File Binary Masquerade Type Mismatch Anywhere
We will check the entire hard drive for any executable binary that is trying to look like something it’s isn’t. For instance an executable file with a .jpg or .gz extension. This is a common way for malware and hacker activity to hide on a host from detection.
This sandfly has a very low chance of false alarms, but may take a bit longer to complete due to searching the entire file system. Again, this is a good one to run from time to time on critical machines just to make sure everything looks OK.
Sandfly File Masquerade Type Mismatch Anywhere
This is similar to the executable binary check above, but we will look for common files masquerading as another type even if not executable. So for instance this could flag a PHP file that has a .jpg extension which is very common with certain types of web attacks. Also other kinds of mismatches will be spotted.
Sandfly File Shell Renamed Anywhere
This will flag any file that is actually a system shell that was renamed. This tactic can be used by attackers to hide a shell with perhaps SUID privileges in a directory for their personal use that won’t be easily found by administrators. This sandfly will check the entire file system for that kind of problem. Again this one is low false alarm potential, but just takes a bit of time to complete as it checks the entire disk.
Sandfly File SUID SGID Binary Anywhere
This sandfly will flag any file that is set SUID or SGID for any user. For instance an editor that is owned by the user bin and group bin but is SUID bin is very dangerous. It means anyone using that file could edit any user bin owned file on the system. Just because it’s not SUID root does not mean it’s not dangerous. This sandfly will show you all files with these permissions so you can view them to make sure they look legitimate.
This sandfly is going to be noisy. We will flag all legitimate SUID/SGID files and this will be several dozen files at least on a typical Linux installation. So while you may not want to run this check all the time, it’s a really good one to have around if you think a system has been compromised and you want a fast assessment for any SUID/SGID files introduced anywhere on the box.
Sandfly File SUID SGID Root Binary Anywhere
This is the same as the check above, but we just list SUID/SGID for the root user. Again useful for post-compromise assessment.
Sandfly File Binary Hidden Anywhere
This check will look for any executable file that has a hidden name. So a file like /usr/local/bin/.t would get our attention. It would be very unusual for a binary to be hidden like this on any normal Linux installation.
If you find any hidden executables on a box, take a good look at it to make sure it’s legit. This sandfly will have very low chance of false alarms, but again may take a bit of time to run as we check the entire file system for problems.
More Stealth Rootkit De-Cloaking
Sandfly Process Module Hidden
We have been focusing a lot on agentless Linux stealth rootkit detection lately. We now have another sandfly that can de-cloak loadable kernel module stealth rootkits and show you the exact name of the module that is hiding from you. When this sandfly sees any kind of loadable kernel module that is hiding itself from view, we’ll tell you exactly what it is with location information to investigate. Sandfly now has several methods to not only detect, but de-cloak stealth rootkits on Linux without needing to load any agents on your endpoints.
Tampering Alerts
Finally, we now have methods to detect if a sandfly check has been halted deliberately either by a user or malicious process. Any sandfly halted in this way will report back as an alarm in the UI for review.
Elasticsearch 6.4.0
The start-up scripts have been updated to pull the latest version of Elasticsearch 6.4.0. Please update your start-up scripts by following the upgrade procedure below. It’s a very easy process by simply issuing a git pull command from the sandfly-setup directory.
Important: Re-Sync Sandflies
With the addition of the new incident sandflies we need you to re-sync your database after the update to see them all. After you do the update, simply go to the Sandflies side bar and click on the “Reload All” option. That will sync the database to the new names. If you had any deactivated sandflies, you’ll need to reactivate them again after the reset.
Upgrading Is Easy
We recommend you upgrade to the latest version to take advantage of these new features.
Upgrading Sandfly is very easy with our included scripts. Please read the instructions here:
Thank you for using Sandfly.