Respuesta a incidentes

Conexiones regulares de un puesto de trabajo a un servidor externo nuevo, un equipo que escanea rangos internos en busca de puertos SMB, RDP o de bases de datos, sesiones de administrador nuevas hacia muchos servidores y una gran subida a la nube desde un servidor que normalmente envía poco. Suelen aparecer en ese orden, antes de que se cifre ningún archivo.

A menudo sí, porque los pasos previos al cifrado cruzan la red: conexiones de mando y control, escaneos, movimiento lateral y robo de datos. Es la ventana en la que todavía se puede detener un ataque. No todos los ataques muestran todos esos pasos, y uno limitado a una sola máquina deja poco que ver a la red.

No. NetSenX avisa del comportamiento de red que suele preceder al ransomware, para que su equipo actúe mientras hay tiempo. Aislar equipos, expulsar al atacante y restaurar los datos siguen siendo tarea de su equipo, de su protección de endpoints y de sus copias de seguridad.

Desconectar de la red los equipos afectados, conservar sus registros, restablecer las credenciales usadas en ellos y llamar a su proveedor de respuesta a incidentes. Si su organización está en el ámbito de NIS2, el plazo de 24 horas para la alerta temprana empieza cuando tiene conocimiento de un incidente significativo.

Desconecte de la red las máquinas afectadas, en el switch o quitando el cable y apagando la wifi. Si puede, manténgalas encendidas, porque la memoria contiene pruebas, salvo que no pueda aislarlas de otra forma. No contacte con los atacantes ni pague nada antes de recibir asesoramiento. Llame a su proveedor de respuesta a incidentes, a la línea de asistencia de su seguro cibernético si la tiene o a su CSIRT nacional. Cambie las contraseñas de administrador desde un dispositivo limpio, compruebe que sus copias de seguridad están intactas y desconectadas y empiece un registro escrito, con horas, de lo que ve y hace. Si le aplica NIS2, el plazo de 24 horas para la alerta temprana corre desde el momento en que tiene conocimiento de un incidente significativo, así que implique desde el principio a quien gestione las notificaciones.

Más o menos en este orden, ajustado a su situación. Uno: aísle de la red las máquinas afectadas sin apagarlas y frene la propagación en los switches o el cortafuegos. Dos: llame a su proveedor de respuesta a incidentes, a la línea de asistencia de la aseguradora y, si hace falta, a un abogado, y empiece un registro del incidente. Tres: asegure las pruebas y compruebe si las copias de seguridad están intactas y desconectadas. Cuatro: averigüe cómo entraron los atacantes, a qué sistemas llegaron y si salieron datos, y evalúe las obligaciones de notificación de NIS2 y del RGPD, con sus plazos. Cinco: decida qué contar a la plantilla, los clientes y los socios. Seis: expulse al atacante, restablezca credenciales y cierre la vía de entrada. Siete: reconstruya y restaure por orden de prioridad desde copias limpias. Ocho: vigile de cerca durante semanas y haga una revisión de lecciones aprendidas. NetSenX ayuda en los pasos cuatro y ocho, con evidencia de red y detección continuada.

Es una decisión empresarial y jurídica, y las fuerzas de seguridad desaconsejan pagar: financia a los atacantes, no garantiza que vuelvan los archivos ni que se borren los datos robados, y pagar a un grupo sancionado puede ser ilegal. Decida con su proveedor de respuesta a incidentes, su aseguradora y sus abogados, y denuncie el incidente a la policía y, cuando corresponda, a su CSIRT. NetSenX no negocia ni restaura datos; ayuda a ver antes lo que hicieron los atacantes en la red.

Pagar no deshace el robo. Estaría pagando a delincuentes por la promesa de borrar unos datos que tienen todos los motivos para conservar, y las fuerzas de seguridad, entre ellas Europol y las policías nacionales, desaconsejan pagar; hay casos conocidos de datos publicados o vendidos después del pago. Pagar a una persona o grupo sancionado puede además ser ilegal. La decisión corresponde a la dirección, con su proveedor de respuesta a incidentes, su aseguradora y sus abogados. Antes de decidir, establezca los hechos: qué salió realmente, si contiene datos personales, qué notificaciones proceden con independencia del pago y qué dirá a las personas afectadas. Según el RGPD, una violación de la seguridad de los datos personales se valora por lo que ocurrió, no por si se pagó un rescate. NetSenX no negocia; ayuda con los hechos mediante alertas que muestran qué equipos enviaron volúmenes inusuales y cuándo.

Un negociador de ransomware es un especialista, a menudo aportado por una empresa de respuesta a incidentes o a través de la lista de la aseguradora, que se comunica con los atacantes en nombre de la víctima. Su trabajo es ganar tiempo, obtener pruebas de lo que se llevaron, comprobar si una herramienta de descifrado funciona y, si la empresa decide pagar, revisar las listas de sanciones y gestionar las condiciones. Recurrir a uno no significa haber decidido pagar: hablar puede dar días para restaurar desde las copias de seguridad. No abra usted mismo el chat de los atacantes ni responda a sus correos antes de recibir asesoramiento, porque lo que diga puede debilitar su posición. Pregunte primero a su aseguradora, porque las pólizas suelen exigir la empresa que ella elige, y guarde cada mensaje como prueba. NetSenX no participa en la negociación; sus alertas ayudan a establecer qué salió realmente de la red, algo importante cuando se ponen a prueba las afirmaciones de los atacantes.

Revise qué salió de la red y cuándo: registros del cortafuegos y del proxy, registros de auditoría del almacenamiento en la nube y registros de las máquinas implicadas. La señal habitual son subidas grandes a un almacenamiento en la nube o a una dirección desconocida en los días previos al cifrado. Pida a su proveedor de respuesta a incidentes que compare los volúmenes con lo que contiene cada servidor y conserve los registros antes de que se sobrescriban. Si los atacantes publican una muestra en un sitio de filtraciones, dice algo de lo que se llevaron, aunque rara vez todo, y sus afirmaciones no prueban nada en ningún sentido. NetSenX conserva sus alertas de volúmenes salientes inusuales por equipo, con hora, destino y volumen, lo que ayuda a dimensionar una transferencia. No ve nombres de archivo dentro de sesiones cifradas.

