Session 1

There we go. There we go. Turn down my speakers. I think you might have two windows open. John, welcome everybody. Sorry for the technical glitches this morning. Uh, I'm having internet issues. I really apologize. Um, hope everybody's doing fantastic. I am going to let John take over. I'm going to email out everybody to make sure we are live right now. Um, John, so I'm gonna mute myself for a minute and let you go Do it. You, you good? Alright, everybody, Thank you so much for joining.

Um, a little bit weird and like strange this morning, uh, but we really appreciate you all coming and hanging out. Um, I've got your chat over on the right hand side, so as you have questions, please feel free as always to just dump the questions into the chat and I'll be happy to answer them. Um, I really, Andrew kind of brought to my attention like over the past week that there's been a large number of MSPs that have been compromised.

Um, and the question kind of popped up, do we see a widespread kind of, you know, targeted attack against MSPs? And I think the answer is yes, and I think the answer is no. And let, let me explain what I mean by that. Um, so whenever we see something in the industry, uh, like hackers going after a specific group, there is a tremendous amount of times that we see where you start to see copycat attacks.

Um, you also see the news stories start to get amplified again and again and again because it becomes like this meme and the true definition of a meme, you know, like kind of like a mental gene that kind of starts spreading through and it starts to hit the news. Um, all that being said, uh, some of the cases that we've actually seen over the past week or so, or two weeks that we've seen in the chat groups that are being monitored, the attackers are actually talking about targeting MSPs.

Um, and specifically we start to see things, and I'll talk about this in one of the cases where some of the attackers get access to so much data by going to an MSP and then compromising their customers that they say things like, we have so much data we don't know to do with it. We're willing to give you all more, more money if you can come, come in and you can help us. So today I really wanted to take, you know, about an hour and kind of talk through some of these cases.

And then I want to talk through some of the technical things that we're seeing insofar as attack methodologies and compromise that we're seeing in the industry as a whole. Now, as always, if anybody on you or your team that are watching this have any questions, please just type them in. Um, Andrew, whenever I go to full screen and I'm sharing my screen, I may not see those questions, so Andrew will just like interrupt me and he'll just read the questions.

So don't worry about interrupting or anything at all. So I'm gonna share my screen. Go ahead and share that. All right, there we go. So this is the, this is the first one. Now, this particular news article kind of feeds into the next news article, um, about a Kansas MSP and has been compromised. We'll talk about it, but this is the one where, uh, where Beeper, who's the hacker handle, uh, basically was posting on their channels. Let me zoom in a little bit on this.

Oops, that was not what I wanted. There we go. Lemme zoom in. Hit the wrong button. There we go. Um, this particular attacker basically went on a forum and said this, um, it, it, it, it's, and this is a terrifying quote from an attacker. Like, if you ever see this in the industry as a whole, it's time to pause, reflect, and freak out. Uh, looking for a partner for MSP processing.

I have access to the MSP panel of 50 plus companies over a hundred ESXI thousand servers, and I wanna work qualitatively, but I do not have enough people in terms of preparation. Only little things are left, so my profit share will be high. Please send me a message in more details and suggestions. It, it's a bad day whenever a hacker says, I've gotten access to so much stuff I need to bring other people in to pillage it.

And, um, and this concerns me and it concerns me for a couple of reasons, right? It concerns me that it's out on a form number one. Um, it concerns me that they literally have a phrasing of like MSP processing, right? Because when you're talking about MSP processing, that usually indicates that there is some type of process associated with it. And that means that there are more MSPs that are actually getting, getting popped.

And then asking, asking people to come in and help pillage these, uh, is, is also terrifying as well. So there's been some security researchers, Carvey out of Hunt Huntress was one that actually posted this. And what's weird is we're seeing at the exact same time, this jumps into another news story, um, where a Kansas MSP, um, was actually compromised as well. Um, so we've got Net Standard, uh, was compromised. Now a couple of things about Net Standard.

Um, the first thing about Net Standard is I am really very happy right now from what I'm seeing with what, how it appears that Net Standard is actually handling this. Um, one of the things that you've noticed in some of the news articles is Net Standard for a while was doing hourly updates to their customers and keeping people in the loop on exactly what was actually going on. Um, that's the first thing that I liked about kind of seeing how Net Standard was handling this.

The other thing that I'm seeing that Net Standard did is look at what net standards shut down, right? So net standards shut down my apps anywhere, and it, it killed, uh, hosted gp, hosted CRM hosted Exchange, hosted SharePoint, and they literally just shut down absolutely everything once they knew that they had an attacker on the inside of their environment.

Um, and they are of course working with an m, not an MSP, they're working with a forensics firm that is associated, was probably like, kind of directed by their insurance provider. So they're actually working through this particular attack. Um, so yeah, they are down and they are down hard. So right here is where the company is hosting hourly Zoom calls to basically update their customers with the outage. Please do me a favor, if any of you all get hit, um, I, I don't need money.

