Cyber Security Quiz: Endpoint Persistence Mechanisms
10 questions · exam conditions
0:00
Endpoint Persistence MechanismsQuestion 1 of 10

On a Windows workstation, an unknown executable starts whenever user Alice signs in. It does not start when other users sign in, and it is absent immediately after a reboot until Alice authenticates. The executable is not present in either Startup folder.

Which persistence location most closely matches the observed scope and trigger?

An auto-start service configured under the system-wide Services registry branch
A Run value configured under Alice's HKEY_CURRENT_USER registry hive
A boot-start driver registered under the system-wide Services registry branch
A Run value configured under the HKEY_LOCAL_MACHINE registry hive
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Endpoint Persistence Mechanisms

Practice Endpoint Persistence Mechanisms in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Endpoint Persistence Mechanisms, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

On a Windows workstation, an unknown executable starts whenever user Alice signs in. It does not start when other users sign in, and it is absent immediately after a reboot until Alice authenticates. The executable is not present in either Startup folder.

Which persistence location most closely matches the observed scope and trigger?

  1. An auto-start service configured under the system-wide Services registry branch
  2. A Run value configured under Alice's HKEY_CURRENT_USER registry hive (correct answer)
  3. A boot-start driver registered under the system-wide Services registry branch
  4. A Run value configured under the HKEY_LOCAL_MACHINE registry hive
Explanation: When troubleshooting persistence on Windows, your two key diagnostic questions are: who does it affect? and what triggers it? Here, the executable fires only for Alice and only after she logs in — never at boot, never for other users. That pattern points directly to a per-user, login-triggered persistence mechanism. The HKEY_CURRENT_USER (HKCU) hive is loaded exclusively when a specific user authenticates, making it invisible until that moment. A Run value placed under Alice's HKCU\Software\Microsoft\Windows\CurrentVersion\Run executes automatically at her login and no one else's. This matches every observed clue perfectly — user-specific scope, post-authentication trigger, absent after reboot until she logs in. B is correct. Here's why the distractors fail: A describes an auto-start service under HKEY_LOCAL_MACHINE's Services branch. Services run under the system account and launch at boot, independent of any user logging in — the wrong scope and wrong trigger. C describes a boot-start driver, which loads even earlier than services, during the boot process itself, long before any user is involved. That directly contradicts "absent after reboot until Alice authenticates." D uses HKEY_LOCAL_MACHINE's Run key, which applies system-wide to all users — the persistence would appear for every user, not just Alice. The study tip to carry forward: HKCU = per-user, HKLM = all users, Services/drivers = system-level (boot-time). On exam questions describing selective, login-triggered behavior tied to one user, HKCU is almost always the right category to investigate.

Question 2

On a Linux endpoint, an intruder places sync-cache.service in /etc/systemd/system/. The unit contains a valid [Install] section with WantedBy=multi-user.target. The intruder runs systemctl start sync-cache.service but never enables the unit or creates a target dependency. The service is running when the endpoint is seized.

Assuming no other configuration changes, what should the analyst expect after the next reboot?

  1. The service will start because storing a unit in /etc/systemd/system/ enables it automatically
  2. The service will start because WantedBy immediately adds the unit to the named target
  3. The service will not start automatically because starting and enabling are separate operations (correct answer)
  4. The service will not start because custom systemd units cannot persist across a reboot
Explanation: When analyzing persistence mechanisms in Linux, the key distinction to understand is that systemd separates runtime state from boot-time configuration. These are two completely independent operations, and conflating them is exactly the trap this question sets. systemctl start launches a service immediately in the current session — nothing more. For a service to survive a reboot, it must be enabled via systemctl enable, which creates symlinks inside the appropriate target directory (in this case, /etc/systemd/system/multi-user.target.wants/). Since the intruder only ran start and never enable, no such symlink exists. When the system reboots, systemd reads its dependency graph fresh, finds no reference to sync-cache.service, and never launches it. Answer C is correct. A is wrong because dropping a unit file into /etc/systemd/system/ makes it available to systemd, not active or enabled. Placement alone creates zero automatic behavior. B is wrong because WantedBy=multi-user.target inside the [Install] section is declarative metadata — it tells systemctl enable where to create the symlink, but it does nothing until that enable command is actually executed. The [Install] section is inert until acted upon. D is wrong in the opposite direction: custom unit files in /etc/systemd/system/ can absolutely persist across reboots — but only when properly enabled. The issue here is process, not capability. Your study tip: memorize the phrase "start ≠ enable." On security exams, questions about attacker persistence often hinge on whether a malicious service was merely started or actually enabled into a target's dependency chain.

