MITRE ATT&CK T1602 Data from Configuration Repository: Detecting Data Gathering

A single router or switch configuration can hand an adversary your network map, your routing design and a set of reusable credentials, and the protocols that expose it are often the ones your own monitoring depends on. MITRE ATT&CK T1602 Data from Configuration Repository sits in the Collection tactic (TA0009) on the Network Devices platform. It covers adversaries pulling data from the repositories that management systems use to configure and control devices, through SNMP and the Management Information Base (MIB) or through full configuration dumps. This guide takes the technique view: what the two sub-techniques cover, how named groups have used them, what ATT&CK v20 tells you to detect and where, the mitigations it lists, and how to test your coverage. It is for network engineers, SOC analysts and detection engineers. For SNMP protocol hardening in depth, see the SNMP Security Guide, and for the wider tactic, the ATT&CK Collection Tactic Guide.

Key takeaways

• Configurations are credential stores. Cisco Talos found Salt Typhoon taking device configurations that held SNMP read/write community strings and local accounts with weak password types that can be decrypted offline.
• Two routes, one goal. T1602.001 SNMP (MIB Dump) reads the MIB object by object; T1602.002 Network Device Configuration Dump takes the whole configuration file over SNMP, Smart Install, the CLI or file transfer.
• Detection lives off the endpoint. ATT&CK v20 points to flow records, device syslog, CLI accounting and SNMP access logs, not EDR, so you need network device telemetry in your SIEM.
• The six mitigations are mostly configuration. SNMPv3 with authPriv, SNMP views, a separate management network, ACLs, IPS signatures and current software (M1041, M1054, M1030, M1037, M1031, M1051).
• Assume dumped configs are read offline. Rotate every secret a configuration contains after a suspected dump, because the adversary no longer needs the device to use them.

What T1602 covers

ATT&CK describes configuration repositories as the stores that management systems use to configure, manage and control remote systems, and notes that they can also support remote access and administration. Adversaries target them to collect large volumes of system administration data, much of which serves Discovery. The technique was last modified on 24 October 2025 (version 1.1) and has two sub-techniques.

The data that comes out is a reconnaissance shortcut. ATT&CK lists the network layout, the device and its software, and legitimate accounts and credentials. Talos adds that named interfaces in the configurations helped Salt Typhoon identify upstream and downstream segments for further movement. Collection from a configuration repository therefore often precedes Discovery and Lateral Movement rather than ending an intrusion.

What a typical configuration exposes

How adversaries use it: cases from ATT&CK and published research

• Salt Typhoon (G1045), telecommunications: ATT&CK v20 records the group attempting to acquire credentials by dumping network device configurations, obtaining data using RANCID (a configuration backup tool), and enumerating device configuration over SNMP and the MIB, citing Cisco Talos and CISA advisory AA25-239A. The Talos analysis of February 2025 describes configurations exfiltrated over TFTP and FTP, and capture of SNMP, TACACS and RADIUS traffic including shared secret keys. See the Salt Typhoon Threat Actor Profile and the breach analysis of Salt Typhoon's telecom intrusions, which traces how stolen device secrets led to more secrets.
• 2025 Poland Wiper Attacks (C0063): ATT&CK v20 records that the adversaries gathered FortiGate bookmarks from a configuration file, including statically defined credentials used for RDP connections to jump hosts, citing CERT Polska. The lesson is that a firewall or VPN configuration can contain credentials for systems far beyond the device itself. See the FortiGate Hardening Guide.
• GlassWorm (S9010): ATT&CK v20 records this malware gathering VPN configuration data, including a locally stored FortiClient VPN configuration file on macOS. This is the endpoint side of the same idea: VPN client configurations are configuration repositories too.
• Smart Install abuse: Cisco PSIRT explained in February 2017 that the Smart Install protocol has no authentication, so a client switch left enabled can be told to change its TFTP server setting and copy files, including its configuration, to an attacker host. Cisco's advisory cisco-sa-20180328-smi2 (CVE-2018-0171) was updated in August 2025 to note continued exploitation attempts. ATT&CK names SMI as one of the protocols used for T1602.002.

For the related identity angle, every one of these cases turns on machine credentials: SNMP strings, AAA shared keys, local device accounts and service credentials embedded in configurations. See the MITRE ATT&CK T1552 Unsecured Credentials Guide.

What to detect and where

ATT&CK v20 publishes three detection strategies: DET0592 for the parent technique, DET0453 for SNMP (MIB Dump) and DET0233 for Network Device Configuration Dump. Each maps to data components and log sources on the network device platform.

Behaviour sequences worth an alert

• Auth failures then bulk reads: DET0453 describes repeated SNMP authentication failures followed by successful large-scale OID retrieval from the same source.
• Login then dump then transfer: DET0233 describes anomalous authentication or privilege escalation, then bulk configuration retrieval, then an outbound file transfer.
• Off-window activity: DET0592 calls out repository access outside normal maintenance windows and sudden enumeration of device inventory.
• Tool from the wrong place: a legitimate backup tool such as RANCID or your network configuration manager polling from a host that is not its registered server, or at an unusual time.

Baselining the noise

Your monitoring platform and configuration backup system perform exactly these actions every day. Build allowlists of management station addresses, SNMP users and backup schedules first, then alert on deviation. Talos notes that Salt Typhoon ran collection from jump hosts and devices inside the network, so a source that is "internal" is not enough to clear an alert. See the Network Device Syslog and Configuration Change Detection Guide for log collection and the ESXi Logs Detection Guide for comparable hypervisor telemetry.

Mitigations in ATT&CK v20

