Malware practice questions

Worm

Why wrong: A worm is standalone malware that self-replicates and spreads across networks automatically, typically exploiting software vulnerabilities or using shared credentials, without requiring user interaction. The scenario lacks evidence of such autonomous network propagation; the malware spreads through a deceptive installer that tricks the user into executing it. Even if the downloaded utility later led to worm-like behavior, the initial delivery vector is a trojanized application, and the core mechanism is social engineering, not self-replication.

Spyware

Why wrong: Spyware is a category of malware that covertly monitors user activity, such as keystroke logging, screenshots, or data exfiltration, and typically operates quietly after installation. While a trojan can certainly deliver spyware as its payload, the scenario emphasizes the disguised installer and security tampering—the latter of which goes beyond passive information gathering. Spyware focuses on the collection of sensitive data, whereas a trojan describes the deceptive delivery method that enables arbitrary malicious behavior, which is the central clue in this question.

Rootkit

Why wrong: A rootkit is a stealth tool focused on hiding successful compromise at the kernel or OS level—concealing processes, files, and registry keys from administrators. In this scenario, the primary infection vector is a user downloading and running a fake utility, not the post-infiltration concealment that a rootkit provides. A rootkit could be a payload delivered by a trojan, but the initial malicious delivery mechanism here is the disguised installer, making 'trojan' the accurate classification.

Worm

Why wrong: A worm is a type of malware that self-replicates and autonomously propagates across networks, often by exploiting vulnerabilities or using built-in spreading mechanisms. In this scenario, there is no mention of the malware copying itself to other hosts or traversing the local network; the symptoms are confined to a single infected laptop. The original infection vector—a deceptive free utility—is a hallmark of a trojan, not a worm. Since the malware lacks the ability to move laterally or self-distribute, it does not qualify as a worm.

Rootkit

Why wrong: A rootkit is designed to hide its own presence and maintain privileged, stealthy access by intercepting operating system APIs, modifying kernel data structures, or replacing system tools. The visible symptoms described—browser homepage changes, persistence, and communication with an unknown server—are user-observable and disruptive, which contradicts the stealth-oriented nature of a rootkit. While a trojan could later install a rootkit as a secondary payload to conceal itself, the primary behavior in this scenario aligns with the trojan's deceptive delivery and payload symptoms. Without evidence of OS-level concealment or kernel-level manipulation, rootkit is not the correct classification.

Ransomware

Why wrong: Ransomware is defined by its method of extorting money: it typically encrypts user files or locks the entire screen, then demands payment to restore access. In this scenario, there is no indication of file encryption, a lockout screen, or a ransom note, so the attack's motive does not appear to be data destruction or denial of access. The symptoms—browser hijacking, persistence, and beaconing to an unknown server—point to a trojan that may be exfiltrating data or enabling remote access. While a trojan can serve as a delivery vector for ransomware, the absence of any encryption or ransom demand makes that classification unsupported here.

Vishing, because the attacker is using a voice call to pressure the user

Why wrong: Vishing uses a phone call or voice channel, not a text message with a link.

Baiting, because the attacker is offering a free service upgrade

Why wrong: Baiting usually relies on a tempting lure, while this message uses urgency and account fear.

Tailgating, because the attacker is trying to enter a building behind someone else

Why wrong: Tailgating is a physical access attack and has nothing to do with SMS messages.

Normal software update check

Why wrong: Incorrect. While some software updates use periodic checks, they usually occur at less regular intervals, often with randomized delays to avoid server load, and the data transferred is typically larger (e.g., update manifests or actual patches). The extremely consistent timing and small size are more indicative of beaconing.

DNS tunneling

Why wrong: Incorrect. DNS tunneling exfiltrates data by encoding it in DNS queries, which use UDP port 53 (or sometimes TCP port 53). The traffic described is over TCP port 443 (HTTPS), not DNS, so this pattern does not match DNS tunneling.

Data exfiltration via HTTPS

Why wrong: Incorrect. Data exfiltration via HTTPS typically involves transferring larger volumes of data in a single session or over a shorter period. The steady 1 KB every 5 minutes would take an extremely long time to exfiltrate significant data, making this pattern unlikely for exfiltration. Beaconing is far more probable.

Worm, because the host is making outbound connections to a remote system.

