De un peak de CPU a un servidor minando cripto: lo que tu monitoreo no te está contando

Tu plataforma te dice si la red está arriba y si está rápida. No te dice si lo que está pasando es normal. Ese punto ciego es donde vive hoy la mayoría de los incidentes que terminan costando caro.

Salta una alerta: la CPU de un servidor se disparó. Nadie desplegó nada, no hubo ventana de mantenimiento. El equipo revisa el gráfico, confirma el alza, reinicia un servicio y cierra el ticket en 40 minutos. Buen tiempo de respuesta.

Salvo que el peak no era un problema de capacidad: era el síntoma. Más abajo reconstruimos, paso a paso, qué había realmente detrás de esa alerta.

Dos preguntas resueltas y una tercera sin responder

El monitoreo de red se construyó alrededor de dos preguntas: «¿está arriba?» (disponibilidad: ping, SNMP, uptime) y «¿está rápido?» (rendimiento: ancho de banda, latencia, NetFlow). Ambas siguen siendo imprescindibles y ninguna herramienta nueva las vuelve obsoletas.

Pero juntas dejan afuera una tercera: «¿es normal?». Un servidor puede estar perfectamente disponible, con latencia impecable, y estar enviando datos a un destino al que nunca antes se conectó. Disponibilidad: verde. Rendimiento: verde. Comportamiento: alarmante. Y nadie lo ve.

Las tres preguntas del monitoreo. La mayoría de las organizaciones solo puede responder las dos primeras.

El costo de esa brecha, en números

El estudio Network Management Megatrends 2026 de EMA (352 profesionales de TI) pone cifras al problema: solo el 37 % de las alertas corresponde a un problema real, el 42 % de los incidentes se detecta cuando el usuario ya los sufre y el 29 % de la jornada del especialista se va en apagar incendios.

Fuente: Enterprise Management Associates (EMA), «Network Management Megatrends 2026».

La capa que faltaba

La tercera pregunta tiene nombre: inteligencia de comportamiento, o NDR en su versión orientada a seguridad. No reemplaza a las capas anteriores; se apoya en ellas y las completa.

Las tres capas se alimentan de la misma infraestructura: cambia la pregunta, no el cableado.

El mecanismo tiene cuatro etapas. Observa los flujos que tus switches, routers y firewalls ya exportan (NetFlow, IPFIX, sFlow) —sin agentes ni cambios en la red—. Aprende qué es normal para cada dispositivo, en cada horario. Detecta desviaciones estadísticas sin necesidad de firmas ni reglas escritas a mano. Y explica qué cambió, cuánto y con qué contexto histórico.

Como el análisis usa metadatos y no contenido, funciona igual sobre tráfico cifrado.

Y lo que aparece no siempre es un ataque: buena parte son problemas de higiene operativa —Telnet activo, respaldos en horario productivo— que hoy se descubren seis meses tarde y en una auditoría.

El mismo motor sirve a NetOps y a SecOps: cambia la lectura, no la señal.

Un caso completo: de la alerta a la causa raíz

Veamos qué pasa cuando esta capa está activa. El caso que sigue está tomado de una investigación real reproducida por Progress con WhatsUp Gold. No hace falta conocer la herramienta: lo importante es la secuencia de preguntas, que se repite igual en cualquier plataforma con capa de comportamiento.

El escenario. Una red corporativa con servidores en data center propio. Los switches y routers exportan flujos hacia la plataforma de monitoreo, así que existe un registro de cada conversación de red: quién habló con quién, cuándo, por qué puerto y cuántos bytes. Nadie instaló nada en los servidores. Un lunes por la mañana, la CPU de un servidor de aplicaciones —lo llamaremos por su dirección interna, 10.40.88.132— se dispara sin explicación.

Se cambia la pregunta.El monitoreo tradicional termina en el gráfico de CPU: confirma que subió, no dice por qué. En vez de quedarse ahí, el operador pregunta otra cosa: ¿con quién ha estado hablando este servidor? Como la plataforma guarda el historial de conversaciones de red, la respuesta está a un clic.

1. Primer hallazgo: el servidor está escaneando la red.En los últimos días intentó abrir conexiones contra siete equipos de la propia red, probando puertos uno por uno —FTP, SSH, Telnet, y decenas más—: 11.584 intentos sin respuesta en cinco minutos. Eso se llama escaneo de puertos y es la fase de reconocimiento de un ataque: alguien está levantando un mapa de qué hay alrededor. Un servidor de aplicaciones no hace eso jamás por sí solo.

2. No es un hecho aislado.Al pedir todos los eventos asociados a esa dirección aparecen cinco familias distintas: el escaneo, consultas DNS fuera de patrón, comunicaciones con destinos con los que nunca había hablado, un cambio en su comportamiento de largo plazo y una coincidencia con una amenaza conocida. Cinco señales convergiendo en el mismo equipo.

3. Aquí está el peak de CPU: criptominería.Una de esas señales identifica minería de criptomonedas. El detalle de flujos muestra las conversaciones salientes: direcciones en Francia y Estados Unidos que corresponden a pools de minería públicos. El servidor no tenía un problema de capacidad; estaba trabajando para otra persona, que factura con tu cómputo y tu cuenta de electricidad.

