Scenario practice questions

Installation

Why it fails: Installation covers establishing persistence on the victim host, such as installing a backdoor or remote-access trojan. The FTP transfer is outbound exfiltration, which is Actions on Objectives. It is tempting because installation follows exploitation, but no persistence mechanism is evidenced in the PCAP.

Weaponization

Why it fails: Weaponization covers coupling an exploit with a deliverable payload before delivery; the FTP transfer is exfiltration of data already collected, which is the Actions on Objectives phase. It is tempting because weaponization precedes delivery, but no exploit or payload creation appears in this traffic.

Exploitation

Why it fails: Exploitation is the phase where a vulnerability is triggered to gain access; the outbound FTP transfer shows data already being removed, which is Actions on Objectives. It is tempting because exploitation often precedes exfiltration, but the capture shows no exploit delivery or code execution.

The access-group 'OUTSIDE_IN' permitted the traffic.

Why it fails: Deny indicates blocked.

An internal host attempted to connect to an external web server.

Why it fails: Source is outside, destination is inside.

The ASA allowed the connection because it is a stateful firewall.

Why it fails: Log says 'Deny'.

HIPAA

Why it fails: HIPAA protects US healthcare information, not EU citizens' personal data. It is tempting because both are privacy regulations with breach notification duties, but HIPAA applies to protected health information held by covered entities; the scenario describes GDPR, which governs processing of EU residents' personal data.

ISO 27001

Why it fails: ISO 27001 is a voluntary information security management certification, not a privacy regulation imposing legal obligations. It is tempting because it covers data protection controls, but certification does not satisfy statutory EU privacy requirements; GDPR is the binding regulation governing EU citizens' personal data processing.

PCI DSS

Why it fails: PCI DSS governs payment card data handling, not EU citizen privacy. It is tempting because both are regulatory compliance frameworks with audit requirements, but PCI DSS applies to cardholder data environments; the EU privacy regulation described is GDPR, which mandates lawful processing of personal data.

MitM

Why it fails: MitM intercepts or alters traffic between two parties, which does not explain a server becoming unresponsive under volume. It tempts because it also involves an adversary positioned in the traffic path, and would be correct where credentials or sessions are being silently intercepted and relayed.

DoS

Why it fails: A DoS attack originates from a single source, whereas the stem specifies multiple compromised systems generating the traffic. It tempts because the symptom — a server overwhelmed and unresponsive to legitimate users — matches DoS exactly, and it would be correct if only one attacking host were involved.

Botnet

Why it fails: A botnet is the collection of compromised hosts itself, not the attack category; the question asks what type of attack overwhelms the server. It tempts because the stem mentions multiple compromised systems, and botnet would be correct if asked to name the infrastructure launching the traffic.

It stores threat intelligence locally

Why it fails: TAXII is a client-server exchange protocol, not a storage repository; local retention of intelligence is a function of the consuming platform or TIP. It would be correct if the scenario asked where an organisation keeps its own indicators, rather than how it shares them with an ISAC.

It is a platform for malware analysis

Why it fails: TAXII is a transport protocol defining how threat intelligence is exchanged over HTTPS between servers and clients; it performs no malware analysis. It would be the right answer if the question asked how STIX content is transmitted to the ISAC, rather than what analyses the shared data.

It defines the format for threat indicators

Why it fails: STIX, not TAXII, defines the structured schema and objects describing threat indicators, observables and relationships. TAXII specifies the API and collection services used to transport that STIX content. Choosing this confuses the data model with the exchange protocol, which is the axis the question tests.

Deploy the patch only at the end of the business day

Why it fails: Deferring to the end of the business day delays remediation of an actively exploited vulnerability, extending exposure beyond what an emergency change permits. It is tempting because it limits disruption, but it would be correct for routine patches where business-hours impact outweighs the urgency of immediate deployment.

Wait for the next scheduled change window

Why it fails: Waiting for the next scheduled window leaves a widely exploited vulnerability unpatched, contradicting the emergency change path that critical patches require. It is tempting because it follows routine change governance, but it would be correct for low-risk, non-urgent updates where no active exploitation is occurring.

Install the patch without approval

Why it fails: Installing without approval bypasses the change management process entirely, removing the authorisation and documentation that emergency changes still require. It is tempting because speed matters for exploited vulnerabilities, but it would be correct only under a formally invoked emergency change procedure with retrospective approval.

It self-replicates without user interaction.

Why it fails: Self-replication without user interaction defines worms, not trojans; a trojan relies on user execution and does not propagate itself. It is tempting because rapid spread is commonly associated with malware outbreaks, and it would be correct if the sample propagated autonomously across hosts via network exploits.

It encrypts files and demands ransom.

Why it fails: Ransomware encryption is a distinct behaviour; the stem describes a trojan with downloader and remote-access capability, with no file encryption or extortion. It is tempting because ransomware is high-profile malware, and it would be correct if the analyst observed mass file encryption plus a ransom note.

Confidentiality

