Cryptography and Malware Analysis practice questions

Rainbow table attack

Why it fails: A rainbow table attack is a precomputed table lookup technique specifically designed to reverse cryptographic hash functions, primarily used for cracking password hashes. It works by storing precomputed chains of hash values and their corresponding original inputs, allowing for a faster lookup than brute-forcing each hash. This method does not directly analyze the internal structure or key of an encryption algorithm to find weaknesses, making it distinct from cryptanalytic attacks on ciphers.

Replay attack

Why it fails: A replay attack involves intercepting a valid data transmission and then retransmitting it, often to impersonate a legitimate user, repeat an authorized action, or bypass authentication mechanisms. This is a network-level attack on communication protocols or session integrity, exploiting weaknesses in how cryptographic primitives are *used* within a system. It does not involve breaking the underlying cryptographic algorithm itself or recovering its secret key, thus it is not a cryptanalytic technique.

Keylogging

Why it fails: Keylogging involves the surreptitious recording of user keystrokes, often through API hooking, kernel-level drivers, or direct hardware interception. The provided scenario does not describe any observed behavior related to capturing keyboard input, such as monitoring user activity or transmitting keystroke data. Therefore, attributing keylogging functionality to the malware based solely on the given information is unsubstantiated.

Fileless execution

Why it fails: Fileless execution refers to malware that operates entirely in memory, leveraging legitimate system processes and tools (e.g., PowerShell, WMI, living-off-the-land binaries) to avoid writing any artifacts to the disk. The description explicitly states that the malware creates a hidden file on disk, which is a direct contradiction to the core principle of fileless operation. This disk-based artifact immediately disqualifies it from being categorized as fileless.

Privilege escalation

Why it fails: Privilege escalation is the act of gaining higher access rights on a system than initially possessed, such as moving from a standard user account to an administrator or SYSTEM account. This typically involves exploiting vulnerabilities, misconfigurations, or leveraging User Account Control (UAC) bypass techniques. The provided information does not describe any actions indicative of attempting to elevate privileges, such as exploiting a kernel vulnerability or attempting to bypass User Account Control.

The process with PID 1234 is not identified

Why it fails: The claim that PID 1234 is not identified is incorrect. The `netstat -ano` command output explicitly associates PID 1234 with the `explorer.exe` process in the final column, which identifies the owning process for each network connection. This functionality is precisely why the `-o` switch is used with `netstat`, providing crucial process context for network activity analysis.

svchost.exe (PID 5678)

Why it fails: The `svchost.exe` process (PID 5678) connecting to port 80 (HTTP) in a `TIME_WAIT` state is generally less suspicious. `svchost.exe` is a legitimate Windows process that hosts numerous services, many of which may legitimately access HTTP resources. The `TIME_WAIT` state indicates that the connection has recently been closed, which is a normal part of the TCP connection termination sequence, rather than an active or persistent malicious connection.

The process with PID 5678 is not identified

Why it fails: The assertion that PID 5678 is not identified is false. The `netstat -ano` command output clearly shows `svchost.exe` listed in the 'Image Name' column corresponding to PID 5678. The `-o` flag in `netstat` is specifically designed to provide this process identification, linking network activity directly to the executable responsible for it.

Create WLAN, then set up RADIUS server, then configure AP to use RADIUS, then enable the WLAN, then test connectivity

Why it fails: When creating a Wireless Local Area Network (WLAN) that relies on WPA2/3-Enterprise, the security configuration often requires specifying the RADIUS server's IP address and shared secret. Attempting to create the WLAN before the RADIUS server is set up means these critical authentication parameters are unknown or non-existent, leading to an incomplete or invalid WLAN definition. This sequence forces a placeholder or incorrect configuration initially, requiring subsequent modification to rectify.

Set up RADIUS server, then configure AP to use RADIUS, then create WLAN, then enable the WLAN, then test connectivity

Why it fails: An Access Point (AP) is configured to use RADIUS specifically in the context of a defined Wireless Local Area Network (WLAN) or SSID. Configuring the AP for RADIUS authentication before the WLAN itself is created means the AP has no specific SSID to apply these authentication settings to. This creates a logical dependency issue, as the RADIUS configuration on the AP is typically tied directly to a WLAN profile, making this order inefficient or prone to configuration errors.

Set up RADIUS server, then create WLAN, then enable the WLAN, then configure AP to use RADIUS, then test connectivity

Why it fails: Enabling the Wireless Local Area Network (WLAN) before the Access Point (AP) is configured to utilize the RADIUS server for authentication creates a significant security vulnerability. The WLAN would become active, potentially broadcasting its SSID, but without the WPA2/3-Enterprise security mechanism fully operational. Clients attempting to connect would either fail authentication or, in some misconfigurations, might connect without proper validation, thereby exposing the network to unauthorized access.

Perform entropy analysis on the packed file to identify the encryption algorithm, then write a decryptor to unpack the code statically.

Why it fails: Entropy analysis can indicate packing but does not reveal the encryption algorithm or key. Commercial packers often use custom or strong encryption, making static decryption impractical without knowing the algorithm and key. This approach is time-consuming and unlikely to succeed, whereas dynamic unpacking in a sandbox is more reliable and safer.

Submit the packed file to an online multi-engine antivirus scanner and use the results to infer the unpacked code's behavior.

Why it fails: Online scanners provide detection names and sometimes behavioral reports, but they do not give access to the unpacked code. The analyst needs the original unpacked binary for deeper analysis, such as identifying C2 protocols or writing signatures. Relying solely on AV results is insufficient and may not reveal the full capabilities of the malware.

Use a debugger to set a breakpoint at the entry point and single-step through the unpacking stub until the original entry point (OEP) is reached, then dump the process memory.

Why it fails: While debugger-assisted unpacking can work, it requires significant manual effort and expertise to identify the OEP and handle anti-debugging tricks. In this scenario, the analyst needs a more automated and safe approach that also prevents C2 communication. Debugging alone does not inherently block network access, and the malware could still attempt to contact its C2 if run outside a controlled environment.

Nmap

Why it fails: Nmap (Network Mapper) is primarily used for network discovery and security auditing. It employs raw IP packets to determine hosts available on a network, their services, operating systems, and firewall status. While crucial for reconnaissance, Nmap does not possess any functionality to analyze a file's hash or query threat intelligence databases for malware detection. Therefore, it is unsuitable for investigating a suspicious file based on its cryptographic hash.

John the Ripper

Why it fails: John the Ripper is a free and open-source password cracking utility designed to detect weak Unix passwords and other types of credentials. It works by performing dictionary attacks, brute-force attacks, and other cryptographic attacks on password hashes. This tool's sole purpose is to recover passwords, not to analyze the characteristics or threat intelligence associated with a suspicious file's hash.

Wireshark

Why it fails: Wireshark is a powerful network protocol analyzer that allows users to interactively browse and inspect the data traveling on a computer network. It captures network traffic in real-time and displays it in a human-readable format, enabling deep inspection of individual packets. However, Wireshark's functionality is limited to network traffic analysis and does not include any features for submitting file hashes to threat intelligence platforms for malware identification.

Weak TLS cipher suite

Why it fails: A weak TLS cipher suite would indicate a vulnerability in the cryptographic algorithms used for the transport layer (HTTPS) itself, potentially allowing an attacker to decrypt traffic in transit. However, the problem statement implies HTTPS is correctly implemented for secure transmission, meaning the issue lies beyond the integrity of the TLS handshake or the strength of its ciphers. The core problem is not about how data is transmitted securely, but what data is encrypted by the application before transmission or at rest, making this option incorrect.

SSL stripping attack

Why it fails: An SSL stripping attack, often executed via a Man-in-the-Middle (MITM) position, involves downgrading an HTTPS connection to an unencrypted HTTP connection, allowing the attacker to intercept plain-text traffic. The question does not provide any indicators of such an active downgrade attack, nor does it suggest that the connection itself was compromised to remove TLS. The scenario describes an issue where data remains unencrypted within the application context, despite an active HTTPS connection, making this option irrelevant.

