AN1249: Analytic 1249
Defenders may observe suspicious SNMP MIB enumeration through abnormal queries for large sets of OIDs, repeated SNMP GETBULK/GETNEXT requests, or queries originating from non-administrative IP addresses. Anomalous use of community strings, authentication failures, or enumeration activity outside maintenance windows may also indicate attempts to dump MIB contents. Correlation across syslog, NetFlow, and SNMP audit data can reveal chains of behavior such as repeated authentication failures followed by successful large-scale OID retrieval.
Analyst context for executives and security teams
This analytic matters because SNMP MIB enumeration can expose detailed network device information that supports later compromise, misconfiguration discovery, or operational mapping. For leaders, the practical question is whether network-device monitoring can distinguish normal administration from abnormal large-scale SNMP queries, especially from non-administrative IP addresses or outside approved maintenance windows.
Executive priority
Prioritize this as a network infrastructure visibility and resilience issue. Coverage depends less on a single alert and more on whether teams can correlate SNMP audit data, syslog, and NetFlow to prove who queried network devices, when, from where, and at what scale. This is useful for incident response scoping, compliance evidence around administrative access monitoring, and validating that network management protocols are not creating an unmanaged blind spot.
Technical view
For SOC, detection engineering, and IR teams, validate monitoring for suspicious SNMP MIB enumeration on network devices. The supplied ATT&CK description highlights abnormal queries for large OID sets, repeated SNMP GETBULK or GETNEXT requests, queries from non-administrative IP addresses, anomalous community string use, authentication failures, and activity outside maintenance windows. Correlation should look for sequences such as repeated authentication failures followed by successful large-scale OID retrieval. No ATT&CK tactics or relationships were supplied, so local mapping to incident scenarios should be environment-driven.
Likely telemetry
- SNMP audit logs from network devices or management platforms
- Syslog from network devices
- NetFlow or equivalent network flow records showing SNMP traffic patterns
- Authentication failure events related to SNMP access
- Records of approved administrative source IP addresses and maintenance windows
Detection direction
- Baseline normal SNMP polling behavior by administrative source, device class, time window, request type, and expected OID volume.
- Alert or hunt for large-scale OID retrieval, repeated GETBULK/GETNEXT activity, and SNMP queries from non-administrative IP addresses.
- Correlate authentication failures, anomalous community string use, and subsequent successful enumeration activity across syslog, NetFlow, and SNMP audit data.
- Tune for legitimate network management systems and scheduled maintenance to reduce false positives.
- Check for blind spots where SNMP traffic is visible in flows but not enriched with request type, authentication outcome, community string anomalies, or target device context.
Mitigation priorities
- Define and maintain an authoritative list of approved SNMP management sources and maintenance windows.
- Restrict SNMP access to expected administrative systems and review exposure on network devices.
- Ensure network devices and management systems produce logs sufficient to identify SNMP authentication failures, source addresses, request patterns, and large OID retrieval behavior.
- Centralize syslog, NetFlow, and SNMP audit data so incident responders can reconstruct enumeration chains.
- Use detection tuning and periodic validation to confirm that abnormal SNMP enumeration would be visible, investigated, and documented.
Analyst notes and limits
The object is a detection analytic for Network Devices focused on suspicious SNMP MIB enumeration. Although the official detection field is not provided, the official description contains concrete detection ideas and correlation points. Because no relationships or tactics were supplied, this take avoids linking the analytic to a specific ATT&CK technique, campaign, actor, or impact path.
Assessment is limited to the supplied ATT&CK analytic fields and one external MITRE reference. Local device logging, SNMP configuration, network management architecture, approved administrative sources, and maintenance schedules are required to determine actual coverage and risk.
Analytic 1249
Defenders may observe suspicious SNMP MIB enumeration through abnormal queries for large sets of OIDs, repeated SNMP GETBULK/GETNEXT requests, or queries originating from non-administrative IP addresses. Anomalous use of community strings, authentication failures, or enumeration activity outside maintenance windows may also indicate attempts to dump MIB contents. Correlation across syslog, NetFlow, and SNMP audit data can reveal chains of behavior such as repeated authentication failures followed by successful large-scale OID retrieval.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.0 | Current bundle | dd109195eda9… |
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]
mitre-attack AN1249Open 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.