The SecOps Group CNSP Certified Network Security Practitioner (CNSP) Exam Practice Test

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.

The Windows Registry is a hierarchical database storing system and application settings, organized into predefined root keys (hives). Only specific names are valid as top-level keys.

Why A is correct:HKEY_LOCAL_MACHINE (HKLM) is a standard root key containing hardware and system-wide configuration data. CNSP references it for security settings analysis (e.g., auditing policies).

Why other options are incorrect:

B:HKEY_INTERNAL_CONFIG is not a valid key; no such hive exists.

C:HKEY_ROOT_CLASSES is a misspelling; the correct key is HKEY_CLASSES_ROOT (HKCR).

D:HKEY_LOCAL_USER is incorrect; the valid key is HKEY_CURRENT_USER (HKCU).

References:CNSP "Windows Registry Security" (Section on Registry Structure) lists HKEY_LOCAL_MACHINE as a valid hive, detailing its role in system configuration.

The Active Directory (AD) database on Windows domain controllers contains critical directory information, stored in a specific file format.

Why D is correct:The NTDS.DIT file (NT Directory Services Directory Information Tree) is the Active Directory database file, located in C:\Windows\NTDS\ on domain controllers. It stores all AD objects (users, groups, computers) and schema data in a hierarchical structure. CNSP identifies NTDS.DIT as the key file for AD data extraction in securityaudits.

Why other options are incorrect:

A. NTDS.DAT:Not a valid AD database file; may be a confusion with other system files.

B. NTDS.MDB:Refers to an older Microsoft Access database format, not used for AD.

C. MSAD.MDB:Not a recognized file for AD; likely a misnomer.

References:CNSP "Windows Active Directory Security" (Section on Database Files) confirms NTDS.DIT as the Active Directory database file.

The SMB protocol, used for file and printer sharing, has evolved across versions, with significant security enhancements in later iterations.

Why C is correct:SMBv3, introduced with Windows 8 and Server 2012, added native support for encrypting SMB traffic. This feature uses AES-CCM encryption to protect data in transit, addressing vulnerabilities in earlier versions. CNSP notes SMBv3’s encryption as a critical security improvement.

Why other options are incorrect:

A. SMBv1:Lacks encryption support and is considered insecure, often disabled due to vulnerabilities like WannaCry exploitation.

B. SMBv2:Introduces performance improvements but does not support encryption natively.

D. None of the above:Incorrect, as SMBv3 is the version that introduced encryption.

References:CNSP "File Sharing Protocols" (Section on SMB Versions) details SMBv3’s encryption feature, contrasting it with the limitations of SMBv1 and SMBv2.

Symmetric encryption is a cryptographic technique where the same key is used for both encryption and decryption processes. In the context of network security, when data is encrypted prior to transmission and decrypted at the receiving end using a symmetric encryption algorithm (e.g., AES or Triple-DES), both the sender and receiver must share and utilize an identical secret key. This key is applied by the sender to transform plaintext into ciphertext and by the receiver to reverse the process, recovering the original plaintext. The efficiency of symmetric encryption makes it ideal for securing large volumes of data transmitted over networks, provided the key is securely distributed and managed.

Why A is correct:Option A accurately describes the fundamental property of symmetric encryption—using a single shared key for both encryption and decryption. This aligns with CNSP documentation, which emphasizes symmetric encryption’s role in securing data in transit (e.g., via VPNs or secure file transfers).

Why other options are incorrect:

B:This describes asymmetric encryption (e.g., RSA), where different keys (public and private) are used for encryption and decryption, not symmetric encryption.

C:Symmetric encryption inherently relies on keys; the absence of keys contradicts its definition and operational mechanism.

D:Symmetric encryption is not inherently insecure; its security depends on key strength and management practices, not the algorithm itself. CNSP highlights that algorithms like AES are widely regarded as secure when implemented correctly.

