Iot And OT Exploitation practice questions

Executing an MQTT-specific TCP SYN flood against port 1883

Why it fails: This is a standard network-layer TCP SYN flood, not an application-layer MQTT attack leveraging missing ACLs.

Subscribing to the '$SYS/#' system topic hierarchy using wildcard expansion

Why it fails: While '$SYS/#' provides broker telemetry, standard brokers restrict publishing to '$SYS', and reading telemetry does not inherently cause a denial of service.

Sending a CONNECT packet with an invalid keep-alive timer value of zero

Why it fails: A keep-alive value of zero disables the keep-alive mechanism, which is a valid configuration and does not cause a denial of service on standard brokers.

Hydra

Why it fails: Hydra is a fast network login cracker supporting numerous protocols, not BLE.

Sqlmap

Why it fails: Sqlmap is an automated SQL injection and database takeover tool.

Aircrack-ng

Why it fails: Aircrack-ng is designed for 802.11 wireless network auditing, not Bluetooth Low Energy.

The device's physical serial number printed on the casing

Why it fails: The serial number is printed identification, not cryptographic key material, so Wireshark cannot derive the network key from it. It is tempting because device identifiers are often collected during reconnaissance, and would be the correct input when correlating captured frames to a specific physical device.

The manufacturer's IEEE 802.15.4 MAC address

Why it fails: A MAC address is an addressing identifier, not a key, so it cannot decrypt the application-layer payload. It is tempting because the tester already sees MAC addresses in captured frames, and would be the correct input when filtering traffic for one specific node.

The Wi-Fi WPA2 pre-shared key of the local router

Why it fails: WPA2 protects Wi-Fi at layer 2 on a different network; Zigbee runs over IEEE 802.15.4 with its own network key, so the PSK decrypts nothing here. It is tempting because both are wireless keys, and would be correct when decrypting Wi-Fi traffic captured from the same environment.

TCP 443

Why it fails: Port 443 is reserved for HTTPS secure web traffic.

TCP 2404

Why it fails: Port 2404 is used for IEC 60870-5-104 protocol communications.

TCP 44818

Why it fails: Port 44818 is used for EtherNet/IP (CIP).

Impacket

Why it fails: Impacket is a collection of Python classes for working with network protocols, primarily focused on Windows/Active Directory environments.

Airgeddon

Why it fails: Airgeddon is a multi-use bash script for auditing wireless 802.11 networks.

Bettercap

Why it fails: Bettercap is a Swiss army knife for network reconnaissance and man-in-the-middle attacks on IP networks.

ssh -p 5684 -o KexAlgorithms=psk 192.168.1.50

Why it fails: SSH is used for secure shell remote logins, not for connecting to CoAP/DTLS services.

nc -u 192.168.1.50 5684

Why it fails: Netcat (nc) does not handle DTLS handshaking or Pre-Shared Key cryptography natively.

telnet 192.168.1.50 5684

Why it fails: Telnet operates in cleartext and cannot negotiate DTLS or handle PSK cipher suites.

Flashing a modified bootloader directly onto the physical SPI flash chip using a desoldered programmer

Why it fails: SPI flash chip flashing is a physical hardware manipulation technique, not a static software file system analysis step.

Capturing over-the-air 802.11 management frames using Wireshark

Why it fails: Packet capturing is a dynamic wireless monitoring technique, not static firmware analysis.

Relying on standard IEEE 802.11 physical layer framing and MAC headers

Why it fails: Z-Wave uses proprietary ITU-T G.9959 physical and media access control layers, not IEEE 802.11.

Requiring all participating nodes to maintain an active BGP routing table with upstream Internet routers

Why it fails: BGP is an Internet routing protocol for Autonomous Systems, not a smart home mesh networking protocol.

Operating natively on the 5 GHz Wi-Fi frequency band with WPA3-Enterprise authentication

Why it fails: Z-Wave does not operate on 5 GHz Wi-Fi bands or utilize WPA3-Enterprise.

DirBuster

