La parte uno fue la venta. Esto es el parque.
El papeleo está firmado, la factura corre cada mes, y hay material. Parte tuyo, parte suyo, la mayoría elegido antes de que nadie preguntara qué hace de verdad la empresa entre las ocho y las seis. Lo que sigue es el material en sí: qué se elige, qué se quedó encendido dentro, y quién más puede alcanzar las máquinas que pagaste desde una consola en la que nunca has iniciado sesión.
Dos de los fallos de aquí llevan una conclusión de un regulador con una cifra pegada. Ninguno le pasó a un cliente — le pasaron a un proveedor, y los clientes estaban aguas abajo. Cada afirmación lleva un enlace.
La caja de la que no se les disuadirá
Ahora la incómoda. Quiero hacerla con pruebas en vez de con aseveraciones, porque es la sección donde la gente echa mano de la palabra conspiración — y echar mano de esa palabra es como el tema se deja caer sin que nadie tenga que mirarlo.
Cisco es la recomendación por defecto en la mayor parte de esta industria. Así que mira lo que el propio fabricante ha publicado sobre acceso sin documentar a su propio material.
En marzo de 2018 publicaron un aviso para CVE-2018-0141: se podía iniciar sesión en Prime Collaboration Provisioning por SSH a causa de «a hard-coded account password on the system» — una contraseña de cuenta codificada en duro en el sistema. Ocho meses después, CVE-2018-15439 en los switches Small Business, donde «the affected software enables a privileged user account without notifying administrators of the system» — el software afectado habilita una cuenta de usuario privilegiada sin notificar a los administradores del sistema —, sin software corregido disponible al publicarse y un apaño ofrecido en su lugar. En octubre de 2023, CVE-2023-20101: Emergency Responder se entregaba con una cuenta root que portaba «default, static credentials that cannot be changed or deleted» — credenciales estáticas por defecto que no se pueden cambiar ni borrar —, credenciales «typically reserved for use during development» — habitualmente reservadas para uso durante el desarrollo.
Una cuenta de la que nadie fue avisado, que no puedes quitar, con root en una caja de tu parque. Llámalo como quieras. Es lo que describe el propio aviso del fabricante.
Luego está el material de Snowden, que ya tiene más de una década y nunca se ha retirado. En diciembre de 2013 Der Spiegel publicó el catálogo ANT, informando de que una división de la NSA «has burrowed its way into nearly all the security architecture made by the major players in the industry – including American global market leader Cisco and its Chinese competitor Huawei» — se ha abierto camino excavando en casi toda la arquitectura de seguridad hecha por los grandes actores de la industria, incluido el líder mundial estadounidense Cisco y su competidor chino Huawei. El mismo reportaje describía cómo el material llega ahí: envíos desviados a talleres secretos en un proceso que la NSA llama interdicción, donde «at these so-called ’load stations,’ agents carefully open the package in order to load malware onto the electronics, or even install hardware components that can provide backdoor access» — en estas llamadas «estaciones de carga», los agentes abren con cuidado el paquete para cargar malware en la electrónica, o incluso instalar componentes de hardware que pueden dar acceso por puerta trasera. Un boletín interno de la NSA de 2010, publicado en 2014 con las fotografías, exponía el proceso con las propias palabras de la agencia: dispositivos «being delivered to our targets throughout the world are intercepted» — que se entregan a nuestros objetivos por todo el mundo son interceptados —, luego «re-packaged and placed back into transit to the original destination» — reembalados y puestos de nuevo en tránsito hacia el destino original.
Lo que el reportaje no muestra es complicidad. Der Spiegel dijo claramente que nada en los documentos sugería que los fabricantes supieran o ayudaran, y Cisco negó toda implicación en su momento, y en mayo de 2014 su director jurídico lo dejó por escrito: «as a matter of policy and practice, Cisco does not work with any government, including the United States Government, to weaken our products» — por política y práctica, Cisco no trabaja con ningún gobierno, incluido el de los Estados Unidos, para debilitar sus productos. Se quejaron de ello al presidente. A primera vista, ellos también fueron una víctima aquí.
Tómalo al pie de la letra. No cambia nada de la caja de tu rack, porque la interdicción nunca necesitó la ayuda del fabricante. Y vale la pena saber qué peso lleva el desmentido, porque la palabra de Cisco se ha puesto a prueba en un tribunal. En 2019 zanjaron un procedimiento bajo la False Claims Act por 8,6 millones de dólares a nivel federal, más 6 millones de dólares ante un grupo de estados, por un software de videovigilancia vendido a organismos públicos con «flaws that would permit unauthorized access to the system, with the potential to control and otherwise manipulate security cameras and the recorded footage» — defectos que permitirían acceso no autorizado al sistema, con potencial para controlar y manipular de otro modo las cámaras de seguridad y las imágenes grabadas. La versión del fiscal general de Nueva York es que Cisco supo de los defectos en 2009 y no los corrigió hasta 2013, después de que empezara la investigación. Los acuerdos no son admisiones de responsabilidad y no fingiré lo contrario. Aun así son cuatro años vendiendo un producto a cuerpos de policía y organismos públicos con una vía de entrada conocida, sin decirlo.
Así que el historial es: cuentas root sin documentar por su propia admisión, un catálogo de hace una década que los nombra, una cadena de envío demostrada como comprometible, y un periodo en que sabían de un agujero y siguieron vendiendo. Cualquiera de ellos por separado lo podrías dejar pasar. Juntos son un patrón. Una declaración de una parte interesada no zanja un patrón.
La respuesta a eso son controles, no una prohibición. El riesgo tiene su sitio en el documento de diseño con todo lo demás, y las alternativas se cotizan en vez de descartarse. Pregunta qué material competidor se evaluó y qué costaba. Pregunta cuál es la política de verificación y actualización del firmware, y quién la comprueba. Pregunta cómo se recibe e inspecciona el material, y por quién. Pregunta qué pasa con un número de serie que no coincide con el pedido de compra.
Y fíjate en qué fabricantes reciben este escrutinio en tu sector y cuáles no. La misma industria que puso a Huawei en un registro de riesgos por una capacidad que nadie ha producido en público escribirá a Cisco en el diseño de bajo nivel sin una línea de justificación, sobre la fuerza de una insignia de socio. He escrito sobre lo que le pasa a ese argumento cuando aplicas el criterio de forma pareja. Una insignia de socio es una relación comercial con objetivos pegados. Como tal, no es una conclusión de seguridad.
El cortafuegos es la vía de entrada
Amplía eso de un fabricante a la categoría, porque el cortafuegos es el producto que un MSP vende con más fuerza. Es la partida que justifica la parte de seguridad del contrato.
La CISA mantiene un catálogo de vulnerabilidades que se sabe que se explotan en la naturaleza — no teóricamente peligrosas, de verdad usadas contra alguien. Saqué el catálogo y lo conté por fabricante. La versión 2026.08.27 tiene 1 685 entradas. Cisco supone 96 de ellas, solo por detrás de las 386 de Microsoft, y 42 de esas se sientan en las líneas de cortafuegos y borde. Fortinet tiene 29. Palo Alto Networks tiene 15. Para la escala, Ivanti tiene 35 y SonicWall 17.
Mira lo que son de verdad las entradas, porque el patrón nunca varía. Es la interfaz de gestión o el VPN, es decir, la parte deliberadamente expuesta a internet.
El CVE-2024-3400 de Palo Alto fue una inyección de comandos en la función GlobalProtect de PAN-OS, puntuando 10,0, explotada como día cero. Más tarde el mismo año CVE-2024-0012 dejaba a «an unauthenticated attacker with network access to the management web interface» — un atacante no autenticado con acceso de red a la interfaz web de gestión — pasar de largo la autenticación a 9,8, y se encadenaba con una inyección de comandos en la misma interfaz.
El CVE-2022-40684 de Fortinet fue una «authentication bypass using an alternate path or channel» — elusión de autenticación usando una ruta o canal alternativo — a 9,8. Su CVE-2018-13379, un salto de directorio en el VPN SSL, entró en el catálogo en noviembre de 2021. Años después de que el parche existiera, porque había cajas todavía posadas en internet sin parchear y por las que se entraba andando.
El CVE-2023-20198 de Cisco en la interfaz web de IOS XE puntuó 10,0. CVE-2025-20333, en el servidor web VPN de su software Secure Firewall ASA y FTD, puntuó 9,9 el pasado septiembre.
Y luego está CVE-2026-20316, añadido al catálogo el 29 de julio de 2026. Cisco Secure Firewall Management Center, «use of hard-coded password» — uso de contraseña codificada en duro —, dejando a «an unauthenticated, remote attacker to log in to an affected device» — un atacante remoto no autenticado iniciar sesión en un dispositivo afectado. Una credencial estática, en la caja que gestiona los cortafuegos, confirmada como explotada, un mes antes de este artículo. El mismo fallo que en 2018 y 2023 de la sección de arriba, en la máquina que administra tu perímetro.
Ahora la parte útil, porque «algunos fabricantes son peores que otros» no es de verdad la lección. Cada uno de estos tiene un historial público y nada de ello aparece en una propuesta. Más al grano, el total del fabricante no es la cifra que decide si te hacen daño. Tu exposición es el hueco entre que una vulnerabilidad entra en ese catálogo y que tu caja está parcheada. Ese hueco no es del fabricante para cerrarlo. Pertenece a quien pagues para hacer funcionar la cosa.
Que es la misma medida que la ICO tomó en Capita. Alerta a los diez minutos, acción a las cincuenta y ocho horas, objetivo de una. Nadie le pide a su proveedor esa cifra sobre el parcheado de cortafuegos, y es una cifra que tiene todo proveedor.
Cuando lo básico es lo que compraste
La parte uno iba sobre la venta. Esto es lo que vino después, en dos casos donde un regulador hizo la investigación y publicó lo que halló.
En marzo de 2025 el Information Commissioner multó a Advanced Computer Software Group con 3,07 millones de libras por un incidente de ransomware en agosto de 2022. Advanced «provides IT and software services to organisations, including the NHS and other healthcare providers» — presta servicios de TI y software a organizaciones, incluidos el NHS y otros proveedores sanitarios. Los atacantes entraron «via a customer account that did not have multi-factor authentication» — a través de una cuenta de cliente que no tenía autenticación multifactor. El NHS 111 se vio interrumpido, el personal sanitario no podía alcanzar los historiales de pacientes, y la información personal de 79 404 personas fue tomada. La conclusión de la ICO sobre la causa vale la pena leerla despacio: «while Advanced had installed multi-factor authentication across many of its systems, the lack of complete coverage meant hackers could gain access» — aunque Advanced había instalado autenticación multifactor en muchos de sus sistemas, la falta de cobertura completa permitió que los hackers obtuvieran acceso. Fue también la primera penalización que la ICO ha emitido contra un encargado del tratamiento en vez de contra la organización de quien eran los datos.
En octubre de 2025 el mismo regulador multó a Capita con 14 millones de libras por el ataque de 2023 que tomó la información personal de 6,6 millones de personas. Un fichero malicioso aterrizó en el dispositivo de un empleado el 22 de marzo de 2023. Una alerta de alta prioridad se disparó en diez minutos. El dispositivo no se puso en cuarentena durante 58 horas, contra un tiempo de respuesta objetivo de una hora, y la ICO halló que el Security Operations Centre «was understaffed, and in at least six months before the incident fell well below the target response times for responding to security alerts» — estaba falto de personal, y en al menos seis meses antes del incidente cayó muy por debajo de los tiempos de respuesta objetivo para responder a las alertas de seguridad —, junto a pruebas de intrusión y evaluación de riesgos inadecuadas.
Lee lo que esas dos conclusiones tienen en común. No un adversario hábil. No un día cero. Nada que nadie pudiera haber visto. Autenticación multifactor que se compró pero no se terminó, y una cola de alertas que nadie había dotado de personal. Ambas son partidas que alguien aprobó y reportó en verde.
Y nada de esto pilló a la industria por sorpresa. El 11 de mayo de 2022, tres meses antes del incidente de Advanced, las agencias de ciberseguridad del Reino Unido, Australia, Canadá, Nueva Zelanda y los Estados Unidos sacaron un aviso conjunto sobre las amenazas a los proveedores de servicios gestionados y sus clientes, porque estaban «aware of recent reports that observe an increase in malicious cyber activity targeting managed service providers» — al tanto de informes recientes que observan un aumento de la actividad cibernética maliciosa dirigida a los proveedores de servicios gestionados. La primera acción táctica de la lista es imponer autenticación multifactor en las cuentas del MSP que entran en el entorno del cliente.
Las agencias de seguridad de cinco países lo pusieron por escrito, en público, y nombraron el control. Tres años después un regulador todavía multa a la gente por no haberlo terminado.
Ninguna de esas es una historia de pequeña empresa. Aquí va una. El viernes 24 de noviembre de 2023 el proveedor de TI del sector jurídico CTS se cayó en un incidente cibernético. El propio diario de la Law Society informó de que unos 80 bufetes no podían concluir transacciones, con sistemas fuera de línea y contratos atascados. Son despachos de compraventa inmobiliaria, la mayoría bufetes pequeños, y sus clientes eran gente en plena mudanza. Uno de ellos lo dijo sin rodeos: «This leaves us with so much uncertainty — with movers needing to be booked, days needing to be taken off work at potentially short notice and lives put on hold» — esto nos deja con tanta incertidumbre, con mudanzas que reservar, días de trabajo que pedir libres con poca antelación y vidas puestas en pausa. CTS solo pudo decir esto: que estaba «unable to give a precise timeline for full restoration» — incapaz de dar un calendario preciso para la restauración completa.
Nadie en esa cadena eligió CTS. El bufete lo eligió, y cada cliente aguas abajo del bufete heredó la decisión sin que nunca se le preguntara.
Eso es lo que compras cuando compras un servicio gestionado.
¿Y cómo te habrías enterado?
Fíjate en algo de cada incidente de la sección de arriba. Ninguno le pasó al cliente. Le pasaron al proveedor, y los clientes estaban posados aguas abajo de la mala semana de otro.
Así que pon la pregunta directamente. Si nos hackean, ¿nos enteramos por ti? ¿Y a qué velocidad?
Hay un suelo legal, y es más bajo de lo que la gente supone. Allí donde tratan datos personales por cuenta tuya, el artículo 33 dice que «the processor shall notify the controller without undue delay after becoming aware of a personal data breach» — el encargado notificará al responsable sin dilación indebida tras tener conocimiento de una violación de datos personales. Ningún número fijo de horas. Mientras tanto tú, como responsable, tienes 72 horas para avisar al Information Commissioner una vez que tienes conocimiento. Lee esos dos juntos. Cada hora que pasan decidiendo si decírtelo es una hora menos en un reloj que corre contra ti, no contra ellos.
Y ese suelo solo cubre los datos personales. Una intrusión en su consola de gestión, sin prueba aún de que nada tuyo se moviera, puede no generar ningún deber de decírtelo en absoluto — mientras las credenciales que alcanzan cada máquina que posees se sientan en manos de otro. Ese es el hueco. No es pequeño.
Piensa en a quién se avisa antes que a ti. A sus abogados, por el privilegio. A su aseguradora, porque la póliza lo dice. A su regulador, en el reloj legal. Estás más abajo en esa lista de lo que querrías estar, y el incentivo en cada paso es decir menos hasta que se sepa más.
Lo que deja las alternativas, y todas son peores. Te enteras porque tus sistemas se paran, que es como se enteraron los despachos de compraventa. Te enteras porque llama un periodista. O te enteras porque alguien ve el nombre del proveedor en el sitio de filtraciones de una banda de ransomware, que no es un proceso de notificación, es un accidente del marketing de otro.
Así que contrátalo, y sé concreto, porque las cláusulas vagas recaen en el suelo legal. Notificación de cualquier incidente material en su red dentro de un número de horas estipulado, por escrito, se confirme o no que tus datos están implicados. Notificación si cualquier credencial con acceso a tus sistemas ha podido quedar expuesta. Notificación si aparecen en un sitio de filtraciones. Un contacto nombrado de tu lado, no un buzón general.
Luego haz la pregunta que más te dice, y hazla mientras todavía te están vendiendo. ¿Habéis tenido un incidente? ¿Qué pasó, cuándo se enteraron los clientes, y cómo se enteraron? Un proveedor que ha pasado por uno y lo ha gestionado bien te hablará de ello. Es la mejor prueba que tiene. Alguien que dice que nunca ha pasado es o muy afortunado, o muy pequeño, o no está contando nada.
La herramienta que alcanza a cada cliente a la vez
Ningún MSP gana dinero tocando máquinas de una en una. La economía necesita una consola que lo alcance todo, y para eso está el software de supervisión y gestión remotas. El RMM se sienta en cada máquina bajo contrato, corriendo como sistema, y el proveedor lo pilota todo desde un solo inicio de sesión.
Dale la vuelta y míralo desde tu lado. Hay software en tus máquinas que no elegiste, que probablemente no sabes nombrar, y del que nunca has visto el registro de parcheado. Como tal, puede hacer cualquier cosa, a cualquiera de ellas, en cualquier momento.
El historial de esas herramientas no es reconfortante. Empieza en 2021.
Kaseya, julio de 2021. La CISA y el FBI describieron una respuesta a un ransomware «leveraging a vulnerability in the software of Kaseya VSA on-premises products — against managed service providers (MSPs) and their downstream customers» — explotando una vulnerabilidad en el software de los productos on-premises de Kaseya VSA, contra los proveedores de servicios gestionados (MSP) y sus clientes aguas abajo. Una cincuentena de proveedores fueron golpeados, y hasta 1 500 empresas posadas debajo, la mayoría de las cuales nunca había oído hablar de Kaseya y no tenía voz en que estuviera ahí.
En enero de 2023 la CISA, la NSA y el MS-ISAC emitieron un aviso conjunto para «warn network defenders about malicious use of legitimate remote monitoring and management (RMM) software» — advertir a los defensores de red sobre el uso malicioso de software legítimo de supervisión y gestión remotas (RMM) —, tras una campaña el octubre anterior en la que unos atacantes engañaron por phishing a la gente para instalar ScreenConnect y AnyDesk, y luego los usaron para llevar una estafa de reembolsos contra las cuentas bancarias de las víctimas. Nadie tuvo que hackear un MSP para eso. La herramienta funciona exactamente igual de bien para ellos que para el proveedor.
En febrero de 2024 ConnectWise ScreenConnect resultó portar CVE-2024-1709, que «may allow an attacker direct access to confidential information or critical systems» — puede permitir a un atacante acceso directo a información confidencial o sistemas críticos. Puntuó 10,0. Fíjate en la clase de debilidad que lleva: elusión de autenticación usando una ruta o canal alternativo, palabra por palabra la misma categoría que la elusión de FortiOS de más arriba. Fabricante distinto, producto distinto, mismo error. Nota máxima, en el software que alcanza a cada cliente que tiene un proveedor.
Luego SimpleHelp. El aviso de la CISA de junio de 2025 describe a actores de ransomware «leveraging unpatched instances of a vulnerability in SimpleHelp Remote Monitoring and Management (RMM) to compromise customers of a utility billing software provider» — explotando instancias sin parchear de una vulnerabilidad en SimpleHelp RMM para comprometer a clientes de un proveedor de software de facturación de servicios públicos —, alcanzando «downstream customers» — clientes aguas abajo — para una doble extorsión. El fallo por debajo, CVE-2024-57727, deja a un atacante no autenticado sacar «server configuration files containing various secrets and hashed user passwords» — ficheros de configuración del servidor que contienen varios secretos y contraseñas de usuario hasheadas — directamente del host.
Fíjate en dónde aterriza la pérdida cada vez. No en el fabricante. Tampoco de verdad en el proveedor. En los clientes de debajo, que nunca compraron la herramienta, a los que nunca se les dijo cuál era, y que no tuvieron voz alguna en cuándo se parcheaba.
Una salvedad sobre esas fuentes, porque importa. Son avisos estadounidenses, y eso es porque la CISA publica el detalle de los incidentes mientras que el NCSC en general no nombra. Es una diferencia de divulgación, no de conducta. La herramienta es la misma herramienta, salida del mismo catálogo, y una pequeña empresa de soporte informático de este país está corriendo ScreenConnect o SimpleHelp o uno de sus competidores en tus máquinas esta tarde.
Así que pregunta cuál es. Pregunta qué versión, cuándo se parcheó por última vez, quién puede iniciar sesión en la consola, si cada cuenta en ella tiene autenticación multifactor, y cuál es el plan la próxima vez que uno de estos saque un diez.
Luego pregunta una más, porque la respuesta te dice algo que las otras no. ¿Funciona sobre IPv6?
Es una pregunta justa en 2026 y aterriza más fuerte de lo que parece. Si la herramienta de gestión solo habla IPv4, entonces IPv4 es lo que tu red tiene que conservar — no porque tu empresa lo necesite, sino porque su herramienta lo necesita. Ese es el plan de direccionamiento fijado por el software de un proveedor en vez de por tus requisitos, y estás pagando cada mes las direcciones que lo hacen posible. Un teletrabajador en una conexión móvil bien puede estar ya en una red solo de IPv6, en cuyo caso todo el arreglo se apoya en una traducción que mantiene otro.
Y si la respuesta es que nunca lo han comprobado, has aprendido la cosa por la que de verdad preguntabas.
Una más sencilla primero, que se pierde en toda la charla de seguridad. ¿Qué carga pone el agente en la máquina, y dónde está la prueba?
La respuesta que obtendrás es «insignificante». Eso es un adjetivo. Lo que quieres es una cifra, medida en hardware como el tuyo en vez de sacada de una ficha técnica — CPU media y de pico, memoria residente, actividad de disco durante un barrido de inventario o un escaneo de parches, y red diaria. Tomada en la máquina más vieja del parque en vez de la más nueva.
Y mide toda la pila, no un agente por su cuenta. Gestión remota, antivirus, detección en el puesto, el cliente de copias, la supervisión, el seguimiento de activos. Cada proveedor dice menos del uno por ciento, hay seis de ellos, y la persona que de verdad tiene que trabajar en ese portátil es la que descubre a cuánto suman seis de ellos. Casi cero es el objetivo correcto. La prueba es la única manera de establecerlo.
Pide las cifras antes del despliegue, y pide tomar las tuyas después en una máquina que tú elijas. Un proveedor confiado en su herramienta ofrece ambas sin que se le empuje.
Una más sobre la herramienta en sí, y es la que la gente encuentra más extraña hasta que lo piensa. ¿Se te dice cuándo el agente se actualiza en tus máquinas?
El agente es el software de mayor privilegio de tu parque. Corre como sistema, en todo, y cambia de versión cuando el proveedor o el fabricante deciden que debería. Se está instalando software por toda tu empresa por un tercero, en silencio, y en la mayoría de los contratos nadie te dice que pasó.
Ahora pon eso al lado de lo que de verdad salió mal en Kaseya. Una actualización maliciosa empujada por un canal de gestión de confianza a cada máquina a la vez. Desde donde tú estás, el día mismo, eso es indistinguible de una actualización de agente rutinaria — mismo canal, mismo privilegio, mismo silencio. La única diferencia es la intención. La intención no es algo que puedas observar.
Así que pide notificaciones de cambio de versión, pregunta quién aprueba una actualización de agente y si se prueba en algún sitio antes de alcanzarte, y pregunta la que más importa: ¿qué te diría que ocurrió un empuje que no debería haber ocurrido? Si la respuesta honesta es nada, entonces el control en el que te apoyas es la propia vigilancia del proveedor, que es de lo que trata toda esta sección.
Y las llaves que la abren
Luego está lo que abre la consola. Eso recibe aún menos atención que la consola.
Un MSP tiene credenciales administrativas para cada cliente de su cartera. Es el oficio — es todo el producto. Así que el criterio aplicado a sus propias credenciales debería ser más alto que el que fija para las tuyas, y en la práctica es rutinariamente más bajo. Cuentas compartidas, porque inicios de sesión individuales para doce ingenieros sobre doscientos inquilinos es un engorro. Contraseñas en un cofre que toda la mesa de servicio puede leer. Claves SSH sin frase de paso posadas en portátiles que se van a casa en el tren. Cuentas de emergencia que nadie ha tocado desde que la persona que las hizo dejó la empresa.
«Usamos MFA» es donde esa conversación normalmente se para, y no debería, porque sus formas no son iguales. La CISA las clasifica de la más fuerte a la más débil: FIDO/WebAuthn y las basadas en PKI arriba, que llama «the gold standard» — el estándar de oro; contraseñas de un solo uso por aplicación y notificaciones push por debajo, «vulnerable to push bombing attacks as well as user error» — vulnerables a los ataques de bombardeo push así como al error del usuario; y SMS del todo abajo, que «should only be used as a last resort MFA option» — solo debería usarse como opción de MFA de último recurso. Solo la fila de arriba resiste al phishing. Todo lo de debajo se puede retransmitir, fatigar o interceptar mientras la persona que lo aprueba cree que inicia sesión con normalidad.
Los atacantes también han leído ese documento. El aviso de la CISA sobre Scattered Spider dice que el grupo «targets large companies and their contracted information technology (IT) help desks» — apunta a grandes empresas y a sus mesas de ayuda de TI contratadas. No al cliente. La mesa de ayuda que puede reiniciar las credenciales del cliente. Eso es mucho más fácil, y te da a todo el mundo a la vez.
Así que la pregunta es más estrecha que si usan MFA. ¿Está cada cuenta que puede alcanzar tus sistemas en un token de hardware — un token, no una aplicación — y qué pasa cuando alguien llama a la mesa de servicio a las once de la noche diciendo que es un ingeniero que se ha quedado fuera?
El arreglo aquí es excepcionalmente simple, lo que hace su ausencia difícil de perdonar. Google le dijo a KrebsOnSecurity en 2018 que «has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017» — no ha tenido a ninguno de sus más de 85 000 empleados phisheado con éxito en sus cuentas de trabajo desde principios de 2017 —, cuando empezó a exigir llaves de seguridad físicas en vez de contraseñas y códigos de un solo uso. No menos incidentes. Ninguno. El mismo artículo nota que la llave básica se vendía al por menor a veinte dólares.
Ahora escala eso a un proveedor de servicios gestionados. No necesitan emitir llaves a tu personal. Necesitan emitirlas a sus propios ingenieros, y hay quizá una docena de esos que tienen las credenciales que alcanzan a cada cliente de la cartera. Una docena de llaves, compradas una vez, contra un radio de explosión que cubre cada empresa que tocan. Veinte libras cada una. Cuando alguien te dice que los tokens de hardware son impracticables, pregunta cuánta gente necesitaría de verdad uno.
Y hay una pregunta relacionada que deberías hacer sobre tu propio parque, porque la mayoría de los clientes nunca ha pensado en ello. ¿Quién tiene la cuenta de emergencia de tus sistemas? En muchísimos contratos la respuesta honesta es que la tiene el proveedor, y tú no tienes un juego en absoluto. No puedes entrar en tu propia infraestructura sin llamarlos. Eso no es un control de seguridad, es una dependencia. Muerde en los peores días en vez de en los ordinarios. El día que das el aviso. El día que los compra alguien que tú no elegiste. El día que son ellos los comprometidos y tienes que actuar sin ellos.
Deberías tener tus propias credenciales de emergencia, selladas, escritas en el contrato, y probadas en una fecha que alguien pueda señalar. Si tu proveedor es reticente, la reticencia misma te ha dicho algo.
La misma pregunta baja hasta el escritorio, y esta es la que se olvida del todo. Cada portátil y sobremesa que te construyeron tiene una contraseña de administrador del BIOS puesta, fijada durante la construcción por alguien de su lado. Tú posees la máquina. Ellos tienen la llave de ella.
Piensa en lo que esa contraseña gobierna de verdad. El orden de arranque. El arranque seguro. Si la cosa arrancará siquiera de un pendrive USB. Es decir, si puedes reinstalar una máquina que posees, recuperar una que no arranca, entregar un lote a otro, o borrarlas como es debido antes de que salgan por la puerta. En un portátil también puede ser lo que se interpone entre un ladrón y el disco. Nada de eso es exótico. Es el asunto ordinario de poseer ordenadores, y en muchísimos parques el dueño no puede hacer nada de eso sin llamar al proveedor.
Pide el lote. Cada portátil, cada sobremesa, cada servidor — la contraseña del BIOS o firmware, el inicio de sesión del BMC en todo lo que tenga uno, y la contraseña del gestor de arranque en todo donde GRUB o su equivalente se haya bloqueado, que es el mismo candado una capa más arriba y es lo que se interpone entre ti y un arranque de rescate en un servidor que no arranca. Si es la misma contraseña en todos, eso vale la pena saberlo también. Y si la respuesta es no, pregunta por qué no, porque las razones que se ofrecen son delgadas: la honesta es que hace más fácil su construcción, y el resto va disfrazado de seguridad. Una contraseña que no tienes permiso de tener no te protege de nadie. Los protege a ellos de que te vayas.
Luego está la cuenta con la que de verdad inicias sesión para arreglar una máquina. Administrador local en cada caja Windows, root en cada Linux, y algo equivalente en cada switch, cortafuegos e hipervisor del edificio. Dos preguntas cubren el lote, y cubren también las contraseñas de firmware y gestor de arranque de arriba. ¿Son distintas en cada máquina, y qué sistema de gestión de contraseñas las tiene — el tuyo, o el suyo?
Que sean distintas importa más de lo que la gente espera. Una contraseña de administrador local en doscientas máquinas no son doscientas contraseñas, es una, y está posada en el portátil menos defendido de la empresa tanto como en el servidor de finanzas. Eso no es una debilidad teórica, es la jugada estándar — entrar en cualquier cosa, leer la contraseña, andar hacia todo. Microsoft entrega la respuesta en la caja. Windows LAPS fija una contraseña distinta en cada máquina, la renueva según un calendario, y la respalda en Active Directory o tu propio tenant de Entra. La propia página de Microsoft lista el beneficio primero como «protection against pass-the-hash and lateral-traversal attacks» — protección contra los ataques pass-the-hash y de traslado lateral —, y la función es gratis en cada versión soportada de Windows, sin nada más que pagar para guardar las contraseñas en tu propio directorio. Así que si la respuesta es una contraseña en todas partes, no es un problema de licencia y no es un problema de herramienta. Alguien nunca la activó.
De qué sistema es el que hay que presionar, y fíjate en dónde pone LAPS la contraseña por defecto: en tu directorio, bajo tu control de acceso, con tu registro de quién la leyó. Esa es la forma que quieres en todo. La credencial de tu máquina vive en algo que posees, y a tu proveedor se le concede acceso a ella — un acceso que puedes ver, y retirar un martes por la tarde sin pedir permiso.
La otra forma es la común. Las contraseñas se sientan en su gestor de contraseñas, o en el cofre de acceso privilegiado atornillado a su herramienta de gestión remota, y no tienes inicio de sesión para él. Entonces cada contraseña administrativa de tu empresa la tiene una empresa con la que no tienes cuenta, el registro de quién leyó una es suyo, y el día que la relación se agría estás pidiendo con educación las llaves de máquinas que posees.
Así que haz la repregunta, y hazla ahora en vez de en la reunión de salida. ¿Cómo entran estas en nuestro sistema? Hay tres respuestas honestas. Mover el depósito a nuestro directorio o nuestro cofre, y tomar un acceso delegado a él. O darnos acceso de lectura al vuestro hoy, con un export que podamos lanzar nosotros mismos, en un formato que nuestro propio cofre trague. O entregarnos una copia sellada según un calendario, fechada, que abramos y probemos. «Está todo en nuestro sistema y lo tendrás cuando te vayas» no está en la lista, porque el día que te vas es el día que tienen menos razón para ser rápidos con nada.
Y pregunta qué pasa con esas contraseñas después. Una credencial que sus ingenieros han conocido durante cuatro años no se vuelve segura por un correo diciendo que se fue. Cada una de ellas necesita renovarse a la salida, por ti, en máquinas de las que ahora tienes la contraseña de firmware.
Y luego la versión en vivo de todo ello. ¿Se te dice cuándo se lee una contraseña de uno de tus sistemas?
No un registro que ellos guardan y podrían enseñarte si lo pidieras. Un mensaje que llega a tu lado: qué credencial, qué ingeniero, qué ticket, y cuándo. La capacidad no está en duda en ningún sitio — cada cofre digno del nombre registra una retirada, y el propio depósito de Microsoft lo hace en tu propio tenant, donde recuperar una contraseña se escribe en el registro de auditoría de Entra como «Recover device local administrator password» — recuperar la contraseña de administrador local del dispositivo — contra la cuenta que lo hizo. Así que la única pregunta real es si el registro apunta a algún sitio que puedas ver.
Pregunta, y si la respuesta es no, pregunta por qué no. Hay un no honesto ahí en algún sitio — una alerta en cada retirada en un parque cargado se dispararía cuarenta veces al día y dejarías de leerla para el miércoles. Eso tiene una respuesta en vez de ser el final de la conversación. Alerta sobre las que deberían ser raras: la cuenta de administrador de dominio, las credenciales de emergencia, las contraseñas de firmware y gestor de arranque, las claves de recuperación. Y alerta sobre cualquier lectura sin número de ticket pegado, porque eso es o una llevanza de registros descuidada o precisamente la cosa de la que quieres oír, y ninguna de las dos se sirve bien enterándose en la revisión trimestral.
Lo que pueden hacer una vez dentro
Una más, y es la que más a menudo recibe una mirada en blanco. ¿Se te dice cuándo uno de sus ingenieros entra en tus sistemas?
No un registro que ellos guardan. Una notificación que recibes — quién entró, cuándo, por cuánto tiempo, y contra qué ticket. Pídela, y si la respuesta es no, pregunta por qué no.
Hay un precedente, y se sienta dentro de los productos que te revenden. El Customer Lockbox de Microsoft hace que un ingeniero de Microsoft pida tu aprobación explícita antes de poder alcanzar tu contenido en un caso de soporte. Google publica registros de Access Transparency de su propio personal tocando tus datos, y Access Approval hace que pidan primero. Así que los mayores proveedores de la tierra, con un acceso mucho más estrecho que el que tiene tu proveedor, han construido flujos de aprobación y registros de acceso para sus propios empleados, y te entregan el registro.
Tu MSP tiene administrador de dominio. Pregunta qué te entrega.
Y hay una razón más dura que la rendición de cuentas. Una notificación que llega a tu lado es el único signo independiente que obtendrás jamás de que sus credenciales las está usando alguien que no son ellos. Si un atacante entra por una mesa de servicio, cada registro que lo mostraría se sienta dentro de la organización que acaba de ser comprometida. Uno que aterriza en tu bandeja de entrada se sienta fuera.
Un nivel por debajo de eso otra vez, en la máquina misma. ¿Puede la herramienta remota conectarse al escritorio de alguien sin que esa persona lo consienta?
Para un servidor a las tres de la mañana, el acceso sin supervisión es todo el objeto y nadie sensato objeta. Para una máquina a la que alguien está sentado, con su correo abierto y su trabajo en la pantalla, es un acto distinto. Cada producto de gestión remota serio se puede ajustar para pedir antes de conectarse, para mostrar un indicador visible mientras una sesión está en curso, y para dejar que la persona rechace. Que el tuyo haga algo de eso es un ajuste de configuración, y el ajuste lo eligieron las personas a quienes les conviene.
Así que pregunta tres cosas, y mantenlas separadas. ¿Pueden tus ingenieros alcanzar un escritorio del personal sin aviso? ¿La persona sentada delante ve algo mientras alguien está conectado? ¿Puede rechazar?
Si la primera es sí y las otras dos no, eso no es una restricción técnica. Es un valor por defecto que nadie revisó, sobre un producto comprado por la parte a la que favorece. También vale la pena ponerlo delante de quien lleve la protección de datos en tu organización, porque alguien mirando la pantalla de un empleado sin su conocimiento es una decisión que debería tener un nombre enfrente.
Luego la pregunta que decide si algo de esto es demostrable después. ¿Se graba a sus ingenieros mientras trabajan en tus sistemas?
La grabación de sesión no es exótica y no es una gran petición. Es una función estrella de cada producto de acceso privilegiado del mercado, lo que quiere decir que tu proveedor bien posiblemente ya la paga y nunca la ha activado. Una sesión grabada te da un vídeo, o un registro de pulsaciones y comandos, o los dos, ligados a un ingeniero nombrado y un número de ticket. Así es como se ve la rendición de cuentas cuando es real en vez de prometida — no una garantía de que los ingenieros se portan bien, sino un registro que lo mostraría si uno no lo hiciera.
Así que pregunta si está activada, y luego pregunta cómo accedes a ellas, porque una grabación que no puedes obtener no es una prueba, es un rumor. Hay tres respuestas que vale la pena tener, en orden descendente. Las grabaciones aterrizan en un almacenamiento que posees, escritas a medida que se hacen. O tienes acceso de lectura a su sistema hoy, con un export que puedes lanzar tú mismo. O hay una vía de solicitud con un plazo estipulado — horas, por escrito, en el contrato — que has probado al menos una vez en una sesión ordinaria en vez de por primera vez durante una discusión.
Lo que no quieres es el arreglo común: grabaciones guardadas solo por el proveedor, retención fijada por el proveedor, borrado a voluntad del proveedor. Ese es un control que funciona perfectamente hasta el día en que se necesita contra el proveedor. Así que pregunta quién puede acortar la retención, quién puede borrar una, y si mirar una grabación se registra en sí. Y pregunta qué pasa con el lote el día que te vas.
Sé justo con el otro lado de ello, porque lo hay. Una grabación de un ingeniero arreglando un portátil es también una grabación de lo que tu personal tenía en esa pantalla, y de vez en cuando de una credencial tecleada a la vista de todos. Las grabaciones son sensibles por derecho propio y quieren el mismo trato que el cofre: cifradas, con acceso controlado, registradas al consultarse, guardadas por un periodo estipulado y no más. Un proveedor que saca eso contigo antes de que tú lo saques con él ha pensado en el problema. Uno que nunca lo ha considerado te ha dicho algo también.
La misma herramienta casi con certeza mueve ficheros, en ambos sentidos. Pregunta si lo hace, y luego pregunta qué se ha puesto a su alrededor.
Lo saliente es lo que nadie cotiza. Una transferencia por el canal de gestión está cifrada, es de confianza, y se sienta fuera de cada control que ya has pagado — la prevención de fuga de datos, la supervisión de salida, la política sobre pendrives USB. Cualquiera con acceso a la consola puede tomar una copia de cualquier cosa en cualquier máquina, y en la mayoría de los despliegues no hay registro de ello que se te vaya a enseñar jamás.
Lo entrante es cómo los incidentes de más arriba en este artículo pasaron de verdad. Empujar un fichero a cada puesto a la vez no es un defecto de estos productos, es la función estrella. El ransomware simplemente la usó como fue construida para usarse.
Así que pregunta si la transferencia de ficheros está activada siquiera, si se puede apagar en las máquinas que nunca la necesitan, si cada transferencia se registra con el fichero, la dirección, la máquina y el ingeniero — y si ese registro te llega a ti, o se une a los otros en su bandeja de entrada.
Y lo último sobre esto, porque es lo que nadie piensa en preguntar en absoluto. ¿Qué recoge de verdad el agente, y qué pasa con ello?
Estas herramientas recogen mucho más que un nivel de parche. Inventario de hardware y software, registros de eventos, telemetría de rendimiento, a menudo grabaciones de sesión y capturas de pantalla, a veces mucho más según lo que esté activado. Es una imagen detallada de cómo funciona tu empresa y qué hace tu personal todo el día. Está saliendo de tus instalaciones de forma continua.
Así que pregunta qué se recoge, dónde se almacena y bajo qué jurisdicción, cuánto tiempo se guarda, y quién puede verlo — porque la respuesta suele ser el proveedor y el fabricante de la herramienta, que es una segunda empresa que nunca elegiste y con la que no tienes contrato. Pregunta si algo de ello se usa para algo más allá de darte soporte: analítica de producto, benchmarking, entrenamiento de modelos. Pregunta qué pasa con todo ello el día que el contrato acaba, y consíguelo por escrito en vez de en una conversación.
Y fíjate en de quién son los datos. Registros sobre tu personal y tus sistemas, en poder de alguien que trata por cuenta tuya, es una frase con obligaciones pegadas, y son tuyas en vez de suyas.
El chip que responde cuando la máquina está apagada
Hay una capa más por debajo de todo eso, y vale la pena preguntar por ella por su nombre. ¿Usan Intel vPro, o la Active Management Technology de debajo?
Si no te la has encontrado, la versión corta es que un firmware de gestión corre en un controlador separado dentro del chipset, con su propia pila de red. Responde mientras la máquina está apagada, siempre que haya corriente y un cable. Puede encender la caja, cambiar los ajustes del BIOS, montar una imagen remota y reinstalar, y en la configuración adecuada tomar la pantalla y el teclado a nivel de hardware — antes de que el sistema operativo haya cargado, y lo haga alguna vez o no.
Hay razones reales para quererlo. Una máquina que no arranca, un ajuste del BIOS en un dispositivo a trescientas millas, una reimagen sin mandar a nadie. En un parque grande y disperso es útil y no fingiré lo contrario.
Pero mira dónde se sienta. Por debajo del sistema operativo, lo que quiere decir por debajo de cada control que has comprado. Tu protección en el puesto no puede verla, porque no corre en el sistema operativo. Tu cortafuegos de host no la filtra, porque el tráfico nunca alcanza la pila de red del sistema operativo — se maneja en sus propios puertos antes de que nada más le eche un ojo. Tu registro no la cubre. Nada de lo que hayas instalado puede decirte que tuvo lugar una sesión.
El historial de seguridad tampoco es tranquilizador. CVE-2017-5689 puntuó 9,8, y la descripción vale la pena leerla despacio: «an unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs» — un atacante de red sin privilegios podría obtener privilegios de sistema en los SKU de gestión de Intel aprovisionados. La CISA emitió una alerta y CERT/CC una nota de vulnerabilidad. Fíjate en esa palabra «provisioned» — dormido no es una vía de entrada, y encendido lo es. Y el firmware que la porta no se actualiza por el parcheado normal que estás pagando. Viene del fabricante de la máquina, en su calendario.
Luego está la parte que debería preocupar a cualquiera responsable de personal en vez de servidores. El control de pantalla a nivel de hardware quiere decir que alguien puede mirar una pantalla mientras el sistema operativo no tiene ni idea. Pregunta si el aviso de consentimiento del usuario está impuesto y si el indicador de sesión visible está encendido, porque los dos son configuración y los dos los puede apagar quien la aprovisionó.
Así que las preguntas son cortas. ¿Está aprovisionada en nuestras máquinas, y quién lo hizo, y cuándo — fue parte de una construcción que nadie mencionó? ¿Qué trabajos concretos la necesitan, y cuántas máquinas necesitan de verdad esos trabajos? ¿Qué red puede alcanzar los puertos de gestión, y está segmentada de todo lo demás? ¿Está impuesto el consentimiento, está encendido el indicador, y dónde está la pista de auditoría? ¿Y se puede desaprovisionar en cada máquina que no la necesita?
Si la respuesta a la primera es «no lo sabemos», eso vale la pena saberlo por sí solo, porque quiere decir que la capacidad está posada ahí, configurada por alguien y vigilada por nadie.
El riesgo entró gratis
Dale la vuelta a todo este capítulo del revés y dice una cosa. Cada capacidad de él llegó como una comodidad y se cotizó como una. El agente que parchea mil máquinas es la cosa que puede poner un fichero en mil máquinas. El chip que ahorra un viaje de doscientas millas responde cuando la máquina está apagada y no le dice nada a tu registro. La comodidad se cotizó, se detalló y se aprobó. La capacidad vino en la misma caja, sin cotizar. No aparece en ningún documento que se te haya enseñado jamás.
Nada de eso es un argumento para pasar sin nada de ello. Los parques necesitan parcheado, y alguien tiene que poder alcanzar una máquina muerta. Es un argumento para saber qué hay en el edificio, quién puede alcanzarlo, desde dónde, y qué haría falta para que la persona que tiene ese alcance sea alguien distinto de la empresa que lo tiene actualmente. Una factura nunca te lo dirá, porque una factura es una lista de lo que pagas. No es una lista de a qué estás expuesto. A nadie en este arreglo se le ha pedido jamás producir la segunda.
La parte tres es lo que pasa cuando uno de ellos se dispara. Lo que el contrato promete de verdad, quién acaba cargando con la pérdida, a qué suenan las excusas, y lo que cuesta irse cuando por fin has tenido bastante.
Fuentes
Consultadas el 28 de agosto de 2026.
Formación y competencias.
- National Vulnerability Database — recuentos de publicación de CVE por año, sumados por trimestre: 6 595 en 2015 contra 49 972 en 2025.
El material.
- CVE-2018-0141 — contraseña de cuenta codificada en duro, Cisco Prime Collaboration Provisioning, marzo de 2018.
- CVE-2018-15439 — Small Business Switches, una cuenta privilegiada habilitada sin notificar a los administradores, noviembre de 2018.
- CVE-2023-20101 — Cisco Emergency Responder, credenciales root estáticas que no se pueden cambiar ni borrar, octubre de 2023.
- Der Spiegel, 29 de diciembre de 2013 — el catálogo ANT, nombrando a Cisco y Huawei entre otros, de los documentos de Snowden.
- Der Spiegel, 29 de diciembre de 2013 — dentro de TAO: interdicción, estaciones de carga, y qué le pasa a un envío desviado.
- Ars Technica, 14 de mayo de 2014 — el boletín interno de la NSA de 2010 y las fotografías de un router Cisco siendo implantado, publicadas en No Place to Hide de Glenn Greenwald.
- Cisco, 13 de mayo de 2014 — la respuesta de la empresa, en sus propias palabras.
- Fiscal general de Nueva York, 2019 — el acuerdo multiestatal por el software de videovigilancia vendido a organismos públicos, y el calendario de 2009 a 2013.
El material perimetral.
- Catálogo de vulnerabilidades explotadas conocidas de la CISA — versión 2026.08.27, 1 685 entradas; los recuentos por fabricante de este artículo son mi propio conteo de ese fichero.
- CVE-2024-3400, CVE-2024-0012 — PAN-OS, GlobalProtect y la interfaz web de gestión.
- CVE-2022-40684, CVE-2018-13379 — elusión de autenticación de FortiOS y salto de directorio del VPN SSL.
- CVE-2023-20198, CVE-2025-20333, CVE-2026-20316 — la interfaz web de Cisco IOS XE, el servidor web VPN del ASA, y una contraseña codificada en duro en Secure Firewall Management Center.
- CISA, Implementing Phishing-Resistant MFA — la clasificación de las formas de MFA, de la más fuerte a la más débil.
- KrebsOnSecurity, julio de 2018 — Google sobre sus más de 85 000 empleados y ningún phishing con éxito tras exigir llaves de seguridad físicas.
- Aviso conjunto AA23-320A — Scattered Spider, y su ataque a las mesas de ayuda de TI contratadas.
- Resumen de Windows LAPS — una contraseña de administrador local distinta por máquina, renovada y respaldada en tu propio Active Directory o tenant de Entra; gratis en cada versión soportada de Windows.
Cuando sale mal.
- ICO, marzo de 2025 — Advanced Computer Software Group multada con GBP 3,07 millones, la primera penalización del regulador contra un encargado del tratamiento. La página de ejecución lleva el detalle.
- ICO, octubre de 2025 — Capita multada con GBP 14 millones por la brecha de 2023: la alerta de diez minutos, la respuesta de 58 horas contra un objetivo de una hora, y el Security Operations Centre falto de personal.
- Law Society Gazette, 28 de noviembre de 2023 — unos 80 bufetes de compraventa incapaces de concluir transacciones tras caerse su proveedor de TI.
- La CISA y el FBI sobre el ataque a Kaseya VSA, julio de 2021 — ransomware contra los proveedores de servicios gestionados y sus clientes aguas abajo.
- Aviso conjunto AA23-025A, 25 de enero de 2023 — la CISA, la NSA y el MS-ISAC sobre el uso malicioso de software RMM legítimo.
- CVE-2024-1709 — elusión de autenticación de ConnectWise ScreenConnect, CVSS 10,0, febrero de 2024.
- Aviso de la CISA AA25-163A, junio de 2025 y CVE-2024-57727 — actores de ransomware alcanzando a clientes aguas abajo a través de SimpleHelp RMM sin parchear.
- Aviso conjunto AA22-131A, 11 de mayo de 2022 — las agencias del Reino Unido, Australia, Canadá, Nueva Zelanda y EE. UU. sobre las amenazas a los proveedores de servicios gestionados y sus clientes.