So, our next speaker is Mark Lechtig, and he's going to talk about Sili vaccine, 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 an occupation and as a hobby. So, a huge round of applause to Mark, and we're starting to talk. Let's begin with a short video. If you don't know this lady in pink, her name is Lee Chun-hee, 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 Sili vaccine. Of course I'm lying, she's not my friend, nor did she even speak about Sili vaccine in this video, but still, kudos to her for grabbing your attention. And again, hello, thank you for joining me for this talk titled Sili vaccine, 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 Leftig. As previously mentioned, I'm the malware research team leader at Checkpoint, and my partner in crime for this research is named Michael Kajilotti. 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 a particular 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 CeliVaxi.  Well, as you may understand by now, CeliVaxi 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 t-virus. 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 CeliVaxi, 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's actually no Internet inside North Korea, right? Instead, what they have is what's called an intranet, which is this highly restricted, 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's actually a phenomenon of USB sticks with western media that somehow magically find their way inside 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% 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 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 Celi vaccine 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 this software in the first place. Well, the answer to this lies in the Bloomberg article I mentioned earlier, it linked to a blog post 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 Young-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 this 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 exposed some hidden agenda of the developers. And in particular, we tried to locate any potential backdoor that could have been deliberately put in place as 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 silly vaccine. And you know what? Let's just test this feature and see if it works. So here we have a 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 engine of this antivirus. And this is really the core component that contains the logic that implements a virus scan of files. This dll exposes roughly 20 export functions with the names svfunc001 through svfunc020, a 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 white listing and black listing actions. And basically, this is a GUI one-stop shop for all of these antivirus features. 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 to SVmain 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 it will verify them with an external component called svdfupd.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, an IP, which is for the most part kind of suspicious. I mean, why the hell do they need all 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 client's, 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, which I have no idea what kind of dealer they had in mind. But obviously this has nothing to do with the HTTP protocol. And speaking of dealers, there's 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 ststdi.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. 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 Celi vaccine. So we'll just leave it be, I guess.  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 in Google. And here's, ladies and gentlemen, where it actually gets interesting. Because it turns out that if we look it in 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. 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 Sealy vaccine? Did they use any kind of interesting way of incorporating its functionality inside their engine? Well, let's find out. So here on the screen, you can see what's called a 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 Sealy vaccine engine. And actually, you can notice a few things here. For one, there's a 100% match between more than a thousand functions of those two engines. A thousand functions like a quarter of Sealy vaccine's engine code. And then you can see also that there's a 100% match on some of the export functions. In fact, if you look at all of the first 18 export functions in Sealy vaccine, you realize they somehow map to functions of trend micro. And as an example, let's just take three of these functions and look at their call flow 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, VS init and SVfunk005. And one interesting thing we noted at the very beginning is that while trend micro's engine uses mostly libc functions like command set, for instance, the equivalent in Sealy vaccine would at some points inline those functions. It would use function inlining to convey the same function. And that essentially hints at the fact that the developer of Sealy vaccine could have recompiled this particular trend micro code as kind of a compiler optimization that was not applied on the original engine. You can see another example for this right here with the mem copy and q mem copy. It's inline equivalent. And let's look at another pair for this matter. So we have VS get VSC info and SVfunk004. 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 here is actually the engine version of this antivirus. And it turns out that the engine version used inside Sealy vaccine is 8.910 which is an engine used by or 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 VS quit and SVfunk006. Once again, you can see a call to a proprietary Sealy vaccine function inside what used to be a trend micro function. This is just some kind of a cleanup 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 Sealy vaccine, there was some kind of a 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 Sealy vaccine. So in the 2005 version, which I mentioned earlier, we actually found a trace of another component by trend micro, which is called tmfilter.cis. This is actually a kernel mode equivalent of this engine called VS API 32. 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, Sealy vaccine used 10 plus year old version of their engine in their code. They said like, what the fuck, we did not do any business with North Korea. 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 whatnot. 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 Sealy vaccine is essentially using a trend micro engine. And we thought if they're using the same engine, 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 Sealy vaccine has multiple pattern 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 is this happens in SV Kernel DLL in a particular function called SV fun 19. And what happens there is that the name of the particular pattern file of one of the pattern 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 at this whole process repeats. So essentially what this function does is to load the pattern 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, it turns out that it literally means pattern encryption. Thank you. So, okay, so we decided to look a little bit deeper. Now, regarding the encryption itself, we saw a lot of encryption mechanics inside. Some have some cryptographic artifacts that resemble the Xiaowan 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's quite much of a similarity in strings. Actually, there's more than 90% a match amongst 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.  They were all detected. We scanned them also with trend micro. They were also detected, but there's 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 silly vaccine actually renames the signature names before displaying them to the user. And here is how this works. So, basically, silly vaccine will take a trend micro signature name for this purpose, Torch underscore steel dash one. It would then replace, it would then strip it off 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 letter, from a number to a letter. It will modify the casing, append everything together with dots. And this is how you get a silly vaccine signature. 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 a media commercial protector, which means that the binary files does 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 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 a little 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.nucryp.f. And we realized that based on its format, it's probably some kind of signature name. So, we decided to understand what it was. We ran our algorithm in reverse, and we get this following detection name, mal.nucryp-5. But what's the deal with this 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, then its detection name is compared against this string. And if that's the case, then CeliVaccine will simply ignore this file, which is suspicious. Now, of course, we wanted to test this thing, so we ran six 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 CeliVaccine, and nothing was detected. 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 they whitelisted something called malnucryp.f, which has no equivalent in Trend Micro's engine.  And according to Trend Micro's encyclopedia, which is a thing, apparently, mal.nucryp-5 is described as some kind of a signature related to some old malware named Newar, Zillat, which hacked all of them. They have no relation whatsoever to North Korea. But a 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 on 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 whitelisting 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 microengine, that this signature mistakenly detected one of CDVaccine'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 CDVaccine. And remember, CDVaccine 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 noted is some fishy stuff, like the fact that its entry point resides in the Relock section. And that it's supposedly packed with some kind of a packer called Bobcrypt, which we never heard of. And we looked around Bobcrypt, 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 in the kernel? So we thought, wait a second, before we dive in and do all of these stuff, maybe we can actually find some kind of an answer by looking at this file again from the outside. And it turns out that our answer was right there, and our answer is 42. Actually, it's hex 42. 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, sv-filter.sys, I remind you, this is a file system filter driver. This is loaded and utilized by sv-dealer, 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 sv-dealer to conduct a scan on it. And also, it's actually used to protect the antivirus 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.  So this is how sv-filter.sys works in a nutshell. The first action it does is waste time. 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 scan here is actually binary related to the antivirus itself. Of course, if it is, then it will deny access to it. Then it moves to the very important action of wasting a lot more time. 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 sv-filter. There was another driver called sv-hook.sys, which is utilized by the main GUI component, sv-main.exe.  It's actually used to query some kind of process object data from the kernel. And really, it's quite a confusing driver because it seems to have like 13 iOctals, only three are ever used, and it's highly, highly buggy. There's a lot of bugs there. For instance, we've seen the following function where there's an iOctal issued to this driver. And it really seems that those two components, sv-main and sv-hook, were really developed by two different developers. So here we can see that this programmer who wrote this particular iOctal 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.  So while looking at this, we try 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 underscore eight zero zero something, 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 engineer driver. So essentially what happened here is that the developer of SVHook took some driver, decompiled 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 the vaccine? Well, to tackle this question, we resorted to some version info that can be found inside the antivirus binaries, and there we found some version manifest that pointed at several companies, the first one of which is called PGI, Pyongyang Guangmyeong Information Technology. It seems to be some kind of a North Korean establishment, an own 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 in North Korea, and that is due to this brochure you see here on the screen which is taken from 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 the North Korean side. Still some questions remain, is that a private company in North Korea? 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 Korea People's Army, but we have no way of corroborating this. And you remember, Trend Micro stated that their engine could have been leaked from a 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 SV Kernel is basically some kind of modified version of Trend Micro's engine. But then we also seen that STS Tech Service at some point cooperated with a company called Silverstar 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, Silverstar 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, Silverstar and STS Tech Service, cooperated with the KCC, a very famous North Korean research establishment, the Korea 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, alright, 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 email sent by this supposedly Japanese engineer, Kang Yong-hak, and we inspect the installer provided in this particular email, then actually it has no metadata. And that's not surprising because this installer is in fact, or this file is in fact a self-extructing archive, which contains the real installer of the vaccine. But then it also contains another file called SVPatch4.0, which, well, okay. But when you look at the metadata, you see it's supposedly related to Microsoft automatic updates, which is again, highly suspicious.  If you look the issuer up in Google, we come to a Kaspersky report about the Dark Hotel 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 Jakku, uncovered by Forcepoint in 2016. Now, what is Jakku? Jakku is, it was an ongoing botnet campaign. I targeted mainly North Korea and Japan. And while it infected a lot of victims, the later stages of the malware, stages two and three, 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 Jakku and Dark Hotel, 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 celi-vaccine installation is bundled with this malware, but we really 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. I would like to, before I let you go, I would like to summarize everything that we've seen in this talk. And let's look back and see those things. So, for one, we have seen that celi-vaccine 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 for several years. Then we've also seen that the authors of celi-vaccine tried to conceal the fact that they used this engine with some interesting mechanism. Then we've seen that there's an explicit white listing of a particular signature and that the installation of celi-vaccine comes bundled with the malware called Jakku. Now, well, 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 celi-vaccine might have been recompiled with some other optimizations that were not in Trend Micro's engine in the first place. So, having said that, how did the celi-vaccine authors obtain such an access to a proprietary resource? We have no idea. Also, this whitelisted 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 this Jakku 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, 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. 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 to the left side of the stage. So please queue up if you want to ask questions. And we already have a question on the microphone one. Do you have any idea why they choose Trent Micro over any other engine? Excuse me, could you repeat the question and raise your hand because I don't see you. Do you have any idea why they choose Trent Micro and not any other engine like an open source engine, for example? Do I have any idea of Trent Micro's tools as what? I'm sorry? Do you have any idea why Trent Micro was chosen by them in comparison to anything else? Actually, I have no idea. Thank you. If you know, then tell me, please. Microphone 2. So have you looked at the fact that this antiviruses and XC, so it runs on Windows, but all of North Korea runs Red Star S, which is the Unix? Well, as far as I could tell from people I discussed with who do know a few things about North Korea, actually Red Star S is not the most common operating system there.  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. Thank you. Another question from Mike Wan. How did you get the 2005 version of the antivirus? Come to me later and I'll tell you. Mike Wan, please. Yeah, I just wanted to know if you checked that the bundle JQ malware was not part of this whitelist program. Oh, yes, we checked it. Actually, this was not the whitelist signature. It was actually not detected by SiliVaxi, but it was also not detected by Trend Micro. It was not detected by anyone, actually, so it was not the whitelist signature. Thank you. That's all. Thank you, Mark. Thank you for the amazing talk.