Linux Malware Detect: multi-engine scanning for shared hosts

Why LMD targets shared-host web threats

Linux Malware Detect, or LMD, is designed primarily for Linux shared-hosting environments, especially sites running under separate user accounts. Its stated focus is the malware that traditional antivirus products often overlook, including PHP shells, JavaScript injectors, base64-encoded backdoors, IRC bots, and other web-application-layer threats. This scope differs from a general endpoint security suite. LMD is built around inspecting hosted content and reacting to suspicious files rather than managing a fleet of desktop endpoints.

The repository also describes a signature-generation context. Threat data is derived from network edge intrusion detection systems, LMD checkout submissions, and malware community resources. That provenance matters when evaluating coverage, because the signatures reflect the sources used by the project rather than a promise that every threat will be identified.

LMD runs on Linux distributions with bash and standard GNU utilities. The documented platform table includes RHEL, Rocky Linux, AlmaLinux, CentOS, Debian, and Ubuntu releases, with both systemd and SysV arrangements represented. The primary implementation language is Shell. This makes deployment familiar on traditional servers, but operators still need suitable scan performance and access to the files being examined.

Inside LMD's layered detection pipeline

LMD does not depend on a single matching method. Its detection layers begin with MD5 file hashes for exact threat identification. Version 2.0.1 adds SHA-256 hash scanning, with hardware detection exposed through the documented `scan_hashtype` setting. Hash checks are precise for known samples, but the mechanism has a boundary: a modified file will no longer have the same hash as its known sample.

HEX pattern matching uses a native batch grep engine with parallel workers. Compound signatures, identified as csig, add multi-pattern boolean logic, including AND, OR, and threshold conditions. They also support case-insensitive matching, UTF-16LE wide matching, and bounded gap wildcards. Native YARA scanning is enabled with `scan_yara=1`, while statistical analysis looks for suspicious string lengths associated with obfuscated content such as base64 and gzinflate.

ClamAV provides a separate detection layer, and the README describes automatic signature linking for dual-engine coverage. These mechanisms process complementary forms of evidence. A known hash is direct identity matching. HEX and csig rules search content or byte patterns. YARA evaluates structured rules. Statistical analysis searches for characteristics of encoded or compressed content. ClamAV applies its own signatures. LMD can therefore report different hit types for the same scanning run.

The release notes for version 2.0.1 say that batch parallel processing replaced per-file pattern compilation in the native scan path. They also state that MD5 and HEX matching now use Aho-Corasick workers, reducing subprocess creation during scans. The timing and hit totals in the release notes belong to the project's reported benchmark; they are not independent performance results.

Installing LMD and performing a first path scan

The README gives a checkout-based installation that installs LMD under `/usr/local/maldet`:

./install.sh

A successful installation should make the documented `maldet` command available in the intended environment. The repository also includes `uninstall.sh`, a systemd service unit, a SysV init script, cron files, and package manifests, but the README does not provide package-manager commands. Operators choosing a packaged deployment would need to consult the repository's installation documentation rather than infer a package name or flags.

After installation, scan a web-hosting path using the command supplied in the README's Quick Start:

maldet -a /home/?/public_html

The `/home/?/public_html` glob is intended to cover public web roots beneath home directories. The shell must be able to expand that pattern to actual paths. LMD should then produce scan output and a scan identifier that can be used for follow-up operations.

For files modified within a recent interval, the README documents:

maldet -r /home/?/public_html 2

Here, the trailing `2` tells LMD to consider files modified in the last two days, according to the Quick Start description. This narrower mode can reduce the amount of content considered when a full scan is not immediately needed. It does not change the underlying detection methods.

Real-time monitoring, quarantine, and alert paths

LMD can monitor files through Linux kernel inotify events for creation, modification, and movement. The documented startup command selects the `users` monitoring mode:

maldet -m users

This is useful when the goal is to react to web content as it changes rather than waiting for a scheduled scan. The event boundary is important. The README identifies create, modify, and move coverage, so LMD should not be described as monitoring every possible filesystem action.

Suspicious hits can be moved into a quarantine queue. The README says this queue uses zero-permission file storage, and it documents batch quarantine and restoration by scan ID. The Quick Start provides this command for quarantining all hits from a completed scan:

maldet -q SCANID

The actual scan identifier must replace `SCANID` in use. LMD can also apply signature-specific cleaner rules. The project states that full restoration preserves content, owner, permissions, and modification time. Administrators still need a controlled restoration procedure for a hosting service because a cleaner rule can alter hosted content based on the rules selected.

