{
	"id": "b00e2340-f23a-485b-9dcd-79a9da76f0bf",
	"created_at": "2026-04-10T03:22:11.717532Z",
	"updated_at": "2026-04-10T03:22:16.710185Z",
	"deleted_at": null,
	"sha1_hash": "5843c0733397b45fb9f758909e0eb064c470bcfb",
	"title": "Babuk Ransomware v3",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 565416,
	"plain_text": "Babuk Ransomware v3\r\nBy Chuong Dong\r\nPublished: 2021-01-16 · Archived: 2026-04-10 02:47:50 UTC\r\nReverse Engineering  · 16 Jan 2021\r\nOverview\r\nThis is a short report for the latest Babuk ransomware sample. This sample is marked as version 3 based on the\r\nrun-once mutex string.\r\nFor this new version, the malware author keeps most of the old functionalities the same except for the encryption\r\nscheme and the multithreading approach.\r\nSince I have covered Babuk old sample here, I will only discuss the new changes in this report.\r\nFor encryption, Babuk uses ChaCha20 encryption, but the Elliptic-curve Diffie–Hellman (ECDH) key generation\r\nand exchange algorithm is changed from NIST K-571 to Curve25519, one of the fastest ECDH curves.\r\nIOCS\r\nBabuk v3 comes in the form of a 32-bit .exe file.\r\nMD5: 8b9a0b44b738c7884e6a14f4cb18afff\r\nSHA256: 704a0fa7de19564bc743fb68aa0652e38bf86e8ab694bc079b15f945c85f4320\r\nSample:\r\nhttps://bazaar.abuse.ch/sample/704a0fa7de19564bc743fb68aa0652e38bf86e8ab694bc079b15f945c85f4320/\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 1 of 12\n\nFigure 1: VirusTotal result for Babuk v3\r\nRansom Note\r\nFigure 2: Babuk’s new ransom note\r\nNew Changes\r\nRun-Once Mutex\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 2 of 12\n\nIn the beginning, Babuk checks if a mutex with the name “babuk_v3” exists through the call to OpenMutexA. If\r\nit already exists, the malware exits immediately.\r\nThis is commonly used by malware to prevent themselves from having multiple instances running at once.\r\nFigure 3: Babuk checking for mutex\r\nCommand-line Arguments\r\nBabuk can work with or without command line parameters.\r\nThe new command line parameters are “lanfirst”, “nolan”, and “shares”.\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 3 of 12\n\nFigure 4: Babuk checking for mutex\r\nIf a parameter is given, it will process these arguments upon execution and behave accordingly.\r\nCMD Args Functionality\r\n-lanfirst Encrypting other drives on LAN and locally\r\n-nolan Encrypting locally\r\nshares Encrypting shared drives and locally\r\nMultithreading\r\nThe multithreading implementation has been changed a lot since the first version. I guess they really tried to\r\nimprove it after reading what I had to say in the last blog post\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 4 of 12\n\nFigure 5: Babuk team’s friendly response to my analysis!\r\nThe steps taken to improve the ransomware’s threading functionalities are in the right direction since they do\r\nincrease the encryption speed by quite a bit.\r\nBabuk uses a structure similar to a circular queue (Ring Buffer) backed by an array to store file names to encrypt.\r\nThe queue size is double the number of processors on the system, which is the same amount of child threads being\r\nspawned.\r\nFigure 6: Queue initialization\r\nThis queue is shared and used by child threads.\r\nThe parent thread will recursively crawl through directories and enqueue the file names it finds to the head of the\r\nqueue. The child threads will start dequeuing them at the tail of the queue to begin encryption.\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 5 of 12\n\nFigure 7: Babuk’s circular queue illustration\r\nFirst, Babuk will spawn child threads. The number of threads being spawned is double the number of processors.\r\nThis is clearly not a good amount so I have no idea why they still use it similar to the previous version.\r\nFigure 8: Spawning child threads\r\nThe Babuk parent thread then proceeds to traverse through an entire drive by checking whether it has encountered\r\na directory or a file.\r\nUpon finding a directory, it will call that function again and go down another layer to recursively traverse that\r\ndirectory.\r\nUpon finding a file, it will enqueue that file to the head of the queue and move on.\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 6 of 12\n\nFigure 9: Babuk parent thread traversing through directories and enqueuing files\r\nEach child thread will dequeue a file at the tail of the queue and encrypt it.\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 7 of 12\n\nFigure 10: Babuk child threads dequeuing and encrypting files\r\nHere is the implementation for enqueuing and dequeuing files.\r\nFigure 11: Function to enqueue files\r\nFigure 12: Function to dequeue files\r\nAs we can see, Babuk uses a file queue backed by an array. By keeping track of the head and tail indices, adding\r\nand removing file names from the queue take a constant time and are really fast.\r\nWith all of these new changes to the implementation, this new version of Babuk is much faster than the original\r\none. Unfortunately, there is still a lot more room for improvement since it is nowhere near Conti and other\r\nransomware in terms of speed and efficiency.\r\nWith an array-backed queue, space is limited. As we can see in the enqueue function, there is no check to see if the\r\nqueue is full before adding more files onto it. In the theoretical case where all the threads are busy encrypting files\r\nand the queue is full, the parent thread will continue adding more files. Since this is a circular queue, this will\r\nresult in files being overwritten with new ones before the child threads have a chance to encrypt them if the parent\r\nthread is fast enough.\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 8 of 12\n\nMoreover, the malware author still sticks with the old recursive approach to traversing files. With only the parent\r\nthread traversing entire drives, there will be an extreme amount of overhead from the stack frame since there will\r\nbe too many recursion layers. This essentially makes the total encryption time dependent on the time it takes for\r\none thread to traverse the entire system.\r\nEncryption\r\nEncryption scheme remains the same from the original version. However, there is a slight change in the ChaCha20\r\nkey generation.\r\nFor every file, a random buffer of 32 bytes is generated using CryptGenRandom.\r\nFigure 13: Generating random buffer\r\nNext, using the this exact piece of Curve25519 implementation, Babuk will generate a public key for the victim\r\nfrom the random buffer using ECDH.\r\nIt will also generate a shared secret using its hard-coded public key and the random buffer. This shared secret is\r\neventually used as the ChaCha20 key to encrypt the file.\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 9 of 12\n\nFigure 14: Public key and shared secret generation\r\nFinally, the victim’s public key is then written to the end of the file to be used for decryption if the victim decides\r\nto pay.\r\nFigure 15: Victim’s public key being written to the end of file\r\nNot sure if this was intended, but I believe the Babuk group has messed up the public key generation phase.\r\nAccording to Dan Bernstein who was the author of this Diffie-Hellman function, here is the procedure of\r\ngenerating a public key using Curve25519.\r\nFigure 16: Curve25519 Public Key Generation\r\nInstead of using 9 followed by all zeroes, Babuk uses an array of all 9 values.\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 10 of 12\n\nFigure 17: Babuk’s basepoint constant\r\nUnless the malware author has modified the math in the Curve25519 source code to accommodate for this (which\r\nis unlikely), this basepoint constant might not generate a correct public key.\r\nWith an incorrect public key, it’s impossible for the malware author to generate the correct shared secret to decrypt\r\nfiles.\r\nKey Findings\r\nThe new version of Babuk has been improved to encrypt files at a much faster rate using a better multithreading\r\napproach. Despite still having a lot to improve, Babuk has been really effective in attacking many corporations\r\nusing ChaCha20 encryption as well as Elliptic-curve Diffie–Hellman algorithm.\r\nAs suspected, the Babuk team probably uses spear phishing attacks, VPN 0-days, and vulnerable RDP setup to\r\ntarget certain companies. They have dropped this sample specifically targeting a mechanical contractor in Austria\r\naccording to the ransom note and the conversation with the victim on their website.\r\nFigure 18: Babuk team asking the victim to provide their company email\r\nMessage to newer victims\r\nI recently notice I’m getting a lot more traffic from Europe on this page, which I’m assuming newer victims are\r\nviewing this to better their understanding of the ransomware.\r\nThis blog post is really out of date because Babuk has evolved a lot, and the malware is drastically different from\r\nwhat I talk about here.\r\nIf recent Babuk victims are interested in getting more information about the newer version of this ransomware or\r\nrequire any assistance with analyzing any sample, feel free to reach out to me through my email cdong49@gatech\r\nor Twitter!\r\nYARA Rule\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 11 of 12\n\nrule BabukRansomwareV3 {\r\n meta:\r\n description = \"YARA rule for Babuk Ransomware v3\"\r\n reference = \"http://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\"\r\n author = \"@cPeterr\"\r\n date = \"2021-01-16\"\r\n rule_version = \"v3\"\r\n malware_type = \"ransomware\"\r\n tlp = \"white\"\r\n strings:\r\n $lanstr1 = \"-lanfirst\"\r\n $lanstr2 = \"-nolan\"\r\n $lanstr3 = \"shares\"\r\n $str1 = \"BABUK LOCKER\"\r\n $str2 = \"babukq4e2p4wu4iq.onion\"\r\n $str3 = \"How To Restore Your Files.txt\" wide\r\n $str4 = \"babuk_v3\"\r\n $str5 = \".babyk\" wide\r\n condition:\r\n all of ($str*) and all of ($lanstr*)\r\n}\r\nReferences\r\nhttps://twitter.com/Sebdraven/status/1350025347690098689\r\nhttp://chuongdong.com/reverse%20engineering/2021/01/03/BabukRansomware/\r\nhttps://cr.yp.to/ecdh.html\r\nhttps://github.com/agl/curve25519-donna/blob/master/curve25519-donna.c\r\nSource: https://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nhttps://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/\r\nPage 12 of 12\n\n  https://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/  \nFigure 9: Babuk parent thread traversing through directories and enqueuing files\nEach child thread will dequeue a file at the tail of the queue and encrypt it.\n   Page 7 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://chuongdong.com/reverse%20engineering/2021/01/16/BabukRansomware-v3/"
	],
	"report_names": [
		"BabukRansomware-v3"
	],
	"threat_actors": [],
	"ts_created_at": 1775791331,
	"ts_updated_at": 1775791336,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5843c0733397b45fb9f758909e0eb064c470bcfb.pdf",
		"text": "https://archive.orkl.eu/5843c0733397b45fb9f758909e0eb064c470bcfb.txt",
		"img": "https://archive.orkl.eu/5843c0733397b45fb9f758909e0eb064c470bcfb.jpg"
	}
}