Why wrong: Outbound connections to a remote IP address are a generic indicator of many malicious behaviors, but they do not define a worm. Worms are characterized by autonomous self-replication and lateral movement across systems, typically by exploiting network vulnerabilities or copying themselves to other hosts. Here, there is no evidence of scanning, propagation, or other hosts being affected, so calling this a worm is unjustified.

Spyware, because the host is communicating with an external IP address.

Why wrong: Spyware is typically installed as a persistent file on the system and then performs surveillance or data exfiltration. The strongest clues in this alert are the encoded script and the use of mshta.exe, which indicate in-memory execution rather than a dropped spyware payload. Communicating with an external IP is common to both spyware and fileless malware, but the absence of a disk-resident component points away from classic spyware behavior.

Rootkit, because the system tools are being hidden from the user.

Why wrong: A rootkit's defining characteristic is concealing itself and other malicious objects, often by hooking OS calls or modifying system structures so that files, processes, or network connections remain hidden. In this scenario, the evidence shows script-based execution and network communication, but nothing suggests that system tools are being hidden or that any stealth mechanism is active. The abuse of PowerShell and mshta.exe is a fileless attack pattern, not a rootkit's hiding technique.

Immediately power off the workstation to stop any malicious activity.

Why wrong: Powering off a live system is an anti-forensic action: it destroys the very volatile evidence that incident responders need, such as RAM-resident malware, injected code, active network sockets, and running processes. Memory forensics can often reveal command-and-control activity, encryption keys, and process hollowing that would be permanently lost. The proper first step is to capture a memory image and record running processes, then follow an established order of volatility before any shutdown.

Run a full antivirus scan before documenting anything.

Why wrong: Running a full antivirus scan on a suspicious live system alters the evidentiary state: the scan updates timestamps, quarantines or deletes files, and may trigger malware defenses that wipe artifacts or connect to an attacker. Moreover, modern malware can evade signature-based scanning while in memory, giving a false sense of security. Preservation must happen first—through memory and disk imaging—before any remediation tool touches the system.

Delete temporary files to reduce the chance of reinfection.

Why wrong: Deleting temporary files at this stage destroys potential evidence such as dropped payloads, credential-stealing logs, or staged malware that may reside in temp directories. The action also changes file system metadata and can delete the very indicators of compromise needed to determine the infection vector. Containment via network isolation should come first, and any cleanup must wait until forensic copies are made and the investigation is complete.

Worm

Why wrong: A worm is a self-contained malicious program that replicates and spreads to other systems automatically, typically by exploiting network services, email, or removable media. The exhibit depicts a scheduled task that launches a destructive script only when a specific date and username match, with no apparent propagation or network-spreading functionality. Since the artifact lacks any self-replication or lateral movement mechanism, it does not qualify as worm behavior.

Spyware

Why wrong: Spyware is designed to covertly monitor user activity and collect sensitive data such as keystrokes, browsing habits, credentials, or screen captures, usually for exfiltration to an attacker. The exhibited script is instead a destructive payload that deletes user files once its logical trigger conditions are met; there is no indication of data gathering, keystroke logging, or a communication channel to transmit stolen information. Thus, the behavior aligns with a logic bomb rather than spyware.

Rootkit

Why wrong: A rootkit is a stealth mechanism that provides an attacker with continued privileged access by hiding files, processes, or registry keys, often by hooking or patching operating system internals. The evidence in the exhibit focuses on a timing- and username-based condition that, when satisfied, deletes files—not on concealment of malicious artifacts or escalation of privilege. While a logic bomb can be combined with rootkit techniques, the exhibit's trigger-based destruction is the defining characteristic, so rootkit is not the most likely classification.

Trojan, because the attack requires a disguised program to install itself.

Why wrong: A trojan is a delivery mechanism that disguises itself as a benign application to trick a user into running it; it is a distribution vector, not the observed behavior itself. While a trojan could drop ransomware, the visible symptom of files being renamed with a new extension and locked points decisively to the ransomware payload, not to the trojan's deception. Without evidence of a disguised executable or user-invoked installer, the classification is based on the end-state behavior: data encryption and a ransom demand.

Spyware, because the attacker is likely trying to monitor file activity.

Why wrong: Spyware operates under an entirely different set of objectives: it quietly monitors keystrokes, screenshots, browsing habits, or credentials, and exfiltrates that data to a remote attacker, all while leaving existing files intact. Renaming files and adding a new extension indicates destructive or coercive modification of data, which spyware avoids to maintain stealth and persistence. The presence of a ransom-style attack signature—locked files plus an extortion demand—contradicts the passive, collection-focused nature of spyware.