Why it fails: DirBuster is a multi-threaded Java application designed to brute force directories and file names on web/application servers.

Nmap

Why it fails: Nmap is a network discovery and security auditing tool, though it has some MQTT scripts, it does not natively perform advanced MQTT topic fuzzing.

Nikto

Why it fails: Nikto is a web server scanner that tests web servers for multiple items.

Address Space Layout Randomization (ASLR)

Why it fails: ASLR is an operating system kernel feature, not a compiler flag verified directly via binary checksec analysis.

Bandwidth Throttling

Why it fails: Bandwidth throttling is a network traffic management feature and has no relation to binary compilation security flags.

APIMOTE

Why it fails: APIMOTE is an older 802.15.4 research platform that can be used for Zigbee sniffing, but it is largely obsolete and not as widely supported as modern dedicated sniffers. It requires custom firmware and may lack support for the latest Zigbee standards. While it can capture traffic, it is not the most practical or specifically designed tool for current Zigbee assessments.

Ubertooth One

Why it fails: Ubertooth One is designed for Bluetooth (Classic and Low Energy) sniffing, not Zigbee. It operates in the 2.4 GHz band but its firmware and software are tailored to Bluetooth protocols. It cannot decode Zigbee frames without significant modification. Therefore, it is not the right tool for capturing Zigbee network traffic in this scenario.

HackRF One

Why it fails: HackRF One is a software-defined radio (SDR) capable of transmitting and receiving a wide range of radio frequencies, including the 2.4 GHz band used by Zigbee. However, it is not specifically designed for Zigbee; it requires additional software and configuration to decode Zigbee frames. For targeted Zigbee analysis, a dedicated Zigbee sniffer is more appropriate. HackRF is more general-purpose and not the primary tool for Zigbee capture.

RTL-SDR

Why it fails: RTL-SDR is a low-cost SDR receiver that can capture raw radio signals, including Zigbee's 2.4 GHz band if paired with a downconverter. However, it is receive-only and lacks the ability to inject frames. It also requires significant post-processing to decode Zigbee. It is not a dedicated Zigbee tool and cannot interact with the network, so it is not a correct choice.

Proxmark3

Why it fails: Proxmark3 is a powerful RFID/NFC research tool used for reading, writing, and emulating RFID tags and NFC cards. It operates at 125 kHz, 13.56 MHz, and other RFID frequencies, not the 2.4 GHz band used by Zigbee. Therefore, it cannot capture or interact with Zigbee networks and is incorrect for this scenario.

HackRF One

Why it fails: HackRF One is a Software Defined Radio (SDR) capable of transmitting and receiving signals from 1 MHz to 6 GHz. While it can capture raw Zigbee signals, it requires additional software and processing to demodulate and decode Zigbee frames. It is not specifically designed for Zigbee; it is a general-purpose SDR. Thus, it is not the best tool for straightforward Zigbee traffic capture and interaction.

DNP3 Secure Authentication

Why it fails: DNP3 Secure Authentication is a security extension that provides authentication for critical messages, including responses. When properly configured, it prevents spoofing by requiring cryptographic authentication. The scenario states that the master does not authenticate responses, implying that Secure Authentication is either not enabled or misconfigured. Thus, this feature is not the cause of the weakness; it is the mitigation. The question asks for the improperly configured feature that allows spoofing.

DNP3 Link Layer Confirmation

Why it fails: Link layer confirmation is used for reliable delivery of frames, not for authentication. It ensures that frames are received correctly but does not verify the identity of the sender. An attacker can still spoof link layer confirmations. Therefore, this is not the feature that, when improperly configured, allows response spoofing; the lack of authentication is the root issue.

DNP3 Unsolicited Responses

Why it fails: Unsolicited responses are a DNP3 feature where an RTU can send data to the master without a prior request. While this can be abused in some attacks, it is not the core reason for lack of authentication. The master still expects responses to its requests; spoofing those responses is possible when authentication is absent. Unsolicited responses are a separate mechanism and not the improperly configured feature that directly enables response spoofing.

