Risky Business - Risky Business #720 -- How cloud identity provider federation features can get you mega-owned

Episode Date: September 5, 2023

On this week’s show Patrick Gray and Adam Boileau discuss the week’s security news. They cover: Why everyone should pay attention to some recent attacks on Okta customers Why third party comms apps are risky af Why are Russian espionage opps using Tor for C2? Surveillance firms abuse Fiji Telco Digicel’s SS7 access Much, much more! This week’s show is brought to you by Gigamon. Mark Jow, Gigamon’s EMEA Technical Director is this week’s sponsor guest. Links to everything that we discussed are below and you can follow Patrick or Adam on Mastodon if that’s your thing. Show notes Cross-Tenant Impersonation: Prevention and Detection | Okta Security BadBazaar espionage tool targets Android users via trojanized Signal and Telegram apps NCSC-MAR-Infamous-Chisel.pdf Ukraine says an energy facility disrupted a Fancy Bear intrusion Experts Fear Crooks are Cracking Keys Stolen in LastPass Breach – Krebs on Security Telstra-owned Pacific mobile network likely exploited by spies for hire - ABC News CISA, MITRE shore up operational tech networks with adversary emulation platform LogicMonitor customers hit by hackers, because of default passwords | TechCrunch Barracuda thought it drove 0-day hackers out of customers’ networks. It was wrong. | Ars Technica Why is .US Being Used to Phish So Many of Us? – Krebs on Security UK cyber agency announces Ollie Whitehouse as its first ever CTO Embattled consulting firm PwC swept up in global cyber breach of file service MOVEit by cybercrime group C10p ONLINE-SCAM-OPERATIONS-2582023.pdf Unmasking Trickbot, One of the World’s Top Cybercrime Gangs | WIRED

Hi everyone and welcome to Risky Business. My name's Patrick Gray. This week's show is brought to you by Gigamon and Gigamon's Mark Jowell will be along in this week's sponsored review to talk about how Gigamon is positioning itself as a data source for security teams and products. of the network security market. It seems to be breaking down into companies that do collection and other companies that do the analysis part on the collected data. So that is interesting stuff, and it is coming up after this week's news with Adam Boileau. And Adam, we have like one of the shortest run sheets in recent memory this week, thanks to a long weekend in the United States and just not all that much happening.

But we've got some really, really good, interesting stuff to get through this week as well. So I'm kind of glad we're going to have time to talk through these things in detail. And the first thing I want to talk about is a blog post from Okta that has announced that some of its customers have been owned in an interesting way. And yeah, look, let's just start with that. What exactly is Okta telling us all here? So a campaign went across some of their customers that was seeking to compromise the super admin account

of their Okta tenancy. So many big customers use Okta for auth. And this was a case where someone had either gained access to passwords or had some other mechanism of understanding the layout of these customers and then they social engineered the customer's in-house IT team to password reset like the multi-factor auth token for the super admin user inside the Okta tenancy so at that point they've got full control of the Okta and you you could imagine that they can, you know,

change some MFA settings, remove MFA and so on and so forth, which like so far kind of so ordinary. Well, I mean, yes, except should your help desk really be resetting MFA for the super admin account? And the answer to that is no. No, it should not be able to do that. They should not be able to do that they should not be able to do that or at least it should raise some alarm bells when they do yeah um and so like

yeah that part interesting but kind of normal i suppose uh where it gets really interesting though is the post-intrusion activity in octa where the attackers get into the octa control panel made a bunch of changes but one of the things they did for long-term persistence stood out as quite novel and really interesting. Well, and what you're talking about there is they basically added an external identity provider into the Okta config, which could then be used to authenticate any user, right?

Like once you've set that up, it's game over. Now you did just say, okay, it's normal. They got super admin, they can reset MFA, but the super admin account, and I'd confirmed this, the super admin account in Okta, you cannot use it to masquerade as another user. So it's all well and good having super admin access, but if you want to, you know, access a target user's mailbox or whatever, you would need to use that power to reset their creds. And that is going to set off alarm bells. When a user comes in and can't actually log in because their creds have been reset,

that's the sort of thing people are going to notice. Whereas if you tell Okta, hey, we're spinning up an external identity trust source and adding it to the configuration and anyone that this IDP says is authenticated is authenticated, guess what? You can then masquerade as any user without setting off any alarm bells. And that's, you know, you're not going to see failed login attempts in your logs.

You're not going to see a bunch of MFA and cred resets, right? It's not the sort of thing you're going to detect unless you're looking for it exactly and that's what makes it such a smooth uh you know post-compromise activity either for long-term backdoor or for accessing stuff where you know the sensitive monitoring or users that are going to be aware if their regular access stops working or like if you've got push-based mfa or something like they're going to spot weird pushes. So having this kind of capability, a backdoor in the auth system itself, is just super powerful.

And it's not a thing I think we have seen people do with Okta, but... So that's the thing. This is a conversation we've had before a couple of years ago because the attackers in the SolarWinds case, in the SolarWinds campaign, they did exactly the same thing to Azure, right? They did exactly the same thing. And this is information that seems to have fallen out of people's heads

because when I mentioned it to you, you were like, oh, what do you mean? No, they did the ADFS thing. And that's true, right? So they got in on-prem, went through ADFS and went up into the cloud that way. And that's the part everyone remembers. But what people seem to have forgotten, and it wasn't just you, I've spoken to a bunch of people about this. They all seem to have forgotten that this was the ultimate victory for the SolarWinds crew as well well which was adding another identity provider to the

