Flame: msglu32.ocx, Component That Can Track Location

This particular DLL component of the Flame threat is designed to locate various files in the system, read their contents and populate the SQL database with the file contents and characteristics. In addition, this file is capable of collecting geographical identification metadata that may be present in the files it inspects.

The string decryptor is slightly different this time:

void decrypt(int result, int iCount)
{
   int i1, i2, i3, i4;

   i1 = result;
   if (iCount)
   {
      i2 = 11 - result;
      do
      {
         i3 = i1 + i2;
         i4 = i3 + 12;
         result = i3 * i4;
         *(BYTE *)i1 -= result ^ ((i3 * i4) >> 8) ^ 
                        ((i3 * i4) >> 16) ^ ((i3 * i4) >> 24);
         ++i1;
         --iCount;
      }
      while (iCount);
   }
}

void Decrypt3(LPBYTE lpBuffer)
{
   if (lpBuffer[16])                    // 16th byte is a flag "encrypted"
   {
      decrypt((int)(lpBuffer + 20), (int)lpBuffer[18]);
                                       // 18th byte is the string size
                                       // 20th byte is where encrypted bytes start
      lpBuffer[16] = 0;                // clear "encrypted" flag (16th byte)
   }
}

Feeding it the string below:

BYTE szTest3[] = 
{
    0xA7,0xC9,0xDF,0xF8,0x30,0x0C,0x52,0x9D,0x0C,0x7F,0xB5,0x32,0x2B,0x05,0xC6,0x08,
    0x05,0xD5,0x26,0x00,0x74,0x21,0xA5,0x6D,0x0B,0xC1,0x54,0x1E,0xB0,0x82,0x24,0xEE,
    0xA0,0x63,0xFF,0xDF,0x7A,0x64,0x03,0xE8,0x9F,0x85,0x3E,0x1A,0xD0,0xC6,0x73,0x6B,
    0x34,0x28,0xD6,0xD4,0x96,0xA9,0x78,0x66,0x42,0x4B,0x00,0x00,0x68,0xB8,0xE7,0x8A,
    0x23,0x51,0x36,0x5C,0xCD,0xC3,0x4D,0xE4,0xF2,0xE5,0xCC,0xA3,0x00
};
Decrypt3(szTest3);

produces the following result:

    A7 C9 DF F8 30 0C 52 9D 0C 7F B5 32 2B 05 C6 | ....0.R....2+..
    08 00 D5 26 00 77 00 61 00 77 00 68 00 61 00 | ...&.w.a.w.h.a.
    6D 00 7A 00 61 00 61 00 62 00 6F 00 76 00 65 | m.z.a.a.b.o.v.e
    00 61 00 72 00 61 00 62 00 69 00 63 00       | .a.r.a.b.i.c.

The file is capable of locating the following files:

• Wicrosoft Word documents


• Microsoft Excel spreadsheets


• Microsoft PowerPoint slides


• Microsoft Access Databases


• Microsoft Outlook objects (IPM Notes, Appointments, Schedule/Meeting Requests)


• AutoCAD Drawings


• Visio Drawings


• PDF Documents


• Image files (JPEG, BMP, TIFF, PNG, GIF)

For every document, the DLL collects file characteristics, such as:

• Modification Date


• Creation Date


• Creator


• Author


• Comments


• Company


• Producer


• Title


• Info


• Revision number


• Number of Keywords

The information about located files can then be stored in the database. That data is added and queried with the SQL commands, such as:

• INSERT INTO Media (Type, MediumDescription) VALUES ('%s', '%s')


• SELECT State FROM Pst_States WHERE FileName=? AND Size=%u AND LastModification=%I64d

The module contains a large table that consists of 4,173 Postscript glyph names, such as 'alefhamzabelowfinalarabic' or 'alefqamatshebrew'. This table is used to convert Postscript glyph names into Unicode codes - presumably to be able to parse the content of Adobe PDF documents written in Unicode Character Entities, such as Hebrew or Arabic.

The DLL is aware of the presence of the security product by inspecting the registry entries:

• HKLM\SOFTWARE\KasperskyLab\AVP6


• HKLM\SOFTWARE\KasperskyLab\protected\AVP7

If the files it inspects include geographical identification metadata (geotagging), it will extract the following data:

• GPS Latitude


• GPS Latitude Ref


• GPS Longitude


• GPS Longitude Ref


• GPS Altitude


• GPS Altitude Ref

This geotagging data may be present within the images, as shown below:


Image Source: Wikipedia, Geotagging

Some cameras use automatic picture geotagging with a built-in GPS receiver (such as Panasonic Lumix DMC-TZ10, Sony Alpha 55V, or Canon PowerShot SX230/SX260). Many mobile phones use either a built-in GPS receiver or a Wi-Fi positioning (assisted GPS) to embed geotagging in the photos by default.