Why it fails: Confidentiality protects data from unauthorised disclosure. Here the insider modified records and ransomware encrypted the database; neither event exposed records to unauthorised readers, so disclosure did not occur. Confidentiality would be violated by a breach that actually leaked patient data.

Authentication

Why it fails: Authentication verifies a claimed identity at login. The insider was already an authorised user with valid credentials, and ransomware does not defeat login checks, so identity verification functioned. Authentication would be the violated principle if attackers had logged in using stolen or forged credentials.

Non-repudiation

Why it fails: Non-repudiation proves a specific party performed an action, typically via digital signatures or audit trails binding identity to data. The scenario describes integrity loss and availability loss, not a sender denying an action, so no repudiation dispute arises here.

ARP spoofing

Why it fails: ARP spoofing poisons the local ARP cache to redirect Layer 2 traffic, enabling interception, but modification requires the attacker to relay altered frames onward, which the stem's on-path tampering describes as a man-in-the-middle attack. ARP spoofing is tempting as the classic LAN interception technique, yet it is the enabling mechanism, not the attack type named.

DNS poisoning

Why it fails: DNS poisoning corrupts resolver records so clients reach attacker-controlled destinations, which redirects name resolution rather than intercepting and altering an established session between two devices. It is tempting because it enables redirection, but the stem's on-path modification of live communications indicates a man-in-the-middle attack.

Denial of Service (DoS)

Why it fails: A DoS attack exhausts resources or bandwidth to make a service unavailable, producing outages rather than silent interception and modification of traffic between two devices. It is tempting because flooding tools can disrupt communications, but the stem describes confidentiality and integrity compromise, not availability loss.

Excessive connection attempts from a single IP

Why it fails: Excessive connection attempts from a single IP is a signature of scanning or brute-force activity, an anomaly rather than a normal-traffic metric. It is tempting because connection counts feed intrusion detection, which would be correct when alerting on deviations from an established baseline, not when building it.

Peak traffic times

Why it fails: Peak traffic times record when volume is highest, not the recurring volume, protocol and flow characteristics that constitute a traffic baseline. It is tempting because timing data supports capacity planning and scheduling, which would be correct for that purpose rather than for establishing normal-traffic metrics.

Unusual payload sizes

Why it fails: Unusual payload sizes describe anomalies deviating from established norms, so they cannot define the baseline itself. It is tempting because payload size analysis supports anomaly detection, which would be correct when comparing live traffic against an already-documented baseline rather than constructing one.

Brute force

Why it fails: Brute force guesses credentials against authentication services; here the host submits captured NTLM hashes directly, which is pass-the-hash. It is tempting because repeated SMB authentication failures resemble password guessing, and would be correct if plaintext passwords were being tried rather than replayed hashes.

Kerberoasting

Why it fails: Kerberoasting requests Kerberos service tickets for offline cracking of service account passwords; it does not relay NTLM hashes over SMB to other hosts. It is tempting as a credential-access technique, and would be correct when targeting SPNs with weak service account passwords rather than performing lateral movement via hash relay.

Golden ticket attack

Why it fails: A golden ticket forges a Kerberos TGT using the KRBTGT hash, so authentication would appear as Kerberos, not NTLM relayed over SMB. It is tempting because it grants domain-wide persistence, and would be correct after full domain compromise when forging tickets rather than relaying captured hashes.

Destination port is well-known

Why it fails: Restricting to well-known ports narrows scanning detection to a small fixed range, missing scans that sweep ephemeral or high ports. It is tempting because common service ports are frequently targeted, but the rule must count many distinct destination ports regardless of their number.

Average packet count per connection is high (e.g., >100)

Why it fails: A high average packet count per connection describes data-heavy sessions, not scanning, which typically sends single small probes. It is tempting as an anomaly threshold, but the rule needs many distinct destination ports across multiple hosts from one source within a short window.

Network share access event

Why it fails: Share access is unrelated to the credential sequence: the stem's three events are failed authentications, a successful login and privilege escalation. Share access is the right correlation when investigating data exfiltration or ransomware staging, where file-share reads follow compromise rather than authentication anomalies.

Account creation event

Why it fails: Account creation is a separate identity lifecycle event; the stem already names failed authentications, successful login and privilege escalation as the trio. Account creation is the correct pivot when hunting persistence, where an attacker provisions a new backdoor account after gaining a foothold.

A successful HTTP connection from the outside to the inside server

Why it fails: The message direction and interface fields show an outbound connection initiated from the inside, so it does not describe inbound HTTP reaching an internal server. A successful inbound connection is tempting because ASA logs do record permitted web traffic, but the source and destination ordering here is reversed.

A VPN tunnel initiation that was rejected due to authentication failure

Why it fails: The entry shows a connection being built, not an IKE or IPsec negotiation failure; VPN authentication rejections produce different message IDs. A rejected tunnel is tempting because ASA logs do record VPN events, but this syslog concerns regular session setup rather than tunnel establishment.

A NAT translation failure for an outbound connection

