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.

Multiple security and technology companies have been swept up in a far-reaching attack spree originating at Salesloft Drift, including Cloudflare, PagerDuty, Palo Alto Networks, SpyCloud and Zscaler. 

Victim organizations continue to come forward as customers of the third-party AI chat agent hunt for evidence of compromise or receive notices from Salesloft and other companies involved in response, recovery and ongoing attack investigations. 

Salesloft initially claimed exposure was limited to customers integrated with Salesforce. Yet, Google Threat Intelligence Group and Mandiant Consulting — Google’s incident response firm which is now working with Salesloft — said any platform integrated with Drift is potentially compromised. 

The root cause of the attacks, specifically how the threat group that Google tracks as UNC6395 gained initial access to Salesloft Drift, remains unconfirmed. “There is no evidence of any unusual or malicious activity with the Salesloft platform,” Salesloft said in an update Saturday.

On Monday, the company said “Drift will be taken offline in the very near future,” rendering the platform inaccessible and the Drift chatbot unavailable on customer websites. “This will provide the fastest path forward to comprehensively review the application and build additional resiliency and security in the system to return the application to full functionality,” the company added.

Salesloft, which acquired Drift in February 2024, has not responded to requests for comment since news of the attacks first surfaced last week. 

The company announced an agreement to merge with Clari, a competitor in the customer-relationship management space, one day before the attacks started Aug. 8. In the merger announcement, the combined companies said they will serve more than 5,000 organizations globally across all industries.

The exposure caused by the attacks has cast widespread concern, as customers seek clarity about the unfolding disaster. Salesloft customers are assessing if they were impacted, and then sifting through data to determine the extent to which they or their customers were compromised. 

The attacks did not hit every Salesloft Drift customer. Some Salesloft Drift customers, when contacted by CyberScoop, confirmed they were not implicated by the attacks and found no evidence that corporate or customer data was compromised. 

Okta said it was not impacted by the incident, but confirmed it was a target based on indicators of compromise Google Threat Intelligence Group shared last week. “The threat actor attempted to use a compromised token to access our Salesforce instance, but the attack failed because the connection originated from an unauthorized IP address,” the company said in a blog post Tuesday.

Many other businesses were less fortunate.

Sam Curry, chief information security officer at Zscaler, said the company’s Salesloft Drift integration with Salesforce was the point of unauthorized access. The company was using Salesloft Drift integrated with other platforms, but they were not impacted, he added. 

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. 

“No product, service, or infrastructure was affected,” Curry said. “We are looking to hear from Salesloft Drift and from Salesforce if there are any other findings since this happened in their infrastructure.”

Curry said Zscaler was already in the process of ending its relationship with Salesloft Drift for unrelated reasons. 

Palo Alto Networks on Tuesday confirmed that it, too, was one of hundreds of organizations impacted by the supply chain attack. The company’s incident response business Unit 42 confirmed the incident was limited to its Salesforce environment, adding that no Palo Alto Networks products or services were impacted. 

“Most of the exfiltrated data was business contact information,” a Palo Alto Networks spokesperson told CyberScoop in an email. “However, a small number of customers who included sensitive information, such as credentials, in their recent case notes might also have had that data compromised.”

Cloudflare said any information customers shared with the company’s support system — including logs, tokens or passwords — should be considered compromised. The company said it found 104 Cloudflare API tokens in the compromised data and, while it found no evidence of abuse, rotated the tokens out of an abundance of caution.

The company also maintained that no Cloudflare services or infrastructure were compromised. 

“We are responsible for the choice of tools we use in support of our business,” a group of Cloudflare security leaders said in a blog post Tuesday. “This breach has let our customers down. For that, we sincerely apologize.”

Former Salesloft Drift customers were impacted as well. In a blog post announcing some data contained in its Salesforce environment was exposed, SpyCloud said it was previously a customer of Salesloft and Drift, but not currently.

Google previously said the data theft campaign occurred over a 10-day period last month, potentially impacting more than 700 organizations.

The post Salesloft Drift attacks hit Cloudflare, Palo Alto Networks, Zscaler appeared first on CyberScoop.

The U.S. government today unsealed criminal charges against 16 individuals accused of operating and selling DanaBot, a prolific strain of information-stealing malware that has been sold on Russian cybercrime forums since 2018. The FBI says a newer version of DanaBot was used for espionage, and that many of the defendants exposed their real-life identities after accidentally infecting their own systems with the malware.

Initially spotted in May 2018 by researchers at the email security firm Proofpoint, DanaBot is a malware-as-a-service platform that specializes in credential theft and banking fraud.

Today, the U.S. Department of Justice unsealed a criminal complaint and indictment from 2022, which said the FBI identified at least 40 affiliates who were paying between $3,000 and $4,000 a month for access to the information stealer platform.

The government says the malware infected more than 300,000 systems globally, causing estimated losses of more than $50 million. The ringleaders of the DanaBot conspiracy are named as Aleksandr Stepanov, 39, a.k.a. “JimmBee,” and Artem Aleksandrovich Kalinkin, 34, a.k.a. “Onix”, both of Novosibirsk, Russia. Kalinkin is an IT engineer for the Russian state-owned energy giant Gazprom. His Facebook profile name is “Maffiozi.”

According to the FBI, there were at least two major versions of DanaBot; the first was sold between 2018 and June 2020, when the malware stopped being offered on Russian cybercrime forums. The government alleges that the second version of DanaBot — emerging in January 2021 — was provided to co-conspirators for use in targeting military, diplomatic and non-governmental organization computers in several countries, including the United States, Belarus, the United Kingdom, Germany, and Russia.

“Unindicted co-conspirators would use the Espionage Variant to compromise computers around the world and steal sensitive diplomatic communications, credentials, and other data from these targeted victims,” reads a grand jury indictment dated Sept. 20, 2022. “This stolen data included financial transactions by diplomatic staff, correspondence concerning day-to-day diplomatic activity, as well as summaries of a particular country’s interactions with the United States.”

The indictment says the FBI in 2022 seized servers used by the DanaBot authors to control their malware, as well as the servers that stored stolen victim data. The government said the server data also show numerous instances in which the DanaBot defendants infected their own PCs, resulting in their credential data being uploaded to stolen data repositories that were seized by the feds.

“In some cases, such self-infections appeared to be deliberately done in order to test, analyze, or improve the malware,” the criminal complaint reads. “In other cases, the infections seemed to be inadvertent – one of the hazards of committing cybercrime is that criminals will sometimes infect themselves with their own malware by mistake.”

A statement from the DOJ says that as part of today’s operation, agents with the Defense Criminal Investigative Service (DCIS) seized the DanaBot control servers, including dozens of virtual servers hosted in the United States. The government says it is now working with industry partners to notify DanaBot victims and help remediate infections. The statement credits a number of security firms with providing assistance to the government, including ESET, Flashpoint, Google, Intel 471, Lumen, PayPal, Proofpoint, Team CYMRU, and ZScaler.

It’s not unheard of for financially-oriented malicious software to be repurposed for espionage. A variant of the ZeuS Trojan, which was used in countless online banking attacks against companies in the United States and Europe between 2007 and at least 2015, was for a time diverted to espionage tasks by its author.

As detailed in this 2015 story, the author of the ZeuS trojan created a custom version of the malware to serve purely as a spying machine, which scoured infected systems in Ukraine for specific keywords in emails and documents that would likely only be found in classified documents.

The public charging of the 16 DanaBot defendants comes a day after Microsoft joined a slew of tech companies in disrupting the IT infrastructure for another malware-as-a-service offering — Lumma Stealer, which is likewise offered to affiliates under tiered subscription prices ranging from $250 to $1,000 per month. Separately, Microsoft filed a civil lawsuit to seize control over 2,300 domain names used by Lumma Stealer and its affiliates.

Further reading:

Danabot: Analyzing a Fallen Empire

ZScaler blog: DanaBot Launches DDoS Attack Against the Ukrainian Ministry of Defense

Flashpoint: Operation Endgame DanaBot Malware

Team CYMRU: Inside DanaBot’s Infrastructure: In Support of Operation Endgame II

March 2022 criminal complaint v. Artem Aleksandrovich Kalinkin

September 2022 grand jury indictment naming the 16 defendants