Risky Business - Risky Business #767 – SEC fines Check Point, Mimecast, Avaya and Unisys over hacks

Episode Date: October 23, 2024

On this week’s show Patrick Gray and Adam Boileau discuss the week’s cybersecurity news, including: SEC fines tech firms for downplaying the Solarwinds hacks Anonymous Sudan still looks and quacks like a Russian duck Apple proposes max 10 day TLS certificate life Oopsie! Microsoft loses a bunch of cloud logs Veeam and Fortinet are bad and should feel bad North Koreans are good (at hacking) And much, much more. This week’s episode is sponsored by Proofpoint. Chief Strategy Officer Ryan Kalember joins to talk about their work keeping up with prolific threat actor SocGholish. This episode is also available on Youtube. Show notes Four cyber companies fined for SolarWinds disclosure failures U.S. charges Sudanese men with running powerful cyberattack-for-hire gang Hacker Charged With Seeking to Kill Using Cyberattacks on Hospitals | WIRED Risky Biz News: Anonymous Sudan's Russia Links Are (Still) Obvious Microsoft confirms partial loss of security log data on multiple platforms | Cybersecurity Dive Risky Biz News: Apple wants to reduce the lifespan of TLS certificates to 10 days Encrypted Chat App ‘Session’ Leaves Australia After Visit From Police Crypto platform Radiant Capital says $50 million in digital coins stolen following account compromises North Korean hackers use newly discovered Linux malware to raid ATMs - Ars Technica Brazil Arrests ‘USDoD,’ Hacker in FBI Infragard Breach – Krebs on Security Here’s how SIM swap in alleged bitcoin pump-and-dump scheme worked - Ars Technica Critical Veeam CVE actively exploited in ransomware attacks | Cybersecurity Dive FortiGate admins report active exploitation 0-day. Vendor isn’t talking. - Ars Technica Hackers reportedly impersonate cyber firm ESET to target organizations in Israel The latest in North Korea’s fake IT worker scheme: Extorting the employers

Hey everyone and welcome to Risky Business. My name's Patrick Gray and I am seriously unwell this week. So we're going to struggle through the show the best we can. For those of you watching on YouTube, I'm not going to do the graphical overlays this week. I'm just too sick. I've got to finish the show and get it down as soon as possible so I can go back to resting. But we do have a great show to get through this week with Adam Boileau. He'll be along in just a moment to go over the week's security news. And then we'll be hearing from Ryan Callenber, who is this week's sponsor guest. Ryan is the Chief Strategy Officer for Proofpoint, and he'll be talking to us about the Sock Gullish campaign, which is, as best they can tell, number one at the moment in terms of mass exploitation activity

targeting its user base, Proofpoint's user base. So he'll be joining us to talk about the evasion steps that they're doing these days, which are actually pretty interesting. So that one's coming up after the news, which starts now. Adam, good to see you. Yeah, nice to see you. I'm glad that you're functional enough to bring us some news today because it was looking a bit sketchy there

yesterday. Well, yeah, I would put my functioning level at barely at the moment but, you know, hopefully in a couple of days I'm going to feel better. So, let's get into it and just some news that broke overnight for us. The SEC has fined a bunch of companies for essentially covering up the extent of the impact of the SolarWinds campaign on them. So we're looking at Checkpoint via Unisys and Mimecast. complained about here is that you know they sort of used very general language to disclose these breaches when in the sec's view they were sort of material and you know they should have they should have come clean yes like some of the statements that we saw around that hack and kind of i i want to say downplayed it but maybe uh kind of made it seem like it was theoretical when in fact they knew very much that they're the

actors the russians had been in the network through that you know particular set of backdoors and that they had in some cases lost customer data i think one of them said that some email had been taken but actually there was a bunch of other stuff so the sort of you know just kind of making it seem smaller and less than it was uh which is you you know, a thing the SEC does not take kindly to. Yeah, I mean, disclosing a breach as a security vendor looks bad. I think getting dinged by the SEC for failing to disclose it looks even worse.

Yeah, exactly. And, you know, hopefully it will encourage the others in this world to, you know, say things how they actually are. We are just seeing a lot of weaselly weaselly language around security breaches and bugs lately okay now we're going to talk about probably the most interesting story of the week uh which is this anonymous sudan arrest right or arrests two brothers have been arrested in an unnamed country and apparently they were the ringleaders of this

group anonymous sudan and for a long time, we've thought, well, Anonymous Sudan clearly looks like a front for Russian activity. We're not the only ones who think this. The threat intel community also believed this. So it was kind of surprising when DOJ announced that they'd arrested a couple of Sudanese people for actually being behind, you know, Anonymous Sudan. I mean, they've collaborated with Kelnet. They've got shared infrastructure with Russian groups and things like that. So big surprise.

And that's much how it's been reported. In fact, even at the DOJ press conference, they came out and they said, look, there's no nexus with Russia here. And that's been the reporting. Although when I started talking about this in Slack, I kind of got slapped down pretty hard by our own colleague, Katalin Kimpanyu. And I really

appreciated how he did this because he says so many people have short memories. He didn't say it directly about me, but that's what he meant. So many people have short memories and then laid out a bunch of reasons why he thinks this has Russia's fingerprints all over it. And indeed, he wrote that up for his newsletter, which we publish called Risky Business News. And I've linked through to the web version in this week's show notes, and he lays out a really compelling case that just because these guys were Sudanese doesn't mean that Russia wasn't all over this.

Yeah, I mean, I guess the easy headline of, oh, my God, you mean Anonymous Sudan was actually Sudanese, it does take away a bit from the truth of it, as he kind of points out, right, which is that whilst they may actually be Sudanese their purported kind of you know motives of Sudanese national interest isn't really supported by their activity right they have done so many things and here's like a laundry list of the activities that anonymous Sudan carried out and you know kind of you know at

best maybe useful idiots and at worst you know kind of actively getting getting paid by the Russians or you know getting you know working directly and closely with the Russians but the actual things that they were doing you know were so diverse from you know sort of things that would matter to Sudan and very much you know aligned with russia's interests right i mean there's things that lined up with the invasion ukraine there's things that lined up um with um you know the burning of the quran in sweden there's well that's that's when and he points out that's when this group sort of first emerged and he also points out that like they threatened france with a ddos attack if it sent troops to nigeria after the country was taken over

