Skip to content

SNMPv3 Fingerprinting #10

@Zamanry

Description

@Zamanry

SNMPv3 adds two standardized, unauthenticated discovery mechanisms that let you fingerprint its presence without knowing any credentials:

  1. Engine-ID Discovery (RFC 5343)
    Every SNMPv3 engine MUST support a GET of the “well-known” OID snmpEngineID.0 (1.3.6.1.6.3.10.2.1.1.0) and reply with a REPORT or GetResponse containing its engineID. This is defined in RFC 5343, which updates the SNMPv3 architecture in RFC 3411 by specifying exactly how managers can learn an agent’s engineID before any authentication.

  2. USM-Model Error Reporting (RFC 3414 § 4.2)
    If you issue an SNMPv3 GET with a bogus userName (and no valid security parameters), a compliant agent MUST reply with a REPORT PDU whose usmStatsUnknownUserNames.0 OID (1.3.6.1.6.3.15.1.1.4.0) indicates “unknown user.” This behavior, mandated by RFC 3414 § 4.2, confirms the presence of the USM model itself.

By combining these two probes—engine-ID discovery and USM error reporting—you can unambiguously detect virtually any SNMPv3 implementation on UDP/161, even when no valid credentials exist. This will enable us to only spray v3 dictionaries against valid SNMPv3 targets, substantially increasing efficiency by not spraying v3 creds against non-v3 targets. The only systems we would be missing with this fingerprinting approach would be managers not support RFC 3414 or 5343 which is unlikely. We should add a --no-fingerprint flag for those who wish to have all targets sprayed with v3 dictionaries.

Please note that SNMPv1/2c do not support unauthenticated fingerprinting given my consultation with ChatGPT o4-mini and prior manual research.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions