Durante años, en el área de IT se nos entrena para pensar en una sola misión: mantener a los atacantes fuera. Sin embargo, un incidente investigado recientemente muestra algo igual de importante: lo que ocurre después de que ya lograron entrar puede ser la parte decisiva del ataque, y también la más costosa si se ignora.
En este caso, el adversario no se limitó a robar o cifrar datos. Tras obtener acceso inicial, dedicó tiempo a “asentarse”, modificar el entorno y reducir la probabilidad de ser detectado. A continuación, verás un desglose de cómo ocurrió y qué implicaciones tiene para una limpieza posterior al incidente que de verdad funcione.
Por qué importan los ataques tras la intrusión
En la práctica, muchos equipos se enfocan en eliminar el “daño visible”: eliminar herramientas maliciosas, borrar archivos, revisar alertas y restablecer servicios. Eso es necesario, pero no suficiente. Los atacantes suelen aprovechar el momento para transformar el sistema comprometido en una plataforma más cómoda para ellos.
Así, en lugar de ejecutar un golpe rápido tipo “robo y salida”, se observa una fase de permanencia: creación de puertas traseras, ocultación de rastros, deshabilitación de componentes de seguridad y cambios que garantizan que puedan volver a entrar si el primer plan falla.
Cómo se originó el acceso inicial
El equipo de seguridad que investigó el caso detectó actividad sospechosa asociada a un proceso de Microsoft SQL Server. Lo relevante es que el atacante no se dirigió al servidor de base de datos “directamente” como único objetivo. En cambio, encontraron una página alojada en el mismo servidor con un fallo de validación de entradas.
Ese error encajaba con una vulnerabilidad clásica de inyección SQL. En términos simples, ocurre cuando una aplicación toma datos que un usuario introduce (por ejemplo, un campo de búsqueda o inicio de sesión) y los envía a una base de datos sin comprobar que la entrada es segura.
Esta brecha permitió que el atacante alcanzara el sistema subyacente de Windows, dejando claro un punto: incluso si el equipo “vigila” ciertos componentes (como el proceso de base de datos), el punto de entrada real puede estar en la capa web.
Reconocimiento antes de cambiar el juego
Una vez dentro, el adversario no actuó con prisas. Primero ejecutó una herramienta del propio sistema operativo para listar qué servicios estaban corriendo. Este paso funciona como reconocimiento: ayuda a identificar qué procesos existen, qué se puede aprovechar y qué podría servir para camuflar actividad.
Además, los resultados de ese análisis se enviaron a un servidor controlado por el atacante. Es habitual que quienes atacan recojan esa información para revisarla después o conectarla con automatizaciones.
Consolidación: acceso remoto, nuevas cuentas y privilegios
Después del reconocimiento, el atacante pasó a convertir el acceso inicial en algo estable. Entre las acciones observadas se incluyó:
- Activar el acceso a Escritorio Remoto, ya que no estaba habilitado previamente.
- Crear una cuenta de usuario nueva y añadirla al grupo de administradores locales.
- Ingresar por Escritorio Remoto usando esa cuenta recién creada.
Este patrón es especialmente preocupante porque da continuidad. Una vez que tienes una cuenta con privilegios y una vía de acceso remoto habilitada, no dependes del mismo vector inicial: incluso si intentan contener el incidente, el atacante puede mantener su control.
Defensas: qué se desactiva y qué se deja intacto
El adversario deshabilitó Windows Defender, el antivirus integrado de Microsoft. Lo llamativo es que no desactivó otras capacidades de monitoreo (por ejemplo, herramientas tipo EDR siguieron presentes).
Esto sugiere varias posibilidades: quizás no era consciente de la existencia del monitoreo adicional, o tal vez intentó suprimir solo partes que encontraba, o no disponía de un método para deshabilitar el resto.
Para los equipos defensivos, el mensaje es claro: no basta con “buscar ransomware” o pensar solo en un tipo de malware. Una intrusión puede incluir ajustes granulares que cambian el terreno.
Convertir el servidor web en una herramienta de fraude
Con el entorno ya bajo control, el atacante instaló complementos maliciosos en Internet Information Services (IIS), el servidor web en ejecución. Estos añadidos pertenecían a una familia conocida como BadIIS.
La finalidad típica de este tipo de abuso es secuestrar el tráfico legítimo del sitio. En lugar de mostrar el contenido esperado, el sitio puede redirigir visitantes, inyectar enlaces ocultos o presentar contenido diferente, favoreciendo conductas de fraude como la manipulación de resultados, posicionamiento o tráfico publicitario.
Es decir: no se trata solo de “infectar el equipo”, sino de usar la infraestructura comprometida como palanca para afectar terceros y monetizar el acceso.
Minería de criptomonedas y técnicas para ocultarla
Además, el atacante instaló un programa de minería de criptomonedas. En un escenario así, el valor proviene del uso de la capacidad de cómputo del sistema comprometido para generar moneda, a costa de la víctima (incluidos consumos energéticos).
Para reducir la probabilidad de detección, se emplearon varias medidas:
- Ocultar atributos de archivos marcándolos como ocultos, sistema y de solo lectura.
- Configurar el minero como servicio en Windows usando una herramienta administrativa legítima y disponible libremente, de manera que arrancara automáticamente incluso tras reinicios.
- Agregar una herramienta adicional para ayudar a evadir la detección del malware.
Uso de scripts: continuidad silenciosa
Otra parte del patrón observada fue la descarga de múltiples scripts de PowerShell y archivos por lotes desde servidores externos. Este método permite incorporar funcionalidades sin empaquetarlo todo desde el inicio.
Además, se utilizó PowerShell de una forma orientada a la ejecución silenciosa: sin ventanas visibles, sin avisos evidentes y evitando restricciones habituales de políticas de ejecución.
Por sí solas, estas técnicas no siempre sorprenden. Lo que destaca del caso es la combinación: en una sola máquina y en un solo incidente se acumularon cambios de persistencia, ocultación y abuso de recursos.
Lección principal para la defensa
Es tentador pensar que quien administra sus propios sistemas tiene “ventaja de local”. Pero esa ventaja se pierde si el plan de contención se queda en la superficie. Cuando un atacante entra, puede rediseñar el entorno para sus objetivos, más allá de deshabilitar antivirus o dejar malware.
La clave es una idea: detectar y corregir el punto de entrada importa tanto como limpiar lo que quedó detrás. Si el equipo elimina cuentas y herramientas, pero no repara la causa que permitió el acceso (por ejemplo, una inyección SQL sin validación), el atacante puede volver usando el mismo “camino” que ya conoce.
Acciones prácticas para reducir el riesgo
Con base en el enfoque recomendado, el camino suele empezar por lo básico: saber exactamente qué tienes y cómo está expuesto. A partir de ahí, se proponen medidas de mejora continua:
- Construye un inventario de sistemas físicos y virtuales, además de aplicaciones y sus versiones. Mantén esa información actualizada.
- Reduce la superficie de ataque: menos servicios expuestos y menos aplicaciones visibles implican menos oportunidades.
- Retira lo innecesario o no autorizado. Si no se usa, suele ser un riesgo.
- Endurece el control de accesos: usa autenticación multifactor (MFA) cuando sea posible y limita permisos a usuarios autorizados.
- Mantén parches y monitoreo: aplica actualizaciones de forma regular y asegúrate de que las aplicaciones estén cubiertas por la supervisión.
- Investiga la causa raíz en cada incidente: no te quedes solo en eliminar lo obvio; identifica cómo entró el atacante para fortalecer defensas futuras.
Conclusión
Este caso deja una enseñanza muy concreta sobre los ataques tras la intrusión: una intrusión no termina en el primer acceso. El atacante suele dedicar tiempo a consolidar control, habilitar rutas de regreso, debilitar defensas y convertir el sistema en una herramienta para actividades adicionales.
Por eso, una limpieza efectiva debe ir acompañada de correcciones reales del vector inicial. Si arreglas la brecha, reduces la probabilidad de que el “puente” que abrió el atacante siga disponible.
