35C3 - SiliVaccine: North Korea's Weapon of Mass Detection

35C3 preroll music

Herald: So our next speaker is Mark
Lechtik and he is going to talk about

SiliVaccine, North Korea's weapon of mass
detection. Mark is the malware research

team leader at checkpoint and he deals
with reverse engineering and malware

analysis both as occupation and as a
hobby. So a huge round of applause to Mark

applause and we are starting the talk.

Mark Lechtik: Let's begin with a short video

Video

Laughter
Ladies and gentleman, for those of you who

don't know this lady in pink, her name is
리춘히, a good friend of mine, North Korea's

main news presenter. And she just turned
75 years old this July. Let's give her a

warm round of applause for her passionate
introduction to SiliVaccine. Of course I'm

lying, she's not my friend, nor did she
even speak about SiliVaccine in this

video. But still, kudos to her for
grabbing your attention. And again, hello,

thank you for joining me for this talk
titled "SiliVaccine - North Korea's weapon

of mass detection". Before I actually tell
you about the research story here, I would

like to introduce you to the two notorious
dissidents who are behind this infamous

research. You see them right here on the
screen. One of them actually happens to be

me. My name is Mark Lechtik. As previously
mentioned, I'm the Maleware-research team

leader at checkpoint and my partner in
crime for this research is named Michael

Kajiloti. Unfortunately, he couldn't be
here today because he's in a vacation in

Hawaii probably drinking some smoothie
from a coconut. So I thought this would be

a better picture. To Michael, have a lot
of fun in your travel. Come home safely

and beware of Koreans who stare at you
suspiciously. Now, we both work at

checkpoint as mentioned and without
further ado let me give you a little bit

of a background for this research. So this
whole research actually began at one point

this year around March when I was looking
for something to read in Twitter and then

I stumbled upon this article you see right
here titled "Inside North Korea's Hacker

Army" by Bloomberg and it's actually a
pretty interesting piece, I recommend you

to read it. It discusses particular a
North Korean defector who was drafted to

work for a government agency in North
Korea and ended up raising money for the

regime through hacking. And an interesting
thing I noted throughout this publication

is that the author tried to portray some
kind of a narrative of North Korean state

sponsored cyber operations and in
particular in one paragraph he gives a

representation of what seems to be the
North Korean government's official comment

to various hacking allegations made
against North Korea by the West. And

here's a quote: "So formally, North Korea
denies engaging in hacking and describes

accusations to that effect as 'enemy
propaganda'. It says its overseas computer

efforts are directed at promoting its
antivirus software in the global market.

The country has for more than a decade
been working on such programs including

one called SiliVaccine. Now looking at
this, you're probably asking yourselves:

What the hell is SiliVaccine? Well, as you
may understand by now, SiliVaccine is an

antivirus that is developed and used
exclusively in North Korea. So this is

basically a North Korean antivirus. Or how
I like to call it: The Kim Jong Un-tivirus.

laughter Now obviously this is
a very rare product. You can't find it on

the Internet, you cannot download it
anywhere. It basically resides only inside

the DPRK. As far as we could tell in this
research it's actively developed since

2003 and the version that I'm going to
focus on here today is version 4.0, which

was released in 2013. Just as a caveat: We
are also in possession of another version

from 2005, which was one of the early
versions of SiliVaccine and I will mention

it a little bit later throughout this
talk. Now if you know anything about North

Korea, then one thing you should note is
that there is actually no internet inside

North Korea, right. Instead, what they
have is what's called an Intranet, which

is this highly restricted but glorified
local area network; and, having that in

mind, you must be thinking "Why the hell
would North Korea use an antivirus in the

first place?". Well, there are a few
interesting explanations for that: One,

the more exotic one, is to actually
protect against threats that might reside

within media that is smuggled to the
country. And for this matter as an

example, it turns out that there is
actually a phenomenon of USB sticks with

Western media that somehow magically find
their way inside North Korea. And then

they get sold in the country's black
market to citizens. And I know it sounds

totally fucked up, but remember, it's
North Korea and to convince you a little

bit better, you're invited to go to this
website called "flash drives for freedom",

which is actually a crowd-source funding
project for USB sticks that get written

