Sobre y candado sobre un escritorio claro, imagen destacada sobre el arresto del negociador de ransomware

FBI arrestó a un negociador de ransomware: qué revisar en tu plan de incidentes

octubre 23, 2026 Alfonso Moreno | Sysadmin Senior 14 Visitas 17 min de lectura

Hay un tipo de trabajo que casi nadie del lado defensivo quiere mencionar en voz alta, pero que ocurre en casi todas las empresas grandes que han tenido un incidente serio: alguien, fuera de tu organización, habla con el atacante por ti. Negocia el rescate, compra tiempo, pide que te devuelvan las llaves a cambio de silencio. Hasta hace poco eso se despachaba como un servicio más de respuesta a incidentes, facturado por tu aseguradora de ciberseguros y sin casi ninguna supervisión legal sobre la mesa.

El 8 de octubre de 2026 el FBI detenía en Pensilvania a un ejecutivo canadiense de ese negocio. Edward Dubrovsky, de 54 años, aparece en los registros judiciales con el apellido escrito como “Dobrovsky”, fue acusado de conspiración para amenazar la confidencialidad de información con intención de extorsionar, y de conspiración para cometer extorsión bajo la Ley Hobbs. El expediente central está sellado, así que muchos detalles todavía no son públicos. Pero lo que ya se sabe es suficiente para cambiar una conversación que hasta hace poco nadie estaba teniendo: si hay un tercero hablando con el criminal por ti, quién responde si ese tercero cruza la línea.

Esto no es una nota de color sobre ciberseguridad. Es el punto donde tu plan de respuesta a incidentes deja de ser un documento técnico y se vuelve un documento con exposición legal. Y eso, para un sysadmin, es un problema que se puede verificar con comandos.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 a 45 minutos de revisión documental, más los comandos de inventario que aparecen abajo.
Requisitos: acceso root o sudo en tus servidores, y el contrato de tu firma de respuesta a incidentes o tu póliza de ciberseguros.
Resultado: un inventario verificable de quién habla por tu empresa durante un incidente, qué accesos tienen los terceros y qué registros necesitas preservar.
Troubleshooting: si tu organización nunca contrató un negociador, el ejercicio sigue aplicando. Casi todas las pólizas de ciberseguros incluyen una red de proveedores que puede actuar en tu nombre sin que tú lo sepas.

Qué pasó exactamente, con lo verificable hasta ahora

El arresto ocurrió el jueves 8 de octubre de 2026 en el estado de Pensilvania, y el caso fue presentado ante un juez de distrito el 9 de octubre. Una notificación de ese día mueve el caso al Distrito Este de Texas, que según fuentes cercanas a la investigación es ahora el centro de la investigación del FBI sobre ShinyHunters. Ese traslado importa por una razón concreta: el Distrito Este de Texas es donde se concentra la investigación del FBI sobre ShinyHunters, no donde ocurrió la brecha. La del portal de empleo del FBI se explotó en otro lado, contra una plataforma operada por un contratista de Accenture que nunca aplicó el parche de Oracle de junio.

Dubrovsky no es el primero. En septiembre, la policía holandesa arrestó a Pepijn van der Stap en el marco de la investigación sobre ShinyHunters. Pocos días después, Reuters informó que un adolescente identificado como Saif Al-din Khader, conocido dentro del grupo como “Rey”, había sido detenido en Jordania y estaba colaborando con los investigadores del FBI. Ese alias es relevante porque “Rey” fue quien tomó el control del grupo tras la detención de Van der Stap y que colaboró con el FBI mediante filtraciones sobre los datos robados al propio bureau.

Elemento	Qué se sabe verificable	Fuente
Fecha del arresto	8 de octubre de 2026	Registros judiciales en CourtListener
Lugar	Pensilvania, Estados Unidos	Reuters, CyberScoop
Acusación formal	Conspiración para amenazar confidencialidad con fines de extorsión, que Krebs transcribe como “interference with commerce by threats”, y conspiración para cometer extorsión bajo la Ley Hobbs	Krebs on Security (primer cargo), CyberScoop (segundo cargo)
Empresa vinculada	CYPFER, en Canadá, como director gerente hasta que renunció en diciembre de 2025	Declaración de CYPFER obtenida por Krebs on Security
Segundo vínculo	CyberSteward, otra firma de seguridad canadiense; Krebs no menciona sede ni ciudad	Krebs on Security
Traslado del caso	Distrito Este de Texas, presentación del 9 de octubre	Politico, docket de CourtListener
Contexto de operación	Conferencia Cyber Risk Summit en Filadelfia, del 5 al 7 de octubre	Krebs on Security

Hay un detalle en la historia que merece atención aparte. El titular original decía “cofundador”, y durante unas horas circuló esa versión. Después, un representante de CYPFER le dijo a Krebs on Security que Dubrovsky nunca fue fundador ni cofundador sino director gerente, y que renunció en diciembre de 2025. CyberScoop reporta lo mismo, con una diferencia adicional: el perfil de LinkedIn del acusado se había presentado como COO y ex-fundador. Esa discrepancia entre lo que declara un perfil profesional y lo que dice la empresa es en sí misma una lección: en un mercado donde la reputación profesional es el activo principal, ese activo se puede inflar desde el propio perfil.

Por qué a un sysadmin le importa el negocio de la negociación

El punto no es si Dubrovsky cometió los cargos. Los cargos son acusaciones, y hasta ahora el FBI se negó a comentar y el expediente está sellado. El punto es que este caso convierte en algo judicialmente discutible una práctica que hasta hace poco se daba por sentado dentro del ecosistema de respuesta a incidentes.

La línea que la industria siempre continuaba argumentando es esta: comunicarse con un criminal no es lo mismo que negociar un pago, y negociar no es un compromiso de pagar. Es una distinción real y muy usada. Durante una contención, un equipo de respuesta puede necesitar hablar con el atacante para ganar tiempo, entender el alcance, confirmar qué datos se llevaron o comprar horas mientras termina el aislamiento. Eso es respuesta a incidentes. Lo que se está cruzando es otra cosa: intermediarios que coordinan contacto permanente con la banda, que reciben un porcentaje de lo pagado, o que abren canales de comunicación con grupos de extorsionadores para activar la negociación. La frontera entre asesorar a la víctima y facilitar un delito federal siempre fue delgada. Este caso le pone una luz que ninguna póliza de seguro había puesto antes.

El segundo ángulo, más ignorado, es el del proveedor externo con acceso a tu entorno. Una firma de negociación o respuesta a incidentes no solo habla con el atacante: necesita ver tu arquitectura, tus logs, tu identidad. Y hay una tendencia clara en la industria: en lugar de que tú descanses, ellos operan. Eso significa que alguien externo tiene credenciales en tu tenant de nube, en tu directorio activo y probablemente en tus respaldos. Si esa persona termina siendo del mismo perfil que las personas acusadas en este caso, tu posición se debilita muchísimo.

El tercero es más simple y más incómodo: la cobertura de ciberseguros. Buena parte del mercado de respuesta a ransomware se sostiene sobre pólizas que, en muchos casos, despliegan una red de proveedores preferidos. Es probable que tu póliza tenga una lista de firmas de negociación preaprobadas, y que nunca hayas leído esa sección. Es el documento más importante que tienes para tomar decisiones durante una crisis, y casi nadie lo abre hasta que ya hay un atacante en pantalla.

Los tres cambios concretos en tu operación

El playbook de incidentes se vuelve un documento legal. Quien redactó los guiones de respuesta debería revisarlos con un abogado que no sea de tecnología. Qué puede decir tu empresa, qué puede ofrecer, qué no se puede prometer y quién autoriza cada mensaje. Es una tarea de una tarde.
La cadena de custodia de tus registros deja de ser opcional. Si hay una investigación penal de por medio, y ahora hay varias simultáneas, tus logs de acceso, de cambios y de red son evidencia. Perderlos por rotación automática es perder evidencia.
El inventario de accesos de terceros es prioridad de este mes. No en un trimestre. Este mes.

Inventariar quién habla por tu empresa y quién tiene acceso

Este es el ejercicio que le corresponde a un sysadmin, y se puede hacer hoy con herramientas que ya tienes. La idea es simple: en un incidente grave, la comunicación con el atacante rara vez la hace tu equipo. Necesitas saber quién más está en esa mesa y qué ve.

# 1. Cuentas de servicio con shell interactivo.
#    Un usuario de sistema con bash habilitado es una credencial
#    que alguien puede usar para entrar sin dejar rastro evidente.
awk -F: '$3 >= 1000 && $7 !~ /(nologin|false)$/ {print $1"  uid="$3"  shell="$7}' /etc/passwd

Qué hace este filtro: lista usuarios con UID igual o superior a 1000 que todavía tienen un shell interactivo. Revísalo contra tu inventario de cuentas conocidas. Cada línea que no reconozcas es una cuenta con acceso potencial que alguien debe explicar.

# 2. Secretos expuestos en el entorno de procesos que corren ahora.
#    Un token de API que alguien exportó y olvidó queda vivo
#    mientras el proceso exista.
for p in $(ls /proc | grep -E '^[0-9]+$'); do tr '' 'n' < /proc/$p/environ 2>/dev/null | grep -E '^(AWS_|AZURE_|GOOGLE_|.*_API_KEY|.*_TOKEN|.*_SECRET)=' | sed "s/^/PID $p  /"; done | sort -u | head -40

Esto lista secretos que viven en el entorno de procesos activos. En un servidor de producción normal no debería haber casi nada. Si hay algo, ya sabes qué proceso lo puso y desde cuándo. Es un comando de solo lectura y se puede correr sin downtime.

# 3. Quién tiene sudo, y desde cuándo.
sudo getent group sudo wheel admin 2>/dev/null
sudo visudo -c 2>&dev/null | tail -5
# 4. Último inicio de sesión de cada cuenta con shell.
lastlog | head -25

Verificar el parche que faltaba en el incidente del FBI

El incidente del FBI no empezó con un negoziador ni con un teléfono clonado. Empezó con un parche de Oracle PeopleSoft que no se aplicó. La vulnerabilidad, la CVE-2026-35273, está en el componente Environment Management Hub. Oracle publicó su parche el 10 de junio de 2026, y el FBI no lo aplicó a tiempo. Cuando ShinyHunters entró, el portal de empleo del FBI cedió datos personales de miles de agentes y solicitantes: nombres, direcciones, teléfonos y, según los propios atacantes, entre 2 y 3 terabytes.

Lo que hace esta historia más útil que un reporte de patching genérico es que hay un detalle en la mitigación que falló. Oracle recomendó a quien no pudiera parchear de inmediato bloquear el componente vulnerable en el perímetro con una regla de firewall. Mandiant documentó después que ShinyHunters encontró una forma de pasar esa regla con una sola sustitución de caracteres en la petición web: la regla de borde comparaba la URL sin normalizar y no veía lo mismo que veía el servidor. Parchar funcionó. La regla sola, no.

# Verifica si tu capa de borde normaliza ANTES de aplicar la regla.
# El bypass documentado consistía en URL-encoding un carácter de la ruta:
# la regla comparaba "%50SEMHUB" y el servidor decodificaba "PSEMHUB".
# Si el codificado y el plano devuelven ambos 403, tu borde está bloqueando
# las dos formas y la regla aguanta.
curl -s -o /dev/null -w 'codificado: %{http_code}n' "https://tu-dominio/%50SEMHUB/hub"
curl -s -o /dev/null -w 'plano:       %{http_code}n' "https://tu-dominio/PSEMHUB/hub"
# Si el codificado devuelve 200 y el plano 403, tu regla fue EVADIDA: el WAF
# bloquea /PSEMHUB pero deja pasar /%50SEMHUB, que es exactamente el bypass
# de ShinyHunters. Ese resultado no se celebra: la regla necesita acción.

Este fragmento es pequeño a propósito. La lección es general y aplica a cualquier WAF, a cualquier ingress controller y a cualquier regla escrita contra una URL literal: normaliza, decodifica y compara de forma canónica, o un carácter de diferencia te la deja pasar. Vale igual para un nginx, un HAProxy, un Fortigate o una regla en el borde de un proveedor.

# Inventario de parches pendientes en tu flota, por familia de sistema.
# Ubuntu y Debian: solo el canal de seguridad.
apt-get update -qq && apt-get --just-print upgrade | grep -i security
# RHEL, Fedora y openSUSE: actualizaciones de seguridad disponibles.
dnf updateinfo list security --available | head -40
# Solo vulnerabilidades con severidad alta, para triage rápido.
dnf updateinfo list --cves --severity Important --available

