 Hello everyone after after packet here. We have another great speaker for you today. We have Alan with fire and a virus with a spreadsheet. And we're very excited to have them. And with that, I will let Alan take it away. Thank you. Yeah, I'm Alan Baronov. I'm from Melbourne, Australia. Today I'll be taking you through a real life story that that happened to me, mostly real life. Names and places have been changed to protect the innocent. What we'll do is we'll start at the successful end and we'll rewind a couple of months back to see exactly what steps were taken by me and my team to ensure that everything worked out okay. Yeah, the whole thing will be done in Excel because that's what we're on about. But about me, so I started off as a technical person about 20 years ago, working my way through firewalls and other kind of technical security controls and now a GIC consultant. So yeah, that's where I am and who knows where the future will be. If you want to reach out to me, I'm a Baronov or Alan Baronov and most social media. And yeah, let's take it away. All right. So on this slide, one of my friends who works in a blue team environment said I'm definitely put a warning here because some of the stuff that we were about to talk about can be quite scary for blue team. So yeah, Tuesday the 27th of June 2017, I arrived into work and yeah, my boss Trevor was was waiting for me. He was sleeping on a milkshake, which was a bad sign for me because when he does that that means it's going to be an interesting day. And he said that he just wanted to get in before the big people came to speak to me so essentially the CIO and what they called the security board came in and said that they wanted to speak to me. I'm okay. I'm not sure what's going on, but okay. They took me into a meeting and told me that there was something called MS17-010 and that it had been used. We didn't know what it was called just yet, but it's now it's got a name called not petia. It had taken down many of the Australian businesses and businesses around the world like Merck and Merck. And they were worried about our infrastructure and they were worried that that we were going to be brought down. And so could I actually get involved and help them out with that? So yeah, that's all good. And so what actually happened in that was I went back to them and I said, listen, we've got no problems because we're fully patched and they were like unbelievable. They didn't believe me. And I said, okay, that's fine. No problem. I've got all the information in spreadsheets. I'll show you how we've tracked the patching that we've done over time. And they were a bit impressed, but they're also a bit disappointed because I think they actually wanted to put up a bit of a fight against this piece of malware. But anyway, we were successful. And so now I want to take you back through the bit of the history before this as to how we got to this point and I could actually say, yeah, all good. That virus is not going to come anywhere close to us. All right. So yeah, while I was working there, my manager, he came out with this idea that he wanted big monitors and he wanted us to look like NASA. And well, yes, we had Pew Pew Maps and all of that on there, but he also wanted to put some other information up there. And so, yeah, he got me to do that. And I actually coined the phrase security through big monitors and I googled this and there were no search results that came out for that. So basically, I think I invented the term. So if anyone wants to use it, you're welcome. You just need to pay me royalties. So the first thing I decided that we'll do is put up some traffic lights because anytime you have a manager and they want information, traffic light, all the things, of course, because buses like to be given pretty pictures to look at. So what we did, yep, we came out and did a graph where we took all the patches, all the servers, sorry, all the patches divided them by all the servers and of course got lovely diagram. Some months we had more than 90% of patches applied some months we had SNAT. And so we tracked against the stats there. And of course, because we're using traffic lights, you always want to make sure that you're in the yellow just basically because if you're in the red that means you're not doing your job and if you're in the green it means that you've got way too much budget. So that you got to keep it in the yellow, which is a bit strange because essentially what you're looking at now, you know, if Microsoft release a lot of patches you'll probably go into the yellow if they don't release a lot of patches you go into the green. If they release a lot, a lot of patches then you might hit the red. So you're tracking Microsoft and that doesn't really help you. It doesn't give you any direction of where to go. But some of the stuff that we're looking at at this time to try and improve the whole process is, is it really the total number of patches? Did we get them all right? Is it to prove patches? Are there other servers that we could be looking at, etc? So that was that. And then the other thing that, so then what I did was I thought, okay, well let's enhance it, let's see if we can actually dig into the information a bit deeper. So you'll see I've taken this kind of list of computers, total patches, installed patches, all in all we came out 93.6%, which is good, which is great, which gets us in the green. But if you have a look at the actual computers themselves, you'll see that there's some issues here. So some of them are below what we're supposed to be having. Some of them are good. Most of them are good. But this one you'll see even is 76.5%. That may or never have received any patches in the lifetime of that server at all. So it's good to do that because of course it gives us direction. Let me just go back to that one. So it gives us direction as to where to go. So we can see, hang on, most of these are okay. We can just leave them. They seem to be updating. Everything's fine. The two that aren't, we can fix it out that that might be just a, you know, one month that just didn't quite work out properly. Maybe they just need to be rebuted. Who knows. So you can sort those. And then the one that has, is getting no patches at all. That's one where you're going to want to concentrate and get, get everything sorted out. Yeah. So I mean, I can talk about an hour on each one of these kind of slides. But unfortunately I can't. But if anyone wants to catch me on the discord, yeah, I'm available there. Or if you want to drop me a tweet, whatever we can talk further. But essentially, the reason why I put this in here is, you know, once, once you've sorted out stuff, if you see that stuff is recurring. Then you can do, you can check against it and see why it's happening and just keep on working through it. And over time, what you'll find is that you're actually improving. And that's a good thing. So you're no longer tracking whether Microsoft has released too many patches for you to patch or not. What you're actually tracking now is how well are you doing? And how well are you getting patched? Okay. So what I just wanted to point out at this point is that a many, many two relationship is actually a very difficult thing to get right. And we have one in this particular case. So what we're looking at here is we have multiple servers. We have multiple patches. And if you have a case like that, then you need to start working out because it's too much information to try and work with all at once. So you kind of summarize it down to, okay, what, how many servers do we have? Okay, these are servers. Okay. And then what patches are there? But you can get more interesting information once you start looking at the patches. So you can have a look at whether they're a high, medium or low risk patch. And maybe you have different rules for each of those. So now you're starting to get into understanding information at an even higher level. And also you can start looking at the actual ages of the patches. So what you might do is you might say, okay, well, we haven't actually patched these patches here, but we're not expecting to because they only came out this month. And we just haven't had time to test them. We haven't had time to apply them. And they're not critical that we need to do it immediately. So that's okay, that they haven't been patched all good. You might have some that are one month out. And that's a problem because they haven't gone through. But at least you know that. And the next time you patch, okay, well, then that's fine. We'll patch them that time. You might then have a process. You might have it where the process has failed twice. And now you're going to have a bit of a problem. Why is your process not working? That's that's a bit of an issue. And then of course, if it fails three times, then hang on a second. And now we have a huge issue because we've looked at it three times and we still haven't been able to work it out. Hopefully something is being worked out to get that sorted eventually. And now that you have these that information, you have meaningful information that you can graph. And you can go back to doing the red, the yellow and the green, like a kind of flag. And it actually means something because what you can say is like, hang on a sec, where you see red is where our processes are failing. And we can actually start to work on that. And you can bring that down over time. All right, but wait, what about MS-17010 from the beginning of our discussion. So what we were doing before this point was we were actually trying to patch all the different servers over time. We weren't looking at the patches really. We were just looking at the servers and trying to patch server by server. And now all of a sudden you have this really bad vulnerability. It can be remotely attacked. And yeah, it's just a very, very bad vulnerability. It came out bad. And then of course, one of the things that Joshua Coleman came out with is something called HD Moers law, which is it's basically a pun on Moers law. And essentially what it is, is as vulnerabilities get easier and easier to exploit, they become more and more dangerous. And so what happened with this one is it's slowly, I noticed that it's exploits were being built, theoretical exploits and real exploits. And then I saw that and I thought, okay, this thing is going to become a worm in the not too distant future. So going back into the slide here, as I said, many to many relationships are not good because they bring in complexity. But sometimes they are good because now we can actually pivot and we can say, okay, well, we were looking at servers and how many patches we had running on the different servers. Now we can actually go back and we can say, okay, well, now let's look at this one single patch and how many servers have this patch installed on it. And so if we bring it, if we work out that information, then we can see, okay, well, these servers, A, B, E, G, A, N, H, I have the patch installed. And then these three computers have the patch missing. Now remember we're also using, so the reason why we've got so many computers that actually have it patched is because we were going through the computers and we will attack the critical patches while we're doing it. And also at the same time we were looking for computers that were missing. So we actually managed to get all the computers and we got them mostly patched. And then, hang on, these three for some reason just don't have this one single patch. And it could be that the new computers, they just haven't had patches applied at all ever. And so therefore, we can just basically apply the patch. And so that's what we did. And that's why we were successful. So essentially we built the information over time and got to this point. And then we managed to flip it and managed to change our processes. So there's a couple of takeaways. Well, there's more than a couple of takeaways. There's a few takeaways that I'd like to show you. Number one, get information. There's always information out there. The information I got directly from the Microsoft guys, they just basically pulled it out and sent it my way. Raw information, stick it into Excel. And then number two, play with it, manipulate it, move it around, experiment. Keep changing it. It's low risk that you have no issue with, you know, playing around with information. It's all in your spreadsheets. It's all good. Number three, use it to improve things. Try and say, okay, well hang on a sec, our processes need to be improved or not. Do we know? Or don't we know? And then of course, get the information that will tell you exactly what you need to know, whether your processes are working or not. Always ask why don't just fix stuff. Work out why was it broken in the first place, because if it happens again, you'll know and you'll be able to fix it up. Also just note that you don't need expensive tools. We have Excel and that's all I used. So basically that was, I didn't have to guard and buy anything, any special tools or anything. I had it already. All I needed was the information and some of my time to get it working. Don't believe that Excel was free. Yeah. Okay. Yeah. So doing security right is hard. There's no easy wins. So it looks easy from what I've shown you here, but there was a lot of hard work behind the scenes. Once I got the information in place, sitting with the RT team and getting them to patch and repatch and repatch and get it right and research and find out what was going wrong. There was a lot of work. The one thing that I could point out at this point now is that having that extra good information that I could give to them made them more excited about the job that they were doing. It wasn't me just coming as a security person and saying, listen, you need to patch your service because patching service is a good thing to do. It was me coming to them and saying, hey, this computer, it doesn't seem to be working, doesn't seem to be getting its patches. Can you work out why that is? And then they come back to me and say, listen, this is a story and we can actually sort it out and fix it. So that's what comes out of having the information. It makes life a lot easier for you and for your RT team. And yeah, as I said, work with your teams. Yeah, you can say, okay, well, if you're asking why, can you help them? A lot of times they would come back to me and say, listen, I have no idea why this isn't working. And we dig in the history and we can see, okay, well, it patches sometimes, sometimes not. There must be something strange with that box or it's never been patched before. And then you can work out stuff like maybe there's a firewall in the way, et cetera, et cetera. Keep digging deeper. So as I showed you, the first things we were monitoring were just like the total number of patches across everything divided by the total number of computers. And it didn't really tell us very much. It didn't give us a good deep amount of information that we could work with. And usually that information is there. You're just not looking at it. So always keep getting more information. And don't be scared to get information from two different places. Like for instance, what I was saying earlier is we had all the computers that we knew about, but when I found some other lists of computers, those were different. And then the question is, well, why are they different? And then that helps you to actually get a more, a bigger understanding of your total, the total issue that you need to deal with. And number 10, don't be scared to change your process. So we had a good process. We were getting, we were making, you know, making leeway against what we had to do. So, sorry, making headway against what we were trying to do. So we were getting our servers patched and we were getting more servers patched and the lines were coming down because less and less critical patches were missing, less and less non-critical patches were missing. But then when all of a sudden I saw that there was one patch that was really, really important, that we really needed to get out of the way, changed everything. Okay, this is the one. This is what we need to sort out first. Everything else needs to take us, you know, we'll get to that. We'll get to it eventually. But this is what we need to get right now. And yeah, next steps. So if you're interested in this, the next step for you would be get your information. Go find where you can get it from. Get CSVs, get some JSON, get text and convert it. Put it all into Excel. Start fiddling with it. Learn how to join the sources together. Learn how to use pivot tables. Learn how to use graphs and play and play and play until you get the information that you need. Just, yeah, you're a hacker. So use your hacking ability to work with Excel. And that's pretty much it. I'm just a shout out to the Baronov clan and to the DEF CON group of Melbourne. Hey, guys. I'm going to introduce also to the Australian B-Sides team, B-Sides, Canberra, B-Sides, Melbourne. And yeah, to all of you that are there, taking your time out to watch this presentation. Thank you very much for that. And thank you very much to the DEF CON team and to the Blue Team village for having me. It's a great honor to be able to speak in this forum. And yeah, if there's anyone that does have any questions, I'm not sure there might be a bit of time left or alternatively just find me in either the DEF CON Discord or alternatively in the Blue Team Village Discord. And yeah, I'll answer any questions that you have. Thank you very much. Awesome. Thank you for the wonderful presentation, Alan. As always, we suggest that you join the Blue Team Village Discord and direct your questions to Text Talk Track 1. Okay. I will do for sure. The presenter will take a look and be able to answer your questions. And other than that, I appreciate that. And thank you again. Thank you.