Episode Transcript
Transcript is generated via AI and contains errors! Although this time it got our name correct, so that's good.
[00:00:00]
Matthew: Welcome to the Security Serengeti. We're your hosts, David Schwendiger and Matthew Keener. Stop what you're doing, subscribe to our podcast, leave us a lovely five star review, and follow us at SerengetiSec on Twitter, and who knows, I might check it one day.
DAVID: There's always hope.
Matthew: Always hope
DAVID: We're here to talk about cybersecurity and technology news headlines, and hopefully it provides some insight and analysis and practical application that you can take into the office to help protect your organization.
Matthew: the views and opinions expressed in this podcast are ours and ours alone, and do not reflect the views or opinions of our employers or each other.
DAVID: Hey, we've heard news of a potentially compromised snowflake. If Philip K. Dick were writing this storyline, it would be snowflakes of the third variety.
Matthew: That's right, it's not the kind of snowflake you're thinking of. And it's not the other kind of snowflake you're thinking of either.
DAVID: It is that kind of snowflake.
Matthew: It's [00:01:00] that kind of snowflake,
DAVID: All right, well, before we get to talk about snowflakes, we're going to talk about the White House.
Matthew: man, way to lead
DAVID: how that just goes right in there? White House and snowflakes. All right. So, White House report dishes out deets on all 11 major government breaches from 2023.
Matthew: What a news headline. Where's that from?
DAVID: oh, Can you believe it's from the register?
Matthew: Oh my gosh.
DAVID: All right. So apparently there were 32, 211 cybersecurity incidents in 2023 per the white house report, which is entitled federal information security modernization act of 2014 annual report fiscal year, 2023.
Matthew: That is a really. Loose definition of quote incident,
DAVID: Well, it is the government. They're relatively loose with their stat, their facts and their Anything they say, really.
Matthew: the truth,
DAVID: All right. So they, they've broken [00:02:00] down the the categories of the instance into I think it's, Is it into nine different categories? So the, the one which was the most popular, this was improper usage. So they had 12, 261 of those.
Matthew: and that's got to be people visiting inappropriate websites and using work computers for personal stuff and stuff like that.
DAVID: Yeah, exactly.
The next one is phishing slash malicious emails. And there were 6, 198 of those. Now that, that sounds like a pretty good number actually. Because the government employs 4 million people. So that's less than 0. 2%. Which is totally believable that that's all they had out of 4 million users.
Matthew: yeah, that's got to be confirmed clicks, right? Folks that folks that opened up the email and clicked on the link, that's the only way that would be even close to that low. But. What I find interesting is that most phishing training companies, they'll claim, or you'll see when you do a phishing training, like somewhere between five and 10 percent of people is kind of the normal [00:03:00] click through rate.
Does this mean that the attackers that are going after the government are really bad at their jobs or the government is really good at their training or someone is lying about this?
DAVID: Well, I'll let you guess which one of those three I think is accurate.
Matthew: Actually, you know what? They may not have to be lying about it. It may be that their coverage is extremely poor. You know, if they don't have a proxy or if they don't have a proxy links in their email, they may not know the vast majority of clicks. That's maybe just the number of clicks they were able to detect.
DAVID: Oh, right. So if we move that up,
Matthew: you know, sorry,
DAVID: so, so there's potentially, let's see, 30, 000 that they don't know about them.
Matthew: have somewhere and yeah, some, some number that they just don't know about. Cause as we'll talk about later IDS and IPS is not part of their current modernization. I didn't check to see if proxy coverage is part of their current modernization, but if they're not currently prioritizing IDS and IPS, then I bet proxy is not a big [00:04:00] one either.
DAVID: Yeah. It's flavor of the month with them.
Matthew: Yeah. They're currently still working on deploying EDR everywhere. So
DAVID: Well, ETR is the latest thing.
Matthew: yeah.
DAVID: All right. Next category is unknown.
Matthew: That's a weird one. Why didn't they just leave it as other? Why would they add unknown?
DAVID: Cause they don't have the, they, they knew where they were compromised, but they don't know how, how they became compromised guessing,
Matthew: yeah, maybe. This is where all the xfile stuff goes in.
DAVID: right. So there it's all in the basement of the Pentagon. So there's 5, 687 of those next is web based attacks, but 3, 569. Theft or loss of equipment, 3, 135. And the article pointed out that it would be interesting to see actually what the breakdown there is of how much was theft and how much was lost.
My guess is that 3000 of those at least were laptops left on the Metro.
Matthew: Sorry, I shouldn't laugh, but [00:05:00] it
DAVID: Happens just about every day. The next one is attrition slash brute force. Which is 1147. And then from there, there's a precip precipitous drop to,
Matthew: hold on. Let's talk about the attrition brute force. One that has got to be successful brute forces, right? Because otherwise it wouldn't, if there was just
DAVID: wouldn't be an
Matthew: a brute force on them, it wouldn't be an incident and that would number in the millions. So that is actually a lot of successful brute forces.
DAVID: Yeah. It's interesting though, that they had this many brute forces, which means they had that many account compromises. And yet when we get down into the incidents, the 11 major incidents or whatever, none of them are tied to a brute force.
Matthew: no, they're not. So,
DAVID: So that's pretty interesting.
Matthew: yeah. Well,
DAVID: Which leads into additional,
Matthew: means we know that they caught it immediately and remediated it.
DAVID: or, or as I saw in the army all the time it was just a test [00:06:00] account, no, no big deal.
Matthew: They're all test accounts, if you're a private.
DAVID: Yeah. Test accounts or test systems all the time. But there's a precipitous drop from the, from that 1100 down to the next one, which is multiple vectors. And that's only 92 followed by removal media, which is also 92. And then finally impersonation, which is 30. Now, when we talk about the impact of all of these incidents to quote the article, none registered higher than medium on the national cyber incident scoring system.
Matthew: Oh, thank God. That sounds like a TV show.
DAVID: NCISS, it does sound very much like a TV show for some reason. Okay. Which which acts as the CVSS for individual vulnerabilities and grades instance, according to how impactful they're likely to be on aspects of society. Such as national and economic security [00:07:00] delivering public services and foreign relations.
I thought that was weird. The impact to aspects of society. I mean, most people can't even decide, define what society is. And yet they're using this in their definition of what's impactful for a security incident. So, when you break down the impacts, you have 31, 621, which were highly unlikely to affect society, 348, which were low, unlikely to affect society, 229, uncategorized, which is weird to say that there's not enough info to determine whether it impacts society or not, I guess. And then finally, 31, for the medium which may affect society.
Matthew: So those are the ones that got into the JFK records and
DAVID: Yeah, I don't think the CIA is included in any of this list, so probably not the JFK records.
Matthew: That's fair. Oh, the CIA wouldn't talk about what breaches they've had.
DAVID: [00:08:00] No, except for the what was that? The the Vault 7.
Matthew: that was public. Civil
DAVID: But of those 31, they only categorize 11 as major incidents, and they define major incidents as one of the, one of the following. Any incident that is likely to result in demonstrable harm to national security interests, foreign relations, or the economy of the United States, or to the public confidence, civil liberties, or public health and safety of the American people.
Matthew: liberties, interesting. So like if it came out that, you know, never mind, I'm not even gonna speculate.
DAVID: If you had some malware that was racist, then it would be a
Matthew: I was, I was more talking about like some of the FBI's internal surveillance would be very interesting and would probably, that would be a breach that would potentially cause,
DAVID: let's see FBI breaking into other people's computers though. All right. So the other possible definition of what a major incident would be a breach that [00:09:00] involves personally identifiable information that if exfiltrated, modified, deleted, or otherwise compromised is likely to result in demonstratable harm to national security interests, foreign relations, or the economy of the United States, or to the public confidence, civil liberties, or public health and safety of the American people.
Matthew: public health one's interesting too. What kind of, I guess it'd be like anthrax or something like that.
DAVID: Now, I think that's just a breach of any of the public health establishment, which is actually in the list of. The major instance is the HHS. Which is what we're going to talk about here is we go, we're going to go through the, these 11 breaches here.
Matthew: they gripping?
DAVID: Oh, they're riveting, but it's we'll be run through them pretty fast because there's not actually a lot of information here about them.
The first two. We're from the department of health and human services. And so they had a ransomware attack on a contractor who was responsible for the centers for Medicaid and Medicare services [00:10:00] which exposed the personal identifiable information of 2. 8 million people, half of which were dead.
Matthew: Well,
DAVID: I guess, I guess it's just 1.
4. Really?
Matthew: Yeah.
DAVID: I'm pretty sure dead people are not concerned about how much PAI was compromised of theirs,
Matthew: Yeah. I I was, I actually, when I first read this, I was like, oh, this contract. And then I realized that a lot of these are contractors. And I was like, oh, wait, that's just how the government does all the work. So not actually a surprise.
DAVID: Yeah. Outsource everything because how are you going to pay? Uh, contracting companies, if you don't may have contractors. And the second breach was there were two, I guess they, these were part of one incident, but two systems were targeted by attackers using a zero day, which exposed the PII of 1. 8 million people. So it's pretty interesting that they, they spent a zero day on, on compromising HHS, you
Matthew: Well, it just means that it's [00:11:00] been used elsewhere and it wasn't caught.
DAVID: know, that could be. Because generally you don't want to burn your, your zero day unless you're going to get a high payoff. So they must have expected quite a bit out of that. All right. The next two were compromised at the department of treasury. So the first one is the IRS. Oh, so sad. Saw that.
Matthew: sad.
DAVID: I'm holding back tears. So the, the 990 T forms were, were compromised. The vendor did not the vendor that was responsible for managing these forms not delete data from a staging server. What was interesting about that one is technically that is not in FY23. Because it happened in September of 22, and the fiscal year for the government doesn't start until October of 23,
Matthew: They just didn't report it in time to make last year's
DAVID: my guess. And the other compromise at Treasury was an employee at the Office of the Inspector General. unwittingly handed their login [00:12:00] credentials after being phished by a overseas state sponsored attacker.
Matthew: Always stay sponsored.
DAVID: Yep. But luckily after they unwittingly handed over their credentials they were able to stop the compromise before any lateral movement took place within 15 hours.
Matthew: Yeah this is interesting. So there were 6, 000 quote unquote phishing incidents, and then there's also the 1, 000 plus brute force attacks, and this is the only one of them where somebody's credentials were compromised, and they mention it. And I don't know why. I don't know if it's because there was more sensitive data available on this laptop, like maybe there was PII on the laptop, so therefore they felt like they had to report it, or I don't know what makes this one worse.
State sponsored actor, maybe?
DAVID: Well, I mean, they categorize anybody they want as a state sponsored attacker.
Matthew: Yeah,
DAVID: But the, I think the, the thing is that with all their definitions and everything, there's so much wiggle room in there that they really need to decide what they want to report as what.
Matthew: that's [00:13:00] fair.
DAVID: But the next one is the justice department was the target of two
Matthew: them too.
DAVID: Incidents. Also one was the U S marshal service, which was ransomware. And the second one is vendors applying data analytics support for cases, which led to the compromise of personal and medical data,
Matthew: Analytics support. Interesting. That compromised medical data. I wonder if it was related to like a crime lab or something. I guess analytic data can be any number of things. It does say case analytic data, data analytics support for cases. Weird.
DAVID: right? So maybe it's forensic data.
Matthew: Yeah, that's what I was thinking initially. I don't know.
DAVID: Now you would think that forensic data relating to cases would not be online.
Matthew: No, it's got to be. Everything's online these
DAVID: Yeah, that's a good point. And what's the point of having it if it's not online?
Matthew: Yeah, people expect immediate access to it afterwards. I don't want to wait for the mail to come through.
DAVID: All right, the next one is the computer, I'm sorry, the [00:14:00] Consumer Financial Protection Bureau. So they had an insider send 14 emails, which contain two of which contain two spreadsheets, which with the PII of 256 consumers and apparently they mailed this to a financial institution.
Matthew: That's really weird. Sent 14 emails
DAVID: sure what's going on there.
Matthew: Well, it says, I think it says that the, the 256, 000 consumers, the consumers were linked to a financial institution. So this is
DAVID: I misread
Matthew: an investigation that they were doing.
DAVID: Hmm. Okay. That makes more sense.
Matthew: No,
DAVID: All right, and the next one, park and transit benefit system. So 273, 000 people were potentially affected after several administrative systems were breached and personal information personal data was stolen. And this was a compromise due to an unpassionate critical vulnerability. And the next one, everybody's favorite office, the Office of Personnel Management.[00:15:00]
Matthew: again, I
DAVID: Yeah, this one's a little bit smaller than the 15 million, uh, SF 86s that they gave to the Chinese. But OPM, an OPM contractor was using MOVIT and this is related to the Federal Employee Viewpoint Survey. And this allowed the unauthorized access of data belonging to 632, 000 employees at the Department of Justice and Defense. But I looked at to see what the Federal Employee Viewpoint Survey is. That's the, that's their bitching survey about how, how, how happy they are to be government employees or how unhappy they are to be government employees. So
Matthew: I guess it's not anonymous anymore.
DAVID: not after, I don't think it was, probably never anonymous. I would never trust the government to do anything anonymously correctly.
Alright, so the last one. Is the DOE, Department of Energy. So this appears to be another also move it, move it related incident where [00:16:00] their waste isolation pilot plant and the Oak Ridge associated universities were compromised. So they had 34, 000 former DOE workers covered by a program to support those who may have been exposed to dangerous substances like nuclear waste.
Had their personal and, and health data exposed. And also 66, 000 people from the office of science, were also part of that. So in total, almost a hundred thousand.
Matthew: So this is interesting, just looking over these. So you have two move it related ones. We have one for exploiting an unpatched critical vulnerability. We have one insider. We have two ransomwares.
And we have one phishing. And one zero day. And then the, the the internal revenue service. That wasn't really an incident. That was the vendor didn't delete the data from a server. That was more like a mistake or a
DAVID: Inadvertent [00:17:00] exposure.
Matthew: Yeah, I guess that's a pretty wide variety of items. I mean, two ransomware, one phishing.
One exploited vulnerability to move it. Yeah, it's pretty fun. I was hoping that there would be enough of a pattern that we could draw something interesting from that, but I don't think there is, I think there's just the government has a wide footprint and they're vulnerable to a variety of attacks.
All
DAVID: And this was all generated by a ai, so,
Matthew: right. I found a couple other interesting quips in the report I pulled out that I found interesting. I tried to read through the whole report. It was 37 pages. I didn't quite have time to hit all of it. But they procure, they, they talk a lot in the first half of the report about their zero. Trust initiative.
They're trying to get the government into zero trust
and what's.
DAVID: have zero trust in them, so I think they've already finished that.
Matthew: They've accomplished their goal. Well, there's still people in the United States that do trust the government. So, uh, what's interesting to me is everybody that I, I don't, I haven't heard of any company successfully fully deploying zero [00:18:00] trust but the government on their own self reported report card, most of their agencies are reporting that they are well on their way and they're in the green and they're, they're making it to zero trust.
Maybe in a future episode, we can go through what, what exactly that means. Cause I, I'm wondering if there's zero trust doesn't mean what we think zero trust means. Yeah,
DAVID: that or the Office of Zero Trust is collated Co. Co-located with the, with the the the Unicorn, the Unicorn Containment Unit.
Matthew: right next to the X Files. All right. So two other ones that I found really interesting they made mention in here that in the Latin and fiscal year, 2023, they procured 1. 2 million EDR licenses to cover gaps. In various agencies that blows my mind that the government is still rolling out EDR to all their systems.
They are a decade behind.
DAVID: Well, they said procured too. They didn't say installed or Yeah. They said they did say that bought them. said deployed for three quarters of a million. So they, they bought 1. 2 million. [00:19:00] They deployed three, 750, 000. So you're right, but they're like, that's, that's, that blows my mind. The second part of this was the intrusion prevention and intrusion detection, certain systems IDS IPS are not part of this zero trust project.
Matthew: They're not part of the scope of this. I'm not in scope of the CADS program, which is the automating, something about automating this. And I find this, well, again, this is wild. This is incredibly behind the times, frankly, IDS IPS is before EDR. I don't know why they're putting it off until afterwards or not deploying them simultaneously.
These are big agencies with big IT departments.
DAVID: Well my speculation would be that they see EDR as being pivotal to zero trust, but not IDS IPS,
Matthew: Yeah. I mean, there's, there's something
DAVID: might be why it's not that big a deal for them.
Matthew: Yeah, there's something there about remote work and you know, folks are not on the networks as much they're working from home, they're working from coffee shops, et cetera, but you can still do [00:20:00] IDS IPS with a, with something like a, a Palo Alto Prisma access or something.
DAVID: Well, I don't know. The thing is,
Matthew: go through your network.
DAVID: thing is this is 2024. If they don't have IDS and IPS deployed already,
Matthew: All right, then maybe it's not. Yeah, then maybe it's not worth prioritizing that. That's fine.
DAVID: I mean, it's not like IPS IDS is new. I
Matthew: No, it's not.
DAVID: mean, EDR, it's only a decade old now. You can't expect them to have that done yet.
Matthew: right, maybe they're only eight years out of date on that one. My bad. Not quite a full decade.
DAVID: Yeah. I mean, we talked about, I think it was in our last podcast. We were saying, what's the definition of recent?
Matthew: Yeah,
DAVID: But the reason that I thought that this was somewhat interesting is you know, what is missing from this report?
Matthew: my raise.
DAVID: A tax cut, you know
Matthew: there's a lot of things in this report. Is that
DAVID: but you may have recalled that the Chinese [00:21:00] hackers stole 60, 000 emails from the Department of State in May due to that Microsoft cloud exchange breach in May of 23. That is right in the center of fiscal year 23. So I guess that was not a major incident, had no impact on foreign relations or
Matthew: yeah, it had no impact. No impact on health services or, you know, civil order. So,
DAVID: No, it's the State Department,
Matthew: yeah, not important.
DAVID: so it's probably all emails about who we're going to fight next. But I think it just demonstrates that, you know, they're liars because they're probably justifying not including this in the, in this because of all the wiggle room in their, in their loose language with what needs to be in the report. So there are probably numerous other incidents far worse than what we're talking about here. I mean, we just touched on the, the fishing thing, how the numbers don't even seem wouldn't, would not even make sense in a fishing scenario. So
Matthew: Or the brute force one. [00:22:00] Eleven hundred successful brute forces and not a single one got enough access to make the major incident list.
DAVID: or even rate as a medium, as far as the impact goes. It just doesn't, the numbers are just not adding up. So there are probably like, like I said, dozens or more that you're never going to hear about that are far worse than any of these. And the only reason you hear about these is because they're relatively benign, not, not so bad.
Matthew: this is, this is the whole thing where they ask you in an interview, like, what's your, you know, what's, what's your biggest weakness and you find something that you're like, Oh, but it's secretly a superpower.
DAVID: Right.
Matthew: This is
DAVID: I'm, I'm
Matthew: they made a
DAVID: detail oriented. That's the problem.
Matthew: I'm not I'm not gonna mention the rest of it, let's just
DAVID: All right.
Matthew: So that's it for this one.
That's it for that one next we are going to talk about snowflake, I know all you guys are excited to hear our opinions on it and we made you wait for 20 minutes of talk about boring government intrusions. for joining us. And I am killing yet more time [00:23:00] making you wait even Yeah,
DAVID: just like the ads.
Matthew: we I ended up picking one of the register articles as the headline for this, Snowflake customers not using MFA are not unique, over 165 of them have been compromised, but there's any number of articles out there, you've all seen them.
Everyone knows about Snowflake. It's been all over the news. We're not going to dive into the intrusion itself. You've probably heard that on other podcasts. Our thousands of listeners who are deeply entrenched in the security industry. But we're going to talk instead about what lessons can be learned and maybe some of the stuff kind of around the periphery of this.
As of recording as of the articles we picked up yesterday, Friday, the 14th, 165 organizations that use Snowflake, a cloud data storage processing and analysis platform have been compromised and a quote unquote significant volume of records has been exfiltrated. The earliest known date of the issue was April 14th.
Tackers used legitimate credentials from Infosdealers to log in, even though there were some early reports that Snowflake itself was compromised, which turned out to only be partially true. There was [00:24:00] apparently a test account that was one of these legitimate credentials from Infosdealers. Hudson Rock originally published an investigation they published it a day after the Snowflake advisory, judging by The dates on these various things.
They've now removed their original investigation because they said they spoke to the seller of the information who are trying to get a 20 million ransom from Snowflake. And the person they talked to lied to them and told them that they had gotten this from that test Snowflake account. Mandiant, at the point of time that this was revealed, I think it was on May 31st, had already been investigating for like a month.
So there's a lot of incorrect information the first week or so.
DAVID: Yeah, yeah, I transpose their names every time I read through this in the article, reading that Rock Hudson had originally published the report.
Matthew: You're like, wow, he's dead, isn't he?
DAVID: dead for a long time, and yet he's still publishing cybersecurity reports.
Matthew: I mean, that's what makes him so good. He's the original zero cool. It's just, he's, he's living in the, he's living online [00:25:00] now. I don't know
DAVID: in the ether.
Matthew: He's in the ether. Yeah, he's all right. So my first, my first discussion point kind of in here is, is more around the Infostealer part.
This makes me wonder how many of your organization's cloud slash SaaS credentials are just out there and stolen via Infostealer, but haven't taken advantage of yet.
Uh,
DAVID: maybe they have been taken advantage of.
Matthew: yeah, is this something where the attackers have been using these credentials for years, but it just hasn't hit the news? Like companies have kept it quiet and so nobody really knows that this is a thing.
Yeah.
DAVID: Well, here's the thing. And we'll kind of get into this in, into the, what you can do about it though. But SAS logging is notoriously bad, right? So if they're using legitimate credentials to log into a SAS platform,
Matthew: As long as they don't do anything.
DAVID: as long as they don't do anything that raises a lot of alarm bells, they could be in there for a long time, reading stuff, downloading stuff, even, and who's going to know.
Matthew: That's [00:26:00] fair. I was, I was, I don't know. I wasn't sure if it was that, or that they were focused in the past on certain types of credentials, such as bank accounts or business email that are easier to monetize. Like if you break into a bank account, you just transfer the money out, you break into a business email account.
You can do all kinds of business, you know, compromise related fraud. And now they're kind of like, Oh, this is getting harder. How do we. How do we expand our scope? How do we make money off these things we already have?
DAVID: Right,
Matthew: Yeah, the fact that some of the credentials were from 2020 lends some credence to this to me, but again, like you said, the logging is so bad, maybe they've just been in there forever and this was the first actor who really decided to try and monetize it and get that ransom. It wouldn't surprise me if state actors had been doing this for quite a while, because since they're not financially motivated that would make so much more sense that you would just never know that they were there.
DAVID: right,
Matthew: Yeah, they're just quietly siphoning off the information and giggling to themselves.
Yeah.
DAVID: because they're not incentivized to monetize it, at which point that's when it becomes apparent that something has occurred versus simply [00:27:00] obtaining information that's, that's present in whatever SaaS solution we're talking about.
Matthew: Yeah so I, my personal opinion here is that we are going to see a run on SAS systems by attackers now that someone has publicly done this. There are going to be a whole bunch of criminal gangs out there, and maybe we're too late, maybe this is already happening,
DAVID: Well, I think maybe what we might see happen out of this and I guess it'd be yet to be seen is that we'll find out more about this kind of activity that's taking place because maybe SAS vendors or SAS customers will start in, you know, pushing on their SAS providers to get more information about what's going on in there and you get better logging and you have more visibility of potential, these potential compromises.
And it's not the fact that, you know, attackers are going to be doing more of this so much as it will be more visible.
Matthew: I think there's room for both, because I think there's room for the the JV teams of criminals that are now going to be like, Oh, I, I can log into the SAS system and ransom the, and maybe make [00:28:00] a, maybe make an extra couple hundred thousand dollars. , but you're right. I think you are also going to see, you know, as you start logging, you're going to find that a bunch of these SAS platforms that you thought were totally hunky dory you're going to discover or not. So, although the, the really smart ones are going to know that, and they're going to be like, all right, let's get what we need and let's get out of here and not log back in because now, now that there's an eye on this.
DAVID: just avoid getting caught.
Matthew: Yeah, yeah. So it sounds to me like we're not resetting enough credentials when we detect malware on a system. I mean, I, I know I've typically seen in the past you detect malware on the system, you reset the work accounts. You might tell them like, Oh, you should reset, you know, if you do any banking on this system, you should reset your credentials on that.
Do we, I don't know, maybe, maybe places, maybe there are other places that do this better, but are you doing full on inventories like asking the user or checking their password vault and being like, all right, you got to reset. All these credentials. And that's, that's a thing.
DAVID: I mean, do you even have a password vault for your [00:29:00] employees?
Matthew: That's a fair one, but you should. Everyone should have a password vault. It's 2024.
DAVID: Okay, you keep wishing that, Matt.
Matthew: Although, does a password vault actually make this worse? I don't know how the infosealers work when it comes to password vaults. Does it only access like when you log into a password vault? I mean, I guess they could technically exfiltrate the password vault and they could keylog your password to get into the vault.
So I guess you do have to assume that everything in the vault is compromised.
DAVID: Well, it depends on how the stealer works. You know, if it's just a keystroke walker, then it's only going to get what keystrokes it gets. And depending on the nature of the password vault, they won't be able to log into the password vault to get everything else. I have yet to hear of
Matthew: to even log in. Yeah.
DAVID: Well, I mean, what would be a good info stealer, though, is one that identified the fact the password vault was there, and then once it got the credentials for the vault, then downloaded the vault.
Matthew: Yeah. Yep. Yep. That would be a real pain because a lot of these vaults too, you have shared credentials,[00:30:00]
DAVID: Mm hmm.
Matthew: for every, you know, the, Oh, here's the admin account for AD. It's in the password vault. It's shared. So everybody can access it.
DAVID: Right. Here's all our service account passwords.
Matthew: So that would be a problem.
DAVID: that could be ugly.
Matthew: So, but yeah, that was, so I would definitely, so that, that's where threat intel comes in. Right. You find the infostealer malware and you're like, all right, this is an infostealer malware. Like David said, what does it do? Does it steal password vaults? There may be some more there may be some more call for actual malware versus engineering as opposed to, you know, a lot of companies.
I'm sure listeners have worked through these companies where when you find malware in a system, you. Hit it with Malwarebytes or a safety scanner or whatever, rebuild the system and you're like, all right, back to the races. Let's go.
DAVID: Mm hmm.
Matthew: not, may not want to do that. You may want to figure out actually what it's doing.
DAVID: Right. And if these info sealers got, you know, if these, if the accounts which were compromised at Snowflake were SSO accounts too, that means that those [00:31:00] credentials are also corporate credentials that were compromised.
Matthew: I think that's actually safer though, because that makes it a lot easier with SSO. You only have to change one set of credentials versus 20 or a thousand.
DAVID: Is If they have the SSO credentials for Snowflake, then they've got the corporate credentials. So what other avenues can they leverage corporate credentials for, you know, if they don't have MFA on the remote access, can they use their corporate credentials then just to remote into the network or, you know, what other
Matthew: I mean, I'm pretty sure that's what they
DAVID: are for SSO,
Matthew: Yeah. I'm sure that's what they were doing though, is they were just trying to like RDP into it and get into their email and stuff. So, but yeah, the other SSO, the other SAS stuff, I wonder if there's an easy way to tell that. I wonder if there's an easy way to tell what SAS has been set up so you don't have to just try literally everything.
DAVID: no idea.
Matthew: Yeah, me neither. According to Mtrends 2024 stolen credentials are responsible of 10 percent of breaches. I bet that's going to go up in [00:32:00] 2020. For in the entrance 2025, I bet that goes up to 20%. So some of the credentials that were stolen were from 2020 and had not been rotated. How often are you updating your SAS credentials?
I know that corporate credentials are typically rotated every 90 days, or I think the new isn't the new guidance like six months to a year.
DAVID: I don't know.
Matthew: Well, it sounds like some of the SAS stuff is not being updated anywhere near that. I actually have some experience with this. I have an account on a specific system from a vendor who will not be named. Where there is no way to set a password update policy. In fact, there's no way to even change a password on the system.
If you want to change the password, you have to delete and recreate the account. And this is from
DAVID: Holy cow.
Matthew: right? It is a very interesting,
DAVID: Well, I've never managed a SAS solution. They generally have those, those kind of configurations in there for for
Matthew: Yeah. I've never, I've, I've managed very few of them, so. I can think, actually, [00:33:00] you know what? I can think of another one. That does not, that I've used the same password for. Does that one have SSO? I'm trying to remember. I don't think it does. I think I think I've used the same credentials for like seven years.
DAVID: holy cow,
Matthew: Yeah, maybe I need to go and reset some of my own credentials. This coming week. Sorry, boss, can't do any work this week. got 128 sets of credentials. You know, after I after the last pass thing, and I did reset all my credentials, that was a multi week process. Not like continuously, but you know, an hour or two a day. All right some of the credentials were, some of the credentials were traced back to contractors who had access to multiple organizations, and they were doing, they were using personal devices, which they then used for multiple different organizations that they were working on. Definitely something to highlight.
If you have contractors highly recommend that you ship them a laptop. If even if it's only for a few weeks,
DAVID: Yeah. I mean, especially if you're talking about a small contractor, like who's a sole proprietor, but it hasn't [00:34:00] their own LLC or whatever, you know, the, the, the line between work and personal device is probably very shady there.
Matthew: I mean, their work device, they want the most powerful device for work. And then they're going to be like, ah, well, got to set aside my MacBook pro M two so that I can, you know, get back on this Chromebook to. Highly doubtful they're
DAVID: Hmm. Right.
Matthew: Is there any reason not to have MFA enabled for every single log on accessible outside of the org at this point in time,
DAVID: I don't see one. I
Matthew: especially in the day of pass keys and stuff like YubiKeys and things like that. If everybody complains about MFA then buy everybody a YubiKey.
DAVID: mean, even SMS is better than nothing.
Matthew: Yeah, yeah, I mean, you'd have to be really valuable or really important to justify an attacker doing that interception. Anton Chevokyan wrote an article about this. The important part, I thought, was he brought up kind of a mental exercise of how much responsibility does the vendor share based on how [00:35:00] They treat additional security kind of on the, the vendor is mostly responsible spectrum.
The vendor might not build an extra security or alternatively they might build it and then charge a bundle of money to use it. That's guaranteeing that hardly anybody uses it. That would definitely make the vendor more culpable. In the middle, there's, you know, Gradation such as the extra security exists, but it's kind of hidden under documentation or options or it's available in the UI, but by default, it's off or they, you know, do some of that nudge stuff to try or make you make it a choice when you set up.
Do you want to turn this on on the most secure and the extra security is either default on or is the only choice. And we've seen Amazon go through this over the last decade. They started off making S3 buckets default open. And now they are in default closed and, and there's a lot of other security choices that they've made to make it more secure by just making the default the more secure one.
DAVID: Yeah. I thought this was really interesting approach that Anton came up [00:36:00] with here showing that, you know, there there's as usual, no black and white. This is your fault. This is your fault. There are shades of gray on, on the, on the line here, even in the shared security model, where supposedly we understand who's responsible for what.
Matthew: Yeah shout out to Jay, one of my coworkers who told me on Friday that apparently Snowflake does make it somewhat difficult to turn on MFA. It's an available option, but you apparently have to do some scripting to get it turned on. It's not just like a simple UI change.
DAVID: Holy cow,
Matthew: Yeah, I was kind of, I was so surprised to hear that
DAVID: that is bizarre.
Matthew: it was a very interesting choice.
Yeah, that's, I've actually been thinking a lot about this cause this is something that comes up all the time in security where you talk about like, you know, Oh, everybody participates in security and every employee is our last line of defense. And there's things shouldn't be like that. It should be secure by default.
People shouldn't be able to, you know, destroy the whole company by clicking on a link in a phishing email.
DAVID: Yeah, it's almost like process [00:37:00] isolation, right? So it used to be back in the day, if a program locked out, you had to reboot your computer because your whole computer was locked up because they didn't have really good process isolation. Whereas now, when you've got a process that locks out, You know, you just have to kill that one process.
The rest of your computer is fine. So we should consider security along those kinds of same lines of I mean, silos have a bad name, but you know, being able to do proper isolation between what's what's really dangerous or isolate dangerous activities or dangerous potential things that way.
Matthew: Oh yeah. Yeah. That makes a lot of sense to me. I see that definitely as the future of security for sure. Yeah. Cause we, the way we're doing it now is just, it's, it's, we've talked about this before, like incident response and security operations and detections and so much of security now is slapping a bandaid on stuff that was built default insecure or never patched or never updated.
And, and it's just a money sink,[00:38:00]
DAVID: Right. It's the thing about never really addressing the root cause of the problem,
Matthew: you know.
DAVID: you know, because if you look back to say what was that the credit rating agency that had the the compromise because they failed to patch I forget the company now, but the the root cause of that is their entire vulnerability management process.
It's not the fact that they failed to patch that one thing, right. Even though when they go back to the root cause of the, the that compromise is this was not patched. Now, if that's as far as you go in determining what, what the root cause of the problem is, you're not getting to what the true root cause is.
It's better to go through the, the, the whole five Ys of a root cause analysis to determine what was the true root cause of this. And maybe the, the ultimate root cause of it is your vulnerability management program is crap because you don't want to put money into it. You [00:39:00] know, so it's actually a board decision or an executive decision.
That's the root cause of the compromise. It's not failure to patch. It's not your vulnerability management program. It's, you know, leadership decisions that are the root cause of the problem. And unless you dress address those, you're never actually going to get better or prevent this kind of thing in the future.
You're just band aiding over it until the next time.
Matthew: Yeah. All right Spectrops had an interesting post on the access model of Snowflake and the commands used to exfiltrate data. Makes an interesting read if you're not familiar with Snowflake, which I wasn't. Goes over the commands list in the Mandiant report, discusses how they work, gives a little more information.
Both give some idea on how to detect an attack like this, especially with the staging of data and the exfiltration. Although they did use built in commands, we're back to living off the land to stage and exfiltrate. So you can't just create a rule that says whenever somebody sets up a stage or whenever somebody copies data, because that's just gonna, that's just gonna go wild.
But you could probably look for reconnaissance commands or a bunch of commands like that listed out the contents of the tables and then [00:40:00] look for staging. Recon plus staging maybe. But in this case, prevention is probably easier than detection. By the time you detect it, the exfiltration is probably ongoing. So
DAVID: I think you and I may have talked about this before about. How with the expansion of the law bins, it's more and more important for security teams to be talking to the businesses about how they do business and how
they do things
Matthew: to see? What are the commands that, you know, are part of normal business and then therefore what would not be?
DAVID: in order to better, better identify when something hinky is going on
Matthew: So why does this matter? Every company uses SAS these days and SAS databases, especially are very high risk. That last part was courtesy of David. What should you do about it? Reset every SAS credential.
DAVID: now, right
Matthew: I'm overreacting.
DAVID: reset your path. Reset it.
Matthew: I'm overreacting. No turn on MFA everywhere.
DAVID: Yeah. And you know, and if you access, or if you can only access the SAS [00:41:00] solution from your corporate network, see if you can do IP restrictions on that access to the SAS, if possible, get the logs from the SAS into your SIM and monitor those like anything else, or maybe even more so. That's going to be a tough one based on my experience with SAS vendors. Before you contract with a SAS, make sure you know the state of their MFA and IP restrictions and logging capabilities. It would also be a good idea to sign up your organization for the Have I Been Pwned account. So, you know, if a corporate ID was compromised you, you can get set up and get up alerts and monitoring for that and see if you can have, you can do this maybe also with your employees, personal accounts because of the possibility of password reuse between their personal accounts and their corporate accounts, train your, your, your employees to use a password manager and not to reuse passwords.
Matthew: I'm curious if any password managers at a corporate level allow you to take inventory of the credential store in [00:42:00] their URLs. I'm wondering if, for example, we're talking about Snowflake or, you know, Box or anything like that, if you can go into, you know, the Corporate LastPass, probably don't use that one, but I'll use it for the example, the Corporate LastPass, and look like how many Box.
com credentials are stored in here? How many Snowflake credentials are stored in here? I don't know if that's possible, probably not in the personal private part of the vault, but in the shared part, I would bet they would.
DAVID: Right. And this is one of those things also where I think, you know, we were talking about thread Intel. That would be a thread Intel function. I could see that thread Intel would be you thread it. This would kind of fall within the realm of thread Intel of saying who's got, who's been compromised and comparing those compromises to your SAS inventory essentially to see how affected you are by that SAS compromise.
Matthew: That would be really interesting as well for the next one. Cause the next question is, do you have an inventory of SaaS platforms your company uses and who uses them? You probably have an official [00:43:00] inventory and then you probably, there's probably a separate inventory that doesn't exist of the shadow it ones.
And would you even know if one of these credentials was stolen by an Infostealer? If you were able to do a password manager audit, you might be able to see, you know, oh, that's weird. We've got 47 sets of box credentials that use corporate email addresses.
DAVID: Yeah, and if you have a CASB, a CASB can help you do that inventory of who, what SAS platforms are being accessed, depending on which CASB you have.
Matthew: finally be more aggressive, as I said, when you do password changes. Again, don't just change the work. Talk to the user, figure out what they have accessed since if you, especially if you can tell when the malware was installed, you know, if it was installed earlier today, then maybe you're good. If you look it up and you do some thread Intel on the info stealer, and it's just a key logger, like, all right, great.
You know, whatever you typed in the last four hours, although I don't trust them, make them change more because users will always lie.
DAVID: No, come on now.
Matthew: but be more aggressive, like don't just [00:44:00] change the work password and then move Apparently they're getting a lot more than just your work email. They're getting those SAS platforms.
They may be getting the personal logins, bank accounts LinkedIn, you know, social media, who knows? Be aggressive about it.
That looks like that is all the articles we have for today. Thank you for joining us. Follow us at Serengeti Sec on Twitter and subscribe on your favorite podcast app.