Azure config so this is officially like the I'm calling it the equivalent of like domain admin victory for cloud right is when you can actually add an external IDP and federate it into the to your primary IDP yeah and I think you're absolutely right like this is a you know once you pointed this out to me and i started thinking about like it makes a whole bunch of sense we've done similar sorts of things with kerberos trusts adding new uh you know inbound trusts in there or like i've backdoored radius servers in people's environments to allow backdoor access in the future um so it makes sense to get into the auth system into the trust root into a place where you can validate and create auth tokens without needing key material or without needing your user passwords

or resetting or anything like that so it totally makes sense and it's a great reminder for everybody that you know with federated auth comes great power yeah yeah i mean and that's what we said two years ago we said like you really want to make it hard. And you know, I was saying that back then that the providers need to make it really, really hard for you to actually enable this. And maybe that should involve a phone call or something. But I mean, there is stuff you can do, okay, short of having to present your super admin to an Okta office for dna sequencing before they can make this change so there's a bunch of good advice in the uh in the octa blog post i mean the primary um you know the primary advice i think is don't let your help desk reset the super admin

password but then it comes down to like and i spoke about this with brett winifred of course who is at octa and a former colleague of ours and i spoke to him about it and i'm like well maybe you just need another super admin account that is only used to reset the mfa on the primary super admin account and it's it's kind of dumb but it'll work because otherwise otherwise who where is that reset gonna fall back to octa's help desk and i think brett's response to that was oh god please no um so you know i mean i think people need to think about like that's the first thing they need to think about is is what are the processes for resetting mfa on super admin accounts because you can't let your help desk handle that that's just insane yeah like it's too much of a trust

anchor and it needs you know pretty robust controls around it. And, you know, Okta, I'm sure there's some mechanisms that they've been talking about that could help facilitate that. But as you say, like requiring the super admin to physically show up and present ID, you know. Present DNA, buddy. DNA sequencing. Yeah, yeah, is perhaps not practical. And a 50-page questionnaire.

Yeah, but at the very least, you know, strong alerting so that you can spot it happening in ideally real time and go hey we didn't do this but you know this is a degree of you know this requires a degree of understanding of cloud governance that probably isn't super common and clearly should be but this stuff is complicated and is new and is kind of evolving. Like if you set up Okta 10 years ago, whoever old Okta is now, you know, thinking back and thinking about all the things you have to worry about now when you built it, it's kind of similar to how AD, you know, became a trash fire because it's complicated and it lasted a long time and a lot of stuff in the world changed around it.

And, you know, clearly Okta has some, you know, they could make this easier to spot for their customers. Well, and I'm sure they probably will. I'm sure they will, right? I mean, I think also, first of all, I should mention that historically Okta had been a sponsor of this show. They didn't sponsor anything this year, but they are coming back next year.

So just a disclaimer there that they are soon to be a sponsor again. And I think they deserve a pat on the back for actually publishing this blog post because a lot of organizations would just sweep this under the rug right so i think it's really good that they're raising awareness on this and this isn't this is an abuse of you know legit functionality right so this isn't a weakness in their system per se, but, and they're publishing good advice on here, but yeah, you know, you say, right, that this is something that requires a big detailed knowledge of cloud info and whatever. I don't see it that way. I see this as a fairly fundamental thing that you use cloud IDPs to do, which is to do

federation, right? Federated identity. So so it's it's a pretty fundamental simple thing that attackers are abusing and it's i just don't think it's as novel as people think it is because we have seen it before and i bet there's a lot more of this happening than we realize yeah i mean i think you know auth systems in general are complicated we've seen the same kind of class for attack against other distributed auth systems but i you know the terminology and the complexity of federated auth i think just scares a lot of people because you know it's it does require structured thinking i guess about how auth works and who you trust and how those trust systems work and you know the threads that you uh dug up out of the like octa support forums

oh that was funny yeah so let me let me just tell that tell that story because i i seriously was just googling around going because i was thinking they have to be doing this so that they don't have to reset people's creds but surely as super admin you could masquerade right so i googled around on that and i found some post from like 2017 in some octa forum where someone's like you know can i um log in as other users using super admin? And the Okta person answered in the thread and said, no, as a security measure, you can't do that because that would be pretty bad

if that account got compromised, blah, blah, blah. And then some other Okta user just replied and like, oh, you could probably plumb something through with like SAML and as a federated ID or something. Like pretty much hit the nail on the head of how you would then go about doing this, right? Yeah, which is kind of funny because, you know, that's a, you know, knowing what terms to Google,

like to find that particular thread and to understand what's going on like that. I guess that's what I mean. Like there's a bunch of back knowledge that you would need. But once you get there and you're thinking about it, right, then yeah, of course it kind of makes sense that you'd be able to do this. And Okta in their blog post describes a couple of circumstances where this

kind of inbound trust is really useful so yeah in mergers and acquisitions for example or other big integration projects so like all of the pieces of the puzzle make sense but i guess they're being combined in a way that only you and the people who've been doing the hack and remember it i mean it is it is funny, right? Because as I say, it is just something that sort of fell out of people's heads a bit. And, you know, the thing that we said last time, the place that we arrived,

was that you need really strict controls around adding new IDPs and federating other external IDPs and trusting them. So you need really strong controls to prevent that from happening. And you need really strong detections for figuring out when that has happened. So I think this is something where it's kind of worth people going away and taking a look at. Because if this happens to you, that's very bad. Yeah, as you say, it's ultimate victory against anything cloud auth and these

days we are building systems where there is one way to do auth everywhere and if you compromise that one way you get everything all at once everywhere but see that's the thing the idps have kind of built some protections in so even if you're super admin you can't do all of the stuff that you can do with an externally trusted idp it's just such a great example of attackers saying oh i can't masquerade as any user oh well i'll just do this instead yes yeah it's good it's good work you know solid it's like be the water that flows around the stone in the river kind of thing right exactly exactly yeah well uh people could check out the octa blog post in this week's uh show notes and i'd recommend they

