Refer to the Exhibit Practice Questions

SSL/TLS renegotiation DoS

Why wrong: An SSL/TLS renegotiation DoS specifically exploits the resource-intensive process of re-establishing cryptographic parameters within an existing secure session. This attack involves repeatedly requesting renegotiations, forcing the server to expend significant CPU cycles on cryptographic operations, leading to resource exhaustion. However, the scenario describes multiple *established* connections from distinct IPs, not a pattern of repeated renegotiation requests, which is the hallmark of this particular DoS vector.

Slowloris attack

Why wrong: A Slowloris attack operates by opening many incomplete HTTP connections to a web server, sending partial requests to keep these connections alive for as long as possible. This ties up the server's available connection threads, preventing legitimate users from establishing new connections. The key discrepancies here are that Slowloris typically targets HTTP (port 80) with incomplete requests and often from a single source, whereas the exhibit shows established connections on port 443 from multiple distinct IP addresses.

Man-in-the-middle attack

Why wrong: A Man-in-the-Middle (MITM) attack involves an attacker secretly relaying and possibly altering the communication between two parties who believe they are directly communicating with each other. This attack focuses on intercepting and manipulating data flow, not on overwhelming a single server with a high volume of direct connection attempts from multiple disparate sources. The observed pattern of numerous external IPs connecting to one server is a direct assault on availability, not an interception of existing communication.

Command Injection

