BSides Track 1 Day 2

Check, check. All right, check, check. All right, I'm good. Good morning, everybody. Good morning, everybody. I'm glad to see that you're all well caffeinated. I'm glad that you guys are here. I'm glad that you guys are here. So today I'm going to be talking about the importance of hunting and what hunting actually is. More importantly, what hunting is and what we're looking at trying to actively go after bad guys in our organization. And I have this slide that's been following me around for years. And it's interesting. It's from the Verizon data report, which I know that people like. Oh, God. Which I know that people like. Oh, God. But I love this slide. It's from

years ago. But it's basically detection mechanisms. But it's basically detection mechanisms. in their organization. And the numbers really haven't shifted over the years. The numbers really haven't shifted over the years. And they say that these percentages for detecting bad guys and actors in their organization are about the same. And I think that there's some things that we can learn from this. If you look up here at the top, unrelated third parties 34% of the detects in organizations. That means that's how they discovered they were in fact compromised. If you drop down fraud detection, that would be an external resource. Think credit card fraud. A bunch of credit cards are stolen from an organization and then

Visa triangulates them and says, yes, they all came from this one organization. That's 24%. That's not just Visa. I'm just using them as an example. Customers are a lot of fun. 90% of the time, 90% of the time, I think you guys are compromised. And that terrifies me because honestly, whenever we talk to help desks or a lot of our customers, what's the level of technical acumen that we put on our customers? Law enforcement is 8%. Actors going out on Pastebin and saying, hack your organization. Here's proof. 7%. And this actually mirrors up with what we see at Black Hills Information Security and our incident response. There's a lot of organizations that call us and they say, "We received an email from

a hacker that said we were compromised. We need help getting them out of the network." That's 7% of the organizations detect that they were breached. I don't know how they know that. I've called and I've talked to some people, like, "What is unknown?" So it's basically organizations waking up in the morning and they're like, "Hey, we're compromised!" I don't know, I just kind of came in and I slipped and whoa, there's a breach. And I'm a mistake. Reported by internal users. A lot of us think our customers aren't that right. But think about your end users. Like walk through the cube farm where you work. And look at the average user and how they use

a computer system. These are people that predominantly still think the DVD tray is a coffee coaster. And 4% of the breaches in our organization. And you know, because those are good guys, right? But less than 1% manage security service providers. So I know I'm not supposed to talk about products because that's just slimy, right? But I'm going to break that rule. Because I'm happy to announce to absolutely everyone in the room that we are starting a brand new company at Black Hills Information Security. It's going to be five times more effective than your current app, the detection technologies. We're going to be five times more effective. effective than your horse-based IPS or your antivirus. We're going to be that

effective. What I'm going to do, and by the way, what I'm going to do, and by the way, you guys are here at the ground floor. You guys can invest in this. It's agentless. I don't need an agent. I do not need to get anywhere on your networks. Periodically call you up out of the blue. Periodically call you up out of the blue.

You're compromised. I say, you're compromised. And you're going to say, you guys are here at the ground floor of unknown security, so just throw your money at me. It's funny when I do that bit. It's funny when I do that bit. And you're right. So you're right. So every year, Black Hills Information Security does this webcast called Sanity Cash. And we pick on the top antivirus vendors out there. We basically take a list of the top 15. And we buy what we have. And usually the conversation goes like this. I call up one of my testers. I'm like, hey, are you done with your secret cash? I'm like, hey, are you done with your secret cash? That's due tomorrow? I already started drinking. I'm like, well, we

need it for tomorrow. Give me five minutes. It's really been interesting over the past few years because we're seeing improvements in some areas and basically some areas just haven't gotten any better. For example, for a long time, some members of Endpoint Protection, we've reused the exact same technique like three years in a row. And we document these techniques and we walk through them with slides and videos showing people exactly how to do this. And there's a couple of reasons for us doing this. The first reason why we do this is, of course, it is marketing. But it's also kind of stuff. The real reason is a lot of our customers, a lot of our customers, CIOs, CTOs, if we bypass a security

product, they say, well, let's rip out Symantec and let's put it in Macintosh. That's not what we're trying to get at when we're breaking through organizations successfully and saying that they're security technologies. Instead, we need people to start understanding that computer security is about starting that computer security. It's about how our organization is set up. It's about how our organization is set up. The fence of death that we've been talking about. The fence of death that we've been talking about. The fields of view. The fields of view. It doesn't create a catastrophic across the entire organization. And all of this is available. I'll give you guys the URL in a little bit. But we have

AV bypass. I want to call out one specific vendor. This is kind of a weird conversation. So we got into it a little bit with Silance. Anybody here use Silance or looking to buy Silance? So here's a bunch of blogs. So here's a bunch of blogs. bypassing silence in four or five different ways. And none of them were all that difficult. And, alright, Black Hills Information Security out of South Dakota, there's no, that is spun in their favor. Like, well, this scrappy little startup is basically... So, we kept going at it. And then on day four, it was weird. Because somebody at silence released a video. I can't remember what the guy's name was. And he

basically was like, And he was like, you know, we're hearing silence. There are multiple ways to bypass. There are multiple ways to bypass. These rumors are unfounded. These rumors are unfounded. However, silence will be bypassed. And we silence will be bypassed. We're working with the security. We're working with the security to do better. Because we believe that you must be the change you wish to see in the world. Oh, my God, they just quoted Gandhi. God, they just quoted Gandhi. And then the next Monday they laid off, and then the next Monday they laid off, which actually happened. I'm sure I remember reading that. I'm sure I remember reading that. You must lay off your workforce. You must lay off your workforce. Maybe it was one

of his speeches that wasn't documented as well as the others. But they did this. And we released the last one where we actually were able to buy things on PowerShell. At this particular point, whenever we were bypassing silence, if you tried to invoke PowerShell.exe, it's like naughty, naughty. You can't run PowerShell. So how do we get around this? So how do we get around that? We just maintain the PowerShell to explore.exe. I rip on silence. The final thing that I talk about is a lot of these endpoint security products that are out there are light years better than traditional blackouts. The problem I had with silence is their marketing was ridiculous. We stop 100% of

threats, or we silence all attacks on your network, and it's total marketing garbage. Further, they were very, very mean security researchers for a very, very long time. In the States, they had their contracts in their space. They had their non-disclosure agreement that says if you have vulnerabilities in the product or you find things that you don't like about the product, you're not allowed to talk about those things. And in the States, we passed a lot of unfairness. We passed a lot of the Fairness Act of 2016 that retroactively voided all of those things. Every single one of them is void. Every single one of them is void. So you can go out and you can talk publicly about anything you want. about a product. And it doesn't make sense.

Could you imagine if you bought a car? And when you purchase this vehicle, you sign a contract with the vehicle, you sign a contract with the vehicle, you can't say anything about it. I think consumer reparative analysis would be busted overnight. There's no difference between that and computers. So that's why I was excited about getting sued. Which I think the lawyers are like, wait a minute. That guy seems really excited about getting sued. He's practically saying, in fact, I think he tweeted that out.

What do you think is going on? It's a trot. All right. It's a trot. But I want to close out the story with silence. But I want to close out the story with silence. And it's a really good story. And it's a weird thing. If you go to Silance's website, the language has been dialed back. They're no longer saying things like stop. They're no longer saying things like stop. It's unbelievable. It stops everything that our competitors don't attack. And they change their approach and how they work with security. I received this case from Silance. And I first made sure that it wasn't in case. I'm not blinking, ticking. I opened it up. And it was

filled with beer. And it was filled with this brewery called Lost Ashes. And they open it up, and it says from the sidelines team, thank you very much for keeping us honest and keeping the security team moving in the right direction. And we opened up a dialogue with them. And we opened up a dialogue with them, talking about what things were working for us, and they were giving us feedback back and forth. It was a good conversation, and no lawyers were involved. And that was improvement. And the point we should take is we can hold our vendors accountable. And they only get better if we hold our vendors. And silence is definitely. However, after this whole thing, I started looking at the beer and the names of the

beer. And they were like, righteous bastard ale, retribution, hard cider. But this is a happy story because we're seeing a vendor that's doing things right. So ultimately, what I'm coming at with all of this is a lot of traditional security technologies that we have ultimately in the Independent point security technologies. Can and will be viable. There's no silver bullet and there never will be a silver bullet. And a lot of times they talk about automating. This is the equivalent of automating the equivalent of automating a hunting. Spam in a can is not hunting. Like you don't come home with your friends, crack open a beer and say, I remember when I got the It's Fork-tastic spam. Here I was, it was early morning, here I was, it

was early morning, here I was, had my shopping cart at the ready, saw the can, it was right there, saw the can, it was right there. I went over it, I went over it. No, it's not, it's not, and if we're relying on automated solutions to do all of this for us, we are going to fail. So I'm going to focus on detecting difficulties to identify command and control channels. After an adversary has gained access to your network, and they establish a And they establish command and control as they're communicating outbound from the organization. And I'm just using this as one example. And I'm just using this as one of the other examples. But this

is the first one that I want to talk about right now. There's a number of beacons, like HBP, social media, DNS, and SETP. and protocols that are very, very difficult for organizations to tap. And we can use artificial intelligence. Now, I understand that as soon as I say artificial intelligence, as soon as I mention artificial intelligence, how many of you think it's not artificial? Stick with me. All right. All right. Stick with me. All right. We're going to do this. I'm going to talk about artificial intelligence, and you guys will get it by the time we're done. Fair? By the time we're done. Fair? Because I hate it when you talk to vendors about artificial intelligence, and they say things like, well, that's magic. It's fine. So

we have the smartest people in the world working on it. So I'm going to talk about one particular algorithm. We're going to discuss K-means. And I would like to share that with you. And it's just one algorithm. And it's just one algorithm. And I honestly think that it's pretty much solved. Look at it. I know, I know, I know. Now let's talk about Egan vector values. So how exactly does this work? Well, one of the things we can do is we can start with Plato. And Plato was obsessed with an idea of understanding forms. More importantly, trying to understand how human beings understood that forms, existed that forms. So with Plato, he had a question. As a human being, how do

we know this is a chair?

Experience, could you elaborate a little bit? You've used a chair. How do you identify what the properties are? You can sit on it. Would a log be a chair? Log. So the railing's out front. So the railing's out front. Can I sit on those and call those chairs? If you want. If you want. But honestly, what happens as a human being is, and believe it or not, Plato was actually a computer scientist. When we look at human beings, we have attributes. I heard somebody say attributes. I can't hear somebody say attributes. That's absolutely right. We tend to group clusters of attributes for definitions. Whenever we look at this, it has... When we look at this, it has four legs. We can say, well, it has four

legs. We can say it has four legs. Most of the chairs that I've seen are off that specific level. Most of them have four legs. But we create these clusters of attributes that starts weighting that definition on how we identify fairness. And it also means that if it doesn't match an absolute form of what we expect the chair to be, it's flexible enough for us to understand. This is actually a computer science. This is actually If you run a whole bunch of pictures through an algorithm, say I want you to look at every single one of these pictures, you have to identify attributes of the chance to be able to work with that. So stick

with me. So stick with me. All right, so let's talk about how this works. So let's talk about how this works with computer security detecting organizations, just as an example. So what we're going to do is we're going to identify chance for So if we look at intervals, interval against count-bound speed, is that interval consistent? Is that interval fast? And that heartbeat can be fast? Consistent. 5 seconds, 10 seconds, 15 seconds, 22 seconds, 13 seconds, 22 seconds, 1.98 seconds. As long as it's consistent and it's heartbeat and it's interval, then we have a bit of consistency. Now the clustering is important. Now the clustering is exact. Because if you look at any beacon that exists, let's say a 5 second beacon, by the time you

see that 5 second beacon, it goes through switches, goes through routers, goes through routers, it's always going to be an absolute perfect. There's going to be slight variations. But there is going to be a cluster. And k-means clustering helps you identify those clusters. And the tighter those clusters are, the closer they are to one. It also means this is resilient by a connection between two systems. And 100 of those connections are perfect five seconds. And one of those connections is 24 hours later. That one becomes an hour, but we still have it. Is everyone with me? Is everyone with me? Very, very cool.

try to identify is not good enough. Because bad guys can vary. They can introduce jitters. So what is data size? Every time a backdoor beacons out, the control server, the vast majority of backdoors, the vast majority of backdoors. Let me give you an example. How many of you guys have children? How many of you guys have children moving into the team on something? Mom! Mom! Mom! Mom! Mom! Mom! Mom! Mom! Mom! Mom! That is consistent in data size and data size and interval. You may have a change in the interval. Randomizing the interval. However, the data size is the same. That makes sense to everybody. Very good. The next thing we have is dispersion. Dispersion is interesting whenever you're trying to detect

backdoors because a lot of modern backdoors out there are like Trevor's Shell Empire. You can implement things like that. You can say, I want you to communicate every 10 seconds. I want you to jitter plus or minus 2 seconds on either side. And that's based on design. But it's beautiful. Anytime anybody uses a computer program to generate randomness, we have to actually call it one. We have to actually call it pseudo-random. It's 50% of the connections are less than 10 seconds, and 50% of the connections are greater than 10 seconds. So there's a bunch of ways. There's a bunch of ways that you can identify behavior in an organization. So I'm going to be talking about a tool called reading.

Real intelligence. This tool is free. This tool is used for mathematical algorithms that I was just talking about. It absolutely has zero dollars. Is that fair? And if I told you how much money I have, if I told you how much money I have, I'd smile politely and start moving my face. The reason why we created human control traffic is we didn't have any products. We had a bunch of backdoors that were on a bunch of backdoors. We wanted to create

and a customer said, so how does a backdoor that's using G-Band here is a tool that actually has? I'll show you that here in a second. So we need to set it up. So we need to print that for analysis and then read it. It takes out bro logs and it answers bro logs. We usually do 24-hour G-Band. It's interesting as the stuff I just showed you is really CPU intensive. We run once a day and it takes about seven hours. And the reason why is it's looking at every single action and every single ROI. from every single system going out to the internet and then going out to the internet and doing all of those things and basically finding the base of

the code and finding the speed. It's fantastic. It has an amazing user base. It has lots of support. It has lots of maintenance. It's just awesome. Anybody here use Q's fantastic? It allows you to filter through the broad data to bring up the things that are interesting. And also, like I said, it is from... So I've got a front end. We've created a front end.

So the first backdoor I want to talk about is a backdoor that was created to demonstrate that it beacons once every 10 or 40 seconds. Traditional security technology. If you set up a beacon in between like 30 seconds, 40 seconds, many intrusion detection interventions will not successfully detect that backdoor. The backdoor to establish a connection and to keep that connection established per day. It also beacons and clear texts HTTP specifically. It beacons and clear texts HTTP. So you're talking about a random field. So you're talking about a random field. Can you actually write a signature field? on your security tool. And most organizations don't. So with this tool, I want to show you what it

looks like whenever it actually fires up. So I'm going to open up the data set. I lost my connection. All right. This is what VSH looks like visually. Now, do you see any consistent patterns here? So right here along the bottom, these are the connections over time. the number of connections that happen within that. I can also change the resolution. You'll see a consistent pattern showing up again. This here is the interval in between connections. You can see that there was about 8 seconds, or sorry, 10 seconds. So we can find out very quickly We have very, very consistent pattern and connection. And we can actually see that the interval is 10 seconds. The interval is 10 seconds. Between these two systems. So we've got to be

able to identify. So we've got to be able to identify. Also, let me zoom in here. Let me zoom in here. It also does the scoring on it. It also does the scoring on it. And also statistical skew. And also statistical skew. And skew is something that we've thrown in there. And skew is something that we've thrown in there. haven't quite figured out how to use it. And the closer a backdoor is to a one value, of having a perfect beacon, of having it be 100%. So the dispersion is perfectly level. The skew is 100%. It means if you're looking at the bell curve, it's perfectly balanced on each side. It doesn't skew one way

or the other. It doesn't skew one way or the other. make the connection. How long is that connection? How long is that connection? That would be the equivalence of, once again, talking about your kids. If your kids want something. Dad! No. That's the duration of the conversation. That's the duration of the conversation. So another interesting way that we can quickly identify whether or not we have an interesting being. We can also look at data size as well. And if you see a very, very strong indicator of data size, that we have about 500 to we have about 9,000 So that's another good indication that they actually have the backdoor. So that's how you can detect

something like a BS agent. Next one is DNS cut. Is anyone here played with DNS backdoors? They're kind of spooky, aren't they? They're kind of spooky, aren't they? Like, really spooky. And a lot of security tools don't detect DNS backdoors. And in this situation on this slide, if you look, this DNS backdoor is communicating media address 8.8.8.8. These are raw robots. These are raw robots. Now, what is 8.8.8.8? Google. You guys want to know a dirty little secret? You guys want to know a dirty little secret in the security community? Your security appliances pretty much ignore anything that goes to Google. Just completely discards it completely.

Because they're trusted, right? Because they're trusted, right? Google is a command and control. I'll show you that here in just a second. I'll show you that. Now, what we discovered is that DNS backdoors, that DNS backdoors, make outstanding backdoors. Because most organizations are looking at that backdoor. Because most organizations assume that it's not evil, and they let it leave their environment. I want you guys, however, to stick with... See that we have a domain here? I'm going to zoom in on it. So we have cat.nanobotninjas.com. This is the domain that we set up for our DNS control. It's using DNS. It's working for those of you that don't know. If you remember back in the 80s, if you wanted to look up a

number, you would go to a phone book, look up the name of the business, it would give you the number, and you would dial it. Computers work in very much the same way. They don't understand Yahoo.com. So they have to convert that into a number. DNS servers support the recursively used alternative name servers. If you have something like www.google.com, your DNS server will hash that. So if you ask the same question a hundred times, it's the same way that you learn to ask apps. If I randomize every single time that we actually have randomized subdomains, the forces of every single time are required to have all of these subdomains, and that's to make the complete DNS server, not the NS server,

