Executive Summary In the first part of this article, it was possible to see the instructions executed by the droppers of Red October. Such instructions are executed after the exploitation of a specific vulnerability in Microsoft Office, and are intended, at first, at the creation of some files within the victim system.The most interesting, for now, is the file svchost.exe, the execution of which is borne, as seen above, of the dropper itself through the function CreateProcess. Svchost.exe Analysis EP is located at 0x411974.
Also in this case, the file appears to be protected / encrypted with the same custom packers or code protector. The analyst, after an initial analysis, performs successfully the same steps performed above for the recovery of “dropper” executable. Again, once malware reaches the VirtualAlloc function, the analyst is able to clearly read the magic “x4Dx5A” at memory location 00040606.
A new memory dump is performed in order to retrieve the original executable.
Once performed the dump of the useful memory region, a new file is then obtained. The new file appears, in its turn, compressed through the known tool UPX, and therefore, is also executed through the manual decompression of it, for obtaining another file, this time totally clear.
The first step taken by the analyst on this new obtained file is a string analysis as follows:
From this, it is already possible to extract very useful information about it. The first highlighted area (1) looks very much like a key probably used by some encoding / decoding subroutine. The group number two (2) shows likely recipients of certain communications that the malware is expected to make,and, finally, the third (3) string found gives us an indication of the use of the “zlib” compression library (just searching on any search engine “Copyright Mark Adler“). Most likely, the information the malware wants to hide then, were first compressed through the use of zlib, and then encrypted with some sort of internal algorithm.At this point we can also start a static analysis of the malware. Among the first instructions executed, there is the control for the existence of a specific registry key, the “HKLM Software Classes CLSID {00000000-40E0-E92F-CEF2-1972CB64D313}“. If not present, it goes to create it and to set into it a REG_SZ value named “Infotip“. After a few more instructions,the malware goes to call WSAStartup function to initiate use of Winsock DLL…
..and subsequently to compose the HTTP requests.
An attempt to connect to “www.microsoft.com“, “update.microsoft.com” and “support.microsoft.com” is then make through a HTTP GET request. The HTTP connections will be done through a dedicated thread that is created through CreateThread function.
Probably, such procedure is performed to check the connectivity of the victim system. After it reached this point, malware seems to have reached its primary instructions set at sub_403930 after retrieving the content of “wsdktr.ltp” file. This subroutine presents two loops inside and looks very much like a decoding function. EAX and EDI registers are respectively the counters of first and second of these, and are compared, each time, with a hardcoded value of 100 (256).
Assuming a reversed, simplified, pseudo-syntax for this sub as the following… [plain] key= “dfdedkwe3322oeitodkdjeio3e9ekdjwasddcncmvjdasalwpeoryg7534hvn5wewse” s= array[]; for (i=0; i<256; i++) { s[i] = i; } j = 0; for (i=0; i<256; i++) { j = (j + s[i] + key[i % strlen(key)) % 256; x = s[i]; s[i] = s[j]; s[j] = x; } [/plain] ..RC4 is the algorithm used to decrypt the context desired.At this point, the function sub_404500is called. Here we assume the use of zlib for decompression of the text previously recovered. The analyst then tries to manually recover the context of wsdktr.ltp based on the information just seen. Other few lines of python code are written for the occasion.
The retrieved file appears as an UPX packed DLL. Another step again is taken to unpack this library,and a new clear file is obtained. The library starts with DLLMain
and sub_10001100 is called.Following the execution, we land on a SetTimer function call.
The address of “TimerFunc” function is pushed onto the stack and the TimerFunc function is so executed. This starts a new thread, and the context that will be executed is a never directly called function located at 10001020.Here, the sub_100013A0 function is called. At this point, it seems that we have reached the “heart” of Red October! This is a large image of the real work done by the “Red October” malware.
The heart of Red October Once reached sub_100013A0, sub_1000D9C0 is called to retrieve information about the Windows Directory. If this is not found, the malware retrieves the type of drive and file system in use. Then, Red October lands on sub_1000DD70. Here, two other calls (sub_1000DBD0, and sub_1000DA60) are made to retrieve useful information about OS in use.
At sub_10003F00, the malware goes to create a new socket and to forge the HTTP requests for the C&C servers.
The C&C servers contacted are shown in the following image:
And the path used in the following:
Communications are made through HTTP POST requests and use a XOR loop with a random key, generated taking the string “12345” as generation parameter.
Once these requests are done, it is provided the recovery of useful commands by the C&C servers. The malware handles orders issued by the C&C servers, with a switch-case statement reported, for a better understanding, with the following, simplified, pseudo-syntax: [plain] switch (command issued) { case 0x3: Download and Execute a file; break; case 0x4: Launch a process from a locally stored file; break; case 0x5: Inject code to a locally stored binary; break; case 0x6: Download a file; break; case 0x7: Reinstall itself; break; default: Do nothing; break; } [/plain] This primary cycle of operations is performed every 90 seconds, according to the parameters of the SetTimer function. No other particular instructions are executed. Conclusion Based on the version analyzed, Red October appears to be like many common Trojan Horses available in the wild.Certainly, in terms of complexity, it is not comparable to the “Flame Virus” or others for example, and, perhaps,its dangerousness is probably due to the targets to which it points.Red October remains, in any case, a dangerous threat that can potentially compromise the integrity, the confidentiality and the availability of information contained within the victim systems.
