Why signature scanning alone underperforms on servers
A signature scanner asks whether a file matches something already catalogued as malicious. That is genuinely useful for known commodity malware and it is worth running. It is also inherently retrospective: a webshell edited slightly, or generated for one campaign, has no signature yet.
The deeper problem is that on a compromised server much of what matters is not a file at all. A cron entry, an added SSH key, a modified sshd configuration, a setuid binary and an outbound connection to a mining pool carry no signature. Scanning files for known-bad content cannot see any of them.
Behavioural detection asks different questions: what changed, what is running, what is this server talking to, and does any of it fit. That is the model SecAI is built on.
Webshells: the most common foothold on a web server
A webshell is a small script placed in a web-served directory that gives command execution through a normal HTTP request. It is the usual next step after an application vulnerability or a compromised CMS account, because it survives password changes and needs no open port.
They are difficult to detect naively. A webshell is PHP, and so is everything legitimately around it. A scanner keyed on suspicious functions flags large amounts of ordinary plugin and framework code, and an alert stream that is mostly false positives gets ignored, which is the real failure mode.
SecAI screens candidates with an AI pass that is aware of common application patterns, including WordPress, so what surfaces is the small set worth looking at rather than every file that calls eval. Confirmed findings are reported with the path and the reason. Automated webshell scanning is included on the Pro plan and above.
Cryptominers, and why they hide in plain sight
Mining is the most common outcome of an opportunistic server compromise, because it converts stolen compute directly into money without needing to exfiltrate anything.
The naive signal is CPU load, and the careful ones defeat it: they throttle to a fraction of available CPU, run under a plausible process name, and start only outside business hours. Watching a CPU graph is not a reliable detection method.
The durable signals are behavioural: a process whose executable has been deleted from disk while it continues running, an unfamiliar binary in a temporary directory, a persistent outbound connection to a mining pool, and a persistence mechanism that restores it. SecAI watches process and network behaviour against the server baseline rather than a single threshold.
Persistence: the part that makes cleanup fail
Removing a malicious file is not remediation if the mechanism that installed it is still present. This is why a server gets cleaned and is compromised again days later, and why reinfection is a signal about the server rather than about the site.
- Cron entries, including per-user crontabs and drop-ins under /etc/cron.d.
- systemd units and timers added to start something at boot.
- New or modified authorized_keys, giving access that survives a password change.
- New accounts, or an existing account added to a privileged group.
- Preload tricks such as modified ld.so.preload, and unexpected setuid binaries.
- Modified shell profile scripts that re-execute a payload on login.
What SecAI does not claim to do
It is not a signature-based antivirus product and does not maintain a malware signature database. If you specifically need catalogue-driven file scanning, run a scanner alongside it.
It reports and alerts on malicious files rather than automatically rewriting or cleaning application code. Automatic cleanup of PHP files is a hosting-oriented feature and a deliberate non-goal here, because silently editing an application is a good way to break a site.
It also cannot detect what leaves no trace on the host. Detection is grounded in files, processes, authentication and network behaviour on the server.