AN0223: Analytic 0223
Adversary targets cloud-hosted public endpoints. Chain: (1) ALB/ELB/Cloud LB logs show exploit-like inputs or error spikes → (2) workload spawns shell or reaches metadata API → (3) egress to new external hosts.
Analyst context for executives and security teams
AN0223 is a cloud detection analytic for public-facing IaaS endpoints where suspicious load balancer activity is followed by workload behavior that suggests compromise, such as spawning a shell, contacting the cloud metadata API, and then reaching new external destinations. Its value is in correlating edge, host/workload, and egress evidence rather than treating web errors or unusual outbound traffic as isolated events.
Executive priority
This analytic matters for organizations running internet-exposed cloud workloads because the decision point is whether teams can quickly connect public endpoint attacks to possible workload takeover and outbound activity. Leaders should ask whether load balancer logs, workload process/network telemetry, metadata API access visibility, and egress monitoring are collected together with enough retention and ownership to support incident triage, containment, audit evidence, and cloud resilience decisions.
Technical view
For SOC and detection engineering, validate the full chain described by MITRE: cloud load balancer logs showing exploit-like inputs or error spikes, followed by shell execution or metadata API access from the workload, followed by egress to new external hosts. Because no official detection logic is provided, teams should build environment-specific correlation across IaaS edge logs, workload telemetry, cloud metadata access observations, and outbound network records. Treat any single signal cautiously; the analytic is strongest when multiple stages occur in sequence on the same endpoint or workload.
Likely telemetry
- ALB/ELB/cloud load balancer access logs
- HTTP request paths, parameters, user agents, response codes, and error-rate trends
- Workload process execution telemetry, especially shell or command interpreter launches
- Workload network telemetry for metadata API access
- Outbound egress logs showing new or uncommon external destinations
Detection direction
- Confirm that public load balancer logs can be joined to backend workload or service identity.
- Baseline normal error spikes and scanner noise to reduce false positives from internet background traffic.
- Correlate edge anomalies with workload shell execution or metadata API access rather than alerting only on exploit-like request strings.
- Flag egress to new external hosts after suspicious edge and workload events, especially when destination reputation or business purpose is unknown.
- Validate coverage gaps for ephemeral workloads, autoscaling groups, short log retention, NAT aggregation, and missing process telemetry.
Mitigation priorities
- Prioritize complete logging for internet-facing IaaS load balancers, backend workloads, metadata API access, and outbound egress.
- Harden public endpoints and patch exposed workloads through vulnerability management processes based on exposure and business criticality.
- Restrict workload access to metadata services and apply least-privilege cloud identity controls where applicable.
- Control and monitor outbound egress so new external destinations can be investigated and contained quickly.
- Ensure incident response playbooks can map a suspicious public endpoint event to the affected workload, owner, credentials, and containment path.
Analyst notes and limits
The object is a detection analytic, not a technique or procedure. MITRE provides a useful behavioral chain but no formal detection logic and no relationship context. Glexia would treat this as a correlation design pattern for managed detection, cloud security validation, and incident response readiness around public IaaS workloads.
The supplied ATT&CK fields only specify IaaS platform context and a brief analytic description. Tactics, relationships, and official detection text are not provided. Local architecture, logging configuration, workload telemetry, normal traffic patterns, and cloud provider implementation details are required before determining coverage or alert quality.
Analytic 0223
Adversary targets cloud-hosted public endpoints. Chain: (1) ALB/ELB/Cloud LB logs show exploit-like inputs or error spikes → (2) workload spawns shell or reaches metadata API → (3) egress to new external hosts.
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 | caebc19d2fe3… |
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 AN0223Open 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.