Why wrong: Command Injection involves injecting and executing arbitrary operating system commands through an application. The provided exhibit does not contain any typical command separators like semicolons (`;`), ampersands (`&`), pipes (`|`), or backticks (`` ` ``), nor does it show common command utilities such as `ls`, `cat`, or `whoami`. Therefore, there is no indication that the attacker is attempting to execute system-level commands on the server.

SQL Injection

Why wrong: SQL Injection exploits vulnerabilities in an application's database layer by inserting malicious SQL code into input fields. The exhibit lacks any characteristic SQL syntax, such as single quotes (`'`), double dashes (`--`) for comments, or keywords like `UNION`, `SELECT`, `OR`, or `AND`, which are typically used to manipulate database queries. Without these elements, the attempt does not align with the patterns of an SQL injection attack targeting a backend database.

Cross-Site Scripting

Why wrong: Cross-Site Scripting (XSS) attacks involve injecting malicious client-side scripts, typically JavaScript, into web pages viewed by other users. The exhibit does not display any HTML tags like `<script>`, `<img>` with `onerror` attributes, or `javascript:` pseudo-protocols commonly used to embed or execute scripts within a web browser. The observed input is focused on file path manipulation rather than browser-side script execution.

EternalBlue (MS17-010)

Why wrong: EternalBlue (MS17-010) exploits a critical vulnerability in Microsoft's Server Message Block (SMBv1) protocol. The security update addressing this flaw was released in March 2017. Given that the exhibit's patch dates extend into 2020, it is highly improbable that a system regularly updated would still be vulnerable to EternalBlue, as its patch would have been applied years prior, making it not a 'missing' patch in this context.

BlueKeep (CVE-2019-0708)

Why wrong: BlueKeep (CVE-2019-0708) is a severe remote code execution vulnerability affecting the Remote Desktop Services (RDS) in older Windows operating systems, specifically Windows 7, Windows Server 2008 R2, and earlier versions. This critical vulnerability does not impact Windows 8 or Windows 10 systems. Therefore, if the system in question is running Windows 10, BlueKeep would not be a relevant missing patch to check for.

ZeroLogon (CVE-2020-1472)

Why wrong: ZeroLogon (CVE-2020-1472) is a critical privilege escalation vulnerability in the Netlogon Remote Protocol (MS-NRPC) that could allow an unauthenticated attacker to gain domain administrator privileges. The necessary security update for this vulnerability, identified as KB4577586, was released in August 2020. As indicated by the exhibit, this specific patch was installed on the system on September 8, 2020, meaning the vulnerability is already addressed and not a missing patch.

The OUTPUT chain policy is set to ACCEPT, which allows any outbound traffic.

Why wrong: Setting the `OUTPUT` chain policy to `ACCEPT` is a standard and often necessary configuration for most systems. This policy permits the system itself to initiate and send outbound connections, which is essential for normal operation, including accessing external resources, updating software, and responding to legitimate client requests. Restricting outbound traffic too severely can break legitimate applications and services, and the primary security focus for firewalls is typically on controlling inbound (`INPUT`) and forwarded (`FORWARD`) traffic to prevent unauthorized access.

The FORWARD chain only allows traffic from 192.168.1.0/24 to any destination, which is too permissive.

Why wrong: Allowing traffic from an internal network segment like 192.168.1.0/24 to any destination via the `FORWARD` chain is a common and often required configuration for a router or gateway firewall. This rule enables internal users to access external resources, such as the internet, which is a fundamental function of network connectivity. While specific outbound ports or protocols might be further restricted for enhanced security, the general allowance for internal clients to reach external destinations is not inherently "too permissive" for standard internet access.

UDP port 53 is allowed, which could permit DNS tunneling attacks.

Why wrong: Permitting UDP port 53 for DNS traffic is a fundamental requirement for almost any network to resolve domain names and function correctly. While DNS tunneling is a legitimate concern where attackers exfiltrate data over DNS queries, merely allowing UDP port 53 does not automatically enable this attack. Preventing DNS tunneling typically requires deeper packet inspection, behavioral analysis, or DNS proxying solutions that can identify and block anomalous or malicious DNS query patterns, rather than simply blocking the essential DNS port.

Phishing

Why wrong: Phishing is a social engineering technique involving deceptive electronic communications, such as emails or instant messages, designed to trick recipients into revealing sensitive information or performing malicious actions. While it can lead to system compromise, the direct manifestation in firewall logs would typically be outbound connections from an infected host or credential theft, not an unauthorized internal IP directly attempting SMB connections without a prior successful compromise leading to internal network access.

Vishing

Why wrong: Vishing, or voice phishing, is a social engineering attack conducted over the telephone where attackers impersonate legitimate entities to manipulate victims into divulging confidential information or performing specific actions. This method primarily exploits human trust through verbal communication and does not directly result in an unauthorized internal IP address appearing in firewall logs attempting SMB connections, as it is not a direct network-level attack.

Baiting

Why wrong: Baiting is a social engineering attack that involves leaving a malware-infected physical device, such as a USB drive, in a public place, hoping a curious victim will pick it up and connect it to their computer. While a successful baiting attack can lead to network compromise and subsequent unauthorized network activity, the initial unauthorized internal IP connection to SMB in firewall logs is not the direct, primary indicator of a baiting attack itself, which focuses on the initial infection vector via physical media.

Banner grabbing

Why wrong: Banner grabbing involves connecting to an open port on a target system and observing the service's initial response, often called a banner. This technique primarily identifies the specific application, its version, and sometimes the underlying operating system running on that particular host. While useful for identifying vulnerable services and enumerating host-specific software, it provides no information about the network path or the sequence of routers packets traverse to reach the target.

DNS enumeration

Why wrong: DNS enumeration systematically queries Domain Name System (DNS) servers to gather information about hostnames, IP addresses, mail servers, and other records within a specific domain. This process helps map the logical structure of an organization's online presence and identify potential targets by resolving names to addresses. However, it focuses on discovering domain assets and their associated IP addresses, not on tracing the physical or logical routing path packets take across the network to reach those hosts.

SNMP walk

Why wrong: An SNMP walk is used to query a Simple Network Management Protocol (SNMP) agent on a network device to retrieve a hierarchical tree of Management Information Base (MIB) data. This data provides detailed operational statistics, configuration parameters, and status information about the device itself, such as interface status, CPU usage, or its internal routing table. While it offers deep insight into a single device's state and configuration, an SNMP walk does not actively discover or map the end-to-end network path between multiple devices across the internetwork.

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

Why wrong: 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 wrong: 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 wrong: 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.

The attacker successfully performed a blind SQL injection to enumerate the database structure

Why wrong: The attacker did not perform a blind SQL injection, which relies on inferring data through true/false responses or time delays without direct output. Instead, the exhibit demonstrates a successful UNION-based SQL injection where the attacker directly received the database's response containing enumerated data. This direct data exfiltration method is fundamentally different from the indirect, inferential nature of blind SQL injection techniques.

The attacker caused a denial of service by sending an invalid query

Why wrong: The query executed successfully, evidenced by the HTTP 200 OK status code and the return of actual data from the database. A denial of service attack would typically manifest as a server error, timeout, or an inability to process legitimate requests, none of which occurred here. The system remained operational and responsive, fulfilling the attacker's data retrieval request without interruption.

The attacker modified the database records to update user passwords

Why wrong: The SQL payload utilized in the exhibit, specifically `UNION SELECT`, is designed for data retrieval, not for modifying database records. To update user passwords, the attacker would need to employ a DML (Data Manipulation Language) statement such as `UPDATE` along with appropriate `SET` and `WHERE` clauses. The current query merely extracts existing information without altering the database's state or content.

The port is closed and the target sent a RST packet.

Why wrong: If a port is truly closed, the target host's TCP/IP stack would respond to an incoming SYN probe with a TCP RST (Reset) packet, indicating that no service is listening on that port. Nmap interprets this RST response as the port being definitively 'closed'. The 'filtered' state, however, implies that no such RST packet was received, meaning the probe was likely intercepted and dropped before reaching the host's TCP stack.

The port is open but the service is not responding to the scan.

Why wrong: For Nmap to classify a port as 'open', the target service must successfully complete the initial TCP three-way handshake by responding to a SYN probe with a SYN/ACK packet. Even if the service subsequently fails to respond to application-layer requests or is misconfigured, the initial SYN/ACK would still confirm the port's 'open' status. A 'filtered' state indicates that Nmap did not receive any SYN/ACK response, suggesting the probe never reached the service to begin with.

The port is open but Nmap cannot determine the service.

Why wrong: Nmap's ability to determine the service version (e.g., Apache HTTPD 2.4) is a separate function from determining the port state (open, closed, filtered). If a port is open, Nmap will report it as 'open', even if it cannot identify the specific service or its version due to an unknown banner or custom application. The 'filtered' state specifically signifies that Nmap's probes are being blocked, preventing any determination of whether the port is open or closed, let alone the service running on it.

User profile (C:\Users\jdoe)

Why wrong: Gaining access to the user profile folder, such as C:\Users\jdoe, provides access to a collection of user-specific files and settings, including documents, desktop items, and application data. However, the profile *folder itself* is a container, not a specific file directly holding credentials in a readily exploitable format like a script. While sensitive information might reside within subfolders, the profile as a whole isn't the most direct answer for an attacker seeking immediate credential compromise in the context of a specific exploitable artifact.

Home directory on \\fileserver\home\jdoe

Why wrong: A user's home directory, typically a network share like \\fileserver\home\jdoe, serves as a centralized storage location for personal files and documents. Similar to a local user profile, this is a network *location* or *container*, not a specific executable file or database inherently designed to store credentials for other resources. While an attacker might find sensitive documents or configuration files within it, the home directory itself is not the direct source of credentials in the same manner a logon script might be.

Active Directory database (NTDS.dit)

Why wrong: The NTDS.dit file is the core database of Active Directory, containing all domain objects, including user accounts and their NTLM password hashes. This critical file resides exclusively on a Domain Controller (DC), not on a standard user's workstation. Therefore, an attacker who has only gained access to a user's local machine would not directly find or extract the NTDS.dit file from that workstation, making it an incorrect answer for a scenario focused on local user machine compromise.

Distributed denial of service (DDoS) attack

Why wrong: A Distributed Denial of Service (DDoS) attack involves overwhelming a target with traffic from numerous compromised systems, aiming to exhaust resources and deny legitimate access. The output of `ping` and `arp -a` primarily reveals network layer connectivity and local address resolution anomalies, respectively. While a DDoS could impact network performance, these commands alone would not directly indicate the distributed nature or sheer volume of traffic characteristic of a DDoS attack, which typically requires traffic analysis or network monitoring tools.

MAC flooding attack

Why wrong: A MAC flooding attack targets a network switch's Content Addressable Memory (CAM) table, overwhelming it with a large number of fake MAC-address-to-port mappings. This forces the switch to operate in a 'fail-open' mode, behaving like a hub and broadcasting all traffic to all ports, enabling sniffing. However, this attack primarily impacts the switch's internal forwarding logic and would not directly manifest as duplicate MAC addresses for different IP addresses within a host's ARP cache, which is what `arp -a` displays.

Ping flood attack

Why wrong: A ping flood attack is a basic Denial of Service (DoS) technique where an attacker overwhelms a target with a high volume of ICMP echo requests (pings), consuming bandwidth and system resources. While the exhibit mentions `ping`, the critical evidence for identifying the attack type comes from the `arp -a` output, which shows anomalies in the ARP table. ARP anomalies, such as duplicate MAC addresses for different IPs, are not direct symptoms of a ping flood; they indicate issues with data link layer address resolution, not excessive ICMP traffic.

The DNS server is configured to block zone transfers

Why wrong: A zone transfer (AXFR or IXFR) is a specific type of DNS query used to replicate an entire DNS zone file, typically between authorized DNS servers. The command in question, which queries for MX records, is a standard lookup for a specific resource record type, not an attempt to initiate a zone transfer. Therefore, the results of an MX record query provide no information about whether the DNS server is configured to block or allow zone transfers.

Mail is automatically forwarded to a backup server

Why wrong: MX records specify the mail servers responsible for a domain and include a preference value (a numerical priority, where lower numbers indicate higher preference) to guide sending mail servers on which server to try first. While multiple MX records provide redundancy and a fallback mechanism, they do not inherently indicate automatic mail forwarding to a 'backup' server. Instead, they instruct external sending servers to attempt delivery to the highest preference server first, then fall back to lower preference servers if the primary is unavailable, rather than an internal forwarding configuration.

The domain has an SPF record configured

Why wrong: An SPF (Sender Policy Framework) record is a type of DNS TXT record that specifies which mail servers are authorized to send email on behalf of a domain, primarily used to combat email spoofing. The command shown specifically queries for MX (Mail Exchange) records, which are distinct from TXT records. Without explicitly querying for TXT records, the output will not reveal the presence or absence of an SPF record for the domain, as it's a different record type.

Name server records

Why wrong: Name Server (NS) records identify the authoritative DNS servers for a domain, delegating responsibility for that zone. While crucial for DNS resolution, `nslookup` does not display NS records by default; a specific query type, such as `set type=NS` or `nslookup -query=NS`, must be explicitly used to retrieve this information. Therefore, a basic `nslookup` command, as implied by the exhibit, would not primarily yield NS records.

IP addresses of the web server

Why wrong: IP addresses of web servers are typically stored in A records for IPv4 or AAAA records for IPv6, which map a hostname to its corresponding IP address. While `nslookup` defaults to querying A records, the question's correct answer specifically points to mail server information, implying the output primarily highlighted MX records. Thus, even if A records might be part of a default query, the core information being sought or presented in the correct context is not the web server's IP.

SPF records for email authentication

Why wrong: Sender Policy Framework (SPF) records are vital for email authentication, helping to prevent email spoofing by specifying which hosts are authorized to send mail for a domain. SPF information is published within DNS as TXT (text) records. To retrieve SPF records using `nslookup`, an attacker would need to explicitly set the query type to TXT, for example, by using `set type=TXT` before the domain query, as they are not part of a default `nslookup` output.

The pairwise cipher is CCMP, which is outdated.

Why wrong: The statement that CCMP is outdated is incorrect. Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) is the mandatory and robust encryption protocol for WPA2, leveraging the Advanced Encryption Standard (AES) for strong confidentiality and integrity. It remains the industry standard for secure wireless communication and is not considered outdated or insecure for WPA2 networks.

