Scenario practice questions

An IoT penetration tester is assessing a smart camera that communicates with a cloud service using MQTT. The tester captures network traffic and notices that the MQTT CONNECT packet includes a username and password in cleartext. Which of the following is the MOST likely reason for this exposure?

Trap 1: The MQTT broker is configured to use TLS, but the client is not.

If the broker were configured for TLS, it would reject non-TLS connections or the client would fail to connect. The fact that credentials are visible in cleartext indicates that TLS is not in use at all, not merely a client misconfiguration. This option incorrectly assumes broker-side TLS is present, which contradicts the observed cleartext traffic.

Trap 2: The MQTT client is configured to use MQTT over WebSocket without…

MQTT over WebSocket without TLS would indeed send credentials in cleartext, but this is a specific implementation. The question asks for the most likely reason, and the simplest explanation is that TLS is not used at all. WebSocket is just a transport; the lack of TLS is the root cause. This option is too narrow and not the most likely general reason.

Trap 3: The MQTT broker is using a self-signed certificate that the client…

If the broker used a self-signed certificate and the client rejected it, the connection would fail, not proceed with cleartext credentials. The presence of cleartext credentials means the connection was established without encryption. This option describes a TLS handshake failure, which would not result in the observed traffic.

A
The MQTT connection is not using TLS encryption.
MQTT, by default, does not encrypt traffic. If TLS is not configured, all data, including CONNECT packets with username and password, is sent in cleartext. This is the most likely reason for the exposure. The tester observed credentials in cleartext, which directly indicates the absence of TLS encryption on the MQTT connection.
B
The MQTT broker is configured to use TLS, but the client is not.
Why it fails: If the broker were configured for TLS, it would reject non-TLS connections or the client would fail to connect. The fact that credentials are visible in cleartext indicates that TLS is not in use at all, not merely a client misconfiguration. This option incorrectly assumes broker-side TLS is present, which contradicts the observed cleartext traffic.
C
The MQTT client is configured to use MQTT over WebSocket without TLS.
Why it fails: MQTT over WebSocket without TLS would indeed send credentials in cleartext, but this is a specific implementation. The question asks for the most likely reason, and the simplest explanation is that TLS is not used at all. WebSocket is just a transport; the lack of TLS is the root cause. This option is too narrow and not the most likely general reason.
D
The MQTT broker is using a self-signed certificate that the client rejects.
Why it fails: If the broker used a self-signed certificate and the client rejected it, the connection would fail, not proceed with cleartext credentials. The presence of cleartext credentials means the connection was established without encryption. This option describes a TLS handshake failure, which would not result in the observed traffic.

Question 2mediummultiple choice

During an assessment, a penetration tester captures an LLMNR/NBT-NS broadcast request on the local network segment. Which tool can the tester use to spoof the response and capture the resulting NTLMv2 password hash when the victim machine attempts authentication?

Trap 1: Cain & Abel

Cain & Abel is a legacy password recovery and network sniffing tool for Windows.

Trap 2: Ettercap

Ettercap performs ARP poisoning and man-in-the-middle interception, but it does not natively answer LLMNR or NBT-NS multicast queries to harvest NTLMv2 hashes. It is the right tool for ARP-based MITM on switched segments, not for name-resolution poisoning.

Trap 3: Wireshark

Wireshark passively captures and decodes packets; it cannot transmit spoofed LLMNR or NBT-NS responses, so no authentication is induced. It is correct for analysing captured traffic and extracting hashes already present, not for actively poisoning name resolution.

A
Cain & Abel
Why it fails: Cain & Abel is a legacy password recovery and network sniffing tool for Windows.
B
Ettercap
Why it fails: Ettercap performs ARP poisoning and man-in-the-middle interception, but it does not natively answer LLMNR or NBT-NS multicast queries to harvest NTLMv2 hashes. It is the right tool for ARP-based MITM on switched segments, not for name-resolution poisoning.
C
Responder
Responder poisons LLMNR, NBT-NS and mDNS queries, answering the broadcast so the victim authenticates to the attacker and surrenders its NTLMv2 hash. This directly satisfies the stem's requirement to spoof the response and capture credentials.
D
Wireshark
Why it fails: Wireshark passively captures and decodes packets; it cannot transmit spoofed LLMNR or NBT-NS responses, so no authentication is induced. It is correct for analysing captured traffic and extracting hashes already present, not for actively poisoning name resolution.

Question 3mediummulti select

A penetration tester is performing lateral movement inside an Active Directory domain and wants to use Pass-the-Hash (PtH) attacks to authenticate to other systems without cracking user passwords. Which TWO requirements must be met for a successful Pass-the-Hash attack using NTLM hashes against Windows targets?

Trap 1: SMB signing must be globally disabled across the entire Active…

SMB signing blocks PtH only on hosts where it is enforced; disabling it forest-wide is unnecessary, as the attack succeeds wherever signing is not required. It is tempting because signing is the actual control that prevents NTLM relay and PtH on SMB, so it is the correct consideration when targeting a specific host with signing enforced.

Trap 2: The target user account must have Kerberos pre-authentication…

Kerberos pre-authentication governs the Kerberos AS-REQ exchange, not NTLM authentication; PtH replays the NT hash directly over NTLM, so this setting is irrelevant. It is tempting because disabling pre-auth enables AS-REP roasting, which is the correct technique when targeting accounts that authenticate via Kerberos without pre-authentication.

Trap 3: The local Windows Firewall on the domain controller must be…

PtH requires only that the target accept NTLM authentication and that the attacker hold a valid NT hash; the domain controller's local firewall state does not gate this. It is tempting because firewall rules can block SMB or RPC ports, which is the correct consideration when a specific service port is filtered on the target host.

A
The target account's NTLM password hash must be known to the attacker
NTLM authentication proves knowledge of the hash itself, not the plaintext, so possessing the target account's NTLM hash lets the attacker inject it into an authentication exchange and impersonate the user. Without that hash, no valid NTLM response can be computed, so the requirement is fundamental.
B
SMB signing must be globally disabled across the entire Active Directory forest
Why it fails: SMB signing blocks PtH only on hosts where it is enforced; disabling it forest-wide is unnecessary, as the attack succeeds wherever signing is not required. It is tempting because signing is the actual control that prevents NTLM relay and PtH on SMB, so it is the correct consideration when targeting a specific host with signing enforced.
C
The target system must accept NTLM authentication (i.e., NTLM is not completely disabled via group policy)
Pass-the-Hash reuses an NTLM hash directly in the authentication exchange rather than cracking the plaintext password. If Group Policy disables NTLM entirely, the target rejects the hash-based logon attempt, so NTLM must remain enabled for the attack to succeed.
D
The target user account must have Kerberos pre-authentication disabled
Why it fails: Kerberos pre-authentication governs the Kerberos AS-REQ exchange, not NTLM authentication; PtH replays the NT hash directly over NTLM, so this setting is irrelevant. It is tempting because disabling pre-auth enables AS-REP roasting, which is the correct technique when targeting accounts that authenticate via Kerberos without pre-authentication.
E
The local Windows Firewall on the domain controller must be completely disabled
Why it fails: PtH requires only that the target accept NTLM authentication and that the attacker hold a valid NT hash; the domain controller's local firewall state does not gate this. It is tempting because firewall rules can block SMB or RPC ports, which is the correct consideration when a specific service port is filtered on the target host.

Study the full ACL explanation →

Question 4hardmultiple choice

You are conducting an external penetration test against a company that uses a Cisco ASA firewall. You have identified that the firewall is running an older firmware version. Which technique would best allow you to bypass the firewall's access control lists to reach an internal web server on port 80?

Trap 1: Fragmented packet attack using overlapping IP fragments

