Srsly Risky Biz: Exploiting authorisation sprawl is the new black

Summary

---

Risky Bulletin – Srsly Risky Biz: Exploiting Authorization Sprawl is the New Black

Host: Amberly Jack
Guest: Tom Uren (Policy and Intelligence Editor)
Date: September 11, 2025

---

Overview

In this episode, Amberly Jack and Tom Uren discuss two major cybersecurity developments:

1. The recent Salesloft Drift breach as a key example of "authorization sprawl," where attackers exploit interconnected accounts and services using stolen authentication tokens, creating a massive "blast radius" far beyond an initial point of compromise.
2. Apple’s newly-announced “memory integrity enforcement” feature, how it targets a longstanding class of software vulnerabilities, and what this shows about Apple's approach to device security.

The show provides a nuanced exploration of modern cyber threats, shifting attacker tactics, and both the challenges and progress involved in defending complex ecosystems.

---

Main Discussion Points & Insights

1. The Salesloft Drift Breach: Anatomy of Authorization Sprawl

Incident Breakdown:

• Attackers compromised Salesloft’s GitHub account, pivoted into Salesloft’s AWS environment, and obtained an authentication token.
• Using this token, they accessed the Salesforce instances of Salesloft Drift customers, impacting a broad range of organizations.
• Notably, Cloudflare (an affected company) published an unusually detailed post-mortem, shedding light on attack mechanics and fallout.

Key Points:

• Shift in Attacker Tactics (01:13–03:00):

  • “It's not hacking a device... This is much more, let's get an authentication token and just use the authorities or privileges that that token has to move through the network.” – Tom Uren [01:16]
  • Modern attacks often forgo traditional exploits or device compromises, instead moving laterally and exploiting the legitimate privileges attached to existing tokens.

• Blast Radius and Unintended Exposure (03:00–06:30):

  • Attackers enumerated Cloudflare's Salesforce environment, testing rate limits before extracting maximum data without triggering alarms.
  • Stolen data included customer communications, API keys, and authentication credentials. The degree of exposure varied based on how each company used Salesloft Drift and what data/chats included.
  • “We've gone from the compromise of Salesloft's GitHub to potentially the compromise of all sorts of different things... it could be, you know, passwords, AWS keys, who knows? So it's become a potentially very, very broad, quite unscoped [impact].” – Tom Uren [05:54]

• Transparency as a Learning Opportunity (06:30–07:25):

  • Unusually, both the breached SaaS provider and a key customer shared extensive details, making this a rare, instructive case study in authorization sprawl.

Why More of These Attacks Are Expected (07:25–08:34):

• Monitoring for illicit use of legitimate tokens is far less mature than endpoint detection for classic exploits.
• “There’s not a lot of security tools that are optimized to figure out is this legitimate authentication token being used correctly or maliciously... it sidesteps a lot of traditional protections.” – Tom Uren [07:46]
• Existing controls and best practices are “not necessarily the done things and they’re all more work” [08:48].

On Defensive Recommendations:

• Cloudflare and Salesloft issued remediation advice; other experts highlight the need for tighter privilege controls, monitoring, and review of SaaS integrations, but adoption is slow.

• “The nature of these things is that people get bitten and then they adjust their behavior.” – Tom Uren [09:16]

• “[Attackers] will also be learning off this case study... it’s inevitable fun times, not ideal.” – Tom Uren [09:03]

---

2. Apple’s Memory Integrity Enforcement: A Quiet Security Leap

Feature Announcement:

• Apple introduced “memory integrity enforcement” with its latest chips, blending hardware and software mitigations to thwart memory corruption attacks.

Background (10:19–12:05):

• Memory manipulation—“fiddling with the way it stores memory”—is a foundational technique for software exploits, prevalent for over 50 years.
• Recent governmental push (especially in the US and allied countries) for adoption of memory-safe programming languages.

Significance and Impact:

• While high-profile malware like NSO Group’s Pegasus uses such memory attacks, only a tiny segment of Apple’s vast user base is typically at risk.
• “They’re doing all this work really to cut off the, reduce the risk for a small number of people and there’s no real business case for that.” – Tom Uren [13:05]

Why Does Apple Bother?

• “I think they've got it in their sort of corporate culture. I think they just believe in doing it. I think they've got the money to do it.” – Tom Uren [13:35]
• Rare example where major security advancement doesn’t hinder profitability or user experience, so Apple pursues it as a long-term benefit.

How the Work Unfolded (15:05–16:20):

• “The culmination of at least five years of work... From an offensive point of view, they have a research team that was constantly attacking... what they thought they were building.” – Tom Uren [15:06]
• Apple’s engineering teams used “iterative attack and defense” against simulated and prototype devices, steadily eliminating classes of vulnerabilities before they could be abused in the wild.

What It Means for Users and Industry:

• This doesn’t make iPhones “impregnable” but raises the bar for attackers—especially state-backed and mercenary actors.
• The security benefits are expected to “work their way into other products as well” as competitors copy these techniques [16:50].

---

Memorable Quotes & Moments

• On Authorization Sprawl as the “New Black”

  • “Single impact, but massive blast radius.” – Tom Uren (paraphrased by Amberly) [00:55]

• On Data Leakage Potential

  • “So in the course of normal discussion with their customers, people had shared... secrets or authentication tokens that could allow the threat actor to do something else.” – Tom Uren [05:30]

• On Industry Readiness

  • “There’s not a lot of security tools that are optimized to figure out is this legitimate authentication token being used correctly or maliciously... it sidesteps a lot of traditional protections and it’s a greenfields opportunity for threat actors.” – Tom Uren [07:46]

• On Apple’s Security Philosophy

  • “I think they've got it in their sort of corporate culture. I think they just believe in doing it. I think they've got the money to do it.” – Tom Uren [13:35]
  • “This allowed us to identify and eradicate entire attack strategies and techniques before attackers could ever discover them.” – (Apple, quoted by Tom Uren) [15:49]

---

Important Segment Timestamps

• 00:38 – 07:25: Deep dive into the Salesloft Drift breach, step-by-step attack path, and its wider implications.
• 07:25 – 10:09: Discussion on the rising trend and defensive challenges of authorization sprawl.
• 10:09 – 17:30: Apple’s memory integrity enforcement: what it is, why it matters, and the long-term impact.

---

Overall Tone and Takeaways

Amberly and Tom focus on clear, accessible explanations of complex cybersecurity issues, blending technical clarity with practical policy and industry context. The conversation is collegial, lightly humorous (“fun times, not ideal”), but grounded in the urgency of modern digital risks.

For defenders and decision-makers, the message is clear:

• The classic “breach one, breach many” risk of interconnected services must be addressed with new detection and privilege management strategies.
• Security investments, even for a minority of high-risk users, can yield broad and lasting improvements for the wider ecosystem.

---

End of summary.

Transcript

[A]

Hey, everyone, and welcome to Seriously Risky Business. My name is Amberly Jack, and this is the podcast here at Risky Biz, all about cybersecurity policy and intelligence. And in just a moment, I will bring in Tom Uren, our policy and intelligence editor. But first up, I would like to thank the William and Flora Hewlett foundation for supporting Tom's work here at Risky Biz and also Lawfare, who syndicate his newsletter and publish it on the Lawfare Media website. And finally, we do have a corporate sponsor this week, Trail of Bits. So big thanks to them for that. And Tom, G'.

[B]

Day.

[A]

Thank you for joining me.

[B]

G', day, Amberly. How are you?

[A]

Pretty good, thanks, Tom. And just been reading through your newsletter here and really keen to talk to you about the Salesloft Drift breach. And you've kind of given a bit of a rundown on what's happened in the newsletter. And you've said there this is a great case study of the. The kind of sprawling impact that a breach on a single service provider can have. And I think you even said in the newsletter, single impact, but massive blast radius. So I guess to start with, Tom, what's the big deal here? Why is this a great case study and what is the story here?

[B]

