Network Incidents practice questions

rule-name

Why it fails: This indicates which security policy allowed the traffic.

action

Why it fails: Action indicates whether the traffic was allowed or dropped.

source-ip

Why it fails: Source-ip identifies the host, not the application context.

PROTOCOL

Why it fails: This field indicates the Layer 4 protocol used.

IPV4_SRC_ADDR

Why it fails: This field indicates the source address, not the volume.

LAST_SWITCHED

Why it fails: This indicates timing, not data volume.

filter smb-exploit

Why it fails: This is not a standard Cisco ASA command.

access-list permit any

Why it fails: This only permits traffic without performing inspection.

nat dynamic

Why it fails: NAT is used for address translation, not deep packet inspection.

shutdown vlan 99

Why it fails: This command does not exist.

vlan isolation enable

Why it fails: This is not a valid IOS command.

switchport trunk vlan 99

Why it fails: This command is for trunking, not isolating access ports.

SMB_COM_OPEN

Why it fails: SMB_COM_OPEN is a legacy SMB1 file-open request carrying no NTLM authentication fields, so it cannot evidence Pass-the-Hash. It is tempting because it appears in SMB traffic captures, and it would be relevant when investigating file access or share enumeration rather than credential-reuse authentication exchanges.

NTLMSSP_NEGOTIATE

Why it fails: NTLMSSP_NEGOTIATE merely opens the NTLM exchange and advertises supported capabilities; it carries no credential material, so it cannot evidence hash reuse. It is tempting as the first NTLM message seen in SMB traffic, and would be relevant when fingerprinting authentication negotiation rather than detecting Pass-the-Hash.

SMB_COM_TREE_CONNECT

Why it fails: SMB_COM_TREE_CONNECT merely binds a client to a share after session setup, so it carries no NTLM credential material to analyse for Pass-the-Hash. It is tempting because tree connects appear throughout SMB traffic, but the hash-reuse evidence sits in the SMB_COM_SESSION_SETUP_ANDX exchange containing the NTLMSSP authentication messages.

snmp-server enable

Why it fails: SNMP is for management, not security mitigation.

ip access-group

Why it fails: This is for Layer 3 filtering, not Layer 2 ARP mitigation.

switchport port-security

Why it fails: While it limits MAC addresses per port, it is not the primary defense against ARP spoofing.

Event ID 1000 (Application Error)

Why it fails: This tracks software crashes.

Event ID 4688 (Process Creation)

Why it fails: While useful, it is not as specific as logins and service installs for lateral movement.

Event ID 1102 (Log Cleared)

Why it fails: This is an anti-forensics indicator, not specifically lateral movement.

Using clear-text Telnet for all communication

Why it fails: Telnet is easily detectable and rarely used for hiding traffic.

Sending traffic exclusively during business hours

Why it fails: This makes traffic look like user activity, but is not a method for 'hiding' the traffic itself.

Disabling all logging on the source host

Why it fails: This is an anti-forensics technique, not a way to hide network traffic.

Check if the disk is full

Why it fails: Disk fullness would stop logging, not detection.

Reboot the IDS appliance

Why it fails: Rebooting is a troubleshooting step, but checking visibility is the root-cause action.

Ensure NTP is synchronized

Why it fails: NTP is for time, not detection logic.

The HTTP User-Agent string used by the internal host

Why it fails: The User-Agent string is part of HTTP headers, but in HTTPS traffic, it is encrypted unless TLS inspection is performed. Even with inspection, User-Agent can be spoofed and is not a reliable indicator of exfiltration. It may help identify the client application, but it does not directly reveal the exfiltration channel or destination.

The total number of bytes transferred during the session

Why it fails: While a large data transfer might indicate exfiltration, many legitimate activities also transfer large amounts of data. Byte count alone does not distinguish malicious exfiltration from normal traffic. It is a supporting indicator but not the best artifact to identify the specific channel, especially without context about the destination or content.

The source IP address and port number of the internal host

Why it fails: While source IP and port can identify the internal host involved, they do not reveal the content or destination of the exfiltration. Many hosts could be using similar ports, and the port number alone does not indicate malicious activity. This information is too generic to pinpoint the exfiltration channel without additional context.

TCP RST flood denial-of-service attack

Why it fails: A TCP RST flood would typically involve a high volume of RST packets targeting a single victim to disrupt connections. Here, the RST packets are originating from an internal server and going to various external IPs, which is not the typical pattern of a DoS attack against the server itself. The server is the source, not the target, so a RST flood against it is unlikely.

TCP SYN scan with RST responses

Why it fails: A TCP SYN scan would involve the server sending SYN packets, not RST packets. The scenario states the server is not responding to SYN packets, so it is not initiating scans. RST responses would be sent by a target to a scanner, but here the server is the source of RSTs to many external IPs, which is inconsistent with a scan.

TCP SYN flood denial-of-service attack