do and let's see you know they they are the first to talk about this particular campaign you know let's see if anything shakes out of the others like microsoft or whatever yeah yeah and i think you know the same logical components exist in every other auth system so i'm sure we'll see people doing similar things in the others well i mean it was microsoft in the case of solarWinds, but I mean specifically this campaign. Like, let's see if anything else shakes out on this one. Now we're going to have a chat about some malware, Adam.

And ESET has a write-up on the Bad Bazaar Espionage tool. And, like, this one's hit the headlines over the last few days, so people have probably seen this one already. But what looks to be a chinese espionage crew created like fake third-party uh apps for signal and telegram i mean i guess they were real third-party apps for signal and telegram but with the added benefit to the people who wrote them of being able to uh in the case of the signal signal plus which they created that links someone's Signal account

through the account linking feature that you use to use Signal on desktop or your iPad or whatever. It uses that functionality to sort of carbon copy everyone's Signal messages. And the Telegram one does something funky with backups, I think, to be able to access Telegram message content and stuff.

And these apps were advertised on forums popular with Uyghur Muslims and so you know we can only guess what this stuff was was being used for but this is interesting because the the bad apps managed to get into the play store and into the like Samsung app store as well I think the telegram one it's it's kind of a historical thing. Like I think that one wrapped up a couple of years ago, but like thousands of people downloaded and installed it. The Signal one looks like it was less successful. But what I find interesting about this is it would be very hard to stamp out this type of campaign completely because you would need to ban all

third-party apps for tools like signal and telegram yeah i mean the amount of control that would have to be exerted by the app stores to filter this stuff out uh you know seems implausible in the case of play uh and then you know there's always going to be especially in the community where getting access to those tools is already complicated so in the case of Uyghur Muslims like maybe they can't just go and get regular mainline signal they're trying to China has historically used this sort of thing to target the Uyghur diaspora right so Uyghur is based outside of territory they control so I think that's more what this is for rather than targeting

people in China yeah but I guess like that community is used to having to distribute apps in non-normal, non-standard ways, I guess is what I meant, both inside and out. And so the Signal Plus one had an extra feature, like it will use proxies to automatically connect and stuff that kind of appeal to those communities where they're already being oppressed to some degree. The use of the signal linking

functionality i think is pretty novel i don't know that we've seen that uh abused in this way before because it's a transparent like you install this app and then it behind the scenes will do that linking process yeah to get copies of your messages and so that's kind of interesting and novel and i think he said pulled apart like the exact mechanism by which that worked and wrote it up on their blog um but yeah it's a i mean it's a it's an approach to targeting those communities that has been unfortunately effective and as you say kind of hard to stop as well yeah and i think the the fact that they were actually advertising and promoting it you know this is how you can get people to use an obscure third-party app that's you know buried in in some app store.

You go and spend some money and you promote it, right? And you're going to get results. Yeah. I mean, the numbers on the Signalize, they were not great. There was like a couple of hundred installs, I think, but the Telegram one was thousands. Yeah. So clearly it was working for them.

Yeah, yeah. It is interesting. And you just sort of think, how do you how do you stop that and you know my initial reaction was oh you know lazy work by these app stores and i'm thinking well having to do such complete analysis of these apps you know to see i mean a third-party app is always going to look suspicious really confirming that one is good is is going to be very it's going to be a lot of work that's what i'm getting i mean the the signal one like if a human looked at it like to my eye it looked obviously dodge like the the logo looked crappy

and the slogan was crappy but i just know that's english speak you know a native english speaker eyeballing something that i'm already primed primed to think is sus versus you know automated assessment by Google Play's you know kind of gatekeeping process whatever it is yeah like these are hard problems to solve yeah I mean we haven't seen an example on the iOS store but I'm guessing the targeted population is Android heavy anyway right so yeah yeah exactly I mean I'm sure people have tried to get fake signal apps into the Apple App Store and hopefully failed. But yeah, this is a hard problem, even with Apple's slightly more aggressive approach to policing it.

Now, staying with Android malware, we've got a report out from the Five Eyes agencies about a bit of Russian malware that is targeting Android phones that they are calling Infamous Chisel. Yes, this is the one that targeted Android tablets being used by Ukrainian military personnel in the field. And it's, you know, kind of fairly... So this is the one that I spoke about with Ilya Vityuk.

Yes. Yeah, okay. So this is the one with the debugger on 5555 or whatever. Yes, for initial entry vector, yes. And then we'll keep an eye on the you know starlink terminals nearby uh as well as you know stealing data from messengers and whatever else uh the five wise write-up has a bunch of details for you know iocs and details of how it worked um there's a couple of interesting bits in there one is the use of tor for c2 which i

suppose is pretty common russiancraft, but you would think Tor traffic coming in over the cell network from military tablets would be a thing that Ilya and friends would be on the lookout for, so a bit of a tell there. And then there's some specific targeting of Ukrainian military apps as well, in terms of the data collected, etc., which is kind of what you'd expect from the GRU targeting Ukrainian military apps as well. Yeah. In terms of the data collected, et cetera, which is kind of what you'd expect from the GRU targeting Ukrainian military. Yep. Yep. So people, I've linked through to the report.

People can read that one. But, you know, you just mentioned the tour thing, and you and I both went down this rabbit hole a little bit today when preparing the show because there's a, Darina Antoniuk over at The Record has written up a fancy bear attempt to disrupt a critical energy facility in Ukraine. What's interesting here, two things jumped out at me about this.

First of all, was the use of Tor for C2, right? And we'll talk about that more in a little bit. The second thing that jumped out to me is like, what year is this? Because the way they were trying to spread this malware was with like a zip attachment and a body in an email saying hey check out all of these nude girls you know in this zip file and then you open it and one of the files is i'm not kidding it's a dot bat so they're using using windows batch files uh to drop malware and you know normally we say

