{ "id": "85c65032-4f3f-454a-acfa-247e8690b64b", "created_at": "2026-04-06T00:06:33.892497Z", "updated_at": "2026-04-10T03:36:13.717019Z", "deleted_at": null, "sha1_hash": "01d1c86d064e1e13a115b3fe84938ddc56fe75bf", "title": "Rook Ransomware", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1971409, "plain_text": "Rook Ransomware\r\nBy Chuong Dong\r\nPublished: 2022-01-06 · Archived: 2026-04-05 20:23:15 UTC\r\nReverse Engineering  · 06 Jan 2022\r\nContents\r\nRook Ransomware\r\nContents\r\nOverview\r\nIOCS\r\nRansom Note\r\nStatic Code Analysis\r\nRSA Key Generation\r\nAnti-Detection: Alternate Data Streams\r\nCommand-line Arguments\r\nLogging\r\nStopping Services\r\nTerminating Processes\r\nDeleting Shadow Copies\r\nMultithreading Setup\r\nNetwork Resource Traversal\r\nDrives Traversal\r\nShares Traversal\r\nChild Thread\r\nFile Encryption\r\nReferences\r\nOverview\r\nThis is my analysis for ROOK Ransomware.\r\nROOK is a relatively new ransomware that has been coming up in the last few months. With the Mbed TLS\r\nlibrary, the malware uses a hybrid cryptography scheme to encrypt files using AES and protect its keys with RSA-2048.\r\nFor execution speed, ROOK is quite fast since it uses a decently good method of multithreading with two global\r\nlists for file and directory traversal.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 1 of 35\n\nAs it has been claimed by other researchers, ROOK borrows some of the code from the leaked BABUK source\r\ncode. To be more specific, the ROOK developers copied and pasted the code for services \u0026 processes termination\r\nas well as deleting shadow copies. ROOK’s multithreading approach is a reimplementation and an upgrade from\r\nthat of BABUK version 3, which is now more efficient for directory traversal.\r\nHowever, unlike BABUK devs who are big fans of using ECDH curves and eSTREAM portfolio Profile 1 ciphers\r\nsuch as ChaCha and HC-128 for hybrid-encryption, ROOK devs stick with the traditional choice of RSA and\r\nAES.\r\nFigure 1: ROOK Leak Site.\r\nIOCS\r\nThe analyzed sample is a 64-bit Windows executable.\r\nMD5: 6d87be9212a1a0e92e58e1ed94c589f9\r\nSHA256: c2d46d256b8f9490c9599eea11ecef19fde7d4fdd2dea93604cee3cea8e172ac\r\nSample: MalwareBazaar\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 2 of 35\n\nFigure 2: VirusTotal Result.\r\nRansom Note\r\nThe content of the default ransom note is stored in plaintext in ROOK’s executable.\r\nROOK’s ransom note filename is “HowToRestoreYourFiles.txt”, which is really similar to BABUK’s “How To\r\nRestore Your Files.txt”.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 3 of 35\n\nFigure 3: ROOK’s Ransom Note.\r\nStatic Code Analysis\r\nRSA Key Generation\r\nThe first thing ROOK does upon execution is setting up the RSA keys for asymmetric encryption.\r\nFirst, the malware initializes a CTR_DRBG context using the Mbed TLS library, which is used to build a pseudo-RNG to later randomly generate AES keys.\r\nFigure 4: CTR_DRBG Initialization.\r\nNext, it calls mbedtls_pk_parse_public_key to parse the TA’s RSA public key into a mbedtls_pk_context struct.\r\nThe ROOK’s public key context is then extracted from the pk_ctx field on the newly populated\r\nmbedtls_pk_context struct.\r\nBelow is the raw content of the public key.\r\n-----BEGIN PUBLIC KEY-----\r\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4g06WvN+BRr9GeeOkZ4y\r\nnnK1uHreCPZyEsc43g3ftVXqsq2Kbdy7Z+XORqxmBi8D5nhDfw3eHRzH8wpcUos3\r\nszWKyJLOeKhN6DM5M4FppD8hyuKDTcgsa70Nhapc1Oyjfh3kf3Kc/2CUhnPYEzHe\r\nfHN3yOq9wxOVGc1S+bcTM3ez8gRuv0fB9ao2bJM0pKJphYq5dNkT0p2Ty923n+yZ\r\nAOKELIWwwyOQgyfiv8ZwkdPL+UbNQq2dYZEWa1qSsGgN2655hvvD/pH/bggAFEqm\r\nOybQFnRcdG9Fja9m/ZVp7jBYuX+4FaFq3DjD0oW/7imboVsEqcx7l7ym4tiKCz57\r\nMwIDAQAB\r\n-----END PUBLIC KEY-----\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 4 of 35\n\nFigure 5: Parsing ROOK’s RSA Public Key.\r\nROOK then calls RegCreateKeyExW to open the subkey Software in HKEY_CURRENT_USER. Using that,\r\nit calls RegQueryValueExW to check if the registry value RookPublicKey exists in there. If it does not, the\r\nmalware generates a public-private key pair for the victim.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 5 of 35\n\nFigure 6, 7: Querying From Registry \u0026 Generating Victim Public-Private Key Pair.\r\nNext, ROOK encrypts the victim’s RSA private key using its own public key context.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 6 of 35\n\nFigure 8: Encrypting Victim Private Key Using TA’s Public Key.\r\nThe victim’s public key and encrypted private key are consecutively stored in the registry at the value\r\nRookPublicKey and RookPrivateKey.\r\nIf the victim’s public key was already generated before and the malware can query it directly from registry, the\r\nvictim’s encrypted private key is pulled from the registry value RookPrivateKey.\r\nFinally, the malware calls mbedtls_pk_parse_public_key to retrieve the victim’s public key context and wipes\r\nthe victim’s raw private key from memory.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 7 of 35\n\nFigure 9: Writing Keys to Registry \u0026 Cleaning Up.\r\nAnti-Detection: Alternate Data Streams\r\nAlternate Data Streams (ADS) is a file attribute on the NT File System (NTFS) which was designed for\r\ncompatibility with Macintosh Hierarchical File System (HFS).\r\nFor normal files, there is typically one primary data stream that is known as the unnamed data stream since its\r\nname is an empty string. However, ADS allows files to have more than one data stream, with any stream with a\r\nname being considered alternate.\r\nBecause alternate data streams are hidden from Windows Explorer and the dir command on the command-line,\r\nthey are a sneaky way to hide external executable from a seemingly harmless file.\r\nTo evade detection, ROOK uses ADS to hides its own executable. First, it calls GetModuleFileNameW with a\r\nNULL handle to retrieve its own executable path.\r\nIt then calls CreateFileW to retrieve its own handle and SetFileInformationByHandle to rename the file with a\r\ndata stream named “:ask”. This ultimately puts the entire executable into the alternate “:ask” data stream, leaving\r\nan empty file on the primary stream.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 8 of 35\n\nFigure 10: Moving Executable to Data Stream.\r\nPausing the execution after the handle is released using the call to CloseHandle, we can examine how it looks in\r\nthe system.\r\nBy running the command “dir /r”, we can examine what changes to the executable file.\r\nTo test this, I use two copies of the ROOK sample and have the ro0k.mal_ one hide itself in the “:ask” data\r\nstream. As we can see in the command-line, that file shows up empty, but its alternate data stream contains the full\r\nmalicious executable.\r\nFigure 11: Examining Alternate Data Stream In Command-Line.\r\nAfter doing this, the ransomware file will appear as empty in the file system until the end of execution.\r\nAfter hiding itself, ROOK also calls SetFileInformationByHandle again to set the file to be deleted once all\r\nhandles are closed at the end.\r\nFigure 12: Set Up File for Self-Deletion.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 9 of 35\n\nCommand-line Arguments\r\nROOK can run with or without command-line arguments.\r\nBelow is the list of arguments that can be supplied by the operator.\r\nArgument Description\r\n-debug \u003clog_filename\u003e Enable logging to the specified log file\r\n-shares \u003cshare_list\u003e List of network shares to be traversed\r\n-paths \u003cdrive_list\u003e List of local \u0026 network drives to be traversed\r\nLogging\r\nWhen the debug argument is provided on the command-line, ROOK enables debugging and calls CreateFileW\r\nto create the log file to later log into.\r\nIt also calls InitializeCriticalSection to initialize a critical section to prevent multiple threads from writing into\r\nthe log file at the same time.\r\nFigure 13: Logging Initialization.\r\nStopping Services\r\nFor stopping services, ROOK borrows this part from the leaked BABUK source code.\r\nThe malware first calls GetTickCount to get a tick count prior to stopping services. It then calls\r\nOpenSCManagerA to retrieve a service control manager handle.\r\nFigure 14: Retrieving Service Control Manager.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 10 of 35\n\nNext, it iterates through a hard-coded list containing services to be stopped. For each of these service, the malware\r\ncalls OpenServiceA to retrieve the service’s handle and QueryServiceStatusEx to query and checks if the\r\nservice state is SERVICE_STOP_PENDING.\r\nIf it is not, ROOK calls EnumDependentServicesA to enumerate through all dependent services of the target\r\nservice and stop them.\r\nFigure 15: Iterating Through Service Stop List.\r\nFor each dependent service, the malware calls OpenServiceA to retrieve its handle and ControlService to send a\r\ncontrol stop code to stop it. It also sleeps and calls QueryServiceStatusEx to wait until the service’s state is fully\r\nstopped.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 11 of 35\n\nFigure 16: Stopping Dependent Services.\r\nAfter stopping all dependent services, ROOK calls ControlService send a control stop code to the main service\r\nand continuosly checks until the service is fully stopped.\r\nFigure 17: Stopping Target Services.\r\nFor stopping all services, the maximum timeout is 30000ms or 30 seconds from the original tick count. If it takes\r\nmore than 30 seconds to stop services, the malware aborts and exits the function.\r\nBelow is the list of services that are stopped.\r\n\"memtas\", \"mepocs\", \"vss\", \"sql\", \"svc$\", \"veeam\", \"backup\", \"GxVss\", \"GxBlr\", \"GxFWD\", \"GxCVD\", \"GxCIMgr\", \"De\r\nTerminating Processes\r\nThis part of code is also copied and pasted from the BABUK source code.\r\nROOK calls CreateToolhelp32Snapshot to retrieve a snapshot of all processes and threads in the system. It then\r\ncalls Process32FirstW and Process32NextW to enumerate through the snapshot.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 12 of 35\n\nFor each process whose name is in the list of processes to be terminated, the malware calls OpenProcess to\r\nretrieve the process’s handle and TerminateProcess to terminate it.\r\nFigure 18: Stopping Target Services.\r\nBelow is the list of processes that are stopped.\r\n\"sql.exe\", \"oracle.exe\", \"ocssd.exe\", \"dbsnmp.exe\", \"visio.exe\", \"winword.exe\", \"wordpad.exe\", \"notepad.exe\", \"\r\nDeleting Shadow Copies\r\nThis part of code is also copied and pasted from the BABUK source code.\r\nROOK first checks if its process is running under a 64-bit processor by calling IsWow64Process.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 13 of 35\n\nFigure 19: Checking Process Architecture.\r\nIf it is, the malware calls Wow64DisableWow64FsRedirection to disable file system redirection for its process.\r\nThen it executes ShellExecuteW to launch the following command in the command line to delete all shadow\r\ncopies in the system.\r\nvssadmin.exe delete shadows /all /quiet\r\nFinally, if the malware’s process is running under a 64-bit architecture, it calls\r\nWow64RevertWow64FsRedirection to enable file system redirection.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 14 of 35\n\nFigure 20: Deleting Shadow Copies.\r\nMultithreading Setup\r\nPrior to encrypting files, ROOK sets up its own multithreading system.\r\nInitially, it calls GetSystemInfo to retrieve the number of processors in the system.\r\nThe multithreading structure is divided into two parts: file encryption and directory enumeration.\r\nFor file encryption, the malware calculates the maximum number of files to be encrypted by multiple threads at\r\nthe same time is 24 times the number of processors. It then calls HeapAlloc to allocate a global array to store the\r\nfiles that are set to be encrypted and CreateSemaphoreA to create 2 semaphores that are used for synchronization\r\namong threads that access the file array. Finally, it also calls InitializeCriticalSection to initialize a critical\r\nsection that allows one thread to add or remove a file from the global array at a time.\r\nFigure 21: Threading Setup for File Encryption.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 15 of 35\n\nFor directory enumeration, the malware calculates the maximum number of directories to be enumerated by\r\nmultiple threads at the same time is 6 times the number of processors. It also creates a global array, 2 semaphores,\r\nand a critical section like to the file encryption part above.\r\nFigure 22: Threading Setup for Directory Enumeration.\r\nNext, the malware calls HeapAlloc to allocate two arrays to store child thread handles, one for file encryption and\r\nthe other for directory enumeration.\r\nROOK then calls CreateThread to spawn threads for double the number of processors for each thread array. The\r\nfunctionalities of these threads are later discussed in the Child Thread section.\r\nFigure 23: Spawning Child Threads.\r\nNetwork Resource Traversal\r\nWhen the command-line argument “-paths” or “-shares” is not provided, ROOK recursively traverses through\r\nall resources in the network.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 16 of 35\n\nThe malware calls WNetOpenEnumW to retrieve an enumeration handle for all network resources and\r\nWNetEnumResourceW to enumerate through them.\r\nFor each network resource, if it’s a container for other resources that can also be enumerated, ROOK recursively\r\npasses it back to the current function to traverse it.\r\nIf the resource is just a normal and connectable directory, the malware passes it into a recursive function to\r\ntraverse it, which will be discussed in the Drives Traversal section.\r\nFigure 24: Traversing Network Resources.\r\nDrives Traversal\r\nWhen the command-line argument “-paths” is provided, ROOK specifically enumerates them and exits upon\r\ncompletion.\r\nThe argument can come in the form of a list of paths, each separated by a comma. Instead of a normal directory\r\npath, ROOK also accepts a two-character string of a drive letter followed by a colon as a path to a drive.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 17 of 35\n\nFigure 25: Parsing “-paths” Command-Line Argument.\r\nWhen traversing a drive, ROOK builds the following drive path.\r\nWith the path, the malware checks and avoids enumerating the drive if it’s a CD-ROM drive.\r\nIf the drive type is a remote drive, ROOK calls WNetGetConnectionW to retrieve the remote name of the drive\r\nand passes it to be traversed by the recursive_traverse_dir function.\r\nIf the drive type is not remote drive and CD-ROM drive, the malware simply passes it to the\r\nrecursive_traverse_dir function.\r\nIn the recursive_traverse_dir function, ROOK begins by executing two nested while loop. The first one loops\r\nand waits until the END_ACCESS_DIR_SEMAPHORE semaphore’s count is reduced to zero, and its state is\r\nnonsignaled. When this happens, it means every directory in the global directory list is already traversed and no\r\nthread is extracting from it.\r\nWhile waiting for this, the inner while loop waits until the BEGIN_ACCESS_FILE_SEMAPHORE semaphore\r\nis signaled, which allows the current process to access the global file list. After obtaining the ownership of the\r\ncritical section for the global file list using EnterCriticalSection, ROOK extracts the file at the current index,\r\nincrements the index, and encrypts it. The file encryption routine is later discussed at the File Encryption section.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 18 of 35\n\nFigure 27: Waiting for Directory List to Be Cleared \u0026 Encrypting File in the Meantime.\r\nInstead of just looping and waiting for the directory list to be cleared, ROOK extracts and encrypts files in the\r\nglobal file list during the wait time to increase efficiency and avoids wasting computing resources. This makes the\r\noverall enumeration and encryption process quite fast.\r\nNext, the malware calls EnterCriticalSection to obtain the ownership of the global directory list and adds the\r\ndirectory path to be traversed in. Then, it calls ReleaseSemaphore to release the\r\nBEGIN_ACCESS_DIR_SEMAPHORE semaphore, which increments its count by one and signals other threads\r\nthat another directory is available to be enumerated.\r\nFigure 28: Adding Directory to Global List \u0026 Signaling for Enumeration.\r\nThen, the function begins enumerating the directory for all its sub-directories. ROOK builds the path **“\\\\\\*\"**\r\nand passes it to **FindFirstFileW** to start the enumeration.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 19 of 35\n\nFigure 29: Enumerating Directory for Sub-Directories.\r\nFor each sub-directory found, the malware checks if the filename is not in the list of files and directories to avoid.\r\nIf it’s not, the sub-directory full path is constructed and passed back to recursive_traverse_dir to be recursively\r\ntraversed.\r\nBelow is the list of files and directories to avoid.\r\n\u003clog_filename\u003e, \"Mozilla Firefox\", \"$Recycle.Bin\", \"ProgramData\", \"All Users\", \"autorun.inf\", \"boot.ini\", \"boot\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 20 of 35\n\nFigure 30: Recursively Traversing All Sub-Directories.\r\nIf the command-line argument “-paths” is not provided, ROOK manually mounts all drives that have no volume\r\nmounted and traverses through all of them.\r\nFirst, it builds a list of all drive letters and iterates through it to find drives with type DRIVE_NO_ROOT_DIR.\r\nThose drives are then added to the end of the list.\r\nFigure 31: Finding Drives with an Invalid Root Path.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 21 of 35\n\nNext, ROOK calls FindFirstVolumeW and FindNextVolumeW to scan for available volumes in the system. For\r\neach volume, the malware calls GetVolumePathNamesForVolumeNameW to retrieve the volume GUID path\r\nand SetVolumeMountPointW to set the path as the root path for the next no-root drive in the list.\r\nFigure 32: Mounting All Unmounted Drives.\r\nFinally, the malware calls GetLogicalDrives to iterate through all the drives in the system and traverse them.\r\nFigure 33: Traversing All Mounted Drives.\r\nWhen the command-line argument “-shares” is provided, ROOK specifically enumerates them and exits upon\r\ncompletion.\r\nThe argument can come in the form of a list of network server paths, which each separated by a comma.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 22 of 35\n\nFigure 34: Parsing “-shares” Command-Line Argument.\r\nTo traverse each share server, the malware calls NetShareEnum to retrieve information about each shared\r\nresource on it.\r\nFor each shared resource, if its type is not a special share reserved for interprocess communication (IPC$) or\r\nremote administration of the server (ADMIN$), the shared resource is skipped.\r\nIf the share name is “ADMIN$”, the malware builds the path **”\\\\\\\\ADMIN\\$\"** and passes it to\r\n**recursive_traverse_dir** to be traversed.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 23 of 35\n\nFigure 35: Traversing Shared Resources.\r\nChild Thread\r\nFor the spawn child threads, they have two different modes of execution depending on the flag passed in as\r\nparameter.\r\nIf the flag is 1, the thread will process a directory from the global directory list.\r\nFirst, it enters a nested while loop like the one we have seen earlier. The first loop waits until the\r\nBEGIN_ACCESS_DIR_SEMAPHORE semaphore enters a nonsignaled state, which means no thread is adding\r\nto the directory list.\r\nWhile waiting for that, ROOK efficiently waits to retrieve access to the global file list, extract a file, and encrypts\r\nit similar to the previous nested while loop.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 24 of 35\n\nFigure 36: Waiting for Global Directory List Access.\r\nAfter the directory list is full, the malware obtains ownership of the list’s critical section, extracts a directory out,\r\nand begins traversing it for sub-files.\r\nFigure 37: Extracting Directory \u0026 Enumerating for Sub-Files.\r\nFor the enumeration, ROOK first builds a path to a ransom note file in the directory, calls CreateFileW to create\r\nit and WriteFile to write the ransom note content to it.\r\nBelow is the raw content of the ransom note.\r\n-----------Welcome. Again. --------------------\r\n[+]Whats Happen?[+]\r\nYour files are encrypted,and currently unavailable. You can check it: all files on you computer has expansion ro\r\nBy the way,everything is possible to recover (restore), but you need to follow our instructions. Otherwise, you\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 25 of 35\n\n[+] What guarantees?[+]\r\nIts just a business. We absolutely do not care about you and your deals, except getting benefits. If we do not d\r\nTo check the file capacity, please send 3 files not larger than 1M to us, and we will prove that we are capable\r\nIf you will not cooperate with our service - for us, its does not matter. But you will lose your time and data,c\r\nIf we find that a security vendor or law enforcement agency pretends to be you to negotiate with us, we will dir\r\nYou have 3 days to contact us for negotiation. Within 3 days, we will provide a 50% discount. If the discount se\r\nPlease use the company email to contact us, otherwise we will not reply.\r\n[+] How to get access on website?[+]\r\nYou have two ways:\r\n1) [Recommended] Using a TOR browser!\r\na) Download and install TOR browser from this site:hxxps://torproject[.]org/\r\nb) Open our website:\u003credacted\u003e[.]onion\r\n2) Our mail box:\r\na)\u003credacted\u003e@onionmail[.]org\r\nb)\u003credacted\u003e@onionmail[.]org\r\nc)If the mailbox fails or is taken over, please open Onion Network to check the new mailbox\r\n------------------------------------------------------------------------------------------------\r\n!!!DANGER!!!\r\nDONT try to change files by yourself, DONT use any third party software for restoring your data or antivirus sol\r\n!!!!!!!\r\nAGAIN: Its in your interests to get your files back. From our side, we (the best specialists) make everything fo\r\n!!!!!!!\r\nONE MORE TIME: Security vendors and law enforcement agencies, please be aware that attacks on us will make us ev\r\n!!!!!!!\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 26 of 35\n\nFigure 38: Dropping Ransom Note.\r\nNext, it builds the path **“\\\\*\"** and passes it to **FindFirstFileW** to begin enumerating through files in the\r\ndirectory.\r\nFigure 39: Enumerating Files in Directory.\r\nFor each found file, ROOK checks to make sure its name is not in the files and directories to avoid list and is not\r\nHowToRestoreYourFiles.txt.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 27 of 35\n\nFigure 40: Checking for Invalid Filenames.\r\nROOK also skips the file if its extension is “.exe”, “.dll”, or “.Rook”. After checking, the malware enters a\r\nnested while loop to wait until no thread can add to the global file list and extracts files to encrypt during the wait\r\ntime.\r\nAfter getting access to the file list, ROOK calls EnterCriticalSection to obtain the ownership of the file list’s\r\ncritical section and adds the subfile to the list.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 28 of 35\n\nFigure 41: Adding Subfile to Global File List.\r\nIf the flag from parameter is 1, the child thread will continuously encrypt files from the global directory list until\r\nthe list is completely empty.\r\nFigure 42: Iterating \u0026 Encrypting Files in Global List.\r\nFile Encryption\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 29 of 35\n\nPrior to file encryption, ROOK calls SetFileAttributesW to set the file attribute to normal.\r\nIt builds the following path **“.Rook\"** and calls **MoveFileExW** to change the file name to have the\r\nencrypted extension **.Rook**.\r\nFigure 43: Adding Encrypted Extension.\r\nNext, the malware calls CreateFileW to retrieve the file handle for the target and begins the encryption.\r\nFirst, it uses the Mbed TLS CTR_DRBG context to generates a random 16-byte AES key.\r\nFigure 44: Randomly Generating AES Key for File.\r\nNext, ROOK populates the following structures for the file footer.\r\nstruct ROOK_FILE_FOOTER\r\n{\r\n LARGE_INTEGER file_size;\r\n ROOK_CRYPT_METADATA metadata;\r\n};\r\nstruct ROOK_CRYPT_METADATA\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 30 of 35\n\n{\r\n _QWORD encrypted_chunk_count;\r\n _QWORD unk;\r\n BYTE AES_key_encrypted_by_my_public[256];\r\n BYTE my_private_key_encrypted_by_Rook_public[2304];\r\n};\r\nThe malware begins by calling GetFileSizeEx to retrieve the size of the file and store it in the file footer. It then\r\nuses the victim’s RSA public key to encrypt the AES key and store it in the metadata’s\r\nAES_key_encrypted_by_my_public field.\r\nFigure 45: Encrypting AES Key Using Victim’s Public Key.\r\nNext, it copies the victim’s private key that is encrypted using ROOK’s public key during RSA Key Generation\r\ninto the metadata’s my_private_key_encrypted_by_Rook_public field.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 31 of 35\n\nFigure 46: Writing Victim’s Encrypted Private Key into File Footer.\r\nIf the file size is greater than 0x80000 bytes, the malware reads and encrypts at most three 0x80000-byte chunks at\r\nthe beginning of the file using AES-128 ECB.\r\nFigure 47: Encrypting Files Larger Than 0x80000 Bytes.\r\nIf the file size is less than 0x80000 bytes or is between 0x80000 and 0x180000 bytes, the entire file will be\r\nencrypted.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 32 of 35\n\nFigure 48: Calculating \u0026 Encrypting the Last Chunk That Is Less Than 0x80000 Bytes.\r\nFinally, the file footer is written to the end of the file, which ends the encryption routine.\r\nFigure 49: Writing File Footer.\r\nIf ROOK is unable to open the file prior to encryption, the malware attempts to terminate the file owner’s\r\nprocess.\r\nIt first calls RmStartSession to starts a new Restart Manager session and WideCharToMultiByte to convert the\r\nfile path to a multibyte buffer.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 33 of 35\n\nFigure 50: Starting A Restart Manager Session.\r\nUsing that session handle, the malware calls RmRegisterResources to register the target file as a resource to the\r\nRM.\r\nFigure 51: Registering Target File as a Resource.\r\nNext, it calls RmGetList to get a list of all applications that are using the file. For each of these applications, if the\r\napplication’s type is Windows Explorer or a critical process, it is skipped.\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 34 of 35\n\nThen, ROOK checks to make sure the application is not its own ransomware process through the process IDs.\r\nFinally, it calls OpenProcess to retrieve the process’s handle and terminate it using TerminateProcess.\r\nFigure 52: Terminating File Owners.\r\nAfter terminating all processes that are using the file, ROOK passes it back in to be encrypted.\r\nFigure 53: Setting Up File to Be Encrypted Again.\r\nReferences\r\nhttps://infosecwriteups.com/alternate-data-streams-ads-54b144a831f1\r\nhttps://www.sentinelone.com/labs/new-rook-ransomware-feeds-off-the-code-of-babuk/\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/03/BabukRansomware/\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nSource: https://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nhttps://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/\r\nPage 35 of 35\n\n https://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/ \nFigure 6, 7: Querying From Registry \u0026 Generating Victim Public-Private Key Pair.\nNext, ROOK encrypts the victim’s RSA private key using its own public key context.\n Page 6 of 35", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "references": [ "https://chuongdong.com/reverse%20engineering/2022/01/06/RookRansomware/" ], "report_names": [ "RookRansomware" ], "threat_actors": [ { "id": "f8dddd06-da24-4184-9e24-4c22bdd1cbbf", "created_at": "2023-01-06T13:46:38.626906Z", "updated_at": "2026-04-10T02:00:03.043681Z", "deleted_at": null, "main_name": "Tick", "aliases": [ "G0060", "Stalker Taurus", "PLA Unit 61419", "Swirl Typhoon", "Nian", "BRONZE BUTLER", "REDBALDKNIGHT", "STALKER PANDA" ], "source_name": "MISPGALAXY:Tick", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "54e55585-1025-49d2-9de8-90fc7a631f45", "created_at": "2025-08-07T02:03:24.563488Z", "updated_at": "2026-04-10T02:00:03.715427Z", "deleted_at": null, "main_name": "BRONZE BUTLER", "aliases": [ "CTG-2006 ", "Daserf", "Stalker Panda ", "Swirl Typhoon ", "Tick " ], "source_name": "Secureworks:BRONZE BUTLER", "tools": [ "ABK", "BBK", "Casper", "DGet", "Daserf", "Datper", "Ghostdown", "Gofarer", "MSGet", "Mimikatz", "Netboy", "RarStar", "Screen Capture Tool", "ShadowPad", "ShadowPy", "T-SMB", "down_new", "gsecdump" ], "source_id": "Secureworks", "reports": null }, { "id": "d4e7cd9a-2290-4f89-a645-85b9a46d004b", "created_at": "2022-10-25T16:07:23.419513Z", "updated_at": "2026-04-10T02:00:04.591062Z", "deleted_at": null, "main_name": "Bronze Butler", "aliases": [ "Bronze Butler", "CTG-2006", "G0060", "Operation ENDTRADE", "RedBaldNight", "Stalker Panda", "Stalker Taurus", "Swirl Typhoon", "TEMP.Tick", "Tick" ], "source_name": "ETDA:Bronze Butler", "tools": [ "8.t Dropper", "8.t RTF exploit builder", "8t_dropper", "9002 RAT", "AngryRebel", "Blogspot", "Daserf", "Datper", "Elirks", "Farfli", "Gh0st RAT", "Ghost RAT", "HOMEUNIX", "HidraQ", "HomamDownloader", "Homux", "Hydraq", "Lilith", "Lilith RAT", "McRAT", "MdmBot", "Mimikatz", "Minzen", "Moudour", "Muirim", "Mydoor", "Nioupale", "PCRat", "POISONPLUG.SHADOW", "Roarur", "RoyalRoad", "ShadowPad Winnti", "ShadowWali", "ShadowWalker", "SymonLoader", "WCE", "Wali", "Windows Credential Editor", "Windows Credentials Editor", "XShellGhost", "XXMM", "gsecdump", "rarstar" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775433993, "ts_updated_at": 1775792173, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/01d1c86d064e1e13a115b3fe84938ddc56fe75bf.pdf", "text": "https://archive.orkl.eu/01d1c86d064e1e13a115b3fe84938ddc56fe75bf.txt", "img": "https://archive.orkl.eu/01d1c86d064e1e13a115b3fe84938ddc56fe75bf.jpg" } }