When security researchers issued warnings about the Salesloft Drift issues last month, two prominent cybersecurity companies found themselves facing the same threat — but their stories ended up unfolding in different ways. 

Okta and Zscaler, among the larger players in the identity management space, were among the more than 700 Drift customers targeted in what has become one of the most significant supply chain attacks of the year.   Within a week of Google security researchers’ warning about the incident, which targeted the widespread theft of Salesforce customer data, both companies went to work in figuring out how bad the damage would be.  

The companies had very different experiences. While Okta’s security measures thwarted any lasting damage, Zscaler wasn’t as lucky, having to deal with unauthorized access of both customer and internal company data. Same threat actor. Same timeline. Opposite outcomes.

The divergence in incidents and responses offers a rare opportunity to understand how a cybersecurity strategy works in action. CyberScoop spoke with the security leaders of both companies to learn about how the attack went down from those directly in its crosshairs, and lessons learned that could bolster defenses of their companies and others going forward.

From warning to incident

Salesloft hasn’t publicly released a comprehensive root-cause analysis into the attack, but initial results of its investigation revealed a threat group gained access to its GitHub account as far back as March. The group, which Google tracks as UNC6395, achieved lateral movement and set up workflows in the Salesloft application environment before it accessed Drift’s Amazon Web Services environment and obtained OAuth tokens used by Drift customers. 

Those tokens allowed the threat group to access and steal data from separate platforms integrated with Drift, an AI chat agent primarily used by sales teams. Google said the “widespread data theft campaign” occurred during a 10-day period in mid-August. Nearly 40 companies, including more than 20 cybersecurity vendors, have publicly disclosed they were caught up in the attack spree.

Zscaler received its first security alert from Salesforce a week after the data theft concluded, warning the security vendor that unauthorized IP addresses were using the application programming interface (API) for its Drift OAuth token. Zscaler immediately revoked the token, “even though it didn’t really matter by that point,” said Sam Curry, the company’s chief information security officer.

The damage was already done. Data on a large number of Zscaler’s customers was exposed, including names, business email addresses, job titles, phone numbers, location details, Zscaler product licensing and commercial information, and plain text content from some support cases. 

IP limitations for defense

Since Okta uses Drift, it proactively hunted for signs of compromise when threat intel experts started warning about an issue with the service. The company found a “short burst of attempts” to use Drift tokens from locations outside of the manually configured IP range it set up for security purposes, David Bradbury, Okta’s chief security officer, told CyberScoop.

That control blocked the attack and kept Okta’s Drift integrations secure. Yet, many companies don’t take that approach because setting IP restrictions for API calls is a manual and often laborious process requiring input and support from every vendor in the supply chain. 

“If we can put our minds to these problems, we can come up with solutions so that you can implement IP restrictions in a matter of clicks, rather than in a matter of days and weeks of continuous testing, and investigation and discovery,” Bradbury said.

Okta’s investigation revealed a seemingly automated threat campaign. “They were not persistent,” Bradbury said. “The hypothesis that we have at the moment is that there was a single significant script that was engineered that hit all of these all at once and pulled down all of this information in a series of events.”

Zscaler’s compromise was particularly frustrating given the timing: the company had already stopped using Drift in July, a decision completely unrelated to security — and made before any indicators of the attack campaign came to light. 

“That OAuth token that was being used with [Drift] was still active,” Curry said. “It was due to be retired by the end of August,” he added, describing that decision as a deliberate delay to make sure the token was fully disconnected and no longer in use. 

Token theft cause remains a mystery

Salesloft hasn’t explained how the threat group accessed its GitHub account, nor how it accessed Drift’s AWS environment and ultimately obtained customers’ OAuth tokens. 

“I don’t actually know how they got the tokens out. I just know they did,” Curry said. “As for how they store it, I don’t know internally, except that they passed our security questionnaire and probably hundreds, if not thousands of others” for third-party risk management, he added. 

Okta also doesn’t know how the threat group accessed its Salesloft Drift OAuth token. That information would have to come from Salesloft, Bradbury said.

“The internet is connected by some very brittle, small pieces of information — these tokens that we constantly talk about, these combinations of letters and numbers in files that ultimately provide access to all of the applications that we use,” he said. 

“Those tokens need to be stored somewhere, and sadly there are mechanisms in place right now which doesn’t necessitate actually tying these tokens directly to something — to prevent their reuse,” Bradbury added. 

