*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!