{
	"id": "959008b9-bec1-4747-8fe9-6cf602aa3f62",
	"created_at": "2026-04-06T00:21:16.323984Z",
	"updated_at": "2026-04-10T03:33:35.593573Z",
	"deleted_at": null,
	"sha1_hash": "6c3116aa5f0d0e4944b09d3ca1cd7a0b7077cfd2",
	"title": "Hunting Russian Intelligence “Snake” Malware | CISA",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2878434,
	"plain_text": "Hunting Russian Intelligence “Snake” Malware | CISA\r\nPublished: 2023-05-09 · Archived: 2026-04-05 21:42:19 UTC\r\nSUMMARY\r\nThe Snake implant is considered the most sophisticated cyber espionage tool designed and used by Center 16 of\r\nRussia’s Federal Security Service (FSB) for long-term intelligence collection on sensitive targets. To conduct\r\noperations using this tool, the FSB created a covert peer-to-peer (P2P) network of numerous Snake-infected\r\ncomputers worldwide. Many systems in this P2P network serve as relay nodes which route disguised operational\r\ntraffic to and from Snake implants on the FSB’s ultimate targets. Snake’s custom communications protocols\r\nemploy encryption and fragmentation for confidentiality and are designed to hamper detection and collection\r\nefforts.\r\nWe have identified Snake infrastructure in over 50 countries across North America, South America, Europe,\r\nAfrica, Asia, and Australia, to include the United States and Russia itself. Although Snake uses infrastructure\r\nacross all industries, its targeting is purposeful and tactical in nature. Globally, the FSB has used Snake to collect\r\nsensitive intelligence from high-priority targets, such as government networks, research facilities, and journalists.\r\nAs one example, FSB actors used Snake to access and exfiltrate sensitive international relations documents, as\r\nwell as other diplomatic communications, from a victim in a North Atlantic Treaty Organization (NATO) country.\r\nWithin the United States, the FSB has victimized industries including education, small businesses, and media\r\norganizations, as well as critical infrastructure sectors including government facilities, financial services, critical\r\nmanufacturing, and communications.\r\nThis Cybersecurity Advisory (CSA) provides background on Snake’s attribution to the FSB and detailed technical\r\ndescriptions of the implant’s host architecture and network communications. This CSA also addresses a recent\r\nSnake variant that has not yet been widely disclosed. The technical information and mitigation recommendations\r\nin this CSA are provided to assist network defenders in detecting Snake and associated activity. For more\r\ninformation on FSB and Russian state-sponsored cyber activity, please see the joint advisory Russian State-Sponsored and Criminal Cyber Threats to Critical Infrastructure and CISA’s Russia Cyber Threat Overview and\r\nAdvisories webpage.\r\nDownload the PDF version of this report:\r\nINTRODUCTION\r\nWhat is Snake?\r\nWe consider Snake to be the most sophisticated cyber espionage tool in the FSB’s arsenal. The sophistication of\r\nSnake stems from three principal areas. First, Snake employs means to achieve a rare level of stealth in its host\r\ncomponents and network communications. Second, Snake’s internal technical architecture allows for easy\r\nincorporation of new or replacement components. This design also facilitates the development and interoperability\r\nof Snake instances running on different host operating systems. We have observed interoperable Snake implants\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 1 of 43\n\nfor Windows, MacOS, and Linux operating systems. Lastly, Snake demonstrates careful software engineering\r\ndesign and implementation, with the implant containing surprisingly few bugs given its complexity.\r\nFollowing open source reporting by cybersecurity and threat intelligence companies on Snake tactics, techniques,\r\nand procedures (TTPs), the FSB implemented new techniques to evade detection. The modifications to the\r\nimplant enhanced challenges in identifying and collecting Snake and related artifacts, directly hampering detection\r\nfrom both host- and network-based defensive tools.\r\nThe effectiveness of this type of cyber espionage implant depends entirely on its long-term stealth, since the\r\nobjective of an extended espionage operation involves remaining on the target for months or years to provide\r\nconsistent access to important intelligence. The uniquely sophisticated aspects of Snake represent significant effort\r\nby the FSB over many years to enable this type of covert access.\r\nBackground\r\nThe FSB began developing Snake as “Uroburos” in late 2003. Development of the initial versions of the implant\r\nappeared to be completed around early 2004, with cyber operations first conducted using the implant shortly\r\nthereafter. The name Uroburos is appropriate, as the FSB cycled it through nearly constant stages of upgrade and\r\nredevelopment, even after public disclosures, instead of abandoning it. The name appears throughout early\r\nversions of the code, and the FSB developers also left other unique strings, including “Ur0bUr()sGoTyOu#”,\r\nwhich have publicly come back to haunt them.\r\nUnique features in early versions of Uroburos included a low resolution image of a portion of a historical\r\nillustration of an uroboros by the German philosopher and theologian Jakob Böhme. One approach to a tertiary\r\nbackdoor used this image as the key. The same image had also been embedded in other Snake-related components.\r\nThe image, blown up to a higher resolution, is shown below.\r\nIn addition, early FSB developers of the Snake implant left portions of unique code throughout the implant which\r\nreveal inside jokes, personal interests, and taunts directed at security researchers. For instance, the\r\n“Ur0bUr()sGoTyOu#” string referenced above was replaced with “gLASs D1cK” in 2014 following some of the\r\npublic cybersecurity reporting.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 2 of 43\n\nAttribution\r\nWe attribute Snake operations to a known unit within Center 16 of the FSB.  This unit more broadly operates the\r\nnumerous elements of the Turla  toolset, and has subunits spread throughout Russia in a reflection of historical\r\nKGB signals intelligence operations in the Soviet Union. Snake has been a core component of this unit’s\r\noperations for almost as long as Center 16 has been part of the FSB.  The extensive influence of Snake across the\r\nTurla toolset demonstrates its impact on practically every aspect of the unit’s modern era of cyber operations.\r\nDaily operations using Snake have been carried out from an FSB facility in Ryazan, Russia, with an increase in\r\nSnake activity during FSB working hours in Ryazan, approximately 7:00 AM to 8:00 PM, Moscow Standard Time\r\n(GMT+3). The main developers were Ryazan-based FSB officers known by monikers included in the code of\r\nsome versions of Snake. In addition to developing Snake, Ryazan-based FSB officers used it to conduct\r\nworldwide operations; these operations were different from others launched from Moscow or other FSB sites\r\nbased on infrastructure and techniques.\r\nWhile the development and re-tooling of Snake has historically been done by Ryazan-based FSB officers, Snake\r\noperations were also launched from an FSB Center 16-occupied building in Moscow. Our investigations have\r\nidentified examples of FSB operators using Snake to its full potential, as well as FSB operators who appeared to\r\nbe unfamiliar with Snake’s more advanced capabilities. These observations serve to illustrate the difficulty in\r\nusing such an advanced toolset across the various geographically dispersed teams comprising this unit within FSB\r\nCenter 16.\r\nWe have been collectively investigating Snake and Snake-related tools for almost 20 years, as well as other\r\noperations by this unit since the 1990s. During that time, the FSB has used Snake in many different operations,\r\nand they have demonstrated the value placed in this tool by making numerous adjustments and revisions to keep it\r\nviable after repeated public disclosures and other mitigations. Snake’s code and multiple Snake-related tools have\r\nbeen either a starting point or a key influence factor for a diverse range of other highly prolific implants and\r\noperational tools in the Turla family. Most notably, this has included Carbon (aka Cobra)—derived from Snake’s\r\ncode base—and the similarly Snake-adjacent implant Chinch (currently known in open sources as ComRAT).\r\nVictimization\r\nWe have identified Snake infrastructure in over 50 countries across North America, South America, Europe,\r\nAfrica, Asia, and Australia, to include the United States and Russia itself. Although Snake leverages infrastructure\r\nacross all industries, its targeting is purposeful and tactical in nature. For instance, if an infected system did not\r\nrespond to Snake communications, the FSB actors would strategically re-infect it within days. Globally, the FSB\r\nhas used Snake to collect sensitive intelligence from high priority targets, such as government networks, research\r\nfacilities, and journalists. As one example, FSB actors used Snake to access and exfiltrate sensitive international\r\nrelations documents, as well as other diplomatic communications, from a victim in a NATO country. Within the\r\nUnited States, the FSB has victimized industries including education, small businesses, and media organizations,\r\nas well as critical infrastructure sectors including government facilities, financial services, critical manufacturing,\r\nand communications.\r\nOther Tools and TTPs Employed with Snake\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 3 of 43\n\nThe FSB typically deploys Snake to external-facing infrastructure nodes on a network, and from there uses other\r\ntools and TTPs on the internal network to conduct additional exploitation operations. Upon gaining and cementing\r\ningress into a target network, the FSB typically enumerates the network and works to obtain administrator\r\ncredentials and access domain controllers. A wide array of mechanisms has been employed to gather user and\r\nadministrator credentials in order to expand laterally across the network, to include keyloggers, network sniffers,\r\nand open source tools. \r\nTypically, after FSB operators map out a network and obtain administrator credentials for various domains in the\r\nnetwork, regular collection operations begin. In most instances with Snake, further heavyweight implants are not\r\ndeployed, and they rely on credentials and lightweight remote-access tools internally within a network. FSB\r\noperators sometimes deploy a small remote reverse shell along with Snake to enable interactive operations. This\r\ntriggerable reverse shell, which the FSB has used for around 20 years, can be used as a backup access vector, or to\r\nmaintain a minimal presence in a network and avoid detection while moving laterally. \r\nSnake Architecture\r\nSnake’s architectural design reflects professional software engineering practices. Critical pathways within the\r\nimplant are made of stacks of loosely coupled components that implement well-designed interfaces. In addition to\r\nfacilitating software development and debugging, this construction allows Snake to use multiple different\r\ncomponents for the same purpose, choosing the specific component based on environmental considerations. For\r\nexample, Snake’s custom network communications protocols function as a stack. All implementations use an\r\nencryption layer and a transport layer, such as Snake’s custom HTTP or raw TCP socket protocol. Each layer of\r\nthe Snake network protocol stack solely implements a specified interface for operability with the two adjacent\r\nlayers. The encryption layer and underlying transport layer thus function independently, so any custom Snake\r\nnetwork protocol can employ an encryption overlay without any change to the encryption layer code. \r\nThis modularity allows Snake operators to choose the most logical network transport for the given environment\r\nwithout affecting Snake’s other functionality. When using a compromised HTTP server as part of the Snake P2P\r\nnetwork, the operators can ensure that all traffic to this machine follows the Snake custom HTTP protocol and\r\nthereby blends effectively with legitimate traffic. In the context of a compromised machine that legitimately\r\nallows secure shell (SSH) connections, Snake can utilize its custom raw TCP socket protocol instead of its custom\r\nHTTP protocol. All other layers of the Snake protocol stack, from the immediately adjacent transport encryption\r\nlayer to the distant command processing layer, can and do remain entirely agnostic to the transport layer as long as\r\nit implements its interface correctly. This architecture also allows the Snake developers to easily substitute a new\r\ncommunications protocol when they believe one has been compromised, without necessitating any downstream\r\nchanges in the code base. Lastly, this design facilitates the development of fully interoperable Snake implants\r\nrunning on different host operating systems.\r\nSnake’s technical sophistication extends from the software architecture into the lower-level software\r\nimplementation. Original versions of Snake were developed as early as 2003, before many of the modern\r\nprogramming languages and frameworks that facilitate this type of modular development were available. Snake is\r\nwritten entirely in C, which provides significant advantages in low-level control and efficiency, but which does\r\nnot provide direct support for objects or interfaces at the language level and provides no assistance with memory\r\nmanagement. The developers of Snake successfully implemented the implant’s complex design in C with very few\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 4 of 43\n\nbugs, including careful avoidance of the common pitfalls associated with null-terminated strings and the mixing of\r\nsigned and unsigned integers. Additionally, the developers demonstrate an understanding of computer science\r\nprinciples throughout the implant’s implementation. This includes selecting and correctly coding asymptotically\r\noptimal algorithms, designing and utilizing efficient custom encoding methodologies that closely resemble\r\ncommon encoding schemes, and handling the numerous possible errors associated with systems-level\r\nprogramming in a secure manner.\r\nCapitalizing on Mistakes\r\nAlthough the Snake implant as a whole is a highly sophisticated espionage tool, it does not escape human error. A\r\ntool like Snake requires more familiarity and expertise to use correctly, and in several instances Snake operators\r\nneglected to use it as designed. Various mistakes in its development and operation provided us with a foothold into\r\nthe inner workings of Snake and were key factors in the development of capabilities that have allowed for tracking\r\nSnake and the manipulation of its data.\r\nThe FSB used the OpenSSL library to handle its Diffie-Hellman key exchange. The Diffie-Hellman key-set\r\ncreated by Snake during the key exchange is too short to be secure. The FSB provided the function\r\nDH_generate_parameters with a prime length of only 128 bits, which is inadequate for asymmetric key systems.\r\nAlso, in some instances of what appeared to be rushed deployments of Snake, the operators neglected to strip the\r\nSnake binary. This led to the discovery of numerous function names, cleartext strings, and developer comments as\r\nseen in the following figure.\r\nSNAKE HOST-BASED TECHNICAL DETAILS\r\nThe FSB has quickly adapted Snake when its capabilities have been publicly disclosed by private industry. Snake\r\ntherefore exists in several variants, as it has evolved over almost 20 years. This CSA focuses on one of the more\r\nrecent variants of Snake that up until now has not been widely disclosed. Older variants of Snake will be\r\ndiscussed briefly where applicable, but not discussed in depth, as many details of earlier Snake variants already\r\nexist in the public domain.\r\nInstaller\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 5 of 43\n\nThe Snake installer has gone by various names throughout Snake’s existence (e.g., “jpinst.exe”). This advisory\r\nwill describe the version of the installer which regularly used the name “jpsetup.exe”. This executable is packed\r\nusing a customized obfuscation methodology. The developers appear to have added the unpacking functionality\r\nfrom an open source project for viewing JPEG files. This technique serves to obfuscate the unpacking code within\r\nan otherwise legitimate code base.  The unpacking code extracts an executable, herein referred to as the “Png\r\nExe”, and it extracts an AES encrypted blob from the Png Exe’s resources, which herein will be referred to as the\r\n“Png Resource”. \r\nThe jpsetup.exe installer requires two arguments to be passed via the command line for execution. The first\r\nargument is a wide character string hashed with SHA-256 twice, and the resulting value of these computations\r\nbecomes the AES key that decrypts the Png Resource. The AES initialization vector (IV) consists of the first 16\r\nbytes of the second argument to jpsetup.exe after prepending the argument with a wide character “1” string. Once\r\ndecrypted, the Png Resource becomes an executable that will be referred to herein as “Stage 2”. \r\nWhen unpacked, many components are extracted from Stage 2’s resources. Several of the resources are\r\nexecutables with additional resources of their own. Stage 2 creates structures from its resources, which ultimately\r\nbecome the host artifacts of Snake.\r\nOn-Disk Components\r\nAs Windows has been the most prevalent operating system targeted by Snake, this document will only discuss the\r\nWindows-based artifacts; however, Snake can be cross-compiled and is capable of running on other operating\r\nsystems.\r\nOn-Disk Obfuscation\r\nSnake’s host architecture and network communications allow an unusual level of stealth. Snake makes inventive\r\nuse of its kernel module in both of these contexts. All known Windows versions of Snake have used a concealed\r\nstorage mechanism to hide host componentry. In addition to using the kernel module to remove the relevant\r\ncomponents from any listing returned by the operating system, Snake utilizes the kernel module to mediate any\r\nrequests between Snake’s user mode components and the concealed storage mechanism, which itself is encrypted\r\nwith a unique per-implant key. This unique keying creates detection difficulties even for tools that are independent\r\nof the compromised operating system, since simple signatures targeting Snake host components would be\r\nineffective. \r\nPersistence Mechanism\r\nThe Snake version primarily discussed in this advisory registers a service to maintain persistence on a system.\r\nTypically, this service is named “WerFaultSvc,” which we assess was used to blend in with the legitimate\r\nWindows service WerSvc. On boot, this service will execute Snake’s WerFault.exe, which Snake developers chose\r\nto hide among the numerous valid Windows “WerFault.exe” files in the %windows%\\WinSxS\\ directory.\r\nExecuting WerFault.exe will start the process of decrypting Snake’s components and loading them into memory. \r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 6 of 43\n\nEncrypted Registry Key Data\r\nUpon execution, Snake’s WerFault.exe will attempt to decrypt an encrypted blob within the Windows registry that\r\nis typically found at HKLM:\\SOFTWARE\\Classes\\.wav\\OpenWithProgIds. The encrypted data includes the AES\r\nkey, IV, and path that is used to find and decrypt the file containing Snake’s kernel driver and kernel driver loader.\r\nThe registry object’s structure can be seen on the right side of the following figure. Snake uses Microsoft\r\nWindows Cryptography API: Next Generation (CNG) key store to store the AES key needed to decrypt the\r\nregistry object.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 7 of 43\n\nKernel Driver and Custom Loader\r\nSnake’s installer drops the kernel driver and a custom DLL which is used to load the driver into a single AES\r\nencrypted file on disk. Typically, this file is named “comadmin.dat” and is stored in the\r\n%windows%\\system32\\Com directory. The structure of this file can be seen on the left side of the figure above.\r\nThe key, IV, and path to comadmin.dat are stored in the encrypted registry blob. \r\nThe Queue File\r\nThe last host-based artifact to discuss is the Queue File. Typically, this file has been found within the\r\n%windows%\\Registration directory with the format of \u003cRANDOM_GUID\u003e.\u003cRANDOM_GUID\u003e.crmlog, and is\r\ndecrypted by Snake’s kernel driver. Due to the complexity and importance of the Queue File, its details are\r\ndiscussed at length in the following subsection. \r\nThe Queue\r\nThe Queue is a Snake structure that contains various pieces of information, including key material,\r\ncommunication channels, modes of operation, the principal user mode component, etc., that Snake requires for\r\nsuccessful operation. It should be noted that this is a name used by the developers and is not equivalent to a\r\n“queue” in the normal context of computer science. The Queue data is saved on disk in the Queue File, which is a\r\nflat file with a substructure that includes a 0x2c-byte file header followed by data blocks. Each data block\r\ncorresponds to exactly one Queue Item, which could be, for example, a simple configuration parameter, a Snake\r\ncommand, or an entire embedded executable. Each Queue Item is associated with a specific Queue Container.\r\nQueue Containers and Items\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 8 of 43\n\nEach Container is identified by its Type and Instance values. Each Container Type holds the same type of\r\ninformation used by the Snake implant for a specific purpose. The following table shows the various Container\r\nTypes and their functions. A Queue can have multiple Containers of the same Type, but each of these Containers\r\nwill have different Instance values.\r\nThe data in each Container in the Queue is separated into Queue Items with the 0x40-byte metadata structure\r\nshown in the following table. The data content of the Queue Item immediately follows this structure. The Queue\r\nItems in each Container are distinguished by their corresponding Item Number as well as their Item Type\r\nidentifier. The Item Number is assigned by the Snake implant itself, while Snake operators generally refer to the\r\nItem Type value when trying to reference a specific item.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 9 of 43\n\nQueue File Encryption\r\nIn previous versions of Snake, the Queue File existed within an encrypted covert store. The data belonging to the\r\nQueue Items themselves were also CAST-128 encrypted. In more recent versions, the covert store was removed,\r\nand the Queue File exists by itself on disk. The Queue Items inside the Queue File are still encrypted with CAST-128, and in addition, the full Queue File is also CAST-128 encrypted. The CAST keys used to encrypt the Queue\r\nItems within a Container Instance can be found in that Instance's corresponding 0x2 Container as Item Type 0x229\r\n(see below). The key and IV used to encrypt the Queue File can be found by decoding strings within Snake’s\r\nkernel driver.\r\nContainer Descriptions\r\n0xb Container\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 10 of 43\n\nThe 0xb Container lists the available modes of operation for a given Snake implant. When using a certain mode,\r\nSnake uses a specific set of Containers and communication channels. Each infection can use up to four different\r\nmodes. Each mode in the 0xb Container will have a Container Instance value that all Containers associated with\r\nthis mode will use, except for the 0x3 Container. \r\n0x0 Container\r\nThe 0x0 Container handles incoming commands/data for the host of the Snake infection. Commands will be\r\nqueued in this Container until the implant is ready to execute them.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 11 of 43\n\n0x1 Container\r\nThe 0x1 Container handles outbound commands/data for the host of the Snake infection. The data will be queued\r\nwithin the 0x1 Container until the implant is ready to exfiltrate them.\r\n0x2 Container\r\nThe 0x2 Container holds the configuration information for the mode to which it corresponds. Various pieces of\r\ninformation vital to Snake’s successful operation are stored within these Containers. This subsection will discuss a\r\nsubset of the parameters that can be found within the 0x2 Container.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 12 of 43\n\nPivotal key information can be found within the 0x2 Containers. This includes the inbound and outbound RSA\r\nkeys (Items 0x228 and 0x227, respectively), the CAST key (Item 0x229) used to encrypt the individual items\r\nwithin the Queue Container, pre-shared keys used for the top layer of encryption in Snake’s network\r\ncommunication protocol, and a quasi-unique value for the implant, called the “ustart” value, needed for Snake\r\nnetwork connectivity.\r\nSnake is constantly passing data between its kernel and user mode components. The methodology (generally,\r\nnamed pipes) used to make these communications is listed in Items 0x65-0x6f of the 0x2 Container. Items 0x70-\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 13 of 43\n\n0x7a list the parameters necessary to establish these communications. \r\nItems 0xc9-0xd3 contain details of up to ten other Snake infections, referred to as “communication channels”,\r\nwhich the implant can communicate with during Passive Operations. The parameters needed to establish Snake\r\nsessions with the other hosts can be found in Items 0xd4-0xde.\r\nMany additional data points, such as the process name where Snake injected itself or the modules Snake has\r\nloaded from its 0x3 Container, can be found within 0x2 Containers.\r\n0x3 Container\r\nThe 0x3 Container houses embedded files and modules for Snake. A single 0x3 Container will be accessible to all\r\nContainers in the Queue. The 0x3 Container has its own dedicated 0x2 Container that only includes a single\r\nQueue Item of Item Type 0x229 (a CAST-128 key). This key will be used to encrypt and decrypt all of the\r\nembedded files and modules within the 0x3 Container.\r\nThe Item Types assigned to the embedded files and modules within the 0x3 Container are consistent across all of\r\nthe Snake infections within Snake’s P2P network. For example, the 0x01 Item Type is the Zlib library, and\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 14 of 43\n\ntherefore any time an Item Type of 0x01 is seen within the 0x3 Container of a Snake infection, that file is always\r\nthe Zlib library. The implant’s 0x2 Container will keep track of libraries that it has loaded. If the DLL is a file on\r\ndisk, the full path to the DLL is saved in the 0x2 Container. If the library was loaded from a 0x3 Container, the\r\nloaded module will be displayed in the implant’s 0x2 Container in the format “\u0026\u003cItem Type (within 3 container)\r\nof loaded module\u003e”. \r\n0x4 Container\r\nThe 0x4 Container logs command activity. Each Queue Item within the Container is a log of a single executed or\r\nattempted command. Each mode will have its own corresponding 0x4 Container.\r\n0x5 Container\r\nThe 0x5 Container holds Snake network logs, noting any IP address that has connected to this implant. Some\r\nversions of Snake no longer make use of this Container.\r\n0x6 Container\r\nThe 0x6 Container saves commands that are set to execute at specific times. A Queue Item is created for each\r\nscheduled command.\r\n0x7 Container\r\nThe 0x7 Container logs the IP addresses of any other Snake implants that have connected to this implant during\r\nPassive Operations. The commands 0x79 (Read Agents Track) and 0x7a (Clear Agents Track) are used to interact\r\nwith this Container. Note that the command 0x7a had been deprecated in some versions of Snake and returns the\r\nerror “function unsupported” if called.\r\nSNAKE NETWORK COMMUNICATIONS\r\nSnake’s network communications are encrypted, fragmented, and sent using custom methodologies that ride over\r\ncommon network protocols, including both raw TCP and UDP sockets and higher-level protocols like HTTP,\r\nSMTP, and DNS. Snake’s protocols for HTTP and TCP are the most commonly seen, but functionality exists for\r\nUDP, ICMP, and raw IP traffic. Snake’s network communications are comprised of “sessions”, which are distinct\r\nfrom the sessions associated with the legitimate protocol it is riding on top of (e.g., TCP sessions). The Snake\r\nsession is then comprised of distinct commands. Both Snake’s custom transport encryption layer (“enc”) and\r\nSnake’s Application Layer have their own encryption mechanisms, where the enc layer operates on an individual\r\nP2P session and the Snake Application Layer provides end-to-end encryption between the controller (i.e., point of\r\norigin) and the command’s ultimate destination. The following figure details Snake’s communication protocol\r\nstack. \r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 15 of 43\n\nNetwork Obfuscation\r\nSnake’s use of its kernel module also facilitates stealthy network communications. To participate fully in Snake’s\r\nP2P network, implanted machines which are not the ultimate target must act as servers for other Snake nodes.\r\nSnake’s kernel module, along with a thoughtfully designed mechanism for distinguishing Snake traffic from\r\nlegitimate client traffic, allows the implant to function as a server in the Snake P2P network without opening any\r\nnew ports, greatly complicating detection efforts. Additionally, Snake’s custom network communication protocols\r\nare designed to blend with traffic that the compromised server normally would receive. This allows Snake\r\noperators to use legitimate servers as infrastructure, which reduces the effectiveness of simple IP address or\r\ndomain blocking without needing to open new ports or send unusual looking traffic to this infrastructure. \r\nSnake’s Network Authentication Technique (“ustart”)\r\nSnake uses its custom HTTP and raw socket TCP based protocols for large data communications.  With these\r\nprotocols and others, Snake employs a specific authentication mechanism to distinguish Snake traffic from\r\nlegitimate traffic destined for application software on the compromised server. This technique enables one of the\r\nuniquely sophisticated aspects of Snake, which is its ability to function effectively as server software without\r\nopening any further ports on the compromised system. The relevant per-implant authentication value is referred to\r\nas the “ustart” and is stored in the implant’s Queue File. There are multiple forms of the ustart value, including\r\n“ustart”, “ustart2”, and “ustartl”. \r\nRather than open a listening socket on a specified TCP port, the Snake kernel module intercepts the first client-to-server packet following the 3-way handshake in every TCP session. The kernel module then determines whether\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 16 of 43\n\nor not the contents of that packet are in fact valid for the ustart value of that target Snake implant. If so, the Snake\r\nkernel module forwards that packet and any future packets in the same TCP session to Snake’s own processing\r\nfunctionality, and the (presumably legitimate) application listening on that port remains unaware of this TCP\r\nsession. If not, the Snake kernel module allows the packet—and the rest of the TCP session as it occurs—to reach\r\nthe legitimate listening application, for example web server software. See the following for an illustration. \r\nAll of the ustart versions perform authentication by sending a random nonce along with data that comprises a\r\nmathematical operation on the combination of the nonce and the ustart value itself. The receiving machine then\r\nextracts the nonce and performs the same computations to authenticate the sending machine. The ustart2 and\r\nustartl versions use the Fowler-Noll-Vo (FNV) hash algorithm to generate the overall authentication value from\r\nthe nonce and the ustart. This mechanism is slightly different in the custom Snake HTTP protocol versus the\r\ncustom Snake TCP protocol.\r\nUsing the ustart methodology, a node in the Snake P2P network can function as a server without opening any\r\notherwise closed ports and without interfering in the compromised server’s legitimate functionality. Snake will\r\nonly communicate over TCP ports on which another application is actively listening. This technique makes\r\ndetecting Snake compromises through network traffic monitoring far more difficult. Inbound traffic to an\r\nunexpected TCP port can be detected or blocked using standard firewall or network intrusion detection\r\nfunctionality. Replacing a legitimate service application with a modified executable can lead to detection at either\r\nthe host or network level. Snake’s technique bypasses both of these mitigations. When combined with the fact that\r\nSnake traffic looks similar to expected traffic, especially in the case of Snake’s HTTP based protocols, this renders\r\ndetecting Snake communications difficult absent detailed knowledge of Snake’s custom protocols.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 17 of 43\n\nSnake UDP\r\nOutbound Communications via DNS Query\r\nSnake uses a specialized communications protocol to encode information in seemingly standard DNS queries run\r\nvia the Windows or POSIX API function gethostbyname, depending on the version. \r\nSnake outbound DNS requests consist of character strings that are constructed to resemble standard domain\r\nnames. The actual information being transmitted from the implant is contained in the part of the character string\r\nprior to the first ‘.’ character. For illustration purposes, this subsection will outline how an arbitrary string of bytes\r\nis manipulated and then encoded to form an outbound Snake DNS request carrying data provided by the implant.\r\nSnake outbound DNS requests originally take the form of byte arrays stored on the stack as the implant progresses\r\nthrough the communications function. The byte array has the following structure.\r\nOnly the low-order seven bits of the flags byte are used, and they have the following significance.\r\nAfter calculating and obfuscating the byte array values shown above, Snake encodes these byte values as de-facto\r\nbase32 text, using the ten digits 0-9 and the 26 lowercase ASCII letters a-z, with v, w, x, y, and z all corresponding\r\nto the same value, as only 32 distinct characters are needed. Snake then inserts ‘-‘ characters at specified locations\r\nand sends the DNS request using the gethostbyname function. The resulting encoded string mimics a legitimate\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 18 of 43\n\nDNS request; because characters after the first ‘.’ are not part of the implant’s communications, any arbitrary\r\nsuffix (e.g., “.com”) can be used. \r\nInbound Communications via DNS Query Response\r\nAfter sending the encoded DNS request, Snake parses the returned information. In a normal DNS request, the\r\nreturned hostent structure contains a list of IPv4 addresses as 32-bit unsigned integers if the domain resolves to\r\none or more IPv4 addresses. In the Snake DNS protocol, these 32-bit integers represent the covert channel data.\r\nThe Snake implant sorts the 32-bit integers by the highest order nibble and then interprets the remaining 28 bits of\r\neach integer as the actual encoded data. The Snake DNS protocol thus provides a well-concealed, low-bandwidth\r\ncommunications channel.  For larger bandwidth communications, Snake uses its custom HTTP and TCP protocols.\r\nSnake HTTP\r\nThe most common custom protocol that Snake uses is its “http” protocol, which rides on top of standard HTTP. It\r\ngenerally looks like normal HTTP communications, including a lot of base64-looking strings, thus blending well\r\nwith normal network traffic. There have been multiple iterations of Snake’s http protocol, though the differences\r\nare only in the encoding; once that is peeled away, the underlying Snake http protocol is the same. For the\r\npurposes of this document, Snake’s former version of HTTP will be referred to as “http” and its more recent\r\nversion as “http2”. \r\nSnake communications using http2 are contained within seemingly legitimate Application Layer HTTP\r\ncommunications. In the client-to-server direction, the implant data is contained within an HTTP header field of a\r\nGET request, unless the data is over a certain size (usually 256 bytes, but configurable). Observed field keys have\r\nincluded: Auth-Data, Cache-Auth, Cookie, and Cockie (note misspelling). This list is not exhaustive; any standard\r\nHTTP header field can be used. The communication itself is contained in the legitimate HTTP header field’s\r\nvalue, meaning the content following the ‘:’ character and any whitespace immediately thereafter. In HTTP GET\r\nrequests, the implant generally uses the default path ‘/’, but this is not required and is configurable. Larger client-to-server Snake http2 requests are contained in the body of an HTTP POST request, and server-to-client\r\ncommunications are contained in the body of the HTTP response.\r\nAll client-to-server Snake http and http2 requests begin with the ustart authentication. The specifics vary with\r\neach ustart version, but in each case the random nonce and the computed function of the nonce and ustart value\r\nare encoded in a manner which closely resembles the rest of the Snake communication. Since Snake http and http2\r\nimplant sessions can span multiple TCP sessions, the ustart authentication mechanism is included in every client-to-server communication.\r\nBase62 Encoding\r\nSnake’s http2 protocol uses a custom base62 encoding scheme that has the following differences from base64.\r\nBase62 uses 62 semantically significant characters instead of 64. The ratio of encoded-to-decoded characters in\r\nbase62 is less dense (11:8) than the ratio base64 can achieve (12:9). Also, base62 uses extraneous characters in\r\ncertain instances that have no semantic significance. \r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 19 of 43\n\nThe base62 characters of semantic significance are the 62 strict alphanumeric characters: [0-9A-Za-z]. The\r\nextraneous characters that can be present in a base62 string—but which have no semantic significance—are: ‘/’,\r\n‘;’, ‘=’, and ‘_‘ (underscore). When present, these characters are removed prior to performing the decoding\r\nprocess. A valid base62 string can have up to 11 of these extraneous characters. A regular expression for base62 is\r\nincluded in the Mitigations section of this CSA.\r\nhttp and http2 Metadata Structure\r\nAfter the base62 decoding is completed, if necessary, the remaining data begins with an 8-byte metadata structure\r\nthat provides rudimentary sessionization on top of the stateless HTTP. Snake’s http and http2 client-to-server\r\ncommunications have three de-facto parts, which are concatenated into a single HTTP header value. These parts\r\nare: 1) an announce or authentication string, 2) a custom metadata structure, and 3) payload data. The metadata\r\nstructure consists of the following:\r\nstruct http_meta {        uint32_t session_number;        uint16_t communication_number; uint8_t flags; uint8_t\r\nchecksum; };\r\nSnake uses the session_number and communication_number fields to provide its own custom sessionization on\r\ntop of the stateless Application Layer HTTP protocol. The checksum byte serves to validate the integrity of the\r\nstructure and must equal the sum of the first seven bytes modulo 256.\r\nSnake TCP\r\nSnake has the ability to communicate through POSIX-style TCP sockets. The implant’s custom TCP protocol,\r\nwhich herein will be called “tcp”, uses the reliability features of the underlying TCP protocol.  Thus, in the\r\nimplant’s custom tcp protocol, the concept of a TCP session and an implant “session” are the same, whereas in the\r\nimplant’s custom http protocols, one implant session could span multiple Transport Layer TCP sessions. Since the\r\nimplant’s overall communications protocol is based on the idea of commands and responses, Snake depends on\r\nbeing able to specify the length of any given command and response so the recipient Snake node knows when a\r\nparticular communication ends. Snake achieves this in the custom tcp protocol by prefacing each communication\r\nwith its length encoded as a 32-bit big-endian unsigned integer. \r\nImmediately following the TCP 3-way handshake, the implant completes the ustart authentication for this session.\r\nSince Snake tcp sessions are mapped one-to-one with an underlying protocol TCP session, the ustart\r\nauthentication only occurs once per session, rather than with each client-to-server communication as in Snake http\r\nand http2. The Snake tcp ustart mechanism is similar to the Snake http and http2 mechanisms, except that for\r\ncertain ustart versions, Snake tcp uses a raw binary ustart which is not encoded in printable characters.\r\nAfter the ustart authentication, the implant will begin sending length-data pairs. These pairs can be sent in the\r\nsame packet or in two (or theoretically more) separate packets, but the pattern of length-data pairs will be present\r\nin each half of the stream (i.e., each direction) for the entirety of the implant communications for the remainder of\r\nthe TCP session. Specifically, a length-data pair will consist of the length encoded as a big-endian 32-bit unsigned\r\ninteger followed by data of exactly that length. For example, consider the instance where the implant is sending\r\nthe following 4 arbitrary bytes: \r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 20 of 43\n\n89 ab cd ef\r\nThe on-wire communication from the implant would send the integer value 4 encoded as a big-endian 32-bit\r\ninteger, followed by the actual 4 bytes themselves, as shown below. This could be split across two (or theoretically\r\nmore) packets.\r\n00 00 00 04 89 ab cd ef\r\nThe custom tcp protocol (as well as all custom http protocols) have been used in conjunction with the Snake enc\r\nprotocol. Details of the Snake enc protocol are provided in the following subsection. Due to the manner in which\r\nthe Snake enc and Snake tcp protocols interact, the first six length-data pairs of each TCP half-stream (following\r\nthe single client-to-server announce or authentication packet described above) will have known lengths.\r\nSpecifically, each half-stream will begin with length-data pairs of the following lengths: 0x8, 0x4, 0x10, 0x1,\r\n0x10, 0x10. Note that these are the lengths of the raw data, so each communication will be preceded by a 4-byte\r\nbig-endian integer specifying the corresponding length. Thus, one of the half-streams could have the following\r\nTCP content:\r\n00 00 00 08 12 34 56 78 9a bc de f0 00 00 00 04 89 ab cd ef 00 00 00 10 12 34 56 78 9a bc de f0 12 34 56 78 9a\r\nbc de f0 00 00 00 01 12 00 00 00 10 12 34 56 78 9a bc de f0 12 34 56 78 9a bc de f0 00 00 00 10 12 34 56 78 9a\r\nbc de f0 12 34 56 78 9a bc de f0\r\nSnake “enc” Layer\r\nAs described above, Snake communications are all comprised of “Snake sessions”, irrespective of whichever\r\nlegitimate protocol Snake is operating on top of. Snake’s top layer of encryption, called the enc layer, utilizes a\r\nmulti-step process to establish a unique session key. The session key is formed through the combination of a\r\nDiffie-Hellman key exchange mixed with a pre-shared key (PSK) known to both parties. This PSK is stored in one\r\nof the communication channels, stored within the Queue. \r\nThe overall establishment of the session key requires 12 communication steps, six in each direction, which\r\ninvolve sharing the pseudo-random values used in the Diffie-Hellman exchange process as well as custom aspects\r\nof the Snake session key derivation method. The session key is used to encrypt the command headers and (inner)\r\nencrypted payloads.\r\nThis is the layer in which the critical error of providing a value of 128 bits instead of 128 bytes for the call to\r\nDH_generate_parameters within the OpenSSL library occurred. Due to this insufficient key length, breaking the\r\nDiffie-Hellman portion of the exchange is possible. Note that in the following figure, the variables ‘p’, ‘g’, ‘a’,\r\nand ‘b’ are used in standard descriptions of Diffie-Hellman.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 21 of 43\n\nSNAKE APPLICATION LAYER\r\nSnake’s Application Layer is used to process Snake commands. The payload data for a Snake session can contain\r\none or more command exchanges, which include both the incoming data sent to the implant as well as the\r\nresponse returned to the server. Each command is associated with a specific ordinal, and due to Snake’s modular\r\ndesign, operators are able to add new commands to extend Snake’s capabilities by remotely loading a new\r\nmodule.\r\nThe Snake implant differentiates between High and Low commands and handles them differently, based on the\r\nordinal number range. The majority of Snake commands are High commands that have an ordinal of 0x64 (100\r\ndecimal) or higher. There are far fewer Low commands, and these include the Forwarding command (with ordinal\r\n0x1), and the four Queue commands (with ordinals 0xa, 0xb, 0xc, and 0xd). While Low commands are mostly\r\nused for moving data across the network, the High commands give the operator many options for interacting with\r\nan infected system. \r\nCommand 0x15-byte Header\r\nAll commands begin with a 0x15-byte header, followed by optional command parameter data; only some\r\ncommands require parameters for successful execution. For example, the command Get, which exfiltrates a file,\r\nrequires the name of the file to exfiltrate, whereas the command Process List, which returns a process listing, does\r\nnot require any parameters. \r\nThe most important Command Header field contains the integer ordinal of the command being sent. The Item UID\r\nfield represents a unique identifier for each individual command instance, and these values increase sequentially.\r\nThe header has two fields used when a command is set to run at a specified date and time; these commands will be\r\nwritten to the 0x6 Container.\r\nSome Low commands have another header before the payload data, which will be detailed below. All other\r\ncommands have only the Command Header followed by the encrypted parameter data.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 22 of 43\n\nCommand Encryption\r\nUnderneath Snake http2 or tcp encryption at the session layer, each command exchange is further encrypted. In\r\nolder versions of Snake, the exchanges were CAST-128 encrypted using a different key for incoming and outgoing\r\ndata. These keys were saved in the 0x2 Container in the 0x227 and 0x228 Items. The incoming payload data, if\r\nparameter data was present, could be decrypted with the 0x227 CAST key. Any response data was encrypted with\r\nthe 0x228 CAST key. \r\nIn recent versions, the 0x227 and 0x228 Items hold two RSA-4096 public keys. For each side of an exchange, a\r\nnew 16-byte CAST key is created with Microsoft’s CryptoAPI CryptGenRandom function to obtain 16 random\r\nbytes. This key is used to CAST-128 encrypt the parameter or response data.\r\nFor an incoming command, the CAST key is signed (not encrypted) by the private key corresponding to the public\r\nkey on the node to create a 512-byte RSA data blob. The incoming payload has the RSA blob, followed by the\r\noptional parameter data, which is CAST-128 encrypted. Snake uses the 0x227 RSA public key to decrypt the RSA\r\nblob, recover the CAST key, then decrypt the parameter data.\r\nFor 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\r\npayload data contains the 512-byte RSA blob, followed by the encrypted response data, when present.\r\nCommand Decoding\r\nThe implant will expect data in a specific format for each command ordinal. Parameter and response data contain\r\nseveral possible underlying data types, including wide-character plaintext strings, numeric values, data tables,\r\nfiles, or a combination of multiple types. \r\nThe parameter data buffer itself will be formatted in a specific way, depending on the command ordinal. Some\r\ncommands have required parameters, as well as optional parameters. Commands with optional parameters will\r\ninclude a metadata header with the data length and data type (e.g., bool, integer, text, or data buffer) before the\r\noptional parameter’s data. Other commands will expect the parameters to be formatted with length-data pairs,\r\nconsisting of the parameter data length encoded as a four-byte big-endian integer followed by data of exactly that\r\nlength. Still other commands have a custom header or will expect no length or metadata and will simply send the\r\nparameter data alone.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 23 of 43\n\nThe response data will similarly be formatted by the implant in a specific way according to the command ordinal.\r\nThe response data typically does not have a length or metadata preceding it, with the exception of the data tables.\r\nExamples of commands that return a table are the Process List command and the List Dir command.\r\nResponse data that includes a table will start with a table description header that indicates the number of columns\r\nand rows in the table. In addition, the header will include a Column Descriptor structure to indicate the type of\r\ndata that column will contain, for example a string, uint32 or uint64, timestamp in epoch format, or the contents of\r\na whole file (included as a table entry).\r\nAfter the table description header, each field is added to the data payload buffer one at a time in a length-data pair.\r\nThe fields across the first row are added in order, then the fields across the second row are added immediately\r\nafter the first row with no metadata or separation, and so on. To parse this table, the server will account for the\r\nnumber of columns to determine where the next row starts.\r\nHigh Commands\r\nHigh commands are those with an ordinal of 0x64 (decimal 100) or higher. High commands give the operator\r\nmany options for interacting with an infected system, as well as implant components. This subsection will\r\ndescribe some examples of the many High commands that can exist in the implant.\r\nSome of the most basic High commands will gather information about the machine and return the results. For\r\nexample, the FSB operators can use the PS command (0x65) to return a list of running processes, the List Dir\r\ncommand (0x840) to list the contents of a directory, or the Syst command (0x6b) to gather basic system\r\ninformation.\r\nThere are several commands that interact with the infected machine using standard built-in OS tools. The operator\r\ncan use the Kill command (0x67) to kill a process, the Get command (0x68) to exfiltrate a file, the Put command\r\n(0x69) to write a file, the Del command (0x6a) to delete a file, or the Run command (0x66) to execute a command\r\nin a terminal shell and receive the results. For example, operators have used the Run command to run PowerShell\r\ncommands, ping other hosts, use the Windows “net use” command to map network drives, and to run executable\r\nfiles that had been previously written to the node using the Put command.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 24 of 43\n\nIn addition to commands that use the built-in OS functionality, there are several High commands that interact with\r\nSnake components. An operator can use the Read Config command (0x70) to read the 0x2 Container, which\r\ncontains configuration data, or the Set Config Item command (0x71) to set a specific Queue Item within the 0x2\r\nContainer. For example, operators have used the Set Config Item command to add or update the IP addresses or\r\ndomains and option parameters used to communicate with other Snake nodes. The Read Agents Track and Clear\r\nAgents Track commands (0x79 and 0x7a) interact with the 0x7 Container to read or delete logs which track which\r\nother Snake nodes have connected to this node. Note that the 0x7a command has been deprecated in some\r\nversions of Snake and returns the error “function unsupported” if called.\r\nSnake has the ability to add additional commands by loading new modules. New modules can be loaded using the\r\nLoad Modules command (0x72) or directly into memory using the Load Modules Mem command (0x7f). When\r\ncompiling a module, the developer will assign an ordinal to each constituent command, which will then be used\r\nby the operator to call the newly added commands. These loaded modules can be removed using the Module\r\nUnload command (0x73).\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 25 of 43\n\nQueue Commands\r\nQueue Command Header\r\nThe four Queue commands contain a 0x3d-byte Queue Header following the Command Header. In more recent\r\nversions of Snake, this header is encrypted using the same CAST key used to encrypt the payload data. In this\r\ncase, the Command Header is followed by the 512-byte RSA encrypted CAST key blob, the encrypted Queue\r\nHeader, and finally the encrypted payload data.\r\nEven though each of the four Queue commands only use a subset of the fields of the Queue Header (in different\r\nways), the full header must be present for the command to be considered valid by the implant. Two fields in the\r\nheader that all four Queue commands use are the Container Instance and Container Type fields, which indicate the\r\nspecific Container on a node the Queue command intends to interact with. In the Queue Read and Write\r\ncommands, the Item Type field is used to track the specific commands and their responses in the Containers.\r\nQueue Enumerate Command\r\nThe Queue Enumerate command, with ordinal 0xa, is used to enumerate the contents of the 0x0 or 0x1 Containers\r\nto list all incoming or outgoing commands, respectively. The enumeration returns the 0x40-byte structure\r\ndescribed above for each Queue Item, concatenated into a single return buffer.\r\nQueue Read Command\r\nThe Queue Read command, with ordinal 0xb, is used to read an Item from the specified 0x0 or 0x1 Container.\r\nSeveral relevant fields in the Queue Header determine how the data is sent and stored. For example, the header\r\ndetermines whether the data should be sent immediately back to the server or stored for later transport. The header\r\nindicates if the implant should send the Queue Item’s header (i.e., the same 0x40-byte metadata structure returned\r\nby the 0xa command), the Item’s data, or both. The header also indicates whether the Queue Item should be\r\ndeleted after being read and can also indicate that Queue Items with a lower Item Type should be deleted. This\r\nallows FSB operators to clear out all command Items previous to the one being read.\r\nQueue Write Command\r\nThe Queue Write command, with ordinal 0xc, is used to write a Queue Item to the specified 0x0 or 0x1 Container.\r\nThe Queue Header will indicate if a new Queue Item will be created, or an existing Queue Item will be modified.\r\nIf a Queue Item is set to be modified, an Item with the specified Item Type must exist in the specified Container.\r\nSeveral fields in the header must match specific attributes of the existing Queue Item. If these checks are met, the\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 26 of 43\n\nparameter data is written to the Queue Item. Fields in the Queue Header will indicate the length of data to be\r\nwritten, and the offset into the existing Queue Item where the write should begin.\r\nIf a Queue Item is set to be created, Snake will delete existing Queue Items of the specified Item Type in the\r\nContainer of interest, then create a new Item of the specified Item Type and write the parameter data to the Queue\r\nItem. A field in the Queue Header will indicate the length of data to be written.\r\nQueue Delete Command\r\nThe Queue Delete command, with ordinal 0xd, is used to delete a Queue Item from the specified 0x0 or 0x1\r\nContainer. The Flags field will determine if the single Queue Item should be deleted, or if all Queue Items with a\r\nlower Item Type should be deleted as well.\r\nForward Commands\r\nForward commands, with command ordinal 0x1, are used to tell an implant to forward a Snake command to a\r\nsecond target node, where the command will be executed. The target node sends the response data back to the first\r\nimplant, which will then package that response data as its own response back to the caller.\r\nThe command is designed to tell an implant to forward one command to another implant, but in practice, Forward\r\ncommands are often built on top of each other to create a chain of hop points that will continue to forward a\r\ncommand to an end point, where it will be executed. The response data is then sent back through the same chain\r\nof hop points until it reaches the operator.\r\nThe Forward command has a 0x199-byte Forward Header, followed by the encrypted command parameter data\r\nthat will be sent to the target node of the Forward command. The Forward Header contains the information the\r\nimplant will need to connect to the target node, including the ordinal of the Snake command that is being\r\nforwarded to the target node for execution.\r\nThe implant that receives the Forward command will construct a new Snake command of the ordinal indicated in\r\nthe Forward Header. It will connect to the target node in a new session, construct the Command Header, and send\r\nthe encrypted command parameter data on to the target node. The parameter data already will have been encrypted\r\nusing the key associated with the target node, so that the target implant will be able to decrypt the parameter data\r\nand execute the command. \r\nWhen the Forward command is constructed, the CAST key used to CAST-128 encrypt the payload data—to\r\ninclude the 0x199-byte header and the parameter data to be forwarded—is encrypted with the RSA key pair used\r\nby the first implant. The parameter data that contains the parameters for the command to be forwarded is also\r\nCAST-128 encrypted, but the key used to encrypt the parameter data is encrypted with the RSA key pair used by\r\nthe target node. The first implant knows through the header what command ordinal it is forwarding, but it is\r\nunable to decrypt the parameter data.\r\nIf the Forward Header sent to the first implant indicates that the command to be forwarded was another Forward\r\ncommand, the first target node will decrypt the parameter data and find another Forward Header. This first target\r\nnode implant will then go through the same process to connect to the next target node, constructing the new\r\ncommand with the ordinal indicated in the second Forward Header to send the remaining encrypted parameter\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 27 of 43\n\ndata to the next target node. This will repeat until the command to be forwarded is something other than another\r\nForward command.\r\nThe Command Header and pertinent parameters for each target node are encrypted specifically for that node by\r\nthe operator before the Forward command is sent into the Snake P2P network. To illustrate, the diagram below\r\nshows how the buffer might look when several Forward commands are chained together to include two hop points\r\nand an end point. The first hop point (HP1) will recover the first CAST key and CAST-128 decrypt the rest of the\r\nbuffer, which will uncover the first Forward Header. HP1 will then forward the remainder of the decrypted buffer\r\nto the next hop point (HP2), starting with the second CAST key blob. HP2 will recover the second CAST key and\r\nCAST-128 decrypt the rest of the buffer, which will uncover the second Forward Header. HP2 will then forward\r\nthe remainder of the decrypted buffer to the end point, starting with the third CAST key blob. The end point will\r\nrecover the CAST key, decrypt the command parameter data, and execute the command. \r\nWhen a target machine has executed a forwarded command, the return data is encrypted with that implant’s RSA\r\nkeys and returned directly to the previous hop point. As the data is returned up the chain in the Snake P2P\r\nnetwork, the intermediate hop points do not manipulate the encrypted data, as they do not have the RSA private\r\nkey necessary to do so. In this manner, the return data is de-facto end-to-end encrypted throughout the P2P\r\nnetwork until it arrives back at the FSB operator.\r\nSNAKE IMPLANT OPERATION\r\nSnake uses two main methods for communication and command execution, namely Passive and Active. In\r\ngeneral, Snake operators will employ Active operations to communicate with hop points within Snake’s\r\ninfrastructure; however, hop points can and do sometimes operate using Snake’s Passive method. Snake’s end\r\npoints tend to solely operate using the Passive method.\r\nActive Operations\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 28 of 43\n\nDuring Active operations, Snake commands are issued by an FSB operator or a script to a target machine,\r\ngenerally through Forward commands (described in the previous section). The response to the command is\r\nimmediately returned to the point of origin following the same path that the command took to reach its end target,\r\nas shown in the previous figure on Forward command structure.\r\nPassive Operations\r\nDuring Passive operations, Snake implants operate on their own, without the synchronous interaction of FSB\r\noperators. The nodes with which an implant communicates during Passive operations are stored within its 0x2\r\nContainer(s) as communication channels. Up to ten communication channels can be present at any time; an\r\noperator can change these channels via the Set Config Item command.\r\nPassive Intake\r\nDuring Passive operations, the implant will beacon by sending a Queue Read (0xb) command to one of its stored\r\ncommunication channels that it has chosen at random. These Queue Read commands look for a Queue Item within\r\na Container with an Instance Number equal to the implant’s UID. The matching UID indicates the Queue Items in\r\nthis Container are intended for the beaconing implant.\r\nIf such a Queue Item is found, the beaconing implant will read in the Queue Item and delete it off of the host from\r\nwhich it was read. There can be multiple Queue Items found within the specified Queue Container that was\r\nbeaconed to; each Queue Read command will read one of these items. This process is repeated until all items\r\nwithin the Container are read, which the infrastructure node will indicate by sending a specific error in response to\r\nthe Queue Read. This beaconing will continue to randomly select hosts at nondeterministic time intervals for as\r\nlong as the implant is set to perform Passive operations.\r\nPassive Data Exfiltration\r\nSimilar to how Snake intakes commands passively, it can also exfiltrate the resulting data passively. This is done\r\nusing Queue Write (0xc) commands to write to one of the stored communication channels chosen at random. Once\r\nthe data is off the end point node, operators generally retrieve it manually or using a script. The Item Type field,\r\nwhich is unique per executed Snake command, is needed to associate the exfiltrated data with the target node on\r\nwhich the command was run.\r\nIn the context of Passive Snake communications, the term Item Type is defined as a UID for a given Snake\r\ncommand and its resulting data. The Item Type serves as a unique identifier to associate the results of command\r\nexecution with the original command written by the operator. When the FSB collects the data, Snake knows\r\nexactly what infection the data came from, and therefore it can determine what key to use to successfully decrypt\r\nthe data.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 29 of 43\n\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 30 of 43\n\nTo illustrate how Passive operations are conducted between the end points, the operator, and the hop points in\r\nbetween, see the diagram above, which is explained further by the following steps:\r\n(1), (2): During Passive operations, the Node randomly chooses a host from amongst its stored\r\ncommunication channels and will beacon out to it with a Queue Read command (Hop Point 1 in this case).\r\nThe Item Type for these beacons will be one greater than the Item Type of the last command received by\r\nthe Node, indicating in this example that a command of Item Type 0x08 was the last command that was\r\nread in by the Node during Passive operations. This Node will continue to beacon with Item Type 0x09\r\nuntil it receives a command, via Passive operations, with an Item Type of 0x09 or greater. The lines are\r\ndotted for (1) and (2) as this activity will be repeated at random intervals until a successful Queue Read\r\noccurs.\r\n(3), (4): In these steps, the operator uses a Queue Write command to write a command to Hop Point that is\r\nultimately intended for the Node. The Item Type of the command being written to Hop Point 1 is assigned\r\n0x20 (for this example). Note that the path of this command, its execution, and its results making it back to\r\nthe operator can be tracked via the red text.\r\n(5), (6): The Node continues to beacon out looking for commands to read in (5). The return (6) is\r\nsuccessful, and the command written by the operator to Hop Point 1 (3) is read in by the Node, then deleted\r\nfrom Hop Point 1.\r\n(7), (8): The Node attempts another Queue Read to Hop Point 1, however now the Item Type is set to 0x21,\r\none greater than the command that was just read in by the Node at (5) and (6). This returns an error as Hop\r\nPoint 1 has nothing else for the Node to read in, indicating to the Node that everything at Hop Point 1 was\r\nread.\r\n(9), (10): At this point, the Node has executed the command it read in at (5) and (6) and is attempting to\r\nsend back the results. The Node randomly selects another host from its stored communication channels,\r\nHop Point 2 in this case, and sends out a 0xb command to make sure that the Item Type 0x20, the Item\r\nType of the command it executed, does not already exist within the Queue of Hop Point 2. If it receives an\r\nerror, there is no Item with Item Type 0x20 on Hop Point 2, and the Node can proceed to send the\r\ncommand results.\r\n(11), (12): Here the data from the executed command is written to Hop Point 2 with Item Type 0x20 into its\r\n0x1 Container with a 0xc command, the Item Type the command was initially given at creation (3).\r\n(13), (14): The Node continues its normal beaconing routine again as seen in (1) and (2), searching for Item\r\nType 0x21, one greater than the Item Type of the most recently executed command. As in (1) and (2), the\r\nlines here are dotted to denote that this process will repeat until there was a successful beacon as in (5) and\r\n(6).\r\n(15-22): These steps show how the operator retrieves the resulting data that was written to Hop Point 2.\r\nThe Queue Enumerate command (15) lists the contents of Hop Point 2’s 0x1 Container, showing the data\r\nwritten by the Node (11). This data is identifiable by its Item Type, namely 0x20. The Queue Read\r\ncommand (17) reads in the Item that was found in Hop Point 2’s Container. The Queue Read command that\r\nfollows (19) is asking if there is any data left. In this case, the entirety of the data was read with the first\r\nQueue Read (17, 18). Therefore, the error returned from second Queue Read command (20) lets the\r\noperator know all of the data from Item Type 0x20 was read and there is nothing further. A Queue Delete\r\ncommand (21) follows and is sent to delete the item with Item Type 0x20 from Hop Point 2.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 31 of 43\n\nThe subsequent Queue Read, Queue Read, and Queue Delete commands (17-21) are denoted with dashed\r\nlines to indicate that this sequence of commands is repeated for all items returned from the Queue\r\nEnumerate command (15).\r\nMITIGATIONS\r\nA number of complementary detection techniques effectively identify some of the more recent variants of Snake.\r\nHowever, as described above, Snake is purpose-built to avoid large-scale detection. Below is a discussion of the\r\nadvantages and disadvantages of various detection methodologies available for Snake.\r\nNote that some of the techniques identified in this section can affect the availability or stability of a system.\r\nDefenders should follow organizational policies and incident response best practices to minimize the risk to\r\noperations while hunting for Snake.\r\nNetwork-Based Detection\r\nNetwork Intrusion Detection Systems (NIDS) can feasibly identify some of the more recent variants of Snake and\r\nits custom network protocols as detailed above.\r\nAdvantages: High-confidence, large-scale (network-wide) detection of custom Snake communication protocols.\r\nDisadvantages: Low visibility of Snake implant operations and encrypted data in transit. There is some potential\r\nfor false positives in the Snake http, http2, and tcp signatures. Snake operators can easily change network-based signatures.\r\nSnake http\r\nSnake client-to-server http and http2 traffic is contained within an arbitrary HTTP header field. The header field\r\nvalue for http begins with 10 pure alphanumeric characters, followed by base64 encoding of 8 bytes, which yields\r\nexactly 11 valid base64 characters plus one base64 padding character.\r\n      ^[0-9A-Za-z]{10}[0-9A-Za-z/\\+]{11}=\r\nThe following two Suricata rules will detect the traffic described:\r\nalert http any any -\u003e any any (msg: \"http rule (Cookie)\";\\    pcre:\"/[0-9A-Za-z]{10}[0-9A-Za-z\\/\\+]{11}=/C\";\\  \r\n flow: established, to_server;\\    sid: 7; rev: 1;) alert http any any -\u003e any any (msg: \"http rule (Other Header)\";\\  \r\n pcre:\"/[0-9A-Za-z]{10}[0-9A-Za-z\\/\\+]{11}=/H\";\\    flow: established, to_server;\\    sid: 8; rev: 1;)\r\nSnake http2\r\nThe header field value for http2 begins with 22 pure alphanumeric characters (base62 with non-extraneous\r\ncharacters), followed by the base62 encoding of at least 8 bytes, which must comprise at least 11 base62\r\ncharacters with the four extraneous characters allowed. The actual requirement is stricter than this expression,\r\nsince the total number of non-extraneous characters alone must equal or exceed 11; however, it is not possible to\r\nencode that aspect into a regular language.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 32 of 43\n\n^[0-9A-Za-z]{22}[0-9A-Za-z/;_=]{11}\r\nThe following two Suricata rules will detect the traffic described:\r\nalert http any any -\u003e any any (msg: \"http2 rule (Cookie)\";\\    pcre:\"/[0-9A-Za-z]{22}[0-9A-Za-z\\/_=\\;]{11}/C\";\\  \r\n flow: established, to_server;\\    sid: 9; rev: 1;) alert http any any -\u003e any any (msg: \"http2 rule (Other Header)\";\\  \r\n pcre:\"/[0-9A-Za-z]{22}[0-9A-Za-z\\/_=\\;]{11}/H\";\\    flow: established, to_server;\\    sid: 10; rev: 1;)\r\nSnake tcp\r\nThe client-to-server communication for tcp must begin with the ustart, which is not captured in this signature set.\r\nImmediately following the ustart, the next client-to-server communication must be the big-endian 32-bit unsigned\r\ninteger 8 followed by any 8 bytes of data. The next communication must also be client-to-server, and it must\r\ncomprise the big-endian 32-bit unsigned integer 4 followed by any 4 bytes of data. The next two communications\r\nmust be server-to-client, comprising the integer 8 followed by 8 bytes of data and the integer 4 followed by 4\r\nbytes of data.\r\nThe following six Suricata rules will, in conjunction, detect traffic of the form described:\r\nalert tcp any any -\u003e any any (msg: \"tcp rule\";\\    content: \"|00 00 00 08|\"; startswith; dsize: 12;\\    flow: established,\r\nto_server; flowbits: set, a8; flowbits: noalert;\\    sid: 1; rev: 1;) alert tcp any any -\u003e any any (msg: \"tcp rule\";\\  \r\n content: \"|00 00 00 04|\"; startswith; dsize:8;\\    flow: established, to_server; flowbits: isset, a8; flowbits: unset,\r\na8;\\    flowbits: set, a4; flowbits: noalert;\\    sid: 2; rev: 1;) alert tcp any any -\u003e any any (msg: \"tcp rule\";\\  \r\n content: \"|00 00 00 08|\"; startswith; dsize: 4;\\    flow: established, to_client; flowbits: isset, a4; flowbits: unset,\r\na4;\\    flowbits: set, b81; flowbits: noalert;\\    sid: 3; rev: 1;) alert tcp any any -\u003e any any (msg: \"tcp rule\";\\    dsize:\r\n8; flow: established, to_client; flowbits: isset, b81;\\    flowbits: unset, b81; flowbits: set, b8; flowbits: noalert;\\  \r\n sid: 4; rev: 1;) alert tcp any any -\u003e any any (msg: \"tcp rule\";\\    content: \"|00 00 00 04|\"; startswith; dsize: 4;\\  \r\n flow: established, to_client; flowbits: isset, b8; flowbits: unset, b8;\\    flowbits: set, b41; flowbits: noalert;\\    sid:\r\n5; rev: 1;) alert tcp any any -\u003e any any (msg: \"tcp rule\";\\    dsize: 4; flow: established, to_client; flowbits: isset,\r\nb41;\\    flowbits: unset, b41;\\    sid: 6; rev: 1;)\r\nHost-Based Detection\r\nAdvantages: High confidence based on totality of positive hits for host-based artifacts.\r\nDisadvantages: Many of the artifacts on the host are easily shifted to exist in a different location or with a\r\ndifferent name. As the files are fully encrypted, accurately identifying these files is difficult.\r\nCovert Store Detection\r\nThe Snake covert store comprises a file-backed NTFS (usually) or FAT-16 (rarely) filesystem. The filesystem is\r\nencrypted with CAST-128 in CBC mode. The encryption key can be either statically hardcoded or dynamically\r\nstored in a specified Windows registry location. The IV is 8 bytes, since CAST-128 has an 8-byte block length.\r\nThe first byte of the IV for any 512-byte block of the covert store is the 0-indexed block number. The remaining\r\nbytes of the IV are the corresponding bytes of the key, meaning that bytes at 0-indexed indices 1 through 7 of the\r\nIV are the bytes at 0-indexed indices 1 through 7 of the key.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 33 of 43\n\nWhen statically hardcoded, the encryption key has the following constant value: \r\n     A1 D2 10 B7 60 5E DA 0F A1\r\n65 AF EF 79 C3 66 FA\r\nWhen stored in the Windows registry, the encryption key is the classname associated with the following key:\r\n      SECURITY\\Policy\\Secrets\\n\r\nThe following initial 8-byte sequences are known to be used by NTFS or FAT-16 filesystems as observed:\r\n      EB 52 90 4E 54 46 53 20      EB 5B 90 4E 54 46 53 20      EB 3C 90 4D 53 44 4F 53      EB 00 00 00 00 00 00\r\n00\r\nFor tool development, the following test vector illustrates the encryption of the first given header above (EB 52 90\r\n…) using CAST-128 with the default key shown above and the IV constructed as described, given this header\r\noccurs at the beginning of the first 512-byte block of the covert store.\r\n      Plaintext:      EB 52 90 4E 54 46 53 20\r\n      Key:              A1 D2 10 B7 60 5E DA 0F A1 65 AF EF 79 C3 66 FA\r\n      IV:                 00 D2 10 B7 60 5E DA 0F\r\n      Ciphertext:   C2 C7 F4 CA F7 DA 3A C8\r\nBy encrypting each possible initial filesystem byte sequence with CAST-128 using the key obtained from the\r\nregistry—or the default encryption key if the registry entry does not exist—and searching for any file with a size\r\nthat is an even multiple of 220, it is possible to efficiently detect Snake covert stores. Validation can be performed\r\nby decrypting the entire file using the outlined methodology and then verifying that it comprises an NTFS or FAT-16 filesystem.\r\nOther On-Disk Artifact Detection\r\nRegistry Blob\r\nThe registry blob is generally found at the location listed below. In case it is not present at its typical location, the\r\nregistry blob can be found by searching the full registry for a value of at least 0x1000 bytes in size and entropy of\r\nat least 7.9.\r\n      Typical Name: Unknown (RegBlob)\r\n      Typical Path: HKLM\\SOFTWARE\\Classes\\.wav\\OpenWithProgIds\r\n      Characteristics: High Entropy\r\nQueue File\r\n      Typical Name: \u003c RANDOM_GUID \u003e.\u003cRANDOM_GUID\u003e.crmlog\r\n      Typical Path: %windows\\registration\\\r\n      Unique Characteristics: High Entropy, file attributes of hidden, system, and archive\r\n      Role: Snake Queue File\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 34 of 43\n\nThe Snake Queue File generally has a predictable path and filename structure, in addition to being high entropy.\r\nThe Snake Queue File can be located by scanning all files in the typical queue path with filenames matching a\r\nregular expression that captures the typical naming convention. Files meeting these criteria should be scanned for\r\nhigh entropy, which is performed by the Yara rule below:\r\nrule HighEntropy {    meta:        description = \"entropy rule\"    condition:        math.entropy(0, filesize) \u003e= 7.0 }\r\nThe following UNIX find command will scan files with names matching the GUID-based convention (note that\r\nthe HighEntropy yara rule is assumed to be contained in a file named “1.yar”):\r\nfind /PATH/TO/WINDOWS_DIR -type f -regextype posix-egrep -iregex \\    '.*\\/registration/(\\{[0-9A-F]{8}\\-([0-\r\n9A-F]{4}\\-){3}[0-9A-F]{12}\\}\\.){2}crmlog' \\     -exec yara 1.yar {} \\;\r\nThe following PowerShell command does the same:\r\nGet-ChildItem -Recurse -File -Path %WINDOWS% | Where-Object {  $_.FullName -match  '(?i)/registration/(\\\r\n{[0-9A-F]{8}\\-([0-9A-F]{4}\\-){3}[0-9A-F]{12}\\}\\.){2}crmlog$' } | ForEach-Object {  yara 1.yar $_.FullName }\r\nComadmin\r\n      Typical Name: comadmin.dat\r\n      Typical Path: %windows%\\system32\\Com\r\n      Unique Characteristics: High Entropy\r\n      Role: Houses Snake’s kernel driver and the driver’s loader\r\nThe Snake Comadmin file can be found using analogous techniques to that presented above for locating the Snake\r\nQueue File. The following UNIX find command will do so:\r\nfind /PATH/TO/WINDOWS -type f -regextype posix-egrep -iregex \\    '.*\\/system32/Com/comadmin\\.dat' \\     -\r\nexec yara 1.yar {} \\;\r\nThe following PowerShell command does the same:\r\nGet-ChildItem -Recurse -File -Path %WINDOWS% | Where-Object {    $_.FullName -match '(?\r\ni)/system32/Com/comadmin\\.dat$' } | ForEach-Object {    yara 1.yar $_.FullName }\r\nWerfault\r\nTypical Name: Werfault.exe\r\nTypical Path: %windows%\\WinSxS\\x86_microsoft-windows-errorreportingfaults_31bf3856ad364e35_4.0.9600.16384_none_a13f7e283339a0502\\\r\nUnique Characteristics: Icon is different than that of a valid Windows Werfault.exe file\r\nRole: Persistence mechanism\r\nThe Snake Werfault.exe file has non-standard icon sizes, which form the basis of the Yara rule below. This rule\r\nshould be run on all files in the typical path, specifically the %Windows%\\WinSxS directory.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 35 of 43\n\nrule PeIconSizes {    meta:        description = \"werfault rule\"    condition:        pe.is_pe        and        for any rsrc in\r\npe.resources:            (rsrc.type == pe.RESOURCE_TYPE_ICON and rsrc.length == 3240)        and        for any\r\nrsrc in pe.resources:            (rsrc.type == pe.RESOURCE_TYPE_ICON and rsrc.length == 1384)        and        for\r\nany rsrc in pe.resources:            (rsrc.type == pe.RESOURCE_TYPE_ICON and rsrc.length == 7336) }\r\nMemory Analysis\r\nAdvantages: High confidence as memory provides the greatest level of visibility into Snake’s behaviors and\r\nartifacts.\r\nDisadvantages: Potential impact on system stability, difficult scalability.\r\nCapturing and analyzing the memory of a system will be the most effective approach in detecting Snake because it\r\nbypasses many of the behaviors that Snake employs to hide itself. With a memory analysis tool, such as Volatility,\r\ndetection of a Snake compromise may be possible.\r\nSnake’s principal user mode component is injected into a chosen process via a single allocation of\r\nPAGE_EXECUTE_READWRITE memory. The starting offset is generally 0x20000000, however the module\r\ndoes allow for relocation if needed. Additionally, since the user mode component is not obfuscated in any way, a\r\nvalid PE header can be located at the beginning of the allocated memory region. Further validation can be\r\nperformed by confirming the presence of strings known to exist in the user mode component also within the\r\nmemory region. A plugin compatible with Volatility3 which can scan all processes on a system using this method\r\nis provided in the Appendix. A screenshot showing the results of the plugin successfully detecting Snake is\r\ndisplayed below.\r\nPREVENTION\r\nNote that the mitigations that follow are not meant to protect against the initial access vector and are only\r\ndesigned to prevent Snake’s persistence and hiding techniques.\r\nChange Credentials and Apply Updates\r\nSystem owners who are believed to be compromised by Snake are advised to change their credentials immediately\r\n(from a non-compromised system) and to not use any type of passwords similar to those used before. Snake\r\nemploys a keylogger functionality that routinely returns logs back to FSB operators. Changing passwords and\r\nusernames to values which cannot be brute forced or guessed based on old passwords is recommended.\r\nSystem owners are advised to apply updates to their Operating Systems. Modern versions of Windows, Linux, and\r\nMacOS make it much harder for adversaries to operate in the kernel space. This will make it much harder for FSB\r\nactors to load Snake’s kernel driver on the target system.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 36 of 43\n\nExecute Organizational Incident Response Plan\r\nIf system owners receive detection signatures of Snake implant activity or have other indicators of compromise\r\nthat are associated with FSB actors using Snake, the impacted organization should immediately initiate their\r\ndocumented incident response plan.\r\nWe recommend implementing the following Cross-Sector Cybersecurity Performance Goals (CPGs) to help\r\ndefend against FSB actors using Snake, or mitigate negative impacts post-compromise:\r\nCPG 2.A: Changing Default Passwords will prevent FSB actors from compromising default credentials to gain\r\ninitial access or move laterally within a network.\r\nCPG 2.B: Requiring Minimum Password Strength across an organization will prevent FSB actors from being able\r\nto successfully conduct password spraying or cracking operations. \r\nCPG 2.C: Requiring Unique Credentials will prevent FSB actors from compromising valid accounts through\r\npassword spraying or brute force. \r\nCPG 2.E Separating User and Privileged Accounts will make it harder for FSB actors to gain access to\r\nadministrator credentials.\r\nCPG 2.F. Network Segmentation to deny all connections by default unless explicitly required for specific system\r\nfunctionality, and ensure all incoming communication is going through a properly configured firewall.\r\nCPG 2.H Implementing Phishing Resistant MFA adds an additional layer of security even when account\r\ncredentials are compromised and can mitigate a variety of attacks towards valid accounts, to include brute forcing\r\npasswords and exploiting external remote services software.\r\nCPG 4.C. Deploy Security.txt Files to ensure all public facing web domains have a security.txt file that conforms\r\nto the recommendations in RFC 9118.\r\nAPPENDIX\r\nPartnership\r\nThis advisory was developed as a joint effort by an international partnership of multiple agencies in furtherance of\r\nthe respective cybersecurity missions of each of the partner agencies, including our responsibilities to develop and\r\nissue cybersecurity specifications and mitigations. This partnership includes the following organizations:\r\nFederal Bureau of Investigation\r\nNational Security Agency\r\nCybersecurity and Infrastructure Security Agency\r\nCyber National Mission Force\r\nThe United Kingdom’s National Cyber Security Centre\r\nCanadian Centre for Cyber Security\r\nCommunications Security Establishment\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 37 of 43\n\nAustralian Cyber Security Centre\r\nNew Zealand National Cyber Security Centre\r\nCollectively, we use a variety of sources, methods, and partnerships to acquire information about foreign cyber\r\nthreats. This advisory contains the information we have concluded can be publicly released, consistent with the\r\nprotection of sources and methods and the public interest.\r\nDisclaimer\r\nThe information in this report is being provided “as is” for informational purposes only. We do not endorse any\r\ncommercial product or service, including any subjects of analysis. Any reference to specific commercial products,\r\nprocesses, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply\r\nendorsement, recommendation, or favoring by co-authors. \r\nMITRE ATT\u0026CK Techniques\r\nThis advisory uses the MITRE ATT\u0026CK® for Enterprise framework, version 13. See MITRE ATT\u0026CK for\r\nEnterprise for all referenced tactics and techniques. MITRE and ATT\u0026CK are registered trademarks of The\r\nMITRE Corporation. This report references the following MITRE ATT\u0026CK techniques.\r\nTechnique Title ID Use\r\nNetwork Connection\r\nEnumeration\r\nT0840\r\nAdversaries may perform network connection enumeration to\r\ndiscover information about device communication patterns.\r\nData Obfuscation T1001\r\nAdversaries may obfuscate command and control traffic to make\r\nit more difficult to detect.\r\nProtocol Impersonation\r\nT1001.003\r\nAdversaries may impersonate legitimate protocols or web service\r\ntraffic to disguise command and control activity and thwart\r\nanalysis efforts.\r\nOS Credential Dumping T1003\r\nAdversaries may attempt to dump credentials to obtain account\r\nlogin and credential material, normally in the form of a hash or a\r\nclear text password, from the operating system and software.\r\nRootkit T1014\r\nAdversaries may use rootkits to hide the presence of programs,\r\nfiles, network connections, services, drivers, and other system\r\ncomponents.\r\nObfuscated Files or\r\nInformation\r\nT1027\r\nAdversaries may attempt to make an executable or file difficult to\r\ndiscover or analyze by encrypting, encoding, or otherwise\r\nobfuscating its contents on the system or in transit.\r\nSoftware Packing\r\nT1027.002 Adversaries may perform software packing or virtual machine\r\nsoftware protection to conceal their code.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 38 of 43\n\nMasquerading T1036\r\nAdversaries may attempt to manipulate features of their artifacts\r\nto make them appear legitimate or benign to users and/or security\r\ntools.\r\nNetwork Sniffing T1040\r\nAdversaries may sniff network traffic to capture information\r\nabout an environment, including authentication material passed\r\nover the network.\r\nNetwork Service\r\nDiscovery\r\nT1046\r\nAdversaries may attempt to get a listing of services running on\r\nremote hosts and local network infrastructure devices, including\r\nthose that may be vulnerable to remote software exploitation.\r\nDynamic-link Library\r\nInjection\r\nT1055.001\r\nAdversaries may inject dynamic-link libraries (DLLs) into\r\nprocesses in order to evade process-based defenses as well as\r\npossibly elevate privileges.\r\nKeylogging\r\nT1056.001 Adversaries may log user keystrokes to intercept credentials as\r\nthe user types them.\r\nPowerShell\r\nT1059.001 Adversaries may abuse PowerShell commands and scripts for\r\nexecution.\r\nApplication Layer\r\nProtocol\r\nT1071\r\nAdversaries may communicate using OSI application layer\r\nprotocols to avoid detection/network filtering by blending in with\r\nexisting traffic.\r\nWeb Protocols\r\nT1071.001\r\nAdversaries may communicate using application layer protocols\r\nassociated with web traffic to avoid detection/network filtering by\r\nblending in with existing traffic.\r\nMail Protocols\r\nT1071.003\r\nAdversaries may communicate using application layer protocols\r\nassociated with electronic mail delivery to avoid\r\ndetection/network filtering by blending in with existing traffic.\r\nDNS\r\nT1071.004\r\nAdversaries may communicate using the Domain Name System\r\n(DNS) application layer protocol to avoid detection/network\r\nfiltering by blending in with existing traffic.\r\nData Staged T1074\r\nAdversaries may stage collected data in a central location or\r\ndirectory prior to Exfiltration.\r\nValid Accounts T1078\r\nAdversaries may obtain and abuse credentials of existing\r\naccounts as a means of gaining Initial Access, Persistence,\r\nPrivilege Escalation, or Defense Evasion.\r\nFile and Directory\r\nDiscovery\r\nT1083 Adversaries may enumerate files and directories or may search in\r\nspecific locations of a host or network share for certain\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 39 of 43\n\ninformation within a file system.\r\nMulti-hop Proxy\r\nT1090.003 To disguise the source of malicious traffic, adversaries may chain\r\ntogether multiple proxies.\r\nNon-Application Layer\r\nProtocol\r\nT1095\r\nAdversaries may use an OSI non-application layer protocol for\r\ncommunication between host and C2 server or among infected\r\nhosts within a network.\r\nMulti-Stage Channels T1104\r\nAdversaries may create multiple stages for command and control\r\nthat are employed under different conditions or for certain\r\nfunctions.\r\nNative API T1106\r\nAdversaries may interact with the native OS application\r\nprogramming interface (API) to execute behaviors.\r\nModify Registry T1112\r\nAdversaries may interact with the Windows Registry to hide\r\nconfiguration information within Registry keys, remove\r\ninformation as part of cleaning up, or as part of other techniques\r\nto aid in persistence and execution.\r\nAutomated Collection T1119\r\nOnce established within a system or network, an adversary may\r\nuse automated techniques for collecting internal data.\r\nData Encoding T1132\r\nAdversaries may encode data to make the content of command\r\nand control traffic more difficult to detect.\r\nNon-Standard Encoding\r\nT1132.002\r\nAdversaries may encode data with a non-standard data encoding\r\nsystem to make the content of command and control traffic more\r\ndifficult to detect.\r\nNetwork Share\r\nDiscovery\r\nT1135\r\nAdversaries may look for folders and drives shared on remote\r\nsystems as a means of identifying sources of information to\r\ngather as a precursor for Collection and to identify potential\r\nsystems of interest for Lateral Movement.\r\nDeobfuscate/Decode\r\nFiles or Information\r\nT1140\r\nAdversaries may use Obfuscated Files or Information to hide\r\nartifacts of an intrusion from analysis.\r\nExploit Public-Facing\r\nApplication\r\nT1190\r\nAdversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network.\r\nDomain Trust Discovery T1482\r\nAdversaries may attempt to gather information on domain trust\r\nrelationships that may be used to identify lateral movement\r\nopportunities in Windows multi-domain/forest environments.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 40 of 43\n\nInstaller Packages\r\nT1546.016 Adversaries may establish persistence and elevate privileges by\r\nusing an installer to trigger the execution of malicious content.\r\nDynamic Linker\r\nHijacking\r\nT1547.006\r\nAdversaries may execute their own malicious payloads by\r\nhijacking environment variables the dynamic linker uses to load\r\nshared libraries.\r\nInter-Process\r\nCommunication\r\nT1559\r\nAdversaries may abuse inter-process communication (IPC)\r\nmechanisms for local code or command execution.\r\nArchive Collected Data\r\nT1560.003 An adversary may compress and/or encrypt data that is collected\r\nprior to exfiltration.\r\nHide Artifacts T1564\r\nAdversaries may attempt to hide artifacts associated with their\r\nbehaviors to evade detection.\r\nService Execution\r\nT1569.002 Adversaries may abuse the Windows service control manager to\r\nexecute malicious commands or payloads.\r\nLateral Tool Transfer T1570\r\nAdversaries may transfer tools or other files between systems in a\r\ncompromised environment.\r\nProtocol Tunneling T1572\r\nAdversaries may tunnel network communications to and from a\r\nvictim system within a separate protocol to avoid\r\ndetection/network filtering and/or enable access to otherwise\r\nunreachable systems.\r\nEncrypted Channel T1573\r\nAdversaries may employ a known encryption algorithm to\r\nconceal command and control traffic rather than relying on any\r\ninherent protections provided by a communication protocol.\r\nSymmetric Cryptography\r\nT1573.001\r\nAdversaries may employ a known symmetric encryption\r\nalgorithm to conceal command and control traffic rather than\r\nrelying on any inherent protections provided by a communication\r\nprotocol.\r\nAsymmetric\r\nCryptography\r\nT1573.002\r\nAdversaries may employ a known asymmetric encryption\r\nalgorithm to conceal command and control traffic rather than\r\nrelying on any inherent protections provided by a communication\r\nprotocol.\r\nDLL Side-Loading\r\nT1574.002 Adversaries may execute their own malicious payloads by side-loading DLLs.\r\nCompromise\r\nInfrastructure\r\nT1584\r\nAdversaries may compromise third-party infrastructure that can\r\nbe used during targeting.\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 41 of 43\n\nMalware\r\nT1587.001 Adversaries may develop malware and malware components that\r\ncan be used during targeting.\r\nObtain Capabilities T1588\r\nAdversaries may buy and/or steal capabilities that can be used\r\nduring targeting.\r\nStage Capabilities T1608\r\nAdversaries may upload, install, or otherwise set up capabilities\r\nthat can be used during targeting.\r\nDeploy Container T1610\r\nAdversaries may deploy a container into an environment to\r\nfacilitate execution or evade defenses.\r\nVolatility Plugin\r\nThe following plugin for the Volatility memory analysis framework will scan all processes on the system until it\r\nfinds the Snake user mode component injected into a process. If found, the plugin will list both the injected\r\nprocess and the virtual memory address at which the Snake user mode component is loaded.\r\n# This plugin to identify the injected usermode component of Snake is based # on the malfind plugin released with\r\nVolatility3 # # This file is Copyright 2019 Volatility Foundation and licensed under the # Volatility Software\r\nLicense 1.0 # which is available at https://www.volatilityfoundation.org/license/vsl-v1.0 import logging from\r\ntyping import Iterable, Tuple from volatility3.framework import interfaces, symbols, exceptions, renderers from\r\nvolatility3.framework.configuration import requirements from volatility3.framework.objects import utility from\r\nvolatility3.framework.renderers import format_hints from volatility3.plugins.windows import pslist, vadinfo\r\nvollog = logging.getLogger(__name__) class snake(interfaces.plugins.PluginInterface):  \r\n _required_framework_version = (2, 4, 0)        @classmethod    def get_requirements(cls):        return [          \r\n requirements.ModuleRequirement(name = 'kernel',            description = 'Windows kernel',            architectures =\r\n[\"Intel32\", \"Intel64\"]),            requirements.VersionRequirement(name = 'pslist',            component = pslist.PsList,\r\nversion = (2, 0, 0)),            requirements.VersionRequirement(name = 'vadinfo',            component =\r\nvadinfo.VadInfo, version = (2, 0, 0))]    @classmethod    def list_injections(            cls, context:\r\ninterfaces.context.ContextInterface,            kernel_layer_name: str, symbol_table: str,            proc:\r\ninterfaces.objects.ObjectInterface) -\u003e Iterable[            Tuple[interfaces.objects.ObjectInterface, bytes]]:      \r\n proc_id = \"Unknown\"        try:            proc_id = proc.UniqueProcessId            proc_layer_name =\r\nproc.add_process_layer()        except exceptions.InvalidAddressException as excp:            vollog.debug(\"Process\r\n{}: invalid address {} in layer {}\".            format(proc_id, excp.invalid_address, excp.layer_name))            return  \r\n     proc_layer = context.layers[proc_layer_name]        for vad in proc.get_vad_root().traverse():          \r\n protection_string = vad.get_protection(vadinfo.VadInfo.            protect_values(context, kernel_layer_name,\r\nsymbol_table),            vadinfo.winnt_protections)            if not \"PAGE_EXECUTE_READWRITE\" in\r\nprotection_string:                continue            if (vad.get_private_memory() == 1                    and vad.get_tag() ==\r\n\"VadS\") or (vad.get_private_memory()                    == 0 and protection_string !=                  \r\n \"PAGE_EXECUTE_WRITECOPY\"):                data = proc_layer.read(vad.get_start(),                vad.get_size(),\r\npad = True)                if data.find(b'\\x4d\\x5a') != 0:                    continue                yield vad, data    def\r\n_generator(self, procs):        kernel = self.context.modules[self.config['kernel']]        is_32bit_arch = not\r\nsymbols.symbol_table_is_64bit(self.context,        kernel.symbol_table_name)        for proc in procs:          \r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 42 of 43\n\nprocess_name = utility.array_to_string(proc.ImageFileName)            for vad, data in\r\nself.list_injections(self.context,            kernel.layer_name, kernel.symbol_table_name, proc):              \r\n strings_to_find = [b'\\x25\\x73\\x23\\x31',b'\\x25\\x73\\x23\\x32',                b'\\x25\\x73\\x23\\x33',b'\\x25\\x73\\x23\\x34',    \r\n           b'\\x2e\\x74\\x6d\\x70', b'\\x2e\\x73\\x61\\x76',                b'\\x2e\\x75\\x70\\x64']                if not all(stringToFind in\r\ndata for                stringToFind in strings_to_find):                    continue                yield (0, (proc.UniqueProcessId,\r\nprocess_name,                format_hints.Hex(vad.get_start()),                           format_hints.Hex(vad.get_size()),      \r\n                    vad.get_protection(                               vadinfo.VadInfo.protect_values(self.context,              \r\n kernel.layer_name, kernel.symbol_table_name),                vadinfo.winnt_protections)))                return    def\r\nrun(self):        kernel = self.context.modules[self.config['kernel']]        return renderers.TreeGrid([(\"PID\", int),\r\n(\"Process\", str),        (\"Address\", format_hints.Hex), (\"Length\", format_hints.Hex),        (\"Protection\", str)],\r\nself._generator(pslist.PsList.list_processes(        context = self.context, layer_name = kernel.layer_name,        \r\n symbol_table = kernel.symbol_table_name)))\r\nSource: https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a\r\nPage 43 of 43\n\n  https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a     \nEach Container is identified by its Type and Instance values. Each Container Type holds the same type of\ninformation used by the Snake implant for a specific purpose. The following table shows the various Container\nTypes and their functions. A Queue can have multiple Containers of the same Type, but each of these Containers\nwill have different Instance values.     \nThe data in each Container in the Queue is separated into Queue Items with the 0x40-byte metadata structure \nshown in the following table. The data content of the Queue Item immediately follows this structure. The Queue\nItems in each Container are distinguished by their corresponding Item Number as well as their Item Type \nidentifier. The Item Number is assigned by the Snake implant itself, while Snake operators generally refer to the\nItem Type value when trying to reference a specific item.    \n   Page 9 of 43",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a"
	],
	"report_names": [
		"aa23-129a"
	],
	"threat_actors": [
		{
			"id": "8aaa5515-92dd-448d-bb20-3a253f4f8854",
			"created_at": "2024-06-19T02:03:08.147099Z",
			"updated_at": "2026-04-10T02:00:03.685355Z",
			"deleted_at": null,
			"main_name": "IRON HUNTER",
			"aliases": [
				"ATK13 ",
				"Belugasturgeon ",
				"Blue Python ",
				"CTG-8875 ",
				"ITG12 ",
				"KRYPTON ",
				"MAKERSMARK ",
				"Pensive Ursa ",
				"Secret Blizzard ",
				"Turla",
				"UAC-0003 ",
				"UAC-0024 ",
				"UNC4210 ",
				"Venomous Bear ",
				"Waterbug "
			],
			"source_name": "Secureworks:IRON HUNTER",
			"tools": [
				"Carbon-DLL",
				"ComRAT",
				"LightNeuron",
				"Mosquito",
				"PyFlash",
				"Skipper",
				"Snake",
				"Tavdig"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "a97cf06d-c2e2-4771-99a2-c9dee0d6a0ac",
			"created_at": "2022-10-25T16:07:24.349252Z",
			"updated_at": "2026-04-10T02:00:04.949821Z",
			"deleted_at": null,
			"main_name": "Turla",
			"aliases": [
				"ATK 13",
				"Belugasturgeon",
				"Blue Python",
				"CTG-8875",
				"G0010",
				"Group 88",
				"ITG12",
				"Iron Hunter",
				"Krypton",
				"Makersmark",
				"Operation Epic Turla",
				"Operation Moonlight Maze",
				"Operation Penguin Turla",
				"Operation Satellite Turla",
				"Operation Skipper Turla",
				"Operation Turla Mosquito",
				"Operation WITCHCOVEN",
				"Pacifier APT",
				"Pensive Ursa",
				"Popeye",
				"SIG15",
				"SIG2",
				"SIG23",
				"Secret Blizzard",
				"TAG-0530",
				"Turla",
				"UNC4210",
				"Venomous Bear",
				"Waterbug"
			],
			"source_name": "ETDA:Turla",
			"tools": [
				"ASPXSpy",
				"ASPXTool",
				"ATI-Agent",
				"AdobeARM",
				"Agent.BTZ",
				"Agent.DNE",
				"ApolloShadow",
				"BigBoss",
				"COMpfun",
				"Chinch",
				"Cloud Duke",
				"CloudDuke",
				"CloudLook",
				"Cobra Carbon System",
				"ComRAT",
				"DoublePulsar",
				"EmPyre",
				"EmpireProject",
				"Epic Turla",
				"EternalBlue",
				"EternalRomance",
				"GoldenSky",
				"Group Policy Results Tool",
				"HTML5 Encoding",
				"HyperStack",
				"IcedCoffee",
				"IronNetInjector",
				"KSL0T",
				"Kapushka",
				"Kazuar",
				"KopiLuwak",
				"Kotel",
				"LOLBAS",
				"LOLBins",
				"LightNeuron",
				"Living off the Land",
				"Maintools.js",
				"Metasploit",
				"Meterpreter",
				"MiamiBeach",
				"Mimikatz",
				"MiniDionis",
				"Minit",
				"NBTscan",
				"NETTRANS",
				"NETVulture",
				"Neptun",
				"NetFlash",
				"NewPass",
				"Outlook Backdoor",
				"Penquin Turla",
				"Pfinet",
				"PowerShell Empire",
				"PowerShellRunner",
				"PowerShellRunner-based RPC backdoor",
				"PowerStallion",
				"PsExec",
				"PyFlash",
				"QUIETCANARY",
				"Reductor RAT",
				"RocketMan",
				"SMBTouch",
				"SScan",
				"Satellite Turla",
				"SilentMoon",
				"Sun rootkit",
				"TTNG",
				"TadjMakhal",
				"Tavdig",
				"TinyTurla",
				"TinyTurla Next Generation",
				"TinyTurla-NG",
				"Topinambour",
				"Tunnus",
				"Turla",
				"Turla SilentMoon",
				"TurlaChopper",
				"Uroburos",
				"Urouros",
				"WCE",
				"WITCHCOVEN",
				"WhiteAtlas",
				"WhiteBear",
				"Windows Credential Editor",
				"Windows Credentials Editor",
				"Wipbot",
				"WorldCupSec",
				"XTRANS",
				"certutil",
				"certutil.exe",
				"gpresult",
				"nbtscan",
				"nbtstat",
				"pwdump"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "a97fee0d-af4b-4661-ae17-858925438fc4",
			"created_at": "2023-01-06T13:46:38.396415Z",
			"updated_at": "2026-04-10T02:00:02.957137Z",
			"deleted_at": null,
			"main_name": "Turla",
			"aliases": [
				"TAG_0530",
				"Pacifier APT",
				"Blue Python",
				"UNC4210",
				"UAC-0003",
				"VENOMOUS Bear",
				"Waterbug",
				"Pfinet",
				"KRYPTON",
				"Popeye",
				"SIG23",
				"ATK13",
				"ITG12",
				"Group 88",
				"Uroburos",
				"Hippo Team",
				"IRON HUNTER",
				"MAKERSMARK",
				"Secret Blizzard",
				"UAC-0144",
				"UAC-0024",
				"G0010"
			],
			"source_name": "MISPGALAXY:Turla",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "d11c89bb-1640-45fa-8322-6f4e4053d7f3",
			"created_at": "2022-10-25T15:50:23.509601Z",
			"updated_at": "2026-04-10T02:00:05.277674Z",
			"deleted_at": null,
			"main_name": "Turla",
			"aliases": [
				"Turla",
				"IRON HUNTER",
				"Group 88",
				"Waterbug",
				"WhiteBear",
				"Krypton",
				"Venomous Bear",
				"Secret Blizzard",
				"BELUGASTURGEON"
			],
			"source_name": "MITRE:Turla",
			"tools": [
				"PsExec",
				"nbtstat",
				"ComRAT",
				"netstat",
				"certutil",
				"KOPILUWAK",
				"IronNetInjector",
				"LunarWeb",
				"Arp",
				"Uroburos",
				"PowerStallion",
				"Kazuar",
				"Systeminfo",
				"LightNeuron",
				"Mimikatz",
				"Tasklist",
				"LunarMail",
				"HyperStack",
				"NBTscan",
				"TinyTurla",
				"Penquin",
				"LunarLoader"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434876,
	"ts_updated_at": 1775792015,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6c3116aa5f0d0e4944b09d3ca1cd7a0b7077cfd2.pdf",
		"text": "https://archive.orkl.eu/6c3116aa5f0d0e4944b09d3ca1cd7a0b7077cfd2.txt",
		"img": "https://archive.orkl.eu/6c3116aa5f0d0e4944b09d3ca1cd7a0b7077cfd2.jpg"
	}
}