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!