BSides St. John's 2023 LIVE!

I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice.

I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice.

I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to eat a lot of rice. I'm going to

Yeah, absolutely. put it up here yeah yeah uh Watch, we've agreed. We've agreed. Thank you.

♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪

♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪♪

All right, we're going to get started very shortly. If anybody could go out and tell the folks out there to come in and take a seat, that would be greatly appreciated. Apologies for running a little bit late here today. Apparently there's some accidents, so we wanted to give folks time to get here and get situated. All right. Can everybody hear me okay? Awesome. Awesome. So, good morning, everyone, and welcome to the 11th Annual Security B-Side St. John's. So, yeah, 11 years. Absolutely amazing achievement. Thank you. Thank you. We are still one of the longest running B-sides in Canada and one of the longest running in North America. Again, quite an achievement. Honestly, it's pretty amazing to see the growth that we've had in

the security community here in the province. I can remember back first B-sides 2011, I don't know, there might have been 60, 70 people max. We've reached a point now where today we have 225 people with 135 people on our wait list that couldn't get tickets. It's unfortunate they couldn't get tickets, but it's also a testament to the amount of work that has gone into growing this community. It's actually pretty humbling. It's pretty cool to look out over the audience and see a lot of familiar faces. A lot of people have been with us pretty much since the beginning, but also new faces. It's really nice to look out and see. It's really nice and quite humbling again. Yeah, you should all be proud. It's quite an achievement.

Every year I get comments from people about... Not introducing myself. I get up here and talk every year, but I don't say who I am. And, you know, I'll be honest, the speakers today are far more interesting than I am. But for those that don't know me, so my name is Robert Percy, and I'm the VP of Security IT and Cloud at a local company called CoLab Software. And I am one of the many volunteers that make this event possible for you. If you want to connect and learn more about me, come up to me, introduce yourself, have a chat, reach out to me on LinkedIn. I'm a half friendly person, so reach out. I love a chat. We have a great lineup of speakers today. So

with that, I'll keep it short, and we're already behind schedule. I do want to start with a special thank you to all of the volunteers that make this event happen. Most people don't realize there's an absolute tremendous amount of work that goes into making this event happen. The amount of work that happens behind the scenes is phenomenal. And this entire event is done essentially off the side of our desks as volunteers. It's done after hours, lunchtime, whenever we can get the time to do it. So all the volunteers have blue t-shirts on. So throughout the day, please go up, talk to them, say thank you. It won't be possible without them. And this year, I do want to say a very

special thank you to Nancy Johnson. Previous to this, the amount of work that I had to shoulder was a lot, far more than I probably should have. But this year, Nancy took a large amount of that off my plate and said, I don't, it basically would not have been possible to pull off this event without your help. So thank you very much. Another very special thank you to all of our sponsors, obviously. This is a free event. All of our attendees come here for free. Everything you see is free. Everything during the day, everything in the evening, everything is free. So without the generous support of our sponsors, again, none of this would be possible. So, All of our sponsors that are Platinum sponsors all have booths

outside throughout the day. Go talk to them. There are other sponsors kind of embedded in the crowd here. Please, talk to them all. Hear what they have to say. They're all great. Listen to them. We do have our evening social this afternoon, and that's like our sponsor appreciation networking event that'll take place this afternoon. So again, go talk to them during that. It's going to be a great time. And of course, lastly, thank you to all of our attendees. Again, the response and demand for tickets was just mind-blowing, to be honest. The tickets sold out in less than 12 hours. It's pretty damn crazy. Sorry. I try to not swear every year. But I'm doing-- well, keep it PG.

So a few housekeeping items before I turn it over. If you have parked in the upper parking lot, we don't have that parking lot. That's not part of our booking. So if you parked up there, we're gonna have to ask you to move. We have the lower and the middle parking lot. If there's no spaces available, we have overflow parking at the geocenter and whatever overflow parking they have. So if you park there at some point, go and move your car. We do have lunch provided again today as well as our breakfast. We do have a limited quantity of gluten-free and vegetarian options, so please choose accordingly. Lunch will be downstairs, and to help with flow, we'll just ask tables to

go in order just to keep the traffic moving. Again, sponsor appreciation, social networking event is this evening. We're going to have lots of finger foods. That's all courtesy of our sponsor, Canary. They're sponsoring the finger foods for the evening, so a very special thank you to them. And at the same time, we'll be hosting our Capture the Flag event, and that is happening courtesy of Hack the Box. The evening social will start just after we've done our prize giveaways for the end of the day. And we do have some great prizes to give away. The Xboxes and the keyboards are prizes for the capture the flag. Quite a few other options there to give away during the day as door prizes. And of course our sponsors

have some great prizes that they're going to give away themselves as well. For our prize draws that use tickets, you would have gotten them at the registration desk. You have to be present to win. I just draw tickets, and if there's nobody here, it goes, and I grab another one. So if you don't have a ticket for the prize draw, you can go to the registration desk and get yourself one. As always, we will be having a bar that will open lunchtime and drink tickets are available. I think we're late getting the drink tickets, so I don't think everybody got one when you registered, but I'll be giving those out. The volunteers will be giving them out throughout the day. And very important to note for the drink tickets,

it's not just for alcoholic beverages. whatever you want. The tickets are for anything. So you want it, take it, drink it. There should be some water on the tables. There's soft drinks, I believe, outside, juice. And if you don't see something that you want, ask about it, and we'll see if we can get it for you. And of course, you know, we are serving alcohol, so it goes without saying, absolutely do not drink and drive. If you need a cab at the end of the day, or you need help, just let one of us know. We'll get a cab for you, not a problem. And of course, if you have any questions or concerns with

anything that's happening today, or if you need any help at all in any way, you can come talk to me directly, or talk to one of the volunteers, and we'll help you out. So, as many of you know, TechNL, they have been a, what I would call, a very strategic partner for us for quite a number of years, I believe going back to 2014. And honestly, without them, we would not be able to pull off this event. They take care of a tremendous amount of stuff that happens behind the scenes for us, including all of our sponsor invoicing, all of our, you know, invoicing payments, reimbursements, all that stuff is all taken care of. So I do need to say a very, absolutely very special thank

you to Allison at TechNL for handling all of the invoicing and the financial part. Her support is, has been nothing shy of extraordinary. She's an amazing person and we absolutely very much appreciate everything that she does for us. So to speak a little bit more about TechNL, who they are, what they do, I've invited Marlene Hardy from TechNL to join us and kick off our event. Following Marlene's opening remarks, Chris Parsons is going to keep the day moving by introducing each one of our speakers as they come up. And that is it for me. I really hope you have an absolutely wonderful day. Thank you. Do you want that microphone or do you want one of the... This

is fine. That one's good? Awesome, thank you. I'll move it down. I had to stretch it up. Good morning. How exciting, you sold out in 12 hours. That's amazing. So congratulations to Rob and Nancy and all the B-Sides team for putting off this incredible event. And TechNL is thrilled to be a partner. It does predate my time at TechNL. I'm Director of Innovation Programs with TechNL, and I've been with them about four years. And I also had to go back and say, how long have we been doing this partnership with B-Sides? So we are thrilled to be partners and congratulate you on another wonderful day today coming up. So if you're not familiar with TechNL, we are a non-profit

membership association and we represent 266 member companies and organizations as well as the Newfoundland and Labrador tech sector. Our purpose is to enable a thriving innovation driven economy here in Newfoundland and Labrador. and our vision is to make our province the most sought-after Canadian tech ecosystem and to be globally recognized for our collaborative community, diversity and exceptional quality of life. The programs and services that TechNL delivers provides visibility and a collective voice for the sector. We also focus on business growth, which encompasses a wide range of programs and services, including cultivating the talent pipeline, creating member connections, advancing digital transformation, and overall ecosystem development in our province. Our tech sector is consistently punching above its weight, and with so much growth and success, it's unique and

attractive both to Newfoundlanders and Labradorians and to those outside our province and our country. One of the benefits of being a smaller ecosystem is how collaborative and accessible our tech sector is. We consistently hear how our tech company leaders are exceptionally generous with their time and expertise, and we regularly see members of the tech sector collaborating to help others in the sector succeed. Over the last year, there have been many groundbreaking and exciting developments in our sector. For example, AI coaching startup Trophy AI received more than 3.3 million in funding. Medical AI startup Cifmed received 2.7 million and legal AI company Spellbook raised 10.9 million US. And those are just a few examples of the

wonderful things that are happening in our sector. Our technology landscape is undergoing tremendous transformation and growth. and TechNL, together with our industry partners and ecosystem stakeholders, have played a pivotal role in supporting this evolution. The theme of our last annual report was "Leveling up the Tech Sector" and we see every day, through our work with members, the tech sector is really reaching new heights. In the past year, TechNL achieved two significant milestones and the largest investments in our tech sector here in Newfoundland and Labrador. We announced the Innovation Centre for Remote Operation, which will open in the new year, and we launched a $27 million Find Your Future in Tech program. Both of these significant initiatives show that our province and

country see the pace of change and growth of our sector, and that we are being recognized by what we are continuing to build. With these two monumental projects alone, in the last year our budget at TechNL has grown from approximately $4 million to $40 million. This tremendous growth is a testament to the immense potential of our tech sector and of the impact that TechNL is committed to continuing to develop, not only for our tech sector but the province as a whole. The Innovation Center for Remote Operations is a game changer. It will address the technology development needs of established and growing companies, particularly those engaged in remote operations across sectors like ocean, energy, healthcare, mining, fisheries, transportation, defense.

This includes solving challenges, facilitating learning from peers and experts both locally and internationally, and providing access to physical and digital spaces for demonstrations. The Innovation Center will be the first of its kind in our province and will produce stronger, innovative exports to meet industry needs and foster more collaboration within our ecosystem. This past February, we launched a $27 million project, Find Your Future in Tech, which is a collaborative effort with 11 partner organizations. This is the biggest investment in our tech sector to date. This groundbreaking program is dedicated to training and upscaling Newfoundlanders and Labradorians with a special emphasis on equity deserving groups. It is a critical initiative for the growth of the tech sector in our province, bringing together private training providers, private companies and

public post-secondary institutions like never before to offer meaningful and funded training opportunities to bolster our province's workforce. with a solid foundation of tech skills that our province will continue to need in the future. As part of this program, Keehan College is offering two micro-credentials for Cybersecurity and AWS. There are currently just a few seats left for the Cybersecurity track, but there are additional cohorts open for registration through to March 2024, and new slots are always being added. So these micro-credential programs are available with flexible and self-paced learning options. There are live instructor-led classes and other self-study materials included. So for more information about those programs, you can check out the website findyourfuturenl.ca. So as part

of that Find Your Future in Tech program, an awareness and marketing campaign will be launched this fall during TechNL's Innovation Week, which is happening at the end of October. The campaign will highlight the incredible place in which we live with technology at the forefront and will showcase our diverse and passionate tech community connected to a unique place that cultivates innovation. There are limitless opportunities for potential for growth here in Newfoundland and Labrador and this campaign will help attract and retain talent right here. This exciting campaign will raise awareness about Newfoundland and Labrador's burgeoning tech sector, positioning it as the destination for tech companies. Many people mistakenly believe that tech careers can only be found in big cities, but our incredible member companies have continued to prove

otherwise. Our province boasts a thriving tech sector and a vibrant, diverse and passionate tech community anchored to a unique place that inspires resilience and innovation. We celebrate those local successes and showcase our tech sector as an exciting opportunity for building a world-class career right here in Newfoundland and Labrador. And the B-Sides Convention is part of all that. So as you engage in your sessions today, I encourage you to keep in mind the incredible journey that our tech sector is embarking upon. Together we are shaping the future of tech innovation in our province, and we invite you to be part of this remarkable journey. Innovation Week is happening October 31st to November 2nd here at the St. John's Convention Center. So I

hope to see many of you there and you can find more information on our website. So thank you for your attention and have a wonderful day. - All right, thank you Marlene and welcome back to B-Side St. John's for 2023. We're gonna kick things off with a talk that I'm really looking forward to. Here is Glen Stacy. - Oh, don't set me up to fail. We're going to start off strong. Yep, okay, perfect. Yep, just got to hook up my laptop. We'll be all set. Make sure the sound works on the computer. Let's just do a check, check. I'm going to give it away. Perfect. All righty. And make sure this works.

Alright, my name is Glen Stacy. I'm the regional director for Fortinet for all of Atlantic Canada. We've grown a lot. I've been with Fortinet for about eight years now. We've grown a lot in Atlantic Canada. I actually live here. So I'm from Newfoundland, grew up in Newfoundland, grew up in Mount Pearl, moved away for a little while, and now I'm back and I love it. So I'm in Conception Harbor, Newfoundland, but I am the director for all of Atlantic Canada. Seeing everybody here, there's a lot of faces that I recognize over the years. I've been in this industry for 27 years now. As an engineer for 26 and a half of those. And financial director for the last five months. So we're going to go through some stuff.

The topic that was on the actual thing, I'm not doing that. We had a different speaker going to do it and it was all super high level. Yeah, that's not me. So I spent two days with one of our inside of our organization with a guy that actually goes around in deep web, dark web, and I've seen a lot of cool stuff. I got really excited, so I created a whole presentation around what I've seen. And a lot of it is towards ransomware, because ransomware is actually not the same as it used to be. It's very, very, very different than what everyone thinks it is. So let's just go through it. So let's go through episode one. So this hasn't changed. The reason why most people get hit with

ransomware is financial gains for these organizations that are doing the ransomware against you. One thing that has changed though is the espionage piece. So that's getting bigger and bigger. We've seen a lot of it now, especially around what happened with the Ukraine. There was a ton going on there. There was denial of service attacks against the organization or against the country, trying to disrupt anything that was going on from a military standpoint, trying to get internal information from the government. Yeah, they were three and a half days trying to stop the DDoS attack from Russia against the Ukraine and it was all around the espionage side of the house. This is an interesting slide. This actually

surprised me immensely. 6.9% of ransomware happens in phishing. 6.9. Four years ago that was 89%. Four years ago. Now it's not. Valid accounts is the biggest thing now. By far the biggest thing. So if you look at this, valid accounts, exploit public facing applications, so anything that you have out there that's public facing, and external remote services is where most of the ways that they're getting in to hit you with ransomware. So if you look, possible to mitigate 82% of intrusions just by changing your role-based access. That's the way it is today. Like I said, it used to be phishing and you used to get a file through email that you clicked on some kind of botnet that caused you

all kinds of issues. Someone downloaded some malicious piece of software. That still happens, don't get me wrong. It's just not the number one way people are getting in. Also, for the most part, antivirus will not work with ransomware today. And I'll show you how that works. The zero malware attack. So in our ultimate wisdom as IT people, we've created all these security capabilities within our OS. So Microsoft has built in BitLocker inside of the Microsoft OS, which does what? Encrypts your hard drive so that people can't get your data. Well, how many people here are actually using BitLocker in their organization to encrypt their hard drives on every machine? Not many, right? We're what? Less than

1%? But this is still on the machines. So what hackers are doing is they're getting in and they're actually encrypting you with your own software. There is no bad, there's no malware. There's no malware. How is antivirus going to pick it up? It's not. It's not going to see it. And by the way, all of these are different things that people can get in because it's built into the OS, right? So the days of, oh, you know, I downloaded a bad file and I clicked on it and it created something. some kind of ransomware which the last going off when it was super prevalent was about 18 files that would get built on a machine

so again antivirus wouldn't work then either but now they're actually using your software against you there is no malware here no malware no antivirus is going to pick it up like this really surprised me that this is actually one of the number one ways today that they're actually encrypting you let's go through something so big game hunting Most ransomware organizations are still going after big organizations with big paybacks. OT. OT is the number one thing that people are going after today. So when we went through everything on the dark web, well, deep web first, and I'll talk about the difference between the two. A lot of it was, a lot of the work that hackers are actually creating is around the OT side of the

house. It's the biggest opening for most organizations today. Because let's face it, OT environments have been in place for 25, 30 years. OS wasn't created 25 or 30 years ago for OT. There was no security in the OS. They're also headless. There is no two-factor authentication. There is nothing for an OT environment. So that's a good place to go in. Also, it's very disruptive, right? Take out a power grid, take out a healthcare infrastructure, take out a government, all based on the OT side of the house. But there's lots of conflicting information. So Veeam published that 80% of all ransomware gets paid. Other organizations say that they don't pay ransomware anymore. Cybersecurity insurance companies, especially in Europe, are saying we're not going to pay out

for ransomware anymore. It's just too costly and if we keep paying the ransom then it's going to keep the business alive of ransomware. Well, near the end we'll go through a debate on that, whether you should or you shouldn't. But really, What we're seeing is in 2021, there's a 10% increase. 2022, there's a 16% increase in the amount of ransomware. And a lot of that's got to do with ransomware as a service. So these organizations are actually now created. Actually, I'm going to show you kind of, is it on the next slide? I'm going to show you organizational, how they're built. They're actually built like any other organization on the planet. Their help desk, I wish every help desk on the planet was as good as their help desk.

And I'm going to show it to you. Very cordial, super businesslike. You think it's all cloak and dagger and some guy with a wife beater shirt on and stuff. It's not. There were suits and ties and CFOs and CIOs. It's insane. So when I was on the dark web, we spent about two hours kind of going through stuff. You can buy anything you want on the dark web, like seriously anything. And the reason why I have up even mermaid tails is because for $10,000, you can get an authentic mermaid tail on the dark web. It's everywhere. There's everything from drugs, the guns, to a tank. Could have bought a tank the day before yesterday if I had the money. It's all there. Like,

everything is there. So this scared me, this slide. When we went through and looked at the numbers, only 4%. So think of the entire internet worldwide. Everything that you search for on a regular basis. YouTube, you know, anything. Anything. Twitter, Facebook. any kind of news, anything that's out there, only 4% makes up searchable information. 4% of the entire internet makes up searchable information. 96% of all traffic on the internet is not searchable. Now think about that for a sec. 96% is made up of deep web and dark web. So money laundering, guns, drug control, everything else. And here, Deep Web, that's credentials. That's all information. Medical records, student records, everything else. That's all in the middle, not as dark as what's down here. So here, they're gathering information.

Down here, they're doing a whole lot of other stuff. That's completely legal and not fun. So from a business standpoint. So it used to be you'd have one organization that did everything. It's not like that anymore. So we have Access Broker. So this is a company, and I'm going to use the word company because that's what they are. They build entire infrastructures just to get credentials from you. They build social hacks. They build anything you want. They'll come up to get compromised credentials from you. But that's all they do. Then you have this ransomware as a service person. They're the ones that actually write the tools to actually create ransomware on your environment. So these are all the deep

tech guys that actually build all of the malicious tools that people will use against every OS, every software vendor on the planet, every hardware vendor on the planet. That's all they do. So these guys get paid on any kind of ransomware. These guys get paid on any ransomware, but they get paid less than this guy, which is the affiliate. He takes the information from both sides. And again, these are three different companies. It might be a little bit in the same company, but overall, this is three different organizations that are partnering together. They partner together to create this. These guys get the most money out of a ransomware because they're taking the biggest risk. They're the ones that are actually hitting you. They're the ones

that are actually executing the ransomware against you. So they take the biggest chunk of whatever they get out of you. We can't think of this as cloak and dagger anymore. These are very organized, wearing suit people. It's insane. Only way to stop ransomware is to kind of make the field a little more level. So what they did, the FSB in Russia, they kind of said that they took out Revel are evil some people call, but it's like they call themselves revel so what give me a break 440,000 pounds that's nothing it's nothing to these guys. They're billions They're making billions and billions of dollars so United States if you offered a reward if you know of any person that's associated with revel

or Conti or oh another one kill net They'll give you $10 million if you can point them out and prove that they're actually part of that organization. That'll help, but everyone's scared to actually give up the, get the $10 million because now you have a very big crime industry coming after you. So until that levels out, the risk-reward kind of levels itself out, you're going to see this stuff. It's not going to change. The guy that hacked Yahoo and got all the emails, so he got about 2.6 million different email addresses and credentials. He then sold those to five different hacking communities for $318 US per credential. And he sold them five times. He got arrested. He was in Oshawa, Ontario. So he got arrested.

So they took all of his, you know, he had a Hummer and he had a Maserati and all this kind of stuff. They took all his stuff, but they couldn't find his money. So they put him in jail, but let's face it, it's a tennis club jail. It's a white-collar crime. He was in jail for three years. They sentenced him to seven. He was in there for three, got out after three on good behavior, and no one has seen him since because no one found his money. So now he's a billionaire, and he went to a tennis club for three years. I'm sorry, but I'm a straight-shooting, honest individual as they call me. Someone offered me to go to if I went to jail for three years

and came out with a billion dollars I'd go to jail for three years and come out with a billion dollars. That's that's family life-changing money forever, right? Yeah, so again as nice as I am it would be it'd be scary. This is also something interesting. So this actually shows most active ransomware campaigns that are going on which is a lot of them and This is the countries that are getting hit the most based on this is as of two days ago. But look where the majority of it's coming from. A lot of it's coming from Asia-Pac. Now, having said that, how do we guarantee it's actually coming from Asia-Pac? Because it might be Russia going through Asia-Pac to actually get out to do the stuff. So take some, you

know, just look at the numbers in a little bit of jest, but still, it's still massive. So as organizations, we should be putting in all kinds of geo filters of where the traffic is coming from, be very specific in where it's coming from to stop some of this. You're not going to stop it all, but stop some of it. So this is, I'm going to show you two videos, one from Revel and another one from KillNet. These were posted in June of this year. And by the way, I found these on the dark web, which is kind of cunny. If God rules Russia, then who rules Europe? That's right, the banking system. No money, no problem. Revel is sufficiently familiar with the European

financial infrastructure. See you soon. Yeah, that was just June. Like it's insane. I mean that's really cloak and dagger. That's something that's going to come out of Mr. Robot TV show, right? I mean it's kind of interesting to see, but they're still doing it. And they're calling out to other organizations to join in with them to actually do it. And when I say organizations, I mean other bad actors, okay? So it's getting more and more and more organized. So let's go into ransomware attack real quick. So this is the business of ransomware. That's exactly what this is. So, we have these crimeware producers. They're developers, the same as every developer in here except they're creating all kinds of nasty stuff. They have senior

developers, junior developers. They all work from a central source code. They turn around and they sell their information to criminal organizations. As far as I'm concerned, this is also a criminal organization. They sell that stuff there. Criminal organizations have sales, marketing, support. They have these people and they're very nice about it. They do partnerships with different affiliate programs and then they have all kinds of people on the consulting services side. So they have consultants on how to mule money between countries and hide it and everything else. These are three different organizations from each other. They are very, very, very organized. And not as cloak and dagger as the video I just showed you. So let's look at a timeline. Now this is an actual ransomware, and it is using

phishing. But let's go through it. So they do a ton in recon. This is where they spend most of their time, is on the recon side of the house. How do I get into your infrastructure? Is it credentials? Is it a phishing tech? How do I get in there? So then they turn around and they do a weaponized office document or something, a PDF of some sort, something like that. If that gets clicked on, so they send it as a phishing attack, if it gets clicked on, now you have your victim. Have the victim, malware is installed, usually a botnet of some sort, then the victim is infected, now the attacker gains control. Now here's the kicker. They have this long thing, this is a fairly long timeline, but

that could be really short or it could be really long. So they're already in. So the average is 21 days, so 21 days that someone's dwell time within your environment before you find them, usually 21 days. I've seen some up around 380 days. But 21 days is kind of the norm if you're a very good security posture as an organization. The thing is that they can actually tell if you're catching on to them. So until you know that they're there, they're going to download every bit of information they possibly can from you. Every record go east-west do whatever they can but if they find that you're actually catching on to them They'll instantly do ransomware instant. They'll stop right there and just go ahead and and deploy Okay, so

some kill change takes hours even weeks some are a lot shorter shorter So this is an actual fish fishing attack. I want I'm gonna pause this at one point so I This is just on a GitHub. You can actually go and download it. Actually, you don't download it. You actually go to their site. You actually run it. It's actually kind of neat. That's the technical guy in me thinks it's neat. It's horrible to people, but yes, it's kind of cool. So they go and they click on it. They run it. And I'm going to pause right there. Can I pause that before it goes? So they've already built All of these screens for all of these applications. It's already pre-built. I want to do one for LinkedIn? Click on

LinkedIn. I want to do one for Shopify and blast it out to a whole bunch of people? Go ahead. It'll create the screen exactly for what? I wouldn't say exactly. You can tell the difference if you pay attention, but most people don't pay attention. This is a lot. PayPal, right? So you can actually click it and they actually create it for you. It'll just run through. So choose 9, which is actually LinkedIn. So they run their server, goes through, actually creates it, gives you back a link. So waiting for victims. So there's the link. Now you put that link, you send it out to whoever, but if you click on the link, it actually pops

up with your sign-in for LinkedIn. This, again, you're not on LinkedIn. That's what it comes up and looks like. So, and then if you actually go and sign in, you can actually see a little bit of a difference here. So this is the actual LinkedIn versus the fake one. Screen backgrounds are different. Everything else kind of looks the same. So we're now going to actually log in to what we think is the real LinkedIn, but it's not. Once you actually go and put in your password and you sign it in, don't save the password. Don't ever save the password. It actually goes back here. It actually gives you all the information on the person. what IP address they're coming from, what agent they used, where they came

from, and then credentials down here actually shows you the actual password that they used to get onto LinkedIn. It's all there. Then you can actually test it if you want. Go ahead and download it and run it and see if it passes or not, which it does. I didn't create a bloody thing. I just clicked on a link and got someone to make it for me. It's getting kind of scary on how readily available this stuff is. Now, this is an actual... So I actually found, when we're going through stuff, an actual ransomware negotiation. And you'll see what I mean by the help desk. I wish every help desk on the planet was as nice

as these people. Because it is phenomenal. So this is what pops up on your screen when you get ransomware from this particular organization. A couple things I'm going to point out is do not touch anything because you may damage the files and we won't be able to do anything as the person who ransomware you to get it back. You have two days to get back to me, and if you do, you'll get a very special price. Very salesy. Isn't that cool? Limit time offer. If you get back quick, we'll give you a special price. Your whole network was fully compromised. We downloaded more than two terabytes of private sensitive data off your infrastructure. They're very specific. They will tell you, they even show from file structures that you

actually have in your environment. So let's look at the actual chat. So this is a chat room between an actual ransomware organization and a customer. So support, how can I help you? Hello, what do we need to do to get our data back? Get the data deleted first off your servers and unlock our files. Well, you have 30,000 infected machines in your environment worldwide. The price of $10 million, you get two services from us. We'll decrypt your stuff and we'll delete all of the downloaded information that we got from you. We'll delete all of it so we won't put it out in the world. And on top of that, we will actually, down here, we'll actually do two files for you to prove that we can actually

decrypt your files. Two random files just to prove. Because just so everyone knows, not all ransomware people out there, even though you get it and you're encrypted, A lot of them don't actually get the crypto key when they do it, so you pay it and they still can't decrypt you. So if you do get hit, make sure that you get them proof of life that your files still exist. But yes, support says we will turn around and we'll make it. We'll show you that we can. So in your message you left us, you mentioned a very special price. We reached out to join. We did get to you in two days, but how is $10

million a special price? They come back. Yeah, no, it's not special, right? But we did offer you a, we will give you a special price if you're willing to pay immediately. Okay? So their special price though is 20, they try and negotiate. So again, I appreciate the discount. I don't know about you, but as a customer, I would not be this polite. I wouldn't. Super polite. I guess they're afraid to piss these guys off. So anyway. $8 million is not really a special price either. They gave them 20% discount. They're trying to go in at $3.7 million. They come back and say, yeah, we appreciate your offer, but we're not going to touch that because

our service is very important to you. Right? So unfortunately, the amount is not good for us, but we'll give you another 5% in discount if you pay right away, or we'll put you on payment plan. Give me four million now and we'll decrypt all of your stuff and then we can put you on a payment plan and once we receive the rest of the money, then we'll delete all your files off our server. Like how cordial is this? Like this is insane. Also, part of their service is they tell you how to avoid this in the future. Again, how nice is Help Desk and Support to actually give you how they got into your infrastructure. Now, do I believe that this is how they got in? Yeah, I

don't know, right? But at least it's something to look at. They're saying turn off all local passwords, force end on administrator access, so have timers associated to it. In-group policy, set W digest to zero, so it never stores credentials, right? Most cases, enough standard Windows software. So what they're saying is that Don't count on antivirus. Antivirus will not work for most ransomware solutions today. Install endpoint detection and response security because that's behavior-based, not signature-based. Okay, so huge difference today than what it used to be. Also for huge companies suggest three system administrators working 24 hours, maximum of four men working three shifts, eight hours per day. I'm sorry man, but I don't know of any organization that has necessarily that capability. Also with the cybersecurity shortage, so

that's out there. Take a look at services to add and augment to your environment. Then they go back. Thank you for all this in a very timely manner. Again, super cordial guy. You're welcome. It's a pleasure to work with professionals. My help desk isn't this nice to anybody. So please confirm you write down all the important stuff because we're going to remove. But we'll leave the chat open to you for any support if necessary. Well, how nice of them. Just gave you $8 million and you're going to keep a chat open into a very bad organization. So, Just a couple closing thoughts. So these are lessons learned. This is for everybody. So patching, visibility, if you can't see it, if you can't see it, you can't protect it. You

just can't. It's impossible. So having traditional layer 3 at your core just doesn't work anymore. It doesn't because you're only seeing that layer 3. You're not seeing layer 7. So ensure you have the right tools. Oh, also, if you fail to plan, you plan to fail. So You should have all of these incident response plans in place. You should test them, not just put the plan in place, but test them to see if they work. And you have to include all scenarios, not just technical ones. Social engineering is a huge thing. Everyone's heard of MGM and what happened with them for the most part. That was social engineering. That had nothing to do with technical. It had to do with planning and procedures. It's not technical. Let's face it.

Vegas was created by mob. They have more money than anywhere on the planet. They can spend the money to put in the proper security, plus they have to because they're a lottery group. And they still got hit by something very simple, which I'm going to show you in a minute. So yeah, just kind of pay attention to some of this. Now this, I'm going to-- so chat GBT and all that kind of stuff, AI. So what we did-- and we did this actually on day four yesterday-- we put in a bunch of words. So we created this and then based on 10 seconds of recording somebody, 10 seconds, the AI came back with, Hi sweetheart, it's me. I've just been

arrested for speeding on my motorbike. It isn't a problem, but I need to pay $5,000 bail. Can you quickly send it to my bank so they can release me and I can sort this out? Here's my paid. Love you. Okay, so that's a 10 seconds. seconds of anyone in this room, like all of you guys could have been recording me for the last 25 minutes or 30 minutes, and you would get a much better sample size than 10 seconds. But this is based on 10 seconds. Okay? So let's look what happens with 10 minutes. So again, think of every public person that speaks in the world. Hi, sweetheart, it's me. I have just been arrested for speeding on my motorbike. It isn't a problem, but I need

to pay $5,000 in bail to get out of lockup. Can you quickly send the money through to the police station so they will release me and I can sort this out? Here's the police's pay ID. Love you. See, that sounds a whole lot better, but it's still only 10 minutes of a person's clip. So MGM Grand got hit because someone left a voicemail for support and support changed their password and sent it to them because they were high up within the organization. It's part of the reason why they got in. Anyone can do this. This is on any AI platform around the world. So you can do deep fakes, not only a voice, but you

can do it a video too. It's not a problem. As long as you've got some form of pictures of an individual, you can create it. Don't just think of the technical side, think of the social engineering side, because this stuff is coming fast and furious because it's all open. Hi sweetheart. Hi sweetheart. Alright, final thoughts. So I've got two, yeah this is a final thought. So, this is a company called Black Axe, they were created in 1977. They're a really nasty group of people. They have 30,000 employees, or Axemen. They're out of Nigeria. Their main business was, since 1977, street crime, torture, human trafficking, money laundering, that kind of stuff. But their number one revenue now is internet fraud. So think of it. In 1977,

there was very little internet fraud. But now their main revenue stream is internet fraud. That shows you what's happening with these organizations. Now, this is the whole debate of do you pay ransomware or not? So if you pay it, say against the company to someone like Black Axe, they're using that money to do more of the nasty stuff on the back end also. So it enables them to buy guns, hire more people, finance terrorist groups, that kind of stuff. But then you have the other side. A hospital gets hit with ransomware or someone's life's in danger. So again, I hate, I would never want to pay for ransomware because it just creates a business for them. If I'm in an alley and someone comes over with

a gun and asks me for my wallet, I'm giving them my goddamn wallet, right? I am. I'm going to give it to them because someone's life is at stake. So everyone can debate and do the high moral ground, say I'm never going to pay for ransomware. I don't think it's as cut and dry as that. So I want to make sure everyone understands if you need help with that kind of stuff, there's lots of people out there that have gone through it that can help you through it. And that's it. Thank you very much.

And we're by our booth is by the bar so anytime you want you can come and hang out. Oh So did everyone hear that So From my understanding, so don't quote me on it, but my understanding when we were going through it two days ago is because Turkey has some of the lowest IT capabilities in the world. They're not as advanced from a cybersecurity standpoint. So that makes them easy targets. Okay. Well, thank you. Any other questions? Wow, you guys are quiet. Again, we'll be near the bar. I bet you won't be as quiet then. So, all right. Thank you, everybody. I appreciate it. Oh, thank you.

Kevin's like me, hates standing behind the podium. - I got a pretty loud voice, but I'll use it. - Oh, he shut it off. I'll be back. - Thank you. - All right, thank you, Glenn. Next up we have Kevin Burgess. Good morning. First, thanks Robert and the team for letting me come in. I work for somebody that you probably never heard of and I'll talk about that later. I've been doing IT a little longer than Glen. I'm 30 years in this industry, which makes me two things. One, I've seen a lot of change and I'm old as dirt. So that's what I know about 30 years. I have worked, I started my career in the late 80s working for a small computer shop in Halifax. And then

from there I've worked for SI's, bars, manufacturers, customers, and now I'm back on the startup side. So what I think what I've learned over that time is there's always change and there needs to be change. And if we don't change, we die. We're like sharks and we need to swim. So when I joined this latest startup, it opened my eyes to a lot of things that that are changing in the world. I've known, done work with the cloud. In one of my last roles, I did a complete cloud migration. And this is something we all need to talk about. We all need to understand where, how cloud is affecting our lives. But from a networking perspective, because that's what I've

done for most of my career, it's about how do we protect ourselves and do it differently than maybe we've done it before. So I don't normally present at a lot of conferences events because it's not really part of my role, but when I did a B-Sides in Halifax earlier this year because this was super prevalent in the industry and I wanted to get it out there. So what I'm going to talk about is how does malware propagate through our companies? But not only malware, just breaches overall. And how do these things happen? And then what can we do to help prevent them?

Glenn gave a really good talk on the overall threats, and I think we all just need to know that they're out there. And malware, road access, breaches, is there anyone in the room that believes, and we just have to accept the fact that it's no longer an if, it's a when. He can't compromise this system that he's on. So, because it's a flat layer two network, he's going to then pivot. and he's going to look for other targets on that Layer 2 network. He's going to scan them, find one that's vulnerable, and then go take control of that system. He'll find the vulnerability, he'll exploit it, he'll escalate his privileges, and then he'll be able to do whatever he

wants. He can download ransomware, he could go on to another system and use that. This second system is not as well patched as the first system. That's why he's able to take control of it. And we all know we have, in most cases, most organizations have those systems that aren't as well patched. Why? I can tell you I've been in situations where we had a, believe it or not, a physical security server that was running on Windows 7 because the software wouldn't run on anything but Windows 7. We had no choice. So was it patched? No way. Glenn mentioned IoT devices. IoT devices generally don't get patched like the rest of us do with our systems. It just doesn't happen. So they're typically very vulnerable.

So we all know they're out there and sometimes we just can't do anything about it. So let's see if how this runs. Hopefully it runs well. Click. Hi everyone, Chris Tristan here with Niall. And I'm gonna go ahead and run a quick demo of what could possibly happen on a traditional layer 2 based network where you have multiple users and devices on that local LAN on the same IP subnet. Now, the first example of what could possibly happen is you have a user who becomes socially engineered, downloads some application that they're not exactly sure what's in it, and they go ahead and run the application. So when that application is run, what could typically happen is there's somebody from

the outside hosting a service that will terminate these reverse shelves. So I will go ahead and run this and right away you can see that because I ran that application on that Windows workstation, it is running a process in the background where it is essentially opened up a reverse shell all the way back to my server here and now I have established a backdoor access. So the expectation here is that this workstation is pretty well patched. But what you're looking at right now is that I have actually, through this reverse shell, gotten access to the local command line prompt of this workstation. Now, If I wanted to, I could dig a little bit deeper and look through the directory. And right now you can see that I'm sitting

directly in the downloads folder. But what might be more interesting for me is if I were to back out of this shell and try to get the elevated privileges on the system. Now, because this workstation is patched pretty well, it's not going to be very easily exploitable for me. So what I'm going to do is try to find another workstation or scan their network and see what else might be available. So something fairly simple is just going into the shell of that workstation and just taking a look at what might be available by running an IQ config, just learning what network they actually sit on. And then I can actually do something like an ARP and

see what other workstations might exist. And right away I can see that there is a workstation sitting adjacent to this one with an IP address ending in 20. Now, I could run some additional port scans, but there's really no need to. I'm going to go ahead and try to check if that workstation is vulnerable. But I'm going to use the workstation that I'm in right now as a jumping point to do so. So this would be an example of lateral movement, which is too easy on a VLAN-based network and very hard to detect, especially if that network is further away from a border firewall in that customer's environment. So let's go ahead and do some lateral movement here. So I'm going to

go ahead and exit out of this session, out of this shell. Then I'm going to background this session that I'm in. And I'm going to go ahead and add a route to my Kali workstation to access this 192.168.10 network through the session that has been established. So if I just want to be, I just want to make sure I gather the right session. So here I have session ID of 5 and it's sitting over there on the 192.168.10 network. So I'm going to go ahead and do route add and I'm going to go ahead and type in the network that I'm looking to scan. Go ahead and type in the netmask and then I'm going to tell it to reach that network through session 5. Okay.

Then I'm going to go ahead and search for a port scan tool. And then I'm going to go ahead and use the fifth option to do a TCP scan. And then I'm going to go ahead and set the remote host. And because I know it exists based off of the shell access I got earlier, I'm going to go ahead and scan this workstation, 192.168. The idea here is that it's widely available because... I can access it right across that same VLAN based network. There's really no controls for me to stop me from doing that. I'm going to go ahead and run this scan and find out what ports might be open. Okay, so that's interesting. Right now I can see that RDP is

open through port 3389 and some version of SMB is open. So now I'll go ahead and search for the EternalBlue because I know that that will utilize port 445. I'll go ahead and check if that machine is indeed vulnerable by scanning. We'll set the remote host to that workstation that is sitting adjacent to us here. And we'll run the scan and check what the workstation reports back to us. So it says here that it is likely vulnerable. meaning it is running an older software version where I have a great chance of exploiting this machine successfully and gaining elevated privileges. So I'm going to go ahead and run option one to try to use this payload against it. So I'm going

to set the remote host. We're going to go ahead and try to hit that same workstation. And let's go ahead and run that. looks successful so far. We have established a session with it and we're now trying to exploit this workstation. And just like that we have established a meterpreter session on a second workstation that is adjacent to the original workstation that we have gained access to through that reverse shell. Now what is interesting about this is that this workstation was not patched So as you can see here, I have full access to this system and if I want to access the shell further, I can and I can essentially migrate any process and run further exploitation against this device. You

can grab screenshots, access cameras, run keyboard scanners, etc. So just to reiterate the point One more time as to how this demo went is the two workstations are resigning next to each other. I'm going to stop it there just because he's just going to recap what we did. On a standard layer 2 network, all he did was run ipconfig arp -a. Sees everything because that's the way Ethernet works. Ethernet says everything is out there. I should be able to see it. The problem with that is if I can see it, I can do that. So for the most part, this is the way we built networks for the last 30 years, once we started using Ethernet.

If you're looking at real defense in depth, and you've looked at, "I got my workstations covered, I got my firewall covered, I'm doing EDR like Glenn mentioned." Why are we leaving our networks like that? So the company that I work for is called Nile. We're a John Chambers startup out of California. Hopefully most of you know who John Chambers is. He was former chairman of Cisco. We came out and we said in 2018, there's got to be a better way of building networks. There's got to be a better way of managing networks. So we are a pure networking as a service organization. Campus. We build and maintain and manage campus networks for our customers. Higher ed, huge in the US. We actually have zero presence

in Canada, except the company I used to work for in Halifax, I deployed in December 2020, they're still running it. So no sales organization in Canada today, all based in the US. But it's important that you understand why, you know, what we're doing and what the difference is. So we are networking as a service, but we built this in a different way. We have no full layer two. doesn't exist. You can't do what Chris was just able to do. And I'm going to show you that. So, exactly the same setup. The only difference is in the middle we have our network. It's called a Niles Service Block. It's essentially a network that we deploy and then manage on behalf of the customer. Everything else is exactly

the same. Same workstations, same OS, same upper level, same layer three, everything. The only difference is we took out the legacy layer two, layer three network and put in a layer two network of our own. We're gonna try to do the same things. Exactly the same conversation. We can't stop that malware or that attacker from getting in. That's not us. We don't do that. If they can get to the internet, Bad shit can happen. Sorry, I said shit. Sorry. I'm a new flan, so it's probably all right. Right? Okay, good. That will happen. So we already said that. You're gonna get hit. You're gonna get breached. You're gonna get malware. So we know that. Exactly the same thing. We'll do that. We'll do this. And we'll

do that. This is a screenshot. Because we, I can't show you an art-a because it won't work. This is showing those systems. This is our dashboard to show a customer what's on their network. This is just a quick screenshot of a Nile network to show you these workstations do exist. This isn't magic. This isn't me making this up. Those workstations exist. And what we're going to do, they're on the same exact subnet. So if you look, they're all on the 1023 subnet. So they're all adjacent. They are all on the same subnet.

Hey everybody, Chris Tristan here again. And in this demo, as a follow-up for the last, what we're going to do is run more of the same type of attacks and reconnaissance on a LAN. But the key difference is that all the devices are now plugged into a Nile-based node. So what you're looking at right now is the client view of the Nile dashboard. and you can observe that all three Windows workstations are plugged in via wired into the same segment and are residing in the same IP range. So this is a /24 subnet mask and therefore very similar situation to the last where all three devices are adjacent to each other from an IP perspective. The difference here is that in the Nile

network, we have client isolation running by default without any configuration, and we provide full firewall visibility for all client traffic no matter where it's destined. So let me go ahead and give you an example of that by kicking the demo off. I will go to the workstation that was located on the .12 subnet mask. I will launch the reverse shell application just like I did on the last demo. I'll head over to my Kali Linux server and I will run my multi handler and the shell session is established right away. Now, like I showed you before, this 10.234.1.12 workstation is this device right here. So let me give you an example of the power of our client isolation by default embedded native behavior.

So I'm going to go ahead and establish a, or jump into the command prompt of this workstation. Then I'm going to do just a basic IP config to understand the network that it's on. And like I said earlier, it's /24, in this case 10.54.1.0. Now I'm going to go ahead and run an ARP just to see what else I can discover on the network. Now, right now, as you can see, there's really nothing there. But unlike the last demo, what I'm going to do is run a wider sweep of scans. So I'm going to go ahead and exit from the shell, and then I'm going to background the session. I'm going to go ahead and use that same port scan tool that I did

earlier, but in this case, I'm going to widen my sweep because the workstation in this case has not contacted any of the other three workstations in the network, so it wasn't easy for me to identify them. So let's go ahead and use the TCP scanner, which is option 5. And then I'm going to set the remote hosts for the entire network that the workstations are sitting on. And then I'm going to say that we're going to get to this network through this workstation that I have established the reverse shell, which is session 8. Now before I forget, I do have to add a route so that my Kali workstation knows how to get to that /24 node.

So I will go ahead and do that now. And that's actually session 8. And then we're going to set the remote host. I actually moved it backwards on this. We're going to set the remote host to the entire node. Okay. So... With that being said, the expectation here is that I'm going to send out a port scan and I am looking for vulnerable ports from ports 21 through 23, SMB, and RDP. So a little bit more of a targeted scan for these ports. Let's go ahead and run this. Now, we discovered that we're running SMB on our own IP, but we haven't discovered anything else just yet. And I'll kind of give you the spoiler alert is nothing's

going to show up because by default on a Nile network, we are isolating all client traffic. So just a reminder, if I go back, you'll see that there's other active workstations, .32 and .35. Yet I am not able to discover those clients because of the native client isolation. without any configuration. Now, if I dig in a little bit deeper, I can actually go to the upstream firewall and discover that these port scans are taking place. So really quick, I'm going to go ahead and click on a-- run a quick filter here. And the IP that I was using was 10.2.3.4, not 1.12. And I'll go ahead and filter. Now, check this out. In the logs, you see that this workstation was

just being used as a device to perform a port scan, which is a form of lateral movement, but the firewall was able to actually see that this traffic was being generated and that this type of activity was taking place on essentially every single session. Remember I scanned from ports 21 through 23. So here you can see all three ports in the 20s. I scanned for the RDP and server message block and all of those IPs were hit as a part of that scan. Now typically we would have finite policy to allow some connectivity. But in this case, we are denying all to show you exactly the level of visibility that the Nile network is providing to the customer's firewall. What's even better is

that in the logs, if I were to click on threat, we should see that right off the bat, we are showing that we're able to discover that there is a potential threat because of the port scanning activity that is taking place. So this is just an example of the level of visibility that we're giving you with zero configuration embedded behavior on the Nile network. So I don't know about you, but I've never seen a firewall pick up layer two connectivity between two workstations on the same network. Because normally, in the networks we build, the firewall sees when traffic leaves my subnet, not the traffic within the subnet. Now, can this be done with other technologies, other vendors out there? Absolutely. Sure. You can build

this. We do it out of the box. Zero config, zero touch. It just happens that way. So what did we do? We did the first thing. That all worked. Then we try to do the identification, the lateral movement, not going to work. Lateral control, not going to work. So this is again a tool in your kit. I'm not saying, you know, get this, do this, and you're going to end up with a perfectly secure environment. Not going to happen. We need defense in depth, and this is just another way of doing it. In fact, we're not a security company. We don't do this and come out and say, "Yep, we're doing it because we're building

it." We are a networking company that's built a secure network. 30 years ago, if we had known what we know today, we would have built networks like that. That would have been the way we would have built them because they are inherently more secure. So we did a social engineering, we did network reconnaissance, we did pivoting lateral movement, we exploited the idea being with what we do on our network, this new way of building a network, your blast radius for that infection or that attack or that breach is literally now one. It can't get past that workstation without the traffic going to a layer 3 device at the top of the network. Now, if you go on that layer 3 device

and you say allow all, I can't help you. You have to be able to put some type of control at that layer in order for this to work. And people also say, well, I do need some things on the same subnet to talk to each other. Printers, great. We can do micro-seg within our network to allow that. But you don't need every workstation to talk to every other workstation. That ship sailed. The only real reason for my laptop to talk to somebody else's laptop on the same segment is malware or a breach of some kind. If you don't believe that, we can talk about it later. But we do allow some things. Security cameras, talking to a security server totally makes sense. But generally, traffic

on the network should stay on the network. So... What did we do for our breach detection, our malware detection? We've now identified, we know where the infection is. It can't get anywhere else. It's on that one device. And we isolated the box. It's already happened. Your isolation is already done. So you don't have to worry about it. This isn't going to work for everything. It's not going to work, as Glenn mentioned, for some reasons of malware because that traffic looks like normal traffic to the network. You have to have something like behavioral heuristics that understands that this workstation shouldn't be talking to that server over there. That's going to happen. So you have to have

the EDR stuff. But on the same subnet, we can do this. So I've got a couple of minutes left. I'm going to just talk quickly about zero trust because everyone wants to talk about zero trust and we love zero trust. Zero trust to me means you don't trust anything. That's what zero trust means. It empirically don't trust anything. The problem with zero trust is it adds complexity. including distributed management. So some people say, I'm going to put zero trust, I'm going to put management points or access points all over the place. That's a challenge. That takes time and manpower. That also means you have... maintenance problems because you put all these extra devices who's going

to manage them, who's going to update them, who's going to do all the work on them. Troubleshooting becomes crazy. You've got levels of control, control points at different layers of your network. Well, how does that policy work? Who manages all that policy? And then it costs a lot more money, generally. We're doing everything out of the box. So the way we built it is that that network now has a single point of control. It's the layer 3 at the top of the network. That layer 3 controls all the traffic, essentially. It sees, and more importantly, it sees all the traffic. So in general, firewall vendors love this approach. If you've talked to a firewall vendor,

they generally say, "If we don't see the traffic, we can't control the traffic, we can't policy the traffic, you've got to let us see the traffic." So that's why you put in taps. You put in a tap here and a tap there and a tap here. That's expensive. So what we're saying is our network ingests all the traffic and then sends it to a layer three control point, a single layer three control point, obviously high availability, but all the traffic is seen there. Therefore, that firewall vendor can then say, yep, I see everything. I can help you control it. So that's what zero trust isolation means. Zero trust access essentially is we don't allow unauthorized

access to the network. There is no such thing as an open network in the Nile world. You have to be authorized. And the last thing is the network itself that we build has basically being a black box. No SSH, no console port, no way to physically attack one of these boxes. When we put it in, we own it, we manage it.

I think I'm on time, yes, somewhat. Good. Couple minutes. I'll take questions, anything you want to throw out about what I've talked about. We can talk about Niall, where we come from, we can talk about what we showed. Anything that was interesting. Questions? Come on. Yes. So, on the physical side, from a networking perspective, all our devices are secure black boxes. So there is no console port. You can't walk, if you even get access to a closet where a NIL network is deployed, you can't plug a console cable in. Doesn't exist. And when you're on the network itself, you can't see any devices. You can't, and there is no SSH. So nobody locally can SSH

to a single box and do bad things on it. The other thing, there's no config. There's literally nobody typing in host name, blah blah blah, IP address, blah blah blah, that doesn't exist. So there is no way to fat finger something inside this network. So we all know how bad people get in, somebody leaves something open, well there is no config on our side. Doesn't happen. Everything is automated. So built in the cloud, built from the ground up with automation, it's just a different way of building networks that we've never done before. Now, again, campus, yes, data center, we don't touch. We're not going to go into a data center and say, hey, let's build

this in there. It's way too complex to build this type of network. But in a campus, in a LAN environment, wired and Wi-Fi, absolutely 100%. I was telling a story. We have a university we deployed at in Buffalo, New York. And we deployed across their dorms just in mid-August. Students came back in in September and I had a call with their VP of Student Related or Student Resources or student something and she, I've never had this happen in 30 years, she gets on the call and she says immediately to me, first thing she says, "I love Nile." I didn't prompt it, I didn't say it, okay, thank you, I guess. I said, "Why?" And she

said, "This time last year, students moved into the dorms, we had between three and 500 trouble tickets in the first 24 hours." with things not working, students not getting on, whatever. This year, with the network we deployed, zero. In, up in two weeks, two and a half weeks, and zero trouble tickets when the students moved in. So, it's a different way of doing it, and I'm pretty happy that I got involved. I mean, it's pretty cool. Other questions? Gotta be somebody over here. Are you guys awake? Yep, yep. Yep. So, no. We give you the opportunity to set up policy. So, what I meant by fat finger is more config. So, putting in the OSPF config or

putting in config at the switch layer itself. The policy and the micro seg, that's all on you. That's on the customer. So, we own, we're essentially like AWS for the on-prem network. We give you the infrastructure, you build on top of it what you want. Your SSIDs, your segments, your micro-seg policy. Yeah, so everything's in the cloud. So the way it actually works is when our switches come up, they build an SSL tunnel back to our NOC. and then we ride that SSL tunnel back to get configured on those switches. So when you're configuring things, you're configuring things in our portal interface at the NOC layer, and that gets pushed down the switches. No, once it's down, we can't change it, but

if the SSL tunnel drops for some reason, policy will still work. Same as users can still, even if the internet goes down, users can still work. We're kind of built on the premise that the internet goes down today, what the hell are you doing anyway? In most cases. Yeah, in some ways it kind of does, but again, much more config intensive. So, again, you can do this with Cisco DNA. You can do it with a bunch of different products, but I defy you to do it in a way that's zero config and takes no time to do it. Because I've done it, and it takes man hours, a lot of man hours. So it can work, yes.

There are multiple applications out there. But because we built it from the ground up to be this way, we don't have to have that. Yep? So geographically, I expect it works as home to So the NOC itself is hosted in the US West, AWS. The data traffic never traverses that. So the only thing that goes into our NOC is the control plane. So your data traffic stays local. We don't have to do anything with it. We don't touch it. Your traffic, your site. But what we bring up, because we're managing the network itself, the control plane data gets sent up to us, as well as metadata on the traffic. So understanding the, being able to see the data. We then encrypt that data

at the AWS NOC, and you have the ability to decrypt it with your own keys. So, yes, I have had people talk about, "Where's my data?" Well, your data stays local. The only thing that goes into the cloud is metadata control plane. Welcome. Yes? All our own. We built it from the ground up. We started four years ago and said, "We can't build this on top of somebody else's platform." We couldn't have done what we did at that university in Buffalo with somebody else's platform. We had to build something that we knew would just work. The key is, we don't get paid unless it works. It's a service. So if the network doesn't work and

it goes down, we don't make any money. We literally charge you a subscription fee for the network. So we had to build it so that we were 100% confident we could make it work. Which is why we started with over a thousand data points and said, what are the things, if we could build a network in a better way, what are they? Well, we have no layer two spanning tree. Spanning tree is great. If you know networking, Spanning tree works great. You have multiple links, one link goes down, another link comes up, it's great. But there's a learning period, right? You have blocking, you have learning, you have forwarding. That happens within Spanning tree. Whether it happens within microsecond, 10 microseconds, milliseconds, whatever, there's still downtime for your

network when Spanning tree kicks in. And we said, we're building a brand new network, do we need Spanning tree? The answer is no. Everything passed at layer 3. All the links between switches are done at layer 3. So there is no requirement for layer 2 spanning tree. So another thing checked off the box, can the network go down because of layer 2 spanning tree convergence? No. So again, we built it for that manner. Anything else? Yes? So DHCP will work right out of the box, but you have to configure your DHCP server. So we do layer three forwarding, basically proxying of DHCP. So your DHCP sitting on server over here, we basically proxy it in. So we take the DHCP request in, proxy