Uh, but if you could please get me on the phone and I can give you some advice, uh, based on the nature of the attack on how to handle customers when you're working through an incident. Uh, consider this to be free consulting. 'cause there's a very strong possibility that BHIS is not on your insurance panel, uh, for working with us. And even at that, like former students in the MSP space, if it's just friendly advice, I'm happy to give that. But these calls can be incredibly contentious.

I know for a number of you, you've already been on contentious calls that had nothing to do with a hack. You've, they've had nothing to do with a compromise where services went down and customers are angry and justifiably so, right? Their business is currently down. But there's some things that we can talk about if this ever unfortunately happens to anybody here on how you frame this as an issue. And let, let me explain. So in pen testing, we always run the risk of crashing services, right?

So whenever we're running scanners, we may hit old out of date systems and bring those systems down, and that's really rare. We may do a password spray attack and bring some systems down. And once again, that's really rare. But how you actually set the context around it is important. Let, let me give you two separate examples on how people tend to handle these calls. The first example is you show up to the call and you're like, we are so sorry. Oh my gosh, this is horrible.

I, I don't know what to say. I can't apologize enough. Um, you know, that we're really gonna try to do better in the future. You're immediately taking blame and you're immediately framing it as your fault. And I understand from a human perspective how that is like perceived as a good thing. Like you're doing the right thing, you're trying to be honest, and I totally understand that. But there's more than one way to frame these things, okay?

Like, if you immediately go in Mia Kopa and you're willing to fall on your sword, then that becomes how it's framed to all of your customers. That's how it gets framed to their CEOs. That's how it gets framed to their customers. And then they start talking about you as an MSP and oh my gosh, they're incompetent. They did this, they did this, they did this, they did this instead. If you can change the framing of the incident, I think it's important to frame it.

I I I'm going to say it to frame it properly. Okay? So whenever we have a pen test where something goes south and something crashes, we try our best to frame it in the context of this is a vulnerability. And what I mean by that is when we're testing and going after, let's say web servers or we're going after servers and we crash a server, it's almost always a like Windows server 2008 or Linux two six kernel or something really janky and super out of date.

And we're always trying to frame that as a vulnerability. Why? Because it is a vulnerability. Um, it absolutely is. You know, if your server can go down with a simple scan, then that's a problem with that server.

Like, and that's one of the things like, you know, whenever you all get access to my, um, my, uh, my pentest in class, we talk about how if you use industry standard scanning templates that are used everywhere, then when you're talking to a customer, you say, look, this is a scan that we use thousands of times per year and it causes problems in less than 1%. And almost always those 1% systems are really old out of date systems or poorly developed systems. You're framing it properly.

It's a vulnerability. So taking that logic and moving it over to something like this, like an IR engagement where you are down hard, how do you frame this so it doesn't automatically like completely set the entire narrative around being your fault? Okay? The first thing that I think is important whenever you're kind of building the narrative of being compromised is to basically frame the attack more or less as an act of God. And what I mean by that is if my house gets hit by a tornado, right?

Um, I don't get mad at the builder of the house, right? I I don't go to one of the three little pigs and say, oh my gosh, why did you build my house out of sticks? I look at it like this was an act of God, I got hit by a tornado. And it's important whenever you start having these conversations to not immediately say, it's not our fault. It's not our fault, it's not our fault, but frame it in a larger context of what the attackers are doing in the industry.

So if you get hit by a, an attack like this, you learn who the attacker is and what they're doing. Find some relevant news articles where you're talking with the customers and saying, look, we got hit by this a PT group. We got hit by this hacking group. They're hitting a number of different MSPs using a number of very advanced tactics.

'cause some of the things that I'm seeing, they actually do have some fairly advanced tactics as far as what they are actually encountering and what they're working on and share with us in the larger context of the fact that MSPs are getting hit all over the place, right? So we got a story that's main news story, the Kansas MSP, um, that, that got compromised. We also have another story of uk um, uh, national Health Services was hit by a ransomware attack.

Find some other news stories and then put it in the broader context of saying there's a lot of companies out there that are getting compromised by very advanced attackers that are backed by freaking China and Russia and they're coming after different organizations that frames it, okay? That frames it in a slightly better way. And more importantly, if it gets to a legal situation, you have not admitted liability in your meetings, all right?

You know, your, your knee jerk reaction will be like, oh my gosh, this, we're so sorry we got compromised. This is our fault or whatever. And we're not Canada. Well, some of you may be in Canada where Canada has literally passed a law that says sa saying sorry, does not mean it's an admission of guilt. That's what they did in Canada.

Um, but in the United States you don't want to do that because if it goes to court and there's a recording of you admitting guilt, then we can start having conversations about negligence, then we can start having conversations about damages. This becomes a very dicey situation. So if you are doing this, like I said, frame it in a larger context, never admit guilt upfront, right? And try to frame it in like what it is in the global perspective.

So I wanna stop sharing my screen and go back to the ask me anything and see if there's any questions, um, that we have coming back on this as well. There's a few in there. One, how do we get ahold of you, John? Sure. I'm gonna go ahead and do this real quick while you're doing that. And then Damon, it says, Damien, I'm gonna see if I can understand it. I read it a few times. Should we not be suggesting MSPs who will offer some sort of security offering, even basic AAV be eating their own dog?

So I don't understand what what you're asking. No, I get it. You, I I I get the question. Um, so, so should we not be suggesting MSPs who will offer some sort of basic security offering? Um, yes. And, and we're gonna talk about some of those basics and fundamentals. Um, one of the things Andrew and I are working on for write of Boom, um, which we're super excited about, um, I think we talk about it like weekly.

Um, 'cause the last write of boom was super awesome is, you know, in your portal you have access to my intro to security class. And it goes through the, it goes through 11 things that you all need to be doing, right? Freaking now, uh, setting up strong passwords, two-factor authentication absolutely everywhere. Uh, getting your systems patched, doing vulnerability assessments, doing all of that motherhood and apple pie stuff. That's your dog food. Please do that.

If you were doing those things and we talk about how we map the critical controls, then we're at the situation where we've provided due diligence. And if it goes to court, you can show your compliance mapping to something like CIS which then maps to absolutely everything that is basics and fundamentals, blocking and tackling. You need to be doing that. 'cause here's the deal. Even if you're doing that, I can still get in your organization and I cannot stress that enough.

If a targeted very skilled adversary or nation state is coming after you, they're going to get in. Let, let me repeat that. If you have somebody that is set up by a nation state and they are coming after you, they are going to get in. Now in the class, we also talk about logging, we talk about alerting, we talk about stopping post exploitation, we talk about all those different things and how your organization can actually stop that lateral movement with proper logging and analysis.

And I always say, you know, you're gonna get compromised. And I hate to say this, but it's okay. It's okay. Like death and taxes, it's something that happens. What's not okay? Is the attacker taking over your entire organization? What's not okay? Is the attacker dwelling in your organization for months? And that's really the core gist of what we do at the intro to security section of your training. And that's really what I'm trying to get across in that particular section.

But that also applies for your customers. Okay? So if you do your own dog food, right? Like if you do, uh, like, like your own dog food, right? Like you're gonna set up and set up sim logging and alerting. You're working with huntress, you're working with perch, you're setting up application, allow listing for the terminals that your analysts are using or the jump systems that they utilize to access.

You're setting up that two factor authentication, doing all of that stuff that you should do, get that in place. But also in your course we have an entire section on selling security. Alright? This is really critical. Start doing those brown bag launches.

Start doing those like, like daily seminars where you do it like once a quarter or something like that where you talk about the state of computer security, you talk about ransomware to your customers, and then you offer additional services around that as well. All right? Now the reason why I say that is this ransomware thing that we're talking about can target MSPs, but they can also target your customers. And this gets back to liability reduction for your firm as well.

If you are offering security services to your customer, you're talking about how it relates to compliance, you're talking about how it relates to them in an insurance and they end up getting compromised because they have chosen not to purchase those services from you. It reduces your liability as an MSP because your customers, and you all know this, are gonna love to blame you.

They're gonna say, we thought our MSP was handling all of this, but if you can say, look, we wanted to implement two factor. We wanted to implement better logging, we wanted to implement sysmon, we wanted to implement, and it goes on and on and on and on. And you said, Hey, we just wanted to go with the cheapest thing that we possibly could. That helps limit your liability. If it ever comes to a situation where they start to sue.

And trust me with insurance companies, the cases that I'm seeing, insurance companies love to look for who they can blame, who's not their customer. And if they can blame an MSP and they can basically try to go after an MSP or a vendor or somebody that had vulnerabilities, they're gonna move in that area because there's money there to recoup. So it's all about establishing that basic fundamentals that we have in the class that you all have available.

And then it's also selling it to your customers. And they may not buy it, but by you doing those brown bags and doing sessions and webcasts and things like this with your customers, dumbing it down to very, very, very plain English for your customers and they end up choosing not to purchase and they end up getting compromised, that helps reduce your liability as well. So I hope that makes sense, right? Hey John? Yeah, I I, I'd just like to, I could mention a few things.

One, um, to your LA go in reverse to your last point. You know, in talking to me, multiple breach coaches, breach attorneys, so just realize, um, percentage wise, just because of the multiplier effective in MS P, the chances of your customer being compromised over you is far greater. If we just look at the aggregate MSPs, you know, um, you have an MS P servicing 200 customers, right? And MSPs by and large, go ahead. I'm gonna disagree with that.

Um, the impact, potential impact when you're looking at the risk calculation is far greater in the MSPs. But if you look at the total number of breaches, the vast majority of breaches are at individual companies, not at the MS P level. So just wanted to clarify that. And that's like, yeah, no, yeah. So I just wanted to clarify. I'm not, I'm not disagreeing the impact I'm saying percentage wise.

Maybe I said it incorrectly percentage wise because like you said, they're at the end customer level relative to the MSP, not the impact. Obviously the impact of gaining command and control of the MSP is massive. So I think we're in agreement there. What I wanted to say is, what the insurance company will do is they immediately assign a breach coach.

And if you speak to any breach coach who's on the insurance side representing the end customer, you'll be blamed no matter what, even if you're doing everything perfectly. So I just want to iterate John's point of the criticality of and Damien eating or dog food, but the criticality of building your own internal security program first, because they're gonna look at you, number one, and ask you questions around your policies and controls.

And then number two, um, it gets into, uh, another piece I'd just like to say, John, which is, what are you, um, you know, suggesting for your customers? What standard are you aligning to? And then do you have a process? I was speaking with an MSP that had, I, I think one of the best processes I've seen yet in making sure their customers know that where they stop in the event, they feel that something could be beyond, you know, just a technical fix.

Like we think something could be, no, they don't say this, but we're going to move outside of our basic managed services program and bring in an expert for an evaluation of a potential malicious act. The reason they do that is several fold. Number one, by bringing the expert, number one, they're telling also internally their team, you are not to wipe and restore, which is obviously, you know, a death nail, which we've seen many times from MSPs, unfortunately.

'cause we wanna fix, we wanna get the customer up and running from a forensics perspective. Number two, your customers understand this is now moving into a TNM situation. It's no longer covered. 'cause you're gonna bring in a for, you know, a a, an IR team that's gonna charge anywhere from what, John three to $600, depending on the type of retainer you have. Yeah. Per hour. Per hour.

So, um, but it, it gives you guys some coverage and validation that we moved out of also your PSA for discoverability. I recommend having another system potentially to do that. Um, so those, those are some policies and things you might want to consider in your MSP. Um, I'd love to hear your thoughts on that. And John, if you wanna enter, answer any questions. So one of, so this is one of the things that we've brought up multiple times.

Whenever you have a customer that's brought in a breach coach, that breach coach, coach is not your friend, the, the company that they're hiring to do the IR is not your friend. Um, and it's a really good idea to basically bring in another kind of firm, but the breach coach often wins. But if you can bring in somebody, and I've done this a lot where basically I'm talking to breach coaches and you know, I'll basically be like, that's insane.

And I have no problem saying that, uh, to a number, to a number of different breach coaches, mainly because I trained most of them, um, 'cause they didn't get things. And they're always doing stupid stuff like Andrew was talking about, like, you know, oh, we gotta preserve all those systems. You're not allowed to touch the systems. And I could be like, that's not, that's not the right practice.

The right practice is to get the evidence, to get the artifacts, make sure that we've got proper evidence and artifacts, snapshot and time. Once we have that evidence, then we start trying to restore operations as quickly as possible. You cannot wait in doing forensics and IR to say we're gonna do full forensics on all of our systems before we actually bring the systems up.

That is something that we were talking about back in the early two thousands, and we were dumb in saying it, but it gets into that perfect situation. We're like, we'll do forensics on all of the hard drives for hundreds of systems and then we will bring the environment up with many of these different, uh, with many of the different, uh, organizations that are out there. Like, you'll go outta business, right? You'll go outta business.

So basically probably should just create a forensics IR course and just throw it in. Um, it gets really close to SANS 5 0 4 for me, but it probably needs to be done. But no, if you have virtual machines and you're running it on ESXI, you can snapshot those virtual machines, save those snapshots, save them as artifacts at that point of time, and then you can start restoring operations after you have the memory, after you have the actual images of the systems that you believe to be impacted.

And especially if you know the initial attack path, how they got in, right? And I'm gonna talk about here in a second on recovery and how that works. But Andrew, I think, I think we probably need to do an entire class on that, that we can throw out the MSPs as well. I wanna say image snapshots using your backup RMM tool for those not using dm. Yeah, absolutely. As long as you have some type of capability to create a snapshot.

Now, if you look at historical forensics, it was dead disc forensics and there's still a lot of books that talk about dead disc forensics where you shut the entire system down. You basically take the hard drive out, put it on a right blocker with something like, um, like a firefly, and then you do a full backup of the hard drive and you do analysis on that.

But if you're looking at many of the systems as they exist today, they're very athermal like they might be in the cloud, they might be in a virtual machine environment, and that aids with our forensics analysis and, and so far as what we're gonna do for ir, which is great and it makes it easier for us to recover, but if you have somebody that is, you know, like, like the breach coach and they come from that old school, they're gonna want, you know, they're, I've literally had breach coaches telling me it's like, we need to take a snapshot of the spinning disc.

And you're like, it's in Amazon. And they're like, yes, we need to bring that spinning disc down. And they have no concept of like cloud or SAS at all. So that is a difficult thing. Um, that is very, very difficult.

Uh, like anything, like Justin said, that is a no today you can do live forensics and we have a lot of that in the intro to SOC class, doing that basic live forensics, dumping the memory off the system, doing analysis, pulling the virtual machine, hard drive, um, and then doing analysis on it there. Um, which I think is absolutely something that we should have a course on. Um, the other thing that I think is important for all of this is have a plan.

So if you get breached, what is your plan for getting forensics artifacts and getting back into operation? Because if you have it documented and there's an actual attack, you follow your documented procedures and it shows to the courts. And if it goes to a judge and a jury that you've thought about it, you've came up with a plan and people may argue with a plan, but it's much more difficult to argue with a documented plan than it is to do, uh, argue with like just ad hoc activities.

So let me explain that. If you have a plan for doing a snapshot for, let's say you talk about using your RMM tool for doing a backup, but you're gonna need to copy that Damien, your RMM backup, you're gonna need to couple that and add a procedure for acquisition of memory on your systems as well. You want to have both, you want have the backup of the files and you want to have acquisition of memory. Have that documented on how you do that.

If you do that as part of an incident and that was your process goes to court, gets into all these really weird, esoteric like academic arguments, like is this correct? Is it not correct? But it's documented and between you and me, judges and juries love people who have procedures and they're probably gonna give you some deference and some weight on that.

Whereas if you actually do this as an ad hoc activity where you literally are just, you know, willy-nilly, like yolo, we're gonna do it and it's not documented, then it opens up all kinds of different questions on what is the best practice for it. Okay. So hopefully that kind of answers that question. And I think that this is an area that we need to add into, uh, add into the class as well so we can get it set up.

Um, so that's absolutely critical that you have those procedures actually documented. Alright, any other questions? How's the coffee this morning, John? Um, it's actually pretty good. I got up and did a run this morning and you know, got some coffee, I got fired up. Um, we're actually actively working an incident, um, right now with an MSP out of South Africa, but they're not compromised, but one of their customers is compromised.

And um, it's, it's frustrating because the customer is like super, super, super nice, but they keep saying, yes, they'll do things and then they never do the things and then we find out that they don't know how to do those things, like after two, three days. So it's been, it's been a hard incident. Um, so finally the customer just handed us over the keys to the kingdom and they're like, how about you just come in and just do it? And we're like, that's awesome, we'll do that.

But, um, it's on the other side of the planet, which means, you know, sleep is a little bit difficult. You guys are, um, I have to say from an IR side, um, and I'll let you continue a second. I referred over, um, here in Tampa and there was a company that got compromised and then company that I knew and you guys did a fantastic job for them. They were, they're really pleased. Thanks, I appreciate it.

You need to send me an email follow up on that 'cause there's some stuff that I need to do on the background that I need to make sure gets done, Andrew. Oh they did. Alright, cool. Uh, crazy Wolf, uh, said. Um, what is the difference between SOC MSP and MDR? So, security Operation center incorporates a lot of different, um, a lot of different aspects as it relates to computer security and many times it's actually variable based on the customer.

So we will do EDR maintenance, we will do SIM log analysis, we will do network analysis, we do all of the different security operation center activities for our customers where we are effectively either integrated with their security team or we are their security team. And that can also include things like vulnerability management with MSP, you're actually doing a lot of the day-to-day maintenance of the IT infrastructure, right?

Like you're man maintaining web servers, you're maintaining email servers, you're maintaining desktops, you're doing all of those things. And a lot of times you can drop another S in there and security gets added into it as well. Managed detection and response usually in the industry is specifically associated with an EDR vendor where you can hire somebody to manage just an EDR.

Now many of the, uh, MDRs out there are starting to incorporate network analysis with the endpoint analysis as well because Gartner has actually pushed that as a standard. So hopefully that, uh, that answers your question. Um, hopefully I got that. That's a very, very, very quick overview and that it's not clean.

They bleed back and forth with each other as well, so, So alright, Jeff, you wanna talk, um, any, like, anything new what you're thinking on the potential migration to scorm or what you're thinking new with the, uh, learning LMS or Yes. You know, any, any kind of updates and that, that people might, might wanna know about? You bet. So we're currently, like I said, we're cooking the, um, we're cooking the class, uh, for the pen testing course and getting that migrated in.

So you all are gonna get access to the pen testing, intro to pen testing class. Um, so that'll, and that's really built folks for you to start doing security assessment work for your customers. Um, you can sell it, you can incorporate it as part of your overall package and basically how do you do it in such a way that you don't burn your customer's network to the ground. Uh, so check gee on the lookout, I'll shoot out an email once that goes live.

The other thing is once we move to quorum, it allows us to do some things in the platform that we can't do. Now, the biggest single complaint that I'm getting now is you go to a video it plays and then you have to click the button to go to the next video. It plays and you have to click the button to the next video.

And a lot of my stuff, like I'll have an introduction slide talking about something for three minutes and then it goes to a longer slide and then there'll be another introduction that's two to three minutes. Wouldn't be a problem if the player automatically went from one module to the next.

But if people, like one of the, one of the people in the MSP space, they contact me and they're like, dude, I like running and listening to you, however, I've got to constantly go to the mobile app and push next to get to the next video. Um, so that is, uh, that is a problem, um, that we are working on. And I'm trying to get D two L to fix that 'cause it seems to me that's something that D two L should have, um, in play as well. Um, yes.

Um, whenever you're looking at how MSPs are getting hit, um, a lot of the MSPs that are getting popped are standard motherhood and apple pie. They're doing spearfishing, um, using things like evil Gen X or evil jinx to capture two factor of two factors in play. But the MSPs that we have direct knowledge and we've worked with, they don't have two factor.

Um, and I'm, I'm going to tell you right now that if you have two factor, there's like, I can't remember what it was, it's something like 80% of the attackers will literally move away from your MSP and go to another MSP. So pretty pleased with sprinkles and sugar on top for your MSP employees. Like if you do not have two factor enabled on your MSP, on all of your different apps, do so, uh, get it set up now.

It's not gonna shut down all of the attackers, but it's gonna shut down a very large percentage of them. John, is that again, like w is it because of lemme just get this out. Is it because of quote unquote laziness and ease? They won't go to the extent of trying to set up a man in the middle to intercept MFA? Is it just easier to try and find one that doesn't have it? It's just easier to just move on. Um, because you're really looking at no problem.

You're really, whenever you're looking at these attackers, like I always, I always try to put it like, you know, into the standard biological imperatives of a predator, right?

So if you look at a tiger, right, and a tiger's out in the middle of the jungle, they can go after a larger prey and the reward may be really, really good for the larger prey, but if smaller, easier to get prey is, is abundant, they're going to go after that because the energy and risk associated with expending and going after a larger prey is so great. They're gonna go after bunny rabbits and they're gonna go after that. They're gonna go after the low hanging fruit.

And the other thing about attackers, I I, I don't want this to be a false sense of security for you all, but with many attackers, when they have a a target and it has MFA, the risk profile of that organization just went up. It's not just harder to get into the organization, it's also once you get into the organization, the odds of them having good telemetry logs and analysis is also higher. So I want you to think of that as like a hippopotamus.

Many predators will not go after a hippo, even though a hippo has tremendous amounts of calories in a hippo. A hippo will freaking kill you and enjoy it the entire time. So just by looking at it being like that's a hippo, tigers are just gonna move on someplace else, right? They're gonna go to a gazelle instead because the risk associated with that is far lower. How effective are IP restrictions?

Um, they're really effective against your general automated malware, but targeted attackers aren't coming through those IP addresses like at all. Um, and that's also in the class.

That's why we talk about internet allow listing, um, for your own employees when they surf the internet, you can actually go through your web proxy and you can set the uncategorized and say anything that's uncategorized that, you know, Cisco umbrella has never seen before or Forcepoint has never seen before, I'm not gonna allow people to go to that website.

And that's smart because if Cisco has not seen that website before and has not categorized that website before, you do not want any of your employees going to that website. And that also is true for command and control. They may get compromised by going to like Drudge Report, Huffington Post, Fox News, CNN, whatever by an ad. But that command and control will go to another domain that more than likely is a domain that they haven't seen or categorized before, and it'll shut that down.

So it depends on how you do the IP restrictions. Go back to the class and, you know, talk about DNS and the sections in the intro to security module there. Good stuff, Good question. Yeah, absolutely. Um, and then what was I gonna ask John? Um, so intro, we talked about intro for pen testing. Oh, I was just gonna ask you all, um, are you talking to other MSPs about security training? Um, do you, do you share at all? Are you in a peer group?

Um, and it'd be great to start to, we're we're looking for ideas on starting to spread the word. We're in some talks with some big organizations that are going to, uh, get John's stuff out far and wide that have, you know, very big megaphones in the industry. But love, love your feedback on maybe some ways in which we can help John get things out, um, and help more MSPs. So if you have any thoughts or suggestions, I would, I would, I know we'd love to hear 'em. That would be my ask.

Um, and That could be just an email to Andrew and I as well. Sure, sure, sure. Absolutely John. Um, Yeah, 'cause this is, like I said, I, this is going to be the best deal at Antis Siphon because we're gonna continue to add in more classes and you know, the, ask me anythings and things of that nature. But, um, like, like I said, I'm getting pretty sick and tired of seeing these massive breaches or lots of organizations getting compromised.

And there was an article that I dropped, um, that was just talking about ho how horribly hosed we are. Um, I've actually got it right here. Um, it was a, it was an article that was talking about like patching. And here, let me share my screen. Where do my controls go? Uh, just right above your head, John, you should be able to see, oh, I've got a, it disappears for a second. Yeah, sorry. My bad. Lemme share that.

And this particular article, I wanted to talk about CVSS scores and patching and trying to deal with this, and it's really not getting easier, right? Like, you know, there's so many different vulnerabilities that are coming out and they're coming out so fast because there's so much technology, um, that, especially for an MSP and you're running a large, you know, a lot of like very diverse technology stacks for many of these different companies.

And let me, let me explain it to you how I see it and see if I'm right. Um, if I am working on a security team for a financial firm, okay, if I'm working on a security team for a financial firm, and let's say that they're a fairly large financial firm of like 20, 30,000 people with billions of dollars of assets, a financial firm's going to have a technology stack.

And if you're an MSP and you're working with a financial firm that's a smaller financial firm, odds are they're going to have a similar technology stack, right? If I'm in a larger company, I have to deal with one set of technology, I have to deal with legacy applications and all of that. But if I'm an MSP, I've also gotta deal with legacy applications in a financial stack. The difference is an MSP has to deal with the financial stack.

They have to deal with the medical stack, they have to deal with the point of sale stack, they have to deal with the law firm stack. And I'm, I, I don't know, this is probably gonna be something, I might talk about it, right, a boom or, uh, maybe another MSP conference, but I don't think the industry quite understands how complicated this whole problem of patching is on the face of it for individual firms.

