Ciberseguridad 4 min de lectura
Ataques SaaS y SSO sin malware: cómo cerrar la puerta que el EDR no ve
Guía técnica para PYMEs ante actores como Cordial Spider y Snarky Spider que operan dentro de Salesforce, Workday y Snowflake usando vishing y abuso de SSO. Hardening por proveedor y monitorización útil.
En este artículo +
En las últimas semanas dos clusters de extorsión, identificados como Cordial Spider y Snarky Spider, han operado exclusivamente sobre entornos SaaS como Salesforce, Workday y Snowflake. La técnica no usa malware, no toca el endpoint y no genera alertas EDR/XDR clásicas. Combina vishing dirigido, ingeniería social al help desk y abuso del proveedor de identidad para obtener accesos legítimos.
Para una PYME con tres o más SaaS críticos detrás de SSO, el modelo de detección basado solo en endpoint deja un hueco grande. La defensa pasa por hardening del IdP, revisión de actividad dentro de cada SaaS y procesos de help desk que no reseteen MFA por una llamada.
Respuesta corta
El control efectivo está en cuatro capas: identidad robusta en el IdP, configuración endurecida dentro de cada SaaS, registro y revisión de eventos relevantes y un proceso de help desk con verificación fuerte. Sin esas cuatro capas, una llamada bien hecha basta para entrar.
Por qué falla la defensa tradicional
| Suposición habitual | Realidad ante estos actores |
|---|---|
| ”El EDR lo verá” | No hay binario, ni proceso, ni hash que detectar |
| ”MFA basta” | El atacante engaña al help desk para resetearlo |
| ”El SSO es seguro” | El abuso ocurre dentro de tokens válidos del SSO |
| ”Los logs del SaaS los vemos si pasa algo” | Sin alertas, nadie los mira hasta el incidente |
El problema no es técnico-tecnológico. Es de proceso y configuración.
Mapa de superficie
| Capa | Riesgo principal |
|---|---|
| Identidad (IdP) | Reseteo de MFA, sesión persistente, dispositivos no gestionados |
| SaaS por proveedor | Permisos amplios, exportación masiva, integraciones desconocidas |
| Help desk | Verificación basada solo en datos públicos del empleado |
| Visibilidad | Logs sin centralizar y sin alertas accionables |
Cualquiera de las cuatro capas puede ser el eslabón débil. El atacante encuentra el más blando.
Hardening por proveedor de identidad
| Proveedor | Controles concretos |
|---|---|
| Okta | MFA hardware (FIDO2), políticas por dispositivo gestionado, restricción de IP en admin, revisión de “system log” semanal |
| Microsoft Entra ID | Conditional Access con riesgo, dispositivos compliant, bloqueo legacy auth, revisión de “sign-in logs” |
| Google Workspace | 2SV obligatorio con llaves de seguridad para admin, alertas en “Admin alerts”, restricción de OAuth a apps confiables |
| Auth0 | MFA adaptativo, restricción de orígenes, revisión de tenant logs |
El denominador común: MFA basada en hardware o passkey, sesiones cortas para administradores, allowlist de IP en consolas de gestión y revisión periódica de actividad anómala.
Hardening por SaaS crítico
| SaaS | Controles concretos |
|---|---|
| Salesforce | Desactivar exportación masiva por perfil, IP login ranges, Event Monitoring activo |
| Workday | Restringir usuarios con permisos de “Implementer”, revisar OAuth apps de terceros |
| Snowflake | Network policies por warehouse, masking en columnas sensibles, revisión de “ACCOUNT_USAGE” |
| Microsoft 365 | Audit log activado, alertas en exfiltración OneDrive/SharePoint, control de eDiscovery |
| HubSpot / CRM | Restricciones de exportación, revisión de integraciones y API keys |
No hace falta una herramienta SSPM para empezar. Sí hace falta una persona que repase trimestralmente la configuración base.
Proceso del help desk
El abuso típico ocurre por una llamada que pide reseteo de MFA o cambio de número de teléfono. Las contramedidas son simples y a la vez incómodas:
- Verificación fuera de banda con un canal distinto al solicitado.
- Aprobación del manager directo para acciones sensibles.
- Periodo de retención antes de aplicar cambios críticos.
- Registro completo de cada acción del help desk con motivo.
- Capacitación específica del help desk en pretextos comunes de vishing.
- Política explícita de “ante la duda, no se cambia”.
La incomodidad es el coste de evitar el ataque. El equipo debe entender por qué.
Detección útil sin SOC dedicado
| Señal | Dónde mirar | Frecuencia |
|---|---|---|
| Inicio de sesión desde IP nueva en horario inusual | Logs IdP | Diaria con alerta |
| Reseteo de MFA o cambio de teléfono | Help desk + IdP | Cada caso, registrado |
| Exportación masiva en CRM o ERP | Logs del SaaS | Semanal |
| Creación de OAuth app o API key | Cada SaaS | Cambio activa revisión |
| Inicio de sesión sin dispositivo gestionado | Conditional Access | Diaria con alerta |
| Cambio de configuración en consola admin | Audit log IdP | Cada cambio, registrado |
Para una PYME con presupuesto limitado, un buzón compartido con alertas filtradas y revisión semanal cubre la mayor parte del valor.
Errores frecuentes
- Confundir tener SSO con tener seguridad de identidad.
- Permitir reseteos de MFA por llamada sin verificación.
- Dejar OAuth apps de terceros sin revisión periódica.
- No clasificar quién es admin “completo” en cada SaaS.
- Activar logging y no asignar a nadie su revisión.
- Tratar Salesforce, Workday o Snowflake como “responsabilidad del proveedor”.
Indicadores de avance
| Indicador | Bueno | Malo |
|---|---|---|
| MFA por hardware en admin | Implantado en todas las consolas | Solo software para algunos |
| Conditional Access | Reglas por riesgo y dispositivo | ”Permitir todo” |
| Verificación help desk | Doble canal documentado | Llamada y reseteo inmediato |
| Logs SaaS | Centralizados con alertas | Activos pero nadie mira |
| Inventario de OAuth apps | Conocido y revisado | Lista no consultada nunca |
Cuándo invertir más
Una herramienta de SaaS Security Posture Management (SSPM) tiene sentido a partir de un cierto número de SaaS críticos o cuando el equipo no puede sostener la revisión manual con calidad. Antes de eso, los controles nativos de cada proveedor cubren la mayor parte del riesgo.
Criterio final
Los actores que operan en SaaS y SSO no buscan una vulnerabilidad técnica. Buscan procesos débiles. La defensa eficaz combina hardening medible, verificación fuerte en el help desk y revisión periódica de logs. Para una PYME, eso es alcanzable sin contratar un SOC.
Fuentes de trabajo
- Reportes de actividad de Cordial Spider y Snarky Spider sobre entornos SaaS.
- Documentación oficial de Okta, Microsoft Entra ID y Google Workspace para controles de identidad.
- Buenas prácticas de SSPM aplicadas a Salesforce, Workday y Snowflake.
- Las decisiones técnicas deben adaptarse al sector, tamaño y datos tratados de cada empresa.