Man-in-the-middle attack

Why it fails: A Man-in-the-Middle (MITM) attack involves an attacker secretly relaying and potentially altering the communication between two parties who believe they are directly communicating. While MITM attacks can target various protocols, HTTPS, when properly implemented with valid certificates, is designed to prevent such attacks by ensuring the authenticity of the server and the integrity and confidentiality of the data in transit. The problem described points to an application-level vulnerability, not a compromise of the secure transport channel itself, thus ruling out a MITM attack as the primary issue.

The CRL published by the certificate authority that signed the issuing CA's certificate

Why it fails: The certificate authority that signed the issuing CA's certificate is the root CA in a two-tier PKI. While the root CA establishes the chain of trust, its Certificate Revocation List (CRL) primarily contains information about revoked subordinate CA certificates, not the end-entity certificates issued by those subordinate CAs. Therefore, checking the root CA's CRL would not provide the necessary revocation status for an end-entity certificate issued by the online CA.

The CRL published by the intermediate CA, if any

Why it fails: The question explicitly describes a two-tier Public Key Infrastructure (PKI) with an offline root CA and an online issuing CA. There is no mention or implication of an intermediate CA in this specific scenario. While an intermediate CA would publish its own CRL for certificates it issues, its absence from the described architecture means its CRL is not relevant for determining the revocation status of certificates issued by the designated online issuing CA.

The CRL published by the offline root CA

Why it fails: The offline root CA, being the trust anchor, is primarily responsible for signing the certificates of its subordinate CAs, such as the online issuing CA in this setup. It does not directly issue end-entity certificates to users or devices. Therefore, its Certificate Revocation List (CRL) would only contain information about revoked CA certificates that it signed, not the end-entity certificates issued by its subordinate online CA.

Check running processes for suspicious entries

Why it fails: Hardware keyloggers operate at a physical layer, intercepting keystrokes between the keyboard and the computer's input port before they are processed by the operating system. Consequently, these devices do not execute as software processes within the operating system's memory space. Checking running processes would only reveal software-based malware or legitimate applications, rendering this method entirely ineffective for detecting a physical keylogger.

Review USB device history in Event Viewer

Why it fails: While Event Viewer can log the connection of new USB devices, many sophisticated hardware keyloggers are designed to operate transparently, often mimicking the original keyboard's device ID or functioning as a pass-through device. This stealth capability means they may not generate distinct, suspicious entries in the USB device history that would clearly indicate a malicious device. Therefore, relying solely on Event Viewer logs is insufficient for definitive detection.

Run an antivirus scan

Why it fails: Antivirus software is specifically engineered to detect, quarantine, and remove malicious software components, such as viruses, worms, and software-based keyloggers, by scanning files and monitoring system behavior. Hardware keyloggers, however, are standalone physical devices that do not install files on the system or execute code within the operating system. An antivirus scan would therefore completely overlook such a device, as it operates outside the scope of software-level detection.

GCM

Why it fails: Galois/Counter Mode (GCM) is an authenticated encryption mode that combines confidentiality with data integrity and authenticity. While it uses a counter mode for encryption, its defining feature is the generation and appending of an authentication tag to the ciphertext. This tag, crucial for verifying data integrity and authenticity, inherently increases the overall length of the transmitted data beyond just the padded plaintext, making it unsuitable when minimal length increase is the primary concern.

CFB

Why it fails: Cipher Feedback (CFB) mode operates as a stream cipher, generating a keystream that is XORed with the plaintext. While it can produce ciphertext of the same length as the plaintext, it requires a unique Initialization Vector (IV) for each encryption operation to ensure semantic security and prevent identical plaintexts from yielding identical ciphertexts. This IV, though not part of the ciphertext blocks themselves, is an essential additional piece of data that must be transmitted or derived, contributing to the overall data overhead.

CBC

