Secure by Design, Exposed by Reality: Rethinking SNMPv3

Most security teams treat SNMPv3 as a solved problem. Authentication. Encryption. Case closed.

Our research proves otherwise. SNMPv3 functions exactly as designed, yet its pre-authentication responses leak signals that can collapse a brute-force problem from billions of combinations into a focused password guess. This is not a broken protocol. It is a design tradeoff that was acceptable when the standard was written and is dangerous in 2026.

This report documents how those signals work, demonstrates a staged attack pathway that exploits them, and provides concrete mitigations for organizations running SNMP in production.

Executive Summary

SNMP sits at the core of every managed network. It monitors routers, switches, firewalls, and embedded devices across every infrastructure segment. SNMPv3 was built to replace the cleartext weaknesses of its predecessors with proper authentication and encryption. It succeeded on paper.

Our research shows that SNMPv3's pre-authentication exchanges expose distinguishable signals that can reduce credential attack complexity by orders of magnitude. These behaviors are standards-compliant and intentional. They do not arise from vendor bugs or misconfiguration. They stem from protocol design decisions that prioritized interoperability and diagnostics over zero-knowledge authentication.

In practice, an unauthenticated remote actor can identify the device vendor through engineID analysis, enumerate valid usernames through differential Report-PDU responses, and narrow the authentication algorithm space to a handful of vendor-typical configurations. What starts as a multi-dimensional search space (usernames x algorithms x passwords) collapses into a targeted password-guessing problem.

We validated these findings across approximately 470,000 SNMP-enabled endpoints. 99.4% of devices leaked vendor identity through their engineID prefix. The implications are operational, immediate, and relevant to any organization with SNMP-accessible infrastructure.

Does This Apply to Your Organization

Yes. This research is relevant to any organization that operates network infrastructure monitored or managed through SNMP: enterprises, cloud environments, service providers, industrial networks, and organizations running routers, switches, firewalls, network appliances, or embedded systems that support SNMPv3.

Risk increases when SNMP management interfaces are reachable outside trusted management networks, when credentials are weak or reused, or when monitoring systems rely on default or predictable configuration patterns. Even environments running SNMPv3 with authentication and encryption may still expose the pre-authentication signals described in this report.

Who Should Read This

Security leaders, network architects, security researchers, and defenders (CISOs, SOC analysts, red/blue teams) who need to understand how SNMPv3's standards-compliant behaviors create reconnaissance value for attackers, and how to detect, harden, and monitor against it.

What's SNMP

Simple Network Management Protocol (SNMP) is the standard protocol for monitoring and managing network devices: routers, switches, firewalls, printers, servers. It uses a manager-agent model where the manager queries agents running on devices to retrieve structured data from a Management Information Base (MIB). Administrators use it to collect performance data, check configuration status, and in some cases modify device settings remotely.

For attackers, SNMP is a goldmine. Misconfigured or publicly exposed SNMP services, particularly older versions like SNMPv1/v2c using weak community strings, can reveal device types, software versions, network topology, routing tables, interface details, and configuration data. This intelligence dramatically reduces reconnaissance time, identifies vulnerable assets, and enables lateral movement or further exploitation. When not properly secured, SNMP functions as a blueprint of an organization's internal network.

SNMPv3 on the Crosshair

SNMP has been a high-value target for decades. Offensive security guides for pentesting and exploiting SNMP are widely available through Metasploit, HackTricks, Hackviser, and other frameworks.

Because of its central role in network infrastructure and its broad visibility across managed environments, SNMP has attracted consistent attention from threat actors at every level of sophistication. From the cleartext community strings of SNMPv1 through operational weaknesses in SNMPv3, every version of the protocol has been tested in real-world campaigns. The following cases illustrate what that looks like in practice.

State-Sponsored Threat Actors

In 2018, a joint alert by CISA, FBI, and UK NCSC described how Russian state-sponsored cyber actors had been actively exploiting network infrastructure devices (routers, switches, firewalls) on a global scale to gain unauthorized access, conduct reconnaissance, and enable further compromise. The campaign affected government and private-sector organizations, critical infrastructure providers, and the service providers that support them. This advisory was reissued multiple times between 2021 and 2025.