Retrieving the geotagging data allows this Flame component to find GPS coordinates of the location where the pictures were taken, or with some statistical probability, where the compromised system is (has been) located:

.text:100C5DE8 sub_100C5DE8    proc near
.text:100C5DE8                 push    offset aGps_latitude ; "GPS_LATITUDE"
.text:100C5DED                 call    decrypt_string
.text:100C5DF2                 pop     ecx
.text:100C5DF3                 push    eax
.text:100C5DF4                 push    offset GPS_LATITUDE
.text:100C5DF9                 call    copy_string
.text:100C5DFE                 push    offset sub_100F32F8
.text:100C5E03                 call    _atexit
.text:100C5E08                 pop     ecx
.text:100C5E09                 retn
.text:100C5E09 sub_100C5DE8    endp

The code is also capable of enumerating and terminating the following processes found on a compromised system:

• AntiHook.exe


• EngineServer.exe


• FAMEH32.exe


• FCH32.exe


• Filemon.exe


• FPAVServer.exe


• FProtTray.exe


• FrameworkService.exe


• fsav32.exe


• fsdfwd.exe


• fsgk32.exe


• fsgk32st.exe


• fsguidll.exe


• FSM32.exe


• FSMA32.exe


• FSMB32


• fspc.exe


• fsqh.exe


• fssm32.exe


• jpf.exe


• jpfsrv.exe


• mcagent.exe


• mcmscsvc.exe


• McNASvc.exe


• McProxy.exe


• McSACore.exe


• Mcshield.exe


• mcsysmon.exe


• McTray.exe


• mcupdmgr.exe


• mfeann.exe


• mfevtps.exe


• MpfSrv.exe


• naPrdMgr.exe


• procexp.exe


• PXAgent.exe


• PXConsole.exe


• shstat.exe


• sp_rsser.exe


• SpywareTerminator.exe


• SpywareTerminatorShield.exe


• UdaterUI.exe


• VsTskMgr.exe

Flame: Component nteps32.ocx ... or should we call it Tosy?

Analysis of another Flame component - a DLL file nteps32.ocx, reveals that its strings are also encrypted, just like in soapr32.ocx.

There is slight difference in the parameters used in the encryption algorithm.

Here is the reconstructed logic of the decryptor:

void Decrypt2(LPBYTE lpBuffer)
{
   if (lpBuffer[16])                          // 16th byte is a flag "encrypted"
   {
      for (BYTE i = 0; i < lpBuffer[18]; i++) // 18th byte is the string size
      {
         lpBuffer[20 + i] -= GetKey2(i);      // encrypted string starts from 20th byte
      }
      lpBuffer[16] = 0;                       // clear "encrypted" flag (16th byte)
   }
}

Passing it an encrypted string below:

BYTE szTest[] = {0x15,0xEE,0x8A,0x6D,0x13,0xF0,0xD4,0x55,0x5B,0x0A,0x61,0x17,0x70,
                 0x88,0xDF,0x0A,0x90,0x7D,0x52,0x00,0xCA,0xA2,0x0F,0xE8,0x5B,0x37,
                 0xAE,0x8D,0x17,0xEB,0x71,0x52,0xD3,0xBC,0x40,0x37,0xC5,0xB1,0x4E,
                 0x3C,0xBB,0xC2,0x67,0x59,0xF4,0xFF,0xA6,0xA6,0x3B,0x49,0x10,0x0C,
                 0xDD,0xCA,0x9D,0x81,0x4C,0x5C,0x3C,0x27,0x04,0x06,0xDB,0xFC,0xE4,
                 0xD3,0xA2,0xDA,0xBE,0xDD,0xA6,0xC8,0xAB,0xF7,0xD2,0xEE,0x0B,0x0E,
                 0x27,0x55,0x37,0x78,0x84,0xB3,0xBD,0xFA,0x11,0x32,0x39,0x6D,0xA0,
                 0xD0,0xC3,0x34,0x03,0x8F,0xBC,0xDE,0xE9,0x56,0x48,0xD1,0x00};
Decrypt2(szTest);

results in the following decoded output:

15 EE 8A 6D 13 F0 D4 55 5B 0A 61 17 70 88 DF 0A 00 7D 52 00 48 | ...m...U[.a.p....}R.H
00 4B 00 4C 00 4D 00 5C 00 53 00 4F 00 46 00 54 00 57 00 41 00 | .K.L.M.\.S.O.F.T.W.A.
52 00 45 00 5C 00 4B 00 61 00 73 00 70 00 65 00 72 00 73 00 6B | R.E.\.K.a.s.p.e.r.s.k
00 79 00 4C 00 61 00 62 00 5C 00 70 00 72 00 6F 00 74 00 65 00 | .y.L.a.b.\.p.r.o.t.e.
63 00 74 00 65 00 64 00 5C 00 41 00 56 00 50 00 37 00          | c.t.e.d.\.A.V.P.7.

