Alert icon Keyboard navigation enabled.
Alert icon TAB or Shift+TAB to navigate across. Down ↓ to open menu. ESC to close menu.
Alert icon Down ↓ to select section. Right → to activate. Up ↑ / Down ↓ / Tab to traverse all. ESC to exit.
BeyondTrust
Skip to content Use space or enter to skip.

What can we help you find today?

Instant Results
  • Website Results
  • Technical Documentation

Filter Options

Focus your search

Filtering by

Your recent searches:

Contact Us Chat with Sales Get Support
  • English
  • Deutsch
  • français
  • español
  • 한국어
  • português
  • Home
  • Resources
  • Blog
  • Flame is frightening but don’t hide under the bed current page
Link copied

Flame is frightening but don’t hide under the bed

Oct 20, 2017
Author:
John Dunn
Blog banner default
Flame is frightening but don’t hide under the bed
John Dunn

Cyber-weapons set the security bar uncomfortably high. But why make it easy for them?

Imagine a hacking enterprise free to develop malware on the back of an unlimited budget, a small army of elite coders and mathematicians, barely-documented programming, and a clutch of software vulnerabilities the world has never heard of. Stopping such a program would surely be nigh on impossible.

Until the discovery of a hugely sophisticated cyber-malware platform called ‘Flame’ three weeks ago this often-imagined security fantasy was just that – highly unlikely. Only large countries steeped in decades of computing development would have the resources to take on such a project and, it was argued, the political embarrassment of exposure would act as a deterrent.

Astoundingly, judging from the age of some Flame components it now looks as if the world crossed into the age of super-malware as far back as 2007 without even realizing it. Worse, Flame was not a lone warrior, having now been forensically linked to a second platform called ‘Stuxnet’ (discovered 2010), and a third, the enigmatic and frankly pretty odd ‘Duqu’ (discovered 2011).

Here is not the place to speculate on who created this software or why (although the targeting of Iran by the US Government looks like an open and shut case frankly), so much as trying to delve into the technical challenges the existence of such software poses for a security industry that is suddenly feeling less self-confident.

Is Flame a big deal? Conceptually, yes. Despite being the largest malware system ever uncovered, Flame went unnoticed for years, partly because it targeted small numbers of systems in countries such as Iran but also because it was so myriad and complex that security vendors were not able to join up enough dots when they encountered fragments of it.

It’s a backdoor, a Trojan, a worm, it compromises multiple programming elements seemingly at will and can even hijack the Windows Update mechanism using forged code signing and cryptographic cleverness that have been described by experts as working in ‘God mode’. The more we learn about Flame, the more it seems to draw attention to the apparent puniness of security systems ranged against it, be they firewalls, intrusion detection system, or anti-virus.

The first thing to say about Flame, Stuxnet and Duqu is that they are unusual – the chance of even large companies being hit by such a malware system right now are probably small. But that won’t last. Flame’s success will breed imitators with much more mundane motivations, including profit and subversion. This brings us back to assessing its real threat.

I’ve come to the conclusion that while Flame would have been impossible to stop in its entirety given the extremes its designers went to, defenders can still learn some lessons for the future.

Might patching have stopped it? Not on its own (it accessed at least five zero days over time), but rapid vendor release and application cycles clearly shorten the time period malware developers have in which to use each exploit. Given that patching is better in 2012 than in 2008, this is a good start.

How about blocking its infection route? Appealing, but unreliable. We now know that anti-virus alone couldn’t stop Flame jumping to its targets from infected USB sticks. Even seeing it on these drives would have been difficult as Flame hid itself by interfering with the FAT32 file system.

Here’s a small chink, however; Flame spread from USB sticks through a zero day exploit that caused a privilege escalation at Windows kernel level (probably patched in June 2009 as MS-209 025); this was the purpose of a module identified by one security vendor as ‘Resource 207’ common to both Stuxnet and Flame.

Would privilege management have helped? Answering this is complex and would depend on the state of the compromised system and what it was being used for – we know they were probably running XP and at least some of them were being used in a conventional, insecure Windows setup.

Removing admin rights from as many systems as possible would have forced the malware to look for other systems not defended in this way, a significant inconvenience and one that would have slowed its spread. In 2008, it is unlikely that the risk posed by the ability for software to elevate privileges on Windows was appreciated; in 2012 there is no excuse to ignore this weakness.

It is intriguing that the anti-virus defense designed to catch malware could fail so spectacularly while the less obvious approach of restricting what each system can do would have had more success. Unaccountably, privilege escalation is now used in a large number of relatively mundane exploits and yet the option to manage this dimension is still seen by some as unconventional.

As every security vendor will tell you, the answer is to layer security, but some layers are probably more important than others. Many organizations seem to over-invest in antivirus and firewalls when attackers have clearly figured out how to beat those long ago.

Flame tells us that the new front line is elsewhere; in privilege restriction, in allow listing and in a ferocious commitment by admins to strip out every conceivable weakness from their networks. If you were attacking your network, how would you do it?

Latest Posts
  • Hooked on Identity (Part 2): Abusing OAuth Trust Boundaries in Okta
    Jun 12, 2026 Hooked on Identity (Part 2): Abusing OAuth Trust Boundaries in Okta
    Blog
    7m
  • Hooked on Identity: Abusing SAML Assertion Inline Hooks in Okta
    Jun 9, 2026 Hooked on Identity: Abusing SAML Assertion Inline Hooks in Okta
    Blog
    6m
  • Joining Project Glasswing: Securing the Privilege Backbone of the AI Era
    Jun 8, 2026 Joining Project Glasswing: Securing the Privilege Backbone of the AI Era
    Blog
    5m
  • The Most Common & Most Dangerous Types of Shadow IT
    Jun 5, 2026 The Most Common & Most Dangerous Types of Shadow IT
    Blog
    19m
  • 14 Password Management Best Practices
    May 28, 2026 14 Password Management Best Practices
    Blog
    12m
Related
  • The Anthem Breach: What We Know Now
    Feb 5, 2015 The Anthem Breach: What We Know Now
    Blog
    1m
  • CIEM Security Best Practices: 5 Steps to Success
    Feb 27, 2026 CIEM Security Best Practices: 5 Steps to Success
    Blog
    7m
Share this Article
  • Link
Stay up to Date
Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

Keep up with BeyondTrust

Customer Support Get Started
  • LinkedIn
  • X
  • Facebook
  • Instagram
  • Add BeyondTrust as a preferred source on Google
  • Privacy
  • Security
  • Manage Cookies
  • Do Not Sell My Data
  • WEEE Compliance

Copyright © 2003 — 2026 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.

Prefers reduced motion setting detected. Animations will now be reduced as a result.