Archive

Archive for the ‘MSTIC’ Category

North Korean threat actor targets small and midsize businesses with H0lyGh0st ransomware

A group of actors originating from North Korea that Microsoft Threat Intelligence Center (MSTIC) tracks as DEV-0530 has been developing and using ransomware in attacks since June 2021. This group, which calls itself H0lyGh0st, utilizes a ransomware payload with the same name for its campaigns and has successfully compromised small businesses in multiple countries as early as September 2021.

Along with their H0lyGh0st payload, DEV-0530 maintains an .onion site that the group uses to interact with their victims. The group’s standard methodology is to encrypt all files on the target device and use the file extension .h0lyenc, send the victim a sample of the files as proof, and then demand payment in Bitcoin in exchange for restoring access to the files. As part of their extortion tactics, they also threaten to publish victim data on social media or send the data to the victims’ customers if they refuse to pay. This blog is intended to capture part of MSTIC’s analysis of DEV-0530 tactics, present the protections Microsoft has implemented in our security products, and share insights on DEV-0530 and H0lyGh0st ransomware with the broader security community to protect mutual customers.

MSTIC assesses that DEV-0530 has connections with another North Korean-based group tracked as PLUTONIUM (aka DarkSeoul or Andariel). While the use of H0lyGh0st ransomware in campaigns is unique to DEV-0530, MSTIC has observed communications between the two groups, as well as DEV-0530 using tools created exclusively by PLUTONIUM.

As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with the information they need to secure their accounts. Microsoft uses DEV-#### designations as a temporary name given to an unknown, emerging, or a developing cluster of threat activity, allowing MSTIC to track it as a unique set of information until we reach high confidence about the origin or identity of the actor behind the activity.

Who is DEV-0530?

DEV-0530 primarily operates ransomware campaigns to pursue financial objectives. In MSTIC’s investigations of their early campaigns, analysts observed that the group’s ransom note included a link to the .onion site hxxp://matmq3z3hiovia3voe2tix2x54sghc3tszj74xgdy4tqtypoycszqzqd[.]onion, where the attackers claim to “close the gap between the rich and poor”. They also attempt to legitimize their actions by claiming to increase the victim’s security awareness by letting the victims know more about their security posture.

A screenshot of the ransom noted displayed by the H0lyGh0st ransomware. The page has a white background with black text, and presents information on how the ransomware victim can restore their files.
Figure 1. A H0lyGh0st ransom note linked to the attackers’ .onion site.
A screenshot of the H0lyGh0st .onion website. The page has a white background and white text, and presents claims made by the group regarding the motives behind their activities.
Figure 2. DEV-0530 attackers publishing their claims on their website.

Like many other ransomware actors, DEV-0530 notes on their website’s privacy policy that they would not sell or publish their victim’s data if they get paid. But if the victim fails to pay, they would publish everything. A contact form is also available for victims to get in touch with the attackers.

A screenshot from the H0lyGh0st website, presenting two sections in two columns. The column on the left detail their privacy and policy, while the one on the right pertains to their contact information.
Figure 3. Privacy policy and contact us information on the H0lyGh0st website.

Affiliations with other threat actors originating from North Korea

MSTIC assesses there is likely some overlap between DEV-0530 and PLUTONIUM. PLUTONIUM is a North Korean threat actor group affiliated with clusters of activity that are also known as DarkSeoul and Andariel. Active since at least 2014, PLUTONIUM has primarily targeted the energy and defense industries in India, South Korea, and the United States using a variety of tactics and techniques.

MSTIC has observed known DEV-0530 email accounts communicating with known PLUTONIUM attacker accounts. MSTIC has also observed both groups operating from the same infrastructure set, and even using custom malware controllers with similar names.

To further assess the origin of DEV-0530 operations, MSTIC performed a temporal analysis of observed activity from the group. MSTIC estimates that the pattern of life of DEV-0530 activity is most consistent with the UTC+8 and UTC+9 time zones. UTC+9 is the time zone used in North Korea.

Despite these similarities, differences in operational tempo, targeting, and tradecraft suggest DEV-0530 and PLUTONIUM are distinct groups.

Why are North Korean actors using ransomware?

Based on geopolitical observations by global experts on North Korean affairs and circumstantial observations, Microsoft analysts assess the use of ransomware by North Korea-based actors is likely motivated by two possible objectives.  

The first possibility is that the North Korean government sponsors this activity. The weakened North Korean economy has become weaker since 2016 due to sanctions, natural disasters, drought, and the North Korean government’s COVID-19 lockdown from the outside world since early 2020. To offset the losses from these economic setbacks, the North Korean government could have sponsored cyber actors stealing from banks and cryptocurrency wallets for more than five years. If the North Korean government is ordering these ransomware attacks, then the attacks would be yet another tactic the government has enabled to offset financial losses.

However, state-sponsored activity against cryptocurrency organizations has typically targeted a much broader set of victims than observed in DEV-0530 victimology. Because of this, it is equally possible that the North Korean government is not enabling or supporting these ransomware attacks. Individuals with ties to PLUTONIUM infrastructure and tools could be moonlighting for personal gain. This moonlighting theory might explain the often-random selection of victims targeted by DEV-0530.

Although Microsoft cannot be certain of DEV-0530’s motivations, the impact of these ransomware attacks on our customers raises the importance of exposing the underlying tactics and techniques, detecting and preventing attacks in our security products, and sharing our knowledge with the security ecosystem.

Ransomware developed by DEV-0530