it's not dumb if it works like even if this works it's still dumb and i don't like it because it's just i feel like i'm in a time warp i did like though that the email lure uh whilst being old school in its mechanism uh did say that the girls in question consented to having their pictures shared so that's quite a nice modern development. Well, I think that's progress, at least on some level, right? Where we have an expectation that that should be mentioned. So that's good. Good job, Marshall.

Very progressive of you. But do we have any idea if this campaign was at all successful, Adam? It sounds like it was successful at getting some initial initial execution but it seems to have been snapped pretty quickly by uh the employee in question so they figured that something weird was going on escalated it and then it was contained so it looks like you know near miss uh for the ukrainian energy people in question but still kind of funny that uh that it did work to a certain degree as i mentioned you know you and i started had a big conversation before we got recording about you know russians using tor and it seems like this is as you say something that they are regularly

employing in their trade craft these days and you do kind of wonder why, because Tor is the sort of thing that tends to stand out on the wire, and Ukraine is in an existential war, which means they're going to have the authorities they require to be able to monitor network traffic and look for stuff like this. Why is it you think Russians are using Tor for command and control when correlating, you know, when spotting Tor traffic is easy. And, you know, I'm guessing quite rare, you know, Tor traffic is not that common. Yeah, so we had that conversation

and I guess I came away from it thinking that, yes, whilst Tor does stand out on a network, like direct Russian C2, like straight to the C2 point, probably stands out more. And there is enough doubt in tour traffic that you'd have to go investigate, I guess. Something weird is happening, we don't know what,

versus seeing full-on bare C2 over the internet. That's a definite sign of compromise. So maybe there's enough tour traffic sloshing around in Ukraine that it's not as strong an indicator as the alternative, which is straight up bare C2 over the internet. And the other options for like domain fronting or hiding inside regular apps are either complicated or problematic.

Well, I would think if I was operating a CDN, I would have a rule, a detection rule that just said, because CDNs can detect domain fronting, right? Yes. You can't when it's leaving your network, but the CDNs can. And I would think a rule that says any domain fronting activity in the geographical area of Ukraine should be treated

as highly suspect and flagged for review, you know, would bear fruit. So I can understand why they wouldn't want to go the CDN route with domain fronting at least. The naked C2, I get that as well but it just i don't know it just seems like this is such an opportunity for the ukrainians in particular just monitoring for tor is going to give you such a good starting point to to spot this c2 and i'm guessing the traffic is going to be quite different from uh browsing traffic as well because i mean I mean, I think in the previous case, the Android one, it spins up a hidden service and then binds SSH to it.

And that's going to look real funky on the wire. Yeah. I mean, I guess it may just be that this is the least worst option they've got. There's no good options for doing C2 on Ukrainian monitored networks. And at least Tor adds enough doubt and maybe enough time delay. Like if you have to spin up a human to go look at it, like maybe that buys you an hour or two or, you know, five or whatever.

Like maybe it's enough. I don't know how long that's going to last though. I don't know. And look, if I'm Ukraine at this point, I'm pretty much just going to drop all Tor entry exit at core. Like, that's what I'm doing. Yeah, that seems like the smart move. But maybe there's other complexities.

I think, you know, if it was my op and you have to go, like, what's the least worst option we've got? Maybe Tor is it. Yeah, maybe, maybe. All right. Now we've got a late breaking story from Brian Krebs. He actually texted me just before we were recording to make sure we got this in, and I'm glad he did because it's a cracker of a story, a real long write-up too.

What he's done is he's managed to put forward a very strong but circumstantial case that suggests the people behind the last pass breach are indeed going after crypto assets. So what looks like is happening is a bunch of crypto is being stolen. Like we're looking at about $35 million worth of crypto assets stolen from people who a lot of them were LastPass users and had stored their seed phrases in their LastPass vaults. And now those vaults are apparently being offline cracked and attackers are running away with the money i mean it is circumstantial but you read through this and

it is pretty compelling yeah it is pretty compelling there's uh some people on you know on twitter x uh that have been investigating a bunch of these thefts and trying to correlate like how they happen there's been a few cases where people's wallets have just been emptied with no other apparent reason. And these are people that are otherwise security conscious or members of the bit like have been in the Bitcoin scene for a while and kind of understand what to do. And through interviews with some of the people who've had their money stolen, there's a

reasonable suggestion that there's a people who had stored their seed phrase in LastPass, perhaps had a LastPass master key that was in fact crackable given enough time. And then all of a sudden, you know, their money is gone without any other indicators like having their phone SIM swapped or other things that you would normally see in common cryptocurrency theft techniques. And it does come across pretty compelling because there's such a broad um set of kind of victimology i suppose like there's this is one of the common factors that ties together a bunch of otherwise unexplained thefts like one of the victims for example is an employee of chainalysis right who understands presumably a little bit about cryptocurrency and blockchain and how to you know not have their money stolen but I think stealing stealing money from a blockchain investigator is like you know a recipe for a bad time but let's see yeah like I feel like

whoever is doing this you know is being pretty bold with their targeting but hey maybe they don't know whose money they're stealing even so anyway it's interesting because you know we hadn't really seen much in the way of fallout from last pass you know other than like reputational to them um but in terms of actual victims and actual impact we hadn't seen much uh and you know there was a lot of speculation at the time about other non-password things that people stored in their LastPass vaults, like, you know, Wi-Fi creds or whatever else. But, you know, seed phrases for crypto wallets is a pretty natural target. And, you know, whoever is doing this is making good money out of it. So clearly it was a good scheme.