Busque la transferencia, no la afirmación. Los atacantes a veces exageran para aumentar la presión y a veces sí se llevaron todo lo que dicen. Revise en los registros del cortafuegos y del proxy las transferencias salientes grandes de los días previos al cifrado, sobre todo hacia almacenamiento en la nube o direcciones que nadie más usa, y anote qué equipos internos las enviaron. Compare el volumen con lo que contienen esos servidores. Pida una muestra como prueba solo a través de su equipo de respuesta y mire qué contiene. Los registros de auditoría del almacenamiento en la nube y de los servicios SaaS pueden mostrar descargas masivas. Si las pruebas no muestran una transferencia saliente significativa, eso ayuda a decidir y a cualquier notificación, pero la falta de pruebas en una vía no demuestra que no saliera nada por otra. NetSenX conserva alertas de volúmenes salientes inusuales por equipo, con hora, destino y volumen; no ve los nombres de archivo en las transferencias cifradas.

A menudo sí, si los registros de esa época siguen existiendo. Los archivos publicados dan pistas: su fecha de modificación más reciente marca el momento más temprano posible del robo, y las carpetas de las que proceden señalan los servidores implicados. Después busque en los registros del cortafuegos, del proxy y de auditoría de la nube transferencias salientes grandes desde esos servidores en esas fechas, y el primer contacto regular con un servidor externo desconocido, que suele marcar el inicio de la intrusión. Encárgueselo a su proveedor de respuesta a incidentes y no descargue usted los datos filtrados del sitio: implique a su equipo de respuesta y a su abogado, porque manejar datos robados tiene sus propios riesgos. Denuncie la publicación a la policía. NetSenX conserva, durante el historial de alertas de su plan, alertas de volúmenes salientes inusuales por equipo con hora y destino, lo que puede acotar mucho la ventana.

No. NetSenX analiza metadatos de flujos y algunos campos de protocolo, y nunca descifra el tráfico. Cuando los datos salen por una conexión cifrada, que es casi siempre, ve qué equipo envió cuánto, a qué destino y cuándo, pero no los nombres ni el contenido de los archivos. Aun así es útil: le dice qué servidor examinar, qué tamaño tuvo la transferencia y cuándo ocurrió, lo que a menudo basta para acotar qué pudo contener. Para saber qué archivos se llevaron, combínelo con fuentes que ven archivos: registros de auditoría de servidores de archivos y almacenamiento en la nube, telemetría de detección y respuesta en endpoints (EDR), herramientas de prevención de fugas de datos o un examen forense del servidor. Si los atacantes publican muestras, también indican qué carpetas estuvieron implicadas.

Lo intentan, si se dejaron una puerta: contraseñas robadas, una herramienta de acceso remoto olvidada, una cuenta nueva, una tarea programada o una VPN que nunca se parcheó. Algunos delincuentes también venden o ceden el acceso, así que un segundo ataque puede venir de otra persona por la misma puerta. Después de un incidente, restablezca todas las credenciales que puedan haberse expuesto, incluidas las cuentas de servicio, elimine las herramientas de acceso remoto que nadie aprobó, cierre la vía de entrada, reconstruya las máquinas afectadas desde imágenes fiables y vigile la red de cerca durante semanas. Las conexiones renovadas con los servidores del atacante son una señal típica; NetSenX detecta beaconing C2 en todos los planes, incluido Free, y los indicadores de su informe de incidente se pueden buscar en los registros del cortafuegos y de DNS.

La respuesta a incidentes es la forma organizada en que una empresa detecta un incidente de seguridad, lo contiene, se recupera y aprende de él. Abarca el trabajo técnico, como aislar máquinas, expulsar al atacante y restaurar sistemas, y las decisiones que lo rodean: quién dirige, a quién se informa, cuándo pedir ayuda externa, qué notificar a reguladores, aseguradoras y clientes. Una pequeña empresa no necesita un equipo de seguridad para hacerlo bien. Necesita un plan escrito breve, números de teléfono que funcionen cuando el correo no funciona, alguien autorizado a decidir de noche y pruebas que muestren lo que ocurrió. NetSenX ayuda con las pruebas y los plazos: detecta comportamientos de red que a menudo indican una intrusión, explica cada alerta y sigue los plazos del artículo 23 de NIS2 por incidente. No expulsa a los atacantes ni restaura sistemas.

El modelo más conocido tiene seis: preparación, identificación, contención, erradicación, recuperación y lecciones aprendidas, del manual del SANS para gestores de incidentes. La guía anterior del NIST, SP 800-61 Revision 2, agrupaba ese mismo trabajo en cuatro fases. En abril de 2025, el NIST la sustituyó por la SP 800-61 Revision 3, que vincula la respuesta a incidentes con las seis funciones de su Cybersecurity Framework 2.0: gobernar, identificar, proteger, detectar, responder y recuperar. Todos transmiten lo mismo: la mayor parte del trabajo ocurre antes del incidente, en la preparación, y después, en la mejora. Para una pequeña empresa el orden práctico es sencillo: darse cuenta, limitar el daño, eliminar la causa, volver a trabajar con seguridad y cambiar lo que permitió el incidente. Poner por escrito esa secuencia para sus propios sistemas es el primer paso más útil.

Decidiendo ahora lo que de otro modo tendría que improvisar en plena noche. Escriba un plan de una página: quién dirige, quién puede apagar sistemas, quién habla con clientes, aseguradoras y reguladores. Guarde los teléfonos en papel y en un segundo canal, porque el correo y el chat pueden caer o estar comprometidos. Conozca sus tres o cuatro sistemas más importantes y el orden en que los restauraría, y pruebe una restauración desde la copia de seguridad. Acuerde condiciones con un proveedor de respuesta a incidentes antes de necesitarlo y compruebe a quién le exige llamar primero su seguro cibernético. Asegúrese de que los registros que necesitaría existen y se conservan el tiempo suficiente: cortafuegos, VPN, directorio e historial de red. NetSenX aporta el historial de red y alertas explicadas, y los informes en PDF desde el plan Starter facilitan entregar un paquete de pruebas.

Menos de lo que sugieren la mayoría de las plantillas, siempre que funcione bajo presión. Lo esencial cabe en dos o tres páginas: quién dirige y quién lo sustituye, los teléfonos de las personas y proveedores a los que llamará, cuándo aislar un sistema o desconectar la empresa de internet, dónde están las copias de seguridad y cómo restaurar los sistemas más importantes, y quién decide las notificaciones al CSIRT, a la autoridad de protección de datos, a las aseguradoras y a los clientes, con sus plazos. Añada una breve lista de comprobación para la primera hora y una plantilla del registro del incidente. Imprímalo, porque el servidor de archivos que lo guarda puede ser precisamente el que se cifre. Revíselo después de cada incidente y al menos una vez al año. NetSenX sigue los plazos del artículo 23 de NIS2 por incidente y mantiene un registro de auditoría de alertas y decisiones de los analistas, lo que apoya la parte de notificación del plan.