Between June 2021 and May 2022, MSTIC classified H0lyGh0st ransomware under two new malware families: SiennaPurple and SiennaBlue. Both were developed and used by DEV-0530 in campaigns. MSTIC identified four variants under these families – BTLC_C.exe, HolyRS.exe, HolyLock.exe, and BLTC.exe – and clustered them based on code similarity, C2 infrastructure including C2 URL patterns, and ransom note text. BTLC_C.exe is written in C++ and is classified as SiennaPurple, while the rest are written in Go, and all variants are compiled into .exe to target Windows systems. Microsoft Defender Antivirus, which is built into and ships with Windows 10 and 11, detects and blocks BTLC_C.exe as SiennaPurple and the rest as SiennaBlue, providing protection for Windows users against all known variants the H0lyGh0st malware..

A timeline of the payloads used by DEV-0530 over time, SiennaPurple and SiennaBlue. The timeline covers developments from May 2021 to June 2022, with SiennaPurple being used from May to October 2021, and SiennaBlue from September 2021 to June 2022 and beyond.
Figure 4. Timeline of DEV-0530 ransomware payloads.

SiennaPurple ransomware family: BTLC_C.exe

BLTC_C.exe is a portable ransomware developed by DEV-0530 and was first seen in June 2021. This ransomware doesn’t have many features compared to all malware variants in the SiennaBlue family. Prominently, if not launched as an administrative user, the BLTC_C.exe malware displays the following hardcoded error before exiting:

"This program only execute under admin privilege".

The malware uses a simple obfuscation method for strings where 0x30 is subtracted from the hex value of each character, such that the string “aic^ef^bi^abc0” is decoded to 193[.]56[.]29[.]123. The indicators of compromise (IOCs) decoded from the BLTC_C.exe ransomware are consistent with all malware variants in the SiennaBlue family, including the C2 infrastructure and the HTTP beacon URL structure access.php?order=AccessRequest&cmn. The BTLC_C.exe sample analyzed by MSTIC has the following PDB path: M:\ForOP\attack(utils)\attack tools\Backdoor\powershell\btlc_C\Release\btlc_C.pdb.

SiennaBlue ransomware family: HolyRS.exe, HolyLocker.exe, and BTLC.exe

Between October 2021 and May 2022, MSTIC observed a cluster of new DEV-0530 ransomware variants written in Go. We classified these variants as SiennaBlue. While new Go functions were added to the different variants over time, all the ransomware in the SiennaBlue family share the same core Go functions.

A deeper look into the Go functions used in the SiennaBlue ransomware showed that over time, the core functionality expanded to include features like various encryption options, string obfuscation, public key management, and support for the internet and intranet. The table below demonstrates this expansion by comparing the Go functions in HolyRS.exe and BTLC.exe:

HolyRS.exe [2021] BTLC.exe [2022]
main_main
main_init_0
main_IsAdmin
main_encryptFiles
HolyLocker_RsaAlgorithm_GenerateKeyPair
HolyLocker_RsaAlgorithm_Encrypt
HolyLocker_CryptoAlogrithm___ptr_File__EncryptRSA
HolyLocker_CryptoAlogrithm___ptr_File__EncryptAES
HolyLocker_utilities_GenerateRandomANString
HolyLocker_utilities_StringInSlice
HolyLocker_utilities_SliceContainsSubstring
HolyLocker_utilities_RenameFile
HolyLocker_Main_init
HolyLocker_communication_New
HolyLocker_communication___ptr_Client__GetPubkeyFromServer
HolyLocker_communication___ptr_Client__Do
HolyLocker_communication___ptr_Client__SendEncryptedPayload
HolyLocker_communication___ptr_Client__SendFinishRequest
HolyLocker_communication___ptr_Client__AddNewKeyPairToIntranet
HolyLocker_communication___ptr_Client__AddNewKeyPair

main_main
main_init_0
main_IsAdmin
main_encryptFiles
main_DeleteSchTask
main_DisableNetworkDevice main_encryptString
main_decryptString
main_cryptAVPass
main_SelfDelete
HolyLocker_RsaAlgorithm_GenerateKeyPair
HolyLocker_RsaAlgorithm_Encrypt
HolyLocker_CryptoAlogrithm___ptr_File__EncryptRSA
HolyLocker_CryptoAlogrithm___ptr_File__EncryptAES
HolyLocker_utilities_GenerateRandomANString
HolyLocker_utilities_StringInSlice
HolyLocker_utilities_SliceContainsSubstring
HolyLocker_utilities_RenameFile
HolyLocker_Main_init
HolyLocker_communication_New
HolyLocker_communication___ptr_Client__GetPubkeyFromServer
HolyLocker_communication___ptr_Client__Do
HolyLocker_communication___ptr_Client__SendEncryptedPayload
HolyLocker_communication___ptr_Client__SendFinishRequest
HolyLocker_communication___ptr_Client__AddNewKeyPairToIntranet
HolyLocker_communication___ptr_Client__AddNewKeyPair  

MSTIC assesses DEV-0530 successfully compromised several targets in multiple countries using HolyRS.exe in November 2021. A review of the victims showed they were primarily small-to-midsized businesses, including manufacturing organizations, banks, schools, and event and meeting planning companies. The victimology indicates that these victims are most likely targets of opportunity. MSTIC suspects that DEV-0530 might have exploited vulnerabilities such as CVE-2022-26352 (DotCMS remote code execution vulnerability) on public-facing web applications and content management systems to gain initial access into target networks. The SiennaBlue malware variants were then dropped and executed. To date, MSTIC has not observed DEV-0530 using any 0-day exploits in their attacks.

