Using RTF Data to Become the Phishing Guardian of Your Network Galaxy: Detect ‘19 Series

MICHAEL RAGGI: We're here today to present a presentation called Attribution is in the Object.

This is a very sexy word, attribution.

Analysts love it.

Reporters love it more.

But it can be really problematic.

So today we're dealing mainly with technical methods for attribution and not so much the specific attribution for the APT groups that we're going to be discussing.

So if you have a strong opinion about it, and you want to come up to us afterwards over a tea or over a drink, I would love to argue with about there, but not so much here while I've got the clicker in my hand.

So questions at the end.

I'm happy to discuss those groups as well.

So like I said, Attribution is in the Object is a technique and a suite of techniques that we're going to present that's going to help everybody become the guardian of your network galaxy.

My name is Michael Raggi.

I'm a senior threat research engineer at Proofpoint.

GHAREEB SAAD: I'm Ghareeb Saad.

I'm principal security researcher at Anomali.

MICHAEL RAGGI: The typographer and font designer, Hrant Papazian, said, "Nothing made by a human can avoid personal expression." As cyber threat researchers, we believe that to be especially true.

There's nothing really an adversary can do to hide their fingerprint that doesn't ultimately point back at them.

Whether it be something like shared strings, whether it be code overlap, or a PDB path, those fingerprints remain.

And it is the point of this presentation to identify the human fingerprints in the tools that our threat actors and adversaries create.

So attribution in the object using RTF object dimensions to track phishing weaponizers.

It's going to start by presenting what a weaponizer is, a document and phishing weaponizer.

We're going to cover why we need to track these weaponizers.

We're going to discuss the RTF file format, dig deep on it, and discuss RTF weaponizers in depth.

Hopefully, we'll provide you with four mechanisms for identifying and attributing RTF phishing files.

And then finally, we're going to present a case study on the APT Royal Road weaponizer that was utilized by both Chinese and Indian APTs over the course of two years.

So let's dive in.

What is a document weaponizer, a phishing weaponizer?

Well, a document weaponizer is a tool used by threat actors to create malicious phishing attachments from pre-existing lures that injects malicious code for the exploitation of vulnerabilities or zero days.

These are often simple scripts in the form of Python.

And they are distinct from the vulnerabilities or the zero days that they're exploiting.

The reason threat actors utilize these is for convenience.

They can acquire them in the dark web.

They have developers in-house that create these tools.

It allows them to scale their operations automating the injection of malicious code into a phishing document and customizing the social engineering lures across campaigns.

So let's visualize this.

Every phishing attack begins with a threat actor assembling a plausible social engineering scenario.

They create this lure document that supports a social engineering scenario in their host environment with a word processor, something like Microsoft Word.

Next, they run their weaponizer script, which injects malicious code for the exploitation of a vulnerability or a zero day into the lure document they just created.

They're left with a malicious document that can now be attached to a phishing email and delivered to their victim.

And to help visualize what these RTF weaponizers look like, their script-- these are Python scripts for RTF files you can see by the graphic there-- that injects the malicious code.

In this case, these are Equation Editor exploits that would inject the code into pre-existing phishing documents.

So now that we understand what a weaponizer is, why should we be tracking these weaponizers?

Well, 2019 Verizon DBIR came out, and they're still listing email attachments as a primary infection vector for malware.

Not surprising.

Many of these infection vectors, email attachments, are built by weaponizers.

When you start tracking a weaponizer in your environment, this allows you to have visibility you didn't have previously.

It gives you the ability to attribute attacks to known sophisticated and unsophisticated actors based on shared weaponizer usage.

The same principle applies for identifying new payloads delivered by known weaponizers.

It can allow you to track objectives and targeting across multiple campaigns based on sectors targeted.

And it can even allow you to identify the introduction of new exploits into the wild that are delivered by known phishing weaponizers.

GHAREEB SAAD: Perfect.

So why RTFs?

Why are we focusing today on attributing RTF files?

