A (2:51)

So that's interesting. So if you're trying to block email at the gateway, that's going to be pretty hard to defend against, right?

B (2:56)

Well, I mean, you can block all the email in the world. None of these things are getting delivered through email. So. Yeah, no, absolutely. Even some of these things. Now that's kind of taking us onto the second was a pretty interesting campaign we saw last week, which we blogged about recently, which is we were looking at this trace and we looked at the trace and started at a Google search. So we're like, okay, cool, that's the normal thing we're expecting for a malvertising attack. But then the first link they clicked on was like a legitimate Microsoft.com link. Like, okay, you did a search for a Microsoft and then you clicked on a Microsoft link in a Google search result and then you got phished. How did this happen? And so it turns out, yeah, when we looked at the full trace this person had Googled for Microsoft 265. Someone was sort of keyword squatting to I guess make the malvertising a little bit cheaper. But I mean, yeah, I bet there are a lot of people who are doing that in this type. And so the attacker in this case had figured out how to actually do to use the AD FS authentication capability in Microsoft corporate accounts. So you can set up your Microsoft account to redirect to a local AD FS server, but there's no connection that the thing that you're redirecting to is actually a real adfs. You could just put any URL in there. And so in this case they were just putting. They were setting up a legitimate Microsoft tenant. Well, I mean, I say legitimate. A real Microsoft tenant.

A (4:24)

Legitimate enough, Yep.

B (4:26)

And then redirecting you to something which was behind an auth page. And when you hit that auth page it redirected you to the upstream idp, which in this case was a phishing server. So this is essentially like function like an open redirect.

A (4:39)

I was going to say there's a combination of things happening there because obviously you've got the fact that there's an open redirect on the Microsoft side and that's strictly speaking kind of a lower priority vulnerability. But if it's leveraged in this way, it becomes something that's quite useful. Right?

B (4:54)

Yeah, I mean that's actually, I'm saying on the Microsoft side, but it's kind of how SAML works.

A (5:00)

Right.

B (5:01)

If you set up Google SSO and you have an upstream idp, exactly the same thing happens. We tested it last week and it works in exactly the same way. So now there is a consistent way to get a google.com or a Microsoft.com URL that will take you to any arbitrary page with zero user interaction. You click that link to get to any arbitrary page. It's not like hosting a document that you then have to click another link, click a Microsoft.com link or a google.com link and you get to a phishing page. So like, yeah, it's pretty tough to do user education when you're faced with that prospect because what are you supposed to be checking for here?

A (5:35)

Yeah, and I guess coming back to the ATTCK for a second. So is what you're saying that this is kind of inherent to the SAML spec and how it's typically implemented, or is it like a vulnerability in that sense?

B (5:46)

The first step of XAML flow is the thing authenticating you sends you to the AUTH server and in this case that is just an arbitrary website. So yeah, there's nothing that checks that you're getting redirected to a real IDP versus just a fake phishing page.

A (6:02)

So that's a fun kind of systemic problem for the Internet to have at this point in time. Like what the heck do we do about this?

B (6:09)

Stop worrying about domains.

A (6:11)

Right.

B (6:12)

We need to be doing detections at a different level because clearly you can't be trusting where you're going and where you're getting redirected to. If you're looking at relying on domain intelligence or domain reputation of any kind of. Yeah, I think those days have passed.

A (6:26)

Got it. And in terms of what Push is able to do to assist with that and I guess the other part of this that we were talking about a Little bit before, we got on just the idea of users being aware, both at the corporate and kind of the personal level, that this is a thing, this is actually something that can happen. It's a fascinating attack. And to see it actually getting exploited in the wild and not necessarily getting talked about a lot, I think there's. There's a lot in that that probably needs to be kind of evangelized and educated out across the Internet, but just bringing it back to brass tacks around, like, what do we do? Like, how do you guys think about that?

B (7:02)

It's hard to tell you this without telling you what we do in the product side, because I think there really isn't much of another way to deal with this problem if you're dealing with this thing through anything other than actually looking at the traffic. Obviously we think doing that in the browser is the right way, but whatever you're doing, you need to be looking at the traffic on the wire. Because if you're looking just at domain names or trying to do user education, I mean, it's good for users to be aware that this is the kind of thing that can happen. But in these cases, the level of user education required is so high. I mean, you need to basically be a developer and then be awake. It's crazy high.

