AN1165: Analytic 1165
Repeated invocation of high-resource application endpoints or GUI components causing CPU and memory spikes, logged as elevated request volumes, prolonged handle locks, or frequent crash recoveries.
Analyst context for executives and security teams
This analytic describes a Windows-focused signal for resource exhaustion behavior: repeated use of expensive application endpoints or GUI components that drives CPU and memory spikes, elevated request volume, handle locks, or crash recovery loops. For leaders, the value is in treating this as an operational resilience indicator, not just a security alert: the same evidence can determine whether a disruption is malicious, abusive automation, misconfiguration, or a failing application workflow.
Executive priority
Prioritize this where Windows applications support business-critical operations or user-facing services. The decision question is whether the organization can quickly distinguish normal workload surges from repeated high-resource invocation that threatens availability. This matters for incident triage, continuity planning, audit evidence around monitoring, and budget decisions for logging, endpoint visibility, and application performance telemetry.
Technical view
SOC, detection engineering, and IR teams should validate whether Windows endpoint, application, and service telemetry can show CPU and memory spikes correlated with repeated endpoint or GUI component invocation. Because ATT&CK provides no detection logic or tactic mapping for this analytic, teams should treat it as a detection concept requiring local baselining. Useful validation includes correlating elevated request volumes, prolonged handle locks, frequent crash recoveries, and process resource usage over time, then separating expected batch jobs, administrative activity, and legitimate peak usage from abnormal repeated invocation patterns.
Likely telemetry
- Windows process and resource utilization telemetry, including CPU and memory trends
- Application logs showing elevated request volumes or repeated component invocation
- Service or application error logs showing crash recovery events
- Handle, file, object, or resource lock indicators where collected
- Endpoint monitoring data that can correlate process behavior with application activity
Detection direction
- Confirm whether telemetry exists to correlate high CPU or memory usage with repeated application endpoint or GUI component activity, not just standalone performance spikes.
- Baseline normal request volume and resource consumption for the relevant Windows applications to reduce false positives from patching, reporting, backups, batch processing, or legitimate peak demand.
- Look for repeated patterns over a meaningful time window: sustained elevated request volume, prolonged handle locks, or recurring crash recovery can be more decision-useful than a single spike.
- Tune triage to include application owners, because local workflow knowledge is required to distinguish abuse from misconfiguration or capacity issues.
- Document gaps where crash recovery, handle lock, or application request telemetry is not collected; those gaps will limit confidence in this analytic.
Mitigation priorities
- Start with monitoring coverage for business-critical Windows applications: ensure endpoint, application, and performance data can be retained and correlated.
- Establish baselines and alert thresholds for normal resource consumption and request volume before relying on this analytic for security decisions.
- Review application resilience controls such as rate limiting, resource quotas, timeout handling, and crash recovery visibility where applicable to the monitored application environment.
- Prepare IR and operations runbooks that define when repeated resource exhaustion indicators become a security investigation versus an application reliability incident.
- Use findings to inform vulnerability management and architecture reviews when specific applications or components repeatedly fail under high-resource invocation.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique, and has no supplied tactics, relationships, aliases, labels, or official detection procedure. The strongest supported interpretation is defensive monitoring for Windows resource exhaustion indicators involving high-resource application endpoints or GUI components.
No relationship context, tactic mapping, detection pseudocode, adversary procedure examples, or mitigation references were supplied. Local application architecture, logging configuration, and business process baselines are required before this analytic can be operationalized with confidence.
Analytic 1165
Repeated invocation of high-resource application endpoints or GUI components causing CPU and memory spikes, logged as elevated request volumes, prolonged handle locks, or frequent crash recoveries.
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 | ac47e7e78585… |
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 AN1165Open 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.