CNSP Practice Questions

A Silver Ticket is a forged Kerberos Service Ticket (TGS - Ticket Granting Service) in Active Directory,

granting access to a specific service (e.g., MSSQL, CIFS) without KDC interaction. Unlike a Golden

Ticket (TGT forgery), it requires:

Service Account’s NTLM Hash: The target service’s account (e.g., MSSQLSvc) hash, not a ticket.

Forgery: Tools like Mimikatz craft the TGS (e.g., kerberos::golden /service: /user:

/ntlm:).

Kerberos Flow (RFC 4120):

TGT (Ticket-Granting Ticket): Obtained via AS (Authentication Service) with user creds.

TGS: Requested from TGS (Ticket Granting Service) using TGT for service access.

Silver Ticket Process:

No TGT needed; the attacker mimics the TGS step using the service account’s stolen hash (e.g., from

a compromised host).

C . Service Account Ticket: Misnomer—it’s the hash of the service account (e.g., MSSQLSvc) that

enables forgery, not a pre-existing ticket. CNSP’s phrasing likely tests this nuance.

Security Implications: Silver Tickets are stealthier than Golden Tickets (service-specific, shorter-

lived). CNSP likely stresses hash protection (e.g., LAPS) and Kerberos monitoring.

Why other options are incorrect:

A . Session Ticket: Not a Kerberos term; confuses session keys.

B . TGT: Used for Golden Tickets, not Silver.

D: Incorrect; the service account’s hash (implied by “ticket”) is essential.

Real-World Context: Silver Tickets exploited in APT29 attacks (2020 SolarWinds) for lateral

movement.

Reference: CNSP Official Documentation (Kerberos Attacks); RFC 4120 (Kerberos).

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.

Reference: CNSP "Network Scanning Techniques" (Section on UDP Responses) confirms ICMP Port

Unreachable as the standard response for closed UDP ports.

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.

Reference: CNSP "Penetration Testing Techniques" (Section on Network Segmentation Bypass) lists

DNS tunneling, VLAN hopping, and covert channels as effective methods.

In Windows, security principals (users, groups) are identified by a Security Identifier (SID), formatted

as S-1---. The RID (Relative Identifier) is the final component, unique

within a domain or machine. For local accounts:

RID 500: Assigned to the built-in Administrator account on every Windows machine (e.g., S-1-5-21-

-500).

Created during OS install, with full system privileges.

Disabled by default in newer Windows versions (e.g., 10/11) unless explicitly enabled.

RID 501: Guest account (e.g., S-1-5-21--501), limited access.

Technical Details:

Stored in SAM (C:\Windows\System32\config\SAM).

Enumeration: Tools like wmic useraccount or net user reveal RIDs.

Domain Context: Domain Admins use RID 512, but the question specifies a local machine.

Security Implications: RID 500 is a prime target for brute-forcing or pass-the-hash attacks (e.g.,

Mimikatz). CNSP likely advises renaming/disabling it (e.g., via GPO).

Why other options are incorrect:

A . 0: Reserved (e.g., Null SID, S-1-0-0), not a user RID.

C . 501: Guest, not Administrator.

D . 100: Invalid; local user RIDs start at 1000 (e.g., custom accounts).

Real-World Context: Post-compromise, attackers query RID 500 (e.g., net user Administrator) for

privilege escalation.

Reference: CNSP Official Study Guide (Windows Security); Microsoft SID Documentation.

The screenshot is from Wireshark, a network protocol analyzer, displaying captured network traffic.

The relevant columns include the source and destination IP addresses, ports, protocol, and additional

information about the packets. Let’s break down the details:

Destination Port Analysis: The screenshot shows multiple packets with a destination port of 443 (e.g.,

in the "Destination" column, entries like "172.72.61.9:443"). Port 443 is the default port for HTTPS

(HTTP Secure), which is HTTP traffic encrypted using SSL/TLS. This indicates that the application is

communicating over HTTPS.

Protocol Analysis: The "Protocol" column lists "TLSv1.2" for most packets (e.g., frame numbers

2000084, 2000086). TLS (Transport Layer Security) is the cryptographic protocol used by HTTPS to

secure HTTP communications. This confirms that the traffic is HTTPS, not plain HTTP.

Packet Details: The "Info" column provides additional context, such as "Application Data" for TLS

packets, indicating encrypted application-layer data (typical of HTTPS). There are also HTTP packets

(e.g., frame 2000088), but these are likely part of the HTTPS session (e.g., HTTP/2 over TLS, as noted

by "HTTP2").

Now, let’s evaluate the options:

Option A: "The application is running on port 443 and the HTTPS protocol."

This is correct. The destination port 443 and the use of TLSv1.2 confirm that the application is using

HTTPS. HTTPS is the standard protocol for secure web communication, and port 443 is its designated

port. CNSP documentation emphasizes that HTTPS traffic on port 443 indicates a secure application-