Logic bomb, because the malware likely triggered after a specific condition was met.

Why wrong: A logic bomb is a piece of code that lies dormant until a specific condition or trigger, such as a date, a user action, or an internal counter, causes it to execute; however, the trigger alone does not define the malware's primary effect. In this scenario, the key indicator is not the timing or condition but the outcome: files are encrypted, renamed, and a ransom note appears—classic extortion behavior. Even if the ransomware was conditionally triggered, the correct classification is the payload family, ransomware, not the triggering mechanism.

Worm behavior, because the malware is automatically spreading across the network.

Why wrong: Worm behavior requires self-replication and active propagation across network hosts, typically via OS or application vulnerabilities. The EDR alert shows no evidence of scanning, lateral movement, or worm-like spread; it describes a localized PowerShell process with encoded arguments and a registry run key, which are classic fileless execution and persistence indicators.

Rootkit behavior, because the attacker is hiding from the operating system at a low level.

Why wrong: Rootkits operate at kernel or privileged layers to hide malware artifacts from the OS, often by hooking system calls or patching boot components. The alert's evidence points to user-mode PowerShell script execution and registry-based persistence, not kernel-level stealth, so mislabeling this as rootkit behavior overlooks the actual in-memory, living-off-the-land technique.

Spyware, because the malware is using HTTPS traffic to contact an external domain.

Why wrong: Spyware is specifically designed to covertly gather user information, such as keystrokes, screenshots, or browsing habits, and exfiltrate it. Although outbound HTTPS to an external domain could be consistent with spyware, the encoded PowerShell and registry persistence are far more precise indicators of a fileless attack, and the alert does not mention any data collection or exfiltration functionality.

Trojan, because the malware may have been disguised as a legitimate application.

Why wrong: A Trojan is a delivery category that describes malware tricking a user into running it, not a set of observable post-infection effects. Here the hard evidence—file encryption with random extensions, a ransom note, and deliberately purged shadow copies—directly matches the defined behavior of ransomware. While a trojan could absolutely be the initial vector that dropped this payload, the question asks which type of malware the symptoms identify, and those symptoms are the signature of ransomware extortion, not just deception.

Worm, because the malware likely spread automatically to other systems.

Why wrong: Worms are fundamentally self-propagating malware that spreads autonomously across hosts via network services, email, or removable drives. The scenario gives no indication of lateral movement, automated replication, or other systems being affected—it only describes files on the local workstation being encrypted. Even though some ransomware families have worm-like spreading components, the core classification here is driven by the encryption-and-payment demand, not by any observed ability to move from system to system on its own.

Rootkit, because the attacker would want to hide persistence on the system.

Why wrong: A rootkit is designed for stealth and persistent concealment, typically hooking operating system internals to hide processes, files, or registry keys from detection. Encrypting thousands of user files and dropping a ransom note is the opposite of stealthy behavior because it creates immediate, visible business impact and alerts the user to the compromise. The deletion of shadow copies is meant to block recovery and increase extortion pressure, not to hide the attacker's presence—so the evidence points to ransomware's denial-of-access tactic rather than rootkit-style covert access.

Assume the traffic is benign because it happens on a fixed schedule.

Why wrong: A fixed schedule is not a reliable indicator of legitimacy; many malware families use periodic beaconing to evade detection and maintain C2 channels. Security analysts must validate the source process, destination, and signature before dismissing the alert, rather than relying solely on timing patterns.

Suppress all alerts from the host permanently after this one event.

Why wrong: Permanently suppressing alerts for a host after a single event eliminates visibility and may mask subsequent malicious activity, especially if the original alert was actually a false negative. Tuning should be minimal and evidence-based—ideally scoped to the specific process or destination—and should never be based on a one-time assumption that no further investigation is needed.

Stop collecting logs from the server so the same alert does not recur.

Why wrong: Disabling log collection on the server is disruptive and degrades the security posture, making it harder to perform incident response or retrospectively analyze behavior. Instead of preventing future alerts, the analyst should validate the current alert and, if warranted, adjust the rule with a specific exception that still retains the log data for auditing.

Worm behavior that is spreading through SMB shares