Why it fails: A TCP SYN flood involves sending a large number of SYN packets to a target to exhaust its connection table. The scenario describes RST packets, not SYN packets, and the server is the source, not the target. Therefore, this is not a SYN flood. The absence of SYN responses from the server further rules out a SYN flood originating from it.

Run a full antivirus scan on the workstation to remove the malware.

Why it fails: A full antivirus scan may remove the malware but does not address the active network C2 channel. The attacker could still communicate and exfiltrate data during the scan. Moreover, scanning can alter volatile evidence and is not a containment action; containment must first sever the adversary's access.

Immediately disable the switch port where the workstation is connected.

Why it fails: Disabling the switch port would sever all network connectivity, including the C2 channel, but it also destroys the ability to capture ongoing traffic and may alert the attacker. The responder should first collect volatile evidence and then isolate; immediate port shutdown is premature and can cause loss of critical network artifacts.

Reboot the workstation to terminate the malicious process.

Why it fails: Rebooting terminates the process but also destroys volatile memory evidence, including running processes, network connections, and encryption keys. It does not prevent the malware from restarting via persistence mechanisms, and the C2 channel could be re-established after reboot. This action is not a controlled containment step.

TCP sequence number prediction attack

Why it fails: Sequence number prediction attacks involve guessing the next sequence number to inject packets into a session, but the attacker must still use incrementing sequence numbers that match the receiver's expectations. Static sequence numbers would immediately desynchronize the session and cause the receiver to drop the packets. This attack is about predicting future values, not reusing the same value repeatedly.

TCP session hijacking

Why it fails: TCP session hijacking involves an attacker injecting packets with the correct sequence and acknowledgment numbers to take over an established session. It typically results in desynchronization between the legitimate endpoints, not in repeated identical sequence numbers across consecutive packets. The pattern described—static sequence numbers with varying payload sizes—is not characteristic of hijacking, which requires precise sequence alignment rather than static values.

TCP retransmission storm

Why it fails: A TCP retransmission storm occurs when multiple packets with the same sequence number are sent because acknowledgments are not received, but the payload sizes are typically identical for each retransmission. The scenario specifies varying payload sizes, which contradicts a simple retransmission. Retransmissions also usually show decreasing frequency over time as the sender backs off, not a static pattern with changing payloads.

A covert channel using TCP PSH flag to transmit data.

Why it fails: The PSH flag is a standard TCP mechanism to push data to the application layer and is not inherently covert. Attackers may abuse it, but the regular interval and small encrypted payloads over port 443 suggest a beaconing pattern, not just PSH abuse. The PSH flag alone is not a strong indicator of a covert channel.

A denial-of-service attack using TCP SYN flood.

Why it fails: A SYN flood involves a high volume of TCP SYN packets to exhaust resources, not regular small encrypted payloads. The observed traffic is low-volume and periodic, which is inconsistent with a DoS attack. SYN floods typically target a service and cause resource exhaustion, not stealthy data transfer.

A legitimate software update check.

Why it fails: Legitimate update checks often occur at longer intervals (e.g., hours) and may transfer larger files. The 30-second interval is unusually frequent for software updates and is more consistent with malware beaconing. Additionally, the small encrypted payloads and external IP suggest malicious C2 rather than routine updates.

Cross-site scripting (XSS)

Why it fails: Cross-site scripting is a web application vulnerability that allows attackers to inject client-side scripts into web pages viewed by other users. It is not a lateral movement technique in a Windows environment; it is typically used for session hijacking or defacement. Lateral movement requires moving between hosts, which XSS does not directly enable in the context of an internal network.

Kerberoasting

Why it fails: Kerberoasting is a technique used to extract service account credentials by requesting Kerberos service tickets and cracking them offline. While it can lead to privilege escalation and potentially lateral movement, it is primarily a credential access technique, not a direct lateral movement method. The question asks for lateral movement techniques, and Kerberoasting is more about obtaining credentials for later use.

SQL injection

Why it fails: SQL injection is a web application attack that targets databases by injecting malicious SQL queries. It is not a lateral movement technique in a Windows environment; rather, it is an initial access or data exfiltration method. Lateral movement involves moving from one compromised host to another, which SQL injection does not directly facilitate unless it leads to code execution on the database server, but that is not the primary goal.

ICMP flood denial-of-service attack

Why it fails: An ICMP flood typically involves a high volume of ICMP echo requests to a single target to exhaust its resources. Here, the requests are sent to various external IPs, which is not the typical pattern of a DoS attack against one victim. The large payload size might cause fragmentation, but the distribution across multiple destinations suggests a different purpose, such as tunneling or scanning.

Network reconnaissance via ICMP ping sweep

Why it fails: A ping sweep involves sending ICMP echo requests to multiple hosts to identify live systems, but the payload is typically small and standard. The large payload size of 1500 bytes is not characteristic of a simple ping sweep; it suggests data is being carried. While a sweep targets multiple IPs, the large payload is the distinguishing factor that points to tunneling rather than reconnaissance.

