DirectAdmin Malware Removal: A Practical Guide
Unlike cPanel, DirectAdmin ships with no built-in malware scanning, so an infected account often stays hidden until an external warning arrives. Here is what to do once one has.
DirectAdmin malware removal starts from a harder position than most control panels: there is no built-in scanner running in the background the way cPanel bundles with some hosting plans, so an infected account frequently goes unnoticed until a hosting provider suspension notice, a Google Safe Browsing warning, or an outbound spam complaint forces the issue. By the time you find out, the infection has usually had time to settle in properly.
Start from whatever evidence you already have
A blacklist notice, a host's abuse email, or a browser warning almost always names a specific domain, IP or even a URL path. Do not start a blind full-server scan when you already have a lead.
grep -r 'targetdomain.com' /var/log/httpd/domains/ 2>/dev/null | tail -100
grep -r 'targetdomain.com' /var/log/nginx/domains/ 2>/dev/null | tail -100
If a specific URL path was flagged (Google Safe Browsing reports usually include one), check that exact file first before widening the search.
Install ClamAV if it is not already running
Without it, you are relying entirely on manual inspection, which works but takes far longer. ClamAV is not part of a default DirectAdmin install and needs to be added through the plugin system or manually.
apt-get install clamav clamav-daemon
freshclam
systemctl enable --now clamav-daemon
clamscan -r --infected --log=/root/scan-USERNAME.log /home/USERNAME/domains/
Expect this to take a while on an account with a large public_html, and expect some noise, ClamAV's signature database includes plenty of generic heuristics that need manual verification rather than being treated as confirmed findings.
Find what a signature scan misses
A meaningful share of real infections use custom or lightly obfuscated code that will not match any known ClamAV signature. Pattern-based grepping catches a lot of what signature scanning does not.
grep -rlE 'eval\s*\(\s*(base64_decode|gzinflate|str_rot13)' --include='*.php' /home/USERNAME/domains/
grep -rl 'FilesMan\|c99shell\|r57shell\|WSO' --include='*.php' /home/USERNAME/domains/
Also check for files with recent modification times that fall outside any legitimate update window, this catches custom-written malware that has no known signature at all.
find /home/USERNAME/domains/ -type f -mtime -21 -printf '%T@ %p\n' | sort -n | tail -40
Remove it and find the actual entry point
-
1
Quarantine, do not immediately delete
Move confirmed malicious files to a location outside the web root rather than deleting them outright, in case you need to reference them to understand the full scope of the compromise.
-
2
Check what let the attacker in
Review the account's CMS and plugin versions against known vulnerabilities, check for weak or reused passwords, and look for an unrestricted file upload path.
-
3
Rotate every credential the account touches
The DirectAdmin account password, any CMS admin passwords, database passwords, and FTP or SSH keys if the account has them.
-
4
Reinstall from clean sources rather than patching in place where possible
For a badly compromised CMS install, downloading a fresh copy of the core, theme and plugins from official sources and migrating only the content and database across is often faster and more certain than hunting down every injected file individually.
Doing this manually, account by account, especially without a built-in scanner to lean on, is a real time cost on a DirectAdmin server hosting more than a handful of sites. BashSecure runs signature and pattern-based detection together across every hosted account, flags the entry point evidence alongside the infection, and does not require you to install and maintain ClamAV yourself.
Scanning every DirectAdmin account after a host warning
Scanned all 18 hosted accounts. One account has a confirmed backdoor and a cron job re-injecting it every 6 hours.
| Account | Finding | Cron job present |
|---|---|---|
| oldstore.example | PHP backdoor in uploads/ | yes, every 6h |
| 17 others | clean | no |
Removing the malicious file, deleting the associated cron entry, and rescanning oldstore.example to confirm nothing regenerates it.
crontab -l -u oldstore | grep -v 'suspicious-entry' | crontab -u oldstore -
Try this on one of your own servers.
Start free trialVerify the account is actually clean
Do not close this out on one clean scan result. Confirm nothing regenerates the infection over the following days.
clamscan -r --infected /home/USERNAME/domains/
find /home/USERNAME/domains/ -type f -mtime -1 -printf '%T@ %p\n'
If new suspicious files appear within a day or two of cleanup, either the entry point was not actually closed, or a second backdoor was missed the first time. Check cron again specifically, it is the most common way a cleanup gets quietly undone.
Prevent it happening again
- Install ClamAV and run scheduled scans across every hosted account by default, rather than reacting only after an external warning arrives.
- Restrict PHP execution in upload directories server-wide as a default policy, not account by account after an incident.
- Set an internal alerting threshold for outbound connection volume per account, since a compromised site sending spam or participating in a botnet usually shows up there before any external party notices.