State-sponsored actors continue to value SNMP. A late-2025 report by Cisco Talos details how "Static Tundra," a Russian state-sponsored cyber espionage group, targets network infrastructure devices and embedded systems using botnets, exploiting default credentials and exposed management interfaces. While not SNMP-specific, the campaign reinforces a recurring pattern: attackers systematically scan for and abuse exposed management protocols. SNMP is frequently among the services left reachable on the public internet, and weak or default credentials make these devices trivial footholds. The operational lesson is clear: exposed management planes, whether via HTTP, SSH, or SNMP, are high-value targets for automated compromise. Attackers do not need advanced exploits when they can reach a service and guess credentials. SNMP's pre-authentication signals make these interfaces even richer targets for reconnaissance and follow-on exploitation.

July 2026: Joint Advisory AA26-194A

The most recent and definitive evidence arrived on July 13, 2026. CISA, NSA, FBI, DC3, and intelligence agencies from nineteen partner organizations across fifteen allied nations issued Joint Cybersecurity Advisory AA26-194A, confirming that Russian FSB Center 16 cyber actors (tracked under multiple designations including Berserk Bear, Energetic Bear, Dragonfly, Ghost Blizzard, and Static Tundra) continue to exploit poorly configured routers worldwide, compromising critical infrastructure networks across communications, defense industrial base, energy, financial services, government services, and healthcare sectors.

The primary attack method is exactly what this research examines: scanning Internet IP ranges for devices running SNMP agents that accept common or default community strings, then using SNMP Set-Requests from spoofed IP addresses to instruct target devices to copy their configuration files and transfer them, typically via TFTP, to attacker-controlled virtual private servers or compromised FTP infrastructure. The advisory notes overlap with techniques used by other state-level actors, including Salt Typhoon.

The advisory explicitly mandates upgrading to SNMPv3 with authPriv and modern encryption, disabling SNMPv1 and SNMPv2, restricting management protocol access through ACLs, monitoring SNMP OIDs for reconnaissance indicators, and blocking external communications on UDP ports 161/162 and TCP/UDP ports 10161/10162.

This joint advisory, co-issued by the US, UK, Australia, Canada, Czech Republic, Denmark, Estonia, Finland, France, Italy, New Zealand, Poland, and Sweden, confirms that SNMP exploitation is not theoretical. It is an active, state-sponsored operation targeting the management plane weaknesses this research documents.

Our findings on SNMPv3 pre-authentication signal leakage add a critical dimension: even organizations that have upgraded to SNMPv3, as the advisory recommends, remain exposed to the reconnaissance and credential-narrowing techniques described in this report.

Reference: CISA Joint Cybersecurity Advisory AA26-194A, "Improve Router Hygiene to Protect Against Russian State-Sponsored Targeting," July 13, 2026.

Deploying Rootkits into Network Infrastructure

Towards the end of 2025, a high-severity vulnerability in the SNMP subsystem of Cisco IOS and IOS XE devices was discovered (CVE-2025-20352). The vulnerability stems from a stack-overflow condition triggered by crafted SNMP packets. The flaw allows an authenticated remote attacker to crash devices and cause denial-of-service conditions. In more severe cases, it enables arbitrary code execution as root, giving full control over network infrastructure such as switches and routers.

This vulnerability was soon exploited in the wild, enabling threat actors to achieve remote code execution on switches and deploy stealthy rootkits directly into network infrastructure.

Once compromised, these devices become ideal persistence points. Adversaries can manipulate routing, intercept traffic, conceal configuration changes, and move laterally across segmented environments while remaining largely invisible to endpoint-centric defenses. Switches and routers underpin visibility and control. Compromising them effectively blinds defenders and grants attackers a privileged position inside the organization's core network fabric.

Botnets Targeted SNMP

