Free Practice Questions for the The SecOps Group Security Practitioner CNSP Exam (2026 Updated)

SSL/TLS protocols secure network communication, but older versions have vulnerabilities:

SSLv2 (1995): Weak ciphers, no handshake integrity (e.g., MITM via DROWN attack, CVE-2016-0800). Deprecated by RFC 6176 (2011).

SSLv3 (1996): Vulnerable to POODLE (CVE-2014-3566), weak block ciphers (e.g., RC4). Deprecated by RFC 7568 (2015).

TLSv1.0 (1999, RFC 2246): Inherits SSLv3 flaws (e.g., BEAST, CVE-2011-3389), weak CBC ciphers. Deprecated by PCI DSS (2018) and RFC 8996 (2021).

TLSv1.1 (2006, RFC 4346): Improved over 1.0 but lacks modern cipher suites (e.g., AEAD). Deprecated with 1.0 by RFC 8996.

TLSv1.2 (2008, RFC 5246): Secure with strong ciphers (e.g., AES-GCM), widely used today.

TLSv1.3 (2018, RFC 8446): Latest, removes legacy weaknesses, mandatory forward secrecy.

Answer: C (A and B) —SSLv2, SSLv3, TLSv1.0, and TLSv1.1 are unsafe due to exploitable flaws. TLSv1.2 and 1.3 remain secure. CNSP likely aligns with IETF/PCI standards, mandating modern versions.

Why other options are incorrect:

A: Correct but incomplete without B.

B: Correct but incomplete without A.

D: Incorrectly includes TLSv1.2 and 1.3, which are secure and recommended.

Real-World Context: POODLE forced mass SSLv3 disablement in 2014; TLS 1.0/1.1 deprecation hit legacy systems in 2021. References: CNSP Official Documentation (Cryptographic Protocols); RFC 8996 (TLS Deprecation).

The net localgroup command manages local group memberships on Windows systems, with syntax dictating its action.

Why B is correct: net localgroup Sales Sales_domain /add adds the domain group Sales_domain to the local group Sales, granting its members local group privileges. CNSP covers this for privilege escalation testing.

Why other options are incorrect:

A: Displaying users requires net localgroup Sales without /add.

C: Adding a user requires a username, not a group name like Sales_domain.

D: The reverse (local to domain) uses net group, not net localgroup.

References: CNSP "Windows Group Management" (Section on net Commands) explains net localgroup for adding domain groups.

The Linux Filesystem Hierarchy Standard (FHS) , per FHS 3.0, defines directory purposes:

/mnt: Designated for temporarily mounted filesystems , typically by system administrators.

Use: Mount points for removable media (e.g., USB drives: mount /dev/sdb1 /mnt/usb) or network shares (e.g., NFS).

Nature: Transient, user-managed, not persistent across reboots (unlike /etc/fstab mounts).

Contrast:

/media: Auto-mounts removable devices (e.g., by desktop environments like GNOME).

/mnt vs. /media: /mnt is manual, /media is system-driven.

Technical Details:

Empty by default; subdirectories (e.g., /mnt/usb) are created as needed.

Permissions: Typically root-owned (0755), requiring sudo for mounts.

Security Implications: Misconfigured /mnt mounts (e.g., world-writable) risk unauthorized access. CNSP likely covers mount security (e.g., nosuid option).

Why other options are incorrect:

B. System config/init scripts: Found in /etc (e.g., /etc/passwd, /etc/init.d).

C. Driver modules: Located in /lib/modules/ < kernel-version > .

D. Kernel state: Resides in /proc (e.g., /proc/cpuinfo).

Real-World Context: Admins mount ISOs at /mnt during server provisioning (e.g., mount -o loop image.iso /mnt). References: CNSP Official Study Guide (Linux Filesystems); FHS 3.0 Documentation.

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) port numbers are defined by a 16-bit field in their packet headers, as specified in RFC 793 (TCP) and RFC 768 (UDP). A 16-bit integer ranges from 0 to 65,535, yielding a total of 65,536 possible ports (2^16). However, port 0 is universally reserved across both protocols and is not considered "usable" for standard network communication. According to the Internet Assigned Numbers Authority (IANA), port 0 is designated for special purposes, such as indicating an invalid or dynamic port assignment in some systems (e.g., when a client requests an ephemeral port). In practice, operating systems and applications avoid binding to port 0 for listening services, and it’s often used in error conditions or as a placeholder in protocol implementations (e.g., socket programming).

