A Primer to Russian Intelligence “Snake” Malware

“Snake” Malware

Snake is a malware that was originally developed by the FSB (Federal Security Service of the Russian Federation) in late 2003 under the name “Uroburos”. That development ended in early 2004, at which time it began conducting cyber operations.

Snake has been one of the major tools used by Center 16 of the FSB, the notorious Russian Turla hacking group. It has been in use for almost 20 years and FSB conducted a vast number of operations with it.

Described as “the FSB’s most sophisticated long-term cyberespionage malware implant,” Snake allowed its operators to remotely install malware on compromised devices, steal sensitive documents and information (e.g., authentication credentials), maintain persistence, and hide their malicious activities when using this “covert peer-to-peer network.”

As discussed by a Joint Cybersecurity Advisory compiled by cybersecurity and intelligence agencies from all Five Eyes member nations (the United States, the United Kingdom, Canada, Australia and New Zealand) and issued by the Cybersecurity & Infrastructure Security Agency (CISA), the Snake implant is considered the most sophisticated cyber espionage tool designed and used by Center 16 of Russia’s FSB for long-term intelligence collection on sensitive targets. To conduct operations using this tool, the FSB created a covert peer-to-peer (P2P) network of numerous Snake-infected computers worldwide. Many systems in this P2P network serve as relay nodes which route disguised operational traffic to and from Snake implants on the FSB’s ultimate targets. Snake’s custom communications protocols employ encryption and fragmentation for confidentiality and are designed to hamper detection and collection efforts.

The Snake infrastructure has been found in over 50 countries across North America, South America, Europe, Africa, Asia, and Australia, to include the United States and Russia itself. Although Snake uses infrastructure across all industries, its targeting is purposeful and tactical in nature. Globally, the FSB has used Snake to collect sensitive intelligence from high-priority targets, such as government networks, research facilities, and journalists. As one example, FSB actors used Snake to access and exfiltrate sensitive international relations documents, as well as other diplomatic communications, from a victim in a North Atlantic Treaty Organization (NATO) country. Within the United States, the FSB has victimized industries including education, small businesses, and media organizations, as well as critical infrastructure sectors including government facilities, financial services, critical manufacturing, and communications.

What is it?

Essentially, the U.S. government kept a close eye on Snake and Snake-linked malware tools for almost 20 years while also monitoring Russian Turla hackers using Snake from their FSB facility in Ryazan, Russia.

The malware was disrupted following a coordinated effort named Operation MEDUSA (get it?). As this US Department of Justice press release states:

“The Justice Department, together with our international partners, has dismantled a global network of malware-infected computers that the Russian government has used for nearly two decades to conduct cyber-espionage, including against our NATO allies,” said Attorney General Merrick B. Garland. “We will continue to strengthen our collective defenses against the Russian regime’s destabilizing efforts to undermine the security of the United States and our allies.”

“Operation MEDUSA disabled Turla’s Snake malware on compromised computers through the use of an FBI-created tool named PERSEUS, which issued commands that caused the Snake malware to overwrite its own vital components. Within the United States, the operation was executed by the FBI pursuant to a search warrant issued by U.S. Magistrate Judge Cheryl L. Pollak for the Eastern District of New York, which authorized remote access to the compromised computers.”

“As described in court documents, through analysis of the Snake malware and the Snake network, the FBI developed the capability to decrypt and decode Snake communications. With information gleaned from monitoring the Snake network and analyzing Snake malware, the FBI developed a tool, named PERSEUS, that establishes communication sessions with the Snake malware implant on a particular computer, and issues commands that causes the Snake implant to disable itself without affecting the host computer or legitimate applications on the computer.”

As discussed by the advisory, the disruption of the malware was possible due to mistakes in development and operation, which allowed investigators to track Snake and manipulate its data.

“The FSB used the OpenSSL library to handle its Diffie-Hellman key exchange. The Diffie-Hellman key-set created by Snake during the key exchange is too short to be secure. The FSB provided the function DH_generate_parameters with a prime length of only 128 bits, which is inadequate for asymmetric key systems. Also, in some instances of what appeared to be rushed deployments of Snake, the operators neglected to strip the Snake binary. This led to the discovery of numerous function names, cleartext strings, and developer comments as seen in the following figure.”

Figure 1: Non-Stripped Function and Command Names (Source: CISA)

As discussed by the advisory, the disruption of the malware was possible due to mistakes in development and operation, which allowed investigators to track Snake and manipulate its data.

“Snake” Host-Based Technical Details

jpinst.exe and jpsetup.exe are examples of Snake installer names and the Snake installer employs sophisticated customized methods to run, with its underlying code obfuscated through the use of legitimate open-source code for a JPEG viewer. Once its code is unpacked, the installer extracts an executable file, which in turn decompresses an encrypted AES blob. Once decrypted, many components are extracted and among them are other executables utilized by the Snake malware. The encrypted blob can be found at HKLM:\SOFTWARE\Classes.wav\OpenWithProgIds.