Yeah. And of course, you know, this breach at LastPass involved the attackers exploiting a bug in plex uh at an engineer's home network but it looks like you know once this money starts moving around we might even find out who is behind this after all well yeah someone's making big money out of it so i imagine and like as you say if you're going to go after people who work in blockchain currency tracing yeah i think there's going to be a few eyes on on those coins and yeah you And if you're the person behind this, you may want to think twice about how good your laundering is going to be to get this stuff out. Because, yeah, you are the dog that caught the car. Yes, pretty much. Now, let's talk about what's going on in Fiji.

Fiji, a wonderful, beautiful country quite close to Australia and New Zealand. Its telco, its cell network provider, Digicel, has apparently been used by a, or is being used by a bunch of surveillance companies as an entry point into the global SS7 network. And this is, you know, a problem for Telstra, which is Australia's sort of formerly state-owned incumbent telecommunications provider, because it bought Digicel, its acquisition closed last year, and it bought Digicel with $1.9 billion in financing assistance from the Australian government, right? Because Fiji, very close to Australia, China, etc., etc., blah, blah, blah.

That's a whole other story. But Adam, walk us through the story here. Yeah, so some analysis from Citizen Lab has been looking at requests made into the SS7 network to locate individual subscribers. So if you're on the network, you can query the kind of global network about where a phone is to facilitate things like roaming and message delivery. And to do that, you have to be on the ss7 network and telcos some telcos will lease you that access so you have to have what's called a global title you don't necessarily have to use them through

their network but in some cases it looks like the queries were not originating from digicel even though they were using digicel associated global title addresses. There's also the option that you can just bust into Telco and help yourself use their network and their services and their addresses without necessarily having their cooperation. Both are quite feasible. We're not sure which it is in this case. Well, that's the thing.

Like, we don't really know, do we, whether or not this is a case of bad governance corruption bad business practices or bad security like we just know that this is a problem we don't really know what is causing it yeah so i think telstra had said that they had shut down a number of global title leases that were either sus or you know the business bits of it didn't quite work right or whatever um but it's not that's not to say that it was exclusively that um like i know other you know phone freak types uh who have illicitly used global titles from telcos before in the past so like i figure it's probably both uh and you know since telstra bought the place

probably they have been trying to clean house, but Citizen Lab certainly has some criticisms about how fast that process has been happening. Yeah, well, fun times for people at Telstra trying to deal with all that, right? Yeah, exactly. So let's hope the Australian government's money covers all of the work required to make it fit for purpose. I think it is amazing, isn't it,

that you can correlate SS7 location queries with murders. Yes. Like if you had any doubt left in your mind that some of these surveillance people just belong in the bin, the fact that it's like a journalist's phone number was located via SS7, oh, two hours later they were murdered. Yeah, this is not great. And the scale of this is pretty large. I think they said, what, last October, 9,000 queries for location information. So that's quite a scale of operation.

It's not one or two. This is industrial sort of scale monitoring and surveillance and interception. Yeah, I linked through to the Australian Broadcasting Corporation's write-up on this, and this comes from their Organ crime and corruption reporting project. And look, got to say, for something quite technical, they did a hell of a job. Like, very nice reporting there. Yeah, it was a great write-up.

Yeah. All right, now we're going to talk about a John Grigg piece about CISA, a CISA initiative. They're working with MITRE to spin up an attack emulation platform for OT networks. Now, okay, fair enough, not huge news. But funnily enough, in debating whether or not to include this piece today, Adam, we wound up having a really interesting conversation about attack emulation.

So let's use this piece to have that conversation. I'm a big believer in attack emulation. I think that there are open source tools like Atomic Red Team. There are some of the commercial providers like Attack IQ who have previously sponsored Risky Biz and have been in the business for a long time. I'm a fan. It took a long time for people to realize that these types of activities could be useful. But honestly, I think before people go absolutely ape with things like red teams and pen testing doing some emulation you know attacker emulation on your network is just a really great way to see if you've got your ducks in a row and astonishingly Mr. Bearded Pen Tester over here you actually

agreed with me on that. Yeah it's taken a while for me to kind of come around to where this stuff fits in the overall offering. And part of that is because we used to do this stuff by hand as red teamers back in the day before this was easily automatable. And we wanted to think that we were magical and added value. Where the reality these days is a lot of these techniques are exercising a full breadth of them is more useful than a depth first human-led red team for you know managing detection response and i think

in ot environments particularly like having a human wandering around is even more problematic just because you know you could mess things up pretty good um and so yeah i think you know the value of a human-led red team in a trad ad environment these days is not super high like it makes more sense to expend the money and efforts going for breadth because all the techniques are well understood and automatable and don't necessarily require human insight and i think it is a better return on investment than letting a human run around and do one thing so yeah yeah yeah i mean it just really is the case that if you're going through an emulation exercise and you fail something big that is extremely valuable information yes you know you might say like and this is for people who already have security

controls already have detections like if you don't have those in place there's no point doing emulation but if you do have a security program if you have detections. Like if you don't have those in place, there's no point doing emulation. But if you do have a security program, if you are trying to detect things, if you are trying to block things, this is a good way to just really see if the stuff that you think works, works. You know, and I just,

I have been a believer in it early and it is satisfying to see a technology that, you know, because when AttackIQ started doing this commercially, it was kind of new, and it always seemed like a good idea. So I'm glad to see that it's getting somewhere, and I'm glad to see CISA doing this with MITRE. Yeah, MITRE has this Cold Era open source tool, and this development adds support for BACnet, Modbus,

and DNP3 industrial protocols into it so then you can kind of write test cases that exercise like reading modbus coils for example and be able to do so in a way where you can order that in advance rather than letting a human yolo it live and prod definitely you know provides a bunch of value for those kinds of environments now let's talk about Logic Monitor. This is amazing. Just tell us about this story, Adam. I'm not even going to bother introing it. So Logic Monitor are a company that provide like a cloud-based monitoring service and, you know, availability and statistics collection and those kinds of things and necessarily have quite detailed access

