The Opening Ceremony of the 2012 Olympic Games is exactly 1 week away and Websense Security Labs researchers are already seeing data-stealing malware that aims to capitalize on the Games. Malware piggybacks on the buzz surrounding current, high profile events like the Olympics in order to steal personal data. Olympics-themed content armed with malware is introduced mainly through social engineering-based attacks. The cyber criminals behind the themed attacks know that they have a better chance of enticing potential victims by appearing current and relevant to a hot topic. That gets clicks, and the chance to spread their data-stealing creations further.
We have been following with interest an advisory released by the Polish Computing Emerging Response Team (CERT) which analyzed an interesting sample of data-stealing malware. This malware, once executed, has the ability to interact with social channels like Facebook, Skype, and Microsoft Live Messenger. This particular variant spreads malicious URLs through those channels and the victim's contact list. To be precise, it employs a socially engineered attack accompanied by a malicious URL that ultimately leads to a malware file that is part of a bot network. Since the sample analyzed has tried to take advantage of the buzz around the start of this year's Olympic Games, we decided it was timely to write this blog post.
Technical Analysis
Our analysis is based on a sample (MD5: 3E50B76C0066C314D224F4FD4CBF14D5 ) of the same malware family reported by the CERT.PL advisory. It is also detected as Pushbot, which is known to be a data-stealing malware variant. After a first look, when the binary file is executed on the affected system, it creates a new process of itself in memory with core functionality. When we open it with a debugger and try to debug, it appears that the binary is protected using some anti-debugging techniques. Specifically, we recognize the use of TLS functions (Thread Local Storage) without a clear TlsCallback function. The use of TLS functions makes the reverse engineering a bit trickier, since some of the core routines are already executed when the sample is debugged, thanks to the TLS use.
Likely, the authors of the loader have obfuscated the TlsCallBack function. This function is usually executed just before the main entry point function when the binary is run. If we can detect the Thread Local Storage callback address function, it would be possible to retrieve the Relative Virtual Addresses list, which is useful to map the address of the imported function from the system DLLs. In the TLS handler code section it was possible retrieve the use of FlsSetValue() and other Flsxxxx functions introduced in the Microsoft Vista operating system:
This snippet of code could also probably be used to detect if the impacted system is a Windows XP operating system or a Windows Vista/ Windows 7 operating system. To avoid spending time to obtain a proper PE file, we opted to dump the process directly from memory. This allows to start to debug the process at runtime. Basically, we have a dumped and non-compliant PE file, but it has all the information needed to start a dynamic behavior analysis of the malware by attaching our stub (the dumped file) to the runtime process:
In the screenshot above, it is possible to see the different sizes between the dumped process and the original malicious PE file. At this point, the stub has been opened through the debugger, resulting in a clean strings list. This includes a list of shortener domains called by the malware in the initial sequence using the Windows DNS Resolver to be saved in the local DNS Cache. This means the malware is not forced to create another DNS request, rendering detection strategies less easy to implement:
From the strings list, we can also find the list of processes that the malware checks to choose the communication channel used to spread itself. Specifically, the malware looks in memory for these processes: opera.exe, firefox.exe, iexplore.exe, skype.exe, and msnmsgr.exe. When it uses a web browser, the malware changes the starting page to redirect user HTTP sessions to malicious websites. In the case of Skype or Microsoft Live Messenger, the malicious process is able to forge HTTP requests with malicious payloads to users in the victim's contacts list. We have also detected a Facebook URL forger used to build proper HTTP requests and send them to the Facebook server. In this way, if there is an active Facebook session, the malware can send malicious messages to the victim's Facebook friends list. This is seen also when we decrypt the configuration file retrieved by the C&C, as shown here in its encrypted form as originally sent by the C&C server:
The C&C URL requested in this sample is hxxxp://tintiurl.net/query.php, which is also involved in the so called "Alcatraz" botnet. The domain seems to be tied to three different IP addresses, as shown below (from Robtex result):
The IP addresses so far are: 46.220.203.212, 89.63.178.149, and 39.54.215.205. After decrypting the configuration file, we could see a clear 2012 Olympic Games theme:
The screenshot below shows the result of the decoding routine (the same routine reported by the CERT PL advisory). Basically, the configuration parameters and the values are Xored with the hexadecimal value 0x66 as shown in the following disassembled code:
After the decoding cycle, a sort of configuration parser is executed (it starts in the second box above). Going back at the content of the configuration file, we now have the configuration file of the malware decrypted:
The "hp" parameter is used to set the home page of the web browser on infected systems. In this case, the host hxxp://domredi.com/1/ lead to hxxp://www.easynetseek.com is used. This is a custom Google search page, as shown below:
The parameter "MSN" is valued with the shortener hxxp://goo.gl/Ub99F. This URL is sent to users in the Microsoft IM client contacts list. We can also see that the configuration file apparently updates this bot to infect only MSN users, since the parameters related to Facebook and Skype are not valued with any URL. The Google short URL redirects to a domain registered 3 days ago ("hxxp://urilsfotosnica.com/images.php?=" ), which, according to our ThreatSeeker network, still appears to be inactive:
(click to enlarge)
The pattern ("/images.php?" ) used in the URL above is also a common pattern used by the RedKit Exploit Kit. Below is the source URL of the sample we analyzed in this blog:
(click to enlarge)
The URL hxxp://lokralbumsgens.com/pictures.php?pic=google is still active, and the domain was registered 20 days ago.
Although this malware is already detected very well, we have focused our attention on how the malware authors are ready to exploit the interest in this worldwide event and succeed better in compromising systems throughout the world. Websense customers are protected from these threats by ACE, our Advanced Classification Engine.