Thus, the usable port range spans from 1 to 65,535, totaling 65,535 ports. These ports are categorized by IANA into:

Well-Known Ports (0–1023): Reserved for system services (e.g., HTTP on 80/TCP). Note that 0 is still reserved within this range.

Registered Ports (1024–49151): Assigned to user applications.

Dynamic/Ephemeral Ports (49152–65535): Used temporarily by clients.

From a security perspective, understanding the usable port count is critical for firewall configuration, port scanning (e.g., with Nmap), and detecting anomalies (e.g., services binding to unexpected ports). Misconfiguring a system to use port 0 could lead to protocol errors or expose vulnerabilities, though it’s rare. The CNSP curriculum likely emphasizes this distinction to ensure practitioners can accurately scope network security assessments.

Why other options are incorrect:

A. 65536: This reflects the total number of possible ports (0–65535), but it includes the reserved port 0, which isn’t usable for typical TCP/UDP communication. In security contexts, including port 0 in a count could lead to misconfigured rules or scanning errors.

C. 63535: This is an arbitrary number with no basis in the 16-bit port structure. It might stem from a typo or misunderstanding (e.g., subtracting 2000 from 65535 incorrectly), but it’s invalid.

D. 65335: Similarly, this lacks grounding in protocol standards. It could be a miscalculation (e.g., subtracting 200 from 65535), but it doesn’t align with TCP/UDP specifications.

Real-World Context: In penetration testing, tools like Nmap scan ports 1–65535 by default, excluding 0 unless explicitly specified (e.g., -p0-65535), reinforcing that 65,535 is the practical usable count. References: CNSP Official Study Guide (Network Protocols and Ports); RFC 793 (TCP), RFC 768 (UDP), IANA Service Name and Transport Protocol Port Number Registry.

An IP address with a /18 prefix (CIDR notation) indicates 18 network bits in the subnet mask, leaving 14 host bits (32 total bits - 18). For IPv4 (e.g., 192.168.0.1):

Binary Mask: First 18 bits are 1s, rest 0s.

1st octet: 11111111 (255)

2nd octet: 11111111 (255)

3rd octet: 11000000 (192)

4th octet: 00000000 (0)

Decimal: 255.255.192.0

Calculation:

Bits: /18 = 2^14 hosts (16,384), minus 2 (network/broadcast) = 16,382 usable.

Range: 192.168.0.0–192.168.63.255 (3rd octet: 0–63, as 192 = 11000000 covers 6 bits).

Technical Details:

Subnet masks align on octet boundaries or mid-octet (e.g., 192 = 2^7 + 2^6).

Contrast: /24 = 255.255.255.0 (256 hosts), /16 = 255.255.0.0 (65,536 hosts).

Security Implications: Larger subnets (e.g., /18) increase broadcast domains, risking amplification attacks. CNSP likely teaches subnetting for segmentation (e.g., VLANs).

Why other options are incorrect:

A. 255.255.255.0: /24 (8 host bits), not /18.

B. 255.225.225.0: Invalid mask (225 = 11100001, non-contiguous 1s).

D. 255.225.192.0: Invalid (225 breaks binary sequence).

Real-World Context: Subnetting 192.168.0.0/18 isolates departments in enterprise networks. References: CNSP Official Documentation (IP Addressing); RFC 1918 (Private IP).

Online attacks require real-time interaction with a target system (e.g., a login interface), whereas offline attacks occur without direct system interaction, typically after obtaining data like password hashes. A rainbow table attack is an offline method that uses precomputed tables of hash values to reverse-engineer passwords from stolen hash databases, distinguishing it from the other options, which are online.

Why B is correct: Rainbow table attacks are performed offline after an attacker has already acquired a hash (e.g., from a compromised database). The attacker matches the hash against precomputed tables to find the plaintext password, requiring no interaction with the target system during the attack. CNSP classifies this as an offline password recovery technique.

Why other options are incorrect:

A: Brute force attacks involve repeatedly submitting password guesses to a live system (e.g., via SSH or a web login), making it an online attack.

C: Password spraying attacks test a few common passwords across many accounts on a live system, also an online attack aimed at avoiding lockouts.

D: Phishing attacks trick users into submitting credentials through fake interfaces (e.g., emails or websites), requiring real-time interaction and thus classified as online.

References: CNSP "Password Attack Methodologies" (Section on Online vs. Offline Attacks) defines rainbow table attacks as offline and contrasts them with online methods like brute force and phishing.

