Salesforce Related Breaches Continue

We’re going to be going over a campaign that has been ravaging companies recently.

I had previously talked about this campaign in a previous post.

Stepping back to give background, ShinyHunters has been a busy threat actor group over the last few years.

Their notable victims include AT&T, Ticketmaster, and Santander to name a few.

Kind of reminds me of Lapsus$ a few years back. Methodical, using the same attacker tactics, rinse and repeat with ruthless execution.

Also interesting was the targets for this campaign. It looked to be focused on luxury retail, before moving on to insurance, and now other companies.

A batch of data breaches by way of Salesforce.

Here's an overview of how it works

• Use of compromised Salesforce accounts from unrelated companies to register their malicious applications

• Impersonation of IT staff via vishing

• Social Engineering other staff to share credentials or to authorize the malicious app to the victim companies Salesforce

• CRM Access by OAuth

• Abuse of this access

Just to make it clear, this is not due to a vulnerability in the Salesforce platform, but due to OAuth applications being authorized in the platform.

Here's an overview of the companies who have been impacted by this campaign

Birds eye view of the impacted companies

As you can see, there’s been a lot of damage done over the last few months.

But Wait There’s More

A recent development in all of this is due to a breach in the third-party Salesloft Drift app. This is an AI orchestration tool for sales data.

This theft of Salesloft tokens is in addition to the wave of Salesforce data breaches linked explained above.

For now, this newer development looks to only impact those who use the Drift Salesforce integration.

Steps to Counter

What can companies do?

Although certain factors will vary, here are some controls that are table stakes.

• Multi-Factor Authentication (MFA): Phishing-Resistant MFA

• Support Agent Change Control: Fewer exceptions and tighter controls for privilege escalation for help desk interactions

• Allowlisting for connecting apps: an allowlist approach is easier said than done, but will mitigate most of this attack class

• IP-Based Access Restrictions: restricting access to defined Enterpise IP ranges and VPN networks, default deny otherwise

• Segmentation and Least Privilege: Limit internal lateral movement from compromised apps or accounts

Now I understand these aren’t exactly groundbreaking, but it is surprising how many companies are not doing these (some easier said than done as mentioned), and get caught for it.

---

What I Read This Week

• AWS CEO says using AI to replace junior staff is 'Dumbest thing I've ever heard'

  • Coulda told you that a year ago ¯\_(ツ)_/¯

  • More CEO’s will realize this after the cycle comes back down to earth

• Perplexity's Comet browser with security vulnerability

  • Prompt injection, but not in an overly sophisticated way. Literally just a crafted comment

  • Raising the need for explicit user confirmation

  • Is it a bug, or a feature?
    

• Tracking malicious code execution in Python

  • The release of a static analysis library called hexora

  • Going over obfuscation of dangerous actions such as exec and eval

  • This continues to be a challenging area to secure development

• More TOTP accounts (Reddit Discussion)

  • An interesting discussion in the Yubikey subreddit about the limit with time-based one time passcodes

  • For context, this second factor combines usage of the physical key and then uses Yubico Authenticator to generate the time-based passcodes

  • All the more reason to move to FIDO wherever possible, removing this problem and is currently the only non-phishable MFA

---

Wrapping Up

That’s all for now. More to come on this story as it develops.

See you in the next one.

---