to people's cloud environments to be able to collect that data. There's been a tech campaign going around that abuses the fact that Logic Monitor give their customers a default password that's a, you know, like welcome at some numbers kind of thing. So like normal corporate help desk grade default password

that then doesn't expire or require a change. And so someone has figured that out, presumably brute forced a bunch of accounts versus some default passwords and then use that to pivot onwards into the cloud environments that they're monitoring, which like that's some sad trombone right there. Well, and they dropped ransomware, the attackers.

Like, so this wasn't like some kids dropping some crypto miners, like people got wrecked because of this and look i mean i think you can sort of equally split the blame here between the provider and the and the users but geez you know it just shows you know you're using a monitoring tool that probably has over provisioned access and an extremely weak auth mechanism and that that's it. You're done. Yeah. I mean, it kind of warms my heart in a way that we can still make such babby infosec mistakes in this year, 2023 AD, but not great for the customers, obviously. Now, we've got a bit of a follow-up, more of a follow-up on the Barracuda Oday drama. This is the one where, of course, a Chinese APT crew hacked into a bunch of Barracudas and then went. I think it was, what, Mandiant and Barracuda working together, tried to evict them.

And they just dug in so deep into the firmware that Barracuda said, yeah, you're going to have to throw away those devices. Turns out also some of these patches, it was pretty easy for the attackers. You know, there was Oday involved. But once they were patched, like it turns out that the attackers were able to sidestep those patches pretty easily. So for the 5% or so of Barracuda email security gateways that were affected in this campaign, yeah, even if you patched in time, it probably didn't do you much good. Yeah, there's certainly a number of things went wrong in this response process, like patches that were incomplete and that didn't provide the prevention required. And then the advice that they have been giving about junking the devices you know junking the gateways rather than upgrading them or patching them in place uh you know you and i both assumed

this was probably because of firmware malware it sounds like um from this write-up that they were the chinese were persisting through the device configuration backup and restore process so if you were going to to replace the device you would probably export the config using the config export which was actually like a like a MySQL database dump and then they were persisting by adding triggers into the database that they will be executed when it's loaded into the updated device so I think rather than necessarily there may have been firmware as well we don't know but that kind of mechanism of of looking at the obvious thing an admin is going to do and then backdooring that was just like my hat is off good job that's uh so but is this is this

why they said the patches don't work? Because there was a persistence mechanism that would persist through that config file? Or are they saying the patches didn't work because the patches didn't work? I think there's a degree of both here, right? The actual initial entry vector patches didn't work and then the process for upgrading them in the field also had a persistence mechanism that would survive across that. And even if you've

got a new device and migrated it across using the backup restore process it might have survived that as well so like just very smooth like i mean i'm you know i'm impressed and i wish i had done that to somebody's device once because that would have been a good story yeah it looks like the target selection was pretty bang on too like the crew that did this didn't just own every Barracuda like we thought that they may have. They went after about 5% of the total number out there and they were all what looked to be pretty valid in collection targets. Let's put it that way.

And they were using different post-compromise malware depending on the importance of the target. So there was like a special one that they were reserving for tech and government. And then other people, boring people like defense and military and telecoms providers got the lower grade one, which I thought was that's a good way to kind of split your, like, you know, you're going to get snapped. Like by splitting it into a couple of pools of victims, then maybe you can survive longer and you can deploy more safely these crazy techniques. Yeah. To keep assistance where you really, really want it. So. so yeah we've got another one from brian krebs here uh which is just a look at the dot us

domain and how much it's used for phishing and the funny the funny part i guess i mean we don't really need to spend much time on this but the funny part of this is that the dot us domain is supposed to be for like us citizens only and you And you go to register one through GoDaddy and proving you're a US citizen is a matter of selecting I am a US citizen from a drop-down menu and then pressing Go. Yeah, and in fact, that is the default selection. So if you just next, next, next, you get yourself a US domain. Good job, GoDaddy, good job.

But I mean, what do we expect? You know, they're going to ask for birth certificates or, you know? Yeah, but yeah. And even then, like, that's five minutes in Photoshop. So I don't know. It's just, I think it is a bit quaint to expect that you can have affordable domain registrations that are also going to be robust, robustly verifying people's citizenship. You know, just what do we expect?

If you don't want them to cost two and a half grand each this is what it's going to look like yeah exactly and if you will outsource it all to the go daddy then you know you don't necessarily get the good stuff yeah now alexander martin over at the record uh has a write-up on this um but ollie whitehouse has been appointed as the ncsc's first ever cto and i just wanted to say congratulations to ollie uh a while, he was more or less an honorary Australian. He lived in Melbourne for quite a while and you'd run into him at conferences like Ruxconn and whatnot. I still remember his amazing Bluetooth security research from 20 years ago and so much research. Ollie is just one of those really smart people who's been kicking around in cybersecurity for as long as I can remember. And it's great to see him going into a role like this.

Yeah, no, this is exactly the sort of person that we would like to see rescued out of private sector and back into a lowly paid role in government where perhaps you can make some change and do some things that, you know, being a yacht dwelling, you know, private sector CTO, you know, you can't do. So good for him. Yeah, no, I think it's great that he's doing this as well. And I'm curious to see what comes out of NCSC, out of, you know, from the mind of Ollie Whitehouse into public policy. Let's see how that goes. Oh, and we've got to correct something from last week.

We were joking that when we're talking about Kroll, having one of its employees SIM swapped, and then I'm like, well, this sort of thing happens to the, you know, the big four consultancies as well, even though they do good cyber work. And you said PwC got domain admin. Pretty sure that was Deloitte and that PwC, we got that mixed up with PwC getting moovited.

