Wednesday 30 May 2012

Flame: Component soapr32.ocx

One of the Flame's components, soapr32.ocx, is a DLL that is designed to collect information about the system and about the software installed on the victim's computer.

All the strings that might give clues about the malware functionality are encrypted. Any time the code needs a string, it decrypts it first, as shown below:

.text:100023E8 push offset encrypted_string ; some encrypted API name
.text:100023ED call decrypt_string
.text:100023F2 pop ecx
.text:100023F3 push eax ; decrypted API name
.text:100023F4 push ebx ; hModule
.text:100023F5 call edi ; GetProcAddress
.text:100023F7 mov [ebp+234h+var_api], eax ; store the address of API in var_api
.text:100023FA push offset encrypted_string_2 ; another encrypted API name
.text:100023FF call decrypt_string

The code below reflects the restored logic of the decryptor:

BYTE GetKey(BYTE i) // calculate a key for a given position
{
BYTE i1 = i + 11;
BYTE i2 = i + 17;
return i1 * i2 ^ ((i1 * i2) >> 8) ^ ((i1 * i2 ^ ((i1 * i2) >> 8)) >> 16);
}

void Decrypt(LPBYTE lpBuffer)
{
if (lpBuffer[8]) // 8th byte is a flag "encrypted"
{
for (BYTE i = 0; i < lpBuffer[9]; i++) // 9th byte is the string size
{
lpBuffer[11 + i] -= GetKey(i); // encrypted string starts from 11th byte
}
lpBuffer[8] = 0; // clear "encrypted" flag (8th byte)
}
}

Feeding it an encrypted string below:

BYTE szTest[] = {0x54,0xDA,0x4B,0xFF,0xD8,0xFB,0x5C,0xC5,0x9C,0x0E,0x00,0x0B,0x4A,
0x66,0x7C,0x9F,0xD4,0xF9,0xE4,0x0C,0x50,0x9E,0xDC,0x0C,0x46,0x00};
Decrypt(szTest);

will produce a decrypted output:

 54 DA 4B FF D8 FB 5C C5 00 0E 00 50 72 6F 63 65 73 73 | T.K...\....Process
 33 32 46 69 72 73 74 00                               | 32First.

In total, there are 304 encrypted strings in the soapr32.ocx file. Decrypting them manually would be insane, so a dedicated tool can now be constructed to process the entire file and patch it with the decrypted strings so that the file can be disassembled and studied.

The tool would need to take a list of all 304 virtual addresses of the code that cross-references the decrypt_string() function (e.g. 0x100023ED, 0x100023FF shown above). Next, the tool would convert those addresses into the raw file offsets to parse the file; from every found offset, the tool would inspect the bytes backwards looking for the parameters' virtual addresses passed to the function calls. Those virtual addresses would correspond to the encrypted string addresses. Next, it would find out what PE sections those addresses belong to in order to figure out the raw file offsets of the encrypted strings.

With the file offsets of the encrypted strings known, the tool can now decrypt them all with the aforementioned Decrypt() function. Since every decrypted string actually starts from the 11th byte of every 'encrypted string' block, it can also be moved to the start of each block to facilitate static analysis.

Once done, the listing will look much more plausible:

.text:100023B2 push offset aKernel32_dll ; "Kernel32.DLL"
.text:100023B7 call Decode
.text:100023BC add esp, 1Ch
.text:100023BF push eax ; lpModuleName
.text:100023C0 call ds:GetModuleHandleA
.text:100023C6 mov ebx, eax
.text:100023C8 cmp ebx, edi
.text:100023CA jz loc_100024F8
.text:100023D0 push offset aCreatetoolhelp ; "CreateToolhelp32Snapshot"
.text:100023D5 call Decode
.text:100023DA pop ecx
.text:100023DB push eax ; lpProcName
.text:100023DC push ebx ; hModule
.text:100023DD mov edi, ds:GetProcAddress
.text:100023E3 call edi ; GetProcAddress
.text:100023E5 mov [ebp+234h+CreateToolhelp32Snapshot], eax
.text:100023E8 push offset aProcess32first ; "Process32First"
.text:100023ED call Decode
.text:100023F2 pop ecx
.text:100023F3 push eax ; lpProcName
.text:100023F4 push ebx ; hModule
.text:100023F5 call edi ; GetProcAddress
.text:100023F7 mov [ebp+234h+Process32First], eax
.text:100023FA push offset aProcess32next ; "Process32Next"
.text:100023FF call Decode

