Inside sKyWIper/FLAME

sKyWIper, also known as FLAME/FLAMER was not designed to simply steal passwords or damage files. It was an enormous modular espionage platform capable of turning an infected Windows computer into a listening device, network reconnaissance station, Bluetooth scanner, document collector and gateway into surrounding systems.

It was publicly exposed in May 2012 after researchers investigating attacks against Iranian computer systems uncovered something far larger and more sophisticated than an ordinary virus. Evidence indicated that it had been operating since at least 2010, primarily against carefully selected targets in Iran and other parts of the Middle East.

According to Kaspersky’s original analysis of Flame, it combined the functions of a backdoor, Trojan and worm. Its operators could install additional modules, activate particular surveillance capabilities and instruct it to spread across a local network or through removable media. Flame was less like one fixed piece of malware and more like an expandable intelligence collection system.

Flame was exceptionally large for malware of its era. Its complete collection of components reached roughly 20 megabytes, while most contemporary malware was measured in kilobytes. Much of that size came from its libraries, databases, compression tools, encryption functions and interchangeable surveillance modules.

Once inside a computer, Flame loaded its core components and began gathering information about the system. It could identify the operating system, hardware, user accounts, network configuration, installed software, storage volumes and available surveillance devices. Its operators could then activate the modules they needed for that particular target.

The basic sequence was straightforward. Flame started with Windows, inventoried the computer, activated selected surveillance modules and stored the collected information locally. When a usable network connection became available, it contacted its command infrastructure, uploaded selected material and received configuration changes, additional modules or new instructions.

The CrySyS Lab technical analysis of sKyWIper found that Flame used structured databases to manage what it collected. This allowed it to quietly gather information over time rather than immediately transmitting every screenshot, recording or document. Information could remain staged on the laptop until Flame decided that the correct communication conditions had been met.

One of Flame’s most unusual capabilities was its ability to examine the physical environment surrounding the infected computer. A module named BeetleJuice enumerated discoverable Bluetooth devices near the machine and collected information broadcast by nearby phones and other Bluetooth equipment.

Depending upon its configuration, BeetleJuice could also turn the infected computer into a Bluetooth beacon. The computer would become discoverable and encode information about Flame’s status within its advertised device information.

Kaspersky documented BeetleJuice in its analysis of Flame’s individual surveillance modules. This was not merely network reconnaissance. Flame was using the laptop’s Bluetooth hardware to observe devices physically present within radio range.

On a home laptop, that type of activity could appear as repeated engagement with the Bluetooth adapter and surrounding devices. Bluetooth services could repeatedly discover, identify or process nearby equipment even when the person using the laptop was not actively pairing anything. A familiar phone entering range could be noticed again, its broadcast information collected and the result stored with Flame’s other surveillance data.

That Bluetooth activity could occur alongside recurring entries from Windows components responsible for device discovery, Bluetooth communication and device setup. If the malware repeatedly queried the adapter or reacted to changing devices in the surrounding area, Event Viewer could show bursts of activity rather than one predictable event occurring at the same hour every day.

Flame also contained a module called Microbe that handled audio surveillance. Microbe listed the multimedia devices installed on the infected computer, recorded their complete configurations and attempted to select an appropriate recording source. Once it identified a usable microphone or audio source, Flame could record conversations occurring near the computer.

This meant that Flame did not simply request access to a microphone by name. It first examined the available multimedia hardware, determined which recording devices existed and chose one that could provide useful audio. That inventory process could involve built in microphones, Bluetooth headsets, external microphones, webcam microphones and virtual audio endpoints.

On a home laptop, the audio portion could appear as repeated enumeration of recording devices, unexplained initialization of microphone hardware or recurring interaction with Windows audio services. Audio endpoints could be opened, queried and released while no visible recording application was running. If devices were connecting and disconnecting, Flame could inventory the changed configuration again and select a different recording source.

The malware compressed the captured audio and stored it for later transmission. This allowed a compromised laptop to function as an unattended room listening device without requiring an operator to maintain a continuous live connection.

Flame could also collect screenshots, keyboard input and information associated with internet communications and applications. Its surveillance capabilities included capturing screenshots when targeted programs were active and collecting information connected to conversations occurring through software such as Skype.

The combination was significant. Flame did not depend upon one source of intelligence. It could combine microphone recordings, screenshots, keystrokes, documents, Bluetooth observations and network information to reconstruct what was happening both on the computer and around it.

A person using an infected home laptop might not see one obvious program named Flame. Microsoft’s threat description stated that there were no obvious symptoms that clearly announced the infection. What could remain visible instead were the individual actions performed by its modules.

Those actions could include recurring device enumeration, unexplained microphone or multimedia activity, repeated Bluetooth discovery, temporary files created outside normal user activity, services loading components, removable volumes being accessed, periods of increased processor or disk activity and bursts of encrypted network communication.

Event Viewer could preserve portions of that activity across several channels. Bluetooth operations could touch Bluetooth and device related providers. Audio discovery could touch multimedia, audio endpoint and device framework components. USB activity could engage removable storage, volume and device setup logs. Module loading and persistence could generate service or application events. Network reconnaissance and command communications could generate connection, authentication, firewall or name resolution activity.

The pattern would not necessarily be one identical warning repeated forever. It could be a cascade. A nearby device appears. Windows reports a Bluetooth or device state change. Flame inventories the device environment. An audio or network module becomes active. Information is written to local storage. An outbound connection follows. The machine becomes quiet again until another event or instruction starts the next cycle.

That sequence could also begin when the laptop wakes from sleep, connects to a network, detects removable media, sees a nearby Bluetooth device or receives instructions from its command server. Surveillance activity could therefore occur at different times on different days while still following the same operational pattern.