El orden importa cuando tienes una ventana de mantenimiento corta. Los tres comandos son de solo lectura y te dan la lista real de lo que falta, no un porcentaje de cumplimiento comprado.

El paso 4 es el que más hallazgos produce en auditorías reales. Cuentas que nunca han iniciado sesión pero tienen shell válido y permisos elevados son candidatas a limpiar. Revísalas una por una contra tu inventario.

Preservar evidencia cuando aparece una investigación

Con varios casos abiertos en paralelo sobre el mismo grupo de actores, tus registros dejaron de ser solo registros operativos. Ahora son evidencia potencial. Eso cambia dos cosas concretas: cuánto tiempo los retienes y cómo los sellas.

# Retención mínima de 12 meses en journald, sobrescribiendo el valor por defecto.
# SystemMaxUse=4G es el tope de espacio, 4 GB, no el objetivo de retención.
# El límite de tiempo real lo impone MaxRetentionSec.
sudo mkdir -p /etc/systemd/journald.conf.d
cat <<EOF | sudo tee /etc/systemd/journald.conf.d/retention.conf
[Journal]
SystemMaxUse=4G
MaxRetentionSec=31536000
EOF
sudo systemctl restart systemd-journald
journalctl --disk-usage

El valor que importa aquí no es el tamaño en gigabytes sino MaxRetentionSec. Sin él, journald rota por tamaño y el archivo más antiguo desaparece sin aviso, que es exactamente lo que no quieres cuando hay una subpoena esperando.

# Sellar un export con hash para que nadie pueda alterarlo después.
sudo journalctl --since "2026-10-01" --until "2026-10-22" --no-pager 
  > /var/forensics/journal_oct_2026.log
sha256sum /var/forensics/journal_oct_2026.log | tee /var/forensics/journal_oct_2026.log.sha256
# Verificar integridad más tarde.
sha256sum -c /var/forensics/journal_oct_2026.log.sha256

Guarda el archivo .sha256 fuera del servidor, o en un bucket con versionado. Si el hash y el archivo están en el mismo disco, un atacante con acceso root puede regenerar ambos y la cadena de custodia no vale nada.

El vector que ShinyHunters sí usa todos los días

Conviene separar dos cosas. El ingreso al portal de empleo del FBI fue un exploit de software sin parchar. Ese es el titular. Pero según el propio FBI, el grupo ha extorsionado más de 70 millones de dólares este año, y esa cifra no sale de exploits: sale de phishing y credenciales robadas contra cuentas corporativas en empresas de software como servicio.

El método clásico de ShinyHunters no necesita una vulnerabilidad de cero días. Necesita que alguien haga clic en un enlace. De ahí el patrón: credenciales convergentes, apoyo en herramientas de acceso remoto commodity, y salida de datos en trozos pequeños para no disparar los umbrales de DLP.

# Herramientas de acceso remoto y exfiltración que aparecen
# en las intrusiones documentadas de este grupo.
sudo find / -xdev 2>/dev/null | grep -iE 'screenconnect|screenovate|anydesk|rclone'
# Procesos activos sospechosos de preparar salida de datos.
ps aux | grep -iE 'rclone|onioncloud|mega|ngrok|teamviewer' | grep -v grep

Rclone merece atención aparte porque es legítimo: hay administradores que lo usan para respaldos fuera de sitio. Precisamente por eso es difícil de detectar. Un rclone legítimo tiene un cron configurado; uno malicioso tiene un servicio que corre cada pocas horas.

# Transferencias salientes pequeñas y repetitivas: el patrón de
# exfiltración en trozos que no dispara alertas por volumen.
# En el formato combined de nginx, $1 es la IP y $10 el tamaño en bytes de
# la respuesta; $NF es el User-Agent, no el tamaño.
sudo awk '{print $1, $10}' /var/log/nginx/access.log | awk '$2 > 10000 && $2 < 500000 {print $1}' | sort | uniq -c | sort -rn | head -20

Este comando no mide el volumen total, sino el tamaño de cada respuesta. En el formato combined de nginx el primer campo es la IP y el décimo ($10) es el tamaño en bytes de la respuesta; el último campo ($NF) es el User-Agent, y por eso el awk pide $10 de forma explícita en vez de $NF. Una IP que descarga cientos de archivos de tamaño medio, de forma repetida y sostenida, es más sospechosa que una que descarga un archivo grande una vez. Esa es la diferencia entre exfiltración que se nota y exfiltración que pasa desapercibida.

Vale la pena invertir tiempo en esto

Mi opinión corta: sí, pero no por el arresto. El arresto es la noticia que va más allá de hoy. Lo que justifica el trabajo es que este caso destapa tres prácticas que nunca se escribieron en ningún documento y que de pronto tienen consecuencias Judiciales.

La primera es que la negociación de rescate opera en un vacío legal real. En la mayoría de las jurisdicciones es legal siempre que el cliente sea la víctima del incidente y no el extorsionador, y no existe ningún registro ni licencia para la actividad. Eso significa que la responsabilidad individual es casi completamente unexplored. Un arresto es una señal, no una solución: probablemente verás más servicios mudarse de país o cambiar de marca, mientras las herramientas que los hacen rentables siguen escalando.

La segunda es que tu contrato de respuesta a incidentes probablemente nunca pasó por un abogado. La tendencia de la industria a que el proveedor opere directamente en tu entorno multiplica el riesgo, y a la vez reduce tu visibilidad sobre qué se hizo en tu nombre.

La tercera es que ShinyHunters sigue usando las mismas tácticas de siempre contra la mayoría de sus víctimas: phishing, credenciales robadas y salida de datos en trozos. El FBI no cayó por una vulnerabilidad recién explotada de cero días; cayó por un parche de junio que nadie aplicó. Ese sigue siendo el riesgo más probable para tu servidor, y no tiene nada que ver con negociadores.

Si tuviera que priorizar tres tareas para esta semana, serían: leer la sección de proveedores de tu póliza de ciberseguros, correr el inventario de accesos de terceros que está más arriba, y confirmar que el parche del 10 de junio está aplicado en cualquier Oracle PeopleSoft que tengas. Lo demás puede esperar al próximo incidente.

Preguntas frecuentes

¿Puedo usar un negociador de ransomware si soy la víctima?

En principio sí, y es práctica común con cobertura de ciberseguros. La línea se vuelve borrosa cuando el intermediario coordina contacto permanente con el grupo, recibe un porcentaje de lo pagado o negocia por fuera de tu autorización. El caso Dubrovsky trata precisamente sobre esa frontera, y todavía está en fase de juicio, así que aún no existe un criterio firme sobre dónde cae.

¿Cómo sé si mi póliza de ciberseguros tiene un negociador asignado?

Busca las secciones de respuesta a incidentes y de proveedores preferidos en tu póliza. Casi todas incluyen una red de firmas que la aseguradora activa por ti cuando hay un incidente. Si tu póliza no dice quién habla por ti, esa es una pregunta que deberías poder responder hoy, no durante la crisis.

¿El bloqueo en el WAF contra la CVE-2026-35273 sirve sin aplicar el parche?

No es confiable. Mandiant documentó que una sola sustitución de caracteres en la URL hizo que la regla de borde no detectara el ataque mientras el servidor sí lo procesaba. El parche de Oracle del 10 de junio de 2026 es la mitigación real. La regla de firewall sirve como medida temporal mientras aplicas el parche, no como reemplazo.

¿Cuánto tiempo debo conservar mis logs?

Como mínimo, el periodo de detección y respuesta más un margen amplio para una investigación posterior. Configura MaxRetentionSec en journald para que la rotación sea por tiempo y no solo por tamaño. Si hay una investigación de por medio, sella el export con hash y copia fuera del servidor: la evidencia pierde valor si una tarea automática puede sobrescribirla.

¿Tener rclone en mi servidor es una señal de compromiso?

No necesariamente. Rclone es una herramienta legítima usada para respaldos fuera de sitio. La diferencia está en cómo se ejecuta: un rclone legítimo tiene un cron documentado y un destino conocido; uno malicioso corre como servicio cada pocas horas hacia un destino que no reconoces. Revisa las tareas programadas y los destinos antes de asumir lo peor.