Apr 9, 2019 · 12 min read

Revisiting the O.G. Threat Actor Supergroup

Threat intelligence as a discipline is the continuous pursuit of cyber situational awareness. The idea that there are threat actors out there, unbeknownst to us, operating in the shadows, with impunity is something that drives researchers to hunt further and further. The more unsettling experience is having a small piece of information on a threat without context: a single indicator, a rumor, …a name. That maddening uncertainty drove us from a vague name on a creative revisiting of a cluster of the most prolific and daunting threat actors ever discovered. And along the way, we were given the opportunity to fill in important gaps in the history of humankind’s incursion into the fifth domain.

Studying Our Favorite Slidedeck

Image for post
Image for post

Slide highlighting some of the threat actors tracked in REPLICANTFARM by their cryptonyms

Some of these actor names, like MAKERSMARK and SNOWGLOBE are now familiar to us. The former now a common name related to Moonlight Maze, Agent.BTZ, and Turla. The latter (as the presentation goes on to detail) is another name for Animal Farm and includes its well-known Babar malware family. But who are these other actors worthy of rising to the scrutiny of our northern siblings?

We combed through the presentation inch by inch, hoping some small fragment would slip out that we’d be able to associate to the unidentified actors. A small sliver of hope presented itself in Slide 23. A pixelated screenshot of an alerts window shows barely legible signature names like mod_101_MM_CARBON — a likely reference to MAKERSMARK’s (i.e.Turla’s) Carbon system. That would mean the format of these signatures is:

Image for post
Image for post

Combing through the other legible names, we were largely stumped. The actor acronyms were either unrecognizable or the malware family names were unfamiliar or of little hunting value. However, one signature stood out, ‘mod_501_GR_FLAME.pl’. Was this a connection between GOSSIPGIRL and Flame? The thread was thin but it was all we needed to set us off on our parallel investigation.

GOSSIPGIRL on a Blank Slate

So how best to start an investigation into what CSEC might’ve been looking at with Flame? Well, we could turn to a different leak. As part of the Shadow Brokers leaks, the security community got access to a series of malware signatures for a program identified as Territorial Dispute (‘TeDi’). The TeDi signatures are an interesting (if likely outdated) snapshot of Five Eyes Counter-CNE efforts and, as such, a great starting point for rebuilding what might be categorized under the GOSSIPGIRL moniker. Dr. Boldizsár Bencsáth published excellent work identifying a portion of the TeDi signatures. Among them, two signatures for Flame (SIG9 and SIG16) as well as a signature for its likely predecessor, Miniflame (SIG10).

Applying Modern Tooling to Ancient Problems

However, the rapid rate of discovery often leads modern practitioners to mistakenly assume that the tooling available to the researchers involved in these discoveries is any way comparable to our own. Remember that at the time YARA rules were not widely used for malware research. Nor did researchers have access to VirusTotal retrohunts, code similarity searching at scale, ngram or byte-string searches, etc. Most of the modern tooling that makes hunting for malware scalable was not available. Instead, these researchers were relying on tooling proprietary to each AV company and stitching their visibility together as best they could to form a picture. The limitation only makes their discovery more admirable but it also made us wonder ‘what did they miss?’

Ultimately, we decided to take creative license with the GOSSIPGIRL term and use it for two purposes: to compensate for an ontological deficiency in threat intel terminology, and, to investigate a collaborative umbrella of threat actors.

Describing Supra Threat Actors

The resulting limitations are best exemplified by Regin as a likely multi-country platform, Equation as a likely multi-institution umbrella, and Red October as a possible dual-country collaboration. While each of these ‘threat actors’ was researched extensively and competently, the industry was ill-equipped to describe the perpetrator arrangement faithfully. For that, we want to introduce the concept of a Supra Threat Actor or STA.

