{ "id": "66aee976-0cf4-4dac-95b7-66d24069c15c", "created_at": "2026-04-06T00:22:18.105605Z", "updated_at": "2026-04-10T03:22:00.222723Z", "deleted_at": null, "sha1_hash": "a2112aa01433908eff19e414064afa0e96fa7e67", "title": "DMA Locker Strikes Back | Malwarebytes Labs", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 434537, "plain_text": "DMA Locker Strikes Back | Malwarebytes Labs\r\nBy hasherezade\r\nPublished: 2016-02-08 · Archived: 2026-04-05 19:21:38 UTC\r\nA few days ago we published a post about a new ransomware – DMA Locker (read more here). At that time, it\r\nwas using a pretty simple way of storing keys. Having the original sample was enough to recover files.\r\nUnfortunately, the latest version (discovered February 8) comes with several improvements and RSA key. Let’s\r\ntake a look at the changes.\r\nDMA Locker in recent campaigns have been found installed by the attackers via Remote Desktop (similar\r\ndistribution method was used by LeChiffre ransomware).\r\n[UPDATE] READ ABOUT THE LATEST VERSION OF DMA LOCKER: 4.0\r\nUPDATE: version 3.0 (discovered 22-th Feb) fixed the bug in the cryptography implementation. Due to this\r\nfact, encrypted files cannot be recovered by external tools (although it was possible in case of the earlier\r\nversion, described in this article). Sorry, but our decryptor can no longer help!\r\nPREVENTION TIP: Create these files to protect yourself from this version of DMA Locker. Content doesn’t\r\nmatter. In presence of these files, the program will go by other path of execution and display the red message only\r\n– but not deploy the encryption.\r\nC:Documents and SettingsAll Usersdecrypting.txt\r\nC:Documents and SettingsAll Usersstart.txt\r\nC:ProgramDatadecrypting.txt\r\nC:ProgramDatastart.txt\r\nThis trick works only as a PREVENTION – once your files are encrypted, it is not going to help. For more info\r\nabout why it happens, please read this post.\r\nAnalyzed sample\r\n28b44669d6e7bc7ede7f5586a938b1cb\r\nBehavioral analysis\r\nAgain we are alerted by a red window – almost identical like before, only the locker image is added:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 1 of 10\n\nThis time the key necessary to decrypt files must be supplied not as a text, but as RSA key file. Author added also\r\nkey validation.\r\nSimilarly, it drops files in C:ProgramData (or C:Documents and SettingsAll Users). Now, the dropped copy is\r\nnamed svchosd.exe.\r\nAnd created registry keys to autorun the file and to autodisplay ransom note via notepad at system startup.\r\nEncrypted files again have unchanged extensions – they can be only recognized by 8 byte long prefix at the\r\nbeginning of the content. In the previous edition it was “ABCXYZ11“, in current it is “!DMALOCK“:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 2 of 10\n\nExperiment\r\nLet’s compare how the encrypted files look\r\nFrom the left we can see visualizations of raw bytes of following files: original, encrypted by previous DMA\r\nLocker, encrypted by current DMA Locker\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 3 of 10\n\nPrevious DMA Locker(middle picture) was encrypting files by AES-256 ECB mode, applied on 16 byte long\r\nchunks of input. Now (last picture), also repetitive patterns exist – so probably AES-256 ECB mode was used\r\nagain.\r\nHowever, pay attention to the strips in the BMP – in a new file they are shifted a bit more. It would suggest that\r\nthe header is longer than previously. Let’s visualize the same files with a different width, to make sure that this\r\nimpression is right. The header of the file is visualized as a line at the top left corner – it ends where the vertical\r\nline starts.\r\nNow it is visible clearly – the header is really longer. Why? To answer this question, code analysis is required –\r\nbut it can signify, that some additional data have been stored there (it can be for example the AES key, encrypted\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 4 of 10\n\nby RSA).\r\nInside\r\nWhen does the encryption start?\r\nAt the beginning of execution, (as in the previous version) the malware terminates applications used for backups.\r\nAlso, adds registry keys for its persistence. Then, execution of the main function may follow 3 alternative paths.\r\nif system is already infected -\u003e do not deploy encryption, only display the red window with ransom note\r\nsystem is not yet infected, malware is not yet installed (current file name is different than the expected one\r\n– svchosd.exe) -\u003e install the malware in ProgramData and then deploy again the dropped file\r\nsystem is not yet infected, but malware is installed -\u003e deploy encryption, after finishing display the red\r\nwindow with ransom note\r\nThe recognition, in which state is the system, is performed basing on the presence of some predefined files.\r\nPresence of file decrypting.txt informs that system is already infected. File start.txt informs that encrypting\r\nstarted (and no need to start it again):\r\nKnowing this fact, we can easily drop those files by our own and fake that our system is infected. It will prevent\r\nthis version of DMA Locker from attacking our system (it will display the ransom note but not touch our files).\r\nHow does the encryption work?\r\nThis time the author decided to practice what he preached and really used RSA key (previous version supplied to\r\nthe encrypting function just a text key, read from the end of the original sample).\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 5 of 10\n\nIn contrast to the previous edition, where one AES key was used for all the files, here a new random key is\r\ngenerated per every file.\r\nAs you can see – in example below the randomly generated key was\r\nMRNW9KSC5JRCeT4uJVmI2AOS7JUjPQc6\r\nThen, the key is used in the same way like the previous one – to encrypt 16 byte long chunk with AES ECB mode.\r\nBelow – buffer before encryption (fragment of the input is selected on the hex dump – it is a header of a PNG\r\nfile):\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 6 of 10\n\nThe same chunk encrypted (result in bytes -\u003e “55 0F 94 4C B0 98 81 DB F4 57 8A 98 92 2C 09 14”)\r\nAfter use, the random AES key is RSA encrypted:\r\nand then, appended to the beginning of the AES encrypted file (just after the “!DMALOCK” signature):\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 7 of 10\n\nWe can see that now the AES encrypted content starts with offset 0x88 (compare the selected part with the above\r\nexample showing AES encryption result):\r\nWhat is attacked?\r\nAs previous, attacked are logical disks as well as network shares.\r\nThis sample introduced also check against Floppy and CD using QueryDosDeviceA (floppy and CD are skipped):\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 8 of 10\n\nLike in the previous version, skipped are some predefined folders:\r\n…and file extensions:\r\nConclusion\r\nThe author of this malware, despite appearing inexperienced in programming, seems to be very determined to\r\ngradually improve the quality of the product. The disparity between the quality of the first edition, second\r\n(described in the previous article) and the third (current) is significant. We will keep eye on the evolution of this\r\nmalware family and provide you with updates and possible tips on dealing with this threat.\r\nAbout the author\r\nUnpacks malware with as much joy as a kid unpacking candies.\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 9 of 10\n\nSource: https://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://blog.malwarebytes.com/threat-analysis/2016/02/dma-locker-strikes-back/" ], "report_names": [ "dma-locker-strikes-back" ], "threat_actors": [], "ts_created_at": 1775434938, "ts_updated_at": 1775791320, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/a2112aa01433908eff19e414064afa0e96fa7e67.pdf", "text": "https://archive.orkl.eu/a2112aa01433908eff19e414064afa0e96fa7e67.txt", "img": "https://archive.orkl.eu/a2112aa01433908eff19e414064afa0e96fa7e67.jpg" } }