RedAlert / N13V
Alias: RedAlert ransomware, N13V
Fecha de revisión del perfil de origen: 2026-06-21
Añadido al registro de la fuente: 2022-07-14 · Instantánea de la fuente: 2026-09-15
Los metadatos de la fuente no se han verificado de forma independiente. La fecha de registro no es necesariamente la del primer ataque. Los resúmenes de la fuente se traducen automáticamente cuando es necesario; el flujo puede contener evaluaciones antiguas.
Estado de la investigación: Expediente investigado existente
Este expediente separa la información de fuentes específica del actor del análisis defensivo general. Las recomendaciones y preguntas de investigación no constituyen hechos adicionales sobre el actor. Las limitaciones de la evidencia pública se indican expresamente.
Traducción generada localmente; la revisión lingüística está pendiente.
Resumen ejecutivo
RedAlert/N13V es conocido por Linux/VMware ESXi-like ransomware context y consecuentemente golpea capas servidor
RedAlert, también llamado N13V, fue discutido públicamente en 2022 como ransomware con Linux- y VMware ESXi-impact. Por lo tanto es relevante para la virtualización y la usabilidad del servidor.
Las últimas cinco víctimas reivindicadas conocidas
Cargando reivindicaciones guardadas…
Son reivindicaciones públicas atribuidas al grupo, no intrusiones confirmadas de forma independiente. Las fechas indican publicación o descubrimiento, no necesariamente el ataque.
Resumen de la gestión
RedAlert / N13V es relevante porque el patrón consiste en acceso a capas servidor o hipervisor, cifrado de archivos Linux/ESXi e impresión de publicación. Este perfil está escrito para ayudar a los visitantes a comprender rápidamente qué pasos de ataque pueden detectar o bloquear.
El valor está en la traducción a defensa: qué acceso se utiliza, qué datos se buscan, qué herramientas o artefactos son notados y que reparar derivados de riesgo surgen.
En grupos menos documentados, la confianza es menor y las reclamaciones se tratan como OSINT. En los grupos históricos el valor está en las lecciones para la continuidad y recuperación.
Grupo y desarrollo
Linux /ESXi cargas de pago, notas de rescate, archivos VM cifrados,SSH /hipervisorlogs y reclamaciones de fuga de datos son artefactos básicos.
Un perfil de ransomware no solo necesita ser actualizado para ser valioso. Grupos históricos muestran qué debilidades son usadas más tarde por otros actores.
Cuando un nombre se conoce principalmente a través de los sitios de alimentación o fuga, el pesaje de fuentes debe permanecer visible. Una reclamación es una señal, no evidencia técnica completa.
Patrón de ataque en casos públicos
Las víctimas son vulnerables cuando la gestión de virtualización y las copias de seguridad no están separadas.
Las fases de renombre están por delante del cifrado o publicación: acceso remoto, uso credencial, descubrimiento, archivo, transferencia de datos y utilización de herramientas de gestión.
Vincular cada reclamación a registros y pistas de sistema. Sin contexto de cuenta, procesar datos de árbol y red, la atribución sigue siendo incierta.
COI y artefactos conocidos
MonitorSSH , vCenter/ESXi , acceso a la tienda de datos,VM- acciones de alto y desconocidoLinux - Binaries.
DuroIOC pistils debe ser enriquecido por incidente. Patrones conductuales como el acceso a archivos de gran tamaño,RDP ,PowerShell ,RMM , las paradas de servicio y la exfiltración siguen siendo utilizables más largo que los viejos hashes.
Guardar notas de rescate, extensiones, hashes, líneas de comandos, rutas de estadificación, destinos externos y referencias fuente por incidente.
Patrón y lecciones de las víctimas
Gestión de hipervisores de separación, parche ESXi, limitación de las redes de gestión y prueba VM- recuperación.
Las víctimas aprenden sobre puntos de presión en particular: servicios públicos, datos sensibles, cadenas de suministro, capas de servidores o dependencia de recuperación.
Use patrones de sector y víctimas como lista de verificación para su propio entorno. No están destinados a ser una colección de nombres sueltos.
lógica de detección práctica
https://www.bleepingcomputer.com/news/security/new-redalert-ransomware-targets-windows-linux-vmware-esxi-servers/
Crear detecciones en cadena: inicio de sesión sospechoso, descubrimiento, formación de archivos, volumen outbound, paradas de servicio y archivo masivo escribe juntos dan una imagen mucho más fuerte.
También trae copias de seguridad, hipervisores, NAS, almacenamiento en la nube y SaaS. Mucha extorsión comienza con datos o gestión, no el dispositivo de cifrado.
Prioridades de endurecimiento concreto
No definida
Fuerza MFA, límite directo RDP/VPN, utilizar hosts de salto, servidores de segmento y proteger cuentas privilegiadas.
Cree copias de seguridad inmutables/offline siempre que sea posible y pruebe recuperación cuando el dominio primario no puede ser confiado.
Identidad, nombres y atribución
Una evaluación fiable de RedAlert / N13V comienza con una identificación precisa. El expediente local recoge los siguientes nombres o alias: RedAlert ransomware, N13V. Un alias facilita la búsqueda, pero no demuestra que distintas operaciones compartan responsables. Los nombres parecidos, logotipos reutilizados y textos de extorsión similares no bastan. Conserva la grafía original y distingue entre quien publica, la familia de malware y el supuesto ejecutor de la intrusión. Pueden ser personas diferentes. Un incidente no debe atribuirse únicamente por la semejanza de un nombre de archivo. Toda relación propuesta necesita una fuente propia, verificable y fechada. Las nuevas pruebas deben permitir corregir la atribución anterior.
Cronología e interpretación de las fechas
La fecha de registro disponible para RedAlert / N13V es 2022-07-14; la instantánea de metadatos corresponde a 2026-09-15. Estas fechas describen el registro, no el comienzo demostrado de la actividad criminal. El grupo podría haber actuado antes y una publicación podría referirse a un incidente antiguo. Separa la intrusión supuesta, el acceso a datos, el descubrimiento por la víctima, la publicación del extorsionador y la observación del servicio de seguimiento. La fecha de revisión del perfil tiene otro significado. No conviertas implícitamente unos hitos en otros. Cuando las fuentes discrepen, conserva ambas observaciones y su procedencia hasta disponer de pruebas que permitan una cronología más precisa.
Víctimas reivindicadas y selección de objetivos
El panel de víctimas de RedAlert / N13V muestra hasta cinco organizaciones distintas del historial guardado. Es una muestra, no un censo completo de incidentes. Las listas públicas pueden omitir víctimas, repetir información antigua o exagerar el acceso obtenido. Varias organizaciones del mismo país o sector no demuestran por sí solas una campaña dirigida. Compara especialmente proveedores compartidos, accesos remotos, servicios expuestos y flujos sensibles con los de tu organización. Una reivindicación sobre un proveedor justifica verificarla mediante contactos conocidos, pero no prueba que sus clientes estén afectados. Mantén claramente separadas las declaraciones confirmadas y las afirmaciones de los extorsionadores.
Indicadores de compromiso (IOC)
Los indicadores son observaciones históricas, no pruebas de una infección actual. Verifica la fuente, la antigüedad y el contexto antes de detectar o bloquear; las herramientas legítimas de administración pueden producir falsos positivos.
| Tipo | Valor | Fuente | Contexto |
|---|---|---|---|
| behavior | Het patroon bestaat uit toegang tot server- of hypervisorlagen, encryptie van Linux/ESXi-bestanden en publicatiedruk. | profile references | Patrón defensivo primario. |
| artifact | ransom notes, leak-site claims, data staging and exfiltration artefacts | case-dependent | Grabar valores concretos por incidente. |
Fuentes
- Bronprofiel voor RedAlert / N13V
- MITRE ATT&CK — Valid Accounts (defensive context)
- MITRE ATT&CK — External Remote Services (defensive context)
- MITRE ATT&CK — Exfiltration Over Web Service (defensive context)
- MITRE ATT&CK — Inhibit System Recovery (defensive context)
- Ransomware.live — RedAlert / N13V
Evidencia y limitaciones
La atribución describe la evaluación de la fuente, no una identidad verificada. Una publicación en un sitio de filtraciones no demuestra por sí sola cifrado, robo de datos, una vulnerabilidad concreta ni una relación de afiliación. La información ausente se señala explícitamente.