As Michael said, it's very important.

It's very useful to be able to track and attribute exploits, not only for security researchers but also for threat analysis.

It's very important for you to be able to group or understand attacks and exploits coming to your organization and try to attribute it to a certain actor or a previous incident or attack you have been seeing into your organization.

And since RTF is mainly one of the most common file formats used to deliver exploits-- actually, if we exclude macros, which is technically not exploits, I would consider RTFs are the most common file formats used in phishing attachments.

That's mainly because how RTFs are built is making it very flexible.

And it can host multiple or different object types that can enable attackers to deliver different types of exploits.

As a security researcher, on our daily threat research and APT tracking, we see a lot of RTF files.

And we always try to attribute it to actors to understand who is behind this attack.

Only during the last year, we have been tracking around 22 unique RTF weaponizers, which, as Michael said, is a tool used to generate RTF files.

We have seen multiple actors using them.

We have been seeing them using at least six different CVE numbers.

So our idea was to collect the techniques and tools and methodologies we are using to track RTF files-- malicious RTF files-- share it in our research paper, and we hope this presentation will be a good summary for these techniques.

So let's first start with quick introduction into RTF formats.

So RTF, rich text format, was developed by Microsoft in 1987 with a main goal to enable cross-platform document interchange.

And to achieve this goal, RTF specification was designed to be very flexible.

And that led to one thing, which is when you develop a very flexible specification, that led to very complex parsers.

The code that's able to parse the files needs to be very complex.

And that leads then to a lot of vulnerabilities into RTF formats.

The other characteristic of RTF files, it was designed to be able to embed different types of objects.

Like you can have images in RTF files.

You can have flash files.

You can have pictures.

You can have forms.

And you can even have other files, like you can open doc files from RTFs.

You can open executables from RTFs.

That's a very good functionality.

But that's another very good option for attackers who want to use RTF to deliver exploits.

You can use RTF to deliver a flash exploit.

You can use RTF to deliver an exploit for [INAUDIBLE] parsers.

So that's like, for example-- that's a list of some CVEs that have been widely used lately with APT actors, cyber criminals, in RTF.

If you are in threat research, you will know that these are very commonly used CVE numbers.

So in the next slides, we will try to focus more into characteristics and features of RTFs that we can use to track and attribute RTF files.

We will try to explain how you, as an analyst, when you see a file coming as an attachment for an exploit, what are the features you can look at and say.

OK, I have seen this in my previous attack, like last month.

That's connected to a Chinese actor we are tracking.

That will be our goal from this presentation.

So to make it easier, we have grouped these features and [INAUDIBLE] into four main groups that we can map into the malicious document creation process Michael has explained in the first slides, which is lure document creation, payload selection, and weaponization, or the usage of weaponizers.

These main four groups are RTF metadata, obfuscation artifacts, shellcode characteristics, and RTF object headers and dimensions.

MICHAEL RAGGI: So of those attribution mechanisms, let's talk about the simplest one first, metadata author tag attribution.

This is a simple method because metadata author tags exist within the strings of the properties of an RTF.

And they're plain to see just by looking at the strings of a file.

This RTF metadata is applied during the lure creation prior to the weaponizer script injecting a malicious exploit code into the prepared lure.

And that is a high value IOC because that metadata author value was taken from the actor's host environment and delivered to you as a victim, which allows you to track it long-term and make correlations across multiple campaigns.

A good example of this that I like to use is something I call the Schrodinger's backslash string.

This is a string that's associated with Chinese APT groups and was applied to many documents over several years.

And by pivoting just on that string, we were able to find a bunch of red samples that shared this single metadata author string used by the Chinese APT, Goblin Panda, APT10, and the Sun Orcal Reaver group.

GHAREEB SAAD: Perfect.

So Michael said RTF metadata.

And they map to the first stage of a malicious document creation, which is lure document creation.

The next stage is payload selection.

And then the most important thing of a payload selection is shellcode.

Shellcode is the assembly code executed after a vulnerability was successfully exploited.