NHI Mgmt Group recommendations beyond the ATT&CK list

• Make the central store the source of truth: Talos advises storing configurations centrally and pushing them to devices, and not letting devices be the trusted source of their own configuration. That also turns your backup system into a high-value target: protect it like a PAM vault. See Network Configuration Backup and Change Control.
• Strip secrets from configurations: use strong password types (Talos recommends type 8 for local accounts and type 6 for TACACS+ keys on Cisco), prefer centralised AAA over local accounts, and remove static credentials such as VPN bookmarks.
• Use encrypted transfer only: SCP or SFTP for configuration movement, never TFTP or FTP across segments.
• Harden the management plane: disable unused services such as Guest Shell, the HTTP server and Telnet, as Talos lists. See the Network Device Management Plane Hardening Guide.
• Treat SNMP credentials as non-human identities: inventory them, give each monitoring system its own SNMPv3 user, and rotate on staff change and on suspicion.

How to implement, in order

1. Inventory: list every device with SNMP enabled, the versions and communities in use, whether Smart Install is enabled (Cisco: show vstack config), and where configuration backups are stored and who can read them.
2. Collect telemetry: forward device syslog, AAA command accounting and flow records from management segments to the SIEM before changing anything, so you have a baseline.
3. Restrict reach first: apply management ACLs and segmentation. This is low risk if the inventory of management stations is correct; test on one site and keep a console path for rollback.
4. Migrate SNMP: add an SNMPv3 authPriv user alongside the existing community, switch the monitoring platform over, confirm polling, then remove v1 and v2c communities. Roll back by re-enabling the old community for that device only.
5. Apply views: restrict each SNMP user to the subtrees it needs. Test with the monitoring team, because missing OIDs show up as gaps in graphs rather than errors.
6. Remove secrets and legacy features: disable Smart Install where unused, upgrade password types, move to central AAA.
7. Turn on detections: start with the sequences above in alert-only mode for two to four weeks, tune allowlists, then promote to incidents.

Decision guidance

• Small estates: if you have a handful of devices and one monitoring server, prioritise management ACLs, SNMPv3 and disabling unused services. Full flow analysis may not be worth it; device syslog with authentication and configuration-change events gives most of the value.
• Large or regulated networks: carriers and large enterprises should treat configuration repositories (RANCID, network configuration managers, automation platforms) as tier-zero systems, with privileged access controls, integrity monitoring and alerting on any read by an unexpected identity.
• Legacy devices that cannot run SNMPv3: isolate them on the management network, restrict the community to a single collector with an ACL and a read-only view, and put replacement on the risk register.

How to test your coverage

In an authorised exercise with change approval, run a bulk SNMP walk from a host that is not a management station, then from an approved station outside the maintenance window. Display and copy a configuration from the CLI using a test account, and transfer it with an unapproved protocol. Confirm that each action produced the expected log in the SIEM, that the sequence rules fired, and that the ACLs blocked the unapproved sources. Record time to detect, and repeat after major network changes. The ATT&CK coverage mapping guide explains how to record the result.

Measuring it

• Percentage of devices with SNMPv1 and v2c disabled.
• Percentage of SNMP users bound to an ACL and a restricted view.
• Percentage of devices sending syslog and command accounting to the SIEM.
• Number of devices with Smart Install or other unauthenticated management features enabled (target zero).
• Median time to detect a test configuration dump from an unapproved source.
• Days since last rotation of SNMP credentials and AAA shared keys.

Common failure patterns

• Default or shared community strings: one string across the estate means one leak exposes everything. Salt Typhoon later changed SNMP community strings to keep control, according to the NHI Mgmt Group breach analysis.
• Read-write communities nobody uses: left in place from initial deployment, they allow configuration change as well as collection.
• Backups on file shares: configuration archives on general file servers are collection targets for anyone with access to the share.
• Rotating the device password but not the secrets in the config: after a suspected dump, every community string, shared key and embedded credential is exposed.
• No logging from network devices: without syslog and command accounting, DET0233 and DET0453 cannot be implemented at all.

Framework mapping

Practitioner checklist

• Inventory SNMP versions, communities, SNMPv3 users and Smart Install status on every network device.
• Disable SNMPv1 and v2c where possible; use SNMPv3 authPriv with SHA-2 and AES.
• Bind each SNMP user to an ACL of named management stations and a read-only view.
• Run no vstack on Cisco switches that do not use Smart Install, and block TCP 4786 at the edge.
• Move configuration transfers to SCP or SFTP and protect the configuration store as a privileged system.
• Remove reversible password types and embedded static credentials from configurations.
• Forward device syslog, command accounting and management segment flows to the SIEM.
• Alert on bulk SNMP reads, configuration display or copy, and outbound transfers from unapproved sources or outside windows.
• After any suspected dump, rotate every secret the configuration contained.

Standards and references

• MITRE ATT&CK: T1602 Data from Configuration Repository
• MITRE ATT&CK: T1602.001 SNMP (MIB Dump)
• MITRE ATT&CK: T1602.002 Network Device Configuration Dump
• Cisco Talos: Weathering the storm, in the midst of a Typhoon
• Cisco: Securing SNMP access
• Cisco: Smart Install Remote Code Execution Vulnerability (cisco-sa-20180328-smi2)
• Cisco PSIRT: Mitigating and Detecting Potential Abuse of Cisco Smart Install Feature
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: SNMP Security Guide, ATT&CK Collection Tactic Guide, Network Device Management Plane Hardening Guide, Salt Typhoon Threat Actor Profile, T1016 System Network Configuration Discovery.