{
	"id": "323ee931-0451-4f4e-96b4-e088abcf5057",
	"created_at": "2026-04-06T00:13:04.324009Z",
	"updated_at": "2026-04-10T03:30:32.925749Z",
	"deleted_at": null,
	"sha1_hash": "182193dde53bf73dfd2b584e1da77682c80b362f",
	"title": "It's A File Infector... It’s Ransomware... It's Virlock",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5020628,
	"plain_text": "It's A File Infector... It’s Ransomware... It's Virlock\r\nArchived: 2026-04-06 00:02:47 UTC\r\nVlad Craciun, Andrei Nacu \u0026 Mihail Andronic\r\nBitdefender, Romania\r\nCopyright © 2015 Virus Bulletin\r\nTable of contents\r\nAbstract\r\nWin32.Virlock, with all its variations, is both a new kind of file infector and a piece of ransomware (screen-locker) at the same time. In this paper, we aim to cover the techniques used by this virus and discuss methods that\r\ncan be used to detect and disinfect systems affected by it.\r\nVirlock uses several techniques, including code obfuscation, staged unpacking, random API calls and\r\nlarge/redundant areas of decrypted code, to make it difficult to analyse. It also protects its code by decrypting only\r\nthe sequences that are going to be executed. After a sequence of code is executed, Virlock encrypts it again. By\r\nstaggering the decryption/encryption process, it ensures that a memory dump at a certain point will not reveal its\r\nfeatures but only the piece of code that is being executed at that time.\r\nThere is also a moment in its first execution when it shifts its shape by changing certain instructions and\r\nencryption keys so that new generations will look different. Each new infection is different from any other, mostly\r\nbecause of the timestamps that play an important role in computing the encryption keys. Having these protection\r\nmethods will also make any clean-up attempt quite a challenge. The disinfection process for this virus involves\r\nsearching inside malware code for specific instruction arrangements.\r\nWe will present some ideas that could help in detecting and disinfecting a Virlock-infected system.\r\nIntroduction\r\nMalware has grown significantly in the last decade, both in prevalence and complexity. It has developed from\r\ninnocent bad jokes and simple trojans to advanced polymorphic file infectors, rootkits and ransomware. While\r\nsecurity companies have studied all the types of malware and built specific categories for them, it can be difficult,\r\ntoday, to categorize a malicious application as a trojan, a piece of spyware, or even a file infector, as they tend to\r\nbe more complex and to embed several different kinds of behaviour at once.\r\nSecurity vendors have been forced to develop different kinds of engines to reach faster conclusions in malware\r\nanalysis, be it static or dynamic, but security products by definition are usually a step behind the malware creators,\r\neven if we try to minimize that time-interval. The security industry had tried to figure out better solutions and\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 1 of 26\n\nbetter engines to prevent malware execution in advance by using artificial intelligence, but no matter how hard we\r\ntry, or how much time we invest in research, there is always something new which doesn’t get caught. There are\r\nmany cases in which we reach the conclusion that an engine is not doing the best to protect against a new piece of\r\nmalware, or that making a small improvement will slow down the entire product. In some cases we reach the\r\nconclusion that a particular detection method is simply not adequate for a specific piece of malware.\r\n1. Ransomware and file infector evolution\r\n1.1 Old file infectors, behaviour and purpose\r\nKnown categories: appenders, prependers, EPO, polymorphic, interleaved.\r\nPurpose:\r\nThe first file infectors were just bad jokes or proofs of concept. The earlier ones interleaved malicious code with\r\noriginal application code or prepended malware code to a clean application. By prepending the malicous code to a\r\nclean application, the authors increased the time needed for analysis, and also gained time for their malware to\r\nspread while users were searching for solutions. This is also a safe way to expose users’ computers to hackers; file\r\ninfectors act like agents, collecting confidential user data, or continuously delivering other kinds of malware to the\r\ninfected system.\r\nBehaviour:\r\nMalicious code is executed first, infecting the system or ensuring it is running within another process or thread\r\nand eventually deploying any missing files, then it executes the original application. When a portion of the clean\r\napplication is executed, the malware will also be executed at some point, this being triggered by a patched API\r\nimport or by malicious code insertion. After the malicious code has finished running, the clean application’s code\r\ncontinues to be executed from where it was left off.\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 2 of 26\n\nFigure 1: Example of a common file infector (appended code to clean application).\r\n1.2 Old screen-lockers: behaviour and purpose\r\nPurpose:\r\nAn easy way to get money from users by blocking access to their working environment. (Childish play for\r\ngrownups!!!)\r\nBehaviour:\r\nThis kind of malware creates an additional desktop and switches to the new environment, just as if another user\r\nhad logged on. Some of them may encrypt user files, but most of them don’t. The ones that do encrypt user files,\r\nlike some CryptoLockers, do not lock the user’s screen, because the damage is already at a stage where the user\r\nmight wonder where the backup is, or whether a decryption tool is worth paying for.\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 3 of 26\n\nFigure\r\n2: Ransomware blocking user screen and requesting payment.\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 4 of 26\n\nFigure 3: RSA1024 CryptoLocker displaying message to user.\r\nLet us mention some of the well known pieces of ransomware among both families:\r\nACCDFISA, PornoBlocker, Rannoh, IcePol, CryptoWall, CoinVault.\r\nIn the following chapters we will uncover the main features and components of Virlock; however we are not going\r\nto focus on the infection process. This type of malware has the vaccine within itself, but only applies it for each\r\ninfected file at runtime. We will focus mainly on its design and its abilities to sneak past some security solutions.\r\n2. Analysing Virlock, Refining Behaviour, Combining Purpose\r\nVirlock combines the technology of file infection with the screen-locking features of regular screen-lockers. The\r\nauthors embed both infection and disinfection tools, throwing away the management system to bind infected users\r\nto some private decryption keys. Their remaining concern is about users who are willing to pay their fee rated in\r\nbitcoins.\r\nThe screen-locking picture is very similar to that of those pieces of ransomware that pretend to be some higher\r\nauthority with full rights to request certain amounts of money from home-users – for example as fines (see Figure\r\n4). Most texts appearing on the locked screen are trying to scare the users, for example threatening them with\r\nprison for up to five years or more if they do not pay the money. \r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 5 of 26\n\nFigure 4: Virlock screen lock.\r\n2.1 Analysing Virlock – refining behaviour\r\nVirlock is changing the way in which the infection process takes place:\r\nIt has an ingenious polymorphic engine (most file infectors don’t come with such an engine), making the\r\ndetection process more difficult with each infected system.\r\nIt doesn’t just insert a piece of code into the clean application as most file infectors do, but the entire clean\r\napplication becomes a small piece of the malware itself (similar to Morto/Sality/ACCDFISA).\r\nIt uses techniques to cheat users at first glance (seen in a few other pieces of malware), to bypass users’\r\ndoubts that an infected file is really malicious.\r\nIt has a lot of features (not new, but different) that make the reverse-engineering process more difficult,\r\noverload the analysts and annoy them.\r\nIt has screen-locking (borrowed from screen-lockers) to increase the time taken to get to an infected sample\r\n– most home-users prefer to reinstall their operating system rather than trying to remove the malware. \r\nIt uses multi-threading and rooting into the environment to get full control over the infected systems\r\nwithout the need for drivers, and to execute different paths inside the same application, but from different\r\npoints of view (running processes/services/threads).\r\n2.1.1 Not embedding malware code, but embedding a clean file\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 6 of 26\n\nThe infection process is somewhat different from the infection process of other known file infectors. However,\r\nthere are small similarities between Virlock and both the Sality file infector and the ACCDFISA ransomware:\r\nVirlock and Sality: both replace the clean application with the malware which contains the original\r\napplication packed or modified.\r\nVirlock and ACCDFISA: ACCDFISA uses the RAR archiver to make all the infections self-extractable –\r\nthis is very similar to Virlock’s behaviour but with the small difference that Virlock uses its own techniques\r\nto accomplish the same behaviour. \r\n2.1.2 Anti-analysing techniques\r\nAt the moment we know about five different Virlock versions. They’re not too different but they do differ in such\r\na way that some simple checks will not catch them all.\r\n2.1.2.1 Code obfuscation\r\nOne of the main techniques used to harden the reverse engineering and analysis process is obfuscation.\r\nObfuscation is present in all five versions and is similar between some and different between others. However,\r\nwhile obfuscation may contribute to detection, it is not a key-point in doing that.\r\nFigure 5 shows some screenshots of obfuscated code from four different versions. \r\nFigure 5: Obfuscated code inside four different Virlock versions.\r\nIf we are going to trace the entropy of those pieces of code, or count the number of some target instructions which\r\nrepeat excessively, we can create some checkpoint conditions that Virlock infections will not pass. Code can be\r\nobfuscated in lots of configurations, but some of them are built based on some basic principles. It is not too\r\ndifficult to observe the criteria with which an obfuscation engine was built.\r\nWe could also de-obfuscate some instruction blocks by following the true aim of an obfuscated piece of code.\r\nHowever, de-obfuscation becomes irrelevant when one can look at the execution traces. They are still a plus when\r\nbuilding documents to reveal the true meaning of some code.\r\nObfuscation also contributes to making the static analysis procedure more difficult.\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 7 of 26\n\n2.1.2.2 Anti-debugger\r\nThere are lots of anti-debugger techniques, and usually, malware creators combine those features with techniques\r\nto detect virtual machines, emulators or supervisor tools like PIN from Intel (which allows one to instrument an\r\nexecuted application), or API loggers which inject tracing modules or pieces of code into a target process.\r\nVirlock does not combine all of these, but it uses the strongest of them all, in order to bring the analyst to a point\r\nwhere he/she could easily give up.\r\nMulti-staged unpack\r\nThis is a known technique for making the reverse engineering procedures harder, for both static and dynamic\r\nanalysis. If a piece of code is unpacked piece by piece, one at a time, while it is executed, then performing a static\r\nanalysis could be very difficult. Following the modifications inside a debugger might also be tricky, as some\r\ndebuggers simply refuse to disassemble the code at the point where they think that there is no code in the first\r\nplace. If we add to that the fact that code might re-encrypt the previously executed code, then things get really\r\ninteresting.\r\nFigure 6: Short example of execution flow, following the chunk encryption/decryption template.\r\nStaged unpack \r\nStaged unpack is a feature which minimizes the ‘area’ of ‘plain-text’ code at any time. There is a piece of code,\r\nmore like a template, which repeats itself along the execution of the malware, and at each step:\r\nIt hashes the buffer to be unpacked\r\nIt decrypts the next piece of code, only if the hashes match\r\nIt executes the code inside the decrypted chunk (possible more function-templates)\r\nIt rehashes the unpacked code and alters the hash, inside the code\r\nIt re-encrypts the previously decrypted code.\r\nThe template follows the data structure of a linear linked list, where each node is itself a linear linked list of many\r\npossible function calls. We are seeing linked lists inside linked lists mainly because each function call inside\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 8 of 26\n\nsuch a code-chunk calls another unpack-execute-repack template.\r\nFigure 7 shows the code template for the mentioned trick inside a particular infection, which starts by checking\r\nthe integrity of the packed chunk-code at 40193F, decrypts the buffer at 4019C0, jumps to unpacked code at\r\n401A7E, and finally rebuilds the HASH for the unpacked code which it overwrites at the beginning of the code\r\ntemplate and re-encrypts the entire code starting at 401A7E. \r\nFigure 7: Template-code for staged unpack (yellow square -\u003e unpacked code).\r\nIf someone is trying to make some process-dumps to have a look at the code inside the malware while it’s\r\nexecuting, they might be surprised to find that the malware is almost fully packed, just as it was in the first place.\r\nThe surprise gets bigger, as one is thinking that the malware might have some running threads which did not get\r\ndumped at the time of the process dump and while trying to grab all the memory pieces, one will obtain nothing\r\nmore than the first process dump.\r\nChecking for the presence of a debugger\r\nEvery infected sample checks for the presence of a debugger at some point. There is a standard way to do that,\r\nwhich is by querying a flag inside PEB, called isDebuggerPresent at [fs:[30h]+2], bit 0 (see Figure 8). \r\nFigure\r\n8: Anti-debugger checking inside PEB.\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 9 of 26\n\nIn our example, if it’s being debugged, the code jumps to 0x495A2D . If we are taking a closer look we can see in\r\nFigure 9 that the code is being executed in those conditions. \r\nFigure\r\n9: Code executed when debugger is found.\r\nEventually we find a piece of code looping on itself and calling Sleep.\r\nMost of the time, we can trick the application by changing the condition flags; and thus the condition itself or the\r\nvalue being compared. However, the time spent getting one’s hands on that piece of code is sometimes too much\r\nto continue with the dynamic analysis that way.\r\nRooting inside the execution environment\r\nWe mentioned earlier that the malware does not use all known methods to harden the analysis procedure, but it\r\nuses the strongest of all methods gathered together to at least discourage analysts or to create problems for\r\nautomated tools.\r\nThe technique described in this section does not refer to a behaviour that rootkits are using, but rather to a\r\nbehaviour which spreads the infection inside the infected system, making self-copies and additional processes or\r\nservices, each of them with a couple of threads. If the malware gets to execute inside such a configuration, then\r\nthe synchronization policies between processes and threads will enable it to do its main job, otherwise one will not\r\nget anything useful from it.\r\nAt the beginning of the execution, an infected sample will first create two copies (of the original infection core –\r\nmorphed) inside hidden folders with random names but constant length (eight characters), one located\r\nin %AllUsersProfile% and one inside %UserProfile%:\r\n[%UserProfile%\\[a-zA-Z]{8}\\[a-zA-Z]{8}.exe]\r\n[%AllUsersProfile%\\[a-zA-Z]{8}\\[a-zA-Z]{8}.exe]\r\nThe copy located in the %UserProfile% folder is executed first using CreateProcess and it is also set as a starting\r\npoint inside the startup key:\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 10 of 26\n\n[HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run].\r\nSecond and (in some cases) third copies are written in the %AllUserProfile% folder inside different subfolders.\r\nOne of them is executed like the first copy in order to work together with it (one of the copies ensures that the\r\nother is not killed, and if that happens then it just recreates it), and the other is created as a service to supervise\r\nsome tasks and gain privileged access to operating system components.\r\nIt is important at that point to note that the malware copies are not only different from the first one (using a\r\npolymorphic packer), but also have some key-flags changed. The changing of flags will enable, for example, one\r\nof the copies to execute a slightly different path inside the malware just like a switch-case block. For example, the\r\nmalware self-disinfects the file inside it, only if a certain flag located at a hard-coded address says that this can be\r\ndone.\r\nA series of batch-files and VBS scripts are written on the disk temporarily to help the malware infect files by first\r\nmaking a backup and then overwriting the target file. Scripts are also used to change security policies inside the\r\nregistry, in order to hide the malware or to disable default security features.\r\nThe following is a list of commands altering registry entries:\r\nreg add HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced /f /v HideFileExt /t\r\nREG_DWORD /d 1\r\nreg add HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced /f /v Hidden /t REG_DWORD\r\n/d 2\r\nreg add HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System /v EnableLUA /d 0 /t\r\nREG_DWORD /f\r\nStraight after the installation, the malware tries to brute-force the user logon account password with at least a few\r\nthousand common password templates, and straight after that creates a new user with a random name and full\r\nadministrator rights.\r\nFigure\r\n10: New account created by Virlock after successfully brute-forcing the administrator password.\r\n The following are just a few examples of passwords that had been tried by the malware:\r\npassword, P@ssw0rd, 1234, Password1, 123456, admin, 12345, Passw0rd, p@ssw0rd, Pa$$w0rd, !QAZ2wsx,\r\ntest, sunshine, P@ssword, 1qaz@WSX, 123456789, 12345678, abc123, qwerty, letmein, changeme, master,\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 11 of 26\n\nPassword!, passw0rd, 1q2w3e4r, Password01, password1, hunter, qazwsx, welcome, Welcome123, secret,\r\norig_Administrator, princess, dragon, pussy, baseball, football, monkey, 696969, operator123, N0th1n9,\r\n!qaz@wsx, 1q2w3e4r5t6y7u8i, abcd12345, 7654321, Administrator, q1w2e3r4, q1w2e3r4t5.\r\nA process created with the following command line will discard any possible API-tracer or debugger following the\r\nprocess execution. However, we can still trick such behaviours by altering the code at the entry-point and forcing\r\na debugger to enter first, modifying the parameters for CreateProcess, or using some advanced environment\r\nemulators:\r\nCreateProcessW(\"%TEMP%\\AccMwMEs.bat\", \" \"%TEMP%\\AccMwMEs.bat\" \"C:\\samples\\virlock.exe\" \", …………)\r\n[AccMwMEs.bat]\r\necho WScript.Sleep(50)\u003e%TEMP%/file.vbs\r\ncscript %TEMP%/file.vbs\r\ndel /F /Q file.js\r\ndel /F /Q %1\r\ndel /F /Q %0\r\nWhen an infected sample gets to execute on a clean system, we say that the sample is the original one which is the\r\nprimary cause of the infection. This sample is almost like any other fresh infected sample, which was not executed\r\nafter the infection. There are some flags hard-coded into the malware so that it knows, at runtime, whether the\r\nsample being executed is a fresh infection that has not been executed before, or a drop made by malware targeted\r\nas a service or a malicious process running on the user’s system. Figures 11 and 12 illustrate that behaviour.\r\nHard-coded\r\nvalue\r\nMeaning\r\n0 Installed malware process, usually two synchronized processes\r\n1 Original sample, installs malware components\r\n2\r\nIntermediate actions (while rooting into environment), brute-force user account\r\npassword\r\n3 Multithreading and synchronization (screen-locking, online payment)\r\n4 Sample is running as service\r\nTable 1: Associations between hard-coded values and their meaning.\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 12 of 26\n\nFigure 11: First context switching actions. \r\nFigure 12: Last context switching actions.\r\n2.1.2.3 Anti-emulation\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 13 of 26\n\nMost malware creators integrate into their applications techniques to escape emulation and/or virtual machines.\r\nThere are a number of known methods to accomplish that, we won’t discuss all of them, but mainly those used by\r\nVirlock.\r\nAmong all the techniques which can cause emulators not to work, there are time constraints and unimplemented\r\nemulated API calls. Some emulators which are at the beginning, might have problems overcoming both of these,\r\nothers might give up over time constraints (mainly because authors consider this a performance hit), and other\r\nadvanced emulators could solve all of these in more efficient ways. However, most emulators are somewhere in\r\nthe middle most of the time. We have to consider the possibility that from time to time malware creators reverse\r\nour engines and create malware which might target some of these security engines. If that is the case, then no\r\nmatter how strongly an emulator is built, it might become useless if it’s being targeted by malware.\r\nRandomly chosen API calls\r\nIn an attempt to morph itself, Virlock rebuilds itself inside each infection, decorating the core of functionalities\r\nwith things like random API calls from randomly chosen modules. The malware uses some tables, meaning that it\r\ndoes not choose from a huge set of possibilities but from a finite set. It chooses a random number of libraries\r\nwhich the future infection will import, and from those libraries, some random APIs inside each of them are chosen\r\nas imports.\r\nIf emulators are only emulating a certain set of APIs, then that might impede their ability to continue at the point\r\nof an unknown API call, or an API call not implemented accordingly (Figure 13). \r\nFigure 13: Consecutive blocks of random API calls, trying to escape emulators from the beginning.\r\nIncreasing the number of executed instructions\r\nMost malware, be it packed or unpacked, does not require more than a few million instructions to be executed. At\r\nthat point there are optimizations such as binary translation, which tries to improve performance over emulated\r\nloops like decryption blocks which get to be executed by the real processor and not by the emulator. Binary\r\ntranslation is sometimes combined with file-read operations – the best emulators will try to reduce the number of\r\nread operations and at the same time the maximum number of instructions allowed to be executed.\r\nAll versions of Virlock have a first stage decryption. Without it, any further code execution is basically\r\nimpossible. There is currently no version that executes fewer than 60M instructions for that purpose, and the\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 14 of 26\n\nnumber of instructions increases for bigger files and larger obfuscated loops, to hundreds of millions of\r\ninstructions. Some infections also spread the obfuscated loops over a large area of the infected file, thus passing to\r\nemulators the pain of consecutive file reads, which also is a hit for performance.\r\nThere are many cases where the binary translation for loops is almost impossible if we are not first going to de-obfuscate the code being executed by the loop. Figure 14 shows such a case where just three calls to load more\r\nthan 180 APIs from different modules is taking at least 500k instructions. \r\nFigure\r\n14: Loading some APIs (calling is based on templates discussed in 2.1.2.2).\r\n2.1.3 Cheating users\r\nVery rarely seen in other pieces of malware of this kind (which embed the clean file into a totally different file),\r\nVirlock tries to cheat users into thinking that an infected file is actually what its icon claims it to be. There is a\r\nstage in the infection process where the malware searches inside the registry for the application associated with an\r\nextension type, in order to get to the file containing the icon of the associated application. This is a primary step\r\nfor grabbing the icon and embedding it into the final infected file as an icon-resource. At a first glance, there is no\r\ndifference between the original file and the infected one.\r\nStraight after the infection, the malware will set a registry setting to hide extensions for known filenames. That\r\nway users will see their original files with their relevant icons and no EXE extension, so no one will ever doubt\r\nthe actions of the file.\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 15 of 26\n\nFigure 15: Infected files with extensions revealed.\r\n2.1.4 Polymorphic engine\r\nThe thing that makes Virlock so special is that it has a polymorphic engine which mutates its shape in future\r\ninfections. In this section we reveal the techniques used by the malware to accomplish this task.\r\nStraight after the API-loading process, the malware allocates two buffers (one of them big enough to hold the core\r\nof the malware) to prepare the morphing process for the infections to come. The core of the malware is\r\nsomewhere inside the infected application, but only visible after a few stages of successive decryption procedures.\r\nFigure 16 shows the schematics of the core, which resides packed, layered inside any infected file. \r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 16 of 26\n\nFigure 16:\r\nVirlock core with embedded clean application.\r\nA polymorphic engine is located in our example at 0x45E636 and it is called several times during the installation\r\nof the malware into the newly infected system. Each new malware copy will also have modified the flags\r\ndiscussed previously, accordingly.\r\nFigure 17: Code\r\ncalling the polymorphic engine.\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 17 of 26\n\nThe process of shape-changing is accomplished in two steps, for each of the two dropped files which are going to\r\ndo the real infection. Figure 18 shows the preparation for the reshaping of a self-copy. \r\nFigure 18: Preparing the reshape of a self-copy.\r\nThe first stage consists of preparing random file names, some random seeds, and the buffers involved in the\r\nmorphing procedure (see Table 2). \r\nBuffer alias Buffer size Buffer ptr Description\r\nTAB1 0x200 0x970000 Randomization table 1\r\nTAB2 0x2300000 0x1100000 Working buffer for reshaping procedure\r\nTAB3 0x10000 0x9A0000 Intermediate table 1\r\nTAB4 0x10000 0xAA0000 Intermediate table 2\r\nTAB5 0x200 0x980000 Randomization table 2\r\nTable 2: Buffers involved in the morphing procedure.\r\nWe also see at this step the creation of two different MZPE file headers, originally packed inside the malware (see\r\nFigure 19). Their purpose is to fulfil the creation of the processes which will actually carry out the infection. \r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 18 of 26\n\nFigure 19: Preparing headers for the files to be constructed.\r\nIn the beginning of the second stage, the malware creates a custom import table, also based on time seeds (see\r\nFigure 20). The RDTSC instruction, which provides those time-seeds, is called very frequently, not only to\r\nrandomize stuff, but also for choosing random locations in the target application, where relevant data regarding\r\ndecryption keys, buffer pointers, etc., will be placed. \r\nFigure\r\n20: Building a customized import table.\r\nIn Figure 21, we can see a sequence of instructions which progressively builds the decoration of the new\r\ninfection. \r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 19 of 26\n\nFigure 21: Reshaping a new infection.\r\nAll the steps required for a full file creations are called in a sequence of three consecutive calls, as shown in\r\nFigure 22 {reshape / append / recrypt}. \r\nFigure 22: Main reshape steps for self-copies.\r\n2.2 Analysing Virlock – Combining purpose\r\nWe have seen lots of malware categories that combine their powers with other malware categories. The results of\r\nthose combinations have, most of the time, been some kind of surprise for security products. Not only do malware\r\nauthors learn from security products how to improve their performance, but we also learn from malware authors\r\nthat there is always something which we have not taken into account in the first place. This sounds like an\r\nevolving loop, where security products try to nullify malware actions, while on the other hand malware authors try\r\nto nullify security products’ actions. Well, at least the loop is more like a three-dimensional spiral, otherwise we\r\nwould not exist at this moment in time. \r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 20 of 26\n\nThe following is a brief history of combined malware actions including Virlock, which we find as a reference for\r\nthis case:\r\nViking / Jadtre – rootkit and file infector\r\nCBDoorK – rootkit and backdoor\r\nSality – file infector, botnet, worm\r\nVirlock – ransomware, file infector.\r\n2.2.1 File infector and screen-locker\r\nUntil Virlock, no other malware combined these features. Malware authors who write ransomware are doing it for\r\nthe money – they say as much in their readme files appearing on the infected computers. For example, a piece of\r\nransomware using the Bitlocker feature from Windows tells the infected users that ‘This is just how business\r\nworks, pay and you’ll get your data back.’\r\nEarly versions of ransomware only locked users’ accounts, hoping that some of them would fall into their trap –\r\nand they succeeded, but there is always room for improvement. Some of the next versions tried to encrypt users’\r\nfiles with symmetric keys and locked the users’ accounts, making it more difficult to revert the process. But as the\r\nsecurity products improved their strategies and delivered rescue-CDs to users, malware authors improved their\r\nmethods of cryptography, using asymmetric algorithms, and gave up the screen-locking. When infecting users\r\nwith those kinds of ransomware, malware creators need a management system in order to bind private-keys with\r\nmalware versions. Maybe they did not expect their methods to be so fruitful, but they seem to be overwhelmed by\r\nthe number of infected users and public/private keys. It is not unusual for a user to try to pay, and get a decryptor\r\nwhich attempts to decrypt files from a different infection.\r\nVirlock tries somehow to escape the load produced by the key-infection management system while improving the\r\nold techniques used in locking files and user accounts by embedding the clean file and packing it safe inside the\r\nmalware with random and hard-coded keys. It also tries to crack users’ account passwords, to lock their account in\r\norder to make it as difficult as possible for the users to recover their files. Using the presented technique for file\r\ninfection, security products have to consider an entire arsenal of variables in order to begin a clean method,\r\nbecause it would be very easy to miss a certain hard-coded-key and to damage the file instead of recovering it.\r\n3. Getting to the Core of Virlock\r\nWe’ve seen so far that Virlock uses a template-based reshape, so we can use that template as some kind of regular\r\nexpression to find some inner pylons / code-blocks to start with. Studying the five different versions until now,\r\nthere are certain similarities between them, which will lead us to classify a sample as infected.\r\nIn this chapter we will try to reveal the malware’s weak points and see how those weaknesses may contribute to\r\nstudying it better in all its present forms.\r\n3.1 Revealing the core, inside different malware versions\r\nFirst, there is an initial layer of decryption which will end up by continuing the execution somewhere at\r\nFirstSectionVA+0x400 or FirstSEctionVA+0x1000 with or without additional obfuscated code and possibly a\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 21 of 26\n\nshort second decryption stage (Figure 23). \r\nFigure 23: First chunk of relevant code in all five versions.\r\nThere are two major switch sections inside the malware which choose a path of execution depending on the hard-coded flag discussed in section 2.1.2.2. We will consider the two sections as the core of the malware, as they are\r\npresent inside all versions, no matter how obfuscated the code is, and the path to those functionalities is unique if\r\nan emulator behaves just like a real operating system.\r\nNot all versions are as compact, as shown in Figure 24. There are some cases where junk-code might appear\r\nbetween relevant instructions in our target code, but ignoring them is not as difficult as one may think. \r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 22 of 26\n\nFigure 24: A comparison between all five versions inside context-switch sections.\r\n3.2 Searching for a match \r\nMost detection algorithms will just try to find a relevant piece of code inside a piece of malware. Looking at the\r\ncode shown in Figure 25, we might be tempted to say that we found something relevant for our malware (a\r\nbranching point where it chooses to execute as installed or as a fresh infection). However, in other malware\r\nversions we found other such pieces of code, doing the same thing but with modified instructions. Considering\r\nthis, the detection cannot choose that sequence of instructions to follow, but we need some rules depending mostly\r\non the constant addresses given in the piece of code and the instruction types, which are not so different across\r\ndifferent malware versions. This kind of matching seems to be as powerful as a regular expression-matching\r\nalgorithm, but additional changes have to be considered. \r\nFigure 25: Piece of malware code to decrypt clean file.\r\n3.3 Cleaning infected files\r\nTo recover the clean file from the malware, we need to follow the code until a point at which we can check\r\nwhether the infection contains a clean file (switch-flag == 1) or not (switch-flag != 1). If we do have a clean file,\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 23 of 26\n\nwe need to grab the hard-coded values inside the malware (different with each infected file) and to force the\r\nemulation of decryption functions.\r\nA simple clean procedure is to use the emulation to execute the decryption function. After that, we can grab from\r\nmemory, using the specified variables, the actual clean file. The starting point of a particular clean file inside the\r\nmalware is shown in Figure 26. \r\nFigure 26: Finding clean file using hard-coded variables.\r\n4. Statistics\r\nFigure 27 shows a graphic for the timeline of Win32.Virlock.Gen.1, which is the most widespread version at the\r\nmoment. \r\nFigure 27: Infection timeline for Win32.Virlock.Gen.1.\r\nIn Figure 28, we see how many systems have been infected since March 2015 for the three most common\r\ndetections. Almost 39,700 unique files were detected by Bitdefender on 148 systems in less than five months. The\r\nhighest number of infections were detected in Canada – almost 30,000, representing 75% of all infections. We\r\nexpect a small increase in the next few months as the authors of the malware seem to still be working on it, and a\r\ntotal decrease by the middle of next year, by which time many security products will have solutions for it. \r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 24 of 26\n\nFigure 28: Left: Win32.Virlock.Gen.1, Top-right: Win32.Virlock.Gen.3, Bottom-right: Win32.Virlock.Gen.4.\r\n5. Conclusions\r\nIt seems that malware creators are constantly learning from their mistakes and they always find new ways to\r\nbypass security products, be it with a small improvement such that their sample will not be detected for a few\r\ndays, combining technologies that could force certain security products to redesign their engines (due to\r\nperformance-hits) in order to come up with a feature to successfully detect and clean the malicious application, or\r\nforcing security companies to search for better solutions or to give-up by not being able to keep up with damages\r\ndone by specific malware infections.\r\nVirlock is among the few malware applications which combines different technologies to harden the reverse\r\nengineering process and at the same time to make the creators of security products question their technologies.\r\nThe redesign process of certain engines is not always an easy step, and most of the time this is not a solution. For\r\nexample, to add some features to emulators, in order to execute unimplemented APIs, to track a certain sequence\r\nof generic assembly instructions, or to increase the complexity of search algorithms near to the complexity of\r\nstrstr(), might result in performance hits which will impact the overall functionalities of the security product.\r\nSome designers being inspired in the first place might laugh at the idea that an improvement could be made as a\r\nnext step inside an already evolved tool, but that is not always the case.\r\nWith the advance of malware technologies in the last few years, we find it even harder to revert malware, or to\r\nrevert the infection process and to restore the system to a clean state. Ransomware using asymmetric encryption\r\nalgorithms is constantly destroying user-data requiring money to get data back. More than ever, we need methods\r\nto automate dynamic analysis and at the same time to extract relevant features from different infections along with\r\nimproving the prevention techniques. Model-checking and symbolic simulation may be a solution from that point\r\nof view, and maybe combining that with time-line analysis and control of a running operating system\r\nenvironment, we might prevent, learn and successfully revert much more complex infections.\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 25 of 26\n\nThere is also a small chance that by using classifiers to extract common vector-features from traces obtained from\r\nemulation of such malware, and then dynamically observing the modifications which take place during the\r\ninfection, one could generate the detection process (which resumes to a search problem in the space of files to be\r\nscanned), along with the disinfection process, in just one click.\r\nAcknowledgements\r\nThis work was co-funded by the European Social Fund through Sectoral Operational Programme Human\r\nResources Development 2007 – 2013, project number POSDRU/187/1.5/S/155397, project title ‘Towards a New\r\nGeneration of Elite Researchers through Doctoral Scolarships.’\r\nSource: https://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nhttps://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/\r\nPage 26 of 26",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-its-file-infector-its-ransomware-its-virlock/"
	],
	"report_names": [
		"vb2015-paper-its-file-infector-its-ransomware-its-virlock"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "75108fc1-7f6a-450e-b024-10284f3f62bb",
			"created_at": "2024-11-01T02:00:52.756877Z",
			"updated_at": "2026-04-10T02:00:05.273746Z",
			"deleted_at": null,
			"main_name": "Play",
			"aliases": null,
			"source_name": "MITRE:Play",
			"tools": [
				"Nltest",
				"AdFind",
				"PsExec",
				"Wevtutil",
				"Cobalt Strike",
				"Playcrypt",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434384,
	"ts_updated_at": 1775791832,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/182193dde53bf73dfd2b584e1da77682c80b362f.pdf",
		"text": "https://archive.orkl.eu/182193dde53bf73dfd2b584e1da77682c80b362f.txt",
		"img": "https://archive.orkl.eu/182193dde53bf73dfd2b584e1da77682c80b362f.jpg"
	}
}