Fragment overlap attacks manipulate IP fragmentation to evade intrusion detection systems, but modern firewalls like Cisco ASA reassemble fragments before applying ACLs. They do not bypass ACLs to reach an internal server; they may only evade signature-based detection. The scenario requires bypassing ACLs, which fragment overlap does not achieve on properly configured ASA devices.

Trap 2: TCP port redirection using a compromised external host

Port redirection requires a pre-existing compromised host inside the network to forward traffic. In an external penetration test with no internal foothold, this is not possible. The technique does not bypass firewall ACLs directly; it relies on an internal pivot. Since the scenario provides no internal access, this option is not applicable.

Trap 3: Source routing with the IP Record Route option

Source routing allows a sender to specify the path a packet takes, but most firewalls, including Cisco ASA, drop packets with source routing options enabled by default. It is not a viable ACL bypass technique. The scenario describes an external tester trying to reach an internal web server, and source routing would be blocked at the perimeter, failing to achieve the goal.

A
Fragmented packet attack using overlapping IP fragments
Why it fails: Fragment overlap attacks manipulate IP fragmentation to evade intrusion detection systems, but modern firewalls like Cisco ASA reassemble fragments before applying ACLs. They do not bypass ACLs to reach an internal server; they may only evade signature-based detection. The scenario requires bypassing ACLs, which fragment overlap does not achieve on properly configured ASA devices.
B
TCP port redirection using a compromised external host
Why it fails: Port redirection requires a pre-existing compromised host inside the network to forward traffic. In an external penetration test with no internal foothold, this is not possible. The technique does not bypass firewall ACLs directly; it relies on an internal pivot. Since the scenario provides no internal access, this option is not applicable.
C
Source routing with the IP Record Route option
Why it fails: Source routing allows a sender to specify the path a packet takes, but most firewalls, including Cisco ASA, drop packets with source routing options enabled by default. It is not a viable ACL bypass technique. The scenario describes an external tester trying to reach an internal web server, and source routing would be blocked at the perimeter, failing to achieve the goal.
D
Exploiting a known vulnerability in the ASA firmware to gain access
If the Cisco ASA firmware is outdated and vulnerable, exploiting a known vulnerability could allow you to bypass ACLs, gain shell access, or tunnel traffic. This directly addresses the scenario's hint about older firmware. Unlike evasion techniques, exploiting a vulnerability can provide a direct path to the internal web server by compromising the firewall itself.

Read the full DNS explanation →

Question 5hardmultiple choice

You have compromised a Linux server and want to exfiltrate sensitive data to an external server. The network egress filtering only allows DNS traffic (UDP port 53) to a specific internal DNS resolver. Which technique would best allow you to exfiltrate data over DNS while evading detection?

Trap 1: Use SSH tunneling to forward data through the internal DNS resolver.

SSH uses TCP port 22, which is not allowed. The scenario restricts egress to DNS traffic on UDP port 53. SSH tunneling cannot be established over DNS without additional tunneling software, and the DNS resolver is not an SSH server. This method would fail due to the egress filtering.

Trap 2: Use HTTP GET requests to a web server with data encoded in the URL.

HTTP traffic typically uses TCP port 80 or 443, which are not allowed according to the scenario. Only DNS (UDP 53) is permitted, so HTTP exfiltration would be blocked. While HTTP is a common exfiltration channel, it is not viable when egress filtering restricts traffic to DNS only.

Trap 3: Use ICMP tunneling with ptunnel to encapsulate data in ping packets.

ICMP tunneling requires ICMP traffic to be allowed, but the scenario states that only DNS traffic (UDP port 53) is permitted. ICMP is a different protocol and would be blocked by the egress filter. Therefore, this technique would not work in this environment. It is a common exfiltration method but not applicable here.