That's the code that enables the attacker to achieve their main goal, like execute a next stage payload or to achieve persistence.

And it's very common when we look at exploits to see that actors have their own custom shellcodes.

They write their own custom shellcodes to achieve their own goals.

And these shellcodes usually have some unique features that we can use to track and attribute a shellcode or an exploit to a certain actor.

Although these feature are not unique or specific to RTF files, but one important thing is RTF files, as we said in the beginning, are text files.

They basically consist only of ASCII characters.

They have no backing.

There is no compression in RTF files.

It's not like Office files where they are binary files.

So it's much easier for an analyst to be able to pinpoint shellcode inside an RTF file.

It's out of the scope of the presentation to explain these techniques, but I will just go through them and just explain them in a quick way.

So one of the characteristics we usually use to tie a signature to attribute and track shellcodes is the shellcode bytes, the code itself.

It's unique, and you can write signature for it.

Another feature is ROP oriented gadgets, return-oriented programming.

Sometimes-- if you know what return-oriented programming is-- it's certain addresses the attacker used to pivot over data execution prevention.

Sometimes these addresses are very unique to the attacker who did all the shellcodes, and you can use them to track attribute and say this shellcode is coming from this actor I have been seeing before.

Another technique is called egg hunting, is when an attacker have a next stage payload inside the document file.

And they mark it with a certain magic number or string that sometimes is a very unique string you can use to track and attribute the shellcode.

Other characteristics that's more into behavior, and they are a lot easier to find, are dropped file names.

Shellcode drops a file to execute and usually sometimes these file names are unique, like if you are tracking Chinese actor, these will use something called A to T payloads.

And you can attribute this shellcode using these file names.

The other is payload execution.

How do they execute their payload?

Are they using [INAUDIBLE] to execute it?

Are they using CMD to execute the next stage?

Are they manually using it in memory using DLL files?

That's also another technique you can use to attribute a shellcode.

That's a very simple example of a Yara rule, very simple, very straightforward, that can attribute an exploit using shellcode.

We see here, we just specify the file format, which RTF.

And then we have a string, which specify a very unique bytes used to overflow a certain byte.

That was very successful to be able to track multiple exploits we were seeing from this actor.

Another example, as I said, that's a signature that's trying to detect a file name dropping using RTF files by a Chinese actor.

The signature is again very straightforward.

It specifies how the bytes look like for the next stage file name.

So shellcode, as we said, it might be a little bit [INAUDIBLE] difficult since you might need a reverse engineer to be able to spot the shellcode and extract these characteristics.

But it's very persistent.

And it's very rare to see actors changing shellcode.

We even see actors reusing their own shellcode when they are using a new exploit or even when they are using a new zero day.

Another technique, which is less sophisticated, much easier to use, are RTF obfuscation.

As we said, RTF was created with the goal to enable cross-platform document interchange.

And to achieve this goal, RTF was created to be very flexible.

This optional-- so another thing rather than only being very-- a lot of vulnerables in a parser, it led to an option where an actor can make use of this to create-- when they are targeting a certain RTF parser, they can make use of this by creating the RTF file in a certain format where it's still valid RTF file for the certain parser they are targeting, but it's very challenging for AV and analysis tools to be able to analyze and extract these files.

Usually, these obfuscation techniques, or obfuscation artifacts as we call them, are very unique to these actors.

It's very easy to find them.

There are clear strings inside the file.

You can spot them, and then you can use them in a signature to track the actor.

Yeah.

So next slide.

Yeah, so again that's a quick example of RTF obfuscation.

There's a lot of options for RTF obfuscation.

There's already a lot of good write-ups on the internet explaining how RTF obfuscation works.

We've just tried to point out how they look like and how we can use them to track a certain RTF file.

So the main idea is RTF objects inside an RTF file are divided in two parts.

RTF headers and RTF data, which is the flow of what's [INAUDIBLE] this object.