Question 3

An attacker adds the following entry to user devops's personal crontab: @reboot root /usr/local/bin/.sync. The file /usr/local/bin/.sync is executable, but there is no executable or shell function named root in the user's environment. The system later reboots, and the payload does not run.

Which explanation best accounts for the failed persistence?

  1. Personal crontabs do not support @reboot; only system-wide cron files support it
  2. Cron suppresses @reboot jobs when the referenced payload is stored under /usr/local
  3. The job requires an interactive login before cron can process a personal crontab
  4. The username field is inappropriate in a personal crontab and becomes part of the command (correct answer)
Explanation: When working with cron, one of the most important distinctions to understand is the structural difference between system-wide cron files and personal crontabs. System cron files (like /etc/crontab or files in /etc/cron.d/) include a username field that tells cron which user should execute the job. Personal crontabs — managed via crontab -e — do not have this field, because cron already knows to run them as the owning user. In this scenario, the attacker wrote @reboot root /usr/local/bin/.sync into the devops user's personal crontab. Because personal crontabs have no username field, cron parses the entire string after the time specification as the command to execute. That means cron attempts to run root as an executable — passing /usr/local/bin/.sync as its argument. Since no binary or shell function named root exists in the user's environment, the command fails silently. The payload never runs, and the attacker's persistence mechanism breaks. D is correct for exactly this reason. A is wrong because @reboot is fully supported in personal crontabs — it's a standard cron shorthand. B is fabricated; cron places no restrictions on payloads stored under /usr/local or any other directory path. C is wrong because cron is a background daemon that processes jobs without requiring an interactive login session. Study tip: Memorize the rule as a two-column table — system cron files have minute hour day month weekday **user** command; personal crontabs drop the user column entirely. Any extra word before the command becomes the command.

Question 4

On a Linux workstation using standard Bash behavior, an attacker appends a payload command to a user's .bashrc. Opening a terminal window executes the payload, but running ssh workstation.example command as that user does not. No distribution-specific startup hooks alter Bash's normal file-processing rules.

What is the most accurate interpretation of the persistence mechanism?

  1. The payload failed over SSH because .bashrc is processed only by privileged shells
  2. The payload is scoped to interactive Bash startup rather than every authentication event (correct answer)
  3. The payload is system-wide because .bashrc is processed before user identity is selected
  4. The payload is boot persistence because Bash reads .bashrc when the SSH daemon starts
Explanation: When analyzing persistence mechanisms on Linux, the key question to ask is: under what conditions does this file actually get sourced? Bash has distinct startup behaviors depending on whether a shell is interactive, non-interactive, login, or non-login — and mixing these up is exactly what this question tests. .bashrc is sourced by interactive non-login shells, which is what you get when you open a terminal emulator on a desktop. However, when you run ssh workstation.example command (a command passed directly to SSH), Bash launches as a non-interactive shell and deliberately skips .bashrc. That's why the payload fires when the user opens a terminal but stays silent over that SSH invocation — making B the correct interpretation. The persistence is scoped specifically to interactive Bash startup, not every authentication event. A is wrong because .bashrc has nothing to do with privilege level. It's sourced by interactive shells, not privileged ones — conflating these two concepts is a classic trap. C is completely backwards: .bashrc is a per-user file in the user's home directory, processed after authentication, not before user identity is established — it cannot affect other users. D misrepresents how SSH works entirely; the SSH daemon itself does not invoke Bash or read user dotfiles at startup. The daemon is a long-running service, and user shell environments are only constructed per-session. Study tip: Memorize the Bash startup file matrix — which files load for login vs. non-login, and interactive vs. non-interactive shells. Exam questions on persistence often hinge on exactly this distinction, so knowing when each file is sourced is more important than just knowing the files exist.

