{
	"id": "87892807-4421-46c1-a4cc-5f7ccb82d52c",
	"created_at": "2026-04-06T00:22:38.561299Z",
	"updated_at": "2026-04-10T03:20:57.405843Z",
	"deleted_at": null,
	"sha1_hash": "0bdef3b6f0e617af618450f1179cfa53d64fc03c",
	"title": "LockBit 2.0 Ransomware Becomes LockFile Ransomware with a Never-Before-Seen Encryption Method",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1012535,
	"plain_text": "LockBit 2.0 Ransomware Becomes LockFile Ransomware with a\r\nNever-Before-Seen Encryption Method\r\nBy Moshe HayunThreat Intelligence Team Leader\r\nPublished: 2021-09-21 · Archived: 2026-04-05 19:00:45 UTC\r\nThreat actors are constantly improving their attack mechanisms to gain an advantage over cybersecurity defenses.\r\nSometimes this involves new malware; other times this means making iterative adjustments to previously\r\nsuccessful malware to exploit new vulnerabilities or use new attack techniques to evade and breach underprepared\r\nnetwork environments.\r\nWe have seen ransomware evolve in this way previously, perhaps most famously with Petya and NotPetya.\r\nRansomware is one of the top threats to businesses, with DarkSide, WastedLocker, and many others leaving their\r\nmark on the international business landscape.\r\nIn this post we provide analysis on an emerging ransomware variant called LockFile which evolved from Lockbit\r\n2.0 and has breached security defenses using new attack techniques.\r\nLockFile’s Unique Encryption\r\nMost ransomware operates in a similar way. It generates an encryption key and uses it to encrypt the entire binary\r\nof the file, corrupting all data.\r\nLockfile works differently. Rather than encrypting the entire file, it intermittently encrypts 16 bytes at a time. For\r\ntextual data, this means that part of the file will remain readable. For files where the structure is important (such as\r\na pdf), it will corrupt the file and make it unusable.\r\nAdditionally, LockFile ransomware does not encrypt certain file extensions (for example .exe and .dll), a common\r\nbehavior amongst a variety of ransomware. The purpose of this encryption technique is to allow the operating\r\nsystem to still function for the victim, albeit only by using corrupted data, ensuring the infected organization pays\r\nthe ransom.\r\nhttps://www.deepinstinct.com/blog/lockbit-2-0-ransomware-becomes-lockfile-ransomware-with-a-never-before-seen-encryption-method\r\nPage 1 of 5\n\nOne aspect of LockFile that makes it different from other ransomware is that it does not attack image files (jpeg,\r\nbmp, giff, jpg). This is a curious approach. Does LockFile do this to preserve a victim's animal pictures, or is this\r\nsimply coincidental?\r\nWhat is the Strategy Behind Encrypting Only Part of the File?\r\nTo understand the thinking behind encrypting only part of the file rather than the entire thing, think of a file like an\r\nenormous puzzle. When you encrypt the file, you scramble the puzzle image to the point where you can’t\r\nrecognize the original. At that point no one could be tricked into thinking that this is a legitimate puzzle.\r\nBut what if a large portion of the puzzle remained untouched? Without careful examination, you might not notice.\r\nAs such, it may well be that only part of these files are encrypted by design to obfuscate the threat. When a full\r\nfile is encrypted, it is quite easy to determine that the file has been tampered with. However, using intermittent\r\nencryption may be a new tactic to avoid detection.\r\nOld Dog, New Tricks\r\nSo, who is behind this new ransomware?\r\nSome speculate that the Conti ransomware gang is responsible based on the email address in the ransom note\r\n(contact@contipauper.com).\r\nhttps://www.deepinstinct.com/blog/lockbit-2-0-ransomware-becomes-lockfile-ransomware-with-a-never-before-seen-encryption-method\r\nPage 2 of 5\n\nBut a close examination of the note reveals a striking similarity to the note used in LockBit 2.0.\r\nAlthough the ransom note is nearly identical (the font, colors, and formatting are the same) LockBit 2.0 uses 32bit\r\nfiles while all the LockFile samples we found were 64bit. The 64bit payload Lockfile narrows the target range of\r\npotential victims since 64bit won’t work on machines with older operating systems or 32bit operating systems.\r\nhttps://www.deepinstinct.com/blog/lockbit-2-0-ransomware-becomes-lockfile-ransomware-with-a-never-before-seen-encryption-method\r\nPage 3 of 5\n\nThis is interesting because threat actors typically prefer to keep a wider scope, not limiting their targets to specific\r\nOS architectures. Perhaps Lockfile’s developers had performance aspects in mind during the development process\r\nwhich led them to this decision?\r\nLockBit 2.0 and LockFile: What are the Differences?\r\nThere are three more noticeable ‘features’ which differentiate LockBit 2.0 and LockFile:\r\n1. LockBit 2.0 did not use the unique intermittent encryption we saw in LockFile.\r\n2. LockBit 2.0 used wmic.exe only for deleting shadow copies, while in LockFile we saw their extensive use\r\nto terminate any process related to virtualization or databases the machine is connected to.\r\n3. LockBit 2.0 encrypted victim’s images, whereas LockFile did not do image encryption.\r\nMitigating the Threat\r\nAccording to sources familiar with the threat infection chain, the latest version of the ransomware is using two\r\nvery new attack vectors:\r\nProxyShell – Microsoft Exchange servers remote code execution vulnerability\r\nPetitPotam NTLM relay attack – new technique used to perform an NTLM relay attack\r\nTo mitigate the ProxyShell vulnerabilities, one must simply patch the exchange servers. (CVE-2021-31207, 2021-\r\n33473, 2021-34523, 2021-31206)\r\nMitigating the PetitPotam requires more than just downloading a patch – it necessitates following a guide\r\nMicrosoft released, which first informs a user about whether they are affected and includes details on how to\r\nconfigure one’s domain controllers to mitigate this attack vector.\r\nHow Deep Instinct Stopped LockFile\r\nThreat actors will continue to find flaws and create sophisticated ways to attack your environment. The onus is on\r\nall of us to stay one step ahead.\r\nWhen it comes to preventing LockFile ransomware, Deep Instinct is the answer. We detect it pre-execution\r\nwithout any updates or modifications to our product and stop it in its tracks.\r\nhttps://www.deepinstinct.com/blog/lockbit-2-0-ransomware-becomes-lockfile-ransomware-with-a-never-before-seen-encryption-method\r\nPage 4 of 5\n\nIf you’d like to learn more about our ransomware prevention capabilities – including our industry best $3M no-ransomware guarantee – we'd be delighted to give you a demo.\r\nIOCs:\r\nLockfile’s SHA256 Referred to in this Blog Post:\r\nSHA256 File Type\r\n2a23fac4cfa697cc738d633ec00f3fbe93ba22d2498f14dea08983026fdf128a 64-bit executable\r\ncafe54e85c539671c94abdeb4b8adbef3bde8655006003088760d04a86b5f915 64-bit executable\r\nbf315c9c064b887ee3276e1342d43637d8c0e067260946db45942f39b970d7ce 64-bit executable\r\n a926fe9fc32e645bdde9656470c7cd005b21590cda222f72daf854de9ffc4fe0 64-bit executable\r\nSource: https://www.deepinstinct.com/blog/lockbit-2-0-ransomware-becomes-lockfile-ransomware-with-a-never-before-seen-encryption-meth\r\nod\r\nhttps://www.deepinstinct.com/blog/lockbit-2-0-ransomware-becomes-lockfile-ransomware-with-a-never-before-seen-encryption-method\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://www.deepinstinct.com/blog/lockbit-2-0-ransomware-becomes-lockfile-ransomware-with-a-never-before-seen-encryption-method"
	],
	"report_names": [
		"lockbit-2-0-ransomware-becomes-lockfile-ransomware-with-a-never-before-seen-encryption-method"
	],
	"threat_actors": [],
	"ts_created_at": 1775434958,
	"ts_updated_at": 1775791257,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0bdef3b6f0e617af618450f1179cfa53d64fc03c.pdf",
		"text": "https://archive.orkl.eu/0bdef3b6f0e617af618450f1179cfa53d64fc03c.txt",
		"img": "https://archive.orkl.eu/0bdef3b6f0e617af618450f1179cfa53d64fc03c.jpg"
	}
}