AN0869: Analytic 0869
Monitoring for discrepancies between system daemon/service state and reported health messages (e.g., syslog shows AV/IDS daemon stopped, but spoofed messages claim it is still running). Detects userland processes impersonating AV/IDS command-line outputs or modifying log forwarding configurations.
Analyst context for executives and security teams
This analytic matters because it looks for a dangerous trust gap: Linux security services may be stopped or tampered with while logs or health messages still claim everything is normal. For leaders, the practical issue is not just malware evasion; it is whether SOC, incident response, and audit teams can trust the status signals they use to make containment and compliance decisions.
Executive priority
Prioritize this as a resilience and evidence-integrity concern for Linux environments that rely on AV, IDS, daemon health checks, syslog, or log forwarding to prove security control operation. Executives should ask whether security-service status is validated independently, whether log forwarding changes are monitored, and whether incident responders can distinguish real service health from spoofed userland output.
Technical view
For SOC and detection engineering teams, validate monitoring that compares actual Linux daemon/service state against reported health or log messages. The supplied analytic specifically focuses on discrepancies such as syslog indicating an AV/IDS daemon stopped while other messages claim it is still running, userland processes impersonating AV/IDS command-line outputs, and modification of log forwarding configurations. Because no ATT&CK detection logic is provided, teams must build local logic from available Linux service, process, syslog, and configuration telemetry.
Likely telemetry
- Linux service or daemon state records
- Syslog entries showing service start, stop, failure, or restart events
- AV/IDS process and health-status output where available
- Process execution telemetry for userland commands that may imitate security-tool output
- Log forwarding configuration files and change events
Detection direction
- Correlate reported security-tool health messages with independent service-manager or process-state evidence.
- Alert on conflicting signals, such as a stopped AV/IDS daemon alongside continued healthy-status messages.
- Monitor changes to log forwarding configuration, especially when paired with security-service failures or suspicious process activity.
- Tune for legitimate maintenance windows, package upgrades, service restarts, and administrator troubleshooting to reduce false positives.
- Assess blind spots where Linux hosts only forward application logs but do not provide process, service-state, or configuration-change telemetry.
Mitigation priorities
- Establish authoritative monitoring for Linux security-service state rather than relying on a single health message source.
- Protect and monitor log forwarding configurations and security-service configuration files.
- Require change control and maintenance documentation for security-service stops, restarts, and logging configuration updates.
- Ensure incident response playbooks include verification of sensor, AV, IDS, and log-forwarder integrity before relying on host evidence.
- Use compliance evidence to show not only that security tools are deployed, but that their operational state and logging paths are independently monitored.
Analyst notes and limits
The object is a detection analytic for Linux and has no supplied tactic, relationship context, or official detection query. Its value is in validating the integrity of defensive telemetry and control-health reporting, especially where defenders depend on Linux logs and service health messages during investigations.
This take is limited to the supplied ATT&CK fields. No active exploitation, threat actor use, specific tool, impact, or guaranteed detection coverage is implied. Local service managers, logging architecture, AV/IDS products, and telemetry retention will determine practical implementation.
Analytic 0869
Monitoring for discrepancies between system daemon/service state and reported health messages (e.g., syslog shows AV/IDS daemon stopped, but spoofed messages claim it is still running). Detects userland processes impersonating AV/IDS command-line outputs or modifying log forwarding configurations.
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 | 8006c440a15c… |
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 AN0869Open 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.