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

AN1370: Analytic 1370

Detects kill/systemctl/service commands against EDR, auditd, falco, osquery, rsyslog, journald, or agent processes; configuration edits disabling startup; module unload attempts; abrupt cessation of logs after privileged shell execution.

EnterpriseAN1370AnalyticObject v1.1 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

AN1370 is a Linux detection analytic focused on attempts to disable or disrupt endpoint security and logging services such as EDR agents, auditd, Falco, osquery, rsyslog, and journald. For leaders, the practical issue is not just tool tampering; it is loss of visibility during an incident. If these services stop, are killed, are prevented from starting, or suddenly stop producing logs after privileged shell activity, the organization may lose the evidence needed for containment, investigation, compliance reporting, and recovery decisions.

Executive priority

Prioritize this analytic where Linux systems support critical business services, regulated workloads, or incident response evidence requirements. Security leaders should ask whether SOC and IR teams can prove that security-agent shutdowns, logging gaps, startup-disablement changes, and module unload attempts are centrally visible and alertable. This is especially important for resilience and audit readiness because the absence of logs can become a material incident-handling blind spot.

Technical view

For Linux environments, validate monitoring for kill, systemctl, and service commands targeting EDR, auditd, Falco, osquery, rsyslog, journald, or related agent processes. Also validate visibility into configuration edits that disable service startup, module unload attempts, and abrupt log cessation following privileged shell execution. Because no ATT&CK tactic or relationship context is supplied, treat this as a defensive analytic for Linux telemetry integrity and security tooling availability rather than as evidence of a specific campaign or technique chain.

Likely telemetry

  • Linux process execution telemetry for kill, systemctl, and service command usage
  • Service manager activity and unit state changes
  • Security and logging agent process status events
  • Configuration file change telemetry related to service startup behavior
  • Kernel/module unload attempt telemetry where available

Detection direction

  • Confirm the SOC can distinguish authorized administration or maintenance from unexpected disabling of security and logging services.
  • Correlate service-stop, process-kill, startup-disablement, and module-unload signals with user, host, privilege, and recent shell context.
  • Tune for named services and agents present in the environment; the analytic is Linux-specific and should not be assumed to cover other platforms.
  • Monitor for negative evidence: abrupt cessation of logs or heartbeats can be as important as explicit stop commands.
  • Account for false positives from patching, troubleshooting, agent upgrades, and approved service restarts by using maintenance windows and change records.

Mitigation priorities

  • Establish baselines and approved change processes for Linux security and logging service administration.
  • Restrict privileged access capable of stopping agents, editing startup configuration, or unloading modules.
  • Ensure critical logs and agent health signals are forwarded centrally so local tampering does not erase investigation evidence.
  • Implement service health monitoring and alerting for auditd, journald, rsyslog, Falco, osquery, EDR, and comparable agents actually deployed.
  • Regularly test incident response playbooks for scenarios where endpoint telemetry becomes incomplete or stops unexpectedly.
Analyst notes and limits

The supplied object is a detection analytic, not a technique, and no relationship context is provided. Its value is strongest as a control-validation and telemetry-integrity check for Linux security operations. Detection engineering should map the named process, service, configuration, module, and log-gap conditions to the organization’s actual Linux builds and deployed agents.

Official detection logic is not provided, tactics are not specified, and there are no relationships to techniques, groups, software, or mitigations. This take therefore avoids claims about adversary use, impact, attribution, or guaranteed coverage. Local command logging, service telemetry, agent inventory, and centralized log pipeline design are required to determine actual detection effectiveness.

Official MITRE ATT&CK definition

Analytic 1370

Detects kill/systemctl/service commands against EDR, auditd, falco, osquery, rsyslog, journald, or agent processes; configuration edits disabling startup; module unload attempts; abrupt cessation of logs after privileged shell execution.

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.1
Created
Modified
Raw hash
4206ec31e59abf86...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 4206ec31e59a…
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 AN1370
    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.