{
	"id": "843b936b-d452-454e-9d70-11105a5cf9dd",
	"created_at": "2026-04-06T00:11:28.745146Z",
	"updated_at": "2026-04-10T13:12:38.356348Z",
	"deleted_at": null,
	"sha1_hash": "e43b1fbb678979791654476a5c293850c9f7e6c6",
	"title": "Between a rock and a hard place - exploring mount locker ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 31668311,
	"plain_text": "Between a rock and a hard place - exploring mount locker\r\nransomware\r\nBy f0wL\r\nPublished: 2020-12-23 · Archived: 2026-04-05 16:52:19 UTC\r\nThis time we will be analyzing Mount Locker, a relatively new Ransomware strain that appeard in the second half\r\nof 2020. This blog post will detail the initial Analysis, Unpacking and Static + Dynamic Analysis of samples\r\nbelonging to the second iteration of the Malware.\r\nHey there, long time no blog post :D It's not like I haven't been doing any research the last couple of months, but\r\nbetween the whole Covid-19 Situation, University work and everything else there was either too little time to\r\nfinish the posts I started or I came up with multiple smaller things like my Netwalker Config Extractor that would\r\nnot justify a dedicated blog article (I normally dump stuff like this on Twitter instead).\r\nAnyway, I wanted to get atleast one more Blogpost out before 2020 comes to an end. This time I will be looking at\r\n\"Mount Locker\", yet another Double Extortion Ransomware (as a Service) that is targeting Microsoft Windows.\r\nThe goals of this article are:\r\nHighlight the Unpacking of the samples\r\nA bit more debugging, something that my older posts lack\r\nA walkthrough of the cryptographic functions\r\nA quality Yara Rule\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 1 of 37\n\nBack in September NHS Digital already released an alert for Mount Locker dating its first appearance to July\r\n2020. Although they do not state a delivery method at the moment access through stolen Credentials and Remote\r\nManagement are very likely. The Advisory also features very solid remediation advice.\r\nNews \u0026 Leak Sites\r\nSince we are talking about Double-Extorition Ransomware here of course Mount Locker runs its own Leak Site. It\r\nis available via Tor only and features a Home page, a contact formular and a blog style listing of compromised\r\ncompanies they hit and stole their data.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 2 of 37\n\nNext, let's have a look at how they communicate with their victims. All of the dropped HTML Ransomnotes\r\ncontain a unique-per-sample onion URL with a live chat. Browsing to this Tor site without the Client ID specified\r\nlike this /?cid= you will end up with the login prompt shown below (victims don't get a password and leaving the\r\ninput field blank does not work, so this might only work for operators/affiliates?). I went ahead and removed the\r\nClient IDs from all screenshots to not lower the bar for people trying to mess with the chat in any way. Same with\r\nthe additional contact E-Mail addresses that were found in two of the sample Ransomnotes which follow the\r\npattern firstnameLastname[year/integers]@protonmail.com.\r\nI will include two of the support chat logs as well, because they allow for a few interesting insights into how\r\nMount Locker attacks work. In the Screenshot below you can see a monologue by the Mount Locker Operators.\r\nThey obviously really like the support the \"Tech Support Role\" since they open up the conversation with \"We are\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 3 of 37\n\nready to help you. What are your problems?\". After over a week with no reply from the victim they try to contact\r\nthem again by adressing the message directly to an employee (name redacted, classic scare tactic). It's unclear how\r\nthey got the name, but my guess is they either gained access via Malspam or remote access to the employee's\r\naccount.\r\nIn the second case the conversation went on for much longer. This time the victim more or less confirms that the\r\naffected server was compromised through internet-exposed Remote Access. Upon asking for a decryption price\r\nthey return with a price of 10 BTC. If this is their default price for an individual they likely won't get anywhere\r\nwith their ransom demands, since BTC is on an all-time high as well. The criminals later discount this price to 5\r\nBTC which is still too much and the victim decides not to pay (good choice).\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 4 of 37\n\nJust for fun I took a quick look at their sites code and noticed their 404 page displayed the nginx version in use.\r\nBoth of the chat portals from Mount Locker Version 2 (we'll come to the specifics later) likely use nginx 1.14.2.\r\nWould you like to take a guess when that version was released? How does over 2 years ago (04.12.2018) sound?\r\nTheir main Leak site does not display a version number, but I guess they really prefer legacy stuff 👴\r\nInitial Analysis\r\nBoth of the samples I will be focusing on in this post belong to \"Version 2\" of Mount Locker, because since the\r\ninitial Version of the Ransomware turned up in Sandboxes and Analysis platforms, there were some major changes\r\nmade by the operators of the campaign.\r\nSample 1\r\nfilename: BreakOut.exe, XACQDAPEV.exe\r\nfilesize: 200KB\r\nsha-256: 226a723ffb4a91d9950a8b266167c5b354ab0db1dc225578494917fe53867ef2\r\nssdeep: 1536:ssBoz9GFuIdclwKfVPoawSL20mRbg2DrE1mHkrY0f3r6fR0ZzDWR+3itGSh6ZVvg:ssS3oifBoaXhDWA4G3e\r\nVT First Submission: 11.11.2020 15:26:06\r\nDownload: AnyRun | Malware Bazaar | VirusTotal | HybridAnalysis\r\nSample 2\r\nfilename: QuantumQuditSimulator.exe\r\nfilesize: 532KB\r\nsha-256: e7c277aae66085f1e0c4789fe51cac50e3ea86d79c8a242ffc066ed0b0548037\r\nssdeep: 6144:Q5fW8eILySdSS4JoHjnJVZJQQIreKsuKu3a2WQe0gz+Y:OeILzSS5jnJ/JTu3zWtqY\r\nVT First Submission: 18.11.2020 19:33:26\r\nDownload: AnyRun | Malware Bazaar | VirusTotal | HybridAnalysis: unavailable\r\nAs always we'll start out with a quick look at Detect it easy to see what we are working with. In both cases it\r\ndetects Virtual Basic 6 yay! Checking the imports to be sure: yep they only Library we see is MSVBVM60.DLL,\r\nthe Microsoft Virtual Basic Virtual Machine (yo dawg, heard you like virtual things :D). Although the entropy\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 5 of 37\n\ngraph didn't directly indicate a packer I doubt that a serious RaaS Group would write Ransomware in VB.6 these\r\ndays.\r\nThe next step is to check out the Resources with Resource Hacker. Let's start off with one of the embedded String\r\nTables. The marked function names are definetely a red flag and indicate that this is in fact a VB.6 packer.\r\nThe second curious thing is a PE File! But wait, take a closer Look. There is something wrong with the DOS and\r\nRich Header. The \"DOS String\" should normally read \"This programm cannot be run in DOS mode.\" whereas this\r\none reads \"This!prohsam!caolpt be tum gm DOS kndc.\". 🤔 Looks like some of the characters were shifted by one\r\nand then a few were skipped. But instead of figuring it out by hand we'll take a look at the code next and unpack\r\nit, since this is just a diversion after all.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 6 of 37\n\nBecause VB.6 looks absolutely horrendous in IDA or Ghidra we'll have to use a more specialized tool,\r\nVB.Decompiler Pro in this case. Upon opening the samples with it we notice that most of the implemented\r\nfunctions are dead code. This is also apparent when we look into the GUI Designer (see below), because there is a\r\nGraphical User Interface that we never get to see upon running it in a Sandbox. Sample 1 seems to be a game\r\ncalled \"Break-Out\" and Sample 2 is called \"Quantum Qudit Simulator\", some kind of calculation programm from\r\nthe National University of Ireland. Of course both of the Developers of the original applications do not have\r\nanything to do with Mount Locker Ransomware, because these samples were obviously altered to act as a packer\r\nfor it. Even after a lot of search engine magic I couldn't find out where they got these programs from, but if you\r\nfind them anywhere let me know!\r\nNow let's look at some decompiled VB.6 code! The API declarations below basically reveal what we already saw\r\nin the string table in the resources.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 7 of 37\n\nI'll try to present the next lines of snuck-in code in a logical order. The first step is to load the PE resource we saw\r\nearlier.\r\nUp next is a long boi call to VirtualAlloc (sorry if the font in the screenshot is a bit small). Also take note of the\r\nvariable names like var_804C (which sometimes indicates this code was inserted at a later date) and the\r\nobfuscation of the arguments to VirtualAlloc.\r\nLast but not least we have a call to VirtualProtect and RtlMoveMemory (renamed to CopyMemory in the API\r\nDeclarations above), again with the same obfuscation, to change the protection of the allocated Region in memory\r\nand moving the payload there. This is as far as we are going to look into this right now though, since this is just\r\nsupposed to be a quick look into this \"backdoored\" application and we'll continue by unpacking the Ransomware\r\nsample now.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 8 of 37\n\nUnpacking\r\nSince I'm pretty lazy and a big fan of Open Analysis Live I thought I'd give Unpac.me a chance at this packer first.\r\nUnfortunately something went wrong here (I did not expect more than one Child Binary), but that has to be\r\nexpected since Classifier Issues with VB.6 Code is one of the Challenges that they are still working on.\r\nThat should not deter us from unpacking it manually though! The easiest and fastest way would be to set a\r\nbreakpoint on CreateProcessInternalW and dump it from there if applicable.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 9 of 37\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nAgain, sadly this does not what we want here. Apparently this sample utilizes Self-Injection, so the call to\r\nCreateProcessInternalW won't take us to the unpacked Child Process but rather a Powershell script. This seems to\r\nbe part of the actual Ransomware rather than the packer, so we are too far in already.\r\nI'll have to do it the old fashioned way then. One Breakpoint on VirtualProtect and one on the Return from\r\nVirtualAlloc. For good luck I'll also throw in one on IsDebuggerPresent.\r\nTurns out altering the return value of IsDebuggerPresent is not necessary for Sample 1, it just unpacks the child\r\nregardless. Sample 2 on the other hand will throw an error message and terminate.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 10 of 37\n\nThe disadvantage of breaking on VirtualProtect or VirtualAlloc in the case of VB.6 is that the Microsoft Visual\r\nBasic Virtual Machine calls both of them multiple times in the setup process. Instead of \"Following in Dump\"\r\nevery time we hit a breakpoint it is far easier to just look for the jump to the unpacked PE. The fastest way to get\r\nyou there is placing a breakpoint on VirtualFree which (atleast in case of these two samples) is called right before\r\nthe function call that jumps into said Ransomware PE. Once you are there, step into the function and follow the\r\naddress in jmp ecx to find the unpacked sample. Below I also included a screenshot (green border, blue/white font)\r\nof the packed sample in a hex-editor to show that the binaries actually differ.\r\nA quick look at the memory map before we'll dump the segment and go right ahead.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 11 of 37\n\nOf course the first thing after dumping the binary for me is to throw it into PE-Bear. Looks like it is still in it's\r\nmapped state, so let's continue by unmapping it. (Screenshot: left = mapped, right = unmapped)\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 12 of 37\n\nOne more thing: Don't forget to adjust the Image Base or your Disassembly/Decompilation results will look like\r\ngarbage. Ask me how I know 😅\r\nJust to verify that we (likely) don't have another packed stage here I'll take a look at it with Detect it Easy. Seems\r\ngood, let's continue with Static Analysis!\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 13 of 37\n\nStatic Analysis\r\nFirst let's check the compiler timestamps on the samples we have. Both x86 binaries contain the same one from\r\nNovember 6th 2020 10:47:05 UTC. Interestingly the x64 Version was (allegedly) copiled just one second earlier.\r\nTo make a list of what to expect from this Ransomware I would normally go through the Imports and make some\r\nmore or less educated guesses what it would do with those functions, but this is again a perfect opportunity to try\r\nout a new tool: capa by Fireeye. It was released about 6 months ago and it looks like I've been really missing out.\r\nAs you can see below I made one minor correction after I finished the analysis, but besides that the tool is pretty\r\nspot on and will definitely save you some time in triage-like situations.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 14 of 37\n\nBecause it will be easier to \"navigate\" the functions of the Ransomware if you know in what context and point in\r\ntime the log messages are printed I extracted them all. Quite interesting to see this level of verbosity in a\r\nRansomware strain that has been deployed in a few attacks already in the last months. It will become even more\r\napparent in the course of this analysis, but the developers are obviously still trying to figure things out.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 15 of 37\n\nAlright, enough 🦆-ing around, let's dive in! Ghidra 9.2 is the tool of choice this time around since I wanted the\r\ncomfort of a decompiler. To start off I took a look at it function-by-function and renamed them to reflect what\r\neach one of them does. The following screenshots will show most of the peripheral functions and setup-related\r\nthings. The Crypto functions will be discussed in a separate chapter. Something to watch out for: there is quite a\r\nlot of variable re-use happening in certain functions, so I either renamed the variable to something that would\r\nreflect the value it was asigned last or I kept the original name generated by the decompiler to avoid confusion.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 16 of 37\n\nWe'll start at the entrypoint. From here the sample branches off into two functions: mw_getArguments will handle,\r\nas the name suggests, the arguments given by the operator and mw_mainLockRoutine from where multiple\r\nperipheral functions are called.\r\nGiven that the Ransomware sample accepts commandline arguments it speaks for the asumption, that Mount\r\nLocker is designed to be manually operated by criminals. The screenshot below depicts the function\r\nmw_getArguments that handles the supplied commandline options:\r\n/log: --\u003e can be used with 'F' or 'C' to write a Log to a File or Console respectively\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 17 of 37\n\n/scan: --\u003e valid options: L | N | S, scan attached drives where L = Local Drive, N = Network Drive, S =\r\nNetwork Share\r\n/marker: --\u003e create a specified marker file on each volume to be encrypted\r\n/nodel: --\u003e do not delete the Ransomware binary after execution\r\nThe third function we will take a look at is what I would call the \"Main Routine\". From here a lot of substantial\r\nfunctions of the Ransomware are called. After allocating the debug console (if the argument flag was set) it will\r\ncheck if a Mutex from another Mount Locker process was already set. Before the actual file encryption functions\r\nare called it will delete the Volume Shadow Copies and terminate running processes.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 18 of 37\n\n1) To make sure the Ransomware only runs once on a particular system it will create a Mutex that is derived from\r\nthe Volume Serialnumber of the System Drive e.g. 1AB6AEEA4356D5DDA86ADABB750D5B57. If it fails to\r\nretrieve the Serialnumber via GetVolumeInformationW it will default to a Backup value: 0x41a207bd which is\r\npermuted in the same way. Should CreateMutexW fail and return NULL or System Error 0xb7\r\n(ERROR_ALREADY_EXISTS) the mw_mutex function return false, write an error message to the log and the\r\nRansomware will terminate. Otherwise the function will return true and the execution continues.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 19 of 37\n\n2) Up next we have a Powershell script that is written to %temp% (Path via GetTempPath) with the Filename\r\ndetermined via GetTickCount and the extension .tmp. In the next step we'll check what it actually does.\r\nFor decoding and decompressing the Powershell script the most popular tool is of course Cyberchef. Because I\r\nlike to try out new/alternative tools we'll use Binary Refinery today! It is a great substitute for Cyberchef in\r\nMalware Analysis/Triage situations and you can also use it as a Library for your Python projects / tools. And don't\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 20 of 37\n\nforget about the extra street cred for using a CLI tool 😎 As you can see in the screenshot below the first half of\r\nthe Powershell script is used to delete the Volume Shadow Copies via vssadmin.exe and to stop all services that\r\ndon't run from the Windows System Directory.\r\nI shortened the process exeption list, but in total it contains 657 filenames of Webbrowsers, System Tools, a lot of\r\nAnti-Virus and EDR Clients and even ollydbg.exe, how nice of them! (or maybe they use it internally for\r\ndebugging? 🤔). Every process running on the system that does not belong to the Ransomware, run from the\r\nWindows directory and is not on the Exception List will be terminated.\r\n3) In line with their verbose logging functionality Mount Locker will separate its log output by the volume type of\r\nthe targeted drive. The interesting \"discovery\" in this case is that the encryption of Network Shares is not\r\nsupported yet and therefore Mount Locker won't proceed with file encryption on such volumes.\r\nThe Log strings in the mw_lockerDirCheck also allow for interesting insights into features into (upcoming)\r\nfeatures. For one the are messing around with NTFS Reparse Points which is rarely seen in Malware and log\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 21 of 37\n\nmessages like \"[OK] locker.dir.check \u003e target_hidden\" indicate that they are also trying to attack hidden\r\ndirectories.\r\nThe generation of the ClientID is based on the return of GetComputerName which is used with a 32 character\r\nhardcoded string to compute the 64 character long ClientID String found in the Ransomnote.\r\nMount Locker ships with a list of Directory Paths and extensions to be spared from encryption to keep the\r\nOperating System ... operational. We'll see in the dynamic Analysis Chapter how well that actually works.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 22 of 37\n\nTo constantly remind the victims of the Ransom and increase psychological pressure Mount Locker registers the\r\nRansomnote to be opened when the user tries to access an encrypted file. The lower screenshot is taken from the\r\nHatching Tria.ge Report for Sample 2 which you can find here.\r\nThe second file that is written to %temp% during the execution of Mount Locker is yet another one with its name\r\nderived from the return value of GetTickCount. After the Ransomware finished the encryption routine and if the\r\n/nodel flag was not supplied it's time to clean up and Mount Locker will delete itself by invoking e.g. cmd /c\r\n\"C:\\Users\\admin\\AppData\\Local\\Temp\\\\0F7565F4.bat\" \"C:\\Users\\admin\\Desktop\\mountlocker.exe\" .\r\nCryptographic Functions\r\nAnother useful Tool for Ransomware Analysis is PEid with the KANAL plugin. KANAL is short for \"Krypto\r\nAnalyzer\" and tries to detect crypto algorithms, functions and constants. In the case of Mount Locker it only\r\nrecognizes the RSA Public Key import via the WinCrypt API.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 23 of 37\n\nAs the function name suggests mw_importPubkey imports the RSA Public Key that is ebedded into the binary.\r\nThis function also generates the Session Key used with ChaCha20 via __rdtsc + Sleep (more on that later) which\r\nis encrypted with the RSA using CryptEncrypt. Once that is done the ClientID will be generated and the\r\nRansomnote is registered to opened with the file extension of the Ransomware.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 24 of 37\n\nTo take a closer look at the supplied RSA Public Keys I dumped them from both samples with x32dbg.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 25 of 37\n\nJust as a quick \"sanity check\": Yes, the Public RSA Keys differ between the samples. Wouldn't be the first time\r\nthat lazy Ransomware operators reused the same RSA Keypair in multiple samples, so I think it's worth to check\r\natleast.\r\nIn the screenshot below we see the ChaCha20 Block function which is an important component of the Algorithm.\r\nIt can be identified by the expand 32-byte k magic value.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 26 of 37\n\nSince the folks at Blackberry ThreatVector already spilled the beans, I'll mention it here as well. Instead of using a\r\nsecure Random Number Generator for the File (and Session) Encryption Keys they opted to use __rdtsc, which\r\nreturns the processor time stamp (clock cycles since the last reset) without a Sleep call. The Time Stamp Counter\r\nis a bad way to generate encryption keys because it is a deterministic function that wraps around every ~49 days\r\nand could therefore theoretically be bruteforced (with knowledge about the point in time when __rdtsc was\r\ninvoked, the Sleep call would be used to \"obfuscate\" this). This is nothing new though and with the coverage\r\nMount Locker has received up until now I expect this issue to be fixed by the next version.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 27 of 37\n\nI don't want to throw shade here, but I'm not a fan of detailing Cryptobugs in ongoing Ransomware campaigns.\r\nThe use of GetTickCount (__rdtsc) isn't a huge flaw in itself, but it could very well come in handy if there were\r\nmore flaws in the crypto-implementation used. I strongly recommend to watch @Polartoffee's Talk from\r\nSteelcon2019 where this is addressed as well (the video below is timestamped for your convenience):\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nFun-fact, speaking of Cryptowall: The File extension list in Mount Locker Version 1 contains about 2600 entries.\r\nIt made headlines because it also targets Tax Software (which isn't a common thing, but it has been seen before on\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 28 of 37\n\nseveral occurrences). What I find far more interesting is that they target files previously encrypted by other\r\nRansomware strains as you can see below:\r\nMapViewOfFile is used to map each file into Memory for encryption. Smaller files are mapped according to their\r\nsize and if a file is larger than 0x40000000 it will be mapped in chunks and encrypted.\r\nTo further investigate the File Encryption I used the classic trick of the bait file filled with null bytes to check for\r\npatterns and appended data. As we can see the encrypted file is now 288 bytes longer. They can be divided into 32\r\nbytes for the File Key (which is, as the name suggests, unique for every file) and 256 bytes for the Session Key.\r\nOf course these keys are not prepended to the fileheader like that: the File Key is encrypted with the Session Key\r\nusing ChaCha20 and the Session Key is encrypted with the public RSA Key through CryptEncrypt.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 29 of 37\n\nThis can be confirmed with Ghidra: Both encrypted keyblobs are prepended to the file with WriteFile.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 30 of 37\n\nSince most Ransomware groups don't try to reinvent the wheel when it comes to crypto implementations they\r\noften get their inspiration from Open Source projects. I looked around Github for a while to find C++\r\nImplementations of ChaCha20 that would fit what we see in Mount Locker. The Repository linked below is just a\r\nguess at what they could have used, since this seems to be the oldest ChaCha20 C++ Repo on Github and many\r\nImplementations borrow code from it. The structure and compartmentalization into functions also looks very\r\nsimilar. Berstein's reference Implementation for example is constructed differently. I crossreferenced it with\r\nRFC8439 and it looks solid at first glance. Parts of the Quarter Round Mechanism and the Block function are\r\ndirectly copied from the Wikipedia article on Salsa20/ChaCha20 though and the code comments are a bit too\r\nsketchy IMO 😂\r\nDynamic Analysis\r\nLet's first take a look at the Ransomnote. In all investigated versions of Mount Locker it is delivered as a HTML\r\nfile named RecoveryManual.html. It exhibits a lot of the by now classic scare tactics we know from Ransomware\r\ngangs in the Realm of \"Don't try to decrypt your files, we are the only ones who can help\" and of course the\r\nThreat that they would release the stolen data if the Ransom would not be payed in time. Communication with the\r\ncriminals is to be done through a Webchat via Tor with no Clearnet alternative except for contacting them by E-Mail (accounts registered with Protonmail, which is still the most popular Mail hosting service for Ransomware\r\noperators. See ransomware.email for more information).\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 31 of 37\n\nDuring the \"Detonation run\" I opened Process Monitor for a better Overview of what's going on. Because I didn't\r\nwant Mount Locker to terminate it, I renamed it to firefox.exe since this process name is on the exception list 👍\r\nAs you can see below the Ransomware has four Subprocesses in total: Powershell + vssadmin for process\r\ntermination and restore point deletion and cmd + attrib for self-deletion.\r\nI ran Mount Locker with the /log:F argument to have it log to a file. It created a file on the Desktop named\r\nexecutableName.exe.log, the contents of which can be seen below. The first few lines are related to the deletion of\r\nthe Volume Shadow Copies. Since Mount Locker currently is not capable of escalating priviledges and I ran the\r\nsample without administrative rights the Shadow Copies were left untouched.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 32 of 37\n\nSince it is probably one of the most interesting debug features of Mount Locker here is another snippet from the\r\nLog File showing the statistics of the System Drive Encryption.\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 33 of 37\n\nAnd if you would like to know what happens when Mount Locker V2 is run with local admin priviledges, because\r\nI already hinted that it doesn't go well: After the machine is rebooted (which some Users do instinctively after a\r\nRansomware infection) Windows will not be able to boot because the bootmgr file was encrypted. I'm not sure if\r\nthey didn't test this case or they forgot to include it in their exception lists, but the User will certainly not be able\r\nto contact them with a (temporarily) bricked machine.\r\nConclusion / Key Takeaways\r\nUp until now only Mount Locker V2 x86 binaries have been submitted to analysis platforms in a packed\r\nstate. Similar to other Ransomware Gangs they opted to deliver their x64 executables as DLLs.\r\nNo Obfuscation beyond the initial packing\r\nNo Persistence Methods used\r\nDepending on the Users permissions: Mount Locker either fails to delete Shadow Copies and files on other\r\ndrives or it will encrypt critical system components and render the system unusable after a reboot\r\nMultiple features are not implemented in Version 2\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 34 of 37\n\nThe Operators behind Mount Locker are obviously just starting out, as the observed Ransomware samples are still\nvery verbose and noisy on execution. Although the are not nearly as active as a lot of other well established\nCrimeware Groups, I expect to see more attacks from them in the upcoming year 2021. I hope this blog post will\nbe somewhat helpful in future investigations on this Ransomware strain and of course I will be keeping up with it\nas well.\nAlright, that's it for now. Thank you for reading this blog post! If you have got any feedback please let me\nknow and don't miss the Yara Rule, Mitre Att\u0026ck List and IoCs below 🤓 See ya in 2021 👋\nYara Rule\nimport \"pe\"\nrule RANSOM_MountLocker_V2 {\n meta:\n description = \"Detects Mount Locker Ransomware, Version 2 x86 unpacked\"\n author = \"f0wL \"\n reference = \"https://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-rans\n date = \"20.12.2020\"\n tlp = \"WHITE\"\n hash1 = \"226a723ffb4a91d9950a8b266167c5b354ab0db1dc225578494917fe53867ef2\"\n hash2 = \"e7c277aae66085f1e0c4789fe51cac50e3ea86d79c8a242ffc066ed0b0548037\"\nstrings:\n //picks up on the Volume Serial Number Permutation in function mw_mutex\n $mutex_shift = { 8b c1 c1 c8 ?? 50 8b c1 c1 c8 ?? 50 8b c1 c1 c8 ?? 50 51}\n $x1 = \"powershell.exe -windowstyle hidden -c $mypid='%u';[System.IO.File]::ReadAllText('%s')|iex\" f\n //$x2 = \"explorer.exe RecoveryManual.html\" fullword wide\n $x2 = \"RecoveryManual.html\" wide\n $x3 = \"expand 32-byte k\" fullword ascii\n $x4 = \"**/!\\\\ YOUR NETWORK HAS BEEN HACKED /!\\\\  \n\" fullword ascii\n $s1 = \"[SKIP] locker.volume.enum \u003e readonly name=%s\" fullword wide\n $s2 = \"[WARN] locker.dir.check \u003e get_reparse_point gle=%u name=%s\" fullword wide\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\nPage 35 of 37**\n\n$s3 = \"[ERROR] locker.file \u003e get_size gle=%u name=%s\" fullword wide\r\n $s4 = \"[OK] locker \u003e finished\" fullword wide\r\ncondition:\r\n uint16(0) == 0x5a4d and filesize \u003c 600KB\r\n and pe.imphash() == \"1ea39e61089a4ea253fb896bbcf01be5\"\r\n and $mutex_shift\r\n and 2 of ($x*)\r\n and 2 of ($s*)\r\n}\r\nMITRE ATT\u0026CK\r\nT1012 --\u003e Query Registry --\u003e Discovery\r\nT1027 --\u003e Obfuscated Files or Information --\u003e Defense Evasion\r\nT1055 --\u003e Process Injection --\u003e Privilege Escalation, Defense Evasion\r\nT1059 --\u003e Command and Scripting Interpreter: PowerShell --\u003e Execution\r\nT1070 --\u003e Indicator Removal on Host: File Deletion --\u003e Defense Evasion\r\nT1076 --\u003e Remote Desktop Protocol --\u003e Lateral Movement\r\nT1082 --\u003e System Information Discovery --\u003e Discovery\r\nT1083 --\u003e File and Directory Discovery --\u003e Defense Evasion\r\nT1112 --\u003e Modify Registry --\u003e Defense Evasion\r\nT1129 --\u003e Shared Modules --\u003e Execution\r\nT1134 --\u003e Access Token Manipulation --\u003e Defense Evasion, Privilege Escalation\r\nT1486 --\u003e Data Encrypted for Impact --\u003e Impact\r\nT1489 --\u003e Service Stop --\u003e Impact\r\nT1490 --\u003e Inhibit System Recovery --\u003e Impact\r\nT1546 --\u003e Event Triggered Execution: Change Default File Association --\u003e Privilege Escalation, Persistence\r\nT1562 --\u003e Impair Defenses: Disable or Modify Tools --\u003e Defense Evasion\r\nIOCs\r\nMount Locker\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 36 of 37\n\nVersion 1\r\nf570d5b17671e6f3e56eae6ad87be3a6bbfac46c677e478618afd9f59bf35963\r\nVersion 2\r\n32-bit\r\n226a723ffb4a91d9950a8b266167c5b354ab0db1dc225578494917fe53867ef2\r\ne7c277aae66085f1e0c4789fe51cac50e3ea86d79c8a242ffc066ed0b0548037\r\n64-bit\r\n2d2d2e39ccae1ff764e6618b5d7636d41ac6e752ce56d69a9acbb9cb1c8183d0\r\nAssociated Files\r\n[8-digit hex].bat - Batch script\r\n~[9-digit int].tmp - Powershell script\r\n--\u003e both of these files will be dropped in C:\\Users\\username\\AppData\\Local\\Temp\\\r\nRecoveryManual.html\r\nOnion URLs\r\nhxxp://mountnewsokhwilx[.]onion\r\nhxxp://zsa3wxvbb7gv65wnl7lerslee3c7i27ndqghqm6jt2priva2qcdponad[.]onion\r\nhxxp://soxbhgx23tabwh2k447b2tljcu5tktdc2elmi2ls7huzntrhknygxsqd[.]onion\r\nhxxp://lhvqpdydwvtgy2ficsvamluobvonnitji5jgpfvc7c5pj6ci35gurjyd[.]onion\r\nhxxp://4bt5hu4vid5c7uq4ioszgzwi4ix6qon7a226cxowgrnomfgxl5b3wtid[.]onion\r\nSource: https://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nhttps://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html\r\nPage 37 of 37",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://dissectingmalwa.re/between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html"
	],
	"report_names": [
		"between-a-rock-and-a-hard-place-exploring-mount-locker-ransomware.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434288,
	"ts_updated_at": 1775826758,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e43b1fbb678979791654476a5c293850c9f7e6c6.pdf",
		"text": "https://archive.orkl.eu/e43b1fbb678979791654476a5c293850c9f7e6c6.txt",
		"img": "https://archive.orkl.eu/e43b1fbb678979791654476a5c293850c9f7e6c6.jpg"
	}
}