AN0666: Analytic 0666
Adversary uses compromised instance credentials or web application access to deface content hosted in S3 buckets, Azure Blob Storage, or GCP Buckets.
Analyst context for executives and security teams
This analytic concerns cloud-hosted content defacement where an adversary uses compromised instance credentials or web application access to alter content in object storage such as S3 buckets, Azure Blob Storage, or GCP Buckets. For leaders, the issue is not just website appearance; it can affect customer trust, public communications, incident escalation, and evidence that cloud storage access is governed and monitored.
Executive priority
Prioritize this as a cloud security and incident readiness validation item for IaaS environments that publish or serve business content from object storage. Executives should ask whether teams can prove who changed public-facing bucket or blob content, whether compromised credentials would be noticed quickly, and whether recovery procedures can restore known-good content without prolonged disruption or reputational damage.
Technical view
SOC, cloud security, and IR teams should validate monitoring around object storage write, overwrite, delete, permission, and publishing changes tied to instance credentials and web application identities. Because ATT&CK provides no official detection logic for AN0666, teams should build detections from local cloud audit logs, storage data events, identity activity, and application access records. Focus on unusual modification patterns, unexpected principals, changes from workloads that do not normally publish content, and content changes inconsistent with approved deployment workflows.
Likely telemetry
- Cloud control-plane audit logs for S3, Azure Blob Storage, and GCP Buckets where applicable
- Object storage data access events for write, overwrite, delete, copy, and metadata changes
- Cloud IAM activity involving instance credentials, service accounts, managed identities, or application identities
- Web application logs showing authenticated content-management or upload actions
- Deployment pipeline and change-management records for approved content updates
Detection direction
- Confirm that object-level write and delete activity is logged for public or business-critical buckets and blobs; control-plane-only logging may miss the decisive evidence.
- Baseline expected publishers, service accounts, instance roles, and deployment paths for hosted content, then alert on modifications by unusual identities or sources.
- Correlate storage modifications with web application authentication and instance credential use to distinguish legitimate publishing from compromised access.
- Tune for false positives from normal content deployments, marketing updates, CI/CD jobs, and scheduled synchronization tasks by integrating approved change windows and deployment metadata.
- Validate alerting and triage workflows despite the lack of MITRE-provided detection logic for this analytic.
Mitigation priorities
- Restrict write access to hosted-content buckets and blobs to the smallest practical set of application or deployment identities.
- Separate public read access from administrative write paths and review permissions for instance credentials, service accounts, and web application identities.
- Enable storage versioning, backups, or equivalent recovery mechanisms for content that supports public operations or customer trust.
- Require controlled deployment workflows for content changes so unauthorized modifications can be distinguished from approved publishing.
- Regularly review cloud audit logging coverage and retention so incident responders can reconstruct who changed what and when.
Analyst notes and limits
The supplied object is a detection analytic, not a technique, and it has no tactics or relationships supplied. The practical value is in using it as a coverage check for cloud object-storage defacement scenarios involving compromised instance credentials or web application access.
Official detection content is not provided, and no relationship context is supplied. This take cannot infer specific adversaries, active exploitation, impact severity, or existing detection coverage. Local cloud architecture, logging configuration, identity design, and publishing workflows are required to turn this into precise detections.
Analytic 0666
Adversary uses compromised instance credentials or web application access to deface content hosted in S3 buckets, Azure Blob Storage, or GCP Buckets.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | f0ad306783fa… |
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 AN0666Open 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.