CNSP The SecOps Group Certified Network Security Practitioner (CNSP) Free Practice Exam Questions (2025 Updated)

UDP (User Datagram Protocol), per RFC 768, is connectionless, lacking TCP’s handshake or acknowledgment mechanisms. When a UDP packet reaches a port:

Closed Port:The host typically sends an ICMP "Destination Port Unreachable" (Type 3, Code 3) unless suppressed (e.g., by firewall or OS settings).

Open Port:If a service is listening (e.g., DNS on 53/UDP), it processes the packet but doesn’t inherently reply unless the application protocol requires it (e.g., DNS sends a response).

Scenario:Anopen UDP port behind a firewall, with the firewall rule allowing traffic (e.g., permit udp any host 10.0.0.1 eq 123). The packet reaches the service, but UDP itself doesn’t mandate a response. Most services (e.g., NTP, SNMP) only reply if the packet matches an expected request. In this question’s generic context (no specific service),no responseis the default, as the firewall permits the packet, and the open port silently accepts it without feedback.

Security Implications:This silence makes UDP ports harder to scan (e.g., Nmap assumes "open|filtered" for no response), but exposed open ports risk amplification attacks (e.g., DNS reflection). CNSP likely contrasts UDP’s behavior with TCP for firewall rule crafting.

Why other options are incorrect:

A. ICMP message showing Port Unreachable:Occurs for closed ports, not open ones, unless the service explicitly rejects the packet (rare).

C. A SYN Packet:SYN is TCP-specific (handshake initiation), irrelevant to UDP.

D. A FIN Packet:FIN is TCP-specific (connection closure), not UDP.

Real-World Context:Testing UDP 53 (DNS) with dig @8.8.8.8 +udp yields a response, but generic UDP probes (e.g., nc -u) often get silence.References:CNSP Official Documentation (UDP and Firewall Behavior); RFC 768 (UDP).

In Linux/Unix, theSUID (Set User ID)bit allows a program to execute with the owner’s permissions, typically root, rather than the caller’s. It’s denoted by an s in the user execute field (e.g., -rwsr-xr-x). Common SUID programs perform privileged tasks requiring temporary elevation.

Analysis:

C. /usr/bin/passwd:

Purpose: Updates user passwords in /etc/shadow (root-owned, 0600 perms).

Permissions: Typically -rwsr-xr-x, owned by root. The SUID bit lets non-root users modify shadow securely.

Command: ls -l /usr/bin/passwd confirms SUID (s in user execute).

A. /bin/ls:

Purpose: Lists directory contents, no privileged access needed.

Permissions: -rwxr-xr-x (no SUID).Runs as the calling user.

B. /usr/bin/curl:

Purpose: Transfers data over HTTP/FTP, no root privileges required by default.

Permissions: -rwxr-xr-x (no SUID).

Technical Details:

SUID Bit: Set via chmod u+s or chmod 4755.

Security: SUID binaries are audited (e.g., find / -perm -u=s) due to escalation risks if writable or poorly coded (e.g., buffer overflows).

Security Implications:CNSP likely highlights SUID as an attack vector (e.g., CVE-1996-0095 exploited passwd flaws). Hardening removes unnecessary SUID bits.

Why other options are incorrect:

A, B:Lack SUID; no privileged operations.

D:Incorrect, as /usr/bin/passwd is a SUID example.

Real-World Context:SUID on /bin/su or /usr/bin/sudo similarly enables privilege escalation, often targeted in exploits.References:CNSP Official Documentation (Linux Security); Linux File Permissions Guide.

Social engineeringexploits 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’s connectionless nature means it lacks inherent acknowledgment mechanisms, affecting its port response behavior.

Why B is correct:An open UDP port does not respond unless an application explicitly sends a reply. Without a firewall or application response, the sender receives no feedback, per CNSP scanning guidelines.

Why other options are incorrect:

A:ICMP Port Unreachable indicates a closed port, not an open one.