To elude discovery, Snake employs an unusual level of stealth, utilizing its kernel module to erase its components from all Windows machine lists. Additionally, it utilizes an encrypted, covert storage mechanism to evade detection. As a result, detecting Snake proves challenging, even when employing external search tools.

Snake maintains its persistence in the system by registering a service. It usually is named WerFaultSvc and mimics the legitimate Windows service WerSvc. When the service is registered it launches WerFault.exe on system boot allowing Snake to persist after shutdown. Snake exe is hidden in %windows%\WinSxS\ directory among other legitimate Windows executables.

Figure 2: Snake Boot Cycle (Source: CISA)

When launched, Snake’s WerFault.exe will attempt to decrypt an encrypted blob in the Windows registry, commonly located at HKLM:\SOFTWARE\Classes.wav\OpenWithProgIds. The Encrypted details comprise the AES key, IV, and path, which are necessary to trace and decode the file housing Snake’s kernel driver and kernel driver loader. The registry object’s structure can be seen on the right side of the following figure. Snake uses Microsoft Windows Cryptography API: Next Generation (CNG) key store to store the AES key needed to decrypt the registry object.

Figure 3: Driver Decryption Routine (Source: CISA)

During the installation process, Snake drops the kernel driver and DLL file. In detected Snake instances the file is named comadmin.dat and is in %windows%\system32\Com.

The last host-based artifact to discuss is the Queue File. Typically, this file has been found within the %windows%\ Registration directory with the format of ..crmlog, and is decrypted by Snake’s
kernel driver.

The Queue is a Snake structure that contains various pieces of information, including key material, communication channels, modes of operation, the principal user mode component, etc., that Snake requires for successful operation. It should be noted that this is a name used by the developers and is not equivalent to a “queue” in the normal context of computer science. The Queue data is saved on disk in the Queue File, which is a flat file with a substructure that includes a 0x2c-byte file header followed by data blocks. Each data block corresponds to exactly one Queue Item, which could be, for example, a simple configuration parameter, a Snake command, or an entire embedded executable. Each Queue Item is associated with a specific Queue Container.

A detailed discussion of the Queue is contained within the advisory.

Snake leverages its unique HTTP and raw socket TCP protocols to send massive amounts of data. By utilizing a distinct authentication process, Snake separates its data from regular application data on the compromised server.

One of the most notable features of Snake is its capability to function effectively as server software without needing to open additional ports on the compromised system. The authentication value specific to each implant is called the “ustart”, and it is stored in the implant’s Queue File. There are several versions of the ustart value, such as “ustart”, “ustart2”, and “ustartl”.

The Snake kernel module works by intercepting the first packet sent from the client to the server in every TCP session, instead of opening a listening socket on a specific TCP port. It checks if the packet contents match the ustart value for that particular Snake implant. If there is a match, Snake forwards all future packets from the same session to its own processing functionality, while leaving the application listening on that port (which is presumably legitimate) unaware of this TCP session. This allows for seamless operation without the application being aware of the TCP session. If the values do not match, the Snake kernel module allows the packet — and the rest of the TCP session — to reach the legitimate application, such as web server software.

Figure 4: Snake Network Session Distinction (Source: CISA)

“Snake” Host-Based Technical Details

Every version of the ustart authenticates by sending a random number (known as a nonce) along with those results from a mathematical operation on the combination of the nonce and the ustart value itself. The receiving machine extracts the nonce and performs the same calculations to authenticate the sending machine. The ustart2 and ustartl versions use the Fowler-Noll-Vo (FNV) hash algorithm to generate the overall authentication value from the nonce and the ustart. This process varies slightly between the custom Snake HTTP protocol and the custom Snake TCP protocol.

Utilizing the ustart methodology, a node within the Snake peer-to-peer network can operate as a server without needing to open any additional ports or interfere with the legitimate functionality of the compromised server. Snake exclusively communicates over TCP ports being utilized by other applications, making detection of Snake compromises through network traffic monitoring significantly more difficult. Inbound traffic to an unexpected TCP port can be detected or blocked using standard firewall or network intrusion detection measures.

Replacing a legitimate service application with a modified executable is detectable to security measures at either the host or the network level. However, Snake’s technique bypasses both these measures effectively. Additionally, Snake’s traffic appears similar to regular traffic, particularly in terms of its HTTP-based protocols. This makes detecting Snake communications without an in-depth understanding of Snake’s custom protocols challenging.

Steps to Prevent Snake Ransomware Attacks

To safeguard against Snake ransomware attacks, here are two things you can do:

Close all RDP ports: In cases where remote operations necessitate their openness, ensure that they are password-secured. It is often observed that industrial applications have lower security standards than office systems. If your automated manufacturing system depends on RDP access that is unprotected or secured by mediocre passwords, you must prompt your system provider to address this vulnerability promptly or consider an alternative software option.

Backup Management: Make sure that you use backup management software that scans all files for malware infection before they are uploaded. It’s important to back up your manufacturing command files regularly to help ensure tight account control and activity tracking.

Partnership

The advisory was developed as a joint effort by an international partnership of multiple agencies in furtherance of the respective cybersecurity missions of each of the partner agencies. This partnership includes the following organizations: