AN0585: Analytic 0585
Malicious script or binary causes repeated kernel panics, OOM kills, or systemd service restarts targeting services like nginx, httpd, sshd.
Analyst context for executives and security teams
This analytic points to a Linux availability-risk pattern: a malicious script or binary repeatedly destabilizes a host by triggering kernel panics, out-of-memory kills, or systemd service restarts against important services such as nginx, httpd, or sshd. For leaders, the practical issue is service continuity: if web or remote access services repeatedly fail, the incident may look like reliability noise unless SOC, infrastructure, and IR teams can correlate crashes, restarts, and suspicious process activity.
Executive priority
Prioritize this as an operational resilience and incident triage concern for Linux environments running critical services. Executives should ask whether teams can distinguish normal service instability from malicious disruption, whether restart/crash evidence is retained long enough for investigation, and whether critical Linux services have monitoring and escalation paths tied to business impact.
Technical view
Because ATT&CK provides no official detection logic for AN0585, defenders should validate coverage around Linux crash and service-restart evidence rather than assume a ready-made rule exists. SOC and IR teams should correlate repeated kernel panic indicators, OOM killer events, and systemd restart loops with process execution, service status changes, and activity affecting nginx, httpd, or sshd. Detection should focus on abnormal frequency, clustering across hosts or services, and proximity to suspicious binaries or scripts.
Likely telemetry
- Linux system logs showing kernel panic, OOM killer, and service failure events
- systemd journal entries for service restarts, crashes, and restart loops
- Process execution telemetry for scripts or binaries preceding instability
- Service monitoring data for nginx, httpd, sshd, or other critical Linux services
- Host performance and memory pressure metrics that can contextualize OOM events
Detection direction
- Validate that Linux hosts forward kernel, journald/systemd, and service logs to a centralized location with adequate retention.
- Build or tune analytics for repeated service restarts, OOM kills, or crash patterns affecting critical services, especially when the pattern is new or concentrated in time.
- Correlate instability with recent process execution, file changes, configuration changes, or administrative activity to reduce false positives from legitimate maintenance or resource exhaustion.
- Treat single OOM or restart events cautiously; the material signal in the supplied object is repetition and targeting of important services.
- Confirm that coverage exists for Linux specifically; no other platform is supported by the supplied ATT&CK fields.
Mitigation priorities
- Ensure critical Linux services have health monitoring, restart visibility, and escalation paths tied to business service ownership.
- Harden operational baselines for nginx, httpd, sshd, and similar services so unusual restart frequency or crash behavior is measurable.
- Maintain centralized logging for kernel, systemd, service, and process evidence to support incident response and audit reconstruction.
- Review resource limits, service isolation, and change-control practices to reduce ambiguity between malicious disruption and ordinary capacity or configuration failures.
- Prepare IR playbooks for Linux availability incidents that include evidence preservation before rebooting or rebuilding affected systems.
Analyst notes and limits
AN0585 is a detection analytic object, not a technique, and the supplied record has no tactic mapping, relationship context, aliases, labels, or official detection text. The strongest supported interpretation is a Linux-focused detection and response use case for repeated host or service instability caused by a malicious script or binary.
This take is limited to the official fields supplied. It does not establish prevalence, attribution, active exploitation, specific tools, affected organizations, or guaranteed detection logic. Local baselines, logging coverage, service criticality, and change history are required to determine whether observed instability is malicious or operational.
Analytic 0585
Malicious script or binary causes repeated kernel panics, OOM kills, or systemd service restarts targeting services like nginx, httpd, sshd.
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 | 575618f64119… |
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 AN0585Open 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.