not the nanobot. So what we're doing is we're balancing our command to get our command in control, to get our command in control. This is a very, very difficult, very difficult for many organizations to detect. Some will actually try to write specific signatures for it, but at the same time, it won't work that well, especially if they're working. So if we look at TNS-CAT, we can actually identify that. We can actually identify the view. So you would expect there to be 2,232,000 Google.yahoo.com. You would expect thousands and thousands of domains and thousands of Why The reason why Google is like a DNS server is if you're an organization, if people are using Google DNS instead of going through your approved DNS, you

need to look at that. That's either A, somebody who's probably a little more crafty than they should be, or B, it's a backdoor. And if somebody's being crafty, try to be in your own organization. Really, really interesting. We're connecting to a DNS server, and we have this many bytes transferred, this many bytes all connected IP addresses, all the connected IP addresses, and then you can run seven blacklists on the internet and see if you have better connecting systems to the internet, to known blacklists. And here you have one of those blacklists, and here you have one of those thousands of bytes of traffic that you do not. This is also key because when you're looking for somebody who's going to block this site, you're going

to have tons of sites that happen to go to all the sites. have systems that will connect once or twice or maybe three times. Why would that be online? Ads. So those onesie-twosie connections, those data transfer connections, not that data tree. All of a sudden you have a tremendous amount of database on your website. That means that you need to invest a lot more. All right. So now, one of the things I recommend before you start hunting, you can do this in a number of different ways in your web field. You can go to categories, you can go to advertising, you can block advertising. The vast majority of time that I worked was basically sifting through advertising by clearing them out, basically researching

them. If you can filter advertising, it's so much easier because it reduces the signal-to-noise ratio to something that's effective. Be careful with this. This is insane. This is insane. I've had two customers, I've had two customers where we'd said, damn, watch this. All of our infections come from ads. Let's block them. Let's block them. And then someone in marketing goes to a website. They notice their ad. They say, hey, the advertisement for our company didn't load on this website. Why is that? Well, we block ads because they're evil. We need to allow our ads. We've got to show good corporates. We've got to show good corporates. We're getting ads on. And then they turn the ads on

because they want to show good corporates. So be careful. They can absolutely beat you. The other thing that we've been discovering is RoundRob and malware. We've had a number of instances over the past 12 months where malware doesn't connect with specific guys. Instead, if RoundRob is like 5 or 6, it's like 5 or 6. This is actually an incident that we worked with. It might have made an incident. I'm not sure. But there were video cameras that they And the video cameras were connecting IP addresses back in China. And they were round robbing. Remember I talked about dispersion? If you start finding consistency in dispersion and data size between multiple IP addresses, then you're looking at something like SC, where

you're looking at some malware. And this was another one. Now, the next one is probably my own. So we had a customer. And we were looking at their data. And they were looking at their data every single day. Every single day. And that came out my IP address that was like 9.8.15. Now that IP was actually reserved for the United States exact same IP address. So we went to the customer with the question. And we sat and we looked at it and we were like, "The data." So we started looking at the data. And Marshall Bear incident response. And they sat down and they started doing analysis. Sure enough, all of their systems were in fact, all of their systems were

in fact. Yes, it was an ID address. And immediately, like, it's the NSA. The NSA is hacking us. We know the NSA is hacking us. We have proof. We have proof. The NSA hacked us. I used to do cyber offensive operations. Never once in my entire career did we say, we need our command and control service. We need our command and control service. That's like a good idea. That seems like a good idea. That's ridiculous. It doesn't work that way. But we did have some legitimate concerns. We were afraid that maybe there was another shadow where some tools were released that made schools more easy to use. That's the only part of it. When we

sat down and looked at the system, one of the core programs actually made use of this. So we sat down with one of the developers and we said, look, we need you to reverse engineer this. We need you to reverse engineer this. How do we do that? I'm like, great. Looking at this while I'm firing up, looking at this while I'm piloting, And the IP address is 9.8.9.8.9.8.9.8.9.8.9.8.9.8.9.8.9.8.9.8.9.8.9.8.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9.9

The lesson for this is you can take on data, and this is one of the keys. If you ever have a vendor that says, automate all of this for you, your network does all the times. It just does, folks. And it requires you to be interactive with your data. I get into arguments with vendors. Somebody called me. According to our algorithm, you can basically identify all evil traffic by all the Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you

be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you

be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you

be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be on your own? Shouldn't you be active, engaged, on our networks. You're going to see things like syslog. You're going to see things like syslog. Somebody checked, yeah, share my telemetry with the vendor. Every time you use the product, every time you're constantly sending everything you're doing to the vendor over syslog, clear text on the internet, customer experience data, direct software updates, Microsoft generates tremendous amounts of traffic. It looks exactly like beat. Because it's mothership and checking mother software. You've got to be able to filter that. And you've got to be able to filter that as

well. And it gets easier. Remember the first time we ever did a video? We fired up Nessus and scanned it. We fired up Nessus and scanned it. And we're like, all right, what are we going to do here? All right, what are we going to do here? And you're like, burn it down. There are so many times when I'm doing it on a team. And I'm like, look, I have all these users going to their accounts, blacklisted sites. It's bad. It's real bad. It doesn't make that real bad. It's like a blacklist. So on the topic of blacklisting, you will see a lot of your systems that are connecting to you. websites and IP addresses and a couple of hints on how to look at it. It is very

common for a system to go to an IP address that was only on one line. And also because of virtual hosts, you're going to see multiple websites that are legitimate, posted on a legitimate, the same IP address that is an evil IP address. And this requires some level of research. That's why the DNS data is so incredibly key. We do absolutely everything. Also, the amount of data that should be transferred. Or will be transferred. You see a large amount of data being transferred to a blacklisted IP address. It's time to start panicking and investigating what's going on. Digging in a little deeper. You can't get through this entire presentation without a note of porn. This is the system that was connecting back to a triple X dot net

porn. Or at least attempts on a network. It's I don't know if you guys are getting a little bit jaded. A little bit on me getting jaded. I've been doing this now for 18 years. And I started working from home about 10 years ago. And we started Black Hills Informations. I was working a gig where there was a county employee. And he was serving porn at work. And no surprise. And how he was surfing for was interesting. He was going to Wikipedia and using Wikipedia as his main pornography. So if you go to Wikipedia and you put in vagina, it's like, oh, wow, that's a trip to vagina. And he was using that as porn. If you're wondering if you've hit rock bottom, going

to Wikipedia and searching for vagina is equivalent to drinking a cigarette. It's like that sipping of that beer on the sidewalk seemed like a good idea. So I had to show the pictures of the report. I got into a conversation with a customer about censorship. I gave them the actual pictures of the report. Oh, my God. There's naked people. Why did you hire me? Yes. Why did you hire me? Yes. And they wanted me to come up with the right size bars. And they wanted me to come up with the right size bars. And my wife walks in. And my wife walks in. And I have these big screens. And I have all the pictures. And she comes in. She's got a couple suits. She comes in.

She's got a couple suits. Oh, they're working. Oh, they're working. She sets the suit down and she's like, I'm going to lock the door. I'm going to lock the door. I'll be down in like five minutes. I've gotten to the point in my career, if my wife walks in and there's porn on my screen, she assumes it's work. She assumes it's work. What I also find interesting is how many of you, when you're working from home, like late at night, like 9 o'clock, you actually hide from your significant other. Like they walk in and they're like, what are you doing? What? I'll get in more trouble for having porn on a stream. You also see a number of situations where sites go bad. There's a bunch

of different domain tricks, domain fronting, domain tricks, domain fronting. And we've seen a lot of things like hospital.org, a hospital got filtered out a little bit. And it just goes to sites that have all kinds of strange ports that are all kinds of strange and weird traffic. Spyware is strange. This is actually recent. I think I have it somewhere. So this is January. This is a hunt that I was working on. And I saw this. What is it? REVSCI.net. One of their internal systems. What the hell? That seems really familiar. I couldn't put my finger on it. It's basically tracking software that goes in your browser. 2007. 2007. This system had tracking and spyware over a

decade. And whenever they investigated, it was a Windows XP system. How many of you guys have those floating around? So I was shocked by that. It's not quite malware, but it's very, very strange. I get excited when I see things that are strange. So compromise servers, I want to show you what I want to show you. I want to show you what I want to show you. Just so you know, I do jump on cloud-based host. If I see something's connecting out to the internet, I will jump on the cloud host. I will download some other jakey or weird, some cloud provider. And I'll run scans and look at that server and figure out what

it is. And this is what a lot of compromise third party works for. This is that hot content. You have your standard 50, 80, and 440. like Infraware RADSAT, but then you get into this 2222, that's weird, like Sans 504, we used 2222, all of the time, that was actually the worst, and then also the MySQL database was exposed to the Y database, you could actually try to authenticate to actually try to authenticate, which is funny, because we used Mongo, compromised website, no, I did not actually server. It's basically just a scan and identify services. Crypto mining, I want to pull up and just kind of say, for one simple reason, it's awesome. We went from ransomware,

where computers would get compromised, they basically locked the system down, it was an idiot, and people, it's kind of fun, but security improved a lot over the past few years because of ransomware. Because how do people learn the frying pan? Because how do people learn the frying pan? Touch it. And executives, they click on something that has ransomware, click on something that has ransomware, and they're like, we need to invest more money in computer security. Why? It's immediate. It's visceral. And we saw this huge jump. Ransomware doesn't do that. That's why crypto mining doesn't do that. It basically just sits in the browser. It basically just sits in the browser. It's Ethereum or Narrow or

BitNarrow or something. But it just simply runs, it just simply runs. And they'll sit there for weeks and weeks. We are not seeing tons of crypto mining showing up in organizations today. What's weird is when I go to customers, I'm like, hey, you have about 15 that are connecting into this server. Go to the server, go to 8084, go to the server, go to 8084. It gives you all the IP addresses, gives you all the IP addresses, utilization, each of those systems. They're like, oh, we don't think, yeah, it's fine. As long as they're in Seattle. exactly what I want so I'm warning you right now for going back now we're going back there's a lot of

improvements and have those immediate feedbacks, that's going to change things. Another resource, IP URL void. It's not necessarily a great website. But if something does show up, you can actually go to the individual block list and get additional data. Also, has anyone seen what they've been doing with Luxembourg, with ASN ranking? All right, so ASN ranking. I want you like zip codes and postal codes for sending letters. You have different areas of responsibility that the internet service provides. And those zip codes or those postal codes, those can be good neighborhoods and they can be bad neighborhoods. So in Luxembourg, they've gone through and they've taken all the different ASN numbers and basically the entire internet has broken down. I'm going to tell you what is the ranking

of those ASN numbers. Are there a number of IP addresses that are on known blacklists within that So this is really, really cool. You have an IP address and it's in a specific ASN. You can go to this website and you can check to see if this ASN is a bad one. Shodan is just awesome. It's not just for pen testing and breaking into the computer system, but if you're trying to research an IP address and you don't want to touch it and you don't want to show it to it, Shodan will a lot of times have an index for all of that website's services so you can see what's actually running there so you

don't have to actually touch it. You guys remember I'm like spider from a number of years ago. Have you seen it recently? Have you seen it recently? So, oh, so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh

so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh so oh, so, oh, so, oh, so, oh, so, oh, so, oh, so, In addition to

looking for web vulnerability, we're doing full Nmap scanning. We're doing full Nmap scripting engines, Nmap services, product engines. And you can also break it down by context. So Punks fighter is big. So ultimately, kind of wrap this up. When you got started in computer security, what did you think it was going to be? Right here. You thought that you would get the opportunity to fight attackers firewall with JavaScript. This is really the most inefficient way to hack. We've tried it multiple times. We've tried it multiple times. And it just does not work at all. Computer security is meant to be interactive. We were going to be hunting the bad guys. We were going to be hunting the habitants. We were going to be

hunting the hackers. And instead what we got was certification accreditation. Instead what we got was They said what we got was a tremendous amount of vendors trying to sell us on a single pane of glass. Here's one product, and you look at this one product, and you look at this one status of your entire organization, and almost every organization we test that has that single pane of glass, their security architecture is poor. The organizations that were terrorized are the ones that have active programs going on. So, we're right on time. Detecting command and control traffic is harder. And I want to share with you one last fact. And this was a surprise to all of us. We had this backdoor

that we created called GCAT does all of its command and control over Gmail. So, it's sending and receiving email messages back and forth to itself. And I think that this last one... The last one. Internet connection is down. Tech was able to actually detect Gmail backdoor. Gmail backdoor. And that was absolutely massive for us when we found that. And that was absolutely massive for us when we found that. So it's getting harder and harder to detect. It's getting harder. We have another tool called Sneaky Creepers. It does all this command and control over Salesforce. It does it over Google Sheets. And we're using these services that you guys use every single day. And we're still detected if you're doing that type of

tactic. Rita costs nothing. We give it away for her. We give it away for her. So please get a chance to play with it. Please get a chance to play with it. Get it installed. We've got the Git repository. And I'd like to hand it over to you guys. Do you guys have any questions for the last 10 minutes? What? Can I send them to the conference? Can I send them to the conference? Can I send them to the attendees? Is that okay? Cool. All right. I got them. Yes. There's a couple of different ways that you can do that. use the Cisco umbrella, or you can use OpenDNS, which is also open DNS. You can also use PyHub, which is very,

very cool. The easiest way, though, is in your outbound web proxy point or whatever, or it's point, go into its categories, and you can click categories, and it won't shut down 100%, but it'll shut down a good 85%, and that's what we're looking for is cleaning up. So there's a bunch of possibilities. So there's a bunch of

No, you're not looking at every endpoint. We're looking at every endpoint. Oh, okay. With 10,000 boxes, you would want to have multiple terabytes of SSD. It runs in Mongo. It uses Golang as a language because it's multi-threaded, which is fantastic. It does fantastic when you're pulling all of that data and you're running it right at the directory of the world. When your logs are and pull it off of that. Right now we're in a learning process with Redux. We do have a product, and we do talk about that offline, but trying to get that set up in organizations is very organizations. It's a big need to start using grow and doing this analysis. But you do need to do it. Thankfully, today, hardware is

cheap. You're talking about less than $5,000 for a client that can run it and just do a fantastic job. Another question. Yes, sir. Another question. Yes. I love that. That's beautiful. He just said create a separate policy for your marketing team so they can see the ads but no one else can. In fact, you could go so far as make it so every single website they go to has your ad. It's like, man, this ad grew. Any other questions? Any other questions? Yes, sir.

Are there other IP addresses that you should be aware of? We actually have backdoors that will use Office 365, Dropbox, a drop tool that was created by Malware Jake called Dropkick. I can't remember. He released it at Black Hat. He released that as well. And that gets into why it's difficult. A general user using a lot of resources, it doesn't generate a really strong... Let me explain why. So if you go to Gmail, so if you go to your tasks, you have your calendar, you have your chat, you have your Those will all be syncing. Those will all be syncing, right? I mean, job search, right? AJAX type activity. Where it's synced in an A-sync

sort of way. It doesn't create a really strong heart rate. Same thing with Dropbox. We see Dropbox syncing. The data size is going to be different. The interval is going to be different. If all of a sudden these things are being used for malware, the pattern moves from malware that's far more rigid. The only thing that we do see that's really, really rigid that shows up quite a bit is like updates. Microsoft and also some Microsoft tracking and Amazon tracking. Amazon cookies and Amazon cookies and Amazon are a nightmare. But you can filter all of that out. Rita has the capability. Rita has the capability. We can put those domains and we can put those domains. By IP address, by IP

address, and also by ASN. Also by ASN. Organization. Right. Any other questions? Go see the rest of the presentations, everybody. Go see the rest of the presentations, everybody. Good morning. Before you leave, we want to... prizes so do we have representatives from three teams? DC604 do we have cut off? We have the Islanders. Do we have a prize for the DC604 crew? With 2,000 points. Land Turtle from Hack 5 one of our sponsors. Elite Badge from 2015. No comment. No comment. And a $50 gift certificate. And a $50 gift certificate. Another sponsor. And lastly, if you were a professional ticket holder, we actually owe you a mug, so please go see the ladies up front,

and they'll give you the mug. They'll give you the mug. So go grab your cool hack mark, and we'll see you after the break. Thank you. Blah. Test, test, test, test. Test, test, test.

Test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test

test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test 1 1 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Talking some more. I'll start at about 10:30. I don't bite, so if you want to come to the front, I may be more entertaining from that vantage point. It's also shorter range for throwing the rotten fruit, so it's all good. Yeah, I got, okay, he's turning me back down, good. Or he

hasn't. Okay. That's fine, that's fine. Okay, that sounds good. Yeah, I caught most of John's talk and I caught a whole pile of talks yesterday. It was interesting. That's why I'm asking, oh, there we are. You can hear me in the back. Excellent. Although I'm told I have a voice that carries anyway, so I can probably project to the back of the room. Anyway, I'm Bob Fruth. I'm going to talk about what you do with threat modeling results. And please stop me if you have questions. I'll try and answer them as we go along, or I may postpone the question to the end. Standard disclaimer, these are my opinions, not the opinion of any current, former, or future employers. Although certainly some

of those employers' experiences, or some of the experiences I've had with those employers have certainly influenced what I'm going to talk about today. I'm going to talk a little bit about threat modeling, talk about some best practices for creating an effective threat model, talk about managing the details. You've created a threat model, so how do you manage what comes out of that, what the results of the threat modeling were? We'll talk about assessing risk and then I've got the usual summary slides. Before I go further, who was in the room three years ago at B-Sides Vancouver for my talk on threat modeling? Excellent. Thank you. Welcome back. Obviously, I did something right that afternoon. The other question is how many of you have threat modeled or have read a

threat model? Okay, so about 30%. which tells me that next year I need to put an abstract in for threat modeling how to do it talk, which I've been told at a couple conferences would be useful. So who am I? You can read this and I'll describe a couple of the major things I think that are pertinent. One is that I spent six and a half years in trust with the computing at Microsoft, learned how to do security by doing it, was the Program Manager for the Microsoft Crypto Board for two and a half years, which was very entertaining, and wrote several SDL requirements. Now I'm at GE Healthcare working on medical records software where

I not only worry about security, but I worry about privacy and the fact that if our stuff screws up, the patient might die. So yeah, I don't sleep well at night sometimes. So what is a threat model? At its basic root, it's one or more data flow diagrams. a list of threats related to the elements of that data flow diagram, hopefully with some accompanying thoughtful analysis. The whole purpose of threat modeling is to do that analysis. And if you put together a threat model and the analysis is incomplete or not well thought out, it sticks out like a sore thumb. And then of course the whole point of threat modeling is to identify vulnerabilities and

then come up with mitigations to address those vulnerabilities, mitigations that address each of the threats. And finally supporting information, which is a beneficial side effect. You can summarize what the model is about. I read lots of threat models. If I see an empty summary dialogue, the threat model goes back and it's like, what am I looking at? Who wrote the threat model? Who reviewed it? The assumptions you've made, and there's some that are kind of implicit, which is if you're running on top of a platform such as Windows or Linux, you make assumptions about that platform, although certainly it's useful to call out particular aspects of the platform that are really germane to your threat

model, whether it's Active Directory or the crypto APIs work as expected. And finally, your dependencies. And I'll talk more about dependencies on a later slide. So here's a really high level diagram of a simple web server. At the left, you have the browser. I've extrapolated out the user, who is assumed to be to the left, because ultimately the user talking to the browser. I'm not threat modeling the browser. I'm threat modeling the web server, so I don't care as much about the user at this level. The browser talks to my web server over the internet. which is a trust boundary, rather important. Trust boundaries are where there's a level of trust. The internet by definition is a trust boundary. If you read a threat model and don't identify

the internet as a trust boundary, whomever, you should throw it back at the team or the person who wrote the threat model and say, what about the internet, it's not a trust boundary. Even if you're doing something, a tunnel over the internet, you still have that threat boundary. For some reason that went on ahead of itself. You're talking the web server. This is definitely a context diagram. So the web server is very much summarized as a single process bubble. Most web servers have multiple process bubbles and some data stores and probably some boundaries inside them because you generally don't put your database server directly on the internet. And if you do, I want your IP

address because I want to retire in Argentina. On the right-hand side is an administrator, an external interactor. And I have a trust boundary here which is administrative authentication and authorization. And in that simple trust boundary, I have extrapolated out the fact that there's an authentication and authorization step that my web server threat model is making. I'm assuming that away. Now, if I'm reviewing this Threat Model, I will ask to see the Threat Model talking just about off-Z and off-N. So, very high level. So, historical perspective, Threat Modeling had its origins in client-server enterprise software applications about 25 years ago, when people first started understanding that having a rich client and a database talking to each other over a network was kind of insecure if you threw more pieces in

play, like the internet. So, they put three tiers in, and the middle tier does all the work. In the late 90s, we had what I call the internet boom and bust cycle. We had lots of honeypots, I mean web servers. Blaster came along, Slammer, those of us who were working computer security at the time remember those days all too well. Microsoft in 2002 stopped development on Windows for what was scheduled to be four weeks and turned into closer to six to ten, and Threat Model to the operating system. And I was a part of that security push, which is when I can actually trace my getting bit by the security bug to that month. Office

sat across the campus from us and kind of watched and said, oh, we need to do this too. And so they followed not long after. Other software companies have threat modeled. And the practice now is extended to hardware and software in combination. So let's consider some examples. The couple of you who were here three years ago will probably recognize this example, but I've extrapolated out a couple pieces of it. Consider an ATM, which is a complex hardware and software device. Is an ATM secure? Well, the money is in a safe, kind of by design. The computer that spits out the money may or may not be in that safe. OK, that's kind of interesting. The connectivity of the ATM is not in the safe by design. That's

kind of its connectivity. If it's wireless or networked, there's probably a network port or Bluetooth or wireless or whatever. There may be a USB port on the ATM's motherboard. The keys to get inside these ATMs, typically, that's one of several-- a dozen or whatever. You can buy them on the internet. So they're always the same. The passcode is a default, which, of course, the manufacturer says change on first use. And the only question I have is, is it changed on a regular basis? Is it changed at all? Open question. Although if I'm servicing 300 ATMs, I can understand having 300 passwords in my head is probably not practical. Turns out that this particular example is

based on a talk that Barnaby Jack gave at Black Hat now eight years ago, where he found that some of these ATMs use bad crypto for checking for firmware update validity. He was able to install his own ATM software. Bad crypto leads to your own ATM software. The whole point of this is that threat modeling can be useful. This is a case where the assumption they made is that their crypto was good. In this particular case that Barnaby was able to exploit, it was pretty clear that their crypto wasn't. A threat model might have saved them. Now, as it turns out, of course, he gave this talk. And you can look on YouTube for Barnaby

Jack. It's a great demo. Absolutely stunning demo. Consider what I call the Internet of Ransomware things. I love this cartoon, but the point of putting this up here is here's a bunch of kitchen appliances, and of course it's all kind of humorous. I love the toaster talking about burning the toast or other sort of things. The point of this is if I'm putting these appliances in my house, I kind of like to know that the manufacturer threat modeled them and understands what network traffic is going into and out of my refrigerator. I don't have an Internet-connected fridge because I can tell when my eggs are rotten, thank you very much, and I don't need the fridge to tell Amazon to bring me more milk. Although truth be

told, my wife has gotten into these wireless controlled light switches, which is really great because we can set them when we leave the house and go on vacation and so forth, and I haven't asked about the threat model. Some other examples, my talk in 2015, I actually talked, I threat modeled a car as the example, The NCC group has produced an automotive threat modeling template, which I've looked at. It's pretty good if you are threat model, and if you work in the automotive industry or know anybody who does. Medical's coming. You know, there's an example of a notice. Two of my colleagues have written a medical device template for threat modeling. They're going to announce

it and talk about it at RSA. So if you're going to RSA, go tell Valeria and Jonathan I sent you. If you're not going to RSA, look for their talk afterwards. Toys, this is a couple years ago, but Talking Barbie was all the rage for US and Canadian Christmas holiday season one year because Barbie talks to your child, listens and talks. That's a great idea. And Barbie communicates over the internet to a server that actually does all the speech digitization and so forth. I don't think Mattel throttled model before that toy was produced. And finally, the last one on myself, you know, you can throttle model TSA. I know from personal experience, I don't recommend this when you're standing in line. My

long suffering wife looks at me and says, "Stop. Stop. Don't throttle model." So some best practices. When you're throttling modeling, it provides you with a really structured way of describing your product security. The data flow diagram is basically an architecture diagram that's special purpose. If you can't produce a data flow diagram that makes sense, chances are your architecture diagram is a rat's nest. And I would encourage you to stop development now and go figure out why the architecture is so convoluted. Because if the threat model is convoluted, it's probably an indication that the architecture needs some rework. You want to identify design problems early. You want to find those implementation gotchas. I love the crypto example from the ATM because that's an implementation gotcha.

That was an implementation flaw. Threat modeling gives you a way of analyzing and document everything you see listed here. The key is that you want to identify threats and vulnerability, your resources, your threats, vulnerabilities against those resources, threats against those resources, and test cases to validate the mitigations you put in place. And maybe also a test case to kind of make sure you understand the vulnerability properly. Have you scoped the threat model appropriately? The test case can help determine that. At the end of the day, it's all about knowing what your risk is. If you want a threat model early or often, we've all seen this chart, which I think first appeared in the mid-1970s, if not earlier. You know, it is cheaper to fix

a bug early in the cycle. In fact, every time I talk to a development engineer and they complain about test finding bugs late, the immediate thought I have is, why did you introduce the bug in the first place? All of us who work on products know that fixing a bug when the product is released in the field can be relatively easy. If it's something like Windows and you've got Microsoft Windows Update or Apple's Update or things like that, If it's a device or an automobile, it's a service call or a recall. And there are some types of products that you can't update once it ships. You want a threat model often. The threat model is just another design spec. If you change the design, you update the

design specs, you update the architecture diagram, and you revisit the threat model. It's pretty straightforward. The devil is in the details of actually doing that, but it's a pretty straightforward process.

You need to understand what you're modeling. I've already stated this basically, but you're maybe modeling a complete product, a feature in a product, a component of a product, a subsystem, some processes. The car threat model I talked about three years ago, I talked about the braking system, the entertainment system, and the question I asked, which I left unanswered in the threat model, was are they air gapped or separated? And three months later, two guys actually took over Jeep Cherokee on Interstate 70 outside of St. Louis, Missouri, took control of the entertainment system, took control of the steering system and the braking system, and brake the Jeep to the side of the road. And they got

criticized, of course, for endangering people because the vehicle was going 65 miles an hour, which is about 90 kilometers an hour or what have you. At the time that they took control of it, they were very sure of what they were doing. And 10 days later, Jeep issued a recall. You need to set expectations properly. Define threats you can't address. One of the speakers yesterday talked about administrators and administrative safeguards. You need to decide how much you're going to protect against evil administrators. At some level, you have to trust the humans who are running your product or maintaining it or deploying it or updating it or configuring it to be honest and truthful and ethical. If they're not all of those things, there's not a lot-- there

are things you can do, but you can't mitigate that one completely. Physical possession is an interesting question. 15 years ago, the understanding was if you had physical possession of a device, you owned the device. Now, we didn't have as many internet of things then. Smartphones were in their infancy. Now we have computers in our pockets that have more computing power in our pockets now than a whole room full of computers had 30 years ago. Now with encrypted TPMs, encryption and TPMs and things like that, the whole physical possession question is a real open question. My laptop, for example, has a TPM chip. If I hibernate it, the hard disk is encrypted, and it takes a passcode to get back into it. So there is some mitigation there

against somebody actually getting onto my computer and doing something with it. You need to get the diagram right first. I've looked at a number of threat models over the years where the diagram changed a lot as the threat analysis was happening. And the problem with this is that you end up with the same result, but it's a lot more difficult to work through an analysis if you change the diagram five times. If you have the diagram absolutely spot on up front, the analysis then is straightforward. You need to remember what you're protecting. Customer data. That's kind of interesting stuff. Secrets. I work in medical software. We talk about patient data all the time, which gets into the third bullet, which is privacy. Patient data, those conversations

are really short. We need to encrypt this data. Why? Patient data. Right. Done. There, I've just threat modeled and mitigated a whole series of threats in one sentence. Availability of the product is very important. Is it responsive? Is it performing? If you think about the web server, if that web server happens to be Amazon.com, Amazon's entire primary business model is built on Amazon.com being available 24/7, 365, so you can spend your money. Availability is their top concern for that particular set of servers. And I say set of servers, it's probably several buildings or data centers full of servers. I also want to consider reliability and integrity of the device or the system or the thing. Medical devices are assumed to work properly and provide good results. If the

x-ray machine provides a bogus x-ray, that's a bad thing. If the x-ray machine malforms because of a software bug and gives the patient a lethal dose of radiation, that's an entirely different set of threats, and boy, you want to make sure you mitigate that one before you ship that machine out the door. Okay, so we've talked about threats, so let's talk about mitigations. First and foremost, when you put a mitigation down, when you list it, make sure it actually addresses the threat. HTTPS, SSL, TLS are great mitigations for web traffic, but they don't address spoofing. They address confidentiality and integrity of the data, but you can still send bogus traffic over a secure connection. There are

four ways to reduce or eliminate your threat risk. The easiest is to redesign the product or the feature or whatever it is you're threat modeling, which is why if you threat model early, you find that that's easier to do. You can apply the standard mitigations. I happen to like SSLs or TLSs as a mitigation because it's easy. Everybody knows how to use it. If TLS breaks, it's a bigger issue than any individual product. If you think about SSLv3 and Poodle or OpenSSL and Heartbleed, that's a pretty big issue. But it's a bigger issue than any individual product. Why the standard mitigations? What are similar things done? Security practitioners all borrow from each other. To be honest, I use Wikipedia all the time because I can't keep

everything in my head. But Wikipedia generally is accurate and it's the collective wisdom of all of us. and all of us meaning a broader set of people than the people in this room. You can invent new mitigations, which is always-- it takes a fair amount of creativity, always an interesting thing to do. You may need some specific skills. And if you're working at a company, you may end up with some nice patent-- having a conversation with your company's patent lawyers, which I can tell you is both rewarding and tedious. From personal experience, I can tell you it's rewarding and tedious. It's tedious because you go through everything to the nth degree. You're talking to legal

people who have no idea what you're describing technically. They're turning it into something that can be filed. And then several years later, you get a nice little piece of paper that says, oh, congratulations. Or you can accept the vulnerability in design. The Threat Model will help you assess the risk of doing so. If you're going to accept the vulnerability in design, you want to discuss it with your engineering team, your product team, your management, the customer. The customer may look at that and go, yeah, we don't care about that. Once you've described the risk and the vulnerability in language that they can understand. On the other hand, they may look at it and go, no,

we can't accept that risk with your product. We will go with your competitor's product, in which case you have an answer about whether you need to, you know, you've answered the question, do I accept that vulnerability? The bottom line with accepting vulnerabilities is assessing the risk and making an informed decision.

So I talked about dependencies. Threat modeling will help you understand those dependencies because you'll list everything that you're dependent on. The platform. If you're on Windows and using authorization authentication, you may be using Active Directory. You can make assumptions about Active Directory that are fairly valid, but you need to list it as a dependency. You may not have control over how those dependencies are used. Now, if you're directly including a third party library, generally you can control how it's used, but you need to understand what properties of that library you're depending on. And then you make assumptions and you validate those assumptions. I've had people say, oh, I don't have to worry about the component

because it's a third party component. No, if you depend on it, it's part of your threat model. You have to consider the issues in that component and how they might affect your threat model and how they might affect your product. And here are a couple notable examples. Heartbleed was an implementation bug in a version of OpenSSL, what, three, four years ago now. I use that as an example because the internet went crazy for about two days. Heartbleed to me is a real example of a decent vulnerability with a great marketing campaign and a really cute logo. Apache Struts is an interesting question because of Equifax, which affected a lot of us in the United States, and I understand affected a number of Canadians as well. The root cause of

the Equifax breach was that they hadn't updated Struts for an issue that was patched last March. And then the former CEO of Equifax tried to blame Apache for it, and he got called out pretty quickly, and then his board asked him to find other employment. My point of these examples is if you know that you're using Struts as part of your product or part of your service or you're deploying it in your network, You have a dependency on it. And if Apache puts out an update to struts, you probably want to update your deployment of it. Patching is not rocket science. It's difficult, and it's time consuming, and it's tedious, and it's potentially disruptive, but it's not rocket science. You don't get patent applications for

patching. You do get notorious notoriety if you don't patch, see Equifax. Then you want to review your threat model and review it again and again. Because ultimately, threat modeling is a group exercise. You may have a single person on the team or a single person in the IT group that is doing the threat model, but somebody else is looking at their work. At GE, when I do a threat model review, I tend to include all the teams that might be affected by the particular thing in question. I'm a reviewer as well, so I'm one of the stakeholders that reviews it. If there are dependencies that I can get that the threat model uses, or the component or feature that the threat model is using, if I can

bring those dependency owners in, I do. Obviously, with, say, something like OpenSSL or Struts, you can't unless you work at Apache or you're at Google and you have your own version of OpenSSL. But you try and pull those people in. If you are writing something that other people are going to use, Have the owners of those things participate in your threat model review. You're going to validate the assumptions you're making on them. And they're going to validate the assumptions they're making on you. And if you're able to do that in a collective group exercise, that's a really powerful thing. Because at the end of the day, you end up with a threat model. And everybody

kind of looks at it and says, yes, we think this is accurate, nods their heads. Yes, we have three work items to go fix some vulnerabilities, address vulnerabilities, build mitigations, and so forth. That's a great result. If you write a threat model and nobody reviews it, what was the point? Well, maybe you got something out of it because you understand your risk and you understand vulnerabilities in your product or service or IT environment or car or medical device or what have you, but you really want to pull other people in. So the devil of threat modeling is with anything we do is in the details. You end up having three primary results of threat modeling.

You've implemented some mitigations. You need to have test cases to verify that those mitigations actually mitigate the threats in question. And yeah, the test cases can be really simple. Is TLS turned on by default? And if the answer isn't yes, I have some doubts about the product. If you have a mitigation that's not implemented yet, that's a fine thing. You've just identified a development work item. Or if you're an IT shop, you've identified a work item for closing a hole in your IT deployment. Oh, by the way, you have test cases on that too. Because when you build new features or change things in your environment, you need to verify that they actually work. If you don't mitigate the threat, it's a vulnerability. And it becomes a bug, which

I'll talk about in a few slides. So the devil's in the details. So how do you track the details? Use the tools at hand. If you have a bug tracking system, use it. Vulnerabilities are bugs. Put the bug in the database. Do an initial severity and priority assessment. Send it off to the developer or the person who's responsible for fixing it. If it's a critical, it's a pri 1 or a pri 0, depending what scale you're using. Or it's a pri 5 if you're using the opposite scale. If it's an informational bug, yeah, it's a lower severity, lower priority. Doesn't mean you don't want to file it. Some examples I've provided. The Threat Modeling Tool

from Microsoft, full disclosure, I love this tool. People have complained that it's too Windows centric. That's changed over the years. There now is an Azure template for it because guess what, Microsoft has Azure and they kind of want to push Azure services. I've Threat Modeled a car with it. There's a template for Threat Modeling cars. There's a template for Threat Modeling medical devices with the Threat Modeling tools. Anyway, enough pitch for it. The reason I mention it here is that it enables direct copy and paste of Threat Modeling results into a bug. And you can export your throttling results into a CSV file, which many tracking systems can import. Now, you may have a little

