MITRE ATT&CK T1491 Defacement: Detecting and Limiting Damage

A defaced website or a ransom note on every desktop is the moment an intrusion becomes public, and by then the attacker has usually had write access for some time. MITRE ATT&CK T1491 Defacement is an Impact (TA0040) technique: an adversary modifies visual content inside or outside the enterprise to deliver a message, intimidate, or claim (sometimes falsely) credit for an intrusion. ATT&CK v20 lists it for Windows, IaaS, Linux, macOS and ESXi, with two sub-techniques: T1491.001 Internal Defacement and T1491.002 External Defacement. This guide is the ATT&CK technique view for detection engineers and platform owners: the procedure examples MITRE records, the three v20 detection strategies, the single listed mitigation and the controls that make defacement both hard and cheap to reverse. For the incident steps, see the Website Defacement Playbook; for the actors who use it most, see the Hacktivism Guide.

Key takeaways

• Defacement is the last visible step. ATT&CK notes that internal defacement exposes the adversary, so it often follows after other goals are met: wallpaper and ransom notes arrive with or after encryption and wiping.
• External defacement is a write-access problem. Whether through a web shell, a CMS account, an exposed storage bucket or a hosting provider, someone gained the right to change content. Find and close that path before restoring the page.
• Most detection is file and object integrity. MITRE's analytics watch for writes to web roots, banner files, wallpaper settings and cloud storage objects by unexpected processes and identities.
• Restoration speed is a control. ATT&CK lists only M1053 Data Backup; versioned, immutable and pipeline-built content turns a defacement into a short outage.
• Deployment identities are part of the attack surface. The accounts, keys and bucket policies that publish content are the same ones an attacker uses to deface it.

What T1491 covers

The technique is about integrity of what people see. Data Encrypted for Impact (T1486) and Data Destruction (T1485) are about the data itself; they often run first, with defacement announcing them. See the MITRE ATT&CK T1486 Data Encrypted for Impact and the ATT&CK Impact Tactic Guide.

How adversaries use it

External defacement: state and hacktivist operations

• Sandworm Team (G0034), Georgia, October 2019: ATT&CK records Sandworm Team defacing approximately 15,000 websites belonging to Georgian government, non-government and private sector organisations. The UK government said the NCSC assessed "with the highest level of probability" that the GRU carried out the attacks of 28 October 2019, which targeted Georgian web hosting providers and also interrupted the service of several national broadcasters. The lesson for defenders is concentration: one compromised hosting provider defaced thousands of customer sites at once. See the Sandworm Threat Actor Profile.
• Ember Bear (G1003), Ukraine: ATT&CK links Ember Bear to defacements of several Ukrainian organisations' websites. Microsoft, which tracks the group as Cadet Blizzard, reports defacements in January 2022 alongside the WhisperGate wiper, renewed defacements in January 2023, and initial access mainly through exploitation of perimeter web servers (Confluence, Exchange) and likely commodity flaws in content management systems, followed by web shells. That chain, exploit then web shell then content change, is the pattern most external defacement detections should target. See the T1190 Exploit Public-Facing Application Defensive Guide and the T1505 Server Software Component Defensive Guide.

Internal defacement: ransomware and wipers

• Wallpaper and lock screen: ATT&CK records Black Basta, BlackCat, Qilin, INC Ransomware and The Gentlemen ransomware changing desktop wallpaper to show a ransom message, Meteor changing both wallpaper and lock screen image, and Diavol setting a black background with an "All your files are encrypted!" bitmap.
• Ransom notes in folders: BlackByte (G1043), ROADSWEEP and RansomHub are recorded leaving notes in directories they encrypt; ShinyHunters (G1057) is recorded leaving notes titled README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT.
• After destruction: Lazarus Group (G0032) replaced wallpaper with a threatening image after making systems unbootable with Disk Structure Wipe (T1561.002).
• Taunting and propaganda: Gamaredon Group (G0047) left taunting images and messages on desktops as proof of access; SameCoin can set the background to an image naming Hamas's military wing.
• Disk labels: ShrinkLocker renames disk labels to the actor's email address so that victims can make contact.

Internal defacement is a late signal, but not a useless one. A wallpaper or note written to one host is often the first of many, and the same process will touch the next host within seconds. Treat the first event as a trigger for isolation, not just a ticket.

Cloud-hosted content

MITRE's IaaS analytics watch for altered HTML or JavaScript uploaded to storage-backed sites through compromised console or API access. The Twilio TaskRouter SDK compromise shows the same failure without any stolen credential: a bucket policy changed during build troubleshooting let any AWS principal write to the path, and a replaced JavaScript file was served to visitors for about nine hours. The content was code rather than a political banner, but the control lesson is identical: who can write to what the public loads.

What to detect and where

ATT&CK v20 maps three detection strategies: DET0238 for the parent technique, DET0082 for internal defacement and DET0590 for external defacement. The table combines their analytics by platform.

S3 object-level events are CloudTrail data events, which are not logged by default; turn them on for buckets that serve public content. See the AWS CloudTrail Guide.

Detections to build first

1. Web root writes outside deployment: any create or modify in a web root by an identity or process that is not the deployment pipeline. With pipeline-only publishing this rule is nearly silent, which is the point. See the File Integrity Monitoring Guide.
2. Web server spawns a shell or writes a script: the web worker starting cmd.exe, powershell.exe, sh or bash, or writing a new .php, .aspx or .jsp file, which is the step before most external defacements. See PHP web shells.
3. Storage writes by the wrong principal: CloudTrail PutObject on content buckets from any role other than the publishing role, and any bucket policy change that widens write access.
4. Same note or wallpaper on many hosts: identical new file names (ransom notes) created across many directories or hosts, or wallpaper registry changes on more than a handful of endpoints in minutes.
5. External content check: synthetic monitoring that fetches key pages from outside and compares a hash or expected strings. This catches defacement through the CDN, DNS or hosting provider, which host logs never see.

Tuning notes

• CMS editors change pages legitimately. Alert on file system writes to templates and code, not on content edits made through the CMS's own audited workflow; review new CMS administrator accounts separately.
• Dynamic pages break naive hashing. Hash a stable element (a footer marker, a script list) or compare the rendered DOM for unexpected scripts and iframes, which also catches the drive-by setup ATT&CK describes.
• Wallpaper policy is noisy in some estates. Where Group Policy or MDM sets wallpaper, alert on changes made by any other process.

Mitigations

ATT&CK v20 lists one mitigation for T1491 and both sub-techniques: M1053 Data Backup, with backups stored off system and protected from the methods adversaries use to destroy them. See M1053 Data Backup. The table adds NHI Mgmt Group recommendations for preventing and reversing defacement.

Where identity fits

Almost every external defacement uses an identity that can write content: a CMS administrator, an FTP or SSH account on the host, a hosting control panel login, a CI/CD deploy key, or a cloud role with s3:PutObject. Inventory these identities per site, give the pipeline a dedicated workload identity, remove shared and long-lived credentials, and alert when any of them writes outside its normal path. A deploy key that only the pipeline uses is easy to monitor; a password shared by three agencies and a contractor is not. See the Backup Identity Isolation Guide for keeping the restore path separate from the identities an attacker may hold.

How to implement

1. Inventory public content: list every site, storage bucket, CDN origin and intranet portal, its owner, how it is published and which identities can write to it.
2. Make restore boring: confirm each site can be rebuilt from source or a versioned store; time a restore in a test environment and record it.
3. Turn on telemetry: file auditing or FIM on web roots, auditd rules on Linux web directories, CloudTrail data events on content buckets, hostd and messages logs from ESXi.
4. Run detections in report-only mode: two weeks of the five detections above, with every hit tied to a deployment or tuned.
5. Remove write paths: move to pipeline-only publishing in rings, starting with the highest-profile sites; roll back by restoring the previous deployment method for that site.
6. Test: in an approved test, have the red team write a harmless marker file to a staging web root and a staging bucket, and change wallpaper on a test host; measure time to alert and time to restore. See the Purple Teaming Guide.

Choosing controls by size

Detection and measurement

• Write-path coverage: percentage of public sites with FIM or storage data events feeding the SIEM. Target 100 percent of high-profile sites.
• Pipeline-only sites: percentage of sites where no interactive identity can write to production content.
• Time to detect: median time from a test marker write to alert.
• Time to restore: measured restore time per site against the target agreed with the owner.
• Writer identities: number of identities with write access to public content, trending down.

Common failure patterns

• Restoring before closing the path: the page is fixed, the web shell stays, and the site is defaced again that night.
• Trusting the hosting provider by default: the Georgia 2019 operation went through web hosting providers; ask your provider how it isolates customers and how it will notify you.
• Temporary write access that never ends: as in the Twilio case, a troubleshooting change widened a bucket policy and stayed for years.
• Monitoring only the origin: CDN, DNS and registrar changes deface the site without a single file changing on your server.
• Treating the ransom wallpaper as the incident start: it is the end of the intrusion; scope backwards for access, credential theft and exfiltration.

Framework mapping

Practitioner checklist

• Every public site, bucket and CDN origin has an owner and a list of identities that can write to it.
• Production content is published only by a pipeline identity; web roots are read-only for the web server.
• FIM or auditd covers web roots, banner files and ESXi welcome files; CloudTrail data events cover content buckets.
• Alerts fire on web servers spawning shells or writing scripts.
• External synthetic checks compare key pages against expected content.
• Bucket policies contain no wildcard write principals, and widening changes alert.
• Registrar and DNS accounts use MFA, scoped tokens and registry lock where offered.
• Restore time for each high-profile site has been measured in the last quarter.
• The incident runbook closes the access path before restoring content.

Standards and references

• MITRE ATT&CK: T1491 Defacement
• MITRE ATT&CK: T1491.001 Internal Defacement
• MITRE ATT&CK: T1491.002 External Defacement
• MITRE ATT&CK: M1053 Data Backup
• UK Government: UK condemns Russia's GRU over Georgia cyber-attacks
• Microsoft Threat Intelligence: Cadet Blizzard emerges as a novel and distinct Russian threat actor
• AWS: Retaining multiple versions of objects with S3 Versioning
• MITRE D3FEND: File Integrity Monitoring

Related NHI Mgmt Group resources: Website Defacement Playbook, Hacktivism Guide, Web Shell Response Playbook, ATT&CK Mitigations.