by a russian-backed military military junta and you know that doesn't sound like sudanese nationalist ideology right uh yeah and what was the other one they yeah ddos attacks related to the ukrainian war or a country would announce military funds for ukraine in the next day anonymous sudan and a bunch of pro-Kremlin groups coordinated attacks on their schools and hospitals. As Catalan writes, that does not sound like a Sudanese nationalist ideology. And also, yeah, also the Koran stuff in Sweden.

And they use all of the terms that are favoured by Russians, like, you know, talking a lot about Western colonialism and French imperialism, which is the lingo that's been used by Russian info ops in Africa africa for years he also points out like some of the infrastructure overlap is pretty interesting yeah i think also that like their telegram was previously like largely conducted in russian until they switched so yeah like there's a lot of things that point to russia even though you know the indictments that we've seen so far don't really kind of spell it out. I think Catalin is probably onto something here

that if it quacks enough like a duck, it probably is some kind of duck or duck-like thing. And so, yeah. The point is these guys have been arrested. We don't know particularly where. We don't know if they're going to arrive in the US to face American justice. But either way, we haven't seen a whole bunch out of a non-Sudan,

you know, since these two were rounded up. So that's probably good. As you say, Catalan writes, there's also the small detail of the anonymous Sudan Telegram channel having a history of Russian posts before switching to Arabic and then to a Sudanese Arabic dialect. They also have a history of cooperating with Russian-based groups like Killnet and sharing their infrastructure and tools.

And when the feds took down the anonymous Sudan botnet and arrested the two brothers, another pro-Kremlin hacktivist group popped up out of nowhere sharing infrastructure and an MO with anonymous Sudan. And that one, at least according to Radware, was actually run by a Russian. And, you know, it's just amazing. Anyway, I've linked through to it.

I think he's done a terrific job here. So yeah, I just, I just think that was terrific. Now look, let's move on to Microsoft, some Microsoft news here. And there's been a bit of an issue involving Purview and like Microsoft logs where they just like lost some of these logs. Can you, cause I know you did a more of a deep dive on this one. Can you walk us through what actually happened here? So at some point, Microsoft made some software changes to an internal like log collection

mechanisms and things that were inside Microsoft infrastructure that collects data to stream off into the rest of Microsoft's logging platform. And they, it looks like there was some software flaw they were able to fix for it, and that fix introduced another bug that they hadn't really expected. And the net result of this was they ended up losing a bunch of logs, including probably most importantly logs from Entra, so authentication logs out of their cloud identity service, which is then like this is kind of one of the upstream sources

for things that get fed down into their SIEM product, into Sentinel, into things that they share with customers. So it looks like they lost maybe, you know, three-ish weeks worth of data. But hang on, hang on, hang on. So the thing that I'm not clear on here, is that across all customers and tenants, or is this just some of them?

So the answer is it's probably complicated. We don't exactly know. But what Microsoft have said about the bug was essentially there was like a deadlock condition that could occur in the logging software. And if enough of the threads of the logging software got deadlocked, then it would stop logging. And then it had a local cache where it would store logs. And if that got too full, then they were lost for good. If they restarted the agent or whatever else in between, before the local cache got too full,

then they would get those logs when it subsequently reconnected. So we're not talking 100% loss. We're talking kind of statistical loss. Yeah, random. A little bit over here random a little bit over here a little bit over there when that logging box rebooted and you know it came back and for a while and yeah i i see where you're going with that yeah yeah and they've got like a timeline uh on their like initial incident right up which kind of you know spells out how it happened which

kind of started beginning of september and then they went through a bunch of steps whilst they tried to figure out you know what the problems were how how to fix it um and you know kind of illustrates the difficulty of troubleshooting you know very big distributed systems also multi-threaded systems also um you know all of the the you know kind of the complexities of the cloud aspect of it like this stuff is hard especially at scale and with live data but on the other hand like microsoft's huge and this is security logs for most of the planet so yeah you've got you've got to do good I like how every time there's a story like this about Microsoft Kevin Beaumont pops up you know always to give him a kicking and

yeah he's in here he's quoted in a bunch of the stories we're talking about this week it's the link through to their write-up that I'm working on he posted a link to that so So, yeah. Thanks. Thanks, Kevin. Thanks, Kevin. Yeah. Now let's talk about Apple's plans for TLS certificates because, you know, we've got them down to like just over a year, right? That's the sort of accepted standard by what's the body called again?

The browser. The browser. The CA browser forum. Yeah, CA browser forum, right? So, you know, we're down to about a year and Apple's come along and they've said no we're shooting for 10 days which that's you know that's ambitious uh but i wanted to ask you to explain to everybody why we might want to do this because that is that means that everybody's certs are going to need to be sort of programmatically generated it's going to be like auto renewal because there's no way admins are going to be manually swapping out certs i mean for our site we're still on one

year certs and we swap them over because there are some complexities there if you want to use let's encrypt like for example because we distribute through a cdn the only way that we would be able to use let's encrypt with our cdn is if we also transferred the domain to the same provider. And I don't want to do that because I like to have multiple providers in these things in case you lose one account, it's not the end of the world, et cetera, et cetera, right? You don't want to put everything in one basket. So, you know, I just think I'm going to have to change if this becomes a reality, it's, I'm going to be absolutely forced to do this programmatically for risky beers.

But yeah, why the push to get it down to such a short time? Well, I guess there's been a bunch of problems with certificate infrastructure over the years and reducing the timeframe has, I guess, a couple of things. Like one you've hit on, which is that it forces people into automation. And that means a bunch of kind of good systems engineering practice like rolling certs by hand you can get away with when it's a year

but then there's a bunch of other challenges with how you know key material gets managed and how like the whole process is ad hoc if you do it yearly if you have to do it every week every couple of weeks you have to automate it and you have to automate it probably well i think the other aspect of this is the recognition that the revocation infrastructure and the process for dealing with certificates being stolen or lost is just not working so by reducing the lifetime of certificates you kind of solve the revocation problem like you kind of make it you know much less of an issue because you know turning around a revocation probably is going to take about that amount of time anyway so if the certificates get rolled then you've kind of solved that problem in a way that you know probably is good for the

ecosystem overall you know working revocation there's so many kind of moving parts in revoking stuff that just reassuring things constantly probably is still easier and better so i think that's probably what they're what they're aiming for here but you know there are just there's such a long tail of ways that certificates and tls are used beyond very modern very hip very you know agile and dev op technology companies right there's a lot of people who do just do it by hand in some cases for good reasons. As you said, with our infrastructure, you know, there is some diversity and some resilience in how we do things that we would have to rethink. So, you know, it's probably still a good idea, but, you know,

