SaaS and SSO attacks without malware: closing the door EDR cannot see

In recent weeks, two extortion clusters identified as Cordial Spider and Snarky Spider have operated exclusively on SaaS environments such as Salesforce, Workday, and Snowflake. The technique uses no malware, does not touch the endpoint, and does not trigger classic EDR/XDR alerts. It combines targeted vishing, social engineering of the help desk, and IdP abuse to obtain legitimate access.

For an SMB with three or more critical SaaS apps behind SSO, endpoint-only detection leaves a large gap. Defense relies on IdP hardening, activity reviews inside each SaaS, and help desk processes that do not reset MFA on a phone call.

Short answer

Effective control sits in four layers: strong IdP identity, hardened configuration inside each SaaS, logging and review of relevant events, and a help desk process with strong verification. Without those four layers, a well-prepared call is enough to get in.

Why traditional defense fails

Common assumption	Reality with these actors
”EDR will see it”	There is no binary, process, or hash to detect
”MFA is enough”	The attacker tricks the help desk into resetting it
”SSO is secure”	Abuse happens inside valid SSO tokens
”We will see SaaS logs if something happens”	Without alerts, nobody looks until the incident

The problem is not purely technical. It is process and configuration.

Surface map

Layer	Main risk
Identity (IdP)	MFA reset, persistent sessions, unmanaged devices
SaaS per vendor	Broad permissions, mass export, unknown integrations
Help desk	Verification based only on public employee data
Visibility	Decentralized logs without actionable alerts

Any of the four layers can be the weak link. The attacker finds the softest one.

Hardening per identity provider

Provider	Concrete controls
Okta	Hardware MFA (FIDO2), managed-device policies, IP restrictions for admin, weekly “system log” review
Microsoft Entra ID	Risk-based Conditional Access, compliant devices, legacy auth blocked, “sign-in logs” review
Google Workspace	Mandatory 2SV with security keys for admin, “Admin alerts”, OAuth restricted to trusted apps
Auth0	Adaptive MFA, origin restrictions, tenant log review

The common denominator: hardware-based or passkey MFA, short admin sessions, IP allowlists on management consoles, and periodic review of anomalous activity.

Hardening per critical SaaS

SaaS	Concrete controls
Salesforce	Disable mass export per profile, IP login ranges, Event Monitoring on
Workday	Restrict “Implementer” roles, review third-party OAuth apps
Snowflake	Network policies per warehouse, column masking, “ACCOUNT_USAGE” reviews
Microsoft 365	Audit log on, OneDrive/SharePoint exfiltration alerts, eDiscovery control
HubSpot / CRM	Export restrictions, integration and API key reviews

You do not need an SSPM tool to start. You do need someone who reviews the base configuration every quarter.

Help desk process

Typical abuse happens through a call requesting an MFA reset or a phone number change. The countermeasures are simple and uncomfortable at the same time:

1. Out-of-band verification through a different channel from the request.
2. Direct manager approval for sensitive actions.
3. Holding period before applying critical changes.
4. Full record of every help desk action with reason.
5. Specific help desk training on common vishing pretexts.
6. Explicit policy: “if in doubt, no change is made”.

The discomfort is the price of avoiding the attack. The team needs to understand why.

Useful detection without a dedicated SOC

Signal	Where to look	Frequency
Login from new IP at unusual hour	IdP logs	Daily with alert
MFA reset or phone number change	Help desk + IdP	Each case, logged
Mass export in CRM or ERP	SaaS logs	Weekly
OAuth app or API key creation	Each SaaS	Change triggers review
Login without managed device	Conditional Access	Daily with alert
Configuration change in admin console	IdP audit log	Each change, logged

For a budget-constrained SMB, a shared inbox with filtered alerts and weekly review covers most of the value.

Common mistakes

1. Confusing having SSO with having identity security.
2. Allowing MFA resets via call without verification.
3. Leaving third-party OAuth apps without periodic review.
4. Not classifying who is “full admin” in each SaaS.
5. Enabling logging and assigning nobody to review it.
6. Treating Salesforce, Workday, or Snowflake as “the vendor’s responsibility”.

Progress indicators

Indicator	Good	Bad
Hardware MFA for admin	Across every console	Software only for some
Conditional Access	Risk- and device-based rules	”Allow all”
Help desk verification	Documented dual-channel	Call and immediate reset
SaaS logs	Centralized with alerts	On but unread
OAuth app inventory	Known and reviewed	List never consulted

When to invest more

A SaaS Security Posture Management (SSPM) tool makes sense above a certain number of critical SaaS apps or when the team cannot sustain manual reviews with quality. Before that, native vendor controls cover most of the risk.

Final criterion

Actors operating in SaaS and SSO do not look for a technical vulnerability. They look for weak processes. Effective defense combines measurable hardening, strong help desk verification, and periodic log review. For an SMB, that is achievable without hiring a SOC.

Working sources

• Activity reports on Cordial Spider and Snarky Spider in SaaS environments.
• Official documentation from Okta, Microsoft Entra ID, and Google Workspace for identity controls.
• SSPM best practices applied to Salesforce, Workday, and Snowflake.
• Technical decisions must be adapted to each company’s sector, size, and processed data.