it layer three directly to that DHCP server. Which is great, works fine. The other thing we've done is we've created our own DHCP service. First one, cloud-based DHCP service. So if you've got a site out in Gander that you don't want to stick a DHCP server in, we will offer you a service that says we'll run DHCP for you in the cloud. So your users will get a DHCP server or DHCP address from us based on a subnet that you specify. Anything else? Going once, twice. Okay, thank you very much. Awesome, thank you, Kevin. We're going to take a quick break. We'll see you back here at about, we'll start the next talk at about 11. I was wondering

when you were going to come with the bad pigs. Why not? So we live on YouTube as well? I don't think we are right now, but you will be. Not right now, but my talk will be live. Yes. I hope it's going to be live. Is there any people connected? There were 42 people when I left earlier. What number? Just make a request to you as presenters. If there are any questions in the room, nobody online will be able to hear it. Last time it was super confusing. That side of the room versus that side of the room is huge. Nobody's really yelling. Nobody can hear it either. If you don't mind, that would be great. Nobody will? I love that. I love it. But yeah, so repeat

the question. I'll try to mention it to the audience. Yeah, if you don't mind, that would be great. For sure. And nobody's said anything online yet, but who knows? Yeah. I think people understood what he was going for the whole time, but at the same time. Yeah, it's a good point. I'll remind them. Perfect. Thank you very much. And is the mic on always? The mic will be on always, but I'll unmute and mute you. So before your talk, you can put it on now. It's muted. Actually, you know what? Before I 100% say that. It is muted. So I tend to move a lot. Yeah, that's fine. Can I move from anywhere? I mean, if you're running through the room, that's

fine. I won't be able to catch you on the camera that easily. I'm totally not going to stay here. I have my own ticker, so. Okay. But, yeah. Perfect. Great. Awesome. Thank you very much. Well, that's good. I can go deep with this. Well exactly. yes how are you finding yeah the ceiling is pretty low i am here not sure i'm gonna be able to see there you go over to that side yeah I am going to laugh. It's good to stay there forever. It's good to come back in 10 years from now and say, do you remember? Oh, it's on your back. - Make your own time. - Maybe it'll be Mikey speaking up. - Traveling

more. Yeah. I mean it doesn't really matter I guess but it's got to be annoying for people online it's up now it's up now apparently they can hear me talking it's up now yeah it must be yours I hope you didn't say anything no it was not that bad just talking about yeah I'm kind of curious, like, on the social engineering side, with some actually, like, testing, that's got to be crazy. I mean, yes. Because, like, you get rid of, there's, like, spelling and things like that that are usually ticked, right? Yeah. I don't know. I mean, yes, looking for bad grammar and stuff is scary to people. We always have to look out for that sort of thing. But realistically, I'm not sure how many people actually do

it. I'm not sure the extent to which grammar actually matters. It has a waterline to it, though, too, right? Like, it's liquid. And you scream. Yeah. You could be like, is there something that's going to make me scream? Not really. It's not. I'm not. I mean, not effectively. I mean, you could automate it, but like... I do have very light slide, anyway. I do have light slide. Have you written English to write efficient statements? It's not that difficult. I don't know what I'm going to talk about. No, I'm joking. The difference between somebody writing efficient statements is... It saved you a couple of minutes ago. Maybe other people have an interview on it. That might be it. I'm

much more concerned. Oh, it's maybe that microphone that is open. I'm much more concerned personally with these people. Like actual pedals for fishing that are virtually always the case. This is the fun thing with spearfishing. It makes you stop and think, right? I know that energy is in our... Yep. Social engineering And their way in was to research the CFO on LinkedIn, find the school that his daughter goes to, and send him an email that says, hey, it's your daughter's school. Click this link to sign a form so that she can go home with her mother or something like that. People are gonna fall for something. If you have enough time and you know what you're doing to research stuff, you're going

to make an effective social engineering people. I will say, however, of Kevin's talk, one thing that I really liked, I now have my favorite sentence for describing someone getting phished. In the demo, the guy who was doing his demo said, "Somebody who was social engineers." That's an interesting way of referring to somebody who clicked a bad link. I like it. - That's it, like you're aware of, but at Cisco we were affected by a breach of, I think it was almost a year now. And the way they were able to get in is to, they call someone, they were able to get the credential of that person. We had MFA all around, right? But they call that person. They say, "We are Cisco,

we need to authenticate you "and can you prove to ourselves "that you still have that device? "So we're gonna send you something on your phone, "and you just click accept." Okay, good, done. It's using the security layers against us. It's actually a really, really good way to compromise one of your friends' accounts and send you a message like, hey, I need to get my account back. Can you send me the code that I just texted you because I need to prove that I know you or something like that. You send them your MFA code, they already know your password. Fishing someone's Facebook password is not heard. Getting the MFA token is the hard part. That's one, huh? Yeah, we

dress still. Still? I thought we dealt with that. There's a bunch of company. You can even have, like, there's training. That would be a fun one. Physical pentesting is pretty nice. Like, you'd be amazed at how many things you can get into with, like, a physical pentesting. I remember a couple of the... I have a travel flash drive in the parking lot kind of thing. There's a guy in Montreal a couple of years ago. He had a talk at the B-side in Quebec. And he was asked by the police to do a brief talk. Yeah. It was a multi-year. It was fascinating. It was a new world. Thank you. I got two minutes. But it

could be very challenging. It's almost just on the edge of what's legal and not legal. I was talking to my friends about that, too. I was like, because they were explaining something. We were talking about, like, we had to do a sit-down business here, and they left the computer. I could have just left it right there. You know what I mean? Those were the bad parts. Passport loan. Yeah. And most of the time, the person in front of you They don't know until after something happened. This is where it's like, that's a really hard sell, because you can't do it. It's illegal. But then you can't let them really know it's possible. So, yeah. - The big one in Canada,

like the Lord, and all the other institutions, aren't in New York. They are open. They're instituted in New York. - The company now, I think they have suffers from Yo, insurance? I love insurance. I used to have insurance bills, so I have an appreciation for policy and everything. And like, insurance, I've got, like, I know some family who are like, actually, actually, I don't mind.

That's the trick so it's like what system are you? Like there's an angle to come in on the insurance side of life And like if I was doing sales, that's what I would do too. Because it would be like, hey listen, you've got to pay out at this time. Yeah, so there's other color at the kiosk. I've been collecting stress balls at every conference I've been to. Do you have the black one? The official black one? Yep. I never went to black. Oh, sorry, give me that black one. Remember a few years ago You guys had a whole pile of these left over that you basically like Chris Chris said I don't want them I So I just gave them out. Like

everybody just had all these pigs. There's a superhero one as well. I have the superhero one. I do not have that one. I remember a couple of years ago at Altecon, we had like a bunch of different variations of those pigs on the table. And one lady, she was coming every single 15 minutes, I would say. Nice. Nice. Nice. Yeah, that's awesome. That's awesome. All right. Cool. All right. All right. We're going to kick things off again. If everybody could come back and take their seats. I'm going to do a draw for an Apple HomePod Mini. So you need to be here to win. Yeah. If we could have one of the volunteers run out and

kind of wrangle people to come back in, that would be fantastic. What? You already got one, right? No, no, we already got your copy. Yeah. Yeah. - Nice, that's awesome. - All right, I think we got enough people here. Let's see who's gonna win the HomePod Mini. All right, we have ticket number 8238514. Anybody? Anybody? Already, already missing somebody. All right, next. All right. 823-8473. All right. There you go. All right. All right, Chris. We'll get Chris to do the intro for you. Awesome. All right. Welcome back, everyone. Next up, we have Alex Argyris. Yeah, should be a good talk. Is my mic on? Yeah? Everyone can hear me well? Perfect. Are we waiting for a couple of

other folks? They're all going to miss my talk, I guess, eh? Anyway. So, hi everyone. My name is Alexandre Argeris. I'm one of the few cybersecurity technical solution architects at Cisco, but my talk is not going to be a sales pitch. Okay? So, we're going to talk about other stuff than usually what I talk when I'm in front of a customer. So... Thanks to the team again and this year for those of you who have been at many other B-Sides for the last couple of years, B-Sides used to be always the same week as my wife's birthday and I was always in a rush either to arrive or to leave the B-Sides just to be there for her birthday. But this year it was over the

weekend so I was just happy. So, we did arrive on Monday. I had a couple of minutes to go on Sino Hill, do my jogging run. And yesterday, we even had the pleasure to go around as well a couple of other sites with one of my colleagues over there to see the beautiful area, of course. So, today, we're going to talk about something that is pretty close to my heart. If you remember, if you have been to other of my talk, I usually talk about stuff that are free, cool, anyway, stuff like that. So you can have fun in your own lab as well and implement those type of strategy as well within your organization

if you're willing to. Or even apply the same strategy to commercial product, like the one that I sell. So for today, we're going to try to see how we can enrich your experience when you're using a NixDR technology with free API services. I mean free because these are not open source like we used to call software and stuff like that. These are most of the time services that offer a free tier to access stuff that are lower than what you can get if you pay the extra money for it. But anyway, even if they are free, most of the time you can get a lot of information from those services to enrich your experience while using a technology like a NixDR technology in a sense. Make sense?

Just a little bit about myself, I've been presenting at B-Side for many, many years. I think the first year was in 2015. I've been talking about many different topics, SSL decryption, honeypots. I even have shared some of my story when I was younger as well, stuff that I should have not done and stuff like that. So a bit about myself, I probably had my first computer in early age and I also one that I was able to access Gopher. How many of you know Gopher? Nice, nice. So it was a nice way for me to be introduced into the networking slash whatever other industry. I'm able to surf the CLI of the gopher across the world and stuff

like that. So I started to code like an amateur or whatever, as I say, most of the time around the 90s as well, by building my own web page. How many of you have been building their own web page as well? It was awful. Anyway, and I have more than 25 years of experience, whatever. I've been with Cisco for the last 10 years. I have three kids. Thanks God they are all at high school now. And I have a wonderful wife as well. If you're looking for me during winter, I usually... ski over the weekend. Even on holiday and all that, every time that I can I go on the ski hill. And during summer, if you want to do an activity with me, call me and ask me

to go on the road bike. Okay, make sense? So, a little bit of warning here. First of all, that presentation, typically the presentation that I do over here, it's make sure that you guys go away from that presentation, not with content. My goal is always to make you think, right? Make sure that you have some sort of experience that will leave you with something that will encourage you to go deeper into that research, okay? Of course, please ask questions, but I will say more at comment. I'm not an expert. I'm a generalist, like probably most of you guys as well. So if you think that what I'm saying in front of you does not make sense, raise your hand and say, Alex, you're wrong. Okay?

And it's going to be too boring as well if you don't ask questions. I do have pigs. Remember, for the one of you who were there last year, I do have a bunch of pigs over here as well. So for each comment, question as well, or wherever I want, I'm going to send a pig as well. So first of all, let's ask our friends. ChatGPT, what XDR is. Are you guys ready? So how many of you are familiar with the XDR? marketing, whatever terminology of XDR. Yeah, that's the first hand. Almost. So if we ask chat GPT, it's a good definition, I would say. It said extended detection and response. Okay. So it means we extend the detection of what we're used to.

to include multiple different telemetry. Not only one single telemetry that usually all the other tools are providing, but we extend that telemetry as well, that visibility to other tools as well. The primary objective, I really like having that slide over there as well. So the primary objective is to provide visibility and context. So here's the important word over here, context. So my talk is all about context. adding additional context to an investigation. And by analyzing data, whatever, with advanced analytic, we're not going to go there today. Machine learning, of course, we all do that. And at one point, there's other things that ChatGPT are telling us. It will leverage or do detection and response. Response and other keywords

here are very important. So we're going to look at some services, tools, or whatever that we can leverage as well to do response to a potential threat. The other thing is automate response, right? Being in front of the computer or a tool, it doesn't make sense. No one wants to have a dedicated... Hi, Cathy. How are you? So no one wants to... be in front of the computer or the logs or whatever 24/7, right? We want to be able to automate as well those response. And the other part as well, it's threat intelligence, threat intelligence. So typically there's a bunch and if you have money, you can spend a lot of money on threat feed, right? There's a bunch of different organization across the

world that will give you a lot of information like the dark web stuff. as well to be able to correlate, add additional context to investigation as well. But today we're going to look at free stuff. So there is commercial market, the big commercial market for that XDR stuff. Everyone has their own flavor of what XDR could be. Of course, if you have money in your organization, go ahead and buy those solutions. It's going to be a lot easier for you, of course. But if you want to play and have fun, there is some other as well. So those are open source, whatever free service or free, not service, but free tools that can be leveraged to accomplish something similar to

an XDR technology. Of course, on the other end, there's Python, PowerShell, any other technology. tools that do scripting and stuff like that can be leveraged as well, right, to do the response, add additional context to an investigation, and so on and so forth. So if you don't have money, or if you want to have fun, go on that side, right? And make sure to prove to your organization that having additional context with free tools and free services as well makes sense to you to protect your organization, and then maybe you're going to get money to buy additional stuff. So now let's talk about API. So that's the second portion of my talk, API. So how many of you

remember my talk last year? Yeah, there you go. Nice. So what was the first challenge of API? Oh, that's a good one, huh? Authentification. You guys remember, we all have MFA right now applied to most of the account that we all own, right? But we don't have an MFA solution for an API, right? Typically we have a set of API key or we use a token and unfortunately we never refresh or change our API key. It should be a best practice to do it but we don't do it. Anyway, so for today where we're going to go with API is by leveraging free services. Some of those ones does not require authentication so we don't care. And some others as well just

leverage your API key from a free services. So you don't care as well if those API key are shared. So let's ask JPT again. It's application programmability or programming, my French accent is coming back, interface here. And then what's API is, I will say that API is a way, the best way to communicate, to have two machines communicate together. That's probably the best way to interpret what API is. And essentially, API will leverage what we have already. It's HTTP protocol, most of the time. REST API uses HTTP. So here's a cool API example. So this one is pretty nice. Predict the age of a name. Is it useful? Not really. But it's cool, right? And if you look at it, it predicts that my name, Alexandre,

has... 46 years old. I will be 46 in three months from now. So they're pretty good, right? So you can go and Google your own or look for your own name as well, see if it's true or not, but whatever. Is that could be applicable to any of your threat detection? It could be, right? Let's say you have a use case where you want to define, I don't know, it's a phishing use case or playbook or whatever, and then you want to identify if the name or the mini name that could be in that email could be applicable to the threat. typical age of your employees or stuff like that. So you can you can leverage that of course. It's free. You're not gonna do

it by yourself. You're not gonna have to copy and paste the result. It's gonna be built into the solution if you go up to what my talk is about. So if you look at REST API and what REST API is in general, how many of you guys are familiar with REST API? Nice, here you go. So I like to play with REST API. Am I an expert? No, but I like to. So there's multiple different functions within REST API that is pretty important to understand. The first one is get. Please get me, Mr. Service. Get me something, right? Get me what you have on REST. a pet name in that type of example. It could be on anything else as well. The other one is put, right? Please update

the date you have for that person, stuff like that. Delete, of course. Please delete that IP. Please delete that address or whatever or that record, right? And post. Can you please upload the file or can you please add the record to your database and stuff like that? That's going to be pretty important for the rest of the presentation here. So let's look at what's going to be the framework for today's presentation. So we do have XDR on one hand, on the top, and API at the bottom. So the first important thing when we're talking about API is how do we collect telemetry? Telemetry could be anything from a firewall logs to an EDR logs, NDR, cloud, any type of services, identity services, and so on

and so forth. It could be even from an OS or whatever. Things that matter to you. that could be used to identify a potential incident. And of course, some of those technologies, I would say most of them right now, are exchanging that type of telemetry with an XDR platform through API. We still leverage pretty old technology like, I guess, Syslog. which could be non-encrypted, but sometimes it's encrypted now as well. But SysLog is still used, unfortunately. And then the second part is how do we correlate and prioritize all these different incidents? I don't want to give to my security analysts all these different security incidents at once. I want to make sure that they are looking at the one that matters to them.

And to be able to do that, typically, I will reach out to an API service or to a threat intelligence service, right? Maybe within that incident, there's an IP, there's a domain name, there's a hash from a file, a URL, or a name, or a MAC address, or whatever other stuff as well. So I'm trying to reach out to a service service. that will give me more insight, more information about it, so I can correlate, prioritize, add a score or whatever other stuff as well, so I can say, you know what, mister, you should look at this one and not those one. Then the investigation part, right? Everyone needs to go into the investigation part. So from the investigation standpoint,

First of all, we're still going to need to quarry those threat intelligence, right? Can you give me the reputation of that hash? Is there a... when that hash was first seen, right? Is there any tag? As I said, without hash. I mean signature from a specific malware, campaign and stuff like that. And also, we're going to reach out using API to the original source. Can you give me the context? Is there a user tied to that MAC address? Is there a user tied to that public IP? And so on and so forth. And then the response, which is the fun part. How do we mitigate, control, whatever, isolate a potential threat? And here's the difference. From now on, we will use additional tools HTTP or

REST API function, like the update, the post, and the delete as well, because we're in the response phase, right? So we can go and add additional context to our source, right? Let's say it's the entity provider. It's Azure AD, right? I'm going to put name here. You're using Azure AD, so as a response, I'm going to just deactivate the user, right, in Azure AD. So it's probably going to be something like a push or something like that. I'm gonna go in threat intelligence as well. I'm gonna show you how to contribute to the community, okay, by adding comments on different platform about potential threat that you have find out. Instead of just getting information from other, you can contribute

as well to the community. And then there's other stuff as well, external and internal source. You may reach out to your CMDB or whatever other management platform and stuff like that for your host or whatever. So there's other places as well that you may want to delete, asset and stuff like that to isolate the problem. So there is many, many different collection of free API. So that's one I really like, Rapid API. So there's a bunch of different API that you can look at it. Some of them are free, some of them are free to use, some of them you have to pay for it as well. And it's not only for security, right? There's API for jokes. There's API for weather. There's API for

anything, right? I'm making jokes here about those different type of API, but if you're in an investigation, it may be very cool to have some of those information, some of that context as well, right, within the information ticket or the investigation ticket. Any questions so far? Comments? No? Okay. Yeah. Why does your API aid device says I'm 67? Right? It's 77 right now? That's a good one. Sorry, I didn't repeat the question. Sorry. He said, why in your API, or the API, say that I'm 77? Right? It's because you're looking old. So how many of you are familiar with VirusTotal? Yeah, go ahead. Here you go. Which is a free service. There's a paid service as well