Authentication and Authorization (often abbreviated as AuthN and AuthZ) are foundational pillars of access control in network security:

Authentication (AuthN): Verifies "who you are" by validating credentials against a trusted source. Examples include passwords, MFA (multi-factor authentication), certificates, or biometrics. It ensures the entity (user, device) is legitimate, typically via protocols like Kerberos or LDAP.

Authorization (AuthZ): Determines "what you can do" after authentication, enforcing policies on resource access (e.g., read/write permissions, API calls). It relies on mechanisms like Access Control Lists (ACLs), Role-Based Access Control (RBAC), or Attribute-Based Access Control (ABAC).

Option A correctly separates these roles:

Authorization governs access decisions (e.g., "Can user X read file Y?").

Authentication establishes identity (e.g., "Is this user X?").

In practice, these processes are sequential: AuthN precedes AuthZ. For example, logging into a VPN authenticates your identity (e.g., via username/password), then authorizes your access to specific subnets based on your role. CNSP likely stresses this distinction for designing secure systems, as conflating them risks privilege escalation or identity spoofing vulnerabilities.

Why other options are incorrect:

B: Reverses the definitions—Authentication doesn’t grant/deny access (that’s AuthZ), and Authorization doesn’t validate identity (that’s AuthN). This mix-up could lead to flawed security models.

C: Falsely equates AuthN and AuthZ and attributes access rules to AuthN. They’re distinct processes; treating them as identical undermines granular control (e.g., NIST SP 800-53 separates IA-2 for AuthN and AC-3 for AuthZ).

D: Misassigns access control to AuthN and claims they don’t interoperate, which is false—they work together in every modern system (e.g., SSO with RBAC). This would render auditing impossible, contradicting security best practices.

Real-World Context: A web server (e.g., Apache) authenticates via HTTP Basic Auth, then authorizes via .htaccess rules—two separate steps. References: CNSP Official Study Guide (Access Control Fundamentals); NIST SP 800-53 (Security and Privacy Controls).

EternalBlue (MS17-010) is an exploit targeting a buffer overflow in Microsoft’s SMB (Server Message Block) implementation, leaked by the Shadow Brokers in 2017. SMB enables file/printer sharing:

SMBv1 (1980s): Legacy, used in Windows NT/XP.

SMBv2 (2006, Vista): Enhanced performance/security.

SMBv3 (2012, Windows 8): Adds encryption, multichannel.

Vulnerability:

EternalBlue exploits a flaw in SMBv1 ’s SRVNET driver (srv.sys), allowing remote code execution via crafted packets. Microsoft patched it in March 2017 (MS17-010).

Affected OS: Windows XP to Server 2016 (pre-patch), if SMBv1 enabled.

Proof: WannaCry/NotPetya used it, targeting port 445/TCP.

Version Scope:

SMBv1 Only: The bug resides in SMBv1’s packet handling (e.g., TRANS2 requests). SMBv2/v3 rewrote this code, immune to the specific overflow.

Microsoft: Post-patch, SMBv1 is disabled by default (Windows 10 1709+).

Security Implications: CNSP likely stresses disabling SMBv1 (e.g., via Group Policy) and patching, as EternalBlue remains a threat in legacy environments.

Why other options are incorrect:

B, C: SMBv2/v3 aren’t vulnerable; the flaw is SMBv1-specific.

D: SMBv2 isn’t affected, only SMBv1.

Real-World Context: WannaCry’s 2017 rampage hit unpatched SMBv1 systems (e.g., NHS), costing billions. References: CNSP Official Documentation (Windows Exploits); Microsoft MS17-010 Bulletin.

TCP’s three-way handshake , per RFC 793, establishes a connection:

Client → Server: SYN (Synchronize) packet (e.g., port 80).

Server → Client: SYN-ACK (Synchronize-Acknowledge) packet if the port is open and listening.

Client → Server: ACK (Acknowledge) completes the connection.

Scenario: An open TCP port (e.g., 80 for HTTP) with no firewall. When a client sends a SYN to an open port (e.g., via telnet 192.168.1.1 80), the server responds with a SYN-ACK packet, indicating willingness to connect. No firewall means no filtering alters this standard response.

Packet Details:

SYN-ACK: Sets SYN and ACK flags in the TCP header, with a sequence number and acknowledgment number.

Example: Client SYN (Seq=100), Server SYN-ACK (Seq=200, Ack=101).

Security Implications: Open ports responding with SYN-ACK are easily detected (e.g., Nmap “open” state), inviting exploits if unneeded (e.g., Telnet on 23). CNSP likely stresses port minimization and monitoring.

Why other options are incorrect:

A. A FIN and an ACK packet: FIN-ACK closes an established connection, not a response to a new SYN.

B. A SYN packet: SYN initiates a connection from the client, not a server response.

D. A RST and an ACK packet: RST-ACK rejects a connection (e.g., closed port), not an open one.

Real-World Context: SYN-ACK from SSH (22/TCP) confirms a server’s presence during reconnaissance. References: CNSP Official Documentation (TCP/IP Fundamentals); RFC 793 (TCP).

In Linux, password hashes are stored in a secure file to protect user authentication data. The evolution of Linux security practices moved password storage from plaintext or weakly protected files to a more secure location.

Why C is correct: The /etc/shadow file is the standard location for storing password hashes in modern Linux systems. This file is readable only by the root user, enhancing security by restricting access. It contains encrypted password hashes (typically using algorithms like SHA-512), along with user details such as password expiration policies. CNSP documentation on Linux security emphasizes /etc/shadow as the authoritative source for password hashes, replacing older methods.

Why other options are incorrect:

A. /etc/passwd: Historically, /etc/passwd stored passwords in plaintext or weakly hashed forms (e.g., using DES), but modern systems use it only for user account information (e.g., UID, GID, home directory) and reference /etc/shadow for hashes.

B. /etc/password: This is not a valid file in the Linux file system; it appears to be a typographical error or misunderstanding, with no recognized role in password storage.

D. /usr/bin/shadow: /usr/bin contains executable binaries, not configuration or data files like password hashes. /etc/shadow is the correct path.

References: CNSP "Linux Authentication Mechanisms" (Section on Password Storage) details the transition to /etc/shadow for enhanced security and contrasts it with /etc/passwd.

WannaCry is a ransomware attack that erupted in May 2017, infecting over 200,000 systems across 150 countries. It exploited the EternalBlue vulnerability (MS17-010) in Microsoft Windows SMBv1, targeting unpatched systems (e.g., Windows XP, Server 2003). Developed by the NSA and leaked by the Shadow Brokers, EternalBlue allowed remote code execution.

Ransomware Mechanics:

Encryption: WannaCry used RSA-2048 and AES-128 to encrypt files, appending extensions like .wcry.

Ransom Demand: Displayed a message demanding $300–$600 in Bitcoin, leveraging a hardcoded wallet.

Worm Propagation: Self-replicated via SMB, scanning internal and external networks, unlike typical ransomware requiring user interaction (e.g., phishing).

Malware Context: While WannaCry is malware (malicious software), "ransomware" is the precise subcategory, distinguishing it from viruses, trojans, or spyware. Malware is a broad term encompassing any harmful code; ransomware specifically encrypts data for extortion. CNSP likely classifies WannaCry as ransomware to focus on its payload and mitigation (e.g., patching, backups).

Why other options are incorrect:

B. Malware: Correct but overly generic. WannaCry’s defining trait is ransomware behavior, not just maliciousness. Specificity matters in security taxonomy for threat response (e.g., NIST IR 8019).

Real-World Context: WannaCry crippled NHS hospitals, highlighting patch management’s criticality. A kill switch (a domain sinkhole) halted it, but variants persist. References: CNSP Official Study Guide (Malware and Exploits); Microsoft Security Bulletin MS17-010, NIST IR 8019.

Social engineering exploits human psychology to manipulate individuals into divulging sensitive information, granting access, or performing actions that compromise security. Unlike technical exploits, it targets the "human factor," often bypassing technical defenses. The listed attacks fit this category:

Phishing: Mass, untargeted emails (e.g., fake bank alerts) trick users into entering credentials on spoofed sites. Uses tactics like urgency or trust (e.g., typosquatting domains).

Spear Phishing: Targeted phishing against specific individuals/organizations (e.g., CEO fraud), leveraging reconnaissance (e.g., LinkedIn data) for credibility.

Vishing (Voice Phishing): Phone-based attacks (e.g., fake tech support calls) extract info via verbal manipulation. Often spoofs caller ID.

Scareware: Fake alerts (e.g., “Your PC is infected!” pop-ups) scare users into installing malware or paying for bogus fixes. Exploits fear and urgency.

Watering Hole: Compromises trusted websites frequented by a target group (e.g., industry forums), infecting visitors via drive-by downloads. Relies on habitual trust.

