Technical details are obtained from JCA reporting, including images and illustrations. This article focuses on encryption and the DNS channel aspect of Snake while going through some general aspects

The Snake implant, a piece of art from the digital underworld, is arguably the most sophisticated cyber espionage tool that we've seen so far. Who are the masterminds behind this nefarious creation, you ask? None other than Center 16 of Russia's Federal Security Service (FSB).

This tool isn't for some run-of-the-mill, one-off hacking shenanigans, but it's designed for long-term intelligence collection on super-sensitive targets. It's like having a permanent, invisible spy in your computer. Spooky, right?

Now, here's where it gets even trickier. The FSB, they've got this covert peer-to-peer (P2P) network of numerous Snake-infected computers worldwide, like a virtual army of cyber zombies. Several of these zombies serve as relay nodes, routing disguised operational traffic to and from Snake implants on the FSB's ultimate targets.

Snake’s custom communications protocols are no less fascinating, employing encryption and fragmentation to ensure the utmost confidentiality. Not only that, but they're also designed to throw off detection and collection efforts. Crafty, isn't it?

To give you an idea of the scale we're talking about, Snake infrastructure was identified in over 50 countries across all continents. It's everywhere! While Snake's spread seems indiscriminate, its targeting is anything but. The FSB has used Snake to collect sensitive intelligence from top-tier targets, including government networks, research facilities, and even journalists.

Take a moment to digest this – there is evidence of FSB actors using Snake to sneak into a North Atlantic Treaty Organization (NATO) country, accessing and swiping sensitive international relations documents and other diplomatic communications.

In the good ol' USA, the FSB has been busy meddling with industries including education, small businesses, and media organizations, not to mention critical infrastructure sectors such as government facilities, financial services, critical manufacturing, and communications. A virtual feast of sensitive information, isn't it?

Alright, time to pull up the cybersecurity advisory (CSA) map! This CSA gives you the details on Snake’s attribution to the FSB and all the nitty-gritty technical details of the implant’s host architecture and network communications. It also talks about a recent Snake variant that hasn't made headlines yet.

This article isn't meant to cover all of the technical details (as there is A LOT!), but to highlight some interesting part to me and hopefully helps you in your own blue team efforts.

Technical Details of Snake

"Human always make human errors"

In almost all instances that I have worked on, the bad guys (tm) have always been busted because of an intentional or unintentional mistake they make.

So, what kind of mistake did FSB make in Snake? Let's look at the hardest part to implement correctly in code that affects everyone. It's cryptography!

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 insufficient for asymmetric key systems. The deployment of Snake may have been rushed, indicated by the lack of binary stripping of Snake. Makes it easy to identify function names, cleartext strings and developer commits (gasp!)

On-Disk Operations

Snake uses its kernel modules extensively throughout its operations. In the Windows version of Snake, there is a concealed storage mechanism. This mechanism is used to hide all of the host components. The kernel module ensures that Its components are removed from any listing provided by the operating system, as well as mediating request between the user mode components and the concealed storage, which is encryped with a unique per-implant key. Since the key is unique, it makes it more difficult for tools independent of the operating system to use simple signature from identifying Snake host components. Think of it as an embedded miniature whole disk encryption, those similar to TrueCrypt.

Registry key - also encrypted!

Snake uses the services WerFault.exe to run its operations. This service will try to decrypt th registry key found at HKLM:\SOFTWARE\Classes.wav\OpenWithProgIds . The encrypted data contains the AES key, IV (initialization vector) and part used to find and decrypt the file containing Snake's kernel driver and kernel driver loader.

Snake makes use of CAST-128 encryption algorithm throughout it's operations. Not the latest or the greatest, it will do and sufficiently secure. RSA keys are used for inbound/outbound communications encryption, while CAST-128 is used to protect the Queue/Container file.

Snake uses DNS Query

The usage of DNS as covert or exfil channel isn't new. Its been used for a long time as a means to evade detection as DNS are often not-logged and volumous.

MITRE identifies this as T1071.004 - DNS protocol layer based attacks, primarily used for C23. https://attack.mitre.org/techniques/T1071/004/

Snake uses standard DNS query via Windows/POSIX function gethostbyname. Actual information being transmitted by the implant contained in the part of the character string prior to first "." character. Using base32 character encoding, Snake embeds the "-" character at specific locations and sends the DNS request using gethostbyname function. The outcome shows that DNS request looks legitimate because any character after "-" is not part of the implant communications.

Receiving DNS replies are another trick. Usually a DNS response will have IP addresses in it's body, which is essentially 32 bit unsigned integers. Snake DNS protocol sorts the 32 bit integer by the highest order nibble and interprets the remaining 28 bits of each integer as actual encoded data.

To me, this looks like a highly effective covert low bandwidth channel. For higher bandwidth, Snake uses custom HTTP/TCP protocol channels. Snake has multiple channel communications at its disposal.

More encryption?

Snake uses encryption thoroughly in it's implementation. The channel commands are encrypted using CAST-128, with different keys for incoming and outgoing bits.

The containers hold two RSA-4096 public keys. For each side of exchange, a CAST key is created. CAST-128 is then used to encrypt the data.

For an incoming command, the CAST key is signed (not encrypted) by the private key corresponding to the public key on the node to create a 512-byte RSA data blob. The incoming payload has the RSA blob, followed by the optional parameter data, which is CAST-128 encrypted. Snake uses the 0x227 RSA public key to decrypt the RSA blob, recover the CAST key, then decrypt the parameter data.

For an outgoing command, a new CAST key is obtained from CryptGenRandom, and any response data is CAST-128 encrypted. The key is then encrypted using the 0x228 public key to create a 512- byte data blob. The response payload data contains the 512-byte RSA blob, followed by the encrypted response data, when present.

The mix between CAST-128 and RSA is obvious in this implementation of Snake.

It's also evident that FSB stays clear from mainstream encoding methodology. Base64 is extensively used by most, while FSB opts to use obscure or lesser known methods as means of evading detection.

Detection

The earlier explanation focuses on the DNS channel for Snake. The obvious method monitoring would be to log DNS records and identify anomalies of communications that is logged by the DNS Server.

All DNS communication should go through a central DNS Server and not directly out to the Internet. Only the DNS Server can communicate to other DNS Servers in the Internet. This prevents DNS leakage or bypass.

Long tail analysis also helps identifying outliers and for those "out-of-the-blue" traffic that happens.

References

[1] Application Layer Protocol: DNS, Sub-technique T1071.004 - Enterprise | MITRE ATT&CK®. (2023). Retrieved 10 May 2023, from https://attack.mitre.org/techniques/T1071/004/

[2] FBI takes down Russia's sophisticated 20-year-old malware network known as "Snake". (2023). Retrieved 10 May 2023, from https://www.cbsnews.com/news/fbi-takes-down-20-year-old-russian-malware-network/

[3] https://www.reuters.com/world/fbi-says-it-has-sabotaged-hacking-tool-created-by-elite-russian-spies-2023-05-09/

[4] Recognize Strategic Opportunities with Long-Tail Data. (2023). Retrieved 10 May 2023, from https://www.nngroup.com/articles/long-tail/