for VirusTotal. And I think VirusTotal is owned by I think it's owned by a big company now. Anyway. So most of you, I guess most of you leverage VirusTotal by copy on IOC and paste the IOC within the web platform, right? Most of you are probably doing this. But there is also an API for VirusTotal, which is cool. And here's the different use case that can be leveraged with VirusTotal, let's say. Getting the URL, file, domain, IP reputation for better enrichment. You can submit a URL and a file to be analyzed as well. Those two functionality, I would say most of the other vendors out there charge you for this, including Cisco. So we charge

you for this. But here's the free service. If you want to test it, use it, and if it makes sense for you, go for it, right? The last use case over here that I really like is to contribute to the community. Make sure to add additional comment. There's someone that is telling you that that URL is a phishing email, it's part of a phishing whatever campaign, and if you see this as well, say yes, I see it as well. So add additional comment. Maybe you have a screenshot from that email and stuff like that, so on and so forth. Make sense? How do you do this? It's fairly easy. So within your account, there's a section where you can generate your API

key, copy your API key, and then leverage any tool that you want to take advantage of VirusTotal. Of course, if you do own a commercial version of an XDR platform, it's typically built into it. Otherwise, there's many other way to test it and implement it into your own framework, let's say. So how many of you are familiar with Postman? Nice.

So here's the example of Postman, which is not used, typically it's not used for production environment, right? It's for testing. But essentially, here's what you will do. It's you test the different API through Postman, and then you will replicate what the Postman is doing in terms of requests into your own script, right? Let's say you are building a script with Python or PowerShell or whatever other scripting tool as well. You will replicate this. So here's the request: give me, Mr. VirusTotal, the reports for that specific hash. What is a hash? Anyone know what is a hash? Come on, come on. What's a hash? SHA-256, right? of a file. It's a fingerprint of a file. So here's the hash.

Give me, Mr. Barceló, the result for that hash. And here's the result that come in JSON format. So Most of you that are doing coding, I guess, do understand what JSON is. Fairly easy. It's a result that you can parse and get the information that's mattered to you and ditch all the other rest. And use that information as you want. The good thing about VirusTotal, it gives you multiple different results. It will give you for, let's say, different type of antivirus, EDR and stuff like that, it will give you all the different results for all these different EDR. So the other function as well or use case is comments or contribute to the community itself. So

it's fairly easy as well. So you can definitely implement this within your framework of XDR by saying that I want to send back when I saw that coming into my infrastructure, let's say, and stuff like that. Add a comment and that's about it. How many of you are familiar with Malware Bazaar? Yeah, that's nice. Oh, am I going to be able to go up there? Yeah, here we go. So Malware Bazaar, which I really, really like. It's a little bit more underground and virus-total, I guess. I think it's... It's not owned by any big organization. And it's under the abuse.ch umbrella, let's say. Someone who may know as well that organization. So you can definitely, through the web,

you can search for a hash for URL and other IOC as well. The cool thing about it, there is a signature URL. identify if it's belonged to or it's been tied to a specific campaign, a family of malware and so on and so forth. There's tag as well and you can even download the malware piece, which could be bad but anyway. So let's look at the use case itself for Malware Bazaar. Again, getting the file intel. Is there any malware signature or tag for better enrichment? Threat hunting. Give me, for example, give me all the last files that are tied to a rat or any signature that we want to look that could be bad for my organization as well and stuff like

that. Submit the file as a sandbox, a ticker lower sandbox, and contribute to the community again. So if we look at Postman, get me the last 10 malware, you can definitely see things that could matter to you while you're doing an investigation. What is the first time we have saw that file within the community? The last time as well, the file type, and all the tags that are associated to it. We can also use this as a threat hunting tool, let's say, or to add and enrich as well information while we're doing a threat hunting. So, for example, give me all the different file that are assisted with the tag rat, right? And then it's just a matter of scanning all

the infrastructure, see if that file could be in your infrastructure. So how many of you still look at phone numbers? Typically, what type of technology the phishing or the social engineering type of attack are using? Phone, right? So we better have a tool as well to enrich information that we can gather automatically on phone number. There is phone number and signature in email. There is many other places as well where we may want to know if a phone number is valid or not and if it's tied to a malicious activity. So there's a service called NEM Verifier, but there's million of others as well. So this one do offer a free API services that give you the ability to identify multiple

different things about a phone number. Of course, the use case, again, you look at an email, it's malicious. Instead of having to copy and paste the phone number in Google and see if it's valid, then you can use a service like this to add that information right away into your ticket, right, or investigation ticket. So, again, pretty easy to get your API key. Yeah, question here. I like question. Or is it question or comment? Wait. Oh yeah, of course. Yeah, it's just a number. Yeah, of course. Or it's going to say that the phone number is not valid. The service will say phone number not valid. So you can increase, in that case, you can increase the risk of

your ticket. Say, oh, there's a phone number not valid within the email or the incident I'm looking at. All right? Good question. So how do we do this through Postman? Just a regular get with the phone number and then we get the information about that phone number right away. And then we can parse all the information and use it as we want within our investigation. How many of you are familiar with Nmap? I guess a lot of you. Who wants a pig? There you go. I have plenty of pigs, don't worry about that. So there's a cool service that I have found a couple of months ago, which is nmap.online. For those of you who

are not familiar with nmap, it's a cool tool that allows you to scan open ports on a machine. So what nmap.online offers you is to do this on behalf of you from the web. So they probably have tons and tons of different services across the world. And then through API, you can ask them to scan a public IP and get the result, which is nice. Question, comments? So is there any use case that we can tie to this? Of course, there is a couple of use case. The one that I really like is to be able to add context about the public IP that is targeting you. Let's say you do have multiple in-secret incidents that are related to the same

public IP, then you can use that type of service to add automatically to your incident ticket the result of the port scan of that public IP. Why does that matter? Then you can identify maybe that there's some open ports that may be associated with a CNC, let's say, or other malicious activity as well. Exactly. So the question is, I'm going to repeat the question. So the question is, is that tool Nmap in a browser? Yes. So you can go to nmap.online right now and scan any public IP to the browser. And it will not be initiated from your current public IP. It will be initiated from their service public IP. You get the difference? So you're not going to be responsible for that scanning.

Don't abuse it. And the beauty is you can automate this as well through API, which is cool. So you can ask to scan any IP. Of course, for those of you who are familiar with Nmap, it could take anything from a couple of seconds to a couple of minutes to get the result. So the first request you ask, Can you hear me well? Yeah, okay. You ask the service to scan the IP. It gives you, I think it's a scan ID. Then you get the scan ID and you do another request to get the result. And then you get the result in a JSON format, of course. Yeah. Do you have one? Not yet? No. Okay. Yeah, okay. What was the advantage or disadvantage to the

API as well? I will give you an example. The company that I'm working with... Repeat the question. So the gentleman here was asking what's the advantage of scanning, of having an external service to scan the public IP on behalf of you, instead of scanning it from yourself, I guess, right? So I'm going to give you an example here. Of course, this is to scan a public IP, not an internal IP. That's a bit different, right? So I'm going to give you an example here, short example. I work for a company and I'm building workflow and playbook. And I had the idea to create a port scan within our own XDR platform, which is Oath in

the Cloud. And to test the solution, I was port scanning 1.1.1.1. And a couple of minutes later on, I got a call from someone from security at my organization saying, what the hell are you doing? 1.1.1 is owned by one of our competitors. So I said, okay, yes, mister, I'm going to stop what I'm doing, and I'm going to delete that workflow. And then I did some research, and then I found out nmap.online. All right, make sense? Perfect. Yeah? Do you know who owns nmap.online, or do you just scan around? So the question is, do you know who owns nmap.online? No, I don't. Neither most of people, I guess, as well. Is that service... That's a

good question. Is that service used for good or bad? Right? It's probably used for bad as well. Oh, that's... But that's a good point as well. So the question is, whatever you are tapping in or you're searching for, is it public? Yes, it is. So if you're searching for a specific IP and scanning for a specific IP, it will be a report on their web page. The result will be public. So it can be used later on by someone else with bad intention. But I think you can pay for an extra fee and get those scanned private. Anyway, I'm just telling you. MAC address. The last talk was pretty cool. It's almost like get rid of the MAC address, right? But MAC address

is still used a lot in our technology. infrastructure, wherever you go. And there is multiple different reason why you want to look at the vendor behind that MAC address while you're doing an investigation. Remember, investigation could be not only on external threat, it could be from an internal threat as well, right? And when it's from an internal threat, most of the time you do have access to a MAC address as well that is tied to internal IP. So what are the different use case here? You may want to double check. Typically it's a printer that is tied to that MAC address. Is it still a MAC address that is owned by another vendor? It may be a MAC

or whatever other type of devices as well. It doesn't make sense. Identify wrong devices as well. Or you may also want to maybe scan all your MAC address in your switches, in AP. And say, I'm not supposed to have any iPhone. Why do I have a MAC address that is linked to an iPhone in my infrastructure? And so on and so forth. Again, Postman. These are just for reference, but it's quite easy to look at. MAC address, there's not even an authentication mechanism or a key for that. So this one is pretty cool as well. IP table. How many of you are familiar with IP table? I guess some of you, right? Gentleman on the back there. Okay. Oh, there you go.

Sorry, I hit someone on the way. So, iptable is pretty cool. For those of you who are not familiar with iptable, it's kind of a host firewall for Linux base/whatever OS. So, there's someone or a group, whatever, that has created a tool that allows you through API to add an IP to be blocked on iptable. Okay, so now we are in the response phase, right? Well, the other services were more into the investigation and enrichment phase. Now we are more into the response phase here. Is it scalable? No, it's not, right? Remember, these are free services, free tools, or whatever that you can use as a proof of concept or whatever other reason as well. If you are cheap, you

don't have money, or so on and so forth, you can leverage that for sure. And on top of that, there is some other mistake that they're doing within that script that I've been looking at. They do not authenticate requests. So if you're a bad actor and you have compromised their infrastructure, you can literally add block, remove any IP on their server. You can totally isolate their server. Block a server, isolate a server as well. This could be useful when you're under attack, let's say. The way it's built, you have to compile, install a small tool on each individual server, of course, in that case, and then it's just a matter of adding an IP to the IP table and that's it, and that IP will be blocked after

that. Make sense? I reach out the end of my presentation, but I do want to talk about one more thing that I have not created any slide for it because I want to keep this for later on. But ChatGPT, IE in general is pretty cool. One of the other use case as well that I have imagined and I want to be able to build as well is to take any phishing email, let's say, and start a conversation with the bad actor. Using IE, using ChatGPT API or whatever other intelligence artificial API as well. So I can gather more information about Threat Actor in general. That will be cool. But again, I think my talk was more on let's give you

some tools, let's give you some ideas as well, so that you can start on your own to start your journey on adding additional free services to your XDR strategy, let's say. Think outside of the box. Any comments, questions? So the comment was, is this a phishing attempt? No. Maybe. Yeah, maybe. Of course, maybe. Thank you very much and see you next year. All right. Lunch is going to be ready for around 12. So we do have a few minutes for people just to, you know, wander around, go visit some sponsors. If you are back in here for 12, we'll probably just go with, let's say, dude and thirds. So that side, go first for lunch, then the middle, and then we'll take

that side. Cool. Thank you. And when we come back, we'll do some more prize draws. And so I'll lure you all back in with prizes. Any comments? Hmm? Any comments? It was good. Pleasure. Actually, we did have a problem. I've got one. Yeah, always. Hey. Yeah. - You know what I had to be like, the last few years I haven't even heard from you about this. - It's like four hours ahead of the game. - It's not the same premise. - We have a good reference. - Okay. - It looks pretty. - We're gonna get the board on the bill. - Yeah, I think we have a good one.

I always try to keep my eye on that.

-

Thank you.

Thank you. - I want to go for an atmosphere. I want to do a fresher with those.

so um

Thank you.

All right, lunch is ready downstairs. So folks on this one-third if you want to go down grab your lunch. And everybody else as you see people coming back with their food, if you want to just Kind of mosey on. That would be great. I just want to keep the congestion off the stairs. Thank you. And the bar is open as well.

Thank you.

All right. um

- I want to say more money.

I said it wasn't me.

♪♪ ♪♪ ♪♪

so

Thank you.

Thank you.

Oh, sorry. If you've got a... You can plug it right in. He said something about it had to be on his laptop and I'm not sure why. I'll just get him to come out. We'll run a test and make sure it's here. ... ... ... ... ... ... ...

Thank you. Yeah, this doesn't play super well with math. That's why I wanted to check it out. Something about like... Yeah, I was just going to say. I have an option. Yeah, let's see how it looks and what's going to happen with it. Power should be there. Let's make sure this is going to sleep. Yep.

Is the pro with the HDMI out? Great. I also have a quad. Sure. You know, if we need it, let's use that as a last resort. All right.

♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪

♪♪ ♪♪ ♪♪

so

do

♪♪ ♪♪ ♪♪

♪♪ ♪♪ ♪♪ All right, we're gonna pick things back up again. If everyone could get a seat, and if one of the volunteers could go out and start wrangling people back into the room, we're going to do some prize draws before we kick it back again with our next talk. Thank you. Yeah. Alright, so first up, let's give away some Netscout swag. So we've got a really nice Yeti tumbler and a, I guess it's a beer koozie. Keep your drinks nice and cool. So let's give those away first, courtesy of our very good friends over at Netscout. Alright, let's see. We have 823-8551. Nobody? Alright, 8551. Alright, here you go.

Have fun. All right. Next, we have a nice set of AirPods Pro. 823-8486. Awesome. All right. Now, we're going to do five different draws for AirTags. All right. First set. We have 823-8601. 8601. You? All right. Thank you very much. Here you go. All right, next one. Another AirTag. We have two tickets. We have 823-8555. Bowling. Oh, sorry, buddy. It's 8555. It's 8555? Yeah. Yeah, you didn't get it. No. I am Jack. 823-8606. 8606. Nope. All right. Next. 823-8521. Sit back, Dad. All right. Awesome. All right. And another one. 823-8450. I'll keep that one. No more prizes yet. 8-4-5-0. 8-2-3-8-5-7-9. 8-5-7-9. Nope. Next. 8-2-3-8-5-7-4. 8-5-7-4. All right. I realize it is hard to give away

prizes. 8-2-3-8-5-6-2. Come on up. All right. Still got one more to give away. And then we got five more for later, too. So don't worry. Kudos to them. All right. 823-8428. 8-4-2-8. This is really hard to give away prizes. Holy shit. 823-8481. Buddy. Airbags. Dude, you look tired. All right. Thank you very much, folks. Chris will introduce our next speaker.

All right everyone, welcome back. Next up we have Nathan Wensler with Mastering the Three Levels of Risk Decision Making. Thank you. Appreciate that. Hello everyone. I'm going to try to keep everybody awake here for a little while, so hopefully this works out. So before I jump into the talk, I want to talk a little about the talk. So I work for a company called Tenable, which happens to be up on the screen there. Many of you probably know Tenable as the creators of Nessus. We're a company that's been in the vulnerability assessment business for 25 years now. I'm not here to talk about that. I get to live in kind of a unique position in

the company where they kind of just let me talk about whatever I want, which is kind of cool. What I'd like to do today is talk a little bit about risk communication. It's a major, major problem for a lot of organizations. Everyone seems to struggle with it. And I've had a lot of opportunity in my career to fail at this in many, many ways. And so I thought what I'd do today is talk a little bit about tips and tricks on how to communicate about risk up the org, down the org, laterally, everybody who you're trying to deal with in your organization. offer some tips, some strategies, maybe they help you, hopefully. And I'll show

you some examples at the end which, in full disclosure, yes, come from a Tenable product, but it's only because that's the tool I have access to. So think of it as an example. I'm not going to talk about product. We have people here who will talk to you all day long about that out in the hall. That's not my job here today. So if you have questions, thoughts, please speak up. I'm happy to make this a bit of a conversation. And with that... We'll talk a little bit about, well, me some more. I hate slides like this. I really do. I don't generally talk about myself in these things. But I do it here because,

again, I've failed a lot at this. And I've been in security over 25 years. I started in government in the United States working for state and local agencies, building out security programs, quite frankly, at a time when security didn't exist. We were the IT department. And often we were the people that sat in the corner of the cubicle farm every now and then raising our hands saying, "Hey, you know, not sure it's a really good idea that we're letting all the government employees download porn to the taxpayer systems. Can we not do that anymore?" We're trying to do the right thing. We're trying to protect these systems. We weren't very popular with all the users

for some reason. But that's what we were trying to do, right? And that's kind of how security formed in a lot of agencies. We came out of technology and trying to do the right thing to mitigate risk. We didn't think of it that way, but that's what we did. I did that for about 15 years. Got out of the public sector, went into the private sector. Started managing teams, became a CISO for a few companies. So I ran security programs overall, a whole different world, as you might imagine. Got a little tired of that, went into consulting, primarily in sort of the management level. I did a lot of work with C-suite players, often got

brought into big financial institutions who just wanted to understand why their security program wasn't working. Spoiler alert, it's usually the C-suite. Which, by the way, if you ever get into that opportunity to consult like that, man, it is a great job. Coming into a place where you've already been paid, well, your company's been paid. You don't get the money, but your company gets the money. And you sit down in a room full of people in the C-suite who think they've been doing it all right, and you go, no, you haven't been doing it right. There's something kind of satisfying about that, I have to tell you. Don't do that to your C-suite. That will limit

your career opportunities. But consult for it. It's good. So, I've been kind of all over the place, right? I've been in the trenches. I've been in management. I've been an advisor. I've kind of seen it done a lot of different ways. That's why this is up here. Not to tell you that I've done it right or better, but just to tell you that I've worked in just about every industry or alongside it, law enforcement included, manufacturing, shipping, restaurants, finance, healthcare. I've kind of seen a lot of stuff. And so that's where a lot of this comes from, my experience with this. We talk about risk communication, you know, it's a little bit different for every

organization, but I find that there's a lot of similarities. And the similarities usually start with how organizations look at security inside their company. So, like for me, I'll give you an idea of kind of what my life looked like as a CISO. Now look, this is just, sorry for the small font, this is just an example, don't take this to heart. And this is representative of teams, not people. So like right here, I have the CISO here, but this is really the security team, so I didn't have enough font space for everything, sorry. But, in a lot of organizations, one of the ones I used to work for at least, this was common. The CISO

