SNMP's defaults are the most reliable way in. The overwhelming majority of agents ship with public as the read-only string and private (or write) as the read-write string, and these are left unchanged on a large share of real devices, printers, switches, access points, IP cameras, and appliances especially. Vendors also add their own defaults (for example cisco, ILMI, admin, security on various gear). So the first action against any SNMP agent is to try the documented defaults for read and, separately, for write, because a default read string gives full enumeration and a default write string gives device control.
# test common read defaults
for c in public private cisco ILMI community manager admin security read; do
snmpget -v2c -c $c -t1 -r0 <target> 1.3.6.1.2.1.1.1.0 2>/dev/null \
| sed "s/^/[$c] /"; done
# specifically test write (needs a read-write string): a harmless re-set of sysContact
snmpset -v2c -c private <target> 1.3.6.1.2.1.1.4.0 s "$(snmpget -v2c -c private -Ov -Oq <target> 1.3.6.1.2.1.1.4.0 2>/dev/null)" 2>/dev/null && echo "WRITE works: private"
Exploitation notes#
- Try read and write defaults separately:
publicfor read is near-universal, and a workingprivatefor write is device control; many devices have one default but not the other. - Fingerprint the device first where possible (Device information) to add the vendor-specific defaults for that product to the list.
- Appliances and embedded devices (printers, cameras, PDUs, switches) are the most likely to retain defaults and are high-value because SNMP often exposes their full configuration.
- If defaults fail, move to weak strings and brute force; a found string then drives enumeration and, if read-write, write access.