Historically, botnets targeted exposed SNMPv1 and SNMPv2c instances to generate amplified denial-of-service (DDoS) attacks. The technique: an attacker sends small, spoofed requests to SNMP servers with a forged source IP (the victim's IP). Because SNMP servers reply with much larger responses, the victim gets flooded with amplified traffic.

Old Discussion, Serious Threat

Malanta researchers analyzed well-known, standards-compliant behaviors in SNMPv3 and identified a novel attack flow that chains these behaviors into a staged credential-narrowing pathway. Our contribution is not the discovery of individual protocol signals, which are documented in the RFCs, but the demonstration that combining them creates a materially reduced authentication search space with operational security implications.

Our research demonstrates how SNMPv3's pre-authentication exchanges can unintentionally weaken its effective security posture by exposing distinguishable signals during standard protocol operation.

SNMPv3 engineID discovery and the User-based Security Model (USM) Report-PDUs allow an unauthenticated remote actor to deterministically distinguish between unknown-username errors, wrong-digest errors, and decryption errors before any credential is validated. These differential responses, combined with vendor fingerprinting via the engineID enterprise prefix, enable a staged reduction of the authentication search space from a multi-dimensional combinatorial problem to a substantially narrower, guided credential guess.

This behavior is not vendor-specific and does not indicate non-compliance or defects in any particular implementation. The differential responses are defined by RFC 3414 (USM) and RFC 3412/3414 Report-PDU handling, and represent standards-compliant protocol behavior as designed.

Although this behavior may not be formally classified by the IETF as a vulnerability or protocol flaw, the operational security impact is significant and measurable, particularly in environments where SNMP management interfaces are reachable from untrusted networks.

Our Research in Simple Terms

Authenticating to an SNMPv3 instance typically requires a valid username, password, and associated authentication parameters (authentication and privacy protocols such as SHA/MD5 for authentication and AES/DES for encryption). The combination of possible values across these three dimensions creates a large search space that makes brute-force attacks computationally infeasible under normal conditions.

This complexity is what makes SNMPv3 appear highly secure in theory. The protocol-level signals described above can reduce that apparent complexity in practice.

Our work builds on established research. The paper "Third Time's Not a Charm: Exploiting SNMPv3 for Router Fingerprinting and Credential Theft" presented at USENIX Security 2024 systematically examined SNMPv3's pre-authentication metadata and demonstrated how engineID structures and USM Report-PDU variations can be leveraged for device fingerprinting and credential inference.

Prior research treated pre-authentication signals mainly as identification artifacts. Our work takes a fundamentally different approach: we model these signals as components of a staged attack pathway. Specifically:

Rather than treating pre-authentication signals merely as identification artifacts, we model them as components of a staged attack pathway:

1. It can reveal the vendor through the engineID: The engineID structure frequently contains enterprise identifiers that map directly to known vendors. This reveals the implementation family and its likely default configurations, algorithms, and credential patterns.

2. It narrows which security settings are likely in use: Once the vendor is known, the likely authentication and encryption algorithms are significantly constrained. Most vendors ship with a small, predictable set of defaults.

3. It can reveal whether a username exists: By returning different Report responses, the device may indicate whether a username is valid or not. Specifically, the protocol distinguishes between:

• "Unknown username"
• "Wrong password / wrong key"

These responses are part of the standard. They exist to help legitimate systems synchronize and troubleshoot. From an attacker's perspective, they reduce a blind credential search across the space of:

|U| x |R| x |W|

Where U is usernames, R is auth/priv algorithm pairs, and W is the password space.

An attacker can now:

• Infer the vendor (and likely algorithm defaults)
• Enumerate valid usernames
• Reduce the search space dramatically, to focus on passwords

Into a materially smaller, guided space:

|U'| x |Rv| x |W|

Where U' is guessed usernames, Rv is known auth/priv algorithm pairs, and W is the password space.

Proof of Concept

To validate this exploitation sequence, we used controlled, rate-limited SNMPv3 requests against authorized systems. No credentials were compromised, and no unauthorized access was obtained. The tool is included to demonstrate the reduction in effective search space, not to automate credential compromise.

We first conducted a one-time discovery of internet-connected devices with an open SNMP port. We sampled approximately 470,000 devices. Of these:

• 73,000 (approximately 15.5%) responded as SNMPv1/v2c
• The remaining 397,000 (approximately 84.5%) negotiated SNMPv3
• Analysis of the snmpEngineID prefix revealed that in approximately 467,138 devices (99.4% of the sample) the signal allowed us to map the vendor/family. Only 2,862 devices (0.6%) remained unmapped
• Vendor mapping shows Cisco (302,601) and Enterprise-0 (105,241, open-source stacks) together comprise approximately 86.8% of the entire sample

Pre-authentication engineID inference significantly narrows the set of plausible implementation families for the vast majority of exposed SNMPv3 devices.

Based on these findings, we developed a Golang proof-of-concept tool that implements the following stages:

Authentication mode narrowing: Using pre-authentication engine discovery metadata, the tool restricts the set of plausible auth/priv algorithm pairs to those typical for the identified vendor family.

Username enumeration: The tool submits standards-compliant SNMPv3 requests using candidate usernames and classifies responses as "unknown user," "wrong digest," or "decryption error," deterministically identifying valid principals.

Credential feasibility testing: For an identified principal and a reduced set of plausible authentication modes, the tool demonstrates the feasibility of password-only brute-force by iterating over a focused candidate list.

The purpose of this tool is to empirically demonstrate how standards-conformant SNMPv3 behavior enables a staged reduction of authentication uncertainty. It does not assert guaranteed exploitation outcomes and does not publish operational parameters, dictionaries, or vendor-specific recipes.

The proof-of-concept exercises standard SNMPv3 User-based Security Model (USM) processing by issuing well-formed SNMPv3 requests with intentionally incorrect authentication material.

We first search for the vendor:

Then, for each candidate username, the code submits a single SNMPv3 GET request and observes the resulting Report-PDU or error response returned by the agent:

The implementation classifies responses based on the standardized USM statistics OIDs surfaced during pre-authentication, specifically distinguishing between:

• usmStatsUnknownUserNames
• usmStatsWrongDigests
• usmStatsDecryptionErrors

This distinction allows the PoC to deterministically infer whether a supplied msgUserName corresponds to an existing SNMPv3 principal, despite the absence of valid credentials and without violating protocol specifications.

Once two of the spaces collapse, we are left with guessing the password based on a pre-made password list:

To summarize: we have demonstrated how the combination of pre-authentication signals, structured guess lists, and a deep understanding of the protocol can materially reduce the effective complexity of SNMPv3 authentication. What initially appears to be a multi-dimensional search space can, under certain conditions, collapse into a focused password-guessing problem.

Accelerated by AI and Compute

This design tradeoff has existed since the early 2000s. For most of that time, the narrowed search space was a theoretical concern. Even with the pre-authentication signals described above, executing a credential attack at scale required significant time and computational resources. That calculus has changed.

AI-powered attack tooling can now analyze pre-authentication responses, optimize credential candidate lists based on vendor fingerprints and leaked credential databases, and adapt guessing strategies dynamically. Models trained on default configuration patterns can prioritize statistically likely passwords for a given device family, converting what was once a brute-force exercise into an informed, targeted operation. Simultaneously, commodity cloud compute and widely accessible GPU resources have driven the cost of password cracking to a fraction of what it was five years ago.

The convergence is significant: a protocol design that narrows the credential search space, AI tooling that optimizes which credentials to try first, and compute resources that can cycle through candidates at scale. Each factor compounds the others. The practical security margin that SNMPv3 was assumed to provide through combinatorial complexity is eroding, and the rate of erosion is accelerating. What was a manageable design tradeoff in 2004 has become a materially higher risk in 2026.

How to Mitigate: Closing the Window

Move SNMP to Authenticated Transport (TLSTM): Run SNMPv3 over TLS or DTLS (TLSTM) instead of raw UDP/161. This removes the exposed pre-authentication behavior at the transport layer and shifts trust to modern cryptographic channels. If you are still exposing UDP/161 to the internet, treat that as transitional risk.

De-Internet Your Management Plane: Management protocols should not be internet-facing.

• Segment management networks
• Enforce strict ACLs
• Restrict SNMP to known IP ranges only
• Use VACM views properly

SNMP should live in a management enclave, not on the public internet.

Harden SNMPv3 USM: If TLS is not an option:

• Require authPriv mode
• Use HMAC-SHA-2 authentication
• Use AES-128 (or stronger) encryption
• Disable MD5, SHA-1, and deprecated privacy modes
• Implement rate limiting if supported

Monitor the Pre-Attack Signals Attackers Would Use:

Track spikes in:

• usmStatsUnknownUserNames
• usmStatsWrongDigests
• usmStatsNotInTimeWindows

Cross-reference requests and inbound traffic with intelligence sources to:

• Identify low-level attack signals
• Enable preemptive measures when a campaign indicator is detected

These counters are not just diagnostics. They are reconnaissance indicators. If you do not monitor them, you will not know you are being enumerated.

The Bottom Line

The SNMPv3 behavior described here is not a zero-day. It is not an implementation flaw. It is a design-era tradeoff. In the hands of an attacker, even standards-compliant behavior can be escalated, chained, and weaponized.

From an operational perspective, SNMP weaknesses are dangerous precisely because they are easily discoverable and widely exposed. Attackers routinely scan the internet and internal address space for open SNMP services, weak community strings, and legacy devices. The July 2026 CISA advisory confirms this is not theoretical: FSB Center 16 actors are doing exactly this, right now, against critical infrastructure routers worldwide.

A single exposed or poorly secured SNMP interface can shift an attacker from reconnaissance to full infrastructure control. SNMP is not just a monitoring protocol. It is a high-value attack vector that can enable stealthy persistence, network manipulation, and large-scale compromise if misconfigured or left unpatched.

From Research to Readiness: The Pre-Attack Prevention Layer

SNMP is one example. The pattern repeats across every exposed service, management interface, legacy configuration, and newly disclosed vulnerability in a modern enterprise. Every attack begins with preparation: infrastructure is registered, configured, and staged before execution. This preparation phase, mapped to MITRE ATT&CK TA0042 (Resource Development), is where adversaries are most active and least observed.

Where Traditional Controls Fall Short

Most security programs rely on two established pillars. Both are necessary. Neither covers the critical gap.

Traditional Threat Intelligence operates on Indicators of Compromise: domains, IPs, hashes, and signatures extracted from incidents that already happened. It looks backward. By the time an IOC reaches a feed, the attack it describes is historical. Detection rules built on yesterday's indicators catch replays. They do not catch preparation.

Exposure Management focuses inward: discovering your own assets, mapping vulnerabilities, scoring misconfigurations, prioritizing patches. It answers the question "where am I weak?" It does not answer "who is preparing to exploit that weakness, and when?"

The gap between these two is the setup window: the period between an attacker preparing infrastructure and executing the attack. That window is where defenders have the most lead time and the least visibility.

Indicators of Pre-Attack: Closing the Setup Window

Indicators of Pre-Attack (IoPAs) surface adversary infrastructure preparation activity: domain registration patterns, certificate staging, hosting configurations, WHOIS clustering, and infrastructure reuse across attack campaigns. These are not post-compromise artifacts. They are pre-attack signals, observable before a single payload is delivered.

Where traditional threat intelligence tells you what happened, and exposure management tells you where you are vulnerable, IoPAs tell you who is preparing to act, against what, and how far along they are. The three operate as complementary layers:

Exposure Management: "Where am I vulnerable?" Present-state asset and configuration visibility.

Threat Intelligence: "What attacks have occurred?" Post-incident indicators and attribution.

Pre-Attack Prevention (IoPAs): "Who is preparing to attack, and when?" Pre-execution adversary infrastructure signals.

IoPAs give defenders something the other two cannot: lead time. The window between adversary preparation and execution is measurable. Sometimes days. Sometimes weeks. That window is actionable.

How Malanta Delivers Pre-Attack Prevention

Malanta's platform continuously identifies Adversary Infrastructure Identity through common identity attributes, clustering attack infrastructure, and correlating pre-attack signals against protected assets. The result is operational visibility into the Resource Development phase (TA0042) before it transitions to execution.

More broadly, Malanta makes the adversary's preparation phase visible and operational. We do not replace threat intelligence or exposure management. We extend the defensive timeline backward, into the phase where adversaries build their tools and stage their infrastructure, where they are most exposed to disruption and takedown.

From Signal to Preemptive Action

The next time you observe pre-authentication anomalies on SNMP or any other protocol and you see them accumulate into volume, pattern, or coordinated activity, you should not be guessing.

You should be acting.

Whether the source is:

• A zero-day exploitation campaign
• A known misconfiguration being harvested at scale
• Credential stuffing automation
• A state-sponsored reconnaissance operation

Early visibility allows you to take preemptive action: restrict exposure, enforce segmentation, rate-limit aggressively, rotate credentials, or block hostile infrastructure before escalation occurs.

Attackers move from preparation to compromise predictably. The advantage belongs to those who can see the preparation phase clearly.

That is what Pre-Attack Prevention delivers.

Responsible Disclosure Process

We responsibly disclosed our findings to the IETF and received confirmation that the observed behavior is known and stems from deliberate design decisions made during the creation of SNMPv3's User-Based Security Model (USM). The IETF clarified that pre-authentication Report PDUs and related disclosures were intentionally designed to support operational requirements such as discovery and management and are considered protocol-compliant rather than implementation flaws.

‍