Question 5

During incident response, an analyst finds a new Windows service whose image path points to an unfamiliar executable. Its start type is automatic, it runs as LocalSystem, and its first recorded execution occurs before any user signs in. No corresponding scheduled-task definition is present.

Which interpretation of this evidence is most accurate?

  1. The executable persists through a machine-wide Run key processed before authentication
  2. The executable persists as an auto-start service launched during system startup (correct answer)
  3. The executable persists through a user Startup item launched by the shell
  4. The executable persists as a logon-triggered task running with elevated credentials
Explanation: When analyzing Windows persistence mechanisms, you need to match each technical clue to the correct persistence category. The key evidence here is threefold: a Windows service object, an automatic start type, and execution before any user logs in. That combination points unmistakably to one mechanism. Windows services are managed by the Service Control Manager (SCM), which launches automatic-start services during the boot/startup phase — before the login screen ever appears. This perfectly aligns with the scenario's timeline. The LocalSystem account further confirms this is a system-level, pre-authentication mechanism, not a user-context one. Answer B is correct because every detail — service object, automatic start, pre-logon execution — is the textbook fingerprint of a malicious auto-start service used for persistence. Answer A describes Run registry keys (e.g., HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run), which are processed by the Windows session manager after a user authenticates, not before. Even machine-wide Run keys fire post-logon, so the pre-authentication timing rules this out. Answer C describes user Startup folder items, which are launched by Explorer.exe as part of the user shell — inherently a post-logon, user-context mechanism, the opposite of what the evidence shows. Answer D describes a scheduled task with a logon trigger, but the passage explicitly states no scheduled-task definition exists, making this a direct contradiction of the given evidence. Your study tip: memorize the execution timeline for each persistence type — services fire during startup (pre-logon), Run keys and Startup items fire post-logon, and tasks depend on their configured trigger. Exam questions will deliberately mix these timelines to test whether you know the difference.

Question 6

A legitimate, digitally signed updater is started each morning by an existing scheduled task. The updater recently began loading an unsigned DLL from its writable application directory instead of the intended system DLL. Removing the unsigned DLL stops the malicious behavior, but the scheduled task continues to start the updater.

Which statement best characterizes the persistence chain?

  1. The unsigned DLL is independently persistent because DLL files execute automatically at startup
  2. The signed updater itself is malicious because signed programs cannot load unsigned libraries
  3. The scheduled task supplies the recurring trigger, while DLL side-loading executes the payload (correct answer)
  4. The DLL registration database supplies the trigger, while the scheduled task is incidental
Explanation: When analyzing malware persistence, train yourself to separate the trigger mechanism from the payload delivery mechanism — they are almost never the same component, and attackers deliberately layer them. In this scenario, two distinct techniques are chained together. The scheduled task runs every morning and launches the legitimate, signed updater — this is the recurring trigger that keeps the attack alive. The DLL side-loading is how the malicious code actually executes: because the updater searches its local writable directory before the system directory, the attacker plants an unsigned DLL there, and the updater loads it automatically. This is the classic DLL search-order hijacking/side-loading pattern. Answer C captures this precisely — the scheduled task provides the trigger, DLL side-loading delivers the payload. The fact that removing the DLL stops malicious behavior but the task keeps running confirms these are two separate, cooperating layers. Answer A is wrong because DLL files have no independent persistence mechanism. A DLL must be loaded by a running process — it cannot trigger itself at startup. Calling the DLL "independently persistent" fundamentally misunderstands how DLLs work. Answer B contains a false premise. Signed applications can absolutely load unsigned libraries; code-signing validates the signed binary's integrity, not the behavior of everything it subsequently loads. This is precisely what makes side-loading so effective against detection. Answer D invents a role for a "DLL registration database" that simply doesn't apply here. Nothing in the scenario involves COM registration or similar mechanisms — the scheduled task is clearly the trigger, not incidental. Your study tip: on persistence questions, always ask what starts the attack (trigger) and what carries the malicious code (payload) separately — they are rarely the same component.