But it's exponentially more complicated when you're an MSP and you're dealing with 15 customers financials tax, and every single one of them is an appreciable percentage of a single customer's technology stack and the amount of patches that they have to deal with. Um, so I don't know if that's, if I'm heading down the right path on that, but talking to these, talking to these, uh, talking to a lot of the MSPs, it's the problems that we have in just the security community are amplified John.

And if I could say this and like Justin's been involved with like a, a project from day one on really good vulnerability management platform called Cyber CMS. But my reason I want to kind of echo what you're saying is, um, I've had no less, 'cause I helped them with their go to market, I've had no less than 1200 conversations with MSPs on vulnerability management. Mm-Hmm. And the vast majority, when I'll, I'll ask them about vulnerability management and the, I'll say, do you have a policy?

Do, does the customer, do you guys, have you agreed on a policy? Like do we understand what the most critical um, systems are? Do we understand what the SLAs are? Have we agreed that it's A-C-V-S-S score of X and it's being actively exploited and that you are able to bring that system down and take action? Just using that as an example, as a policy. Please don't take it as a literal No, no, Absolutely.

But, but the vast majority, high 90 percentage, 90 percentile, when I ask the question, I'm not trying to bash anybody. I'm just saying they don't even have the wherewithal to do it like a lot of times because it's the line of business application and there hasn't been even been an agreed upon we can do this at this time, it's being actively exploited, et cetera, et cetera. I dunno if that makes sense, it just hear out there. But it, I think that's, that, that in and of itself is a huge issue.

Well, and, and it's like the way I teach vulnerability management for large firms. You know, I talk about the, uh, telco company that we did an assessment on a million IP addresses and we could address all the vulnerabilities, high, medium lows and informationals. And we did it in like two weeks with like two testers. That approach of looking at your vulnerabilities on plugin ID and how many systems have those vulnerabilities works in large scale like Fortune, you know, 500 companies, right?

That works. I can push those companies to do some sort of automation to deal with vulnerabilities across thousands of computer systems because you have an architecture like a management structure where your cis o your CTO and your CIO can get behind that and enforce that through the entire organization. That approach fails completely with MSPs. Uh, because you can't just automate, you're not going to see consistencies of vulnerabilities across multiple different customers.

'cause their technology stacks are different. And I, I can tell you the answer to this is two things. One, migration to cloud services and SaaS has to happen because that helps take a lot of the patch management off the plate. Not all of it, but it takes a lot of it off the plate. But that's up to your customers if they want to do that. And then the other thing that we have to get into is more automated patch deployment.

And I know a lot of people are very nervous about that, justifiably so about potential downstream impacts for those patches. But we need to get into a situation where we are not like super concerned. Like if a patch crashes something, the MSP should not be blamed, the vendor should be blamed. Um, and that's a whole mindset change. That's not easy. That's like, that's like saying, you know, in this Christmas season, I would like all the children to hold hands and sing songs about world peace.

It sounds great, but it's not gonna happen. So we got a couple of things that tops up. Um, not all your clients get it in terms of clients bring the horse to water. You can't make them drink the Kool-Aid technically Justin, it was flavor aid. Uh, but when you're talking about that, uh, in the cult, yeah, you can still show them and offer them and kind of show them the ways of security.

And if they choose not to do it and they get compromised legally, you can basically go back and you can point out this is something that you had actually done. Um, selling security section is great, thank you. However, was curious whether you have bare bones fundamentals that MSP should include at the most basic tier when security is included in the MSP offering. Um, I would say the basics would be, you know, the MFA, the vulnerability management, um, the password controls and the patching.

Those would be the absolute tier, like both base ones. Then you can start moving into an internet, allow listing application, allow listing, which are significantly more difficult, uh, to implement as well. I tend to see AV backup or just AV more than anything else, and I don't feel like that's enough, even at a basic level. I agree.

Um, I would definitely put in some vulnerability management on your customer's attack surfaces there with the emergence of A ITM attack compromised accounts at MFA. Do you know, or have a preferred tool to mitigate these kinds of threats? Um, so a lot of what you can do, especially if you're dealing with, um, with Azure and you're dealing with Office 365 is there is settings that you can set up where it logs or blocks and possible login, uh, time.

So if somebody's logged in in Kansas and then at the exact same time they're logged into KAZAKI Stan, um, you can get notified or you can shut that down, um, that works out really, really, really well, uh, to try to shut down a lot of those different attacks because I will get that multifactor authentication code and be, you know, then I'll be logged in the same time as the customer. Um, but that is something you can turn on with a lot of vendors.

Um, the difficulty is you may have customers that are actually legitimately logging in, um, multiple different times. So it, it is difficult, right? It's difficult. See your stack on CIS implementation group. Oh one a great base to start. That's awesome. Um, like conditional, yeah, kind of like, like conditional access policies. And Andrew, there was a question up above that I wanted to hit a technical question.

Somebody was asking, can you set up where you can log onto your workstation with a different user ID and password than you do with your Azure? Um, it was from Josh. I said, I'm starting to look at Azure ad. Is there a way to set the username to log into the pc, not their email address, first name, last name, and random stuff. Um, yes, no, and maybe set. Um, so yes, you can do it on Windows 10.