Most SaaS applications implement tokens and authentication in rather rudimentary means. “They’re doing what’s easy and what works, and what works is once you’ve granted access you’re actually storing these tokens somewhere,” he said. 

Lessons learned for collective defense

While their experiences in the wake of the Salesloft Drift attacks were quite different, Bradbury and Curry shared similar reflections and took many like-minded lessons from the third-party compromise that impacted hundreds of companies. 

“APIs are becoming a new highway of access that we need more control over, and we need better control of collectively,” Curry said. “APIs get wider in terms of what you can do with them, and you need the ability to monitor them and to put preventative controls on them to look for behavioral changes.”

Zscaler learned another lesson the hard way — the importance of limiting IP address ranges for API queries, and rotating tokens more frequently. 

“For me, this wake-up call is saying API is a new attack-and-control plane that’s far more exposed than most people realize from just a simple risk exercise,” Curry said.

“There are no small vendors in an API-connected world. It’s just like — if you think about border security — there’s no small and insignificant ports of entry,” he added. “They all use the same highway systems.”

Bradbury, who is expectedly pleased Okta wasn’t impacted by this malicious campaign, can’t help but feel frustrated because he believes there are better, more secure methods to protect unauthorized token use. The central issue in this supply-chain attack could have been avoided with Demonstrating Proof of Possession (DPoP), a mechanism that can constrain token use to a specific client and prevent the use of stolen tokens, he said. 

Once attackers steal tokens that can be reused without restriction, disastrous consequences await all, Bradbury added. 

“We need to see more SaaS vendors actually prioritizing security features on their roadmap, not just the features that will result in customer growth and revenue,” he said. 

Security leaders have an important role to play in demanding these changes from their vendors. “It’s about time that we started to use our collective ambitions to raise the bar for security to actually hold our vendors accountable,” Bradbury said. 

Curry is taking a similar forward-looking approach. “Let’s learn from one another, instead of bayoneting the wounded,” he said. 

“After the fact, in the cold light of day, we’ll all look at what happened,” Curry added. “I’m not interested in blame at this point. I’m interested in better security.”

The post Security leaders at Okta and Zscaler share lessons from Salesloft Drift attacks appeared first on CyberScoop.

Google Threat Intelligence Group warned about a “widespread data theft campaign” that compromised hundreds of Salesforce customers over a 10-day span earlier this month. 

According to a report published Tuesday, researchers say a threat group Google tracks as UNC6395 stole large volumes of data from Salesforce customer instances by using stolen OAuth tokens from Salesloft Drift, a third-party AI chat agent for sales and leads. Google said the attack spree occurred from at least Aug. 8 to Aug. 18.

“GTIG is aware of over 700 potentially impacted organizations,” Austin Larsen, principal threat analyst at GTIG, told CyberScoop. “The threat actor used a Python tool to automate the data theft process for each organization that was targeted.”

The attackers primarily sought to steal credentials to compromise other systems connected to the initial victims, according to Google. UNC6395 specifically searched for Amazon Web Services access keys, virtual private network credentials and Snowflake credentials.

“Using a single token stolen from Salesloft, the threat actor was able to access tokens for any Drift linked organization. The threat actor then used the Salesforce tokens to directly access that data and exfiltrate it to servers, where they looked for plaintext credentials including Amazon, Snowflake and other passwords,” said Tyler McLellan, principal threat analyst at GTIG.

Mandiant Consulting, Google’s incident response firm, hasn’t observed further use of the stolen credentials in any current investigations, he said. 

Salesloft confirmed the intrusions in a security update Monday and said all impacted customers have been notified. The company first issued an alert about malicious activity targeting Salesloft Drift applications integrated with Salesforce Aug. 19. 

Salesloft said it worked with Salesforce to revoke all active access and refresh tokens for the application and asserts the impact is limited to customers integrated with Salesforce. Google said the attacks stopped once Salesloft and Salesforce revoked access on Aug. 20. 

Salesforce, in a statement Tuesday, said a “small number of customers” were impacted, adding “this issue did not stem from a vulnerability within the core Salesforce platform, but rather from a compromise of the app’s connection.” 

Google advised Salesloft Drift customers integrated with Salesforce to consider their data compromised, search for secrets contained in their Salesforce instances and remediate by revoking API keys, rotating credentials and investigating further. 

Google hasn’t yet determined UNC6395’s origins or motivations. The attack spree was “broad and opportunistic, and appeared to take advantage of any organization using the Salesloft Drift integration with Salesforce,” McLellan said.

