SharePoint como puerta de entrada al ransomware: checklist de defensas para equipos .NET/M365

SharePoint como puerta de entrada al ransomware: checklist de defensas para equipos .NET/M365

Tu granja de SharePoint puede ser la puerta del ransomware. Checklist accionable para endurecer, segmentar y monitorizar antes de que sea tarde.
05-10-2026 • 8 min de lectura • 0 visitas
Compartir:

La historia se repite: una app interna, un portal de colaboración o un viejo SharePoint on‑prem se convierte en la puerta por la que entra el ransomware. No por magia, sino por falta de hardening básico.

A raíz de las tácticas de Warlock explotando fallos de SharePoint (The Hacker News), aquí va un checklist muy concreto para que tu granja o tenant M365 no sea el eslabón débil.

Enfocado a equipos .NET/M365: cosas que puedes empezar a revisar mañana.

1. Entiende el riesgo específico de SharePoint

SharePoint es especialmente atractivo para ransomware porque suele concentrar tres cosas:

  • Superficie enorme: múltiples webs, add‑ins, flujos, APIs, autenticaciones híbridas.
  • Datos críticos: documentos, contratos, código, procedimientos internos.
  • Puente de privilegios: desde una vulnerabilidad web se puede escalar a:
    • cuentas de servicio con permisos de sistema
    • comunicación con AD / Azure AD
    • herramientas de backup y seguridad

El patrón que hemos visto en campañas como la de Warlock es:

  1. Explotar vulnerabilidades en SharePoint expuesto.
  2. Ganar ejecución de código en el servidor.
  3. Moverse lateralmente hacia controladores de dominio / M365 / herramientas de seguridad.
  4. Desactivar defensas y desplegar ransomware a escala.

Tu objetivo: romper esta cadena en varios puntos, no confiar en una única barrera.

2. Checklist de hardening de SharePoint (on‑prem y Online)

2.1. Superficie expuesta mínima

  • Revisa qué URLs de SharePoint están publicadas en internet.
    • Nada de exponer directamente servidores de app/DB.
    • Usa WAF / reverse proxy delante del front.
  • Deshabilita servicios y features que no usas:
    • Servicios de búsqueda, workflows antiguos (SharePoint 2010/2013), InfoPath, etc.
    • En SharePoint Online, revisa características heredadas y conectores que no necesitas.
  • Bloquea WebDAV y métodos HTTP peligrosos si no son imprescindibles.
# Ejemplo: limitar métodos en IIS para el sitio de SharePoint
Import-Module WebAdministration
Set-WebConfigurationProperty \
  -pspath 'MACHINE/WEBROOT/APPHOST/SharePoint - 80' \
  -filter "system.webServer/security/requestFiltering/verbs" \
  -name "applyToWebDAV" \
  -value "false"

Add-WebConfigurationProperty \
  -pspath 'MACHINE/WEBROOT/APPHOST/SharePoint - 80' \
  -filter "system.webServer/security/requestFiltering/verbs" \
  -name "." \
  -value @{ verb='TRACE'; allowed='false' }

2.2. Patching disciplinado

  • Define una ventana mensual fija para aplicar CUs y security fixes de SharePoint.
  • Mantén un entorno de preproducción lo más parecido posible a producción.
  • Automatiza el inventario de versiones:
# Listar versiones de SharePoint instaladas
(Get-SPFarm).BuildVersion

# Exportar lista de servidores y versión
Get-SPServer | Select-Object Address, Role, BuildVersion | \
  Export-Csv .\sp-servers-version.csv -NoTypeInformation
  • Para M365, habilita alertas de cambios de configuración en el centro de seguridad.

2.3. Cuentas de servicio con mínimos privilegios

  • Revisa las cuentas de servicio de SharePoint:
    • Servicio web, App Pool, servicios de búsqueda, timer jobs, etc.
  • Asegúrate de que no son Domain Admin ni tienen permisos excesivos.
  • Usa Managed Service Accounts (gMSA) cuando sea posible.
# Crear gMSA para SharePoint WebApp
New-ADServiceAccount -Name sp_web_gmsa -DNSHostName spweb.domain.local -PrincipalsAllowedToRetrieveManagedPassword "DOMAIN\\SP_Servers"
  • Aplica Password Policies estrictas y rotación automática de credenciales.

3. Segmentación de red: que SharePoint no sea autopista al dominio

Tu objetivo es que comprometer SharePoint no implique comprometer el dominio entero.

3.1. Zonas y firewalls internos

  • Separa los roles de SharePoint:
    • Web front‑ends en una DMZ interna.
    • Servidores de aplicaciones y bases de datos en redes más protegidas.
  • Limita tráfico entre zonas con firewalls internos:
    • Sólo puertos necesarios (SQL, HTTP/HTTPS internos, etc.).
    • Nada de RDP abierto desde cualquier sitio.
Internet
  ↓
WAF / Reverse Proxy
  ↓
DMZ interna (WFEs)
  ↓ (puertos mínimos)
Red de apps SP / SQL
  ↓ (muy restringido)
Controladores de dominio

3.2. Sin rutas directas a herramientas de seguridad

  • Aísla consolas de seguridad centralizadas (EDR, backup, SIEM) en una red de alta protección.
  • Desde los servidores SharePoint:
    • Sólo salida necesaria a los agentes de seguridad (puertos específicos).
    • No permitir conexiones administrativas inversas desde SharePoint.

Si el atacante desde SharePoint puede llegar a la consola que administra tu EDR o tu backup, estás un paso más cerca del desastre.

4. Pipelines de despliegue: no subas el malware tú mismo

Los despliegues de soluciones .NET para SharePoint (on‑prem o SPFx) son otro vector típico.

