Defacement
Defacement changes visible content to mislead, intimidate, or damage an organization's public or internal presentation.
What it means
Defacement changes visible content to mislead, intimidate, or damage an organization's public or internal presentation. It may signal compromise beyond the page itself.
An investigation example
An organization discovers unauthorized text on a public site following an unexpected publishing-account login.
Evidence to examine
Review content versions, publishing identities, deployment records, server integrity, and related access.
A common analytical pitfall
Restoring the original page does not establish that the underlying access path or other affected systems are secure.
Response considerations
Preserve changed content and access evidence, protect publishing authority, and investigate the cause before declaring recovery complete.
Visible content can be an integrity incident
Defacement changes a public or internal presentation without the owner's authorization. It can damage trust, spread false information, or interfere with normal activity. The modified page may be only the visible symptom of broader access. Investigators should establish how the content was changed and what else the same access could reach.
A website can receive content from a repository, content-management system, database, object store, or external integration. Follow the actual publishing path rather than assume that the web server itself was modified. Caches and content-delivery layers can also cause users to see different versions while the origin has already changed.
A fictional altered course page
An academy's course page displays an unauthorized message. The team preserves the visible content and relevant timestamps, then reviews publishing records, administrator sessions, repository changes, and hosting configuration. It checks whether the change originated from an account takeover, an exposed publishing credential, or another path supported by evidence.
Restoring the correct page addresses the public symptom but not necessarily the access problem. Revoke or rotate affected authority where appropriate, review other content and integrations, and validate the trusted publishing path before normal changes resume. Coordinate public communication with the responsible owner rather than speculate about attribution.
Trace a publishing route
Draw a fictional page's path from an editor to the public site, including review, build, hosting, and cache layers. Mark who can modify each stage and where audit records exist. Then identify the evidence needed to distinguish an unauthorized source edit from a hosting-level change. A prepared screenshot and event list are enough for this exercise; no real page needs to be altered.
Preserve a record of what different users actually saw, including the page address and observation time. Content caches can continue presenting an older unauthorized version after the origin is corrected. That difference affects both investigation timelines and verification that public recovery is complete.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
MITRE ATT&CK T1491: Defacement