it'd be nice to make those choices on our timeframe instead of, you know, instead of Apple's. It's worth noting that this is just a proposal and Google proposed a similar kind of thing to the CA browser forum, you know, a while ago, they wanted 90 days and that didn't kind of make it through the process. So, you know, I'll believe this when they actually get, you know, get a yes vote out of the CA browser forum, but browser forum but it's pretty it's it's bold you know it is it is i mean they say they want this to happen between september next year and september 2027 um you know maybe that's achievable i'm not sure uh but i think the point you made about revocation that's the convincing argument because it is so

broken you know oh god are we still using CRLs? Like it's just, it's never worked well, ever. Yeah, I mean, yeah. It's not a thing that we ever really exercised at scale and there's a bunch of mechanisms that we've put in place to try and deal with it. So things like OCSP and state plan and reivocation and even just specific transparency.

It's not just CRLs yet. Like that problem's been addressed. But it's still fragile because I remember some of these other more modern ways to do checking for revocation. If you were upstream, you could block them and then it would fail open, right? So like there's always been issues there with revocation. Yeah.

I mean, as a general mechanism, it was never really well thought out and certainly not at scale i mean certificate infrastructure if you were going to design a mechanism to do this at planet scale like this is not what you would have would have arrived at right this was designed for a much kind of smaller world where admins had control over their environments and things like there's just so many reasons why you know this infrastructure never was really meant to be like this and i think yeah this is a recognition of that and like it's just it is such a mess uh and dealing with all the weird failure cases all of the failing open all of the um you know other strange things that

can happen you know this is it seems sensible despite the initial sticker shock of oh my god i have to roll my certs once a week yeah i mean it will you know automation introduces some fragility we've seen companies uh have issues before when they haven't been able to get their new certs due to failures failures and various services i'm i'm less sold on the idea that it's a giant leap forward in terms of making certificates that you've stolen useless, because I think if you can get persistence, if you're in a position to steal the certificates,

you're in a pretty good position to get some persistence there as well. In most places, at least, at least, but I do, I do a hundred percent agree with you that the, that the revocation piece is the, is the compelling argument here.

So let's see how they go. Yeah, exactly. I mean, best of luck to them. So let's see how they go. Yeah, exactly. Best of luck to them. I mean, my 10 seems low. I mean, even 45 as an intermediate step that they're proposing, that would be pretty cool too. I would be happy for smaller.

Yeah, yeah. We've got a great story here from Joe Cox, which actually looks at some events in Australia where there's this open source encrypted messaging app which is metadata resistant and I'll talk about that part of it in a minute it's called session and it has announced that it's moving its operations to Switzerland after one of its employees got visits was visited by the Australian Federal Police so the Federal Police came interviewed this employee and was basically like asking them a bunch of

sort of general questions about the platform there were two visits asked some general questions about the platform development roadmap sort of stuff and discussed an ongoing investigation into a sort of high profile session user who i presume is australian and this was enough for them to say okay that's it we're out of here and they've pulled stumps for switzerland now i hadn't actually heard of this app until uh joe's story and it looks really interesting because it looks a bit like stuff like, you know, Ricochet or Tox. But instead of using the Tor network, which and there are inherent problems with trying to do that on mobile, right? Because if you're offline, when someone sends you a message, and then they dip offline, how do you get the message to them, right? Everyone, you know, people need to be online at the same time for these, these sessions to, to actually work. So what they've done is they've built like their own onion routing network and they've got community volunteers running some of these, which I think for intelligence and law enforcement presents some opportunities there. Cause I can't imagine the network has that much power in it. Um, but yeah, so, so the idea is it's a, is a,

a metadata resistant mobile messaging platform. And I've had a look at their website. It is interesting, right? Because you go through this story and they're just like, oh, my God, you know, Australian regulations want us to collect a phone number or an email address for, you know, for users. And this is unacceptable because, you know, privacy, privacy, privacy. And you go to their website and, you know, they are clearly big believers in privacy, privacy, privacy. And you go to their website and, you know, they are clearly big believers in, in, in privacy, absolute privacy being an essential function, uh, these days. Uh, so, you know, they, they are true believer types. I don't, they don't strike me as the sort

of crime phone types, if that makes sense. Um, but I am curious about how well this move to Switzerland will work out for them because it's one thing to move the registration of the company or the foundation or whatever. But if you're not moving the staff, I don't know how far that gets you in front of an Australian magistrate who, you know, if a prosecutor can argue, well, you're in control of this thing, it doesn't really matter where the thing is registered. You know what I mean? Anyway, I want to get your thoughts on this too, because I found this a very interesting story. Yeah, it's interesting because, you know, we expressed surprise, I think, a couple of weeks ago about it was a crime phone manufacturer

or a crime phone operator, something that was running out of Australia. And we were like, well, that seems like a silly choice. So seeing another one crop up so soon after is funny. Well, again, I think these people are more sort of your open source privacy hippie types right like they're not they're not they give us 10 000 a month and we'll stop you getting intercepted types that's different yeah yeah and i i think you know your point to that moving you

know in this case like it's the foundation that holds the like publishing rights for the app stores and science certificates and things like that, that they're moving to Switzerland. If, you know, the actual developers and operators are inside Australia, as you say, I think, you know, that technicality may not matter quite so much. Well, I mean, Pavel Durov was arrested in France and Telegram's not based in France. Yes, exactly right.

I mean, in the end, the law is willing to use its powers in whatever way it sees fit, right? As to the technical aspects of this network, it does have a bunch of interesting properties to it. Like the idea of running your own onion routing because of the problems with Tor, I think is really interesting. Open source and volunteer run, that has worked on some other platforms.

Like I guess Tor is the biggest one that's, that has run a functional onion routing network. But we also know a lot more about attacking onion routing protocols and stuff than we did, you know, back when Tor was originally designed and they've made a bunch of changes over the years. But, you know, I would be a little, I a little i know intelligence agencies are smart and have a lot of resources and as you said like if you're at a scale where the network is small and you the adversary is quite big you know things can be difficult but when i'm not a not an expert on on their particular protocol so i don't know what you know how they address the challenges but you know there are you know there's a bunch of moving parts to doing this and you know i mean it's you know, there's a bunch of moving parts to doing this and, you know,

you would be kind of worried about. It's one of those things, Adam, where if you have the majority of the nodes in the network, there are things you can do. You know, I think it's really that simple. So if you're, you know, if you're NSA, for example, and you notice that this app is catching on among a subset of people that you're very interested in decloaking, then, you know know you're going to be quietly spinning up nodes left right and center

until you've got you know a sizable enough chunk of the network which you can't do with tor now because it's so big we've seen the number of tor nodes swell and then contract and that's obviously some agency somewhere trying to get some intel on someone right um but when it's something like this early on you know maybe there's an opportunity there for them not that i agree with it uh you know but um i'm just saying that could be something they could do yeah and i guess anything like this the challenge is what happens when you succeed right because something like telegram has gotten so big and now you know durov's arrested as a result so you know let's say that this thing i mean the um uh 404 media story already says like they've got some anecdotal evidence of people doing crimes on the platform um because it supports kind of telegram style group messaging

as well as direct messaging um so like let's say they succeed and they run out of switzerland and they're you know do wonderful things and and bring lots of Switzerland and they're, you know, do wonderful things and bring lots of privacy, but then what happens, you know? Yeah. So yeah. Then they might wake up one day and realize that their platforms being used for crime and Nazi stuff and,

you know, maybe reevaluate some choices. But I mean, I don't, I don't think it's a reasonable, I'm sorry. I don't think it's an unreasonable regulation that if you're going to operate a messaging platform that you should have at least one identifier for who's going to...

In a country like Australia where we have rule of law, we have protections for political activity and stuff. Like, what's the problem? But I get yelled at for saying stuff like that. So, you know, let's move on. John Greig over at The Record has a write-up on a crypto platform called radiant capital having 50 million dollars worth of digital coins stolen but what's interesting here

is the nature of the compromise which it looks like they got three developers for this platform and they were using hardware wallets so like walk us through what we know here, Adam, because I think if I had to guess, like maybe they had, you know, malware in the right spot to sort of, you know, to sort of set up the transactions they wanted in the background while presenting different transactions to the user. But I mean, I thought that's what hardware wallets were supposed to stop. So, yeah, this is an interesting one. We don't often talk about the specifics of of crypto theft because there's so many of them um but yeah so these this lot appeared to be doing things kind of roughly best practice right they had a multi-signature mechanism where to move their coins around the blockchain you know they had to have multiple signatures multiple developers

distributed geographically and then the private key material was stored inside various models of hardware wallets and the attackers in this case got onto the computers of these three developers and then made a fake like faked a user interface for their multi-sync process so they had that the thing that generated multi-signatures to approve big transactions so they made a you know fake user interface that convinced them that they were dealing with their real piece of software presented one set of transaction details whilst in the background approving the theft of you know 50 million dollars worth of of ether or whatever else um and then carried out those transactions using their hardware wallets normally and that's pretty slick um and you know you've got to wonder like if you were entrusting

all of your money and wealth and whatever to cryptocurrency platforms this is pretty best case what a crypto platform looks like you know in terms of taking it seriously and doing the right things and they still get it nicked uh so like but i thought i thought the point of a hardware wallet is they have a display which will actually tell you what you're doing with the transaction right like you don't just trust your computer plug in your hardware wallet and go yeah sign sign sign that's why a little bit fuzzy here that's the theory but i think the multi-sig part of it probably complicated that display process right where they right because they've added extra things to it there's another layer of you know

kind of indirection into it it may have not been obvious what they were authorizing and i think there were um a couple of them using trezor wallets and another one was using a different brand of wallet so that wasn't it wasn't the exact same hardware you know kind of key store so i don't know exactly what that looked like on the display but either way like whoever pulled this off is pretty good you don't you don't gotta hand it to him you don't gotta hand it to him i don't know if it was north korean speaking of not handing it to them i can you know i mean come on who else i mean it might have been them i don don't know. We just haven't seen anyone manage to figure out, I think, or any ideas that it ties into existing stuff.

But yeah. So maybe you do got to hand it to them, you know? Maybe you do. You do. But look, speaking of North Korea, this is great, actually. This is an Ars Technica piece from Dan Gooden, and they've got a write-up on North Korean activities targeting ATM networks what's funny about this though is that they have replicated work that you did uh years ago and they've almost replicated it one to one walk us through this uh yes so the

um the North Koreans in question uh have deployed some malware on payment switches so these are the things that kind of connect ATMs and point of sale terminals to banks and then also connect banks together and card brands together and you know acquirers and all the other bits of that kind of transaction processing ecosystem and there are a number of kind of messaging standards for doing these transactions and these are standards by and large from the 80s and are kind of extensible and pluggable and have all those sorts of problems that come with you know being extensible and also very old the North Koreans in this case had got software on

to some of these payment switches and were reading and writing the messages as they went past and they would look at for example a request to withdraw cash from an ATM. That gets sent onwards to the bank that holds the account. The bank comes back and says, no, transaction denied because not enough funds. And then the North Koreans would rewrite the message to say, hell yeah, you got enough funds and off you go. And then the ATM spits out cash and onwards to great victory. I think the sample that we've seen of the malware that was doing this was doing it in turkish

uh lira lyra uh so suggests there was a you know a campaign there that they were using to get money out um but yeah i this really warms my heart because this bit of the payment ecosystem is so old and crusty and i've written a protocol stack for doing this like i man in the middle to a point of sale terminal so that i could rewrite balances and and rewrite approvals and so on and things like we should point out that you did this in a professional capacity i did this in a professional capacity you weren't trying to buy get a free flat screen we should probably no um but the uh like most people say like surely this is inside tls and like this stuff predates this is designed for when it was dial-up modems sending these

messages over you know over leased lines or whatever else like this stuff predates the internet and these days people do run it over tls in some cases but you know it's not like this software has search checking revocation support in it or whatever else like a lot of the stuff is not done over tls and then where there is crypto or message integrity checking it tends to be done on like a per field basis inside the actual messages and then there's things like this predates the understanding that padding oracles exist or whatever else so like this is old, old tech. Anyway, it's fiddly.

I got to hand it to the North Koreans for actually going through the process of doing, because having written it myself, like I know what a pain in the ass this is to actually do. And to do it in the wild, stealing actual money. Like, you know, my hat is legit off to the North this week, I'm afraid. I mean, you read this and you're like, wow, you actually really did the R&D here, you know? Yeah, I mean, it's just fiddly. And then they've done this on like old school,