Alerting supports email and webhook-based channels for Slack, Telegram, and Discord. Email alerts can use HTML or text templates and can use an SMTP relay with TLS or SSL. Custom alert templates can be placed under `alert/custom.d/`. Version 2.0.1 added Discord webhook support and contains reported fixes for Slack and Telegram alerting. The README does not document alert-template filenames, required credentials, or test commands, so those details should be checked in the full configuration guide before relying on delivery.

YARA, signature updates, and resource controls

YARA is available as a native LMD scanning feature rather than a separate operational flow. It can be enabled at runtime with the documented option:

maldet -co scan_yara=1 -a /home/?/public_html

This command requests a scan with YARA enabled for that invocation. The README also documents custom YARA rules, but it does not show their file paths or include an example rule, so those details cannot be supplied from the repository excerpt.

Signature maintenance has a direct command in the Quick Start:

maldet -u

The project says that signature and version updates can be automated. It also documents `scan_workers`, whose default is `auto`, for controlling parallel work in the rewritten native scan pipeline. Scheduling is supported through the included daily cron files, including `cron.d.pub`, `cron.d.sigup`, `cron.daily`, and `cron.watchdog`.

For large unattended scans, LMD includes background scanning, scan lifecycle commands, and resource controls based on `nice`, `ionice`, and `cpulimit`. The version 2.0.1 notes add `--kill`, `--pause`, `--stop` or `--continue`, and `-L` for scan lifecycle management. The Quick Start does not explain the precise lifecycle semantics, so an administrator should consult the relevant usage and configuration entries before automating those commands.

The native engine's stated architecture uses batch grep and parallel workers. According to the project release notes, this was intended to avoid compiling patterns separately for every file and to remove large numbers of subprocess forks. That is a concrete upgrade consideration, but the reported timing table should not be treated as a guarantee for a particular host, filesystem, rule set, or scan path.

Operational limits and GPL-2.0 implications

The first limitation is coverage. LMD can detect files that match its hashes, patterns, YARA rules, statistical checks, or enabled external signatures, but the README does not claim that every unknown or heavily modified web shell will be found. A clean result means that the enabled checks found no matching evidence. It does not establish that a file is harmless.

The second limitation concerns dependencies and permissions. LMD is written primarily in Shell and relies on bash and standard GNU utilities. The project describes YARA and ClamAV integration, but the README does not provide installation commands or dependency checks for those engines. It also does not explain whether a particular ClamAV daemon or database configuration is mandatory for every LMD scan. A team considering LMD as its only malware-control layer must verify that distinction.

A third constraint is response scope. LMD can quarantine, clean, and restore files, and it can run cleaners according to signature-specific rules. Those capabilities do not make the tool a complete incident-response platform. The README does not document a formal rollback process, incident evidence export format, or cross-host coordination workflow.

The repository is licensed under GNU GPL version 2. The README identifies `COPYING.GPL` as the license file. That matters when LMD is modified, packaged, or distributed, because GPL obligations can affect how modified versions are conveyed. This is a license boundary to review with the relevant legal process, not legal advice.

Maintenance status and upgrade burden

The repository is not archived. Its last push was on 2026-05-24. Recent release history includes `v2.0.1` on 2026-04-29, `v2.0.1-rc4` on 2026-04-20, and `1.6.6.1` on 2025-02-26.

The release notes for version 2.0.1 describe a rewritten native scan engine, SHA-256 support, YARA changes, new or corrected alert integrations, wildcard handling, and more than 200 reported bug fixes. Upgrading therefore involves reviewing scan behavior, configuration, alert delivery, and external engine compatibility rather than simply replacing a shell script.

The repository includes `CHANGELOG`, `CHANGELOG.RELEASE`, and `CHANGELOG.VARIABLES`, which are the relevant files for checking release-specific changes. Signature updates are exposed through `maldet -u`, while packaged hosts also need to account for the platform's package configuration path, such as `/etc/sysconfig/maldet` or `/etc/default/maldet`, as listed in the README. LMD's GPL-2.0 license and Shell-based operations remain relevant at each upgrade.

Editorial conclusion

Linux Malware Detect is suited to administrators of shared Linux hosting who need web-oriented malware detection, scheduled scanning, and response operations in one interface. It is less suitable where ClamAV or YARA coverage is mandatory but external engines cannot be operated, or where GPL-2.0 distribution terms do not fit the deployment. Before adoption, verify the selected engines, alert transport, quarantine path, signature updates, and supported platform, then run `./install.sh` on a controlled system and inspect a first `maldet` scan.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. rfxn/linux-malware-detect on GitHub