OS and Network Forensics practice questions

A successful user logon

Why wrong: A successful user logon is a distinct security event that corresponds to Event ID 4624, not 4625. The 4624 event is written only after a user is granted a logon session, indicating success with fields like logon type (interactive, network), authentication package, and the logged-on user's SID. Because 4625 explicitly represents authentication failure, the presence of this ID cannot be interpreted as a successful logon.

A service was installed

Why wrong: Event ID 7045 is a System log entry that denotes the installation of a new service on the Windows host, including the service name, binary image path, and startup type. Unlike 4625, which lives in the Security log and tracks authentication attempts, 7045 is a system-level configuration event and has no relation to logons or failed credentials. Therefore, the 4625 event cannot represent a service installation.

A new user account was created

Why wrong: A new user account being created in Active Directory or on the local SAM is logged as Event ID 4720 in the Security log, which belongs to the account management (Audit User Account Management) category. This event records the creator, the created username, and other attributes but does not reflect any authentication attempt. Since 4625 is an authentication failure event, it is not consistent with account creation activity.

/var/log/syslog

Why wrong: /var/log/syslog records kernel, daemon, and system-level messages, but it does not capture interactive shell commands by default. While syslog can be configured to log certain events like sudo or authentication, it lacks the per-user command history of each bash session. Thus it is an unreliable source for a complete command history.

/proc/1/cmdline

Why wrong: /proc/1/cmdline is a pseudo-file that exposes the initial command line arguments of process ID 1, typically the init system like systemd or SysV init. It is a live snapshot of a single process, not a historical log of user commands. Reading it only shows how the kernel started the first process, not what users typed later.

/etc/shadow

Why wrong: /etc/shadow is a root-only-readable file that stores hashed user passwords and password aging policy, not command history. It exists to manage authentication and is protected to prevent unauthorized password hash disclosure. Its content has no bearing on what commands were executed in a shell session.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

Why wrong: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB exposes PnP device nodes for every USB device and hub that has ever been enumerated on the system, organized by VID/PID and instance ID. While it confirms that a particular USB peripheral was present, its values are hardware identifiers and configuration data, not forensic timestamps — there is no first connection or install date stored in this key. It may show the parent hub or ContainerID, but it cannot answer when the device was first plugged in, so it is not the correct source.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

Why wrong: The DeviceClasses key with GUID {53f56307-b6bf-11d0-94f2-00a0c91efb8b} represents the storage volume device-interface class, which Windows uses to surface volume symbolic links such as \\?\\Volume{GUID}. This key shows that a storage volume (which could be a partition on a USB drive or an internal hard disk) was exposed to user-mode applications, but it does not record the time the USB device was first attached. Because this GUID applies equally to fixed internal disks, it is neither USB-specific nor a first-connection timestamp source.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Why wrong: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 stores per-user, MRU-style mount point mappings for volumes the logged-in user has accessed, including entries that reference USBSTOR device paths. However, the timestamps visible in this hive are the LastWrite times of the mount point keys, reflecting when that specific user mounted or accessed the volume, not when the device was first connected system-wide. It can indicate user awareness or use of a USB volume in a user profile, but it cannot supply the device's first-connection timestamp and is therefore incorrect.

4624

Why wrong: Event ID 4624 logs every successful authentication to the host, including interactive, network, and remote logons. Web shells typically execute within the existing web server process (e.g., w3wp.exe) and do not initiate a distinct logon session; they run under the web application pool's identity. Hence, 4624 is too generic and not a specific or reliable artifact of web shell usage.

4648

Why wrong: Event ID 4648 records explicit credential logon attempts where a user supplies alternate credentials via RunAs or credential delegation. A web shell operates by receiving HTTP requests and executing commands under the already-authenticated web server context, without invoking any separate credential validation. Therefore, 4648 is not generated by web shell activity and instead points to a different form of credential abuse, making it incorrect.

4720

Why wrong: Event ID 4720 indicates the creation of a new user account, a persistence technique often employed after initial compromise. Installing a web shell does not require nor typically trigger user account creation; the shell simply provides remote command execution through the web server's existing security context. While a threat actor might later create an account for persistent access, 4720 is not a direct indicator of web shell exploitation.