cleanup to do, but the bottom line is if you've got output from throttling, there's a way to get it into Rally or TFS or BugTracker or what have you, or into a spreadsheet if that's what you're using. Question, for which? I haven't looked for one. I wouldn't be surprised if there's one out there somewhere. It may or may not. I mean, look on GitHub, for example. That's where the NCC group posted theirs. And I have a link to that later on in the resources. I suspect there probably is a template somewhere for AWS, although I can imagine Amazon probably not, they may or may not want to publicize that, but there's enough ex-Microsofties at Amazon,

I know a bunch of them, that I'm sure they're using the tool or something similar. When I first joined GE, actually, slight tangent, We got pushback because, oh, it's a Microsoft Windows tool. And my comment was, if you find a better threat modeling tool, I want to know about it now. There are a couple of other commercially available tools that my group and I have looked at. Haven't really found them to be as flexible. And you run into that old, yes, we could go spend this money or we can use this tool for free. I really like this. Yeah. It is still, the very first versions were very Windows centric. In fact, the very first version, the most notable thing was that it produced a report at the

end of the Threat Model so I could point to management, point the report and point to management and say, "Yes, we Threat Modeled this." Thankfully, this is like the seventh or eighth generation. It's a heck of a lot better. If you don't use a tracking system, you must be using something. You've got a spreadsheet, a list and a document. You're using email. You're using a mental list. Whatever you're doing for bug and work item tracking, make sure it's working for you. That's kind of a broader issue than threat modeling. If it's not working for you, that's a good data point to have. Go find a tool that works. If it's tedious to migrate threats into bugs, I would claim your tools aren't working for you. Because

if it's tedious to migrate threats into bugs, it's probably also tedious to migrate bugs into bugs, and you just have thrown your bug tracking system out the window because it's not working. So, unmitigated threats. You need to assume someone will find and exploit them. If you put a system on the internet with an unmitigated threat, or an open endpoint for example, somebody will find it relatively quickly. I haven't looked for the statistics on how long it takes for a honeypot to be discovered, but I know it's a matter of hours. And if it's a honeypot, say, on Microsoft's network, because Microsoft's one of the most attacked networks in the world, it's probably a matter of minutes or seconds.

Don't assume people won't find things, because they will. It may take a couple decades, but they will find it. WannaCry and NotPetya were the direct result of a bug in SMB version 1, which Microsoft released, what, in the early 90s? That's a bug that sat there for 25 years, or, well, we don't know how long it sat there, because the NSA has never fessed up as to when they found it. No one would ever do this. Well, people will. And we know, we all know that they will. Users will click through warning dialogues with verbiage that they don't understand because they want to see the dancing pigs. I want to see pictures of X. Great. Click through these warning dialogues. Let's install some malware. Here you go. Don't

assume we can't fix it. I hate that four-letter phrase. You can fix anything. Maybe the fix is not to ship something or not to deploy it. That's a way of fixing it. Now that's kind of draconian because I always say the most secure product is one that never ships. It's also one that means that we all go looking for another job because products that don't ship don't bring in revenue and revenue ultimately is what pays the salary. You want to err on the safe side. If you think there's an issue, make the assumption there's an issue. If someone in the team thinks there's an issue, let's go validate, verify that their thinking is correct or come up with a counter argument that is successful. The bottom line

is you want to analyze and prioritize thoughtfully, carefully, deliberately, and make informed decisions when you assess risk. So here's a traditional risk equation. Risk is the product of the vulnerability in question, the magnitude of the threat or threats against that vulnerability, multiplied by the value of the asset under attack, and then reduced to somewhat or maybe completely by whatever countermeasures you have in place. And I'm realizing as I'm looking at this equation, if you have no countermeasures in place, you have a big zero there. And divide by zero is infinity, which tells you what your risk is if you have no countermeasures. Interesting observation. I'd never actually observed that until this very moment. So let's look at an example of

intellectual property. If you work anywhere, you have intellectual property. Frankly, if you actually have anything of your own private life, you have intellectual property because it's property that belongs to you. Vulnerability is unprotected intellectual property. In the Seattle area, I always use Boeing and Airbus as the example because Boeing is a rather large employer in the Seattle area with a very visible product, and Airbus is their direct competitor. And so if Boeing has their IP unprotected, that's kind of important for Boeing. Now, I could use Amazon and Google and Microsoft in terms of cloud computing the same way. Or the classic example is Coke and Pepsi. that asset is worth some money. If you go ask the CEO of Coca-Cola Corporation how much the formula for Coke is

worth, he would probably stop, he or she, I don't know whether it's a man or a woman, and then say, "Hmm, that is an interesting question. We have thought about that. We don't discuss those numbers publicly. It's a rather large number." I would claim from a Coca-Cola perspective, it's probably an astronomical number. You then consider the threat against that asset. Pepsi probably wouldn't use-- do anything with the formula for Coke. And Amazon and Google and Microsoft all compete vigorously. But they have a very much an honorable agreement between the three that if there's a serious issue affecting the internet as a whole, they work together to mitigate it. And there have been numerous examples over the years

where Google or Microsoft show up at each other's campuses to talk about something in a closed conference room with no phone link. And three or six months later, the patches get released. Countermeasure. Well, let's encrypt the asset at rest. Now, of course, there's the whole question of how you manage the keys, which is a separate conversation. But bottom line is, you now have mitigation in place. If you encrypt all your intellectual property when it's at rest and you have good key management, if your competitor breaks into your network, they can't, in theory, can't get to that intellectual property. Now, I would argue that most competitors don't do that, but there are any number of examples where people break into networks and go after IP.

I like applying the STRIDE model from threat modeling to assessing risk. STRIDE is an acronym for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. This is a basic tenet of threat model, one of the ways of threat modeling. There are other ways of assessing risk and threat modeling other than STRIDE. I won't read the chart to you, which is reproduced in any number of places. But I'll describe it. Spoofing is a threat, an attack on authentications, pretending to be something or somebody. Tampering is a threat on integrity of data or transmissions. So if I can modify a packet and fly it over the internet, that might be an interesting thing. Repudiation is a threat against attribution. If you

have anything in your environment that logs, that is your mitigation against repudiation threats because those logs tell who did what when. They also might tell who didn't do what when, and if the log's going to be tampered, that's a whole separate conversation. Information disclosure is pretty straightforward. It's an attack on confidentiality. Patient data is a great example. Financial data is a great example. We all use confidentiality every day, every time we make a credit card transaction. We're trusting the banks and the credit card processors not to drop those bits on the floor. Denial of service is a threat against availability. Amazon-- I've used Amazon as an example, medical devices. When you drive a car, you expect it to work. If it doesn't work

because it's out of gas, that's a denial of service threat, or vulnerability rather. And there's mitigation. It's called going to the gas station. Elevation of privilege is a threat against authorization. Being able to do something you weren't authorized to do. And the classic example is you go to a website as guest, and half an hour later you're root, or half a day later, or half a week later, or whatever. That's the classic example. Trust boundaries will help you prioritize and assess risk. If you have data flowing from one level of trust to another, that's a key place to look at the risk. If that trust boundary is the internet, it's really a key place to look at risk. You want to be sure you're very careful about

trusted processes, reading data from untrusted processes. You assume inputs are evil and validate everything. If you have users entering data into your system, you assume the user is evil and the data they're entering is malformed. If you're paying for a pen test, it will be malformed. That's one of the things pen testers do. And they automate it because they can throw lots of different characters at UI, for example. Usability folks hate it when I say assume the user is evil. But in security, we assume everybody's evil. I also want to make sure that when you've got a highly trusted process writing to low, that you're not giving away information unintentionally. And the example I always give here is password dialogues. You know, standard password dialogue.

Your username, password. Easy. Two-part credentials. You'll notice that most password dialogs these days don't do the user friendly thing. They do the security friendly thing. When you type in either-- and mistype the username or mist or or and, mistype the password, the dialog says one of the entries you typed is incorrect. If the dialog says the password you typed is incorrect, I'm like, oh goody, I've got a valid username. And I'm halfway there on brute forcing that set of credentials.

Again, context is really important in this one. It may be that it is important to give the user that contextual information because of the context. When I go to a website and they put up a very specific error message on the password dialogue, the alarm bell goes off in my head. So some general rules when you're using Stride to assess risk. For spoofing threats, it really depends on who or what is being spoofed. If you're spoofing a guest user, Lower risk. Not non-zero risk, but lower risk. If you're spoofing an admin, that's kind of higher risk. If you're spoofing the domain admin, game over because they now have your network. That's why standard practice is you don't do your domain admin duties on a box

or virtual machine that you use for anything else. I'm sure domain admins out there do. If you're spoofing somebody who's famous, that could be or your product or service allows somebody to spoof somebody famous, that would make for higher risk. Tampering information disclosure is very dependent on context. If it's regulated or protected data, it's a higher risk. The assumption is that financial and medical data are accurate and kept secret, except to people who are authorized to see them or use them. If you look at medical software, which I work with, we have the classic consideration. If you look at a medical office, you've got the people who are scheduling the appointments, the doctors and nurses, the practitioners who are seeing patients,

and the back office people who are handling billing and what have you. And I would argue that the only members of that set of people in that medical office who should see my patient record are the doctors and nurses, the practitioners. The receptionists, the scheduling people, the front office people have no need to see the fact that I have whatever medical condition I might have. And the only thing the back office people should see is a diagnosis code. Yes, Bob was seen for XYZ on this date. Please give us our money. The details of that appointment, back office people should never see. If it's public data or no data, that's kind of obvious, it's lower risk. Gee, we're protecting public

data. That's nice. Okay, it's kind of, again, depends on the context. If you're putting your data over HTTP, I would claim that you and your customers don't care about that data at all. I have used that very line with some product teams I work with who now use HTTPS by default because I beat that particular drum repeatedly. Repudiation is typically considered with other threat categories. Medical data, typically, in the United States we have HIPAA. and a few other regulatory things. The EU has a different set. GDPR in two months will add some additional wrinkles to that. Canada has similar laws. In medical data you log who looked at it, when they looked at it, what they did with it. And if

it's required by regulation, which in medical it generally is, a repudiation threat is higher risk. And of course the context is important. Denial of service is very context dependent. If it's life endangering, that's really high risk. I've got some examples there. You may look and say, why is HVAC a risk? Well, if I can take control of that senior citizen nursing home and turn the air conditioning off in the middle of summer in Florida, I probably have just caused a few people to die.

If the availability is important, I used Amazon as the example, that's higher risk. I guarantee you when Amazon threat models their web services, availability denial of service threats are at the top of their list. Same thing with Azure. If the availability is less important, lower risk. I mean, the home lighting controllers, if those have a denial of service attack against them in my house, it's really inconvenient. And frankly, I'm unplugging those suckers immediately if that happens, and getting in contact with the manufacturer and offering my consulting services. Elevation of privilege threats trump everything. If you look at most bug bars that have been published, when they talk about a bug that's essentially an elevation of privilege, it's always a critical or a

high. If you look at Microsoft's bulletin history, elevation of privilege generally is critical or high. And the reason is if you have elevation of privilege, you can get the other five threats. If I get admin on your network, I can do things to your network that you would not like me to do. I can cause it to stop, denial of service. I can look at your information, information disclosure. I can change your information. Ooh, that would be fun. What mischief I could cause. That's tampering.

Oh, by the way, if I have admin on your network, I can also update and change your logs, unless you've made a completely tamper-proof from admins, and cover my tracks. So when you consider impact, again, this is somewhat repeating previous slides, but I'll make the points again. It really depends on how severe the threat is, how severe the risk is if the vulnerability is exploited. For spoofing, it really depends on how easy it is to actually carry out the attack and who can be spoofed. Tampering depends on the environment and what is modified, critical data versus non-critical data. Gamers hate the fact that I use game high scores as a non-critical asset for tampering threats. And I'm like, yes, game high scores versus

a pacemaker. Two very different contexts. Repudiation we've talked about. By itself it's probably low impact, but context is everything. Information disclosure, again, depends on what's being leaked. Medical data is really interesting because, you know, if one of us gets completely owned from an identity theft perspective, we can get a new government ID, we can get new financial data, we can't change our medical data. My medical history is unique to me and we don't have the medical technology that can change it that dramatically, even though I can go get artificial hips and new knees and all this good stuff that our parents and grandparents weren't able to get. Denial of service really depends on the environment. There was an article in the Atlantic

Monthly a couple months back that I looked at where the writer was actually in his early 30s, a male as it turned out, who had had a pacemaker for 10 years. The pacemaker was keeping him alive because his heart is faulty. And the article was writing about the fact that his doctor adjusted the pacemaker using a handheld device, I think maybe even a smartphone and an app held close to the man's chest. The man lives in the New York area and rides the subway regularly. And so he did the article. He didn't know it, but the article he wrote, he basically did the threat model on the pacemaker implanted in his chest. It was very

thought-provoking. It was really, from my perspective, it was really cool to see a non-security practitioner doing that analysis and that level of analysis. Obviously, he had a personal reason for doing it because if the pacemaker fails, his family is going to, you know, planning his funeral. And then elevation of privilege. Generally, you want to assume that this is broad impact. If it's an elevation of privilege, vulnerability, or bug, treat it as somebody's going to own your thing. And you treat it as severe. Now, Meltdown Spectre is an interesting case here because all of us in security kind of went sideways on that when we read through it. I read the initial news report in the register, did the Threat Model in my head and said, "Gee, if this

all plays out, you could be in a web browser surfing the web with an ad popping up and next thing you know, your kernel is owned." That's a bad elevation of privilege bug. And then about 24 hours later, Microsoft and Amazon started rebooting their server farms, their VMs. I'm like, hmm, they threat model too. Consider how easy an attack would be to carry out and how easy it would be for somebody to discover that vulnerability and actually kind of along the lines with that, how easy it would be for you to detect an attack. You know, unprotected web endpoints and HTTP are pretty obvious attack vectors as are phished credentials. I was at a conference within

the last couple years where somebody said, somebody, someone of the speakers said, somebody should just solve phishing. Guess what? People have been trying to solve phishing attacks for centuries and have yet to succeed. Now, if somebody succeeds in solving phishing attacks for good, we all owe that person a major amount of beer. If the vulnerability in question is publicly known, and there's a weaponized exploit against it, yeah, that's kind of easy. You need to assume somebody has that weaponized exploit and they're deploying it. Some examples that are more difficult. Meltdown Inspector, we've all read the analysis. There are no publicly known working exploits on Meltdown Inspector. I fully expect somebody to come up with one. There are a bunch of proofs of concept, but there

are too many hoops still to go through to actually carry out an attack. That we know of. That's an important statement that we know of. WannaCry is a great example. Before March of 2017, it was known only to a few people. The publicly known history on this, of course, it was SMBV1, which was the bug was coded sometime in the early to mid '90s. The NSA apparently went to town with it about six years ago. They got hacked by a group that eventually became known as Shadow Brokers. This was two summers ago. They finally told Microsoft about it six months later. Microsoft turned a patch for that beast around in two months. That's amazing. Anybody who's ever worked on an operating system with as

many different moving parts as Windows and as many different people dependent on it, two months to turn around that was a very nice engineering achievement. And of course, we all know their history since then. If the issue is not publicly known, that will be more difficult, but you need to assume the worst. Ultimately, I guarantee you if Microsoft had known about that bug in SMB v1 in 1999, it would have been fixed in Windows 2000, and in whatever version of Windows 9x was still being shipped. Some other considerations, what are you protecting? If it's patient or medical or financial data, that's kind of important to protect. That's going to raise the risk. you're going to consider the dependencies.

And if you can't validate the assumptions on those dependencies or other assumptions you're making, that raises the risk. And the local environment, obviously, in the context makes a big difference. So some final words. An effective threat model has one or more accurate, unambiguous diagrams that diagram the thing being modeled to sufficient depth and do it accurately. You've generated a list of very clearly stated assumptions that you can go out and validate. You've identified all the things your product, your feature, your component, your subsystem, your network is dependent on. You've done your threat analysis. The threats are well thought out, carefully considered. Mitigations have been identified for those threats and they're implemented and they actually address the threats in question. See my ATM example from

30 minutes ago for a mitigation that was not implemented appropriately. When you assess risk, assume the worst case. I was joking security that we've all imagined the worst and then some of us have seen it. That's why we all drink a lot at after parties. Assume the worst case. Always round up. We are pessimists. We are paid to be pessimists. We need to be pessimists. Our organizations are counting on us to be pessimists and cynical and hopefully not too snarky. As hard as it is, you need to track and apply the changing threat landscape. Meltdown Spectre are a great example. As far as I know, that is the first class of vulnerabilities at the CPU level. I'm hoping it's the last for a while,

but I'm assuming the worst and swallowing hard and moving forward. And don't debate the no brainers. If you're in a room with people and they're debating fixing or not fixing an elevation of privilege bug, I mean, discuss the context, get all the details out on the table, but this is not something you should debate very long. If you're debating not fixing elevation of privilege versus changing the color of a font, oh my God, your marketing people need an education. Attackers only need to find one vulnerability. One, in theory, we need to find all of them. And if I think about that too long, my head starts to hurt and I go running into a wall. My point of that is the devil is

in the details. Make informed decisions. Do your analysis. Understand what it is you're modeling, why you're modeling it, what the risks involved with that model are. Prioritize accordingly and make intelligent, well-informed decisions. Ultimately, the decisions you make may be business decisions, and that's fine. The business decision maker is paid to make those decisions. Maybe it's a collective group of people. If it's a really severe vulnerability, maybe it's an executive. And that's where the rubber meets the road. That's why executives make more money than I do. Because ultimately, I may say, here's a really risky decision point. I would recommend against it. But it's a business decision, and I don't own the business. You do. You decide. Follow some basic principles. We

all know about the principle of least privilege. Administrative safeguards, I've hinted at those. Two-factor auth is a pain in the butt, but it's a great safeguard. If you have really critical administrative tasks, making two people do them together, you're assuming they won't collude. Now, they might. They might be both malicious admins. At some point, you can't control for that. Be transparent. Threat modeling is an open exercise. Now, you don't share your threat model publicly. And hopefully what you share with the customer is, yes, we threat modeled our product or our network or whatever, and we have mitigated the threats that we thought were significant. Which you could actually, would even be better is if you can say, we've mitigated all the threats we identified, and we were thorough. And

