The virus in Odnoklassniki
Thank you, O Habraludi, for a small increase in karma. Now I can finally write about yesterday’s events on Odnoklassniki with technical details.
On July 2, 2008, a massive spam mailing was sent aimed at users of Odnoklassniki. The messages contained a link to a certain site. Unfortunately, when I came to work and began to deal with the problem, the link was already dead. But users managed to go through it and eventually sent us some executable files. Most likely, the link was some kind of exploit, allowing you to download files to the victim’s computer without the user's knowledge and launch them. The first file I got on the victim’s computer I didn’t analyze; I got one of the stages of his malicious life path.
So, winnt32.dll.
An ordinary DLL, unless there are no exports and it immediately catches the eye that the file is encrypted or compressed. First of all, the KiFastSystemCall address is calculated from the two clogged constants and this function is called. In EAX at this time, 0x09, which, it seems, corresponds to NtEnumerateBootEntries:
.text: 004011A6 mov edx, 67C7AE8Eh
.text: 004011AB mov ebx, [edx + 18365472h]
.text: 004011B1 dec ebx
.text: 004011B2 call ebx .text: 004011B2
This is a kind of OS binding and protection against debugging: in one of our virtual machines, the file did not work. In the .rsrc section, the file contains a large array of encrypted data, the address of which is then passed to VirtualProtect. After this, the decryption function is called, as a result of which a full-fledged executable file is obtained in the memory. Now it's up to the small - VirtualAlloc, memcpy several times and a freshly allocated memory image of the file, ready for execution. I note that the decrypted file is not flushed to disk!
The decrypted and downloaded file at the first stage carries all the payload. It creates two parameters in HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon \ Notify \ WinNt32: ID and Unique (filled with a random string). After that, according to an unclear algorithm (most likely randomly), a GET request is generated. The next step is to download encrypted data from the network. Not InternetReadFile or UrlDownloadToFile is used, but the basic functions of Windows Sockets: connect-send-recv. The requested URL is always different, as well as the received data, which suggests that the received data depends on the requested URL. After deciphering the received data, 2 PE-files appear in the memory. The first of the files is saved to disk and launched, but the fate of the second is a bit more interesting. The Trojan launches the svchost process,
Total: in spam, a link was distributed to a page that allegedly contained malicious code that downloaded and launched a file on the victim’s computer. As a result of the work of this file, the WinNt32.dll file appeared on the victim’s disk, which received two encrypted files through the network, one of which was saved and launched, and the second was injected into svchost.
I’m analyzing the functionality of the downloaded files. Wait for the news!
On July 2, 2008, a massive spam mailing was sent aimed at users of Odnoklassniki. The messages contained a link to a certain site. Unfortunately, when I came to work and began to deal with the problem, the link was already dead. But users managed to go through it and eventually sent us some executable files. Most likely, the link was some kind of exploit, allowing you to download files to the victim’s computer without the user's knowledge and launch them. The first file I got on the victim’s computer I didn’t analyze; I got one of the stages of his malicious life path.
So, winnt32.dll.
An ordinary DLL, unless there are no exports and it immediately catches the eye that the file is encrypted or compressed. First of all, the KiFastSystemCall address is calculated from the two clogged constants and this function is called. In EAX at this time, 0x09, which, it seems, corresponds to NtEnumerateBootEntries:
.text: 004011A6 mov edx, 67C7AE8Eh
.text: 004011AB mov ebx, [edx + 18365472h]
.text: 004011B1 dec ebx
.text: 004011B2 call ebx .text: 004011B2
This is a kind of OS binding and protection against debugging: in one of our virtual machines, the file did not work. In the .rsrc section, the file contains a large array of encrypted data, the address of which is then passed to VirtualProtect. After this, the decryption function is called, as a result of which a full-fledged executable file is obtained in the memory. Now it's up to the small - VirtualAlloc, memcpy several times and a freshly allocated memory image of the file, ready for execution. I note that the decrypted file is not flushed to disk!
The decrypted and downloaded file at the first stage carries all the payload. It creates two parameters in HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon \ Notify \ WinNt32: ID and Unique (filled with a random string). After that, according to an unclear algorithm (most likely randomly), a GET request is generated. The next step is to download encrypted data from the network. Not InternetReadFile or UrlDownloadToFile is used, but the basic functions of Windows Sockets: connect-send-recv. The requested URL is always different, as well as the received data, which suggests that the received data depends on the requested URL. After deciphering the received data, 2 PE-files appear in the memory. The first of the files is saved to disk and launched, but the fate of the second is a bit more interesting. The Trojan launches the svchost process,
Total: in spam, a link was distributed to a page that allegedly contained malicious code that downloaded and launched a file on the victim’s computer. As a result of the work of this file, the WinNt32.dll file appeared on the victim’s disk, which received two encrypted files through the network, one of which was saved and launched, and the second was injected into svchost.
I’m analyzing the functionality of the downloaded files. Wait for the news!