And usually, AVs and analysts are trying to extract this data to be able to scan it because, of course, that's where the malicious codes are.

So actors make use of the fact that RTFs are very flexible and can parse these data even if they have invalid tags inside them.

You can define an object inside the data and still RTF parsers will be able to parse it in the right way while this will be very challenging for AV or analysts.

They can use different data representation techniques, like we see with the backslash.

That's a different representation of the parse.

They can use this to obfuscate their code.

They can have invalid tags inside it, as I said.

So the idea is these unique strings that is highlighted sometimes are very unique.

And we can just take this and have it in a signature that's going to track the actors if they are even using it in a different exploiter in different attacks.

That's an example-- again, very straightforward example.

You just see these unique strings, you put it in a Yara signature, and then when you have an RTF file that match that means most probably that's the same actor that was using the same RTF you have seen before.

Again, as I said, RTF files are very sophisticated.

And that's a very good picture that shows how sophisticated the parser is.

That's a flow graph of the code-- of the Office codes that are used to parse RTF files.

You can see that's a very complex code.

It's [INAUDIBLE] like That's why we see a lot of vulnerabilities and a lot of obfuscation options in RTF files.

So and the last technique, or the last option, we use and the one we think are the most convenient and, again, the most easiest to use.

As we said, RTF files can embed multiple type of objects.

And some of these objects-- or actually most of these objects-- can have graphical representation.

If you have an image inside the RTF file, it has graphical representation.

If you have a SWF file, it has a graphical representation.

And as per RTF specification, these graphical representations, as we can see from this table, are defined in the object header using certain characteristics.

As you can see, the objh means the object height, objw means object width.

The main idea here is these object dimensions, when you are developing a malicious RTF file, are generated during the exploit development process.

When an exploit developer is writing an exploit, he gets to create this object with these random dimensions.

And then that's become hardcoded inside the weaponizer.

That's how it looks inside an RTF file.

It's just a string saying that that's an object with a dimension, width is 71 and height 811.

That's very unique dimensions.

And that's hardcoded inside the weaponizer.

So actors might change their shellcode.

They might update their obfuscation.

They might even use a new exploit.

But they rarely modify these object dimensions.

It's very easy for you when you see an RTF exploit coming to your network.

Open it with a text editor, Control F, and look for object dimensions, object header, and object face.

Keep track of this.

And when you see another exploit, if you find the same dimensions in the same file, that's mostly the same actor.

Very easy, very straightforward to use.

That's how it looks like inside a malicious file.

So that's two files that are exploiting the Equation Editor vulnerabilities.

You can see this box that represents an Equation Editor object so you can easy attribute it to using the dimensions.

So as we said, these are usually very persistent techniques.

So actors don't use this.

And if we can see like in the next slide, we have a very straightforward signature that just defines the format we are looking for, RTF, and then a string which defines the object dimensions we are tracking.

This signature we have been using for more than one year.

It was very successful, very persistent.

We have been getting all the exploits coming from these actors.

We didn't miss anyone.

Sometimes, even, we have seen files submitted to VirusTotal with very low AV detection, like this signature for the file that was submitted one year after tracking the actors.

Nearly zero detection, but still, you can see in the strings of the file the same object I mentioned is in there.

Very easy, very persistent.

And yeah.

MICHAEL RAGGI: OK.

So Ghareeb was kind enough to walk us through the different RTF attribution methods.

Let's quickly compare and contrast them to understand strengths and weaknesses because that was a lot of data all at once.

Starting with metadata, metadata is probably the easiest to track.

It's available in plain text in the strings.

It provides a high level of persona visibility.

But it's not very permanent.

These can change between different phishing documents, and they're not always unique.

If you have Windows user as an author, you're going to find that everywhere all over the landscape.

When they're very unique, it's good.

But otherwise, it can be challenging.

Alternatively, shellcode is the most permanent.

It can often be unique to actors, but it can be difficult to track.

It requires a little bit of a skill barrier for reverse engineering to be able to deobfuscate some of the code and make appropriate comparisons across campaigns.