A
Use SSH tunneling to forward data through the internal DNS resolver.
Why it fails: SSH uses TCP port 22, which is not allowed. The scenario restricts egress to DNS traffic on UDP port 53. SSH tunneling cannot be established over DNS without additional tunneling software, and the DNS resolver is not an SSH server. This method would fail due to the egress filtering.
B
Use dnscat2 with a custom domain and encode data in DNS queries.
dnscat2 is a tool designed for DNS tunneling, allowing data exfiltration over DNS queries and responses. It encodes data in subdomains or TXT records, and since DNS traffic is allowed, it can bypass egress filtering. Using a custom domain gives the attacker control over the authoritative DNS server, enabling reliable data transfer. This method is stealthy because DNS is often less monitored.
C
Use HTTP GET requests to a web server with data encoded in the URL.
Why it fails: HTTP traffic typically uses TCP port 80 or 443, which are not allowed according to the scenario. Only DNS (UDP 53) is permitted, so HTTP exfiltration would be blocked. While HTTP is a common exfiltration channel, it is not viable when egress filtering restricts traffic to DNS only.
D
Use ICMP tunneling with ptunnel to encapsulate data in ping packets.
Why it fails: ICMP tunneling requires ICMP traffic to be allowed, but the scenario states that only DNS traffic (UDP port 53) is permitted. ICMP is a different protocol and would be blocked by the egress filter. Therefore, this technique would not work in this environment. It is a common exfiltration method but not applicable here.

Question 6hardmultiple choice

A penetration tester has obtained a low-privileged shell on a Windows 10 workstation that is part of an Active Directory domain. The tester discovers that the workstation has Credential Guard enabled and that the current user has local admin rights on a different server. The tester wants to move laterally to the server using the current user's credentials without knowing the plaintext password. Which technique should the tester use to extract the user's Kerberos ticket from memory and reuse it on the target server?

Trap 1: Use 'net use \\server\share /user:domain\user' to authenticate to…

The 'net use' command with an explicit user and empty password does not leverage cached Kerberos tickets; it attempts a new authentication with a blank password, which will fail. Cached credentials are not automatically used in this manner, and Credential Guard further restricts such usage. This method does not achieve lateral movement using the existing ticket.

Trap 2: Use Mimikatz with the 'sekurlsa::logonpasswords' command to dump…

Credential Guard specifically protects LSASS by isolating secrets in a virtualized container, preventing tools like Mimikatz from dumping clear-text passwords via sekurlsa::logonpasswords. Even if the command runs, it will likely fail to retrieve usable credentials. This technique is ineffective when Credential Guard is enabled and would not allow lateral movement as required.

Trap 3: Use the Windows built-in 'runas /savecred' command to launch a new…

'runas /savecred' relies on credentials previously saved in Credential Manager by the user. There is no indication that the user saved credentials for the target server, and Credential Guard does not automatically populate Credential Manager. This approach would not extract or reuse Kerberos tickets and is unlikely to provide the necessary access to the server.

A
Use 'net use \\server\share /user:domain\user' to authenticate to the server with an empty password, relying on cached credentials.
Why it fails: The 'net use' command with an explicit user and empty password does not leverage cached Kerberos tickets; it attempts a new authentication with a blank password, which will fail. Cached credentials are not automatically used in this manner, and Credential Guard further restricts such usage. This method does not achieve lateral movement using the existing ticket.
B
Use Mimikatz with the 'sekurlsa::logonpasswords' command to dump clear-text credentials from LSASS memory.
Why it fails: Credential Guard specifically protects LSASS by isolating secrets in a virtualized container, preventing tools like Mimikatz from dumping clear-text passwords via sekurlsa::logonpasswords. Even if the command runs, it will likely fail to retrieve usable credentials. This technique is ineffective when Credential Guard is enabled and would not allow lateral movement as required.
C
Use the Windows built-in 'runas /savecred' command to launch a new process with saved credentials from the Credential Manager.
Why it fails: 'runas /savecred' relies on credentials previously saved in Credential Manager by the user. There is no indication that the user saved credentials for the target server, and Credential Guard does not automatically populate Credential Manager. This approach would not extract or reuse Kerberos tickets and is unlikely to provide the necessary access to the server.
D
Use Mimikatz with the 'sekurlsa::tickets /export' command to export all Kerberos tickets from memory, then inject the relevant ticket using 'kerberos::ptt'.
With Credential Guard enabled, plaintext passwords and NTLM hashes are protected, but Kerberos tickets may still be extractable from LSASS memory in some configurations. Mimikatz's sekurlsa::tickets /export exports tickets to .kirbi files, and kerberos::ptt injects a ticket into the current session, enabling lateral movement without the plaintext password. This is a standard pass-the-ticket technique that aligns with the scenario's constraints.

