{
	"id": "bc2a623b-2493-4561-b4c7-05287282c468",
	"created_at": "2026-04-06T00:07:09.364862Z",
	"updated_at": "2026-04-10T03:26:55.199607Z",
	"deleted_at": null,
	"sha1_hash": "053544ab17d9c6901e4a852544434445b07b1396",
	"title": "Hive ransomware gets upgrades in Rust | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2157919,
	"plain_text": "Hive ransomware gets upgrades in Rust | Microsoft Security Blog\r\nBy Microsoft Threat Intelligence\r\nPublished: 2022-07-05 · Archived: 2026-04-05 20:19:29 UTC\r\nApril 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned\r\naround the theme of weather. DEV-0237 is now tracked as Pistachio Tempest.\r\nTo learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a\r\ncomplete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming\r\ntaxonomy.\r\nHive ransomware is only about one year old, having been first observed in June 2021, but it has grown into one of\r\nthe most prevalent ransomware payloads in the ransomware as a service (RaaS) ecosystem. With its latest variant\r\ncarrying several major upgrades, Hive also proves it’s one of the fastest evolving ransomware families,\r\nexemplifying the continuously changing ransomware ecosystem.\r\nThe upgrades in the latest variant are effectively an overhaul: the most notable changes include a full code\r\nmigration to another programming language and the use of a more complex encryption method. The impact of\r\nthese updates is far-reaching, considering that Hive is a RaaS payload that Microsoft has observed in attacks\r\nagainst organizations in the healthcare and software industries by large ransomware affiliates like DEV-0237.\r\nMicrosoft Threat Intelligence Center (MSTIC) discovered the new variant while analyzing detected Hive\r\nransomware techniques for dropping .key files. We know that Hive drops its encryption keys file, which contains\r\nencrypted keys used to decrypt encrypted files, and uses a consistent naming pattern:\r\n[KEY_NAME].key.[VICTIM_IDENTIFIER]\r\n(e.g., BiKtPupMjgyESaene0Ge5d0231uiKq1PFMFUEBNhAYv_.key.ab123)\r\nThe said .key files were missing the [VICTIM_IDENTIFIER] part of the file name, prompting deeper analysis of\r\nthe Hive ransomware that dropped them. This analysis led to the discovery of the new Hive variant and its\r\nmultiple versions, which exhibit slightly different available parameters in the command line and the executed\r\nprocesses.\r\nAnalyzing these patterns in samples of the new variants, we discovered even more samples, all with a low\r\ndetection rate and none being correctly identified as Hive. In this blog we will share our in-depth analysis of the\r\nnew Hive variant, including its main features and upgrades, with the aim of equipping analysts and defenders with\r\ninformation to better identify and protect organizations against malware attacks relying on Hive.\r\nAnalysis and key findings\r\nThe switch from GoLang to Rust\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 1 of 22\n\nThe main difference between the new Hive variant and old ones is the programming language used. The old\r\nvariants were written in Go (also referred to as GoLang), while the new Hive variant is written in Rust.\r\nHive isn’t the first ransomware written in Rust—BlackCat, another prevalent ransomware, was the first. By\r\nswitching the underlying code to Rust, Hive benefits from the following advantages that Rust has over other\r\nprogramming languages:\r\nIt offers memory, data type, and thread safety\r\nIt has deep control over low-level resources\r\nIt has a user-friendly syntax\r\nIt has several mechanisms for concurrency and parallelism, thus enabling fast and safe file encryption\r\nIt has a good variety of cryptographic libraries\r\nIt’s relatively more difficult to reverse-engineer\r\nString encryption\r\nThe new Hive variant uses string encryption that can make it more evasive. Strings reside in the .rdata section and\r\nare decrypted during runtime by XORing with constants. The constants that are used to decrypt the same string\r\nsometimes differ across samples, making them an unreliable basis for detection.\r\nFor example, let’s look at the section where part of the string “!error no flag -u \u003clogin\u003e:\u003cpassword\u003e provided”\r\nis decrypted. In one sample (SHA-256:\r\nf4a39820dbff47fa1b68f83f575bc98ed33858b02341c5c0464a49be4e6c76d3), the constants are 0x9F2E3F1F and\r\n0x95C9:\r\nFigure 1 – String decryption using constants 0x9F2E3F1F and 0x95C9\r\nIn another sample (SHA-256: 6e5d49f604730ef4c05cfe3f64a7790242e71b4ecf1dc5109d32e811acf0b053), the\r\nconstants are 0x3ECF7CC4 and 0x198F:        \r\nFigure 2 – String decryption using constants 0x3ECF7CC4 and 0x198F\r\nSome samples do share constants when decrypting the same string. For example, let’s look where the parameter\r\nstring “-da” is decrypted. In one sample (SHA-256:\r\n88b1d8a85bf9101bc336b01b9af4345ed91d3ec761554d167fe59f73af73f037), the constants are 0x71B4 and 2:\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 2 of 22\n\nFigure 3 – String decryption using constants 0x71B4 and 2\r\nIn another sample (SHA-256: 33744c420884adf582c46a4b74cbd9c145f2e15a036bb1e557e89d6fd428e724), the\r\nconstants are the same:\r\nFigure 4 – String decryption in a different sample also using constants 0x71B4 and 2\r\nCommand-line parameters\r\nIn old Hive variants, the username and the password used to access the Hive ransom payment website are\r\nembedded in the samples. In the new variant, these credentials must be supplied in the command line under the “-\r\nu” parameter, which means that they can’t be obtained by analysts from the sample itself.\r\nFigure 5 – Without a username and a password, the sample won’t continue its execution\r\nLike most modern ransomware, Hive introduces command-line parameters, which allow attackers flexibility when\r\nrunning the payload by adding or removing functionality. For example, an attacker can choose to encrypt files on\r\nremote shares or local files only or select the minimum file size for encryption. In the new Hive variant, we found\r\nthe following parameters across different samples:\r\nParameter Functionality\r\n-no-local Don’t encrypt local files\r\n-no-mounted Don’t encrypt files on mounted network shares\r\n-no-discovery\r\nDon’t discover network shares\r\n-local-only Encrypt only local files\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 3 of 22\n\n-network-only\r\nEncrypt only files on network shares\r\n-explicit-only\r\nEncrypt specific folder(s). For example, ‘-explicit-only c:\\mydocs c:\\myphotos’\r\n-min-size\r\nMinimum file size, in bytes, to encrypt. For example, ‘-min-size 102400’ will\r\nencrypt files with size equal or greater than 100kb\r\n-da [Usage is being analyzed.]\r\n-f [Usage is being analyzed.]\r\n-force [Usage is being analyzed.]\r\n-wmi [Usage is being analyzed.]\r\nOverall, it appears different versions have different parameters that are constantly updated. Unlike in previous\r\nvariants where there was a ‘help’ menu, in the new variant, the attacker must know the parameters beforehand.\r\nSince all strings are encrypted, it makes finding the parameters challenging for security researchers.\r\nStopped services and processes\r\nLike most sophisticated malware, Hive stops services and processes associated with security solutions and other\r\ntools that might get in the way of its attack chain. Hive tries to impersonate the process tokens of\r\ntrustedinstaller.exe and winlogon.exe so it can stop Microsoft Defender Antivirus, among other services.\r\nHive stops the following services:\r\nwindefend, msmpsvc, kavsvc, antivirservice, zhudongfungyu, vmm, vmwp, sql, sap, oracle, mepocs, veeam\r\nIt also stops the following processes:\r\ndbsnmp, dbeng50, bedbh, excel, encsvc, visios, firefox, isqlplussvc, mspub, mydesktopqos, notepad, oc\r\nLaunched processes\r\nAs part of its ransomware activity, Hive typically runs processes that delete backups and prevent recovery. There\r\nare differences between versions, and some samples may not execute all these processes, but one sample that\r\nstarts the most processes is SHA-256:\r\n481dc99903aa270d286f559b17194b1a25deca8a64a5ec4f13a066637900221e:\r\n“vssadmin.exe delete shadows /all /quiet”\r\n“wmic.exe shadowcopy delete”\r\n“wbadmin.exe delete systemstatebackup”\r\n“wbadmin.exe delete catalog -quiet”\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 4 of 22\n\n“bcdedit.exe /set {default} recoveryenabled No”\r\n“bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures”\r\n“wbadmin.exe delete systemstatebackup -keepVersions:3”\r\nRansom note\r\nHive’s ransom note has also changed, with the new version referencing the .key files with their new file name\r\nconvention and adding a sentence about virtual machines (VMs).\r\nThe older variants had an embedded username and password (marked as hidden). In the new variant, the username\r\nand password are taken from the command line parameter -u and are labeled test_hive_username and\r\ntest_hive_password.\r\nOld ransom note text:\r\n Your network has been breached and all data were encrypted.\r\nPersonal data, financial reports and important documents are ready to disclose.\r\n \r\nTo decrypt all the data and to prevent exfiltrated files to be disclosed at\r\nhttp://hive[REDACTED].onion/\r\nyou will need to purchase our decryption software.\r\n \r\nPlease contact our sales department at:\r\n \r\n http://hive[REDACTED].onion/\r\n \r\n Login: [REDACTED]\r\n Password: [REDACTED]\r\n \r\nTo get an access to .onion websites download and install Tor Browser at:\r\n https://www.torproject.org/ (Tor Browser is not related to us)\r\n \r\n \r\nFollow the guidelines below to avoid losing your data:\r\n \r\n- Do not modify, rename or delete *.key.abc12 files. Your data will be\r\n undecryptable.\r\n- Do not modify or rename encrypted files. You will lose them.\r\n- Do not report to the Police, FBI, etc. They don't care about your business.\r\n They simply won't allow you to pay. As a result you will lose everything.\r\n- Do not hire a recovery company. They can't decrypt without the key.\r\n They also don't care about your business. They believe that they are\r\n good negotiators, but it is not. They usually fail. So speak for yourself.\r\n- Do not reject to purchase. Exfiltrated files will be publicly disclosed.\r\nNew ransom note text:\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 5 of 22\n\nYour network has been breached and all data were encrypted.\r\nPersonal data, financial reports and important documents are ready to disclose.\r\n \r\nTo decrypt all the data and to prevent exfiltrated files to be disclosed at\r\nhttp://hive[REDACTED].onion/\r\nyou will need to purchase our decryption software.\r\n \r\nPlease contact our sales department at:\r\n \r\n http://hive[REDACTED].onion/\r\n \r\n Login: test_hive_username\r\n Password: test_hive_password\r\n \r\nTo get an access to .onion websites download and install Tor Browser at:\r\n https://www.torproject.org/ (Tor Browser is not related to us)\r\n \r\n \r\nFollow the guidelines below to avoid losing your data:\r\n \r\n- Do not delete or reinstall VMs. There will be nothing to decrypt.\r\n- Do not modify, rename or delete *.key files. Your data will be\r\n undecryptable.\r\n- Do not modify or rename encrypted files. You will lose them.\r\n- Do not report to the Police, FBI, etc. They don't care about your business.\r\n They simply won't allow you to pay. As a result you will lose everything.\r\n- Do not hire a recovery company. They can't decrypt without the key.\r\n They also don't care about your business. They believe that they are\r\n good negotiators, but it is not. They usually fail. So speak for yourself.\r\n- Do not reject to purchase. Exfiltrated files will be publicly disclosed.\r\nEncryption\r\nThe most interesting change in the Hive variant is its cryptography mechanism. The new variant was first\r\nuploaded to VirusTotal on February 21, 2022, just a few days after a group of researchers from Kookmin\r\nUniversity in South Korea published the paper “A Method for Decrypting Data Infected with Hive Ransomware”\r\non February 17, 2022. After a certain period of development, the new variant first appeared in Microsoft threat\r\ndata on February 22.\r\nThe new variant uses a different set of algorithms: Elliptic Curve Diffie-Hellmann (ECDH) with Curve25519\r\nand XChaCha20-Poly1305 (authenticated encryption with ChaCha20 symmetric cipher).\r\nA unique encryption approach\r\nThe new Hive variant uses a unique approach to file encryption. Instead of embedding an encrypted key in each\r\nfile that it encrypts, it generates two sets of keys in memory, uses them to encrypt files, and then encrypts and\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 6 of 22\n\nwrites the sets to the root of the drive it encrypts, both with .key extension.\r\nTo indicate which keys set was used to encrypt a file, the name of the .key file containing the corresponding\r\nencryption keys is added to the name of the encrypted file on disk, followed by an underscore and then a Base64\r\nstring (also adding underscore and hyphen to the character set). Once it’s Base64-decoded, the string contains two\r\noffsets, with each offset pointing to a different location in the corresponding .key file. This way, the attacker can\r\ndecrypt the file using these offsets.\r\nFor example, after running Hive, we got the following files dropped to the C:\\ drive:\r\nC:\\3bcVwj6j.key\r\nC:\\l0Zn68cb.key\r\nIn this example, a file named myphoto.jpg would be renamed to C:\\myphoto.jpg.l0Zn68cb _ -B82BhIaGhI8. As\r\nwe discuss in the following sections, the new variant’s keys set generation is entirely different from old variants.\r\nHowever, its actual file encryption is very similar.\r\nKeys set generation\r\nA buffer of size 0xCFFF00 bytes is allocated. Using two custom functions to generate random bytes (labeled\r\n“random_num_gen” and “random_num_gen_2” for demonstration purposes) the buffer is filled. The first\r\n0xA00000 bytes of this buffer are filled with random bytes and the remaining 0x2FFF00 bytes are simply copied\r\nfrom the first 0x2FFF00 random bytes that were copied earlier to the buffer.\r\nThe content of each buffer is a keys set (a collection of symmetric keys). Since two buffers are allocated, there are\r\ntwo keys sets. In the encryption process, the malware randomly selects different keys (byte sequences) for each\r\nfile from one of the keys set and uses them to encrypt the file by XORing the byte sequence of the keys with the\r\nfile’s content.\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 7 of 22\n\nFigure 6 – Original keys set generation\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 8 of 22\n\nFigure 7 – Inside get_random_byte\r\nA custom 64-byte hash is prepared for each keys set. This hash will be used later.\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 9 of 22\n\nFigure 8 – Preparing the custom hash of the keys set\r\nAfter the hash is computed and several other strings are decrypted, the encryption process takes the following\r\nsteps:\r\n1. Generate victim_private_key using the same functions introduced above.\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 10 of 22\n\nFigure 9 – Generating victim_private_key\r\n2. Generate victim_public_key using ECDH with Curve25519. The input is victim_private_key and the\r\nbasepoint is 9 followed by 31 zeros (embedded in the sample).\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 11 of 22\n\nFigure 10 – Generating victim_public_key\r\n3. Generate a 24-byte nonce for the XChaCha algorithm, later in Poly1305-XChaCha20.\r\nFigure 11 – Generating a 24-byte nonce\r\n4. Generate shared_secret using ECDH with Curve25519. The input is victim_private_key and\r\nhive_public_key. Then, the  shared_secret (as a key) with hive_public_key (as a nonce) is used to derive the\r\nderived_key using ChaCha20.\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 12 of 22\n\nFigure 12 – Generating shared_secret\r\n5. Encrypt the keys set using Poly1305-XChaCha20. The values used for the encryption are the keys set,\r\nderived_key, nonce, and the embedded associated data (AD). This function encrypts the keys set and adds a\r\n16-byte authentication tag at the end of the buffer of the encrypted keys. It’s unclear if the authentication\r\ntag is ever checked.\r\nFigure 13 – Encrypting the keys set\r\nNow that the keys set is finally encrypted, the nonce, victim_public_key, the now-encrypted keys set, and the\r\nauthentication tag are copied to a new buffer, one after another. This buffer (which we label\r\nencrypted_structure_1) is treated as a new keys set, which is again encrypted using the same method described\r\nabove but with a second hive_public_key. This time, the function outputs new nonce, victim_private_key, and\r\nothers. Only the associated data is the same.\r\nFinally, the new buffer, which contains the second_nonce, second_victim_public_key, and the\r\nencryptedencrypted_structure_1, is written to the root of the drive it’s encrypting (for example, C:\\). The\r\ncreate_extension function generates a Base64 string based on the first six bytes of the custom hash that was\r\ncreated earlier. This Base64 string serves as the file name, and the extension of the file is simply “.key”.\r\nFigure 14 – Generating a Base64 string based on the first six bytes of the custom hash\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 13 of 22\n\nFigure 15 – Using the Base64 string as the file name\r\nThe diagram below illustrates the encryption scheme described above:\r\nFigure 16 – The keys set encryption scheme of the new Hive variant\r\nAs seen in the diagram above, “Keys sets encryption flow” is executed twice. In the first round it is executed with\r\nthe original keys set as an input. In the second round it is executed with the “encrypted structure 1” as an input. In\r\nits second execution, all other input values are different except the AD (associated data) and the Basepoint 9.\r\nHence, the following values are new in the second execution: victim_private_key, victim_public_key,\r\nhive_public_key, nonce, shared_secret and derived_key.\r\nFile encryption\r\nAfter both keys files are written to the disk, the multi-threaded file encryption starts. Before encrypting each file,\r\nthe malware checks its name and extension against a list of strings. If there is a match, then the file will not be\r\nencrypted. For example, a file with .exe extension will not be encrypted if .exe is in the list of strings. It should be\r\nnoted that this list is encrypted and decrypted during runtime.\r\nThe same file encryption method seen in old variants is used in the new one: two random numbers are generated\r\nand used as offsets to the keys set. Each offset is four bytes:\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 14 of 22\n\nFigure 17 – Generating the offsets\r\nFor the encryption, the file’s content is XORed with bytes from the keys set, according to the offsets. The file\r\nbytes are XORed twice—once according to the first offset and a second time according to the second offset. Files\r\nare encrypted in blocks of 0x100000 bytes, with the maximum number of blocks at 100. There is an interval\r\nbetween the encrypted blocks as defined by block_space. After the encryption is finished in memory, the\r\nencrypted data is written to the disk, overwriting the original file.\r\nFigure 18 – Calculation of number of blocks\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 15 of 22\n\nFigure 19 – Actual encryption of the file bytes\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 16 of 22\n\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 17 of 22\n\nFigure 20 – Reading a file, encrypting it, and writing it back to the disk\r\nLooking at when create_extension is called once file encryption has started, we recognized a similar structure in\r\nthe previous variant:\r\nFigure 21 – Creating the extension for the file\r\nLet 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\r\nbefore create_extension is called on a file called EDBtmp.log\r\nRecall that in the older variants, 0xFF was used as a delimiter to separate the key file name from the offset values.\r\nWe can also see it here. Converting the first six bytes (72 D7 A7 A3 F5 5B) to Base64 yields the following:\r\ncteno/Vb\r\nAnd if we step over create_extension, the result is similar—we get cteno_Vb as the .key file name (note: Since\r\nHive uses a different Base64 character set, “/” was replaced with “_”):\r\nMicrosoft will continue to monitor the Hive operators’ activity and implement protections for our customers. The\r\ncurrent detections, advanced detections, and indicators of compromise (IOCs) in place across our security\r\nproducts are detailed below.\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 18 of 22\n\nRecommended customer actions\r\nThe techniques used by the new Hive variant can be mitigated by adopting the security considerations provided\r\nbelow:\r\nUse the included IOCs to investigate whether they exist in your environment and assess for potential\r\nintrusion.\r\nOur recent blog on the ransomware as a service economy has an exhaustive guide on how to protect yourself from\r\nransomware threats that dive deep into each of the following areas. We encourage readers to refer to that blog for a\r\ncomprehensive guide on:\r\nBuilding credential hygiene\r\nAuditing credential exposure\r\nPrioritizing deployment of Active Directory updates\r\nCloud hardening\r\nImplement the Azure Security Benchmark and general best practices for securing identity\r\ninfrastructure.\r\nEnsure cloud admins/tenant admins are treated with the same level of security and credential\r\nhygiene as Domain Admins.\r\nAddress gaps in authentication coverage.\r\nEnforce MFA on all accounts, remove users excluded from MFA, and strictly require MFA from all\r\ndevices, in all locations, at all times.\r\nEnable passwordless authentication methods (for example, Windows Hello, FIDO keys, or Microsoft\r\nAuthenticator) for accounts that support passwordless. For accounts that still require passwords, use\r\nauthenticator apps like Microsoft Authenticator for MFA.\r\nDisable legacy authentication.\r\nFor Microsoft 365 Defender customers, the following checklist eliminates security blind spots:\r\nTurn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker\r\ntools and techniques, block new and unknown malware variants, and enhance attack surface reduction rules\r\nand tamper protection.\r\nTurn on tamper protection features to prevent attackers from stopping security services.\r\nRun EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when\r\na non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in\r\npassive mode. EDR in block mode also blocks indicators identified proactively by Microsoft Threat\r\nIntelligence teams.\r\nEnable network protection to prevent applications or users from accessing malicious domains and other\r\nmalicious content on the internet.\r\nEnable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to\r\ntake immediate action on alerts to resolve breaches.\r\nUse device discovery to increase visibility into the network by finding unmanaged devices and onboarding\r\nthem to Microsoft Defender for Endpoint.\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 19 of 22\n\nProtect user identities and credentials using Microsoft Defender for Identity, a cloud-based security\r\nsolution that leverages on-premises Active Directory signals to monitor and analyze user behavior to\r\nidentify suspicious user activities, configuration issues, and active attacks.\r\nIndicators of compromise (IOCs)\r\nThe below list provides a partial list of the IOCs observed during our investigation and included in this blog. We\r\nencourage our customers to investigate these indicators in their environments and implement detections and\r\nprotections to identify past related activity and prevent future attacks against their systems.\r\nIndicator Type Description\r\nf4a39820dbff47fa1b68f83f575bc98ed33858b02341c5c0464a49be4e6c76d3\r\nSHA-256\r\nHive Rust\r\nvariant\r\npayload\r\n88b1d8a85bf9101bc336b01b9af4345ed91d3ec761554d167fe59f73af73f037\r\nSHA-256\r\nHive Rust\r\nvariant\r\npayload\r\n065208b037a2691eb75a14f97bdbd9914122655d42f6249d2cca419a1e4ba6f1\r\nSHA-256\r\nHive Rust\r\nvariant\r\npayload\r\n33744c420884adf582c46a4b74cbd9c145f2e15a036bb1e557e89d6fd428e724\r\nSHA-256\r\nHive Rust\r\nvariant\r\npayload\r\nafab34235b7f170150f180c7afb9e3b4e504a84559bbd03ab71e64e3b6541149\r\nSHA-256\r\nHive Rust\r\nvariant\r\npayload\r\n36759cab7043cd7561ac6c3968832b30c9a442eff4d536e901d4ff70aef4d32d\r\nSHA-256\r\nHive Rust\r\nvariant\r\npayload\r\n481dc99903aa270d286f559b17194b1a25deca8a64a5ec4f13a066637900221e\r\nSHA-256\r\nHive Rust\r\nvariant\r\npayload\r\n6e5d49f604730ef4c05cfe3f64a7790242e71b4ecf1dc5109d32e811acf0b053\r\nSHA-256\r\nHive Rust\r\nvariant\r\npayload\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 20 of 22\n\n32ff0e5d87ec16544b6ff936d6fd58023925c3bdabaf962c492f6b078cb01914\r\nSHA-256\r\nHive Rust\r\nvariant\r\npayload\r\nNOTE: These indicators shouldn’t be considered exhaustive for this observed activity.\r\nDetections\r\nMicrosoft 365 Defender\r\nMicrosoft Defender Antivirus\r\nMicrosoft Defender Antivirus provides detection for this threat under the following family names with build\r\nversion 1.367.405.0 or later.\r\nRansom:Win64/Hive\r\nRansom:Win32/Hive\r\nMicrosoft Defender for Endpoint detection\r\nMicrosoft Defender for Endpoint customers may see any or a combination of the following alerts as an indication\r\nof possible attack. These alerts are not necessarily an indication of a Hive compromise, but should be investigated:\r\nRansomware behavior detected in the file system\r\nFile backups were deleted\r\nPossible ransomware infection modifying multiple files\r\nPossible ransomware activity\r\nRansomware-linked emerging threat activity group detected\r\nAdvanced hunting queries\r\nMicrosoft Sentinel\r\nTo locate possible Hive ransomware activity mentioned in this blog post, Microsoft Sentinel customers can use the\r\nqueries detailed below:\r\nIdentify Hive ransomware IOCs\r\nThis query identifies a match across various data feeds for IOCs related to Hive ransomware.\r\nhttps://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/HiveRansomwareJuly2022.yaml\r\nIdentify backup deletion\r\nThis hunting query helps detect a ransomware’s attempt to delete backup files.\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 21 of 22\n\nhttps://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/MultipleDataSources/BackupDeletion.yaml\r\nIdentify Microsoft Defender Antivirus detection of Hive ransomware\r\nThis query looks for Microsoft Defender Antivirus detections related to the Hive ransomware and joins the alert\r\nwith other data sources to surface additional information such as device, IP, signed-in users, etc.\r\nhttps://github.com/Azure/Azure-Sentinel/blob/master/Detections/SecurityAlert/HiveRansomwareAVHits.yaml\r\nSource: https://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nhttps://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/\r\nPage 22 of 22",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/"
	],
	"report_names": [
		"hive-ransomware-gets-upgrades-in-rust"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f6f91e1c-9202-4497-bf22-9cd5ef477600",
			"created_at": "2023-01-06T13:46:38.86765Z",
			"updated_at": "2026-04-10T02:00:03.12735Z",
			"deleted_at": null,
			"main_name": "WIZARD SPIDER",
			"aliases": [
				"TEMP.MixMaster",
				"GOLD BLACKBURN",
				"DEV-0193",
				"UNC2053",
				"Pistachio Tempest",
				"DEV-0237",
				"Storm-0230",
				"FIN12",
				"Periwinkle Tempest",
				"Storm-0193",
				"Trickbot LLC"
			],
			"source_name": "MISPGALAXY:WIZARD SPIDER",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434029,
	"ts_updated_at": 1775791615,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/053544ab17d9c6901e4a852544434445b07b1396.pdf",
		"text": "https://archive.orkl.eu/053544ab17d9c6901e4a852544434445b07b1396.txt",
		"img": "https://archive.orkl.eu/053544ab17d9c6901e4a852544434445b07b1396.jpg"
	}
}