¿Hackearon tu empresa? Qué hacer en Uruguay

Un ransomware bloquea los servidores. Una cuenta de Microsoft 365 comienza a enviar correos que nadie reconoce. Aparecen accesos desde ubicaciones desconocidas. Un proveedor avisa que encontró información de la empresa publicada en Internet.

Cuando ocurre algo así, la primera reacción suele ser intentar “arreglarlo” cuanto antes. Sin embargo, durante un incidente de ciberseguridad, una acción apresurada puede eliminar evidencia, alertar al atacante, extender el compromiso o dificultar la recuperación.

Si hackearon tu empresa o sospechás que existe un acceso no autorizado, las primeras horas son críticas. En esta guía explicamos qué hacer durante las primeras 24 horas ante un ciberataque en Uruguay, qué errores evitar y cuándo puede corresponder reportarlo ante organismos como CERTuy, la Dirección General de Cibercrimen o la Unidad Reguladora y de Control de Datos Personales (URCDP).

La amenaza no es teórica. Según datos publicados por CERTuy, durante el primer semestre de 2026 se detectaron y respondieron 32.399 incidentes de seguridad de la información, un incremento del 52% respecto al mismo período de 2025.

¿Qué hacer si hackearon mi empresa?

Antes que nada, es importante entender que un incidente de seguridad no siempre se presenta como una pantalla de ransomware.

Algunas señales frecuentes son:

Archivos cifrados o extensiones desconocidas.
Mensajes solicitando un rescate.
Accesos inusuales a Microsoft 365, Google Workspace, VPN u otros servicios.
Usuarios administrativos creados sin autorización.
Desactivación del antivirus, EDR o herramientas de seguridad.
Correos enviados desde cuentas corporativas sin conocimiento del usuario.
Reglas de reenvío de correo desconocidas.
Transferencias bancarias o cambios de cuentas solicitados por correo.
Consumo anormal de CPU, red o almacenamiento.
Servidores que comienzan a comportarse de forma inesperada.
Información de la organización publicada o puesta a la venta en Internet.
Alertas provenientes de proveedores, clientes o herramientas de monitoreo.

Ante cualquiera de estas situaciones, el objetivo inicial no debería ser simplemente “volver a funcionar”. Hay cuatro prioridades: contener, preservar evidencia, determinar el alcance y recuperar de forma segura.

Primeros minutos: contener sin destruir evidencia

Si existe evidencia de que un equipo está comprometido y el ataque continúa activo, puede ser necesario aislarlo de la red para evitar movimientos laterales hacia otros sistemas.

Por ejemplo, puede desconectarse el acceso de red del equipo afectado o aislarlo utilizando las funciones disponibles en una solución EDR.

Sin embargo, aislar un equipo no es lo mismo que apagarlo, formatearlo o reinstalarlo.

Antes de realizar cambios irreversibles conviene evaluar la situación. Reiniciar o apagar un sistema puede provocar la pérdida de información volátil que podría resultar útil para determinar cómo ingresó el atacante, qué herramientas utilizó o qué acciones realizó.

Cuando sea posible:

Aislá los sistemas comprometidos de la red.
No formatees ni reinstales inmediatamente.
No elimines archivos sospechosos sin analizarlos.
No borres logs.
No desactives masivamente servicios sin evaluar las consecuencias.
Registrá la fecha y hora de cada acción realizada.
Conservá capturas de pantalla, mensajes, correos y alertas.

CERTuy también recomienda realizar el reporte preservando, en la medida de lo posible, las condiciones existentes al momento de detectar el incidente y evitando alterar la evidencia, salvo que sea necesario adoptar medidas urgentes.

1. Determinar qué está pasando

El primer análisis debe intentar responder algunas preguntas básicas:

¿Qué sistema generó la primera alerta?
¿Cuándo comenzó la actividad sospechosa?
¿Qué usuarios o cuentas están involucrados?
¿Hay uno o varios dispositivos comprometidos?
¿Existe evidencia de acceso administrativo?
¿Los atacantes accedieron al correo electrónico?
¿Hay sistemas cloud involucrados?
¿Existe cifrado de información?
¿Hay indicios de extracción de datos?
¿Los respaldos continúan disponibles?

No es necesario tener todas las respuestas inmediatamente. El objetivo es construir una primera imagen del incidente y evitar tomar decisiones basadas únicamente en suposiciones.

2. Proteger las cuentas y credenciales comprometidas

Muchos ataques actuales no comienzan explotando un servidor. Comienzan utilizando una contraseña válida.

Una cuenta comprometida de Microsoft 365, una VPN sin autenticación multifactor o una credencial administrativa reutilizada pueden darle al atacante acceso legítimo a los sistemas.

Si existe evidencia de compromiso de identidad, puede ser necesario:

Bloquear temporalmente cuentas afectadas.
Cambiar contraseñas desde un dispositivo confiable.
Revocar sesiones activas.
Revisar métodos de autenticación multifactor registrados.
Eliminar tokens o sesiones sospechosas.
Revisar reglas de reenvío de correo.
Analizar cambios recientes en privilegios administrativos.

Un simple cambio de contraseña puede no ser suficiente si el atacante mantiene una sesión activa, creó otra cuenta o agregó un nuevo mecanismo de autenticación.

3. Preservar los registros antes de que desaparezcan

Los logs son una de las principales fuentes para reconstruir un incidente.

Dependiendo de la infraestructura de la organización, conviene preservar registros provenientes de:

Firewall.
VPN.
Active Directory y controladores de dominio.
Microsoft Entra ID.
Microsoft 365.
Google Workspace.
EDR y antivirus.
Servidores Windows y Linux.
Aplicaciones críticas.
Proxy y DNS.
SIEM.
Sistemas cloud como Azure, AWS o Google Cloud.

Esto es especialmente importante porque muchas plataformas tienen períodos limitados de retención. Una investigación que comienza varios días después puede encontrarse con que parte de la evidencia ya no está disponible.

4. No asumir que tener backup resuelve el incidente

Una organización puede recuperar todos sus servidores y, aun así, continuar comprometida.

En ataques modernos de ransomware es frecuente que los atacantes intenten primero obtener privilegios, moverse por la infraestructura, acceder a sistemas adicionales y, en determinados casos, extraer información antes de ejecutar el cifrado.

Por eso, antes de restaurar masivamente desde un respaldo conviene determinar:

Cuál fue el punto inicial de acceso.
Desde cuándo existía el compromiso.
Si las credenciales administrativas fueron expuestas.
Si los sistemas de backup fueron accedidos.
Si existe persistencia dentro de la infraestructura.
Si hubo extracción de información.

Restaurar un sistema vulnerable o comprometido sin corregir la causa raíz puede permitir que el atacante vuelva a ingresar.

5. ¿Hay que desconectar Internet?

No existe una respuesta universal.

En determinados incidentes puede ser necesario bloquear comunicaciones externas, segmentos completos de red, conexiones VPN o determinados servicios. En otros casos, una desconexión indiscriminada puede perjudicar la investigación o afectar servicios que no estaban comprometidos.

La contención debería realizarse de forma coordinada y proporcional al riesgo.

Una de las ventajas de contar previamente con segmentación de red, EDR, controles de identidad y monitoreo es poder aislar solamente los componentes afectados sin detener toda la organización.

6. ¿Qué hacer si es ransomware?

Si aparecen archivos cifrados o una nota de rescate, la prioridad sigue siendo contener el incidente y determinar su alcance.

No debería asumirse que el ataque terminó porque apareció el mensaje de ransomware.

En ese momento conviene:

Aislar los equipos afectados.
Identificar otros sistemas que puedan presentar actividad relacionada.
Preservar la nota de rescate y cualquier identificador proporcionado.
Preservar logs y evidencia.
Verificar el estado de los respaldos sin conectarlos innecesariamente al entorno comprometido.
Investigar posibles accesos anteriores al cifrado.
Determinar si pudo existir extracción de información.

El pago de un rescate no garantiza la recuperación de la información ni elimina el riesgo de que los datos hayan sido copiados. Cualquier decisión relacionada con una extorsión debería evaluarse con especialistas técnicos, legales y la dirección de la organización.

7. ¿Cuándo debo reportar un ciberataque a CERTuy?

En Uruguay existe un marco específico para el reporte de determinados incidentes.

El Decreto N.º 66/025 establece obligaciones de ciberseguridad para todas las entidades públicas y para entidades privadas vinculadas a servicios o sectores críticos.

Para las organizaciones alcanzadas por esa normativa, el artículo 10 establece la obligación de comunicar al CERTuy la ocurrencia de incidentes de ciberseguridad dentro de las 24 horas de conocido el incidente.

Los sectores críticos definidos por la normativa incluyen, entre otros:

Salud.
Servicios de emergencia.
Energía.
Telecomunicaciones.
Transporte.
Suministro de agua potable.
Agroindustria.
Industria.
Servicios públicos.
Banca y servicios financieros.
Defensa.

Las organizaciones que no se encuentren dentro de esos sectores también pueden reportar incidentes al CERTuy.

La información oficial y las vías vigentes para realizar un reporte pueden consultarse directamente en Cómo reportar un incidente al CERTuy.

8. Si hubo una filtración de datos personales, atención al plazo de 72 horas

Un ataque informático puede tener además implicancias relacionadas con protección de datos personales.

El artículo 4 del Decreto N.º 64/020 establece que el responsable del tratamiento que constate una vulneración de seguridad que incida en la protección de datos personales debe comunicarla a la Unidad Reguladora y de Control de Datos Personales (URCDP) dentro de un plazo máximo de 72 horas de conocida la vulneración.

La comunicación debe incluir información relevante sobre el incidente, como su fecha cierta o estimada, naturaleza, datos personales afectados y posibles impactos.

La normativa también establece la comunicación a los titulares cuando la vulneración produzca una afectación significativa de sus derechos.

Por este motivo, ante un incidente que involucre bases de clientes, empleados, historias clínicas, documentación personal, información financiera u otros datos personales, el análisis técnico debe coordinarse rápidamente con los responsables legales y de protección de datos de la organización.

9. ¿Cuándo corresponde realizar una denuncia ante Cibercrimen?

Si existen elementos que puedan constituir un delito, también puede corresponder realizar una denuncia.

El Ministerio del Interior recomienda denunciar los ciberdelitos de forma inmediata, ya que la evidencia digital puede modificarse o desaparecer.

En Montevideo, las denuncias pueden realizarse ante la Dirección General de Cibercrimen. En el resto del país pueden presentarse en una seccional policial o ante Fiscalía.

El Ministerio del Interior mantiene información actualizada sobre las vías disponibles en su página oficial de denuncia de ciberdelitos.

Checklist: las primeras 24 horas después de un ciberataque

Como referencia rápida, ante un incidente empresarial conviene trabajar sobre esta secuencia:

Confirmar el incidente y registrar cuándo fue detectado.
Definir un responsable de coordinación para evitar acciones contradictorias.
Contener los activos comprometidos sin destruir evidencia.
Preservar logs y registros antes de que sean eliminados por las políticas de retención.
Analizar identidades y credenciales que puedan haber sido comprometidas.
Determinar el alcance: equipos, servidores, usuarios, cloud y terceros.
Proteger los respaldos y verificar su integridad.
Evaluar si hubo extracción de información.
Determinar obligaciones de reporte ante CERTuy, URCDP u otros reguladores.
Evaluar una denuncia ante Cibercrimen cuando corresponda.
Definir una estrategia de erradicación antes de comenzar a restaurar sistemas.
Documentar cada decisión y acción realizada.

Errores frecuentes durante un incidente

En nuestra experiencia, muchos incidentes se vuelven más difíciles de investigar debido a las decisiones tomadas durante las primeras horas.

Algunos errores frecuentes son:

Formatear inmediatamente el equipo donde comenzó el incidente.
Eliminar archivos o herramientas utilizadas por el atacante.
Borrar usuarios comprometidos en lugar de preservar primero la evidencia.
Restaurar servidores sin conocer cómo ingresó el atacante.
Cambiar configuraciones en decenas de sistemas sin documentar los cambios.
Usar para la investigación una computadora que también podría estar comprometida.
Suponer que el incidente terminó cuando el antivirus elimina un archivo.
Confiar únicamente en que existe un backup.
No revisar Microsoft 365, VPN y servicios cloud porque “los servidores ya están limpios”.
Esperar varios días antes de comenzar la investigación.

¿Cómo saber por dónde entraron los atacantes?

Encontrar el vector inicial es una de las preguntas más importantes de una investigación.

Algunos puntos de entrada frecuentes incluyen:

Credenciales robadas mediante phishing.
Contraseñas reutilizadas o filtradas previamente.
VPN o accesos remotos expuestos.
Servicios publicados directamente en Internet.
Vulnerabilidades sin corregir.
Aplicaciones web comprometidas.
Cuentas cloud sin autenticación multifactor.
Equipos de terceros o proveedores.

Identificar únicamente el malware final no necesariamente identifica la causa raíz del incidente.

Una investigación adecuada intenta reconstruir la secuencia completa: acceso inicial, persistencia, escalamiento de privilegios, movimiento lateral, acciones sobre los sistemas y posible extracción de datos.

¿Cómo evitar que vuelva a ocurrir?

Después de contener y recuperar la operación debería comenzar una etapa que muchas organizaciones omiten: las lecciones aprendidas.

