Seguridad en la Empresa · Respuesta a incidentes

Cómo responder a un incidente de seguridad en una VM Linux: guía técnica paso a paso

Respuesta rápida

Cuando una VM Linux es comprometida, la primera regla es: no apagues el servidor — la memoria volátil contiene artefactos forenses que desaparecen en un reinicio. El protocolo correcto, basado en el NIST SP 800-61, exige que preserves las evidencias, aísles la instancia de la red y solo entonces inicies el triaje sistemático. La respuesta mal ejecutada — como formatear el disco antes de recolectar evidencias — puede inviabilizar la investigación, destruir la cadena de custodia e impedir cualquier acción jurídica o regulatoria posterior.

Empieza gratis ahora Ver planes

Decripte es una empresa de ciberseguridad que atiende a empresas de 1 a más de 100.000 empleados — del diagnóstico a la respuesta a incidentes 24x7.

Señales de alerta

›Procesos desconocidos o con nombres disfrazados. Procesos con nombres similares a binarios legítimos (ej.: 'systemd-' con espacio, 'kworker' en un directorio inusual), consumo anormal de CPU/memoria detectado vía 'top' o 'ps auxf', procesos ejecutándose desde directorios temporales como /tmp, /dev/shm o /var/tmp — patrón clásico de malware y mineros de criptomonedas en Linux.
›Conexiones de red no autorizadas o tráfico de C2. Conexiones de salida hacia IPs desconocidas en puertos inusuales (4444, 8080, 1337), especialmente en estado ESTABLISHED sin un proceso claramente mapeado vía 'ss -tulnp' o 'lsof -i'. Tráfico DNS anómalo con subdominios largos puede indicar DNS tunneling para exfiltración de datos.
›Claves SSH agregadas o usuarios creados. Entradas nuevas en ~/.ssh/authorized_keys de usuarios privilegiados o de cuentas de servicio, usuarios creados con UID 0 o con shell válido que no deberían existir en /etc/passwd, cambios en /etc/sudoers para elevación silenciosa de privilegio — indican persistencia tras el compromiso de credenciales.
›Trabajos de cron y servicios systemd sospechosos. Entradas en /etc/cron.d/, /var/spool/cron/crontabs/ o archivos .service en /etc/systemd/system/ que ejecutan scripts desde /tmp o /dev/shm, descargan payloads remotos vía curl/wget, o se reactivan periódicamente — mecanismo de persistencia usado con frecuencia tras la explotación inicial de una vulnerabilidad.
›Modificaciones en binarios del sistema o archivos de configuración. Binarios en /bin, /usr/bin, /sbin con fechas de modificación recientes incompatibles con el historial de actualizaciones del sistema, detectados vía 'find /bin /usr/bin -newer /var/log/dpkg.log' o vía 'rpm -Va'/'debsums -c'. Cambios en /etc/ld.so.preload para inyección de bibliotecas maliciosas son señal clásica de rootkit en userspace.
›Fallas de autenticación masivas seguidas de un éxito. Cientos de intentos de SSH con distintos usuarios y contraseñas (brute force) en /var/log/auth.log, seguidos de un inicio de sesión exitoso desde una IP externa — patrón de credential stuffing o brute force exitoso. También: inicios de sesión de cuentas de servicio (www-data, postgres, nobody) vía SSH que nunca deberían tener shell interactivo.

Paso a paso