Now, full static analysis is possible. So what soapr32.ocx component is built for?

The malicious DLL queries a number of the registry entries with the purpose of revealing if any of the following software is installed on the victim's machine:
  • Tiny Personal Firewall

  • Kerio Control Firewall

  • FarStone Firewall

  • Kaspersky Antivirus

  • Symantec Internet Security

By enumerating the processes, it is capable of detecting if any of the following software is running:
  • Symantec Event Manager Service

  • ZoneAlarm Personal FireWall

  • ZoneLabs Firewall Client

  • Outpost Personal Firewall

  • McAfee On-Access Antivirus Scanner

  • McAfee Personal Firewall

  • Kaspersky AntiVirus

By looking at the presence of the files and registry entries, it may also detect what type of mobile phone the victim is using (if the phone is connected to the computer, what type of software is used to manage the phone):
  • Sony Ericsson

  • Nokia

The malware tries to retrieve the credentials information, such as username and password, for the following software products:
  • Core FTP Pro

  • CuteFTP 8

  • FTP Explorer

  • Robo-FTP

  • SoftX FTP Client

  • Mssh SSH Client

  • Emurasoft EmFTP

  • NetX NetServe FTP Client

  • South River Technologies WebDrive

  • Martin Prikryl WinSCP 2

  • WinVNC/TightVNC/UltraVNC (via Software\ORL\WinVNC3)

  • TeamViewer

  • RAdmin v2.0 Server

Revealing credentials for the aforementioned software exposes extra risks such as ability to connect to the compromised system remotely (via VNC) or compromise/infect/deface web servers managed via one of the enlisted FTP client solutions.

By checking existence of multiple registry entries, the malware detects if any of the following software is installed:
  • Inno Setup

  • VNC Admin Console

  • PenguiNet

  • RageWork

  • NetX NetServe FTP Client

  • Jildi FTP 1.5.2

  • CyD FTP Client

  • Ace FTP 3

  • InterSoft

  • DameWare

  • BitKinex 2.7

  • SmartFTP Client 2.0

  • SecureCRT 5.2

  • JaSFtp 7

  • Ipswitch WS_FTP Professional 2007

  • BulletProof FTP Client

Apart from that, the malicious Flame component soapr32.ocx performs the following actions:
  • retrieves the cookies for Yahoo.com and parse their contents foe the presence of the 'B=' tag

  • enumerates all services in the service control manager database and for every service it obtains full information

  • enumerates all logical drives and collect information about them such as used space and drive types

  • enlists all files and directories within %CommonAppData% and %ProgramFiles% directories

  • collects system's code page numbers (ACP/MACCP/OEMCP/NLS)

  • retrieves the versions of the installed Outlook Express, Outlook, Microsoft Word, Internet Explorer

  • collects the local time and the time zone information

  • checks the presence of the pipe '\pipe\srvsvc'

  • checks if USB storage devices are enabled in the system

  • enumerates the device interfaces that are contained in a device information set

  • enlist all current connections between the local computer and resources on remote servers; the information it queries is about the connection between a local device and a shared resource: connection status, connection type, user name, and domain name

  • enlists all phone-book entries in a remote access phone book, and for every entry it retrieves the connection information saved by the last successful call (used by dial-up modems)

  • enlists all objects that appear in the network neighborhood (e.g. My Network Places virtual folder)

  • enumerates available printers, print servers, domains, or print providers

  • retrieves SMTP/POP3 server information and also account information/credentials for all Microsoft Outlook profiles

  • retrieves the list of visited URLs from the Internet cache

  • reads DNS cache table, presumably to access the list of the visited (and DNS-resolved) web sites

  • retrieves the interface–to–IPv4 address mapping table, MIB-II interface table, adapter information for the local computer

  • retrieves network characteristics for the network adaptors installed in the system: IP addresses, subnets, default gateways, DHCP settings, binding order, description

  • retrieves both active and persistent routes stored in the IPv4 routing table

  • collects information about shared resources, including name of the resource, type and permissions, number of connections, and other pertinent information

  • reads the contents of the HOSTS file to see if there are any redirects stored in it

  • collects Wireless network information, such as WiFi network name, type of encryption used, authentication method/protocol

  • enumerates user accounts and groups, then enlists users that belong to the 'Administrators' group

  • checks if remote desktop connections are enabled, then queries remote desktop information, such as port numbers, firewall status, the list of the globally open ports