Yeah, yeah. So I think over the last little while, I've noticed that there's this trend of it's not hacking a device. And then traditionally you would pivot to other places within the network, you'd escalate to get higher privileges, you'd get to control the whole network. That's traditional hacking that cybercriminals or states would do. This is much more, let's get an authentication token and just use the authorities or privileges that that token has to move through the network. So there's no compromise of boxes, there's no exploits. There's none of that. And that's been going on for a while. But this has turned into a great case study because there's so many affected third parties. Usually what happens is in this type of incident, there's a single company that's most directly affected. They very rarely go through the nuts and bolts of what actually went on. So the story here is that Salesloft Drift is an AI chat agent, and it's integrated often into Salesforce that many companies use. And this week we learned that the way that the attacker in this broader breach, which I'll talk about a bit more, got in, is, first of all, they compromised Salesloft's GitHub. So Salesloft said that they were somehow able to move from their GitHub account into their AWS environment and they were able to get some sort of authentication token. And with that they were able to compromise all of the Salesloft customers who'd integrated Salesloft Drift into their Salesforce. So the sort of chain ideal the chain is GitHub, Salesloft, GitHub, Salesloft AWS Environment, and then to all of Salesloft Drift's customers who'd integrated it. And so that meant that they had access to a Google response incident response person who's handling incident response for Salesloft said potentially hundreds of companies. And now what makes this interesting is that as I said, usually when it's a single company they're pretty tight lipped about actually went on. In this case, one of the affected companies was client Cloudflare and they've produced quite a detailed blog post about the exact going ons and what the threat actor in this case did. And so now we have the, so we have the whole incident laid out from not, not entirely laid out, but we've got the. A good overview of the whole incident from GitHub through to what they did at the compromised customers Salesforce instances. So Cloudflare says that they spent quite a bit of time, several days enumerating what was available, how Cloudflare managed their customer interactions, like the processes involved, how much data was there, what data was available. They even talk about exploring the API limits. So the limits where if the threat actor tried to gobble too much data, they would get pinged. So this is actually like sounds like quite a carefully carried out operation. It wasn't just smash and grab and get everything. And the threat actor understood Cloudflare's Salesforce environment and then it sucked up all the data it could as quickly as it could, understanding those rate limits so that it didn't get pinged immediately. And it turns out that it was able to get what are called customer case objects. So that includes, it's kind of analogous to an email. So it included the subject line, the text that customers and Cloudflare had shared back and forth. So the sort of communications, but it didn't include files or attachments. Now in those communications Cloudflare said that it found 104 API keys. So, so in the course of normal discussion with their customers, people had shared, you'd call them secrets or authentication tokens that could allow the threat actor to do something else. Possession of those would give the threat actor some ability to do something somewhere else. So we've gone from the compromise of threat Salesloft's GitHub to potentially the compromise of all sorts of different things. So depending upon the company that's affected, it could have who knows what, like, you know, depending upon what they talk to with their customers and what customers and they paste into that chat. So it could be, you know, passwords, AWS keys, who knows? So it's become a potentially very, very broad, quite unscoped. Like it's hard to know how that would flow because there would be some customers where they never talk about that sort of stuff and so they're, you know, no keys, no passwords, that's okay. And other companies where maybe Salesforce is used to handle that material all the time. And so I thought this was just a classic example that because Cloudflare and Salesloft have been more or less, they've revealed enough detail that we've got this good picture that it felt like a case study that was worth writing about.

[A]

Yeah, absolutely. And you sort of say in the, in the newsletter as well, Tom, that this is, this is kind of becoming increasingly common. We can expect to see more attacks, you know, more sort of fallout and attacks like this. Why, why is that?

[B]

I think it's just because of the way that once you've got an authentication token, there's not a lot of tools that make it easy to know that it's being used incorrectly or correctly. So you have to have some other sort of control layout on top. And so it's like I said with traditional hacking, there's a lot of security tools that are optimized for traditional hacking. There's not a lot of security tools that are optimized to figure out is this lake legitimate authentication token being used correctly or maliciously. So there are options, it's just that they're not as well deployed and so it sidesteps a lot of the traditional protections and it's a greenfields opportunity for threat actors to some degree.

[A]

Is there a plan of action here? Do we just kind of sit around and wait for things to go boom and watch the massive fallout?

[B]

From the perspective of a policy newsletter, that would be great. I think there are lots of things that you can do. It's just that they're not necessarily the done things and they're all more work. So that's the problem. So there's some good blog posts already. So Cloudflare's write up of the incident has suggested remediation steps. Salesloft has suggested remediation steps. There's a good blog post from Joshua Wright, I think his name is about authorization sprawl, which also has a list of suggestions or recommendations. The thing is, they're just not what people normally do. And the nature of these things is that people get bitten and then they adjust their behavior. Yeah, but I think the reason that this is a good study to talk about from a defensive point of view is it's also a good case study to talk about from a cybercriminal's point of view in that it's like, oh, hang on, you know, we're already doing, you know, 75% of this, this other threat actor has done this other thing that gave them all sorts of new opportunities. So I think threat actors will also be learning off this case study, which is, I guess it's inevitable fun times, not ideal.

[A]