The network uses WPA2-PSK, which is easily cracked.

Why wrong: The assertion that WPA2-PSK is easily cracked is misleading. WPA2-PSK (Pre-Shared Key) provides strong cryptographic protection when a sufficiently complex passphrase is used. While it can be vulnerable to offline dictionary attacks if the passphrase is weak or common, this vulnerability lies with poor passphrase choice, not an inherent flaw in the WPA2 protocol's cryptographic design itself, which remains secure.

The beacon frame reveals the BSSID, which is a security risk.

Why wrong: Broadcasting the Basic Service Set Identifier (BSSID) in beacon frames is a fundamental and necessary aspect of Wi-Fi network operation, not a security risk. The BSSID is simply the MAC address of the Access Point (AP) and is essential for client devices to identify and connect to a specific wireless network. It is publicly advertised by design to enable network discovery and communication.

The SSH service is interfering with the scan.

Why wrong: Nmap conducts port scans by sending specific probes to individual ports and analyzing the responses received. The operation of a service like SSH on port 22 is isolated to that particular port and its associated protocols, such as TCP. It does not inherently interfere with Nmap's ability to probe or receive responses from other distinct ports, like port 80, which would be handled as a separate communication channel. Therefore, an active SSH service cannot cause a 'filtered' status on an unrelated port.

The target host is offline.

Why wrong: If the target host were truly offline, Nmap would report it as "Host is down" or "No route to host," indicating a complete lack of reachability, rather than providing specific port status information. The presence of a latency measurement, such as 0.0012s, explicitly indicates that Nmap successfully received a response from the target during its host discovery phase. A 'filtered' port status, therefore, confirms the host is reachable and actively processing network traffic, even if it's blocking specific probes.

The web server is not running.

Why wrong: If the web server application were not running on port 80, Nmap would typically report the port as 'closed'. A 'closed' status indicates that the host received the Nmap probe but no application is listening on that specific port, resulting in a RST packet response. The 'filtered' status, however, signifies that Nmap's probes are being actively blocked or dropped by an intermediary device, preventing Nmap from determining the port's true state (open or closed).