Flame contained network monitoring and reconnaissance capabilities that extended its reach beyond the originally infected machine. It could examine local network traffic and collect account information, usernames and password hashes transmitted across the network. It could inventory surrounding resources and provide its operators with information about other accessible computers.

On a home network, those functions could involve repeated queries involving adapters, local addresses, available computers, shared folders and network services. The resulting activity could appear alongside authentication attempts, share access, name resolution requests and connections to systems that the laptop owner had not deliberately opened.

Flame also possessed worm-like functions. When instructed, it could replicate through local networks or removable media. This gave its operators a method of moving into additional systems, including computers that were not normally connected directly to the internet.

Its removable media component could prepare USB devices to transport the malware between systems. The documented Flame modules included an Infect-media component capable of using multiple methods to infect removable media. One method created an autorun file. Another used a specially constructed directory and shortcut to launch Flame.

On a home laptop, that could produce activity whenever a thumb drive, external drive, memory card or phone exposing writable storage became available. The new volume could be enumerated, its contents examined and files or shortcuts created or modified. That process could repeat for each newly mounted storage device.

Flame’s most technically remarkable propagation method involved the abuse of Microsoft’s digital certificate infrastructure. Some Flame components were signed with certificates that made the malicious software appear to originate from Microsoft. The attackers exploited an older cryptographic design to create a fraudulent signature that Windows would accept as valid.

Microsoft confirmed in Security Advisory 2718704 that unauthorized certificates had been used to sign malicious code. The company revoked the affected certificates and released an emergency update to prevent Windows from trusting them.

In certain network conditions, an infected computer could intercept another computer’s update request and deliver Flame while presenting the malware as trusted Microsoft software. Microsoft explained that the operation combined the unauthorized certificate with a network interception technique. Its technical explanation of the Flame collision attack showed that the certificate contained deliberately constructed data rather than a random signing error.

This was an extraordinary subversion of trust. The victim did not merely receive an unknown executable. Windows was presented with malicious code carrying what appeared to be Microsoft’s own approval.

Flame communicated with an extensive command infrastructure. Researchers eventually counted almost 100 servers and domains associated with its operations.

The servers received information from infected systems, issued instructions and managed different malware components. A joint forensic investigation by Kaspersky, Symantec, ITU IMPACT and German authorities found that the server platform handled at least four separate malware projects. Flame was identified internally as FL, while three other platforms were represented by the names SP, SPE and IP.

The forensic analysis of Flame’s command servers concluded that development of the server platform began as early as 2006. The infrastructure used encrypted communications, concealed stolen information and was disguised to resemble an ordinary content management system.

Flame could perform automated collection while still accepting configuration changes and instructions from its operators. Its activities did not have to occur at the same hour every day. Different modules could activate according to configuration, system conditions, network availability or instructions received from the command infrastructure.

This means activity on a home laptop could arrive in clusters. Device and audio enumeration might begin immediately after a phone appears nearby. Network discovery could begin after the laptop joins a particular network. Stored recordings and screenshots could remain on the computer until internet access becomes available. A command server check in could then be followed by additional inventory, collection or upload activity.

The timing could also be deliberately varied. Rather than contacting its infrastructure every ten minutes at an exact interval, malware can randomize the delay or wait for a particular system event. That makes the activity appear irregular even when it belongs to a programmed collection cycle.

A computer running Flame could therefore produce recurring activity across hardware, services, storage, networking and user applications. Bluetooth enumeration could engage the Bluetooth stack and related device services. Microphone surveillance could repeatedly inventory audio endpoints, initialize recording hardware and access multimedia configuration. Removable media functions could react to newly mounted volumes. Network reconnaissance could create repeated connections, authentication activity and resource discovery. Persistence and module loading could involve services, libraries and scheduled execution.

This is what makes Flame particularly relevant when examining system wide Event Viewer churn. It was specifically designed to coordinate multiple forms of discovery and surveillance from one infected Windows machine. Bluetooth equipment, audio devices, network resources, removable storage and user activity could all become part of the same collection operation.

Flame was publicly exposed more than a decade ago, but its architecture feels strikingly modern. It treated the infected computer not merely as a source of files but as a collection platform positioned inside a physical and digital environment.

It could observe the person using the computer, devices located nearby, conversations occurring in the room, activity displayed on the screen, information moving across the network and systems connected through removable media.

Its discovery also revealed the scale of the operation behind it. The command infrastructure supported several malware platforms, used extensive encryption and had been developed for years before Flame became publicly known. Kaspersky’s later examination of the lessons learned from Flame connected its development to the broader Stuxnet operation and described it as a defining example of nation state cyber espionage.

Flame demonstrated that malware could transform an ordinary Windows laptop into something much larger than a compromised computer. It could become a sensor, recorder, scanner, data repository and communications node, quietly observing both the system and the environment surrounding it.

sKyWIper/Flame was heavily concentrated in the Middle East and focused on the oil industry. The United States appears in reporting about Flame primarily as a suspected sponsor, not a documented victim. Later reporting attributed the broader Flame and Stuxnet operation to the United States and Israel, although the governments did not publicly acknowledge developing Flame. Kaspersky also found technical connections between the Flame and Stuxnet development efforts. 

The clearest American example is PlugX, also called Sogu or Korplug. And it was absolutely used inside the United States. In January 2025, the Justice Department announced that the FBI had removed a China backed version of PlugX from approximately 4,258 American computers and networks. DOJ said the infected systems included numerous home computers and that the campaign targeted American victims, foreign governments, businesses and Chinese dissident groups. The DOJ’s full announcement is here.⁠