with content from the West and smuggled
into North Korea. So just a fun fact, if

you have any kind of problems with your
local IRS, don't worry. The smuggled USB

stick is 100 percent tax refundable. As
for the content inside of it, well, it

contains just all kinds of information,
entertainment content from the West like

Wikipedia articles and South Korean soap
operas, which somehow managed to threaten

the North Korean regime. But anyways,
there's also another explanation for the

existence of this antivirus, and this is
the fact that is actually stated by North

Korea itself, is to raise money for the
regime by selling this product in the

worldwide market. As a matter of fact to
corroborate this, we can refer to the 2005

version of SiliVaccine that I mentioned
previously, which you can see here on the

screen, was written both in Korean and
English, which might hint at the fact that

whoever wrote this version tried to make
it more appealing for English-speaking

users as well as Korean ones. Now you also
must be asking yourselves: "How the hell

did we get our hands on the software in
the first place?" Well, the answer to this

lies in the Bloomberg article I mentioned
earlier. It linked to a blogpost by this

guy named Martin Williams. Martin Williams
is a journalist who covers various kinds

of news items related to North Korea. And
he actually got this particular software

through, I would say, a slightly
suspicious email from a guy calling

himself Kang Yong Hak, a security engineer
from Japan, who wanted to give it to him

as a journalistic lead. And remember this
email, we will talk about it a little bit

later. Now of course Martin was kind
enough to share the software with us and

it's the place to thank him for making
this whole research possible. Now what did

we want to find out in this research? So
first of all, we wanted to understand the

technical structure of the software. How
is it built? Through which we hope to get

somewhat of an anthropological view on
some of the practices employed by the

North Korean engineers meaning how
engineers with restricted resources tackle

a big project like building an antivirus
from scratch. Also we wanted to see if we

can find any kind of abnormal behavior
inside this antivirus. Some things that

could have been left in place and expose
some hidden agenda of the developers and

in particular we try to locate any
potential backdoor that could have been

deliberately put in place as a means of
surveillance against the citizens. So with

that in mind let's take a short overview
of the antivirus architecture and for this

matter let's start with the software
libraries that comprise it, the first of

which is called SV shell. This is just a
basic shell extension that introduces this

entry in the context menu which you can
see if you click the right mouse button.

And this is basically meant to just do a
manual scan on a file using SiliVaccine.

And you know what - let's just test this
feature and see if it works. So here we

have malware, we right-click, we press on
this feature and nothing happens which is

really just some kind of a bug that we see
right from the very beginning of testing

this antivirus spoiler. There are more,
but never mind. Let's move on. The next

component we see here is one called
SVKernel.dll. Now this is in fact the file

scanning the engine of this antivirus. And
this is really the core component that

contains the logic that implements virus
scanner files. This .dll exposes roughly

20 export functions with the names
SVfunc001 through SVfunc020 - very

ambiguous naming convention - and they are
of course used in conjunction with

patterns or signatures which is the
content that allows the software to decide

if a given file is malicious or not. Then
we have another group of components which

is pretty self-explanatory. These are the
GUI components the first of which is this

tray menu you can see on the right corner
of the screen. And this little menu allows

you to execute any other GUI menus in this
antivirus. For instance you can see the

following menu where you can do a full
scan on the file system. You can play

around with some of the configurations of
this antivirus. It's also possible to do

some whitelisting and blacklisting
actions. And basically this is a GUI one-

stop shop for all of this antivirus'
features and other... oh, before talking

about the other components, SVmain
actually communicates with a driver called

SVHook.sys. This is a driver that is meant
to convey some information as the main

from the Kernel space. We will discuss
this driver a little bit later. Then we

have the update mechanism of the antivirus
which will basically download any kind of

update binaries and components or update
signatures and we'll verify them with an

external component called SVDiffUpd.exe.
And of course, as I mentioned, everything

here resides inside North Korea's
Intranet. So this update client will

communicate with a server inside North
Korea and it will do so using a custom

update protocol which works on top of the
HTTP protocol. And here you can see some

of the messages exchanged between this
update client and server. And one thing I

would like you to notice is the vast
amount of information conveyed through

