SaaS Supply Chain Threat Investigation: Detecting and Responding with Databricks

Summary

Attackers increasingly compromise SaaS applications through OAuth token theft and third-party integrations rather than direct user credentials, as demonstrated by the Shiny Hunters and Scattered Spider campaigns of 2025–2026.
Obsidian Security, built on the Databricks Data and AI platform, used data normalization and threat hunting in Databricks notebooks to investigate the largest SaaS supply chain breach and uncover previously unknown indicators of compromise.
Cross-organization intelligence sharing and detection engineering patterns that distinguish developer activity from attacker behavior are essential for identifying and responding to cross-SaaS incidents before data exfiltration occurs.

SaaS Supply Chain Threat Investigation: Detecting and Responding with Databricks

SaaS platforms have become the weakest link in modern cybersecurity. Attackers now bypass user access controls through application integrations, gaining privileged access to sensitive company data in Salesforce, Microsoft 365, and Google Workspace. The 2025-2026 Shiny Hunters and Scattered Spider campaigns demonstrated this shift, with supply chain attacks affecting hundreds of companies. Organizations remain blind to these threats until data exfiltration occurs. Detecting and investigating these cross-SaaS incidents requires unified visibility across fragmented security telemetry and careful threat intelligence correlation.
See how Obsidian Security and Databricks enabled rapid investigation of the largest SaaS supply chain breach, uncovering compromised OAuth tokens and previously unknown indicators of compromise across customer environments. Learn threat hunting techniques using Databricks notebooks, data normalization approaches for tracking identities across SaaS platforms, and detection engineering patterns that distinguish developer activity from attacker behavior. You'll walk through real incident response workflows and understand how cross-org intelligence transforms blind spots into actionable insights.
🤝

Chapters

FAQs

What is a SaaS supply chain attack?

A SaaS supply chain attack exploits third-party application integrations rather than compromising user credentials directly, giving attackers privileged access to sensitive data in platforms like Salesforce, Microsoft 365, and Google Workspace. In this video, the Shiny Hunters and Scattered Spider campaigns demonstrated how OAuth tokens obtained through compromised integrations enabled attackers to reach hundreds of companies.

How did Obsidian Security use Databricks to investigate the SaaS supply chain breach?

Obsidian Security used Databricks notebooks for threat hunting and data normalization to track identities across SaaS platforms and correlate threat intelligence across their customer environments. This enabled them to uncover compromised OAuth tokens and previously unknown indicators of compromise during the investigation of the Salesloft Drift incident.

Why is cross-organization intelligence sharing important for SaaS threat detection?

Cross-org intelligence allows security teams to correlate indicators of compromise—such as IP addresses—across multiple customer environments, turning blind spots into actionable insights. In this video, cross-org detection patterns enabled Obsidian to identify and notify affected customers during the supply chain investigation.

How do security teams distinguish attacker behavior from developer activity in SaaS environments?

Detection engineering patterns that establish integration baselines help identify anomalies where access patterns deviate from normal developer or service account behavior. This video covers how Obsidian Security built these baselines and used them to separate legitimate API activity from attacker-controlled OAuth token use during the investigation.

Full transcript