answers to the CIO, or the IT department, essentially. Now this gets different in some orgs. Sometimes it's the CEO. I've seen CISOs answer to the CFO. Sometimes the general counsel. Depends on the business model. Depends on what the organization, how they look at risk, how they think about this stuff. But for me, this is where I lived. Now, for my organization, I'm based on the west coast of the US. The company I work for, all headquartered on the east coast. Time is a challenge sometimes. And so like for me, on a given day, My day always started with a phone call from that person. And unfortunately, my CEO was not only a little bit of

a panicky person who took newspaper headlines a little too seriously, he also had no respect for those time zones. So I would get the call at 5 o'clock in the morning, panicked about, "I just read in the Wall Street Journal that one of our competitors has been hit with ransom. Where are we next?" Like, dude, I'm asleep. What are you asking me these questions for? You know I'm not looking at anything. Come on. But hey, that was the start of my day, whether I liked it or not. That's now my day. I'm going to get my team up whenever I get online and say, listen, we had a plan for today, but the CEO wants

to know if we're next. And so a lot of effort is going to go into answering the question of, are we vulnerable in those places? Did we patch? How does this particular piece of ransomware work? And so you spin off trying to solve that problem. But of course, five minutes after you start that process, I get a call from the CFO saying, who then says, "Well, hey, I got your budget request. You want another full-time employee and a bunch of new tools. Why? Didn't we give you money like six years ago? Come on." Okay, fine. So now I got to have that conversation. I got to stop the ransomware conversation, got to talk to the

CFO about why we need to justify another person and why we need to justify the expenditure for new tools and why it's not really that much money. And I have to have that conversation. Of course, come out of that, the legal gets me, "Hey guys, we're moving into the EU. Do we have to worry about that GDRP privacy something? There's like something they're doing there. Do we care about that? Yes. But now I've got to stop and answer that question, right? I've got to pull out the regulation and find out are we really going to have to be beholden to it? And I've got to start becoming a legal expert. And you see how this

is going, right? I worked for a software company at the time, so like, you know, my sales team would come get me. "Hey, can you talk to this customer and tell them about our SOC 2 report? Can you help tell them we're super secure and everything's great?" Sure, when I get done with all the other stuff I'm doing, fine. Compliance. We had to do PCI compliance, so of course I have those folks I got to deal with on a regular basis to make sure that the audits are done and the reports are in order and we're not going to get fined. That's a whole different conversation because they don't care about the rest of it,

but they care there. Then of course, As a tech company, I had product management, loved getting me involved because I'd been in the trenches for a long time. So I was a good internal person to ask about, will this solve a problem for our customers? Like, not my own problems I'm trying to solve, but okay, we can have that conversation. I got to get development involved. Marketing wants me to do things like this. You know, I'm happy to do that. Development teams, I got to work on those guys, make sure that they're actually coding everything we do in a secure way, because as we all know, developers are awesome at secure coding practices. Why are

some of you laughing? That's not funny. No, okay. And then, of course, just day-to-day work. When you're doing some of the basic security technical stuff, you've got to work with the IT folks, the admins, and everybody to make sure patches are getting deployed, firewalls are configured correctly. All the stuff we do on a given day, you're talking to administrators all throughout the company, help them understand why they actually need to do the stuff you're asking them to do. And really, it's kind of the whole IT department, whoever's there, DBAs, web application experts, cloud security architects, whoever. This is a mess, but I bet you any of you who work in security, which is all of

you, This probably looks pretty familiar. On a given day, we get pulled in a lot of different directions. And the interesting thing about this problem is it is reflective of something we don't talk about openly in the industry, right? Which is, though we come from technology, a lot of us built our careers coming out of IT, today, security is not an IT function. It's a risk management function. And all of these asks, all of this is happening because everybody sees us as experts in understanding risk, and they have questions. That's why we get asked about all this stuff. But think about almost any other job in a company. If you work accounts receivable, you process POs and push money from one account to another. So pretty much

you can focus on that job all day. I'm simplifying, but you understand. This is really hard to focus. But this is what we're being asked to do because we're trying to have these risk conversations with all these different business units in our organization. People have different needs and different levels of understanding about what risk is. The lawyer doesn't see risk the same way as a CFO does. Close, but not quite. But we're in the middle. Whether we like it or not, this is where we are. And it presents for us really an opportunity to be the translators between all of these groups when it comes to risk. And that's, for me, what we're going to

talk about today a little more is how do we structure this so it's not so chaotic and we can help everybody kind of speak the same language, talk about risk in the organization the same way, and ideally help everybody kind of make better decisions about what to do and not be running around like this. Make sense? Okay. I see some nodding hands. Good. All right. So here's my question for all of you. If you're looking at this list, on a given day, one single day, how many of you in your job do at least half of these things in a single day? Hands? Couple? Keep them up. I want to see some hands. How many of you do, really, some of you don't do half of this in

a given day? You guys have great jobs. Like for those of your hands up, look around, like you're not alone, right? There's a lot of your practitioners out here who do all of these things in a given day. It's hard to focus. It's really hard to be able to do any one of these things, let alone six or seven or eight of them. And that's what we're up against, right? We have to be able to try to get our arms around this, narrow this down a little bit so it's not quite as complicated. So the challenge, of course, this is why my talk was what it is. We have to be all these experts. Now

I'm only wearing one hat today because I'm not a CISO anymore. I don't have to. But this was kind of my life, and I suspect this is a lot of your lives. We're expected to be experts in a lot of different areas, not just technology. But we've got to find a way to talk about this in a way where everybody understands this from a level playing field. So one of the things that I've done, or I've put together a very simple framework. Not reinventing the wheel. This is not for a doctoral thesis. Just trying to make my life easier. But this is something that I used to build when I was a CISO and I

was trying to communicate in my organization is to think about the types of risk decisions that get made in every company can really be broken down into three levels. Now, what I want to highlight here is these jobs are not absolute in these roles and it's fluid. Sometimes, somebody who's like a director of security may be called upon to make executive level decisions because they're the person who has the expertise. So, it's not so much about the positions. I have them here just as sort of a frame of reference. You kind of understand the people you might run into, make these decisions. But it's really about, there are some risk decisions that are made at the executive level. There are different ones made at a strategic level, kind of

a program level, and then there's the stuff that happens tactically every single day from your operations folks. If you can break down the risk conversation to those three levels, suddenly I don't have to have 12 different conversations. I can have three different conversations. It's not perfect. It's way better than 12. And if you build something like this, you can start to help the other folks understand how this relates. You can get the rest of the organization kind of in the same mode and let them almost talk amongst themselves, which that's like the ideal world, right? If you can get them to do it on their own. I know, I know humans. I've met them too.

But this is where we want to go, right? Think about the risk decisions that happen at these three levels. If you can do that and you can build metrics around this, if you can build communication strategies around this, The most important thing you get out of it is a lot more buy-in. Because if people at each of these levels who are trying to make decisions in the organization, you can help them in a way that's meaningful just to them, you win. So questions, thoughts before I explain a little bit more about this? Any thoughts, questions? This is where I want the food comas to kick in. I'm going to talk about that. At least I'll

show you an example. So to the question for those of you here, what kind of metrics do you present? So metrics are a big part of this. And there's a lot of ways to do it. I'm going to tell you right now. A lot of ways to do it, and there is no single right answer. I'm going to talk about some strategies at each level about metrics you can use. And I'll show you an example just to visualize it. That's the product thing. Sorry, I have to do a little bit. Come on. But I'll show you a little bit at the end about an example, but really you have to tailor this to your work,

to what's meaningful to you. So you'll hear me say that a lot today. Anything else? Cool. Let's dive in. So at the executive level, you know, CISOs have a kind of a dual problem. They themselves are typically an executive in the organization. So they have a whole business unit they have to manage and make executive level decisions about the security program. But they're also usually the advisor to the rest of the C-suite. And so they have to be able to help empower those folks to make good risk decisions as well. The challenge, again, that we have is, if we're going to go back to this idea that a lot of us come up out of

technology and not necessarily out of risk management, we often approach this problem with what's familiar, which is technical metrics, right? And that can be a big problem because the people you're talking to at this level, number one, don't understand the context of what you're talking about. And number two, don't really have time to hear it. These are people that have a lot of decisions they've got to make at a given day. Not just about you and your security program, they've got to make other business decisions that affect the course of the whole company. And it's one of the reasons why you see a lot of things like stoplight color graphics for metrics for executives. Right?

You guys know what I'm talking about? Red, yellow, green? I see some of you laughing about that. Look, we use those colors for the C-suite not because they're idiots. Well, okay, sometimes they're idiots, but it's not why we use those colors. We use them because they're easy, they're simple. And if I have 500 decisions to make today, I don't want to spend half an hour on your one decision. Just help me understand, are we good or are we not? If we're good, keep doing your job, we'll carry on. If you're not, what do you need to make it right? At this level of the organization, I don't need to get into the weeds. I just need to know, is the company in danger? Are we at risk or are

we not? Stoplight colors are fine for that, right? So finding ways to make this very simple and intuitive, where I can take one glance at the metric and get it, is really critical when you're talking to these folks. It's not because they're stupid. I can't emphasize that enough. I've had this argument for too many years of my career. Trust your C-suite a little bit here, I promise you. But you've got to help make them easy and quick. And this can backfire if you don't do it. In my first role as a CISO, I got tasked, I got brought into an organization that had a security program, wasn't really doing anything. We had five people on

the team, six after I got hired. We were doing nothing. And my CEO said, go forth and make it happen whatever it takes. Those are good marching orders. So we did. I told the IT department and everybody else, this is going to be a no excuses session. We're doing it. And I told my team, 30 days, first 30 days, we're going to go through a patching exercise because it's low hanging fruit. It had been patching for two years. Let's just get it done. If you have any complaints, any problems, you tell the people to come talk to me. That's my job now, to deal with all the database admins who tell me, you can't reboot

my server. Those are fun conversations, by the way. Really? You didn't build in resiliency to your database? I would have thought for sure you would have built in resiliency on that. I absolutely did. Oh, so you are good at your job. Why can't we reboot OneNode then? It's funny how database happens. Somebody's like, oh, yeah, I guess you can. Okay, go ahead and patch it. Anyway, those are whole other strategies. If you guys ever want to talk about those kinds of things, I can help you there. But team went off. 30 days. We went after it. Start of that time, my organization had about 300,000 employees. Open vulnerabilities in our environment and by the time

we got to the end of the month We had resolved about a hundred thousand of them mostly in the the critical high kind of ranges I see a couple of you nodding which is good. That's a good sign a hundred thousand vulnerabilities in 30 days is Pretty good. I got to tell you And look we celebrated I took the team out to dinner like they busted ass It was good might have been some whiskey involved with that because you know you celebrate when that happens There was definitely was he involved in that? But yeah, so I went back to the board. After that I had, I wanted to report to the board and tell them

what a great job my team did, right? So what did I do? Got my PowerPoints all ready to go. I built a graph. I was like, hey, I'm even gonna do this by a percentage, do a trend, they'll understand. And I added my little trend line at the top. Started the month at 300,000 vulnerabilities. We dropped down to 200,000 at the end of the month. 34% reduction in risk. Awesome, right guys? Isn't that great? Boy, some of you laughing, you already know where this is going, right? My general counsel at this company, the lawyer, of course, looks over at me and says, so what, you only did one third of your job? He's not wrong. From that perspective, from a legal perspective, what did I just tell him?

There are 300,000 places where the organization is at risk and could be harmed, and I left 200,000 of them behind. That's what he heard. So look, any of us who live in this industry, we know that was a massive step forward. But to the lawyer, just sounds like they need a new CISO. You have to find a better way to talk about this stuff other than volume-based metrics and big technical numbers. We love our volume-based metrics, right? We stopped 95,000 probe attempts on the perimeter. Yeah, that's great. What does that mean to a CFO? Nothing. Because is it 95 million bad or is 95 bad? Like, we don't know. They don't know the context. So stay away from volume-based metrics. If you're going to talk to the

board, they don't need to understand that stuff. That's workload management. That's what the ops people need to understand when they're solving the problem. Keep it simple. Keep it intuitive. Make sure that what you're doing, I can tell what you're talking about at a glance. If you can't tell it, refine the metric. And again, I don't care what it is. Use stoplight colors? Great. Use letter grades. I don't care. Use a score. If they're happy with that, they like percentages, I don't care. Use what makes sense to them and what's easy. And if any of you are about to raise your hand and say, "Well, how do I know which one to use?" Just ask them.

I know this is going to be shocking, but I'm serious. As the CISO, sit down with other members of the C-suite and just ask them, "How can I present this information to you in a way that makes the most sense? Would you like a letter grade? Do you like a number? What would make it easier for you?" They'll tell you. They'll give you an idea. "Yeah, colors are fine." "Great. I'll do stoplight colors now." Ask them. It doesn't have to be rocket science. Just talk to them and then keep it simple. Any questions about the executive level, what's going on here and how to talk about risk with these folks? Okay, I'll come to more

stories about this in a minute. Let's talk about the strategic level. Now the strategic level is really about kind of the day-to-day program management of your security effort. This can sometimes come from the CISO, can be your directors, or can be sometimes, you know, analysts and engineers. We're all involved in trying to make sure that we understand is the program working or is it not working? Are the rules and guidelines and things, the processes we're doing today, are they actually reducing risk or are we just wasting time? And so a lot of the things that the decisions we're making at the strategic level are answering those questions. Are we efficient? Are we moving in the right direction? Are we seeing SLAs, as an example, shrink over time? So good

questions. We're trying to answer the fact of is everything actually working? Now, This is the weird level because the output of a lot of this is going to go up to the executives and down to the tactical people who have to actually do the work. So this is also the place where we make decisions about prioritization. We all talk about this today. This is where it lives. And when you're talking to people who are making decisions about what to prioritize over something else, which problem in the org do we want to fix today? Having a kind of unified way of prioritizing that's aligned with the business is really, really key here. And again, this may

be something where you have to ask. And that's okay. The people you're dealing with at the C-level, they want to do this stuff right. They don't want to see the company go bankrupt or fined or get sued by a grand jury for negligence of public funds if you're in government. That is not a fun time. There's a lot of places where they want to help. Ask them. The other thing that I want to emphasize about this is looking for outliers in the program. Now look, as security people, our whole job is built around finding anomalies and patterns. If you think about it, right? We look at log files, we're looking for events that are unusual. If we're looking for what systems to patch, we're looking for

the ones that don't have the patch. We're looking for places in a pattern where there's something isn't quite right. We're really, really, really good at finding outliers. What we're really bad at though is finding positive outliers. And at this level, if you're going to make decisions about what's working and what's not, and identifying the processes and procedures that do or don't work, you have to adjust your mindset away from who are my admins who don't patch, but you still need to find that out. Also find the ones that are absolutely killing it, because they may be doing something that will help you everywhere else. One of my consulting stints was for a very large auto manufacturer and their loan division, their financial services company, separate company.

They act as a bank. And they've got something like 114 countries that they operate as banks. Every one of those countries has its own security team. They all have to report up to the global team in the US. And they're all required to meet certain SLAs and do their thing. And they found they had a bunch of countries that were not, just were not patching for anything. So I got brought in to help them figure out why. I sat with the CSO, the deputy CSO, a couple of the managers, a few other people, and they actually had built a pretty nice manual program. Did it in Excel. They had this whole process, looked pretty good,

a lot of manual work. But they had it all set, country, country, country, country, red, yellow, green, and they could tell you exactly who wasn't doing it, who wasn't meeting SLA. Now, these guys had a 30-day SLA for patching, and we sat down and I said, "Okay, show me the problem." They said, "No problem. Look here, Germany." Germany, 66 days SLA, more than double. That's pretty bad. Okay, who else? France. France here, look at 64 days. They're not patching at all. All right. They went down the list. The 10 countries, 12 countries, they had about 39, 38 countries that were out of compliance. We went down every one of them. I finally asked them the

question. I said, "Well, guys, what's going on in Argentina?" They said, "Argentina? What are you talking about? They have an SLA compliance of nine days." They kill it. We never have to worry about Argentina. Argentina just gets it done. We never even talk to them. Great, what are they doing different? Blank stares. They'd never asked the question. They didn't even look. So we called them up. We got Argentina on the phone. I said, guys, what are you guys doing down there? They said, you got to talk to our, we got this admin in the corner that, like, you know, he doesn't talk to people. But we'll bring him onto the phone. You should talk to

him. And he gets on the phone and he's like, yeah, I don't know. I was bored. I'm like, I like PowerShell. So I wrote this PowerShell script that just like grabs the Microsoft patches and throws it out to my lab. And if it doesn't break anything in 24 hours, I wrote this other script and I throw it out to some people I know in the company who are friends of mine. And then I give them 24 hours and let them tell me if it breaks anything. And then I just let it sit for about seven days because I figured they use applications and stuff. And then at the end of seven days, I don't hear

from anybody. I wrote a third script and I just deploy it to everything. 24 hours, 24 hours, seven days. There's your nine-day SLA. Right? Automation, process, and they did it. And it was like, guys, great. Can we get those scripts, please? Right? Simple question that no one had ever asked. We got those scripts and off we went. If you're curious, by the way, they deployed those out everywhere. Every country was starting to use it. They went in 60 days after implementing that. They went from whatever, what, 38, 39 countries out of compliance to one. 60 days, they turned their whole SLA program around just because they went after the good outlier. So look, strategically, look for the places where it works because it can change everything about your

program and you can communicate those successes in really meaningful ways. All right, I'm running a little short on time. Although I'm going to blame the drawing. Sorry, guys. I'm going to blame you guys for the drawing. Let me talk about the last part, the tactical part. Now look, This one's pretty straightforward. If you've been doing everything else right, if you align with the business, you prioritize, your tactical people should know what to do. You should be able to give them a list of things. Say, here's what I need you to fix. Fix, patch, write better code, whatever it is, fix the problem. That should be okay. Where this goes wrong, in my experience, and this

might be a hard one for some of you to hear, even though you're dealing with engineers and really hardcore technical people, The problem often when they resist and they don't want to patch and they have all these excuses by why it can't be done, never has anything to do with anything technical. I've heard the same six excuses from people about why they can't patch something and I've defeated all of them pretty easily because once you start poking at it, like the database admin guy was telling you about a moment ago, there's no real technical problem. What I often hear is this alignment part. What I've heard from engineers is, well, look, I have a full-time

job. I work for IT. Security comes along, they dump this report on my desk, and they say, go deploy these 200 patches to your 1,000 systems. And even if I do that work, security team goes back up to the board and goes, hey, our security program's awesome. Check us out. We did the work. And the engineer goes, no, you didn't. I did the work. How come I'm not getting credit for the work I did? And so if I'm not going to get credit for it, and I don't get compensated for it, Screw you guys. I'm not doing it. I got a full-time job. You get past the technical stuff. I cannot tell you how often

