Geekly Articles each Day
📜 ⬆️ ⬇️

The first experience in the study of malware under Microsoft Windows

Introduction


Many probably know this feeling of fear for their USB flash drive, plugging it into an “alien” computer. Moreover, if it is impossible to see what is happening in the operating system of this computer because of the rights of the user, and indeed this computer is of “public access” (the audience in an educational institution). And even more lousy feeling when fears are justified: in addition to writing on a flash drive, the virus modifies the data on it in a certain way, and it is crooked.
I ran into this too. And having gotten a sample of the virus on a bogus flash drive, I decided to figure out what else he does and what is the essence of his work, and most importantly, how to expel this infection from computers and “infected” flash drives.
The article will be useful to those who are interested in the field of software analysis, regardless of qualifications and skills (experts can write in the comments about their experience).


Analysis of visible actions collection of information


Even before copying the sample to a USB flash drive, I knew what was happening with such flash drives:

It is not at all difficult to write a program that would restore folders and delete the malware, which was done fairly quickly:

Unfortunately, this method of struggle is inefficient and annoying, because after each pair it was necessary to clean the flash drive again. Therefore, I decided to see what happens on the virtual machine and, accordingly, write an antidote.

Examining a file on a VM


As a VM, Windows XP SP3 on Virtual Box was used. By the way, the analysis itself on the VM indicates the absence of any AntiVM-functions. To analyze the malware, I used quite standard software for this:
')

So, first of all I decided to see what the file is packed with. PEiD showed:

image

It was naive of course to believe that the file was not packed with anything, and after opening the file in Resource Hacker, the guesses were confirmed:



Encrypted resources (possibly a key to decompress, data, or just junk). In any case, the innocent file is no longer similar. I am not strong in disassembling, so I didn’t particularly suspect in ollydbg: I made sure that there was no anti-debugging (at least during installation to the system, there are no readable lines except for the “993” already caught my eye, and the file is still encrypted).

The most common installation paths are: the file is copied to CSIDL_APPDATA under the static name Kmlslc.exe , the startup key is “Kmlslc” in HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Run . After that, the launched file is deleted (most likely it deletes the vmononos already installed on the system, and the path is passed through the command line argument).
By network traffic, you can say that it is a bot. The malware accesses wipmania.com to obtain an external IP address, after which it tries to access several sites by domain names, and bypassing the default firewall:



By the way, when writing the corresponding domains to the hosts file, the bot does not attempt to opt out. In addition, the functions HttpSendRequest, InternetWriteFile, URLDownloadToFile, send to analyze traffic and ban anti-virus updates, go to sites, for example, kaspersky.ru, virustotal.com, etc., are intercepted.

After installing the autorun key in the system, the Autoruns simply did not see it, and there was no Kmlslc.exe in the process list. Plus, the file was not visible on the disk. After scanning the system using RootkitRevealer, it turned out that access to the registry and directories are intercepted, modifying the output of information. Quite a common technique. The following functions are intercepted for implementation: CopyFile, CreateFile, MoveFile, LdrLoadDll, NtEnumerateValueKey, NtQueryDirectoryFile, NtResumeThread, RegCreateKeyEx, RegCreateKeyEx, GetAddrInfo.



By banal filter settings in Procmon, it became clear that the malware had injected interceptor code into a trusted process (explorer.exe). From the logs it is clear that the code periodically tries to check the existence of the file.



Guided by the principle “Why not?” I tried to erase the file via DeleteFile. To my surprise, the function ended successfully, and the embedded code, after accessing the file, began to throw out FILE_NOT_FOUND instead of SUCCESS. It made me think that nothing was implemented in the embedded code, except for WinAPI interception. Unfortunately, I do not know how to program hooks yet, but I know that AVZ does an excellent job with this. After restarting the PC, the OS can be considered clean of this malware.

Conclusion


What conclusions can be drawn from the above? Despite the interception of the API, checking domain names before withdrawing and other techniques, the malware still has a number of shortcomings, against the background of which the advantages make little sense:

Analyzing the pros and cons, we can assume that at least two people were involved in development: one crypto (or the third was doing it) and implemented WinAPI interception, the second wrote copying a file to a USB flash drive installation in the system and communicating with the admin panel (or gate).
After researching malicious activity, an antidote was written. Sources

Source: https://habr.com/ru/post/156895/

More articles:


All Articles