 Wonderful, thank you everyone for coming, it's great to see you here. So before I start, how many of you actually work in information security? Wonderful, great to see you here. And now let's do completely the opposite. How many of you don't really know that much about techy computer stuff? There's a few hands, actually. That is also absolutely brilliant to see. That's why we're here and hopefully I'm not going to go too over your head, please do stop me if I do. Afterwards, that is short time schedule. Right, so let's begin. Now I've talked about you for a while, let's talk about me for a while. So I'm Michelle Disraeli. The reason I'm giving this talk is that I really love incidents and I love analysis. So before I moved into information security, what most people call cybersecurity outside of the industry, I did major incident management. That is, when there was a complete and utter IT disaster, servers on fire, I was in charge in making sure that got fixed and the right people were told and communications sent out. And then after that, I moved into information security. And that was doing again a lot of major instant response within large, this was all within a large global services company. Responding to incidents and also doing things like major headline hitting fraud investigations. So that was really, really cool. And then after that, I went and joined my current employer, Babcock MSS. And for the last year, we have built up from scratch, absolutely scratch, a brand new company, new infrastructure, new servers, new building and created a brand new security operations center. A SOC is what we call it, it's not footwear, it's an office. We watch screens, we look out for security issues, we investigate them. And this talk is really an excuse for me to talk about some of the things I found that were not security incidents, but I thought were worth sharing and talking about some really good reasons. And when I'm not actually in the SOC at work, I can be found volunteering at events like this. So I'm one of the people heading up team conduct and access. Helping make sure everyone has an amazing time with each other and is able to do everything they want to do. And when I'm not doing this, I can be found confusing PowerShell for Skyrim, which don't ask. And when I'm not doing that, I can be found doing things like this and this. You see, I say cybersecurity and unfortunately for everyone else in the industry, I am a convert to the term. Because one, the lovely Dr. Jessica Barker has convinced me that actually it makes sense to call it that, everyone else outside of industry calls it that. And two, well, when I'm not in the SOC, I'm organizing goth and industrial nights. I am literally a professional cyber goth. If you're wondering where my dreads and gas masks are, they're virtual. So what do I mean by false positive? Well, back when I did major in management, it was really, really simple. Is the data center on fire? Kind of obvious, it's really an issue. And the great thing was, people will tell you, hang on, they'll actually tell you. That's a true story, by the way. People do just send emails rather than phone. But in cybersecurity, it's very different. Because we can't just, we don't get people to call us up. The bad guys, they're not generally going to pick up a phone going, oh, hi, I broke into your network, lol. We're going to have to figure out what they're up if anyone's doing anything. And the only way we can do this is we monitor logs. So every single server network device creates logs of what's going on. And those logs, well, there's a lot of them and they look like this, not like that, so that and that. And unfortunately, there are so many of them that we can't do that, actually. As much as I'd love to. There are over, typically, for a reasonable company, over 5,000 a second. And not characters, we're talking complete and utter. This has gone on, this person, this computer, to that one. I can't read that fast, I'd get a migraine. Nor can I do what our marketing says, I can't do that. So instead, what we do is we build clever rules. This is the logarithm for those in the industry, or seems like democracy, ask me later. We build clever rules that automatically look through those logs and raise us alarms, which automatically sort of flag up, this might be a security incident, go do some work, investigate it, find out if it is. But as I said, we have 5,000 logs a second, that's a lot of logs. And unfortunately, if you want to catch bad guys, they're normally not doing much. So you're going to have to have a lot of different alarms. And more than often than not, you're going to get a lot of alarms that are boring and not important. And that's what I mean by false positive. So if an alarm doesn't raise and it is a security incident, that's why we have lots of alarms, hopefully one of them will eventually catch it. If it's not a security incident and there's no alarm, brilliant. That's doing its job. If it is a security incident and there's alarm, yay, that's actually why I get paid money. If it is a security, if there's an alarm and it's not a security incident, that's a false positive. But we don't talk about that much as an industry. All the time in the news, it's APT attack, Russia hacks Ukraine, et cetera, et cetera. Be scared. But we don't talk about all the other things we find that actually have real value both to organizations themselves who learn more about themselves and as cybersecurity professionals how we learn and grow and develop our skills. So this is what I want to share with you all today. So I shall have a drink and then we shall get started. Yes, this is just a massive excuse to bitch. Okay, here's the first false positive I'd like to talk about. I'm going to give it the monkey of false foreign memories. Let's go. So the alarm I mentioned in hindsight, that font is way too small, so don't worry, I should explain this. The alarm. It was a big siren going, we are seeing a suspicious.pwdns query. Does anyone here not know what DNS is? Any hands? I can't see any, absolutely fantastic. That is brilliant because that means I have some false positive slides. Yay. Self-referential talk. So why is .pwdns something we're concerned about? In this case, it's because domains cost money. PWs were traditionally cheap. Bad guys want domains because they need to be able to talk back to get instructions, et cetera. Cheap domain names are the best. So we often see these obscure ones are used in these contexts. Did anyone actually understand that? Sorry. Fantastic. Thank you. Okay, so what actually caused the alarm? Well, digging through our network traffic, this is what we found. So it was a DNS request for a string of random characters. If you see red comic sans on any slide, that's stuff that is redacted or otherwise I'm not supposed to say because even false positives are cared about by security managers. And that is also worth keeping in mind. So random characters and a domain name, that is again exactly what the bad guys like to do. Random is brilliant. It means that a police force can't sit down and look up, oh, let's find bad guys, domain names. I am an evil hacker.com. I think that's a hacker. So they like random. Also, random domain names are things that you can just make a program, guess randomly, pick ones, always cycle through them dynamically, generate them all the time. And that then means you never know which ones you need to block to protect against malware. So that's really worrying is random characters. So we investigated this. I said wheels me, I suffer from giving credit to all my colleagues. So the investigation and this, the IP address behind that was in Russia. And sadly, there is a lot of cybercrime associated with Russia. That's worrying. And the traffic we saw going for IP address was HTTP traffic. It was the web content. In this case, JavaScript file. And does anyone here not know what JavaScript is? You're all an absolutely amazing people. This is fantastic. Well, because of that, though, JavaScript you probably can guess then. It is also one of the things that is used maliciously. It can display false banking pages or whatever or try and infect your computer. So JavaScript can be worrying. So let's have a look at what it was. It's boring. Utterly boring JavaScript. So it was just light boxes, menu controls, all the stuff that you find on a normal web page. But on a HTTP request, there is a refer a header. And that refer a header, in this case, was coming from another random domain name from Russia, which is still a bit dodgy and weird. Maybe this is part of a bigger thing the bad guys are doing. They're setting up a fake banking website. This is the controls for making it look like a normal bank website. So may still be bad. Let's look in further. So we looked in and we found that this is a Russian CDN, a content delivery network, which they like random domain names because they need a lot of them. And it's ultimately live journal. Who remembers live journal? Yep. I still have some live journals kicking up. I need to shut them down now. So that was quite interesting because it wasn't just live journal we found. It was actually an actual account on live journal. It was almost certainly the account of the person who was looking it up because it was looking at their friends feed or their friends posts. So that actually is something we really have to be careful around. And it's one of the things we can learn from this. That as we investigate things in a security operations team, we are going to uncover personal identifiable information about staff that are on our networks or our customers. In this case, it was actually from a public access PC that was sitting on the network intended for the general public to use. So it's even worse than a staff member. This is a normal human being just using computer in a library maybe who looks it up and doesn't think that their information is going to be intercepted by us. So this is something we need to be careful around and be mindful about. And by investigating this false positive for this degree as well, we've stopped the spread of information because we haven't raised like a... sent it on to another team to investigate, raise a big incident, HR spins up. So we don't expose someone's private life to people who don't really need to know about it yet because the content of that live journal wasn't even... that was all work suitable. But it's worth remembering that that content is with like... people stay on older social media, social networks because they're part of communities that live on them. Those are often on older ones like DiveChannel, communities that value privacy. So LGBT, mental health, disability, activist and so on. So we need to be mindful about that. And the other thing is that websites we once trusted, they can be sold on and they can be ran anywhere in the world just because we trusted it once with all our personal angst. Doesn't mean we should trust it forever and it will always stay genuinely good. So let's look at our next one. That's going way too fast, my apologies people. So this is something we saw quite a lot of. So who remembers ShellShock? Fantastic. So this is those of you who use Snort or SourceFire will recognize this rule. So this is a rule looking for possible ShellShock attacks. So this is ShellShock's way of getting code to run on a remote server. So for those who don't know the details of ShellShock, there's a vulnerability in Bash. In this case, it's trying to be potentially exploited on HTTP. Web servers need to know something about the browsers making a request. You need to take that earlier you're asking for and your browser name and pick the appropriate web page to return to you because you use Chrome. So the way they do that is classically on a lot of old web servers. They just drop it straight in a variable. If that variable you drop a function in instead, the website just goes and runs it. Web server runs the code, whatever it is. Boom, the attackers win. So let's see what actually triggered this. So in this case, this is what we found that was triggering the rule. So this is an URL and okay, this looks odd. This isn't a normal URL. It doesn't look like what you'd find if someone was browsing the Daily Mirror. Why you do that is, you know what I mean? So that's what we found. And it's lots of percent symbols in there. For those who aren't familiar, those percent symbols, it's URL encoding. Some characters are not allowed in URLs. So you convert them to a form that is allowed. So let's decode it. This is what we get when we decode it. That's really odd because that there is JavaScript in an URL. Or at least looks like JavaScript. Why would you get JavaScript in an URL? Some of you have probably already figured this out. So what's going on here? Well, JavaScript, you know, the one in the security world, it's quite often you'll think, oh, this could be cross-site scripting. It's trying to put code in a web page. So when someone else accesses it, they see code loads in their browser. They use that person's cookies to do things, pretending to be that person so they can break into their bank account. And that was a real comment made by someone else I've talked to in the industry who's gone, this must be cross-site scripting. It's really scary. What's going on here? Is it code injection? Is it a server run JavaScript? No, it's far more boring. It's just using JavaScript as a means to send information back to the server. I mean, JSON, not quite JavaScript, but it's JavaScript-like. We love JSON. It's a great format for some things. Sometimes we might want to even send what function was running or maybe it breaks and doesn't return a value. So the browser just returns native code to returning the function. So what's actually causing this here? JADServe. This is a very, very common thing that we have found, that it is an advertising server that runs on Java, it has JavaScript input through JSON. It's depressingly common. We see it all the time from JADServe, post-release.com, and from kaseomedia.com. There is a lot of this going on. It's all advertising or analytics-based, and it's depressingly common. So what do we learn from this? Don't immediately jump on the cyber-cyber-hype train because it may not actually be a huge major security issue. It might just be a website deciding to send JavaScript in the URL. Adverts are a pain. A lot of how advertising has to work and needs to work will come across looking very, very dodgy, and we'll come back to that later. The other thing, and this sounds silly if you actually know web design and HTTP, but a lot of people do forget that a GET command can send information back to a server. If you're asking for a page and giving a URI, then you can actually send information back in that request. You don't have to do a post, and that's easy for some people to forget. So let's look at the next example. This one here, the European connection. This was another slightly concerning one. So this one was an Angular exploit kit, outbound URL structure alarm. Who has heard of the Angular exploit kit? Some of you, but fantastic. So what do I mean by Angular exploit kit? So an exploit kit is a bundle of all various vulnerability attacks used so that when a person's browser goes to a site that has it sitting on it, that exploit kit will run through a whole bunch of JavaScript, set cookies, and direct you off to a vulnerability that is perfect for your browser, or maybe you can't be exploited by the vulnerability because you are running some Linux thing with a variant of Chrome you've written yourself with some ad blockers in place, and it'll just send you to some other site to see your connection. And exploit kits, they all use very common techniques across them. Angular no longer exists, but we see a lot of other exploit kits these days use the same methods and techniques, and even code that Angular used to use on its websites to infect things. And one of the things they use is they use long random URLs. As I've said earlier, random is hard for people to pick out and spot. So random is really good because no one looks, you know, someone looks through their logs, looks at normal websites appearing, they won't look at that random one that's been injected in the middle. No one notices it, it's hard for people to work out in advance and say, right, everyone, check you've got Angular, just go to your website address for slash Angular. See if you're infecting people with Angular, that doesn't work. So this is a random one, so you can't just share the URL to find out if your website has been affected by this. So what this rule was looking for was for these long random URLs, or URIs, I'm one of the few people who like calling them URIs. So this is what we actually saw in this case. So it was to a subdomain of wp.pl, long string, and that string there. It's not just long and random looking, it's actually encoded using base64. It's just like so that those of you who don't know base64, it's an encoding, it's not encryption, it just changes things to a different format. Think Morse code, it's still, you can send English with Morse code, it's just an encoding of English. So that was a bit odd though, why would a website have long base64 URLs? That's weird. That's a Polish domain. We saw this on an entirely British customer's network. They were entirely British. They had no overseas operations. Absolutely entirely based in England. So what was going on here? Let's look what actually was behind the URL. That's an advert in Polish, I'm told. So it turns out that actually the same characteristics that make exploit kits love long random URLs, advertisers love it too. Because how do you write an ad block for something that gives completely random URLs that also has other website content similar style addresses? You can't, so they love to use it to make it hard to block adverts. But what is this wp.pl site? This is wp.pl. And it may remind you of something. Yahoo! wp.pl is a Polish equivalent to Yahoo. And the reason we know this is we are lucky to have team members from Poland. And this is one of the many reasons why diversity in your teams really matters in cybersecurity. Because all your different experiences and backgrounds mean you can identify different things as they happen. You can understand the background to them, understand the risk, and so on. So we were very lucky to have a Polish team member who could immediately recognize the site and go, oh yes, I know that. It's very big in Poland. And also, we do live in a global economy. So just because your customer may only be based in one country and not work overseas, not have any overseas partners or suppliers or customers, don't assume they won't have any overseas staff. So you will always get these come up unless you have any special reason to think otherwise. This can be perfectly normal legitimate traffic that we must be aware can and does happen. So, and now, now we come to my final example and this is a personal favorite of mine. This, this is, it's not malicious but it's so overzealous in its technique it may as well be. It is not actually a security incident but they try to be one so hard. So in this one, this is, the alarm itself was an antivirus scanner on someone's computer, picked up that they'd loaded a web page with a JavaScript file in it that had a double exec call. So how many amongst you here actually know the exec call in JavaScript? Some of you, that's brilliant, especially for those of you who don't because I'm going to tell you all about it. So the exec call in JavaScript lets you create and run code on the fly and that can be a really, really useful feature. So you don't always know what you want to do when you're writing the code initially. So sometimes you might want to modify it on the fly. Think, a simple example of that is think Excel, think a spreadsheet. If you're on a spreadsheet thing you might want to put in a formula for a cell and the exec is a really great way of making those formulas work. Props isn't what I'd suggest using, but it can help explain why you might write a feature like this. But because it can generate and run code on the fly that's great for the bad guys because you can just write code that looks all nice and benign and it generates the malicious code on the fly when it's already downloaded to the user's browser so that nothing on the network spots it. And one exec command, as you can imagine, is quite common. You often need to come up with your commands on the fly, work exactly how things work, but two of them in a row? That's, you're taking one bit of code, you're generating some code and then you're generating some more code from that. That normally means you're trying to hide something a lot and you're going to great lengths to do it. So, this particular investigation, this one we got, so the actual trigger for this alarm came from a site that was offering an online security services of service sort of thing. I won't mention which one, but this is a site that security conscious people use regularly and this is then more worrying because if it's a site that security conscious people use, well, that's a prime target for attackers because you're going to go, anyone using that website, they're going to actually be really interesting. I want to break into their computers, I want to break into their email, I want to know what it is they're trying to hide from the rest of the world, maybe they're Hillary Clinton. So yeah, that was odd, that's quite weird and that does suggest maybe there's something dangerous going on here, maybe someone's managed to deface the web page with a script that does something naughty. So, here's the actual code we found and as you can see there, again, it's a huge amount of random, which is really odd being put in a string and that went on for a very long time and then eventually it decodes, at the end it decodes it and passes it through the exact command twice. Now, you'll remember from earlier base 64, that's base 64 encoded again and there's a decode string there for it. So let's decode it and see what it decodes to. It decodes to this, which again, that's not final code yet, that's really worrying, why would it hide twice? Decode that again. Here it is, setting cookies and checking out what plugins your browser has. That's weird. Remember exploit kits from earlier, exploit kits do this. They want to know what browser you're running, what plugins you have so they can push you at the right attack code. This is scary stuff. Down here, so one of the things that we see repeatedly through it is Incap and Incapsular. What is Incap and Incapsular? Maybe you should try googling it. It's an analytics and cybersecurity company. They've gone to great lengths to encrypt the analytics script. It's a perfectly benign script, much like the one Google used for Google Analytics and the like to discover things about your browser. They've gone and heavily obfuscated it so you can't tell what it is, which is really weird. What do we learn from this? Actually, all the techniques we just did are the exact same ones you have to do to analyze an actual exploit kit and understand what's going on behind the scenes. It's the same techniques that attackers use that we're seeing here. When you investigate a false positive, you can actually work all those same skills and practice them all so it can be interesting to investigate and discover. It's a great way of training people. This is also, once again, advertising analytics. There's a huge trend because more and more people don't want to be tracked online. There's a huge trend to trying to block tracking scripts. We're seeing increasingly companies making tracking scripts like that that are heavily obfuscated so you can't tell they're a tracking script. That brings me really to the end of my talk. A few closing notes about this that actually false positives are worth documenting. Something I came across when actually trying to write this up is half of these I hadn't written up as well in advance. I've discovered over the last few months I've been training up some graduates and new analysts and this is exactly what we found that actually maybe we should be training them in false positives. What do false positives actually look like in the real world? Don't just teach people how to spot real cybersecurity incidents. Teach them how to spot when things are not a cybersecurity incident but look like one. Let's talk about them more as an industry. Let's share this information. Next time you have a false positive that's one of the techniques I've covered here you've already encountered something similar. You now already understand it. Let's share it so we can help each other understand false positives and actually focus on the really cool exciting issues. Finally, I'd just like to close with the final thing that Encapsular said just when I tried to close the page didn't find what you were looking for. Thank you all for coming. It's been lovely having you here. Please feel free to come ask me questions. You can follow me on Twitter if you want. I've been Michelle Disraeli. You've been amazing. Thank you everyone.