The introduction of a supra category of activity clustering isn’t meant to add complexity to an already jargon-filled space but rather to allow us to faithfully describe the interesting phenomenon of multi-threat actor or multi-platform operations. The staple of these (as opposed to a threat actor that uses two or more closed-source malware families) is a formalization of cross-platform compatibility that allows droppers, payloads, and configuration files be co-opted and instrumented by the closed-source tooling of other threat actors. We have seen multiple examples of this next-level development practice amongst the true apex threat actors.

A notable example is appears to be the case of the Wzowski API that allows the CSEC and DSD’s WARRIORPRIDE, GCHQ’s DAREDEVIL, and NSA’s STRAITBIZZARRE and UNITEDRAKE tooling to work together despite independent development practices.

With GOSSIPGIRL we’ll be discussing another example of a collaborative threat actor umbrella.

All Roads Lead to Stuxnet

Instead, we shifted our focus onto Stuxnet. In June 2012, Kaspersky researchers discovered that the older version of Stuxnet included a Flame plugin, Resource 207. This connected Flame as one of the threat actors involved in the development of Stuxnet. And it ultimately placed Stuxnet in a central role for our research into the GOSSIPGIRL STA. If we are going to treat GOSSIPGIRL as a collaborate supergroup of threat actors, then Stuxnet represents the fruit of their collaboration. As such, Stuxnet placed at least two other threat actors within the scope of our research: Duqu and Equation.

Researchers connected Duqu to the development of Stuxnet early on. Main Stuxnet kernel drivers (like ‘mrxcls.sys’) shared developmental links with Duqu’s ‘Tilde-D platform’, involving the threat actor in some of the central development of Stuxnet. Equation, on the other hand, would eventually be connected by the use of exploits shared by both Stuxnet and an earlier Equation Group worm named Fanny. Fanny utilized two Stuxnet zero-days 1–2 years before Stuxnet entered the scene: the infamous LNK exploit (CVE-2010–2568) and a privilege escalation embedded in the aforementioned Resource 207. Furthermore, Kaspersky researchers would note shared coding practices between the Stuxnet and Equation developers.

Choosing to stand on the shoulders of the research giants that discovered these operations, we decided to dive once again into the malware. We hoped that leveraging technology and insights unavailable to our predecessors would yield a greater understanding of the GOSSIPGIRL STA. The resulting discoveries were beyond our wildest expectations.

Our Discoveries in a Snapshot

Image for post
Image for post

GOSSIPGIRL Supra Threat Actor cluster of interrelated actors and malware platforms including new discoveries.

After casting such a wide net for insights on what was supposed to be old news, we actually fished out more discoveries than we could handle. Each of these merits a technical deepdive in its own right and links are provided for a technical writeup detailing each. We hope other researchers, malware analysts, and defenders will benefit from the breakdowns and technical indicators. In brief:

STUXSHOP: The Oldest Stuxnet Component Dials Up

Image for post
Image for post

Stuxshop function call graph highlighting identical embedded Flowershop functionality

Key takeaways:

  • Stuxshop ties a fourth threat actor into the GOSSIPGIRL Supra Threat Actor responsible for Stuxnet.
  • Stuxshop further exemplifies the modular design that produced Stuxnet, as a ‘plane flown as it’s being built’.
  • It lends credence Symantec’s hypothesis that Stuxnet was in development as early as 2005, as the Stuxshop compilation timestamp signals 2006 and the relevant overlapping Flowershop codebase was seen in-the-wild as early as 2007.

Read Stuxshop technical analysis (pdf)

Duqu 1.5: A Ghost in the Wires of a Diplomatic Venue

Duqu 1.5’s experimental modular design

Key takeaways:

  • An incident response team’s tenacity for answers revealed artefacts to recreate a full Duqu 1.5 infection across the network of a diplomatic venue.
  • The missing link reveals the iterative development efforts that lead from the burned Duqu 1.0 version of the ‘Tilde-D’ platform to the fully in-memory implementation of Duqu2.0.
  • It includes a more bloated, experimental, multi-tier loading chain: it starts with a trojanized floppy kernel driver signed with a stolen certificate to load up a registry virtual file system (VFS), that loads an in-memory orchestrator, which then loads an on-disk VFS, to deploy a series of plugins for further spreading and backdoor access to infected machines.
  • If it weren’t for the watchful stance and reflex of the incident response team, Duqu 1.5’s multi-tier structure would’ve kept researchers from ever rebuilding all the components of this infection. Moreover, two different AV companies analyzed the first-stage kernel driver without flagging it as malicious. At the time of writing, static detection ratio remains at zero.

Read Duqu technical analysis (pdf)

FLAME 2.0: Risen from the Ashes

Image for post
Image for post

Mapping leaked build times show’s a development beyond deployment of Flame 1.0’s SUICIDE module

Key takeaways:

  • Some Flame 2.0 components continued to leak the original build time of an underlying statically-linked PuTTY library whenever the attackers forgot to remove debug symbols.
  • Despite timestomping the sample compile times to look older, the leaked build times show that Flame 2.0 samples were compiled as early as February 2014, nearly two years after the deployment of the SUICIDE module.
  • Flame 2.0 includes the first Flame samples compiled for 64-bit Windows systems.
  • The attackers now employ AES-256 to encrypt the second-stage embedded resources. At this time, we’ve been unable to crack the encryption to reveal what new scripts and payloads are deployed by Flame 2.0 after a successful infection.

Read Flame 2.0 technical analysis (pdf)

Parting Insights

Firstly, research into past incidents allows us to leverage new tools and insights that weren’t available at the time of initial discovery. At the time Stuxnet, Flame 1.0, and Duqu 1.0 were discovered, YARA rules weren’t widely used, VirusTotal’s retrohunt capability weren’t available, nor did we have access to scalable code similarity engines.

Secondly, retrospective research allow us to unearth connections between diverse threat actors and malware platforms that expand our understanding of the notable adversaries in cyberspace and their respective institutional configurations. These insights speak to humankind’s incursion into the fifth domain. If we fail to study and document these incidents while the source data is still available, it may prove impossible in the future.

Finally, if it’s not evident by now, retrospective research yields unexpected surprises. While the research community assumed Flame had retired and ceased to track this ominous threat actor, Flame 2.0 samples appeared in VirusTotal as early as October 2016 and were likely available in private AV collections a year or two before that. Given that Flame proved to be one of the most daring threat actors ever discovered (going so far as to leverage an innovate MD5 hash collision attack to subvert the Windows Update mechanism to spread infections across an enterprise), this isn’t an adversary we should take lightly in our remit to defend the internet ecosystem.

From a methodological standpoint, we hope that the research community will take cautious advantage of a higher ontological category to describe collaborative frameworks for multiple threat actors. GOSSIPGIRL isn’t the first supra threat actor (STAs) unearthed by the research community, it’s only the first to be described in comprehensive terms. A focus on this ‘multi-tenant’ model of modular malware development and deployment should allow for a higher-fidelity understanding of: the trends followed by seemingly diverse threat actors, the closed-door sharing of techniques and tools, and the organizational complexities behind clusters of malicious activity that defy simplistic attribution claims.

Discovering, understanding, and continuously monitoring complex attacks is difficult and requires a mixture of specialized talent, tooling, and visibility that most enterprises and institutions don’t have access to. It’s unrealistic to expect every company to develop these capabilities in-house. However, as the Duqu 1.5 example shows, the collaboration between driven incident responders and threat researchers yields insights that benefit our shared defense mission in a way neither could accomplish on their own.

A better understanding of the institutions and incentives involved in cyberespionage further supports the view that threat actors don’t go away after exposure; our aggressors never truly vanish. They have an intelligence remit to fulfill and will go to great lengths in doing so. The defender community must be willing to match these efforts in order to insure the collective safety of users and organizations that lack the resources to defend themselves against the most formidable threat actors.

One got outed…

…one went to sleep…

…one faded into memory…

…and one simply played dead.

Chronicle Blog


Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store