What are the signs that a web server has been compromised for defacement or encryption?

Common signs include unexpected file extensions on encrypted content, new ransom notes, modified site pages, strange PHP files, and unexplained archive or key files on the desktop or web root. Administrators should also look for open directory listings, altered content across multiple hosted domains, and unusual POST-driven activity against PHP endpoints. Those indicators often point to webshell-driven abuse rather than normal site maintenance.

What the Compromise Pattern Usually Looks Like

Defacement and encryption rarely appear as isolated visual changes. A compromised web server usually shows a combination of altered content, unexpected files, and abnormal execution paths that point to attacker control rather than a single broken page. The strongest clue is when the web root starts behaving like a staging area, with files that do not fit the site’s normal publishing workflow.

That pattern matters because defacement is often the visible outcome of deeper access, while encryption usually means the attacker had enough reach to rename, overwrite, or lock content after initial intrusion. If you see both presentation-layer changes and strange backend artefacts, treat the server as a compromise investigation, not a cosmetic repair job.

File, Content, and Execution Clues to Check First

Start with what changed on disk and what the server is now trying to execute. Encrypted or renamed content with new extensions, ransom notes, strange PHP files, unexplained archives, and key material in the desktop or web root are all strong indicators of hostile activity. Open directory listings and modified pages across multiple hosted domains are especially important because they suggest the attacker reached beyond one file and may have reused the same access path elsewhere.

Also inspect for files or scripts that do not belong to the application stack, especially webshell patterns hidden in legitimate-looking locations. A server that suddenly serves altered pages while also exposing script-like artefacts is usually telling you that the attacker has moved from entry point to persistence. On a busy host, the compromise may be easiest to spot by comparing known-good file trees, checksums, and deployment timestamps against what is currently on disk.

Request Patterns and Administrator Judgment

Look beyond the files and review how the server has been used. Unusual POST-driven activity against PHP endpoints is a common sign that someone is sending commands or uploading payloads through the application layer, not merely browsing the site. If the content change aligns with suspicious request patterns, the likely issue is active abuse of application logic or a webshell, not a routine publishing error.

For that reason, incident triage should separate “what the site displays” from “how the server is being driven.” A page defacement can be manually visible, but the real compromise is often confirmed by repeated write activity, unexpected execution, and new artefacts appearing in the same time window. If multiple domains on the same host changed together, assume the attacker had broader file-system access and widen the scope immediately.

Risk and Threat Considerations

Web defacement and encryption are operationally serious because they usually imply write access, code execution, or both. The main risk is that the visible change is only the symptom, while the attacker may still retain a foothold through uploaded scripts, stolen credentials, or a reusable webshell.

Failure mechanism: The attacker abuses application access, writable directories, or weak server controls to modify content, stage files, and persist through PHP or similar execution paths.

Impact: You can lose site integrity, suffer downtime, expose adjacent hosted domains, and face further compromise if the attacker keeps execution capability after the defacement or encryption event.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1105 — Ingress Tool Transfer	Webshell staging and payload delivery often precede defacement or encryption.
	T1059.007 — Command and Scripting Interpreter: JavaScript	Unexpected server-side scripts and webshell behavior are central to this compromise pattern.
Recommendation — Hunt for transferred payloads and quarantine the source path before restoring the server. Inspect script execution paths and block unauthorized interpreter use on the host.
NIST SP 800-53 Rev 5	SI-4 — System Monitoring	Detection depends on identifying abnormal file changes, execution, and request behavior.
	CM-5 — Access Restrictions for Change	Defacement and encryption usually reflect excessive or uncontrolled write capability.
	AU-6 — Audit Record Review, Analysis, and Reporting	Log review is needed to trace the first abnormal writes and POST activity.
Recommendation — Monitor web-root changes and suspicious HTTP activity continuously. Restrict who can change web content and require controlled deployment paths. Correlate file modifications with access logs to identify the compromise path.
OWASP ASVS	V16 — Security Logging and Error Handling	Application logs help expose suspicious uploads, writes, and endpoint abuse.
Recommendation — Retain and review logs that reveal abnormal file changes and script execution.

Practitioner Guidance

What to prioritise: Preserve evidence before cleanup, then identify the first abnormal file write, request pattern, or upload path that can explain the change. If the server hosts multiple sites, treat the whole host as affected until you prove otherwise.

What to verify: Compare current web-root contents against deployment records, confirm whether the altered files were deployed through normal release channels, and check whether any unexpected PHP, archive, or key files were written outside the application pipeline. Where available, correlate file changes with access logs and admin activity.

Common mistake: Reverting the visible page without removing the attacker’s execution path. If you do not remove the mechanism that created the defacement or encryption, the compromise often returns.

Practitioner takeaway: The decisive question is not “was the page changed?” but “what access path let someone write, execute, and persist on the server?”