A (7:44)

Or as a user, just turn your computer off and go back to Abacus and just forget about the whole thing. Right. It's one of those ones where it's so complicated in terms of the potential kind of variations of the attack that you might experience that. Yeah, it's a little overwhelming on that side. Right?

B (8:00)

100%.

A (8:02)

Great. That's good news. Thanks for that. No, but look, you know, I think. I mean, I appreciate you kind of leaning away from the pitch side of things, but it is one of the things that, you know, last time we spoke just completely fascinated me about Push's model in terms of actually being inside the browser. And the fact that so many of these things, they're coming in, even when they come in through email or WhatsApp web or whatever else it might be, it looks like a link that's in a web browser that users ultimately interacting with, and then all sorts of different badness that can kind of happen downstream of that. Like the telemetry around that, I think is super important. Like, educating folks on the art of the possible is useful. And it's good to hear that Push is kind of keeping eyes on this and building out solutions to try to solve it.

B (8:48)

Yeah, it's been so interesting just seeing the Number of new techniques and the speed of these, how quickly these guys are evolving. It seems like there's almost not a week or two that goes past without something new changing. I think you can focus on just the sort of silly IOCs. I mean, I say silly, but there's things that are easy to change. It used to be ES domains was a major thing and then we started seeing.it.com domains and in the last two weeks it's been.sa.com and ru.com, and you could try focus on these things. But these things ultimately are those kinds of IOCs that are quick for the attackers to change. They are short lived. It works until it doesn't work anymore and then it stops changing. But the thing that's much harder to detect or much harder for them to change is the actual behavior of what these attacks are doing. And ultimately these attacks have to do the same kind of thing. You have to put an email address in, you have to put a password in, you have to downgrade some kind of mfa. There are structured phases that you have to go through in the browser to get these attacks to work. There's JavaScript methods that you have to call. There is user interaction that you need to elicit. And if you start detecting based on those behaviors, you're in a much, much better position to actually detect these things without having to constantly evolve and consume and be aware of whatever new technique is happening.

A (10:01)

Yeah, I mean that makes a lot of sense. I guess. Switching gears on this one, we were talking about the idea of dark web credentials being harvested and actually used in the context of phishing attacks and some of the, some of the research that you guys have done and things that you've seen over the past period of time. Do you want to go into that a little bit? Because we're talking about kind of the corporate choke point control side of things, but there is also the other side of it in that computer systems exist in family homes and whatever else. Do you want to touch on that?

B (10:34)

Yeah, yeah, for sure. So this is a feature we've had for, I don't know, a good long while now, but basically we're, we're looking to identify when credentials go for sale on the dark web. So we ingest several TI feeds and they tell us that this password is up for sale and we signature that password. And when we see that same password being used in a real corporate browser, well then you can put two and two together, right? You can say like, okay, this password's for sale and it's actively being used. This account is breached. You should assume it's breached. So we kept making these detections, working with customers and the customer's like, we don't get it. This machine has all the EDR on it, it's locked down. We don't understand what's actually happening here. How did this happen? How did this info stealer get onto this corporate machine and evade all this crazy detection that we put in place? And we realize actually what's happening is that person is logging in on a browser and using the built in browser password manager or a third party password manager. And in either case that password manager, either the Browser or their LastPass or whatever that is, is getting synced to a personal Gmail account. So those credentials you're putting in on a work machine in a work browser, but that browser is syncing to a personal Gmail. And so when you get home, all those passwords, even if you never use them at home, all those passwords are still getting synced through where the rest of the family is. Yeah, I mean, not doing the same level of carefulness that hopefully you are using on your corporate machine. So obviously in those cases you don't have edr and that works on that home machine. And that's where you don't detect these things. So these things are getting stolen in a place where you aren't looking for that, that to happen.

A (12:18)

Got it. So, so really what you're saying is that you've got, you've got a, you've got a browser that's logged into both the corporate and the personal accounts, but then what you've also got is a home machine that's less clean or less monitored or whatever else it might be, you know, possibly being used by your, you know, five year old. I think we're talking about this ahead of the call. The idea that Covid really kind of introduced this idea of the five year old being a part of the corporate attack surface into the conversation. This sort of seems like a pretty good example of that. But you're saying that that personal email or that personal kind of profile is synced to the browser of that non work computer and at that point in time you've got an opportunity for IABs to come in and do their thing.