I hear that these guys just want to be validated. They want to know that they're part of the team, that the work they're doing matters, and that they're aligned with what the business is trying to accomplish. So have some empathy. If you're going to work with these folks, and you will, you've got to understand they want to feel part of this team. Now, some of you might be those engineers in this room. And if you are, and you feel that way, tell your security team you want some help here. Because they may not know. But this is where we can start to work together in a more meaningful way. And if you can show the

engineers that what they do matters up the rest of these levels, you can align them with the business. You can get them to a place where they can see that the work they do is represented properly up the chain. Now, what does that look like? Can I take five more minutes? Is that all right? Thanks, guys. Let me show you an example of what I'm talking about, this kind of alignment of the work and everything else. This is the example I'm going to show you. Again, I cannot stress this enough. Do this the way that makes sense for your business. This is the tool I have, like I said. But find what works for you,

what represents risk appropriately for your organization. Do it that way. But at least try to understand kind of what I've been talking about here. So look, if I'm going to talk to the board at the executive level, I need this to be easy. I need to be able to look at this and go, oh, we're at a C. Sucks. How do we get to a B? Pretty quick. I can make that decision pretty easily. And colors, not because we're idiots, but look, here's my cloud environment, here's my IT environment, here's my credentials, identity stuff, here's my web applications. I don't have to be a technical expert to know, hey, our cloud's doing pretty good. Good

job, cloud people. Thank you. But how come our credential situation sucks? What do we need to do here? And as a CISO, I'm going to have an answer for that question, right? But it's a really easy way, it's kind of a risk heat map for an executive to see this and kind of go, "Oh, I see what's good and I see what's not. What do we need to do?" Notice there's no volume numbers here. No talk about number of bones, no talk about missing number of assets or anything else. This is just how much risk do these technologies contribute to the environment? This is really all I want to talk to you at the executive

level. As a CISO, I have a plan, and that plan comes from sort of the strategic analysis. The strategic analysis is we're going to take this and dive down. Maybe I'm going to break this out a little bit more by team or by admin or by technology area or by business function or whatever I want to do. Obviously, we're always trying to make decisions about where to start. Most of us use Excel for that, at least I did. I'm sure a lot of you do too. But if I could just look at something here and go, wow, wait a second, how come the United Federation of Planets is sucking it right now? Sorry, I picked

the Unite-- I'm going to read Trekkies out there. Sorry, that's for you. All right. But hey, that takes me two seconds to figure out that that team isn't patching. I don't have to go try to guess at who's not doing it. I know who's not doing it. So let's go find out why. Because maybe they need help. Maybe they're short staffed. Maybe they don't have the tools. Maybe there's been a death in the family and someone's not there. Who knows? But I don't have to spend a week figuring it out. I can spend a second figuring it out. And as a CISO, this is powerful. Because if I'm going up the level, I need to

be able to tell the executives we have it under control. We have a plan in place. We know the team where the risk is coming from. We have a plan and we're working on it. And as an executive, that's all I want to hear. Tell me you got it. And next month I want to see progress. Easy, right? Same thing can be said for like SLAs. I'm a big fan of looking at SLAs. Look at, be able, when you're looking at SLA compliance, do me a favor. Whatever your number is, 30 days as an example, look at what it is hypothetically at 21 days, 14 days, and 7 days. And the reason I say that

is because the number of times I see organizations who say, ah yeah, we have 30 day compliance at like 96%, we're killing it, we're awesome, 30 days. Well, we're still giving the attackers 30 days, right? So you say to yourself, okay, well hypothetically, what do our numbers look like if the SLA was 21? Right? So one company I worked with at 21 days, they were at 12% compliance. Wait, you're at 96% compliance on day 30. You're at 12% compliance on day 21. What I hear there is you can do it all in nine days. Because why is it a day 21? Your teams haven't done anything. But by day 30, you guys caught up 80

something, 80%. What's up? What's going on? Why has that happened? So you're going to look at this. This is program optimization, right? This is how I can look at my, what I thought was a good policy, 30 days. Maybe we need to talk about making it 14, because we can. The team is demonstrating we can do it in nine days. Let's do it. The more we optimize the program, the better that we can make security work, right? That's the goal, reduce risk. So look at your SLAs. Make sure you're looking at that kind of stuff. When you get down to the bottom, which is a terrible way to say that, I'm sorry. We get down

to the tactical level. Y'all are now at the bottom. Sorry, if any of you are in tactical level, I apologize. That was not what I meant. You are the foundation of this thing, though. We can break this out by individual, right? Look at the numbers individually and start to say, like, okay, well, you know, hey, this is pretty obvious. This admin is not cutting it. They only represent a small percentage of the overall environment, and their assets that they manage contribute a small amount of risk. But for some reason, you're not patching. You're not doing it. What's going on? We don't even give the attackers one opportunity, so let's go talk to that person and

find out what's happening. And of course it's all trending in scores and we're using this number down here to kind of represent how much risk they contribute. I also, by the way, you can see, I want to look at my good outlier. How come they're doing well? Let's go talk to them and find out what's going on. The same kind of thing. Really easy way to glance. And the nice thing about this is that whoever is here, we're using the same kind of metrics to represent a risk score. and we're using the same letter grades, we're using all the same numbers. Which means if I tell an admin this thing at the bottom and say, "Listen, I need your help. If you can fix these 20 problems

in your servers, you move the overall score of the organization by 42 points." And that score is so I can directly tie an engineer's work to the number that the executives see. And if I'm responsible as a security leader, I'll give them that credit. Because I can go back and say, "Hey, you want to know why we trended down 10% last month? It's because Nathan finally did his job and stopped being a slack." No. Because Nathan put in a lot of work and patched some servers. Right? But this kind of, it's simple alignment. We're not recreating, this is not crazy math here. But you can see how a really simple use of unified metrics means I can talk to the engineers and say, can you just,

if you can just move the number by, we're really just talking about risk contribution, but contribute a little less risk here, we can take that all the way up to the executives. This is an alignment technique, and it means that the engineer who feels like they're not getting validated goes, oh, security won't take credit for my work. Like, I get to take credit for my work. Yeah, hell yeah you do. That's what we want. And now everybody also talks about risk the same way. We see scoring mechanisms here where people are like, "Oh, dude, how do I get to an A? I want to move my servers from a B to an A." Cool, I

can help you do that. But you know who else is asking that question? These people. Because the CFO wants to know, "How do we move that from a C to an A? What is it going to take for the whole organization to move that direction?" You get people aligned, starting to talk about this stuff the same way. And suddenly you don't, as the security person, don't have to translate 12 different conversations. we can talk about risk in a really unified way that everybody kind of understands. Without getting technical, we're not bombarding them with big metrics, big volume numbers, right? No vulns, no probe attempts, no events, trying to help them make good decisions about how to mitigate risk. That's what

we're here to do. And we all should be doing that. Okay. I went a little over time. I apologize. Any questions, thoughts, anything? All right, guys. Well, thank you for the time today and appreciate it here. Thank you.

- Oh, thank you, that's very kind. Do you want to use the lab? - Yeah. - Yeah, yeah. The guy's gonna make sure it's in the right place. - Is there a remote included or that's? - Yeah. - Yeah, okay. - Perfect. Just give me a sec here. Guess I'm gonna put this in my pocket. Is your presentation the same as Cremant was going to present? Yes, almost. It's almost identical. There's a picture of my cat. Same title. Okay. - I did, I got that. - I'm all set, thank you. - Appreciate it by the way, thanks. - Great, sweet. - Controlling it, is this gonna work or what? - No. - We can do anything, funky

to your machine. Whoop, whoop, you're good. - Yeah, which one is it? It's the left, right, okay. - Yeah, so the large button's-- - All right, no problem. Is this on? Testing. It's on. Okay. Yeah, okay. All right. Thank you, Nathan. Next up we have Pierre presenting on Cloud Environment's Red Team Perspective. All right. Testing, testing. Everyone can hear me well? Yeah? It's good? For volume? Okay, cool. All right. I'm going to put myself a little timer. Sorry. All right, welcome to Cloud Environment's Red Team Perspective. I'm going to jump right into it. Who am I? My name is Pierre Nicolas. You can call me Pierre. I'm a senior penetration tester at Bell Canada's STIRT team.

That is the Security Testing and Incident Response team. I do a lot of penetration testing, red team operations, purple team engagements, recently some cloud stuff, which you'll see in this here presentation. I also do a little bit of malware development for the Red Team purposes. And here are my two cats, which I have to mention. There we are. What's on the agenda today? Not all of these are equal, just a little preface. We're going to be talking about Cloud Security 101, cloud security challenges, offensive operations in the cloud, approaches and methodologies, standards and frameworks, the cloud attack lifecycle as we like to define it, leveraging the cloud as a red team operator, and finally, cloud security best practices these will not, we won't be spending as much

time on all these topics and I've practiced this a number of times and always come out over time so I will be skipping through a little bit of the more complex stuff and try to get to the interesting stuff you may not have seen before. So, Cloud Security 101, I'm not going to spend too much time here because I'm sure most of you are at least somewhat familiar with what the cloud is. But cloud in very, very simple terms is other people's computers and infrastructure. Very simple terms. The three main providers, there's Amazon's AWS, there's Microsoft Azure, and there's Google's GCP. There are others, but they're pretty niche, so they will be outside of the

scope of the talk today. And why do people use cloud? Well, all sorts of reasons. Scalability, reliability, cost efficiency, accessibility, flexibility, all sorts of things. So again, a little bit of speed in these here parts. There are different AASs, as you may have noticed in your perusing of these documentations. SAS, FAS, PAS, IAS. What does this mean? I'll resume it as... I like to think of it as different levels of granularity and capacity when it comes to using other people's computers and infrastructure, like I said. So you may be interested in simply using the processing power of a cloud setup and just use only the function you're passing it just a piece of code, you want it to calculate something, give you an answer, you're going to

use function as a service. You might be interested in having VMs, actual full machines, in which case you're going to be using more of the infrastructure that's provided by the cloud provider. You might be using the identity service, as we're going to see a little bit later. So basically what these break down to is, what parts of the infrastructure do you need access to and you're going to subscribe to whatever it is that you need. This is an advantage of cloud because it gives you the flexibility to pick and choose on a cost basis and also on a needs basis what components you're going to be actually paying for and leveraging. An important thing to

understand is that cloud does not equal not your responsibility. There's a lot of, unfortunately, a lot of organizations that tend to assume that security in the cloud is not something that they need to consider because it's outsourced. It's someone else's infrastructure, and therefore it's not theirs to secure and properly configure. This is very much so not the case. Here you've got just a small comparison of different types of applications. of services that you might subscribe to from cloud providers versus on-prem. So if we're talking about on-prem, you know, servers that are actually in your organization, your internal network, things you fully have control of, hardware that's in your internal network, in those cases, everything is

your responsibility. But as we start using different cloud services, we start to have a shared responsibility model where security is both the responsibility of the provider and yourself. Although, like I said, it's never entirely their responsibility. If you start using, for example, Microsoft cloud infrastructure and you have a plethora of servers, yeah, those servers might be in a data center somewhere. The physical security of that data center is not your responsibility. If there's a fire, it's not your responsibility. But if you create a bunch of accounts, configure them in a bad way, and then attacker gets access and starts to do nasty things, that's your fault. And that's something that you need to consider as

an implication for your usage of these services, which leads into-- couple of examples. I'm not going to go over these, but just to show you there are major incidents that occur with regards to cloud infrastructure that can be extremely damaging to you as the user or to the parent organization itself. Going back in 2019, I just wanna show that this happens, it exists, and also it evolves over time. In the past, we saw more typical, the types of attacks we were seeing were more typical web application attacks, starting a lot with SSRF attacks, server-side request forgery, Really flaws with the APIs or the infrastructure itself that could be abused by attackers. In 2023, what we're

seeing more of is identity-based leveraging. People finding permission issues between accounts, across accounts from different organizations that can influence each other, leakage of accounts, stuff like this. So it changes over time, something to consider. Yeah, jumping right into the meat of it. Azure versus Azure AD, I just want to get this said. Okay, Azure is not equal to Azure AD. They are not the same thing. It's very confusing naming, which is perhaps why they have moved towards changing the name, I believe, to Intra. But yeah, it's not the same thing. Azure AD is a granular component of Azure Cloud Services as a whole. It is really the identity service that is concerned here. And you will see it is not either a direct correlation to Windows Server

Active Directory, which is a whole plethora of other things that are outside the scope of this talk. But I just wanted to mention it is not the same one-to-one thing. And we will talk specifically about Azure AD, but also a little bit about Azure as a whole. So this is just the vocabulary getting out of the way. Yeah, it's not Azure AD. Azure is Microsoft Cloud's platform, whereas the Azure AD is the enterprise identity service. And we'll see what that implies in a little bit. Moving on to GCP and get used to this. There's a lot of jumping around between the different providers. This talk is about the three main providers and the similarities and differences between them, but also, like the title suggests, the red team perspective. So

I'm not going to talk too much about what cloud actually is. I'm going to talk about how we look at it from an attack perspective. But just to get this out of the way, GCP has its own IAM model and essentially the domain that you would be familiar with is the company and afterwards it's organized into folders which have various rights and permissions on projects. The projects actually then allocate whatever resources required. You can have things like VMs, you can have things like functions, whatever it is you need. Between these three providers, there's basically different naming schemes, but a lot of the same services. So you might see in AWS something is called an S3 bucket, but in Microsoft it's a blob. Or for example, in GCP

you've got your compute engine instances, which are really just another word for virtual machines. So just to give you an idea, AWS, again, different organizations, different hierarchy, but similar concepts. Really in this case, the tenants that you would be familiar with would be the accounts. In some cases it'll be the organization, but not everybody does that. More or less frequently we see accounts as being the root object that is in use and that's what we end up targeting. Underneath you'll have your resource groups with again various permissions. And then at the very end you'll have your actual assets EC2 instances, which are VMs or like we just saw in GCP, cloud compute engines. S3 buckets, which are the storage, etc. So, not going to talk too much

about that. But what does this imply? For an attacker, cloud infrastructure is a new way to get into your internal directory, or internal network, rather. It is a new internet-facing attack surface that opponents are going to leverage to do damage or potentially extract information from your organization. Typically, you'll see an example of a way in to an internal network of whatever organization would be, just as an example, a web application that has vulnerability. That web application, even though it might be vulnerable, might be behind a very strong web application firewall, WAF, right here. So an attacker first has to contend with the web application firewall, then let's say they managed to get through it. Let's say they managed to exploit that web application. Now they have remote

code execution on that server. Great. That server is probably in a DMZ. The DMZ is not directly connected to the internal network. They're going to have to pass through some firewalls. They might have to pass through, hopefully, some sort of network segmentation. There might be all sorts of countermeasures in place, CMs, IDS, IPS, all sorts of things that are going to prevent them from leveraging that level of access to then go and do big damage here in the internal network. One thing that attackers appreciate from the cloud is that it often gives direct access to the internal network and is not secured in the same way with all of these more mature countermeasures that you

would be expecting from a typical internet facing path. So basically big takeaway, it increases your attack surface, it introduces new vulnerabilities, it is complex and organizations have not yet caught up in the understanding of how to properly secure it most of the time. There are some detection and response tools that function at this level, but they're not very widely implemented and they're often not well understood, but they are starting to get there. And it also gives access, something that isn't often considered, but it also gives access from the internal network to the cloud. So an attacker who has already compromised a workstation, say one of your employees opens a malicious email, downloads a payload, detonates

it, and now you have remote code execution on that asset. Well, now there's a new way to get more, let's say, goods out of that position that you're in. You might be able to extract information that previously was not available because you can leverage the fact that the internal network is connected to the cloud environment. So it also adds new paths to further compromise from the internal perspective as well, not just from the outside. So there's basically a whole bunch of new attack surface that's opened up by this. Cloud environments present challenges for attackers as well, of course. There are new systems involved and we need to understand them in order to hack them. There's

less opportunities for traditional types of attacks like MITM. For example, one of the bread and butter things that we do in internal engagements is man-in-the-middle poisoning type attacks that leverage deprecated resolution protocols like LMNR or multicast DNS or BIOS name resolution and more recently IPv6 poisoning. You can't do any of that sort of stuff from the cloud, right? It's just a different position that you're in. So you have to rethink your tools and tactics. but it can still be incredibly useful. There are different IAM models between the major providers which can be a whole headache and which I will skip over in this presentation because I just do not have time to explain it all

but you'll see at least from the slides that there is a considerable amount of complexity there. And you need to stay ahead of the curve as an attacker because a lot of this is not documented or poorly documented or only documented by other hackers and changing all the time. And since it's not documented, you know, these companies don't necessarily have any reason to tell you when they change an API call, the structure of it, or or what have you. So basically the research is not well defined yet. It is getting there and there is some good resources available online, but it's not yet fully mature. And this of course presents a challenge for attackers. So

I said I would skip this part. I'm just going to mention it very, very briefly. AWS, GCP and Azure have different IAM models. There are basically users in all of these cases, there are roles and permissions in all of these cases, and typically there are service accounts in all of these cases. Service accounts which are tied to the usage of applications or resources that you're using in these cloud environments, and then users which are users, as you may have guessed. Like, yeah, I'm gonna skip through that part. Why does this matter? Without having explained the IAM model, this is a cheap cop-out, but either way, This is a typical example of something that is not considered by a company. So down here you have your Pentest account. This

is a compromised account in our example company. It has reset password permissions on the SVC backup account. This is something you might see in real life, actually. The SVC backup account was used to create an application in Azure. So it is the owner of this application in Azure, the data platform application. And the data platform application is running as this data platform service account over here. This is usually something that will be done because first of all the application needs a service account to run as and second of all Application creators are going to be attempting to create segmentation at the very least from their account that they've used to create it With the account that the application uses to do its various services What isn't considered and

why I am models are so important is because is because of this this relationship that allows for takeover. Because you can reset the password here and this guy owns this application which is running as that user, essentially this user owns that user all the way in the corner. If this user, which is intended to be the one that the application runs as, has certain permissions that the application needs in order to function, that can be leveraged by the attacker who has compromised the first. the first account. In this case, you can list all the details and download items from OneDrive users based on these fairly common permissions that you might find an application having. Now

