Flame 2.0 is a later iteration of the Flame malware platform, not a newly discovered threat in 2026. Chronicle Security researchers reported it on 9 April 2019 after finding samples with build evidence pointing to components compiled in February and March 2014. They estimated the iteration was likely used during 2014–2016, but the dates do not prove when or where the malware was deployed. The samples retained Flame’s Lua-based architecture while adding AES-encrypted resources and 64-bit Windows builds; researchers could not decrypt those resources, so much of the payload’s behavior remains unknown.
What was discovered, and when?
In their 9 April 2019 technical report, Juan Andrés Guerrero-Saade and Silas Cutler of Chronicle Security described samples they identified as a new iteration of the Flame platform. They wrote that it was “likely used in the 2014-2016 timeframe.” That is the researchers’ estimate of use, not a confirmed period of continuous operation.
The evidence and timeline are distinct:
- May 2012: MAHER, Kaspersky Lab, and CrySyS Lab announced discovery of the original Flame platform, according to the Chronicle report. In late May, operators distributed a SUICIDE module to clean up infections, and remaining controlled command-and-control infrastructure was scrubbed.
- February–March 2014: Build-time evidence in a subset of the later samples pointed to compilation during these months.
- 2014–2016: Chronicle researchers estimated this as the likely use window for the later iteration.
- October 2016: Chronicle’s companion account says samples had appeared in VirusTotal by this month. It suggests they may have been in private antivirus collections earlier, but that earlier availability is not established as a certainty.
- 9 April 2019: Chronicle published its technical disclosure and called for further collaboration to understand the encrypted resources and broader campaign.
The findings are historical. The cited accounts do not establish that Flame 2.0 is active today.
How did researchers date the samples?
The samples’ visible compilation times had been changed to look older. In some samples, however, debug symbols exposed a timestamp associated with a statically linked library that the researchers assessed as PuTTY-related. That embedded timestamp pointed to February–March 2014. By comparison, the report says ordinary Flame component dates fell between October 2009 and August 2011.
#1 Best Overall
This is evidence about compilation, not deployment: a timestamp in a linked library can support an inference about when a component was built, but it does not show when an operator installed or ran it. The 2014–2016 use period is a separate researcher estimate.
What changed from the original Flame platform?
The later samples show both continuity with Flame and technical changes. Chronicle researchers said the samples were clearly built on Flame source code. Their main orchestrator still used an embedded Lua 5.1 controller, consistent with Flame’s modular architecture.
Rank #2
| Dimension | What the report says | What it establishes |
|---|---|---|
| Platform lineage | Researchers identified the samples as built on Flame source code. | Continuity with Flame; not a separate, unrelated family. |
| Orchestration | The main orchestrator used an embedded Lua 5.1 controller. | A continuing modular design; it does not reveal every module’s behavior. |
| Embedded resources | Resources were AES-encrypted, including with AES-256. | A significant change in how components were protected; researchers could not decrypt the resources. |
| Windows architecture | The report identifies the first Flame samples compiled for 64-bit Windows. | A new build architecture in the samples analyzed, not evidence of a particular victim population. |
The report names candidate orchestrator files sensrsvcs and sensrsvr, and suspected submodules wmisvcs and wmihost. It also says operators appear to have passed a decryption key to the orchestrator through DLL export arguments. These details describe observed sample structure; they do not expose the encrypted modules’ full purpose.
What could Flame 2.0 do?
Researchers could not decrypt the embedded resources, leaving the scripts and payloads they contained undisclosed. Strings and API references offer clues, but not a verified, complete feature list:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Audio-input interaction and process enumeration were possible capabilities inferred from strings and API use.
- Some process checks appeared to involve particular antivirus products.
- PuTTY- and Plink-related strings suggested possible support for lateral movement.
These functions remain suspected rather than confirmed. The report cautions that API calls may also support basic execution. The published sample hashes, artifacts, and YARA rules can help analysts identify the samples described in the report, but they do not resolve the unknown payload behavior.
What is known about attribution and scope?
The connection to Flame source code does not, by itself, identify who operated the later iteration. The cited reporting does not establish a responsible state, the operators’ identities, a complete victim list, or a confirmed geographic deployment scope for Flame 2.0. It also does not provide a defensible current count of infections or active samples. Counts associated with the original Flame or the wider Equation group should not be treated as counts for this later iteration.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How does the 2012 certificate incident fit?
The original Flame disclosure included a separate certificate issue. In a 3 June 2012 post, Microsoft said some Flame components had certificates that made software appear to be produced by Microsoft. Microsoft traced the risk to an older cryptographic algorithm and its Terminal Server Licensing Service, which had issued certificates with code-signing ability. The company said it released Security Advisory 2718704 and an update, and stopped the service from issuing such certificates.
This is historical context about original Flame. The Microsoft account does not establish that Flame 2.0 used the same signing method.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Best Value
Sources
- Chronicle Security, “Flame 2.0: Risen from the Ashes” (9 April 2019), the technical report on sample evidence, architecture, suspected capabilities, and analysis limits.
- Chronicle Blog, “Who is GOSSIPGIRL? Revisiting the O.G. Threat Actor Platforms” (9 April 2019), a companion account of the disclosure and timeline.
- Microsoft Security Response Center, “Microsoft releases Security Advisory 2718704” (3 June 2012), on the original Flame certificate issue and Microsoft’s response.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