1
1. No apagues — preserva la memoria volátil
Antes de cualquier acción, captura la memoria RAM con LiME (Linux Memory Extractor) o vía /proc/kcore. La memoria contiene procesos ocultos, claves de cifrado en uso, sesiones de red abiertas y malware residente que desaparece al apagar el equipo. Usa 'insmod lime.ko path=/mnt/evidencias/mem.lime format=lime' y documenta el hash SHA-256 de inmediato para garantizar la integridad forense y la cadena de custodia.
2
2. Toma un snapshot/imagen del disco antes de tocar cualquier archivo
Crea un snapshot de la VM a nivel del hypervisor (AWS: aws ec2 create-snapshot; GCP: gcloud compute disks snapshot) o usa 'dd if=/dev/sda | gzip | ssh backup@host dd of=disco.img.gz' para una imagen bit a bit. Calcula y almacena los hashes MD5 y SHA-256 de cada imagen. Esa imagen inmutable es la base de la cadena de custodia — sin ella, cualquier análisis posterior puede ser cuestionado.
3
3. Aísla la VM sin destruirla
Modifica el Security Group (AWS), las reglas de firewall (GCP/Azure) o las reglas de iptables para bloquear todo el tráfico de entrada y salida, excepto tu sesión SSH de investigación originada desde una IP de gestión confiable. No elimines la instancia, no restaures el backup todavía. El objetivo es cortar la comunicación con el atacante (C2, exfiltración) manteniendo el estado forense intacto para el análisis.
4
4. Triaje de análisis: procesos, conexiones y persistencia
Ejecuta en secuencia rápida, redirigiendo la salida a archivos con timestamp: (a) Procesos — 'ps auxf', 'top -bn1', 'lsof -nP'; (b) Conexiones de red — 'ss -tulnp', 'netstat -antp', 'lsof -i'; (c) Persistencia — 'crontab -l', 'cat /etc/cron.*/*', 'systemctl list-units --type=service', 'grep -r CRON /var/spool/cron/', 'cat ~/.bashrc ~/.profile', 'cat ~/.ssh/authorized_keys'. Mapea todo antes de modificar cualquier archivo.
5
5. Audita usuarios, inicios de sesión y logs de autenticación
Verifica 'cat /etc/passwd | awk -F: \"$3==0\"' para detectar UID 0 indebidos; 'last -F' y 'lastb -F' para inicios de sesión exitosos y fallidos con IPs; 'who' y 'w' para sesiones activas; 'cat /var/log/auth.log' o 'journalctl -u ssh --since "48 hours ago"' para intentos de autenticación. Identifica usuarios creados por el atacante, claves SSH insertadas y elevaciones de privilegio vía sudo/su.
6
6. Verifica la integridad de los binarios y rastrea rootkits
En sistemas RPM: 'rpm -Va 2>/dev/null | grep -E "^..5|^.M"' detecta binarios alterados. En Debian/Ubuntu: 'debsums -c'. Ejecuta 'chkrootkit' y 'rkhunter --check --skip-keypress' desde un medio externo (pen drive o AMI limpia montada) para evitar falsos negativos causados por binarios del sistema ya comprometidos. Verifica también 'find / -perm -4000 -type f 2>/dev/null' para detectar SUID indebidos.
7
7. Contén, erradica mediante reaprovisionamiento y recupera desde una imagen limpia
Tras la recolección de evidencias, no confíes en ninguna limpieza manual — el atacante puede haber implantado persistencia en niveles que no verás. La práctica recomendada por el NIST SP 800-61 es reaprovisionar la VM a partir de una AMI/imagen de línea base verificada, restaurar únicamente datos (no binarios) de un backup previo al compromiso, y solo entonces reintegrarla al entorno con monitoreo intensificado (IDS/EDR, logs centralizados).
8
8. Documenta, notifica y registra las lecciones aprendidas
Elabora el informe de incidente con: línea de tiempo (timeline), TTPs mapeados al MITRE ATT&CK (tácticas, técnicas, procedimientos), IoCs (hashes, IPs, dominios), causa raíz, impacto estimado y acciones tomadas. Notifica a las partes internas (CISO, jurídico, comunicación) y a las externas obligatorias (ANPD si se expusieron datos personales, conforme al art. 48 de la LGPD). Agenda una reunión de lecciones aprendidas dentro de los 5 días hábiles posteriores al cierre.

Lo que NO se debe hacer

✕No apagues ni reinicies la VM de inmediato. Apagar la máquina destruye la memoria RAM y, con ella, los procesos en ejecución, las conexiones abiertas, las claves de cifrado y los artefactos de malware que solo existen en memoria. Reiniciar también puede activar scripts de limpieza del atacante. Preserva el estado volátil antes de cualquier apagado.
✕No ejecutes herramientas de análisis directamente sobre los binarios del sistema comprometido. Comandos como 'ps', 'ls', 'netstat' y 'find' pueden haber sido reemplazados por versiones troyanizadas que ocultan procesos, archivos y conexiones del atacante. Usa siempre binarios confiables desde un medio externo (live CD, AMI limpia montada en modo read-only) o transfiere los artefactos a una estación forense aislada.
✕No borres logs ni archivos sospechosos antes de copiarlos. Los logs en /var/log/, los archivos en /tmp/ y cualquier artefacto identificado como malicioso son evidencias. Borrarlos o moverlos antes de recolectarlos y calcular sus hashes rompe la cadena de custodia y puede inviabilizar acciones judiciales, notificaciones regulatorias y un análisis forense en profundidad.
✕No intentes limpiar el sistema manualmente y devolverlo a producción. La limpieza manual de un sistema comprometido rara vez es completa. El atacante puede haber instalado rootkits a nivel de kernel, backdoors en bibliotecas compartidas o modificado el bootloader. La única forma segura de volver a producción es reaprovisionar a partir de una imagen base verificada y conocidamente limpia.
✕No comuniques el incidente por canales que puedan estar comprometidos. Si la VM afectada aloja servicios de correo, Slack u otros canales de comunicación, asume que esos canales están comprometidos. Usa un medio de comunicación completamente separado y fuera de banda para coordinar la respuesta — teléfono, Signal o un workspace de incidente aislado — para evitar que el atacante monitoree tu investigación.

