Yes, if your computer gets infected by Urausy Lockscreen, it will get locked. Luckily, not forever! Avast protects you against it. In this blogpost we will introduce an infamous lockscreen called Urausy. We will look at its special anti-debugging and anti-reverse engineering tricks, at its communication protocol, and determine what the conditions (if any) are for self-deleting from the compromised system.
Screen-locking malware has been around for some time. It usually spreads through exploit kits. In addition to locking the victim’s computer and demanding a ransom payment, these applications have other similar traits. One of them is a very high level of obfuscation, which is also the case in Urausy Lockscreen.
The original malware dropper (installer) is a file sized between 100 – 150 KB, which later deobfuscates and unpacks the second layer dropper, which has about 50 KB size. The second layer dropper deobfuscated the third layer dropper, which injects itself twice into two different system processes. The third layer dropper is the place where we start this analysis (because the first two layers are not very interesting).
The third layer dropper is a position independent code. This code is run three times during the execution of the process. A very important part of this layer is in the figure below. There is a counter value, which increments every time the code is executed. Then, based on the counter value, malware chooses one of three stages which will be executed by a “CALL EAX” instruction.
If the counter value is zero, malware knows it is being executed in the original dropper (stage 1). If the counter value is one, malware knows it was injected and executed in explorer.exe process (stage 2). If the counter value is two, malware knows it was injected and executed in svchost.exe process (stage 3). The code in all three stages is the same, but the functionality of the code differs depending on the stage currently being executed. See the scheme below for a better illustration of what I mean by layers and stages. The blue oblong represents the innermost layer, which is the deobfuscated malware itself. It is then injected twice into two other system processes.
The first stage begins with a check for presence of a debugger (NtQuerryInformationProcess with ProcessInformationClass = 7 = ProcessDebugPort). If a debugger is detected, the malware ends. The presence of NtSetInformationThread with ThreadInformationClass = 0×11 = ThreadHideFromDebugger means “the debugger will stop receiving debug information or exceptions from this thread.”
Malware then checks if Windows was started in Normal boot or in Fail-safe boot. If Fail-safe boot is detected, malware then attempts to reboot the operating system.
Malware then calls the Windows API function, GetShellWindow, which according to documentation “retrieves a handle to the Shell’s desktop window.” This gives us a handle to the explorer.exe process. After obtaining the explorer.exe handle, Urausy performs an interesting trick. It allocates a block of memory in explorer.exe and copies itself to this memory block (copies only the third level layer). It can then simply call CreateRemoteThread and execute the injected code, however, Urausy employs a more stealthy way to achieve the same result. At first, it maps ntdll.dll from explorer.exe into the memory space of its current process. Then it locates the last 0×10 = 16 bytes from the first executable section of ntdll.dll library and overwrites them with the code as in the figure below.
This code simply jumps to address 0xDE0000. The address 0xDE0000 is the address in explorer.exe memory space where Urausy copied itself. The second patch in ntdll.dll library occurs at function ZwClose, where the first five bytes are overwritten with instruction CALL. This call instruction points to the last 0×10 bytes of the first executable section.
According to documentation ZwClose (or CloseHandle) “closes an open object handle.” Files are among many different types of objects, whose handles can be closed.
The original (unpatched) ntdll.dll library is then unmapped from explorer.exe address space and the modified (patched) ntdll.dll version is mapped to the explorer.exe. When explorer.exe calls ZwClose function (for example in a situation when it closes a file which it previously opened), it first calls the 0×10 overwritten bytes at the end of the first executable section, which jumps to address 0xDE0000 where the code belonging to Urausy lockscreen is injected. The original dropper now ends. The seconds stage will run in the explorer.exe process as long as explorer.exe calls ZwClose function.
The second stage runs in explorer.exe and starts with removing the patches of ZwClose function. It restores the original ZwClose bytes, then it creates the new desktop, in which it executes svchost.exe process. Urausy then injects itself into svchost.exe process and spawns a new thread by calling CreateRemoteThread function. Then malware switches desktops to the newly created one and the second stage ends here. Pretty short and simple compared to the first stage.
The third stage runs in svchost.exe on a different desktop. First it does similar anti-debugging tricks as in stage 1, then it copies itself into the %APPDATA% folder under name skype.dat and establishes persistence by modifying the “Software\Microsoft\Windows NT\CurrentVersion\Winlogon” registry key with value “explorer.exe, %APPDATA%\skype.dat”. This ensures that the lock screen will start when the computer reboots. After that it creates a window covering the whole display screen. It also spawns a few computational threads. One wakes up each 10 milliseconds and checks, if taksmgr.exe (Task Manager) process is running. If yes, it terminates it. Another thread with an interval of 100 milliseconds checks the current desktop and if the current desktop is not the one created by malware, it switches to that desktop.
The third thread creates a file %APPDATA%\skype.ini in which it stores a 4-byte double word value. This thread wakes up each 0xfa0 = 4,000 milliseconds and subtracts number 4,000 from the value stored in the skype.ini file. This goes on until the value in skype.ini becomes negative. When this happens, Urausy deletes itself from the compromised computer.
If we do a little math, we can figure out that the initial value stored in skype.ini file is 5,000 multiplied by 60,000. We know that 60,000 ms equals 60 seconds which equals 1 minute. 5,000 minutes equals 3 days 11 hours and 20 minutes. After this time expires, Urausy deletes itself from computer, no matter if the victim paid the ransom or not.
It is important to emphasize that the computer must be running all the time. If you switch your computer off and turn it on three and half days later, it will not help because the counter in skype.ini was not decreasing when the computer was switched off. This is probably a protection from users who might change the clock, for example, in BIOS.
The last thread is the internet communication thread. This one is very important, because it reports compromised system details to the cybercriminals and it also receives a payload (a localized website displaying the message asking for the ransom).
First of all, Urausy forms a request which consist of the following information: Hash of the user name, volume serial number, magic value hardcoded in the sample, probably affiliate ID, OS version, and ID of detected antivirus process (if not found, this value is zero).
This request is then encrypted with an 8-byte long randomly generated RC4 password and then each byte (0×00-0xff) is replaced by two chars from a hardcoded 512 byte long string. Several ‘-’ or ‘_’ characters are randomly inserted into the final request.
The final request may look like the figure below. Path “/community/” is not the only possible one. We observed samples requesting other paths, including /news/, /forums/ or /forum/.
The following Python script shows how original information can be decrypted from the request.
After the request is sent, malware expects a reply. This reply is also encrypted. It’s format is length (4 bytes), rc4 key (8 bytes), followed by the payload itself. The following Python script illustrates how decryption can be done.
We identified two types of reply. Urausy checks the first 4 bytes of the reply. If these four bytes are equal to “SELF” (part of a message “SELFDELETE”), then Urausy does not wait 3 and half days and deletes itself immediately. We suppose that attackers use this function in cases when they receive a ransom payment. They then unlock the computer sooner than the default self-unlocking occurs. The second type of reply starts with four bytes equal to PK. Do not get confused, it is not a standard PK signature for ZIP files.
It is a custom file format, which begins with PK magic value followed by filename length (1 byte), the actual file name (variable number of bytes), file offset (4 bytes), file length (4bytes). In the figure below, you can see a sample PK file followed by a Python script for extracting all files from PK archive. In our particular example, the first file of the archive is specified by following parameters: filename length equals 0×18 = 24 bytes, filename is “configs/CZ/a-squared.png”, file starts at offset 0x05ef in PK file and its length is 0xc02e.
Among the extracted files, there is an index.html file containing the page displayed to the victim, and there are also many pictures which are loaded and displayed by index.html. This webpage is displayed on the computer screen. Because of execution in different desktops and because of threads killing important system processes, a victim cannot simply get rid of the lockscreen. The computer therefore remains locked.
Conclusion:
Urausy lockscreen contains a ntdll patching and injection tricks to make following the instruction flow more difficult. If a victim waits for a specified period of time, the lockscreen deletes itself no matter if the victim paid a ransom or not. The only condition is that a compromised computer must be running. Readjusting time and date in BIOS does not help. Cybercriminals can remotely unlock the compromised computer in a shorter time than 3 and half days.
SHAs:
8D45088E2553AB3C88567B086DCBD3F6B354D6E05AD5ECE9928BC025ED02C473
F3B1AA73F82D834415E75241E6976EA8C6CC8FF5A0B284C298F5AA73E8AD670A
E4F821E0C469EF6030F1B309A56A313F25A88E4F91A3EF28387785BB07EBCD8E