After successfully compromising a network, DEV-0530 exfiltrated a full copy of the victims’ files. Next, the attackers encrypted the contents of the victim device, replacing all file names with Base64-encoded versions of the file names and renaming the extension to .h0lyenc. Victims found a ransom note in C:\FOR_DECRYPT.html, as well as an email from the attackers with subject lines such as:

!!!!We are < H0lyGh0st>. Please Read me!!!!

As seen in the screenshot below, the email from the attackers let the victim know that the group has stolen and encrypted all their files. The email also included a link to a sample of the stolen data to prove their claim, in addition to the demand for payment for recovering the files.

A screenshot of the email sent by DEV-0530 as a ransom note to their targets. The email message tells the target to pay in order to recover their files. It also mentions a URL where they can access some of their data.
Figure 5. Ransom note left by DEV-0530 attackers.

BTLC.exe is the latest DEV-0530 ransomware variant and has been seen in the wild since April 2022. BTLC.exe can be configured to connect to a network share using the default username, password, and intranet URL hardcoded in the malware if the ServerBaseURL is not accessible from the device. One notable feature added to BTLC.exe is a persistence mechanism in which the malware creates or deletes a scheduled task called lockertask, such that the following command line syntax can be used to launch the ransomware:

cmd.exe /Q /c schtasks /create /tn lockertask /tr [File] /sc minute /mo 1 /F /ru system 1> \\127.0.0.1\ADMIN$\__[randomnumber] 2>&1

Once the ransomware is successfully launched as an administrator, it tries to connect to the default ServerBaseURL hardcoded in the malware, attempts to upload a public key to the C2 server, and encrypts all files in the victim’s drive.

HolyRS.exe/HolyLocker.exe C2 configuration BTLC.exe C2 configuration
main_ServerBaseURL: hxxp://193[.]56[.]29[.]123:8888
main_IntranetURL: 10[.]10[.]3[.]42
main_Username: adm-karsair  
EncryptionKey: H0lyGh0stKey1234
IntranetUrl: 192[.]168[.]168[.]5
Username: atrismsp Scheduledtask name: lockertask
A screenshot of assembly code presenting configuration information used by the malware to connect to its C2 server. The code includes the C2 URL, as well as the attacker's username.
Figure 6. BTLC.exe C2 communication

Based on our investigation, the attackers frequently asked victims for anywhere from 1.2 to 5 Bitcoins. However, the attackers were usually willing to negotiate and, in some cases, lowered the price to less than one-third of the initial asking price. As of early July 2022, a review of the attackers’ wallet transactions shows that they have not successfully extorted ransom payments from their victims.

A screenshot from a Bitcoin explorer page presenting information on the attackers' Bitcoin wallet. The page shows that the Bitcoin wallet is empty.
Figure 7. Screenshot of DEV-0530 attackers’ wallet

HolyRS.exe/BTLC.exe C2 URL pattern:

  • hxxp://193[.]56[.]29[.]123:8888/access.php?order=GetPubkey&cmn=[Victim_HostName]
  • hxxp://193[.]56[.]29[.]123:8888/access.php?order=golc_key_add&cmn=[Victim_HostName]&type=1
  • hxxp://193[.]56[.]29[.]123:8888/access.php?order=golc_key_add&cmn=[Victim_HostName]&type=2
  • hxxp://193[.]56[.]29[.]123:8888/access.php?order=golc_finish&cmn=[Victim_HostName]&

Examples of HolyRS.exe/BTLC.exe ransom note metadata:

Attacker email address: H0lyGh0st@mail2tor[.]com
Image location: hxxps://cloud-ex42[.]usaupload[.]com/cache/plugins/filepreviewer/219002/f44c6929994386ac2ae18b93f8270ec9ff8420d528c9e35a878efaa2d38fb94c/1100x800_cropped.jpg
Report URL: hxxp://matmq3z3hiovia3voe2tix2x54sghc3tszj74xgdy4tqtypoycszqzqd[.]onion

Microsoft will continue to monitor DEV-0530 activity and implement protections for our customers. The current detections, advanced detections, and indicators of compromise (IOCs) in place across our security products are detailed below.

Recommended customer actions

Microsoft has implemented protections to detect these malware families as SiennaPurple and SiennaBlue (e.g., ALF:Ransom:Win32/SiennaBlue.A) via Microsoft Defender Antivirus and Microsoft Defender for Endpoint, wherever these are deployed on-premises and in cloud environments.

Microsoft encourages all organizations to proactively implement and frequently validate a data backup and restore plan as part of broader protection against ransomware and extortion threats.

The techniques used by DEV-0530 in H0lyGh0st activity can be mitigated by adopting the security considerations provided below:

  • Use the included IOCs to investigate whether they exist in your environment and assess for potential intrusion.

Our blog on the ransomware-as-a-service economy has an exhaustive guide on how to protecting against ransomware threats. We encourage readers to refer to that blog for a comprehensive guide that has a deep dive into each of the following areas:

For small or midsize companies who use Microsoft Defender for Business or Microsoft 365 Business Premium, enabling each of the features below will provide a protective layer against these threats where applicable. For Microsoft 365 Defender customers, the following checklist eliminates security blind spots:

  • Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools and techniques, block new and unknown malware variants, and enhance attack surface reduction rules and tamper protection.
  • Turn on tamper protection features to prevent attackers from stopping security services.
  • Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when a non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode also blocks indicators identified proactively by Microsoft Threat Intelligence teams.
  • Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
  • Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches.
  • Use device discovery to increase visibility into the network by finding unmanaged devices and onboarding them to Microsoft Defender for Endpoint.
  • Protect user identities and credentials using Microsoft Defender for Identity, a cloud-based security solution that leverages on-premises Active Directory signals to monitor and analyze user behavior to identify suspicious user activities, configuration issues, and active attacks.