AppOmni CSO Cory Michal said the compromise and abuse of OAuth tokens and cloud-to-cloud integrations are a longtime known blind spot in most enterprises. Yet, the sheer scale and discipline of the attacks is surprising, he said. 

“The attacker methodically queried and exported data across many environments,” Michal added. “They demonstrated a high level of operational discipline, running structured queries, searching specifically for credentials, and even attempting to cover their tracks by deleting jobs. The combination of scale, focus and tradecraft makes this campaign stand out.”

The post Hundreds of Salesforce customers impacted by attack spree linked to third-party AI agent appeared first on CyberScoop.

KrebsOnSecurity recently heard from a reader whose boss’s email account got phished and was used to trick one of the company’s customers into sending a large payment to scammers. An investigation into the attacker’s infrastructure points to a long-running Nigerian cybercrime ring that is actively targeting established companies in the transportation and aviation industries.

A reader who works in the transportation industry sent a tip about a recent successful phishing campaign that tricked an executive at the company into entering their credentials at a fake Microsoft 365 login page. From there, the attackers quickly mined the executive’s inbox for past communications about invoices, copying and modifying some of those messages with new invoice demands that were sent to some of the company’s customers and partners.

Speaking on condition of anonymity, the reader said the resulting phishing emails to customers came from a newly registered domain name that was remarkably similar to their employer’s domain, and that at least one of their customers fell for the ruse and paid a phony invoice. They said the attackers had spun up a look-alike domain just a few hours after the executive’s inbox credentials were phished, and that the scam resulted in a customer suffering a six-figure financial loss.

The reader also shared that the email addresses in the registration records for the imposter domain — roomservice801@gmail.com — is tied to many such phishing domains. Indeed, a search on this email address at DomainTools.com finds it is associated with at least 240 domains registered in 2024 or 2025. Virtually all of them mimic legitimate domains for companies in the aerospace and transportation industries worldwide.

An Internet search for this email address reveals a humorous blog post from 2020 on the Russian forum hackware[.]ru, which found roomservice801@gmail.com was tied to a phishing attack that used the lure of phony invoices to trick the recipient into logging in at a fake Microsoft login page. We’ll come back to this research in a moment.

JUSTY JOHN

DomainTools shows that some of the early domains registered to roomservice801@gmail.com in 2016 include other useful information. For example, the WHOIS records for alhhomaidhicentre[.]biz reference the technical contact of “Justy John” and the email address justyjohn50@yahoo.com.

A search at DomainTools found justyjohn50@yahoo.com has been registering one-off phishing domains since at least 2012. At this point, I was convinced that some security company surely had already published an analysis of this particular threat group, but I didn’t yet have enough information to draw any solid conclusions.

DomainTools says the Justy John email address is tied to more than two dozen domains registered since 2012, but we can find hundreds more phishing domains and related email addresses simply by pivoting on details in the registration records for these Justy John domains. For example, the street address used by the Justy John domain axisupdate[.]net — 7902 Pelleaux Road in Knoxville, TN — also appears in the registration records for accountauthenticate[.]com, acctlogin[.]biz, and loginaccount[.]biz, all of which at one point included the email address rsmith60646@gmail.com.

That Rsmith Gmail address is connected to the 2012 phishing domain alibala[.]biz (one character off of the Chinese e-commerce giant alibaba.com, with a different top-level domain of .biz). A search in DomainTools on the phone number in those domain records — 1.7736491613 — reveals even more phishing domains as well as the Nigerian phone number “2348062918302” and the email address michsmith59@gmail.com.

DomainTools shows michsmith59@gmail.com appears in the registration records for the domain seltrock[.]com, which was used in the phishing attack documented in the 2020 Russian blog post mentioned earlier. At this point, we are just two steps away from identifying the threat actor group.

The same Nigerian phone number shows up in dozens of domain registrations that reference the email address sebastinekelly69@gmail.com, including 26i3[.]net, costamere[.]com, danagruop[.]us, and dividrilling[.]com. A Web search on any of those domains finds they were indexed in an “indicator of compromise” list on GitHub maintained by Palo Alto Networks‘ Unit 42 research team.

SILVERTERRIER