Why it fails: Cipher Block Chaining (CBC) mode enhances security by XORing each plaintext block with the previous ciphertext block before encryption, creating a dependency chain. For the first block, and to ensure unique ciphertexts for identical plaintexts, CBC mode mandates the use of a unique Initialization Vector (IV). This IV is a critical component for decryption and is typically transmitted alongside the ciphertext, thereby adding to the total data length beyond the encrypted blocks themselves.

Code obfuscation

Why it fails: Code obfuscation is a technique employed by malware authors to make their code difficult for human analysts and automated tools to understand and reverse engineer. This is achieved through methods like junk code insertion, control flow flattening, string encryption, or renaming variables. Its primary goal is to hinder static analysis and intellectual property theft, not to detect the characteristics of a virtualized environment or sandbox by querying system resource counts.

Anti-debugging

Why it fails: Anti-debugging techniques are specifically designed to detect the presence of a debugger attached to a process or to impede its functionality. Malware uses these methods, such as checking for debugger-specific API calls, timing anomalies, or process environment block flags, to prevent dynamic analysis. While critical for evading real-time inspection, anti-debugging does not typically involve querying system hardware resources like CPU cores or memory size to identify a virtual machine or sandbox environment.

Packing

Why it fails: Packing involves compressing or encrypting an executable's original code and data, typically to reduce its size and evade static signature-based detection by antivirus software. The packed executable contains a small stub that unpacks the original code into memory at runtime before execution. This technique primarily targets file-based detection and does not involve querying system resource attributes like CPU or memory to identify a virtual machine or sandbox environment; its focus is on altering the file's static signature.

Sender's public key

Why it fails: The sender's public key is designed for distribution and is used by recipients to verify the digital signature, not to create it. If a sender were to sign with their public key, anyone with access to that public key could forge a signature, completely undermining the non-repudiation and authenticity guarantees that digital signatures provide. This key's function is to confirm the private key's action, not to perform it.

Recipient's private key

Why it fails: The recipient's private key is exclusively used by the recipient to decrypt messages that have been encrypted specifically for them using their corresponding public key. It plays no role in the sender's process of creating a digital signature, as the signature's purpose is to authenticate the sender and ensure message integrity, not to secure the message's confidentiality for the recipient.

Recipient's public key

Why it fails: The recipient's public key is primarily utilized by the sender to encrypt the email message, ensuring confidentiality so that only the intended recipient can decrypt and read it. While crucial for secure communication, this key is not involved in the digital signing process, which focuses on authenticating the sender and verifying message integrity, not on encrypting the content itself.

Remains constant in code to ensure replication

Why it fails: A core characteristic of polymorphic viruses is their ability to alter their internal structure. Therefore, remaining constant in code directly contradicts the definition of polymorphism, which involves continuous mutation. Such a static code pattern would render the virus easily detectable by signature-based antivirus solutions, failing to achieve its primary objective of stealth and persistence. This constancy would be a fatal flaw for a polymorphic threat.

Spreads via network shares

Why it fails: While some malware, including certain polymorphic variants, might leverage network shares for propagation, spreading via network shares is a characteristic of malware delivery mechanisms or worm-like behavior, not an inherent defining trait of polymorphism itself. Polymorphism describes how a virus changes its code, irrespective of its specific method of initial infection or lateral movement within a network. Worms are particularly known for this self-propagating capability.

Resides in the boot sector of a hard drive

Why it fails: Residing in the boot sector is a specific infection location characteristic, defining a category known as boot sector viruses. This describes where the malware physically stores itself and executes upon system startup, rather than how its code behaves or changes. Polymorphism, in contrast, refers to the virus's ability to alter its own code structure, which can be implemented by various types of malware, including those that might or might not infect the boot sector.

Change the encryption mode from CBC to GCM to provide authentication

Why it fails: Changing to GCM mode provides authenticated encryption, offering both confidentiality and integrity, which is an improvement over CBC alone. However, if the same encryption key is reused across multiple records, a compromise of that single key would still allow an attacker to decrypt and potentially tamper with all records encrypted with it. GCM does not inherently solve the fundamental problem of widespread data exposure resulting from a single key's compromise when that key is applied universally.