Indicators of compromise

This list provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

Indicator Type Description
99fc54786a72f32fd44c7391c2171ca31e72ca52725c68e2dde94d04c286fccd SHA-256 Hash of BTLC_C.exe
f8fc2445a9814ca8cf48a979bff7f182d6538f4d1ff438cf259268e8b4b76f86 SHA-256 Hash of HolyRS.exe
bea866b327a2dc2aa104b7ad7307008919c06620771ec3715a059e675d9f40af SHA-256 Hash of BTLC.exe
cmd.exe /Q /c schtasks /create /tn lockertask /tr [File] /sc minute /mo 1 /F /ru system 1> \\127.0.0.1\ADMIN$\__[randomnumber] 2>&1   Command line Example of new ScheduledTask to BTLC.exe
193[.]56[.]29[.]123 C2 C2 IP address
H0lyGh0st@mail2tor[.]com Email Ransomware payment communication address
C:\FOR_DECRYPT.html File path File path of ransom note

NOTE: These indicators should not be considered exhaustive for this observed activity.

Microsoft 365 detections

Microsoft Defender Antivirus

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint customers may see any or a combination of the following alerts as an indication of possible attack.

  • DEV-0530 activity group
  • Ransomware behavior detected in the file system
  • Possible ransomware infection modifying multiple files
  • Possible ransomware activity

Advanced hunting queries

Microsoft Sentinel

To locate possible DEV-0530 activity mentioned in this blog post, Microsoft Sentinel customers can use the queries detailed below:

Identify DEV-0530  IOCs

This query identifies a match based on IOCs related to DEV-0530 across various Sentinel data feeds:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/Dev-0530_July2022.yaml

Identify renamed file extension

DEV-0530 actors are known to encrypt the contents of the victim’s device as well as rename the file and extension. The following query detects the creation of files with .h0lyenc extension:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/Dev-0530_FileExtRename.yaml

Identify Microsoft Defender Antivirus detection related to DEV-0530

This query looks for Microsoft Defender AV detections related to DEV-0530 and joins the alert with other data sources to surface additional information such as device, IP, signed-in on users, etc.

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SecurityAlert/Dev-0530AVHits.yaml

Yara rules

rule SiennaPurple 
{ 
	meta: 
        	author = "Microsoft Threat Intelligence Center (MSTIC)" 
		description = "Detects PDB path, C2, and ransom note in DEV-0530 Ransomware SiennaPurple samples" 
		hash = "99fc54786a72f32fd44c7391c2171ca31e72ca52725c68e2dde94d04c286fccd" 
	strings: 
		$s1 = "ForOP\\attack(utils)\\attack tools\\Backdoor\\powershell\\btlc_C\\Release\\btlc_C.pdb" 
		$s2 = "matmq3z3hiovia3voe2tix2x54sghc3tszj74xgdy4tqtypoycszqzqd.onion"
		$s3 = "H0lyGh0st@mail2tor.com"
		$s4 = "We are <HolyGhost>. All your important files are stored and encrypted."
		$s5 = "aic^ef^bi^abc0"
		$s6 = "---------------------------3819074751749789153841466081"

	condition: 
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and 
		filesize < 7MB and filesize > 1MB and 
		all of ($s*) 
}
rule SiennaBlue 
{ 
    	meta: 
		author = "Microsoft Threat Intelligence Center (MSTIC)" 
		description = "Detects Golang package, function, and source file names observed in DEV-0530 Ransomware SiennaBlue samples" 
		hash1 = "f8fc2445a9814ca8cf48a979bff7f182d6538f4d1ff438cf259268e8b4b76f86" 
		hash2 = "541825cb652606c2ea12fd25a842a8b3456d025841c3a7f563655ef77bb67219
	strings: 
		$holylocker_s1 = "C:/Users/user/Downloads/development/src/HolyLocker/Main/HolyLock/locker.go"
		$holylocker_s2 = "HolyLocker/Main.EncryptionExtension"
		$holylocker_s3 = "HolyLocker/Main.ContactEmail"
		$holylocker_s4 = "HolyLocker/communication.(*Client).GetPubkeyFromServer"
		$holylocker_s5 = "HolyLocker/communication.(*Client).AddNewKeyPairToIntranet"
		
		$holyrs_s1 = "C:/Users/user/Downloads/development/src/HolyGhostProject/MainFunc/HolyRS/HolyRS.go"
		$holyrs_s2 = "HolyGhostProject/MainFunc.ContactEmail"
		$holyrs_s3 = "HolyGhostProject/MainFunc.EncryptionExtension"
		$holyrs_s4 = "HolyGhostProject/Network.(*Client).GetPubkeyFromServer"
		$holyrs_s5 = "HolyGhostProject/Network.(*Client).AddNewKeyPairToIntranet"
		$s1 = "Our site : <b><a href=%s>H0lyGh0stWebsite"
		$s2 = ".h0lyenc"
		$go_prefix = "Go build ID:"
	condition: 
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and 
		filesize < 7MB and filesize > 1MB and 
		$go_prefix and all of ($s*) and (all of ($holylocker_*) or all of ($holygrs_*))
}