According to Unit 42, the domains are the handiwork of a vast cybercrime group based in Nigeria that it dubbed “SilverTerrier” back in 2014. In an October 2021 report, Palo Alto said SilverTerrier excels at so-called “business e-mail compromise” or BEC scams, which target legitimate business email accounts through social engineering or computer intrusion activities. BEC criminals use that access to initiate or redirect the transfer of business funds for personal gain.

Palo Alto says SilverTerrier encompasses hundreds of BEC fraudsters, some of whom have been arrested in various international law enforcement operations by Interpol. In 2022, Interpol and the Nigeria Police Force arrested 11 alleged SilverTerrier members, including a prominent SilverTerrier leader who’d been flaunting his wealth on social media for years. Unfortunately, the lure of easy money, endemic poverty and corruption, and low barriers to entry for cybercrime in Nigeria conspire to provide a constant stream of new recruits.

BEC scams were the 7th most reported crime tracked by the FBI’s Internet Crime Complaint Center (IC3) in 2024, generating more than 21,000 complaints. However, BEC scams were the second most costly form of cybercrime reported to the feds last year, with nearly $2.8 billion in claimed losses. In its 2025 Fraud and Control Survey Report, the Association for Financial Professionals found 63 percent of organizations experienced a BEC last year.

Poking at some of the email addresses that spool out from this research reveals a number of Facebook accounts for people residing in Nigeria or in the United Arab Emirates, many of whom do not appear to have tried to mask their real-life identities. Palo Alto’s Unit 42 researchers reached a similar conclusion, noting that although a small subset of these crooks went to great lengths to conceal their identities, it was usually simple to learn their identities on social media accounts and the major messaging services.

Palo Alto said BEC actors have become far more organized over time, and that while it remains easy to find actors working as a group, the practice of using one phone number, email address or alias to register malicious infrastructure in support of multiple actors has made it far more time consuming (but not impossible) for cybersecurity and law enforcement organizations to sort out which actors committed specific crimes.

“We continue to find that SilverTerrier actors, regardless of geographical location, are often connected through only a few degrees of separation on social media platforms,” the researchers wrote.

FINANCIAL FRAUD KILL CHAIN

Palo Alto has published a useful list of recommendations that organizations can adopt to minimize the incidence and impact of BEC attacks. Many of those tips are prophylactic, such as conducting regular employee security training and reviewing network security policies.

But one recommendation — getting familiar with a process known as the “financial fraud kill chain” or FFKC — bears specific mention because it offers the single best hope for BEC victims who are seeking to claw back payments made to fraudsters, and yet far too many victims don’t know it exists until it is too late.

As explained in this FBI primer, the International Financial Fraud Kill Chain is a partnership between federal law enforcement and financial entities whose purpose is to freeze fraudulent funds wired by victims. According to the FBI, viable victim complaints filed with ic3.gov promptly after a fraudulent transfer (generally less than 72 hours) will be automatically triaged by the Financial Crimes Enforcement Network (FinCEN).

The FBI noted in its IC3 annual report (PDF) that the FFKC had a 66 percent success rate in 2024. Viable ic3.gov complaints involve losses of at least $50,000, and include all records from the victim or victim bank, as well as a completed FFKC form (provided by FinCEN) containing victim information, recipient information, bank names, account numbers, location, SWIFT, and any additional information.

This blog will be referencing the ICS/OT Backdoors & Breaches expansion deck created by BHIS and Dragos. We will be reviewing the ICS-focused Initial Compromise cards that are used to simulate a cyber incident and suggest potential mitigations to what is presented.

The post ICS Hard Knocks: Mitigations to Scenarios Found in ICS/OT Backdoors & Breaches appeared first on Black Hills Information Security, Inc..

Patterson Cake // In PART 1 of “Wrangling the M365 UAL,” we talked about the value of the Unified Audit Log (UAL), some of the challenges associated with acquisition, parsing, […]

The post Wrangling the M365 UAL with SOF-ELK on EC2 (Part 2 of 3) appeared first on Black Hills Information Security, Inc..

Patterson Cake // When it comes to M365 audit and investigation, the “Unified Audit Log” (UAL) is your friend. It can be surly, obstinate, and wholly inadequate, but your friend […]

The post Wrangling the M365 UAL with PowerShell and SOF-ELK (Part 1 of 3) appeared first on Black Hills Information Security, Inc..

Jordan Drysdale//* In this blog, we are assuming that we have obtained an access key, a secret key and maybe a .pem key from a network user who left these […]

The post AWS: Assuming Access Key Compromise appeared first on Black Hills Information Security, Inc..