Mobile and Malware Forensics practice questions

Manual acquisition

Why wrong: Manual acquisition involves an examiner physically operating the device through its touchscreen, screenshotting or photographing each screen that displays relevant data. This process is inherently slow, prone to human error such as missed content or screen transitions, and captures only data currently visible on the interface. It does not create a forensic image, accesses no underlying storage, and completely misses deleted messages, call logs, or artifacts hidden in app sandboxes.

Logical acquisition

Why wrong: Logical acquisition relies on the device's operating system to enumerate and copy files through APIs, often using ADB backup or MTP, yielding an organized set of allocated files and their timestamps. Because it operates above the storage driver, it can only see objects the OS considers accessible; unallocated blocks, deleted entries, and raw partition remnants are never presented to the extraction agent. The result is a clean but incomplete dataset that may satisfy simple requests but fails to reveal deleted database rows or freed blocks.

File system acquisition

Why wrong: File system acquisition reads the on-disk file system structures directly, such as ext4 inodes, APFS file records, or FAT directory entries, to reconstruct allocated files and their metadata (names, sizes, timestamps) without going through the operating system's user-level APIs. However, it operates at the logical file system layer rather than the raw block layer, so unallocated storage blocks and free-space remnants are not imaged; deleted data that has not been overwritten may remain invisible unless the tool conducts targeted carving. This distinguishes it from physical acquisition, which captures the medium itself, and from logical acquisition, which depends on the OS.

Command and control communication

Why wrong: C2 communication requires observable network artifacts such as DNS requests, HTTP/S calls, IRC, or beaconing traffic to a remote server. The described output centers on a modification to the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key, which is a local change with no accompanying packet captures, domain names, or connection logs. Without an outbound connection or command-channel trace, classifying any activity as command and control is unsupported by this evidence.

Anti-debugging technique

Why wrong: Anti-debugging techniques are typically implemented through specific API imports or checks such as IsDebuggerPresent, NtQueryInformationProcess with ProcessDebugPort, or timing anomalies to detect breakpoints. A mutex, even if present, is used primarily for anti-multiple-instance protection or ensuring a single infection, not for thwarting debuggers. The observed registry write to the Run key is unrelated to detecting debugger presence, and the stem provides no evidence of debugger-aware behavior such as exception-based tricks or timing checks.

Privilege escalation

Why wrong: Privilege escalation requires the malware to elevate from the current user token to a higher integrity level, admin or SYSTEM, usually via an exploit, UAC bypass, or service abuse. Writing a value to HKCU\Software\...\Run operates entirely within the current user's registry hive and needs no elevated privileges, so it cannot by itself demonstrate any attempt to increase access rights. Without any loaded kernel driver, token manipulation, or event showing UAC/admin access, there is no basis to conclude privilege escalation occurred.

SELECT * FROM messages WHERE key_remote_jid = '%1234%'

Why wrong: The equality operator requires an exact, case-sensitive match of the entire key_remote_jid value to the literal string '%1234%'. Because the wildcard characters are not interpreted in an = comparison, this query will only return rows where the JID is literally the four-character sequence percent-1234-percent, which never occurs. Consequently, the result set is empty, making it functionally useless for forensic search.

SELECT * FROM messages WHERE data LIKE '%1234%'

Why wrong: The data column contains the actual message content—the body of the chat, such as 'Call me at 1234' or media captions—not the identity of the sender or recipient. Searching LIKE '%1234%' here would return every message whose text happens to include the digit string '1234', which may be a phone number inside a message, a time, or part of a URL. That result is unrelated to finding messages from a particular JID, so it fails to answer the investigative question about a specific contact.

SELECT * FROM messages WHERE timestamp LIKE '%1234%'

Why wrong: The timestamp column stores Unix epoch milliseconds as an integer (e.g., 1614556800000), and applying LIKE forces a type conversion of the numeric value to a string before pattern matching. Because the numeric representation has no thousands separators or characters, a pattern like '%1234%' can unintentionally match dates or times, but more importantly, it ignores the structured nature of the data—filters should use range comparisons like BETWEEN or >=/<. Even if a match occurs, timestamp is not a contact identifier, so the query does not locate messages by recipient.

App installation logs