The post North Korean threat actor targets small and midsize businesses with H0lyGh0st ransomware appeared first on Microsoft Security Blog.

Hive ransomware gets upgrades in Rust

Hive ransomware is only about one year old, having been first observed in June 2021, but it has grown into one of the most prevalent ransomware payloads in the ransomware-as-a-service (RaaS) ecosystem. With its latest variant carrying several major upgrades, Hive also proves it’s one of the fastest evolving ransomware families, exemplifying the continuously changing ransomware ecosystem.

The upgrades in the latest variant are effectively an overhaul: the most notable changes include a full code migration to another programming language and the use of a more complex encryption method. The impact of these updates is far-reaching, considering that Hive is a RaaS payload that Microsoft has observed in attacks against organizations in the healthcare and software industries by large ransomware affiliates like DEV-0237.

Microsoft Threat Intelligence Center (MSTIC) discovered the new variant while analyzing detected Hive ransomware techniques for dropping .key files. We know that Hive drops its encryption keys file, which contains encrypted keys used to decrypt encrypted files, and uses a consistent naming pattern:

[KEY_NAME].key.[VICTIM_IDENTIFIER] 
(e.g., BiKtPupMjgyESaene0Ge5d0231uiKq1PFMFUEBNhAYv_.key.ab123)

The said .key files were missing the [VICTIM_IDENTIFIER] part of the file name, prompting deeper analysis of the Hive ransomware that dropped them. This analysis led to the discovery of the new Hive variant and its multiple versions, which exhibit slightly different available parameters in the command line and the executed processes.

Analyzing these patterns in samples of the new variants, we discovered even more samples, all with a low detection rate and none being correctly identified as Hive. In this blog we will share our in-depth analysis of the new Hive variant, including its main features and upgrades, with the aim of equipping analysts and defenders with information to better identify and protect organizations against malware attacks relying on Hive.

Analysis and key findings

The switch from GoLang to Rust

The main difference between the new Hive variant and old ones is the programming language used. The old variants were written in Go (also referred to as GoLang), while the new Hive variant is written in Rust.

Hive isn’t the first ransomware written in Rust—BlackCat, another prevalent ransomware, was the first. By switching the underlying code to Rust, Hive benefits from the following advantages that Rust has over other programming languages:

  • It offers memory, data type, and thread safety
  • It has deep control over low-level resources
  • It has a user-friendly syntax
  • It has several mechanisms for concurrency and parallelism, thus enabling fast and safe file encryption
  • It has a good variety of cryptographic libraries
  • It’s relatively more difficult to reverse-engineer

String encryption

The new Hive variant uses string encryption that can make it more evasive. Strings reside in the .rdata section and are decrypted during runtime by XORing with constants. The constants that are used to decrypt the same string sometimes differ across samples, making them an unreliable basis for detection.

For example, let’s look at the section where part of the string “!error no flag -u <login>:<password> provided” is decrypted. In one sample (SHA-256: f4a39820dbff47fa1b68f83f575bc98ed33858b02341c5c0464a49be4e6c76d3), the constants are 0x9F2E3F1F and 0x95C9:

Partial screenshot of a code-level analysis of a Hive sample.
Figure 1 – String decryption using constants 0x9F2E3F1F and 0x95C9

In another sample (SHA-256: 6e5d49f604730ef4c05cfe3f64a7790242e71b4ecf1dc5109d32e811acf0b053), the constants are 0x3ECF7CC4 and 0x198F:        

Partial screenshot of a code-level analysis of a Hive sample.
Figure 2 – String decryption using constants 0x3ECF7CC4 and 0x198F

Some samples do share constants when decrypting the same string. For example, let’s look where the parameter string “-da” is decrypted. In one sample (SHA-256: 88b1d8a85bf9101bc336b01b9af4345ed91d3ec761554d167fe59f73af73f037), the constants are 0x71B4 and 2:

Partial screenshot of a code-level analysis of a Hive sample.
Figure 3 – String decryption using constants 0x71B4 and 2

In another sample (SHA-256: 33744c420884adf582c46a4b74cbd9c145f2e15a036bb1e557e89d6fd428e724), the constants are the same:

Partial screenshot of a code-level analysis of a Hive sample.
Figure 4 – String decryption in a different sample also using constants 0x71B4 and 2

Command-line parameters

In old Hive variants, the username and the password used to access the Hive ransom payment website are embedded in the samples. In the new variant, these credentials must be supplied in the command line under the “-u” parameter, which means that they can’t be obtained by analysts from the sample itself.

Partial screenshot of a command prompt showing an error message.
Figure 5 – Without a username and a password, the sample won’t continue its execution

Like most modern ransomware, Hive introduces command-line parameters, which allow attackers flexibility when running the payload by adding or removing functionality. For example, an attacker can choose to encrypt files on remote shares or local files only or select the minimum file size for encryption. In the new Hive variant, we found the following parameters across different samples:

Parameter Functionality
-no-local Don’t encrypt local files
-no-mounted Don’t encrypt files on mounted network shares
-no-discovery Don’t discover network shares
-local-only Encrypt only local files
-network-only Encrypt only files on network shares
-explicit-only Encrypt specific folder(s). For example, ‘-explicit-only c:\mydocs c:\myphotos’
-min-size Minimum file size, in bytes, to encrypt. For example, ‘-min-size 102400’ will encrypt files with size equal or greater than 100kb
-da [Usage is being analyzed.]
-f [Usage is being analyzed.]
-force [Usage is being analyzed.]
-wmi [Usage is being analyzed.]

