Cyber Threats Iocs And Attack Methodology practice questions

T1059: Command and Scripting Interpreter

Why it fails: This refers to shell execution, not the file location.

T1105: Ingress Tool Transfer

Why it fails: This is about moving files to the target, not executing them.

T1204: User Execution

Why it fails: This requires user interaction, which isn't specified.

Registry key creation in RunOnce

Why it fails: This indicates persistence, not lateral movement.

Prefetch file modification

Why it fails: Prefetch tracks application execution, not authentication methods.

DNS query logs

Why it fails: These track network resolution, not authentication tokens.

Fast flux by rapidly changing the domain's A records across many IP addresses

Why it fails: Fast flux involves frequent changes to DNS records, often with short TTLs and multiple IPs, to keep malicious infrastructure alive. Here the domain resolves to a single CDN IP that also hosts legitimate services, which is more consistent with domain fronting than with fast flux.

DNS tunneling by encoding command-and-control data in DNS query names

Why it fails: DNS tunneling would show unusually long or high-entropy DNS queries and high query volume to a single domain, often with TXT records. The scenario describes periodic resolution of a new domain to a CDN IP, not data exfiltration via DNS payloads, so DNS tunneling is not the best fit.

Use of a domain generation algorithm (DGA) to create many pseudorandom domains

Why it fails: A DGA would generate numerous algorithmically created domains, often with high entropy, and the infected host would attempt to resolve many of them. The scenario describes one newly registered domain resolving to a CDN IP, which does not match the pattern of DGA-based communication.

Credential dumping from the LSASS process memory

Why it fails: Credential dumping involves tools or APIs accessing lsass.exe memory, often producing handles to that process or suspicious modules loaded into it. The scenario describes Outlook launching PowerShell, not memory access against LSASS, so this technique is not supported by the described process relationships.

Scheduled task created for persistence

Why it fails: Persistence via scheduled tasks would appear as schtasks.exe or Task Scheduler service activity creating a task, not Outlook directly spawning an encoded PowerShell child. While the PowerShell payload could later create persistence, the described parent-child relationship itself indicates initial execution, not the persistence mechanism.

Spearphishing attachment delivering a malicious macro

Why it fails: A malicious macro typically executes from an Office application such as WINWORD.EXE or EXCEL.EXE, producing a child process like cmd.exe or powershell.exe from the Office parent. Here Outlook itself is the parent, which points to a different delivery mechanism, so the macro explanation does not fit the observed process tree.

Masquerading via renamed binary, confirmed by comparing the file's hash against a known-good baseline

Why it fails: Masquerading involves a malicious file using a trusted name, but here the binary is genuinely signed and in its expected location. The signature being valid argues against masquerading. Hashing would not reveal the persistence mechanism, which is the child process writing to a startup location, so this focus is misplaced.

Scheduled task creation, confirmed by inspecting the Task Scheduler operational log for task registration events

Why it fails: Scheduled task persistence would register a task and show Event ID 106 in the Task Scheduler log. The scenario describes a file written to the Startup folder, which is a different persistence mechanism. Reviewing task registration would not explain the observed Startup folder artifact and would miss the actual technique.

Process injection, confirmed by examining the parent process's memory for unbacked executable regions

Why it fails: Process injection typically manifests as threads created in remote processes or anomalous memory regions within an existing process. Here the evidence is a child process writing a file, not injected code in a live process. Looking for unbacked memory would not confirm a file-drop persistence action and misdirects the investigation.

An email attachment with a double extension, such as invoice.pdf.exe

Why it fails: A double extension like invoice.pdf.exe is a social engineering tactic to trick users into executing a malicious file. However, this is an executable, not a document exploiting a client-side vulnerability. The scenario specifies a malicious document, so this artifact points to a different delivery method. While it may lead to compromise, it does not indicate exploitation of a document vulnerability.

An email with a link to a legitimate cloud storage service hosting a PDF