Obfuscation, like metadata, is easy to track.

These obfuscation data gadgets are present in the strings data of RTF phishing files.

It provides supply chain visibility, meaning if you see, like Ghareeb said, those gadgets appearing across multiple campaigns, it's either a same actor or a same phishing weaponizer being used in the landscape.

These, even more so than the metadata, are impermanent.

You'll find these being changed a lot between campaigns so that actors can avoid Static AV.

Literally, they'll upload it to VirusTotal, change their gadgets, the obfuscation data, so that they're not firing your Yara signatures for it.

And then finally, what we believe to be the most efficient method that we presented was object dimensions.

This is more permanent than metadata or obfuscation gadgets.

It provides the same supply chain visibility even more so than obfuscation gadgets.

And it can often be unique to an actor as well as a group of actors, like Chinese APT, which we'll demonstrate.

It also changes very, very rarely.

So that, again, was a lot of words.

We took the time to visualize this.

We mapped these from the most fleeting to the most permanent, and then operator visibility to supply chain visibility.

Metadata is the most fleeting attribution method for RTF phishing files but provides the highest amount of persona visibility.

Encoding schema, or obfuscation gadgets, is less fleeting and provides a fair amount of supply chain visibility.

Object dimensions, where we believe the best money or effort for your analysts is, is more permanent and provides the highest level of supply chain visibility.

And shellcode, although being most permanent, provides the least amount of operator visibility that we're seeing here.

So we're going to shift gears.

At the beginning, we promised a use case.

We're kind of shifting gears now from technical to attribution and stories about, specifically, the Royal Road RTF weaponizer, which is an APT toolkit introduced in late 2017.

And it remained in use through the middle of 2019.

It was utilized by six APT groups altogether, including five Chinese groups and an Indian APT group for a very brief period of time.

It was eventually adopted by crimeware actors about a year and a half to two years into its run.

And it's identifiable by its unique object dimensions, object width, This is a value that you could write a really strong Yara signature based around.

So this particular Royal Road RTF weaponizer was exploiting three specific CVEs.

And these are all vulnerabilities for the Equation Editor exploit.

The Microsoft Word's Equation Editor, if you're not familiar with it, it's a tool for writing complex equations that in November 2017 had a slew of vulnerabilities disclosed around it.

It was a tool that was acquired by Microsoft.

They didn't actually write or maintain the code.

So when CVE-2017-11882 was disclosed, they attempted to patch it with an ad hoc patch for the binary rather than the source code.

It fixed the initial vulnerability, but it introduced a subsequent vulnerability, CVE-2018-0802.

Very quickly afterwards, CVE-2018-0798 was disclosed as well.

So this caused Microsoft to discontinue support for the Equation Editor.

However, it still remains exploited by the Royal Road builder, as well as a slew of other exploits in the phishing environment.

I'm sure many of you have seen it targeting your environments.

So let's talk briefly about the constancy of these object dimensions we keep mentioning.

The Royal Road RTF weaponizer, we found it in five distinct versions across a two-year period.

So we identify these by the different obfuscation gadgets they utilize.

You'll notice that there are slight differences in the obfuscation gadgets in each of these versions.

They target the three Equation Editor versions that we mentioned, so CVE-2017-11882 is one, two, and three.

CVE-2018-0802 is version four, and CVE-2018-0798 is version five.

However, despite varying their obfuscation techniques and the vulnerabilities that were targeted, the object dimensions all stayed the same.

So you write one signature, you get all of those phishing exploits over the course of two years.

GHAREEB SAAD: OK, so Royal Road and CVE-2018-0798.

That's a very good story that helps us to understand how sophisticated the actors are and how persistent they are into what they are doing.

So as Michael said, the Royal Road weaponizer started by using CVE-2017-11882.

And that was actually after one week of the patch being released.

So it only took them one week to analyze that CVE and try an exploit for it.