C:SYN packets are TCP-specific, not UDP.

D:FIN packets are also TCP-specific.

References:CNSP "UDP Scanning" (Section on Port Behavior) notes "no response" as the default for open UDP ports.

Windows stores password hashes in the SAM (Security Account Manager) file, with a consistent location across 32-bit and 64-bit systems.

Why B is correct:The SAM file resides at C:\Windows\System32\config\SAM, locked during system operation for security. CNSP notes this for credential extraction risks.

Why other options are incorrect:

A:System64 does not exist; System32 is used even on 64-bit systems.

C:C:\System64 is invalid; the path starts with Windows.

D:config\System32 reverses the correct directory structure.

References:CNSP "Windows Credential Storage" (Section on SAM) specifies C:\Windows\System32\config\SAM.

In Linux/Unix, file permissions are displayed in a 10-character string (e.g., -rwxr-xr-x), where the first character is the file type (- for regular files) and the next nine are permissions for user (owner), group, and others (rwx = read, write, execute). Special bits likeSUID(Set User ID) modify execution behavior:

SUID:When set, a program runs with the owner’s permissions (e.g., root) rather than theexecutor’s. It’s denoted by an s in the user execute position (replacing x if executable, or capitalized S if not).

Analysis:

-rwxr-sr-x (myfile): User: rwx, Group: r-s (SGID), Others: r-x. The s is in the group execute position, indicating SGID, not SUID.

-rwsr-xr-x (myprogram): User: rws (SUID), Group: r-x, Others: r-x. The s in the user execute position confirms SUID; owned by root, it runs as root.

-rw-r--r-s (anotherfile): User: rw-, Group: r--, Others: r-s. The s is in the others execute position, but no x exists, making it irrelevant (and not SUID). Typically, s here would be a sticky bit on directories, not files.

Security Implications:SUID binaries (e.g., /usr/bin/passwd) are common targets for privilege escalation if misconfigured (e.g., writable by non-root users). CNSP likely emphasizes auditing SUID permissions with find / -perm -u=s.

Why other options are incorrect:

A. myfile:Has SGID (s in group), not SUID.

C. anotherfile:The s doesn’t indicate SUID; it’s a misapplied bit without execute permission.

D. All of the above:Only myprogram has SUID.

Real-World Context:Exploiting SUID binaries is a classic Linux attack vector (e.g., CVE-2016-1247 for Nginx).References:CNSP Official Study Guide (Linux Permissions); Linux File System Documentation.

AGolden Ticketis a forged Kerberos Ticket-Granting Ticket (TGT) in Active Directory (AD), granting an attacker unrestricted access to domain resources by impersonating any user (e.g., with Domain Admin privileges). Kerberos, per RFC 4120, relies on theKRBTGTaccount—a built-in service account on every domain controller—to encrypt and sign TGTs. To forge a Golden Ticket, an attacker needs:

TheKRBTGT password hash(NTLM or Kerberos key), typically extracted from a domain controller’s memory using tools like Mimikatz.

Additional domain details (e.g., SID, domain name).

Process:

Compromise a domain controller (e.g., via privilege escalation).

Extract the KRBTGT hash (e.g., lsadump::dcsync /user:krbtgt).

Forge a TGT with arbitrary privileges using the hash (e.g., Mimikatz’s kerberos::golden command).

The KRBTGT account itself isn’t "used" to create the ticket; its hash is the key ingredient. Unlike legitimate TGTs issued by the KDC, a Golden Ticket bypasses authentication checks, persisting until the KRBTGT password is reset (a rare event in most environments). CNSP likely highlights this as a high-severity AD attack vector.

Why other options are incorrect:

A. Local User account:Local accounts are machine-specific, lack domain privileges, and can’t access the KRBTGT hash stored on domain controllers.

B. Domain User account:A standard user has no inherent access to domain controller credentials or the KRBTGT hash without escalation.

C. Service account:While service accounts may have elevated privileges, they don’t automatically provide the KRBTGT hash unless compromised to domain admin level—still insufficient without targeting KRBTGT specifically.

Real-World Context:The 2014 Sony Pictures hack leveraged Golden Tickets, emphasizing the need for KRBTGT hash rotation post-breach (a complex remediation step).References:CNSP Official Study Guide (Active Directory Attacks); RFC 4120 (Kerberos), Microsoft AD Security Guidelines.

In Unix-based systems, memory is divided into two primary regions: kernel space and user space, each serving distinct purposes for process execution and system stability.

Why B is correct:Daemon processes are background services (e.g., sshd, cron) that run with elevated privileges but operate in user space. User space is the memory area allocated for user applications and processes, isolated from kernel space to prevent direct hardware access or system crashes. CNSP highlights that daemons run in user space to maintain system integrity, interacting with the kernel via system calls.

Why other option is incorrect:

A. Kernel space:Kernel space is reserved for the operating system kernel and device drivers, which have unrestricted access to hardware. Running daemons in kernel space would pose significant security and stability risks, and it is not the standard practice in Unix systems.

References:CNSP "Unix Process Management" (Section on Memory Spaces) explains the separation of kernel and user space, noting that daemons execute in user space for security reasons.

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 Windows Registry is a hierarchical database storing configuration settings for the operating system, applications, and hardware. It’s physically stored ashive fileson disk, located in the directoryC:\Windows\System32\Config. These files are loaded into memory at boot time and managed by the Windows kernel. Key hive files include:

SYSTEM:Contains hardware and system configuration (e.g., drivers, services).

SOFTWARE:Stores software settings.

SAM:Security Accounts Manager data (e.g., local user accounts, passwords).

SECURITY:Security policies and permissions.

DEFAULT:Default user profile settings.

USERDIFFand user-specific hives (e.g., NTUSER.DAT in C:\Users) for individual profiles, though these are linked to Config indirectly.

Technical Details:

Path:C:\Windows\System32\Configis the primary location for system-wide hives. Files lack extensions (e.g., "SYSTEM" not "SYSTEM.DAT") and are backed by transaction logs (e.g., SYSTEM.LOG) for recovery.

Access: Direct file access is restricted while Windows runs, as the kernel locks them. Tools like reg save or offline forensic utilities (e.g., RegRipper) can extract them.

Backup: Copies may exist in C:\Windows\System32\config\RegBack (pre-Windows 10 1803) or repair folders (e.g., C:\Windows\Repair).

Security Implications:The registry is a prime target for attackers (e.g., persistence via Run keys) and malware (e.g., WannaCry modified registry entries). CNSP likely emphasizes securing this directory (e.g., NTFS permissions) and auditing changes (e.g., via Event Viewer, Event ID 4657). Compromising these files offline (e.g., via physical access) can extract password hashes from SAM.

Why other options are incorrect:

A. C:\Windows\debug:Used for debug logs (e.g., memory.dmp) or tools like DebugView, not registry hives. It’s unrelated to core configuration storage.

C. C:\Windows\security:Contains security-related files (e.g., audit logs, policy templates), but not the registry hives themselves.

D. All of the above:Only B is correct; including A and C dilutes accuracy.

Real-World Context:Forensic analysts target C:\Windows\System32\Config during investigations (e.g., parsing SAM with Mimikatz offline).References:CNSP Official Study Guide (Windows Security Architecture); Microsoft Windows Registry Documentation.

ICMP (Internet Control Message Protocol), per RFC 792, handles diagnostics (e.g., ping) and errors in IP networks. It’s exploitable in:

A. Ping of Death:

Method: Sends oversized ICMP Echo Request packets (>65,535 bytes) via fragmentation. Reassembly overflows buffers, crashing older systems (e.g., Windows 95).

Fix: Modern OSes cap packet size (e.g., ping -s 65500).

B. Smurf Attack:

Method: Spoofs ICMP Echo Requests to a network’s broadcast address (e.g., 192.168.255.255). All hosts reply, flooding the victim.

Amplification: 100 hosts = 100x traffic.

C. ICMP Flooding:

Method: Overwhelms a target with ICMP Echo Requests (e.g., ping -f), consuming bandwidth/CPU.

Variant: BlackNurse attack targets firewalls.

Technical Details:

ICMP Type 8 (Echo Request), Type 0 (Echo Reply) are key.

Mitigation: Rate-limit ICMP, disable broadcasts (e.g., no ip directed-broadcast).

Security Implications:ICMP attacks are DoS vectors. CNSP likely teaches filtering (e.g., iptables -p icmp -j DROP) balanced with diagnostics need.

Why other options are incorrect:

A, B, C individually:All are ICMP-based; D is comprehensive.

Real-World Context:Smurf attacks peaked in the 1990s; modern routers block them by default.References:CNSP Official Study Guide (Network Attacks); RFC 792 (ICMP).

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.

Network segmentation isolates network zones for security, but certain techniques can circumvent these controls, a focus of CNSP penetration testing.

Why D is correct:

A:DNS tunneling encodes data in DNS queries, bypassing segmentation via legitimate DNS traffic.

B:VLAN hopping exploits switch misconfigurations (e.g., double tagging) to access other VLANs.

C:Covert channels use hidden communication paths (e.g., timing channels) to evade segmentation.All are valid techniques per CNSP for testing segmentation controls.

Why other options are incomplete:A, B, or C alone exclude other viable methods, making D the comprehensive answer.

References:CNSP "Penetration Testing Techniques" (Section on Network Segmentation Bypass) lists DNS tunneling, VLAN hopping, and covert channels as effective methods.

In Linux, theSGID (Set Group ID)bit alters execution or directory behavior:

On executables: Runs with the group owner’s permissions (e.g., s in group execute position).

On directories: New files inherit the directory’s group ownership.

Notation: s in group execute field (e.g., -rwxr-sr-x), or S if no execute (e.g., -rwxr-Sr-x).

Analysis:

-rwxr-sr-x (myfile): User: rwx, Group: r-s (SGID), Others: r-x. The s in group execute confirms SGID.

-rwsr-xr-x (myprogram): User: rws (SUID), Group: r-x, Others: r-x. The s is in user execute, not group—no SGID.

-rw-r--r-s (anotherfile): User: rw-, Group: r--, Others: r-s. The s is in others execute, but no x exists, rendering it meaningless (not SGID; could be a typo or sticky bit misapplied).

Security Implications:SGID executables (e.g., /usr/bin/wall) or directories (e.g., /var/local) manage group access. Misuse risks privilege escalation. CNSP likely teaches auditing with find / -perm -g=s.

Why other options are incorrect:

B:SUID, not SGID.

C:No valid SGID; s in others is irrelevant without execute.

D:Only A has SGID.

Real-World Context:SGID on /var/mail ensures mail files inherit the mail group.References:CNSP Official Study Guide (Linux Permissions); Linux File System Documentation.

The screenshot shows an email labeled "B" with the subject "Verify your email address" purportedly from Apple. To determine if this is a phishing email, we need to analyze its content and characteristics against common phishing indicators as outlined in CNSP documentation. Since option A is not provided in the screenshot, we will evaluate email B and infer the context for A.

Analysis of Email B:

Sender and Branding:The email claims to be from "Apple Support" and includes an Apple logo, which is a common tactic to establish trust. However, phishing emails often impersonate legitimate brands like Apple to deceive users.

Subject and Content:The subject "Verify your email address" and the body requesting the user to verify their email by clicking a link ("Verify Your Email") are typical of phishing attempts. Legitimate companies like Apple may send verification emails, but the tone and context here raise suspicion.

Link Presence:The email contains a clickable link ("Verify Your Email") that is purportedly for email verification. The screenshot does not show the URL, but phishing emails often include malicious links that lead to fake login pages to steal credentials. CNSP emphasizes that unsolicited requests to click links for verification are a red flag.

