{
	"id": "0d7250e1-65b7-4507-aacd-7156571fa00d",
	"created_at": "2026-04-06T03:36:55.505996Z",
	"updated_at": "2026-04-10T13:12:48.156306Z",
	"deleted_at": null,
	"sha1_hash": "0542848e5c59717fed254896bf6477b12f2f9d1a",
	"title": "BlackByte Ransomware – Pt. 1 In-depth Analysis | Trustwave",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1986616,
	"plain_text": "BlackByte Ransomware – Pt. 1 In-depth Analysis | Trustwave\r\nBy Rodel Mendrez, Lloyd Macrohon\r\nPublished: 2021-10-15 · Archived: 2026-04-06 03:10:01 UTC\r\nPlease click here for Part 2\r\nUPDATE 19.October.2021 - Based on some reactions and responses to our BlackByte analysis, and specifically,\r\nthe included decryptor, we wanted to provide an update and some clarification.\r\nFirst off, we’ve updated the decryptor on github to include two new files. One is the compiled build of the\r\nexecutable to make the tool more accessible and the second is a sample encrypted file “spider.png.blackbyte” that\r\ncan be used to test the decryptor.\r\nThe decryptor takes a file (or files) encrypted by the ransomware as well as the raw encryption key in the fake\r\nimage file “forest.png”. For instance:\r\nBlackByteDecryptor forest.png spider.png.blackbyte \r\nIn the example the file “spider.png.blackbyte” has been encrypted by BlackByte. By using the key in “forest.png”,\r\nwe can decrypt the file and retrieve “spider.png”. At no time is the original encrypted file, “spider.png.blackbyte”, \r\nmodified.\r\nAs mentioned in the blog post, we know that “forest.png” was used as a key across multiple systems infected with\r\nBlackByte. Based on the retrieval of that key from a hardcoded web server (hxxp://45.9.148.114/forest.png), we\r\nbelieve that it’s likely that this key was reused across many, if not all, current victims.\r\nHowever, it’s certainly possible that the actors behind BlackByte might have changed that key file at some point.\r\nWhile it was taken down and no longer accessible, they may have used different “forest.png” files for different\r\nvictims.\r\nIn cases where the key might be different, the decryptor and key we provide here will not work to recover the\r\nvictim’s data. That said, it will also cause no harm or damage your data (at least not any further than it already was\r\nby BlackByte). When the victim attempts to run the decryptor as in the previous example:\r\nBlackByteDecryptor forest.png spider.png.blackbyte \r\nThe resulting recovered file “spider.png” will simply be garbage data as the incorrect key was used. Additionally,\r\nif the file “spider.png” already existed on the system for any reason, perhaps recovered from a backup, or copied\r\nfrom another system, the decryptor will exit out with the error:\r\nWarning: Target file spiderlabs.png exists. Not overwriting.\r\nThe important part here is that the original, encrypted file, “spider.png.blackbyte”, will still be on the system and\r\nunmodified. If the victim can access the correct key file originally used to encrypt their data, then recovery is still\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 1 of 23\n\npossible.\r\nThe key itself however is only downloaded to the victim system’s memory and not stored on disk. This means\r\nvictims would need to pull the key using memory dump tools on a fresh victim system. Because of this, and since\r\nwe believe that the key we spotted and archived is likely reused by many victims, we provide that key with the\r\ndecryptor in the hopes of helping those affected to recover.\r\nIntroduction\r\nDuring a recent malware incident response case, we encountered an interesting piece of ransomware that goes by\r\nthe name of BlackByte.\r\nWe thought that this ransomware was not only interesting but also quite odd:\r\n1. Same as other notorious ransomware variants like REvil, BlackByte also avoids systems with Russian and\r\nex-USSR languages.\r\n2. It has a worm functionality similar to RYUK ransomware.\r\n3. It creates a wake-on-LAN magic packet and sends it to the target host - making sure they are alive when\r\ninfecting them. \r\n4. The author hosted the encryption key in a remote HTTP server and in a hidden file with .PNG extension.\r\n5. The author lets the program crash if it fails to download the encryption key.\r\n6. The RSA public key embedded in the body is only used once, to encrypt the raw key to display in the\r\nransom note – that’s it.\r\n7. The ransomware uses only one symmetric key to encrypt the files.\r\nThe auction site that is linked in the ransom note is also quite odd, see below. The site claims that it has exfiltrated\r\ndata from its victims, but the ransomware itself does not have any exfiltration functionality. So this claim is\r\nprobably designed to scare their victims into complying.\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 2 of 23\n\nBlackByte's Onion site\r\nFile Decryption\r\nUnlike other ransomware that may have a unique key in each session, BlackByte uses the same raw key (which it\r\ndownloads) to encrypt files and it uses a symmetric-key algorithm – AES.  To decrypt a file, one only needs the\r\nraw key to be downloaded from the host. As long as the .PNG file it downloaded remains the same, we can use the\r\nsame key to decrypt the encrypted files.\r\nSo, we wrote a file decryptor that is available at this link: https://github.com/SpiderLabs/BlackByteDecryptor\r\nThe GitHub repository also includes the \"forest.png\" file that has the necessary encryption keys embedded in it.\r\nExample usage:\r\nDecrypting an encrypted file\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 3 of 23\n\nBlackByteDecryptor forest.png spider.png.blackbyte \r\nDecrypting a directory\r\nBlackByteDecryptor forest.png c:\\temp\r\nThis will decrypt files in the c:\\temp directory, or recursively decrypt a directory:\r\nBlackByteDecryptor forest.png c:\\temp -r\r\nLauncher\r\nThe initial sample we analyzed can be found at this VirusTotal link and is a JScript launcher file. Upon inspection,\r\nwe saw that it utilizes obfuscation techniques to hide its malicious nature. If you want to dig in further on the\r\nobfuscation details, and how we deobfuscated it, we posted a separate blog about this.  Below is an overview\r\ndiagram of the initial execution flow.\r\nFigure 1: JScript execution flow\r\nThe main function of the obfuscated Jscript is to decode the main payload and launch it in the memory. Below is\r\nthe de-obfuscated and the beautified code:\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 4 of 23\n\nFigure 2\r\nThe DLL Payload\r\nThe payload is a .NET DLL (managed code) that contains a class named jSfMMrZfotrr.\r\nFigure 3. DLL file .NET assemblies\r\nThe main purpose of this DLL is the following:\r\n1. Add .JS and .EXE file extensions into Microsoft Defender's exclusion list.\r\n2. Evade the Microsoft Antimalware Scan Interface (AMSI) DLL so that it will not scan the loaded malware\r\nand alert the user for suspicious activity .\r\n3. Check to see if the following DLLs are present:\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 5 of 23\n\n- SbieDll.dll (Sandboxie)         \r\n    - SxIn.dll (Qihoo360 Sandbox)\r\n    - Sf2.dll (Avast Antivirus)\r\n    - snxhk.dll (Avast)\r\n    - cmdvrt32.dll (Comodo Internet)\r\n4. Extract and decode the main payload (BlackByte ransomware) from the resources then execute it in the\r\nmemory.\r\nExtracting the main payload – BlackByte - didn’t come easy, as it turns out that the executable binary is\r\nencrypted.\r\nFigure 4. The Ransomware binary is tucked in the .NET assembly resource file named GOor.PVT5.\r\nTo make it easier and bypass analyzing the encryption and obfuscation layer, we simply let the JScript code run\r\nusing cscript command:\r\ncscript.exe \u003cmalicious JScript launcher\u003e\r\nThen we let the malicious .NET assembly run in memory. Afterward, we dumped all the .NET assemblies\r\nincluding the decrypted BlackByte .NET executable. We used a tool called MegaDumper to achieve this.\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 6 of 23\n\nFigure 5. By dumping the CSCRIPT.EXE that executes the malicious script, we can dump all the.NET assemblies\r\nrunning in its memory space.\r\nFigure 6: Once dumped, the decrypted .NET assemblies are saves in the drive and we can start analyzing them.\r\nBlackByte: Preparing the Infected System\r\nBefore encrypting, BlackByte first prepares the system so that nothing may hamper it from its file encryption\r\nroutine. During the initialization, the ransomware sets the value of essential fields such as the ransom notes, the\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 7 of 23\n\nencrypted file extension, cryptographic salt, OS name, among others. Victim identification is then generated by\r\ncombining the infected system’s processor ID and the volume serial number and hashing them with MD5. The\r\nransomware creates a mutex named Global\\1f07524d-fb13-4d5e-8e5c-c3373860df25 and terminates if that mutex\r\nname already exists.\r\nFigure 7\r\nAfterward, it checks if the system language locale is on its list of language codes – as shown below. If the system\r\ndefault language is on the list, BlackByte terminates:\r\nBCP 47 Code Language Language Code\r\nhy-AM Armenian (Armenia) 1067\r\naz-Cyrl-AZ Azeri (Cyrillic) - Azerbaijan 2092\r\nCy-az-AZ Azeri (Cyrillic) - Azerbaijan  \r\nLt-az-AZ Azeri (Latin) - Azerbaijan 1068\r\nbe-BY Belarusian - Belarus 1059\r\nkk-KZ Kazakh - Kazakhstan 1087\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 8 of 23\n\nky-KZ Kyrgyz - Kazakhstan  \r\nky-KZ Kyrgyz - Kazakhstan  \r\ntt-RU Tatar - Russia  \r\nba-RU Bashkir (Russia)  \r\nsah-RU Sakha (Russia)  \r\nru-RU Russian (Russia) 1049\r\ntg-Cyrl-TJ Tajik (Cyrillic, Tajikistan) 1064\r\nuz-Cyrl-UZ Uzbek (Cyrillic, Uzbekistan) 2115\r\n  Uzbek (Latin) 1091\r\nuk-UA Ukrainian (Ukraine) 1058\r\nka-GE Georgian (Georgia) 1079\r\n  Turkmen 1090\r\nThe ransomware also sets its process priority class to above normal and uses SetThreadExecutionState API to\r\nprevent the system from entering sleep. It then removes applications and terminates processes that can hinder the\r\nencryption of the target files. Below are the actions it does in the system:\r\nIt enumerates the registry key:\r\nHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\r\nAnd then deletes the following subkeys:\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 9 of 23\n\n1. vssadmin.exe\r\n2. wbadmin.exe\r\n3. bcdedit.exe\r\n4. powershell.exe\r\n5. diskshadow.exe\r\n6. net.exe\r\n7. taskkill.exe\r\n8. wmic.exe\r\nBlackByte terminates Raccine, an anti-ransomware utility, and uninstalls it from the infected system by running\r\nthe command:\r\ntaskill.exe /F /IM Raccine.exe\r\ntaskill.exe /F /IM RaccineSettings.exe\r\nschtasks.exe /DELETE /TN \\\"Raccine Rules Updater \\\" /F\r\nIt also deletes any Raccine related registry keys including:\r\nHKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\r\nName = “Raccine Tray”\r\nHKLM\\SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\Raccine\r\nIt runs a series of SC commands to disable a list of services:\r\nsc.exe config SQLTELEMETRY start = disabled\r\nsc.exe config sc SQLTELEMETRY$ECWDB2 start = disabled\r\nsc.exe config SQLWriter start = disabled\r\nsc.exe config SstpSvc start = disabled\r\nsc.exe config MBAMService start = disabled\r\nsc.exe config wuauserv start = disabled\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 10 of 23\n\nIt also enables the following services:\r\nDnscache fdPHost\r\nFDResPub SSDPSRV\r\nupnphost RemoteRegistry\r\nIt uses the Microsoft Restart Manager API RmShutdown to terminate the following processes:\r\nagntsvc CNTAoSMgr dbeng50 dbsnmp encsvc\r\nexcel firefox firefoxconfig infopath isqlplussvc\r\nmbamtray msaccess msftesql mspub mydesktopqos\r\nmydesktopservice mysqld mysqld-nt mysqld-opt Ntrtscan\r\nocautoupds ocomm ocssd onenote oracle\r\noutlook PccNTMon powerpnt sqbcoreservice sql\r\nsqlagent sqlbrowser sqlservr sqlwriter steam\r\nsynctime tbirdconfig thebat thebat64 thunderbird\r\ntmlisten visio winword wordpad xfssvccon\r\nzoolz anydesk chrome opera msedge\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 11 of 23\n\nfirefox iexplore explorer winlogon SearchIndexer\r\nwininit SearchApp SearchUI Powershell  \r\nThe following living-off-the-land commands are also executed to delete all shadow copies on all volumes, delete\r\nWindows restore points, disable controlled folder access, enable network discovery, grant \"everyone\" full access\r\nto target drives, delete the recycle bin, enable file and printer sharing, and enable SMB1 protocol.\r\nvssadmin.exe resize shadowstorage /for=c: /on=c: /maxsize=401MB\r\nvssadmin.exe resize shadowstorage /for=c: /on=c: /maxsize=unbounded\r\nvssadmin.exe resize shadowstorage /for=d: /on=d: /maxsize=401MB\r\nvssadmin.exe resize shadowstorage /for=d: /on=d: /maxsize=unbounded\r\nvssadmin.exe resize shadowstorage /for=e: /on=e: /maxsize=401MB\r\nvssadmin.exe resize shadowstorage /for=e: /on=e: /maxsize=unbounded\r\nvssadmin.exe resize shadowstorage /for=f: /on=f: /maxsize=401MB\r\nvssadmin.exe resize shadowstorage /for=f: /on=f: /maxsize=unbounded\r\nvssadmin.exe resize shadowstorage /for=g: /on=g: /maxsize=401MB\r\nvssadmin.exe vssadmin.exe resize shadowstorage /for=g: /on=g: /maxsize=unbounded\r\nvssadmin.exe resize shadowstorage /for=h: /on=h: /maxsize=401MB\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 12 of 23\n\nvssadmin.exe resize shadowstorage /for=h: /on=h: /maxsize=unbounded\r\nvssadmin.exe Delete Shadows /all /quiet\r\npowershell.exe Get-CimInstance Win32_ShadowCopy | Remove-CimInstance\r\npowershell.exe Set-MpPreference -EnableControlledFolderAccess Disabled\r\ncmd.exe /c rd /s /q %SYSTEMDRIVE%\\\\$Recycle.bin\r\ncmd.exe /c rd /s /q D:\\\\$Recycle.bin\r\nnetsh advfirewall firewall set rule group=\"Network Discovery” new enable=Yes\r\nnetsh advfirewall firewall set rule group=\"File and Printer Sharing\" new enable=Yes\r\npowershell.exe Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol\r\nicacls.exe\" \"\u003cDRIVE LETTER\u003e:*\" /grant Everyone:F /T /C /Q\r\nThe ransomware sets the following registry settings to elevate local privilege, connect mapped drives, enable long\r\npaths:\r\nHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\r\nLocalAccountTokenFilterPolicy = REG_DWORD:1\r\nEnableLinkedConnections = REG_DWORD:1\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\FileSystem\r\nLongPathsEnabled = REG_DWORD:1\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 13 of 23\n\nBlackByte uses the mountvol.exe command to mount volume names and leverage the Microsoft Discretionary\r\nAccess Control List tool – icacls.exe to grant the group to “Everyone” full access to the root of the drive.\r\nC:\\Windows\\System32\\icacls.exe\" \"{DRIVE LETTER}:*\" /grant Everyone:F /T /C /Q\r\nBlackByte: Worm\r\nThis ransomware also has a worm capability. It first checks if the file %AppData%\\\u003cGenerated Victim ID\u003e exists.\r\nIf this file does not exist, it means that the ransomware has not infected the network yet.\r\nFigure 8: Once dumped, the decrypted .NET assemblies are saved in the drive and we can start analyzing them.\r\nWhen the worm function is called, it initially sleeps for 10 seconds then queries at least 1,000 hostnames in the\r\ndomain from the active directory. \r\nFigure 9: To get all the computer names in the network, BlackByte attempts to retrieve the defaultNamingContext\r\nfrom RootDSE from the Active Directory server, then it filters objects in the Active Directory\r\nidentifying as computer and fetching a limit of up to 1,000 records.\r\nIt enumerates the returned record of hostnames, sends a wake-on-lan magic packet and then pings the target hosts\r\nmaking sure they are alive. Below is the worm routine and execution flow:\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 14 of 23\n\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 15 of 23\n\nFigure 10: Worm routine execution flow\r\nBlackByte then proceeds to infect the host by copying itself to the path \u003chostname\u003e\\c$\\Users\\Public\\obamka.js (if\r\nit has admin rights) or \u003chostname\u003e\\Users\\Public\\obamka.js and then creates a scheduled task in the remote host to\r\nexecute the file.\r\nschtasks.exe\u003cremotehost\u003e /TN joke /TR \\\"wscript.exe C:\\\\Users\\\\Public\\\\obamka.js\\\" /sc once /st\r\n00:00 /RL HIGHEST\r\nschtasks.exe /S \u003cremotehost\u003e /Run /TN joke\r\nBlackByte then creates an infection marker file in the target host in the path c:\\Users\\Public\\blockator.\r\nBlackByte: Encryption Routine\r\nWhat we found interesting about this ransomware, is that it initially downloads a .PNG file from the\r\nlink hxxp://45.9.148.114/forest.png which contains a key to be used later to encrypt the files. If the ransomware\r\nfails to download the key, it will crash and will save the infected system from getting its files encrypted.\r\nFigure 11: Fatal Exception Error when the ransomware failed to download the .png file\r\nThe file it downloaded is not actually a PNG image file, instead:\r\nThe first 40 bytes is the raw key used to encrypt the user's files, this is encrypted with 3DES.\r\nThe last 32 bytes contain the 3DES key used to decrypt the first 40 bytes raw key.\r\nThe raw key then goes through a PBKDF2 derivation function to derive the AES 128-bit key and\r\nInitialization Vector for the AES algorithm used to encrypt the user files.\r\nThis raw key is also re-encrypted using RSA with a public key embedded in the module and displayed in\r\nthe ransom note.\r\nThe attacker can decrypt this key using his private key, but this key is the same - provided the user always\r\ngets the same “forest.png” file. Presumably, the file forest.png is replaced periodically.\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 16 of 23\n\nThe first 40 bytes of the PNG file is a key (encrypted in TripleDES) used later for the ransomware’s file\r\nencryption.\r\nFigure 12: TripleDES encrypted key in the first 40 bytes of the file\r\nThe TripleDES key to decrypt the key is found in the last 32 bytes of the PNG file.\r\nFigure 13: The last 32 bytes of the PNG file as highlighted is the KEY to decrypt the TripleDES encrypted key\r\nBelow is the decrypted raw key:\r\n=hQ;d'%44eLHt!W8AU9y?(FO:\u003cswB[F#\u003cF\r\nThis raw key is then re-encrypted with RSA using a public key embedded in the module (shown below) and then\r\nafter the encryption, the key gets encoded with Base64.\r\n\u003c/RSAKeyValue\u003e\r\n\u003cModulus\u003e\r\nwKUX7pbo9XM/Z2gWbVADG8yV7ZklXOSRPv/KvtJHLIBUPvNWgjmKeiIgT3f5h\r\nCxaxqUzCi0QrrIhVIzA0WM+mPY9CLfIFLhq90v8H/+VezQtqeajO5J4ilDbqut9GH3x0ojVjC\r\ntF4/Q1Mxk125Af3D8IZQnXAw5uQ/uGXqP8e3E=\r\n\u003c/Modulus\u003e\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 17 of 23\n\n\u003cExponent\u003eAQAB\u003c/Exponent\u003e\r\n\u003c/RSAKeyValue\u003e\r\nThe encrypted raw key is replaced in the ransom note's key placeholder where it gets displayed.\r\nFigure 14: Ransomnote\r\nAfter downloading and decrypting the raw key, it will  derive the raw key using Rfc2898DeriveBytes\r\nimplementation with the salt byte-array { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08 } and with 1000\r\niterations\r\nFigure 15: Key derivation function\r\nThe graphic below will help visualize the encryption routine:\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 18 of 23\n\nFigure 16: Encryption Routine\r\nThe ransomware will then start enumerating the drives (excluding the CD-ROM drive) and add them to a list. It\r\nmakes sure it has full control of the target drives by changing its access control to full.\r\nAfter gathering all the drives (local and remote) and shared folders on the remote host, the ransomware will start\r\ntraversing it and searches for all the target files.\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 19 of 23\n\nFigure 17: BlackByte file traversal routine\r\nIt avoids encrypting files with a system file attribute, and also filenames and file extensions from this list:\r\nFilenames:\r\nobamka.js thumbs.db\r\nntdetect.com ntuser.dat.log\r\nbootnxt bootsect.bak\r\nntldr autoexec.bat\r\nRecycle.Bin iconcache.db\r\nbootmgr bootfont.bin\r\nFile extensions:\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 20 of 23\n\nmsilog log ldf lock theme\r\nmsi sys wpx cpl adv\r\nmsc scr key ico dll\r\nhta deskthemepack nomedia msu rtp\r\nmsp idx ani 386 diagcfg\r\nbin mod ics com hlp\r\nspl nls cab exe diagpkg\r\nicl ocx rom prf themepack\r\nmsstyles icns mpa drv cur\r\ndiagcab cmd shs    \r\nIf the ransomware encounters a virtual hard drive file extension .vhd and .vhdx, it will attempt to dismount these\r\ndrives using a PowerShell command:\r\npowershell.exe Dismount-DiskImage -ImagePath \u003cvhd path\u003e\r\nA target file to be encrypted undergoes file size filtering:\r\nIf the file is greater than 150MB\r\nencrypt the first 50MB and the last 50MB of the file\r\nIf the file is greater than 15MB\r\nencrypt the first 5MB and the last 5MB of the file\r\nIf the file is greater than 3MB\r\nencrypt the first 1MB and the last 1MB of the file\r\nIf the file is less than 3MB\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 21 of 23\n\nencrypt the whole file\r\nTo encrypt a file, it uses AES symmetric-key algorithm using the RFC2898 derived raw keys from the .png file.\r\nBelow is the code snippet of the file encryption routine.\r\nFigure 18: BlackByte's encryption routine\r\nIn BlackByte Ransomware – Part 2, we will show you how we de-obfuscated the JScript launcher, decompiled the\r\nransomware code, and analyzed more of its inner workings.\r\nIOCs\r\nFilename Description SHA256\r\nObamka.js\r\nJscript\r\nlauncher\r\n884e96a75dc568075e845ccac2d4b4ccec68017e6ef258c7c03da8c88a597534\r\nforest.png Key file 9bff421325bed6f1989d048edb4c9b1450f71d4cb519afc5c2c90af8517f56f3\r\nyk0pdddk\r\nBlackByte\r\nRansomware\r\nd3efaf6dbfd8b583babed67046faed28c6132eafe303173b4ae586a2ca7b1e90\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 22 of 23\n\nvylvz3le.dll\r\nBlackByte\r\nLoader\r\n92ffb5921e969a03981f2b6991fc85fe45e07089776a810b7dd7504ca61939a3\r\n2edpcniu.dll\r\nBlackByte\r\nLoader\r\nf8efe348ee2df7262ff855fb3984884b3f53e9a39a8662a6b5e843480a27bd93\r\nNetwork\r\n hxxp://45.9.148.114/forest.png\r\nSource: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nhttps://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/blackbyte-ransomware-pt-1-in-depth-analysis/"
	],
	"report_names": [
		"blackbyte-ransomware-pt-1-in-depth-analysis"
	],
	"threat_actors": [
		{
			"id": "4e453d66-9ecd-47d9-b63a-32fa5450f071",
			"created_at": "2024-06-19T02:03:08.077075Z",
			"updated_at": "2026-04-10T02:00:03.830523Z",
			"deleted_at": null,
			"main_name": "GOLD LOTUS",
			"aliases": [
				"BlackByte",
				"Hecamede "
			],
			"source_name": "Secureworks:GOLD LOTUS",
			"tools": [
				"BlackByte",
				"Cobalt Strike",
				"ExByte",
				"Mega",
				"RDP",
				"SoftPerfect Network Scanner"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "4e7fd07d-fcc5-459b-b678-45a7d9cda751",
			"created_at": "2025-04-23T02:00:55.174827Z",
			"updated_at": "2026-04-10T02:00:05.353712Z",
			"deleted_at": null,
			"main_name": "BlackByte",
			"aliases": [
				"BlackByte",
				"Hecamede"
			],
			"source_name": "MITRE:BlackByte",
			"tools": [
				"AdFind",
				"BlackByte Ransomware",
				"Exbyte",
				"Arp",
				"BlackByte 2.0 Ransomware",
				"PsExec",
				"Cobalt Strike",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775446615,
	"ts_updated_at": 1775826768,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0542848e5c59717fed254896bf6477b12f2f9d1a.pdf",
		"text": "https://archive.orkl.eu/0542848e5c59717fed254896bf6477b12f2f9d1a.txt",
		"img": "https://archive.orkl.eu/0542848e5c59717fed254896bf6477b12f2f9d1a.jpg"
	}
}