this update protocol. You can see fields
like a serial number, some kind of an

interface ID and IP which is for the most
part kind of suspicious. I mean, why the

hell do they need all of this information
just for an update mechanism? But since we

don't have any access to the server or any
kind of way to understand how the user

communicates with it we can't really tell
why this information is collected so we'll

just leave this fact as is. Another
interesting thing is that the whole HTTP

protocol was manually implemented by the
developers and along the way they did some

interesting mistakes for instance the
content length field of the HTTP header is

written with an underscore here which is
kind of a mistake. It's not the way it is

intended to be used. Also the authors
wanted to convey the update client's

identity to the server and they did so
with the user agent which is a pretty

typical way of doing this but instead of
only using the user agent they added

another field called "User-Dealer". I have
no idea what kind of dealer they had in

mind laughter but obviously this has
nothing to do with the HTTP protocol. And

speaking of dealers there is yet another
component here called SVDealer.exe which

is actually the real-time scanning
component of this antivirus which you can

enable through the tray menu as well. And
this particular component will use another

driver called SVFilter.sys which is a file
system filter driver meant to intercept

all kinds of access to the file system and
issue the underlying file to a scan prior

to actually doing any kind of action on
it. And, again, we'll discuss this

particular driver later on. At this point
I should mention that the two components

here that actually do any kind of scanning
tests are SVDealer and SVMain that you see

here on the screen. Obviously they would
have to use the file scanning engine for

this purpose and also a bunch of
signatures which are represented through a

series of files called the pattern files.
Another thing here that we have as a

driver that I'm not going to talk about at
all. This is a driver called ststdi2.sys.

This is basically a TDI network filter
driver. If you don't have any idea what I

just said, this is perfectly fine because
this driver does absolutely nothing

laughter. It just resides inside this
antivirus and collects all kinds of

information about TCP connections and it
should be queried theoretically by other

components. But no one ever queries it so
it seems like it's just some kind of a

residue from previous versions of
SiliVaccine. So we'll just leave it be, I

guess. And another interesting point here
is that a lot of these components you see

here were protected with a legitimate
protector, a commercial protector called

Themeda which - if you heard of it, you
probably know - it's a pain in the ass to

reverse engineer. Luckily for us, whoever
used this protector did not enable a lot

of its features and we could unpack it
with moderate efforts. This is the full

architecture of this antivirus. I'm not
going to go any further in it. You can

read about it in our publication, full
publication about this software. Actually

I want to focus in all of this complicated
scheme on one particular component which I

already discussed. This is SVKernel.dll. I
remind you: this is the file scanning

engine of the antivirus. This is really
the heart and soul of this whole software

and this is why we're going to talk about
it next. And I would like to begin this

discussion about this component with what
every good reverse engineer looks at. And

these are strings, of course. And the
first thing we did was to open this file

and look at its strings and, like every
professional reverse engineer, we looked

them up on Google laughter and here is,
ladies and gentlemen, where it actually

gets interesting because it turns out that
if we look it up Google we come to another

file called vsapi32.dll. Now what is
vsapi32.dll? As it turns out, this is yet

another file scanning engine. Actually
it's a file scanning engine belonging to a

big corporate in the security field and
that is Trend Micro laughter which we

thought was kind of surprising. And
looking at this, we thought: does it mean

that this .dll is in some way incorporated
inside SiliVaccine? Did they use any kind

of interesting way of incorporating its
functionality inside their engine? Well,

let's find out laughter. So here on the
screen you can see what's called the

binary diff. This is a binary comparison
between those two engines. On the left

side you can see the Trend Micro engine
and on the right side you can see the

SiliVaccine engine and actually you can
notice a few things here. For one, there's

a 100 percent match between more than a
thousand functions of those two engines. A

thousand functions is like a quarter of
SiliVaccine's engine code. And then you

can see also that there's a 100 percent
match on some of the export functions. In

fact, if you look at all of the first 18
export functions in SiliVaccine, you

realize they somehow map to functions of
Trend Micro. And as an example, just take

three of these functions and look at their
call for graphs in IDA and we can see that

they're pretty similar for the most part,
but I would say it's more interesting to