Urgency and Vague Instructions:The email includes a statement, "If you did not make this change or believe an unauthorized person has accessed your account, click here to cancel and secure your account." This creates a sense of urgency, a common phishing tactic to prompt immediate action without critical thinking.

Generic Greeting:The email starts with "Dear User," a generic greeting often used in phishing emails. Legitimate companies like Apple typically personalize emails with the user’s name.

Suspicious Elements:The email mentions "your Apple ID (example@icloud.com)," which is a placeholder rather than a specific email address, further indicating a mass phishing campaign rather than a targeted, legitimate communication.

Phishing Indicators (per CNSP):CNSP documentation on phishing identification lists several red flags:

Unsolicited requests for verification or account updates.

Generic greetings (e.g., "Dear User" instead of a personalized name).

Presence of links that may lead to malicious sites (not verifiable in the screenshot but implied).

Urgency or threats (e.g., "click here to cancel and secure your account").

Impersonation of trusted brands (e.g., Apple).Email B exhibits multiple indicators: the generic greeting, unsolicited verification request, urgent call to action, and impersonation of Apple.

Option A Context:Since the screenshot only shows email B, and the correct answer is "Only B," we can infer that email A (not shown) does not exhibit phishing characteristics. For example, A might be a legitimate email from Apple with proper personalization, no suspicious links, or a different context (e.g., a purchase confirmation rather than a verification request).

Evaluation of Options:

1. Only A:Incorrect, as email A is not shown, and the correct answer indicates B asthe phishing email.

2. Only B:Correct. Email B shows clear phishing characteristics, such as impersonation, a generic greeting, an unsolicited verification link, and urgency, aligning with CNSP’s phishing criteria.

3. Both A and B:Incorrect, as A is implied to be non-phishing based on the correct answer.

4. None of the above:Incorrect, as B is a phishing email.

Conclusion:Email B is a phishing email due to its impersonation of Apple, generic greeting, unsolicited verification request with a link, and use of urgency to prompt action. Since A is not shown but implied to be non-phishing, the correct answer is "Only B."

References:CNSP "Social Engineering Attacks" (Section on Phishing Identification) lists key phishing indicators such as impersonation, generic greetings, unsolicited links, and urgency, all of which are present in email B. The section also contrasts phishing emails with legitimate communications, emphasizing personalization and context as differentiators.

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.

TheManagement Information Base (MIB)is a structured database defining manageable objects (e.g., CPU usage, interface status) in a network device. It’s part of theSNMP (Simple Network Management Protocol)framework, per RFC 1157, used for monitoring and managing network devices (e.g., routers, switches).

SNMP Mechanics:

MIB Structure:Hierarchical, with Object Identifiers (OIDs) like 1.3.6.1.2.1.1.1.0 (sysDescr).

Versions:SNMPv1, v2c (community strings), v3 (encrypted).

Ports:UDP 161 (agent), 162 (traps).

Operation:Agents expose MIB data; managers (e.g., Nagios) query it via GET/SET commands.

MIB files (e.g., IF-MIB, HOST-RESOURCES-MIB) are vendor-specific or standardized, parsed by SNMP tools (e.g., snmpwalk). CNSP likely covers SNMP for network monitoring and securing it against enumeration (e.g., weak community strings like "public").

Why other options are incorrect:

A. SMTP (Simple Mail Transfer Protocol):Email delivery (TCP 25), unrelated to MIB or device management.

C. NTP (Network Time Protocol):Time synchronization (UDP 123), not MIB-related.

D. TACACS (Terminal Access Controller Access-Control System):Authentication/authorization (TCP 49), not MIB management.

Real-World Context:SNMP misconfiguration led to the 2018 Cisco switch exploits via exposed MIB data.References:CNSP Official Study Guide (Network Monitoring Protocols); RFC 1157 (SNMP).