Para proteger un repositorio Server SharePoint Server es necesario añadir controles adicionales al antivirus integrado, que analiza cada archivo una sola vez al subirlo o descargarlo utilizando un único motor. Multiscanning, el CDR (desactivación y reconstrucción de contenidos), el DLP (prevención de pérdida de datos) y el reanálisis continuo subsanan las brechas que permiten que el malware y el ransomware permanezcan inactivos.
Puntos clave
- El antivirus integrado Server SharePoint Server(VSAPI o AMSI) analiza cada archivo con un único motor, únicamente al subirlo o descargarlo. Nunca vuelve a analizar los archivos que ya están almacenados.
- Un archivo que se considera «limpio» desde el primer día mantiene esa calificación de forma indefinida, por lo que el malware y el ransomware pueden permanecer inactivos sin ser detectados mientras las firmas y los modelos de detección mejoran a su alrededor.
- El historial de versiones agrava el riesgo: cada copia conservada conlleva el mismo riesgo de datos sin escanear y en reposo que el archivo actual.
- Los ataques de ToolShell/Warlock de julio de 2025 pusieron de manifiesto que los atacantes introducían archivos de «web-shell» que un análisis puntual con un único motor nunca estaba diseñado para detectar.
- Para cubrir esa brecha se necesita un conjunto de controles por niveles. Este conjunto incorpora el escaneo múltiple, el CDR (desactivación y reconstrucción de contenidos), el DLP (prevención de pérdida de datos) y el reescaneo continuo, además del escaneo nativo.
- MetaDefender Security™ es la plataforma de protección de datos empresariales OPSWAT, que utiliza Metascan™ Multiscanning™, la tecnología Deep CDR™ y Proactive DLP™ para analizar tanto los archivos recién subidos como los que ya se encuentran almacenados.
Cuando los usuarios y administradores de SharePoint local suben un archivo, este se analiza con un antivirus de terceros o con motores compatibles con AMSI (como Microsoft Defender). Si el archivo supera ese análisis inicial, se considera tratado. Una vez limpio, siempre limpio. Esta suposición explica precisamente cómo las cargas útiles de malware y ransomware logran permanecer en el repositorio sin ser detectadas, a veces durante años.
Microsoft lo afirma claramente: la protección contra malware de SharePoint puede limitar los daños, pero no constituye un único punto de defensa.
En los entornos del sector BFSI (banca, servicios financieros y seguros), la sanidad, la administración pública y la tecnología operativa (OT) o las infraestructuras críticas, los datos en riesgo son los documentos de cumplimiento normativo, los historiales de pacientes, los expedientes de casos y la documentación técnica. Todo ello se encuentra en un repositorio que no deja de crecer año tras año, sin que nadie vuelva a examinar lo que ya contiene.
Lo que viene a continuación se resume en tres aspectos: cómo funciona realmente el análisis antivirus de SharePoint, qué es lo que no cubre y cómo debería ser una seguridad eficaz y por capas para el repositorio de archivos de SharePoint.
Lo que no cubre la función de escaneo nativa de SharePoint
Microsoft es muy clara al advertir a los usuarios de que las funciones antivirus integradas en SharePoint pueden contener virus, pero no están pensadas como único punto de defensa contra el malware. Hay tres puntos débiles concretos que merece la pena analizar.
Datos ya almacenados
La detección queda obsoleta rápidamente. Dado que el motor de detección no se activa de forma periódica, el veredicto de un archivo solo refleja lo que un único motor pudo identificar en el momento en que se analizó el archivo.
Historial de versiones
Las bibliotecas de SharePoint, cuando tienen activado el historial de versiones, conservan cada versión guardada como una copia independiente del archivo. Dependiendo de las políticas de control de versiones de la organización, un mismo archivo puede acumular cientos de versiones históricas con el paso del tiempo.
La documentación de Microsoft sobre el historial de versiones no menciona que se realicen análisis en busca de malware en las versiones almacenadas.
Por lo tanto, cada versión histórica almacenada en una biblioteca conlleva el mismo riesgo de exposición en reposo que la versión actual. En las bibliotecas con actualizaciones frecuentes, el riesgo de exposición se acumula con el tiempo. Pueden acumularse cientos de versiones no escaneadas del mismo archivo (infectado). Los riesgos crecen exponencialmente a medida que aumenta la profundidad del historial de versiones.
Amenazas desconocidas o de «día cero»
Un virus de día cero superará el análisis igual que lo haría un archivo limpio, simplemente porque todavía no hay ningún motor que lo detecte. Y como SharePoint no vuelve a analizar el contenido existente posteriormente, un archivo de día cero que pase el análisis el primer día no se volverá a examinar el día doscientos, ni siquiera después de que el proveedor lance una actualización de firmas que lo detectaría.
Las amenazas desconocidas siguen la misma lógica. Al no tener ninguna firma asociada, el análisis estático (lo que hacen los motores antivirus) no puede detectar la amenaza.
Nota: se trata de limitaciones de alcance, no de defectos. El antivirus nativo Server SharePoint Server se diseñó para realizar comprobaciones puntuales en puntos de interacción específicos, no para revalidar continuamente un repositorio en constante crecimiento y con versiones frente a un panorama de amenazas en constante evolución.
En julio de 2025, Microsoft reveló que se estaba explotando activamente una cadena de ejecución remota de código sin autenticación que afectaba a SharePoint Server local: CVE-2025-49706, CVE-2025-49704, a las que posteriormente se sumaron CVE-2025-53770 y CVE-2025-53771. El exploit no requería credenciales ni iniciar sesión para funcionar.
Posteriormente, Microsoft lo corrigió y la cadena de exploits recibió un nombre: ToolShell.
Según el análisis de Eye Security, citado por la revista Infosecurity Magazine, se detectaron 396 sistemas comprometidos en 145 organizaciones de 41 países. El sector público fue el más afectado, con un 30 % de las infecciones confirmadas, y solo Estados Unidos representó el 31 % del total. Por otra parte, la Fundación Shadowserver informó de que más de 10 700 instancias de SharePoint seguían expuestas y accesibles para cualquiera que ejecutara la misma cadena de exploits, incluso después de que se hiciera pública la vulnerabilidad, que afectó a cientos de organizaciones. Storm-2603, uno de los grupos responsables del exploit, aprovechó esa exposición para distribuir una carga útil del ransomware Warlock.
Una vez dentro, Storm-2603 utilizó credenciales robadas y herramientas de administración legítimas para desplazarse lateralmente por los sistemas. Este desplazamiento no despertó ninguna sospecha, ya que se basaba en herramientas que se suponía que debían estar allí. Storm-2603 instaló shells web y sustrajo datos importantes. Mantuvieron el acceso incluso después de que se corrigiera la vulnerabilidad, ya que los atacantes ya habían robado las claves necesarias para falsificar tokens de autenticación válidos.
ToolShell se creó a partir de cuatro vulnerabilidades CVE encadenadas entre sí, con mecanismos para eludir los parches incorporados desde el principio. Las vulnerabilidades CVE-2025-53770 y -53771 existen precisamente porque era posible eludir las correcciones originales de las vulnerabilidades CVE-2025-49704 y -49706.
Lo que realmente importa es que un atacante se adaptó más rápido que el ciclo de parches, en dos ocasiones, contra el mismo objetivo, en cuestión de semanas.
Los controles estáticos, como los antivirus independientes que comprueban un archivo una sola vez comparándolo con las firmas de un único proveedor, nunca se diseñaron, en primer lugar, para detectar una cadena de vulnerabilidades del lado del servidor. Además, no pueden proteger contra un atacante que vuelve tras la aplicación del parche con una forma de eludirlo.
ToolShell pone de manifiesto el nivel de sofisticación al que se enfrentan ahora, concretamente, los servidores de SharePoint. No hay motivos para dar por hecho que esta haya sido la última vez que se ha producido un ataque de este tipo. ¿Están los datos almacenados en estos servidores protegidos por un sistema diseñado para mantenerse al día, o por un análisis que comprueba los datos una sola vez y da el asunto por zanjado?
Para ser justos, ToolShell no era un documento malicioso que hubiera pasado desapercibido en un análisis de archivos subidos. Pero, ¿y el shell web (spinstall0.aspx y sus variantes renombradas) que dejaron los atacantes? Eso sí que es un archivo. Permaneció en el servidor y el hecho de que fuera detectado o no dependía de las mismas limitaciones descritas anteriormente: un solo motor, un único análisis, en un único momento.
Ese es el mecanismo que vincula este incidente con el argumento general. La aplicación del parche cierra específicamente la cadena de explotación de ToolShell. No tiene ningún efecto sobre el siguiente archivo no analizado que ya se encuentre en un repositorio.
Cómo Storage Security MetaDefender™ Storage Security estos requisitos
Storage Security MetaDefender™ Storage Security es la plataforma de protección de datos empresariales OPSWAT, diseñada para proteger archivos en entornos de almacenamiento locales, híbridos y nativos de la nube mediante Metascan™ Multiscanning, la tecnología Deep CDR™ y Proactive DLP™, que analizan tanto los nuevos archivos subidos como el contenido que ya se encuentra almacenado.
Para los usuarios de SharePoint, la plataforma puede resolver tanto el problema del contenido inactivo como las limitaciones derivadas de que la detección se limite a un único motor. Así es como funciona:
- Análisis con más de 30 motores antimalware mediante la tecnología Metascan™ Multiscanning; una amenaza que se le escape a un proveedor tiene otras 29 oportunidades de ser detectada.
- La tecnología Deep CDR™ elimina los puntos ciegos en la detección; la tecnología Deep CDR™ descompone y reconstruye los archivos en una estructura segura, lo que resulta útil para hacer frente a amenazas de «día cero» y desconocidas ocultas en archivos de productividad. El archivo se descompone independientemente de si se ha detectado o no una amenaza.
- La tecnología Proactive DLP™ mitiga los riesgos de fugas de datos mediante la identificación, el bloqueo y la ocultación de datos sensibles o confidenciales en los archivos. Para los entornos del sector financiero, de seguros y de servicios bancarios (BFSI), sanitario y público regulados por los requisitos de PCI DSS, PHI o CUI, se trata de un control de cumplimiento que se suma a la protección contra el malware y a los registros de auditoría.
Múltiples opciones de análisis en MetaDefender Storage Security
Como diferencia fundamental respecto al modelo nativo de SharePoint, MetaDefender Storage Security análisis en tiempo real, programados y bajo demanda del contenido que ya se encuentra en el repositorio. La protección en tiempo real protege las nuevas subidas en cuestión de segundos, mientras que los análisis programados y bajo demanda garantizan que los archivos existentes y las versiones históricas sigan estando protegidos.
La implementación se adapta a tus necesidades
MetaDefender Storage Security puede implementarse mediante diversos modelos: servidores físicos para instalaciones directas de hardware, plataformas de virtualización (compatibles con VMware, Hyper-V y XenServer), IaaS (infraestructura como servicio) de los principales proveedores de servicios en la nube, o mediante implementaciones en contenedores en clústeres de Kubernetes.
Preguntas frecuentes
1. ¿SharePoint Server automáticamente los archivos en busca de malware?
Sí, pero solo en momentos concretos. SharePoint Server analizar documentos al subirlos, descargarlos o editarlos en línea mediante un único motor a través de VSAPI o la función antivirus para documentos basada en AMSI. No vuelve a analizar automáticamente los archivos que ya están almacenados en las bibliotecas.
2. ¿Puede el malware permanecer sin ser detectado en una biblioteca Server de SharePoint Server ?
Sí. Las integraciones antivirus nativas ServerSharePoint Server(VSAPI o AMSI) analizan un archivo al subirlo o descargarlo utilizando las firmas de un único motor disponibles en ese momento. Los archivos no se vuelven a analizar posteriormente, por lo que un archivo que estuviera limpio, o que simplemente no se hubiera detectado, cuando las firmas del motor no estuvieran actualizadas, puede permanecer en la biblioteca de forma indefinida.
3. ¿Vuelve SharePoint Server los archivos que ya están almacenados?
No. El análisis nativo se basa en eventos y se activa cuando se produce una actividad de carga o descarga. No se ejecuta de forma periódica sobre el contenido existente, incluidas las versiones anteriores de los archivos conservadas en el historial de versiones.
4. ¿Cómo pueden los atacantes utilizar SharePoint para distribuir malware, y no solo para almacenarlo?
Los atacantes pueden utilizar las funciones de uso compartido y sincronización de SharePoint —enlaces externos o para invitados, bibliotecas sincronizadas o sitios web comprometidos que alojen documentos de phishing y enlaces maliciosos— para distribuir un archivo ya preparado en un repositorio a otros usuarios y dispositivos finales.
5. ¿Se ve afectado SharePoint Online (Microsoft 365) por las mismas vulnerabilidades y por ToolShell?
No. La cadena de exploits de ToolShell Server afectó a SharePoint Server local; SharePoint Online no se vio afectado. Las limitaciones relativas al análisis de datos en reposo y al motor único que se comentan aquí se aplican igualmente a Server local.
6. ¿Qué es ToolShell? ¿Se soluciona por completo el problema con la aplicación del parche?
ToolShell es una cadena de exploits (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771) que permite la ejecución remota de código sin autenticación en Server SharePoint local. La aplicación de los parches corrige las vulnerabilidades, pero, dado que los atacantes han robado las claves del sistema, las organizaciones también deben rotar las claves y buscar los web shells que ya se hayan instalado.
7. ¿Por qué tengo que renovar las claves de máquina de ASP.NET después de instalar los parches?
Los atacantes que hayan robado las claves de tu equipo pueden falsificar tokens de autenticación válidos incluso después de que hayas aplicado el parche. La recomendación de la CISA es rotar las claves, aplicar la actualización, rotar las claves de nuevo y reiniciar IIS con iisreset.exe para que la aplicación del parche expulse efectivamente al atacante.
8. ¿La activación de AMSI protege a SharePoint frente a ToolShell?
La integración de filtrado de solicitudes de AMSI (activada por defecto desde las actualizaciones de septiembre de 2023, preferiblemente en modo completo) analiza las solicitudes entrantes y puede bloquear los intentos de explotación no autenticados de ToolShell. Esta función es independiente de la función antivirus para documentos basada en AMSI, que analiza el contenido de los archivos al subirlos y descargarlos.