Smurf attack amplification

Why it fails: A Smurf attack uses ICMP echo requests with a spoofed source IP (the victim) sent to a broadcast address, causing many hosts to reply to the victim. In this scenario, the requests are sent to various external IPs, not a broadcast address, and the source is the internal host itself, not spoofed. The large payload also does not align with a Smurf attack, which typically uses small packets.

Block outbound DNS queries from the internal host at the firewall.

Why it fails: Blocking all outbound DNS queries from the host would disrupt the DGA but also prevent legitimate DNS resolution, causing operational issues. It is a blunt approach that may not be necessary if the malicious domains can be blocked specifically. Moreover, the host might use other DNS servers, so a more targeted block is better.

Disable the DNS service on the internal host.

Why it fails: Disabling the DNS service on the host would prevent all DNS resolution, causing significant operational disruption. It is not a network-based containment action and does not address the root cause. The host may also use a hardcoded DNS server, bypassing the local service.

Apply a firewall rule to block all outbound traffic from the internal host.

Why it fails: Blocking all outbound traffic is overly broad and would disrupt all network communications from the host, including legitimate business traffic. It is not a targeted containment and could cause more harm than good. A more surgical block on DNS or specific domains is preferred.

Snort with the 'flow:stateless' option

Why it fails: Snort is an intrusion detection system, but the 'flow:stateless' option disables stateful inspection, which is necessary to track half-open connections. A SYN flood is best detected with stateful analysis that monitors the number of SYN packets without corresponding ACKs. Using stateless mode would not effectively detect the flood, as it treats each packet independently and cannot correlate the lack of completed handshakes.

NetFlow analyzer monitoring TCP flags

Why it fails: NetFlow records provide summary information about flows, including TCP flags, but they are typically sampled and may not capture every SYN packet. While NetFlow can show a high volume of SYN flows, it does not track half-open connections per se and may miss the detailed pattern of a SYN flood. It is more useful for volumetric analysis and traffic profiling than for real-time detection of SYN floods with spoofed sources.

tcpdump with a filter for 'tcp[tcpflags] & tcp-syn != 0'

Why it fails: tcpdump can capture SYN packets, but it only provides raw packet data and does not track half-open connections or generate alerts. An incident responder would need to manually analyze the output to detect a SYN flood, which is time-consuming and not automated. tcpdump is a packet capture tool, not an intrusion detection system, so it lacks the stateful analysis required to identify a SYN flood attack in real-time.

A legitimate network device performing TCP reset for load balancing.

Why it fails: Load balancers may send RST packets to reset connections when a server is unavailable, but they typically do so in the context of established connections and from known load balancer IPs. The external IP and random targeting of internal hosts make this unlikely. Legitimate devices would not send RST packets to arbitrary ports on multiple hosts.

A misconfigured firewall sending RST packets.

Why it fails: A misconfigured firewall might send RST packets in response to blocked traffic, but it would typically send them in response to connection attempts, not unsolicited to various hosts and ports. The pattern described suggests intentional disruption rather than a simple misconfiguration. Firewalls usually send RST to the source of the connection attempt, not to multiple internal hosts.

A port scan using TCP RST packets.

Why it fails: Port scans typically use SYN, FIN, XMAS, or NULL packets, not RST packets. RST packets are used to reset connections, not to probe ports. An attacker might send RST packets to disrupt connections, but a port scan would not rely solely on RST. This option mischaracterizes the technique.

Use of non-standard ports for HTTPS traffic

Why it fails: While attackers may use non-standard ports to evade basic filtering, many legitimate services also use non-standard ports for HTTPS. Moreover, modern exfiltration often uses standard ports like 443 to blend in. The use of non-standard ports is a weak indicator on its own and can be easily changed by the attacker. It does not provide definitive evidence of exfiltration without additional context such as traffic volume or destination reputation.

Periodic outbound connections to a specific IP with consistent packet sizes

Why it fails: Periodic connections with consistent packet sizes can indicate beaconing, but they are not specific to exfiltration. Many legitimate applications, such as software updates or heartbeat mechanisms, exhibit similar patterns. Exfiltration often involves large, asymmetric data transfers, not necessarily consistent sizes. Relying solely on periodicity and packet size may lead to false positives and miss exfiltration that uses variable timing or sizes to evade detection.

Presence of TLS heartbeat extensions in the ClientHello

Why it fails: TLS heartbeat extensions are used for keep-alive and are common in many legitimate TLS implementations. Their presence does not indicate malicious activity; they are part of standard TLS. Attackers might exploit heartbeat vulnerabilities (e.g., Heartbleed), but that is a separate issue from exfiltration. The presence of this extension is not a reliable indicator of data exfiltration and would generate false positives.