And then a couple of PwC people were salty at you, saying we didn't get domain admin guy. Yeah, but not this time. So that admin guy. Yeah, not this time. So that's good. Yeah, it's very easy to mix up all of the movement victims. So my apologies to PwC there. Yeah, you lost your data a different way. Yes.

But, you know, the point still kind of stands, right, which is that you can have organizations that do really good security work that have other divisions that, you know, aren't as secure as they should be. Yes, yeah, it's real hard problems to solve. Just going to mention this. security work that have other divisions that you know aren't as secure as they should be yes yeah it's real hard problems to solve uh just going to mention this the united nations uh commissioner of human rights has put out a report into uh human trafficking into these pig butchering call centers in southeast asia this is turning into a real issue uh catalan kimpanu had a write-up uh in today's newsletter about a raid on a call center in myanmar uh that was a joint operation between chinese and myanmar police and funnily

enough they they arrested like 168 uh chinese people as part of that and the chinese cops like seriously just put them on a bus to on buses to send it back over into china to face trial so they're having a bad day but you know this is just amazing isn't it that there's this human trafficking slash online crime slash call center nexus at the moment yeah it's pretty scary too when you think you know some of these people have had their like families threatened or kidnapped or whatever else to force them to work uh in call centres. And I guess a lot of these seem to be run by mainland Chinese gangs and are targeting victims in China, which I think is one of the reasons that we've seen the Chinese police cooperating with the authorities in Myanmar, et cetera, to raid these call centres.

And there's been a bunch of other work for like in Cambodia and Laos. Well, we saw a similar sort of compound ra rated in the Philippines a month or two ago. So Tom Uren is taking a look at this as an issue, and that'll be out in tomorrow's Seriously Risky Business newsletter. And subsequent to that, I have a discussion with him about his newsletter that goes out in the Seriously Risky Business podcast in the Risky Business News RSS feed, our other RSS feed that you should all be subscribing to.

And finally, Adam, we just wanted to link to a long read for people who might be interested in this week's show notes. And it's a piece from Matt Burgess over at Wired, all about TrickBot. Yes, there was a while back TrickBot, someone broke in and stole all of their message logs and a bunch of other data. And of course, there's so much interesting work to be done

when you've got a corpus of data like that and why I've spent the time to dig in and provide you lots of juicy details about the day-to-day lives of being a TrickBot operator. Yeah, it's just a fun read, so we thought we'd come to that one. But mate, that is it for the week's news. Thank you so much for joining me. Great fun as always, and we'll do it all again next week.

Yeah, thanks so much, Pat. I will talk to you then. That was Adam Boileau there with a look at the week's security news. It is time for this week's sponsor interview now with Mark Zhao, Gigamon's EMEA Technical Director, and we're going to talk about two things in this interview. The first is how Gigamon got out of the NDR business and is now just focusing on being a source of network data that other security companies and teams can consume. And then we're going to briefly talk

about a new product Gigamon has coming out next week. Gigamon was one of the first companies to do break and inspect SSL interception gear. And they've got a new cloud-focused product that basically does the same thing in the other direction. In essence, it's an SSL terminator for cloud environments. You can drop it in and then get decent visibility behind it in your clouds. So here is Mark Zhao. We divested the Threat Insight product, which obviously we bought originally as Iceberg. And what we've seen since then is an increasing amount of proactive approaches to Gigamon from a lot of the security, the SOC, SIEM providers, to help them in two areas. Firstly, reduce the overall volume of traffic

that they're having to consume and absorb and to help the end customers obviously reduce the number of instances of tools that they need for that that but also um we're working with quite a lot of the vendors and we've got you know you know validated technical designs and integration solutions already available with those vendors that identify the specific application data application metadata and that they need in order to get most value from the least amount of data. So effectively, we're giving them high fidelity data by giving them the right attributes, using our application metadata capability, but without overburdening them with too much information that they can't use. So we're looking, we work with organizations like Splunk,

we've got collaboration with things like IBM QRadar and others. But increasingly, if you look at some of the OT space, for example, there's a huge amount of collaboration because obviously OT is an area of concern for a lot of organizations because there are a lot of OT devices and sometimes they're not always secured in the ways that other enterprise IT devices are possible to secure. So a lot of what we're doing in the ways that other enterprise IT devices are possible to secure. So a lot of what we're doing at the moment is integrating tightly and working jointly, meeting out the customer with companies like Forescale and Clarity and Nozomi to help give them exactly the right volume of data and the right data attributes to help inform the use cases that turn their good product into exceptional products that are costing the end customers a fortune because they're having to have multiple instances of those particular tools.

And if you look at the service provider space, for example, one of the things we've been good at for many years and we're getting even better at is reducing the number of different probes and different tools that service providers need to cope with the massive volumes of data that come from their networks. Obviously, 5G, that's going to increase even more rapidly. And we're starting now to have... Well, yeah, I mean, you had 5G and every single gajillion, you know, every single one of those gajillion IoT devices

is going to be connected through it. So if you're a telco, you need to do some crunching. Yeah. Exactly. You've got to be able to cope with all the data, but then be able to filter out just the specific valuable attributes and capabilities. Sometimes after correlation between user and control plate, sometimes it's just extracting from the user plan of data exactly the individual applications and the the attributes that are needed to inform particular use cases and those use cases might be okay which devices can i can i on a 3g network and will tell me my impact if i want to switch off my 3g network to save money which of these devices are using uh different types of data services on 5g so I can identify and market those organizations

to sell them new products or services, for example. So they can only do that if they have a capability, both in cloud and in a physical network, to just give them the rich data they need when they need it, rather than having their existing probes choking on terabits of information, which they would never be able to keep up with. And even if they could, they'd have to buy not tens, but hundreds of copies of these probes and the infrastructure to run them on in order to do that same analysis. And that's where