you can imagine that as an attacker you get access to an account. Now you can download all of the OneDrive information. That's pretty powerful and you might be able to recycle that information, find new credentials, secrets, processes, etc. and leverage it to further your attacks. So, just a little precursor. Alright. Cloud Client, there's many ways to interface with these cloud services. Azure by far is the most complex. It has a whole bunch and this isn't even all of them. Some of them are legacy and deprecated, but I just wanted to mention that there are a bunch of ways to interact with these services from a command line or essentially. So that's all I wanted there.

Now, moving into the crux of the material, consider that to be the intro. Cloud Offensive Operations. At Bell, what we've done is we've split this into three different types of categories. We have penetration testing, we have cloud offensive operations, and cloud purple team exercises. So penetration testing, we split it into three tiers. There's a black box, a gray box, and a white box approach. They complement each other and are not either/or. They're often all required in order to get a good coverage of the application. I'll explain why in a bit. Red team operations focus on specific goals and typically we're going to use a plethora of different tactics that might be a little bit more

advanced or invasive depending on the scope and rules of engagement that we've agreed upon. That would include social engineering, it would include phishing, and it would include perhaps even moving on site if it's required. And purple team exercises are going to be sort of like a red team but with more of an emphasis on collaboration with the blue team or security operations center of the client where we're going to try to help them come up with better response and detection methodologies and see where they're lacking when we do certain actions. So different goals in these types of events. The methodology, like I spoke about, we split the pentesting into three different components: the external, the assumed breach, and the security audit, which is the different box colors. So,

the reason why we do this is you might have a black box engagement that occurs and we look at your profile on the internet, we do our OSINT methods, we don't find anything. There's no exposed credentials, there's no badly configured services that are visible from the outside, there's nothing we can do to get a foothold. But you might have some server that is very, very poorly configured. And the day that there is someone who gets an account, maybe, you know, some person in your organization clicks on a link or does something bad or changes their password and reuses it somewhere else and some website gets breached, whatever, there's a reason why we have a way

in now. Well, the day that that happens and you've only done black box perspective, you might think you're fully secure, but you're absolutely not. So what we do is we... We include this gray box perspective, which will leverage an identity that has been provided that represents our standard employee. And we'll see, OK, if this standard employee gets breached, what's the worst that can happen? And often, companies are surprised to see what is the worst that can happen. They might be expecting, because from an external point of view, there is no current low-hanging fruit, then there might not be anything to find. But that's often not the case. Similar rationale is applied to the white box

perspective. So when we do the white box, we ask for a high privilege account, which has access to everything in the cloud environment. And then what we're going to do is we're going to systematically audit everything to see, okay, in those cases, it might give us visibility on certain assets that we just would never even see if we were using the employee account. That can be important when you're dealing with assets that have, say, random alphanumeric subdomains. It's like an MD5 hash or something. Something you will never find or guess programmatically. And now you have access to it. You have visibility on it. Oh, look at that. It's terrible. That's terribly configured, it's easy for

an attacker to do an incredible amount of damage with it, etc. So this is a bit the ideology behind splitting this into three different tiers. And again, they complement each other, they aren't replacements for each other. So standards and frameworks, I'm going to talk just a little bit about this, and I'll explain why. MITRE has some good stuff, they're very good at making matrices. We are not going to talk too much about the matrix because when it comes to cloud, in my opinion, there is a lot of overlap with the different steps. And also the steps are not so much sequential as you would expect them to be. Sometimes you have a step that skips

another one. Sometimes you have one step which... takes three steps in one and this is often the case. So I just wanted to mention that MITRE has some attack frameworks for cloud specifically. Microsoft has their own and there are some in the community like Alina Lau has a good one on GitHub. which is available. So there are some ways to understand this, but I wouldn't use this as a rigid framework to base your understanding of cloud pentesting on. It's more of something that can complement it. Although we will do some callbacks to this framework here. So this is the cloud matrix framework, and it breaks down in its steps. If you don't know, there's the

initial access Excuse me. The execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, etc. You'll see in my examples later why this isn't so much a good thing to base yourself on rigidly, but it is helpful to understand the overall process and it will be referenced in this documentation. So, let's get into the meat of it. This is the actual reason why I'm here. So, CloudAttack lifecycle. We've got the first step, which is identifying the target, always. In the three different cases of these providers, it's going to be either identifying the organization name, the AWS account ID, or the tenant ID, which is basically the same thing. It's an identifier which represents your

cloud environment that you are leasing from the cloud provider. That's what we base our initial attack on, and everything that comes after is based off of this discovery. The first step, so again, I said I would reference MITRE, right? But you'll see why. So the first step, initial access. It occurs in one of six ways, typically. We either exploit a cloud component, which is a VM, a function, some storage buckets, whatever. Exploit an identity, which is leaked. It could be an access token, or it could be actually credentials. Spraying, which can be username, brute forcing usernames, password spraying, etc., phishing users for credentials or to bypass MFA. Exploiting a device. This happens when we already have access to your internal environment, but maybe we aren't domain admin. We might

not have all the keys to the castle. We might just have a very small foothold in your internal environment. Maybe we just have one user or one workstation that's been compromised. But if that workstation is joined to the cloud and there are ways for us to bounce into the cloud and then back into your internal environment or just into the cloud and get some secrets there, this is one way that we would get initial access to the cloud environment. and abusing trust relationships, specifically supply chain attacks or trust relationships that exist between different organizations or tenants in different cloud environments. You've got some examples of this here. So DNS enumeration, certificate transparency lists, classic OSINT

stuff, that's open source intelligence gathering. I'm going to use that acronym a lot. But this is where we would essentially grab a list of valid targets and things of the source. Search engine indexing, so dorks. There are Google dorks, there are Bing dorks, there's pretty much any search engine has dorks. These are specific operators that let us search for very specific information that's been unintentionally indexed by these great services. This is actually a functional dork, so if you use this right now, you will find creds on the internet to some organizations that I have no affiliation with. But yeah, this is actually working as of this morning. And it's just to illustrate the point. We

would of course refine these and include keywords that relate to this specific target. We're not just looking broadly, but you should be aware that attackers are looking broadly and will eventually find things that are leaked. So that's a good example. Publicly accessible storage. So S3 buckets, cloud storage, Azure blobs. There are aggregation websites and services that exist to find these. Like Grey Hat Warfare is a good one. Here on the left, left, I should say. There is an example of a Python tool which is open source available on GitHub which allows identifying open S3 buckets. You give it a keyword. In this case, the target is devcloudbuck, which is a target we created for this

presentation. And we configured a S3 bucket to be accessible publicly. So you can use this. It'll do some rudimentary brute forcing and permutations on the name to find open S3 buckets. buckets and then it'll list them for you. And then here you've got an example of some goods you would find super secret key. You can imagine this would be an SSH key. It might be some random documents that disclose information about your internal processes. It could be anything. But if it's open, attackers will find it if they're targeting you. Traditional web application vulnerabilities is another way in. Usually you'll see this when cloud components are implemented into web applications like cloud functions, for example, might

be used as back end for an application or maybe the application itself is hosted on a cloud VM. So if we can exploit that application in a traditional way, we will have execution in the context of the cloud account that is running it. So this is another way we get initial access. Open services, this is typical, normal stuff if you have a cloud VM and it's running certain deprecated or vulnerable services on certain ports, or maybe it just has an open port, you know, where you can connect and do some nasty stuff. Well, we can find that just as if it was a regular physical server, same thing. There's also vulnerable serverless functions, I already

went over that. Leaked credentials, there's great tools that allow you to find leaked credentials on the internet. We're gonna spend a bit more time on these, so I won't talk about them now. Password spray, also going to talk more about these in detail. System compromise, this is like when you're in an internal environment and you have system on an asset, server, workstation, whatever, you can extract a primary refresh token, for example, from the computer itself and then use that to access the cloud environment as that computer's account. So you can also do phishing, which we'll talk about again in more details in a sec. So let's move on. Here you've just got a couple of

specific examples for each one, so AWS, Azure, and GCP. You see here it's pretty much the same thing. You can exploit public... VMs and snapshots. This one's actually kind of cool. Lots of companies will have snapshots or volumes of certain assets that are accessible on the internet that belong to assets that are either in the cloud or that are not in the cloud and that are in their internal environment. We've actually seen this in practice where an organization will have, for example, a snapshot backup of their domain controller VM. And then that is hosted publicly in the cloud. But the domain controller is not connected to the internet. Well, if we can get that snapshot,

which is publicly available, we can set up our own computer in our own cloud instance and then just mount that. And we have full control of our own computer. And we just own your domain controller. So this is something we see often. Also, when you get access to a particular server, you might be able to find certain tokens, right? These are just paths that you would look for in different cases, but it's, as you can see, the same thing. It's just a different path. You'll find tokens there. Tokens are cool because they often allow you to bypass MFA because there's kind of an assumption that you've already passed through the MFA transaction in order to

acquire them. So there's limitations on how they're used, but they can be pretty much equivalent or better than credentials in some cases. Okay, so more on access tokens. We can search for these also on the internet because they follow certain patterns. In AWS case, They all start with AKIA. This is a pattern that we can leverage to programmatically look for them. There are services that exist to leverage that. And we can also find, for example, in the case of GCP, like JSON files, which are service count JSON files, which are essentially equivalent to accessing that service count. In the picture you have here, the example is us using the legitimate Google Cloud CLI to upload

or to actually use the IAP-SA JSON file that we have recovered off of the internet. So it was publicly accessible. We found it by searching for it using OSINT again. Well, we can activate that account and now we have access to the projects that that account has access to. So these are just some of the ways that you can leverage these things. And there's a couple of tools here at the bottom. I encourage you to check them out. Some of them are very good, like Truffle Hog, for example, very good tool to do this. Other ways that we get initial access, and it's going to be like this, guys. I'm going to go through them

fast. I'm trying to give you red team perspectives, not teach you everything about it. So initial access, another way we can do it is through user enumeration, particularly in the case of Azure, because Azure doesn't consider this to be a vulnerability. Rather, Microsoft doesn't consider it to be a vulnerability. So they allow username enumeration to continue to exist. It's kind of a by design thing. So yeah, in this case, we're using Credmaster, which is all these tools, by the way, all available on GitHub, all free, all open source, et cetera. In this case, what we're doing is we're creating a list of potential users. We're going to do that through, again, OSINT. We're going to

look at your company's LinkedIn. We're going to look at your company's website. We're going to grab all of the employees' names, everyone who has anything to do with your company. We're going to derive the structure of email addresses that your company is using. So typically it's like first name dot last name or the first letter of the last name and then the first name, whatever. These are predictable patterns. We'll create lists of users that have usernames based on these patterns and we will feed it to these types of tools. These tools in this case are, this case this tool is leveraging AWS infrastructure in order to do this. So we're using AWS and a technique

or tool called FireProx, which basically we create an API gateway and we rotate the IP every time that we make a request. So we can avoid lockout policies this way. As we move forward in time, these companies are getting, or these providers are getting better at detecting this sort of thing. So we also have to add certain randomization like user agent randomization to make it look like it's coming from a different device by adding different HTTP headers. We also have to add jitter to the time intervals. Machine learning is getting better at seeing attacks, so we have to add a little bit more randomness to the attacks, but it's still entirely possible. So in this

case, we're using a specific region which looks legitimate and we are trying all of these usernames until we find some valid ones. Everything's blacked out but the idea is we take a list that we've created and we find valid usernames. Then we do the same thing with passwords until we get a hit. And in this case we're doing again the same thing. You see we've added a delay to the command but again this is just an arbitrary tool. You can use any tool to do this. You can make your own tool. We're using a specific region and we're rotating the IP again every time that we do these requests. So, here you see we have

some valid ones. Okay, cool. So we've done some password spraying, we've found some users, now what? What if there is MFA? MFA is, in this case, or typically based on conditional access policies. In this case, conditional access is an if-then statement. So it says if you want to access a resource, then you have to complete a certain action. This is typically how multi-factor authentication is implemented. So, So there are a number of ways to get around it. Usually it has to do with misconfiguration. We are using a tool called MFA Sweep. Again, free, open source, GitHub, which can be used to test what are the factors that force the use of MFA. There are sometimes

exceptions, and we will leverage those exceptions as an attacker. So these are the typical exceptions. You've got legacy authentication. That means old protocols that just don't work with MFA. They break, so we create exceptions for them. You've got geolocation based. I skipped one. I'll get back to it. You've got geolocation based. So anything from China, deny it. We are in the US. We're not going to let that happen. device type, right? That one is something that MFA sweep will be able to detect. Perhaps all of the C-level at your organization uses iPhones and they can't be bothered with MFA because it reduces their productivity. I've seen that. So they make it so that all iPhones

don't have to use MFA. Or maybe Linux devices because it breaks, whatever. There's also user-based conditions. So there might be groups within the cloud environment that are specifically allowing this. Again, like execs, IT, break glass accounts. So accounts that you'll use if you're locked out of your cloud environment. You might not want MFA on that one account. And it's actually kind of common to have that. And also cookie or access token hijacking. Usually these will bypass MFA altogether. Because like I said earlier, there's an assumption that you've already passed through the appropriate channels. In this case here, we're using MFA sweep to detect which cases are required or not the use of multi-factor authentication. We

see that Linux, Android, and iPhone do not need it. So we would then emulate those user agents or those devices and use them to access this account that we previously found without passing through multi-factor authentication. One thing that I didn't mention and that I'm going back to it, the wireless guest network thing here. So another way that conditional access policies are applied for MFA is through IP ranges. Typically an organization might say, "Okay, all the exit IPs of our internal network, we are going to make it so that they don't have to use multi-factor authentication because we trust that the people are sitting at their desk, we know who they are, we already have cameras

and security guards and all this, so it's fine, they don't have to use 2FA." Well, in that case, something that we've actually seen in practice and that occurs is they'll include accidentally or through neglect the exit IP of their guest network, which happens to perhaps overlap in range with what they're using for their internal network. So what we can do then in those cases is we can drive up to the company, go in the lobby, sign into the guest network with no creds, and then use these accounts that we've derived creds for and bypass MFA because they've allowed the guest network to do so. So this is a good example of things not to do.

Other perspectives, right? Switching up a lot, but for initial access, something that we will do often is leverage communication apps, things that are built into the cloud environment themselves, things like Teams or Google Chat. By default, Google Chat will allow communication from an outside organization. Same thing with teams in a lot of cases. We can create a very realistic outside organization which mimics or looks identical to something that the user is expecting to see. Perhaps a subsidiary, perhaps the same organization itself but with a small change in the letters, whatever. And then we will send them basically spear phishing. What's cool about this as opposed to traditional email phishing is it often bypasses all of

those traditional countermeasures. Remember the graph at the beginning where there's all those countermeasures that are in place but not from the cloud environment. So a lot of people are not protecting against this sort of thing. Although they might have a very good anti-spam filter, they might have, you know, deep packet inspection and they might have a firewall which is stopping resolution of malicious host names and all this. But if we use these, which are legitimate tools that are not watched, we can get past those things, send a malicious link and then, you know, do our thing that way. So this is something we might leverage. AWS assume role abuse. This is more specific but also pretty cool. AWS in particular, now we've moved on to a different

one, has policies which allow for assume role, which is basically an impersonation. The assume role action allows you to take that role that you're asking for through the API. Because of a discrepancy between the response when you ask for a role that doesn't exist or that does exist, we can brute force programmatically a bunch of roles like write access, full admin, global admin, just stuff that might common sense be in use. And we will determine which roles actually do exist at that organization. If any of them are configured as follows, like with principal and then a star, meaning anybody, we can actually After that, take our attacker organization, which also exists in AWS, create an account, and then assume that role. Since we know the name

of the role, we've brute-forced it, and it's misconfigured, we can give that role to our attacker account. This can be very dangerous, and it occurs in practice as well. So there's tools to help with the brute-forcing components of this, although you can just do it yourself. Just a little example of another initial access technique. Now, moving on to Azure. Again, we're spending a lot of time in initial access because of Red Team perspectives. We just want to give you guys a little bit of an eye-opener. So, illicit consent grant. This is a really cool one. We basically create a new tenant in Azure, and we create a new application that is attacker-controlled. The application, we

ask... are going to abuse delegation between the victim and that application. And we're basically going to generate a link which is going to ask the victim to delegate their permissions in their Azure organization to ours, to the application specifically. And it would look something like this. So this is the crafted email. It looks very legitimate. When they click on it, they get this legitimate, like not crafted, this is a real Microsoft pop-up asking for consent. You can see the company, like the attacker company that we've created is MSFT Security Services. up there, looks very realistic. We're using the Microsoft logo. The only indicator that this is malicious is that it says unverified. That's it. If

they accept, they are going to be essentially sending us their access token and refresh token. The access token has a short lifespan. We can use the refresh token for up to 90 days to reobtain the access token. And we would get whatever permissions that they have accorded to the application. So that user, if they have certain permissions on certain things within their cloud organization. Now we have access to that as well. So this is pretty powerful. It's been partially patched since 2020. There are new countermeasures in place like the warnings changed basically, but it still remains exploitable and pretty much the same. Another type of leveraging of legitimate Microsoft infrastructure in order to do phishing

is device code phishing. So this link here, Microsoft device login, exists for devices that are not smart devices, that don't have a web browser and that you want to enroll in your Azure services. So we can use those to create this here code and then we can send that code to the victim in an email that looks like this. If they click on the link, it sends them to the legitimate device code enrollment endpoint from Microsoft. They enter the code that we've provided and then it It again gives us an access token and a refresh token to their instance. The only difference here is we can't control which permissions we want. We are going to

get just basic permissions, but they are enough to, for example, list all the users of the Azure environment. With all those users, we can then re-go back into the first stages and start attacking those users for password sprays or other types of things. So it would feed into the attack lifecycle. Moving to persistence. So this is changing up the MITRE framework a little bit. There are many ways that we can get persistence. And a reason why I mentioned I don't like the MITRE framework to describe this fully is because oftentimes you won't be able to get persistence after your initial access. You have very low privileges. You don't have the ability to modify some of

these things that would allow you to get persistence. It doesn't always make sense to have it as a second step. You might have to do privilege escalation before you get to persistence, or perhaps you're going to do an action which allows you to get persistence and privilege escalation in the same go, and thus it's not necessarily the best way to split it up and look at it that way. In this case, however, we're going back to what we saw earlier. So the assume role thing, well, we can, instead of creating a new service principal or a new account