Store the encryption key in a hardware security module (HSM) and use the same key

Why it fails: While storing the encryption key in a Hardware Security Module (HSM) significantly enhances the security of the key itself by protecting it from extraction and unauthorized access, it does not mitigate the risk if the *same key* is used for *all* records. Should this single key ever be compromised, whether through a sophisticated attack on the HSM's operational interface or a flaw in the application's key usage, every record encrypted with it would become vulnerable. The issue lies in the scope of impact from a single key's compromise, not solely its storage location.

Rotate the encryption key every 24 hours

Why it fails: Key rotation is a valuable security practice that limits the amount of data encrypted with any single key and reduces the window of opportunity for an attacker to exploit a compromised key. However, it primarily protects *new* data encrypted with the freshly rotated key. If an *old* key is compromised, all records previously encrypted with that specific key remain vulnerable to decryption, regardless of subsequent key rotations. This approach fails to limit the 'blast radius' of a key compromise on existing, historical data.

The file has been tampered with because the hash is from a different file.

Why it fails: This statement is incorrect. If the calculated cryptographic hash of the downloaded file precisely matches the officially provided hash, it confirms that the file's contents are identical to the original source. A mismatch would indeed indicate tampering or corruption, but in this scenario, the hashes align, unequivocally verifying the file's integrity and authenticity, not a different file.

The SHA256 hash is not reliable; the analyst should use MD5 instead.

Why it fails: This assertion is fundamentally flawed. SHA256 is a cryptographically robust hashing algorithm, offering significantly stronger collision resistance and security compared to MD5. MD5 has known vulnerabilities, making it unsuitable for security-critical integrity checks where malicious collisions could be engineered. Therefore, SHA256 is the preferred and reliable choice for verifying file integrity, not MD5.

The file is malicious because the hash is too long.

Why it fails: This conclusion is incorrect. The length of a cryptographic hash is determined solely by the specific hashing algorithm used (e.g., SHA256 produces a 256-bit output, which is 64 hexadecimal characters long) and bears no relation to whether a file is malicious. A hash's primary purpose is integrity verification; if it matches the expected value, it indicates integrity, not maliciousness or benignness based on its length.

Implement password hashing with bcrypt on the server side.

Why it fails: Implementing password hashing with bcrypt on the server side is a critical security measure for protecting stored credentials against database breaches. However, this process occurs *after* the password has been transmitted from the client to the server. Therefore, hashing does not protect the password during its journey across the network, leaving it vulnerable to interception in cleartext if the communication channel itself is not encrypted.

Use digital signatures to sign the login request.

Why it fails: Digital signatures provide authenticity and integrity for a login request, ensuring that the request originated from a legitimate source and has not been tampered with during transit. Nevertheless, digital signatures do not encrypt the content of the request. An attacker intercepting a signed request would still be able to read the plaintext username and password, as the signature only validates the data, it does not obscure it.

Encrypt the password field using AES-256 before sending via HTTP.

Why it fails: Encrypting only the password field using AES-256 before sending it via plain HTTP is an incomplete and insecure approach. While AES-256 provides strong encryption for the password itself, the critical challenge lies in securely distributing the encryption key to the client without an already established secure channel. Additionally, other sensitive information within the HTTP request would remain unencrypted and susceptible to interception, compromising overall session security.

Diffie-Hellman (DH) key exchange

Why it fails: Standard Diffie-Hellman alone negotiates a shared secret without any server authentication, so it cannot establish a trusted HTTPS session because it lacks a mechanism to bind the key exchange to the server’s certificate. It is tempting because DH does provide ephemeral keying for PFS when combined with signatures (as in DHE), but the plain DH mode is actually intended for anonymous key agreement where authentication is handled separately or not required.

Pre-Shared Key (PSK)

