 Hi, guys. Before we begin, my name is Stainthor Bjarnarsson and I'm from Iceland. Is anyone from Iceland here? Okay? Somewhere over there. So thank you for attending. Yes, for some of you who haven't probably slept yet and they're sitting here enjoying the cozy chairs. So this presentation is interesting. Well, first of all, Jason Jones, as you probably see, he is not here. Unfortunately, he got sick. So he's staying at home and I'll be doing his slides. But he made them, so he will get credit for it. So this presentation, it's an interesting one because it's about a security incident which didn't happen. But it's an interesting one. And as we are security professionals, we often sit down and think what could be the worst thing which could possibly happen. And all those doomsday scenarios, it happens and so on and so on. And back in February, when something called the Mirai Windows Trojan came out, that was one of those oh, beep kind of things because when we saw it was actually a critical component in one of the worst case scenarios which we could possibly think of. Luckily, it didn't happen. So, yeah, the purpose of this presentation is to explain what was going on, give you some details about the trojan itself, what it can possibly do if it gets activated and how to defend against it. So I think this is rather important. Some people are saying, hey, you shouldn't be going public with this, but yeah, people need information. And if this happens, and I think it actually will, then you are prepared. You know what to do. So, IoT, we all know what IoT is. Yeah, it's all kinds of wonderful things doing all consumermatic, but it's just security issues back and forth. Because they're supposed to be easy to use. They're supposed to be easy to deploy. Should be low cost and so on and so on. And of course, it leads to all kinds of nice security issues. And I'm really happy to see what's happening downstairs at the IoT workshop where you're hacking those things, because this is what is needed. We need to get people to understand, they need to secure those devices. Unfortunately, there's still millions of those things out there unsecured. And what happened last year is basically this, large scale weaponization of vulnerable IoT devices. And those IoT devices, which were weaponized using the Mirai Trojan, actually were used to launch one of the biggest detas attacks we've ever seen. Up to 800 gigs, some say one terabit against DIN, against CREP security, OVH and so on and so on. And these devices are being used to launch attacks which are really devastating and hard to stop. Also, when we were trying to analyze all these things, we actually deployed a number of honey pots out there in different areas around the world. And basically built a VM with simulates and IoT device with those vulnerabilities, place it out there and just basically try to see what's going on. And during two weeks time, we got about, back in November, we got about 100,000 unique IP addresses trying to connect to our honey pot devices and trying to infect them. And the map shows you the source IP of those devices trying to infect our honey pots. So basically see it's all over. What's most important is the number here at the bottom. It takes about one minute for an IoT device when you put it on the Internet to get infected. One minute. After that someone else wants it and can use it for whatever. And that's scary. So what's the situation today? We have, if you have an unprotected IoT device and put out on the Internet, it will get infected within one minute and be used against you. Luckily, most of the IoT devices today are behind a NAT device, a firewall or something protecting it against all those scans from the Internet. The ratio, well, some say 5% are visible, 95% are behind the firewalls. And it's okay, this is sort of okay. They can't be scanned, some might be braced in some ways, but most of them are behind there and it's relatively secure. We thought, that's what we thought basically. Until early 2017. So I'll come back to this iceberg a little bit later on. So Windows-based IoT infection. This is about the Trojan which came out in, which was discovered back in February. So before I go into details, let's give you a little bit of background. Malware infecting other types of devices or basically hopping from one device to another is not something new. We've seen this with Malware which is infects Windows computers and Macbooks and Mac OS and then infects the telephone, the Android phone or Android phone, things which go on and try to break into two factor authentication and so on. But this is, I would say, as far as we know, this is the first Trojan which actually tries to infect IoT devices. So Windows Mirai. Detected early 2017. This is actually, this is not a Windows version of Mirai. This is actually a repurposed Trojan which we discovered back in 2016. Back in 2016 it was actually used to probe for and attack Linux machines and try to mess with the SOX settings. So you can actually attack those machines. So someone took that Trojan and bolted the Mirai code onto it to actually make it now infect IoT devices. So basically someone repurposed it and is reusing it to do new interesting things. It appears to be Chinese. Well, the reason why we say that, some of the text inside the binary, some of the domain names that it uses, the command and control service was a hard coded point towards China and so on. It is not built in a way we should expect a professional organization to do. There are some bugs in it, rather embarrassing bugs in the first versions which then got fixed. But again, we don't really know. Can just guess. So the way we actually map this back to the older versions is that basically the older versions all contain inside the executable these properties which never changed except for the version numbers. The way it works, it spreads to Windows. That is when your computer gets infected, it actually then starts off and tries to brute force MySQL and MSSql databases, scans for us and then if it finds a vulnerable machine, it ejects stored procedure calls, basically they will download and install that Trojan on that machine. Later versions also did the peer attacks and used to WMI as well. Simultaneously, that Trojan will also scan for vulnerable Linux and IoT devices. And this is basically the exact same like Mirai is doing. It scans, tablets, scans, associates, has a database of commonly used using some passwords, tries to log on and then tries to understand what kind of OS it actually was able to log on and then injects the proper binary for that specific OS. So it's basically the same way as normal Mirai. And it's not using any of the other exploits which I've seen more recently, attacks against the web service and so on. It's just plain force username password attacks. A little bit more details. The different versions have used multiple different command and control service. The interesting thing, when we saw it initially, then the command and control service were only active for about a week and then they died. So the later versions actually were pointing towards command and control service which are not active. Which made it a little more difficult to understand how it actually behaves. But as I said, I'm not sure what was going on. Was someone doing an experiment? Was it a mistake or whatever? But the CNC service only active for about a week. Like I said earlier, spreads and installs. We allowed the WGFTFTP. We can also use echo to just push the binary across the state session. And the interesting thing is how they actually build up the binary. Because it actually uses the resource part of the executable to store the different binaries. So basically it has about nine of them. Just puts them in there and it's actually a nice way to build the trod in itself. So I would say the program part is pretty okay. I like the structure of the trod in itself. Easy to modify, easy to create new versions. As you say, the command and controls for the mirai part, they were hard coded to this address and they were all down. They have never come up. The command and control service for the trod in itself, those are the ones that are up for about one week. Okay? And this is just showing you how it's actually stored inside the resource file. Okay? Someone is trying to inject something. It's a remote injection call. They also stored all the debugging strings inside the binary. Which is pretty nice of them. Makes it easier for us to understand what's going on. It also shows us where those debug strings are used in the code. Which makes it easier to detect what the which part of the code is doing what and so on. So thank you. Please continue to do this. A little bit about how it actually works. So as soon as it's infected your machine, it will then try to download a text file. That text file contains two things. One, a link to a JPEG. And then a link to a buts file. So actually they store the executable inside the JPEG. The JPEG, it looks perfectly normal. I'll see you in the next slides. But it actually contains executable which can extract from it. It also downloads a version file. So it actually tries to see what's the latest version and so on. So just to keep itself at the sink. So this is the JPEG. Looks like a normal JPEG. If you take a look at it or try to see what's going on, you can display it. It's a nice picture. But inside it, you have the actual binary for the executable. Pretty common. The buts file downloaded. Also nothing special except for this part. The one highlighted in green. Which is showing you it actually tries to download the DLL. You have no idea what the DLL is doing. Could be doing anything. But at least it has a hook for downloading something extra to do extra things. It also downloads what we believe to be the configuration file. So first it downloads a file containing the M.D.5 checksum of the configuration file and then the configuration file itself. Which is encrypted. And because as I said, we never were not able to do detailed diagnosis of it, then we were not able to crack this and see exactly what it contains. But it probably contains with scanning modules to use. The subteness to look at and so on and so on. And also the use in password is used for brute forcing. Then those are probably in there because they're not part of the executable itself. So, okay. Now I spent about ten minutes talking about the Trojan which never got active. So what's new? Well, people are deploying these creating Trojans all the time. And what's so special about this one? Why am I actually up here and talking about these things? And that's because of the iceberg. Five percent of IoT devices are outside on the open internet and are already being used. Ninety-five percent are behind the firewalls and everyone thought that was perfectly safe. So, these things happen. Zombies. So basically a vulnerable computer, a computer containing the virus, when it comes into your network, it is now capable of actually locating and effecting all those vulnerable IoT things you have behind the firewall. Could be web counts, could be DVRs, could be the, well, anything. We have refrigerators and stoves downstairs. It could be used as bots or zombies. So it will actually separate them and change them all from something innocent and nice into these kind of things. Now, when the attacker is getting control of all those things behind your firewalls, he can begin to do interesting things. Like, of course, scan for other devices, launch outbound attacks, and then also try to attack internal resources. So let's go into more detail about this. What can happen? First of all, this is a typical network design for mid enterprise network. I'm not going to tell you who created it because we need to protect the innocent. But it's a typical design for how to build a secure mid enterprise network. The useful thing, bad guys on the outside, then you have some security boxes, and then you have this guy. The one who was attacking DEF CON, he got infected by something, and then tomorrow he comes back to his network, probably his branch in Las Vegas, and then he plugs in his laptop. What can possibly go wrong? Okay, so first of all, scanning. In this network, you have tons of IoT devices. But just to make your life easier than these are the ones which I found very quickly. The webcams. Well, probably a little bit more high end than the things you buy out on Best Buy or somewhere. But probably not being upgraded recently. Why upgrade the software and most things? They're secure. They're behind the firewalls, right? But what happens is that this guy down here, as soon as he plugs in his computer, could be local, could be remote via VPN or whatever, it begins to scan. Scans the local subnet. In this case, it actually finds a webcam in the same branch office. Continue scanning, goes to some other devices, and then it will probably start to scan other subnets. The version which we got didn't do that. It only scanned the local subnet. But if the configuration fellow said, please scan all RFC 1918 subnets, then it's easy to scan some other subnets. And then it continues and continues and continues. But look at this. Now there's a black arrow coming. Because as soon as this webcam got infected, it will also start scanning. So, and if it infects other Windows computers, it will also start scanning as well. Meaning, as the traffic increases, as more devices get infected, you will have more and more devices doing scans. The scans themselves are not that risky, but actually the act of performing the scans is what can cause problems. And unless you've seen, just sending out ARP packets, try to send the packet to 1 and 2, 1, 6, 8, 0, 1. Okay, that's a hit, 0, 2. Someone is responding, someone is actually trying to use resources for all those ARPs and try to process them and so on. And what we have seen is that just scanning activity itself is enough to make most normal networks collapse. This happened back in the old days with NimDent and those things. This happened actually last year in Germany. When a large service provider got infected by a MIRAE, and when the CP devices began to look for other devices, they actually caused the access routers and switches to collapse. Meaning the entire user population in Germany, about one or two million users got cut offline. Just because of the scanning. Also, this scanning stuff sends a lot of small packets. And devices, most network devices are not comfortable with having tons of small packets going through them. So this could cause a problem. The second thing, now this guy he's suddenly gained control of lots of webcams from different companies. So what will we do with them? Well, he will launch DDoS attacks, of course. So, first one sends a packet, second one, and third one, fourth one, so on, and so on, and so on, and so on. So basically, if we gain control of 100 webcams inside your network, they will probably use all of them to launch outbound attacks against someone else. So, okay, that's bad for the guy on the internet, but in this case it actually could cause serious problems inside the network itself. Because these attacks, the mirror code is using, could be packet plotting, it could be ICP, UDP, TCP, could be syn attacks, could be reflection attacks, could be application level attacks, all kinds of things, but most of those things are small packets. And what's interesting is that inside the network, you have all kinds of devices which are state pool. And this is important. A firewall will actually, when you send a packet through a firewall, any packet, it tries to remember if it remembered the packet itself, because you might be setting up a connection, which means it's storing information about that specific packet. And when the next packet comes along, it stores also information about that packet. And the third one, and the fourth one, and so on. In our experience, a firewall when defending against outside attacks will collapse about 50% of the time. A firewall which is actually sending outbound Deedostract hook will collapse all the time. It will simply go up in smokes and die. So just the act of launching an outbound Deedost attack will cause most of your firewalls, load balances, switches, routers, and anything else inside your network to go up in flames. We attacked it and wasn't planning to do these things, but this is what will happen. Also, you have van links. You're connecting the branch offices back to the headquarters. What will happen? Those links will fill up. That means the important traffic, that is for your commerce systems, your phone traffic, whatever else, will not get through. Basically, your network is full of junk, your boxes are falling down left and right, and you're in a bad state. The third one, if the attacker is clever, he will probably try to do some kind of reconnaissance. Because, well, if he has control of devices inside the network, let's why not try to find out where he is? So he starts to do probes. Basically, try the webcam in the data center, sends out some packets, listens to some packets, and so on and so on. And very quickly, he finds out he's inside Evil Corp. Which is an interesting thing, because that's exactly the target he wanted to attack. Because he's doing reconnaissance, he'll probably find out that, well, the network operation guys, they are in subnet 10, 1, 1, something. The security operation guys, they're on 10, 1, 2, something. And how difficult would it be to inject some kind of a routing packet, or a null packet something, to basically shut off the security guys and the networking guys, leaving them totally offline, and then launch his attacks. That's basically trivial. If you're inside the network, attacking routing protocols is relatively easy. So he would then launch his null routes, shut off the security guys, and then he would start to de-dose the data center, then he would start to de-dose the regional data centers, and so on and so on. And basically, taking everything offline and totally shutting down what's going on. So this sounds bad. And also, this could actually lead to something new, which is the ransom attack, well, basically. De-dose the attack from the inside. Because this clever guy would run this for 10 minutes, then he would send an email saying, hey, please pay me some bitcoins. Otherwise, I'll continue. And defending against an insider attack, if you're not prepared to do that, is really difficult. It's difficult to start to reconfigure a network, set up a segmentation, remove stateful devices, put hardened devices on during an attack. It's basically impossible. So, and then the question is, wait a second. Can a webcam or something, a thing which costs $100, can it actually take down a half a million dollar core switch? Something queued from Cisco or someone else with multi-terrabit, this and that and so on. And the answer is, if that device is not secured properly, yes. But to understand that, we need to understand how the anatomy of the typical network device. Most network devices have something called fast path. And then they have something called slow path. And this is where the CPU lives. This is where all the ASICs and hardware accelerated this and that lives and basically shops packets through it on full via speed. And the packets going through, these are the normal data packets. And this is in most normal situations, a network device works. Packet comes in. There, if you look up where the packets would go, this happens in hardware, takes no time whatsoever and the packet goes out at different port very quickly. That's good. And the main CPU load is about 1%. And that's how things should be. But a network device needs to communicate with other devices. This means it needs to receive information, need to receive routing updates. It needs to be able to be managed. It needs to send statistics and so on and so on. So there will be some packets going towards the device which it has to process. Then you have the interesting packet which is called exception packets. Things which should have gone through the device. But for some reason, need special handling. This could be things like TTL expiry. You send a packet which expires on the device. That means it will have to be sent to the main CPU. The main CPU will have to create an ICMP TTL expiry and then send back to source. This means one packet will actually cause the main CPU to analyze and create a new packet, use memory and resources to do that and then send it out. That's quite a hit. So let's send 10 billion packets towards that device. And if you manage to do things properly, then you will have problems. One other thing which most people don't know about, non-IP packets. If you send a packet which is not IP towards a switch or router, it will have to be sent to the main CPU for special handling. Could be ISIS or could be something else. Again requiring special handling, CPU and resources. And if you manage to keep that CPU busy enough, it will not be able to do what it's supposed to be doing. Like receiving routing updates, sending out routing updates, sending hello-timers or something like that. This basically translates into this and this is actually a test. I did this about, I think, seven years ago at the Dunn and other conference where I was using just a normal tiny little VM to attack a high end course switch, supposed to send 720, be able to do 720 gigs of forwarding and it died in five seconds. Because of this, because I sent just 300 packets per second, specially crafted towards having them sent to the main CPU. What happened, it got so busy, it couldn't send out the hello-timers and basically all the routing information collapsed and it became a black hole and the network just collapsed. That's pretty cool. If you do things correctly, but it was an unsecured device. As soon as they enabled the security on that device, no problem. So, how can it depend against those type of things? So, let's learn from history. This is interesting. Castles. Back in the old times, these guys were actually, they were trying to defend against attacks. So they built castles. And castles are usually quite difficult to get into. Like in this case, if you want to get into the main tower up here, where you have all the goodies, the jewelry and so on and so on, then you need to get through multiple layers of defense. If you take a look at the aerial view of this, sorry, you would probably not try to go up here, not because these are high cliffs, you'd probably go here. And if you look at the aerial view, then you'll see this is actually a big area where we would defend these walls first. And if the attackers get through, then you basically retreat for next set of walls. Short a wall, easy to defend. And if that collapses, then you move to the next one. So it's all about delaying the attacker, seeing what they're doing, gaining visibility into how they operate and so on and so on. So that actually makes a lot of sense. Because as we know, if someone really wants to get through, he will get through in the end. Unless you unplug everything and shut down everything in existence. But then he has succeeded. And here's an interesting fact. Stairways. Who knows why I'm showing this picture? Don't tell them. Okay, some of you guys. The thing is, stairways and medieval castles were usually built clockwise. And there's a reason for that. So, if I'm down here, I'm trying to get up these stairs and let's assume it's circular. I'm standing here with my axe or whatever and this damn thing is in the way. Which means I have to use my left hand. If I'm right handed, that's a problem. If I'm standing up here and I'm right handed, I can really bust the shit out of him. And it gives giving me an advantage. So just the fact of building a castle with the stair going this way actually gives the defenders an advantage. So it's a small thing but actually someone thought through these things and thought this makes sense. And by the way, is anyone from Scotland here? No one? Because the Scots did it the other way around. And the reason for that is one of the last families in Scotland in the medieval times, they were predominantly left handed. So they built the stairways such that it would give them an advantage. This sort of makes sense. The only problem is, by building the stairs that way, that made it actually easier for the right handed guys coming up. Okay, so it's okay. Not sure if it actually makes sense but that's how they did it. So coming back from castles, layer defenses, building your network in such a way they can actually withstand attacks, can detect what's going on and so on and so on. The interesting thing is that the service providers have been doing this for the last 20 years because they are in exactly this situation. They cannot rely on anyone, they cannot trust anyone, they get attacked by the customers, they get attacked by other people and so on and so on. And they really need to build the networks so they can survive almost any kind of attack. The thing is, they actually use a six phase methodology. The first thing is preparation. You need to harden your network. You need to design your network in such a way that it's able to withstand these types of attacks. That means using a lot of time and effort to actually implement security, put segmentation, put access list and so on and so on and such that they are in the best way, the best shape possible to withstand the attacks. Then when things go wrong, you have to first of all identify that you're being attacked. Sometimes you don't, you're not able to see that. If it's a stealth attack, it could be just going underneath what's happening. Someone could launch a big Deedus attack while they're trying to hack the way into your network. So you need identification. That's the first thing. Then you need to be able to classify what type of attack this is. Is it this kind or that kind or so on and so on. Then you need to understand where is the attack coming from? And then and only then you do something. The biggest course of outages is when people do something. They panic. They start pressing buttons and they implement this or that and in many cases they're just helping the attacker because they absolutely no clue what's going on. So you need to follow these steps to actually understand what's going on. Then when you're finished with this, before you go to the pub and say, hey, we did good and we're good guys and everything is fine, understand what went wrong, learn from the different phases and then make sure you actually can do things in a better way. So you can also look at it from this side. This implement network segmentation, understand the developer process and use flow telemetry and this is actually for free. This is NetFlow, which almost every device has. And you can take the NetFlow information and that will actually give you understanding of what's going on. It will detect the scanning attacks. It will detect all the attacks. It will show you what's happening. And by the way, everything I'm saying here is actually in a white paper which can download with all the nitty-gritty details. And then you should scan for your own services. You don't want someone to use your own DNS server to launch a reflection attack against yourself. So find those services which are not secured properly, harden them, config them correctly and basically if you think that everyone is out to get to you, that's the right way to think. Don't first anyone. Not your customers, not employees, anyone. They can all become zombies and attack you. And there's all kinds of features which can implement on the network devices with a disabled by default for some interesting reason. Like URPF, ECP snowpings, all that and so on. Most of them which will stop all those things from happening. So summary. The attack is now inside the house. This hasn't happened yet. But someone took the time and effort to write the code to do exactly these things. For some reason they didn't go live. We don't know why. Was the test, was the mistake? For just someone having fun? We don't know. But the thing is, the binary is out there. Anyone can download them. It's easy to reverse them. This means basically anyone else can actually now go out and do exactly the same thing. Now as I've just presented about all the threats about these things, then yes, maybe someone else will actually think, hey, this is cool. Let's do it. But still the idea is to give you information. So I would say this is real. You need to secure your network before someone actually uses the network against you. And as I said earlier, service providers and large enterprises who are really security conscious, their networks can be secured well enough to actually take care of these things. So it can be done. But it involves work. And the problem is a lot of people want to buy a box with blinking lights because it will solve all the problems, right? And if it doesn't solve the problem, they go off and buy another box with a lot of blinking lights. This case is just a matter of engineering, network engineering, doing the right thing, making sure that that thing actually is secure. It's effort, but it's worthwhile doing it. Because if you do it properly, you not only secure yourself against these things, but you secure yourself against one cry and basically almost everything out there. Because you've segmented your network, you've hardened it, and you can actually protect yourself against most things. But it requires time and effort. So hopefully this presentation will help people to understand the threats which are out there and why they have to do those things. So, at that, I'll basically say thank you. And if you have questions, I'll be your time.