.plist files

Why wrong: Property list (.plist) files are structured preference/configuration containers (XML or binary), commonly found in ~/Library/Preferences and app bundles. They store application settings, registered services, and metadata, not the system's operational log events. While plists can hold timestamps or user activity footprints valuable to a forensic timeline, they do not constitute the centralized system logging mechanism for macOS process, kernel, or network events.

FSEvents

Why wrong: FSEvents is a macOS kernel-generated mechanism that records file system changes in per-volume journal files (e.g., .fseventsd), capturing creation, deletion, rename, and modification events. It is an excellent source for file activity timelines and digital forensic reconstruction of user file actions, but it does not collect general system logs such as process launches, authentication attempts, or network connections. Therefore, an examiner seeking a comprehensive system log source must look beyond FSEvents.

Console.app logs

Why wrong: Console.app is a graphical user interface application that displays and filters the unified log stream; it is a viewer, not a separate logging infrastructure. Opening Console.app does not produce or store additional logs, and it cannot capture events that were already purged. For forensic analysis, relying on Console.app alone is insufficient because the underlying data resides in the unified logging store, which must be queried via the `log` command for reliable, artifact-preserving acquisition.

Jump lists

Why wrong: Jump lists are per-application menus that record files recently opened within that application (e.g., Word or Excel). While they contain LNK files embedded as entries, they are scoped to a specific application and user interaction, not a global file-system access record. Therefore, for broad tracking of recently accessed files across the system, LNK files are the more appropriate artifact.

ShellBags

Why wrong: ShellBags are registry keys that store per-folder view preferences such as icon size, sort order, and window position. They are updated when a user opens a folder in Explorer, so they can indicate which folders were browsed, but they do not track individual file access or recent files. Thus they are not the correct artifact for tracking recently opened or accessed files.

Prefetch files

Why wrong: Prefetch (.pf) files are generated by Windows to speed up application startup; they contain the list of files and libraries loaded when an executable runs. They provide evidence of application execution and its referenced files at runtime, but they do not record user-initiated file opens or recent file lists. Therefore, they are not the primary artifact for tracking recent file access.

ARP spoofing

Why wrong: ARP spoofing (ARP cache poisoning) operates at Layer 2 by sending forged ARP replies or announcements to associate a target IP with an attacker's MAC address, enabling traffic interception or man-in-the-middle attacks. It never generates TCP SYN packets because ARP is a distinct protocol used for IP-to-MAC resolution, not connection establishment. The captured flood of SYN segments therefore cannot be explained by ARP spoofing, which aims at rerouting frames rather than exhausting a server's TCP connection table.

DNS amplification

Why wrong: DNS amplification is a reflection-based DoS technique that sends small DNS queries with the victim's spoofed source IP to open recursive resolvers, which respond with much larger DNS replies (e.g., ANY queries) to flood the victim. The traffic is carried over UDP port 53, and the attacker never initiates direct TCP connections with the victim, so the packet capture would show DNS response packets rather than SYN packets. The attack's amplification factor comes from the query-to-response size difference, not from exhausting a TCP handshake state.

Ping of death

Why wrong: Ping of death is an attack that sends malformed, oversized ICMP echo request packets exceeding the maximum IPv4 packet size, exploiting a vulnerable system's IP stack to cause buffer overflows or crashes. It uses ICMP at the network layer (Layer 3), not TCP SYN segments, so the capture would contain ICMP messages with abnormal payloads or flags. Additionally, ping of death targets a specific implementation bug rather than consuming connection resources, making it fundamentally different from a SYN flood.

Systemd service

Why wrong: Systemd services are managed through unit files with a .service extension, stored under /etc/systemd/system or /lib/systemd/system. While they are a common mechanism for starting persistent daemons or processes at boot, they are not appropriate for scheduling recurring tasks such as the one found in this investigation. The presence of an entry in /etc/cron.d would be characteristic of a cron job, not a systemd service, and systemd units would typically have distinct configuration keys like ExecStart or Restart. Even if a systemd timer could mimic cron's behavior, a .service unit alone does not define a schedule.

