The world is abuzz this week with some flaming malware – well “Flame” is the family name if you want to be precise. The malware package itself is considerably larger than what you’ll typically bump into on average, but the interest it is garnering with the media and antivirus vendors has more to do with the kinds of victims that have sprung up – victims mostly in the Middle East, including Iran – and a couple of vendors claiming the malware as being related to Stuxnet and Duku.
A technical report on sKyWIper was released by the Laboratory of Cryptography and Systems Security (CrySys Lab) over at the Budapest University of Technology and Economics
yesterday covering their analysis of the malware – discovered earlier
in May 2012 – and they also drew the conclusion that this threat is
related (if not identical) to the malware described by the Iran National
CERT (MAHER) – referred to as Flamer. Meanwhile, Kaspersky released some of their own analysis of “Flame” on Monday and created a FAQ based upon their interpretation of the malware’s functionality and motivations.
analyzed by Webroot and attributed to a system in Iran.
it’s practically a certainty that the malware was created and infected a
number of victims before it was “detected” in May, I’d caution against
some of the jumps people are making related to the attribution of the
Firstly, this behemoth of a malware pack is constructed of a lot of
different files – many of which are not malicious; with the package
including common library files (such as those necessary for handling
compression and video capture) as well as the Lua
virtual machine. Secondly, when you’re limited to an 8.3 file naming
convention, even malicious files are likely to have name collisions –
resulting in many spurious associations with past, unrelated, threats if
you’re googling for relationships. And finally, why build everything
from scratch? – it’s not like malware authors feel honor bound to adhere
to copyright restrictions or steal code from other malware authors –
nowadays we see an awful lot of code recycling and simple theft as
criminals hijack the best features from one another.
As you’d expect from a bloated malware package developed by even a
marginally capable hacker, there are a lot of useful features included
within. It’s rare to see so many features inside a single malware sample
(or family), but not exceptional. As Vitaly Kamluk of Kaspersky stated –
“Once a system is infected, Flame begins a complex set of operations,
including sniffing the network traffic, taking screenshots, recording
audio conversations, intercepting the keyboard, and so on,” – which is
more typical of an attack kit rather than a piece of malware. What do I
mean by “attack kit”? Basically a collection of favorite tools and
scripts used by hackers to navigate a compromised host or network. In
the commercial pentesting game, the consultant will normally have a
compressed file (i.e. the “attack kit”) that he can shuttle across the
network and drop on any hosts he gains access to. That file contains all
of the tools they’re going to need to unravel the security of the
(newly) compromised host and harvest the additional information they’ll
need to navigate onto the next targeted device. It’s not rocket science,
but it works just fine.
I’m sure some people will be asking whether the malware does anything
unique. From what I can tell (without having performed an exhaustive
blow-by-blow analysis of the 20Mb malware file), the collection of files
doesn’t point to anything not already seen in most common banking
Trojans or everyday hacking tools. That doesn’t make it less dangerous –
it merely reflects the state of malware development, where “advanced”
features are standard components and can be incorporated through
check-box-like selection options at compile time.
For malware of this ilk, automated propagation of infections (and
infectious material) is important. Flame includes a number of them –
including the commonly encountered USB-based autorun and .lnk
vulnerabilities observed in malware families like Stuxnet (and just
about every other piece of malware since the disclosure of the
successful .lnk infection vector), and that odd print spooler
vulnerability – which helps date the malware packaged. By that I mean it
helps date the samples that have been recovered – as there is currently
no evidence of what the malware package employed prior to these recent
disclosures, or what other variants that are circulating in the wild
(and not been detected by antivirus products today).
Are these exploits being used for propagation evidence that Stuxnet,
Duku and Flame were created and operated by the same organization?
Honestly, there’s nothing particularly tangible here to reach that
conclusion. Like I said before, criminals are only too happy to steal
and recycle others code – and this is incredibly common when it comes to
the use of exploits. More importantly, these kinds of exploits are
incorporated as updates into distributable libraries, which are then
consumed by malware and penetration tool kits alike. Attack kits similar
to Flame are constantly being updated with new and better tool
components – which is why it will be difficult to draw out a timeline
for the specific phases of the threat.
That all said, if the malware isn’t so special – and it’s a
hodgepodge of various public (known) malicious components – why has it
eluded antivirus products in the victim regions for so long? It would be
simple to argue that these regions aren’t known for employing
cutting-edge antimalware defenses and aren’t well served with
local-language versions of the most capable desktop antivirus suites,
but I think the answer is a little simpler than that – the actors behind
this threat have successfully managed their targets and victims –
keeping a low profile and not going for the masses or complex setups.
This management aspect is clearly reflected in the kill module of the
malware package. For example, there seems to be a module named
“browse32″ that’s designed to search for all evidence of compromise
(e.g. malware components, screenshots, stolen data, breadcrumbs, etc.)
and carefully remove them. While many malware families employ a cleanup
capability to hide the initial infection, few include the capability of
removing all evidence on the host (beyond trashing the entire computer).
This, to my mind, is more reflective of a tool set designed for human
interactive control – i.e. for targeted attacks.