AN0492: Analytic 0492
Automated or scripted HTTP/TLS flooding from one VM or cloud instance against another service, exploiting compute-based billing or exhaustion of service infrastructure.
Analyst context for executives and security teams
This analytic describes cloud-to-service HTTP/TLS flooding from a VM or cloud instance. The business issue is not only availability loss; in IaaS environments, traffic and compute consumption can also create unexpected cost exposure and strain shared service infrastructure. Leaders should treat this as a resilience and cloud cost-risk scenario that depends heavily on whether cloud, network, and application telemetry can show abnormal service-to-service request volume.
Executive priority
Prioritize this where internet-facing or internal cloud-hosted services are critical to revenue, operations, or customer trust, and where compute-based billing could amplify the financial impact of abuse. Executives should ask whether teams can distinguish legitimate load from scripted flooding, who owns cloud cost anomaly response, and whether incident response playbooks cover both availability protection and billing containment.
Technical view
For SOC, cloud security, and incident response teams, validate visibility for IaaS-originated HTTP/TLS request floods between a VM or cloud instance and a target service. Because the ATT&CK object provides no official detection logic, tactics, or relationships, teams should derive local analytics from cloud flow logs, load balancer or reverse proxy logs, web/API access logs, TLS connection metadata, and cloud billing or usage metrics. Detection should focus on abnormal request or connection rates, unusual source instance behavior, repeated requests against a service, and correlation with service saturation or cost spikes.
Likely telemetry
- IaaS network flow logs showing traffic volume between cloud instances and services
- Load balancer, reverse proxy, web server, or API gateway request logs
- TLS connection metadata where available, such as session counts, connection rates, and destination service patterns
- Cloud instance metadata linking source traffic to VM or instance identity
- Service health, saturation, latency, and error-rate metrics
Detection direction
- Establish baselines for normal request volume, connection rate, and source-to-destination patterns for cloud-hosted services.
- Correlate high HTTP/TLS request rates from a VM or cloud instance with service degradation, infrastructure exhaustion, or cost anomalies.
- Tune for legitimate bursty workloads, autoscaling events, load testing, batch jobs, and monitoring systems to reduce false positives.
- Validate whether encrypted TLS traffic still produces enough metadata through load balancers, proxies, flow logs, or service logs to support detection.
- Because no ATT&CK relationships or official detection text are supplied, map this analytic to local cloud architecture and service ownership before operationalizing alerts.
Mitigation priorities
- Define ownership and escalation paths for cloud availability events that also create cost exposure.
- Implement and test rate limiting, quota controls, autoscaling guardrails, and service protection controls appropriate to cloud-hosted HTTP/TLS services.
- Harden cloud instance governance so unexpected high-volume traffic from VMs can be investigated and contained quickly.
- Use cloud budget, billing anomaly, and resource consumption alerts as supporting signals for SOC and incident response workflows.
- Document evidence sources and response actions for audit, resilience, and incident readiness purposes.
Analyst notes and limits
This object is a detection analytic in the enterprise ATT&CK domain for IaaS. Its official description is limited to automated or scripted HTTP/TLS flooding from one VM or cloud instance against another service, with billing or infrastructure exhaustion implications. No official detection content, tactics, or relationship context were supplied, so local telemetry and architecture determine practical coverage.
The supplied ATT&CK fields do not identify a specific adversary, campaign, affected vendor, active exploitation status, detailed detection logic, or related techniques. Any assessment of exposure, control effectiveness, or alert fidelity requires environment-specific cloud, network, application, and billing evidence.
Analytic 0492
Automated or scripted HTTP/TLS flooding from one VM or cloud instance against another service, exploiting compute-based billing or exhaustion of service infrastructure.
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 | f16189426d00… |
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 AN0492Open 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.