Exploiting a vulnerability in the PROFINET stack to inject crafted RT frames directly into the network.

Why it fails: While exploiting a vulnerability could allow frame injection, it requires a specific known vulnerability in the PROFINET stack, which may not exist or be patched. This is not a generic MITM technique and is less reliable than network-level interception. In most assessments, testers use network manipulation rather than relying on software exploits for MITM, making this option less practical and not the best choice.

Using a PROFINET engineering tool to change the I/O module's configuration and redirect its output to a malicious device.

Why it fails: PROFINET engineering tools like TIA Portal are used for configuration and diagnostics. They require proper authentication and are not designed for real-time MITM manipulation. Changing the I/O module's configuration would disrupt the process and likely be detected. This approach does not allow stealthy alteration of frames in transit and is not a penetration testing technique for MITM.

MAC flooding the switch to force it into fail-open mode, then capture and modify PROFINET RT frames.

Why it fails: MAC flooding can overflow the switch's CAM table, causing it to flood frames to all ports. While this allows passive capture, it does not provide a reliable MITM position to modify frames in transit. The switch may also have protections like port security. Moreover, flooding can disrupt the entire network, making stealthy manipulation difficult. It is not the best technique for targeted modification of PROFINET RT frames.

Perform a man-in-the-middle attack between the device and the broker by ARP spoofing, then modify MQTT packets in transit.

Why it fails: While a man-in-the-middle attack can intercept and modify MQTT traffic, it requires network positioning and may be more complex. The scenario already provides hardcoded credentials and anonymous access, which offer a simpler and more direct way to access the broker. ARP spoofing might be detected or mitigated, and it does not leverage the discovered credentials. Thus, it is not the most direct method given the available information.

Exploit a known vulnerability in the MQTT broker software to gain remote code execution, then use that to read all messages.

Why it fails: Exploiting a software vulnerability is not guaranteed and may not be present. The scenario does not mention a specific vulnerable version. The tester already has valid credentials and anonymous access is allowed, so there is no need to exploit a vulnerability. This approach is less direct and introduces unnecessary complexity and risk. The credentials provide a straightforward path to access the broker.

Use the hardcoded credentials to access the device's web interface and change the MQTT broker settings to redirect messages to a rogue broker.

Why it fails: The scenario does not indicate that the device has a web interface or that the credentials are for the web interface. The credentials are for the MQTT broker. Accessing a web interface might not be possible or might not allow changing broker settings. This method is indirect and relies on an unconfirmed interface. The direct approach is to use the credentials to connect to the MQTT broker itself.

Nmap with the bacnet-info script

Why it fails: Nmap's bacnet-info script can discover BACnet devices and retrieve basic information such as device ID and vendor. However, it is limited to information gathering and does not provide full interaction capabilities like reading/writing properties or manipulating objects. It is not a dedicated BACnet exploitation tool, making it less suitable for the tester's goal of identifying manipulation points.

Scapy with BACnet layer

Why it fails: Scapy is a powerful packet manipulation tool that can craft and send custom packets, including BACnet frames if a BACnet layer is defined. However, it is not a dedicated BACnet tool; it requires manual crafting and does not provide built-in BACnet discovery or object enumeration features. It is less efficient for a tester wanting to quickly enumerate BACnet devices and objects.

Wireshark with the BACnet dissector

Why it fails: Wireshark can capture and dissect BACnet traffic, allowing the tester to analyze packets and understand the protocol. However, it is a passive analysis tool and cannot actively enumerate devices or interact with BACnet objects. It does not send BACnet requests to discover devices or read/write properties, so it cannot be used for active enumeration and manipulation.

profinet

Why it fails: Wireshark does not have a display filter named 'profinet'. While 'profinet' may appear as a protocol label in the packet details, it is not a valid filter keyword. Using it would result in a syntax error or no matches, failing to isolate the desired RT frames. The correct filter for PROFINET RT is 'pn_rt', which is specific to the real-time communication profile.

pn_dcp