Menos personas de las que cree, pero con funciones claras. Una persona dirige y decide, normalmente la gerencia o alguien a quien designe, con un sustituto con nombre propio. Una persona hace o dirige el trabajo técnico: su administrador de TI, su proveedor de servicios gestionados o una empresa externa de respuesta a incidentes. Una persona gestiona la comunicación con la plantilla, los clientes y los proveedores, y otra sigue la parte jurídica y de notificaciones, a menudo con el delegado de protección de datos y un abogado. En una empresa de 30 personas pueden ser tres personas con varios sombreros. Lo importante es que cada función esté por escrito, que quien dirige pueda decidir de noche sin esperar a una reunión y que los teléfonos externos estén acordados de antemano. Desde el plan Starter, que incluye la gestión de equipos, NetSenX da a cada uno su propia cuenta, de modo que los motivos de las alertas y las decisiones son visibles para todo el equipo.

Un retainer es un acuerdo con una empresa de respuesta a incidentes, firmado antes de que pase nada, que le garantiza una respuesta en un plazo pactado y fija el precio y las condiciones. Sin él, estará buscando proveedor, negociando un contrato y dando accesos mientras el atacante sigue activo. Muchas aseguradoras cibernéticas tienen su propia lista de empresas de respuesta y esperan que las llame a ellas primero, así que revise su póliza antes de firmar nada por separado. Una pequeña empresa quizá no necesite un retainer de pago si la línea de asistencia de la aseguradora lo cubre, pero sí necesita saber a quién llamar, qué necesitará esa empresa el primer día y cómo accederá a sus sistemas. NetSenX no es una empresa de respuesta a incidentes. Da a la empresa que usted llame alertas explicadas y un historial de red anterior al incidente, que suele ser la evidencia más difícil de reconstruir después.

Un ejercicio de simulación de mesa (tabletop) es una reunión en la que las personas que gestionarían un incidente recorren paso a paso un escenario realista, sin tocar ningún sistema. Un moderador presenta la situación por etapas: una alerta a última hora de la tarde, una nota de rescate el lunes por la mañana, la llamada de un periodista, una copia de seguridad que resulta estar también cifrada. En cada etapa el equipo dice qué haría, quién decidiría y a quién llamaría. Bastan noventa minutos con la dirección, TI, comunicación y quien lleve los asuntos jurídicos. El valor está en las carencias que salen a la luz: un teléfono que nadie tiene, una decisión que nadie puede tomar, un registro que nadie lleva. Anótelas, corríjalas y repita el ejercicio una o dos veces al año. Un escenario basado en una alerta real o en un incidente pasado enseña más que uno genérico.

Son peldaños de una misma escalera. Un evento es cualquier cosa que ocurre y se puede registrar: un inicio de sesión, una conexión, un cambio en un archivo. Una alerta es un evento, o un patrón de eventos, que una herramienta señala porque puede importar, como un puesto de trabajo que contacta con un servidor externo nuevo cada pocos minutos. Un incidente es lo que usted declara tras revisar una o varias alertas y concluir que la seguridad se ha visto, o se está viendo, realmente comprometida: hay un atacante dentro, se robaron datos, se interrumpió un servicio. La diferencia importa porque las obligaciones se vinculan a los incidentes, no a las alertas: los plazos de notificación de NIS2 empiezan cuando usted tiene conocimiento de un incidente significativo, no cuando una herramienta lanza una alerta. NetSenX genera alertas con un motivo en lenguaje claro; decidir si forman un incidente sigue siendo su criterio, y esa decisión queda registrada en el registro de auditoría.

Contrastando la alerta con lo que sabe, deprisa y siempre en el mismo orden. Hágase cuatro preguntas: se conoce el dispositivo y a su responsable, hay un motivo de negocio para este comportamiento, el destino o la cuenta son conocidos, y ha pasado algo más fuera de lo normal en el mismo equipo o a la misma hora. Una copia de seguridad, una actualización de software o un administrador trabajando hasta tarde explican muchas alertas en minutos. Lo que nadie sabe explicar, afecta a varios equipos o sigue a otra alerta merece escalarse. Anote lo que comprobó, aunque resultara inofensivo, para que la siguiente persona no empiece de cero. NetSenX explica en cada alerta qué características de red la provocaron, nombra la técnica de MITRE ATT&CK cuando corresponde y le permite marcar un falso positivo, con la decisión guardada en el registro de auditoría.

Por su efecto en el negocio, no por lo alarmante que parezca. Basta una escala sencilla: baja cuando un dispositivo está afectado y contenido, media cuando hay una cuenta o varios dispositivos implicados, alta cuando corren peligro sistemas importantes o datos personales, y crítica cuando se detiene la actividad o los datos han salido de la empresa. Pregunte qué está afectado, cuántos sistemas y personas, si hay datos personales o de clientes de por medio, si se está extendiendo y si se interrumpen servicios que presta a otros. La respuesta decide a quién se llama, con qué rapidez y si pueden aplicarse obligaciones de notificación: NIS2 trabaja con la noción de incidente significativo y el RGPD con la de violación de la seguridad de los datos personales, cada uno con sus propios criterios. Acuerde la escala de antemano y escríbala en su plan. NetSenX muestra en cada alerta qué se vio y en qué equipos, un punto de partida para este juicio, no un sustituto.

Una persona con nombre y apellidos, con un sustituto también designado y autoridad para actuar sin convocar una reunión. Las decisiones en un incidente son urgentes e incómodas: desconectar la empresa de internet, detener un sistema de producción, llamar a la policía, informar a los clientes. Si nadie está claramente autorizado a tomarlas, se pierden horas esperando un acuerdo. En la mayoría de las pequeñas empresas decide la gerencia, asesorada por TI y por un equipo externo de respuesta; en las más grandes, un responsable de incidentes actúa en nombre de la dirección dentro de unos límites acordados. Deje por escrito qué decisiones puede tomar esa persona sola y cuáles requieren a la dirección, y asegúrese de que el sustituto esté localizable cuando el responsable viaje. NIS2 hace además responsables a los órganos de dirección de las entidades afectadas de aprobar las medidas de gestión de riesgos de ciberseguridad y supervisar su aplicación, así que la dirección debería conocer el plan antes de necesitarlo.