like AIX, you know, and old Unix platforms. But in this case, they were doing it on some Linux payment switches as well. So like, it's just a, you know, solid hacking. And yeah, I'm here for it. Okay, now we're going to turn our attention to a story from Brian Krebs at Krebs on Security. And a 33-year-old Brazilian man from the state of Minas Gerais has been arrested.

And apparently he is suspected of being USDOD, who is a prolific cybercriminal who rose to infamy in 2022 after infiltrating the FBI's InfraGard program and leaking the contact information for 80,000 members. That was quite embarrassing. This guy was also the one behind the breach at National Public Data. Funnily enough, we didn't mention it last week, but they've since filed for bankruptcy.

This was that really weird former actor who ran National Public Data, which was like scraped publicly data and whatever um brian's done a great job uh of writing this up uh because really this guy realized he'd been doxxed by i think it was crowd strike got him initially and he's just been doxxed that many times and he actually just came out and said yep it's me uh i've been caught and let's see if i get arrested kind of thing and yeah he's he's he's been arrested but he is in all sorts of trouble you would think yeah i imagine he is going to be going to be in trouble and uh like you kind of

it's unusual that you feel sorry for these guys but um brian had a screenshot of a statement that he made on some hacking forum where he basically says look i'm a human like everyone else to be honest i wanted this to happen i can't live with multiple lives and it's time to take responsibility for every action of mine and pay the price doesn't matter how much it may cost me this is not my end see you around yeah don't worry representing authorities i'm coming to meet you i'm not a threat in fact I can do much for my country so you know like you do get in pretty deep with some of this stuff and a lot of people end up over their head and you know it's hard to get out so sure but he's 33 which means he was 31 when he was doing this you know I would have a little bit more sympathy if he was

like you know 18 now you know and fair fair fair call no i mean i i see what you mean about this guy right like he's you know he got in over his head got a bit excited and now he's in uh now he's in all sorts of trouble um what else do we have here uh we've got a look at the sim swap that resulted in someone taking control of the official SEC Twitter account and announcing that, you know, Bitcoin ETFs had been approved. Like that was a, that was a very interesting takeover of a Twitter account because I thought it was well executed. And we said that at the time because they didn't post stuff that was just ridiculous. They posted something where the SEC was kind of expected to announce this and they just announced it earlier and they were pre-positioned with a bunch of bitcoin and whatever and um you know the whole purpose was to uh was to to to make money uh they've charged this guy

and uh you know the indictment has details on the sim swap i think the interesting thing here though for me is the recon was obviously good if they had figured out the identity of the person who was authorized to log into that account you know uh created false identity documents and then done the done the sim swap although i think uh in this one dan writes that oh well they must have had the password already uh in order to take over the account but i'm pretty sure you could do it you could at the time do an account reset on Twitter without the password. So I'm not sure if that's what happened.

But anyway, what are your thoughts on this one? Yeah, so this guy, Eric Council Jr., 25, of Athens, Alabama, he is the guy that actually walked into the phone store and did the SIM swap. And there's some interesting details there, like the actual goes into the shop, gets the SIM card, goes to the Apple store, buys the phone, goes and does the crime of the phone, takes the phone back the next day to return it for cash. So, like, you know, that's clearly wasn't making that much money. They could just throw the phone away and to go back to the apple store and get caught on the cameras yet again um so you know there's probably you'd hope there was more money in this kind of crime but apparently not uh and then uh conspirator

undefined was the person that uh instructed him to do it so as you said there must have been some good intel somewhere uh in this process but then uh where the wheels kind of really fell off the sky is that after he had done this process he went back home and started googling to see if he was being investigated by the feds which is not not a great sign google doesn't always have the answers folks you know no and if the if the query is how can i know for sure if i am being investigated by the fbi and uh what are the signs that you are under best under investigation by law enforcement or the fbi even if you have not been contacted by them like that's at that point probably google is not the person you should be asking i would say if you have committed a crime like that it's a strange query

because the fbi are looking at you you know anyway now let's talk about v because it's spelled v e a m software that i previously had not heard about but it's backup software with a absolutely crazy like cvss 9.8 bug in it. And look, enterprise crapware with a high CVSS vulnerability in it, not necessarily news. What makes this one worth talking about is like all of the ransomware crews, like we got, I think Akira are jumping on this, Fin7, a bunch of others.

They're going absolutely wild with this one, Adam. Walk us through what we know. Yeah. So Veeam is pretty common in enterprise environments particularly because um they are quite strongly integrated or used to be quite strongly integrated with vmware so if you had large farms or machines that need to be backed up with machines then vm was one of the common solutions that you would see for that and the bugs in question here are like unorth code exec, you know, code exec against the Veeam agent. The actual bug itself comes down to a kind of interesting

.NET deserialization flaw, and one that they had kind of tried to patch over the years. And it's just really filthy to get those things right. So if you can see this stuff on the network, then straight up onwards to code exec. And the kind of great thing about landing, almost anywhere in a corporate environment, like wherever you get a shell in the DMZ

or on client machines, on servers in the middle of the network, like most stuff gets backed up in these environments. And at that point, you've got a network path and often you've got any other prerequisites. In this case, it was unauth, but if you do need auth creds or certificates or whatever else, usually the backup solution has those. So when I was doing this kind of stuff, we had a few bugs in backup

agents and backup pieces of software. And being able to land in the DMZ and then immediately pivot into the middle of the backups and then restore the domain controller back to your machine or restore your scripts onto some other system or in this case or in this case just tell it to execute whatever code you want yes or in this case you know tell it to exec whatever code because once you land in the backups you've just got everything you need so that's the reason that these kinds of bugs get hit so quickly because a you know a 9.8 cvss captures the the individual bug but it doesn't really explain to you how important these systems are in an enterprise context well i mean it's just you know the irony here is just awful right because one of the reasons you

want comprehensive backups in your environment is so you can restore if you get hit with ransomware and now ransomware crews are using it so it's like you can't win it's a beautiful thing yeah so i mean i mean i guess the advice here is just to to patch but i think everyone needs to really think about the way that they do backups because i think one thing that ransomware showed us is that backup technology certainly a few years ago was like really quite bad it was sort of more of a compliance mandated thing it was sort of something that you were expected to do, but no one ever tested them. You know, we even had one of the people from Kroll