Why wrong: Worms self-replicate by exploiting network services such as SMB (e.g., EternalBlue/MS17-010) and automatically copying their payload to remote hosts. The alert shows a single workstation running PowerShell that fetches and executes code in memory; there is no observed propagation to other systems, no SMB-specific network connections, and no creation of file shares or service requests. Therefore, the behavior is isolated and does not match the lateral-spreading signature of a worm.

Rootkit that is hiding itself by modifying kernel drivers

Why wrong: Rootkits are designed to actively conceal their presence, often by loading a kernel driver that hooks system calls, filters device I/O, or manipulates kernel objects via DKOM to hide processes, files, and registry keys. Nothing in this alert indicates kernel-level tampering, no suspicious driver is loaded, and the activity is visible as userland PowerShell and rundll32 processes fetching remote content into memory. A rootkit would prioritize stealth and persistence after reboot, whereas this behavior disappears after reboot and shows no evidence of driver installation.

Trojan that can only run after a user manually opens a malicious attachment

Why wrong: While a trojan often arrives via a malicious attachment, it normally drops or installs a standalone executable or script file onto disk, and running it typically requires explicit user interaction such as double-clicking an attached binary. This alert shows PowerShell downloading and executing code directly in memory with no on-disk payload, which is characteristic of a fileless or script-based attack rather than a classic trojan. Moreover, the alert does not specify that a user opened an attachment; the initial vector is just as likely to be a malicious macro, a URL, or a scripted exploit.

Wait for more alerts before taking any action to avoid disrupting the user

Why wrong: Adopting a passive wait-and-see posture is dangerous because the EDR alert already indicates a potential compromise. Each minute the workstation remains on the network allows an adversary to install persistence, move laterally, or exfiltrate sensitive data. Incident response principles require immediate containment upon a validated alert, not waiting for more alerts, which would only expand the scope of the incident and increase remediation costs.

Immediately reinstall the operating system without collecting evidence

Why wrong: Reinstalling the OS without collecting forensic evidence destroys the very artifacts needed to determine the root cause and scope of the intrusion. Memory dumps, disk images, logs, and prefetch files may reveal the initial access vector, attacker tools, and lateral movement techniques. Early reimaging also fails to address threats like firmware implants that survive reinstallation, and it forfeits the opportunity for intelligence to improve defenses and prevent future incidents.

Disable the user's account in the directory service and close the ticket

Why wrong: Disabling the user account in the directory service only prevents future interactive logons but has no effect on a malicious process already running under that user's context. It does not terminate the process, block the host's network communications, or remove persistence mechanisms, so the compromise remains active. Closing the ticket prematurely also ignores the need for endpoint containment and forensic investigation, leaving other systems at risk.

Wait for another alert before taking any action.

Why wrong: Taking a passive posture after an EDR alert is operationally unsafe because the suspicious process remains active and may be conducting reconnaissance, credential harvesting, or data exfiltration in real time. EDR telemetry is intended to trigger immediate investigation and containment, not to wait for corroborating alerts that may only confirm damage already done. Each minute of delay increases the window for lateral movement to critical assets, and the absence of a second alert does not imply the absence of malicious activity.

Delete the word processor immediately.

Why wrong: Deleting the word processor is a destructive recovery action, not a containment action, and it eliminates the very binary, configuration files, and logs in the application data folders that would reveal how the process was exploited or abused. It also fails to stop an already-injected malicious thread or fileless payload that lives in memory, meaning the active threat can persist even after the file is removed. Furthermore, immediate deletion can trigger tampering indicators, complicate chain-of-custody, and remove evidence needed to attribute the attack or recover legitimate files that the malware may have been using.

Reboot the workstation to see if the behavior happens again.

Why wrong: Rebooting the workstation clears volatile memory, which is exactly where malware execution details—such as injected code, decrypted payloads, and active network connections—reside, leaving responders with only disk evidence that may be incomplete or obfuscated. It also does not address persistence mechanisms already present in the registry or startup folders, so the malicious process can simply relaunch on the next boot, making the behavior appear to 'stop' while the compromise remains. This approach sacrifices forensic integrity and fails to contain any ongoing network-based threat, violating the fundamental IR priority to preserve evidence while reducing impact.

A macro virus that only runs when a document is opened.