Normalmente cinco cosas. Si aislar sistemas o toda la sede, asumiendo la interrupción que eso supone. A quién llamar: una empresa de respuesta a incidentes, la línea de asistencia de la aseguradora, un abogado. Si el incidente puede ser notificable, al CSIRT nacional según NIS2 o a la autoridad de protección de datos según el RGPD, y quién prepara la notificación. Qué contar a la plantilla, a los clientes y a los socios, y cuándo, sin prometer lo que aún no se sabe. Y cómo mantener la actividad: procesos manuales, comunicación alternativa, a qué clientes llamar primero. Ninguna de estas decisiones es técnica, y por eso un equipo técnico no puede tomarlas solo. Prepárelas como opciones en su plan. NetSenX da a la dirección un punto de partida basado en hechos: qué equipos mostraron qué comportamiento y cuándo, y los plazos del artículo 23 de NIS2 seguidos para el incidente.

Lleve las conversaciones sobre el incidente a un canal que el atacante no pueda leer antes de decir nada de sus planes. Los atacantes que controlan un buzón o el directorio suelen leer los mensajes del equipo de respuesta y adaptarse. Acuerde de antemano un canal alternativo: llamadas telefónicas, un grupo de mensajería en dispositivos sin cuentas de la empresa o un espacio de colaboración aparte con sus propias credenciales. Guarde una lista de contactos impresa, porque la libreta de direcciones puede no estar disponible. Pida a su aseguradora, a su banco y a sus clientes clave que confirmen por teléfono cualquier petición suya, porque los delincuentes a veces envían mensajes falsos en pleno incidente. Cuando el directorio y el correo estén reconstruidos y las credenciales restablecidas, vuelva a los canales habituales. Las alertas de NetSenX están en su propio panel, que puede abrir desde un dispositivo limpio, así que la imagen de la red no depende del correo de la empresa.

Porque la memoria falla bajo presión y después todo el mundo preguntará qué pasó y cuándo. Un registro sencillo anota la hora, lo observado, lo decidido, por quién y por qué, y lo que se hizo. Permite que otra persona tome el relevo de noche sin empezar de nuevo, demuestra a la aseguradora y al regulador que actuó con rapidez y criterio, y es la base de la cronología de una notificación NIS2 o RGPD. También protege a quienes deciden: una elección que después parece errónea a menudo era razonable con lo que se sabía en ese momento, y el registro lo demuestra. Llévelo fuera de los sistemas afectados, en papel o en un documento compartido accesible desde un dispositivo limpio, y anote todas las horas en una misma zona horaria. NetSenX aporta alertas con marca de tiempo y un registro de auditoría de las decisiones de los analistas que puede adjuntar a su propio registro.

Corte la red, no la corriente, y copie antes de limpiar. Aislar una máquina afectada en el puerto del switch, en el cortafuegos o mediante la herramienta de endpoints impide que el atacante la use y mantiene intactos la memoria, los procesos en ejecución y las conexiones abiertas para la investigación. Antes de reinstalar máquinas, borrar archivos o eliminar cuentas, exporte los registros pertinentes, anote las cuentas y archivos sospechosos y, si los especialistas lo aconsejan, haga una captura de memoria y una imagen del disco. Bloquee los destinos del atacante en el cortafuegos, pero anote cuáles y cuándo. Si tiene que elegir entre rapidez y pruebas, por ejemplo porque el cifrado se extiende, gana la rapidez: primero frene el daño. Las pruebas de red son las más fáciles de perder, porque muchos equipos guardan poco historial; NetSenX conserva sus alertas con hora, equipos y destinos durante el historial que incluye su plan.

Desconéctelo de la red, pero déjelo encendido salvo que tenga motivos para lo contrario. Quitar el cable y apagar la wifi impide que el atacante lo controle y frena la propagación, mientras la memoria conserva pruebas que desaparecen al apagar: programas en ejecución, conexiones de red, a veces claves de cifrado útiles para recuperar datos. Apagar es lo correcto cuando no puede aislar la máquina de otra forma y el daño se extiende deprisa, o cuando se lo piden los especialistas. No inicie sesión como administrador para curiosear, no ejecute herramientas de limpieza ni reinicie antes de pedir consejo, porque cada paso altera las pruebas. Anote la hora y lo que hizo. Si es un servidor del que dependen otros, aíslelo en el switch o en el cortafuegos en lugar de quitar cables al azar. Un sensor de red como NetSenX conserva el registro de lo que hizo la máquina antes de que la desconectara.

Una lista breve de errores habituales. No borre ni reconstruya máquinas antes de guardar las pruebas, o perderá la forma de averiguar cómo entró el atacante. No restablezca contraseñas una a una mientras el atacante sigue observando; planifique la contención y hágala de una vez. No hable del incidente por un correo o un chat que puedan estar comprometidos. No contacte con los atacantes ni les pague sin el consejo de su equipo de respuesta, su aseguradora y su abogado. No restaure copias de seguridad antes de saber que son anteriores a la intrusión. No anuncie públicamente lo que aún no sabe ni prometa a los clientes que no se vieron afectados sus datos antes de comprobarlo. No deje pasar plazos: una alerta temprana de NIS2 o una notificación del RGPD pueden enviarse con datos incompletos y completarse después. Y no deje de vigilar la red cuando los sistemas vuelvan a funcionar.

Trabaje hacia atrás desde lo que sabe, con ayuda de las marcas de tiempo. Empiece por la máquina donde se detectó el incidente, pregúntese qué otro equipo se conectó primero a ella de forma inusual y repita el proceso con ese equipo. Los registros de endpoints muestran inicios de sesión y programas nuevos; los del directorio, qué cuenta se usó desde qué ordenador; los del cortafuegos y la VPN, las primeras conexiones con el exterior. Los primeros contactos regulares con un servidor del atacante suelen señalar la primera máquina infectada. El paciente cero importa porque dice cómo entraron, y esa vía hay que cerrarla antes de recuperar los sistemas. Tenga en cuenta que la primera máquina que encuentre a menudo no es la primera infectada. Las alertas de NetSenX incluyen horas, equipos y destinos, y desde el plan Pro la correlación en toda la red une escaneos, sesiones nuevas y beaconing entre equipos en una sola historia, lo que acorta esta búsqueda.