note the small nuances or the small
differences between those particular

functions. And as an example let's take
this pair of functions, VSinit and

SVfunc005. Well, one interesting thing we
noticed at the very beginning is that

while Trend Micro's engine uses mostly
Lipsey functions like "memset", for

instance, the equivalent in SiliVaccine
would at some points in-line those

functions, it would use function inlining
to convey the same function and that

essentially hints at the fact that the
developer of SiliVaccine could have

recompiled this particular Trend Micro
code with some kind of a compiler

optimization that was not applied on the
original engine. You can see another

example for this right here, with the
"memcpy" and "qmemcpy", its in-line

equivalent. And let's look at another pair
for this matter. So we have VSgetVSCinfo

and SVfunc004. Once again, function
inlining. But another artifact that was

left here are these numbers you see right
here. So it turns out that this particular

field that is populated in this structure
you see here is actually the engine

version of this antivirus and it turns out
that the engine version used inside

SiliVaccine is a 8.910 which is an engine
released by Trend Micro back in 2008. Now

recall that this software is from 2013. So
basically whoever wrote this was using a

five year old engine inside his code. And
finally, let's look at another pair:

VSquit and SVfunc006. Once again, you can
see a call to a proprietary SiliVaccine

function inside what used to be a Trend
Micro function. This is just some kind of

a clean up function for a driver called
"svio" which has nothing to do with Trend

Micro. And this again strengthens this
kind of speculation that, when compiling a

SiliVaccine, there was some kind of use of
a proprietary resource that belongs to

Trend Micro. Well, I would like to mention
at this point that this was not the only

instance of a Trend Micro engine we found
in SiliVaccine. In the 2005 version which

I mentioned earlier we actually found a
trace of another component by Trend Micro

which is called tmfilter.sys. This is
actually a kernel mode equivalent of this

engine called vsapi32. And this really
shows that this whole sort of copyright

infringement was not a one-time thing. It
has been possibly going on for quite a few

years. Now, we reached out to Trend Micro
to get the response and basically, just to

sum this up, Trend Micro says that, yes,
SiliVaccine used a 10+ year old version of

their engine in their code. They
said,like, "WTF? We did not do any

business with North Korea" laughter.
Also they're saying, "We have no idea how

they got our engine." But they do hint at
the fact that they worked with some

vendors as OEM back at that time and maybe
it's possible that one of these OEMs

leaked their code or what not. So who
knows. So other than, you know, looking at

this; other than saying that this is a
very kind of secretive antivirus that's

developed inside North Korea, we couldn't
help but notice that there are quite a lot

of mechanisms used by the authors to
conceal the fact that they're using a

third party product. And again, I remind
you: we just realized that SiliVaccine is

essentially using a Trend Micro engine and
we thought - if they're using the same

engine this doesn't mean that they're
actually using the same signatures as

well. So if we compare this on the surface
then it seems that no because SiliVaccine

has multiple patterned files while Trend
Micro has one single large file. And also

there seems to be no kind of similarity
between them on the binary level, but if

we look a little bit deeper then we can
find the place in the code where those

particular pattern files are being loaded.
This happens in SVKernel.dll in a

particular function called SVfunc19. And
what happens there is that the name of the

particular pattern file of one of the
parent files is being calculated or

generated, then a handle to this file is
obtained, the contents of the file are

being read, then this particular file is
being decrypted, the decrypted chunk is

appended to some buffer in memory, the ID
of this chunk is incremented and this

whole process repeats. So essentially what
this function does is to load the part of

files one by one, decrypt them and append
them all together. Now before I talk a

little more about the encryption here,
let's talk a little bit about the

encryption key because there's something
interesting here. So this is the

encryption key used there. A seemingly
random English string. We thought: "does

it mean anything in Korean?". It doesn't
mean anything in any language, actually,

but an interesting thing happens when we
take this particular string to a Korean-

English keyboard and we try to type it
while accidentally forgetting to switch to

English. So we get this Korean string. And
if we translate this Korean string to

English, turns out that it literally means
"pattern encryption" laughter and

applause. Thank you. laughter* OK, so we
decided to look a bit deeper now regarding