Um, whenever you're creating an account on a Windows 10 computer system, um, when it gets to creating the account, it tries to force you to actually create a Microsoft Live account that is associated with authenticating to that individual workstation. And I think you have to click on more ways to log in or there's another button in that startup screen where you can create a local account on that computer system. Um, but it has to be done at the Windows 10 level.

Then once you log in, when you access your Azure applications and things like that, you can then log in with a different user ID and password at the Azure level. That's the way I do my Windows 10 system now, okay, Microsoft makes that very, very, very difficult for you to actually implement that effectively, um, to try to set those things up with Windows 11 as it stands right now, last I checked, 'cause Windows 11 is a moving target.

Microsoft is removing the ability for you to initialize that system with a local login only. All right? Microsoft wants to kill local logins on Windows 10 computer systems completely because the more that they kill those local logins, the more accounts that they're creating in, uh, the Microsoft cloud and they want everybody in the Microsoft cloud, okay? They want to be that central two factor or that single sign-on authority for the entire planet.

And they're working very hard to get to that point. So the answer is yes, you can do it now with Windows 10, maybe it'll be something that Microsoft will allow in Windows 11, but right now, especially on Windows 11 systems, it is currently, no, you can't do it. So that's a really complicated answer. Um, but that is what Microsoft is doing right now. Um, out there as well. I see DNS filter among others offer some level of tech, uh, protection against man in the middle attacks. Um, I'm not sure.

It includes two factor authentication protection where cookies are stolen to get around the protection. Now remember whenever you're talking about two factor authentication, um, you're not dealing with cookies, okay?

So what you're talking about for a web application attack is you're talking something more similar to an SSL strip SSL split attack where you do a man in the middle attack for a web service and then you're basically intercepting the session identifiers that exist, um, on that particular computer system whenever it's going to the web server.

Now keep in mind most of the SSL split SSL strip attacks, they actually take advantage of 3 0 2 redirects where you go from an unencrypted port 80 to an encrypted port 4, 4 3 on a web server. That's what they're taking advantage of is switching from unencrypted to encrypted. And a better way to try to shut that down is something called HSTS.

I can't remember what that actually stands for, but it's browser protections in place that constantly query the browser to say, Hey, are you at an encrypted site? Um, are you at the actual website that you expect to be at as well? 'cause what SSL strip and SSL split does is it keeps the client connection as unencrypted. It establishes the encrypted connection for you to the website and then it basically intercepts everything in between. Okay.

With SSL split plus there is some limited bypass of HSTS. Thank you Michael. Um, H-T-T-P-S strict transport security. There are some limited bypasses of HSTS in that particular, um, implementation. So when you're looking at that man in the middle attack, there's a couple of things that have to play. One, the attacker's gotta be on the local network or they've gotta create a link that'll trick a user to go to a website that is a port 80 website and then redirect them.

Or two is the redirect where you do the 3 0 2 redirect. But the biggest thing that you can do is make sure that your web servers have no port 80 anywhere. Like you don't want to have a normal page that's port 80 and then the authentication is actually encrypted, uh, port 4, 4 3 shut down port 80 absolutely everywhere. Um, and then for your customers, um, you can actually run a plugin called H-T-T-P-S everywhere that'll basically force their browsers to always go directly to H-T-T-P-S.

Um, so that's just kind of how some of that stuff works, um, and how you can set it up. So hopefully that answers your question, Damien. There's a lot there, but if you wanna research it, Moxy, marlin, spike, um, SSL strip and SSSL split plus are a couple of tools that can be utilized, but they're getting rare and rare to actually utilize as well.

Um, thinking more of those Outlook, um, two factor attacks that we don't have control over on the back end with those particular attacks, what we're doing is sending up something like Evil Jinx or Evil Gen X, some people call it, where we are basically creating a landing page and we're intercepting those two factor authentication tokens. Um, and right now a number of the different defenses that we've seen to try to stop that in spearfishing attacks haven't been working.

Um, there's a number of ways to bypass those. Hopefully they'll get better, um, over the next few years. Um, but we just got a really great article from Justin from Break Dev, uh, who actually creates Evil Jinx as well, talking about how to fish and pull those two factor authentication tokens. And that's what we've been doing lately, John. Oh gosh, We're at the end. Yeah, I'm really, Huh? Can you hear me okay? You're a little soft, but Yes, I can hear it All. Sorry. Sorry about that.

I, again, I'm having, I'm not sure what my internet problems are today. Everybody's, It keeps blinking, like it keeps shutting you down and then bringing you back. It's pretty spooky. Alright, well, um, John, thank you. Um, I'll, can I give you a quick call after and um, I have one IR call, how about I call you? I've got one IR call I gotta make right now. Um, and then I'll call you right over. Okay. Hey everybody, thank you so much. Um, please tell friends, uh, peers, we'd really help.

We'd like to, you know, get John's stuff out there far and wide. So wishing you guys a fantastic weekend. As always, take care everybody. Thanks guys. Thanks John.