AN0489: Analytic 0489
High-frequency, repetitive service requests (e.g., HTTP, TLS renegotiation) originating from a single or small set of source IPs targeting endpoint web services or application ports, leading to exhaustion of CPU or memory on targeted Windows services.
Analyst context for executives and security teams
This analytic describes a denial-of-service-style signal: repeated high-volume service requests from one or a small number of source IPs against Windows-hosted web services or application ports, with resulting CPU or memory exhaustion. For leaders, the value is not attribution; it is resilience validation—whether critical Windows services can be monitored, rate-limited, triaged, and kept available when request volume becomes abnormal.
Executive priority
Prioritize this where Windows-based web or application services support customer access, internal operations, or regulated business processes. The key decision is whether the organization has enough network, application, and host telemetry to prove an availability incident is caused by abnormal request patterns rather than normal demand, misconfiguration, or capacity limits. This supports incident decision-making, continuity planning, and audit evidence around monitoring and service availability controls.
Technical view
SOC and IR teams should validate visibility for Windows services exposed on web or application ports, especially request frequency by source IP, service resource consumption, and endpoint health. Because ATT&CK provides no official detection logic for this analytic, teams should build baselines for normal request rates and correlate spikes from a single or small source set with CPU or memory pressure on the targeted Windows service. Tuning should separate legitimate load, scanning, monitoring tools, and application retries from sustained repetitive requests that degrade service.
Likely telemetry
- Web server or application access logs showing request rate, source IP, target port, URI or service endpoint where available
- Network flow or firewall logs showing high-frequency connections from one or a small set of source IPs to Windows-hosted service ports
- Windows host performance telemetry, especially CPU and memory utilization for the affected service or process
- Windows service health, restart, crash, or resource exhaustion events
- Load balancer, reverse proxy, or edge device logs where traffic reaches Windows-backed services
Detection direction
- Baseline normal request rates per Windows-hosted application or service port, then alert on sustained high-frequency repetitive requests from a single or small set of source IPs.
- Correlate network or web request spikes with host-side CPU or memory exhaustion before escalating as service-impacting activity.
- Tune for expected business peaks, vulnerability scanners, synthetic monitoring, health checks, and client retry storms to reduce false positives.
- Validate that logs preserve source IP accurately when proxies, load balancers, NAT, or CDN-like services sit in front of Windows services.
- Because no ATT&CK relationships or tactics are supplied, avoid over-classifying this as a specific intrusion phase; treat it as an availability and incident-triage detection pattern.
Mitigation priorities
- Confirm critical Windows web and application services have capacity monitoring, request logging, and alerting tied to service health.
- Use rate limiting, connection controls, and traffic filtering where appropriate at network, proxy, load-balancing, or application layers.
- Define incident runbooks for distinguishing malicious repetitive traffic from legitimate surges or application retry behavior.
- Ensure business owners know which Windows-hosted services are availability-critical and what degradation thresholds trigger response.
- Retain sufficient telemetry to support post-incident review and compliance evidence for monitoring and availability controls.
Analyst notes and limits
This is a detection analytic object, not a technique description. It is limited to Windows platforms and describes repetitive request behavior against endpoint web services or application ports that can exhaust CPU or memory. No official detection logic, tactics, relationships, aliases, or labels were supplied, so local baselining and environment-specific service context are essential.
The supplied ATT&CK fields do not provide active exploitation evidence, attribution, procedure examples, exact thresholds, affected products, or a formal detection query. Applicability depends on whether the organization operates Windows-hosted web or application services and collects network, application, and host performance telemetry.
Analytic 0489
High-frequency, repetitive service requests (e.g., HTTP, TLS renegotiation) originating from a single or small set of source IPs targeting endpoint web services or application ports, leading to exhaustion of CPU or memory on targeted Windows services.
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 | 363c1e57c0be… |
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 AN0489Open 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.