T1602.001: SNMP (MIB Dump)
Adversaries may target the Management Information Base (MIB) to collect and/or mine valuable information in a network managed using Simple Network Management Protocol (SNMP).
The MIB is a configuration repository that stores variable information accessible via SNMP in the form of object identifiers (OID). Each OID identifies a variable that can be read or set and permits active management tasks, such as configuration changes, through remote modification of these variables. SNMP can give administrators great insight in their systems, such as, system information, description of hardware, physical location, and software packages[1]. The MIB may also contain device operational information, including running configuration, routing table, and interface details.
Adversaries may use SNMP queries to collect MIB content directly from SNMP-managed devices in order to collect network information that allows the adversary to build network maps and facilitate future targeted exploitation.[2][3]
Analyst context for executives and security teams
SNMP MIB dumping matters because it can turn network management data into a reconnaissance asset. If an adversary can query SNMP-managed network devices, the MIB may expose system details, hardware descriptions, physical location, software packages, routing tables, interfaces, and running configuration details that help build a network map for later targeting.
Executive priority
Treat this as a control-validation issue for network infrastructure resilience. Leaders should ask whether SNMP access to network devices is limited to authorized management paths, whether sensitive management data is protected in transit and by configuration, and whether audit evidence exists for segmentation, filtering, intrusion prevention, software updates, and secure SNMP-related configuration. The business risk is not the query alone; it is the exposure of network topology and operational detail that can improve an adversary’s next decision.
Technical view
For SOC, detection engineering, and IR teams, validate visibility around SNMP activity to Network Devices under the collection tactic. Because ATT&CK does not provide official detection text for this sub-technique, coverage should be tested against the related detection strategy DET0453 and local network-device management patterns. Focus on identifying SNMP queries to MIB content from unexpected sources, unusual query volume or breadth, and access to devices outside approved management segments. Interpret findings in context: legitimate network monitoring can resemble collection unless authorized managers, expected devices, and normal polling patterns are well documented.
Likely telemetry
- Network traffic metadata involving SNMP-managed network devices
- Firewall, ACL, or network filtering logs for management-plane access
- Network intrusion detection or prevention events related to SNMP activity
- Network device logs for SNMP access, authentication, or management operations where available
- Configuration-management or asset-inventory records identifying authorized SNMP managers, managed devices, and expected monitoring paths
Detection direction
- Confirm whether DET0453 or an equivalent local analytic is implemented and mapped to this sub-technique.
- Baseline authorized SNMP managers and expected polling behavior so monitoring does not alert only on normal network-management activity.
- Look for SNMP access to MIB content from non-management segments, unexpected hosts, or patterns inconsistent with routine monitoring.
- Correlate SNMP activity with network segmentation and filtering logs to identify management-plane exposure gaps.
- Account for blind spots on older or sparsely logged network devices where SNMP access may not produce reliable device-side evidence.
Mitigation priorities
- Prioritize network segmentation so SNMP-managed devices are reachable only from approved management paths where feasible.
- Filter network traffic to restrict SNMP access to authorized systems and reduce lateral access to management interfaces.
- Use network intrusion prevention where appropriate to block or alert on suspicious SNMP traffic at relevant boundaries.
- Review SNMP and device software configuration to reduce unnecessary exposure of sensitive MIB data.
- Protect sensitive management information in transit where supported by the environment.
Analyst notes and limits
This is a sub-technique of Data from Configuration Repository focused on SNMP MIB content on Network Devices. The supplied relationships provide one detection strategy, DET0453, and mitigations for segmentation, intrusion prevention, filtering, encryption, updates, and secure configuration. Local device inventory and management architecture are essential for deciding what is suspicious versus expected monitoring.
Official ATT&CK detection guidance for this object is not provided, and the supplied relationship does not include DET0453 implementation details. This take does not assert active exploitation, attribution, impact, or detection coverage. Validation requires local telemetry, device logging capability, and knowledge of authorized SNMP management workflows.
SNMP (MIB Dump)
Adversaries may target the Management Information Base (MIB) to collect and/or mine valuable information in a network managed using Simple Network Management Protocol (SNMP).
The MIB is a configuration repository that stores variable information accessible via SNMP in the form of object identifiers (OID). Each OID identifies a variable that can be read or set and permits active management tasks, such as configuration changes, through remote modification of these variables. SNMP can give administrators great insight in their systems, such as, system information, description of hardware, physical location, and software packages[1]. The MIB may also contain device operational information, including running configuration, routing table, and interface details.
Adversaries may use SNMP queries to collect MIB content directly from SNMP-managed devices in order to collect network information that allows the adversary to build network maps and facilitate future targeted exploitation.[2][3]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1602 | Data from Configuration Repository | This object subtechnique of Data from Configuration Repository. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 39d1f374567c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
SANS Information Security Reading Room Securing SNMP Securing SNMP
Michael Stump. (2003). Information Security Reading Room Securing SNMP: A Look atNet-SNMP (SNMPv3). Retrieved October 19, 2020.
Open source URL -
[2]
US-CERT-TA18-106A
US-CERT. (2018, April 20). Alert (TA18-106A) Russian State-Sponsored Cyber Actors Targeting Network Infrastructure Devices. Retrieved October 19, 2020.
Open source URL -
[3]
Cisco Blog Legacy Device Attacks
Omar Santos. (2020, October 19). Attackers Continue to Target Legacy Devices. Retrieved October 20, 2020.
Open source URL -
[4]
Cisco Advisory SNMP v3 Authentication Vulnerabilities
Cisco. (2008, June 10). Identifying and Mitigating Exploitation of the SNMP Version 3 Authentication Vulnerabilities. Retrieved October 19, 2020.
Open source URL -
[5]
mitre-attack T1602.001Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.