- Un grupo de hackers ucranianos colaboró con la inteligencia militar para paralizar la infraestructura de TI de Gaskar Integration, un importante fabricante ruso de drones
- Se eliminaron más de 47 TB de datos críticos y materiales de respaldo, lo que interrumpió operaciones clave del negocio
- Los sistemas internos de la fábrica, junto con los programas de contabilidad y producción, quedaron completamente inoperables
- Incluso se bloquearon las puertas de acceso de la planta de producción, por lo que los empleados tuvieron que entrar y salir por las salidas de emergencia
- Los datos extraídos incluyen información personal de empleados y documentación técnica de drones, y fueron entregados al Ministerio de Defensa de Ucrania
Contenido principal
- Activistas cibernéticos ucranianos, en cooperación con la inteligencia militar, atacaron la red y la infraestructura de servidores de Gaskar Integration, uno de los mayores fabricantes que suministran drones al ejército ruso
- Como resultado del ataque, fueron destruidos más de 47 TB de información técnica y 10 TB de materiales de respaldo; esos datos también incluían indicios de una estrecha cooperación entre Rusia y China
- Debido al hackeo, quedaron paralizados internet, los programas de producción, los programas contables y todos los sistemas internos de la empresa, por lo que el centro de investigación y desarrollo de Gaskar tampoco pudo operar con normalidad
- Todas las puertas de acceso dentro de las plantas de producción de drones quedaron bloqueadas, obligando a los empleados a salir y desplazarse por las salidas de emergencia
- La información obtenida incluye cuestionarios confidenciales de empleados y documentos técnicos sobre la producción de drones, por lo que fue entregada a expertos bajo el Ministerio de Defensa de Ucrania
Contexto adicional
- Expertos cibernéticos de la inteligencia militar ya habían desactivado anteriormente el sitio web de los ferrocarriles rusos mediante un fuerte ataque
- En el pasado también llevaron a cabo con éxito un ataque contra la empresa rusa Regiontransservice, logrando interrumpir todos sus servicios
1 comentarios
Opiniones en Hacker News
Yo manejo un pequeño lab en casa, con unas 30 servicios
Un día cambié el disco principal y reconstruí todo desde cero usando los respaldos; en una hora ya estaba de vuelta
Pero después me pasé una semana ajustando cosas por todos lados y tratando de recordar por qué había configurado ciertas partes así
Y eso era solo un lab sencillo basado en Docker administrado por una sola persona, además yo trabajo en IT
Pero recuperar desde cero toda una infraestructura que varias personas mantuvieron durante años es una tarea brutal
Cuando un hospital cercano sufrió ransomware, ayudé como voluntario en la recuperación; los dos empleados de IT de ahí no tenían idea de qué hacer y el soporte oficial estuvo muy por debajo de lo esperado
También ayudé en incidentes de ransomware en grandes empresas, y gran parte del esfuerzo era intentar recordar por qué los sistemas estaban armados de esa manera
Aunque hubiera documentación y pruebas, en la práctica uno se topa con la realidad
Una vez la policía allanó nuestra casa y se llevó equipo por valor de 10 mil dólares: desktops, laptops, NAS, discos duros y más
Como en mi trabajo anterior yo era responsable de respaldos y planes de recuperación ante desastres, sí estaba preparado
En uno o dos días recuperé casi todo, con una pérdida de datos de unos dos días; por suerte era uso doméstico, así que no fue crítico
Después de pasar por eso hice varias mejoras estructurales, así que si vuelve a ocurrir el daño será menor
(Y ocho meses después la policía concluyó que yo era inocente y ordenó devolver mi equipo, pero mis hijos quedaron traumatizados)
Esta es exactamente la razón por la que la documentación es tan importante, y también aplica a nivel de arquitectura de software
Después de unos meses es muy fácil olvidar por qué tomé ciertas decisiones
Por ejemplo, "por qué decidimos usar Kysely como herramienta ORM/SQL", "por qué usamos Deno/Bun", "por qué la estructura de carpetas es por funcionalidades", "por qué se hizo un fork de cierta librería y cómo se mantiene", "por qué se eligió AWS/GCP/Azure/Docker", "por qué se escogió cierta distribución de Kubernetes", "por qué empezó este proyecto y cuáles son sus objetivos", etc.
Por eso hago una sección
# Decisionsen el README.md para documentarloGracias a eso me libero de estar dudando de mis propias decisiones y de rebuscar eternamente entre documentos
Los mainframes de los 90 eran tan estables y tan bien redundados que a veces pasaban más de 10 años sin reiniciarse; incluso se actualizaba el kernel sin interrupciones
Pero en una empresa hubo un apagón, también falló el generador de respaldo, y cuando volvió la energía tardaron meses en averiguar qué estaba haciendo realmente esa máquina y cómo se suponía que debía arrancar
Después de eso, la mayoría de las empresas empezó a reiniciar deliberadamente sus mainframes cada seis meses para probar el arranque
En las prácticas modernas de IT casi no se toma en cuenta la recuperación ante desastres
Incluso en organizaciones que sí hacen respaldos rigurosos, es raro que realmente prueben la restauración
Como falta personal, solo se va construyendo algo a toda velocidad
Diseñar una infraestructura que pueda reconstituirse fácilmente requiere el doble de esfuerzo que simplemente instalarla
Me da curiosidad la historia del voluntariado para recuperar el hospital tras el ransomware
En IT de salud suelen manejar los accesos con muchísimo cuidado; antes era imposible entrar a sistemas sin capacitación PHI o revisión de antecedentes, así que me pregunto si, por tratarse de una emergencia, hicieron un onboarding temporal acelerado o si la ayuda voluntaria llegó por contactos dentro del hospital
Trabajo en una empresa alemana
La gestión de producción está operando con planes impresos desde Excel hechos hace tres meses
Falló una migración del sistema ERP y nadie sabe cómo resolverlo
El área de producción está ocultando ese hecho y ni siquiera se lo dice al equipo de ingeniería
Esto probablemente seguirá así durante años; es un sistema del que viven los consultores
Demuestra que la infraestructura IT no es indispensable para manufactura; se puede vivir sin ella, solo es algo bueno de tener
A finales de los 90 e inicios de los 2000, el Ministerio de Defensa de Dinamarca intentó introducir un nuevo sistema de compras llamado DeMars, hecho con SAP
Un amigo mío que trabajaba en adquisiciones hizo pedidos gigantescos del material que tenía a su cargo justo antes de que entrara DeMars, y hasta lo llamaron por sospechas de fraude
Lo hizo porque desconfiaba mucho de DeMars y pensó que era importante mantener inventario
Y efectivamente, cuando DeMars entró en operación, el sistema de compras quedó prácticamente paralizado durante un año
Al final, solo los artículos de los que él era responsable mantuvieron stock durante todo el periodo de implantación del nuevo sistema
Trabajé como desarrollador de firmware en una empresa manufacturera a fines de los 90
Todavía era la época en que todo se registraba en papel
La empresa logró implementar con éxito un ERP basado en Oracle y todos estaban felices, pero seis meses después alguien golpeó con un montacargas la pared de la sala de máquinas, se incendió el UPS y tres racks completos, incluido el servidor Oracle, quedaron destruidos
Como nadie confiaba del todo en el sistema y todavía seguían registrando todo en papel, seguíamos trabajando con papel más reportes en Excel hasta que renuncié seis años después
Al final quedó demostrado que el método basado en papel resiste mejor a los montacargas
Excel es algo que muchos empleados administrativos entienden intuitivamente y pueden modificar
Si ese tipo de accesibilidad se incorporara a la mayor parte de la infraestructura IT, probablemente sería mucho más práctico
Por otro lado, cuando la automatización IT ya está totalmente integrada en producción y ya no queda gente acostumbrada al método manual anterior, puede ser muy difícil volver a operar manualmente
Aunque depende de la complejidad de las órdenes y del workflow
Sin software, los drones tampoco sirven de mucho
Si uno se supiera el inventario de memoria, tal vez podría armar cuadricópteros de control manual, pero sería imposible producir piezas impresas en 3D, lograr vuelo estable, operación autónoma, vigilancia y otros usos avanzados
Incluso el control remoto sería complicado
La ciberguerra en Ucrania está llegando a un nuevo nivel, ya va más allá de simples ciberataques
Los drones, como en el caso de la planta rusa atacada esta vez, han sido clave para cambiar la dinámica de esta guerra
Los drones han traído innovaciones en reconocimiento, interferencia e interceptación de municiones
Tienen un gran poder destructivo en relación con sus materiales, y con los avances en reconocimiento visual algunos siguen funcionando incluso con interferencia de señal
Está ocurriendo algo que parece sacado de una película de espionaje
Ucrania está demostrando ser experta en guerra asimétrica
Con la destrucción de bombarderos de largo alcance y la parálisis de centros de producción de drones, está golpeando la fuerza principal de Rusia
No sé cómo terminará la guerra, pero está claro que la resistencia de Ucrania continuará
En la novela Ministry of the Future, los drones avanzan tanto que la guerra tradicional deja de tener sentido en un mundo donde nadie está realmente a salvo
Incluso grupos pequeños podrían asesinar a cualquiera en cualquier parte del mundo
La idea es interesante, pero la historia es floja, así que no la recomendaría mucho como libro
Sobre los “drones que siguen operando pese a la interferencia electrónica”, hoy en día también existen drones controlados por cable de fibra óptica en lugar de señales electromagnéticas; es una realidad todavía más aterradora
Queda por ver si la importancia que tienen los drones en esta guerra se trasladará también a otros conflictos en el futuro
La situación especial de Rusia, avanzando poco a poco mientras acepta pérdidas humanas enormes, está aumentando el valor de los drones FPV
La mayoría de los países no toleraría ese nivel de pérdidas, así que no creo que esta forma de guerra se vuelva el estándar
Puede que los drones a reacción baratos de largo alcance terminen teniendo un papel más importante
La información del artículo mezcla muchas suposiciones
Solo estamos escuchando una versión y puede estar exagerada por su valor propagandístico
Lo normal es que haya buen control de versiones y que cada desarrollador tenga copias locales del código y de los archivos CAD
Puede que se hayan perdido correos y archivos de oficina, pero quizá eso no sea una pérdida crítica
El sitio web sigue funcionando con normalidad
Además, esta empresa atacada no es especialmente conocida ni siquiera dentro de la comunidad de drones, así que no parece algo como una gran paralización de producción de modelos importantes
Cuesta creer que no conozcan prácticas básicas como el control de versiones; incluso da la impresión de que el estilo del comentario lo escribió ChatGPT
Trabajo en una empresa mediana en Suiza
Estamos desarrollando un ERP interno y el stack es una auténtica pesadilla
Nosotros mismos lo llamamos “seguridad mediante el caos”
Aunque un atacante logre entrar, no podrá salir
Aunque se destruya el 90% del código, el servicio no se verá afectado, porque el 95% ya es código inútil
Tengo experiencia desarrollando sistemas MRP para grandes empresas, así que me da curiosidad ver cómo termina esto
Yo normalmente hasta agrego una capa de autenticación por claves basada en hash OTP sobre las prácticas recomendadas de seguridad y recuperación ante desastres
Pensaba que yo era el extremo, pero este sistema ya parece un escenario de supervivencia del fin del mundo
Da la impresión de ser un tipo de resiliencia surgida por evolución
Da risa porque parece un muro ICE del mundo real
Da miedo, pero también tiene algo admirable
La mayoría de las empresas no se prepara de forma clara para un escenario en el que prácticamente todos los repositorios de datos internos queden completamente borrados y haya que volver a desplegar todo desde cero
Si nunca has intentado recuperar realmente desde cero, es muy probable que haya dependencias circulares en tu cadena de despliegue
Despliegas un config pusher con Jenkins/Puppet/Ansible y, en algún momento, Jenkins mismo pasa a depender de ese config pusher, así que ya no puedes reconstruirlo todo en orden; terminas teniendo que repetir todo el historial de cambios desde el pasado
En IT hay dependencias circulares en casi todas partes
El SSO termina siendo dependencia de casi todos los sistemas, y dentro del propio SSO también aparecen bucles con la red y con la administración de otros sistemas
Arrancar completamente desde cero siempre es difícil y toma mucho tiempo
A menos que construyas una infraestructura doble totalmente separada, resolver este problema perfectamente es prácticamente imposible
Una empresa que conozco pasó por algo así hace un año
Murió el clúster principal de almacenamiento del que dependía todo
Al final recuperaron todo redeployando desde una laptop de desarrollo
Un black start (recuperación desde apagón total) es un problema dificilísimo
Incluso Facebook alguna vez tuvo que entrar a sus centros de datos perforando literalmente las cerraduras con taladro para poder restaurar servicios
Me pregunto cómo se puede recuperar algo en una situación así
Si al menos queda documentación en papel, ¿eso basta para hacer el bootstrap, o hay que asumir que incluso eso desapareció?
La construcción también sufre un problema parecido
Los productos tienen vidas útiles de más de 50 años, a veces de cientos, pero a menudo ya no se pueden abrir hoy archivos de diseño creados hace 30 años por problemas de compatibilidad de formatos
Se lleva décadas hablando de digitalización, pero al final esos viejos planos 2D —o lo que hoy llaman “papel digital”, los PDF— podrían terminar siendo lo que ayude en el futuro
El uso de papel real sigue bajando, pero por los problemas de compatibilidad de archivos uno termina pensando que el papel todavía puede resultar útil
En el título del artículo llaman a los atacantes “ciberactivistas” y en el cuerpo los llaman “ciberdelincuentes”
Me recuerda a esas figuras fronterizas de la época de los barcos de vela, como los corsarios semioficiales o las patentes de corso
En la teoría de la guerra de cuarta generación se decía que una característica clave era que se difumina la frontera entre lo civil y lo militar
Las reglas de enfrentamiento se vuelven cada vez más ambiguas
Rusia está matando civiles todos los días con drones
Esto no es una zona gris ambigua de guerra híbrida, sino simplemente gente tratando de evitar que sus vecinos mueran por drones
Parece más bien un tema de traducción
Ese sitio tiene una línea muy favorable a Ucrania, así que quizá no querían hacer ver negativamente a los hackers y usaron “cyber criminal” solo con el sentido general de “hacker”
En realidad, lo más lógico es que esto se esté haciendo de forma organizada desde el ejército ucraniano
Así que no sería correcto verlos como criminales
Es algo tipo Robin Hood
Héroes para unos, criminales para otros
Seguramente el artículo mezcla varias notas y por eso se cruzaron los términos
Ojalá hubiera una terminología aparte para hablar de bandos en ciberguerra
“Ciberactivista” suena solo a manifestante online; en vez de ese término cliché de película, estaría mejor algo como “cibersoldado” o “milicia de red”
Me dio risa por mi cuenta ver que la fecha de la foto del artículo está a un día del inicio de la época Unix
Ese sitio web es muy peculiar
El gobierno ruso lo bloquea y muestra errores TLS; incluso si lo evitas, aparece la página de “bloqueado” de Cloudflare, y solo usando VPN puedes llegar al artículo original en ruso
La página enlazada está en inglés, pero quizá el objetivo no eran los rusos locales en la versión rusa del sitio
En Rusia el tema del idioma es sensible, pero en Ucrania de hecho también se usa mucho el ruso y se publican artículos en ruso
Recomiendo de verdad usar sitios de archivo como archive.today o archive.org (Internet Archive)
Alguien también guardó hace poco este enlace archivado
Puede que no sea problema del sitio en sí, sino del bloqueo gubernamental o de algún tema del lado de CloudFlare
Cloudflare quizá está bloqueando precisamente por la causa de fondo del error TLS
Me pregunto si ambos bandos también están preocupados por el firmware de los drones
Parecería estratégicamente valioso infiltrar firmware manipulado en los drones que usa el enemigo
Es interesante, pero el riesgo es alto (sería fácil de detectar y podría arruinar toda la operación)
Al final, un enfoque más duro parece el más razonable
Normalmente el firmware de los drones se flashea justo antes de la misión
En la práctica, quizá sería más efectivo que cerrar una fábrica hacer que los drones se comporten de otra manera a escondidas (por ejemplo, atacar su propia base al momento del lanzamiento o quedar bajo control remoto)
Una táctica curiosa que he oído es infectar con un virus la tarjeta SD del dron, para que si cae en territorio enemigo y lo conectan a una computadora, esa computadora termine infectada
“Ciberactivistas ucranianos colaboran con la inteligencia militar…”
O sea, que solo recibieron una señal de servicios de inteligencia extranjeros y que no fue ciberguerra directa
Sobre la idea de que “si servicios extranjeros solo dieron una señal, entonces no fue ciberguerra directa”
Los servicios de inteligencia rusos ya están atacando directamente a países de la OTAN, así que casi no queda espacio para excusas
Entre Ucrania y Rusia ya existe una guerra desde hace años, así que en realidad no hace falta una negación plausible (deniability)
Me pregunto a qué se refiere exactamente lo de servicios de inteligencia extranjeros y, en realidad, los ataques constantes ocurren por todo el mundo, así que no hay que ser ingenuos
Señalan que en el artículo no aparece “servicios de inteligencia extranjeros”
Dice explícitamente que fue la inteligencia militar ucraniana