Question 7

An organization completely replaces an endpoint's internal drive and performs a clean operating-system installation from trusted media. Soon afterward, the same unauthorized network callback resumes. Boot instrumentation indicates that unfamiliar code executes before the new operating system's boot loader, and no external peripherals remain attached.

Which persistence mechanism most strongly fits the evidence?

  1. A malicious operating-system driver restored by the clean installation process
  2. A modified boot loader remaining in a partition on the replaced internal drive
  3. A compromised local account recreated automatically from the former system registry
  4. A firmware implant executing from the endpoint's UEFI or other platform firmware (correct answer)
Explanation: When troubleshooting persistent malware, you need to mentally layer a system from hardware upward: firmware → bootloader → OS → applications. The key diagnostic clue here is that code executes before the new OS boot loader — meaning the threat lives below the OS layer entirely. That evidence points directly to D, a firmware implant in UEFI or platform firmware. UEFI firmware initializes hardware before any OS component loads, and critically, it survives drive replacements because it resides on a dedicated flash chip soldered to the motherboard — not on the internal drive. Replacing the drive eliminates everything on that storage medium but leaves the firmware untouched, explaining why the callback resumes on a clean system. A is wrong because OS drivers are stored on the internal drive, which was fully replaced. A driver from the old installation cannot survive that process. B falls apart for the same reason — a modified boot loader lives in a partition on the internal drive, which was replaced. Once that drive is gone, so is any modified boot loader. C involves registry-based account recreation, but the registry also lives on the internal drive, and no external peripherals are mentioned that could re-introduce old registry hives. A key trap in this question is assuming "clean OS install" means "clean system." It doesn't — firmware exists outside the OS's reach entirely. On exams, whenever you see persistence that survives complete drive replacement and triggers before the OS loads, immediately think firmware/UEFI implant. That below-OS execution timing is your signature indicator.

Question 8

A macOS endpoint contains a newly created property-list file in /Library/LaunchAgents/. The file specifies RunAtLoad and launches an unknown binary. The binary appears after a user begins a graphical session, but it is absent during the pre-login portion of startup.

Which assessment best matches this persistence behavior?

  1. It is a LaunchAgent intended to execute within a user login session (correct answer)
  2. It is a LaunchDaemon intended to execute before any user logs in
  3. It is a login item that must be stored inside the user's home directory
  4. It is a kernel extension that loads before the graphical environment starts
Explanation: When analyzing macOS persistence mechanisms, the key distinction lies in where the file lives and when the process launches relative to user login. macOS separates persistence into two primary launch service types: LaunchAgents and LaunchDaemons. LaunchAgents run in the context of a logged-in user session — they activate after a user authenticates and a graphical session begins. LaunchDaemons, by contrast, run as root-level processes during system boot, before any user logs in. The clue in this scenario is the file's location (/Library/LaunchAgents/) combined with the binary appearing only after a graphical session starts — both fingerprints of a LaunchAgent. The RunAtLoad key simply means it executes immediately when loaded, which doesn't change the classification. Answer A is correct. Answer B is wrong because LaunchDaemons live in /Library/LaunchDaemons/, not /Library/LaunchAgents/, and they execute before any user session exists — the opposite of what the passage describes. Answer C is incorrect because login items stored in a user's home directory (e.g., ~/Library/LaunchAgents/) are user-scoped, whereas /Library/LaunchAgents/ is system-wide and applies to all users; also, "login items" in the modern macOS sense are a distinct mechanism from property-list launch services entirely. Answer D is wrong because kernel extensions (.kext files) load at the kernel level during early boot, long before any graphical environment or user session — nothing in this scenario matches that profile. Your study tip: memorize the directory-to-behavior mapping. /Library/LaunchDaemons/ → pre-login, system-level; /Library/LaunchAgents/ → post-login, user session. The path alone often gives away the answer.

