AN0851: Analytic 0851
User or remote input triggers application crash or segmentation fault (e.g., SIGSEGV) with service recovery attempts, observed via audit logs and systemd journaling.
Analyst context for executives and security teams
This analytic matters because repeated application crashes or segmentation faults on Linux services can be an early warning of instability, probing, malformed input, or conditions that could affect service availability. For leaders, the value is not in treating every crash as malicious, but in ensuring critical Linux services have enough logging and operational context to distinguish routine software defects from security-relevant disruption.
Executive priority
Prioritize this where Linux-hosted services support customer-facing systems, operational workflows, regulated evidence trails, or incident response dependencies. Executives should ask whether teams can prove when a critical service crashed, what input or remote activity preceded it, whether recovery succeeded, and whether the event created business downtime or degraded resilience.
Technical view
For SOC, detection engineering, and IR teams, validate visibility into Linux crash indicators such as SIGSEGV, application fault messages, service restart attempts, and systemd unit recovery behavior. Because the ATT&CK object provides no tactic mapping, no relationship context, and no official detection logic, this should be handled as a resilience and triage analytic: correlate crash and restart events with audit logs, application logs, remote access records, and recent changes before escalating as suspicious.
Likely telemetry
- Linux audit logs
- systemd journal entries
- Application crash logs and error logs
- Service manager restart and recovery events
- Kernel or syslog messages indicating segmentation faults such as SIGSEGV
Detection direction
- Baseline expected crash and restart frequency for critical Linux services to reduce noise from known software defects.
- Alert on unusual clustering of segmentation faults, repeated recovery attempts, or crashes affecting high-priority services.
- Correlate crash timing with remote input, authentication activity, request spikes, configuration changes, or new deployments before assigning security severity.
- Tune for operational context: a single crash may be low value, while repeated crashes with remote input patterns or failed recovery can be material.
- Document blind spots where audit logs, journald retention, application logs, or service restart history are incomplete.
Mitigation priorities
- Ensure systemd journaling, audit logging, and application logging are enabled and retained long enough for investigation.
- Define ownership and escalation paths for critical Linux service crashes that may affect availability or incident response.
- Harden service recovery practices so restart loops, failed recoveries, and degraded states are visible to operations and security teams.
- Maintain patching and change-control discipline for Linux applications that repeatedly crash under input or load.
- Use incident response runbooks that separate routine defects from potentially security-relevant crashes through correlation with local telemetry.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Linux describing application crashes or segmentation faults with service recovery attempts visible in audit logs and systemd journaling. No tactics, relationships, aliases, labels, or official detection logic were supplied, so this take focuses on defensive validation and operational decision value rather than adversary intent.
This summary is limited to the official STIX fields and external reference provided. It does not establish attacker behavior, exploitation, attribution, impact, or existing detection coverage. Local service criticality, logging configuration, retention, and incident history are required to determine priority.
Analytic 0851
User or remote input triggers application crash or segmentation fault (e.g., SIGSEGV) with service recovery attempts, observed via audit logs and systemd journaling.
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 | 6da9e7f6d00d… |
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 AN0851Open 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.