on in one of the sponsor sections talking about that, about how, you know, people will do like one test restore, but like when you're trying to do large scale restoration, it's a whole different thing and people don't drill on it. And, you know, I just think it's one of those areas that I think is often neglected is like thinking about how to appropriately manage backups and yeah, look at the risks that you get out of using this software. Because quite often, even though they're over permissioned and they just, you know, like it's not just code execution flaws, backup solutions can be a problem. Yeah, absolutely right. Because backups historically have been for kind of accidental problems, right?

They're not really designed or they certainly weren't originally designed really to deal with malice. And so dealing with having someone that wants to disrupt your backups over time, in the case of ransomware, that's kind of a use case or a threat model that didn't really exist when a lot of backup solutions were originally designed and then yeah you've got the problems of permissions of storing key material of being able to restore one file as a thing you exercise but being able to restore every box in your network at once or bootstrapping a cold start

you know when everything's been destroyed like there's just so many cases where you know they are difficult to test and time consuming and there's not a lot of reward if you're a sysadmin or an abac engineer or someone else to drilling and exercising your backups other than ticking a box right so a lot of people didn't do it until ransomware came along and all of a sudden you know now we actually have to be really resilient. So, yeah, I mean, yeah, the ransomware period of computer security has brought some improvements in how resilient we are. Oh, 100%, just like LulzSec did for web application security

a million years ago. And it's funny, though, because I remember like a decade plus ago when you were doing a lot of pen testing, you were very much on the tools and you would achieve great victory by targeting enterprise software. I remember you found a whole bunch of bugs and stuff like, you know, various CA agents and whatnot. And you would always say to me, oh, you know, attackers are going to get on this. And, you know, I think correctly at the time I said, eh, you know, not now. Like it's, it's, it's not happening yet. And I think here we are

like 10 years later and it's finally happening that the chickens are coming home to roost for poorly written enterprise software because finding general platform and browser bugs has got a lot harder. And, you know, staying in that vein, we spoke about a bunch of Fortinet vulnerabilities that I think were being exploited in the wild and added to the CISR Kev list last week. It looks like we've got a different set of vulnerabilities, it's hard to really know isn't it uh i think these are different vulnerabilities but there's a bunch of bugs in fortigate and so far fortinet are staying quite mum on the details of the reports which makes you think it's a doozy yeah so there's been um so i think these are related bugs because fortinet there's so many products and so many bugs and in this case one of the bugs we're talking about like it's in the management product that interfaces with a bunch of products uh so like it all gets a bit murky but it's really not helped uh by how badly

fortinet communicates about it like they're very quick to point out issues with other people's products and to kind of distract from them them from their own issues but some of these are pretty nasty looking ones like one of the 40 manager bugs essentially you could take a certificate or you know key material from other fortinet products and then use that to kind of enroll yourself in the manager exploit bugs get code exec if you've got one fortinet product then you're kind of in a position to talk to the manager and go upstream, downstream to other products. So like it's pretty messy looking and yeah,

like Fortinet are just kind of Weasley about how they communicate and their willingness to go kind of distract everybody with sleight of hand from, you know, quite frankly, some really shoddy engineering in their products. Yeah, I mean, this is like a 25-plus year problem, a 30-year-plus problem of vendors doing this sort of stuff. You know, you just would have expected a little bit better in 2024.

But another Beaumont quote in this one where he says, people are quite openly posting what is happening on Reddit now. Threat actors are registering rogue FortiGates into FortiManager, which is the affected product, with host names like localhost and using them to get RCE. So I don't know. I mean, that's not necessarily verified, but, you know, I'll take his word for it.

And it's, you know, just more Fortinet drama. Just an interesting one here. Darina Antoniuk over at The Record has written up a campaign which is targeting Israeli organizations and the attackers are posing as eset and you know using that as their lure and eset has come out and said we haven't been breached and whatever it's just someone using our brand uh this story also includes a kevin beaumont quote yes i think this is ESET had a partner in Israel that seems to be like maybe they got the mailing list compromised

or something like that. And so then the customers were being emailed with the messages looking like they came from the local partner. And then they were like, oh, my God, we're the government, you know, the team that tracks government attackers at ESET. And we've seen some government backed attackers trying to compromise your stuff. But don't worry, we've developed a piece of software

which will help you stop this, and we attach it conveniently to the zip file. And here's the password, and just click through the warnings, okay? Yes, exactly. What was it? The Advanced Threat Defense Program designed to counter advanced targeted threats, which apparently, very generously,

you can install on up to five devices targeted threats, which apparently very generously you could install on up to five devices. So, yeah. Yeah, I just think as far as lures go, that's a pretty good one. I mean, it's not bad, especially if you can send it from a place that they might be expecting to get communication. So, you know.

Yeah. I guess, like, nice try, you know. Now, I probably massacred Doreen's name there. I think it's Antoniuk, by the way. Sorry about that. I am sick. I'm doing the best I can. Also, we also introduce Jonathan Greig because his last name is spelled G-R-E-I-G.

I realised recently that Americans would probably pronounce that Greg, wouldn't they? It's a good question. Let us know, Jonathan. Yeah, let us know. Anyway, we're going to finish with a story from John Greig or John Greig, whichever you prefer. I'm sure he will advise.

You know, the North Korean fake IT workers thing has been a big issue over 2024. You know, we've seen a number of arrests for people running essentially proxy farms in their basements and whatever in the United States. What a world. Yeah, it's been delightful to cover, really. It's fun stuff.

But now it looks like there is some evidence that some of these North Korean IT workers, when they are discovered and fired, they're now threatening to release data that they've collected and they're demanding ransoms, which I, you know, we shouldn't be surprised that this is happening. But as far as I know, this is a recent development. Yeah, it's weird that it's a recent development because it seems like a pretty logical thing to do. Once you're an insider, you have a whole bunch of interesting access.

It saves you the initial compromise part of the process. So why not steal a bunch of data and then try and find some value in it, be it intellectual property, be it ransoming it back to them, you know, be it just passing it on to other people who are looking for, you know, reconnaissance information or selling it in that way. So, like, there's so many ways to monetize access to people. And the North Koreans are pretty good at, you know, innovating crime. So, I mean, they really do roll just like a really well-funded, well-organized criminal organization at this point, right? Yeah.