Fundamentos: por qué el orden de las acciones importa en incidentes Linux

El NIST SP 800-61 (Computer Security Incident Handling Guide) establece cuatro fases para la respuesta a incidentes: Preparación, Detección y Análisis, Contención/Erradicación/Recuperación y Actividad Posterior al Incidente. En VMs Linux, la secuencia de las acciones en la fase de contención es crítica porque cada acción modifica el estado del sistema — y el orden equivocado puede destruir evidencias antes de que sean recolectadas.

La volatilidad de las evidencias sigue una jerarquía: registros de CPU y estado del proceso (los más volátiles), memoria RAM, conexiones de red y tablas de enrutamiento, procesos en ejecución, sistemas de archivos temporales (/tmp, /dev/shm) y, por último, archivos en disco (los menos volátiles). Ese orden — conocido como 'Order of Volatility' — debe guiar la secuencia de recolección forense antes de cualquier acción de contención.

Errores comunes que comprometen las investigaciones incluyen: reinicio inmediato 'para limpiar el sistema', ejecución de 'rm -rf /tmp/*' antes de recolectar evidencias, restauración del backup antes del análisis y comunicación del incidente por canales potencialmente comprometidos. Los equipos sin capacitación específica en IR tienden a cometer estos errores bajo presión, lo cual es un argumento técnico sólido para convocar especialistas desde el inicio.

Triaje forense: mapa completo de los artefactos en un sistema Linux

El triaje sistemático en Linux cubre cinco superficies de análisis. (1) Procesos y memoria: 'ps auxf --forest' para el árbol de procesos, 'lsof -nP +L1' para archivos eliminados aún abiertos (técnica común de malware), '/proc/[PID]/maps' y '/proc/[PID]/exe' para localizar binarios de procesos sospechosos, 'strings /proc/[PID]/mem' para extraer artefactos de la memoria de un proceso específico.

(2) Red: 'ss -tulnp' lista todos los sockets con su PID asociado, 'iptables -L -n -v' e 'ip rule show' revelan reglas de firewall que el atacante puede haber insertado, '/proc/net/tcp' y '/proc/net/udp' muestran conexiones incluso si 'netstat' está comprometido. (3) Persistencia: además de cron y systemd ya mencionados, verifica '/etc/rc.local', '/etc/init.d/', 'at -l' (trabajos agendados), 'find / -name ".bashrc" -o -name ".profile" 2>/dev/null | xargs grep -l "curl\|wget\|nc "'.

(4) Autenticación y control de acceso: además de /etc/passwd, analiza '/etc/shadow' en busca de hashes recién modificados, '/etc/group' para detectar miembros inesperados de grupos privilegiados (sudo, wheel, adm), y los logs PAM en /var/log/auth.log. (5) Integridad del sistema de archivos: 'find / -mtime -1 -type f 2>/dev/null' lista los archivos modificados en las últimas 24h, 'stat' sobre binarios críticos revela timestamps de modificación inconsistentes con el historial de parches.

Evalúa tu empresa gratis

Descubre en minutos qué ya está expuesto de tu negocio.

El plan gratuito de Gestión de Amenazas de Decripte mapea vulnerabilidades, monitorea amenazas y muestra credenciales filtradas — sin tarjeta y sin equipo técnico.

Empieza gratis ahora

Cadena de custodia y documentación forense: requisitos mínimos

La cadena de custodia es el registro ininterrumpido y verificable de quién recolectó, almacenó y accedió a cada evidencia, y en qué momento. Sin ella, las evidencias son inadmisibles en procesos judiciales y pueden ser cuestionadas en auditorías regulatorias (LGPD, PCI DSS, ISO 27001). Para cada evidencia recolectada, registra: fecha y hora (UTC), responsable de la recolección, método y herramientas utilizadas, hash SHA-256 antes y después de cualquier transferencia, y ubicación de almacenamiento.

