Research

Starting and Stopping a Harmless Linux Service: The Host Journal Against a Commercial EDR Sensor

What a leading commercial EDR platform recorded, set against the host's systemd journal, when a benign dummy service was started and stopped once on one lab Linux host in the 11:16:33 AM PT run: the start and the stop request were recorded; the journal's "deactivated" and "stopped" lines had no matching record.

Sennin Security Labsv1.0October 20, 20267 min read

A plain-English, vendor-neutral account of what a leading commercial endpoint detection and response (EDR) platform recorded on one lab Linux host when an operator started and then stopped a harmless lab-owned service, compared line by line with what the host's own systemd journal recorded. EDR is security software that watches each computer and records what programs do; on Linux a service is a background program managed by systemd, and the journal is systemd's own log. The product is not named.

The claim covers only the host journal against the EDR sensor under test, for one start and one stop. It does not cover auditd as a witness, any detection grade or alert behaviour beyond the one check stated, or any other host or customer environment.

Disclosures

1. auditd recorded only its own rule change, not the service start or stop.
2. A pre-existing audit rule that suppresses per-task syscall auditing was active throughout and probably prevented file-watch records.
3. systemd's service-start and service-stop audit records were not queried, although the test plan asked for them.
4. The first delivery was received by the host at 11:15:27 AM PT. The management agent wrote the script file and launched a shell to run it, but the script could not start ('cannot execute: required file not found', exit 127), so none of its commands ran and nothing on the host changed. A read-only check (11:16:07 AM PT) confirmed this before the single successful run (11:16:33 AM PT). The EDR sensor recorded the script write and a sh -c …/_script.sh process at 11:15:28 AM PT, which is consistent with this; no test command followed it. Because of this failed attempt, the 30 minutes before the run did not meet our quiet-period rule, and we record that as an anomaly.
5. The audit watch appeared twice in the applied ruleset; the cause was not determined.
6. The run's own restore left five working files in /tmp and the send-once marker and did not check the enable symlink; a separate cleanup send (11:29 AM PT) removed them and confirmed the symlink was already gone. An empty marker folder was left in place.
7. The cloud-provider vulnerability scanner was already installed. A separate setup run about 27 minutes before the test failed on this host as an unsupported platform, and it changed nothing. Its activity was not part of the test.
8. One host, one run, no frames.
9. A cloud provider's runtime threat-monitoring agent was also installed and running on the Linux lab host during this run. It may log or act on activity independently of the EDR sensor under test, and it may affect what that sensor records or alerts on. Its effect on these results was not tested.

Environment

One lab Linux host with a leading commercial EDR platform's sensor under test. Identifiers that could create exposure are not shown. Methods line: tested against a leading commercial EDR platform; vendor not named.

Method and commands

In the 11:16:33 AM PT run, the lab's host script recorded a baseline, created a small lab-owned throwaway systemd unit (a "dummy service" that is not a security product; it runs /usr/bin/sleep infinity), applied one reversible audit watch scoped to the dummy unit file, enabled, started and stopped the dummy as the stimulus, captured what the host logged, then reverted the audit rule and removed the dummy unit file. systemctl is-active returned active after the start and inactive after the stop, so the stop acted on a running service. The EDR sensor service was checked read-only before and after and was never stopped, disabled, reconfigured or deleted. Everything was local and reversible: no malware, exploit or offensive technique, and no wipe, rebuild or reboot. The commands below are the host steps:

# SSS-RC-2026-044 Part 01 — benign dummy systemd service: create, enable, start, stop, restore.
# Target ONLY the lab-owned dummy unit. The EDR sensor service is checked read-only
# and is never stopped, disabled, reconfigured or deleted.
# Commands shown are the host steps; the lab runner adds baseline and restore checks.

UNIT=sss-lab-dummy-044.service

# Create the dummy unit (not a security product)
#   [Service] ExecStart=/usr/bin/sleep infinity
sudo systemctl daemon-reload

# One reversible audit change: a scoped watch on the dummy unit file only
sudo auditctl -w /etc/systemd/system/sss-lab-dummy-044.service -p wa -k sss044

# Stimulus
sudo systemctl enable "$UNIT"
sudo systemctl start "$UNIT";  systemctl is-active "$UNIT"   # active
sudo systemctl stop "$UNIT";   systemctl is-active "$UNIT"   # inactive

# Observe
journalctl -u "$UNIT"
sudo ausearch -k sss044

# Restore
sudo systemctl disable "$UNIT"
sudo rm -f /etc/systemd/system/sss-lab-dummy-044.service
sudo systemctl daemon-reload
sudo auditctl -W /etc/systemd/system/sss-lab-dummy-044.service -p wa -k sss044

Journal against the EDR sensor under test (the 11:16:33 AM PT run)

The systemd journal recorded the dummy starting and stopping: "Started", "Stopping", "Deactivated successfully" and "Stopped", all within the same second (11:16:36 AM PT). The EDR sensor under test recorded the dummy service's start (the start command and the service's process) and its stop request (the stop command and the termination signal). It had no record matching the journal's "deactivated" and "stopped" lines; this is a visibility observation from this one pull, and no cause is asserted. A check for alerts on this host, made 30 minutes after the test, returned none. A cloud provider's runtime threat-monitoring agent was also installed and running on the Linux lab host during this run. It may log or act on activity independently of the EDR sensor under test, and it may affect what that sensor records or alerts on. Its effect on these results was not tested. (disclosure 9). The event counts were not filtered for it or for the cloud-provider vulnerability scanner.

### Journal against the EDR sensor under test — the 11:16:33 AM PT run (one host, one run)
Host journal line (11:16:36 AM PT)      EDR sensor under test
"Started  sss-lab-dummy-044.service"    recorded: the start command and the service's process
"Stopping sss-lab-dummy-044.service"    recorded: the stop command and the termination signal
"Deactivated successfully"              no matching record
"Stopped  sss-lab-dummy-044.service"    no matching record

Alert check on this host, made 30 minutes after the test: none returned.
A cloud provider's runtime threat-monitoring agent was also installed and running on the Linux lab host during this run. It may log or act on activity independently of the EDR sensor under test, and it may affect what that sensor records or alerts on. Its effect on these results was not tested.
The event counts were not filtered for it or for the cloud-provider vulnerability scanner.

Host evidence

This evidence pack contains no rendered terminal output frames (disclosure 8). The journal lines quoted above are from the host script's output.

Limitations

• This is one lab Linux host and one run; it is not a statement about any other host, operating system or customer environment.
• auditd recorded only its own rule change; it is not used as a witness here (disclosures 1 to 3).
• A cloud provider's runtime threat-monitoring agent was also installed and running on the Linux lab host during this run. It may log or act on activity independently of the EDR sensor under test, and it may affect what that sensor records or alerts on. Its effect on these results was not tested. (disclosure 9). A cloud-provider vulnerability scanner was also installed (disclosure 7). The event counts were not filtered for either.
• Sensor record times are batched to about half a second and journal times are to the second, so the comparison shows only that events fall in the same second, not their order.
• No matching sensor record for two journal lines is a visibility observation from this one pull; it does not mean the sensor "missed," "ignored" or "allows" anything.
• No product comparison, kill score or detection-gap claim is made or supported.

Methods and limitations

References

1. SSS-RC-2026-044 Part 01 Validation memo (VAL-01)
2. SSS-RC-2026-044 Part 01 evidence report, public-safe summary (2026-10-20)
3. SSS-RC-2026-044 case record

Want to know if your endpoint defenses still work?

We test them in your environment and give you a plain written answer.