Why wrong: A macro virus is embedded in Office documents and only executes after a user opens the file and enables content, usually via a social-engineering prompt. This scenario's observed chain begins with a legitimate browser process spawning child processes, not with a document-opening action. Furthermore, macro viruses typically drop a binary payload to disk or run VBA directly, whereas the browser-to-PowerShell pattern with encoded commands is a hallmark of fileless malware operating entirely in memory.

A boot sector virus that persists by altering startup code.

Why wrong: A boot sector virus resides in the master boot record or volume boot record and runs during the pre-OS boot phase, modifying startup code to persist and gain control on every reboot. This type of infection is installed via physical media or low-level writes, not via browser-initiated scripts or outbound web connections, and it would not cause an immediate browser-to-PowerShell process chain during triage. The absence of disk-level persistence and the presence of memory-resident scripting indicate an active runtime exploit, not a boot-time infection.

A logic bomb that activates only when a specific date or event is reached.

Why wrong: A logic bomb is malicious code that remains dormant until a specific condition is met, such as a date, time, or event (e.g., a user accessing a particular file). The activity observed during triage is already actively occurring, with a browser process spawning child processes, so the malware is not waiting for a trigger. Logic bombs are typically hidden inside legitimate applications or scripts and are not associated with the immediate, interactive execution pattern seen here. The memory-resident, script-based execution is consistent with fileless malware that runs its payload as soon as it is delivered.

The daily domain names, because they are the easiest items to collect.

Why wrong: While domains can be collected quickly from a sandbox or DNS logs, they are designed to be transient: adversaries use fast-flux techniques, short TTLs, and domain generation algorithms (DGAs) to rotate them constantly. This volatility makes them unreliable for long-term detection because by the time a blocklist is updated, the next domain may already be in use for the same campaign. The ease of collection does not translate into detection value when the indicator changes faster than your response cycle.

The cloud provider name, because the attacker uses disposable infrastructure.

Why wrong: The cloud provider name is a broad attribution attribute, not a precise indicator. Tens of thousands of legitimate organizations and unrelated malicious actors share the same IP address ranges, so blocking by provider would cause massive collateral damage and not distinguish this campaign. Even if the attacker uses disposable cloud infrastructure, the provider is not unique to them, and the specific IP or account would be far more relevant; the provider alone offers no actionable detection signal.

The time of day the campaign was observed, because the attacker is consistent.

Why wrong: Time-of-day patterns are behavioral context, not a unique artifact. Malware execution can be scheduled, manually triggered across time zones, or run on compromised hosts in different locales, so the observed time is not a stable or unique property of this attack. Even if a pattern appears consistent, it is not searchable like a file hash and cannot be used to block or detect the sample on an endpoint, making it a weak indicator at best.

Reboot immediately to prevent any further damage from the suspected malware.

Why wrong: Rebooting the system prematurely is a common but destructive reaction: it clears RAM, kills active processes, and resets kernel objects, which can destroy the only copies of malware payloads, in-memory encryption keys, or command-and-control channel state. Volatile data such as the ARP cache, active TCP connections, and process arguments exist only in memory and vanish instantly with a restart. Instead of containing the threat, a reboot gives persistent malware a fresh start to hide or escalate, and it forfeits the primary evidence needed to determine the infection's origin and scope.

Copy suspicious files to a shared drive and continue normal operations.

Why wrong: Copying suspicious files to a shared drive contaminates the evidence chain by changing file system metadata (creation, modified, and access timestamps) and may inadvertently spread the infection if the share is reachable by other hosts. This approach also keeps the affected system running, allowing malware to continue network communication, credential theft, or lateral movement while the analyst works. A proper response requires a forensically sound bit-for-bit image to an isolated storage device, preserving metadata and avoiding network exposure.

Run a full disk cleanup to remove temporary files and reduce risk.

Why wrong: Running a full disk cleanup on a potentially compromised finance workstation is an anti-forensic act: it deliberately deletes temporary folders, prefetch files, browser caches, and thumbnails that frequently contain the initial infection vector, attacker tooling, or signs of data staging. Utilities like Disk Cleanup also perform write operations across the filesystem, altering modification times and overwriting unallocated space where deleted artifacts may reside. This destroys the very remnants that a malware investigation depends on to establish a timeline, identify the malware, and recover stolen data.

Install endpoint protection updates on the laptop right away.