maybe the customer signs an ironclad NDA and then you show them your threat model. Transparency is also important. There's a whole privacy topic on transparency. And the GDPR, one of the aspects of that is the European Union requiring all of us to be very transparent in how we handle their citizens' data. You want to handle data securely? My default is encrypt in rest and encrypt in transit. If I'm working with a product or a service or something and they're talking about a mix of sensitive and non-sensitive data, I'm like, encrypt it all. Let's just be safe. Yeah, it's a slight performance hit. And you have to manage keys and all that stuff. But you have

to manage the keys anyway and you have to performance it anyway. Encrypt it all. Be safe. And finally, logging. Kind of an obvious one. In medical software, we log who, what, when, where, why. We don't log what they actually were looking at. If I look at the logs for a medical device or medical software and I see the patient record there, oh my god, the alarm bells go off. And do provide tamper-proof logs, because ultimately, if you have a network with tamper-proof logs and you're under attack, you can go find where the attacker got in. And you can-- oh, that's kind of interesting to know. Put the customer first. I work for GE. GE pays

my salary. Who pays money to GE? Our customers. Therefore, the customer is at the top of my list, period. And probably the same is true with most of you, whether you work for another commercial organization or you work in academia or even if you're a student working a part-time job. Use common sense. Can't overemphasize that enough. And finally, we are all here because on some level we are a security leader. When you work with people who aren't in security or privacy, they're expecting you to take leadership, to show leadership, to demonstrate that. And this is one of the ways you can by saying, yes, here are the five issues we found. This is the most critical. This one we can live with. The other

three are somewhere in between. That's showing leadership and prioritization. Some references. Microsoft SDL isn't the only SDL, but it was the first one. I wrote several of the requirements that are still actually working around in there. OWASP is great if you're doing web apps or anything on the web. I love OWASP. My talk at B-Sides Vancouver, there's the YouTube link. Alex and the crew posted it. You can go watch me wave my hands on virtual recording. This is the book on threat modeling. Adam Shostak spoke yesterday. When he wrote this book, my comment was several of us at Microsoft could have written it. The right one of us did. It is an excellent, excellent book, and I highly recommend it. OWASP.org has an

article on threat risk modeling, a different approach from STRIDE, certainly a valid approach. I haven't digested it as thoroughly as the STRIDE approach, which is why you heard about STRIDE today, but certainly that's an article to look at. There's the automotive threat modeling template and the medical device template will be discussed in May at RSA. And I have reviewed it and given the authors some critique. I mean, it's excellent. They've added a couple of new threat classes having to do with abuse and patient safety. All right, thank you for your attention. I know I'm keeping you from lunch. I've actually ended basically on time, which is great. Are there any questions? Thank you. Any questions? You're

all either spellbound or starved. All right, well, I'll be around the rest of the day. Feel free to come up to me in the hallway or what have you. Thank you very much. I just wanted to do some house cleaning. So we do have some leftover swag. So at the break, go see the ladies at the front booth. and we are trying to get rid of it because I don't want to take it home. So if you want an extra badge or I think there's some shirts available still, please go in an orderly fashion. Capture the Fly is going to close at 4. It's actually neck and neck between two teams right now. And then apparently if you sign up for a new

team and complete two or three challenges, you'll be third place. So there's still opportunity to win. And then after, so at 5 o'clock we'll do a quick closing ceremonies and hand over our CTF prizes. So stick around for that. And I believe if you are nice and you talk to CyberArk, you'll be invited to their after party as well. All right, well let me introduce Greg Foss. I heard him on Pulse Security Weekly a couple years ago. He was talking about his home lab and I was like, "Ooh, that's really cool." And now I have one of those little micro PCs as my firewall at home. So we've been chatting online. I finally was able

to convince him to come up here. So please give a warm welcome to Greg Foss. - All right, well thank you very much. Thanks for having me, everyone. Before I get started, can we get a round of applause for the B-Sides Vancouver team for putting on this great event?

Well, thank you guys. So I also have stickers. So if you ask questions, or even if you don't, I'm just going to give out a ton of stickers. So let me know after the talk. I don't think I can throw them or anything. But, so there's stickers for Pi, which is essentially short for the Phishing Intelligence Engine. This is an open source project I've been working on for a while now, and basically, I'm just gonna tell you guys kinda all about it. And we're gonna talk through some fun war stories and stuff instead of boring you with all the weird PowerShell stuff we're doing. So a little bit about me. My name is Greg Foss.

I run the Global Security Operations program at Logarithm, based down in the States, in Colorado. And so, you know, you guys have openings up here. I don't know if you watch the news down there, but Vancouver's not looking too bad right now. So... So anyway, why focus on phishing, right? You know, phishing, a lot of times we get that it's a boring topic to cover and stuff like that. I mean, there's not much that hasn't been covered, but I mean, realistically, it's a great way into your organizations. And just get a show of hands, how many of you do phishing assessments of your employees? Phishing drills? Oh, that's good. Awesome. A lot of people. How

many of you go through and fully follow down every single phishing attack that you receive and ensure people haven't clicked links or submitted data and things like that? All right, got a couple. That's good. That's a giant pain in the ass, right? Oh, dude, I hate phishing. That's why we decided to automate a bunch of this, right? Because all it takes is one person in your company to fall for one of these, either give away their credentials, get infected with something. It's a very easy way into your company. And so I gave you guys some stats on just how often we deal with this within our company. So last quarter, we had 242 unique phishing

attacks against our company. And I say unique because these were all different threat actors, different types of attacks that were sent to us, you know, from different people that we were tracking, stuff like that. So on average, a lot of these were spear phishing against our financial department and, you know, some marketing people and stuff like that. People they would think, click on things. Sales, send anything to any salesperson, they'll click on it. Just a fact, I don't know. But this is one of the ones where on average we'd see about five emails per each one of these attacks. Some of them were upwards of hundreds or even thousands of emails. And so of these

attacks, Some quick metrics on them. You know, most often thing we're seeing is these credential theft links, trying to steal O365 access, Dropbox access, all these kind of things that hopefully everyone has a multi-factor on, right? Social engineering was up there, you know, just trying to trick people. malicious links, those are something that, you know, we're just using Office 365, we actually don't pay for a solution like FishMe or ProtectWise or any of those kind of things. And so, you know, it actually blocks a fair amount of malicious content. Same with attachments, we don't see very many of those get through. So the big ones we're focused on are some of these like wire fraud

attacks, social engineering, things like that that, you know, necessarily a lot of the sandboxing technologies don't really stop. So the metrics I'm talking about are actually all the ones that actually made it through, right? This is a accurate antivirus simulation. So who here uses O365 right now? Nice, a few people, excellent. So any of you have access to the admin console? The O365 admins let you go poke around in there and stuff. If not, I mean, part of this presentation, one of the main things I want you to take out of this is what you can bring back to your company and ask for some of this access into some of these critical business systems. O365 is something I'd pretty much, you

know, I'd avoided email servers and stuff most of my career, but then we made the switch to O365 and it's like, oh, we lost all of our message tracking data, we're not seeing all the email traffic coming in and out within our log data. It was like, all right, how do we fix this? And that's kind of where this project came out of. It was actually an effort to get better logging around this and actually pull this data back in and then kind of led into doing some active defense. against all the things that are actually just making it through these filters to begin with. And so when it comes to email, it's not just

phishing you have to worry about, right? There's a lot of other attacks that can hit these environments. So OWA, O365 password spraying, this is something that's very common. If you start looking at your log data, guaranteed you'll see some of this activity going on, especially if you don't have multi-factor. There's some great tools out there to do low and slow attacks against your public-facing infrastructure very easily. And the cool thing with O365, well not necessarily cool, they don't give you a way to block IPs up there. And if they do and I'm wrong, please let me know, 'cause I haven't found a way to do this, unfortunately. We block them through other means essentially. But

then there's also targeted mail scraping and extraction. This is actually something you can do with Py. It's something where we've actually caught some insiders doing some stuff like looking at what people are getting paid and things like that. So it's definitely something to look into. I'll show you guys how to audit for these types of activities. Malicious rule creation. This is a great way to get into an environment just by breaching their O365 interface. You can set up a PowerShell script that runs whenever you send a certain email to them. Very easy to create and passively do. You can even wipe the emails that are received, all sorts of other stuff. Passive account monitoring. Of

course, this is something we've seen some threat actors do for some time now. Some of them didn't even bother breaking into the companies. Instead, they just sat and monitored their email infrastructure and made targeted trades based on communications they were seeing. Very common attack for like law firms and things like that. Auto-forwarding, of course. Who here has found some people forwarding everything to a Gmail address or some personal address? Spoofing, of course, this is a very easy thing to do, especially nowadays, all these different cloud services. VoIP and SMS spoofing. This is one, if we have time, I have some fun use cases where we did some trolling on some attackers. We can talk about

that. Data leakage, of course. Send data outside your company. And then just general malware, and the list goes on. There's a lot of other things that can affect you in terms of just your email. That's how we started working on this project. So the Phishing Intelligence Engine, if you guys want to play around with it, it's up and available on our GitHub page. And I'll be pushing these slides out later, so no worries if you don't get this link down in time. But essentially, this project is a way to automate a lot of the defense and response to dealing with phishing attacks. And right now we're set around O365. We almost have on-premise Exchange support

ready. And the next push we're going to do is journaling so we can support more email platforms such as Gmail and stuff like that. So the way this works, this is kind of a 30,000 foot view of the architecture here. So this PI server, this is our central server where we're going to be running all the scripts and everything from basically a Windows server that we can run PowerShell on. And so we go out and pull the message tracking logs from O365, kind of set this up on a job. We do this all day every day, just pulling this data back in. And so once we have these logs back down, we can start evaluating

these email contents. Now message tracking logs only contain data like the sender, recipient, subject, and message ID. So there's not much to go off of there other than comparing to threat lists and looking for strange regex matches within the subject lines and stuff like that. So that's kind of what we're doing at that point, right? So if we do flag any of these, we're actually gonna start creating a threat list. We're gonna tag all the senders that have been sending us phishing attacks. And basically we're gonna be creating our own threat intel based off of who's attacking us. And we take these emails and we'll do another poll up here to actually get the real,

the full email. We'll send this over to our sandbox. Now the sandbox is really just a bunch of API calls that we have built into the scripts. And what these will do, if it's links or something like that, we'll go evaluate the links against a myriad of different APIs. and just evaluate is this something that's known in any of these different threat lists, something that has been found in attacks or anything like that. We'll actually do active sandboxing. So we'll throw it up in Cisco Threat Grid. We'll do a full analysis of it live, pull that data back. We actually just added a Cuckoo to this as well. So if you have your own Cuckoo

lab, you can push messages to that. So basically we want to try and get as many data points as we can to evaluate what the content of this email is, like these attachments, links, stuff like that. And then we assign a threat score. Now if it passes our threat score, we're going to perform an automated action. We're going to go out and automatically quarantine this mail from everyone at the company who's received it. So, say we set our threshold to a five, this bypasses that, we're gonna go out and just pull this mail and try and stop anyone else who might have seen this from actually clicking on links or anything like that. We'll also

tie back into firewalls and other tools to see if anyone did visit these links, just to kind of validate that. And so once that process is completed, we're gonna pull all the data down into this case folder, and this is essentially where we're gonna capture the whole contents of this attack. We're gonna have a running record of all the different cases for all the different attacks we've seen. So this has the raw data, the phishing email itself, any attachments, all that kind of stuff, and a full report of what came back from the analytics in the sandbox. Now in addition, we're gonna push all the data to the SIM. Now this isn't specific to LogRhythm,

you could do this with any SIM. We just built it around LogRhythm 'cause that's where I work. But we did make this very open source and it's basically just creating a log source and doing various API calls. So whatever you're using, if you're using LogStash or Elk or something like that, you can pretty much do the same thing with pushing all this data in and correlating all the message tracking data. Now the main kind of thing here is we're replicating the case data that we're creating within the case file here. We're gonna replicate that within the SIM. So we have kind of a separate tracking going forward. That's somewhere where we can do easy metrics

gathering and stuff like that. We can tag these cases and show, okay, here's the types of attacks we're seeing. And we actually do that all automatically with the PowerShell running in the backend. We'll do checks on the body of the email and the actual landing pages and stuff and determine, okay, is this like a fake O365 landing page? Did this pull down malware? All those kind of things that help us tag and categorize these. Now the automated piece of this is a little script called O365 Ninja. Now this is the thing we use pretty much every day just to go and quarantine mail and pull messages from inboxes. But it does a lot more than that. Actually more than since when I wrote this slide. Essentially we can

extract mail from specific users, we can extract mail from all users, We can quarantine that mail, we can block senders, we can unblock senders, which I may or may not have had to use a couple times. We can reset O365 credentials. Now this is variable depending on if you're using O365 auth or Okta or some other cloud source. This is one way to terminate sessions at least too. So if someone did say hijack someone's session, you can also terminate it that way. evaluate forwarding rules. We can run checks against all of your O365 configurations. and create and update logarithm cases. So whenever we actually run this, we're gonna automatically create a case within the SIM to essentially track what we just did. So provide some of that accountability. And

there's a lot more here. The next thing we're actually working on right now is URL rewriting integration with O365. So we can go up and dynamically sync all malicious links. So even if we don't quarantine them in time, say someone gets like 2,000 phishing attacks, it's not feasible to quarantine that within a few hours. So that's where that URL rewriting comes in. So you can go and just sinkhole anything like that. So instead of boring you guys with all the fun stuff about how this works, I figured I'd talk through some of the cases we've used this, both within our company and within some customer environments. Do you guys have any questions before I jump into this? All right. So the first thing I want to talk about

is just some quick metrics from our environment. So we've been running this internally for about a year now as we've been kind of developing this and improving the tool set. And right now 90% of the phishing attacks that actually make it through O365 filters were not even being seen by our logarithm employees. And the best part of this, the regex that we're using, is only like 25 lines. It's a very simple regex, we catch so many phishing attacks just with this regex. Those that do make their way through, we're fully tracking those, we're documenting them, creating cases, kind of gathering all that data so we can go up to my management chain and say, you

know, we're actually making progress here. And of the messages reported, 75% of those are quarantined automatically based on the checks that are performed. That's something I didn't really cover in that last section, but we have a reporting feature, you know, just simple like phish me button kind of thing. So people click that, sends it off, and whenever messages are reported, it kicks off that whole analytics workflow. So this is one we actually did last week, so I figured it'd be fun to include in this talk here. So the first one I want to talk about is just an internal phishing exercise. We do these all the time. We don't just do email phishing attacks. We've done fake wireless hotspots, you know, USB drops. We've had social engineering calling. We

actually had set up a separate PBX so that when they'd call back, we'd get different--they'd get a certain recorded message that sounded like the company we're calling from. So we try a lot to trick our employees given that we're a security company and security is really everyone's job. So we decided to do a very simple phishing attack. This one's pretty fun. We told everyone they ordered a crafting with cat hair book. to the office and surprisingly a lot of people thought they did when we saw this. And so, you know, pretty easy we thought. So I just want to highlight all the giveaways here, right? Like all the links go to some super shady email.

The email was shady, like everything about it was shady. Plus they shouldn't have ordered this thing. But we thought it was funny. My boss was like, "Hey, let's put something together tomorrow." And so we just threw this together. And surprisingly, we actually got some good hits. So up here is the log data. We're actually pulling this back down with Py to see how these were successfully delivered, right? So over here, we can see all the recipients, we can see 161 emails went out. So we did about 20% of the company. We usually don't blast the whole company because then everyone tells each other and it ruins the whole thing. Unfortunately for us, we have a

lot of remote people, so they have no clue when they get these things. But so pretty easy to track that, right? Let's get into the more interesting stuff. Let's look at who actually reported this email. So that's pretty neat, right? We can see who reported it, how they reported it, just by doing a query on our phishing response email address. But then we get into some more fun stuff. So up here we're just looking for the subject line of the email we sent out. And by doing this, we can see that someone in our sales department decided to send this to all of his buddies in the sales department. So pretty fun, a little unexpected

thing. And that's where you can see that circled part, that's the spike in more emails getting sent out. And it kind of sucks for this guy, because someone he sent this to did click the link, so he got dinged for it. So it's pretty funny. So you can kind of see the mail flow after you actually execute this exercise, which is kind of cool. But then it gets more fun. We're looking at who actually decided to respond to the phisher, right? So we did a search on that just looking for who actually sent mail back to our super shady Amazon email address. And so looking over here, we can see, okay, we got 23 responses

back to this non-existent email address. And filtering out the auto replies, we can actually see there were two people who did directly reply on their own volition to this address. So filter down again, and we get those two users. So I'm like, what the hell did these guys send us? And so, we'll go back to PowerShell. Now this is one of the things you can do with O365 Ninja. First we're authenticating Doe 365 up here, and then down here we're just pulling mail for these users. So we're looking for what they sent to this address. Because this email doesn't exist, so we were more just interested to see what they were sending them. And so

it turns out he was just saying, "Oh, you got me." So it's kind of funny. But dinged again because he replied to the phisher, but still pretty funny. And so, you know, phishing exercises are all fun and good, right? You know, you have your general metrics of who clicked on links and all that kind of stuff, you know, where they clicked from. And I didn't want to show you guys that, although the timeline kind of gives it away. But, The thing I want to mention with the timeline, whenever you run one of these phishing attacks, as soon as you do this, this email is going to be resident in a lot of people's inboxes for

a long time. So someone could come back from vacation or something a week later and click on these things. They could just click on it for no reason. And what if someone did stand up this actual shady site in the interim or something like that? Definitely something we'd want to avoid, right? So I'll get to kind of what we did for that in a second. But that's kind of why I like mentioning that timeline. You can see way back here is when we sent it, and then the next day we're still getting clicks or views, hopefully not clicks. So one of the things we really like showing with these, not just who fell for the

