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

AN1625: Analytic 1625

Adversary modifies content in cloud-hosted websites (e.g., AWS S3-backed, Azure Blob-hosted sites) by gaining access to management consoles or APIs and uploading altered HTML/JS files.

EnterpriseAN1625AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic concerns unauthorized modification of content in cloud-hosted websites, such as static sites backed by AWS S3 or Azure Blob storage. For leaders, the practical issue is not just website defacement: altered HTML or JavaScript can affect customer trust, service integrity, compliance evidence, and incident communications. Because the object is limited to IaaS-hosted website content changed through management consoles or APIs, the key defensive question is whether the organization can prove who changed public web content, from where, and whether the resulting files are approved.

Executive priority

Prioritize this as a cloud integrity and incident readiness problem. Security and business owners should ask whether public cloud-hosted web assets are inventoried, whether administrative access to storage-backed sites is tightly governed, and whether change evidence is sufficient for audit, breach triage, and customer communications. Budget and control decisions should focus on identity governance, cloud API logging, storage object change monitoring, and approved deployment paths rather than relying only on endpoint or network monitoring.

Technical view

SOC, detection engineering, cloud security, and IR teams should validate visibility into management console and API activity for IaaS-hosted website storage. The supplied ATT&CK description points to altered HTML/JS uploads, so teams should correlate cloud control-plane events with storage object writes, file metadata changes, and deployment records for public website buckets or containers. Because ATT&CK provides no official detection logic and no tactics for this analytic, local baselining is required to distinguish normal publishing workflows from suspicious direct console/API changes.

Likely telemetry

  • Cloud management console authentication and session activity
  • Cloud API audit logs for storage object creation, overwrite, delete, and metadata changes
  • Storage bucket/container access logs where enabled
  • Object versioning or file integrity records for HTML and JavaScript assets
  • Identity and access management events for users, roles, service principals, and access keys used to modify website content

Detection direction

  • Identify cloud storage resources that host public website content and monitor changes to HTML/JS and related web assets.
  • Alert or review when website content is modified outside approved deployment pipelines or expected administrative identities.
  • Correlate object writes with console/API authentication context, source location, role assumption, service principal use, and change ticket or release evidence where available.
  • Tune for legitimate publishing activity to reduce false positives, especially scheduled releases, automated deployments, and content management workflows.
  • Watch for blind spots where cloud audit logging, storage access logging, object versioning, or asset ownership mapping is incomplete.

Mitigation priorities

  • Maintain an inventory of cloud-hosted websites and the storage buckets or containers that serve them.
  • Restrict management console and API write access to website content using least privilege and approved deployment identities.
  • Require strong identity controls for cloud administration, including appropriate authentication and governance over roles, service principals, and access keys.
  • Use controlled deployment workflows so direct content changes are exceptional and reviewable.
  • Enable cloud control-plane logging and, where appropriate, storage object logging/versioning to support investigation and recovery.
Analyst notes and limits

This is a detection analytic object, not a full ATT&CK technique entry. The official description is specific to cloud-hosted website content modification through management consoles or APIs and gives examples of AWS S3-backed and Azure Blob-hosted sites. No relationship context, tactic mapping, or official detection text was supplied, so the take focuses on defensive validation rather than a prescribed detection rule.

Detection fidelity depends on local cloud architecture, logging configuration, identity model, and deployment process evidence. The supplied object does not support claims about specific adversaries, active exploitation, business impact, or guaranteed detection coverage.

Official MITRE ATT&CK definition

Analytic 1625

Adversary modifies content in cloud-hosted websites (e.g., AWS S3-backed, Azure Blob-hosted sites) by gaining access to management consoles or APIs and uploading altered HTML/JS files.

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

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.0
Created
Modified
Raw hash
a1b7f8ce6dcb0f85...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle a1b7f8ce6dcb…
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.

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 AN1625
    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.