Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN0668: Analytic 0668

Detects disabling or reconfiguration of syslog or rsyslog services. Monitors sudden stops in logging daemons and suspicious execution of kill or service stop commands targeting syslog processes.

EnterpriseAN0668AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This analytic matters because Linux syslog and rsyslog are foundational evidence sources for security monitoring, incident response, and audit reconstruction. If these logging services are stopped or reconfigured unexpectedly, the organization may lose visibility at the exact moment defenders need it most. For leaders, the practical question is not only whether alerts exist, but whether SOC and IR teams can prove that critical Linux systems continue producing trustworthy logs during an incident.

Executive priority

Prioritize this as a logging-resilience and incident-readiness control. Disabling or changing syslog/rsyslog can undermine detection, forensic timelines, compliance evidence, and operational troubleshooting. Security leaders should ask which Linux systems are business-critical, whether logging daemon health is monitored, whether log gaps are escalated, and whether incident responders have an independent way to validate that host logging has not been interrupted.

Technical view

For Linux environments, validate monitoring for sudden stops or suspicious reconfiguration of syslog or rsyslog services, including command activity that uses kill or service-stop behavior against syslog-related processes. Because the ATT&CK object provides no tactic mapping and no official detection logic, teams should treat this as a detection validation requirement rather than a complete rule. SOC teams should confirm that alerts distinguish expected administrative maintenance from unexpected logging disruption, and IR teams should include log-service state checks when investigating Linux hosts with missing or delayed logs.

Likely telemetry

  • Linux process execution telemetry showing commands such as kill or service-management activity targeting syslog or rsyslog processes
  • Service state telemetry for syslog and rsyslog daemons, including sudden stops or restarts
  • Configuration change evidence for syslog or rsyslog service files and logging configuration
  • Central log pipeline health data showing unexpected gaps or loss of events from Linux hosts
  • Host audit or endpoint telemetry capable of showing who or what initiated logging-service changes

Detection direction

  • Validate that monitoring covers Linux systems where syslog or rsyslog is deployed; the supplied ATT&CK object does not support other platforms.
  • Alert on unexpected stopping, killing, or reconfiguration of syslog/rsyslog, but tune for approved patching, maintenance windows, and legitimate administrator activity.
  • Correlate host service-stop evidence with downstream log-ingestion gaps to reduce false positives and identify material visibility loss.
  • Review whether detection depends solely on the logging service being monitored; if syslog is disabled, teams may need independent endpoint, audit, or platform telemetry to confirm the event.
  • Because no ATT&CK relationships or official detection logic are supplied, map this analytic locally to relevant incident scenarios and validate with controlled defensive testing.

Mitigation priorities

  • Define which Linux systems require continuous logging and establish service-health monitoring for syslog/rsyslog on those assets.
  • Restrict and review privileged access capable of stopping or reconfiguring logging services.
  • Maintain approved-change workflows for logging configuration changes so the SOC can separate expected administration from suspicious disruption.
  • Use centralized log collection and pipeline monitoring to identify host-level log silence quickly.
  • Include logging-service integrity checks in incident response playbooks and compliance evidence collection.
Analyst notes and limits

AN0668 is a detection analytic for Linux that focuses on disabling or reconfiguring syslog/rsyslog and suspicious kill or service-stop activity against logging daemons. Its main decision value is visibility assurance: defenders should know when a core evidence source is interrupted and whether that interruption was authorized.

The supplied ATT&CK fields do not include tactics, relationships, aliases, labels, or official detection logic. This take therefore avoids attribution, exploitation claims, impact claims, and specific rule syntax. Local service names, logging architecture, administrative practices, and endpoint telemetry determine practical coverage.

Official MITRE ATT&CK definition

Analytic 0668

Detects disabling or reconfiguration of syslog or rsyslog services. Monitors sudden stops in logging daemons and suspicious execution of kill or service stop commands targeting syslog processes.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
8096e589e9074e5b...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 8096e589e907…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN0668
    Open source URL
Source and licensing

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.