El incidente permite identificar controles que no existían, estaban mal configurados o no funcionaron como se esperaba.

Dependiendo del caso, las mejoras pueden incluir:

Implementación de autenticación multifactor.
Reducción de privilegios administrativos.
Segmentación de red.
Gestión continua de vulnerabilidades.
Mayor retención y centralización de logs.
Implementación de EDR.
Monitoreo permanente mediante SOC/MDR.
Revisión de configuraciones de Microsoft 365 o Google Workspace.
Mejoras en la estrategia de backups.
Simulaciones de phishing y concientización.
Pruebas de penetración.
Desarrollo y prueba de un plan formal de respuesta a incidentes.

Servicios como vSecOps permiten mantener controles técnicos y gestión de vulnerabilidades de forma continua, mientras que un servicio de vCISO puede ayudar a incorporar estas mejoras dentro de una estrategia de seguridad, riesgos y continuidad.

También es posible evaluar preventivamente la exposición de una organización mediante un pentest o prueba de Ethical Hacking.

La velocidad importa, pero también la metodología

Durante un ciberataque existe presión por recuperar los sistemas lo antes posible. Esa urgencia es comprensible, pero recuperación y seguridad no deberían tratarse como objetivos separados.

Una buena respuesta a incidentes busca restaurar el negocio mientras conserva la capacidad de responder preguntas fundamentales:

¿Cómo ingresaron?
¿Desde cuándo estaban dentro?
¿A qué sistemas accedieron?
¿Qué credenciales obtuvieron?
¿Qué información pudieron copiar?
¿El atacante sigue teniendo acceso?
¿Qué debemos cambiar para que no vuelva a ocurrir?

Sin esas respuestas, una recuperación rápida puede transformarse simplemente en la primera etapa del próximo incidente.

¿Tu empresa está atravesando un incidente de ciberseguridad?

En InfoSecura brindamos servicios de Respuesta a Incidentes de Ciberseguridad para organizaciones que enfrentan ransomware, accesos no autorizados, robo de credenciales, malware o posibles fugas de información.

Trabajamos sobre cuatro etapas principales:

Triage y determinación del alcance.
Contención coordinada.
Investigación y erradicación.
Recuperación y recomendaciones posteriores.

No es necesario conocer todavía el alcance completo del ataque para solicitar ayuda. Precisamente una de las primeras tareas de una respuesta profesional es determinar qué ocurrió y qué sistemas pueden estar afectados.

Conocé nuestro servicio de Respuesta a Incidentes →

Preguntas frecuentes sobre ciberataques en empresas

¿Qué hago primero si mi empresa sufrió un ransomware?

Aislá los sistemas afectados, evitá formatearlos o modificar evidencia innecesariamente, verificá el estado de los respaldos y comenzá a determinar el alcance del incidente. También debería investigarse si hubo compromiso de credenciales o extracción de información antes del cifrado.

¿Debo apagar una computadora infectada?

No necesariamente. Apagar un equipo puede eliminar información volátil útil para una investigación. Si existe riesgo de propagación, generalmente conviene primero aislarlo de la red. La decisión depende del tipo y severidad del incidente.

¿Tengo que reportar un ciberataque al CERTuy?

Las entidades públicas y las entidades privadas vinculadas a servicios o sectores críticos alcanzadas por el Decreto N.º 66/025 deben comunicar los incidentes de ciberseguridad al CERTuy dentro de las 24 horas de conocido el incidente. Otras organizaciones también pueden reportarlos.

¿Qué pasa si se filtraron datos personales?

Cuando una vulneración de seguridad incide en la protección de datos personales, el responsable del tratamiento debe evaluar las obligaciones establecidas por la normativa uruguaya. El Decreto N.º 64/020 establece un plazo máximo de 72 horas desde que se conoce la vulneración para comunicarla a la URCDP.

¿Un backup protege a mi empresa del ransomware?

El backup es un control fundamental para recuperar información, pero no evita que un atacante robe datos, comprometa cuentas o mantenga persistencia en la red. Por eso un incidente debe investigarse incluso cuando los respaldos permiten recuperar los sistemas.

¿Cómo puedo prepararme antes de sufrir un ataque?

Contar con inventario actualizado, gestión de vulnerabilidades, autenticación multifactor, EDR, backups protegidos, monitoreo, capacitación de usuarios y un plan de respuesta a incidentes probado reduce considerablemente el impacto cuando ocurre un ataque.

Fuentes oficiales y referencias

Este artículo tiene fines informativos generales. Las obligaciones regulatorias y legales aplicables dependen de las características de cada organización y de cada incidente.