Why wrong: Package installation logs live in volatile system areas such as /data/log and /data/system/packages.xml, all within the userdata partition; a factory reset re-keys userdata encryption and recreates these files from scratch, so there is no surviving package-install history in a post-reset logical image. Although deleted blocks could theoretically be carved from raw flash, the package manager does not periodically sync such logs to cloud storage, so they are not a standard retained artefact.

Deleted SMS messages

Why wrong: SMS messages are stored in mmssms.db and other telephony databases under /data/data/com.android.providers.telephony, protected by FBE per-user encryption keys; factory reset destroys both the database files and their encryption keys, rendering the old content cryptographically unrecoverable from a logical acquisition. Recovering them would require either a pre-reset physical image and flash-level carving or an explicit Google One backup copy, neither of which is a routine consequence of a reset.

Wi-Fi passwords

Why wrong: Wi-Fi credentials are held in /data/misc/wifi/WifiConfigStore.xml (or wpa_supplicant.conf) and are encrypted with Android Keystore-backed keys; userdata wipe reformats /data/misc and deletes those key blobs, so saved networks do not persist past reset. Android does not include Wi-Fi password entries in normal cloud backups, unlike Google account data, and no system component writes Wi-Fi secrets to a durable partition, making their post-reset recovery effectively impossible.

Hiding network connections

Why wrong: Hiding network connections would involve runtime API hooking or rootkit techniques that intercept network queries, leaving no trace in a registry comparison. Regshot specifically snapshots the registry and filesystem state before and after execution, not network sockets or live network activity. Since the observed change is a newly created service key with Start=2, there are no network-related registry modifications such as Winsock catalog changes or firewall rule additions. Therefore, this option does not match the evidence.

Encrypting files

Why wrong: Encrypting files typically modifies file contents and appends extensions, but such behavior does not require altering the registry. The only registry change detected is the creation of a service entry designed to execute at boot; there are no encryption-related keys such as a cryptor's startup command or file association changes. Ransomware often adds a registry run key to repeat encryption, but here the service configuration points to a binary that persists, not to a file-encrypting routine. Thus, the evidence points to persistence, not data destruction.

Disabling a legitimate service

Why wrong: Disabling a legitimate service would be evidenced by modifying the Start value of an existing service key to 4 (disabled) or changing its ImagePath to a broken value. In this case, the registry comparison reveals a new service key, not an alteration to an existing one, and the Start value is set to 2, indicating automatic startup rather than disabled. There is also no corresponding deletion of the service's original configuration or dependency modifications. The creation of a new auto-start service is fundamentally different from disabling a pre-existing service.

Host-based IoC

Why wrong: Host-based IoCs are local system artifacts such as registry keys, file creation or modification paths, mutexes, services, and scheduled tasks that indicate compromise on a single machine. A URL or domain discovered by Cuckoo during network analysis is not a persistent local system change; it is an external communication endpoint, so classifying it as host-based would be incorrect.

Memory-based IoC

Why wrong: Memory-based IoCs are artifacts recovered from volatile memory (RAM) dumps, including injected code, API hooking, process hollowing, and in-memory strings. Although a URL might appear inside a memory dump as part of a configuration, the artifact in this scenario is being observed from Cuckoo's network traffic capture, not from memory forensics, so labeling it memory-based misidentifies the source and the analysis phase.

Hash-based IoC

Why wrong: Hash-based IoCs are unique cryptographic fingerprints (MD5, SHA-1, SHA-256) computed over an entire file to identify the malicious sample exactly. The URL and domain in question are not file hashes; they are string-based indicators representing network destinations, so they cannot fall into the hash-based category even though Cuckoo may also report file hashes separately.

Filter for 'WriteFile' events in System32

Why wrong: Filtering WriteFile events in System32 captures file output operations but does not specifically indicate persistence. Persistence requires a mechanism that causes the executable to be launched automatically on startup or logon, such as a service, scheduled task, or Run key. While dropping a file into System32 may be part of an installer or a malware payload, it lacks the autorun trigger needed to conclude persistence. Additionally, many legitimate system processes routinely write to System32, leading to high false positives.

Filter for 'Process Create' events

Why wrong: Process Create events report when a new executable is started, including the malware sample itself and any child processes it spawns. However, creating a process is a one-time execution event and does not by itself establish persistence, which requires a configuration that re-launches the program after reboot or at logon. Malware may run without installing any persistence mechanism, and even benign software generates Process Create events continuously. Therefore this filter lacks the specificity to distinguish persistent mechanisms from ordinary program execution.