Overall, it appears different versions have different parameters that are constantly updated. Unlike in previous variants where there was a ‘help’ menu, in the new variant, the attacker must know the parameters beforehand. Since all strings are encrypted, it makes finding the parameters challenging for security researchers.

Stopped services and processes

Like most sophisticated malware, Hive stops services and processes associated with security solutions and other tools that might get in the way of its attack chain. Hive tries to impersonate the process tokens of trustedinstaller.exe and winlogon.exe so it can stop Microsoft Defender Antivirus, among other services.

Hive stops the following services:

windefend, msmpsvc, kavsvc, antivirservice, zhudongfungyu, vmm, vmwp, sql, sap, oracle, mepocs, veeam, backup, vss, msexchange, mysql, sophos, pdfservice, backupexec, gxblr, gxvss, gxclmgrs, gxvcd, gxcimgr, gxmmm, gxvsshwprov, gxfwd, sap, qbcfmonitorservice, qbidpservice, acronisagent, veeam, mvarmor, acrsch2svc

It also stops the following processes:

dbsnmp, dbeng50, bedbh, excel, encsvc, visios, firefox, isqlplussvc, mspub, mydesktopqos, notepad, ocautoupds, ocomm, ocssd, onenote, outlook, sqbcoreservice, sql, steam, tbirdconfig, thunderbird, winword, wordpad, xfssvccon, vxmon, benetns, bengien, pvlsvr, raw_agent_svc, cagservice, sap, qbidpservice, qbcfmonitorservice, teamviewer_service, teamviewer, tv_w32, tv_x64, cvd, saphostexec, sapstartsrv, avscc, dellsystemdetect, enterpriseclient, veeam, thebat, cvfwd, cvods, vsnapvss, msaccess, vaultsvc, beserver, appinfo, qbdmgrn, avagent, spooler, powerpnt, cvmountd, synctime, oracle, wscsvc, winmgmt, *sql*

Launched processes

As part of its ransomware activity, Hive typically runs processes that delete backups and prevent recovery. There are differences between versions, and some samples may not execute all these processes, but one sample that starts the most processes is SHA-256: 481dc99903aa270d286f559b17194b1a25deca8a64a5ec4f13a066637900221e:

  • “vssadmin.exe delete shadows /all /quiet”
  • “wmic.exe shadowcopy delete”
  • “wbadmin.exe delete systemstatebackup”
  • “wbadmin.exe delete catalog -quiet”
  • “bcdedit.exe /set {default} recoveryenabled No”
  • “bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures”
  • “wbadmin.exe delete systemstatebackup -keepVersions:3”

Ransom note

Hive’s ransom note has also changed, with the new version referencing the .key files with their new file name convention and adding a sentence about virtual machines (VMs).

The older variants had an embedded username and password (marked as hidden). In the new variant, the username and password are taken from the command line parameter -u and are labeled test_hive_username and test_hive_password.

Old ransom note text:

 Your network has been breached and all data were encrypted.
Personal data, financial reports and important documents are ready to disclose.
 
To decrypt all the data and to prevent exfiltrated files to be disclosed at 
http://hive[REDACTED].onion/
you will need to purchase our decryption software.
 
Please contact our sales department at:
 
   http://hive[REDACTED].onion/
  
      Login:    [REDACTED]
      Password: [REDACTED]
 
To get an access to .onion websites download and install Tor Browser at:
   https://www.torproject.org/ (Tor Browser is not related to us)
 
 
Follow the guidelines below to avoid losing your data:
 
- Do not modify, rename or delete *.key.abc12 files. Your data will be 
   undecryptable.
- Do not modify or rename encrypted files. You will lose them.
- Do not report to the Police, FBI, etc. They don't care about your business.
   They simply won't allow you to pay. As a result you will lose everything.
- Do not hire a recovery company. They can't decrypt without the key. 
   They also don't care about your business. They believe that they are 
   good negotiators, but it is not. They usually fail. So speak for yourself.
- Do not reject to purchase. Exfiltrated files will be publicly disclosed.

New ransom note text:

Your network has been breached and all data were encrypted.
Personal data, financial reports and important documents are ready to disclose.
 
To decrypt all the data and to prevent exfiltrated files to be disclosed at 
http://hive[REDACTED].onion/
you will need to purchase our decryption software.
 
Please contact our sales department at:
 
   http://hive[REDACTED].onion/
 
      Login:    test_hive_username
      Password: test_hive_password
 
To get an access to .onion websites download and install Tor Browser at:
   https://www.torproject.org/ (Tor Browser is not related to us)
 
 
Follow the guidelines below to avoid losing your data:
 
- Do not delete or reinstall VMs. There will be nothing to decrypt.
- Do not modify, rename or delete *.key files. Your data will be 
   undecryptable.
- Do not modify or rename encrypted files. You will lose them.
- Do not report to the Police, FBI, etc. They don't care about your business.
   They simply won't allow you to pay. As a result you will lose everything.
- Do not hire a recovery company. They can't decrypt without the key. 
   They also don't care about your business. They believe that they are 
   good negotiators, but it is not. They usually fail. So speak for yourself.
- Do not reject to purchase. Exfiltrated files will be publicly disclosed.

Encryption

The most interesting change in the Hive variant is its cryptography mechanism. The new variant was first uploaded to VirusTotal on February 21, 2022, just a few days after a group of researchers from Kookmin University in South Korea published the paper “A Method for Decrypting Data Infected with Hive Ransomware” on February 17, 2022. After a certain period of development, the new variant first appeared in Microsoft threat data on February 22.

