DET0590: Behavioral Detection of External Website Defacement across Platforms
DET0590 is a MITRE detection strategy for behavioral detection of external website defacement. Even though the detection strategy itself has no official de...
Analyst context for executives and security teams
DET0590 is a MITRE detection strategy for behavioral detection of external website defacement. Even though the detection strategy itself has no official description or detection logic supplied, its relationship to ATT&CK technique T1491.002 External Defacement makes the business issue clear: public-facing web content can be altered to mislead users, damage trust, or signal a broader compromise. For leaders, the value is not just spotting changed pages; it is proving the organization can rapidly detect unauthorized public-content changes, determine whether they are cosmetic or part of a larger intrusion, and restore trusted service.
Executive priority
Treat this as an operational resilience and trust-protection control area for externally facing digital services. Executives should ask whether the organization has ownership of public web assets, baseline integrity monitoring, alert routing, and an incident process that can distinguish defacement from routine publishing. Because the related ATT&CK technique is an impact technique, coverage should support incident decision-making, communications readiness, compliance evidence for change control, and prioritization of controls around public web infrastructure.
Technical view
The supplied object does not include MITRE-provided detection logic, tactics, platforms, or a description. The only relationship states that this strategy detects T1491.002 External Defacement, an enterprise ATT&CK impact technique associated with Windows, IaaS, Linux, and macOS in the related technique context. SOC and IR teams should therefore validate behavioral coverage around unauthorized changes to externally exposed web content, unexpected publication events, integrity deviations from known-good baselines, and web application or hosting changes that cannot be tied to approved deployment activity. Detection engineering should correlate public-content changes with change-management records, administrative access, file/object modification telemetry, web server logs, cloud control-plane events where applicable, and external monitoring observations.
Likely telemetry
- Public website content integrity or checksum monitoring results
- Web server access and error logs for externally facing sites
- File system or object storage modification events for hosted web content
- Cloud control-plane audit logs for IaaS or hosted infrastructure changes where applicable
- Administrative authentication and session logs for web hosting, CMS, deployment, or management interfaces
Detection direction
- Validate that alerts distinguish unauthorized public-content changes from approved deployments, content-management edits, marketing updates, and maintenance activity.
- Baseline known-good web content and monitor for unexpected changes to high-visibility pages, landing pages, static assets, redirects, and user-facing messages.
- Correlate content-change alerts with administrative logins, deployment pipeline activity, cloud or server modification events, and change tickets to reduce false positives.
- Prioritize monitoring on externally facing systems and services because the related technique specifically concerns external defacement and user trust impact.
- Check blind spots around outsourced hosting, content delivery networks, CMS platforms, object storage-backed sites, and business-owned web properties that may not feed the SOC.
Mitigation priorities
- Establish accurate ownership and inventory for externally facing websites and hosting locations.
- Implement approved change workflows and preserve evidence that public-content updates are authorized.
- Deploy integrity or external monitoring for important public pages and assets, with alert routing to SOC or incident response teams.
- Harden administrative access to web hosting, CMS, deployment, and cloud management interfaces using least privilege and strong authentication controls.
- Maintain tested restoration paths for public web content so trusted service can be recovered quickly after unauthorized changes.
Analyst notes and limits
The ATT&CK detection strategy object is sparse: it provides a name and an external reference, but no official description, detection text, tactics, or platforms. The practical guidance here is derived from the stated relationship that DET0590 detects T1491.002 External Defacement and from the related technique description and platform context. Local asset architecture, hosting model, and change processes are required to turn this into a concrete detection specification.
No active exploitation, adversary attribution, detection coverage, or vendor-specific implementation can be inferred from the supplied fields. The detection strategy’s own platforms are not specified; platform references are limited to the related External Defacement technique context. Organizations must validate telemetry availability and detection quality in their own environment.
Behavioral Detection of External Website Defacement across Platforms
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1491.002 | External Defacement Sub-technique | This object detects External Defacement. |
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | f289b6b8efd5… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0590Open source URL
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.