layer protocol, often used for web applications handling sensitive data.

Option B: "The credentials have been submitted over the HTTP protocol."

This is incorrect. HTTP typically uses port 80, but the screenshot shows traffic on port 443 with TLS,

indicating HTTPS. Credentials submitted over this connection would be encrypted via HTTPS, not

sent in plaintext over HTTP. CNSP highlights the security risks of HTTP for credential submission due

to lack of encryption, which isn’t the case here.

Option C: "The credentials have been submitted over the HTTPS protocol."

While this statement could be true (since HTTPS is in use, any credentials would likely be submitted

securely), the question asks for the "correct" statement based on the screenshot. The screenshot

doesn’t explicitly show credential submission (e.g., a POST request with form data); it only shows the

protocol and port. Option A is more directly supported by the screenshot as it focuses on the

application’s protocol and port, not the specific action of credential submission. CNSP notes that

HTTPS ensures confidentiality, but this option requires more specific evidence of credentials.

Option D: "The application is running on port 80 and the HTTP protocol."

This is incorrect. Port 80 is the default for HTTP, but the screenshot clearly shows port 443 and TLS,

indicating HTTPS. CNSP documentation contrasts HTTP (port 80, unencrypted) with HTTPS (port 443,

encrypted), making this option invalid.

Conclusion: Option A is the most accurate and comprehensive statement directly supported by the

screenshot, confirming the application’s use of port 443 and HTTPS. While Option C might be true in

a broader context, it’s less definitive without explicit evidence of credential submission in the

captured packets.

Reference: CNSP "Network Traffic Analysis" (Section on Protocol Identification) explains that port 443

with TLS indicates HTTPS, and contrasts it with HTTP on port 80. The "Wireshark Analysis" section

further details how to interpret destination ports and protocol fields for identifying application-layer

protocols.

The net command in Windows is a legacy tool for managing users, groups, and network resources.

The subcommand net localgroup displays information about a specified local group on

the machine where it’s run. Specifically:

net localgroup administrators lists all members (users and groups) of the local Administrators group

on the current computer.

The local Administrators group grants elevated privileges (e.g., installing software, modifying system

files) on that machine only, not domain-wide.

Output Example:

Alias name

administrators

Comment

Administrators have complete and unrestricted access to the computer

Members

-------------------------------------------------------------------------------

Administrator

Domain Admins

The command completed successfully.

Technical Details:

Local groups are stored in the Security Accounts Manager (SAM) database (e.g.,

C:\Windows\System32\config\SAM).

This differs from domain groups (e.g., Domain Admins), managed via Active Directory.

Security Implications: Enumerating local admins is a reconnaissance step in penetration testing (e.g.,

to escalate privileges). CNSP likely covers this command for auditing and securing Windows systems.

Why other options are incorrect:

A . List domain admin users for the current domain: This requires net group "Domain Admins"

/domain, which queries the domain controller, not the local SAM. net localgroup is strictly local.

Real-World Context: Attackers use this command post-compromise (e.g., via PsExec) to identify

privilege escalation targets.

Reference: CNSP Official Documentation (Windows Security Commands); Microsoft Windows

Command-Line Reference.

The Management Information Base (MIB) is a structured database defining manageable objects (e.g.,

CPU usage, interface status) in a network device. It’s part of the SNMP (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.

Reference: CNSP Official Study Guide (Network Monitoring Protocols); RFC 1157 (SNMP).

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.

Reference: 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.

Reference: CNSP "Linux Authentication Mechanisms" (Section on Password Storage) details the

transition to /etc/shadow for enhanced security and contrasts it with /etc/passwd.

In Unix-based systems (e.g., Linux), the ifconfig command is historically used to configure network

interfaces, including changing the Media Access Control (MAC) address of an Ethernet adapter. The

correct syntax to set a new MAC address for an interface like eth0 is ifconfig eth0 hw ether

AA:BB:CC:DD:EE:FF, where hw specifies the hardware address type (ether for Ethernet), followed by

the new MAC address in colon-separated hexadecimal format.

Why A is correct: The hw ether argument is the standard and correct syntax recognized by ifconfig to

modify the MAC address. This command temporarily changes the MAC address until the system

reboots or the interface is reset, assuming the user has sufficient privileges (e.g., root). CNSP

documentation on network configuration and spoofing techniques validates this syntax for testing

network security controls.

Why other options are incorrect:

B: hdw is not a valid argument; it’s a typographical error and unrecognized by ifconfig.

C: hdwr is similarly invalid; no such shorthand exists in the command structure.

D: hwr is incorrect; the full keyword hw followed by ether is required for proper parsing.

Reference: CNSP "Network Interface Configuration" (Section on MAC Address Manipulation)

confirms ifconfig eth0 hw ether as the standard command, noting its use in penetration testing for

spoofing scenarios.