Una imagen forense es una copia exacta y verificada de un disco o de la memoria de un ordenador, hecha para que los investigadores puedan examinarla sin alterar el original. Se obtiene con herramientas específicas, se marca con un hash como SHA-256 para que cualquier cambio posterior se pueda detectar y se guarda con un registro de quién la ha manipulado. La necesita cuando el incidente puede acabar en un litigio, una reclamación al seguro, una denuncia o preguntas de un regulador, y cuando quiere saber cómo entró el atacante antes de reconstruir la máquina. Las copias de seguridad corrientes no la sustituyen, porque omiten archivos borrados, la memoria y zonas del sistema. Si puede, encárguela a un especialista. La evidencia de red la complementa: NetSenX registra lo que cruzó la red, algo que la imagen de disco de una sola máquina no puede mostrar.

La cadena de custodia es el registro escrito de quién recogió una prueba, cuándo y cómo, y de quién la ha tenido desde entonces. Para una imagen de disco, una exportación de registros o una captura de red significa anotar la fuente, la fecha y la hora, el método o la herramienta utilizada, un valor hash que demuestra que la copia no ha cambiado, dónde se guarda y cada persona que ha accedido a ella. Sin ese registro, un tribunal, una aseguradora o un regulador puede dudar de que la prueba sea lo que usted dice. Una pequeña empresa puede llevarla de forma sencilla: una hoja por elemento, copias en almacenamiento de una sola escritura o con acceso controlado y ningún trabajo sobre los originales. NetSenX mantiene un registro de auditoría de alertas, decisiones de los analistas y cambios de configuración, y desde el plan Starter un rastro de pruebas (proof trail), lo que respalda este registro en la parte de red de un incidente.

Expórtelos en cuanto sospeche un incidente, antes de cambiar nada más. Muchos equipos guardan los registros solo unos días o hasta un límite de tamaño: cortafuegos, pasarelas VPN, switches y algunos servicios en la nube sobrescriben primero las entradas más antiguas, y un atacante activo puede intentar borrarlas. Haga de antemano una lista de los registros importantes, normalmente cortafuegos, VPN, directorio y autenticación, correo, consola de endpoints y DNS, y de cómo exportar cada uno. Durante el incidente, cópielos a un almacenamiento fuera de los sistemas afectados, anote la hora y el hash de cada archivo y, si puede, aumente la retención en los equipos. Pregunte a sus proveedores en la nube hasta cuándo llegan sus registros de auditoría. NetSenX guarda sus alertas en su propio servicio durante el historial de alertas que incluye su plan, 30 días en Free y más en los planes de pago, pase lo que pase con sus equipos.

La erradicación consiste en eliminar por completo la presencia del atacante antes de volver a poner en marcha los sistemas. Incluye borrar el malware y las herramientas, cerrar la vía de entrada, eliminar las cuentas, tareas programadas y software de acceso remoto que creó el atacante, restablecer todas las credenciales que puedan haberse expuesto y parchear las vulnerabilidades que usó. En la práctica, reconstruir las máquinas afectadas desde imágenes limpias suele ser más fiable que limpiarlas, porque es difícil demostrar que se ha encontrado cada cambio. La erradicación falla cuando es parcial: un atacante que conserva un punto de apoyo vuelve, a veces semanas después. Debe planificarse a partir de las pruebas de la investigación, no a ciegas. Vigilar la red después comprueba si funcionó: NetSenX detecta un nuevo beaconing hacia servidores externos conocidos o nuevos y sesiones laterales nuevas, en todos los planes.

Desde un dispositivo limpio, en un orden planificado y dentro de una única ventana corta. Empiece por las cuentas que lo controlan todo: administradores del dominio y de la nube, el sistema de copias de seguridad, el acceso remoto y las cuentas de servicio con permisos amplios. En Active Directory, la cuenta que firma los tickets de Kerberos (krbtgt) se restablece dos veces, dejando tiempo para la replicación entre ambas, para que los tickets falsificados dejen de funcionar. Después restablezca a los usuarios corrientes, revoque las sesiones y tokens activos en los servicios en la nube y exija autenticación multifactor (MFA) donde falte. No envíe contraseñas nuevas por un correo que pueda estar comprometido. Si las restablece demasiado pronto, cuando el atacante aún tiene un punto de apoyo, simplemente capturará las nuevas, así que contenga primero. Los cambios de identidad quedan fuera de la vista de un sensor de red; NetSenX muestra si las máquinas del atacante siguen contactando con el exterior después.

No puede saberlo con certeza, pero sí construir una confianza razonable. Compruebe que entiende cómo entró y que esa vía está cerrada, que se han eliminado todas las cuentas y herramientas que creó y que se han restablecido las credenciales. Después busque la ausencia de actividad: ninguna conexión con sus servidores conocidos, ninguna cuenta de administrador nueva, ningún inicio de sesión sin explicación, ningún escaneo entre equipos. Busque en sus registros y endpoints los indicadores de la investigación, como direcciones IP, dominios y hashes de archivos. Mantenga una vigilancia reforzada durante al menos varias semanas, porque algunos atacantes esperan. Una evaluación de compromiso por parte de una empresa externa aporta una visión independiente. NetSenX apoya esta prueba de ausencia desde la red: el beaconing, los escaneos, el movimiento lateral y los volúmenes salientes inusuales se detectan en todos los planes, incluido Free, así que el silencio en los segmentos supervisados significa algo.

El hardware normalmente sí, pero no la instalación. El ransomware y las herramientas que lo acompañan modifican el sistema operativo, añaden cuentas y dejan mecanismos de persistencia difíciles de encontrar, así que lo fiable es borrar y reinstalar las máquinas afectadas desde imágenes de confianza y restaurar los datos desde una copia anterior a la intrusión. Antes de reutilizar las máquinas que necesite la investigación, conserve sus discos o imágenes de ellos. Las infecciones a nivel de firmware existen, pero son raras; su equipo de respuesta le dirá si hay motivo para cambiar hardware. Las máquinas no afectadas también hay que revisarlas, porque los atacantes suelen tocar más sistemas de los que cifran. Antes de volver a conectar las máquinas reconstruidas, asegúrese de que la vía de entrada está cerrada. El mapa de red de NetSenX muestra qué equipos se comunicaron con los afectados durante el incidente, lo que ayuda a decidir qué más revisar.