attacks, not just who's kind of on our wall of shame and who's gonna end up getting phished for all of eternity from us, But we like showing who reported this, who was most proactive in the company. And a quick way to do that, just some quick PowerShell where you can tie into your inbox and count how many people reported this at what time. It gives you a nice list. A really easy way to just report on this. And so for us, every time we do this, when someone, the first person who reports it, they get a coin. We have our little challenge coins. And so we always like to do a lot of positive reinforcement,

much more so than the negative side. But then back to the cleanup side of things. So this is where O365 Ninja comes in, right? So we want to end this exercise, we want to pull the mail and make sure no one else is gonna inadvertently click on this later. So we can run this. go ahead and pull that mail and the cool thing is we're gonna have a case created where we can track this. So we can go back a year down the road and say here's all our phishing exercises, here are the results, and we pull all that data very quickly and easily back into our case management system. So it kinda makes it

really easy to clean up and track some additional metrics for phishing attacks. Mostly I just added this because I thought the cat hair book was funny. Now getting into some real attacks. This is one we got back in November of last year. And so this one, the reason I bring this up is it was a very targeted one and more unique than a lot of the commodity malware kind of bullshit that we get all the time. This one actually came from, so Andy Grolnik, he's our CEO. He is A, the most commonly spoofed email address at our company. And so he doesn't really mind too much when we use him in demos. But this person went through the trouble of not just spoofing his email this time,

they actually went and registered the logarithm domain, but added a second T to it. So we're like, okay, that's pretty good. The funny thing was, so when he sent this, we have a algorithm tied into the PowerShell framework called Levenstein. And so the Levenstein algorithm looks for similar domains that aren't quite the actual domain. So the second this email came in, it flagged. And so we saw it right away and we started pulling this mail. And that's how we essentially got this mail. And so he's asking John, one of our sales VPs, to do a wire transfer for him. or a cash deposit. And so John, this part's pretty funny, he actually starts emailing back,

and he's like, what are you talking about? You want this from me? You want me to actually do this? And he's like, oh, yes, can you do this? So he started this whole conversation, and we're watching this whole time and just pulling these emails back in to see kind of what's going on. And so after giving him a little bit, we're like, all right, we gotta pull these emails and talk to John and let him know this isn't our CEO. So went ahead and pulled the mail and as I was starting to talk to him, he was like, oh, this instantly disappeared from my inbox. And he was actually getting on the phone to call

Andy to ask him what he was smoking that day to ask him to do a wire transfer. But it's kind of a funny thing because as soon as he is talking to him, all of the mail and conversations he had with this person were removed from his inbox. Because we just wanted to cut off as much possibility for him to continue this as possible. So now what this process looks like, so in O365 Ninja, if you're gonna go ahead and quarantine mail, that's essentially what this looks like. And this is actually the query we ran for this attack to pull that mail from John's inbox. And so up here you can see this is us

connecting to O365 and every line is basically us touching a different inbox to pull that mail and do a hard delete on it. And we actually pull that mail back to our inbox so that we can do analysis on it and have an ongoing record of it. We also blocked the sender, so down here, you can see he was actually sending this to multiple people, so it wasn't just John, it was a lot of other people, higher ups within the company, that he was trying to trick into performing this action for him. And so it was kind of funny to watch that. None of those guys responded, so that was good. But then down here,

we have the logarithm case management. So whenever we do this, we're tracking all of this within the case so that it provides that accountability and a record of, hey, I went and pulled this mail, this is what I did, this is what time, all that kind of stuff. So the funny thing is, up here is our alarms. These were all the alarms that were firing as this guy was emailing us. So he was going to different people. Like once he realized John wasn't going to send him money, he went to another group. And he was doing this for a while until we just finally blocked the domain. But it was funny. He's going around, and

the whole time we're just watching him try and trick other people. It was just funny to watch him kind of bounce around and do all this stuff. But then it gets even better. So this guy wasn't very smart. Turns out he decided to register this domain with his real information. He didn't even try and, you know, domains by proxy or anything like that, didn't even matter. So we got his full information, you know, you can see he's from Louisiana, and so we're like, wow, this guy is not very bright. You're attacking a security company, you know, actually registering our domain, and you don't even use any privacy? This is gonna have a bad day. And we looked this guy up, turns out he was much older than

we would have expected for someone trying to hack us, so... Likely someone was just using his information. We're not too sure. You know, a 69-year-old guy, I don't think he's sitting there crafting up emails in his free time. But if he is, maybe. I mean, we did go check his voter records and validate that he's a legitimate person at this address. So, who knows, right? So long story short, we did actually seize control over the domain and then we sent all this over to our buddies who we talked to very often. Small potatoes for them, but one of these things like these phishing attacks and stuff like that, a lot of these people end up

being part of larger rings. So the more information we can provide them, the easier it is for them to add them to their ongoing tracking and who knows, might help them. Either way, we're like, hey, this is on your plate now. And we've just taken over our domain. Now, this third story, this is a fun one. This is with a customer who had deployed Pi and about a month after we got this all set up for them and they were running with it, they gave me a call and they said they were seeing some weird activity. And so I'll kind of get into what set them off in a minute, but the main thing we noticed was they were getting these low and slow O365 dictionary attacks

for months at a time. It was something where they were all originating from Nigeria. And this was an interesting one because it actually tested the limits of our framework for the first time. So kind of an interesting story to talk about. So we're looking at these attacks and so up here we're highlighting is these are the number of events. So about 3,500 login attempts over a month time against this company from this one attacking group who for some reason uses their same IP for all their attacks, they didn't even bother changing anything. is all this one subset of IP ranges. So we're just tracking them, going back to see how long they've been hammering at this company's door. And this company didn't have multi-factor configured on their O365, so

of course, eventually they're gonna get in. The funny thing is they didn't get in through these password spraying attacks. They got in through generic phishing attack against someone in the company. And it was a typical O365 credential phishing scam. So, you know, same attack we see all day every day against every company I've helped with around this. And so the email itself was very simple, like not a difficult attack or anything like that. Just, hey, this is a... So, you know, you go verify your email account. And it's funny because this guy's not even associated with IT, he's in sales. And so, you know, completely different apartment and, but it worked, right? It worked. He got in and got access to this guy's

account. Now what happened kind of really sucks for this guy here. They took the same exact attack that this guy fell for and sent it to the entire company. So everyone at the company now has this email from this guy and it's validated. It's actually from him. So tracing this back, we can see just how many emails went out, how many people received it, stuff like that. So 284 people of this company received this email. So pretty bad, right? Pretty embarrassing for this guy. Felt pretty bad for him. It was all from this one IP from Nigeria. So same group that was doing the dictionary attacks against their web interface. And funny thing about these

guys, they've been hitting a lot of different companies. So same time we saw this hit them, they tried to hit our company, they tried to hit a couple others that we've been working with at the time. So a very pervasive campaign for a short period of time. And so the really bad part about this one was this actually went out to a bunch of external people. So a bunch of customers for this customer. And so over here were the three external recipients. Now these are ones, there's no way we can pull this data back. By this point we've already tried to pull as many of these internal mails as we could, but by the time

they called this, this had already been going on for a couple hours. So we didn't actually start the quarantine process for quite some time. So, nothing we could do about these, but we could at least try and clean up these internal ones. And fortunately, most of the people who received this actually reported it, which is kind of cool. So, what you're looking at here is kind of the main dashboard we set up just to track all email data. So, we're looking at external sender to internal recipient, locations, so where these actual IPs are based. Down here is the physical locations, so we're doing geo IP correlation. And then over here, the external message subjects. So,

anytime you get these external phishing attacks, immediately bubble up to the surface. Now since this one was internal, kind of breaks that whole model, right? This wasn't spoofed or anything like that. But the main thing I want to show here is the center right here where we're actually tracking phishing messages that are reported. So every time a new email comes in, this little ring lights up red so we can say, "Okay, cool. We have a new phishing attack that's been reported to us." And down here we have our phishing cases where we're just tracking ongoing metrics around cases related to phishing attacks. So you can see it spiked right here, kind of blew up as

soon as this email went out because everyone's trying to report it and get rid of it. Now, the funny part is the auto quarantine didn't work on this one because I put a safeguard in to not quarantine from internal people. Because we had one of my analysts went ahead and ran this one time and accidentally quarantined everything from an internal person. So it's something where we had to implement some safeguards at some point, right? Now, the problem with this was we didn't get to it in time, right? So, there was one guy who actually fell for this right away, like as soon as the email came out. He went and clicked on it, entered his

creds, and was owned. And we had no idea because we didn't see any further authentication activity. We only had a very limited time to work through this with the customers. We actually didn't see anything happen at that time. But turns out a few days later, they logged into this guy's account, who gave his credentials away, and decided to do the exact same thing. They sent this email out to the whole company. So except this time, they sent about four or five copies to everyone at the company. So, giant pain in the ass. And the funny thing with these, I mean, there's not much you need to do to gather a lot of information on a

company. So say, you know, that's kind of the thing we've been wrestling with is like, why would you do this? Why would you blast an entire company? You know you're gonna get caught, you know all this stuff's gonna happen, right? But, if you look at some of the passive stuff you can do with email, like loading images, looking at tracking and stuff like that based on the contents of images, or maybe use a DDE exploit or something like that where you just have to load the content and the attackers can gain access, there's so many other things they could have done with this. So, we're still kind of concerned this could have been a ruse.

We shall see. We haven't heard back from them in a while, so I'm guessing it's maybe okay. But this email, the link again goes to an O365 landing page, another credential theft web page. So typical kind of attack for these guys. And now, tracking kind of the event timeline here, so you can see our initial phish, that's when the first person was compromised. They actually logged in kind of around here, and then second wave, that was when they sent out that second email. So they tested creds right around the first and then sent another email out shortly thereafter. That was one where we actually, so since this company has a lot of external people, with this one, so

the next round was like 2,000 emails. So we're quarantining these, but there's no way we could do this in time. So definitely highlighted some shortcomings in our tool set. But, some of the interesting things here, so this was that first round, we'll call this guy Nick, right, the first guy who was compromised. Now David was the second one, this name may or may not have been changed. But this guy, so this is when they actually logged into his account. So we're looking at authentication logs to O365 to validate when these people came and went, right. And so there, that second spike is actually when they decided to send mail out from this account. So, you

know, first testing access, they went in, set up a bunch of rules to auto-forward, to auto-delete, all sorts of stuff like that to kind of hide themselves in his email account. Then a third guy, call him Bob, clicked on David's email. By this point, we have this whole chain of like a wall of sheep of people who keep falling for this. This was actually the last straw that allowed them to implement multi-factor on their O365. They were like, "Okay, this is just ridiculous." We're tracking this. The best way we determined to actually see if these guys were gaining access was just passively monitoring who's successfully authenticating to these accounts from Nigeria. And it's funny, I

mean, it was very simple. If they would have changed IPs, they could have logged in and these guys wouldn't have known. Now one interesting thing up here, I want to point out, is the user agent strings. So, we noticed as they would log into accounts, as they would actively log in and start poking at these accounts, they had a whole team. It was about five different people per each account that had very specific jobs. So, they would come in, one person would set up rules, one person would begin crafting the next email. They had very specific kind of jobs they would set up, all from different IPs, different user agent strings. and it was just

something where, kind of interesting to watch, but this is where every time we'd see these successful authentications, we'd just go ahead and terminate their accounts, force reset their credentials, kind of all that stuff to at least ensure these people didn't do anything else. Last thing we want is them sending another global email out. But in the end, we finally convinced them to enable multi-factor. We're like, dude, this is literally the only thing you have to do, and it's gonna be way better. They didn't like it too much, but ended up doing it. And now, I think they're doing okay, 'cause they actually are controlling some of this access to these accounts. So, my fourth story. Anyone hear of MailSploit when this came out?

So, MailSploit was pretty interesting. So if you go to, I think it's mailsploit.com, they have a really cool framework where you can test email spoofing rules. And so, MailSploit basically compiled these 30 different attacks to determine how you can best spoof certain clients to make it look like mail came from someone when it definitely didn't, right? So over here, they're spoofing Donald Trump, Of course, this is from him. But it's these very common phishing attacks that have been used for a long time. MailSploit actually just kind of raised this to the surface and made it very easily accessible to people to test out and really kind of validate this within their own clients. Now, when we tested this, about half

of them worked on just Outlook at the time. So this was, I want to say, four or so months ago. And the way it works is it'll look like, it'll actually switch out the name and sender and you can actually spoof this from whatever email you want. And it'll just look like it actually came from this person. So pretty good attacks. And about half of them were working when we tested on mobile. Mobile's where it really got interesting. So most of these attacks actually work on mobile phones. So kind of nifty little thing. But the fun part of this is that, so even though there's all these different ways to spoof the mail and change

things around, the actual log data doesn't change at all. So every time you use one of these mail-sploit tricks, the log data remains intact. And so this won't actually be modified, this won't be changed or anything. So it was actually extremely easy to detect every single variant of the mail-sploit activities, regardless of how they're rendered on the endpoint on the client. So when this came out, we ended up writing a very simple rule to detect this. And then that day, we actually got a bunch of these attacks at our company. But it's just funny. It's a very easy kind of thing to detect. And so essentially, you know, firing alarms whenever this happens. And so

whenever we get one of these, we can automatically quarantine the mail and remove it. So now with Py, anyone have any questions or anything about that stuff? All right. So we have a lot of plans to kind of keep improving this and we definitely want to keep everything open source. We are also building a more tight integration with the product. That's kind of a separate team from mine. But we do want to tie into, so logarithm just released 7.3, which has a more robust case where we can do like attachments and stuff to it. So that's the next thing we want to do is make that much tighter, want to add more functionality to it. O365 URL rewriting is something we almost have integrated now. IDS firewall and

endpoint integration. We're tying into Palo Alto and logarithms NetMon and then the Security Onion tool set right now. We're gonna keep expanding this to add in other tools that other people are using. Support on-premise exchange, of course. A web leaderboard and open metrics. This is something where, one habit where people could actually go to this page and see, okay, who's reported phishing attacks, what kind of stuff are we seeing? Some very cleaned up and internal friendly kind of metrics we could show back to the company. Active defense scripts. This has been some fun stuff we're working on. Basically reverse phishing and all sorts of stuff like that. I think we'll have some time. I can talk about some of that stuff here. More seamless SIM

integration. We want to make this very easy to integrate with all sorts of different SIMs. You know, depending on, you know, obviously we'd like people to use logarithm, but if you're not, we want to be able to tie into Splunk and ArcSight, QRadar, kind of all those other solutions out there. and then more community integrations. A lot of the feedback we've gotten from this is just like, what other APIs people are using, what other kind of sandboxing technology and stuff like that. We want to augment this as much as possible and tie into whatever else you're using that you find very useful. So if you'd like to play around with it, there's the GitHub link. And yeah, feel free to pull it

down and give us some feedback. Let us know what's working, what's not. All that kind of stuff. So, you guys have any questions? Or should we go, yes? - How many, what percentage of false positives? - So false positives, I'd say maybe 10% or so. It's not too high. And the main reason it's not too high is we have that kind of range of threat scores. And so we set it kind of variable depending on which APIs you call out to. And that's why I try and use a myriad of different APIs so we don't rely on like URL void or OpenDNS alone. We want to get all that back and we pull that back for the analyst to kind of make that decision.

So something where, some of these you can quickly go validate, but for the most part, we haven't seen too many false positives. If it's a benign link, it may flag on one or two things, but that's usually because they're using a bit do link or something that's shortened and commonly tied to malware attacks. So it hasn't been too bad in terms of false positives. Oh yeah. - Almost five minutes later. - Yeah, so with two factor makes it much easier 'cause then we can validate. And so for us we use Okta for multi-factor, which is really cool as a log source 'cause you can see what device they used, where they authenticated from, how they authenticate, what type of two

factor. And all of those kind of different pieces of data allow us to fingerprint that user. And so with that, we can actually do some kind of things like what you're saying is look at discrepancies in that. We do fire alarms when someone changes locations, when they're authenticating from a new geographic space. And within O365 directly, they have some really cool correlation rules you can do there where it'll actually show "This person logged in in Boulder, Colorado," but then 20 minutes later they were seen logging in from Vancouver, BC. And then it does an actual calculation of the travel time between the two. Now nine times out of 10 that'll be proxy or VPNs and

stuff, so we can quickly weed those out. But once you weed those out, anything outside of that are definitely users to look into. So collecting this data kind of opens up a lot of that possibility to tracking that. Any other questions? Ideally I'd like to have it next quarter. Just depends, 'cause my main job's running security operations, so this is kind of like my side little thing. But ideally I would like to have it next quarter. And I think we're close, it's just deciding on how we wanna do it. If we wanna do the same type of log collection we're doing now, or if we wanna switch over to solely journaling, which is a little more complicated in some ways, but you get a lot better data.

So hopefully soon. Yes. So... - No, that's a great question. So the question was how do we solve ActiveSync 2FA? For us, since we're using Okta, we can generate a token for a service account through Okta, and it's just something we have to renew periodically. But that's kind of essentially how we did it. We just generated that token, and then we used that and treated it essentially as a service account. And then heavily monitor that and the systems that these scripts are running from. All right, so let's talk about messing with some phishers real quick. So anyone here know this trick with bit.ly links and shortened URLs? You can actually take these and add a plus sign to them and then you can see kind of all

the metrics behind them. So this is a phishing link we got a while ago And by the time we got it, we could tell this is a commodity malware or a commodity attack. They hit about 2300 people before we even saw it. But you know, just a nice little trick to determine if this is a targeted attack, if this is something specific to you. Within Py, we automatically do that and provide the analytics back to you within the report. So this one, another O365, fake O365 credential harvesting page. And so we decided to have some fun with them, 'cause we were a little worried someone might have sent their credentials through. Even though we reset

