A school-district forensics note lists new scheduled tasks and HKCU Run keys on a compromised lab host. Which malware fundamental do those findings primarily demonstrate?

Persistence mechanisms keep malicious code active across restarts, logoffs, or new sessions so the adversary does not depend on the user reopening the original lure. A school-district forensics note listing new scheduled tasks and HKCU Run keys on a compromised lab host primarily demonstrates common Windows persistence: both artifacts are classic autorun-style stay-behind techniques municipal analysts see on endpoints. Mapping findings to persistence clarifies eradication—removing the malware binary alone is insufficient if scheduled tasks or Run keys will relaunch it after reboot.

Initial phishing lure content stored only in webmail drafts fails because that addresses delivery content in mail, not host autorun artifacts discovered on the lab machine. Network enumeration of student-portal open ports fails because enumeration maps services and attack surface; it is not what scheduled tasks and Run keys represent. Prompt engineering used to draft awareness emails fails as a malware fundamental; writing training emails is awareness work, not an endpoint persistence mechanism.

Exam caveat: GOAA expects you to map observed Windows artifacts to the correct fundamental (persistence vs delivery vs scanning). Presence of persistence does not by itself prove which payload objective will follow.

Operational check for school-district IR: export and review the new scheduled tasks and Run key values, identify the launched binaries/scripts, remove persistence entries and payloads under change control, reboot and re-verify autoruns, and hunt peer lab hosts for the same task names, Run values, or hashes before reconnecting the host to student networks.