Init script

Why wrong: Init scripts, located in /etc/init.d/, are legacy SysV init shell scripts that start and stop services during system boot or runlevel changes. They are executed once when the system transitions to a runlevel, not on a recurring schedule. Finding a file in /etc/cron.d is not an init script, as those scripts usually have names matching a service and are symlinked into /etc/rc*.d. The presence of a cron entry with a time specification clearly points to cron, not an init script, which lacks the syntax for defining periodic execution intervals.

At job

Why wrong: At jobs, defined with the at command and stored in /var/spool/cron/atjobs or /var/spool/at, are used to execute a command once at a specific future time, not on a recurring schedule. Unlike cron jobs, at jobs do not use time fields that specify periodic intervals; they instead use a daemon that waits until the scheduled exact time and then runs the job. A file in /etc/cron.d is not an at job because at jobs are not stored in that directory, and their content would include a date/time specification, not the standard cron time columns. Forensic investigators would find at jobs in a spool directory, not under the /etc/cron.d system-wide cron configuration.

HKEY_LOCAL_MACHINE\SAM\SAM

Why wrong: The SAM hive (HKEY_LOCAL_MACHINE\SAM\SAM) stores the Security Account Manager database, which contains local user password hashes, security descriptors, and group membership information. It contains no AutoRun or startup entries, so it cannot be used to execute programs at user logon. Additionally, access to this hive is deliberately restricted even for administrators because of the sensitive credential material it holds, making it a very unlikely target for simple persistence.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Why wrong: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon primarily configures the interactive logon process, including the Userinit and Shell values that run during logon. While those values can be misused to launch programs, this is a less common and more disruptive persistence strategy than standard Run key abuse; modifying Winlogon can destabilize the whole logon experience and usually requires privileged access, so it is not the typical key used for per-user startup entries.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Why wrong: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services is the registry root for the Service Control Manager, storing each service's start type, binary path, dependencies, and recovery options. A service entry is not launched through the same shell startup flow as user Run keys; it is started by the kernel/service control manager and typically requires SYSTEM or administrative privileges to install. While malware can use services for persistence, this is a distinct mechanism from ordinary user-logon auto-start and is not a per-user Run-style location.

Wireshark

Why wrong: Wireshark is fundamentally a packet analyzer that captures individual frames from a network interface or reads trace files, decoding each frame's protocol headers and payload for forensic inspection. Although it can dissect a captured NetFlow export packet when encountered on the wire, it does not listen on UDP/TCP ports to aggregate flow records, nor does it calculate flow-level metrics like byte-per-second trends, top-talker tables, or interface utilization. This makes it an excellent tool for deep-diving into specific sessions, but an impractical one for analyzing the massive, summarized flow data typically used in network traffic forensics.

Splunk

Why wrong: Splunk is a general-purpose log and event intelligence platform that ingests time-series data as searchable events; to handle NetFlow, an administrator must add a NetFlow collection add-on and then define custom field extractions for the IPFIX or NetFlow v9 records. It is not a purpose-built flow collector — it lacks native support for router protocol negotiation and does not maintain flow caches or produce out-of-the-box bandwidth/utilization dashboards. While Splunk can be tailored to show NetFlow-derived insights, it is fundamentally a SIEM/log analytics tool rather than a dedicated NetFlow Traffic Analyzer.

Nmap

Why wrong: Nmap is an active network scanning utility that sends crafted probes — such as TCP SYN scans, UDP packets, and ICMP queries — to discover live hosts, open ports, and operating-system fingerprints. It operates by generating its own traffic and interpreting responses, not by passively receiving exported flow records from routers, and it never reconstructs historical communication patterns between endpoints. Even with the Nmap Scripting Engine, it cannot summarize aggregate flows, so its role in forensics is limited to point-in-time network discovery rather than traffic-flow analysis.

Record USB device connection history