their creds, we still decided to troll this attacker. So I wrote this script that actually goes out and you have two options. You can tie into proxy cannon or proxy chains and it'll make however many requests you want to configure it to run And basically what this does is it goes out and every request it goes and registers a new IP and then submits the form. Goes out, submits a new form, and it just keeps doing this. And it does it in IE headless mode, so it looks like they're actually loading the page. So it's pretty fun. We've actually tuned this quite a bit. This is an old screenshot, but now we have more realistic

password generation. more realistic username generation. We can even target this to the specific type and the specific phishing attack they're using. So basically we did this just to go fuck with them. Especially if they're getting email alerts from this, that's the best. Send 5,000 emails to them or something. And so we've only done this a few times. But it's funny, so far we haven't gotten any flack yet. Actually, one of the attackers that they kept coming back and messing with us, we did this, and I didn't even rate limit it. I was just like, yeah, send as many as you can as fast as you can, and we never got a single fish again from them. So I don't know. So that's pretty fun. I like

trolling these guys. We've done other stuff with web bugs and trying to get them to agree to our terms and then shell their computers and stuff. I was told not to do that anymore. So we've limited it to this, a little less invasive. But it's not limited to email, right? So VoIP, SMS, any of you guys get these? These little techs? Click on this link and exploit your Android. Or hey, tax arrest scam. These ones are particularly evil, the tax arrest guys. So one of these phishing groups in particular, part of the tax arrest scams, they actually were just busted, I want to say three or so months ago in Nigeria. And these guys actually made about $30 million by phishing people in this way.

And that's an insane amount of money for them to call and say, hey, you owe us $10,000 or we're going to lock you up and all this kind of stuff. And they scare people, and apparently it's extremely successful. So we-- fuck these guys, right? So I had a smart response, basically it's PowerShell script that we tied into the SIM that would do phone calls from Twilio to alert you to alarms and stuff. I was like, oh, I could just loop this thing and just go ahead and blow up their entire phone bank. And the cool part is you can tie in, so with this script I tied in about 20 numbers this time, but I

found the max is about 50, and so you can tie in 50 numbers and just blow up their entire phone bank. And the funny part of this is, so I just set this to call as many times as feasible, so as long as their lines open, it makes another call. And you can send about 2,000 phone calls and record five seconds of audio for about $20 with Twilio. I'm not endorsed by them, I just think it's awesome. And so it's funny when I wrote this, I ended up calling my whole floor like that day. It's pretty fun. 'Cause you can plug in as many numbers you want to call too as well. And they can't

block you 'cause if they do, you just change the numbers you're calling from. And so it's pretty fun if you wanna go ahead and ruin their day. We got some really angry voicemails from this. It is so great. But it's not just VoIP, you can do SMS as well. So this one's pretty fun. And so we don't use this one as much, mostly the VoIP flooding one. It's definitely against their terms of service, I'm pretty sure. So sorry Twilio, but it is something, you know, we like to stick it to these guys a little bit, right? I mean, they're messing with us. These phishing attacks take up so much of our time and effort. Why not screw with them a little bit as well, right? And so with

that, thank you guys. And I have stickers as well. Thanks guys. Any other questions or anything? I just want some stickers. Oh, thank you. Here you go, man. I'll give you a couple. Hey, there you go. Thank you. Oh, thanks, man. Here you go. I'll give you a couple stickers here. All right. Hey, how's it going? Oh, thanks. Oh yeah, oh yeah. I'm all about the active defense. Oh, thanks. - How about the voice? - Oh, it could be. I haven't put it out there, but shoot me an email. I'll send it over for sure. I was worried about putting it fully open, but we can definitely do that. Oh yeah. Oh, nice. Yeah. - Social talk and conversation. - Yeah. It's, yeah, I

definitely see both sides of it. And I'm more, hey, let's hack back. Oh, for sure. Oh, yeah. Oh, yeah. Oh, no. Oh, thank you. Oh, thank you very much.

Yeah, like Swimlane's a really good one to look at. Swimlane, they do, it's a commercial service, but they do Python. So, yeah. Thank you. Yeah, yeah, they will end the whole recording. Okay, testing, testing, can you guys hear me? Okay, cool. So I'm Jeff McDonald. I'm an antivirus researcher for Microsoft. I work on Windows Defender, which is our free antivirus software with Windows. We've also got enterprise versions of our product, too. I work here for Microsoft in Vancouver. I've worked a number of years reverse engineering computer viruses and malware, both as well as commodity malware, as well as more targeted attacks as well. Nowadays I spend most of my time building machine learning models, so I work on Windows Defender where we build machine learning models

in order to combat and fight malware. So today I'm gonna be talking to you about how malware, how we've been observing that malware has been defrauding the certificate authorities in order to get code signing certificates. So first off I'm gonna start off with a really brief introduction of what trusted code signing certificates are. I'm sure a lot of you are quite familiar with code signing certificates, but I'd like, since it's a key part of the presentation, I would like to just give a quick recap of what trusted code signing certificates are. So if you as an entity or individual would like to prove executable content that is in the public domain is yours as a

business or as an individual, you can apply to a certificate authority to validate your identity. So you as an individual or organization apply to a trusted certificate authority. There are a few examples of them up here, Komodo, VeriSign are a few of the examples, a few of the common ones. Now you pay them a little bit of money, usually on the order of about $90 US, and then it's their job to validate your identity. So they're gonna validate who you say you are as an individual or as a company. And if you pass your validation process, they're gonna issue you a private and a public key certificate pair. So the private key is designed to

be held by you as an individual organization and to not be given out. Meanwhile the public key is designed to be given to the public to validate anything that you cryptographically sign. So if you were to want to prove that this executable content came from you as an individual or organization, you would use your private key to apply the asymmetric cryptography to the executable and you would append a signature to the executable content, thereby proving that the holder of the private key applied the crypto algorithm to the executable content. Now you would also append the public key certificate, which is designed for the public. You would append that to the executable content as well. That

way when the public encounters this executable file on their computer, they can check both the public key certificate identity and then validate that the signature was generated correctly by the private key holder. So this is called code signing. This was a greatly simplified version of it, but this is the gist of how it works. So your computer only trusts code signing by certificates that your computer trusts by default. By default, Windows has a whole, quite a large list of trusted root certificate authorities, and a bunch of these are the ones listed. But there's a lot more certificate authorities than those. So those are the companies that we trust in order to validate your identity correctly

to certain standards. So you can also individually codesign files, you could self-sign files, but any customers that you ship your binary to wouldn't trust it by default unless you get them to add trust to your certificates manually. This process is very similar for TLS SSL certificates for HTTPS websites, except usually for HTTPS certificates, you don't need to prove yourself as an individual organization, you just need to prove that you own that website, for example. Then they'll issue you a trusted certificate where you can sign content of network traffic going to that website. Okay, cool. So why do people codesign? There are a number of reasons. First off, it proves that the file is from the entity and has not been tampered with. So this is a bigger issue

when it comes to updates to applications, like if you have iTunes installed in your computer, for example, and you've got an update package. It would download the update, maybe even over, it could be even over HTTP, not a secure connection, and it's received an update package, it can verify the integrity of it by validating that it's been trusted code signed by iTunes before it's gonna run and install and apply that update. Other reasons are establishing a security reputation for all files signed by the same entity. So a lot of the security vendors as well as browsers build reputations per certificates. So if we see that a certificate has had very good reputation in the past

and we see brand new files signed by that same certificate, we're gonna be applying a positive reputation to it. So it means fewer false positives for your application. It also means fewer user warnings when users are downloading your files from the web. So sometimes there's browser experiences which are gonna say this isn't commonly downloaded, are you sure you wish to run this? Experiences like that can be avoided by these codesigning of these files as well. It also affects a lot of visible and behind the scenes user experiences. For example, SmartScreen download reputation, that's the download reputation built into Edge. Code signing your applications affects what types of user prompts are gonna appear there. It also affects antivirus false positives in your applications that I just said. And it

affects user access control dialogues as another example. So, uh, codes- this is an example of a code signed, uh, non-code signed flashing seller binary versus a code signed binary requesting administrative privileges. But of course, we all know UAC- UAC dialogs actually are to an integrity boundary. So in the case of malware, this isn't usually their motivation. Uh, so code signing is re- is required also in certain cases and may have special requirements like in the case of Windows- Windows driver code signing is- is required to be code signed by certain authorities. - Okay, so there are two main types of code signing certificates. The first type is individual developer certificates. So this is if you want to build and release code under your own personal name. Maybe

you don't have a company that you're releasing your software under yet. Or the other option is more common, which is the organizational code signing certificates. This is if you want to be able to publish code which is certified under your company name as a business. Okay, so now we're gonna start to look about at some of the recent code signing abuse cases that we've seen from malware authors. So I'm focusing mostly here on commodity malware for this presentation. The targeted attacks abusing code signing kind of falls into some different attack patterns that we're mostly gonna be talking about here today. Here's, over the past few years, some of the most recent outright malware campaigns that we've seen of using code signing malware. And we're not gonna be

talking about every single one of these attacks. It's a few too many of them, but as you can see, it's not on a big rise, which is a good thing. But interestingly, you might see right here, Over the past few months, we've been seeing a significant rise in coin miners. So those are cryptocurrency miner trojans. So what those malware do is they, once they infect the machine, they're going to install cryptocurrency minories on those machines and force them to mine currency towards the criminals. So coin miners are on the rise, unfortunately, probably because of the really big increase in cryptocurrency prices over the last year. So the first one that I'm gonna talk to in detail on is gonna be BALIMID. This is a really interesting malware which

was abusing code signing back in late 2013, early 2014. This is a pretty prevalent malware which is quite common in Turkey. So this malware was a click fraud and search engine optimization malware. So if users who are infected with this, they would use about one gigabyte worth of network traffic per day on their machines. They would navigate to all sorts of different websites and they'd be clicking on all the ads and links on the websites that it visits. It would also do search engine optimization by doing fake Google search queries in the background and then clicking on certain search results to try to raise their prominence in the Google search results. So this author was actually selling the traffic from his botnet publicly on a website

on the web. It's written in Turkish here, but the gist of it is he'll sell you 5,000 credits for around $10 Canadian. Each credit is good for a visit for two and a half minutes, he describes. And for each visit to your website, it's gonna click around your website, it's gonna click on everything for the whole time while it's visiting your website. Now if you look at most of the people who are buying this traffic, they would usually create landing pages which are just full of page upon page upon page of ads. There's no real content to these pages. They would just buy this traffic from this botnet and then do ad fraud with it.

So they even charge VAT in this case. So they're really setting up as a pretty legitimate business. So let's have a look at what they were doing for code signing. Let's look at what their certificate was. So here's the certificate. They're actually pretending to be a fake Windows component, csrss.exe. Probably a lot of you recognize that component. It's a very critical Windows component. They actually code signed their malware pretending to be csrss.exe. And really interesting here, this is the certificate type here. First it's a VeriSign certificate, so VeriSign did the validation process. And it's an individual certificate, an individual developer certificate. So this, some person went through the process validating this specific identity. Now I've blanked out most of the person's name here, but the

whole person's name is actually code signed onto this malware file. Now you, now, at least my first thought would be that no one would codesign their own name onto their malware, right? Like especially fake Windows components. It's gotta be stolen identity or something, right? But if you look at it in this case, it is insane. This person codesigned their own identity onto the malware actually. So if there were a Darwin Awards for hacker fails, I think this takes the cake. They codesigned their name onto a fake Windows component malware. Okay. So for example, the contact information on that website is under the same name where he's selling the traffic. The malware domains which were distributing this malware were actually registered under his name as well, no hiding of his

identity with registering the domains. And even the bank account transfer information for payment under his name. Really careless. But so this case we referred it to law enforcement and I also got the certificates revoked. So the next case we're gonna talk about is a pretty famous one. A lot of you are probably familiar with this Mauer family. It's called Koftor. It's really famous as quite a prevalent Mauer family, and it's mostly famous for, for being, I guess, the biggest Mauer family which began using fileless infection vectors. Oh, sorry, quick question. Yeah, those are embedded in the file itself, yeah. - Yes they did. So those are the file properties which are actually embedded in the file. So they codesigned that right into the file.

Yeah. It's pretty odd. Yeah. - How did VeriSign not have a red flag, wasn't it signature, had the word Microsoft software validation - Yeah, so it doesn't. The certificate is just this part of it. So he, sorry. - Digital ID class three. - Digital ID class three. This one right there. Actually, I'm not sure what the description of that is. I think that might be the class of the certificate. I don't know. Yeah, yeah. But as far as I understand, it's just in this individual developer name. Maybe all individual developers have this prefix there. Maybe, do you have a better understanding of what that one means? Okay, yeah, sorry. Yeah, as far as I understand, it's

just a regular individual developer certificate. Got it, cool. Yeah, so as far as Verisign would have seen, they would have just seen he was requesting a code signing certificate for this developer name. So they wouldn't have known what he was gonna sign with it though, yeah. Okay, cool, so the next one was a pretty famous malware called Koftr. So Koftr is famous for being a fileless malware attack. Now fileless is sort of within quotes. A lot of the fileless attacks actually arrive by a file. So like Koftr initially infects customers usually by social engineering attacks, either as email attachments or social engineering vectors. But once it's running on the customer's machine, infects it, it stays persistent through just registry

keys. So there's no file on disk once it's infected the PC, but for the initial infection attack, it usually relies on a file. And that's, you'll find for a lot of file, supposedly fileless attacks, they still start with a file. So Cofter, for a period in 2016, was abusing code signing, trusted code signing certificates. So now I'm gonna talk about what Cofter was doing as part of these attacks. So Kafka was taking out malvertising campaigns so they're placing malicious advertisements which would then be hosted on many legitimate websites around the world and when users would visit these websites hosting the bad advertisements, they would be redirected to fake Adobe Flash websites which claim that your Adobe Flash is out of date and you need to update it for

security reasons. - Yeah, now interestingly here, these websites that they would redirect to, these were HTTPS trusted secure websites. So they would have the little browser lock which might add a little bit to the social engineering aspect of it. And the reason, like this is, This is a few years back, so I think a lot of security software at the time would apply much higher reputation to trusted HTTPS secure websites because they weren't abused as much for phishing back then. Though I think things have changed more recently in the last year or two, because they're more targeted by malware authors. So I think they're doing this to get better reputation on the websites so that browsers would less likely be willing to block it as phishing attacks as well

as give higher reputation to the download that it was about to lead to. Now this would download flashplayer.exe. Now this would be the file which is valid trusted code signed. There were trusted codes signed in this flashplayer.exe. And again, I suspect the reason is mostly to get through the browser security prompts because Chrome and Edge is gonna throw less of warning dialogues about the user trying to execute a trusted code signed downloaded file. So it's all about improving the efficiency of the social engineering campaigns they're running. So they would run their, Cofter would run their campaigns in really big bursts. The first burst we saw with the first certificate, it affected 350,000 unique machines of

just our customers, Windows Defender customers, which is a lot of machines as far as the volumes we normally see. They would go in bursts which last just a day or two because the certificates would be quickly revoked as soon as we figured out that it's code signing malware, we had notified the certificate authority, get it revoked. So they're running on very short time frames where they would launch the campaigns in very large volumes over very short time periods to get the most of each certificate. So they would get a new certificate for each new campaign that they would run. Yes? - Yeah, so I've got a, I guess I have an internal contact who I notify within Microsoft, he then manages the contact

process through the certificate authority. But usually I would say it might take I don't have any concrete number, but I would, if the whole process goes really quick, it's pretty easy to get certificate authorities to revoke it. They just wanna know whether it's from, you want it revoked from date of issuance or from a specific date, like it was a stolen certificate instead. - Hours, I would say. Like it might take on the order of six hours, but don't quote me on that 'cause I'm actually not entirely sure. Yeah, but I think it's on the order of hours, yeah. But I think a lot of security researchers don't do their good due diligence of actually

notifying the certificate authorities. A lot just don't bother. They add detection on the whole certificate. And it's something we need to keep doing good as a security industry to make sure we notify these certificate authorities when we see it abused to get it revoked quickly. So let's look at the certificate that certificates that Cofter were using. So here's a look at the first of those certificate of certificates that Cofter was using for code signing. We can see it's an organizationally validated certificate. It's a company called ITGMS Limited and this one was by Komodo. Komodo. It was a one year certificate I think, yeah. So these certificates were not stolen. They weren't stolen code signing certificates. Often we'd look at the telemetry on the certificates, we'd see

they wouldn't be used by any clean applications before these malware attacks. And often these code signing certificates were being acquired just before the campaign attacks began. So these clearly weren't stolen certificates. So this got me looking more into how they're getting these code signing certificates. So now we're gonna talk a little bit about how you actually get these certificates. So first, I was gonna quickly go over TLS SSL certificates. This is for HTTPS connections, which Koftra was using. So those are really, really trivial to get HTTPS certificates nowadays. It was a really good presentation on certificate transparency and and certificates yesterday. I don't know if you guys attend that presentation, but it was really good in talking about how easy it is

to get these nowadays too. The first simplest way is getting domain verified certificates. All you have to do is prove that you own the domain. So basically you have to do an email challenge response on a privileged prefix on the domain name like admin@thedomain.com. or you do a DNSC name change request, or you place a specific file in the root of the directory. Now this is extremely simple, it's completely automated as far as their validation processes go. As far as I can tell, it took me all of five minutes to get a HTTPS certificate myself, and best of all, it's free. At least Komodo at the time was offering 90-day free trials of the HTTPS

connections of their SSL certificates, and that's actually what Cofter was using. They were using the Komodo 90-day free trials. There was no cost of barrier to add HTTPS to all of their websites, all their phishing websites. Although I think nowadays, I think from the other presentation I learned that let's encrypt actually offers free certificates now indefinitely. They don't even need to rely on Komodo free trials. Okay, so basically reiterating what the other presenter said, the lock symbol does not necessarily mean trust. It means you have a secure connection to that server. It doesn't mean it's a trustworthy entity that you're connected to. It gives the impression it's safe and secure, better security reputation of the website as far as web reputation, like browser reputation and anti-phishing reputation