That's what they do. And they've got just so many human resources. They've got so many skilled operators. I mean, the mind boggles. Yeah, exactly. I suppose we've been saying so many nice things about North Koreans. It's a North Korean hacking fan club episode of risky biz yeah I think we're praising them as just being really effective criminals so

I don't know if that's like praise I don't know we got a game is game right yes exactly exactly and certainly like in the case of hijacking ATM payments which is like game recognizes game there so good job looks good that's right alright we're gonna wrap it up there, Adam. Thank you so much for joining us to talk through the week's news. A pleasure as always. And we'll do it all again next week.

Yeah. Thanks very much, Pat. Hopefully you'll feel better by then. And we'll do it all over again. That was Adam Barlow there with a look at the week's security news. Big thanks to him for that. And we're going to finish this week's show with our sponsor interview now,

and it's with Ryan Cullinber, who's the chief security, I'm sorry, chief strategy officer for Proofpoint. And yeah, we're going to be talking about Sock Ghoulish because this is a large widespread sort of malware campaign. And it's, you know, at the top of all of the charts at Proofpoint at the moment and they're doing some really interesting things with evasion and trying to evade detection. So Ryan join me to talk about all of that. So here he is first of all just talking a bit about SockGolish. Enjoy. So it's something we've tracked for a very long time but it's been on the top of our

data sets for months and months and months now. If you look at kind of a post-emotech, post-major broad email campaign landscape, it's very, very hard to get around basically this combination of compromised legitimate websites, fake browser updates, which is the social engineering, and actually a malvertising angle, which makes it a lot less detectable than a lot of the other malware families we look at that come across in targeted attacks that have the same sort of sandbox evasion techniques that look and feel like phishing campaigns, because it is fundamentally structured differently. And maybe most perniciously of all, because of the way it works, they don't really have to serve up

the payload to everyone who visits the compromised website. They can look at cookies that are there in the browser, they can look at other aspects of the user agent and be extremely selective, which gives us not only a detection problem, but a perception that some of these are false positives when really that website remains compromised. Yeah. I mean, I've been chatting with some others recently about how, you know, fish kits as well are doing a lot of evasion these days. I mean, we've always seen them do evasion, but now they're getting good at doing evasion which i think is is one of the issues here so i mean that's less of an issue i think for security companies that are making products that are present on the host right because that's where you're in a really good position to actually detect the payload or the page or the whatever once it actually arrives at

the uh at the host but if you're trying to detect and block this at scale, I mean, what do you do, right? What is your response to this sort of challenge? You know, conveniently, there's a reason we announced a browser extension that has these features just this month, actually, because you're absolutely right. It is much easier to solve this if you see what the user sees. But ultimately, one of the things that I think is an interesting detection challenge is if you do have traditional forms of sandboxing, meaning you can take that URL and load it and manipulate the sandbox in various different ways, you will get it to serve the payload if you have smart enough people operating that sandboxing

infrastructure. On the other hand, there have been a lot of kind of modern solutions trying to solve this at scale with pure, say, behavioral AI, where they're just looking at the pattern of the email sending. And again, you're not going to see anything unusual there because the email in some of these campaigns is something like the Google alert for Chrome is what ends up delivering the malicious URL. There's nothing unusual about that. There's absolutely nothing to find no matter how smart your analysis of that communication pattern is. So it just goes back to good old fashioned URL sandboxing in terms of how we detected its scale. But you're absolutely right. The other way to skin this particular cat is to be in the browser and see the fake browser update that gets served up to the user

because their machine meets the criteria and the traffic distribution system chooses them as one of the unlucky ones. Yeah, it's interesting that you've gone for the browser extension as well. I feel like it's an acknowledgement that the sandboxing stuff ain't gonna stay that reliable, right? Like, I mean right like i mean would you would you because you're kind of saying both right you're saying oh no if you know what you're doing you can totally get it get it to load in a sandbox but we've also released a browser extension like if it is the case that you can do all of this with the sandbox why bother with the extension it's a good question i think the sandbox still works really well at scale. And when you talk about a solid goalish campaign, you're going to see this operate very, very much at scale. have the same social engineering uh zphp uh and they're all basically copycats because the

approach is working so well that a scale campaign like that with the proper detection you're gonna catch it with a sandbox at least somewhere right you'll catch it at least somewhere but not everyone again will see it but you're you're absolutely right that at some point the cat and mouse uh game that is evasion that happens on the Fishkit side and happens on the Malware side, has frankly a longer history on the Malware side, means it actually is great if you can just see what the user sees and be right there with them.

So that no matter what the redirects look like, no matter how bizarre the infection chain, you're always there when the payload arrives. So to keep the noise out of the system and to keep the volumes down that ever get to end users, I still think sandboxing plays an incredibly important role. But you're right. I should be shrugging and saying, why not books, right? Because we're used to defense in depth for lots of things. And because this is literally the number one malware family we see dropped, it's a really obvious thing to have defense in depth for.

Yeah. I mean, I'm a big fan of like actually instrumenting browsers, as you know, because I know you're a regular listener of the show. The thing that surprises me is that, you know, for all of the acquisitions they're doing, you know, the most cashed up organizations in the security industry are the EDR companies, and they've just totally slept on this. I mean, you know, the most cashed up organizations in the security industry are the EDR companies, and they've just totally slept on this. I mean, that, honestly, it really surprises me that they're going off and buying companies that do PAM modules and doing, you know, log analysis and doing this and doing and vulnerability scanning. And, you know, they already have a presence on the host. And yet they're not doing this. What are they thinking? It's a great question. I mean, the whole landscape has pivoted to URLs. And at the same time,

all of these chickens are coming home to roost around end-to-end encryption and lots of other kind of trends where I do see some cybersecurity organizations that have managed to pull off the always-on VPN for most of their users, where they are literally on the network most of the time, and they can do some interesting things there. But everybody else

gave up that fight long, long, long ago. So when it comes to a threat like this one, that is going to be particularly irksome, because it's not showing up for everybody, you know, it does make sense to not build something into the network side but to build something that can follow the user around uh edrs will obviously see when uh say well they'll see the payload right they're going to see the malware but but you know what what happened to trying to detect early right detect and block early it just i'm just again it just boggles my mind i just wonder like why there's no one working in strategy at these companies that says, gee, you know, we're already on the host.