Why wrong: Under UserAssist, the key tracks program execution metadata, not USB devices. USB connection history is recorded separately in the USBSTOR and MountedDevices keys within the SYSTEM registry hive, where forensic tools inspect device serial numbers, VID/PID, and first/last insertion timestamps. UserAssist only stores ROT13-obfuscated executable paths, run counts, and last-run times, so it provides no information about USB device insertion or removal.

Store user password history

Why wrong: Storing user password history is an authentication-domain function, not an application-execution artifact. Windows persists password hashes and password history in the SAM hive (HKLM\SAM) and in domain controllers in NTDS.dit, while individual user profiles do not store such secrets. UserAssist values are simply execution counts and timestamps for launched executables; they contain no authentication material, so this option is unsupported by the artifact.

Track recently opened documents via Jump Lists

Why wrong: Jump Lists are separate artifacts that also reveal user activity, but they focus on recently opened documents and application destinations rather than generic executable run counts. These files live under C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations and CustomDestinations, storing MRU entries that point to specific files and URLs. UserAssist does not track document-level paths; it only tracks the execution of the programs themselves, so this option confuses two distinct forensic evidence sources.

To lock the user account

Why wrong: Locking an account in Linux is done by placing '!' or '*' before the password hash in /etc/shadow, not by changing the UID in /etc/passwd. In fact, setting a user's UID to 0 grants that account root-level rights, which is the exact opposite of locking. A locked account denies all logins, while a UID 0 account is unrestricted and highly dangerous.

To enable password-less login

Why wrong: Password-less login means the authentication step can be bypassed, usually via an empty hash in /etc/shadow or an SSH public key in the user's authorized_keys file. Changing a UID to 0 does nothing to suppress password prompts; the account still must authenticate, and only after successful authentication does the UID affect privilege level. Thus, the attacker would still need a valid password, key, or another bypass to use the altered UID.

To hide the user account from the system

Why wrong: Editing the UID to 0 does not hide an account; the entry remains fully visible in /etc/passwd, and commands such as getent passwd, finger, and last still report it normally. Worse, any file or process owned by UID 0 appears as belonging to root in listings, drawing attention to the modified account rather than concealing it. Actual account hiding would require kernel-level rootkit manipulation or log tampering, not a simple passwd file edit.

Event ID 4624 logs

Why wrong: Event ID 4624 in the Windows Security log records successful logon events, including the authentication protocol (e.g., NTLM or Kerberos), logon type (interactive, network, etc.), source IP, and the user account. While this can confirm that a user accessed the system, it provides no information about subsequent file-level activity or which applications were run. Thus, it cannot answer questions about recently accessed documents.

System Restore points

Why wrong: System Restore points are snapshots of critical system files, the registry, and some user data (on select OS versions) used for reverting system state after failures or malware. They do not function as an audit trail of user actions, nor do they record the specific files a user opened or applications they used. Furthermore, restore points are created periodically or during system changes, not continuously, making them unsuitable for time-specific file access history

SAM registry hive

Why wrong: The SAM (Security Account Manager) registry hive, located at `HKEY_LOCAL_MACHINE\SAM`, stores locally defined user accounts and their password hashes (LAN Manager and NT hashes), which are used for authentication. It does not contain any information about file access, application execution, or user browsing behavior. Moreover, the SAM hive is locked by the system while running and its data is encrypted with the syskey, further limiting its forensic utility for activity reconstruction.

Modification of the NTUSER.DAT registry hive

Why wrong: The NTUSER.DAT registry hive is a component of the Microsoft Windows Registry, storing per-user environment settings and application configurations. A Linux server does not use a registry; its equivalent configuration lives in plain-text files like /etc/passwd, /etc/shadow, and dotfiles under /root. Any modification to NTUSER.DAT would be completely foreign to a Linux forensics examination and provides no persistence for a web shell on a Unix-like system. This option is wrong because it is an artifact from the Windows operating system, not Linux.

Prefetch file creation