Why it fails: The filter 'pn_dcp' targets PROFINET Discovery and Configuration Protocol (DCP) frames, which are used for device discovery and name assignment, not for real-time cyclic data exchange. While DCP is part of PROFINET, it does not capture the RT frames that carry process data. Therefore, it would not fulfill the tester's goal of analyzing RT communication between the PLC and I/O devices.

eth.type == 0x8892

Why it fails: While PROFINET RT frames do use EtherType 0x8892, this filter captures all PROFINET frames, including non-real-time traffic such as DCP, PTCP, and alarms. It is not specific to RT frames, so it would include extraneous packets and fail to isolate only the real-time cyclic data. The more precise filter 'pn_rt' is required to achieve the tester's objective.

Use the exploit/windows/scada/modbus_write_coil module to send a crafted packet.

Why it fails: There is no Metasploit module named exploit/windows/scada/modbus_write_coil. Modbus/TCP manipulation is typically performed using auxiliary modules like auxiliary/scanner/scada/modbusclient. Attempting to use a non-existent module would fail. The correct approach is to use the auxiliary module with the appropriate action, not an exploit module designed for Windows-specific vulnerabilities.

Set the RHOSTS to the Modbus server IP and RPORT to 502.

Why it fails: Setting RHOSTS to the server IP and RPORT to 502 is necessary for connectivity, but it is not sufficient alone to write to a coil. The question asks for actions required to write to a coil, which specifically include setting the action and data. While these network settings are part of the overall configuration, they are not the distinctive steps for coil manipulation. The key steps are selecting the write action and providing the coil address and value.

Set the MODBUS_FUNCTION_CODE to 5 for write single coil.

Why it fails: While Modbus function code 5 is indeed for writing a single coil, the Metasploit modbusclient module does not use a MODBUS_FUNCTION_CODE option. Instead, it abstracts the function code through the ACTION setting (e.g., WRITE_COIL). Setting a non-existent option would have no effect and could cause the module to fail. The correct configuration uses ACTION and DATA_ADDRESS/DATA.

Execute a BGP route hijack to redirect IoT management traffic through the tester's workstation for inspection.

Why it fails: BGP hijacking is a wide-area routing attack that affects internet routing and requires control of routing announcements. It is not a device enumeration technique and is far outside the scope of assessing IoT cameras and sensors on a corporate network. This action would be disruptive and unrelated to discovering local IoT services.

Run a Kerberos AS-REP roasting attack against the IoT devices to extract service account hashes.

Why it fails: Kerberos is an Active Directory authentication protocol and is not used by typical IoT cameras or smart sensors. AS-REP roasting targets domain accounts without pre-authentication, not embedded devices. Applying it to IoT endpoints is technically irrelevant and will not enumerate their services, making it an unsuitable choice for this scenario.

Perform an SNMP walk using the public community string against each IoT device to dump its full management information base.

Why it fails: SNMP walks can enumerate device details, but many IoT cameras and sensors do not run SNMP agents, and the public community string is frequently disabled or changed. This technique is more typical of traditional network infrastructure than consumer or building IoT devices. It is not among the most relevant methods for the described deployment and may return little usable data.

tftp 0x80000000 kernel.bin

Why it fails: tftp loads a kernel image into memory; it cannot alter boot arguments. The tempting pull is that U-Boot's tftp command does fetch kernels, so it looks like boot control, but overriding kernel arguments requires editing bootargs to append init=/bin/sh, which tftp never touches.

printenv mtdparts

Why it fails: `printenv mtdparts` only displays the partition layout variable held in the U-Boot environment; it writes nothing to the boot process, so kernel arguments stay untouched. It is tempting because inspecting `mtdparts` is genuinely useful when mapping flash regions during firmware analysis, but reading a variable cannot override `bootargs` — that requires `setenv bootargs` followed by `boot`.

run flash_os_image

Why it fails: run flash_os_image is a custom U-Boot environment variable that merely boots the stored OS image; it does not alter kernel command-line arguments. Such variables suit normal booting, whereas overriding bootargs to spawn a root shell requires editing the bootargs variable itself.