[00:07] First I want to start off by just thanking, I mean all of you for coming. Um, the co-workers at Obsidian that have assisted me with getting this presentation here as well as building it. Um, and most of all thank you to Databricks, the organizers, all of the the tech
[00:23] staff and volunteers for making this event actually happen. Big event I've so I've been told couple couple thousand people at least. So I'm sure it's not no small feat to make this happen. So do quick little introduction. As you
[00:40] heard, Damien Miller McKanders, I work as a threat researcher at a company called Obsidian Security. I'm based out of beautiful, not the most sunny, Alberta, Canada, but down here to California for this conference as well as some other random things this week
[00:57] that I want to do. Obsidian Security, we are a SaaS and AI security company. We do SSPM, ITDR, agentic AI security and discovery, whole bunch of random stuff. And ultimately we are one of the companies
[01:13] that is built on Databricks. We rely on Databricks. I've been using Databricks since I started at the company. And that is one of the reasons why I'm here to talk to you today is about how we use Databricks. But first I want to set the stage by telling you about a warning. You might
[01:30] have heard of this gentleman, it's Pat O'Pet, who is the chief information security officer from JP Morgan Chase. And in April 2025, he published what was his open letter to third-party suppliers. And at this point, JP Morgan Chase had
[01:46] already dealt with a number of supply chain incidents both outside of and within SaaS. And it's a really good letter if you're interested in in reading about it. I'm not going to do it justice. But the quote I want to tell you is that Padiact said, and this is verbatim, "The modern SaaS delivery model is
[02:03] quietly enabling cyber attackers." So, what does that look like? So, last year, including in presentations I gave and and webinars I I spoke at, I like to do the headline and and marketing love to use this
[02:18] headline, 2025 is the year of the SaaS supply chain attack. And I think unfortunately 2026 is also the year of the SaaS supply chain attack. I think at a certain point it's just going to stop being the year of the SaaS supply chain attack, and it's just going to be always a SaaS supply chain
[02:34] attacks. And it's kind of interesting that this, which is some of the the uh the headlines, happened a couple months, I believe it was 3 months after uh Padiact's letter was
[02:50] published. Now, why was 2025 and unfortunately expanding into 2026 the year of the SaaS supply chain attack? There were three things that I want to call out from uh Padiact's letter, and it was
[03:06] three, what you might call problems, what you might call causes, but it was that one, SaaS-to-SaaS integrations are frequently bypassing uh access controls into SaaS environments.
[03:22] Two, that software providers gain privileged access into your SaaS, into your most important data stored in places like Salesforce and ServiceNow, with very limited, if any, transparency for you into what they're connecting to, what they're accessing, where they're
[03:38] coming from. And then finally, that these advanced detection capabilities, which are needed for these very interconnected systems, especially SaaS in the context of identity providers, just isn't there. Uh detections do not correlate signals
[03:53] across services, across tenants, across different organizations. Now, these problems are all at the root of what has made these SaaS supply chain attacks so
[04:09] so impactful and problematic. And they compounded an attack that not many of us, I think, were really ready for. But before we talk about the fun attack and I spend about 10 minutes talking your ear off about my favorite subject,
[04:24] we will talk about some of those problems and how they ultimately form what I like to call the visibility problem. So, there's a difference between an anomaly and not an anomaly. Of course, obviously. But as someone who does both
[04:39] SaaS security investigations, as well as in a in a prior job, on-premise network, you know, your operating system security incident and forensics, uh the opaque nature is what I call the opaque nature of SaaS, in my opinion, breeds more anomalies.
[04:56] So, Windows and Linux internals are very well documented. I have at least two books that are just Windows operating system internals. They're about this thick and about as interesting as that sounds, really. Uh but if there is an application on your Windows OS that's making a strange
[05:13] Windows API call, with enough research, you can pretty easily find out eventually what it's doing, why it's doing it. Now, SaaS platforms, on the other hand, uh they can be black boxes, like I said, they can be opaque. They're hard to understand. And that is compounded by
[05:29] the hundreds, if not thousands, if not for some of our customers, the tens of thousands of third-party integrations they have into their most important SaaS, like Okta, Microsoft 365, and Salesforce. And that can be sometimes per platform.
[05:45] That's not all their integrations on SaaS. Sometimes, some customers do have tens of thousands of third-party integrations into all of their different Microsoft 365 tenants. So, this makes anomaly confirmation is what I like to call it tricky. It's not particularly difficult with the right
[06:02] platform, the right uh the right tooling to detect an anomalous login or some anomalous data access, but confirming that anomaly is actually being malicious is uh in SaaS, I think at times can be very difficult.
[06:17] Now, one of the best examples of this is actually developer activity. Most of the time, integrations, be it your internal integrations that you're running or third-party integrations, are going to run on very stable infrastructure. They're going to have behavior that's very easy to normalize.
[06:35] And they're going to do things at scheduled times, right? It's going to run some random job to take some data from Salesforce and do some calculations four times a day, roughly, you know, 26 hours apart. Had to do a little bit of math in my head. Uh but once in a while, and by once in a
[06:51] while, I mean this is what my uh integration alert Slack channel at at work that I use for alert com- uh confirmation is full of Developers like to just do things with the integrations, whether they're internal integrations your own developers are doing things with or they're third-party integrations
[07:07] that their developers are doing things with. They're going to grab a token. They're going to need to test something. They're going to run a little script. And without more information, depending on the infrastructure that it's coming from and and what they're actually doing on it, that developer behavior can be absolutely
[07:23] indistinguishable from adversary activity. So, what I'm saying is that it's very easy to detect an anomaly in the context of SaaS integrations, but it's harder to detect an attack. So, most organizations are not going to
[07:38] be running some threat intelligence chat. They're not going to be going to to their threat sharing Telegram groups every time an application connects from a weird location and they have to reach out and say, "Hey, any other customers of this thing see this random IP logging into it?" Most companies are not going
[07:55] to be doing that. So, until something else happens, until they get additional signals or something else that clues them in that it's malicious, they're just blind. So, most orgs, unfortunately, from what I've seen um with especially integration
[08:10] ac- uh related incidents, they're blind until the data exfiltration happens and we can alert you on data exfiltration and if everybody can alert you on data exfiltration, but by the time the data has been stolen, there's no stopping it and they have 2 TB of your sensitive company data.
[08:25] So, nothing in most orgs' logs tells them that 699 other companies are looking at the exact same thing. So, because I have to, because I was forced to, that was a joke, don't worry. I want to be here. Let's talk shortly
[08:42] about what we do at Obsidian. So, we ingest data from uh frankly a lot more SaaS services and platforms than I can remember. Can't give you another number, but we take it in and we normalize it and we do a bunch of data processing that I I don't personally uh care about
[08:58] as a consumer of the data, but I can tell you that we do a few things that are really important for this type of data. Uh it gives us the normalization that we do gives us consistent event types, it gives us timestamps. And most importantly for the context of these
[09:13] cross-SaaS incidents for both uh normal human identities as well as integration and agentic identities is we have what we call at Obsidian a global unique entity ID. So, this tracks whatever the identity is across SaaS platforms so
[09:29] that if things like the UPN don't match up or whatever SaaS platform doesn't have a UPN in whatever specific logging event you're looking at, um you know, if the field's called something different than different in Microsoft and Salesforce, for example, we catch that and we can group all that
[09:44] activity up. So, it's a lot easier to search without having to manually do all of that combination work. And then there's some Databricks features that I want to just call out as helping me elevate my threat hunting potential. So, we get direct and reliable and most importantly
[10:02] secure access to our company our customer's production data and I get to do work in notebooks. I run a notebook for every single threat intelligence or like investigation that I'm doing in really whatever programming language you want, Python, Scala,
[10:19] SQL access. And I've been able to build over the last two-ish years a pretty good iterative loop notebook in Databricks that I can do all of my investigative work. I just literally copy the notebook and open it up and paste stuff in. You'll You'll see a
[10:34] couple of examples of that shortly. Plus, as someone who took a single semester one class of SQL in college 5 years ago, the AI assistant I I like to think is pretty helpful for for making it so that I'm not spending all my time chasing
[10:51] down, you know, weird SQL syntax errors and I can just get right to all of the important stuff. Which just so happens to be this. So, in order to tell you about how City and I myself leverage Databricks for threat investigations, I need to tell
[11:07] you about the biggest SaaS breach up to this point in my opinion and or SaaS at least at the very least biggest SaaS supply chain breach and how we investigated it. So, enter UNC 6395 or as I like to call it, uh Shiny
[11:23] Hunters at all versus Sales off Drift. So, Shiny Hunters. we're going to do audience participation while I drink a little bit of water, and I expect to see audience participation. Raise your hand
[11:39] if you're familiar with Shiny Hunters. Now, I'm not talking about your specific company, but raise your hand if you are aware of if you're familiar with Shiny Hunters, if you are aware that you've
[11:55] had your own personal data from some company in one of the breaches stolen by Shiny Hunters. A number. As someone who investigates Shiny Hunters, I've been investigating them for at this point close to a year. Uh and and I've also spoke directly with
[12:11] Shiny Hunters affiliated actors. They've stolen my data three separate times. Uh including all of my basically enough to steal my identity, so uh that's where I am with it, but I keep doing it. So, Shiny Hunters might also sort of see
[12:27] them referred to at times the recent attacks as the Scattered Spider. They're not typically what you would think of when you think of, you know, the more state-sponsored Russia and Russian or Chinese cybercriminal groups. You know, in the
[12:43] in the industry, we call them advanced persistent threats or APTs. Instead, Shiny Hunters, Scattered Spider, and other affiliated actors are what we would broadly call sort of a a loose coalition
[13:00] of related sort of knowledgeable actors. Uh they come from a a specific place online that's referred to as the com or the community, which is actually really kind of what it says, a community of uh young and very digital native English-speaking
[13:17] cybercriminals. Some of them as young as uh 11 or 12. Generally then into Yeah, it's it's it's a little surprising. Generally into like their mid to late 20s. And they exist on places like Discord servers, Telegram chats. Uh a lot of them get their start as cybercriminals
[13:33] by hacking Minecraft and Roblox accounts or stealing people's cryptocurrency and then eventually they by teaching each other, by by making friends within this community, they learn how to do help desk social engineering, voice phishing, they learn
[13:50] how to make malware and eventually then they hack uh thousands of companies and steal at this point they must have stolen hun- at this point hundreds of terabytes of data over the last few years. So, some of these attacks were attributed to
[14:06] different Mandiant are the ones who say UNC they're attributed to different actors, different different names or clusters. I'm just going to refer to it all as Shiny Hunters cuz that's the quickest and easiest thing to say and it's basically true. So, most previous SaaS attacks, including ones that Shiny Hunters had done in the
[14:23] weeks and months leading up to what we call the Salesloft Drift incident, focused on single companies. So, Shiny Hunters were doing a campaign in sort of like early to mid 2025, which involved calling employees and pretending to be IT and saying they'd call someone on on
[14:39] marketing or something like that and convince them to add uh a specific type of integration into a Salesforce tenant, what's called a connected application you might be familiar with. And this connected application was I mean it was a malicious obviously cuz it stole and exfiltrated within some
[14:56] companies a matter of 20 minutes or half an hour all of the data it could access within Salesforce. Now, they did this uh handful of times, but as you can sort of see from the diagram, it's a little limited in scope as well as scalability cuz they need to have all of these actors and I'm going
[15:12] off topic again. They frequently will be advertising for people to do this on various Telegram server uh sort of channels and chats looking for people who can do this sort of thing and training them up and and doing it they're they're asking for you
[15:27] know, English English speaking people without a without a strong accent to do this. So but so they can recruit but still the the scalability and the amount of data that they can steal this way is pretty limited. You know, I'd give that I'd give this sort of attack maybe like a five out of 10.
[15:44] And then they they legitimately did 10x their impact by going after one single company and then carrying out a supply chain attack. So they targeted the company Salesloft which was an AI-powered sales analytics thing into Salesforce and a few other
[16:00] platforms. And in a in a attack campaign that occurred over the span of a couple of months, they got into AWS, they got into GitHub, they were eventually able to obtain a bunch of OAuth tokens for roughly 700-ish
[16:15] customers of Salesloft and their Drift product. And those OAuth tokens can be used to uh access customer data in something like Salesforce as if you are the integration itself and they were able to abuse those OAuth
[16:31] tokens and steal data from those 700-some-odd uh companies. And then they extorted pretty much everyone they could they could try. They extorted Salesloft Drift, they extorted um they extorted Salesforce themselves, they tried to extort all of the
[16:47] companies involved with this. And uh at the end of the day like I said, it was roughly considered to be around 700 companies and I don't remember the exact number of data but it was terabytes and terabytes of data including everything from the sort of
[17:02] stuff that companies want to keep private, their suppliers, their vendors to people's personal information, their PII uh a lot of stuff that you don't want to get into the hands of cybercriminals. So this wasn't the first time that something like this that like a supply chain attack was done, but looking at
[17:19] the platforms, they're targeting SaaS platforms, as well as its scope and its impact, in my opinion, this was definitely the largest and most impactful supply chain attack of its kind. And here's a little bit of just a diagram of the attack that took place.
[17:35] If you wanted some more information, like I said, I could I have done and could do like a 2-hour talk about this. But what I really want to get across is how this attack and a couple others that happened after it, there was Gainsight, a company called Gainsight, another AI-powered analytics company, that happened I think
[17:52] 3 months after uh Salesloft Drift. But this attack and others cemented that a real shift in methodology had occurred. And this was the focus for incidents like this shifting away from the human element to integrations.
[18:10] And these integrations, of course, everybody has them. They're sitting in SaaS platforms like a little ticking time bomb. So now we'll get more into our investigation of this attack because uh we were plugged into a number of uh Salesforce tenants that had this
[18:26] uh specific activity occur in it. And we were there doing the investigation from day one. Um it's never I I know it's never going to be a good day when I wake up and that the one of the very first things I do, of course, is check my phone. And if I have too many Slack notifications, I know that I am not
[18:41] going to have a good day. And that was unfortunately the day this happened. I had so many Slack pings. I so many people were spinning up channels and adding me to them, giving me paragraphs of questions, and I said, "Guys, listen, I just woke up. Can you give me like 2 minutes, and I will get on the computer, and I'll check this
[18:58] out." And that was uh the And of course, it was morning. I don't remember what day of the week it was, but it was morning when when the news broke. So first, Mandiant, um incident response company, Google Google-type company, uh released the initial indicators of
[19:13] compromises as call them our IOCs related to the specific attack. So, that was IP addresses as well as user agents. And usually uh what orgs do when when something like this happens and what a lot of orgs did for this incident is they're going to search independently
[19:29] their own organization. Hopefully, they know all of their Salesforce tenants that they have. Hopefully, they can search in all of them. Hopefully, they don't have to export the data to CSV and uh do a control F. Although, I do know some who did do that. And some actually turns out didn't even
[19:45] do that. They just reach out to the vendor and said, "Hey, are we impacted by this?" And that uh And so, some orgs did actually get a vendor notification as well. Um Salesforce and or Salesloft reached out to companies that they had detected were
[20:02] impacted and let them know, "Hey, we had a little security incident and you know your data was impacted by this." Now, something that a company like Mandiant or Salesforce can't easily do is run a very thorough, pretty darn
[20:17] thorough if I want to say so, investigation across a wide variety of companies across a lot of different uh tenants or environments. So, when the news broke, um I want to point out that nobody actually knew that uh Google Workspace was also uh a
[20:36] compromised vector. So, Salesloft Drift also had an integration into Google Workspace. And those OAuth tokens had also been stolen. But when the news broke, when Mandiant published it and everybody was picking it up, people were just like, "Oh, it's just Salesforce."
[20:51] So, here's a screenshot. Hopefully, you can see this all right of the actual investigation notebook I used. Uh I like I like I think I mentioned at the a bit earlier, I spin up new investigation notebooks for every attack I I investigate everything I do do so that I can show my boss. And he asked
[21:07] me, "Hey, did you run this query? Do you have a query that checks this?" And I can just say, "Yeah, I have this notebook." Cuz if not, um, I'm going to have to very quickly figure that out. But I ran a cross-org search. Uh, I do it iteratively. As you can probably see, it's a loop, of course, for known IOCs,
[21:24] so in those indicators of compromise. And I started getting results right away cuz it it prints it as it gets results. And I want to say, since I looked for a very long time scope, I think I think I scoped it to 3 months. Uh, it took roughly half an hour to finish. And this gave me all of the customers
[21:41] that had some sort of activity from those indicators of compromise. And if you notice, uh, that is, like I said, that is the exact query I did. I did not, uh, specifically target to target it to be Salesforce. And that's the other reason it took half an hour is cuz it looked across every single SaaS platform that our customers had
[21:58] connected into Obsidian. And that was when, uh, I started to see this these, uh, it wasn't the user agents, it was some specific IP addresses were present in, uh, Google Workforce. Google Workspace.
[22:18] And then I was able to take this, um, and of course with every customer that I I see a little printout, this org has five results. Of course, I'm going to go into our product and I'm going to manually validate that. Cuz I also do this. This is another screenshot from a from a different cell in the notebook. But this essentially uh, says, "Hey, find me all IP addresses
[22:37] in these records that aren't in this list of IP addresses." And you can see I I didn't put included in the the prior screenshot, but I'm actually grabbing stuff from the Databricks file system because my results of these queries that I'm running are storing things in the Databricks file system. Because legal is
[22:53] very, uh, is very strict that we can't do customer data into a spreadsheet. For some reason, I can't think of why I shouldn't be allowed to do that. But, the good news is that putting it in the Databricks file system, of course, it's controlled by the access controls. It's where our data is anyway.
[23:10] And this lets me hold on to this important investigation data for as long as I need it. And then I can work it further. I can do I can I can make small changes to my queries and it stores data in a different place if I tell it to. So, for each customer that we had any
[23:25] hits in, I go and I say, "Hey, look for IP addresses in look for your IP addresses that weren't present in the initial list in all of this data." And it uncovered actually some additional IP addresses that weren't too useful. But, it also uncovered a a new
[23:40] user agent that was not published anywhere. And then I go and I plug that back into my my first cell, I run it again, and then I just sort of work back and forth with this. And of course, um validating that all in the the product as well to sort of make uh make a more
[23:57] holistic picture to me of just everything involved in the incident that we have access to and fully understand the scope of the compromise. And then finally, uh very quickly,
[24:13] within I want to say an hour or two of the incident starting cuz I needed enough time to actually sit down and understand what I was looking at and then start just making all of my making my database like pulling up my my Google Doc to start writing out my my uh opinions on this.
[24:31] Uh we were notifying our customers. We have full links to their activity uh involving this incident in our product. We have what's called a saved search. So, it uh it's global and customers can click it and it pulls up all the IOCs we know. We do breach notifications in the product. Our TAMs were reaching out. It was
[24:48] you know, like level five crisis company-wide. Everybody was was in on this. Everybody had their hands in this and was working to notify customers. And what I think our advantage for this was was that we were notifying customers saying, "Hey, you have this data that
[25:03] was stolen it looks like either in Salesforce and or Google Workspace." And at this point when we were telling customers, like I said, the Google Workspace a compromise wasn't mentioned anywhere. But uh there had also been customers that had either just somehow missed the
[25:18] notification from Salesforce or Salesloft that they'd been uh impacted or they had explicitly reached out to Salesloft or Salesforce and had been told that they were not impacted and that uh was not the case because we had surfaced some additional uh indicators
[25:34] that I I I I guess when um Salesforce or Salesloft did their sweep they just they just hadn't uh they just didn't know about. So, I know that we had some pretty pretty grateful customers after that.
[25:52] And then this is the final portion of this. I want to just talk to you about uh a little bit of detection engineering, some detection patterns you can consider taking home for something like this. So, most integrations have very very consistent baselines and this will
[26:07] include internal integrations. It's going to be things like Python, Node, Curl. The simpler an integration, ideally, the more consistent it's going to be. And baselining for that user agent is going to be one of the best ways when looking at the context of past SaaS
[26:22] supply chain incidents to detect an integration compromise. But then we did also talk a little bit about the problem uh between an anomaly and an attack and, you know, developers are going to be connecting to some random thing with Python to run a random script. So, that can be a bit of a a bit of a tricky
[26:38] problem and that's why, you know, we do we do detection correlation. We don't just want to fire a thousand detections based on a single signal cuz that's noisy and people get mad. So, doing something like uh IP correlation, doing IP prevalence logic is also very important. Hopefully your
[26:55] developers are working on the company network on a VPN or at least from a stable like their home IP. Then they're not spinning up some random VPS that they're they just so happen to be doing their developer activity from. Trust me, I've seen it. They Why they're doing it
[27:10] that way? I don't know. Uh but uh that's a really good way for your developer activity to come across as malicious if they're if they're running it on some random VPS. Uh but if you add the needed logic for IP prevalence, then
[27:28] uh and you don't want to suppress it cuz or totally exclude it. You want to either suppress or add the requirement for some additional signals. But that will help you to get more uh more of an idea just after you've
[27:43] gotten at least a uh detection for something like a a deviation from user agent baseline. But with IP prevalence, I do want to mention um like I said, you don't want to totally exclude it. You want to suppress it or or put in some additional logic for a
[28:00] few reasons. So, VPN compromise or intrusion into corporate networks is very I wouldn't say it's common, but I've seen it before. I've I've dealt with incidents where it happens. And if you totally exclude your corporate network or these these well-known IPs from your some of your
[28:15] specific detections for this, you're going to miss stuff, especially if it just so happens to be an internal uh integration that's compromised and they're in some like one of your pipelines. They're in one of your developer environment to doing something like this, which I've also seen. Um if you exclude those internal corporate locations, you'll be
[28:31] completely blind to this sort of attack. And that unfortunately does further apply to vendor IPs. Uh vendors can and frequently are compromised. And well, most of the time when vendors are compromised, we see them take their off tokens and exploit them from their own infrastructure.
[28:47] Exploiting integrations from a vendor's infrastructure is also something that has historically happened. It hasn't happened recently as far as I'm aware, at least that's made the news, but I dealt with one one incident I want to say two years ago where something like that happened.
[29:06] And then secondly, IP exhaustion is a real thing. There's a there's a finite amount of IPv4 addresses available. So something like AWS is going to have potentially hundreds of customers or hundreds of things running from one IP address. And even though it seems like it would need to be a super rare thing that
[29:22] happens that you have an integration connecting from an IP and an attacker connecting from an IP, I have seen that once. Because I guess nothing is rare in the world of cyber security. So that is that's another reason why you
[29:37] have to be really really careful with with IP prevalence logic sometimes. And then finally, SaaS platforms like to be as uh difficult and different as possible, it seems. So the fields that you might think to
[29:52] rely on for things like uh identity normalization like VPN, email display name, they're probably not going to be too consistent between services, especially once you start getting in these weird edge services that barely have an API that's functional. I'm not calling anybody out in
[30:08] particular. I realize that might have seemed like I was. Um but doing this proper normalization, taking into account all of these edge cases, is going to give you a much greater ability to hunt these threats that traverse SaaS infrastructure, which are becoming more and more common.
[30:27] So what's the TLDR? Well, as might be expected, SaaS supply chain attacks, unfortunately, are often invisible from within a single org. I see the struggle every day when I'm analyzing alerts for our customers cuz every day one of the things I do for like two or three hours a day is just analyze our integration
[30:42] detections as well as analyze our uh detections that actually fire cross-org. So, we're lucky. I can see if one of our customers uh or let's say, for example, three of our customers fired a specific uh a specific detection or they fired a
[30:58] specific alert for one integration from one user agent or IP at the same time. I say, "Hey, that could be a supply chain." So, I'm lucky that I can uh I have the ability to look at that. But if it's just one org, often times I'm looking at these and it's not the clearest thing.
[31:14] So, to that point, um like I said, cross-org and cross uh tenant intelligence, even even with one in one org, one org can have a lot of different SaaS tenants for for a specific product. But this can allow you to detect attacks that impact multiple orgs or multiple tenants.
[31:30] And then finally, normalizing our SaaS data and especially throwing it into Databricks makes my job a lot easier. Um probably makes your job a lot easier if you're here. And it for me, it allows me to quickly be able to understand the scope of a threat. And I mean, I guess it probably
[31:46] benefits our customers as well or something like that. So, this is the obligatory ad slide. Uh if what we do at Obsidian sounds interesting, you know, you can visit our website. I want you to visit our website if you're interested and go to our blog section. I publish our Behind the Breach series. I've written about probably
[32:03] two or three Scattered Spider, Chinese Hackers incidents, and a number of others. Um just general uh most of the time I do incident type breakdowns. Um if that just so happens to be something you're interested in. And then I wanted to also, of course, mention that there's going to be the
[32:19] cybersecurity happy hour tonight at Pizazz. Uh 6:30 p.m. to 8:30 p.m. Obsidian is a sponsor there. Myself and some other people from Obsidian will be present at that event if you want to come say hi and talk about this or really anything else you want to talk
[32:35] about. Uh we'll be there. So, at that point, uh, that's everything I have for you today.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.