Why it fails: A link to a legitimate cloud storage service hosting a PDF is not inherently malicious. While attackers may abuse cloud services, a PDF alone is unlikely to exploit a client-side vulnerability without additional malicious content. This artifact is more indicative of a delivery mechanism, but does not by itself show exploitation. It lacks the direct code execution characteristic of a malicious document.

A firewall log showing an outbound connection to a known malicious IP on port 4444

Why it fails: An outbound connection to a malicious IP on port 4444 could indicate C2 communication after a compromise, but it does not directly show a malicious document exploiting a client-side vulnerability. It is a post-exploitation artifact. The question asks for artifacts indicative of the exploitation itself, such as macro execution or suspicious process spawning. This log entry is more relevant to later stages like C2.

Port-based blocking

Why it fails: Blocking a port fails because beaconing traffic commonly egresses over 80 or 443, which cannot be closed without breaking legitimate services. Port-based blocking suits scenarios where malware uses a distinctive, non-standard port that no business application requires.

Signature-based IDS alert

Why it fails: Signature-based IDS matches known static patterns in packet payloads; a 30-second beacon with 5% jitter varies timing enough that fixed signatures miss it. Signatures suit known malware hashes or fixed strings. Detecting periodic beaconing instead needs behavioural or statistical analysis of connection intervals.

Static IP blocklisting

Why it fails: Static blocklists require prior knowledge of the destination IP, so a previously unseen command-and-control server evades them; the beaconing interval itself is the detectable artefact. Blocklisting suits known-bad indicators, such as a documented malicious IP from threat intelligence, not behavioural patterns.

An attempted DDoS attack

Why it fails: Sinkhole traffic signals a host already communicating with a command-and-control server, meaning compromise and containment, not volumetric attack traffic. DDoS detection relies on aggregate bandwidth or connection floods toward a target, so this option misreads the indicator entirely.

A network misconfiguration

Why it fails: Sinkhole traffic indicates a host is attempting to reach command-and-control infrastructure, so the endpoint is likely compromised. Misconfiguration produces erratic or failed connectivity, not repeated contact with a known malicious address. This option would fit a question about routing errors or firewall rule mistakes.

A successful data exfiltration

Why it fails: Sinkhole redirection shows a host attempting to reach attacker infrastructure, so no data has left the environment yet. Exfiltration requires confirmed outbound transfer of sensitive data to an external destination, which this indicator alone cannot establish.

Data exfiltration indicator

Why it fails: Brute-force followed by a successful login is an authentication or access indicator, not exfiltration; no data transfer or outbound volume anomaly is described. Data exfiltration indicators cover large or unusual outbound transfers, such as spikes in uploaded bytes to external hosts, which would fit a confirmed data-theft scenario.

Network anomaly signature

Why it fails: A network anomaly signature describes deviations in traffic patterns such as unusual protocols or volumes, not authentication sequences. This category fits when baselining reveals unexpected port scans or beaconing, whereas the failed-then-successful login pattern is an authentication-based indicator.

System resource exhaustion

Why it fails: Resource exhaustion covers CPU, memory or disk depletion indicators, not login behaviour; the log evidence here is purely authentication events. This category is the right classification when monitoring shows sustained high utilisation or service crashes caused by an overloaded host.

malware.exe

Why it fails: A file named malware.exe is obviously third-party tooling, directly opposing LotL, which uses signed, pre-installed system binaries to blend in. It tempts as a generic indicator of compromise, and would be correct when the scenario describes conventional malware delivery rather than native utility abuse.

mimikatz.exe

Why it fails: Mimikatz is a downloaded credential-dumping tool, not a native OS binary, so its presence contradicts LotL methodology. It tempts because it is a well-known post-exploitation indicator, and would be correct when hunting for dedicated attacker tooling rather than abuse of built-in system utilities.

netcat.exe