Why wrong: Prefetch files are created automatically by Windows to speed up application startup by caching memory-mapped pages, and they are located in C:\Windows\Prefetch. Forensic analysts use them to determine which executables have run on a Windows host, but they do not exist on Linux. A Linux server relies on audit logs like /var/log/audit/audit.log or shell history to track executed commands. Therefore, this option is incorrect for a Linux persistence question.

HKLM\SAM\SAM

Why wrong: HKLM\SAM\SAM is the Security Accounts Manager database, storing local user account credentials and NTLM password hashes. It contains no USB device identifiers, serial numbers, or volume information; its forensic relevance lies in user credential extraction, not peripheral device history. Therefore, it would not be used to determine which USB storage devices were connected to the system.

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Why wrong: HKCU\Software\Microsoft\Windows\CurrentVersion\Run is a per-user autostart registry key used to execute programs at logon. While it may reveal malware persistence or unusual executables launched from removable media, it does not record device identification data, connection times, or mount information for USB drives. Thus it is irrelevant to USB device artifact analysis.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Why wrong: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList contains a list of user profiles, indexing them by security identifier (SID) and mapping each to a ProfileImagePath. This key is used to locate profile directories and load user hive information, not to track external storage or USB device connections. Therefore, it is entirely unrelated to USB forensic analysis.

/var/log/syslog

Why wrong: /var/log/syslog is a general-purpose logging facility that aggregates kernel, daemon, and application messages; on most distributions SSH authentication activity is typically logged to /var/log/auth.log or /var/log/secure, not the default syslog file. Even if authentication messages appear in syslog, it records events such as successful or failed login attempts with timestamps and client IPs, not the static contents of user configuration files. Thus, unauthorized keys would never be listed in syslog; at most, it might show a connection that used a newly added key, but not the key itself.

/etc/ssh/sshd_config

Why wrong: /etc/ssh/sshd_config is the SSH daemon's configuration file, not a credential store. It controls directives such as PermitRootLogin, PubkeyAuthentication, and AuthorizedKeysFile, which defines the default path to the authorized_keys file (normally ~/.ssh/authorized_keys). While an investigator should inspect it to detect changes like enabling root login or redirecting AuthorizedKeysFile to an alternate location, the file does not contain the actual public key material that would appear after an attacker appends a key.

/etc/passwd

Why wrong: /etc/passwd is a structured database of local user accounts containing fields for username, UID, GID, home directory, and login shell, but it does not hold SSH keys; password hashes are kept in /etc/shadow for security. If an attacker created a new user for backdoor access, that user would appear in /etc/passwd, but the authorized_keys for that new user would reside in their home directory (e.g., /home/username/.ssh/authorized_keys). Therefore, /etc/passwd alone would not reveal key-based persistence, only the existence of potentially suspicious accounts that might warrant further examination.

LNK files

Why wrong: LNK files are Windows shortcut files that store a target path, icon location, and metadata such as the original file's creation and modification timestamps, as well as volume serial numbers. They are generated when a shortcut is created or used, but their presence does not prove the target executable was executed, nor do they track how many times an application ran. Forensic examiners use LNK files to demonstrate access to specific files or mounted volumes, not to establish an aggregate application execution history or run count.

Jump lists

Why wrong: Jump lists are a Windows feature, introduced in Windows 7, that maintain per-application lists of recently opened files, folders, or tasks. They are stored as .automaticDestinations-ms and .customDestinations-ms files under the user's Recent directory, and they provide rich MRU (most recently used) data with timestamps, but only for the application's destinations (e.g., documents opened in Word). Jump lists do not log every execution of the main executable itself, and they do not contain a run count or a cumulative execution timeline for the application. Therefore, they are valuable for file-access forensics, not for determining how often an application was launc…

Event logs

Why wrong: Windows Event Logs capture system, security, and application events such as service starts, failures, logon events, and error reports, but they do not natively record a generic 'process executed' event that logs every application launch with a path and run count. While advanced logging mechanisms like Sysmon can be configured to audit process creation (Event ID 1), the default event log infrastructure offers no aggregate execution counter or comprehensive run-history for all executables. Consequently, relying on event logs to answer 'how many times was this application run' is unreliable and incomplete, as they are designed for event auditing rather than per-execution tracking.