Technical Details:

Delivery: Email (phishing), VoIP (vishing), web (watering hole/scareware).

Payloads: Credential theft, malware (e.g., trojans), or financial fraud.

Mitigation: User training, email filters (e.g., DMARC), endpoint protection.

Security Implications: Social engineering accounts for ~90% of breaches (e.g., Verizon DBIR 2023), as it exploits unpatchable human error. CNSP likely emphasizes awareness (e.g., phishing simulations) and layered defenses (e.g., MFA).

Why other options are incorrect:

A. Probes: Reconnaissance techniques (e.g., port scanning) to identify vulnerabilities, not manipulation-based like these attacks.

B. Insider threats: Malicious actions by authorized users (e.g., data theft by employees), not external human-targeting tactics.

D. Ransomware: A malware type (e.g., WannaCry) that encrypts data for ransom, not a manipulation method—though phishing often delivers it.

Real-World Context: The 2016 DNC hack used spear phishing to steal credentials, showing social engineering’s potency. References: CNSP Official Study Guide (Social Engineering Threats); NIST SP 800-50 (Security Awareness Training).

UDP is a connectionless protocol, and its behavior when a packet reaches a port depends on whether the port is open or closed. Without a firewall altering the response, the standard protocol applies.

Why A is correct: When a UDP packet is sent to a closed port, the host typically responds with an ICMP Type 3 (Destination Unreachable), Code 3 (Port Unreachable) message, indicating no service is listening. CNSP notes this as a key indicator in port scanning.

Why other options are incorrect:

B: RST packets are TCP-specific, not used in UDP.

C: No response occurs for open UDP ports unless an application replies, not closed ports.

D: A is correct, so "none of the above" is invalid.

References: CNSP "Network Scanning Techniques" (Section on UDP Responses) confirms ICMP Port Unreachable as the standard response for closed UDP ports.

TCP (Transmission Control Protocol) uses a three-way handshake (SYN, SYN-ACK, ACK) to establish connections, as per RFC 793. When a client sends a SYN packet to a port:

Open Port: The server responds with SYN-ACK.

Closed Port (no firewall): The server sends an RST (Reset) packet, often with ACK, to terminate the attempt immediately.

However, when a firewall is present, its configuration dictates the response. Modern firewalls typically operate in stealth mode , using a "drop" rule for closed ports rather than a "reject" rule:

Drop: Silently discards the packet without replying, resulting in no response . The client experiences a timeout (e.g., 30 seconds), as no feedback is provided.

Reject: Sends an RST or ICMP "Port Unreachable," but this is less common for security reasons, as it confirms the firewall’s presence.

For a closed TCP port behind a firewall, "no response" (drop) is the standard behavior in secure configurations, minimizing information leakage to attackers. This aligns with CNSP’s focus on firewall best practices to obscure network topology during port scanning (e.g., with Nmap).

Why other options are incorrect:

A. A FIN and an ACK packet: FIN-ACK is used to close an established TCP connection gracefully (e.g., after data transfer), not to respond to an initial SYN on a closed port.

B. RST and an ACK packet: RST-ACK is the host’s response to a closed port without a firewall. A firewall’s drop rule overrides this by silently discarding the packet.

C. A SYN and an ACK packet: SYN-ACK indicates an open port accepting a connection, the opposite of a closed port scenario.

Real-World Context: Tools like Nmap interpret "no response" as "filtered" (firewall likely present) vs. "closed" (RST received), aiding in firewall detection. References: CNSP Official Study Guide (Firewall Operations and TCP/IP); RFC 793 (TCP).

DNS cache poisoning, also known as DNS spoofing, involves an attacker injecting false DNS records into a resolver’s cache, altering how domain names resolve.

Why A is correct: The primary risk is that an attacker can redirect users to malicious websites (e.g., phishing or malware sites) by poisoning the DNS cache with fake IP addresses. This can lead to credential theft, data exfiltration, or malware distribution. CNSP identifies this as the core threat of DNS cache poisoning, aligning with real-world attack vectors.

Why other option is incorrect:

B. Manipulate the cache of the web server or proxy server: This describes web cache poisoning, a different attack targeting HTTP caches, not DNS servers. DNS cache poisoning affects DNS resolution, not web or proxy server caches directly.

References: CNSP "DNS Security Threats" (Section on Cache Poisoning) defines the primary risk as traffic redirection to malicious sites, distinguishing it from web cache manipulation.