Question 9

A Windows process launches after successful network logons, including logons that create no interactive desktop. Investigators find no new service, Run key, or Startup-folder entry. Task Scheduler logs show an action beginning immediately after each relevant Security log event.

Which mechanism best explains how the process is being persistently triggered?

  1. A scheduled task using an event-log trigger for successful authentication events (correct answer)
  2. A per-user Startup-folder shortcut activated by Explorer during interactive sign-in
  3. A Winlogon shell modification activated whenever a desktop session is created
  4. An automatic Windows service restarted through service-recovery configuration
Explanation: When investigating persistence mechanisms in Windows, you need to match three clues simultaneously: what triggers the process, when it fires, and what forensic artifacts are absent. The passage gives you all three — network logons (including non-interactive ones), Task Scheduler log entries appearing immediately after Security log events, and no service, Run key, or Startup folder evidence. This fingerprint points directly to A, a scheduled task using an event-log trigger. Windows Task Scheduler supports triggers tied to specific Event Log entries — in this case, Security Event ID 4624 (successful logon). Because the task fires on any successful network logon, it activates even without an interactive desktop session, which explains the non-interactive behavior. The Task Scheduler operational log recording activity right after Security log events is the smoking gun confirming this mechanism. The distractors each fail on at least one clue. B is wrong because Startup-folder shortcuts are activated by Explorer.exe, which only launches during interactive desktop sessions — the passage explicitly says non-interactive logons trigger the process, ruling this out. C, a Winlogon shell modification, also requires an interactive session with a desktop being created; non-interactive network logons never reach that code path. D, a service with recovery options, would require a prior service installation, and investigators would find a service entry — the passage tells you none exists. As a study tip, remember that event-log triggers are a stealthy persistence technique precisely because defenders often focus on Run keys and services. On exam questions, when you see "Task Scheduler logs" correlated with "Security log events," that combination almost always signals an event-triggered scheduled task.

Question 10

An analyst examining the WMI repository finds a permanent event filter that queries for system-startup conditions. No command-line event consumer, script event consumer, or filter-to-consumer binding can be located. Reboots do not produce the suspected malicious process.

What is the best conclusion about the discovered WMI artifact?

  1. The filter is sufficient for persistence because WMI executes the query text as a command
  2. The filter persists only until reboot because permanent WMI filters are memory-resident
  3. The filter launches any executable referenced by the event without requiring a consumer
  4. The filter alone is insufficient because an event consumer and binding are also required (correct answer)
Explanation: When analyzing WMI-based persistence, you need to think in terms of a three-part chain: an event filter (the trigger), an event consumer (the action), and a filter-to-consumer binding (the link connecting them). All three components must exist and be properly bound for WMI to execute anything in response to an event. This question tests whether you understand that architecture — and recognize what's missing. The scenario describes a startup-condition filter with no consumer and no binding. That means even though the filter "watches" for the startup event, there is nothing registered to act on it and no binding to route the event anywhere. The system fires, the filter detects the condition, and then nothing happens — exactly as the passage confirms when it notes that reboots don't produce the malicious process. D is correct: the filter alone is insufficient because the consumer and binding are both absent. A reflects a fundamental misconception — WMI does not execute query text as a command. The filter is written in WQL (WMI Query Language) to detect events, not to run code. B is wrong because permanent WMI subscriptions are stored in the WMI repository on disk and survive reboots — they are explicitly not memory-resident. This is what makes them useful for persistence in the first place. C is incorrect for the same reason as A; a filter has no inherent execution capability. Only a consumer (specifically a CommandLineEventConsumer or ActiveScriptEventConsumer) performs actions. As a study tip, always audit all three WMI persistence components together — finding one without the others means the mechanism is broken or only partially deployed.