Para imágenes de disco y memoria, usa 'sha256sum' inmediatamente después de la captura y almacena el hash junto a la evidencia en un medio separado (ej.: correo firmado digitalmente enviado a ti mismo o a un tercero confiable). Herramientas como Guymager o dc3dd generan hashes automáticamente durante la adquisición. Para los logs, usa 'tar czf --numeric-owner logs_$(date +%Y%m%d_%H%M%S).tar.gz /var/log/' y calcula el hash del archivo comprimido.

El informe de incidente debe seguir una estructura estandarizada: resumen ejecutivo (para la gestión), línea de tiempo técnica detallada (para el equipo de IR y jurídico), IoCs (para bloqueo y threat intelligence), análisis de causa raíz (para la corrección), impacto estimado (para seguros y reguladores) y recomendaciones de remediación priorizadas. Mapear los TTPs al framework MITRE ATT&CK — como T1053 (Scheduled Task/Job), T1136 (Create Account) o T1059 (Command and Scripting Interpreter) — facilita la comunicación entre equipos y permite correlacionar con amenazas conocidas.

Erradicación y recuperación: por qué reaprovisionar es la única opción segura

La tentación de 'limpiar' un servidor comprometido es comprensible — parece más rápido que reaprovisionar. En la práctica, es la decisión que con más frecuencia lleva a nuevos compromisos en días o semanas. Los rootkits a nivel de kernel (LKM rootkits) modifican llamadas al sistema directamente en el kernel, volviéndose invisibles para cualquier herramienta que se ejecute en el mismo sistema operativo. Los bootkits modifican el bootloader. Los implantes en bibliotecas compartidas (/usr/lib/) afectan a todos los procesos que las cargan.

El proceso correcto de erradicación comienza con la identificación de la vulnerabilidad explotada (CVE, misconfiguration, credencial filtrada) y su corrección en la imagen base antes de volver a desplegar. Sin corregir la causa raíz, el mismo atacante — u otros que compraron el acceso — recomprometerán el sistema en horas. Usa infraestructura como código (Terraform, Ansible, CloudFormation) para garantizar que la nueva instancia se aprovisione de forma reproducible y auditable.

En la recuperación, restaura únicamente datos de negocio (base de datos, archivos subidos por usuarios) desde backups verificados anteriores al incidente — nunca restaures binarios, configuraciones o scripts desde fuentes comprometidas. Reintegra el servidor al entorno de producción bajo monitoreo intensificado: EDR activo, logging de todas las llamadas al sistema (auditd), alertas de integridad de archivos (AIDE, Wazuh) y revisión manual de los primeros logs durante 48 a 72 horas. Documenta la fecha y hora del retorno a producción como parte de la línea de tiempo del incidente.

Cuándo convocar a un equipo especializado de respuesta a incidentes

Algunas señales indican que el incidente excede la capacidad de respuesta interna y exige especialistas externos de inmediato: (1) hay evidencias de exfiltración de datos sensibles (datos personales, propiedad intelectual, secretos de negocio), lo que puede activar obligaciones legales de notificación a la ANPD en hasta 72 horas; (2) el compromiso alcanzó múltiples sistemas o parece ser un ataque dirigido (APT) con persistencia sofisticada; (3) la causa raíz no fue identificada tras el triaje inicial; (4) hay impacto operativo crítico (sistemas de pago, infraestructura de salud, control industrial).

Otros criterios para la convocatoria inmediata: (5) el equipo interno no tiene herramientas forenses adecuadas ni capacitación específica en IR Linux; (6) existe riesgo de impacto reputacional o regulatorio que exige documentación forense para la defensa legal; (7) el atacante aún está activo en el entorno — un equipo especializado tiene la capacidad de ejecutar threat hunting y expulsión coordinada sin alertar prematuramente al intruso.

Convocar especialistas no significa perder el control del incidente — significa tener al lado un equipo con herramientas, playbooks y experiencia en cientos de incidentes similares. La diferencia entre una respuesta interna no estructurada y una respuesta profesional puede medirse en horas de downtime evitado, datos no exfiltrados y multas regulatorias no aplicadas. Decripte opera con guardia 24x7 y SLA de inicio de atención en hasta 4 horas para clientes con plan de respuesta a incidentes contratado.