B (13:03)

Exactly. And I mean if someone is. So let's say someone is using their work account to sync their Chrome profile when they log in from home. I mean you get something in your IDP log. So something that's telling you, okay, we're getting a login from A machine that's like not trusted, not authenticated, doesn't have conditional access policies like all the other. Like this is an unprotected connection, at least you got the chance to detect that. But if that's happening using it, if you're logging into your Chrome at work using your personal Gmail, well then there's no, I mean, you're getting no logs on their personal Gmail account usage, so it's impossible to detect that thing. Yeah. So we launched a feature that wherever push gets deployed, we look at who's logged into that browser profile and whether password synchronization is turned on for that browser profile. So if we can see someone is using the Chrome password manager or the Edge password manager is in a browser profile that is being logged into using a non corporate account and that browser profile is set to sync, well then you can be. Yeah, assuming that person has some kind of home or personal device, it's almost certain that that account is getting synced through. And I mean, yeah, in the most predictable analysis in the world, when we did some correlation between what are the numbers of people that we detect this stolen credentials for and how many of them have these personal sync browser profiles, you won't be surprised to hear there's a, there's an extremely high correlation between those two. So we think this is actually responsible for quite a lot of attacks.

A (14:32)

I mean, that's a fascinating ttp. It makes a lot of sense when you're walking through it. Just the fact that that's possible, the fact that kind of the bad guys have cottoned onto it and they're exploiting it proactively, I guess. Last thing there. And then just to give a quick shout out to the phishing techniques resource that you guys have put out to kind of collate all of these different things for the purpose of awareness. What's the mitigation when you guys detect this, when you see it happening, or when you get questions around how possible it is in an environment? Questions and concerns and all those different things. What's the mitigation that you're recommending at this point in time?

B (15:12)

I think a big part of this thing is just getting visibility of this issue. That's the critical thing because I think there's such a vast difference in the numbers we're seeing for different customers. Some customers, 10% of their employees had these synchronized personal accounts and in others it's a really low percentage. So we're still trying to unpick what exactly is it in the corporate culture? What is it in the control set. That changes this so radically because, yeah, it feels like more than human choice there. There are, at least on the Google side, some controls you can activate. So there's a setting you can set up in Google Workspace that tells you if you log into a browser profile using a corporate account, that can only happen in a browser profile which is linked to that same corporate account. So, yeah, that's a little convoluted, but yeah. So if you have a personal Gmail profile, the second you log into inside that personal Chrome profile, the second you start try to log in with your corporate account, it pops a new browser profile and immediately puts you into a corporate browser profile, if that makes sense. It's a little bit harder to do in the Microsoft world. I don't know how to do this in Edge yet. We're still trying to figure out what the way is to replicate that. But then, yeah, just getting visibility to the problem, I think is a huge first step.

A (16:22)

Yeah, I think visibility and awareness is a very good thing. And to that end, the Phishing Techniques resource. Do you want to touch on that real quick and then we'll wrap up?

B (16:31)

Absolutely, yeah. So, I mean, I think there's been so much discussion and evolution in these techniques and they're getting added so quickly. We're struggling to have a common framework just using the same shared language to talk about what these things are. We keep throwing words like domain camouflage and delivery vectors and anti analysis, but having a list of techniques. This is kind of the same MITRE thing again. It's good to just have a resource of named techniques and you could just at least attach ideas and say, we have found a new version of that thing. So we started using this internally and started talking about it. Accidentally realized we were talking about this publicly. We hadn't published anything. So we're like, okay, cool, let's spend the time, put together a bit of a resource and at least allow people to understand how much has changed by just looking at the number of techniques that are getting used across this sort of attack chain, I guess. Yeah.

A (17:23)

And it's open source too, right? I noticed when I was looking at it.

B (17:27)

Open source. Yeah, and published under Creative Commons. So, yeah, please do with whatever's useful.

A (17:33)

Yeah. Huge fan of that approach for educating the masses on kind of the status quo quo and like the evolving status quo. Because, you know, in security those things do tend to evolve pretty quickly. So well done on that. Appreciate it.

B (17:46)

Thanks.

A (17:47)

Well, it's been great to catch up. Jacques, everyone. This has been Casey Ellis for the Risky Business podcast, talking with Jacques Low from Push Security. Cheers.

B (17:55)

Thanks a lot.