Service installation

Why wrong: Service installation is an alternative persistence technique that involves creating a new Windows service under the registry key HKLM\SYSTEM\CurrentControlSet\Services, where each subkey contains an ImagePath that points to an executable the Service Control Manager (SCM) runs. Unlike a Run key entry, a service requires an administrator-level installation process to register a ServiceMain function and set the Start value to 2 (AUTO_START) or 3 (DEMAND_START), and it executes before or during system startup rather than at a user logon. Therefore, an unusual entry specifically in a Run key is not a service, and the two locations are distinct from a forensic perspective.

Scheduled task

Why wrong: Scheduled tasks are stored in the Task Scheduler database, typically as XML files under C:\Windows\System32\Tasks (or within the registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache), and they are triggered based on time, event, or system state—not by the registry Run key. The Run key is only one of many AutoStart Extensibility Points, and a scheduled task would not appear as a stray value in the Run key because it lives in a completely separate namespace. When investigating a suspicious Run key value, an analyst should check Task Scheduler separately to identify tasks that may have been created for persistence, as the two mechanisms are indistinguishable in terms of malicious intent but have different forensic evidence locations.

Startup folder

Why wrong: The Startup folder is a file-system directory, located in the user's profile under C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup (and the common counterpart for all users), that contains shortcuts or executables which are launched at user logon. It is not part of the registry and does not involve a Run key value; an unusual registry entry under a Run key cannot be attributed to a Startup folder item. From a forensic standpoint, the Startup folder is far easier for the user to spot and manually manage, whereas the Run key is hidden within the registry and thus a more stealthy persistence alternative.

SQL injection

Why wrong: SQL injection exploits improperly sanitized input to alter SQL queries executed by the database, typically using tokens like UNION or single quotes, and yields database records, not operating system file listings. The pcap's 'cmd' parameter and resulting directory listing are characteristic of server-side command execution, which SQL injection cannot directly produce unless chained with xp_cmdshell or a similar database-specific feature, an unlikely and indirect mechanism. Therefore, this traffic pattern does not match classic SQL injection.

Directory traversal

Why wrong: Directory traversal abuses unvalidated file paths, sending sequences like ../../../etc/passwd to make the application read arbitrary files from the filesystem, returning file contents—not a dynamic command result. A webshell scenario, by contrast, passes an OS command through a parameter such as 'cmd' and returns the command's execution output, such as a directory listing. The observed command parameter and listing are functional evidence of remote code execution, not merely path manipulation.

Cross-site scripting (XSS)

Why wrong: Cross-site scripting works by injecting JavaScript or HTML payloads that execute in the victim's browser, targeting other users or the session context, not the web server's operating system. The captured traffic shows the server executing a command and returning a directory listing, which requires server-side interpretation of the 'cmd' parameter—something XSS cannot achieve because it runs client-side only. Therefore, XSS is not a plausible classification for this pcap.

Bash history

Why wrong: Bash history is incorrect because it is a passive log file, typically ~/.bash_history, that records interactive shell commands entered by users. It does not possess any scheduling or self-executing capability, so although an investigator might find a suspicious command recorded there, the history itself never triggers or runs anything. Its forensic value is purely artifact-based, showing past actions, not an active execution mechanism.

Systemd service

Why wrong: Systemd service is incorrect because unit files under /etc/systemd/system/ define long-running daemons or one-shot processes that systemd supervises and launches at boot or on demand. They are event- or boot-driven, not time-scheduled like cron jobs, and the /etc/cron.d/ directory is specifically reserved for cron tab definitions, not systemd units. A malicious systemd service is a persistence technique, but it would not be identified as a cron job.

Init script

Why wrong: Init script is incorrect because SysV init scripts reside in /etc/init.d/ and are executed by the init process during system boot or runlevel changes, not at periodic time intervals. They are boot-time automation, triggered by runlevel traversal, and are not parsed by cron; a schedule specification is meaningless to them. In a forensic context, finding a script in /etc/init.d/ suggests boot persistence, but it does not constitute a scheduled cron job.