Decripte realiza respuesta a incidentes y forense digital para empresas de todos los tamaños — desde el emprendedor individual hasta el grupo con más de 100.000 colaboradores — con equipo certificado, cadena de custodia documentada e informes aceptados por órganos reguladores y judiciales brasileños. Si tu VM Linux fue comprometida o sospechas de un compromiso, ingresa a /plano/resposta-incidentes para activar la atención o solicita un diagnóstico gratuito para evaluar el nivel de exposición de tu entorno.

Lecciones aprendidas y hardening posincidente: transformando la crisis en madurez

La fase de lecciones aprendidas — obligatoria en el NIST SP 800-61 — suele ser omitida por equipos bajo presión para volver a la normalidad. Es un error estratégico: los incidentes en organizaciones sin este proceso tienden a repetirse con variaciones, porque la causa raíz estructural no se aborda. La reunión posincidente debe realizarse dentro de los 5 días hábiles posteriores al cierre, con participación de técnicos, gestores y representantes de negocio.

Las preguntas centrales de la retrospectiva: ¿cómo entró el atacante (vector inicial)? ¿Cuánto tiempo permaneció sin ser detectado (dwell time)? ¿Qué controles existentes deberían haber detectado el ataque y no lo hicieron? ¿Qué funcionó bien en la respuesta? ¿Qué procedimientos fallaron? Las respuestas alimentan un plan de hardening priorizado por riesgo real — no por compliance teórico.

Controles posincidente típicos para entornos Linux: implementación de MFA para el acceso SSH (claves + TOTP vía PAM), deshabilitación de la autenticación por contraseña en SSH, uso de bastion host o VPN para el acceso administrativo, despliegue de AIDE o Wazuh para integridad de archivos en tiempo real, centralización de logs en un SIEM inmutable (los logs locales son los primeros objetivos de los atacantes), segmentación de red por función (bases de datos no accesibles directamente desde internet) y un programa de patch management con SLA definido por criticidad de CVE.

Términos importantes

Cadena de Custodia: Registro documentado, cronológico y verificable de quién recolectó, transfirió, accedió y almacenó cada evidencia digital en una investigación forense. Garantiza la integridad y autenticidad de las evidencias para su uso en procesos judiciales, auditorías regulatorias y disputas contractuales. Se establece calculando hashes criptográficos (SHA-256) de las evidencias en el momento de la recolección y manteniendo el registro de toda la cadena de acceso posterior.
Dwell Time: Tiempo transcurrido entre el compromiso inicial de un sistema y su detección por el equipo de seguridad o por el equipo de respuesta a incidentes. Cuanto mayor es el dwell time, mayor es el potencial de daño: el atacante tuvo más tiempo para el movimiento lateral, la exfiltración de datos, la escalada de privilegios y el establecimiento de múltiples puntos de persistencia. La reducción del dwell time es uno de los principales indicadores de madurez de un programa de seguridad.
Order of Volatility: Jerarquía de evidencias digitales ordenada de la más a la menos volátil, que define la secuencia de recolección forense. En orden decreciente de volatilidad: registros de CPU y estado de procesos, memoria RAM, conexiones de red y tablas de enrutamiento, procesos en ejecución, sistemas de archivos temporales, disco duro y, por último, logs y backups archivados. La recolección en el orden correcto preserva evidencias que se perderían con el tiempo o con acciones posteriores.
MITRE ATT&CK: Framework público mantenido por la organización MITRE que categoriza y describe tácticas, técnicas y procedimientos (TTPs) usados por grupos de amenazas avanzadas en ataques reales. En respuesta a incidentes Linux, se usa para mapear los artefactos encontrados (ej.: trabajo de cron malicioso → T1053.003 Cron, clave SSH insertada → T1098.004 SSH Authorized Keys) a técnicas conocidas, facilitando la comunicación entre equipos y la identificación de patrones de ataque específicos de grupos APT.

Preguntas frecuentes

¿Puedo apagar la VM Linux comprometida para 'detener el ataque' de inmediato?

No. Apagar la VM destruye la memoria RAM y, con ella, evidencias críticas: procesos maliciosos en ejecución, conexiones activas con servidores de C2, claves de cifrado y artefactos de malware que solo existen en memoria. Lo correcto es aislar la VM en la red (modificando Security Groups o reglas de firewall a nivel del proveedor cloud) sin apagarla, y solo entonces iniciar la recolección de evidencias. El apagado puede ocurrir tras la captura de memoria y el snapshot de disco.