This would be a good, you know, thing for us to do. But anyway, you know, we didn't spin up this interview to talk about CrowdStrike or, you know, any of the others, right? But it just, yeah, I do find it surprising. I mean, just given how much malware has pivoted to URL-based delivery, you know, independent of how you get the URL in front of the person. Exactly. Like what if, as you've always said,

what if it comes in via LinkedIn or whatever, right? Teams. Well, again, that's a great reason. And that's in fact the first use case that we shipped for that browser extension, right? Making sure that you could get that malicious URL if it came in via any of those platforms. Because interestingly enough,

as we've looked at the data sets here, malvertising is something that Google has a whole team that is working on. And then obviously they don't want actors buying ads or doing other things to distribute these same payloads, which happens pretty frequently. The Mandiant team actually did some really nice work around some of these campaigns in particular, the ones linked to DarkAid and Danabot. But at the same time, there are so many ways to get a URL in front of a user. And we just keep seeing those things proliferate and get creative. So right now, I think the attackers

are trying to torture us by only showing up that payload in a very small fraction of cases, which means some of our users actually report that as false positives, when we know actually that that website is more than capable of sending them the first stage of something that's eventually going to end up in Ransomhub. And so that is something that for them is a workable technique, and it's a lot different than classic phishing. And to your point your point architecturally there's no reason that we have to stay chained to the models of the past it works just as well

to be in the browser as it as it does to work out of email telemetry here so what sort of websites are we talking about here that might selectively drop the malware like what what are these websites that some users are like no that's a false. And we really want to be able to access this website. Are they, are they compromised forum pages or things like that, where the attackers managed to get some, some, you know, some sort of, you know, PHP or JS or something into that, you know, into that website that can do selective, you know, dropping of nasty stuff. Yeah, that is definitely a part of kind of the typical MO. Maybe I'll just talk through a simple example. But yeah, you're right that the original compromises a legitimate website that has malicious JavaScript injected a really good percentage of the time. One of these campaigns

that was a soft goalish one we track is ThreatActor569 recently, you know, a thousand plus of our customers saw that, a couple hundred thousand malicious messages, went through all 14 other tools that we actually look at to see if any of them detected it. And just one single organization actually based in Texas got a huge number of these. The email itself basically promoted a healthcare conference. Again, the email is completely legitimate. It's written by that organization and not the threat actor, much less something like AI. And the URL link was, again, to a real webpage that happened to be compromised.

So what happens is you get that email that, again, the user is expecting, and some percentage of the users that click on that end up basically getting served up the classic kind of fake update notification, which is the social engineering that frankly shouldn't still work in 2024, but amazingly still does. What are the criteria that the attackers are using to make that determination as to whether or not to serve the payload? I'm curious about that. Yeah, it's a really good question. Some of it does move around quite a bit. And some of it seems to, on the malvertising side, link to who they're targeting to begin with. So if you're looking at ad targeting, it's, of course, incredibly powerful.

You can target geos, IP ranges, or even things about organizations that, you know, obviously anyone who's in marketing buying Google ads takes advantage of. If you look at kind of just the malware itself and what it's technically looking at, usually based on the browser cookies, other kind of system information and other things around the user agent. And then they, of course, use TDSs, some of which are completely legitimate, I should say traffic distribution systems, to basically serve up the payload some percentage of the time.

And it's different for every campaign. Yeah, wow. I remember years ago, this is just an aside, someone figured out that they could create a Facebook advertising target group, which was just their roommate. And you remember this? They ran a whole like psychological warfare campaign on their roommate. It was absolutely hilarious and resulted in Facebook actually making some changes. So you couldn't do targeting that granular, right? Because it was... Yeah, exactly. And talk about targeted threats all the time. And interestingly,

it is a good question to ask whether some of these are targeted or not. It's very hard to tell in a way that's not usual for us. And this is the thing. Maybe they're doing, they're putting some sort of conditions, you know, on whether or not it's served because it's, again, it's a way to evade a sandbox. Absolutely. And that's the one thing I think that also gets really interesting here, because there

are clear links between the malvertising actors, the ones who compromise these websites, and the actors that we see in email. Overlaps with Datamot being a really good example. So I think it's just that same group of, it might not even be that many people that are responsible for this aspect of the ecosystem, particularly the ransomware ecosystem, that have now figured out that this is much more irritating for security vendors

taking part of the traditional approaches to detection than other things that they do and have done in the past. Yeah, so SockGolish, again, that's basically a first stage payload, right? Like it's a loader and then it can be used for ransomware, data theft, whatever. Exactly. And I think the part that's interesting is that you look at which one of your security vendors is supposed to catch stuff like this. To your point earlier, the EDR is waiting until a

payload drops because again, it comes in URL form, but half the time there's an email behind it, which is how people encounter URLs that are novel most of the time. But the email, again, could be a newsletter that that person signed up for pointing to the URL for a conference that they plan to attend. And that's what makes this so tricky, that the attacker didn't have to do any of that targeting in order to make something that's so convincing. And the social engineering that is the sort of thing you'd hope a user would recognize doesn't show up until the fake browser update, which is one of the most reliable common elements of these sorts of campaigns.

Yeah, well, I mean, you know, as you said, defense in depth, right? You've got to have your email stuff detecting this stuff at scale. You've got to have something in the browser to detect funny stuff. You've got to have something on the host to detect code execution and weird stuff, exploitation, whatever. Yeah. I mean, it's an old saying, but it's true. You need to do defense in depth. Ryan Callenbaugh, thanks a lot for joining us to talk about sec goal is it sec goalish or sec ghoulish i i everyone sock ghoulish uh yeah ghoulish it should be sock ghoulish you know ghouls ghosts it really should be uh but yeah no it's always a pleasure i think the thing

that is really interesting i think here is what we look at actors doing when there's not an easy vulnerability going around where they can pop a ton of boxes, like just how they keep the lights on. It really does seem to have pivoted. And it's a threat landscape that has been the same for so long talking about BEC, ransomware and assorted APTs that this genuinely does represent a meaningful change. And I think everyone would do well to pay attention to it. All right. Well, again, thank you very much for joining us. It's always a pleasure to chat to you.

Cheers, Pat. That was Ryan Callenberg there from Proofpoint. Big thanks to him for that. And big thanks to Proofpoint for being a long-term sponsor of the Risky Business Podcast. That is it from us this week. Excuse me. I am going to go and try to recover from my illness,

but I'll be back soon with more risky business for you all. Until then, I've been Patrick Gray. Thanks for listening.