En un orden controlado, sobre una base limpia y con los ojos abiertos. Primero asegúrese de que la vía de entrada del atacante está cerrada y de que sus cuentas y herramientas han desaparecido. Reconstruya primero el núcleo: el directorio, las cuentas de administrador, el sistema de copias de seguridad y el cortafuegos, con credenciales nuevas. Después restaure los sistemas por orden de prioridad para el negocio, desde copias que haya comprobado que son anteriores a la intrusión y que se hayan analizado antes de usarlas. Ponga en marcha cada sistema en un segmento de red supervisado antes de dar acceso a todos, y mantenga a los usuarios con contraseñas nuevas y autenticación multifactor (MFA). Diga a la plantilla qué debe avisar si algo parece raro y cuente con que la recuperación dure más que el ataque. Vigile la red de cerca durante semanas; NetSenX detecta beaconing, escaneos y movimiento lateral renovados en todos los planes, y así es como a menudo se descubre una limpieza incompleta.

A menudo en parte, si lo ha planificado. Decida de antemano qué procesos son críticos y cómo funcionan unos días sin TI: hojas de pedido en papel, listas de teléfonos de clientes y proveedores, albaranes manuales, un portátil de reserva que nunca haya estado en la red de la empresa. Aislar los sistemas afectados puede permitir que otros sigan funcionando, y por eso una buena segmentación rinde durante el incidente y no solo antes. Cuidado con los atajos: conectar dispositivos personales o un portátil de casa a la red dañada puede extender el problema o destruir pruebas. Comuníquese con la plantilla por un canal ajeno a los sistemas afectados y diga claramente qué no deben hacer. Aseguradoras y clientes valoran a una empresa que siguió atendiéndolos. NetSenX muestra qué segmentos y equipos están implicados, lo que ayuda a decidir qué puede seguir en línea con seguridad.

Al menos varias semanas, y más tras una intrusión grave. Los atacantes que conservaron un punto de apoyo suelen esperar a que el equipo de respuesta se relaje, y un acceso vendido a otros puede usarse mucho después. Durante ese periodo, revise las alertas a diario, busque conexiones con los indicadores de la investigación, compruebe si aparecen cuentas de administrador nuevas o herramientas de acceso remoto y confirme que las copias de seguridad siguen funcionando y no las tocan equipos inusuales. Trate cualquier repetición del patrón original como un incidente nuevo, no como ruido. Decida de antemano quién revisa qué y cuándo termina la vigilancia reforzada. NetSenX detecta beaconing, escaneos, movimiento lateral y volúmenes salientes inusuales en todos los planes, incluido Free, y su historial de alertas, 30 días en Free y más en los planes de pago, permite comparar las semanas posteriores al incidente con las anteriores.

Es una reunión, unas semanas después del incidente, en la que todos los implicados repasan lo que pasó y lo que hay que cambiar. Reconstruya la cronología con el registro del incidente y haga cuatro preguntas: qué salió bien, qué salió mal, qué no sabíamos o no teníamos y qué vamos a cambiar, con un responsable y una fecha para cada cambio. Sin buscar culpables: el objetivo es corregir sistemas y procedimientos, no castigar a nadie, porque si no la próxima vez se ocultarán los errores. Los resultados típicos son una vía de acceso remoto cerrada, MFA donde faltaba, una copia de seguridad que ahora está desconectada, una lista de teléfonos que funciona, un registro que se conserva más tiempo. Incorpore los resultados a su plan y a su próximo ejercicio de simulación. Las alertas de NetSenX y el registro de auditoría dan a la revisión una cronología basada en hechos en la parte de red.

Decida la regla de antemano, porque una pequeña empresa rara vez tiene turno de noche. Anote qué alertas justifican despertar a alguien, quién es esa persona y qué puede hacer sola: por ejemplo, aislar un puesto de trabajo, pero no apagar el servidor del ERP. Todo lo demás espera a la mañana, con una revisión a una hora fija. Si externaliza la supervisión, acuerde las mismas reglas por escrito con el proveedor. Haga que los primeros pasos sean lo bastante sencillos para alguien no especialista: desconectar el dispositivo de la red, anotar la hora, llamar al número indicado. Pruebe una vez la cadena de llamadas. NetSenX envía alertas con un motivo en lenguaje claro y los equipos implicados, así que quien se despierte puede ver rápido si es una copia de seguridad o un puesto de trabajo que contacta de madrugada con un servidor externo nuevo. No le proporciona un turno de noche.

A menudo sí, porque el cifrado es el último paso de una secuencia más larga. Antes, los atacantes suelen tener que entrar, contactar con su propio servidor, explorar, llegar a los servidores de archivos y a las copias de seguridad y, en la mayoría de los ataques actuales, sacar datos. Esos pasos suelen durar días y cruzan la red: un puesto de trabajo que llama a un servidor externo nuevo a intervalos regulares, un equipo que escanea rangos internos, sesiones nuevas de administrador hacia servidores, una gran subida de datos de noche. Los atacantes eligen fines de semana y festivos porque nadie mira, no porque los pasos anteriores fueran invisibles. La pregunta útil es si algo registró esas señales y si alguien habría visto la alerta. NetSenX detecta beaconing, escaneos, movimiento lateral y volúmenes salientes inusuales en todos los planes, incluido Free; que una alerta del viernes por la tarde se atienda antes del lunes depende de su cadena de aviso.

Varía demasiado para que una sola cifra sirva: de horas, cuando un grupo automatizado explota un sistema expuesto, a semanas, cuando el acceso se compra a otro o los atacantes se toman su tiempo para encontrar las copias de seguridad y sacar datos. Lo constante es la secuencia: acceso, contacto con el servidor del atacante, reconocimiento, movimiento hacia los servidores, robo de datos y solo entonces cifrado. Cada etapa es una ocasión de darse cuenta. Planifique como si tuviera poco tiempo: mantenga copias desconectadas para que sobrevivan, asegúrese de que el acceso remoto exige autenticación multifactor (MFA) y decida de antemano quién aísla un equipo de noche. Trate como urgente cualquier señal de las primeras etapas, como un puesto que escanea rangos internos. NetSenX alerta sobre el comportamiento de red de esas etapas en todos los planes, y de ahí sale el tiempo para actuar.