the encryption itself. We saw a lot of
encryption mechanics inside. Some have

some cryptographic artifacts that resemble
the Shahwan algorithm, for instance, and

all kinds of other stuff. We basically
didn't really bother understanding this

whole mechanism very deeply because we
were interested in the decrypted pattern

files which we could simply dump from
memory and that's what we did. And after

dumping this from memory and comparing the
two signature files one to another we can

actually see a similarity in the header
and if we scroll a little bit down we can

also see that there is quite much of a
similarity in strings. Actually there is

more than 90 percent match on the strings
in those two files. And the difference is

probably due to the version of those
pattern files. Now that's not the end. We

decided to test this thing. So we scanned
a bunch of files with SiliVaccine. They

were all detected. We scanned them also
with Trend Micro. They were also detected.

But there is something interesting here.
Although they're using the same signatures

and same strings the detection names are
totally different. And that is, ladies and

gentlemen, suspicious. So it turns out
there's a reason for this and the reason

is that SiliVaccine actually renames the
signature names before displaying them to

the user. And here is how this works. So
basically SiliVaccine will take a Trend

Micro signature name, for this purpose
"TROJ_STEAL-1". It would then replace it,

strip it of the underscores and dashes and
then replace the prefix with some kind of

word based on a string based on a
predefined dictionary. It will also

replace the suffix from a number to a
letter. It will modify the casing, append

everything together with dots and this is
how you get a SiliVaccine signature

laughter. So looking at all of this it's
interesting to note that the authors are

probably trying to hide something. So just
to summarize all of these hiding

mechanisms, let's just briefly take a look
at what we've already seen. So basically

all of the files or most of the files in
this software are protected with Themida,

a commercial protector, which means that
the binary files do not have any kind of

string artifacts that allow a researcher
to understand what he's looking at. Also

the pattern files are encrypted so we
don't have any string artifacts there. You

can't understand from those signature
files what you're looking at. And finally,

the malware signatures are renamed in real
time, so it means that even in real time

you cannot tell what was the original
signature or where it came from. So

essentially the user and a researcher
won't have any way of knowing that this

product is using the engine of Trend
Micro, which is puzzling. So, moving on -

let's talk about more of the fishy things
that go inside of this product. Namely,

while analyzing it, we've seen a lot of
the following instances of this string,

"Mal.Nucrp.F", and we realized that, based
on its format, it's probably some kind of

a signature name. So we decided to
understand what it was. We ran our

algorithm in reverse and we get the
following detection name - "Mal_NUCRP-5".

But what's the deal with the signature,
why does it even stand out from the other

ones? Well, here are two instances where
this particular signature name is used. So

here you can see actually that what
happens with this signature is that a file

is being scanned to detect if it's
malicious or not. Then, if it was found to

be malicious, its detection name is
compared against the string and if that's

the case, then SiliVaccine will simply
ignore this file laughter, which is

suspicious laughter. Now, of course, we
wanted to test this thing so we ran 6

files that were supposed to be detected
with this particular detection name. In

Trend Micro they were all detected. Then
we decided to run them in SiliVaccine and

nothing was detected laughter. And
actually, this is quite surprising because

we did a little bit of QA on this and it
turns out that for the most part it's

okay. But then in one instance they made a
typo and in the white list it's something

called "Mal.Nurcrp.F" laughter which has
no equivalent in Trend Micro's engine,

which begs the question: WTF is "nucrp"?.
And according to Trend Micro's

Encyclopedia, which is a thing apparently,
"MAL_NUCRP-5" is described as some kind of

a signature related to some old malware
named "NUWAR", "TUBS", "ZHELAT". We

checked all of them. They have no relation
whatsoever to North Korea. But deeper

inspection of this signature name reveals
that actually this "mal" prefix you see

right here means that this is a generic
detection that flags files based on some

heuristic which, in essence, might detect
a whole spectrum of files. So

unfortunately, based only on this
information, we cannot know what malware

was exactly detected here or really if it
was malware at all. But we can still

speculate on why this whitelist thing was
done. And for one, the most obvious

speculation would be that there is some
kind of an existing North Korean tool

installed on citizens' computers and the
authors didn't want to trigger an alert

