Additional technical details re: W32.Flamer--Symantec

Additional technical details re: W32.Flamer--Symantec

Good afternoon

In an effort to keep you posted on developments concerning W.32 Flamer, researchers at Symantec have continued their analysis and have posted the a blog, Painting a Picture of W32.Flamer, which contains further technical details of the various components that make up Flamer. Full understanding of Flamer requires analyzing approximately 60 embedded Lua scripts, reverse engineer each or the sub-components, then piece it back together.  As an analogy, reverse engineering Flamer as opposed to standard malware is like re-creating an architectural drawing, not just for a single house, but for an entire city.

While Flamer is a complex threat, the use of Lua, a lightweight scripting language provides a simple way for the attacker to develop new functionality in the threat. Full text of the blog is below.

If you have any questions please feel free to let me know and I can put you in touch with a researcher from Symantec Security Response. 

Cheers,
James

Painting a Picture of W32.Flamer
By Symantec Security Response

The number of different components in W32.Flamer is difficult to grasp. The threat is a well designed platform including, among other things, a Web server, a database server, and secure shell communications. It includes a scripting interpreter which allows the attackers to easily deploy updated functionality through various scripts. These scripts are split up into 'apps' and the attackers even appear to have something equivalent to an 'app store' from where they can retrieve new apps containing malicious functionality.

To get an idea of how all these components fit together, the best place to start is a file called mssecmgr.ocx. This is W32.Flamer's main file and it is the first element of the threat executed by an infected computer. The file mssecmgr.ocx contains a large number of sub-components. A breakdown of the various components and how they are stored in this file are shown in Figure 1 below:
 

Figure 1. Overview of W32.Flamer components

 
Most sub-components, including the various scripts, are stored in a large encrypted resource embedded in mssecmgr.ocx. This resource has a table at the start which lists the various entries and acts as an index to retrieve the data. It is a similar approach to a standard file system. As well as containing the scripts, several standalone executable DLL files are also included in the resource table. Some of these are advnetcfg.ocx, nteps32.ocx, boot32drv.sys, msglu32.ocx, soapr32.ocs, jimmy.dll, 00006411.dll, and more.

Outside of this resources section there exists code to implement a HTTP server, SOCKS proxy, SSH, SQL database and, of course, the Lua interpreter. Lua is a lightweight scripting language which was specifically designed for embedding into other applications. It is a simple way to extend the functionality of an application. It allows a developer to write a script which can then utilize the functionality of the program it is embedded into. By using Lua, the attacker has reduced the effort required when developing new functionality or 'apps' for W32.Flamer.

When msseccmgr.ocx is executed, it uses some convoluted tricks to embed itself into the running system as shown in Figure 2 below:
 

Figure 2. Initial execution of mssecmgr.ocx

 
It first extracts and executes advnetcfg.ocx. The mssecmgr.ocx file then passes nteps32.ocx to advnetcfg.ocx which in turn injects nteps32.ocx into the clean file shell32.dll. With these files running, mssecmgr.ocx then launches the main Lua 'app' script.
This script starts off by looking for any updated 'app' from the app database. (In the code, the repository of 'apps' is referred to as FLAME.) It also contains the ability to upload to the app repository. After this it creates several database files to store stolen data and starts running various other 'apps'.

The collection of Lua scripts can be split up as shown in Figure 3 below:


 
Figure 3. Lua scripts used by W32.Flamer

 
At the bottom, there are library scripts which provide functionality to other scripts, such as database access or network access. On top of these are the higher level scripts which perform the malicious actions.

These top level scripts are broken into sets. A brief example of some of these are:

• ATTACKOP - Attack another machine and move onto it using a variety of techniques, including exploits
• CASafety - Check for AV software
• CRUISE - Steal credentials
• Euphoria - Spread over LNK vulnerability and junction point directory

Some of the scripts rely on additional executables to operate. For example The ATTACKOP scripts can call the soapr32.ocx file. This file then steals a range of network data from the local computer and then writes it to an RC4 encrypted file.

The ATTACKOP_JIMMY script may use one of the following executables to perform its functionality:

• mssvc32.ocx
• msglu32.ocx
• jimmy.dll

The above is a brief overview of W32.Flamer and how it is laid out. Full understanding of W32.Flamer requires analyzing each of the approximately 60 embedded Lua scripts, reversing each of the sub-components, and then building this all back together. As an analogy, reversing W32.Flamer as opposed to reversing standard malware is like re-creating an architectural drawing, not just for a single house, but for an entire city.

For more information please contact:James Curtis
Max Australia
+61 2 9469 5740
james.curtis@maxaustralia.com.au