Why it fails: Netcat is a separate executable an attacker must upload or install, whereas LotL relies on binaries already present on the host. It tempts because it is a classic tool for reverse shells and data transfer, and would be correct when investigating custom tooling rather than native command abuse.

Delete the file

Why it fails: Deleting the file removes evidence and may trigger reinfection from the persistence mechanism that placed it there, while the running process continues. The option tempts because it appears to eliminate the threat immediately, but proper handling isolates the host and preserves the sample for forensic analysis before removal.

Update antivirus signatures

Why it fails: Updating signatures does not terminate the already-running malicious process or contain the host; the malware keeps consuming CPU and communicating. The option tempts because signature updates are routine hygiene, but scanning cannot act on an active intrusion. Immediate containment means isolating the server and killing the process.

Restart the server

Why it fails: Restarting destroys volatile evidence such as running processes, network connections and memory contents, and the malicious binary may relaunch from persistence. The option tempts as a quick way to clear high CPU, but containment requires isolating the host and capturing memory before any reboot, not blindly cycling the machine.

Deploying a remote access trojan

Why it fails: Deploying a remote access trojan is Installation, establishing persistent access on the compromised host. It is tempting because trojans feature heavily in intrusion reports, but Reconnaissance occurs before any payload reaches the target, encompassing information gathering such as scanning, OSINT collection and identifying exploitable services.

Exploiting a software vulnerability

Why it fails: Exploiting a software vulnerability is the Exploitation phase, where the adversary weaponises an entry point to execute code. It is tempting because exploitation follows directly from delivery, but Reconnaissance is earlier: the adversary passively or actively gathers information about the target before any intrusion attempt.

Encrypting data for ransom

Why it fails: Encrypting data for ransom is the Actions on Objectives phase, where the adversary achieves financial impact after establishing persistence. It is tempting because ransomware dominates breach reporting, yet Reconnaissance precedes delivery entirely, covering target research such as harvesting employee details, domains and technologies.

Mutex name

Why it fails: A mutex name is a host-based artefact used by malware to prevent multiple instances, not a network indicator. It is tempting because mutexes are valuable for host forensic analysis, and would be correct when identifying malicious processes on an infected endpoint rather than network traffic.

Registry key path

Why it fails: A registry key path is a host-based artefact recorded in the Windows registry, not network traffic. It is tempting because registry persistence is a common malware indicator, and would be the correct category for host-based IoCs alongside file hashes and mutex names.

File hash (SHA-256)

Why it fails: A SHA-256 file hash identifies a file on disk, making it host-based rather than network-based. It is tempting because hashes are widely used to detect malicious payloads, and would be correct when hunting for known files across endpoints instead of monitoring network traffic.

explorer.exe

Why it fails: explorer.exe launches Office applications from the shell, but the macro payload is spawned by the Office application process itself, not by explorer. Explorer is tempting because it is the parent of the initial WINWORD.EXE launch, yet the payload's parent is the Office process.

wininit.exe

Why it fails: wininit.exe initialises user-mode Windows startup and is the parent of services.exe and lsass.exe, not of Office applications or their macro payloads. It is tempting as a known system parent process, but it is relevant to session and service initialisation, not document execution.

svchost.exe

Why it fails: svchost.exe hosts Windows services and does not spawn Office child processes, so it cannot be the parent of a macro payload. It is tempting because service host processes appear in many investigations, but it is relevant to service-based persistence, not document macro execution.

Man-in-the-Middle (MitM)

Why it fails: MitM intercepts or alters traffic between two parties in transit; it does not persist an unsigned extension on the endpoint or change homepage settings. It is tempting because MitM can inject content into unencrypted sessions, but that injection is transient. Here the malicious extension is installed locally, which is a different methodology.

Cross-Site Scripting (XSS)

Why it fails: XSS targets web application vulnerabilities.

SQL Injection

Why it fails: SQL Injection manipulates backend database queries through unsanitised input; it cannot install a browser extension or modify homepage configuration on a client. It is tempting because SQLi is a headline web attack and the scenario involves a browser, but the affected component is the endpoint, not a database.

