medium.com Open in urlscan Pro
2606:4700:7::a29f:9904  Public Scan

Submitted URL: https://t.co/E2b4nT2Xcl?amp=1
Effective URL: https://medium.com/chronicle-blog/who-is-gossipgirl-3b4170f846c0
Submission: On May 31 via api from BY — Scanned from GB

Form analysis 0 forms found in the DOM

Text Content

Open in app

Sign up

Sign in

Write


Sign up

Sign in




WHO IS GOSSIPGIRL?

Chronicle

·

Follow

Published in

Chronicle Blog

·
12 min read
·
Apr 9, 2019

116



Listen

Share

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

Of the multitude of documents leaked from sensitive operations over the past six
years, few are as rich and interesting as a CSEC presentation titled “Pay
attention to that man behind the curtain: Discovering aliens on CNE
infrastructure”. Bullet listings meant to serve as a presenter backdrop are
often too anemic to provide meaningful food for thought in the absence of the
speaker, but that’s not the case here. The CSEC slidedeck discusses different
methods for conducting Counter-CNE (i.e.: threat intelligence). Among the
fascinating insights is a list of threat actor cryptonyms including names like
SEEDSPHERE, ALOOFNESS, and VOYEUR.



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:



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

Flame (a.k.a Flamer or sKyWIper) was the object of extensive research and
fascination by the security community circa 2011. Crysys Lab, Kaspersky Lab, and
Symantec researchers contributed extensive analyses on this modular
cyberespionage platform. While some in the security community were skeptical of
the hype generated by claims of yet another modular platform discovered soon
after Stuxnet and Duqu, Flame impressed all with the discovery that it employed
a novel cryptographic attack to impersonate a Windows Update server within an
enterprise and spread onto other computers as if legitimately signed by
Microsoft itself. Ultimately, it turned out that the fortuitous discoveries of
Stuxnet, Duqu, and Flame were in fact related beyond superficial succession.

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

It’s important to remember just how nascent threat intelligence really is as a
field. Pre-2010, the anti-malware industry considered cyberespionage a
possibility, or perhaps an eventuality, but not an ongoing phenomenon. What
followed was a dizzying period of discovery that made the industry realize that
malware-based digital espionage was not only going on, but had been going
strong, unnoticed for years. The tranquil days of reverse engineering banking
trojans were pierced by Stuxnet, Duqu, Flame, Gauss, and MiniFlame. Each a
complex modular malware family worthy of its own pedigree, most abusing zero-day
exploits, and used to carry out operations imbued with geopolitical gravitas.

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

Private sector Threat intelligence has largely shied away from abstract
methodological discussions. Our concepts have largely served us well, except
when it comes to outliers like mercenary APTs or fourth-party collection
practices. However, ignoring methodological deficiencies leads to problematic
blind spots. In particular, the one-to-one equivalence of a ‘threat actor’ to an
institution or organization has left us incapable of accurately representing
multi-institution, multi-country, or multi-group orchestration in collaborative
operational deployment, platform development, or generally complex deconfliction
practices.

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

As we conducted our parallel investigation into Flame we found ourselves
retracing steps from one malware platform to another, much like the researchers
that originally discovered them. First from Flame to Mini-Flame, it’s likely
predecessor, and then to Gauss, considered a more widespread successor or
perhaps a side operation. However, despite the lore of Gauss (due to its
never-cracked encrypted payload), we didn’t find a live lead there. We were
impressed by the relative simplicity of Mini-Flame and the completely
restructured modular architecture of Gauss, but ultimately it seemed that Flame
had died with the deployment of the SUICIDE module in May 2012.

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



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

Stuxshop is ancient component folded into Stuxnet to manage it’s early
command-and-control capabilities. The discovery of Stuxshop is significant
precisely because it unveils the presence of a fourth team involved in the early
development of Stuxnet. Stuxshop shares unique code overlaps with Flowershop
(a.k.a. TeDi: SIG17/SIG18, Cheshire Cat), a malware platform active from
2002–2013 with targets across the Middle East.



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

An investigation into a ‘Ghost in the Wires’ infection at a venue for diplomatic
talks revealed a missing link in the development from the Duqu 1.0 threat actor
involved in Stuxnet to the formidable Duqu 2.0 in-memory modular platform
discovered in the Kaspersky offices and P5+1 talk venues in Switzerland. This
story highlights what can be accomplished when an excellent in-house incident
response team collaborates with threat researchers to hunt down an elusive
threat.

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

Finally, the third and perhaps most momentous finding was our discovery that
Flame merely faked its own death. In May 2012, the Flame operators issued a
SUICIDE module to clean up active infections and burned down their remaining
command-and-control infrastructure. While this move successfully drove
researchers away from tracking Flame, in reality they were simply retooling. At
this time, we are releasing technical indicators and initial findings of a new
iteration, Flame 2.0, and inviting the research community to collaborate with us
in investigating its resurgence.



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

We are often asked why we bother investigating older threat actors. Why bother
with ‘cyber-paleontology’? The reasons are manifold:

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.