¿Cómo saber si los binarios del sistema Linux fueron reemplazados por versiones maliciosas?

En sistemas RPM (RHEL, CentOS, Amazon Linux): ejecuta 'rpm -Va 2>/dev/null' y filtra por líneas que comienzan con '..5' (hash MD5 alterado) o '.M' (permisos alterados). En sistemas Debian/Ubuntu: usa 'debsums -c' para verificar los hashes de todos los archivos de los paquetes instalados. Para ambos: ejecuta chkrootkit y rkhunter desde un medio externo o desde una AMI limpia montada en modo read-only, ya que las herramientas que se ejecutan en un sistema comprometido pueden estar troyanizadas y devolver falsos negativos.

¿Qué es la cadena de custodia en respuesta a incidentes y por qué importa?

La cadena de custodia es el registro documentado y verificable de quién recolectó, transfirió, accedió y almacenó cada evidencia digital, en qué momento y por qué método. Es obligatoria para que las evidencias sean aceptadas en procesos judiciales (delitos cibernéticos, disputas contractuales) y en auditorías regulatorias (LGPD, PCI DSS). Sin ella, la defensa del atacante puede alegar que las evidencias fueron adulteradas. La cadena de custodia se establece calculando hashes SHA-256 de cada evidencia en el momento de la recolección y documentando toda la cadena de acceso posterior.

¿Cuánto tiempo suele permanecer un atacante en una VM Linux sin ser detectado (dwell time)?

Según informes del sector, el dwell time promedio — tiempo entre el compromiso inicial y la detección — varía de 16 a 24 días en entornos sin EDR ni monitoreo continuo. En entornos con SIEM y alertas configuradas, ese número cae a horas o días. Los atacantes sofisticados (APTs) pueden permanecer meses sin ser detectados, realizando reconocimiento lento y exfiltración gradual por debajo de los umbrales de alerta. La implementación de logging centralizado inmutable y análisis conductual es el principal reductor del dwell time.

¿Debo pagar el rescate si mi VM Linux fue infectada por ransomware?

No existe una respuesta universal, pero los especialistas en IR recomiendan no pagar como regla general por las siguientes razones: el pago no garantiza la recuperación de los datos (en promedio, el 30% de las organizaciones que pagan no recuperan todo), financia grupos criminales y no resuelve la vulnerabilidad original — el mismo entorno puede ser recomprometido en días. Antes de cualquier decisión, convoca a un especialista en IR para evaluar si hay backups válidos previos al compromiso, si los archivos pueden recuperarse por medios forenses, y cuál es la extensión real del compromiso.

¿Estoy obligado a notificar a la ANPD si se expusieron datos personales en una VM Linux comprometida?

Sí, conforme al artículo 48 de la LGPD, los controladores de datos personales deben notificar a la ANPD y a los titulares afectados sobre incidentes de seguridad que puedan acarrear riesgo o daño relevante a los titulares, en un plazo que la ANPD fijó en hasta 72 horas tras el conocimiento del incidente. La notificación debe incluir: naturaleza de los datos afectados, número de titulares involucrados (real o estimado), medidas técnicas y de seguridad adoptadas, riesgos relacionados al incidente y medidas que fueron o serán adoptadas. Se recomienda involucrar al DPO y al equipo jurídico de inmediato.

¿Cuál es la diferencia entre chkrootkit y rkhunter para la detección de rootkits en Linux?

Ambas son herramientas open source de detección de rootkits en Linux, pero con enfoques complementarios. chkrootkit (Chuck Rootkit) verifica firmas conocidas de rootkits, troyanos y backdoors en binarios del sistema y en las salidas de comandos. rkhunter (Rootkit Hunter) realiza verificaciones más abarcadoras: hashes MD5 de binarios críticos, atributos de archivos, configuraciones de red, strings en comandos, y compara con bases de datos actualizables de firmas. La recomendación es ejecutar ambas — desde un medio externo — porque cada una detecta subconjuntos diferentes de amenazas. Ninguna herramienta es 100% eficaz contra rootkits avanzados a nivel de kernel.

Seguridad para empresas

Decripte protege empresas de todos los tamaños — del autónomo al Enterprise.

Plataforma y servicios completos: gestión de amenazas, SOC 24x7, respuesta a incidentes, pentest y cumplimiento. Empieza gratis y descubre qué ya se filtró de tu negocio.

Empieza gratis ahora Ver planes