References:CNSP documentation on "Cryptographic Fundamentals" (Section on Symmetric Encryption Algorithms) explains the use of a single key and contrasts it with asymmetric methods, emphasizing secure key exchange challenges.

TLS (Transport Layer Security)secures communication (e.g., HTTPS) using certificates, per RFC 8446. A certificate includes:

Validity Period:Start and end dates (e.g., "Not After: March 8, 2025").

Purpose:Authenticates the server and encrypts the session.

Scenario:An expired TLS certificate (e.g., past "Not After" date). Modern browsers (e.g., Chrome, Firefox) validate certificates during the handshake:

ClientHello:Browser initiates TLS.

ServerHello:Server sends its certificate.

Validation:Browser checks expiration, CA trust, etc.

If expired, browsers reject the handshake, displaying errors (e.g., "NET::ERR_CERT_DATE_INVALID"). No session key is negotiated, andcommunication doesn’t proceed over TLS. Users may bypass warnings (e.g., "Advanced > Proceed"), but this is unencrypted or uses a fallback (not standard TLS), breaking security guarantees.

Security Implications:Expired certificates expose sites to MITM attacks, as trust is lost. CNSP likely emphasizes certificate management (e.g., automation with Let’s Encrypt) to avoid this.

Why other options are incorrect:

B. The communication is still over TLS:False; an expired certificate halts the TLS handshake in compliant browsers. Legacy systems might negotiate insecurely, but this isn’t "TLS" per standards.

Real-World Context:The 2019 Equifax breach partially stemmed from expired certificates missing vulnerabilities.References:CNSP Official Study Guide (TLS/SSL Security); RFC 8446 (TLS 1.3).

SSH (Secure Shell), per RFC 4251, uses asymmetric cryptography (e.g., RSA, ECDSA) for secure authentication:

Key Pair:

Public Key:Freely shareable, used to encrypt or verify.

Private Key:Secret, used to decrypt or sign.

Process:

User generates a key pair (e.g., ssh-keygen -t rsa -b 4096).

Public Keyis uploaded to the server, appended to ~/.ssh/authorized_keys (e.g., via ssh-copy-id).

Private Key(e.g., ~/.ssh/id_rsa) stays on the user’s machine.

Authentication: Client signs a challenge with the private key; server verifies it with the public key.

Technical Details:

Protocol: SSH-2 (RFC 4253) uses a Diffie-Hellman key exchange, then public-key auth.

Files: authorized_keys (server, 0644 perms), private key (client, 0600 perms).

Security: Private key exposure compromises all systems trusting the public key.

Security Implications:CNSP likely stresses key management (e.g., passphrases, rotation) and server-side authorized_keys hardening (e.g., PermitRootLogin no).

Why other options are incorrect:

B:Uploading the private key reverses the model, breaking security—anyone with the server’s copy could authenticate as the user. Asymmetric crypto relies on the private key remaining secret.

Real-World Context:GitHub uses SSH public keys for repository access, with private keys on user devices.References:CNSP Official Documentation (SSH Security); RFC 4253 (SSH Authentication Protocol).

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).

Port 111/TCP is the default port for the RPC (Remote Procedure Call) portmapper service on Unix systems, which registers and manages RPC services.

Why A is correct:Running rpcinfo -p queries the portmapper to list all registered RPC services, their programs, versions, and associated ports. This is a logical next step during a security audit or penetration test to identify potential vulnerabilities (e.g., NFS or NIS services). CNSP recommends this command for RPC enumeration.

Why other options are incorrect:

B. Telnet to the port to look for a banner:Telnet might connect, but RPC services don’t typically provide a human-readable banner, making this less effective than rpcinfo.

C. Telnet to the port, send "GET / HTTP/1.0" and gather information from the response:Port 111 is not an HTTP service, so an HTTP request is irrelevant and will likely fail.

D. None of the above:Incorrect, as A is a valid and recommended step.

References:CNSP "Unix Service Enumeration" (Section on RPC Services) highlights rpcinfo -p as the standard tool for probing port 111/TCP.

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.

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.

DDoS (Distributed Denial of Service) attacks aim to overwhelm a target’s resources with excessive traffic, disrupting availability, whereas other attack types target different goals.

Why D is correct:Brute force attacks focus on guessing credentials (e.g., passwords) to gain unauthorized access, not on denying service. CNSP classifies it as an authentication attack, not a DDoS method.

Why other options are incorrect:

A:SYN Flood exhausts TCP connection resources, a classic DDoS attack.

B:NTP Amplification leverages amplified responses to flood targets, a DDoS technique.

C:UDP Flood overwhelms a system with UDP packets, another DDoS method.

References:CNSP "DDoS Attack Types" (Section on Attack Classification) excludes brute force from DDoS categories, listing SYN, NTP, and UDP floods as examples.

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.

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).

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.

Microsoft SQL Server (MSSQL) relies on specific ports for its core services, as defined by Microsoft and registered with IANA:

1433/TCP:The default port for the SQL Server Database Engine. Clients connect here for querying databases (e.g., via ODBC or JDBC). It’s a well-known port, making it a frequent target for attacks if exposed.

1434/UDP:Used by theSQL Server Browser Service, which listens for incoming requests and redirects clients to the correct port/instance (especially for named instances). It’s critical for discovering dynamic ports when 1433 isn’t used.

1434/TCP:Less commonly highlighted but used in some configurations, such as dedicated admin connections (DAC) or when the Browser Service responds over TCP for specific instances. While 1433/TCP is the primary engine port, 1434/TCP can be involved in multi-instance setups.

Technical Details:

Ports can be customized (e.g., via SQL Server Configuration Manager), but these are defaults.

Named instances often use dynamic ports (allocated from the ephemeral range), with the Browser Service (1434/UDP) guiding clients to them.

Firewalls must allow these ports for MSSQL to function externally, posing risks if not secured (e.g., brute-force attacks on 1433/TCP).

Security Implications:CNSP likely covers MSSQL port security, as vulnerabilities like SQL Slammer (2003) exploited 1434/UDP misconfigurations. Hardening includes restricting access, changing defaults, and monitoring traffic.

Why other options are incorrect:

A. 1433/TCP, 2433/UDP, 3433/TCP:2433/UDP and 3433/TCP are not MSSQL standards; they’re likely typos or unrelated ports.

C. 1433/TCP, 2433/UDP, 1434/TCP:2433/UDP is incorrect; 1434/UDP is the Browser Service port.

D. 1533/TCP, 1434/UDP, 2434/TCP:1533/TCP and 2434/TCP aren’t associated with MSSQL; they deviate from documented defaults.

Real-World Context:Tools like netstat -an | find "1433" on Windows confirm MSSQL’s port usage during audits.References:CNSP Official Documentation (Database Security and Ports); Microsoft SQL Server Documentation, IANA Port Registry.

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

/mnt:Designated fortemporarily 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/.

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.

A DNS zone transfer involves replicating the DNS zone data (e.g., all records for a domain) from a primary to a secondary DNS server, requiring a reliable transport mechanism.

Why A is correct:DNS zone transfers use TCP port 53 because TCP ensures reliable,ordered delivery of data, which is critical for transferring large zone files. CNSP notes that TCP is the standard protocol for zone transfers (e.g., AXFR requests), as specified in RFC 5936.

Why other options are incorrect:

B. 53/UDP:UDP port 53 is used for standard DNS queries and responses due to its speed and lower overhead, but it is not suitable for zone transfers, which require reliability over speed.

C. Both 1 and 2:This is incorrect because zone transfers are exclusively TCP-based, not UDP-based.

D. None of the above:Incorrect, as 53/TCP is the correct port for DNS zone transfers.

References:CNSP "DNS Security Practices" (Section on Zone Transfers) specifies TCP port 53 as the protocol for secure and reliable zone transfer operations.