Exploiting a zero-day vulnerability

Why it fails: Exploiting a zero-day vulnerability belongs to initial access or execution, not command and control, which establishes a channel for issuing instructions to compromised hosts. It is tempting because zero-days grant code execution, and that step would be the correct choice when asked which phase delivers the initial foothold.

Gathering system information

Why it fails: System information gathering belongs to Discovery, which runs before or alongside C2 to map the environment. C2's goals are establishing a covert channel and receiving attacker instructions. Discovery is tempting because it also uses the compromised host, but it is a separate phase with its own objectives.

Encrypting files for ransom

Why it fails: Ransomware encryption occurs in the Actions on Objectives phase, after C2 has already established a channel. C2's goals are maintaining remote access and issuing instructions to compromised hosts. Encryption for extortion is tempting because it is the visible payoff of an intrusion, but it is a later-stage impact, not a C2 objective.

Memory corruption

Why it fails: Memory corruption would not leave a coherent shimcache path referencing a specific absent volume; the entry is written to disk from normal execution tracking. Corruption is tempting because it also yields unexpected forensic artefacts, and it would be indicated by malformed entries or checksum failures across multiple records.

Log manipulation

Why it fails: Shimcache is populated by the application-compatibility engine from observed execution, not by log-writing processes, so deliberate log manipulation would not create this entry. Log tampering is tempting because it also produces missing or altered records, and it would be shown by cleared event logs or timestamp inconsistencies.

System update failure

Why it fails: Shimcache records execution paths, not update outcomes, so a missing volume reflects a drive that was removed or remounted, not a failed system update. Update failure is tempting because it also leaves inconsistent artefacts, and it would be indicated by rollback logs or pending-update registry entries.

Multiple failed login attempts

Why it fails: Failed logins indicate credential-guessing or brute-force against authentication, not bulk data leaving the environment. It is tempting because repeated authentication failures are a genuine security signal, but they belong to intrusion-detection scenarios; exfiltration indicators instead include large outbound transfers or unusual destination traffic.

System clock synchronization errors

Why it fails: Clock synchronisation errors indicate NTP or time-drift faults, not data leaving the environment. The option tempts because exfiltration tooling can disturb system timing, but genuine indicators are large outbound transfers, unusual destinations or unexpected protocol use, so this is unrelated.

Installation of new system drivers

Why it fails: Driver installation alters host or kernel configuration, which points to persistence or privilege escalation rather than data leaving the network. It is tempting because unauthorised driver changes are a real endpoint-compromise indicator, but exfiltration is evidenced by anomalous outbound volume or transfers to external destinations.

Automated mass-scale scanning

Why it fails: APTs use targeted, manual, low-and-slow intrusion against chosen victims; automated mass-scale scanning is opportunistic commodity activity such as worm propagation or botnet recruitment. It tempts because APTs do scan, but selectively and stealthily. Mass scanning would be the correct characterisation for untargeted campaigns, not a persistent threat actor.

Immediate data destruction

Why it fails: APTs pursue long-term espionage and persistence, exfiltrating data quietly over months; immediate destruction describes destructive malware such as wipers, not APT methodology. It is tempting because ransomware and hacktivist attacks do destroy data, but that scenario concerns disruption, not the stealthy, sustained intrusion an APT represents.

Network interface throughput

Why it fails: Network interface throughput measures traffic volume, not the configuration changes persistence mechanisms leave behind. It is tempting because throughput monitoring is the right choice for detecting data exfiltration or denial-of-service conditions, but it cannot reveal scheduled tasks, services, or startup entries.

Browser history logs

Why it fails: Browser history records user web activity, not the host or account changes persistence mechanisms create. It is tempting because browser history is a valuable artifact for investigating phishing or drive-by compromise, making it the correct choice in a user-activity timeline, but it reveals nothing about scheduled tasks or registry run keys.