systems go, although I think this may be changing because there's a lot more abuse nowadays of HTTPS connections. And it bypasses some network protection platforms as well, which can only inspect HTTP content, which can't inspect the content of HTTPS. So secure lock symbol is not enough for trust, that's fine. So HTTPS, that doesn't imply much trust, that's fine. They own that domain, you have a trusted connection to it. What about for code signing? How do you get code signing certificates? Now this, luckily it's not free, at least in my opinion, luckily it's not free, otherwise we'd see more abuse of it. Komodo is the cheapest when I looked it up. You can get a one year for $85 for a code signing certificate, $85 US.

So it's a pretty straightforward process. You pay them the money, generate a certificate signing request, then the certificate authority is gonna validate your identity as an organization or individual, then you can download your certificate from the web and you can begin codesigning your software. Now the validation here is what's really key. Whether they validate whether you are who you say you are and whether you can defraud that system. So first, we're gonna look at how the individual developer certificate validation works for these certificate authorities. Um, so individual developers, the way they validate them varies a bit depending on which certificate authority it is. Uh, for Thought Symantec, for example, they require notary ID- notary ID

form, uh, a passport and two forms of ID, and a telephone call with a non-verified phone number, meaning that they don't have to verify that that phone number belongs to you. Komodo, for example, even requires a face-to-face verification as part of their individual developer certificates. And it requires a verified telephone number as well. So they need to associate the phone number with you as part of the phone call interview. So these look, it either involves a notary or face-to-face, face-to-face interview. It looks not that easy for attackers to cheat, but I definitely wouldn't say it's impossible. Yeah. How do they execute? - The face-to-face, do they have many locations where you could do it? - That's a really good question and I don't know the answer. Yeah,

they don't, yeah. They don't easily document everything for all the certificate authorities. You only can get the information once you start requesting the certificate. So I don't know exactly how they do that face-to-face verification. Maybe it's even a Skype. I don't know if they accept Skype. Wouldn't surprise me though, yeah. But the organizational certification process is actually what Cofter was abusing. So they were getting certificates in the name of organizations. So it's more standardized between the certificate authorities how they validate you are who you say you are as an organization. So it involves verifying that the organization exists, that the address is correct, and then they go ahead and call the business to make sure they ordered the certificate. So let's look more at

this because this is how- what the Koft or Maurer attackers were targeting. So I'd like to say disclaimer here from Komodo that, um, Although now we're gonna be focusing mostly on Komodo's verification process from here on forward, we're only focusing on that because that's what the Cofter malware was targeting. It looks like the other certificate authorities are similarly, have the very similar vulnerabilities in their validation process. So it's more of a industry problem rather than just a Komodo problem. So this is the preferred methods that Komodo does the validation of those three steps. So first off, the organization authentication is basically just checking the local government database to make sure it matches the company that you're requesting the certificate in. So I would just request

a certificate in the name of Microsoft UK, let's say, they would go to the UK government database and make sure that Microsoft UK is an organization exactly matching that within the country. Then they do the address verification where they validate that the address they're requesting the certificate in matches the address of the company. And now the last one is the telephone verification call. So here they look up a phone number for the business. Now they give that business a call and then they make sure that they ordered the code signing certificate. So it seems to make sense, especially the phone call part where they're gonna go ahead and phone the business. So let's have a

closer look at what Cofter did here. So, Cofter was impersonating a company called ITGMS Limited. This is a real UK company. This has a public filing available in the UK government database. And you'll notice that there's also an organizational email address associated with the certificate. They registered this domain, ITGMS.org, the week before they successfully got the codesigning certificate. So ITGMS is a real UK company, it's got one employee. Public UK companies have their documents of incorporation actually available on the government database. So all you do is download the certificate of incorporation and that's your proof of organization within that country for the business that they're trying to impersonate. So they're actually most of the way there already, just with that document of incorporation. All

they need to do is request the certificate in the name and address of the real organization, and they've already knocked off the authenticate organization and the address verification. It's that simple to knock off those first two verification points when you're getting the organization certificate. Now the hard one is the telephone verification call, because now they're gonna, Now they're actually gonna call, look up a phone number for that business, call them and make sure that they ordered the code signing certificate. So this is the only hard part of the attack process. So unfortunately it's really not easy to defeat, unfortunately. So the way that they verify the phone number, look up the phone number for the

organization, is their first choice is to use the online government database. So they're going to look at that online government database for that corporation in the UK and then they're going to see if they can get a phone number for the business. Now that makes sense but the problem is for example the UK government database does not provide phone numbers for any of those businesses. So they can't get a phone number that way. So then it goes to the alternative methods. So this is where they're willing to accept third party directories to find phone numbers for the business. And if you look here, they're willing to take Yellow Pages, Scoot, and 192.com. So these are verified, these are acceptable third party directories. So let's look at what 192.com

is. That is an online business listing directory. So if you go look at 192.com listings, It's an online directory which is automated populated of business addresses and most of them are unclaimed on there. And any unclaimed business, you can actually just click here and you can claim to be the business owner. It's extremely easy to do. You don't have to do any verification that you're the business owner. And then you fill out all the business information. You claim you're the business owner. You fill out all the business information including the phone number and then it shows up as status claimed. Meaning that now no one can modify the details of the business. So if we look in the Cofter case, the ITGMS limited 192.com listing was tampered with. It

was claimed by someone and the phone number was set. They set the website to be the domain that they had registered the week before successfully getting the certificate. And when you edit the business listing here, you're required to enter a business description or it won't let you save changes to the website. So it's clear this person, English wasn't his first language, but was required to enter a description for the business. So, looking pretty bad. What about a local phone number? How do you get a UK phone number? It cost me all of 50 cents to get a phone proxy, so I got a UK phone number, which would redirect my Canadian phone number for just 50 cents. So it's not hard

for the attackers even to get a local phone number, which they would attach to that listing. So now, of course, you just wait for them to call you, and you just claim, yes, I am IGTMS services, and yes, I ordered that certificate, and there you go, you got your code signing certificate. in the name of a different business. So why did they register igtmess.org? This puzzled me for a while because nowhere in the attack process did I see why they needed to create that domain as part of the attack process. So it wasn't until I went through all the steps myself that I figured out why it was needed that they registered the domain. I

went almost through all the steps. I didn't answer the phone as a disclaimer. You can't do organizational certificate requests on a personal email address. So they block list all the Gmail, all the generic email providers. You can't generate this organizational certificate request on a private email address. It has to be an organizational level email address. I tried to circumvent it with a few different ways, but I couldn't circumvent it. So I also had to register a domain to get an email address to try out, to investigate the process. So summary of the tax steps, I think we just went through this. All they have to do is find any incorporated UK company, preferably really small and preferably without a website or phone numbers that they could easily

find. Register domain name under the address and name. Take ownership and create the listing or create the listing. I think most are created by default. It seems like 192.com is taking the listing of directory on the UK government database and automatically creating placeholders. So then you just request a code signing certificate in their company name, address, email address. Now you wait for them to call you and you verify. Now you got the certificate, it seems to work. And that looks like what the attackers were doing in this case. - So this isn't just a Komodo problem, like I said. I didn't go through all the processes for the other certificate authorities. They had the same three components of the verification. I was able to find reference for Thought,

for example, where they actually, for phone numbers, the corporation listed can be through a third party source, such as approved online phone database directories. So I suspect Thought would take the exact same online phone directory as well. So code signing certs as a service, malware authors don't like to figure out all this process themselves necessarily. So it might not be that the Cofter authors actually acquired the code signing certificates themselves, they could have just bought them off another person on the underground market. A quick search yields, I can find someone selling trusted code signing certificates for $500 a pop. And he's targeting selling these certificates to malware authors. So in conclusion, the code signing Trust system isn't so trustworthy. But CAs do have a

really tough job. There are hundreds of countries around the world. How do you validate organizations exist within hundreds of countries around the world? A lot of them might not even have listings of what organizations exist within each country and all the languages you're dealing with. And you want to be able to support them getting code signing certificates. And fake phone bills. Phone bills is another way that you can associate a phone number to an organization. How would you detect fake phone bills across so many different phone companies in so many countries in so many languages around the world? It's a really difficult task, which is really hard to do well. Even just notarized forms, how do you validate all the notaries and how do you detect

notary impersonations even across so many countries? So perfect validation is not gonna happen. The more validation that we add, the higher the cost we add to getting codesigning certificates, as well as the more effort it takes for businesses and individuals to get codesigning certificates. So this is gonna result in fewer companies and individuals codesigning their code. We're gonna have less codesigning in general, but it'll be more trusted certificates. So will this result in better or worse security is the question. Increasing the validation, increasing the cost. It's what we need to think about. It's not widely abused still, despite the malware authors clearly knowing about this. It seems like they're not getting their bang for the

buck, their value out of getting these code signing certificates because they often get revoked. They only have a few days to work with them after they purchase it. If an attacker bought that $500 code signing certificate and used it for a few days, it would have been revoked. He would have been out $500, at least in the commodity malware area. when in the target attack area, they're able to use codesigning certificates for a really long time because they need to be detected first of all. Codesigning certificates will be quickly revoked. - Oh yeah, first point was there's a cost to getting code signing certificates. I think that is the most important barrier. If we decrease the cost of code signing certificates more, I think we're gonna

see even more abuse by malware targeting code signing certificates. But the cost of barrier combined with the fact that they're gonna be revoked quickly makes it not that juicy of a target for malware authors at this point, luckily. It's difficult to pay anonymously with currencies like cryptocurrencies, at least for whoever it is who's doing the work getting the codesigning certificates. And I'm still a huge fan of codesigning, at least from the AV perspective. we get a lot of value out of people, out of everyone signing their code. We can false positive less on applications which are code signed. We've got, even when malware is code signed their code, it's easy for us to add a detection which detects everything signed with that digital certificate. So I'm on

the fence about this, but I don't know what's the right decision here about the cost. So I'm not sure if a costly change is needed, but I think it might be needed in the near future if we start to see more rampant abuse of this codesigning. Extended validation certificates already exist. So this is codesigning certificates which go through a much more extensive validation process which is already offered by certificate authorities. So now the problem with these is that they're very costly and they're quite a process to acquire as a security vendor too. And also with these extended validation certificates, they're held on a special USB device. At least I think they're held on a special USB device where it's very difficult to extract a private key from

the USB device as well. So it's designed to not be an extractable private key. So it can't be stolen so easily. Extended validation certificates also provide default levels of trust in a lot of security platforms like SmartScreen, Microsoft SmartScreen. Users aren't going to be, they're going to have a positive reputation from the get-go because of their reputation, because of their validation process they went through. So security researchers, a couple notes are, of course, code sign does not necessarily mean that you should trust the file, though in most cases it's true. When you observe malware abusing code signing, notify the certificate authority for revocation. It's usually really easy to do, just like upload a file to

VirusTotal and then you can just send a link to that VirusTotal to the certificate authority. I think they all have abuse emails. You can just report it directly to them and they'll revoke the certificate. Usually I think they want to know whether they want it revoked from a specific date or like if it was a stolen certificate or from date of issuance. If you don't know the answer, then I think I'd still report it and I guess they might revoke it at least from that date or something. For CAs, there's already a framework called certificate transparency that you may have heard about from a talk yesterday. Certificate transparency is a framework for HTTPS, TLS, SSL certificates, which allows you as a business to be notified if

certificates are issued for websites that you own. So we as Microsoft can be notified if new SSL certificates are issued for the Microsoft.com domain, allowing people to man in the middle of traffic. So this is really helpful to protect your identity, but the problem is there is no similar framework for code signing certificate. If someone were to be issued a code signing certificate under the name of Microsoft, and I don't see much in the way of the processes that might prevent that, we wouldn't find out until they started distributing malware code sign under our name. And I think they should be looking into hardening the validation without increasing the cost with ease of access. And now I don't know exactly what that should entail,

it's a really challenging problem. And most of the, just as a note, most of the certificates which are targeted are not targeted in the UK, like a lot, most of them, I'd say like 80 or 90% of them nowadays are either like Eastern Europe or Russian certificates, and it's very difficult to investigate about how they actually got a hold of those. But I suspect it's a very similar certification process that they're fooling. Organizations, you can claim your public listing. This will prevent them from impersonating you as a business. At least it'll make it a lot harder for them to impersonate you as a business. You can use Bing Webmaster Tools, which allows you to monitor certificate transparency for certificates issued in domain names that you guys own. And

I think we could really use certificate transparency to code sign in so that we, again, the same point. and use extended validation certificates when available, that is a stronger authentication that is you guys as a business. Okay, that's all I have. Thank you very much guys. Okay, any questions? Oh, cool, thanks. Sure, yeah, I'll get to you after. Oh yeah, you. Yeah. Yeah. Yeah. Yeah. Yeah.

- Yeah, so the organization name is actually, must exist in the government database within that country, so maybe we as Microsoft could register for notifications of any organization name involving Microsoft, might be a guess. But then what if they call themselves Macrosoft, or a play on it? But that's a different story, yeah. So I guess that would be my first thought, would be look for keywords like Microsoft, like your company name. Yeah, sorry, you have a question?

- Yes, yes, so they have one code signing certificate for each attack. So the one I showed you was the one from the UK. The other two, it looked like I think they were Russian code signing certificates, so they weren't UK, impersonating UK companies. It looked like they were impersonating Russian companies. So I suspect it's probably the same exact process, but through Russian companies, yeah. - Yes it would, and it wouldn't say it was verified by Adobe, it would say it would be verified by ITGMS Limited, but I think they actually weren't throwing the UAC prompts, so they actually wouldn't have seen the organization. So it's mostly, I think they're mostly using it for the browser reputation,

so browsers would not warn the user you're about to run an unsafe file that we haven't seen much before. So I think they wouldn't actually see the company name normally. Yeah, exactly. Yeah, yeah, exactly. Cool, question? Yeah, so that's a really good question. I know there are, Microsoft does have representatives who are part of committees which decide a lot of the minimum requirements for validation of the CAs and things like that. Now, I'm more of an antivirus researcher, so I'm not really involved in those processes, but I know they exist, but I don't know too much detail about that. We have reported this to Komodo about a year and a half ago or so. They're aware of the issues.

- Yeah, that's a good point. Yeah, it seemed like for the organization validation they're very similar. Yeah, so it's a tough, yes. Yeah, so the certificate authority just validates them as an organization, then gives them the certificate, so then they can sign whatever they want with it. So the certificate doesn't see the files that they're signing with it. Yeah, so like, yeah, so. - Yeah, so in Windows Defender I can say we do a lot of reputation based on digital certificates. So like if we see a code signer signing a bunch of malware, it'll start to, that entire code sign and certificate will start to have a bad reputation, for example, if that's sort of what you mean. But I think like a lot of automation systems at AV

vendors in general avoid adding signatures against code sign files 'cause it usually means it's a false positive in most scenarios. So therefore they get quite a bit of benefit by avoiding a lot of our machine learning models and automation systems by codesigning their files because we're very afraid of false positives. So they're able to successfully evade some systems by doing so. Until they get a bad enough reputation. Any other questions? Okay, yeah, thank you very much. - Bye, perfect.

Awesome. So, hi guys. My name is Justin. I'm really honored to be here at B-Sides Vancouver talking to all of you and kind of being one of the last talks of the conference. The link up there is because I'm going to leave time at the end for questions and so like whether you have like a trolly comment or a genuine question, like please feel free to shoot it onto that and like in theory Google Slides will make it work for me. Cool. So, First, just a brief background. Like I said, my name's Justin. I'm currently a CISO at a company called Zenefits. We actually have offices here in Vancouver in addition to SF, Bangalore, and Tempe, Arizona in the US. Before this, I've run security at healthcare tech organizations,

hedge funds, been a consultant all the way up from the super junior consultant through a principal level, and been an actual app developer. The point I want to make with this is not like, "Oh, look at my CV." It's that I'm a technologist at heart. I care more about understanding and doing the right thing in security than I do about compliance or other issues that CISOs face day to day. And before I kind of jump into the meat of the talk, I want to say just a couple words about what I'm not going to talk about to you guys. So let's acknowledge that like in my role and for a lot of people in their companies, we have two different kinds of questions when someone says, "Are

we secure?" We have the first type, which is kind of with the security team. And my job is to use that question to actually help drive the right investment, whether it's in processes or technology or policy or anything else. And the other part is for that external stakeholder group. So whether that's your board or your auditors or your customers, like, answering for your external stakeholders is much different than answering with your security team. And in this talk I'm not gonna focus on the everyone else conversation. There's, you could, frankly there's people that are better than me about talking about that and it's a much different talk to give. This talk is for security practitioners. All

of you in the room, I'm guessing you are. And specifically it's for all of us to get to kind of real practical ways of measuring ourselves and our programs to see if we're actually secure or just think we are. So first, why does measuring even matter? So I think it's really important that for those in the audience who may disagree here, I'm gonna be honest, this talk is not gonna be that valuable for you. Because I believe if you can't measure something, then how do you know if it's actually moving in the right direction or not? How do you know if you're moving the needle on a risk or not if you don't have any

way of measuring that thing? We all have limited budgets and we all have huge challenges that face our organizations and I want to know that a control is working, not suppose. I want to know that an attack path is closed down and I want to know that the resources that I do have are being applied effectively on moving the needle on the risk that matters for my company. So measuring doesn't actually have to mean creating arbitrary numeric values. I know probably lots of us have been in organizations in which we have just faced off against this massive number of operational data points that we are expected to capture every single day. And my point is not for us to step back

and start trying to invent tons of new numerics. I don't need to create a framework of operational measurement. I think XKCD said it best when they said like, every time you want to invent a framework to unify a bunch of other stuff, you end up creating another framework that people look to. So the key here is can we measure even qualitatively, did a control stop a thing? It's a pretty binary measurement. The key in measuring this