Gigabon brings a big value capability into SPs in particular. I mean, it certainly feels like when it comes to network security stuff, it used to be security companies that would have their own network sensors and they would do deep packet inspection and have signatures and some heuristics. And they were big clunky stacks that didn't work all that well, which is probably why they're not, you know, so much the hot thing these days. The hot thing these days seems to be what you're talking about, which is handling huge volumes of data and just stripping it for the bare essentials i mean just hearing you talk about it i'm reminded of like uh core

light which i'm guessing these days is a competitor of yours when it comes to this type of type of information or being being a source of this type of information yeah it's interesting interesting because it's it's there are a lot of organizations out there that there are some, obviously, direct competitors to what we do. And there are some what I will call cooperators in the fact that some elements of the portfolio or our portfolio might overlap or be competitive to theirs. But in lots of other areas, we are complementary. You'd include organizations like Cisco and Palo Alto in some of that, for example, whereas the organizations that are probably slightly more competitive might be organizations like ICSI or others. But in the vast majority of cases, I would say we are wholly complementary to what over 200 different tools vendors, whether that's in the network traffic space, application

metadata, network intelligence, or SOC space. We're the Switzerland in the fact of giving them high quality, high quality data. But I mean, this is what I'm saying, like this is the way where now we have, you know, anyone doing network stuff these days is treating themselves as a source of data rather than an entire security stack. Like, you know, internet security systems 20 years ago, I don't know if you remember them, got sold to IBM and taken out to the back paddock and shot in the head, thankfully. But it just seems that these days you're either a data source or you're doing data analytics, right? You're not doing both so much. Yeah, exactly. If you look rudimentary level at what we do with the data,

we enable our customers to access it by tapping it, aggregating it, either physically or virtually. We help transform and enrich that data, and then we broker it out to the applications and services that need that information. So they spend less time and less customer money getting maximum value from it. And in a security use case in particular, one of the reasons that a lot of the, particularly the SOC vendors and the SOC tool vendors are coming to us is, is if you, if you look at logs and metrics, particularly logs, logs are mutable in the increasingly a number of the more refined and intelligent actors

are identifying ways to get access to logs, to copy them, to manipulate them. So the logs are actually mutable. The network data, the network traffic data isn't, it's completely immutable. So the network will tell you what the host is doing, whereas the logs will tell you what the host tells you it's doing. Yeah, yeah. I mean, this is why we still bother, right, with network. And I've heard a bunch of people say it's ground truth, right? I think that might've been originally one of the iceberg people who said that, and then I've heard it from other similar vendors. But network data, yeah, certainly is ground truth. So how are you actually collecting this data?

Do you have specific, like for on-prem, is this just like an additional bit of software that goes onto Gigamon networking products, or do you need to add new hardware? I mean, I imagine for the cloud, it's just a VM, right? You can instrument it that way if you want to start capturing network data from cloud. But when it comes to on-prem, is it additional hardware or is it just, you know, you buy like a software module from Gigamon and spin it up? Yeah. So in terms of the on-prem, this is a physical network stuff. We would have physical taps that tap into the network at various

key points yeah i just i just wondered if you could if you could just tap your existing gigamon gear uh you know without deploying new hardware well they they the way of actually gathering the traffic in the first place in a in a physical network is we have to do a physical tap of the net of the network but once you've got once you've got that data we can send that straight to the gigamon visibility node that in the physical environment is a hardware device that has all the advanced software to filter and enrich and transform.

In a cloud environment, our V-Series solution, which effectively is a VM-based Gigamon equivalent, is effectively the aggregate of the tap, aggregator and the visibility node in one piece of virtual software and it uses whatever the native methods are within the cloud environment to get access to the traffic and that might be nsxt in a vmware environment it might be vpc in amazon in azure at the moment um we would have to deploy a virtual taps to within the environment because at the moment Microsoft's not yet able to deliver an equivalent to us that enables us to capture the traffic as elegantly with our agent as AWS does with VPC, for example. They've been having trouble with that for years.

They have. And as soon as they solve that problem, we'll be on that straightaway with a solution that exploits that and uses it. But again, it is something that is almost like one of those freebie tomorrow type scenarios where they keep saying they'll do it and then there are complexities. And I believe it will come eventually, but I wouldn't even want to put an estimate on when that's going to be. Now, Mark, I understand also, you were an early vendor on the break and inspect SSL interception stuff, you know, on on on on prem, you know, IT networks.

I believe you're now well, you're soon to release essentially a reverse version of the same thing, which is an SSL Terminator, in essence, for cloud environments. That's right. Yeah. Yes. It's a means of giving our customers access to encrypted traffic in the clear when and if they need it within cloud environments, GCP, AWS, Azure container environments. Yep. So you deploy as a VM and then you're handling all of the SSL termination and then feeding that traffic back to wherever it needs to go. Yeah, exactly. And the important thing is because that we understand and we have to respect that that traffic that's fed is in the clear for where customers want to have that decrypted access.

We're able to feed that in a secure way using secure tunnels. So we don't want that information flowing freely in a decrypted state around, but we can pass that to whichever tools. Well, no, I mean, I can't imagine you writing it into text files and then batch emailing it. Yeah, so I would expect that would be tunneled out some way securely.

When's that coming out? That will be due for release on the 12th of September. All righty. Well, Mark Jow, thank you so much for joining me to talk through all of that. Great stuff, mate. Good to meet you and all the best. Thanks, Patrick.

It's been a pleasure. Thank you. That was Mark Jow of Gigamon there with this week's sponsor interview. Big thanks to him for that. And that is it for this week's show. I do hope you've enjoyed it. I'll be back tomorrow with another edition of the Seriously Risky Business podcast in the Risky Business News RSS feed. But until then, I've been Patrick Gray. Thanks for listening.