about it being malicious. It's also
possible that the authors wanted some

option to develop such a tool in the
future and they inserted this signature in

order to conceal this future component
with this particular whitelisting

mechanism. It's also possible that since
the authors used a third party engine, the

Trend Micro engine, that this signature
mistakenly detected one of SiliVaccine's

original components as malware, which they
clearly wanted to avoid. And of course

it's also possible that this whole thing
is some kind of an idiotic false positive

management fix. But I would say this is
unlikely. All right - let's move on and

talk about the kernel side of SiliVaccine.
And remember: SiliVaccine has three kernel

mode drivers, but actually only two of
them are utilized, SVfilter and

SVHook.sys. So let's focus on them. And we
started snooping around and looking at

these drivers. And the first thing we
noticed is some fishy stuff like the fact

that its entry point resides in the relog
section and that it's supposedly packed

with some kind of a packer called
"BopCrypt" which we never heard of. And we

looked around "BopCrypt"; turned out this
is an old Russian PE packer that

supposedly contains some common protection
features such as anti-debug measures and

polymorphic code. Now this is not really
good news when dealing with the kernel

driver because who wants to debug
polymorphic code into kernel. So we

thought: wait a second, before we dive in
and do all of this stuff maybe we can

actually find some kind of an answer by
looking at this file again from the

outside. And turns out that our answer was
right there and our answer is 42

laughter. Actually it's hex42. So
evidently, this whole crazy protection

scheme here is that the text section that
contains the actual driver is sort with a

single byte of the value 42 hex. So with
this insane protection mechanism which we

were able to bypass we were able to look
at the drivers themselves and the first

one of them, SVfilter.sys - I remind you
that this is a file system filter driver -

this is loaded and utilized by SVDealer.
This is the real time scanning component

and it has two main functionalities. One
is to actually scan files upon access so

it would intercept any kind of activity
with the file system and it would take the

underlying file and would issue it to
SVDealer to conduct a scan on it and also

it's actually used to protect the
antivirus as binaries themselves to avoid

any kind of malfunction against them by
the user. And it really took us quite some

time to realize that these are the only
two things that this driver does because

the code for them is really a mess. And
I'm going to save you some time and

explain the flaw of this driver by
simplifying it a little bit. So this is

how SVfilter.sys works in a nutshell. The
first action it does is waste time

laughter. So it does a lot of redundant
checks that seem to have no effect on this

code whatsoever. Then it moves on to see
if the file scanned here is actually

binary related to the antivirus itself. Of
course if it is done it will deny access

to it. Then it moves to the very important
action of wasting a lot more time

laughter by doing what seems to be
pretty much garbage code. And finally at

some point it will take the file, it will
scan it and if the file seems to be

malicious then it will deny the access to
it. Otherwise it will allow the access. So

this is pretty much everything to say
about SVfilter. There was another driver

called SVHook.sys which is utilized by the
main GUI component, SVMain.exe. You look

at this name, you think, yes, it probably
hooks stuff. No - it doesn't actually hook

anything. It's actually used to query some
kind of process object data from the

kernel and really it's quite of a
confusing driver because it seems to have

like 13 ioctls. Only 3 are ever used and
it's highly, highly buggy. There's a lot

of bugs there. So for instance, we've seen
the following function where there's an

ioctl issued to this driver and it really
seems that those two components, SVMain

and SVHook, were really developed by two
different developers. So here we can see

that this programmer who wrote this
particular ioctl call actually used a

buffer of size 12. Now you would assume
that those two developers have agreed that

this should be the buffer size, right?
Well, evidently the second developer was

not really notified about this and in fact
checks explicitly that the buffer size is

12 and if that's the case nothing happens
laughter. Which really is a piece of

shit code that does nothing laughter. So
while looking into this, we tried to dig a

little bit deeper and understand why those
bugs happen and we think we have an

answer. So just strolling around we see a
lot of this. If you look at this you

realize that you're looking at a lot of
debug prints used by the author and you

see that one of the parts of the strings
referenced here is "sub_00something" which

is an IDA-auto-generated name. Which to
me, ladies and gentlemen, seems like

instead of looking at authentic code, we
were in fact reverse engineering a