Filter for 'RegSetValue' events with path containing 'RunOnce'

Why wrong: RunOnce registry entries trigger a program only on the next logon or boot, after which the entry is automatically deleted, so they provide a one-shot execution rather than ongoing persistence. Although malware can use RunOnce for immediate execution, the standard and more durable persistence locations are under 'CurrentVersion\Run', which execute every logon. Since legitimate installers also commonly write RunOnce keys, this filter produces more noise and is less indicative of long-term persistence. The question asks for a persistence indicator, making RunOnce a weaker and less reliable choice.

Wi-Fi password

Why wrong: Although Wi-Fi network secrets do live in the iOS keychain, they are registered under the generic-password service identifier 'AirPort' (or with the network's SSID as the account), not under 'com.apple.sbd' with account 'iCloud'. A keychain item whose account is literally 'iCloud' cannot be a Wi-Fi passphrase, because the service/account pair determines the item's purpose. Therefore this extracted entry points to an iCloud authentication token rather than to a stored Wi-Fi password.

Device passcode

Why wrong: The device passcode is not a keychain item at all; it is held by the Secure Enclave and used to derive the keybag's protection keys. An iTunes backup and its keychain extraction contain software-accessible keychain records, but they never export the SEP-held passcode or the class keys that protect user data. The observed com.apple.sbd/iCloud entry is an account credential, not an authentication secret derived from the alphanumeric passcode, so it cannot be the device passcode.

SMS encryption key

Why wrong: SMS and iMessage encryption keys are associated with Apple's messaging services and are stored under identifiers such as 'com.apple.imessage' or 'com.apple.identityservices', often with account fields like 'Apple Account' or an address book ID, not under the 'com.apple.sbd' service. The sbd service is the iCloud/account data daemon, not the encryption-key store for SMS protocol. Consequently, this keychain item is not an SMS encryption key but the iCloud account token.

Persistence through service

Why wrong: SeDebugPrivilege is a process-access privilege, not a persistence mechanism. While an attacker could create a service to maintain persistence, doing so would exploit service control manager permissions or registry Run keys, not the debug privilege itself. The privilege simply allows a process to open and manipulate other processes, including reading/writing their memory; it confers no inherent ability to survive reboots or restart processes. Thus, service-based persistence would not be the direct reason an attacker needs SeDebugPrivilege.

Anti-debugging

Why wrong: Anti-debugging is an evasion technique used by malware to detect whether a debugger is attached, often through APIs like IsDebuggerPresent or NtQueryInformationProcess. SeDebugPrivilege, by contrast, is a system right that grants a process the ability to open and manipulate other processes, potentially enabling debugging. While a debugger sometimes holds SeDebugPrivilege, the privilege is a prerequisite for attaching, not a mechanism for avoiding detection. Consequently, the presence of this privilege would not indicate anti-debugging behavior; rather it would indicate an attempt to gain access to other processes.

Network sniffing

Why wrong: Network sniffing on Windows requires administrative rights, raw socket support, or a packet-capture driver such as Npcap/WinPcap to intercept traffic. These capabilities are not derived from SeDebugPrivilege, which operates at the process-object level and has nothing to do with the networking stack. Even with SeDebugPrivilege enabled, a process would still lack the NDIS or Winsock hooks needed for passive captures. Hence, sniffing is an incorrect explanation for why an attacker would escalate or retain this privilege.

Encryption

Why wrong: Encryption renders data unreadable through cryptographic algorithms, but it does not delete, conceal, or alter the forensic artifacts themselves; the ciphertext remains on the storage medium, and with the right lawful-access mechanisms such as key extraction or cloud recovery, the data can be recovered. Because it protects confidentiality rather than erasing or manipulating evidence, it is not considered an anti-forensic tampering technique in the same way as data destruction or timestamp alteration.

Steganography

Why wrong: Steganography conceals the existence of hidden messages by embedding them within innocuous carrier files such as JPEGs or MP4s, leaving the file system structure, logs, and timestamps untouched. It is primarily a data-exfiltration or covert-communication technique, not a method for tampering with device evidence; forensic examiners can often detect anomalies through statistical analysis, hash comparisons, or extracted-file carving, and the original evidentiary artifacts remain intact.

Log wiping

Why wrong: Log wiping involves deleting or truncating audit and event logs, such as Android's event log, system log, or app-specific logs, to remove traces of user activity; however, on a non-rooted mobile device, access to these logs is usually restricted by the permission model, making it a less practical tampering method. It also leaves behind gaps in the log sequence or inconsistencies in the file system journal, and it is more commonly associated with server-side incident response or OS-level forensic countermeasures rather than consumer mobile devices.

The registry run key location

Why wrong: The registry run key location indicates a persistence mechanism that allows the malware to launch automatically on startup. However, this local artifact only helps with host-based detection and cleanup; it does not prevent the malware from communicating with its command-and-control server. An attacker can easily change the run key or use other persistence methods, making it a weak indicator for immediate network containment. The C2 IP address is far more actionable because it can be blocked at the egress firewall.

The sample's MD5 hash

Why wrong: The MD5 hash uniquely fingerprints this exact malware binary, which is valuable for searching threat intelligence feeds and detecting identical samples across endpoints. Yet from a dynamic analysis perspective, the hash reveals nothing about the malware's current network behavior, so it cannot be used to interrupt communication. Additionally, an MD5 hash is trivially changed by recompiling the binary, so it is not a stable target for blocking. The immediate response should focus on the observed C2 IP to sever the active channel.

The mutex name 'Global\MyMaliciousMutex'

Why wrong: The mutex 'Global\MyMaliciousMutex' is a synchronization object the malware creates to ensure only one copy runs, and its name can aid in threat hunting on infected hosts. However, detecting the mutex requires already having visibility into the host, and it does not stop the malware from communicating with its C2 server. Mutex names are also frequently randomized or per-sample, making them unreliable for network-level blocking. A firewall rule against the C2 IP is a direct and universal mitigation, whereas mutex detection is only a local signal.

Making outbound TCP connections to an IP address

Why wrong: Making an outbound TCP connection to an IP address is a network artifact that typically indicates command-and-control (C2) beaconing, data exfiltration, or remote command delivery. Persistence, by contrast, requires a mechanism that causes the malware to be re-executed automatically after a reboot or user logon, such as a service, scheduled task, or startup registry key. A single outbound connection is ephemeral and does not by itself re-launch the process, so it is a behavioral indicator rather than a persistence mechanism.

Creating a named mutex

Why wrong: Creating a named mutex is a common synchronization technique used by malware to signal that an instance is already running, preventing multiple simultaneous infections or duplicate execution. A mutex is a kernel object that is automatically destroyed when the creating process exits, so it provides no mechanism to restart the malware after a reboot or logon. The presence of a mutex simply reflects runtime state, not an autostart persistence method.

Creating files in the %TEMP% directory

Why wrong: Creating files in the %TEMP% directory is a typical runtime activity used for unpacking components, dropping additional payloads, or staging data for later execution, but it does not establish a path to automatic execution. The %TEMP% folder is user-writable, frequently cleaned by the system and utilities, and files placed there are not automatically executed at startup or logon. Without an associated autostart entry or trigger, temp file creation is an execution artifact, not a persistence mechanism.

ZCONTACT

Why wrong: ZCONTACT is a table in Apple's Contacts database (AddressBook.sqlite or Contacts.sqlite), not in the call history database. It stores contact records such as names, phone numbers, and metadata, but lacks call-specific fields like timestamp, duration, or direction. Querying ZCONTACT during a call-history examination would return contact information, not evidence of dialed or received calls.

ZOBJECT

Why wrong: ZOBJECT is the primary table in knowledgeC.db, Apple's CoreDuet knowledge database used to store app usage, battery level, and other behavioral and contextual events. It is not part of the iOS call history schema and does not contain telephony call metadata. The presence of knowledgeC.db in an iCloud backup often misleads analysts, but call records must be retrieved from the call table in call_history.db.

ZCALL

Why wrong: ZCALL is a Z-prefixed Core Data table name that may appear in some iOS versions or third-party databases, but it is not the standardized table in the canonical call_history.db artifact. The stable, documented table for iOS call records is simply call, whose schema is widely recognized by forensic tools. Relying on ZCALL as the primary evidence source can cause an examiner to overlook the standard call database and miss important call details.

Static analysis requires the malware to be executed, while dynamic analysis does not.

Why wrong: This inverts the definitions: static analysis is performed on a malware sample without executing it, using disassembly, string extraction, and PE header inspection, whereas dynamic analysis actually runs the sample in a sandbox or emulator to observe runtime behavior. Requiring execution for static analysis would defeat its purpose of safe, code-level inspection, and would more accurately describe dynamic analysis.

Static analysis is used only for packed malware, while dynamic analysis is used for unpacked.

Why wrong: Packing is an obfuscation technique that complicates static analysis, not a delimiter between analysis types. Static analysis can be applied to any sample, though packers may hinder it until the sample is unpacked; dynamic analysis often works even on packed samples because the malware must unpack itself in memory to execute, letting the analyst capture its behavior. The claim that one method is 'only' for packed or unpacked malware is false.

Dynamic analysis uses tools like IDA Pro, while static uses Cuckoo Sandbox.

Why wrong: This option swaps the standard tool assignments: IDA Pro is a premier static analysis tool that disassembles binaries and reveals control flow graphs, while Cuckoo Sandbox is an automated dynamic analysis environment that executes samples in isolation and reports system calls, file, and network activity. Dynamic analysis would not typically leverage IDA Pro as a primary tool, nor would static analysis rely on a sandbox like Cuckoo.

File system extraction

Why wrong: File system extraction parses the mounted file system (e.g., ext4, F2FS) using the kernel's storage drivers to enumerate allocated files, directories, and metadata, and it may identify some logically deleted files by reading remnants in unallocated blocks or file system journal. However, it does not produce a raw block-level image, so it cannot recover data that is not referenced by a file system structure or that resides in slack space or entirely unallocated regions. Consequently, it is less complete than physical extraction and may miss significant deleted artifact.

Logical extraction via ADB

Why wrong: Logical extraction via ADB uses the Android Debug Bridge to issue commands like `adb pull` or to query content providers, operating at the Android application framework level rather than reading raw storage. It only retrieves files that are accessible to the running operating system and user space, so it cannot access unallocated clusters, deleted inodes, or other data hidden beneath the kernel's file system layer. ADB may also alter device state by changing access times or creating temporary files, undermining forensic integrity.

Manual extraction via device UI

Why wrong: Manual extraction through the device UI requires an examiner to scroll through applications and screens while photographing or screen-recording the display, which inherently captures only visible information. It is not forensically sound because it cannot provide a cryptographic hash of the original data, it modifies device state as the examiner interacts with the interface, and it offers no way to recover deleted data or bypass application-level restrictions. At best it produces a non-reproducible record and is only usable as a last resort when no other method is possible.

Code injection via Reflective DLL

Why wrong: Reflective DLL injection is a sophisticated technique that loads a DLL entirely from memory into a process without relying on the Windows loader, mapping the PE headers and sections manually and resolving imports via a crafted stub. However, this method is fundamentally independent of the TLS directory: it does not require parsing the TLS callback table or executing any TLS callbacks for its unpacking or initialization. The presence of a .tls section would therefore not be an indicator of reflective DLL injection, which instead typically leaves traces such as a manually mapped module with no corresponding file on disk.

Packing with UPX

Why wrong: UPX is one of the most widely recognized packers and it typically compresses the original code into sections named UPX0, UPX1, and UPX2, with the decompressor stub at the entry point, but it does not use a .tls section for its unpacking logic. While UPX can theoretically preserve a TLS section if the original binary had one, the packer itself does not add or rely on TLS callbacks to decompress code; instead, the stub manually unpacks the sections in memory before jumping to the original entry point. Therefore, seeing .tls would not be a hallmark of UPX packing, and a malware analyst would look for the familiar UPX section names rather than a TLS directory.

Anti-debugging via NtGlobalFlag

Why wrong: NtGlobalFlag is a process environment variable located in the Process Environment Block (PEB) at offset 0x68 on 32-bit systems and 0xBC on 64-bit systems, which can be queried by malware to detect a debugger by checking for flags such as FLG_HEAP_ENABLE_TAIL_CHECK. This anti-debugging technique is entirely unrelated to the TLS section, as it relies on reading a specific PEB field and does not define any callbacks or executable code prior to the entry point. The presence of a .tls section would not indicate NtGlobalFlag-based anti-debugging, which is instead typically identified by code that accesses the PEB directly.

Oxygen Forensic Detective

Why wrong: Oxygen Forensic Detective is a commercial mobile forensics tool that offers logical, file-system, and cloud extraction together with app-data analysis across various platforms. Its acquisition methods depend on Android Debug Bridge, iOS backups, and vendor-specific APIs, but it does not leverage low-level BootROM exploits such as checkm8, so it is not the tool specifically tied to that vulnerability.

Magnet AXIOM

Why wrong: Magnet AXIAM is a digital forensic examination platform that ingests and analyzes evidence from mobile devices, cloud sources, and computer images, typically relying on other acquisition tools for physical extractions. It does not perform BootROM-level attacks; instead, it focuses on artifact parsing, decryption, and reporting, making it an analysis layer rather than the exploit-based acquisition tool referenced in the question.

GrayKey

Why wrong: GrayKey, developed by Grayshift, is a dedicated mobile forensic acquisition device that exploits the checkm8 BootROM vulnerability present in Apple SoCs from the A7 through A11 (iPhone 4s through iPhone X). By taking advantage of this unpatchable vulnerability, GrayKey bypasses code signing and secure-enclave protections to perform physical extraction of the file system and keychain, even from locked iOS devices.

Packing

Why wrong: Packing compresses or encrypts the malware's executable code and resources so static analysis tools and signature-based detection see only a loader stub. It changes the binary's on-disk representation but does not create, modify, or delete any autostart registry keys, scheduled tasks, or services. The dynamic run may show the process unpacking itself in memory, yet that unpacking activity has nothing to do with hiding the persistence entry that was already placed. In short, packing is an anti-static-analysis measure, not a mechanism for wiping traces of a Run key.

Encryption

Why wrong: Encryption protects data confidentiality by transforming plaintext into ciphertext, so malware often encrypts its configuration, payloads, or C2 communication. However, persistence actions such as creating a scheduled task or setting the 'Run' registry value operate at the system's API level; the existence of that autostart entry is not the kind of content that encryption conceals. Even if the malware's data blobs are encrypted, the log entries generated by the task scheduler or service manager remain intact and readable. Encryption therefore cannot remove or obscure the forensic artifact that the malware created, whereas wiping the log would.

Timestomping

Why wrong: Timestomping deliberately changes a file's modification, access, creation, and entry-change times to mislead investigators about when the file was placed or last used. It can make a persistence binary appear legitimate, but it does not delete or clear records of the persistence entry itself, such as an event log entry showing a service installation or a task registration. In a dynamic analysis, the key observation is that the sample cleaned up the evidence of its autostart action; that cleanup is a log-wiping behavior, not a timestamp alteration. Timestomping addresses the 'when', not the 'that' or 'how' of persistence.

Deleted applications' data

Why wrong: Deleted applications' data is stored in the /data partition under directories like /data/data/<package>, which a factory reset wipes by formatting or reallocating the filesystem. On modern Android devices, this partition is encrypted (FBE/FDE), and the reset destroys the encryption keys or filesystem metadata, making recovery extremely difficult. Additionally, TRIM and garbage collection may physically erase blocks, so application-specific remnants are rarely recoverable without a pre-reset image.

Call logs

Why wrong: Call logs are maintained in the call log provider database, typically /data/data/com.android.providers.contacts/databases/call_log.db, on the /data partition. A factory reset deletes this database along with its journal and WAL files, and call log entries are frequently overwritten as new calls occur, leaving little persistent data. Unlike SMS databases, call logs do not benefit from long-lived journal files or frequent page fragmentation, so their recovery from unallocated space after a factory reset is unlikely.

Photos stored in internal storage

Why wrong: Photos stored in internal storage are kept under /data/media/0/DCIM on the emulated /sdcard, which is part of the userdata partition. A factory reset often formats the internal storage or deletes the media directory, leaving only sparse remnants that depend on the device's wipe routine. Because photos are large contiguous files, some can be carved from raw blocks, but the wipe typically destroys the filesystem metadata, making systematic recovery unreliable and therefore not a guaranteed source.

Registry keys modified during execution

Why wrong: Registry keys modified during execution are dynamic indicators because they only become observable when the sample runs and the malware's behavior alters the host system. Extracting them requires executing the binary in a sandbox or using API-monitoring tools, which is not part of static file analysis. Since the question targets indicators obtainable from the binary itself, registry modifications are not static IoCs.

File paths created during execution

Why wrong: File paths created during execution are dynamic indicators because they are artifacts left on disk when the malware runs its payload, and they must be observed with filesystem monitoring or process tracing in a controlled environment. These paths are not encoded in the PE headers or recoverable by static parsing; they depend on runtime conditions such as the current user profile directories and the malware's installation routine. Thus, they are inappropriate as static indicators.