312-50 Question 89
Single answer▪ SNMP EnumerationDuring an internal authorized security assessment, you discover that several network devices respond on UDP 161. The client wants to know whether you can identify device details such as hostname, interface information, and routing-related data without logging in interactively. You suspect SNMP is enabled with a weak community string. Which action would be the most appropriate next step to enumerate this information in a CEH-style engagement?
- A
Use snmpwalk with a likely read-only community string such as "public" against the target to query standard MIB objects
- B
Use a TCP SYN scan against port 161 to retrieve the SNMP community string from the three-way handshake
- C
Run a zone transfer request against the device because SNMP stores interface and routing data in DNS records
- D
Use an SMTP VRFY request to enumerate device names and interface addresses exposed by SNMP
Show answer and explanation
Correct answer: A
Explanation
The best next step is to use an SNMP-aware enumeration tool such as snmpwalk against UDP 161 with a likely or discovered read-only community string. In real assessments, weak default community strings like "public" and "private" have historically exposed valuable information, especially on older or poorly hardened devices. Standard Management Information Base (MIB) objects can reveal system identity and network configuration, including values under OIDs such as 1.3.6.1.2.1.1 (system), 1.3.6.1.2.1.2 (interfaces), and other IP-related branches depending on the device and SNMP version. This is consistent with practical enumeration methodology: identify the service, test for weak access controls, and retrieve only authorized information. From a best-practice perspective, organizations should disable SNMP where unnecessary, change default community strings, restrict access by source IP, and prefer SNMPv3 with authentication and privacy because SNMPv1/v2c community strings are not cryptographically secure. References: Net-SNMP tool usage documentation for snmpwalk and RFC 1157/RFC 3411-family guidance on SNMP architecture and versions.
- A. Correct.
Correct. SNMP enumeration commonly involves querying UDP port 161 with tools such as snmpwalk, snmpget, or onesixtyone using known or guessed community strings. If the device is using a weak read-only string like "public," an assessor may be able to retrieve system information from standard MIB branches, including sysName, interface tables, ARP tables, and routing-related data depending on access controls and device configuration. This matches a realistic CEH scenario where the goal is to enumerate device information without interactive login.
- B. Incorrect.
Incorrect. SNMP primarily uses UDP 161 for queries, not a TCP three-way handshake. A TCP SYN scan does not reveal SNMP community strings. Community strings are part of the SNMP application-layer request, so they must be tested through SNMP queries rather than inferred from transport-layer behavior.
- C. Incorrect.
Incorrect. DNS zone transfers are related to DNS servers and are performed against DNS service, not SNMP. Although both can disclose infrastructure details, interface and routing information exposed through SNMP is not obtained via DNS zone transfer. This distractor reflects a common confusion between different enumeration services.
- D. Incorrect.
Incorrect. SMTP VRFY is an email-related command used to verify user addresses on mail servers. It has no role in SNMP enumeration of device hostnames, interfaces, or routing tables. This option is plausible only as a generic enumeration technique, but it is unrelated to the service identified on UDP 161.