4.1. Principio básico: nada se instala manualmente en producción

  • Todo cambio pasa por CI/CD:
    • Builds reproducibles.
    • Publicación firmada.
  • No se permite subir:
    • .wsp o .app manuales.
    • Paquetes SPFx sin pasar por el pipeline.

4.2. Scanning y controles en el pipeline

En tu pipeline (Azure DevOps, GitHub Actions, etc.):

  • Análisis SAST de las soluciones .NET / SPFx.
  • Análisis de dependencias (SCA) para detectar librerías vulnerables.
  • Escaneo de malware sobre el artefacto empaquetado.

Ejemplo muy esquemático de pipeline para SPFx en YAML:

trigger:
  - main

pool:
  vmImage: 'windows-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '18.x'

  - script: |
      npm ci
      npm run build
      npm run bundle --ship
    displayName: 'Build SPFx'

  - task: SASTScanner@1
    inputs:
      # Config propia del scanner

  - task: MalwareScan@1
    inputs:
      pathToScan: 'sharepoint/solution/**/*.sppkg'

  - task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: 'sharepoint/solution'
      ArtifactName: 'spfx-package'

4.3. Control de quién despliega qué

  • Usa Service Connections con identidades técnicas, no cuentas personales.
  • Aplica Aprobaciones para despliegues a producción.
  • Limita en SharePoint quién puede:
    • Subir soluciones a la App Catalog.
    • Habilitar features a nivel de colecciones de sitios.

5. Monitoreo específico de SharePoint para detectar ransomware temprano

No basta con tener un SIEM; necesitas indicadores concretos.

5.1. Señales técnicas en los servidores

  • Monitoriza:
    • Creación masiva de archivos con extensiones inusuales.
    • Picos de escritura en webs de contenido.
    • Procesos raros ejecutándose bajo las cuentas de servicio de SharePoint.
    • Cambios en binarios / assemblies de SharePoint fuera de ventana de mantenimiento.
# Ejemplo básico: listar procesos que usan la cuenta de servicio de SP
Get-WmiObject Win32_Process | Where-Object {
  $_.GetOwner().User -like "sp_*"
} | Select-Object Name, ProcessId
  • En M365, habilita alertas en:
    • Compartición masiva de ficheros.
    • Descargas masivas desde ubicaciones inusuales.

5.2. Logs que sí o sí deben ir a tu SIEM

  • ULS logs de SharePoint (al menos de WFEs y app servers críticos).
  • Logs de IIS del sitio de SharePoint.
  • Logs de cambios de configuración y administración (SharePoint y M365).

A partir de los patrones observados en campañas tipo Warlock (fuente):

  • Define reglas para:
    • Nuevas web apps/colecciones creadas fuera de horario.
    • Cambios en cuentas de servicio o permisos de apps.
    • Múltiples errores 500/401 seguidos de éxito 200 en el mismo endpoint (patrón explotación).

6. Protege las herramientas de seguridad de tu propio SharePoint

Los grupos de ransomware tienden a:

  1. Entrar por una app web (por ejemplo, SharePoint).
  2. Buscar las herramientas que pueden detenerles y deshabilitarlas.
  3. Sólo entonces lanzar el cifrado masivo.

Tu diseño debe asumir SharePoint como comprometible y proteger lo que realmente importa.

6.1. Endpoints críticos fuera del alcance de SharePoint

  • Consolas de:
    • EDR/antivirus corporativo.
    • Gestión de backups.
    • Gestión de identidades (IAM).
  • Sin acceso directo desde la red donde residen los servidores SharePoint.

6.2. Principio de doble control

  • Para acciones sensibles (borrar backups, desactivar políticas de EDR):
    • MFA obligatorio.
    • Aprobación de un segundo usuario.

Incluso si el atacante robase credenciales desde SharePoint, no podría desactivar las defensas con un solo golpe.

7. Checklist rápido para mañana

Si mañana sólo pudieras hacer 10 cosas, yo priorizaría:

  1. Revisar qué instancias de SharePoint tienes expuestas a internet y ponerlas detrás de un WAF.
  2. Validar que todas están parcheadas a la última CU de seguridad.
  3. Auditar permisos de cuentas de servicio y revocar privilegios excesivos.
  4. Añadir reglas de firewall interno para aislar SharePoint de:
    • controladores de dominio
    • consolas de EDR/backup
  5. Bloquear métodos HTTP innecesarios y servicios SharePoint legacy que no uses.
  6. Configurar en el SIEM:
    • alertas de actividad anómala en SharePoint
    • envío de logs de IIS y ULS
  7. Revisar el pipeline de despliegue de soluciones .NET/SPFx:
    • sin deploys manuales a producción
    • con SAST + AV al paquete.
  8. Limitar quién puede subir soluciones a la App Catalog o activar features.
  9. Comprobar que las consolas de seguridad no son accesibles desde la red de SharePoint.
  10. Documentar un playbook de respuesta ante incidente en SharePoint (a quién llamas, qué apagas, cómo aislas).

Conclusión

SharePoint no va a dejar de ser un objetivo prioritario para ransomware: es demasiado jugoso. Lo que sí puedes cambiar es lo que pasa después de que alguien encuentre una vulnerabilidad.

Si endureces la superficie, segmentas bien, monitorizas señales específicas y blindas tus propias herramientas de seguridad, conviertes tu granja o tu tenant M365 en algo muy distinto: de “puerta grande al desastre” a “contenedor controlado y ruidoso” donde un atacante lo tiene mucho más difícil para pasar al siguiente nivel.

Elige qué puntos de la checklist puedes atacar esta semana, ponlos en tu backlog y trata SharePoint como lo que es: una pieza crítica de infraestructura, no sólo un portal de documentos.

Compartir: