By John Green, CTO, Prolinx
In early June this year, Flame set the blogosphere and media landscape on fire. But why was this such a big deal, when evidence suggests that this malware tool apparently has been in existence for more than two years (or possibly five) and has infected hundreds of organisations in various countries in the Middle East?
Well there’s a multitude of reasons. Firstly, based on initial analysis, and the fact that it’s an advanced data-stealing tool designed originally to compromise information from organisations in Middle East, security experts started speculating that Flame was built by a Western intelligence agency or possibly even the military. Secondly, at the time of the news breaking around Flame, it was still unclear whether the initial infection vector could use any previously unknown vulnerability in Windows or other applications. This, of course, has since been cleared up, as it was proven that Flame can spoof a Microsoft intermediate certificate and impersonate a legitimate windows update file, as the code appears to be signed by Microsoft.
Thirdly, Flame, it was discovered, is modular in nature. Once the host has been successfully compromised Flame malware configures as an internal web server to distribute itself. This removes the need for it to make multiple calls to the web based CinC servers to get instructions. As such, it only takes one compromised host to call back for instructions or updates then all other infected host within the network can communicate with an internal source – a great cause for security concern as this behaviour reduces this risk of detection through external communications.
In my opinion, the reason for the media buzz was that it soon became clear that Flame is a rather large, complex and well put together piece of malware that followed in the famous footsteps of both Stuxnet and Duqu .
However, I feel that security experts have to be careful and differentiate Flame from its predecessors, both in scope and construction, because, at least in design, it’s quite elegant. Instead of trying to infect as many machines as possible, Flame takes enormous care to avoid detection by running its files and processes under innocuous names in formats that are difficult to scan or ignored completely by traditional IPS/IDS solutions. It’s also designed to evade anti-virus by storing code in files which are generally not scanned by anti-virus agents. Moreover, its choice of file extension is determined by the vendor of the anti-virus product that has been detected on the host.
So the question is, what could have been done to prevent the spread of Flame? Working for a company that specialises in security, I would say that through tight integration of traditional security technologies, along with infrastructure audit logs and next generation security technologies security specialist could have provided the kind of defence required to detect and respond to advanced persistent threats, without user downtime and with full visibility.
I’ll admit that this is not new information, but it’s important that IT professionals are reminded of it every once in a while for a number of reasons. IT professionals and companies need to know that these kind of operations are happening on a regular, ongoing basis and that. Whilst attack tools such as Flame are scary, they’re by no means unique. Flame, Duqu and Stuxnet are just the ones that made it into the media. In addition, the discovery of Flame after two to five years of use should remind us that the defences most organisations have in place right now are of little use for detecting custom threats and tools.
Ultimately, the biggest lesson is that security and defence against malware is a big job and often more difficult than one would think. You need a team with the time and motivation look out for malware all the time, not just when a crisis strikes. The discovery of Flame illustrates this point perfectly.
No related posts.