 Good morning again. For our first talk today, we have Warren Mercer and Paul Raskin-Ras from Cisco TALOS. Please a warm welcome for Paul and Warren, presenting DNS Pionage. As you probably saw on the agenda, the title was DNS Pionage because when the call for paper closed a few weeks months ago, we only have this research available and public at this time. So since the end of the call for paper, we've published more work about DNS hijacking and DNS threats more and more globally. So we changed a little bit the title and the content of the conference. So today it will be DNS on fire talk and we won't speak only about DNS Pionage as you can see on the agenda. But we will speak about another actor than we named Sea Turtle and we will present this both case because it's different actor but the approach, the philosophy is quite similar and they basically target DNS. So yeah, new title and more content basically. So first thing about us. So my name is Paul Raskin-Ras and I'm a security researcher at Cisco TALOS for three years now and I'm working for more than 10 years on the security community, offensive stuff and defensive stuff. Now I'm only doing defensive stuff and mainly working on malware analysis. So I'm a malware guy and that's what I love to do except if it's Delphi as you can see. Then it's bad. But he liked the reverse Delphi. So yeah. We only have one clicker clearly. So we have the teams. My name is Warren Mercer also a threat researcher with Paul at Cisco TALOS. As Paul says, we like finding malware and pulling apart. That's our thing. That's what we do. So today we're going to talk about a couple of different pieces of actors and a couple of different sort of pieces of malware we found along the way. So I'm like Paul's work husband. The guy actually said you guys are like wife because you're always together. I said funny that's in my slide now. I didn't have to have that before but I do know. Paul and I speak a lot at a lot of different conferences and hopefully you'll enjoy it. Hopefully it'll be fun. So yeah, we do have an agenda because sometimes we don't. Sometimes we do. Today we do. So we're going to do a really brief DNS introduction. I'm going to assume a lot of people in the world know what DNS is but if you don't, very quick one-on-one, it's like five minutes if even. Then we're going to talk about DNS spinach. Then we're going to talk about sea turtle. Really important to note here. These are two different actors. Campaign similarities are quite close. Some of the TTPs are quite close. But they're two distinctly different actors with two different attendances. Then we're going to go over some protections and mitigations around DNS and what you can and can't do. If we have time, I don't know, we'll see. If we do, no hard questions, just really easy ones. So DNS protocol, DNS hijackings, primarily what we're talking about today. So DNS protocol is a core fundamental part of the internet. It essentially allows me to go, hello Paul, did you see YouTube.com? And Paul's like, yeah, YouTube.com's cool. If I go, hi Paul, did you see 1.2.3.4? Paul probably won't be very happy with that and I'll probably forget it after a while. So this basically allows us to type in Google.com. First case is an initial DNS resolver, depending on your architecture and your infrastructure. There's different ways that this will and won't work. So for example, when I type that in, it's going to hit my local DNS resolver. If my DNS resolver does not know who that is, I'm going to go and speak to the TLD of that DNS. So .com for example. So I'm going to speak to the top level domain server that can tell me where this needs to go to. They may not know the answer and they will go to the name server. So the name server will be the last point of entry for that domain name. .com's name server will reply and will let us know how to get there. Again, very fundamental. I presume everybody in the room knows it, but just to cover things very quickly. DNS redirection, which you may or may not know about again. Simply put, it's the idea of me asking for one thing but being sent somewhere else. So if you see around Montreal, it's detours everywhere. It seems every time we come here, it's detours, but there's lots of detours this time. So if you think of DNS redirection, very similar to that, I want to send you somewhere else. Not necessarily where you want to go, but where I want you to go in terms of an actor control platform. Seeing a custody that comes with it, so how can an actor do that? They have a couple of different ways. Distinctly speaking, the easiest way is if I can compromise an endpoint or compromise credentials. I say the easiest, it depends how you go about it. And if I've got your DNS administrator credentials, I can go in and change whatever I want. Equally, if I've compromised your endpoint, I can edit your host's file and send you wherever I want anyway. So I can do it a couple of different ways. I can hack your DNS actual resolver in your own infrastructure. I can hack the DNS servers. So some of this stuff we're obviously going to be talking about today. Or I can hack network infrastructure somewhere else to try and re-root you somewhere else. Essentially, what I'm trying to do here is take you from A to B, but I want you to go via my C. So you'll get the B eventually, but only when I want you to get there. So these are just some of the points in time that you can do it. Obviously, you get different protections that we're going to talk about later on through this. So redirection attacks have been going on for quite some time. These aren't new. Some of the techniques that we're going to talk about might seem new, but they've been about for a while. So the earliest one is the Iranian cyber army, and they did a redirection attack on Twitter, right down to some more lesser-known ones, like where they redirected blockchain so they could steal Bitcoin and other cryptocurrency credentials and information. So these are, I think, nine or 10 examples that we have. Just again, if you Google DNS redirection attacks, there's quite a few of them. So how do we start, Paul? Yeah, Paul's a hard worker, I'm not. So it's basically each time we present something or we publish something, I always have the question is how did you start? How did you find it? How did you start to work on it, et cetera? So in this case, everything starts with the first event, a DNS pionage, and everything starts by a malware, because as I said before, I'm a malware guy. I'm a reverser. I analyze malicious documents and stuff like that. So everything starts by that and by an actor using spearfishing email and more specifically, he used LinkedIn account to target specific people on company and asking for jobs, are you happy with your job and this kind of stuff and send a malicious document, not only by email, but via LinkedIn. And the point is on your company, maybe you blacklist LinkedIn, but if you don't blacklist LinkedIn, it's in SSL, it's encrypted and you cannot really look at the LinkedIn traffic and you cannot really analyze from network point of view the file hosted on LinkedIn that your users can download. So it's pretty clever from a detection point of view. So the attackers create two fake websites named hr.weepro.hr.sencor and weepro and sencor are two real company and if you go on these two websites, you will be automatically redirected on the real one. So if you don't really make attention, you can think it's a real website. It's two HR related company. So here is screenshot of the LinkedIn message from the attackers to the victim saying you should download this document and fill it if you want to have a new job. And obviously this document is a malicious document. The screenshot is from an open-minded company and it's how everything starts for the attackers. So you've got this malicious document and here is the document. So it's a real one. If you go on sencor website and if you look at I'm looking for a new job, you finish on this document and you need to fill it. So they take this document, the real one, and add malicious macro inside of this document. So the purpose of the macro was to download or was to drop a malware, execute the malware on the targeted machine. So the malware is pretty basic from technical point of view but here something very interesting is he used HTTP to communicate to the attackers which is something really standard and he used DNS tunneling to communicate to the attackers. So it's not something new. We already saw that but it's not really common. It's not something really standard and a lot of company do analysis of HTTP. They use proxy and check where you connect, etc. But less company checks the DNS. They simply let the DNS do his job because it's safe, you know. And the malware are two feature, downloading stuff, uploading stuff, and executing stuff, of course. And he has two files, the configure.txt file which contains the configuration of the malware and the attackers did a fail. Every programmer has a debug version of their stuff. And by mistake I think they deploy the debug version on several targets with the log.txt. And in the log.txt you've got all executed command and all outputs which is really cool if you do incident response, if you have to create... Yeah, yeah. But yeah, luckily we found this debug version first and after we discovered that it's not as designed, it was a mistake from the attacker. Anyway, the HTTP communication, even if it's HTTP, you need to use DNS because DNS is how you resolve IP and how you know where is the server. And he basically makes a random DNS request simply to register the compromised machine and say to the attackers, hey, I'm here. And the attackers give you his IP. It's the purpose of DNS. And after that, on our case, the malware included its own configure.txt file but the attackers support the fact that we don't have any embedded configuration file and I would like my configuration file. So he's able to communicate like that by using DNS to say, okay, I'm this target ID, I'm FY in this example and I've got the error code 800 in hexadecimal which means I don't have any config file and the attackers would give you your config file with maybe a new server, maybe a new key for data encoding, etc. And finally, once everything is fine, once you have your configuration file, etc. you've got your IP, you've got the domain, the URL and the malware connect on this website. The website is a fake Wikipedia page. If you go on it, you will see the Wikipedia layout. And it's where the magic happens. If you look at the source code of Wikipedia, the fake Wikipedia, of course, you can see some comments here. And in fact, it's based 64 command, directly in comments on the source code. The malware can use a custom base 64 dictionary. In this case, I put you without a custom one so you can really easily recognize the encoding if you are used to play with this encoding. Once decoded, here is exactly the content of these comments. So basically, it's three different comments. The first one, he wants to get the username of the target. The second one, he wants to have the last name of the target and the third one, he wants to know on which domain is binding the machine. Domain from an Active Directory point of view, not from a DNS point of view. And it's clearly a reconnaissance phase. He's trying to be sure the target is valuable and it's not a researcher like me or Warren. The purpose is really to... I know I compromise the company ABC. I get the domain, I get username and I try to make a double check if it's really the company ABC. And don't forget, probably the attackers were on this same company a few months or years before and he perfectly knows the hostname pattern of the company. He knows it's eight characters and the first one hour later, the last one is a number. He perfectly knows the username pattern because every company has exactly the same pattern and he probably already knows your domain. So if he compromised you in the past, you can be sure at 100% it's a real machine or it's not a real machine. If you use Sandbox, probably your Sandbox doesn't follow your pattern for account, your pattern for hostname and it's almost sure it's not connected and binding to your Active Directory. So here, yeah. With the debug version, it's a screenshot of the log.txt file. So I receive command, I execute command and I send the output to the attackers. So very useful if you have the debug version. The only missing part is the timestamp. They should have the timestamp. So it was the HTTP mode. It's very common. It's nothing really complicated and really new and they have a DNS communication channel for the C2 server. How does it work? In fact, you do some DNS requests. The first one is to register the node exactly as previously. I'm the ID GT in this example and I would like to register to you and the attackers know, okay, I compromised this machine. GT is this target and yeah. How your machine can receive order from DNS? So it's pretty easy. The infected machine sends this DNS request here and it receives an IP but it's not a real IP. It's a real IP but it's not the purpose of the request. If you know as key value as everybody, 100 is D, 105 is I, yeah. 114 is R and 0 is 0. So basically the IP, if you convert it as a string, you have DR. The purpose is to execute the DR command. So of course, sometimes your command has more than four characters. So how works the malware? He's performing the request and until you have a zero somewhere. If you have a zero, it means, ah, okay, it's the end of the strings. I've got my full command. So okay, you can receive command. You can execute DR in this case. How you exfiltrate data because the attackers want to see the output of DR. Same thing. Each request is part of the output. In this case, in orange, you've got volume in drive C, blah, blah, blah. And he performed a lot, but like crazy a lot of requests to send to the attackers the output of the command. So if you have a monitoring of your DNS, if you see a machine performing a lot of requests with really random weird pattern at the beginning, yeah, it's probably exfiltration. For example, I work on case previously where it was a malware exfiltrating credit card number and how it works. He said credit card number dot maliciousdomain.com. And the attackers simply look at the log and see I've got this credit card number, this request, which is this credit card number, this request, which is this credit card number, et cetera. So DNS exfiltration, it's really noisy from the DNS point of view, but it works perfectly and you know nobody monitored DNS. So we did some search about the victimology who performed this request, et cetera. For that, we use Cisco umbrella or historically open DNS. And we saw that mainly the activity was from Middle East, specifically two countries in Middle East. And yeah, that's basically how we work for the malware. But yeah, I'm here to speak about DNS hijacking. So yeah, your story is nice. It's a beautiful malware. You use DNS, but what's the point for you? And in fact, here is free IP used by different sample of DNS Pionage Malware. And I was looking at this IP and one specific IP. I checked this story, what domain was registered on this IP, at what time, et cetera, doing classical threat intelligence work. And I discovered one of this IP had more or less the same week free domain from three different countries and dot gov dot the country. So basically it's impossible that an IP be used by free government on three different countries. And it was for mail server. So it's really not normal. And we started to work on this case, saying yeah, is there something weird, this IP seems to be used for DNS free direction or something like that. And we cross this information with the transparency certificate CRT. I don't remember. In fact, when you register, when you create a certificate, SSL certificate, it's a Pion database and you can create this database to know every certificate created in the world at a specific time. Basically look up the serial number of any created SSL certificate and be able to see what happened to it or where it was used and what IPs are related to. Yeah. And we discovered that at one hour, one hour after this governmental DNS point to this IP, we discovered that a Let's Encrypt certificate was generated by someone on this governmental domain. So that means the attackers have a control of the DNS, have a server, one of this IP, find a way to redirect mail server.gov.whatever to this IP. And at this time, as he has the control of the domain, he's able to use a certbot, for example. There was a talk about certbot just yesterday, I think, and he used that to generate a Let's Encrypt certificate. And Let's Encrypt is trusted by your browser, by everything. So that's done. You cannot, you can, but most of the time, you cannot see something change. You are on new IP, new certificate, and game over. So the attacker is able to make money in the middle on your domain. It's basically a camera about how it works. Compromise DNS administrator, redirect the domain to its own IP, generate Let's Encrypt certificate, and he's able to do money in the middle on this domain. Here is some statistic from the end of the year. So it was really, really active during September, October, November. And it concerns exactly our IP here. It's one of the DNS Pynaj IP. So if you look carefully, you have the feeling that the Let's Encrypt certificate is generating before the DNS redirection. But it's not possible first. And in fact, it's due to the... Our passive DNS is not in real time. It depends on the replication, and we don't have the DNS image of the world in real time. We lost one hour. That's why we have one hour, the certificate one hour before. But it's simply due to propagation. It was really created after the redirection. So in this case, we have six domains from six different countries. Public sector, private company, redirected in three months. And the purpose was to target VPN gateway and mail server. So you can guess what kind of information the attacker is looking for, was looking for. If you create a bigger timeline, we were able to identify this sector doing the same thing at least from the beginning of 2017. But he did it really, really not often. And with the time, he did it more and more often. And he tried to reuse IP, and he failed, and we discovered him at this time. So some statistics about DNS Pionage Actor. We identified more than 25 redirections on two years. At least two years, maybe more, but we didn't see that. A peak of activity at the end of last year. And more than 10 countries. I think it's only Middle East countries except one country in Europe and US. So it's mainly, mainly about Middle East. And it targets government, as I said, mail server VPN. And it targets some private company too. So it's not only public sector. But 90% is public sector. And then along came an oil rig leak, which is quite nice. So if you're not familiar with oil rig, APT34, Helix Kitten, maybe our next talk will be about how many names we need to give actors. But it keeps going that way for some reason. So yeah, along came an oil rig. Lake March April time, roughly. So what we started to see here was a clicker that doesn't work very well. March April time, this came out with several assumed tool sets, web shells, a tool called Webmask that we're going to talk about, victimology, screenshots of panels, things like that. So this was an alleged leak that had all of APT34, so alleged Iranian government. We didn't see anything specifically related to DNS from a source code point of view, but we did see some very interesting stuff, which is why we want to talk about it. So we've seen this, which was a panel. You may not be able to see that, so I'm going to point out. All these countries, except this one, are all in the Middle East. So they're all in Lebanon. So that ties in very, very specifically with the victimology that tied in with DNS Spanish. So very Middle East focused, interested in very specific entities within those regions, not just Joe, who lives in Lebanon, who's looking at Google. Very, very different methodologies to who they're trying to attack. So this is one of the panels that leaked from them. So we'll zoom in a bit. There was a directory called thiswaspanel. So initially, when you see that, I don't see anything odd about that. It's another panel name. Paul, however, is very weird and has a very, very photographic memory. And Paul's like, I've seen this before. And I went, what? I knew he hadn't. What are you talking about? And he's like, yeah, I have. Here it's here. And I'm like, right. So this is from Lastline. So Lastline did a blog after we dropped DNS Spanish information. They got access to basically a C2 server. And on that C2 server, they really accessed the Django instance. On that Django instance, they had a panel path. And the panel path is not identical, but it's almost similar. So that's very hard to make out, but says thiswaspanel, essentially. This one says the same thing. Thiswaspanel. So this is, in fact, it's a mistake on the red stuff. Yeah, the red is wrong, but I wasn't going to point that out, Paul, because you did that, but not me. So essentially, you've got a different string of characters along here. So thiswaspanel has a lowercase l, but in here it has an uppercase l, some things like that. So it's essentially thiswaspanel. So that made us think, well, that's very interesting, because if Eulerig have this same panel name, that's not a completely dedicated way of linking attacks to attacks, but it's very interesting when you start to look at some of the other overlays that come with it. So the panel path, yeah, there's the right one there. So lowercase l, uppercase l, lowercase e, uppercase e, et cetera. I mean, as it says here, you can't really draw a firm conclusion from that, but anyone else who does research in this industry will take snippets of information like that and build from it. Obviously, you don't get the whole picture straight away, so that we find very interesting. So then we started to look more into the Eulerig Lake itself, started to look at some of the total sets that came out with it. The interesting one that we want to talk about is Webmask. So Webmask is essentially a framework that lets you do man-in-the-middle redirection, which, funny enough, coincides exactly with what the NSPanage is for. So that's why we started to look at it. They even give you a nice solution guide to set it up. So this is some of the excerpts from the script, so you can get these all over the internet. Just Google Eulerig Lake and you'll find a zip. Be careful, obviously we don't recommend you do that, but be careful. So on it you get things like a solution to be able to set your environment up and even things like install them and install screen, everything that you need to do. You'll see basically other variables used within it, so there's a JavaScript file. This is mainly Python, so there's like three or four Python entities, a JavaScript entity, and a config file from memory. First thing you see here is basically the setup, so how to set your environment up to get ready to do what you want to do. They then have an iCAP platform, so iCAP is the Internet Content Authentication Protocol. Essentially it's a bit like WPAD, where you can have automatic proxy and transparent proxy use. It's to try and save load on proxy servers that you have. So Webmask actually thought about its resources on like some developers that we work with. Some developers don't care, like all the resources. These guys were a bit smarter and tried to be careful with your resources. Again, things in here are log files, potential files, cookie files, so all the information that you want to be able to inject into your man in the middle platform. And then they use the squid proxy to bypass it, and then as Paul mentioned earlier, they use certBuff for certificate creation. So that's quite interesting to us because when you look at the victimology related to the panel that we showed you, this panel is called Scarecrow. Very, very similar victimology, Middle East, Lebanon. When you look at the methodology that these guys are using within their Python infrastructure, it's that they want to build a DNS man in the middle platform, exactly what DNS Manage uses. We are not saying it's 100% linked to OREG, APT34, Helix Kitten. It's absolutely technical possible, but what if we told you maybe it's not? That's the difficulty with attribution, obviously. We're basically saying that technically, if you took this information in these files, you would be able to do exactly what DNS Manage did, but we're not able to tell you fundamentally speaking it is actually related to OREG. The commonalities are there, the similarities are there. People can draw their own conclusions. So then along came event number two, which was C-Turtle. So C-Turtle was a massive attack on the core infrastructure of the entire internet. By that we mean like root servers were compromised. We've seen core DNS mechanisms compromised. It's a very interesting, very interesting actor. We're not going to go into a lot of technical detail about this because some of what we haven't published, but I'm going to give you a really good overview of what happened and how it happened. People are maybe wondering why it's called C-Turtle. So one of the guys that we were working with at the time, a guy called Danny. Danny was actually watching National Geographic at the time, and there was a shoe on about C-Turtles. So he was like, oh, we need a project name. By the way, C-Turtles. It was an internal name that wasn't really meant to go anywhere. And then when we started writing about it and we published it, we'd left C-Turtle everywhere. And we were like, ah, fuck it. C-Turtles there. So we went with C-Turtle, and we do have an awesome graphic department. So the graphic department were like, normally there's like a rat in here or there's like some sort of weird thing, but like this is just a turtle. We're like, yeah, it's just a turtle. She's like, okay. And she made this. So yeah, our graphics department is awesome, because Paul and I suck. So we're going to really go into technical sort of methodology of this, the malware and stuff we haven't published or we haven't spoken about it. So we're going to talk about how it happened and what they're trying to do. The clear primary motive that came with C-Turtle was espionage. Again, this is very, very focused on a certain region that we'll talk about in a moment. These guys were not interested in credit card numbers. These guys were not interested in things like how many users have you got in your infrastructure. These guys are interested in how do you build these rockets? What are your planes made of? How do you build on your roads? This is proper high level espionage. Primary targets and victims that came with it Middle Eastern and North African government departments, intelligence agencies, oil and gas infrastructure and military. These guys are not messing about. They're not attacking, as I mentioned, during Lebanon. They're attacking ministries of defense. They're attacking military contractors. They're attacking oil and gas chemical companies. They're attacking actual government agency departments. They know very, very specifically who they want to attack. That, to us, means that this is very much a state-sponsored attack. We believe they're one of the first publicly confirmed cases of a DNS registry compromise. We're going to talk about registries, registrars and registrants in a moment, because it's all very confusing. This was with Packet Clearinghouse, a company in the US, who actually published some information to say that they've been compromised, and we believe it to be related to sea turtle. So this is what victimology... Excuse me, sorry, this is what their victimology looked like. Our primary targets were all in the Middle East, so Albania, Lebanon, Egypt, UAE, Syria, Iraq, etc. All very, very specifically located within the same geographical region. What these guys did is that they're a primary target list. So these are guys that they absolutely wanted to compromise. They wanted to get access to. They wanted to find out information about. What we've seen with sea turtle was not so much a sophisticated step, but a very interesting step. Obviously, if I'm trying to attack someone in the room, I might not start out with Paul, because Paul's very smart. Paul knows what he's doing. But I might start with Paul's child, because Paul's child probably isn't as smart as Paul. Might be smarter than me, but not as smart as Paul. So I'll maybe start with Paul's child as my secondary target to get to Paul. So what these guys did was essentially the same thing. They compromised two different infrastructures and organizations, one in Sweden called Netnode, who's a domain registry, and one in the United States called Packet Clearinghouse, who are a non-government organization who specifically help root server organizations, companies, et cetera. They help with the mechanisms that are associated with root server infrastructure. So that is our victimology mapping. Again, very similar to DNS binage as well, but very important to note these are two distinctly different actors. They're not the same actor. So yeah, we'll do registrar, registrar, and registrant, because it all gets a bit confusing. So we have three main elements when you have a DNS record. Why does sea turtle go for registries and registrars? Well, the difference basically is a registry and there's an organization that manages a TLD, so top level domain, right? So VerisignOwn.com. I probably should have checked the SeaOwn.ca since we're in Canada, but I didn't, so apologies. But VerisignManage.com TLD. The registrar is in an organization that is allowed to sell that infrastructure, that domain name. So for example, GoDaddy. So GoDaddy can sell .com domains. So you can go on and buy a domain off GoDaddy. The registrant is you, an individual. Obviously that's not all true nowadays because of GDPR within Europe, so the data doesn't always make sense. So why will we use some of this information and what we do? The registrant used to be a really interesting, stroke-easy way to map out C2 infrastructure to be able to see other common domains that were associated with registrant information. Some stuff that we used that for. Registrar and registry would have been good for things like where you can buy a domain from, did they compromise the domain, did they compromise the registry, et cetera. So SeaTurtle went after both of these guys. Methodology that they went through to gain very similar to DNS knowledge, gained initial access to an entity, so that could be the registrar or the registrar as we'll talk about, or it could be an actual individual organization. The attacker then moved through that environment to attain credentials, so lateral movement and then credential harvesting. They then actually traded data from those environments and organizations. The attacker then accessed the DNS registry, so Google.com, or sorry, not Google.com, GoDaddy.com, for example, and they were able then to change how we shared with those pieces of infrastructure and those domains. So how that looks is essentially break-in. So SeaTurtle used various publicly known exploits. We published a list of, I think, it. They're not exhaustive, and SeaTurtle has been very good at not using only publicly known information when they want to get somewhere. If they hit a wall, they have generally been able to break through it, which again suggests they're very sophisticated and very well funded organization that was carrying this out. So use of publicly known exploits, break-in. Go through the network infrastructure, then break into the registry panels by taking the information that we've got from here, change the registry records, and then put in your own malicious name server. Now, again, as Paul mentioned, if you monitor your infrastructure and you monitor DNS, this should be pretty easy to spot, because when you start seeing network traffic at a DNS level going to a random IP that you're not familiar with, you can pretty quickly realize this because all of a sudden your traffic starts going to a domain server or sorry, the infrastructure helps a lot here. Again, being able to monitor that also helps. So this got them into the first side of it, which is maybe a registry C panel, so a control panel to change the name server. SeaTurtle then moved on through to do multiple levels of DNS targeting around their own actor control servers. So what the actor did here was go in and falsify A records. So an A record is a record that you get back when you type in Google.com, for example, tells you how to get to that location, that resource. SeaTurtle then provided a man in the middle instance, which again could be linked with Webmask. This man in the middle instance was used as a server to steal credentials and credential harvest, again exactly what they wanted to do. Once they'd stolen the credentials from the man in the middle server, so they'd logged him, they'd taken him in, they have them, victim was then passed on to legitimate service. The attacker is now able to authenticate in those platforms. So if you think about what that could be related to, if you think of your own organization, Webmail, VPN, any other mail services that you use internally, any JIRA, Confluence, GitHub, any SVN type infrastructure. So I've got your mail, got your source code, got your HR data, got your financial data. I mean, what more do I need? As a sophisticated actor and attacker like this, I'm going to go after really interesting stuff that maybe exists in your development department. So that could be code or information that relates to how your oil pump works, it could be how your missile fires, it could be how your defense systems operate. They're not attacking random everyday people, they're attacking very sophisticated and very high level targets. So what does that look like, again from a quick overview? Melissa's name server will be intercepting the traffic, that will be passed to the DNS server, the victim obviously has no idea what's going on at this time. As Paul mentioned similarly with DNS binars, they used X509, so certificates, sometimes ledson crypts, sometimes they'd stolen certificates from inside the infrastructure as well, and they would pass, go ahead. Yeah, I've got the sum, yes. So something really important is on several specific target, they don't generate a ledson crypt certificate, as I mentioned previously for DNS binars, but they directly stole the real certificate of the target. So in this specific context, even if you have SSL pinning for example and you check the certificate, it's valid and it's this one specifically, you cannot detect the man in the middle. Because before doing that, all the legitimate, the real certificate of the target. So you cannot base only the monitoring on the SSL pinning concerning this actor. And it's one of the big difference between the previous one and this one, is this approach and the TLD targeting approach. And so something to think about whenever I steal a public certificate, that's really easy. I can go to google.com and download their certificate and use it. However, for me to be able to get data out of that, I also need to have the private key associated with that. So we've been asked before, yeah, but anyone can steal a public key? Yes, but put two and two together. If I steal a public key and reuse it in my own service, how do you think I got access to that data? How do you think I see that infrastructure and how you see that network traffic? These guys were able to compromise and steal both sets of keys needed. So public and private key entities. So what do we see here? We see a highly sophisticated actor who's generally extremely motivated. They have no lack of concern when we call them out and disrupt their whole infrastructure and disrupt their whole action. Generally, whenever we publish something, it stops, so you don't see it anymore. And then maybe it comes back months later, but it's slightly different, slightly changed. These guys are like, yeah, we don't care, so just keep going. That to me proves that it's not just a guy in his bedroom. It proves it doesn't care. Yeah, absolutely. They don't care at all. As it says there, it's common for actors to sort of cool off. These guys didn't cool off at all. They are clearly aggressive in their play. They changed up the whole sort of game of who you attack and what you attack. Never before has there really been a massive attack on the core DNS infrastructure like this, i.e. attacking registrars and name servers and registers. We've seen things like BGP redirection where we attack core routers and core infrastructure like that, but never at the real base of DNS, which is required. So what do we see? Yeah, attacking TLD, CCTLD, GDTLDs. It's really, really important to note there. If these guys had been stupid, they could have brought down the whole internet. And I don't say that flippantly. I mean, when you compromise a name server and you own a name server, you can essentially bring down everything else and poison everything else and do whatever you want along everything else. These guys did know what they were doing. They were very specific and very alert in the sense that you've been brought down. They have a clear path to DNS manipulation attacks. That's what they wanted to do. Slightly different from DNS analysis, that these guys wanted to break in and get at those things like root servers to control much more interesting traffic. Abusing certificates. So we've seen abuse certificates. Sorry, I should have given abuse before. Something that happens, but seeing attackers break in and steal both sets of keys to be able to use those infrastructures over and over again is quite interesting. What we did there was steal legitimate infrastructure or sorry, steal legitimate traffic and steal legitimate certificates and then push out. So again, as Paul mentioned, it really brings in a really increased level of difficulty when you want to try and detect some of this stuff. Because if you do do things like certificate pin-in well, the certificate is right. There's nothing wrong with the certificate. It is exactly as it should be. It's just going to the wrong resource in the wrong location. So that's normally what happens as I mentioned. We disrupt them and they say bye-bye but unfortunately with Sea Turtle they just went, actually we're not amused anymore and we're going to keep doing this and so they did continue to do it. Protection is Paul. Yeah, so we saw how this to attackers works and let's speak a little bit about protection. So as always, we don't have a magic solution, sorry. If you expected a magic red proof solution. So something interesting is at the beginning of this year, it was in January, the DHS, so Homeland Security in the US published an emergency directive taking our publication from competitor and explaining how bad it is and give some way to detect stuff and protect infrastructure and I'm going to simply pass this different technique so we don't have more than more solution and more techniques for you. Sorry Paul, just to point out an emergency directive, if you're not familiar that means that companies must follow that information they must follow that directive so the information that the DHS released was related to how they should be monitoring DNS logs and infrastructure based on the DNS research that we published but it's not just that you guys should think about doing this it's Department of Homeland Security telling these organizations that they must do it so it's not just a please maybe think about doing this it's a you need to get this done in a certain period of time. So the first thing is as always monitoring, monitoring, monitoring so a lot of companies monitor DNS but they monitor the outside DNS they have a passive DNS to know at this time this machine on the internet has this IP but before we publish all these stuff they almost never monitor their own DNS the only monitor potentially bad DNS but in this case the bad DNS is your DNS so first things start to monitor your own DNS and same thing for certificate monitor your certificate as we say sit down and take certificate and use legitimate one but maybe it's not really your set model maybe you are not targeted by this specific group maybe you are more targeted by DNS pionage group with people that don't really are not so advanced and prefer simply to acquire a free let's and creep certificate and you can easily detect that especially if you don't use let's and creep at all in your company maybe if you start to have let's and creep certificate generated you should take some time and look at it and don't always your own DNS because obviously if your DNS is compromised and you monitor DNS through your DNS it's not really clever so use your DNS and use third party DNS too because there is less chance that you and your third party DNS are compromised another point is authentication if you look at DNS pionage guy what the attackers did is simply he stole credential of GoDaddy gone GoDaddy and click on the interface and change the IP of this specific domain so you can have I think I don't know for GoDaddy I hope so you can put two factor on the indication so if the attacker stole the credential is not enough to connect on the web page change the setting of your DNS and do the matter in the middle so yeah it's it's it doesn't really dedicated to this case it's more globally used two factor on indication patch of course it's not specifically for this case but you need to patch here I put the vulnerability used by Citadel to compromise targets so it's I don't know 6, 7 CV and it's you have patch and you need to apply this patch because if it's a front web remote code execution yeah you lose basically and revoke and reset so it's more if you are compromised of course you need to revoke all your certificate reset all your credentials and start to investigation on your infrastructure because on all the case if the DNS was redirected it was a second step before the attacker was inside of the infrastructure and after he does the redirection so if you identify a redirection you have two problems the redirection and he was here before the redirection so you have to do two works so conclusion I let you do speak a lot you love to speak oh yeah because you don't talk either conclusion for us is I mean DNS is something we all use every single person in this room uses DNS I would imagine as Paul said Citadel is probably going to impact very few people in this room in this country probably given their victimology but it's really important to know that these guys are after really really important pieces of information they will not stop at anything to get at it it's clear that they're happy to compromise whatever they need to to get to the points where they can get the information they want to gather we obviously we don't attribute Cisco very rarely attribute we will tell you it's a nation state actor because that's who we believe it is we believe they want to get very interesting very detailed information very specific information whereas with DNS we've seen it to be a little bit more I don't want to say DNS is not a good attack or a good platform or a good piece of malware it is but it doesn't really touch what Citadel touched they don't really go for the same victimology and for us that's the major differentiator here we're seeing victims of basically low level hanging through through the likes of DNS where they're sending documents and details but then we're seeing the likes of Citadel come out and go after registrars registrants registrars and registries to be able to basically do what they want to do and as I mentioned at the start that's cyber espionage that's getting very important information that no country, no organization no person wants to lose individually the likes of DNS espionage it's okay really if you get compromised and you lose your credentials to your webmail but if you lose the plans to something very specific that's very important to your national defense that's slightly different obviously both suck but one is a bit more scary than the other we mentioned patch simple stuff like that we mentioned monitor simple stuff like that these are things that people always want to do but never seem to be able to do whether it's resources, whether it's capability I mean monitoring things like your DNS is something you should always do and regardless of what your organization does it's a really really interesting form of intelligence in terms of what's coming in and out of your infrastructure it's a really good key piece of telemetry that I think you should monitor and really what we're trying to say here is pay attention to your DNS don't let these guys get at you if they do please let us know because we'd be more than happy to help and hopefully you don't ever get hit with something like DNS espionage I mean I think our conclusion sums up be careful what you're monitoring go with us that essentially around your DNS these attackers used core DNS infrastructure that we all need every single person in this room needs and they did it with obviously recklessness and abandonment they did it with a bit of finesse because they didn't break everything but it was reckless and abandonment they didn't care essentially but they were very careful at the same time as someone wrote me on Twitter after publication maybe we should use slash a dc slash ost file let's not do that let's not do that if anybody has any questions please feel free