The new variant uses a different set of algorithms: Elliptic Curve Diffie-Hellmann (ECDH) with Curve25519 and XChaCha20-Poly1305 (authenticated encryption with ChaCha20 symmetric cipher).

A unique encryption approach

The new Hive variant uses a unique approach to file encryption. Instead of embedding an encrypted key in each file that it encrypts, it generates two sets of keys in memory, uses them to encrypt files, and then encrypts and writes the sets to the root of the drive it encrypts, both with .key extension.

To indicate which keys set was used to encrypt a file, the name of the .key file containing the corresponding encryption keys is added to the name of the encrypted file on disk, followed by an underscore and then a Base64 string (also adding underscore and hyphen to the character set). Once it’s Base64-decoded, the string contains two offsets, with each offset pointing to a different location in the corresponding .key file. This way, the attacker can decrypt the file using these offsets.

For example, after running Hive, we got the following files dropped to the C:\ drive:

  • C:\3bcVwj6j.key
  • C:\l0Zn68cb.key

In this example, a file named myphoto.jpg would be renamed to C:\myphoto.jpg.l0Zn68cb _ -B82BhIaGhI8. As we discuss in the following sections, the new variant’s keys set generation is entirely different from old variants. However, its actual file encryption is very similar.

Keys set generation

A buffer of size 0xCFFF00 bytes is allocated. Using two custom functions to generate random bytes (labeled “random_num_gen” and “random_num_gen_2” for demonstration purposes) the buffer is filled. The first 0xA00000 bytes of this buffer are filled with random bytes and the remaining 0x2FFF00 bytes are simply copied from the first 0x2FFF00 random bytes that were copied earlier to the buffer.

The content of each buffer is a keys set (a collection of symmetric keys). Since two buffers are allocated, there are two keys sets. In the encryption process, the malware randomly selects different keys (byte sequences) for each file from one of the keys set and uses them to encrypt the file by XORing the byte sequence of the keys with the file’s content.

Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 6 – Original keys set generation
Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 7 – Inside get_random_byte

A custom 64-byte hash is prepared for each keys set. This hash will be used later.

Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 8 – Preparing the custom hash of the keys set

After the hash is computed and several other strings are decrypted, the encryption process takes the following steps:

  1. Generate victim_private_key using the same functions introduced above.
Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 9 – Generating victim_private_key
  1. Generate victim_public_key using ECDH with Curve25519. The input is victim_private_key and the basepoint is 9 followed by 31 zeros (embedded in the sample).
Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 10 – Generating victim_public_key
  1. Generate a 24-byte nonce for the XChaCha algorithm, later in Poly1305-XChaCha20.
Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 11 – Generating a 24-byte nonce
  1. Generate shared_secret using ECDH with Curve25519. The input is victim_private_key and hive_public_key. Then, the  shared_secret (as a key) with hive_public_key (as a nonce) is used to derive the derived_key using ChaCha20.
Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 12 – Generating shared_secret
  1. Encrypt the keys set using Poly1305-XChaCha20. The values used for the encryption are the keys set, derived_key, nonce, and the embedded associated data (AD). This function encrypts the keys set and adds a 16-byte authentication tag at the end of the buffer of the encrypted keys. It’s unclear if the authentication tag is ever checked.
Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 13 – Encrypting the keys set

Now that the keys set is finally encrypted, the nonce, victim_public_key, the now-encrypted keys set, and the authentication tag are copied to a new buffer, one after another. This buffer (which we label encrypted_structure_1) is treated as a new keys set, which is again encrypted using the same method described above but with a second hive_public_key. This time, the function outputs new nonce, victim_private_key, and others. Only the associated data is the same.

Finally, the new buffer, which contains the second_nonce, second_victim_public_key, and the encryptedencrypted_structure_1, is written to the root of the drive it’s encrypting (for example, C:\). The create_extension function generates a Base64 string based on the first six bytes of the custom hash that was created earlier. This Base64 string serves as the file name, and the extension of the file is simply “.key”.

Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 14 – Generating a Base64 string based on the first six bytes of the custom hash
Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 15 – Using the Base64 string as the file name

The diagram below illustrates the encryption scheme described above:

Diagram containing icons and arrows illustrating the new Hive variant's encryption scheme.
Figure 16 – The keys set encryption scheme of the new Hive variant

As seen in the diagram above, “Keys sets encryption flow” is executed twice. In the first round it is executed with the original keys set as an input. In the second round it is executed with the “encrypted structure 1” as an input. In its second execution, all other input values are different except the AD (associated data) and the Basepoint 9.

Hence, the following values are new in the second execution: victim_private_key, victim_public_key, hive_public_key, nonce, shared_secret and derived_key.

File encryption

After both keys files are written to the disk, the multi-threaded file encryption starts. Before encrypting each file, the malware checks its name and extension against a list of strings. If there is a match, then the file will not be encrypted. For example, a file with .exe extension will not be encrypted if .exe is in the list of strings. It should be noted that this list is encrypted and decrypted during runtime.

The same file encryption method seen in old variants is used in the new one: two random numbers are generated and used as offsets to the keys set. Each offset is four bytes:

Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 17 – Generating the offsets

For the encryption, the file’s content is XORed with bytes from the keys set, according to the offsets. The file bytes are XORed twice—once according to the first offset and a second time according to the second offset. Files are encrypted in blocks of 0x100000 bytes, with the maximum number of blocks at 100. There is an interval between the encrypted blocks as defined by block_space. After the encryption is finished in memory, the encrypted data is written to the disk, overwriting the original file.

