How to Remove Malware From an Apache Web Server: A Complete Incident-Response Guide

Do not start by deleting the first suspicious PHP file. Treat a compromised Apache host as a security incident: remove it from service or tightly restrict its network access, preserve disk and volatile evidence, determine how far the attacker moved, and then rebuild from a known-clean operating-system and application baseline whenever possible. Restore only verified data, patch the entry point, rotate every credential the service could read, and use independent checks plus sustained monitoring before allowing traffic back.

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

What to do in the first hour

Your first decisions affect both recovery confidence and the evidence needed to understand the intrusion. A web shell can execute commands, exfiltrate data and alter or delete logs, so assume that the visible symptom is not the whole compromise.

#	Preview	Product	Price
1		Cybersecurity Incident Response Playbooks: Practical AI threat detection, digital forensics and...	$39.95	Buy on Amazon
2		Applied Incident Response	$26.07	Buy on Amazon
3		Cybersecurity Incident Response Drill Scenarios	$38.85	Buy on Amazon
4		Digital Forensics and Incident Response: Incident response tools and techniques for effective cyber...	$54.99	Buy on Amazon
5		Intelligence-Driven Incident Response: Outwitting the Adversary	$44.94	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

1. Contain the host. Remove the server from the load balancer and deployment pool, or place it behind firewall or WAF rules that allow only the minimum administrative access. If taking it offline would create unacceptable risk, block public traffic and preserve a controlled management path from a clean administrator workstation.
2. Preserve evidence before cleaning. Capture a forensic disk or system image and, where your response capability permits, volatile information such as memory, running processes, open files, network connections and loaded modules. Copy Apache access and error logs, suspicious files, configuration files and malware samples to write-protected or otherwise controlled storage.
3. Record the state. Note the hostname, IP addresses, virtual hosts, operating-system release, Apache version and build, loaded modules, application versions, administrator accounts, first alert time and every containment action. Record who collected each item and when.
4. Protect the investigation. Work from a clean response system. Do not execute an unknown script merely to see what it does, and do not parse the only copy of a log. Hash collected files and preserve their original timestamps and permissions.

CISA’s ransomware guidance specifically recommends capturing system images and memory, collecting relevant logs and malware samples, and preserving volatile evidence. Those actions are useful for a suspected Apache compromise even when ransomware is not involved.

Establish scope and a reliable timeline

A clean-looking homepage proves almost nothing. Attackers can hide a shell in an upload directory, use a valid account, alter a virtual host or leave a scheduled task that reinstalls deleted files.

#1 Best Overall

Cybersecurity Incident Response Playbooks: Practical AI threat detection, digital forensics and cloud security for incident response programs (English Edition)

$39.95

Buy on Amazon

Build an asset and identity inventory

• List every virtual host, document root, CGI or script directory, upload and cache directory, reverse proxy, application server and database connection associated with the Apache process.
• Record operating-system, Apache, language-runtime, framework, CMS, plugin and module versions. Include packages installed outside the normal distribution repository.
• Identify local administrators, deployment accounts, SSH keys, service accounts, CI/CD identities, cloud roles, database users and API tokens that the host could access.
• Map neighboring servers, shared storage, containers and management systems reachable from the compromised machine. A shared credential or writable network mount can turn one incident into several.

Correlate independent clocks

Set a time window beginning before the first alert and extending through containment. Compare Apache access and error logs with authentication, firewall, DNS, cloud-provider, database, endpoint, deployment and source-control logs. Align timestamps and account for time-zone or clock drift. Hash collected files and record creation, modification and change times, but treat filesystem timestamps as clues rather than proof: an attacker can alter them.

Look for the first unusual request, the first file write, privilege changes, new accounts or keys, outbound connections and the last known legitimate deployment. Preserve original logs before filtering or importing them into a search tool. Client-controlled fields can contain hostile control characters, so use a parser that safely renders untrusted values.

Use Apache logs to understand what happened

Apache’s own security guidance states: “Log files only report what has already happened, but they help you understand what attacks are being attempted and whether your security configuration is effective.” Logs are therefore evidence, not a guarantee that an event was recorded or that an absence of entries means the host is clean.

Access-log indicators

• Requests for uncommon methods, encoded parameters, command-looking strings, or unusually long query strings and headers.
• Repeated successful responses (especially many 200 responses) to obscure paths, image or cache directories, and files that should not be executable.
• File-upload requests followed by a request to execute the uploaded object, or a sudden sequence of requests from one source across many virtual hosts.
• Requests containing path traversal, server-side include syntax, template expressions, or attempts to reach environment files, version-control directories and administrative endpoints.
• Outbound callbacks or downloads that correspond in time to an inbound request. CISA and the FBI specifically recommend reviewing outbound requests and scanning for unrecognized PHP files.

Error-log and process correlation

Use the error log first when Apache startup or request processing fails. Correlate warnings about permissions, module loading, CGI execution, proxying and unusual child-process behavior with process and audit telemetry. Record the process ID, user identity, parent process and command line for any Apache child that launches an interpreter, shell, network utility or unexpected binary. NSA and ASD guidance supports checking which applications an Apache process starts and using audit telemetry to make that relationship visible.

Do not trust a log that has been truncated, rotated unusually early or stopped recording. Compare file sizes and rotation settings with backups and central logging. If an attacker had administrative access, assume local logs may have been edited and give greater weight to an independent collector, firewall record or provider audit trail.

Rank #2

Sale

Applied Incident Response

$26.07

Buy on Amazon

Find web shells, modified code and persistence

Search broadly and compare what is deployed with a known-good release. A web shell may be tiny, obfuscated, named like an image or hidden under a directory that is writable by the web process.

Document roots and application code

• Generate a complete file inventory for every document root and deployed release, including hidden files. Compare it with a clean build artifact or source-control checkout rather than relying only on modification dates.
• Prioritize recently created or modified PHP, CGI, Perl, Python, shell and binary files, especially short scripts, files with heavy string encoding, dynamic evaluation, command execution, or network-download behavior.
• Inspect files whose extensions look harmless but contain executable content, and check whether the web server is configured to execute scripts in upload, cache or temporary directories.
• Search for unfamiliar PHP files throughout the host, not just beneath the public web root. CISA guidance calls out unrecognized PHP as a useful hunting target.

# Example triage inventory; review output rather than deleting automatically
find /var/www /srv/www -xdev -type f -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %s %pn' 2>/dev/null | sort

# Candidate script and executable files in commonly writable locations
find /var/www /tmp /var/tmp -xdev -type f ( -name '*.php' -o -name '*.phtml' -o -name '*.cgi' -o -perm /111 ) -print 2>/dev/null

Paths differ by distribution and site layout; substitute the actual roots recorded in your inventory. Treat command output as leads for a responder, not as an automated eradication mechanism.

Configuration and Apache loading points

• Review every active virtual-host file, included configuration, rewrite rule, proxy rule, CGI mapping, directory directive and module list against a known-good baseline.
• Inspect .htaccess files in every served directory. Unexpected rewrites, redirects, authorization changes, file handlers or rules that fetch remote content can provide persistence or covert routing.
• Check for unknown virtual hosts, aliases, symlinks, writable configuration paths and newly enabled modules. Verify that the running binary and modules match trusted packages.
• Review access controls for dot-files, environment files, backups, source archives and version-control metadata.

Scheduled and startup persistence

• Enumerate system and per-user cron entries, systemd services and timers, init scripts, shell profiles, login scripts, deployment hooks and container startup definitions.
• Look for jobs that download a file, contact an unfamiliar host, recreate a deleted script, or run as the Apache user or a recently created account.
• Check SSH authorized keys, administrator accounts, sudo rules and credential-helper files for additions that do not belong.
• Inspect neighboring hosts and shared storage for the same files, keys, requests or outbound destinations.

Capture copies and hashes before disabling or removing persistence. If you must stop an active process to contain harm, document the command, time and resulting state.

Delete the files or rebuild the server?

Deleting a shell is an action, not an eradication proof. In-place cleaning can be appropriate for a narrowly scoped, well-understood event when policy requires continuity, but a rebuilt host provides substantially higher confidence that hidden persistence and altered system components are gone.

Consumer cleanup software may help triage an endpoint, but it does not establish that a multi-user Apache host has been rebuilt or that attacker access has been closed. For a server that handled credentials, customer data or privileged connections, involve qualified digital-forensics and incident-response personnel when your team lacks the capability to preserve and validate evidence.

Rank #3

Sale

Cybersecurity Incident Response Drill Scenarios

$38.85

Buy on Amazon

Eradicate and recover from a known-clean baseline

Preferred rebuild sequence

1. Keep the original isolated. Preserve the forensic image, volatile collection and logs. Do not use the compromised machine as the source for installation media, packages or application code.
2. Provision a new host from trusted operating-system media or a verified image. Apply current security updates before exposing any service. Confirm package signatures and repository configuration.
3. Install Apache and required modules from trusted packages. Do not copy the old binary, module directory or full configuration wholesale. Recreate only settings that have been reviewed.
4. Deploy application code from a known-good release. Rebuild dependencies from trusted lockfiles or repositories, scan the resulting artifact, and compare hashes with the release retained in source control or an approved build system.
5. Restore data selectively. Restore databases, media and user uploads only after checking backups for the compromise window and scanning them. Do not restore executable scripts, unknown archives, cached code or old configuration simply because they were present on the original host.
6. Apply least privilege. Use a dedicated service account, make code directories non-writable by Apache where practical, separate upload storage from executable paths, and restrict outbound network access to destinations the application genuinely needs.
7. Run validation before cutover. Complete the independent checks in the validation section, then expose the service gradually while monitoring.

If an in-place cleanup is unavoidable

Have a qualified responder document every identified file, account, key, scheduled task, module, rule and outbound destination. Replace affected packages and application dependencies from trusted sources rather than assuming they are intact. Remove all persistence mechanisms, reset permissions and compare the complete filesystem and configuration with a known-good baseline. A second person or independent tool must repeat the checks. If the scope cannot be bounded, stop and rebuild; availability pressure is not evidence that the host is safe.

Close the entry path before reconnecting Apache

Patch vulnerable software and reduce exposure

Confirm that Apache is not running the vulnerable 2.4.49 or 2.4.50 releases. Update Apache, the operating system, language runtimes, frameworks, CMS components, plugins, modules and deployment tools through trusted channels. Remove unused modules and applications, disable debug mode, restrict administrative interfaces, and deny URI access by default where the application permits it.

Protect sensitive dot-files with an explicit rule such as:

<FilesMatch "^.(?!well-known)">
    Require all denied
</FilesMatch>

Test the rule against legitimate ACME or other .well-known content and against requests for environment files, backups and repository metadata. Configuration syntax checks and a clean-client request test should happen before production traffic is restored.

Remove secrets from exposed locations

Do not leave passwords, API keys or cloud credentials in publicly reachable .env files, backups, debug output or source archives. Move secrets to an appropriate secret-management mechanism where feasible, and ensure the web server cannot serve the storage location.

Rank #4

Digital Forensics and Incident Response: Incident response tools and techniques for effective cyber threat response

$54.99

Buy on Amazon

Rotate every credential the service could read

Reset SSH keys, passwords, API tokens, database credentials, cloud access keys, deployment credentials and TLS private keys that the compromised service or an administrator on that host could access. Revoke old keys rather than merely adding replacements. Review provider audit logs for unauthorized use and inspect source-control, CI/CD and database logs for activity during the exposure window. If the same secret was reused on another host, rotate it there too.

Prove the host is ready for traffic

Use multiple independent checks; no single scanner can establish cleanliness.

• Malware and rootkit checks: Run tools appropriate to the operating system from trusted media or a trusted management plane. Treat a clean result as one signal, not a verdict.
• File-integrity comparison: Compare operating-system packages, Apache binaries and modules, application releases, permissions and hashes with the approved baseline.
• Configuration review: Recheck virtual hosts, includes, .htaccess, handlers, proxy rules, upload execution settings, dot-file denial, debug settings and outbound firewall policy.
• Account and persistence review: Confirm that administrators, SSH keys, sudo rules, cron entries, systemd units, timers, startup scripts and deployment hooks are expected.
• Vulnerability assessment: Scan the rebuilt system and application, then remediate findings before exposure.
• Application tests: Exercise authentication, uploads, authorization boundaries, error handling, redirects, APIs and administrative functions from a clean client.
• External request tests: Verify that sensitive files are denied, unexpected methods fail, TLS and host routing are correct, and no old shell path responds.
• Telemetry checks: Confirm that access and error logs are recording centrally, alerts fire for suspicious methods and file changes, and time synchronization is working.
• Network checks: Confirm that unknown processes, listening ports and outbound destinations are absent. Investigate every exception rather than suppressing it.

Restore traffic in stages: one instance or a small percentage first, followed by a heightened review of requests, process creation, file changes, authentication and outbound connections. Keep the former host isolated until the incident record and evidence-retention requirements are complete.

Common mistakes and how to correct them

“The browser looks normal, so the server is clean.”

Attackers can restrict a shell to a secret parameter, a particular user agent or a non-public virtual host. Replace visual inspection with log correlation, filesystem comparison, account review and independent scans.

“I deleted the file named shell.php.”

The attacker may have used another filename, an altered module, a scheduled downloader, an SSH key or a database-stored payload. Search all served and writable locations, persistence mechanisms, accounts and neighboring systems; rebuild when scope is uncertain.

Best Value

Sale

Intelligence-Driven Incident Response: Outwitting the Adversary

$44.94

Buy on Amazon

“I restored the entire backup.”

Backups made after compromise can contain the payload, and executable files hidden among uploads can reintroduce it. Establish the backup’s date and integrity, scan it, and restore only verified data into a freshly patched system.

“I rotated the web password.”

Apache may have been able to read database, cloud, deployment, SSH and TLS secrets. Inventory what the service and administrators could reach, revoke old credentials, and review provider audit trails for misuse.

“The scanner found nothing.”

Scanners miss novel shells, encrypted payloads, legitimate tools used maliciously and persistence outside the web root. Combine independent scans with baseline comparison, process and network review, log analysis and a clean-client test.

Operational checklist

• Host isolated or public access restricted before modifications.
• Disk image, volatile data, logs, suspicious files and hashes preserved.
• Hosts, virtual hosts, versions, modules, accounts and first-alert time recorded.
• Access, error, authentication, firewall, DNS, cloud, database and deployment logs correlated.
• Document roots, uploads, temporary paths, .htaccess, CGI locations, modules, cron, systemd, accounts and SSH keys examined.
• Apache and all exploited dependencies patched; unnecessary exposure removed.
• Application redeployed from a known-good release or in-place cleaning independently validated.
• Only verified data restored; executable content from uncertain backups excluded.
• SSH, database, API, cloud, deployment, password and TLS credentials rotated and old values revoked.
• Independent malware, integrity, configuration, vulnerability, application and network checks passed.
• Central logging, alerting and outbound-connection monitoring confirmed.
• Traffic restored gradually with heightened monitoring and a documented rollback plan.

Frequently Asked Questions

How can I tell whether a PHP file is a web shell?

A suspicious file often combines obfuscation or dynamic evaluation with command execution, file writes, uploads or outbound network calls, but appearance alone is not conclusive. Preserve and hash it, compare it with the approved release, correlate its timestamps and requests with Apache logs, and have a qualified responder analyze it without executing it on the production host.

Should I take Apache completely offline?

Remove the host from rotation whenever practical. If that would create unacceptable availability or safety consequences, block public traffic with restrictive firewall or WAF rules and allow only controlled administrative access while evidence is preserved.

How long should heightened monitoring continue after recovery?

The appropriate period depends on your risk, logging retention and incident findings. Keep heightened alerts and review in place for at least the full exposure window and long enough to cover delayed jobs, credential misuse and recurring deployment cycles; document the decision rather than treating the first quiet day as proof of safety.

Quick Recap

Bestseller No. 1

Cybersecurity Incident Response Playbooks: Practical AI threat detection, digital forensics and cloud security for incident response programs (English Edition)

$39.95

SaleBestseller No. 2

Applied Incident Response

$26.07

SaleBestseller No. 3

Cybersecurity Incident Response Drill Scenarios

$38.85

Bestseller No. 4

Digital Forensics and Incident Response: Incident response tools and techniques for effective cyber threat response

$54.99

SaleBestseller No. 5

Intelligence-Driven Incident Response: Outwitting the Adversary

$44.94

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.