4. Cómo entró: la cadena de suministro.El evento de amenaza nombra la campaña. Un paquete malicioso (plain-crypto-js) fue introducido como dependencia de Axios, una librería legítima y ampliamente usada en desarrollo. Al instalarse, ejecuta un cargador que despliega un troyano de acceso remoto y abre un canal hacia un servidor de mando y control del atacante. Ese canal es el que da las órdenes: mina, escanea, propágate. La plataforma lo clasifica según MITRE ATT&CK —el marco estándar que cataloga las técnicas de los atacantes— cubriendo acceso inicial, ejecución, persistencia, evasión y control remoto.

5. Hasta dónde llegó.Desde el mismo evento se abre la lista de con quién conversó el servidor. Casi todo es tráfico esperable, salvo una comunicación con otro servidor interno, 10.40.81.10. Al abrirla aparece una sesión SSH de más de 25 segundos con datos fluyendo en ambos sentidos. La distinción es clave: un intento de adivinar contraseñas se vería como cientos de conexiones cortas y fallidas; una sesión larga y bidireccional significa que alguien entró y estuvo trabajando dentro. Hay un segundo servidor comprometido.

Lo que se obtuvo, en unos pocos clics

Causa raíz identificada (una dependencia de software comprometida) · Impacto confirmado (criptominería corriendo en producción) · Propagación detectada (un segundo servidor tomado) · Evidencia preservada: los registros de conversaciones viven en la plataforma de red, así que sobreviven aunque el atacante borre los logs del servidor —cosa que este malware, de hecho, hace.

"¿No serán más alertas de las que ya no alcanzo a revisar?"

Es la objeción correcta y hay que responderla de frente: si dos de cada tres alertas ya son ruido, sumar una fuente nueva parece empeorar el problema.

La diferencia está en cómo se genera la señal. Un umbral fijo «avísame si la CPU pasa de 80 %» dispara cada vez que algo legítimo se repite: el respaldo del domingo, el cierre de mes, la carga masiva de fin de trimestre. Una línea base aprendida por dispositivo y por franja horaria no dispara con eso, precisamente porque ya sabe que ocurre todas las semanas. Y en el caso anterior, seis señales distintas no generaron seis tickets: se agruparon en un solo relato sobre un mismo equipo.

Eso sí, tiene un requisito no negociable: dejar aprender antes de alertar. Entre dos y cuatro semanas en modo observación, cubriendo al menos un ciclo semanal completo. Encender las alertas el primer día es el error de despliegue más común y la forma más rápida de que el equipo pierda la confianza en la herramienta.

Por qué esto le importa al equipo de red

La objeción habitual es «la seguridad la ve el equipo de seguridad». El problema es que no coincide con la secuencia real: los incidentes no empiezan siendo incidentes, empiezan siendo anomalías. Entre la primera señal y la exfiltración pasan días o semanas, y en todo ese tramo los datos de red ya están disponibles.

Cuanto más a la izquierda se detecta, más opciones existen y menor es el daño.

El valor de esta capa no es pedirle a NetOps que responda a amenazas. Es darle visibilidad para detectar la primera señal y escalar con evidencia, no con intuición: la diferencia entre «creo que algo raro pasa» y «este host escaneó 11.584 puertos, está minando contra un pool en Francia y abrió una sesión SSH sostenida hacia este otro servidor».

Sumar esta capa es menos trabajo de lo que parece: se alimenta de exportadores de flujo que la mayoría del equipamiento empresarial ya trae (NetFlow, IPFIX o sFlow, según el fabricante). El punto de partida realista es inventariar qué switches, routers y firewalls pueden exportarlos y empezar por el borde de internet y el core.

La red ya te está contando lo que pasa. La pregunta es si alguien está escuchando esa parte de la conversación.

¿Quieres ver cómo se ve tu red en esta tercera capa?

En Empresa Conectada somos partner de Progress y trabajamos con equipos de TI en Chile para dimensionar, desplegar y operar plataformas de monitoreo unificado. Podemos revisar contigo qué protocolos (exportadores de flujo) ya tienes activos y qué tan lejos está tu operación de responder las tres preguntas.

Pruébalo en tu propia red, sin costo

La mejor forma de saber qué está pasando en tu red no es leerlo: es verlo. En Empresa Conectada somos partner de Progress en Chile y montamos pruebas de concepto de WhatsUp Gold sin costo. El requisito es tan simple como suena: un servidor Windows Server (on-premise o en la nube) y listo. Nosotros nos encargamos de la instalación y de acompañarte durante toda la prueba, para que en pocos días veas tu red —no una demo— respondiendo las tres preguntas. Si al final de la PoC no encuentras nada que no supieras, no perdiste nada. Y si encuentras algo, lo encontraste a tiempo.

Revisa el detalle de la solución en WhatsUp Gold · Monitoreo unificado de red, o escríbenos y coordinamos la prueba de concepto esta misma semana.

Quiero mi PoC gratuita →

Fuentes: Enterprise Management Associates, Network Management Megatrends 2026 · Network World · Progress WhatsUp Gold, Network Detection and Response y demostración en vivo Availability, Performance and Behavior (webinar).