SIGN UP TO DISCOVER HUMAN STORIES THAT DEEPEN YOUR UNDERSTANDING OF THE WORLD.


FREE



Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.


Sign up for free


MEMBERSHIP



Access the best member-only stories.

Support independent authors.

Listen to audio narrations.

Read offline.

Join the Partner Program and earn for your writing.


Try for $5/month
Cybersecurity
Stuxnet
Duqu


116

116



Follow



WRITTEN BY CHRONICLE

1.3K Followers
·Editor for

Chronicle Blog


Follow




MORE FROM CHRONICLE AND CHRONICLE BLOG

Chronicle

in

Chronicle Blog


WINNTI: MORE THAN JUST WINDOWS AND GATES


THE WINNTI MALWARE FAMILY WAS FIRST REPORTED IN 2013 BY KASPERSKY LAB. SINCE
THEN, THREAT ACTORS LEVERAGING WINNTI MALWARE HAVE VICTIMIZED…

7 min read·May 15, 2019

90





Chronicle

in

Chronicle Blog


INTRODUCING VIRUSTOTAL ENTERPRISE


TODAY WE ARE ANNOUNCING AN UPDATE TO VIRUSTOTAL: VIRUSTOTAL ENTERPRISE.

3 min read·Sep 27, 2018

65

1




Chronicle

in

Chronicle Blog


CHRONICLE: CAN I GET THE BACKSTORY?


CHRONICLE IS LAUNCHING BACKSTORY TODAY. IN A NUTSHELL, BACKSTORY IS THE FIRST
GLOBAL SECURITY TELEMETRY PLATFORM DESIGNED FOR A WORLD THAT…

7 min read·Mar 4, 2019

559

3




Chronicle


POWERING SECURITY OPERATIONS WITH CONTEXT-AWARE DETECTIONS, ALERT PRIORITIZATION
AND RISK SCORING…


BY MIKE HOM, PRODUCT ARCHITECT, GOOGLE CHRONICLE & TRAVIS LANHAM, ENGINEERING
LEAD, GOOGLE CHRONICLE

4 min read·Mar 15, 2022

111




See all from Chronicle
See all from Chronicle Blog



RECOMMENDED FROM MEDIUM

Karolina Kozmana


COMMON SIDE EFFECTS OF NOT DRINKING


BY REJECTING ALCOHOL, YOU REJECT SOMETHING VERY HUMAN, AN EXTRA LIMB THAT WE
HAVE COLLECTIVELY GROWN TO DEAL WITH REALITY AND WITH EACH…

10 min read·Jan 21, 2024

35K

942




Unbecoming


10 SECONDS THAT ENDED MY 20 YEAR MARRIAGE


IT’S AUGUST IN NORTHERN VIRGINIA, HOT AND HUMID. I STILL HAVEN’T SHOWERED FROM
MY MORNING TRAIL RUN. I’M WEARING MY STAY-AT-HOME MOM…


·4 min read·Feb 16, 2022

78K

1104





LISTS


TECH & TOOLS

16 stories·244 saves


MEDIUM'S HUGE LIST OF PUBLICATIONS ACCEPTING SUBMISSIONS

312 stories·2789 saves


STAFF PICKS

652 stories·1006 saves


NATURAL LANGUAGE PROCESSING

1479 stories·991 saves


Kevin Beaumont

in

DoublePulsar


HOW THE NEW MICROSOFT RECALL FEATURE FUNDAMENTALLY UNDERMINES WINDOWS SECURITY


MICROSOFT SHIP A FEATURE TAKING CONSTANT SCREENSHOTS OF PCS BY DESIGN.

4 min read·May 21, 2024

301

7




Kallol Mazumdar

in

ILLUMINATION


I WENT ON THE DARK WEB AND INSTANTLY REGRETTED IT


ACCESSING THE FORBIDDEN PARTS OF THE WORLD WIDE WEB, ONLY TO REALIZE THE
DEPRAVITY OF HUMANITY

8 min read·Mar 13, 2024

19.6K

359




The CHADIE Foundation


I WEAPONIZED SEX IN MY MARRIAGE AND THIS IS HOW IT WORKED AND THEN ENDED


MY HUSBAND AND I WERE DEEPLY IN LOVE. WE TRULY ENJOYED SPENDING TIME TOGETHER
TALKING, JOKING, LAUGHING, DREAMING, AND MAKING LOVE. OUR…

6 min read·Dec 11, 2023

1.97K

103




Admiral Cloudberg


CRUELTY OF CHANCE: THE CERRITOS MID-AIR COLLISION AND THE CRASH OF AEROMÉXICO
FLIGHT 498


THE STORY OF A DISASTER THAT SCARRED A LOS ANGELES SUBURB AND CHANGES AMERICAN
AIRSPACE FOREVER.

33 min read·Aug 26, 2023

1.7K

16



See more recommendations

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams

To make Medium work, we log user data. By using Medium, you agree to our Privacy
Policy, including cookie policy.