I want to jump into your second story here, which is Apple new security feature that they have just announced and apparently it's a really big deal, Tom.

[B]

So they've launched this thing they call memory integrity enforcement. So a while back I wrote about memory safety issues. So it turns out that one of the most common ways that you can compromise a device is by basically fiddling with the way it stores memory or manipulating the way it stores memory to your advantage. And there's actually a very long history of these types of attacks going back like 50 years, and yet they're still surprisingly common. And the reason I wrote about it about a year ago was that the US government and allies had basically launched a kind of memory safety initiative where they were trying to encourage people to use memory safe languages, languages that don't have the same kind of flaws. And so this week Apple, with the rollout of the next generation chips, announced what they call memory integrity enforcement. And the idea is that they've got this hardware and software approach that makes it a lot harder for threat actors to compromise their devices by making it a lot harder to manipulate memory in undesirable ways. And it's, this was interesting to me because. Well, first of all, it's part of a trend where people are moving to memory safe implementations languages. And it's also because Apple actually has, in my view, it's actually got not much incentive to try and invest in this kind of cutting edge work.

[A]

Yeah.

[B]

So the story is that Apple devices are very rarely compromised by sophisticated malware. And the cases where that has happened it's been either states or I guess the most famous example is NSO Group where they had their Pegasus malware and that relies on some of these memory manipulation tricks. And they're Trying to make it very, very hard for particularly mercenary spyware to get onto devices. And the reason I think it's interesting is that that just affects very few people. Like in terms of Apple's customer base, it's a vanishingly small percentage of people who get affected by that. So they're doing all this work really to cut off the, reduce the risk for a small number of people and there's no real business case for that. They could just gradually improve things without a huge amount of effort and they'd still be in a good place. I think it makes no difference to their bottom dollar.

[A]

So this isn't something that school teacher Joe down the road will have to rush out and buy the iPhone 17 because it has this feature. So why, if it is such a small sort of set of their customer base, why do you think they're doing this?

[B]

I think they've got it in their sort of corporate culture. I think there's. They just believe in doing it. I think they've got the money to do it. Like Apple is not currently cash strapped, so they've got.

[A]

Always helps.

[B]

That's right. And I don't think it cuts against some of their other business interests. Like sometimes doing security work slows you down in other areas and makes it more. Your product's less competitive. If they're slower to market because they're more secure, is that on balance a good thing for the business? Actually, maybe not. And I don't think there's this dynamic in this case. It's. They have a work stream that is improving memory safety and that isn't a detriment to their other business. So a lot of this work was to make sure that it could implement memory safety without slowing down the devices. Right. And so I think that's a trade off that they wouldn't make. But in this case they're able to do a lot of clever engineering. They sort of balance what's done in hardware and what's done in software so that, you know, you're doing the right thing in the right place and you're getting the best protection for the least performance cost.

[A]

Yeah, for sure. And it was a lot of work, wasn't it? It was like half a decade of kind of attacking and re. Attacking and testing and yeah, they call.

[B]

It the culmination of at least five years of work. And, you know, how do you measure how much work's gone into a chip these days? Like it's, you know, it goes back 50 years. But from an offensive point of view, they have A research team that was constantly attacking, I guess what they thought they were building. And so they would have a theoretical target, they'd try and attack it and then that eventually they built a virtual environment or a simulated environment and they try and attack that. And what they learned from the attacks kind of iteratively fed into the protections that they use. And then finally towards the end, they're attacking prototype hardware. And so at each stage they learnt something like Apple said, that this allowed us to identify and eradicate entire attack strategies and techniques before attackers could ever discover them. So that process of introducing mitigations that eliminate classes of attacks has been very successful. So over the time people have used address space layout, randomization and pack pointer authentication, something beginning with C. Those techniques, because they eliminate classes of attacks, are very effective at just making it very much harder for exploit writers. And so I expect that this will make a significant difference. It's not going to make iPhones like impregnable. There will still be attacks, it'll just be a lot harder. And I suppose if you limit it to states maybe. Well, that's a win. That's a win. And I think even though Apple is in somewhat of a unique position because of its like its business model, the ability to devote resources, its hardware and software integration, other companies will learn from this and so they'll no doubt be in a year or so, these sort of techniques and strategies that Apple has used will be working away into other products as well.

[A]

Okay, Tom, look, we will leave you there, but thank you so much for joining me and we'll catch you again same time next week.

[B]

Thanks Amberly.