reverse.engineered driver. So essentially
what happened here is that the developer

of SVHook took some driver, decompile it,
copied the code and added a bunch of debug

prints in order to try to understand what
he was copying and it seems he didn't only

fail to understand it but he also forgot
to remove this trail of debug prints. That

demonstrates his elite coding skills. So
we are nearly at the end and we talked

quite a bit about the technical parts here
but to get the full picture I think it's a

good idea to look at the development story
behind the software. So in essence, who is

behind SiliVaccine? Well, to tackle this
question we resorted to some version info

that can be found inside the antivirus as
binaries. And there we found some version

manifest that pointed at several
companies, the first one of which is

called PGI (Pyongyang Guangdong
Information Technology). It seems to be

some kind of a North Korean establishment,
a known one, that specializes in network

security software. But really the more
interesting company that we found there

was called "STS Tech-Service" which is
really this kind of shady company that has

no trace of its activity online. We
couldn't find any kind of artifact that

shows what this company does or what is
its main field of occupation. So we still

can answer some questions about STS tech
service. For instance we can say that STS

tech service is highly likely based in the
DPRK North Korea and that is due to this

brochure you see here on the screen which
is taken from a trade fair that took place

in Pyongyang back in 2006. And in this
particular trade fair this company, STS

Tech-Service, they participated. We
contacted the organizers and they actually

confirmed that STS Tech- Service did come
from North Korean side. Still, some

questions remain. Is that a private
company in North Korea or is that even a

thing? Is that a government entity? Is
that the same thing in North Korea? We

don't know. Actually, another source told
us that this company might be a