A couple of months after the patch was released, researchers have figured out that there is a new-- new vulnerabilities was found due to the patch and that for CVE-2018-0802 was released.

And also, again, it took them less than 10 days to write and exploit for this CVE.

And then for the next year, we have been seeing a lot of samples from Royal Road weaponizer being submitted to VirusTotal.

And we have been [INAUDIBLE] them.

And so suddenly we started seeing-- I think by early 2019, we started seeing new samples of the Royal Road weaponizer submitted to VirusTotal with very low detection and our attribution scripts were not able to tag it as CVE2017-11882 or the other one, 0802.

So we went into Static analysis while looking into the samples.

And we figured out that this exploit is using a new vulnerability.

And actually, we didn't find any public information about the vulnerability online.

And we had to reach out to Microsoft to ask them.

And they came back and said, OK, that's a known vulnerability for CVE-2018-0798, but we didn't see it exploited in the wild before.

And that's actually a different exploit.

So the point here was the actors were using the two old exploits.

But there was a problem for them.

The old ones, with versions of Equation Editor before the patch.

And after the patch, it doesn't work.

While for CVE-2018-0802, it only worked with versions of Equation Editor after the 2017 patch.

So for the actor, when they are exploiting a target, they have a one-third probability to be successful.

It's easier to target [INAUDIBLE]..

So the old CVE will not work or either he patched it, but he didn't have the final patch.

So it might work against him.

Or he have completely patched it, and it will not work.

So they had to figure out a way to improve their success rates.

So that's how they were looking for a vulnerability, which is a new one.

There was no public information about it.

There was no research or analysis about these vulnerabilities.

And they were able to write an exploit for it.

MAN: Who [INAUDIBLE],, that, Ghareeb?

MICHAEL RAGGI: Saad was the first person to find that being exploited in the wild.

OK, so moving on to actually present a timeline of the adoption of Royal Road versions.

We have the five versions that we mentioned previously, from November 2017 to May 2019.

Beginning in November 2017, five days after CVE-2017-11882 was disclosed, the group believed to be aligned with the Chinese state interests, as ATP 40 and Leviathan, began using Royal Road, version 1, which exploited CVE-2017-11882.

Following that, in January 2018, Goblin Panda, also believed to be aligned with the Chinese state interest, adopted this version Their primary area of operation is Vietnam.

Subsequently, we saw a new version enter into the landscape still exploiting 11882, but this time, with different obfuscation gadgets associated with it.

This is also believed to be a Chinese APT group.

It's called Temp.Trident-- depends who you ask-- but primarily they're identified by their usage of Icefog malware.

Anyone who's familiar with that knows that that title is not mutually exclusive to a single group.

That version 2 was quickly adopted by Goblin Panda, who jumped from version 1 to version 2.

Then something really interesting happened.

We saw, for a period of two days, two samples utilizing a Royal Road weaponizer, version 3.

This was extremely similar to the Royal Road weaponizer, version 2.

It had very similar obfuscation data.

The only thing that was different was literally the gadget that they were using in this payload.

So our question is, how did they get their hands on this?

It's possible it was an nth party collection situation, where they were sitting on a box, and they saw one of these exploits come in.

And they said, hey, that's pretty cool.

Let's start using that.

Or you can get a little more elaborate and say maybe they were utilizing the same supply chain for acquisition of these exploits through some sort of exploit broker in the underground.

After that point in time, we see a new version 4 hit the market.

This time, it's Cylance released research where the Reaver Sun Orcal APT group, also believed to be aligned with Chinese state interests targeting dissidents, utilized this version 4 first.

Goblin Panda jumped on board.

Temp.Trident also jumped on board and utilized this for quite a long time in a lot of different areas of operation.

Finally, we see Goblin Panda leading the pack.

This is the only time that they lead the pack.

I'm going to make a caveat.

This is based on publicly available samples.

So if I had to guess, they probably didn't lead the pack.

They probably just were the first public samples that we identified.

So we see version 5, which is utilizing the 0798 exploit, which Ghareeb discovered in the wild, being utilized to increase the efficacy of these campaigns.