Why wrong: Installing endpoint protection updates modifies the live system by writing new files, altering registry keys, and running update processes, all of which can overwrite or destroy volatile evidence that is critical to the investigation. It also requires network activity and may trigger the malware to change its behavior or delete its traces, reducing the chances of recovering an accurate picture of the infection. Furthermore, signature-based updates are unlikely to detect a novel or polymorphic threat and do nothing to preserve the running processes, memory contents, and network connections that are needed for analysis.

Delete suspicious files so the malware can no longer spread.

Why wrong: Deleting suspicious files removes the primary physical evidence needed for static analysis (e.g., binary reverse engineering, string extraction, hash correlation) and can permanently destroy the only copy of the malware. Your action may also miss persistence mechanisms—such as registry Run keys, scheduled tasks, services, or WMI subscriptions—so the malware could re-infect the host immediately after the deletion. Additionally, in a live system, deleting files alters file system metadata (timestamps, journal entries) and could trigger the malware's anti-forensics routines that erase logs or corrupt other artifacts, making the overall incident analysis less complete and less defensible.

Reboot the laptop immediately to clear the suspected malware.

Why wrong: Rebooting the laptop forcibly terminates all running processes and clears volatile memory (RAM), which is often the richest source of evidence about active malware, including injected code, decrypted payloads, and command-and-control communication details. This action also drops live network connections, loses the contents of temporary files and open handles, and may trigger the malware's persistence or cleanup routines to execute during shutdown—all of which can destroy evidence that would otherwise be captured. Rebooting should be postponed until after memory and other volatile data have been collected; otherwise, the investigator permanently loses the most time-sensitive artifacts, making it much harder to determine the scope and impact of the incident.

Ignore the alert because SMB is a normal file-sharing protocol

Why wrong: Although SMB is a legitimate protocol for file sharing, a single workstation rapidly connecting to many internal hosts and repeatedly accessing administrative shares such as C$ or ADMIN$ is not normal baseline behavior. This pattern is strongly associated with worm-like propagation or lateral movement, especially when SMB is used to execute remote services via PsExec. Discounting the alert solely because SMB is common ignores the statistical and behavioral anomalies that triggered the SIEM threshold. The correct response is to treat this as a potential compromise indicator rather than benign file access.

Increase the workstation's monitor brightness to help the user notice alerts

Why wrong: Adjusting the monitor brightness is completely unrelated to the SIEM alert or the suspicious network activity; it neither prevents the workstation from initiating connections nor reduces risk. The alert is being processed by security analysts, not necessarily the user, so visual changes to the display have no effect on detection or response. This option is a distraction that fails to address the need for network-level containment and could waste valuable time during an active incident. Physical changes to the endpoint do not stop SMB scanning or lateral movement.

Disable all SMB traffic across the entire company immediately

Why wrong: Prohibiting all SMB traffic company-wide is an overly disruptive measure that would likely break legitimate file sharing, printing, and domain operations for hundreds of users, while the actual compromise may be limited to one host. Such a blanket action violates the principle of least privilege and proportional response, and it may even slow down incident response by harming business continuity. A better approach is to block SMB at the affected workstation or enforce segmentation only for that subnet, then confirm scope via SIEM and endpoint logs. Broadly disabling SMB before investigation can destroy evidence or trigger unintended zero-day disruptions.

Trojan downloader

Why wrong: A trojan downloader relies on a deceptive executable or installer to run on the victim's machine, then reaches out to a command-and-control server to fetch additional malicious files. In this alert, the only observed action is PowerShell launched by a scheduled task, with no indication of a malicious file being dropped or executed first. While PowerShell could be used to download payloads, the signature here points to an in-memory, fileless technique rather than a binary-based trojan.

Rootkit

Why wrong: A rootkit is malware engineering focused on stealth and persistence, typically installing kernel drivers or hooks to hide processes, files, and registry keys from the operating system. The observed event does not indicate any attempt to conceal itself or modify the OS kernel; rather, it shows a visible PowerShell process launched by the scheduler. Rootkits also usually require elevated privileges to install deep components, which is not suggested by this alert, making the fileless malware explanation more appropriate.

Worm

Why wrong: Worms are characterized by self-replication and autonomous network propagation, often exploiting vulnerabilities to spread without user intervention. The EDR alert shows a single scheduled task launching PowerShell on one host, with no evidence of lateral movement, high network traffic, or multiple affected endpoints. Without any indication of self-propagation or network-based replication, classifying this as a worm contradicts the observed data.