The soapr32.ocx DLL can also establish a remote connection to HKEY_PERFORMANCE_DATA (performance counters) registry key on other computers in the network. Performance counters represent a dynamically generated snapshot of the remote system's current state. By querying the contents of the registry key 'Counter 009', the malware can retrieve the 'title database', and then, subsequently, the 'Process' object information to read statistics about each process running on a remote system (using the same principle as PsList, a Microsoft utility written by Mark Russinovich).

The process names it is interested in are related to the following software:
  • Symantec Event Manager Service

  • ZoneAlarm Personal FireWall

  • ZoneLabs Firewall Client

  • Outpost Personal Firewall

  • McAfee On-Access Antivirus Scanner

  • McAfee Personal Firewall

  • Kaspersky AntiVirus

By detecting any of the processes that are associated with the aforementioned software, it will know if other computers in the network are using firewalls/antivirus software solutions. Please note that this function will fail if the remote computers are not running Remote Registry service (by default, this service is configured to be started manually).

9 Comments:

Blogger Unknown said...

You keep saying this is a "malicious DLL", but the functionality described is not malicious - this actually sounds like quite a useful system audit tool. It doesn't seem to exploit or change anything, nor does it transmit the collected data?

Even if Flame as a whole is malicious, this OCX in isolation is not (unless there are other activities not described here).

30 May 2012 at 17:50  
Blogger Nick Kusters said...

Re: Peter bance,

While I agree with you, it might be usefull for people to know that such an audit library is present on your system (from an AV and User standpoint).

30 May 2012 at 19:06  
Blogger AmyGeek said...

@Peter - Personally, I consider anything that installs itself without my permission malicious. The fact that this is collecting information from my machine and transmitting it back to an unknown source is very troubling. This is only one portion of the Flame worm, so there is the potential that "they" can act & either write to my machine or take over processes on my machine based on the information that is extracted. This is dangerous stuff.

31 May 2012 at 05:13  
Blogger Sergei Shevchenko said...

@Peter,

This is just one component of Flame/Tosy that does a specific job when instructed so by other components. The information it collects is stacked in a pre-defined file that other components would read and deliver back to C&C. It carries the same encryption as other members of Flame/Tosy group, so it's definitely a member of this group even though you might consider it useful when taken in isolation.

Think of a gang of criminals from a Hollywood blockbuster where each member is assigned a specific role. When taken in isolation, there're all innocent (a good shooter, a good driver, computer genius, etc.), but once you bust them all in one place, in one time, doing a well-coordinated job, you can't consider them in isolation any more.

31 May 2012 at 10:28  
Blogger Unknown said...

My point, though, was that this OCX doesn't seem to be doing the transmitting, so in isolation it's not "malicious". No argument at all about the rest of the "package" being malicious, and I agree that anything installed without permission should be hunted down and squished!

31 May 2012 at 15:07  
Blogger Unknown said...

Agreed, but a different analogy is (something like) nmap - very useful indeed to most, but can be used for malicious reasons. That doesn't make nmap itself malicious...

Anyway, I'll be on the lookout for new audit tools that are simply wrappers and reporting engiaround ded on this component!

31 May 2012 at 15:12  
Blogger Unknown said...

[Sorry, fat thumbs]

Should have read "...wrappers and reporting engines based on..."

31 May 2012 at 15:15  
Blogger Sergei Shevchenko said...

A case with nmap would have been classified "legitimate tool used in malicious purposes". Whether it is desirable to leave it or not would entirely depend on the context - if it was used by another component in malicious purposes, then the end user should at least be given an option to remove it.

It's like cleaning a crime scene and then asking a mom or a dad: "Do you want to keep this axe?". It could be a perfect tool for a butcher, but no mom or dad are ever expected to have it in their kitchen.

If nmap was encrypted the same way as other malware from the pack (like this OCX), then it'd be safe to delete it - there is no need to ask the user to keep it as classifying it as malicious and removing it with a reliable signature would be 100% safe - it wouldn't touch the vanilla nmap distributions as the signature wouldn't trigger on them.

31 May 2012 at 16:22  
Blogger Unknown said...

That is main thing about software installed on the victim's computer. This malicious DLL actually sounds like quite a useful system audit tool. Those every information really too good.

adobe illustrator training

8 June 2012 at 13:22  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home