As you can see, this time, 16th byte keeps the 'encrypted' flag (used to be 8th), the string size is now kept in the 18th byte (used to be 9th), and the string itself starts from the byte #20 (used to be #11).

Obviously, these parameters are random. The author of this threat must be keeping all the original strings in a separate file, and then a separately executed script selects random encryption parameters and then encrypts those strings, producing the source files for compilation. This is similar to how ZeuS encrypts its strings.

Decrypting entire file is also possible by using the same tool that was suggested before. A file with the fully decrypted strings reveals interesting details.

First, the DLL contains a list of domain name substrings that are used for filtering out the websites it is interested in monitoring:

• .hotmail.


• gawab.com


• gmail.com


• live.com


• mail.


• maktoob.com


• rocketmail.com


• yahoo.co


• ymail.com

Next, it contains a long list of security processes that is it designed to detect:

• 4gui.exe


• antihook.exe


• app_firewall.exe


• asr.exe


• authfw.exe


• avgamsvr.exe


• avgcc.exe


• avgemc.exe


• avgfwsrv.exe


• avginet.exe


• avgupsvc.exe


• avp.exe


• avpm.exe


• blink.exe


• blinkrm.exe


• blinksvc.exe


• bootsafe.exe


• cclaw.exe


• cdas17.exe


• cdinstx.exe


• clamd.exe


• cmdagent.exe


• configmgr.exe


• cpf.exe


• dcsuserprot.exe


• dfw.exe


• dvpapi.exe


• eeyeevnt.exe


• elogsvc.exe


• emlproui.exe


• emlproxy.exe


• fameh32.exe


• fch32.exe


• firewall 2004.exe


• fpavserver.exe


• fprottray.exe


• fsaua.exe


• fsav32.exe


• fsbwsys.exe


• fsdfwd.exe


• fsgk32.exe


• fsgk32st.exe


• fsguidll.exe


• fsguiexe.exe


• fsm32.exe


• fsma32.exe


• fsmb32.exe


• fspc.exe


• fspex.exe


• fsqh.exe


• fsrt.exe


• fssm32.exe


• fw.exe


• fwsrv.exe


• gateway.exe


• icmon.exe


• ike.exe


• ipatrol.exe


• ipcsvc.exe


• ipctray.exe


• jpf.exe


• jpfsrv.exe


• kav.exe


• kavmm.exe


• kpf


• kpf4ss.exe


• licwiz.exe


• live help.exe


• lpfw.exe


• mpsvc.exe


• netguard lite.exe


• netmon.exe


• nip.exe


• njeeves.exe


• nstzerospywarelite.exe


• nvcoas.exe


• nvcsched.exe


• nvoy.exe


• oeinject.exe


• omnitray.exe


• onlinent.exe


• onlnsvc.exe


• op_mon.exe


• pcipprev.exe


• pf6.exe


• pfsvc.exe


• pgaccount.exe


• procguard.exe


• pxagent.exe


• pxconsole.exe


• rdtask.exe


• r-firewall.exe


• rtt_crc_service.exe


• sab_wab.exe


• scanwscs.exe


• sp_rsser.exe


• spfirewallsvc.exe


• sppfw.exe


• spyhunter3.exe


• spywareterminator.exe


• spywareterminatorshield.exe


• ssupdate.exe


• superantispyware.exe


• swnetsup.exe


• swupdate.exe


• sww.exe


• tikl.exe


• tinykl.exe


• tray.exe


• tsansrf.exe


• tsatisy.exe


• tscutynt.exe


• tsmpnt.exe


• umxagent.exe


• umxcfg.exe


• umxfwhlp.exe


• umxlu.exe


• umxpol.exe


• umxtray.exe


• updclient.exe


• vcatch.exe


• vdtask.exe


• vsdesktop.exe


• vsmon.exe


• wsweepnt.exe


• wwasher.exe


• xauth_service.exe


• xfilter.exe


• zanda.exe


• zerospyware le.exe


• zerospyware lite.exe


• zerospyware lite_installer.exe


• zlclient.exe


• zlh.exe

Now, the final exercise.

Compare the lists above to the ones reported here and try to spot 10 differences.

Look similar, don't they?

Update (31 May 2012): changed Tossy into Tosy.

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).

Flame: First Impressions (Free Prose)

Following the report from Crysis over the recently discovered Flame threat, one might wonder how it was that the virus went undiscovered for several years.