De dos maneras. Un dispositivo puede llevar el propio malware, que se ejecuta cuando alguien abre un archivo disfrazado, y algunos programas maliciosos se copian en cada dispositivo que encuentran para viajar entre ordenadores y sedes. Además, un disco conectado cuando empieza el cifrado se cifra sin más junto con todo lo demás, y por eso una copia de seguridad en un disco USB conectado permanentemente no le protege del ransomware. Desactive la ejecución automática desde medios extraíbles, analice los dispositivos desconocidos en un ordenador dedicado, permita solo dispositivos entregados por la empresa cuando pueda y desconecte los discos de copia después de cada ejecución. INCIBE ha publicado un caso real en el que un ransomware se propagó al conectar dispositivos infectados. Una transferencia por USB no cruza la red, así que un sensor de red no la ve; NetSenX ve lo que hace después el ordenador infectado, como escanear o llamar a un servidor externo.

Conserve sin alterarlo todo lo que muestre qué pasó, cuándo y qué hizo usted. Eso incluye el registro del incidente con horas y decisiones; exportaciones de los registros del cortafuegos, la VPN, el directorio, el correo y los endpoints; la nota de rescate y cualquier mensaje de los atacantes; capturas de pantalla de lo que vieron los usuarios; imágenes forenses cuando las hayan hecho especialistas; y justificantes de los costes. Anote de cada archivo un hash, dónde se guarda y quién lo ha manipulado. La aseguradora suele necesitar la cronología y los justificantes de costes; la policía, los mensajes de los atacantes, las exigencias de pago y los indicadores; el regulador quiere saber qué datos se vieron afectados y cómo respondió. Pregunte pronto a cada uno qué necesita y guarde copias fuera de los sistemas afectados. Las alertas de NetSenX, con horas, equipos y destinos, y su registro de auditoría pueden formar parte de este paquete, con informes en PDF desde el plan Starter.

Durante el historial de alertas de su plan: 30 días en Free y más en cada plan de pago, con los periodos exactos en la página de precios. Las alertas se guardan con su hora, los equipos implicados, los destinos, los volúmenes y los motivos que las provocaron, junto con las decisiones de los analistas en el registro de auditoría. Si un incidente puede acabar en una reclamación, en preguntas de un regulador o en un juicio, no confíe solo en la retención: exporte lo importante mientras el incidente está reciente, con informes en PDF desde el plan Starter, y guarde la exportación con el resto de pruebas. Piense antes de que ocurra nada en el periodo que necesitará: el tiempo de permanencia puede ser de semanas, así que un historial corto puede terminar antes de que empezara la intrusión. Los registros del cortafuegos, la VPN y el directorio tienen su propia retención, a menudo más corta, que conviene comprobar hoy y no en pleno incidente.

Gestione usted la primera hora y llame a una empresa para todo lo que vaya más allá de un único dispositivo contenido. Su propio equipo conoce los sistemas, así que debe aislar las máquinas, empezar el registro y conservar las pruebas. Una empresa externa aporta lo que un equipo pequeño rara vez tiene: herramientas y experiencia forense, conocimiento de las costumbres de los atacantes, contactos con las fuerzas de seguridad y credibilidad ante aseguradoras y reguladores. Llámela cuando un atacante pueda seguir activo, cuando estén afectados servidores o muchos dispositivos, cuando puedan haber salido datos o cuando el incidente pueda ser notificable o acabar en una reclamación. Compruebe primero si su seguro cibernético designa una empresa, porque usar otra puede afectar a la cobertura, y acuerde de antemano qué accesos necesitará. NetSenX no es una empresa de respuesta a incidentes; las alertas explicadas y el historial de red que conserva son lo que esa empresa le pedirá el primer día.

Con honestidad, de forma concreta y solo con lo que sabe, y después actualizando. Diga qué pasó y cuándo, qué categorías de sus datos están implicadas, qué ha hecho, qué sigue investigando, qué deberían hacer, como desconfiar de phishing que use sus datos, y a quién contactar. Evite decir que no se vio afectado ningún dato antes de que la investigación lo respalde; una rectificación cuesta más confianza que un primer mensaje prudente. Acuerde el texto con su abogado y su delegado de protección de datos, porque comunicarlo a las personas puede ser una obligación legal con contenido propio, y con su aseguradora. Envíelo por un canal no comprometido y avise a los clientes de que pueden circular mensajes falsos de seguimiento. Las pruebas hacen preciso el mensaje: las alertas de NetSenX muestran qué equipos enviaron volúmenes inusuales y cuándo, lo que ayuda a decir qué sistemas, y por tanto qué clientes, están afectados.

En parte. Los registros de red pueden mostrar que un servidor concreto, el que guarda los datos de ese cliente, no envió volúmenes inusuales en el periodo y que ningún destino externo nuevo recibió datos de él. Es una prueba significativa, sobre todo si el servidor suele enviar poco. No es una prueba concluyente por sí sola: los datos pudieron copiarse antes a otra máquina interna y salir desde allí, enviarse en pequeñas cantidades por debajo de umbrales evidentes o llevarse por un canal que el sensor no vigila, como un servicio en la nube usado directamente o un segmento no supervisado. Preséntela al cliente como lo que es: evidencia de ausencia en las vías que supervisa, combinada con registros del servidor y de la nube. NetSenX conserva alertas por equipo de volúmenes salientes inusuales, y su mapa de red muestra qué equipos se comunicaron con ese servidor.

En la mayoría de los países de la UE, el CSIRT nacional o la agencia de ciberseguridad es la primera llamada gratuita, y varios ofrecen servicios para pequeñas empresas. España tiene la línea gratuita 017 de INCIBE; Polonia, CERT Polska, que recibe notificaciones de incidentes; Alemania, el BSI y las unidades de cibercrimen de las policías de los Länder; Francia, la plataforma nacional Cybermalveillance para empresas y la ANSSI para entidades reguladas; Italia, CSIRT Italia en la ACN; los Países Bajos, el Digital Trust Center para empresas y el NCSC para sectores vitales. Pueden orientarle, a veces darle indicadores y contactos, pero normalmente no hacen el trabajo de recuperación por usted. La línea de asistencia de su seguro cibernético, si lo tiene, es la otra llamada temprana, y los delitos deben denunciarse a la policía. NetSenX no presta servicios de respuesta a incidentes, pero sus alertas dan a quien llame un punto de partida basado en hechos.

