A manufacturer Linux host has a new systemd unit that starts a shell script at every boot, and the distribution authentication log shows no matching change ticket. What persistence mechanism is in front of the analyst?
Select an answer to reveal the explanation.
Short Explanation
A spare key under the mat is still a way back in after you lock the door. On this Linux host the new systemd unit starts a shell script at boot, and that unit is the persistence. A Windows Run key, a flow exporter, and a mail filter do not launch that script.
Full Explanation
Persistence here is whatever starts the unwanted script again after a reboot. A systemd unit on this Linux host that starts a shell script each time the host boots is that mechanism, and the distribution authentication log has no change ticket that explains the new unit. A Windows Run key, on a Linux host that does not use the Windows registry for startup, is a Windows artifact and is not how this host comes back. A NetFlow exporter that summarizes plant traffic and does not launch code at boot records flow summaries and does not start a shell script. An email content filter that classifies messages and does not survive as a boot-time process judges mail and is not a boot entry on the host. The absent change ticket in the distribution authentication log makes the new unit unexpected, so it is treated as persistence rather than as planned startup. Exam caveat: other Linux locations can also persist code, but the artifact in this scenario is the new unit, so that is the mechanism to name. Operational check: read the command the unit runs, open the shell script it launches, and compare the unit's appearance with tickets and the distribution authentication log.