Shortly after that, we see another Chinese APT group, or believed to be attributed to China.

This is a group called Temp.Hex, or TA428.

This is something I'll cover a little more in depth.

And finally, Temp.Trident jumps on board as well GHAREEB SAAD: OK, so the timeline that weaponizers used, Michael has been explaining, have shown us a very good example of what we call weaponizer lifecycle.

How the weaponizer is created, how it's used, who is using it first, and then where it goes.

So when we think about the Royal Road weaponizer, we have two scenarios for it.

So the first scenario is Chinese government, or Chinese actors, have exploit developing capabilities.

And they were able to research the vulnerability and exploit it.

And they handed the weaponizer, or the tool, to the most sophisticated group they have, or the one which maps into the most important objective they have into their operation, which in this case was Temp.Periscope.

Temp.Periscope used the tool for a couple of months until they found a new version of the exploit, which is version 2, Michael has said about.

And then what happens, the version 1 moves to the less sophisticated actors, which are the Chinese actors with less important objectives.

And then Temp.Periscope gets the new version, the new exploit, and they start using it.

And then, again, when they have version 3 of the exploit, what happens again?

So they sell.

And that's a very important point.

We have seen these exploits start being used by Indian actors.

So they sold the old exploit to another actor.

And then the cycle starts.

The more sophisticated get version 3, and the less sophisticated get version 2.

And then when we have a version 4, what happens?

They sell the exploit to commodity mongers.

That's very important because that's when we say-- one of the concerns we have in the community is for cyber weapons and cyber tools created by state-sponsored attacks when they end being used by cyber criminals, like the case with WannaCry or the case like Chinese actors.

We have seen this in multiple locations where Chinese actors develop and exploit.

Or a tool like PlugX, for example.

They use it for a while, and they sell it for commercial use while they are sophisticated and very hard tools to defend against.

So they sell it to persistent cyber criminals, and they get the new version.

And then, after they have another version, they sold the old one to more widespreading cybercrime.

That's a very important example that shows us the lifecycle of an exploit.

When there is a new exploit, very sophisticated, who starts using it, where it ends up.

And then we can use this to map the priority of a threat actor.

Is it more important than the other actors who have the higher priorities for the state-sponsored attacks?

MICHAEL RAGGI: So I'm going to provide some context on these groups.

It is based largely on open source reporting.

There is nothing in here that I know exclusively that I am telling you right now.

Maybe at the bar later, but not in the presentation.

So starting with the first person to adopt the Royal Road weaponizer, Leviathan, or Temp.Periscope.

FireEye refers to this as APT 40.

Temp.Periscope is also a FireEye name for this particular group.

Leviathan is Proofpoint.

They named it first.

It's active since at least 2013.

It utilizes a large suite of custom tools, from everything from recon to lateral network movements, and including hitting air gap devices with their tool, Airbrake.

They're the first to use the Royal Road weaponizer.

And their targets are mainly US Naval and defense Maritime issues that dovetail with the South China Sea issues around the Belt and Road Initiative.

Moving down the list, Goblin Panda, or Conimes, a group again active since 2013-2014.

They're prolific users of open source tools.

Their unique tool, the main backdoor that they phish with, is called QCRat.

It's kind of a gussied up version of NetWire, which is a publicly available rat.

They're early adopters of the tool, as we mentioned previously.

And their primary targeting is Vietnamese government and Vietnamese military.

Moving down the list, Temp.Trident.

This is a group that is subcategorized by CrowdStrike as Nomad Panda and Dagger Panda, based on their areas of operation in Central Asia and Mongolia, respectively.

They're active since at least 2013.

They're identifiable by distinctive metadata, one of the techniques we discussed in their phishing files, as well as their use of the Icefog payload, which has been written about extensively by Kaspersky, as well as other AV companies.

And their primary target is going to be the Belt and Road Initiative, which I'm going to speak a little bit more about.

Everywhere where the Belt and Road Initiative is, you're likely to find one of these Temp.Trident groups or subclusters.

They've been covered also pretty extensively by Ashley Shen at FireEye in her agent Icefog presentation that's available online.

One of the more niche players that we see adopting this tool, based on Cylance research, is the Sun Orcal and Reaver group, active from at least 2010 through 2013.

They're identifiable by their custom payloads, Sun Orcal and Reaver.

They have a pretty good dev team that they work with because their malware is pretty interesting to look at.

Primarily targets in Asian countries that have dissident populations which align with the Chinese five poisons.

So this is social movements believed to threaten the unity of Chinese government control.

That's going to include Tibetans.

It's going to include Uyghurs, followers of Falun Gong, believers in Chinese democracy.

And I can only think of four of the five right now.

So dissidents is what these guys are targeting mainly.

Then you've got some of the super niche players, kind of like out in their own space, like Jeff Goldblum in Planet Hulk, just doing their thing.

This is a group, Temp.Hex, TA428.

They've been active since at least 2009.

These guys are prolific users of Poison Ivy as recently as May.

They're phishing with Poison Ivy against government organizations.

They have a custom payload called Cotx, that's a Proofpoint name, and Fireshadow, which is a FireEye name.

And they exclusively use Royal Road, version 5.

And these guys, their area of operation for years and years is Mongolia.

If you want more details about it, Ghareeb included some of their payloads in one of the Anomali papers on the Royal Road builder.

And I released a paper called, "Operation LagTime IT," that covers pretty extensively some of the phishing stuff these guys are doing.

And then finally, we've got the outlier, Sidewinder.

This is a group that's believed to be associated with the Indian state interest.

It's possibly a contractor.

And they're known primarily to target Pakistani military and governments.

They only used that one version of Royal Road 3 for two days from what we can see in public reporting.

We're not sure how they got it.

But like we've said, they could have bought it.

It could have been a fourth party collection scenario.

Depending on who you ask, they'll feel stronger about it than some others.

What does all of this have in common?

This is China's Belt and Road Initiative map.

It is a plan for economic expansion of China's global influence based on expanding over land and over sea trade routes into Europe, as well as all of Asia.

The blue triangles are all of the areas of operation for the groups that we've discussed, only for the Royal Road builder.

The red is our Indian friends, Sidewinder.

So I want to mention that it is not insignificant that this is where these groups are operating.

We named the Royal Road builder, in part, because of its correlation with the Belt and Road Initiative.

GHAREEB SAAD: Perfect.

So what are the lessons we learned from the Royal Road weaponizer story?

So, as we said in the beginning, tracking weaponizers and being able to attribute it is very important.

And sometimes, it's very easy.

Like, as we said, sometimes it is just a very small string you can use in a signature to track them.

You can do it-- like, we will be releasing a complete research paper, which is technically explaining how to do this tracking for RTF files.

It's very easy.

As easy, as I said, as opening a file with a text editor and looking for certain strings.

We are going to show how it works.

And using these tracking techniques, we will be able to find a lot of threat [INAUDIBLE] findings.

We will be able to identify new payloads.

We were able to identify actor objectives, what-- whom they are targeting, what are they after?

We were able to find new exploits.

Sometimes, even these very simple techniques were more powerful than AV directions.

As we saw, like, some of the samples have one or zero AV detection while we were still able to track it with these simple strings we have been showing how to track.

We were able to figure out connection between state actors.

We were able to see that Chinese actors are all connected.

They all share the same supply chain.

And we were able to give a ranking for each actor.

Who are the most important?

Who have the most sophisticated techniques?

And we were able to figure out connections between Chinese actors and Indian actors.

They have the same supply chain.

Or they are exchanging tools, selling tools between different state-sponsored actors.

And then we have seen how state actors are very persistent and how they try hard to improve their tools to have more success rates.

I think that's it for today.

If you have any questions, we'll be happy to have it.

Thank you.

Have a good day and good evening.