Partial screenshot of a code snippet
Figure 18 – Calculation of number of blocks
Partial screenshot of a code snippet
Figure 19 – Actual encryption of the file bytes
Partial screenshot of a Hive variant's encryption technique in assembly code.
Figure 20 – Reading a file, encrypting it, and writing it back to the disk

Looking at when create_extension is called once file encryption has started, we recognized a similar structure in the previous variant:

Partial screenshot of a Hive variant's structure in assembly code.
Figure 21 – Creating the extension for the file

Let us look at the value (72 D7 A7 A3 F5 5B FF EF 21 6B 11 7C 2A 18 CD 00) in the address of r9 register just before create_extension is called on a file called EDBtmp.log

Partial screenshot of a hexadecimal value

Recall that in the older variants, 0xFF was used as a delimiter to separate the key file name from the offset values. We can also see it here. Converting the first six bytes (72 D7 A7 A3 F5 5B) to Base64 yields the following:

cteno/Vb

And if we step over create_extension, the result is similar—we get cteno_Vb as the .key file name (note: Since Hive uses a different Base64 character set, “/” was replaced with “_”):

Partial screenshot of hexadecimal values

Microsoft will continue to monitor the Hive operators’ activity and implement protections for our customers. The current detections, advanced detections, and indicators of compromise (IOCs) in place across our security products are detailed below.

Recommended customer actions

The techniques used by the new Hive variant can be mitigated by adopting the security considerations provided below:

  • Use the included IOCs to investigate whether they exist in your environment and assess for potential intrusion.

Our recent blog on the ransomware-as-a-service economy has an exhaustive guide on how to protect yourself from ransomware threats that dive deep into each of the following areas. We encourage readers to refer to that blog for a comprehensive guide on:

For Microsoft 365 Defender customers, the following checklist eliminates security blind spots:

  • Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools and techniques, block new and unknown malware variants, and enhance attack surface reduction rules and tamper protection.
  • Turn on tamper protection features to prevent attackers from stopping security services.
  • Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when a non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode also blocks indicators identified proactively by Microsoft Threat Intelligence teams.
  • Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
  • Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches.
  • Use device discovery to increase visibility into the network by finding unmanaged devices and onboarding them to Microsoft Defender for Endpoint.
  • Protect user identities and credentials using Microsoft Defender for Identity, a cloud-based security solution that leverages on-premises Active Directory signals to monitor and analyze user behavior to identify suspicious user activities, configuration issues, and active attacks.

Indicators of compromise (IOCs)

The below list provides a partial list of the IOCs observed during our investigation and included in this blog. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

Indicator Type Description
f4a39820dbff47fa1b68f83f575bc98ed33858b02341c5c0464a49be4e6c76d3 SHA-256 Hive Rust variant payload
88b1d8a85bf9101bc336b01b9af4345ed91d3ec761554d167fe59f73af73f037 SHA-256 Hive Rust variant payload
065208b037a2691eb75a14f97bdbd9914122655d42f6249d2cca419a1e4ba6f1 SHA-256 Hive Rust variant payload
33744c420884adf582c46a4b74cbd9c145f2e15a036bb1e557e89d6fd428e724 SHA-256 Hive Rust variant payload
afab34235b7f170150f180c7afb9e3b4e504a84559bbd03ab71e64e3b6541149 SHA-256 Hive Rust variant payload
36759cab7043cd7561ac6c3968832b30c9a442eff4d536e901d4ff70aef4d32d SHA-256 Hive Rust variant payload
481dc99903aa270d286f559b17194b1a25deca8a64a5ec4f13a066637900221e SHA-256 Hive Rust variant payload
6e5d49f604730ef4c05cfe3f64a7790242e71b4ecf1dc5109d32e811acf0b053 SHA-256 Hive Rust variant payload
32ff0e5d87ec16544b6ff936d6fd58023925c3bdabaf962c492f6b078cb01914 SHA-256 Hive Rust variant payload

NOTE: These indicators shouldn’t be considered exhaustive for this observed activity.

Detections

Microsoft 365 Defender

Microsoft Defender Antivirus

Microsoft Defender Antivirus provides detection for this threat under the following family names with build version 1.367.405.0 or later.

  • Ransom:Win64/Hive
  • Ransom:Win32/Hive

Microsoft Defender for Endpoint detection

Microsoft Defender for Endpoint customers may see any or a combination of the following alerts as an indication of possible attack. These alerts are not necessarily an indication of a Hive compromise, but should be investigated:

  • Ransomware behavior detected in the file system
  • File backups were deleted
  • Possible ransomware infection modifying multiple files
  • Possible ransomware activity
  • Ransomware-linked emerging threat activity group detected

Advanced hunting queries

Microsoft Sentinel

To locate possible Hive ransomware activity mentioned in this blog post, Microsoft Sentinel customers can use the queries detailed below:

Identify Hive ransomware IOCs

This query identifies a match across various data feeds for IOCs related to Hive ransomware.

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/HiveRansomwareJuly2022.yaml

Identify backup deletion

This hunting query helps detect a ransomware’s attempt to delete backup files.

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/MultipleDataSources/BackupDeletion.yaml

Identify Microsoft Defender Antivirus detection of Hive ransomware

This query looks for Microsoft Defender Antivirus detections related to the Hive ransomware and joins the alert with other data sources to surface additional information such as device, IP, signed-in users, etc.

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SecurityAlert/HiveRansomwareAVHits.yaml

The post Hive ransomware gets upgrades in Rust appeared first on Microsoft Security Blog.