Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1491: Defacement

Adversaries may modify visual content available internally or externally to an enterprise network, thus affecting the integrity of the original content. Reasons for Defacement include delivering messaging, intimidation, or claiming (possibly false) credit for an intrusion. Disturbing or offensive images may be used as a part of Defacement in order to cause user discomfort, or to pressure compliance with accompanying messages.

EnterpriseT1491TechniqueObject v1.4 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Defacement is an impact behavior where an adversary changes visible internal or external content, such as web pages, login messages, or user-facing system visuals, to undermine trust, intimidate users, or claim credit for an intrusion. For leaders, the business issue is not only the altered content; it is the loss of confidence in system integrity, the communications burden, and the need to quickly prove what was changed, how far access extended, and whether recovery content is trustworthy.

Executive priority

Treat defacement as a visible integrity incident that can rapidly become a reputational, operational, and audit-evidence problem. Executives should ask whether the organization can identify authoritative content, restore it from protected backups, preserve evidence, and communicate confidently about affected internal or external systems. Priority should be highest for public-facing services, critical internal portals, and platforms where altered content could mislead employees or customers.

Technical view

ATT&CK provides no official detection text for T1491, but the related detection strategy DET0238 points to defacement via file and web content modification across platforms. SOC and IR teams should validate monitoring for unauthorized changes to web content, internal site content, server login messages, desktop or system visual assets, and content hosted on Windows, Linux, macOS, ESXi, and IaaS environments where applicable. Because T1491 is an impact technique with internal and external sub-techniques, triage should separate public-facing defacement from internal user-facing changes while still investigating the access path, scope of modification, and whether additional integrity or availability impact occurred.

Likely telemetry

  • File integrity monitoring or file modification events for web roots, application content directories, configuration files, login banners, and visual assets
  • Web server, application server, and content management logs showing content changes, publishing actions, or unexpected administrative activity
  • Cloud/IaaS audit logs for storage, compute, image, or hosted content modifications where external content is served from cloud infrastructure
  • Endpoint telemetry showing changes to wallpapers, login messages, scripts, or local content on Windows, Linux, macOS, and ESXi systems
  • Authentication and administrative activity logs tied to accounts capable of modifying internal or external content

Detection direction

  • Baseline high-value internal and external content so that unauthorized visual or file changes are detectable rather than discovered only by users or customers.
  • Tune alerts around unexpected modification of web content, login messages, wallpapers, and other user-visible assets, especially when performed by unusual accounts, outside normal deployment windows, or outside approved change processes.
  • Correlate content changes with authentication, administrative access, and hosting-platform audit events to distinguish legitimate publishing from unauthorized defacement.
  • Account for false positives from normal website publishing, branding updates, patching, and configuration management; detection should rely on change authorization, actor context, and content location rather than file-change events alone.
  • Validate coverage separately for Internal Defacement (T1491.001) and External Defacement (T1491.002), since public-facing sites, internal portals, endpoints, and infrastructure consoles may produce different evidence.

Mitigation priorities

  • Prioritize protected, tested data backups for critical servers and content repositories, consistent with ATT&CK mitigation M1053 Data Backup.
  • Keep backups isolated or otherwise protected from compromise during active incidents so altered content can be restored from a trusted source.
  • Define authoritative content sources and approved deployment paths so responders can quickly compare current content with known-good versions.
  • Harden administrative access to systems that can modify internal or external visual content, and review whether logging is sufficient to support incident response and compliance evidence.
  • Include defacement scenarios in incident response planning, including evidence preservation, restoration decision points, and communications coordination for public-facing or employee-facing systems.
Analyst notes and limits

This object is an enterprise ATT&CK impact technique covering Windows, IaaS, Linux, macOS, and ESXi. The most useful relationship context is the split between Internal Defacement and External Defacement, the presence of a related detection strategy for file and web content modification, and the Data Backup mitigation. Glexia would use this technique to drive validation of integrity monitoring, backup recoverability, change-control evidence, and response readiness rather than treating defacement as a purely cosmetic incident.

MITRE does not provide official detection guidance for this object, and the supplied relationship details do not include vendor-specific telemetry, procedures, or confirmed threat activity. Local architecture, content hosting model, identity controls, and change-management practices are required to determine actual exposure and detection coverage.

Official MITRE ATT&CK definition

Defacement

Adversaries may modify visual content available internally or externally to an enterprise network, thus affecting the integrity of the original content. Reasons for Defacement include delivering messaging, intimidation, or claiming (possibly false) credit for an intrusion. Disturbing or offensive images may be used as a part of Defacement in order to cause user discomfort, or to pressure compliance with accompanying messages.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1491.002 External Defacement Sub-technique External Defacement subtechnique of this object.
Enterprise T1491.001 Internal Defacement Sub-technique Internal Defacement subtechnique of this object.
Relationship explorer

All related ATT&CK context

subtechnique of · Technique T1491.002: External Defacement Enterprise subtechnique of · Technique T1491.001: Internal Defacement Enterprise detects · Detection Strategy DET0238: Defacement via File and Web Content Modification Across Platforms Enterprise mitigates · Mitigation M1053: Data Backup Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1053: Data Backup

Data Backup involves taking and securely storing backups of data from end-user systems and critical servers. It ensures that data remains available in the event of system compromise, ransomware attacks, or other disruptions. Backup processes should include hardening backup systems, implementing secure storage solutions, and keeping backups isolated from the corporate network to prevent compromise during active incidents. This mitigation can be implemented through the following measures:

Regular Backup Scheduling: - Use Case: Ensure timely and consistent backups of critical data. - Implementation: Schedule daily incremental backups and weekly full backups for all critical servers and systems.

Immutable Backups: - Use Case: Protect backups from modification or deletion, even by attackers. - Implementation: Use write-once-read-many (WORM) storage for backups, preventing ransomware from encrypting or deleting backup files.

Backup Encryption: - Use Case: Protect data integrity and confidentiality during transit and storage. - Implementation: Encrypt backups using strong encryption protocols (e.g., AES-256) before storing them in local, cloud, or remote locations.

Offsite Backup Storage: - Use Case: Ensure data availability during physical disasters or onsite breaches. - Implementation: Use cloud-based solutions like AWS S3, Azure Backup, or physical offsite storage to maintain a copy of critical data.

Backup Testing: - Use Case: Validate backup integrity and ensure recoverability. - Implementation: Regularly test data restoration processes to ensure that backups are not corrupted and can be recovered quickly.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.4
Created
Modified
Raw hash
98a4d714fee9e3fe...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.4 Current bundle 98a4d714fee9…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack T1491
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use