Why it fails: Pre-Shared Key (PSK) key exchange is generally unsuitable for public web servers due to significant scalability and key management challenges, as each client would need to share a unique secret with the server beforehand. Furthermore, PSK does not inherently provide Perfect Forward Secrecy (PFS); if the pre-shared key is ever compromised, all past and future communications encrypted with that key become vulnerable to decryption. Its primary applications are typically in closed environments like VPNs or IoT devices where key distribution can be tightly controlled.

RSA key exchange

Why it fails: RSA key exchange, while historically common, does not offer Perfect Forward Secrecy (PFS), making it an insecure choice for modern web servers. In this method, the client encrypts a pre-master secret using the server's static public RSA key, which the server then decrypts with its corresponding private key. Consequently, if the server's long-term private key is ever compromised, an attacker can retroactively decrypt all past recorded TLS sessions that used this key exchange mechanism, completely undermining confidentiality.

Reimage the server immediately to ensure the malware is completely removed.

Why it fails: Reimaging a server immediately, while effective for malware removal, is a highly destructive action that obliterates crucial forensic artifacts. This includes memory dumps, registry keys, log files, and temporary files that could reveal the malware's origin, capabilities, and exfiltration targets. This premature action prevents a thorough root cause analysis and understanding the full scope of the breach, prioritizing eradication over essential containment and investigation phases.

Uninstall the current antivirus and install a different endpoint protection solution, then perform a full scan.

Why it fails: Uninstalling and reinstalling endpoint protection is a time-consuming process that leaves the compromised server vulnerable during the transition period. More critically, this action fails to immediately stop active malicious processes, such as ongoing data exfiltration or lateral movement, which could continue unimpeded while the new solution is being deployed and scanned. The primary concern in an active compromise is immediate containment, which this approach does not address effectively or promptly.

Delete the 'UpdateSvc' service and the 'HealthCheck' scheduled task, then run a full antivirus scan.

Why it fails: Directly deleting identified persistence mechanisms like services and scheduled tasks, while seemingly proactive, risks destroying valuable forensic evidence about the malware's configuration and capabilities. Furthermore, sophisticated malware often employs multiple, redundant persistence methods, meaning removing just these two might not fully eradicate the threat and could leave other backdoors active. A full antivirus scan alone might also miss advanced, fileless, or polymorphic malware, making this a potentially incomplete and evidence-destroying approach.

volatility -f memory.dmp procdump

Why it fails: The `volatility -f memory.dmp procdump` command is used to extract the executable image or memory regions of a *specific* process from the dump. While invaluable for subsequent in-depth analysis, such as reverse engineering or string extraction from a known malicious process, it requires the investigator to first identify the suspicious process's PID. Therefore, it is not an initial detection tool for broadly identifying an infection but rather a targeted analysis step performed after initial indicators have been found.

volatility -f memory.dmp svcscan

Why it fails: The `volatility -f memory.dmp svcscan` command enumerates all registered Windows services and their current states within the memory dump. While some malware achieves persistence by installing itself as a service, many infections operate as userland processes or inject into existing ones without creating new services. Consequently, `svcscan` is less direct for initial detection of active malware behavior compared to analyzing running processes or network connections, which are more immediate indicators of compromise.

volatility -f memory.dmp malfind

Why it fails: The `volatility -f memory.dmp malfind` command is designed to detect hidden or injected code within process memory, often indicative of advanced malware techniques like process injection or rootkit functionality. While extremely powerful for confirming sophisticated infections, it focuses on memory regions rather than providing an initial overview of all running processes or active network connections. It is a more specialized detection mechanism, typically employed after initial indicators suggest a process might be compromised.

Block the external IP address at the firewall to prevent further communication with the C2 server.

Why it fails: Blocking the external IP is containment; it does not identify the initial infection vector and can be bypassed by changing infrastructure.

Enable macro security settings in Microsoft Office to block macros from running without explicit user consent, and enforce via Group Policy.

Why it fails: Enabling macro security is a preventive hardening measure that reduces future risk but does not identify how this infection started.

Disable PowerShell across all workstations via Group Policy to prevent script execution.

Why it fails: Disabling PowerShell is an overly broad preventive measure that would break legitimate automation and does not identify the initial infection vector.