Why it fails: The syslog entry records a permitted connection being built, not a NAT failure; translation errors generate distinct messages. A NAT failure is tempting because ASA logs do cover address translation, but this entry's fields describe session creation for traffic that was allowed through.

C2 beaconing

Why it fails: C2 beaconing produces small, regular callbacks to a controller, not bulk FTP transfers of document-named files. It is tempting because beaconing is the classic sign of external command-and-control, but it would be the right answer only for periodic, low-volume, fixed-interval connections rather than sustained exfiltration of internal data.

Normal backup operation

Why it fails: Backups normally run to internal servers or sanctioned cloud endpoints over scheduled windows, not to an arbitrary external IP via FTP. It is tempting because bulk outbound file transfer resembles backup traffic, but it would be correct only where the destination is an approved backup host and the timing matches a defined job.

Port scanning

Why it fails: Port scanning sends small probes across many ports and hosts to map services; it does not transfer document files to one external address. It is tempting because scanning is also suspicious outbound activity, but it would be correct only for reconnaissance traffic showing varied ports and connection attempts, not sustained FTP data transfer.

Monitor alerts and perform initial triage

Why it fails: Monitoring alerts and performing initial triage is the Tier 1 function already completed before escalation. Tier 2 receives the escalated case to investigate and determine whether the failed logons indicate compromise, so this option simply restates the work the Tier 1 analyst has already done.

Make decisions on business impact and notification

Why it fails: Business impact decisions and notifications sit with SOC management or the incident response lead, not Tier 2. Tier 2's task is technical investigation of the escalated failed-login alert; this option describes an escalation-authority responsibility beyond that analyst's remit.

Conduct threat hunting and advanced forensics

Why it fails: Threat hunting and advanced forensics belong to Tier 3, which proactively searches for undetected threats rather than validating an escalated alert. Tier 2's role here is scoping and containing the failed-login activity, so this option misassigns the escalation tier's duty to a later, proactive function.

Reconnaissance

Why it fails: Reconnaissance gathers information through scanning or enumeration without overwhelming the authentication service; repeated failed logins causing unresponsiveness is not information gathering. It is tempting because scanning often precedes authentication attacks, but here the server degradation itself contradicts passive discovery.

Brute force attack

Why it fails: A brute force attack systematically guesses credentials, but the stem describes volume-driven resource exhaustion from one source, which is a denial-of-service pattern rather than credential guessing. It is tempting because failed logins feature in both, yet brute force targets account compromise, not server unavailability.

Man-in-the-middle

Why it fails: A man-in-the-middle intercepts or relays traffic between two parties, requiring positioning within the communication path; it does not generate volume failed logins that exhaust an authentication server. It is tempting whenever credentials are involved, but no interception or session manipulation is described.

Remote administration

Why it fails: Remote administration over SSH is interactive and low-volume; large sustained outbound transfers during non-business hours indicate exfiltration or tunnelling over port 22, not routine admin sessions. Remote administration would fit brief, sporadic connections to known management hosts, not bulk data leaving to an external IP.

DNS query

Why it fails: DNS uses port 53.

FTP file transfer

Why it fails: FTP transfers use TCP ports 20 and 21, not 22, so the observed traffic cannot be FTP. The large outbound volume on 22 points to SSH-based transfer. FTP would be the answer had the analyst seen port 21 control and port 20 data channels.

Reconnaissance

Why it fails: Reconnaissance covers information gathering such as scanning and enumeration before an exploit, so it produces no interception or alteration of traffic. It would be correct if the analyst saw port scans or footprinting activity, but the described on-path modification of communications between two hosts points to a man-in-the-middle technique.

ARP spoofing

Why it fails: ARP spoofing is a technique used in MitM, but not the overall attack.

DNS poisoning

Why it fails: DNS poisoning corrupts resolver caches so name lookups return attacker-controlled addresses, redirecting victims to rogue hosts. It would fit if logs showed falsified DNS responses. Here the attacker is intercepting and modifying traffic between two devices on the same segment, which is on-path manipulation rather than name resolution tampering.

A parent process with a valid digital signature

Why it fails: A valid digital signature indicates a legitimately signed binary, which is a benign indicator rather than a malicious characteristic; attackers often use unsigned or stolen-certificate binaries. It is tempting because signature checks are part of triage, but a valid signature alone neither confirms nor suggests compromise.

A process with a long uptime and low CPU usage

Why it fails: Long uptime with low CPU usage describes a stable, idle legitimate process such as a service; malicious processes more often show short lifetimes, high CPU, or unusual network activity. It is tempting because persistence mechanisms do run quietly, but these metrics alone are not a recognised malicious indicator.

A process chain where the parent is svchost.exe and child is explorer.exe

Why it fails: svchost.exe spawning explorer.exe inverts the normal relationship: explorer.exe is the user shell and typically launches svchost-hosted services indirectly, so this chain suggests injection or masquerading. It is tempting because svchost.exe is a legitimate host process, but its presence as a parent of explorer.exe is the anomaly.