subdivision of the KPA (where KPA stands
for Korean People's Army), but we have no

way of corroborating this. And you
remember that Trend Micro stated that

their engine could have been leaked from
third party. Could that third party be

this company? Well we don't know actually,
but what we did see and which was really

interesting is a particular connection
between North Korea and Japan that repeats

throughout this whole research so for one
we've already seen that SVKernel is

basically some kind of modified version of
Trend Micro's engine. But then we've also

seen that STS Tech-Service at some point
cooperated with a company called Silver

Star Japan on a particular application. As
a matter of fact it not only cooperated

with them but also with another company
called Magnolia which also resides in

Japan. Actually Silver Star and Magnolia
reside in the same address in Japan, which

is quite interesting. And then in a
particular instance all of these three

companies - Magnolia, Silver Star and STS
Tech-Service cooperated with the KCC, a

very famous North Korean research
establishment, the Korean Computer Center,

on another application. And it's important
to say that while we can be very easily

drawn to some conclusions here and
speculate on some very wild scenarios,

especially given the fact that North Korea
and Japan are not friends, we need to

remember that this is just a crazy web of
connections that we unraveled here. And

actually we cannot say much about this
other than pointing out the connections

themselves. Still I can say that we did
find some traces of maliciousness in this

whole package and at this point we
thought: all right, we are done with the

research; could it be that there is no
malware or backdoor here? Well, it turns

out that if we look back on this e-mail
sent by this supposedly Japanese engineer,

Kang yong hak and reinspect the installer
provided in this particular email, then

actually it has no metadata. And that's
not surprising because this installer is

in fact this file is in fact a self-
extracting archive which contains the real

installer of SiliVaccine. But then it also
contains another file called "SVpatch4.0"

which - well, OK. But when you look at the
metadata you see it's supposedly related

to Microsoft automatic updates which is,
again, highly suspicious laughter. Now,

we decided to look deeper in this file and
it turns out that actually this file is a

signed binary. And if you look the issue
up on Google we come to a Kaspersky report

about the Darkhotel APT. Very alarming.
And then we decided to dig deeper and

analyze this file. So we did some
analysis. We realized that this is

actually the stage one malware from a
known campaign called Jaku uncovered by

Forcepoint in 2016. Now what is Jaku? Jaku
was an ongoing botnet campaign, it

targeted mainly North Korea and Japan. And
while it infected a lot of victims the

later stages of the malware - stages 2 and
3 - were only used against a select group

of individuals with North Korea and
Pyongyang being the common theme between

them. Now another interesting connection
that was outlined by Forcepoint is between

Jaku and Darkhotel which is really further
evidence to this kind of an interesting

connection on top of what we saw with the
certificate used previously. Now who could

be the target here? It could be the case
that every SiliVaccine installation is

bundled with this malware, but we don't
think so. We actually think that the

target was Martin Williams who deals
vastly with North Korea. And it is

possible that this particular malware was
used against him. So this is pretty much

the end and I would like to, before I let
you go, summarize everything that we've

seen in this talk. Let's look back and see
those things. So for one we have seen that

SiliVaccine has been illegally using Trend
Micro's engine and it was not a one-time

thing. It has been done at least two times
and probably over multiple versions and

for several years. Then we've also seen
that the authors of SiliVaccine tried to

conceal the fact that they used this
engine with some interesting mechanism.

Then we've seen that there is an explicit
whitelisting of a particular signature and

that the installation of SiliVaccine comes
bundled with the malware called Jaku. Now,

while having these understandings we still
have some unanswered questions. For

instance, we've seen that there are some
artifacts that point at the fact that the

code of SiliVaccine might have been
recompiled with some other optimizations

that were not in Trend Micro' engine in
the first place. So, having said that, how

did the SiliVaccine authors obtain such an
access to a proprietary resource? We have

no idea. Also this white-listed signature
- we cannot say what it represents. It's a

heuristic signature so we cannot really
tell if it was trying to whitelist a

malicious tool or a benign software. It's
not very clear. And then also the Jaku

malware. Since we only have one instance
of this particular software from 2013 it's

hard to say if it's bundled with all
versions or only with this one. And while

I can't answer all of these questions
concisely I do want to point out that

throughout this research we've seen a lot
of effort done to develop this particular

product and through this effort we've
stumbled upon quite many illegal and shady

practices employed by the DPRK to develop
their own homebrew software. A software

that, remember, maybe sometime in another
time and in a perfect world could have

been totally legitimate. And with that in
mind I would like to thank you for your

attention and hope you enjoy your time at
CCC.

applause

Herald: Thank you, Mark, that was
wonderful. We have plenty of time for

questions and we have two microphones. One
is in the middle of the room and one is

sort of outside of the stage. So please
queue up if you want to ask questions. And

we already have a question on the
microphone 1.

Audience member 1: Do you have any idea
why they chose Trend Micro over any other

engine?
Mark: Excuse me, could you repeat the

question and raise your hand, because I
didn't see you?

Audience member 1: Do you have any idea
why they chose Trend Micro and not any

other engine, like an open source engine?
Mark: Do I have any idea of Trend Micro

tools is what? I'm sorry.
Audience member 1: Do you have any idea

why Trend Micro was chosen by them?
Mark: Ah, why Trend Micro.

Audience member 1: In comparison to
anything else?

Mark: Actually I have no idea. I really
don't.

Audience member 1: Thank you.
Mark: If you know, then tell me, please.

laughter
Herald: microphone 2.

Audience member 2: So have you looked at
the fact that this antipiracy is a .exe.

So it runs on Windows but all of North
Korea runs with Red Star OS which is a

Unix.
Mark: Well, as far as I could tell from

people I discussed with who do know a few
things about North Korea actually Red Star

OS is not the most common operating system
there. In fact it's barely used because,

well, to say it shortly, it's shit but
they do use what seems to be some kind of

Chinese versions of Windows XP and Windows
7. So this is intended to run on these

operating systems.
Herald: Thank you. Another question from

mic 1.
Audience member 3: How did you get the

2005 version of the antivirus?
Mark: Come to me later and I'll tell you.

laughter
Herald: Mic 1, please.

Audience member 4: Yeah I just wanted to
know if you checked that the Jaku malware

was not part of this whitelist program.
Mark: Oh yes, we checked it. Actually this

was not the white-listed signature. It was
actually not detected by SiliVaccine, but

it was also not detectable by Trend
Micro. It was not detected by anyone

actually so it was not the white-listed
signature.

Herald: Thank you. That's all. Thank you,
Mark. Thank you for the amazing talk.

applause

35C3 postroll music

subtitles created by c3subtitles.de
in the year 2019. Join, and help us!