This week on the podcast, we discuss the US government's ban on foreign-manufactured consumer routers and its likely impact. After that, we cover a research post from Huntress on a recent phishing campaign leveraging OAuth Device Authentication flows to retain long-term access to compromised accounts. We end with a review of key takeaways from Google's Cloud Threat Horizons report for H1 2026.
View Transcript
Marc Laliberte 0:00
Hey everyone. Welcome back to the 443 security simplified. I'm your host, Mark Laliberte, and joining me today is
Corey Nachreiner 0:07
Corey banded China Nachreiner,
Marc Laliberte 0:11
are you?
Corey Nachreiner 0:11
I hope not.
Corey Nachreiner 0:13
We're doing maybe I will be soon.
Marc Laliberte 0:18
We'll see. On today's episode, we will discuss the United States most recent ban on all consumer routers not made in the country, before talking about a interesting phishing campaign using OAuth device code flow, authentication, phishing. Yeah, it's more interesting than that came off. And then we will end with applications, right?
Marc Laliberte 0:44
Yep. And then we will end with a review of Google clouds threat horizons report for the second half of 2025
Corey Nachreiner 0:53
I'm sure they're saying the clouds are all white and fluffy and safe, and it's all sunshine and rainbows. Certainly no thunder clouds, right?
Marc Laliberte 1:01
it looks pretty stormy
Marc Laliberte 1:05
to me with that. Let's go ahead and I don't know, lightning strike our way in.
Marc Laliberte 1:16
This started out big news out of our homeland, where last week, the US Federal Communications Commission, or FCC, took a pretty dramatic step to ban all new foreign made consumer internet routers over security concerns by adding them to the covered list, as it's called, which is the covered items from Section two of the secure networks act finds itself alongside all technology from Huawei ZTE Kaspersky Labs and Chinese manufacturer drones as well,
Marc Laliberte 1:52
basically any notified, oh,
Corey Nachreiner 1:54
I don't care about drones or anything.
Marc Laliberte 1:58
No,
Corey Nachreiner 1:58
is it more upset about that, then pretty much every single router you can buy as a consumer in America. Anyways, we'll get into
Marc Laliberte 2:07
says a lot to to your hobbies, that's for sure.
Marc Laliberte 2:11
So they added it to the list, which means all new not currently approved, so only net new products are now, by default, banned from the United States if they're not manufactured here, at least for consumer routers, at least
Corey Nachreiner 2:25
at first.
Marc Laliberte 2:26
Anything at first, anything existing, anything you already have purchased and deployed, is still currently allowed, but anything brand new being introduced into our market has to go through, well, a it's banned by default, but there is a exceptions process that they can follow in order to request an exception to this to this list,
Marc Laliberte 2:47
they claim that this is to resolve issues introduced in supply chain, vulnerabilities that could disrupt the US economy and critical infrastructure. But like I mentioned, so the Department of War, as it's called now, and the Department of Homeland Security can grant an exception if devices, device manufacturers, fill out a bunch of questions in an annex to this order
Corey Nachreiner 3:15
the questions are and then we kind of process like they have to answer the questions And then see what the result is correct. The questions are, as you might expect. They request information about the corporate structure. They want to specifically know, like anyone that has more than a 5% equity in it, what the board looks like any foreign government ownership or influence. I suspect if China pops up in there at all, it'll probably get banned.
Corey Nachreiner 3:43
Then they ask about manufacturing and supply chain risks. They want a detailed bill of materials. They want to know the country of origin for all components, a justification for why it's not manufactured in the United States, as well as detailed information on where it is manufactured, including final application B, I'm not aware of a consumer router that is made in the United States, unless you go the assembled route where maybe you take a fully created board with a foreign, Taiwan based firmware, and you put it in a box, and now it's assembled in United like
Corey Nachreiner 4:19
so is there. Is there a router that is made in the United States? I'm even including Cisco, maybe Cisco.
Corey Nachreiner 4:27
I feel like they are probably all manufactured overseas. Oh, it looks like starlinks, Wi Fi routers are made in the great state of Texas.
Corey Nachreiner 4:39
There's one allowed option, but so I think there's like two components to this, like there is, like, undeniably a cyber security, like a cyber risk in some of these devices, like we've seen Huawei and zt specifically back doors that could border on the lines, not back doors, but like, vulnerabilities.
Corey Nachreiner 5:00
Of those back doors, back doors, or hard coded invulnerabilities that were really bad. And when you know they're a Chinese based company, you always have to wonder, was it an accident, or was it on purpose? Yeah, there's also clearly, as we've discussed multiple times over the last year, attacks going on against edge networking equipment. So it makes sense why this would be a focus area for them too. But like, another piece for this is clearly just the manufacturing side, and kind of aligning with the current administration's desire for just everything consumed in the US to be manufactured in the US. Because, like, one of the requirements for this exception request is a detailed time bound plan for establishing or expanding manufacturing in the United States for the router as well,
Corey Nachreiner 5:50
which, by the way,
Corey Nachreiner 5:52
I don't mind in theory, right? It'd be cool to be having jobs in manufacturing here, but the cost profile here is quite different in consumer like, the issue with any sort of plan like this is, yeah, it would be we, one of the things that different administration did is trying to get more chip manufacturing in the United States, because there's risk there. The problem is banning before you actually have, like, literally, I'm not joking when I say every consumer router is foreign and they're well used. I mean, they're the first thing you kind of buy or get from your telco company and and we need them, and you kind of have to sort out having a supply of us ones before you get this aggressive. So to me, it's more chicken before the egg. And I also think, yes, it would be great. But there's reasons business manufactured the same billionaires that may love things like this won't like the cost of manufacturing in the United States anyway. It's just weird,
Corey Nachreiner 6:54
yeah, but I would love to see more Rounders made here.
Corey Nachreiner 6:58
I agree, and I think that's where it's going to be like no matter what. This is going to drive up costs of consumer network equipment, because either it will be made here, which means it will cost 10 times as much to be manufactured, or the administrative overhead of like managing this new exception process will likely added the cost as well too.
Marc Laliberte 7:19
And I
Corey Nachreiner 7:21
don't know I, in principle, I'm not exactly I don't think I'm against this type of it should be more targeted, like when you dive into the the list that I was showing for a second for the YouTube viewers, of the ones they're pointing out, they're the ones we agree with, ZTE Huawei, the bad actors. I feel like,
Corey Nachreiner 7:44
from a security standpoint, we need to do something here, but it shouldn't be all foreign entities are considered bad. It should be targeted to known situations with evidence. So I feel like this is a mix of a security reason for banning which should be more targeted, that I agree with, but then something that's more just to drive
Corey Nachreiner 8:08
economy, like to drive politics and votes, like at the end of the day, by the way, the people in the administration now are part of
Corey Nachreiner 8:17
the the class of rich people that probably outsourced all This back then to save costs for the companies that have made trillions of dollars in profit for the top 1%
Corey Nachreiner 8:27
and now there's they're saying, let's bring it back. Because I know everyone wants American jobs, but the real reality is they don't want to pay the costs that they're doing. So I feel like I agree with the security standpoint of the whole premise, but I feel like a blanket ban was not the right choice for that, and you could do a much more targeted one that would help protect and maybe have some more responsibilities on if you're a foreign made device, you have to have more forced automatic firmware updates, you know, because there's plenty of legitimate foreign devices that I don't think our nation stayed exposed on purpose, and then it's more about get them up to a security practice that makes them not have zero days
Corey Nachreiner 9:11
as often or I think the biggest issue isn't that it's zero days, it's that consumer people don't patch their routers fast enough, even when There was a fixed two years ago. So I don't I think the blanket ban personally is too much, and the fact that, yes, there's a security point for this that I agree with, I think there's more going on here that
Corey Nachreiner 9:35
that is forcing it to be blanket, rather than targeted for security purposes. Now I'm going to go ahead, I'm going to give the steel man argument on this one, Corey, and I'm curious what your thoughts are for this. So blanket ban, massively disruptive steel man, like you know, the strongest thing is Wicker Man, or no, it's a stronger version of Wicker Man. I get it. I get it. So the alternative to this could.
Marc Laliberte 10:00
Have been just banned stuff manufactured in China, which we have, like, we've already banned drones from China. We've banned Huawei and ZTE, like, specific component or companies from China. So if we're saying we want to control risk around consumer routers, we're specifically concerned about China.
Corey Nachreiner 10:17
The, I think the strongman argument, or the steel man argument, is, well, we can say, we ban everything manufactured in China, but what's to stop them from doing the final assembly in Vietnam and then shipping it to the United States and saying, Oh, this is a Vietnamese router. So then we're playing like this cat and mouse game of, you know, it's clearly Chinese, but manufactured elsewhere. That gets because we saw a lot of that with some of the sanctions avoidance, not sanctions, the tariff avoidance, from some of that chaotic activity going on. So I could see why they just said, Screw it. The default state is everything's banned, but it is still pretty disruptive. I thought you're going another route. But to kind of add on to your point, the fact that this is a ban everything, but there's an exception process. The other security argument I thought you might be making is like a whitelisting approach, like we want you to only allow our you know, analogy of this, me and Mark would love to have a situation where we can force our users to only run executables and programs we've allowed, and anything that's not allowed, they have to jump through a bit of security review with us before we allow it. And so I thought you were going to argue maybe they don't want to blanket ban every country, but by whitelisted, by forcing it, they're forcing people to go through a process that gives you a chance to validate the security so that I can buy off on even more than than I agree you're right that there's ways to backdoor the system too. From geography. It's like, you know, the analogy there is VPNs get past country blocks. So I get both of those make sense? So, yeah, I could, that's true. I'll give that to you, I'm not sure that I personally like now we're talking whether that's their real motive or like is their real motive security, but either way, you are right that that is a good security outcome.
Corey Nachreiner 12:13
But so some of our listeners might be wondering, is the firebox affected because it is, believe it or not, not manufactured in the United States, good news is like long story short, it is not affected by this. There is a pretty clear definition on what they mean by both routers and consumer grade networking equipment, and our technology does not fall under consumer grade networking devices. And so we are. This answer has gone through our legal department too, so it's not just a guesstimate. Answer, Mark's opinion.
Corey Nachreiner 12:45
I would not take legal advice. I agree. I mean, your opinion is how I would have read it before legal as well, too. But just so you know me and Mark, have look. We are watching it, though, by the way, our company and people in it has saw the thing immediately and started to look into it,
Speaker 1 13:03
yep. But so if you are in the US and you're looking for your new net gear, or Linksys, or is D link still a company? D link router,
Corey Nachreiner 13:13
the shelves may soon be bare at your local Best Buy as you well, not really, because all the existing ones can sell out, but in about a year, they might be bare, by the way, this is I there's, it's a false equivalency, but we sell a small devices, tabletop devices, that, you know, maybe not with all the great services, but can get down to a price where there may be four times the or five times the amount of a consumer router. And I always have people like, or I Not always. Sometimes there's people that learn in my company, which we're really targeting businesses, not consumers, but are like, I just can't buy that because, you know, I can go get this Linksys that says it's a firewall immediately. It's a false equivalency, because we're better than that. But actually, this could be a good thing for business, because if you start manufacturing consumer routers here, I bet you our tabletop devices are going to be consumer priced with, you know, 10 times the security. So maybe we will. We're not going to change our market focus, but maybe we'll end up getting consumer customers one day. Yeah, screw all you guys, Mark and Corey are going to get their bonuses next year. This is awesome.
Corey Nachreiner 14:33
Sorry about the prices. I mean, we're all freaking dealing with the prices right now,
Corey Nachreiner 14:39
so I don't know. I predict this is going to be rather chaotic at the start, but I actually think there will be some some good net benefits to come out of this. At a minimum, even just getting a bunch of this information about supply chain for network equipment documented, it'll be beneficial and have a security impact. I've always wanted a government.
Corey Nachreiner 15:00
Mostly based security scorecard for IoT equipment. And while this isn't that by them forcing the process, they're kind of doing that sign off in the background. So hey, could be good. Yeah, I guess we will see how it pans out. And in the meantime, I guess time to go stock up on consumer routers that you can sell on the the underground marketplaces before, once all this gets banned, you're totally smart. It's like buying all the new Nintendo Switch threes out before anyone can get them, and selling them for twice or three times or even more the car. We should go buy a bunch of consumer routers Now, Mark and just be the lovely people that that everyone likes because we scout them. Screw Pokemon cards. The next gen currency is going to be d link routers.
Corey Nachreiner 15:48
Oh God,
Unknown Speaker 15:51
I hope not.
Corey Nachreiner 15:54
Anyways, moving on. I saw just this last week a really interesting write up from our friends and enemies over at Huntress, where they talk about enemies other than we also have MDR as a service for MSPs, and they're, they're good at their job. So we want to, we want to show people we are too. I consider all my competitors enemies, even if they do fantastic research from time to time, mark exactly, so we'll
Marc Laliberte 16:26
see. So huntresses Salk published a really interesting write up about a phishing campaign they uncovered using the platform as a service offering railway.com to host an interesting phishing campaign that targeted 344
Marc Laliberte 16:42
organizations. So they gave an update just a couple days ago with some more details about like the exact campaign and some of the toolkit that was being used in this. But the original report basically just talked through how on March 2, they noticed a wave of phishing attacks targeting some of their MDR customers, which they traced back to this campaign that actually started in mid February or so.
Speaker 1 17:09
There were some interesting tidbits from it, where all the phishing messages were tailored towards specific recipients and no two lures were identical. I'm going to extrapolate that into probably some LLM usage in there to custom tailor phishing messages at this scale towards potential victims.
Corey Nachreiner 17:28
They had a weaponized rail at railway, which is a platform as a service offering, and specifically they suspect they were like vibe coded up all this infrastructure to let them. I agree with them, by the way, the fact that they believe there's some AI used in the vibe coding, they are very clear that the external indicators you see from the fish are just the fish and the IP and the infrastructure. So they can't tell you. We know they did this, but if you read the details, it's hard, the speed, especially with how these campaigns change to target things. It seems their takeaways seem very obvious to me, to be very likely.
Marc Laliberte 18:12
They mentioned that even the free tier for railway works great as a hosting engine for this because all their IP space is clean for Microsoft's risk scoring, which really helps it out.
Speaker 1 18:25
Microsoft, with their conditional access policies, you can block like authentication attempts from risky locations, for example, this would allow it to go through
Marc Laliberte 18:35
so it uses OAuth device code phishing, which if you're not familiar with the device code authentication flow for OAuth, if you've ever, like logged into Netflix on your TV, tells you to go to netflix.com/device
Corey Nachreiner 18:49
and enter in the little six digits that show up on your TV. That's basically authenticating your television as a device under your identity for a period of time. Very convenient, by the way, I think every consumer, whether you knew it was OAuth device tokens, love it, because remember when you had to go to your Apple TV or your Roku, and you had to not only type your password, but you're a good security person that has a long random password, and of course, your password manager is not on Roku, so you have to, like, type this 24 character random password then, oh yeah, you remembered MFA. So now it's a paint and this is all on a Roku with a remote control, not a keyboard. So I remember those days, and this is the process Mark was talking about, where you literally look at a QR code and then you accept it after logging on to the same service on your phone. It really sounds like you.
Corey Nachreiner 19:42
You vividly remember those days. Corey, I'm an old man. Get off my lawn. Anyways, that I it's, it's no wonder that these device codes, which then they bypass everything, right? Once you have a device code, there's no MFA, there's no log on, it's an approved device.
Corey Nachreiner 20:00
So there's obviously a security concern and weakness there, but it kind of sucks, because this is a very useful and in my opinion, kind of needed thing for the use cases that you you allow devices, but you should think about that with every and we can talk about security tips later. But yeah, basically they trick the victims into going to microsoft.com/device
Marc Laliberte 20:21
login and pasting in the code they give them, and like you said, grants them an OAuth token with no password, no MFA, that's valid for 90 days by default within these accounts. And often, like hidden from most of like the authentication logs that you would look at in a Microsoft tenant,
Corey Nachreiner 20:40
they mentioned that railway was host, hosting almost the entirety of the token attack chain, and also the services that were using those tokens to log into Microsoft. All that authentication activity came from their IP addresses. The actual like phishing infrastructure was hosted elsewhere. Though, there is a little good news there right for the IP addresses, though, because you mentioned one of the benefits of this attack is railway is a very legitimate and trusted app, even in m3 65 and they have huge ranges of IPs. But you really don't want to block those huge ranges, because there's a ton of legitimate stuff there. It sounded like the there were only a smaller number of IPs, three, really, for most of this activity. So as far as practical tips later, you don't have to block everything, which is kind of nice. Yep,
Marc Laliberte 21:29
they had some interesting evasion techniques along the way too. So instead of just sending their phishing URL directly, they actually abused a lot of legitimate security vendors URL rewriting capabilities to basically hide a redirect loop to the ultimate URL. So basically, when you receive the phishing message, instead of being like hacking website.com
Marc Laliberte 21:51
It was secure web.cisco.com
Marc Laliberte 21:54
or Mimecast protect.com
Marc Laliberte 21:57
which is a legitimate URL and would evade some URL based detection capabilities. They abused a bunch of like compromised sites for a redirect chain, basically the Mimecast one, would go to a compromised WordPress website that had a redirector to the
Corey Nachreiner 22:15
where they were hosting the fish, which we'll get into in a second or hop through a couple of different stops before getting to that that final one, that's just more evasion, right? That's them. Even if you have something looking at the first good URL, they're hoping that at some point it cares less and might miss it because of the mini hops, yep,
Marc Laliberte 22:35
for the actual fish itself, like it got delivered over a bunch of different methods, but the end result was almost always giving the user a eight digit code and telling them to continue to Microsoft to go enter that code, and if they were logged in, they paste in the code and now authorizes the attackers fictional device and grants them access to that victim's account
Marc Laliberte 22:59
they were using Cloud flares, workers dot dev infrastructure in order to host the actual
Marc Laliberte 23:07
the fish in this case. So workers dot Dev was the domain it was being hosted on, which is a serverless hosting service from Cloudflare that was pretty interesting. And then to deliver it, they often used Microsoft Dynamics, 365, customer voice feature, which is like a way to send surveys to customers through Microsoft's platform.
Corey Nachreiner 23:29
They used it instead to host a link to where they were sharing these kind of malicious documents that had the fish contained in them too.
Corey Nachreiner 23:37
Go ahead. Corey, no, no. Looks like you wanted to type in. Nope.
Marc Laliberte 23:44
And finally, like when it came to connecting to Microsoft using these tokens, they even set up user agents to mimic legitimate web browsers too, to just try and mask their activity even more from the threat actors.
Corey Nachreiner 23:58
It was pretty dang interesting, all things said and done, like, in this type of authentication flow, like you said, it is kind of scary, like all it takes is a user that's already logged into Microsoft to get tricked into entering that code and boom, now they've got a 90 day by default, valid token for that user account.
Corey Nachreiner 24:20
Yep, could see why they would be targeting it. But at the end of the it still does require user interaction, which is a,
Corey Nachreiner 24:28
I mean, hopefully every time you're adding a device to your account, any account, Amazon, whatever, by the way, sometimes there's cross account things that they think is a similar you off token, like, for instance, say you have steam, but you wanted to access your green I don't know, your Gog games, you can or you want Gog to see your Steam games, you can basically add Gog to steam. And while it's not a device, it uses the same type of OAuth mechanism, so anytime you're doing that.
Corey Nachreiner 25:00
Whether it's a device, whether it's crossing and linking accounts, you should definitely be thinking about it. And I if we look at practical tips, there is places and all of these cloud apps, clouds where you can go and see connected devices and connected accounts. And I think until there's a better way for security tools or from the cloud providers themselves to
Corey Nachreiner 25:25
to kind of help you audit this on a more regular basis. I think it should be a practical tip that you need to go look at your devices manually every at least every quarter, preferably more, although I don't think anyone will do it more and just check to make sure the devices you have linked are still devices you really expect and want to be there. I mean, hopefully you're not going to fall for the fish that makes you do this in the first place. And you will think about it every time you add a device like this, but you can go monitor those, and I reckon I occasionally will go look at them, just to make sure I still want, you know, WhatsApp to trust my iPad and my phone and my watch and the new whatever I bought
Corey Nachreiner 26:08
and your phone that you lost two years ago kind of thing. Well, that's what I want to find. Oh, wait a second, that phone I sold. Hopefully it's factory reset, and it doesn't matter. Why is it still there? Why do I have seven Kindles on my Amazon account when I only use one. Oh, yeah, I never got rid of the ones when I continue to upgrade. That's the kind of thing you want to get rid of, just in case. And when you get rid of those, you might find that, wait a second, what is this device I don't even recognize. Is it even a device? Nope, you were railroaded. I'd also argue, like businesses should probably just block device code authentication flows entirely and only allow it for specific identities that do need it, like most of your users are not going to need to sign into their TV or whatever with a Microsoft your business Microsoft account, and maybe you've got one or two service accounts, you use it like, I don't know, tablets in your booth at RSA or something, and those might need some sort of access like that, but you can disable it using conditional access policies and only allow it explicitly where it needs to love that.
Marc Laliberte 27:16
But yeah, interesting phishing campaign.
Speaker 1 27:21
As soon as I read the article, I went and audited our infrastructure, and thankfully, none of our users fell for any of those types of fishes that would have been sketchy.
Marc Laliberte 27:31
Anyways. So moving on to the last story. Google published their cloud threat horizons report for the second half of the year. I guess it's h1 2026, so last year's data published the first half of this year just filled with a whole bunch of information they claim is from the Office of their CISO, their Threat Intelligence Group, Mandiant, and then various product and security teams within the Google Cloud Platform. And it has an interesting mix of takeaways from both GCP So Google's cloud as well as third party cloud and SaaS applications too. So I thought we could take some time to go through some of their findings, and I don't know, maybe talk about what surprised or didn't surprise us along the way. And so first section is where they dive into Google Cloud findings within their own environment. Specifically, they talked about first, like the initial access vector for how people are compromising Google Cloud tenants or subscriptions, or whatever the heck they're called. And one thing stood out to me was the software based entry as a category, if you scroll down a little bit on the page, no, as soon as you said it, I know exactly. Software based entry was the biggest vector at 44 and a half percent, which is up slightly from last year. And this is largely thanks to, oh, wait, wait, is it up slightly? I thought it was up a ton. Oh,
Corey Nachreiner 29:02
maybe I was oh, up, you're right up significantly from 2.9% nine to almost half like that is a freaking huge change. Meanwhile, there was a bit of a drop from things like weak or absent credentials, which went from 47% to 27%
Corey Nachreiner 29:19
but it was interesting seeing like vulnerabilities and like code execution points being such a big piece of the pie, for sure. I mean, I we talk a lot about hackers login, they don't hack in meaning that, you know, Phish, identity theft, credential theft, and even things like OAuth token misuse, like we just talked about really isn't like a oday hack, it's misusing identity is usually the big thing. As much as we nerd out about zero day and fully technical attacks, they seem to be rare in the past. So this is a big explosion. This is where I'm getting inspect like this stood out to me, too.
Corey Nachreiner 30:00
We didn't, you know, we didn't collaborate on what we were talking about for this section. But this is speculation, but I wonder if this is AI assisted vulnerability, maybe not discovery, because they do talk later that these are are known CVEs, but known CVEs are often found internally, and the bad guy still would have to reverse and figure out the CV after it was published, if there was no exploit before, if it wasn't literally a zero day. So the amount of software based vulnerabilities blew me away, too. And one of the things I think you and me both agree on and we're predicting, is expect to see more vulnerability exploits in zero day in the coming years because of AI based discovery. So I'm just curious if this could be AI based helping people exploit vulnerabilities, even if they don't have the technical knowledge to reverse patches and stuff like that. They seem to have follow the same speculation lines they said that they suspected it was threat actors opting for more automated paths and software based entry, basically like phishing. It's you can automate it, but it is way easy to automate exploiting a known vulnerability if you've got the proof of concept. And so I could see how this is artificial intelligence being let loose to go after these environments. And it takes the easiest way in which could be an unpatched flaw.
Marc Laliberte 31:26
Other categories, some misconfigurations dropped from 29% to 21% but still, like a good fifth of all incidents were caused by misconfigurations, and then what they labeled as sensitive UI or API exposure dropped way down to just 5% so we're getting better at hardening our endpoints, but I guess we kind of suck at patching our endpoints, unfortunately.
Corey Nachreiner 31:50
So by the way, this this is not endpoints. This is cloud and SaaS app Cloud Endpoints. So this is really kind of, are you configuring Microsoft, 365 correctly? Are you configuring Google workspace, or, more specifically, Google's Pat, you know, platform as a service, Google Cloud? Can they there's plenty of secure configuration you can do in Amazon, AWS
Corey Nachreiner 32:15
and 365 name any SaaS app on top of that. But they also give you the capability to turn things off and shoot yourself in the foot, or worse yet, the face. So I do think the misconfiguration is interesting, because I do, like you guys know how to harden traditional servers and traditional network devices and traditional on premise stuff, but are you doing the proper security configuration and every single SaaS app, which has a completely different way to configure itself, like the configuration settings and m3 65 are completely while they have the same ideas of different things there, it's completely different places to tweak than it would be for Google workspace and AWS from Azure. So it's important to note this is specifically those cloud things, and I think a lot of our MSPs need tools to help find these sorts of misconfigurations. So now this was specifically Google Cloud Platform. They then go on to talk about other third party platforms, which includes both public cloud but also SaaS applications.
Speaker 1 33:18
And the picture was a little bit different once you look at that bucket,
Corey Nachreiner 33:23
look at that later. Yeah.
Corey Nachreiner 33:26
Well, specifically, they said threat actors exploited identity issues 83% of the time, and those so significantly higher than attacks against the Google Cloud Platform. And my first thought was, okay, what are like AWS and Azure doing different than Google? But I'm willing to bet that, like, the bigger differentiator was actually the SaaS applications themselves versus the complexity of Google Cloud's configuration is way higher than the complexity of say, like a Google I would say Google workspace and m3 65 do have more complexity than an average SaaS app, because they're pretty big SaaS apps, but I could see Google Cloud, AWS and Azure, all the infrastructure and platform as a service. The amount of capabilities and configuration is very deep, so maybe it's easier to misconfigure such a big thing, I would still expect things like Google workspace and m3 65 to have more misconfiguration potential than, say, a little SaaS app that's very limited scope, but I'm just guessing either way it sounds like for SaaS apps, it gets more down to these identities, weak or absent credential probably more like identity abuse or credential abuse, but I hear I hear you.
Marc Laliberte 34:49
Yep, right there. Yep, cool. So 83%
Speaker 1 34:53
of events were from just involved identity and broke it into a few different categories. First one.
Corey Nachreiner 35:00
So phishing was about like a third of that. But what stood out to me in there is more than half of all phishing was voice phishing, specifically insane. That's not insane. It's expected with LL, like, with AI being able to automate that. But it's not what I would have expected insane. It is yet different from what we historically would see in phishing where, like, I tend to think phishing is almost entirely email, maybe a bit of, like text or whatever voice would have typically be way further down. I did not expect it to be. More than half. We have had past predictions where we've predicted this and yet we haven't. To me, this is a clear indication that there's pretty light like, you know what I mean? We the trends shoot showed this was starting to happen. But this, to me, is a very clear indication that it's here, and we, those older predictions are probably starting to come through. I remember a machine prediction specifically
Corey Nachreiner 35:53
of the other identity, ones, third party abusing, third party trust relationships, was another pretty big chunk, around 21% I think it was of total events. I wonder if the railways flaw would have fallen within that category, if you could have done it was more like
Corey Nachreiner 36:12
the Salesforce breaches that we've been seeing over the last year or so, where, I mean, it's like accepting OAuth token to connect accounts or I don't either way you Salesforce. Okay, another big chunk was just stolen credentials, either compromised human or non human identities, stolen in a way that wasn't phishing, I suppose. So think like uploaded to a public source repository or stolen by info stealing malware.
Marc Laliberte 36:40
Malicious insiders made up 7% which is a pretty big chunk on its own. The examples they gave were people like shiny hunters going and paying $10,000 for
Marc Laliberte 36:53
employees like HAR files, like exports from their browser with all their authenticated session cookies in it, like if you can find a low paid employee and offer them a big chunk of money that is clearly successful as a method for these threat actors, and 7% of events abuse that too.
Speaker 1 37:14
Of the rest, there was only 2% or vulnerability exploitation, like really damn small compared to what we saw on the platform itself, on Google side.
Corey Nachreiner 37:26
Yeah, huge, huge sense, I think, because, like, if you're talking a SaaS app that's entirely managed by the vendor, and so when they learn the vulnerabilities, they fix them fast and fixing in their cloud, fixes for everyone. When you have a platform as a service application, you literally have to allow things like people bringing their own virtual machines or micro services and the or containers, and those containers can contain a lot of third party products that have nothing to do with your platform. So I could see vulnerability why vulnerability exploitation is so much higher
Corey Nachreiner 38:09
in, you know, paths and actual cloud stuff, the cloud stuff versus the SaaS stuff. And then when it came to the goals for these, 73% of cloud related incidents for targeting data in the cloud, which makes sense if you're going after SaaS applications. 45% of that was data theft without extortion. 28% was data theft with extortion. So there are more threat actors going after data just to steal it, sell it on the underground, whatever, than there are to like, do a ransomware type operation where they threaten to leak it and demand money from you. It is kind of funny though that they have ransomware separately than data theft with extortion.
Corey Nachreiner 38:52
Because I wonder, Oh, maybe their definition of ransomware ransomware, rather than modern don't care about locking ransomware Exactly. That's my takeaway from that.
Corey Nachreiner 39:06
And the last like high level stat that was interesting. And when it comes to like, how they're exfiltrating data out of environments, they looks like we're only a little bit away, if you go to the next image after that one from email being eclipsed by what they call platform agnostic cloud services. Basically for the last couple of years, last decade, they've been seeing like Dropbox, box.com, iCloud, these kind of like cloud data hosting services that you can use from anywhere continue to rise as the preferred method for exfiltrating data out of an organization or an environment, and what used to be the most popular email has been trending downward, and it looks like it's only about a year away from getting surpassed by this other method that makes sense, especially like as we talk about securing the cloud and SaaS specifically, we have.
Corey Nachreiner 40:00
Have tons of controls to monitor email, not just incoming email, but outgoing email. I think if you have any sort of data loss prevention tool, you have it attached to email first, like is at a network level, but less and less, especially in small and mid market, companies, have anything monitoring SaaS, like you threw out drop box, I think, but there's also box, there's OneDrive, there's SharePoint, there's there's so many of these cloud services that offer ways to send big data that are used legitimately, and while you can secure that like there are security controls that will monitor all of those SaaS applications and look for things like large data exfiltrations or unusual activity, or even scan it for certain types of confidential information. But I I feel like threat actors know you have a ton of legacy secure like because emails been around forever, you have a ton of security controls there. But if you're a smaller business, you may have not have invested in protecting the hybrid cloud environment you're now using, and you're you're probably using that environment more than email. So it makes total sense. I think that they're the attackers are changing where they know people might have less protections. So certainly a place to look to protect
Marc Laliberte 41:19
was a really interesting report. They had a lot of defensive takeaways and like recommendations throughout it. They also talked through a specific example of like, a North Korean threat actor stealing millions of dollars in cryptocurrency from a crypto company. That was pretty interesting. But to highlight some of the recommendations that are kind of made sense. First one was just general cloud hardening, so making sure you don't have misconfigurations, following the principles of least privilege. The one that I thought was like, maybe not radical, but ambitious for most companies, was around patch management, where they recommend mitigate within 24 hours and fully remediate within 72 hours anytime there's a vulnerability,
Corey Nachreiner 42:04
and this is more around the Google Cloud AWS an issue, or where you actually have assets that you put there that you can pitch.
Marc Laliberte 42:12
Basically, they gave a few examples of like specific vulnerabilities like react to shell, where they started seeing threat actors actively exploiting them within 48 hours of it getting patched. And so you I think this requires really good visibility into vulnerabilities, but then, like really mature processes to be able to even mitigate within 24 hours.
Corey Nachreiner 42:37
It's something we but, and it's something I feared that the lower you go in the market, they haven't because, like everyone has moved to SaaS in the cloud, SMB probably faster than others, but it feels like the SMB doesn't have the resource to mature their capabilities. So you might be using mostly on prem and virtualized security controls. But do you have this cloud security problem solved in patch management too? It's the same for patch management, right the way? Think about it. Not only do you now have to monitor assets in the cloud, but then some of the things you're monitoring is a Docker container. Does your patch management system know how to get into a Docker container and look at all the patches within that container. And yes, there are tons of solutions for this. We know of them because we use them. We have to do this,
Corey Nachreiner 43:28
but I don't think a lot of smaller companies have have considered that yet. So it's something I think your MSPs can help with you. But with MSPs, you guys should look at solutions that are helping
Corey Nachreiner 43:41
make sure the patch manage in that way too, but also to secure misconfigurations, to look for DLP issues and SaaS apps and to find threads there and cloud apps, because it's obviously the wave of the future.
Marc Laliberte 43:55
Yeah, well said, really interesting report. Definitely recommend taking some time to go through it. And if you do have a cloud environment or even SaaS applications, definitely everyone has SaaS.
Corey Nachreiner 44:07
Anyone not at this, if there's someone literally operating without the cloud, I would be interested to find out, how have they been able to keep that up?
Marc Laliberte 44:18
We have some very cloud allergic customers, so I wouldn't imagine that totally
Corey Nachreiner 44:25
unrealistic tool to get documents and presentations from Google or Microsoft that doesn't require a cloud or any productivity like you have to literally go and find someone selling office 2018 or something. I don't know when they you know?
Marc Laliberte 44:44
I mean, you devil's advocate, you could be installing just like libra office or something like that.
Corey Nachreiner 44:49
I remember,
Corey Nachreiner 44:51
I wonder how updated they are. I've used libra office on one hand. I It's cool that they can do something. But, man.
Corey Nachreiner 44:59
Thank you. Not long term,
Marc Laliberte 45:02
make sure you guys are hardening your cloud environments. Long story short, because they be coming and they be ready to break.
Marc Laliberte 45:09
Hey
Speaker 1 45:12
everyone, thanks again for listening. As always. If you enjoyed today's episode, don't forget to rate review and subscribe. If you have any questions on today's topics or suggestions for future episode topics. You can reach out to us on blue sky. I'm at it, spark.me. Corey is at second depth, and the both of us are on Instagram at Watchguard. Underscore technologies. You can also probably find our emails, and that may be easier to reach us at, but thanks again for listening, and you will hear from us next week.
Corey Nachreiner 45:40
Yeah, let's, let's hope that we clear up the the rain clouds in the future and protect them.
Marc Laliberte 45:46
Someone needs to take corey's little emoji toys away from him.
Corey Nachreiner 45:50
You don't like him. What's up?
