Linux Software & Blog
Linux Malware Detect
Current Release:
http://www.rfxn.com/downloads/maldetect-current.tar.gz
http://www.rfxn.com/appdocs/README.maldetect
http://www.rfxn.com/appdocs/CHANGELOG.maldetect
Description
Linux Malware Detect (LMD) is a malware scanner for Linux released under the GNU GPLv2 license, that is designed around the threats faced in shared hosted environments. It uses threat data from network edge intrusion detection systems to extract malware that is actively being used in attacks and generates signatures for detection. In addition, threat data is also derived from user submissions with the LMD checkout feature and from malware community resources. The signatures that LMD uses are MD5 file hashes and HEX pattern matches, they are also easily exported to any number of detection tools such as ClamAV.
The driving force behind LMD is that there is currently limited availability of open source/restriction free tools for Linux systems that focus on malware detection and more important that get it right. Many of the AV products that perform malware detection on Linux have a very poor track record of detecting threats, especially those targeted at shared hosted environments.
The threat landscape in shared hosted environments is unique from that of the standard AV products detection suite in that they are detecting primarily OS level trojans, rootkits and traditional file-infecting viruses but missing the ever increasing variety of malware on the user account level which serves as an attack platform.
Using the CYMRU malware hash registry, which provides malware detection data for 30 major AV packages, we can demonstrate this short coming in current threat detection. The following is an analysis of the core MD5 hashes (2,597) in LMD 1.3.6 and the percentage of major AV products that currently detect the hashes.
KNOWN MALWARE: 569 % AV DETECT (AVG): 49 % AV DETECT (LOW): 58 % AV DETECT (HIGH): 71 UNKNOWN MALWARE: 2028
What this information means, is that of the of the 2,597 hashes, 78% or 2,028 malware items are not detected/known by the top 30 major AV packages. The 569 malware items that are known / detected have an average of a 49% detection rate among major AV packages with a low / high margin of detection at 58 and 71 percent respective. This clearly demonstrates the lacking capacity in currently available tools and why it is important that something fill the void, especially in the Linux shared hosted environment.
Features:
- MD5 file hash detection for quick threat identification
- HEX based pattern matching for identifying threat variants
- integrated signature update feature, executes through cron.daily and –update
- integrated version update feature with –update-ver, must run manual
- scan-recent option to scan only files that have been added/changed in X days
- scan-all option for full path based scanning
- checkout option to upload suspected malware to rfxn.com for review / hashing
- report option to view past or recent scan results
- quarantine queue that stores threats in a safe fashion with no permissions
- quarantine batching option to quarantine the results of a past or recent scan
- quarantine restore option to restore files to original path, owner and perms
- quarantine suspend account option to Cpanel suspend or shell revoke users
- cleaner rules to attempt removal of malware injected strings
- cleaner batching option to attempt cleaning of previous scan reports
- cleaner rules to remove base64 and gzinflate(base64 injected malware
- daily cron based scanning of all changes in last 24h in user homedirs
- daily cron script compatible with stock RH style systems, Cpanel & Ensim
- kernel based inotify real time file scanning of created/modified/moved files
- kernel inotify monitor that can take path data from STDIN or FILE
- kernel inotify monitor convenience feature to monitor system users
- kernel inotify monitor can be restricted to a configurable user html root
- kernel inotify monitor with dynamic sysctl limits for optimal performance
- kernel inotify alerting through daily and/or optional weekly reports
- e-mail alert reporting after every scan execution (manual & daily)
- path and signature based ignore options
- verbose logging & output of all actions
Source Data:
The defining difference with LMD is that it doesn’t just detect malware based on signatures/hashes that someone else generated but rather it is an encompassing project that actively tracks in the wild threats and generates signatures based on those real world threats that are currently circulating.
There are four main sources for malware data that is used to generate LMD signatures:
- Network Edge IPS: The network I manage hosts over 35,000 web sites and as such receives a large amount of daily abuse, all of which is logged by our network edge IPS. The IPS events are processed to extract malware url’s, decode POST payload and base64/gzip encoded abuse data and ultimately that malware is retrieved, reviewed, classified and then signatures generated as appropriate. The vast majority of LMD signatures have been derived from IPS extracted data.
- Community Data: Data is aggregated from multiple community malware websites such as clean-mx and malwaredomainlist then processed to retrieve new malware, review, classify and then generate signatures.
- ClamAV: The HEX & MD5 detection signatures from ClamAV are monitored for relevant updates that apply to the target user group of LMD and added to the project as appropriate. To date there has been roughly 400 signatures ported from ClamAV while the LMD project has contributed back to ClamAV by submitting over 1,100 signatures and continues to do so on an ongoing basis.
- User Submission: LMD has a checkout feature that allows users to submit suspected malware for review, this has grown into a very popular feature and generates on average about 30-50 submissions per week.
Signature Updates:
The LMD signature are updated typically once per day or more frequently depending on incoming threat data from the LMD checkout feature, IPS malware extraction and other sources. The updating of signatures in LMD installations is performed daily through the default cron.daily script with the –update option, which can be run manually at any time.
An RSS feed is available for tracking malware threat updates: http://www.rfxn.com/api/lmd
Detected Threats:
LMD 1.3.6 has a total of 4214 (2597 MD5 / 1617 HEX) signatures (before updates), below is a listing of the top 60 threats by prevalence detected by LMD:
base64.inject.unclassed perl.ircbot.xscan bin.dccserv.irsexxy perl.mailer.yellsoft bin.fakeproc.Xnuxer perl.shell.cbLorD bin.ircbot.nbot perl.shell.cgitelnet bin.ircbot.php3 php.cmdshell.c100 bin.ircbot.unclassed php.cmdshell.c99 bin.pktflood.ABC123 php.cmdshell.cih bin.pktflood.osf php.cmdshell.egyspider bin.trojan.linuxsmalli php.cmdshell.fx29 c.ircbot.tsunami php.cmdshell.ItsmYarD exp.linux.rstb php.cmdshell.Ketemu exp.linux.unclassed php.cmdshell.N3tshell exp.setuid0.unclassed php.cmdshell.r57 gzbase64.inject php.cmdshell.unclassed html.phishing.auc61 php.defash.buno html.phishing.hsbc php.exe.globals perl.connback.DataCha0s php.include.remote perl.connback.N2 php.ircbot.InsideTeam perl.cpanel.cpwrap php.ircbot.lolwut perl.ircbot.atrixteam php.ircbot.sniper perl.ircbot.bRuNo php.ircbot.vj_denie perl.ircbot.Clx php.mailer.10hack perl.ircbot.devil php.mailer.bombam perl.ircbot.fx29 php.mailer.PostMan perl.ircbot.magnum php.phishing.AliKay perl.ircbot.oldwolf php.phishing.mrbrain perl.ircbot.putr4XtReme php.phishing.ReZulT perl.ircbot.rafflesia php.pktflood.oey perl.ircbot.UberCracker php.shell.rc99 perl.ircbot.xdh php.shell.shellcomm
Real-Time Monitoring:
The inotify monitoring feature is designed to monitor paths/users in real-time for file creation/modify/move operations. This option requires a kernel that supports inotify_watch (CONFIG_INOTIFY) which is found in kernels 2.6.13+ and CentOS/RHEL 5 by default. If you are running CentOS 4 you should consider an inbox upgrade with:
http://www.rfxn.com/upgrade-centos-4-8-to-5-3/
There are three modes that the monitor can be executed with and they relate to what will be monitored, they are USERS|PATHS|FILES.
e.g: maldet --monitor users
e.g: maldet --monitor /root/monitor_paths
e.g: maldet --monitor /home/mike,/home/ashton
The options break down as follows:
USERS: The users option will take the homedirs of all system users that are above inotify_minuid and monitor them. If inotify_webdir is set then the users webdir, if it exists, will only be monitored.
PATHS: A comma spaced list of paths to monitor
FILE: A line spaced file list of paths to monitor
Once you start maldet in monitor mode, it will preprocess the paths based on the option specified followed by starting the inotify process. The starting of the inotify process can be a time consuming task as it needs to setup a monitor hook for every file under the monitored paths. Although the startup process can impact the load temporarily, once the process has started it maintains all of
its resources inside kernel memory and has a very small userspace footprint in memory or cpu usage.
See http://www.rfxn.com/appdocs/README.maldetect for more details on inotify monitoring.
Funding:
Funding for the continued development and research into this and other projects, is solely dependent on public contributions and donations. If this is your first time using this software we ask that you evaluate it and consider a small donation; for those who frequent and are continued users of this and other projects we also ask that you make an occasional small donation to help ensure the future of our public projects.

about 1 week ago
Ryan,
For the benefit of others that read our conversation below, I wanted to point out that what I called “false positives” really aren’t a big deal. When I first installed LMD, I scanned all my files, but now it only scans files changed in the last 2 days. Those programs that I trust, but behave badly in LMD’s eyes, aren’t changed, so they don’t keep bugging me.
Looks like you’ve got a good thing going here Ryan. Thanks!
about 1 week ago
Can you throw me the output of uname -a (you can censor the hostname).
about 1 week ago
Fantastic tool.
Can’t seem to start in iNotify mode though, I get “no inotify process found, check inotify.log” which, when I do, is empty.
clues? CentOS 5.5 w/WHM
MP
about 2 weeks ago
Add the desire maldet command into /etc/rc.local and it will start at boot time.
about 3 weeks ago
Hi:
If you could provide or where can find a sample let me can make a maldetect service script, let it can run when boot?
Thank you
about 3 weeks ago
I am sure this is true:
about 3 weeks ago
You can safely delete items from the quarantine and when running a restore, if the file is no longer present in the quarantine, it will be ignored.
I should also stress, that these are technically NOT false positives, in your case however they most definitely are and the differences are a matter of semantics. I do know those rules do cause some headaches for people but generally speaking, they are frowned upon coding habits and the rules provide more value than they do headaches.
The ignore_paths file will ignore an absolute path or a partial path. So for example if you enter /home/mike/public_html into ignore_paths, it will ignore everything under the public_html folder for that user, or you could put an absolute path to a specific file and it will just ignore that file only.
about 3 weeks ago
I feel bad, turning your comments into a support thread, but maybe it will help someone else too.
I should have mentioned that there were 3 real hits in with my 51 false positives. To me, that makes it worth it to deal with the FPs. Could I have deleted the quarantine files for the real hits, then restored the rest by running the -s with the scan id?
I don’t want to disable a signature because I might need that detection later.
A suggestion would be to have the ignore file update automatically (or with a commnad line switch) when a file is resotred. Does the ignore path follow all the way to a file name, or only to the directory?
The reason I had trouble with the config was that I edited the copy in the “files” directory instead of “/usr/local/maldetect/conf.maldet “
about 3 weeks ago
You can restore the files for an entire scan by using the SCANID value from the report, i.e:
maldet -s 081110-1135.28460
Make sure you have set quar_hits=0 in conf.maldet if you want to disable the quarantine option, there is no known issue at present with the toggle option. I will however do some digging to make sure there is no issue.
about 3 weeks ago
Thanks for the reply, and thanks for the software. I’ll see if I can get my boss to send you a donation.
I had several installs of the same gallery, so I had several files like check_imagemagick.php.1683 and check_imagemagick.php.4863 (I made up the numbers, but you get the idea.).
I tried restoring them with a command like maldet -s /usr/local/maldetect/quarantine/check_imagemagick? but it didn’t like the wildcard, I guess.
Instead, I wrote a bash script, and copied that line and cut and pasted each filename to restore. I ran the script and it restored them.
I had set my config file to quarantine automatically and to send me an email. I opened my conf.maldet file and it looked like the default, even though it had worked. I then edited it, leaving the setting on not quarntine automatically, to send the email, and I put my email address in again. I ran a -r 2(recent 2days) scan and it quarantined files instead of just notifying me. What did I do wrong?
about 3 weeks ago
You can ignore the specific paths that the false positive hits are occuring in by placing the paths in:
/usr/local/maldetect/ignore_paths
OR
You can ignore the specific rules by placing the signature name in:
/usr/local/maldetect/ignore_sigs
The signature name in the ignore_sigs file should be in the format of “php.exe.globals”, so omit the {HEX} or {MD5} and the .# portion of the signature name.
about 3 weeks ago
I have installed and executed your application. It has found a large number of false positives. I use an application from ComDev that is encrypted, so it gets tagged with gzbase64.inject.unclassed.14
I use Menalto’s Gallery and the setup tests some system configuration, so it gets tagged with php.exe.globals.203.
I have a few places where I use “http” in an include, so those get tagged with php.include.remote.214. I can probably clean up the include remotes myself, and become a better developer in the process, but how do I prevent the other false positives?
about 1 month ago
When trying to use monitor on a CentOS 5.5 64-bit server, I get the following error:
no inotify process found, check /usr/local/maldetect/inotify/inotify_log for errors
/usr/local/maldetect/inotify/inotify_log is empty.
Ideas?
Thank you.
about 3 months ago
Hey Peter,
If you take a look at the –help option you will see there is a –checkout feature, this can be used to upload malware that was not detected and I will review it.
For false positives, please send me the exact signature string as it appears in the report output and if possible the file that generated the FP to ryan at rfxn.com , if the file is of a sensitive nature then describe its contents.
You can ignore problematic signatures using the ignore options described in the README file under the heading “IGNORE OPTIONS”.
about 3 months ago
Thank you for this excellent work. Where and how would you like false positives as well as items not caught so the system you created can be improved?
Thank you!