The suggested ‘age’ of the malware activity is based on the Webroot community reports that indicate when and where the first samples were reported. The samples in those firstly reported cases happened to share the same filenames as Flame’s own components, and could either have belonged to the Flame family (or not) and could have been detected under different threat names and by different products (or not). The fact that those previously seen samples did not raise an alarm from Webroot does not mean those samples were not detected by other antivirus vendors.

Therefore, the anecdotal evidence about the earlier reported samples does not say anything about the effectiveness of current malware detection.

Another reason why it may have stayed undetected for so long is in the whole purpose of building a covert communication channel - to avoid detection.

Flame communicates with its command and control server via SSL (port 443) in a way that is similar to how your browser communicates with an Internet banking server or with your online Hotmail account.

These secure communications are reliably protected against prying eyes in such a way that even if the traffic is intercepted, it will be practically impossible to decrypt it for the purpose of inspection. The traffic over port 443 looks like gibberish not only to prying eyes, but also to network analysis and forensic tools. They are simply unable to decrypt the secure communications, and because of that, they apply the presumption of innocence principle to them and so let them happen.

This forms a double-edge sword – on one hand, secure communications protects our transactions and our privacy, while on the other, an inability to inspect the traffic creates an opportunity for the malware to use the same channels to communicate with their remote operators without raising the alarm from the very same security products.

Without knowing what algorithm the traffic is encrypted with and what keys were used to encrypt it, no security solution would be able to classify such traffic as malicious, without increasing the risk of ‘False Positive’ detections that may potentially block legitimate traffic.

One might also wonder if Flame is easier/harder to detect due to its rather large size. Well, a larger size does not always mean it is easier to detect.

The larger size of the malware components normally means either a ‘careless’ mindset of the malware authors (novice authors, or those who prefer using higher level languages) or the fact that the project has recently attracted programmers with a professional development background.

Professional developers prefer utilising third-party components and libraries that have evolved over time into highly reliable time-tested tools. Think of it as being an owner builder of your own house: just call reputable contractors and they’ll do the job quickly and professionally.

Flame utilises LUA scripting language that is widely used by the professional developers to build a high-level logic in their software, such as state machines (did you know that your beloved Angry Birds are built with LUA?).

Flame also uses SQLite database – any professional developer loves it for its simplicity, reliability and speed.

Old-school malware authors normally do not have a luxury of embedding such brilliant third-party tools – it is too costly for them as it blows up the size of the malware. Large malware is harder to deploy, harder to hide, it utilizes more CPU power, more memory, and therefore, it is easier to attract unnecessary attention from an average user ("Hey, my computer is slow!"). Therefore, they even tend to develop their own libraries to replace runtime libraries (so that the malware has no dependencies), often built in Assembler language.

Going with the house analogy, the old-school malware authors ‘build their houses’ by themselves – they do adopt techniques, but they do not rely on heavy and costly third-party solutions.

To keep the footprint minimal, the malware would rather use its own binary format to store all the reports with its own light-weight compression and its own encryption – just like ZeuS does. Going with SQLite to store the reports, Flame becomes a laughingstock in the malware community. Most likely, it simply indicates that it does not care as it has the luxury of uploading and running anything it wants and whenever it wants. These are the tell-tale signs of a targeted attack: it does not have to be slim to survive in the cruel world. On the other hand, this complacency might be explained with the fact the recently attracted professional developers simply work the way they used to work before – developing lower level components might sound like a nightmare idea to them.

Detection-wise, simplistic signature-based detection is obsolete these days. In order to spot malicious code, an antivirus product should emulate it in order to ‘unwind’ the covert (hidden) logic programmatically until the vicious chunks of it are revealed. A large code often means more code to emulate or the usage of higher-level languages that are much harder to emulate or their emulation is simply not supported. Without an ability to follow the execution logic programmatically, an antivirus product might not be able to detect a well-protected sample effectively.

Reverse Engineering is a slow process, but very soon we will most certainly understand the entire scope of its techniques. The tricks it uses are not new – its memory injection model is different from Duqu/Stuxnet, but is similar to ZeuS. There is nothing new in deployment via existing exploits either. Injection into the system process to bypass firewalls has also become a de-facto standard for advanced persistent threats.

Its ‘business level’ purpose and intent are interesting to know, but being a backdoor trojan, its fundamental purpose is to control and monitor the victim, and to steal information. A thief is a thief – its full purpose and intent of its actions is to steal… ‘why’ is a different question.

Should you be worried?

Well, when it comes to the malware, one should never be complacent about it. The malware threat landscape is an extremely dynamic scene, and Australian businesses should always stay agile, be aware about the trends and tendencies, and fully understand the capabilities of modern malware and the associated risks. Flame is probably not aimed at you, but don’t discount the chance of one that is aimed at you, turning up in future.