Unlocking LockScreen

The first anti-debug trick we faced was ‘kernel API modification’. In this case, LockScreen redirects its code flow by modifying the ZwClose API. First, it gets the ZwClose API by calling the GetProcAddress function, then it backs up the first five bytes of ZwClose to a specific location for future restoration. Finally, it adds an unconditional jump which leads the code flow back to itself. Figure 2 shows the ZwClose modification routine, and Figure 3 shows the modified ZwClose function.

Figure 2. ZwClose modification routine.

(Click here for a larger view of Figure 2.)

Figure 3. Modified ZwClose API.

After the modification, it calls the LocalFree API, which eventually calls the modified ZwClose API.

LockScreen will determine whether a debugger is attached to a process by calling the ZwQueryInformationProcess API with the ProcessInformationClass parameter set to 7 (ProcessDebugPort). This API will query the DebugPort field of the EPROCESS kernel structure. A non-zero value in the DebugPort field indicates that the process is being debugged.

Figure 4. Check debug port.

The ZwSetInformationThread is usually used for setting a thread’s priority. However, it can be used to prevent a debugging event from sending from the kernel function bgkpSendApiMessage(). Figure 5 shows an example of such a technique.

Figure 5. Hide thread from debugger.

In Figure 5, ThreadHideFromDebugger (0x11) is set to the ThreadInformationClass parameter when calling ZwSetInformationThread, which results in the ThreadHideFromDebugger setting the HideThreadFromDebugger field of the ETHREAD16 kernel structure. Therefore, the send event to the debugger function is never invoked.

Windows NT-based platforms support multiple desktops, and it is possible to select a different active desktop. LockScreen will create a desktop by calling CreateDesktop with GENERIC_ALL set to dwDesiresAccess. After that, it invokes the SwitchDesktop API (Figure 6), which results in the OS switching to a new desktop which is used for LockScreen to display the scam screen. It will hide the previously selected desktop, with no obvious way to switch back to the old one with our debugger on it.

Figure 6. SwitchDesktop.

LockScreen first lands in the explorer.exe process via injection, then it injects its core code into the svchost.exe process. The injected code creates three threads which kill the taskmgr.exe process, create an autorun registry entry and copy the malware to a specific location. After that, it tries to use the SwitchDesktop API in a loop as a final barrier to the communication routine (see Figure 7).

Figure 7. SwitchDesktop loop.

To prepare the communication data, LockScreen first retrieves the computer name and turns it into a hash by using a custom algorithm. Then it gets the C:\ VolumeSerialNumber by calling the GetVolumeInformation API. Finally, it retrieves the OS minor version by calling the GetVersionEx API. All of the gathered information will form into the structure shown in Figure 8.

Figure 8. Basic computer information.

Next, it encrypts the above data using the RC4 algorithm with the result of the current time-stamp multiplied by 0x18D as the key (QWORD). After the encryption, it will prepend the key to the encrypted data.

Figure 9. Encrypted basic computer information.

In order to generate the C&C server domain name and URL, it will decrypt data from a specific location in the sample using the following algorithm:

data = ((data & 0xFFFF0000) >> (key & 0xFFFF)) ^ (key & 0xFFFF) + ((data & 0xFFFF) >> (key & 0xFFFF - 1) ^ (key & 0xFFFF - 1)

After decryption, it shows the following data:

Figure 10. Decryption result.

It will use the above results and the previously prepared encrypted data to generate the C&C URL via the custom algorithm shown in Figure 11.

Figure 11. C&C URL generation algorithm.

The result of the generation is shown in Figure 12.

Figure 12. C&C URL.

In this way, it hides the basic computer information within the C&C URL, which gives the C&C’s URL random characteristics and makes it hard to detect.

After sending the information, the C&C server will send a big chunk of data back to the bot. First, let’s take a look at the header – which is shown in Figure 13.

Figure 13. Header of C&C response data.

After decryption with the RC4 key and data length specified in the header, it shows the data shown in Figure 14.

Figure 14. C&C response data (clear text).

Note that if the DWORD (offset 0x0C) is 0x464C4553(SELF), it will quit. Only when the DWORD is 0x4b5000(PK) will it decompress the data and write it into 49 different local files which will be used to display the scam page.

In order to display the scam page, it still needs some other information, such as IP address, geo location, etc. This information is actually encrypted in another location of the response data, as shown in Figure 15.

Figure 15. Additional information (key and encrypted data).

After decryption, it shows:

Figure 16. Additional information (key and encrypted data).

It will use the above information to fill the scam page and display it as shown in Figure 1.