Sí, en la mayoría de los casos. El ransomware, la extorsión, el fraude y el robo de datos son delitos, y una denuncia ayuda a los investigadores a relacionar casos, a veces conduce a claves de descifrado obtenidas en operaciones policiales y las aseguradoras la suelen exigir para un siniestro. Denunciar a la policía es distinto de cualquier notificación regulatoria a su CSIRT o a la autoridad de protección de datos; puede que tenga que hacer varias. Muchos países tienen unidades especializadas en cibercrimen o denuncia en línea para empresas, y su CSIRT nacional puede decirle adónde acudir. Lleve los hechos: la cronología, la nota de rescate y los mensajes, las exigencias de pago, indicadores como direcciones IP y dominios, y los costes hasta ese momento. Denunciar no significa perder el control de su recuperación y normalmente no hace público el incidente. Las alertas de NetSenX, con horas, equipos y destinos, pueden formar parte de lo que entregue.

A veces, por los efectos secundarios más que por la intención. INCIBE ha publicado un caso real en el que un empleado introdujo código malicioso y robó un millón de euros. Estos casos se basan en accesos que la persona ya tiene, así que la prevención está en los procesos: separación de funciones en los pagos, aprobación por una segunda persona, revisión del código en los cambios a sistemas financieros y retirada rápida de accesos cuando cambian los puestos. Aun así pueden aparecer señales técnicas: un puesto que contacta con un servidor externo desconocido, conexiones nuevas al sistema de pagos o al ERP desde una máquina que nunca lo usó, subidas inusuales. NetSenX vigila dispositivos y conexiones, nunca personas: puede detectar ese comportamiento en la red, en todos los planes, pero no juzga la intención ni ve lo que ocurre dentro de una aplicación. Investigar a una persona es cosa de Recursos Humanos y de los juristas, y del comité de empresa donde exista.

Compruebe primero las causas corrientes y después busque señales de un ataque. Muchas caídas se deben a un certificado o un dominio caducados, un disco lleno, una actualización fallida o un problema del proveedor de alojamiento. Pregunte a su proveedor y mire su página de estado, y después revise los registros del servidor web: una avalancha repentina de peticiones desde muchas direcciones apunta a un ataque de denegación de servicio; páginas modificadas, cuentas de administrador nuevas o archivos desconocidos, a un compromiso del propio sitio; un registro DNS cambiado, a un ataque al registro de su dominio. Guarde los registros antes de reiniciar nada. Si el sitio guarda datos de clientes o cobra pagos, trate un compromiso como una posible brecha de datos. NetSenX no protege sitios web públicos alojados fuera de su red; si el servidor web está en su red, muestra las conexiones salientes y los volúmenes inusuales que salen de él.

No, y la diferencia está en dónde actúa cada una. Un ataque distribuido de denegación de servicio (DDoS) inunda su web, su VPN o su línea de internet con tráfico de muchas máquinas hasta que dejan de responder. Detenerlo exige capacidad por delante de usted: en su proveedor de internet, en una red de distribución de contenidos (CDN) o en un servicio de limpieza que absorbe y filtra la avalancha antes de que llegue a su línea. La detección de red dentro de la empresa, como NetSenX, vigila el comportamiento de sus propios equipos para encontrar intrusos, beaconing, escaneos, movimiento lateral y datos que salen; no bloquea tráfico ni tiene ancho de banda para absorber una avalancha. Pregunte a su proveedor qué protección DDoS tiene hoy su línea y, para servicios públicos, valore un alojamiento protegido. Algunos ataques DDoS sirven de distracción, así que compruebe que no ocurre nada más dentro mientras dura la caída.

Pruebas y plazos, no manos adicionales. Durante un incidente, NetSenX le da alertas de beaconing, escaneos, movimiento lateral y volúmenes salientes inusuales, en todos los planes, cada una con un motivo en lenguaje claro, los equipos implicados, destinos, volúmenes y horas, y la técnica de MITRE ATT&CK cuando corresponde; el mapa de red de quién habla con quién; un registro de auditoría de alertas y decisiones de los analistas; y el seguimiento de los plazos del artículo 23 de NIS2, con una notificación del artículo 33 del RGPD preparada para su delegado de protección de datos, cuyo envío sigue siendo cosa suya. Desde el plan Starter añade informes en PDF y recomendaciones de respuesta, y desde el plan Pro la correlación de equipos en una sola historia. No expulsa atacantes, no restaura datos ni negocia, y no ve dentro de sesiones cifradas ni en segmentos que usted no supervisa. Eso lo cubren su equipo de respuesta, sus herramientas de endpoint y sus copias de seguridad.

Cierre primero su puerta y después haga preguntas. Suspenda las cuentas del proveedor, su acceso VPN y sus herramientas de soporte remoto en sus sistemas hasta que confirme qué se vio afectado, y cambie cualquier credencial compartida o clave de API. Pregúntele por escrito qué pasó y cuándo, qué sistemas suyos estuvieron implicados, si se expusieron sus datos o sus datos de acceso y qué indicadores de compromiso tiene, y después busque esos indicadores en sus registros. Compruebe hasta dónde llegaba su acceso: qué servidores, qué datos. Trate con cautela sus correos relacionados con pagos, porque los hilos de correo robados se reutilizan para el fraude de facturas. Si sus datos quedaron expuestos a través de él, puede tener obligaciones de notificación propias. Revise el contrato en busca de cláusulas de seguridad y notificación. NetSenX detecta beaconing y sesiones inusuales desde los equipos que usaba el proveedor, y su mapa de red muestra con qué hablaron realmente esos equipos.

Porque la limpieza es distinta. Una cuenta comprometida significa que alguien tiene la contraseña o la sesión de un usuario, utilizables desde cualquier sitio: la solución es restablecer credenciales, revocar sesiones, revisar las reglas del buzón e imponer la autenticación multifactor (MFA), y las pruebas están en los registros de identidad y de los servicios. Un dispositivo comprometido significa que alguien controla la propia máquina, a menudo con malware: la solución es aislarla y reconstruirla, y las pruebas están en el endpoint y en su tráfico de red. Muchos incidentes combinan ambos, como contraseñas robadas desde un portátil infectado o una cuenta usada para instalar herramientas en un servidor. Averigüe cuál tiene antes de elegir medidas, o restablecerá contraseñas en un dispositivo que captura las nuevas. NetSenX ve la parte del dispositivo en la red: una máquina que llama a un servidor externo, escanea o abre sesiones nuevas. El abuso de una cuenta desde fuera de su red corresponde a los registros de identidad.