Question 7hardmultiple choice

During a CPENT engagement against a pharmaceutical manufacturer's OT environment, the tester captures Modbus/TCP traffic between a human-machine interface (HMI) and several PLCs. The tester wants to demonstrate that an attacker on the IT network could manipulate coil states on a specific PLC without authentication. Which action BEST demonstrates this risk while minimizing impact on the production line?

Trap 1: Initiate a Modbus/TCP Diagnose (0x08) request to clear counters and…

Diagnostic function codes can reset counters or clear diagnostic information, which may hamper troubleshooting and does not demonstrate coil manipulation. It also risks erasing evidence that operations staff may need. This action does not meet the objective of proving unauthenticated coil state changes and introduces unnecessary operational risk.

Trap 2: Send a Modbus/TCP Read Coils (0x01) request to the PLC and capture…

Read Coils demonstrates unauthenticated read access, but the objective is to show that coil states can be manipulated. Reading alone does not prove write capability, which is the core risk being demonstrated. It is safer than writing, but it does not fulfill the requirement to show manipulation of coil states on the PLC.

Trap 3: Broadcast a Modbus/TCP Write Multiple Coils (0x0F) packet to all…

Writing multiple coils across all PLCs can alter active control logic and cause physical disruption or unsafe conditions on a pharmaceutical production line. It is indiscriminate and exceeds the scope of a controlled demonstration. While it would prove the lack of authentication, the operational impact is unacceptable and likely violates the rules of engagement and safety requirements.

A
Initiate a Modbus/TCP Diagnose (0x08) request to clear counters and diagnostic registers on the PLC.
Why it fails: Diagnostic function codes can reset counters or clear diagnostic information, which may hamper troubleshooting and does not demonstrate coil manipulation. It also risks erasing evidence that operations staff may need. This action does not meet the objective of proving unauthenticated coil state changes and introduces unnecessary operational risk.
B
Send a Modbus/TCP Read Coils (0x01) request to the PLC and capture the response to prove unauthenticated access.
Why it fails: Read Coils demonstrates unauthenticated read access, but the objective is to show that coil states can be manipulated. Reading alone does not prove write capability, which is the core risk being demonstrated. It is safer than writing, but it does not fulfill the requirement to show manipulation of coil states on the PLC.
C
Craft a Modbus/TCP Write Single Coil (function code 0x05) packet targeting an unused coil address on the PLC.
Modbus/TCP has no built-in authentication, and Write Single Coil (0x05) lets an attacker change a coil state directly. Targeting an unused coil address demonstrates the lack of authentication and the write capability while avoiding disruption to the production line's active control logic. This is a controlled proof of concept appropriate for a CPENT engagement where operational safety must be preserved.
D
Broadcast a Modbus/TCP Write Multiple Coils (0x0F) packet to all PLCs on the subnet to change every coil.
Why it fails: Writing multiple coils across all PLCs can alter active control logic and cause physical disruption or unsafe conditions on a pharmaceutical production line. It is indiscriminate and exceeds the scope of a controlled demonstration. While it would prove the lack of authentication, the operational impact is unacceptable and likely violates the rules of engagement and safety requirements.