Hackers ucranianos destroem a infraestrutura de TI de fabricante russo de drones

• Um grupo de hackers ucranianos, em cooperação com a inteligência militar, paralisou a infraestrutura de TI da Gaskar Integration, uma das principais fabricantes russas de drones
• Mais de 47 TB de dados críticos e materiais de backup foram apagados, interrompendo operações centrais do negócio
• Os sistemas internos da fábrica, assim como os programas de contabilidade e produção, ficaram totalmente inoperantes
• Até os portões de acesso da fábrica foram bloqueados, obrigando os funcionários a usar as saídas de emergência para entrar e sair
• Os dados obtidos incluem informações pessoais de funcionários e documentos técnicos sobre drones, que foram entregues ao Ministério da Defesa da Ucrânia

---

Principais pontos

• Ativistas cibernéticos ucranianos, em cooperação com a inteligência militar, atacaram a rede e a infraestrutura de servidores da Gaskar Integration, uma das maiores fabricantes que fornecem drones ao Exército russo
• Com o ataque, foram destruídos mais de 47 TB de informações técnicas e também 10 TB de materiais de backup; esses dados incluíam indícios de cooperação estreita entre Rússia e China
• Devido à invasão, todos os sistemas da empresa — incluindo internet, programas de produção e programas de contabilidade — ficaram paralisados, e o centro de pesquisa e desenvolvimento da Gaskar também deixou de operar normalmente
• Todas as portas de acesso nas fábricas de drones foram bloqueadas, forçando os funcionários a sair e se deslocar pelas saídas de emergência
• As informações obtidas incluem questionários confidenciais de funcionários e documentos técnicos sobre a produção de drones, e foram repassadas a especialistas vinculados ao Ministério da Defesa da Ucrânia

Contexto adicional

• Especialistas cibernéticos da inteligência militar já haviam anteriormente desativado o site da ferrovia russa com um ataque de grande escala
• No passado, também realizaram com sucesso um ataque contra a russa Regiontransservice, interrompendo todos os serviços

[GN⁺]

Comentários do Hacker News

• Eu mantenho um pequeno lab em casa, com uns 30 serviços.
  Um dia troquei o disco principal e reconstruí tudo do zero usando backups; em uma hora estava tudo de volta no ar.
  Mas depois passei uma semana ajustando coisas aqui e ali e lidando até com partes em que eu já nem lembrava por que tinha configurado daquele jeito.
  Era um lab simples, baseado em Docker, administrado por uma pessoa, e eu ainda trabalho com TI.
  Mas recuperar do zero uma infraestrutura inteira que foi mantida por várias pessoas ao longo de anos é uma tarefa realmente enorme.
  Eu ajudei como voluntário na recuperação de um hospital próximo quando ele sofreu um ataque de ransomware, e os dois funcionários de TI de lá não faziam ideia do que fazer; o suporte oficial foi muito abaixo do esperado.
  Também ajudei em incidentes de ransomware em grandes empresas, e o esforço para lembrar por que os sistemas tinham sido montados daquele jeito foi imenso.
  Até havia documentação e testes, mas na prática a realidade bate forte.

  • Minha casa já foi alvo de uma batida policial, e levaram cerca de US$ 10 mil em equipamentos: desktop, laptop, NAS, discos rígidos etc.
    Como no meu emprego anterior eu era responsável por backups e planos de recuperação de desastre, eu já tinha me preparado.

    • backups espelhados no local (que a polícia não encontrou ou simplesmente deixou para trás)
    • equipamentos antigos (tenho certa tendência a colecionar, e isso também serve para situações assim)
    • múltiplos backups off-site
    • documentação da configuração
      Em um ou dois dias eu já tinha recuperado a maior parte, com perda de dados de só uns dois dias; felizmente era uso doméstico, então não foi algo crítico.
      Depois disso fiz várias melhorias estruturais, então no futuro o impacto de algo assim seria ainda menor.
      (E, oito meses depois, a polícia concluiu que eu não tinha culpa e mandou devolver meus equipamentos, mas meus filhos ficaram traumatizados.)

  • Esse é exatamente o motivo de a documentação ser tão importante, e isso também vale no nível de arquitetura de software.
    Depois de alguns meses, é muito fácil eu não lembrar mais por que tomei certas decisões.
    Por exemplo: “por que decidimos usar Kysely como ORM/ferramenta SQL”, “por que usar Deno/Bun”, “por que a estrutura de pastas é orientada por funcionalidade”, “por que fizemos fork de uma biblioteca e como ela deve ser mantida”, “por que escolhemos AWS/GCP/Azure/Docker”, “por que escolhemos essa distribuição de Kubernetes”, “por que este projeto começou / quais são seus objetivos” etc.
    Então eu criei uma seção # Decisions no README.md para documentar isso.
    Isso me libertou de ficar duvidando das minhas próprias escolhas e vasculhando documentos sem fim.

  • Nos mainframes dos anos 90, a estabilidade e a redundância eram tão boas que às vezes passavam mais de 10 anos sem reboot, com até upgrade do kernel sem downtime.
    Mas então faltou energia em uma empresa, o gerador de backup também falhou, e quando a energia voltou levaram meses para descobrir o que aquela máquina realmente fazia e como iniciar tudo de novo.
    Depois disso, a maioria das empresas passou a reiniciar deliberadamente os mainframes uma vez a cada seis meses para testar o processo de partida.

  • Nas práticas modernas de TI, recuperação de desastre quase não entra na conta.
    Mesmo organizações que fazem backup de forma rigorosa raramente testam a recuperação de verdade.
    Como falta pessoal, o foco acaba sendo só subir as coisas rapidamente.
    Projetar uma infraestrutura fácil de reconstituir exige o dobro de esforço comparado a simplesmente instalar tudo.

  • Fiquei curioso com essa história de voluntariado no ransomware do hospital.
    Em TI de saúde, os controles de acesso costumam ser extremamente rígidos; no passado, sem treinamento de PHI ou checagem de antecedentes, era impossível conseguir acesso aos sistemas. Queria saber se, por ser uma emergência, fizeram algum onboarding temporário acelerado, ou se você entrou como voluntário por meio de contatos dentro do hospital.

• Trabalho em uma empresa alemã.
  O controle de produção está operando com o planejamento de três meses atrás impresso em Excel.
  A migração do sistema ERP falhou, e ninguém sabe como resolver.
  O departamento de planejamento da produção está escondendo isso e nem avisou a engenharia.
  Parece que essa situação vai continuar por anos; é um sistema que alimenta consultores.
  Isso prova que infraestrutura de TI não é essencial para manufatura; dá para viver sem ela, é só algo bom de ter.

  • No fim dos anos 90 e começo dos anos 2000, o Ministério da Defesa da Dinamarca tentou implantar o DeMars, um novo sistema de compras feito com SAP.
    Um amigo meu que trabalhava com aquisições fez pedidos enormes do material pelo qual era responsável pouco antes da entrada do DeMars, e até foi chamado por suspeita de fraude.
    Ele fez isso porque desconfiava profundamente do DeMars e achava essencial manter estoque.
    E de fato, quando o DeMars entrou em operação, o trabalho de compras praticamente parou por um ano.
    No fim, só os itens sob responsabilidade do meu amigo continuaram em estoque durante toda a transição para o novo sistema.

  • Trabalhei como desenvolvedor de firmware em uma fabricante no fim dos anos 90.
    Ainda era a época em que tudo era registrado em papel.
    A empresa implantou com sucesso um ERP baseado em Oracle e todos ficaram felizes, mas seis meses depois alguém bateu com uma empilhadeira na parede da sala de máquinas, isso causou um incêndio no UPS e três racks de equipamentos, incluindo o servidor Oracle, foram totalmente destruídos.
    Como ninguém confiava de verdade no sistema, todo mundo continuou registrando tudo em papel, então até eu sair da empresa, seis anos depois, o trabalho ainda era feito com papel + relatórios em Excel.
    No fim, ficou provado que o método em papel resiste melhor a empilhadeiras.

  • O Excel é algo que muitos funcionários administrativos conseguem entender e modificar intuitivamente.
    Se mais partes da infraestrutura de TI tivessem esse tipo de acessibilidade, provavelmente tudo seria muito mais prático.

  • Por outro lado, quando a automação de TI já está completamente enraizada na produção e não sobram mais pessoas acostumadas ao processo manual antigo, pode ser realmente muito difícil voltar ao modo manual.
    Claro, isso depende da complexidade dos pedidos e do workflow.

  • Sem software, drones também não servem para muita coisa.
    Se você souber o inventário de cabeça, talvez consiga montar algo como um quadricóptero de controle manual, mas produzir peças em impressão 3D, ter voo estável, navegação autônoma, vigilância e outros usos avançados fica inviável.
    Até o controle remoto provavelmente seria difícil.

• A guerra cibernética na Ucrânia está chegando a um novo patamar; já vai além de simples ataques cibernéticos.
  Instalações de fabricação de drones russos, como a que foi atacada agora, são centrais porque os drones mudaram a dinâmica desta guerra.
  Eles trouxeram inovações em reconhecimento, interferência e interceptação de munição.
  Têm um poder destrutivo enorme em relação ao material empregado e, com os avanços em visão computacional, alguns continuam operando mesmo sob interferência de sinal.
  Parece coisa de filme de espionagem, mas está acontecendo de verdade.
  Isso mostra como a Ucrânia domina a guerra assimétrica.
  Ao destruir bombardeiros de longo alcance e paralisar polos de produção de drones, ela abala forças centrais da Rússia.
  Não sabemos como a guerra vai terminar, mas está claro que a resistência ucraniana vai continuar.

  • No romance Ministry of the Future, os drones avançam tanto que a guerra tradicional acaba perdendo o sentido em um mundo onde ninguém mais está seguro.
    Até pequenos grupos passam a conseguir assassinar qualquer pessoa em qualquer lugar do planeta.
    A ideia é interessante, mas a história é fraca, então eu não recomendaria muito o livro em si.

  • Sobre “drones que continuam funcionando apesar da interferência eletrônica”, hoje já existem drones controlados não por ondas eletromagnéticas, mas por cabos de fibra óptica; a realidade é ainda mais assustadora.

  • Ainda resta ver se a importância dos drones nesta guerra vai se aplicar também a outros conflitos no futuro.
    A situação particular da Rússia, avançando aos poucos enquanto aceita perdas humanas enormes, aumenta muito o valor dos drones FPV.
    A maioria dos países não aceitaria esse nível de perdas, então não acho que esse formato vá virar padrão de guerra.
    Drones a jato baratos e de longo alcance podem acabar tendo um papel ainda mais importante.

  • As informações da matéria parecem misturar muitas suposições.
    Estamos ouvindo só um lado, e pode haver exagero por valor de propaganda.
    Em geral existe controle de versão adequado, e cada desenvolvedor costuma manter cópias locais do código e dos arquivos CAD.
    E-mails e arquivos de escritório podem até ter sido perdidos, mas é bem possível que isso não seja um dano crítico.
    O site continua funcionando normalmente.
    Essa empresa atacada nem é especialmente conhecida na comunidade de drones, então talvez não se trate da paralisação de uma grande linha de produção.
    Eles provavelmente não desconhecem práticas básicas como controle de versão; até achei que o estilo do comentário parecia escrito pelo ChatGPT.

• Trabalho em uma empresa suíça de médio porte.
  Estamos desenvolvendo um ERP próprio e a stack é um pesadelo absoluto.
  Chamamos isso de “segurança pelo caos”.
  Mesmo que um invasor consiga entrar, ele nunca vai conseguir sair.
  Mesmo que 90% do código seja destruído, o serviço não será afetado, porque 95% dele já é inútil mesmo.

  • Tenho experiência desenvolvendo sistemas MRP para grandes empresas, então fiquei curioso para ver no que isso vai dar.
    Eu normalmente ainda adiciono, por cima das práticas recomendadas de segurança/recuperação de desastre, uma camada de autenticação por chave baseada em hash OTP.
    Eu achava que eu já exagerava, mas esse sistema parece quase um cenário de sobrevivência de fim do mundo.

  • Dá a impressão de ser uma resiliência surgida pelo próprio processo evolutivo.

  • É engraçado porque parece uma barreira ICE do mundo real.

  • Assusta, mas ao mesmo tempo impõe certo respeito.

• A maioria das empresas não se prepara de forma clara para o cenário em que praticamente todos os repositórios de dados internos sejam totalmente apagados e tudo precise ser implantado outra vez a partir do zero.
  Se você nunca fez de fato uma recuperação do zero, há uma boa chance de existirem dependências circulares no processo de deploy.
  Você começa implantando o config pusher com Jenkins/Puppet/Ansible, mas em algum momento o próprio Jenkins passa a depender do config pusher, e aí já não dá mais para simplesmente reconstruir na sequência; passa a ser necessário reconstituir todo o histórico de mudanças desde muito tempo atrás.

  • Em TI, dependências circulares existem em quase tudo.
    O SSO acaba virando dependência de praticamente todos os sistemas, e dentro do próprio SSO surgem ciclos envolvendo rede e administração de vários sistemas.
    Dar boot totalmente do zero é sempre difícil e demorado.
    A menos que você construa uma infraestrutura dupla completamente isolada, resolver isso perfeitamente é praticamente impossível.

  • Conheço uma empresa que passou por isso há cerca de um ano.
    O cluster principal de storage do qual tudo dependia morreu.
    No fim, eles recuperaram tudo redeployando a partir de notebooks de desenvolvimento.

  • black start (recuperação com inicialização totalmente do zero) é um problema extremamente difícil.
    O Facebook já teve de recuperar um incidente no passado perfurando na broca as fechaduras do datacenter para conseguir entrar.

  • Fico me perguntando como seria possível recuperar algo assim.
    Se ainda restassem documentos em papel, daria para fazer o bootstrap com eles? Ou é preciso assumir que até isso sumiu?

  • A construção civil enfrenta um problema parecido.
    Produtos têm vida útil de 50 anos ou mais, às vezes centenas, mas arquivos de projeto feitos 30 anos atrás muitas vezes não podem mais ser abertos hoje por causa de incompatibilidades de formato.
    Fala-se em digitalização há décadas, mas no fim talvez plantas 2D antigas (ou hoje em dia PDFs, o que alguns chamam de “papel digital”) ainda possam ajudar no futuro.
    O uso de papel de verdade vem caindo, mas por causa dos problemas de compatibilidade de arquivos talvez o papel acabe voltando a ser útil.

• No título da matéria, os atacantes são chamados de “ciberativistas”, mas no texto aparecem como “cibercriminosos”.
  Isso me lembra figuras de fronteira ambígua como os corsários e as cartas de corso da era da navegação à vela.
  A teoria da guerra de quarta geração já falava sobre o apagamento da fronteira entre civil e militar.
  As regras de engajamento estão ficando cada vez mais nebulosas.

  • A Rússia está matando civis com drones todos os dias.
    Isso não é uma zona cinzenta ambígua de guerra híbrida; é simplesmente gente tentando impedir que seus vizinhos virem vítimas de drones.

  • Isso parece um problema de tradução.
    O site em questão tem uma linha fortemente pró-Ucrânia, então talvez tenham usado “cyber criminal” apenas no sentido de “hacker”, para não soar tão negativo.

  • Na prática, a hipótese mais plausível é que isso esteja sendo organizado pela inteligência militar ucraniana.
    Então o correto seria não tratá-los como criminosos.

  • É algo meio Robin Hood.
    Para uns, heróis; para outros, criminosos.
    Provavelmente a matéria em si foi montada a partir de várias reportagens, e por isso a terminologia se misturou.
    Seria bom haver um termo específico para falar de lados em guerra cibernética.
    “Ciberativista” soa só como manifestante online, então em vez desse termo batido de filme eu preferiria algo como “cibersoldado” ou “milícia de rede”.

• Achei engraçado sozinho ao ver que a data da foto da matéria está a um dia do início da época Unix.

• Esse site em questão é muito peculiar.
  O governo russo o bloqueia, então aparece erro de TLS; e mesmo contornando isso, vem a página de “bloqueado” da Cloudflare; só com VPN dá para acessar a matéria original em russo.

  • A página linkada está em inglês, mas talvez o alvo não fosse o público russo local da versão russa do site.
    Na Rússia há muita sensibilidade com a questão do idioma, mas na Ucrânia o russo ainda é amplamente usado na prática e matérias em russo também são publicadas.

  • Recomendo fortemente usar sites de arquivamento, como archive.today e archive.org (Internet Archive).
    Alguém inclusive salvou recentemente um link de arquivo.

  • Isso talvez não seja um problema do site em si, mas do bloqueio governamental, ou então de algo relacionado à CloudFlare.
    Pode ser que o bloqueio da Cloudflare decorra justamente da causa raiz do erro de TLS.

• Fico curioso se os dois lados estão preocupados com o firmware dos drones.
  Parece ter valor estratégico infiltrar secretamente firmware adulterado nos drones usados pelo inimigo.

  • É interessante, mas o risco é alto (ser descoberto facilmente e acabar comprometendo toda a operação).
    No fim, acho que a abordagem mais direta continua sendo a mais racional.

  • Normalmente o firmware dos drones é gravado pouco antes da missão.

  • Na prática, talvez fosse até mais eficaz fazer os drones passarem a agir de forma sutilmente diferente, em vez de fechar a fábrica — por exemplo, atacar a própria base no momento do lançamento ou permitir controle remoto do adversário.

  • Uma estratégia curiosa que ouvi mencionar é infectar o cartão SD do drone com um vírus, de modo que, se ele cair em território inimigo e alguém o inserir em um computador, aquele computador acabe infectado.

• “Ciberativistas ucranianos em cooperação com a inteligência militar...”
  Ou seja, significa que só receberam sinalização de serviços de inteligência estrangeiros, e não que se trate de guerra cibernética direta.

  • Sobre a opinião de que “se só houve sinalização de serviços de inteligência estrangeiros, então não é guerra cibernética direta”:
    os serviços de inteligência russos já estão atacando diretamente países da OTAN, então mal sobra espaço para esse tipo de desculpa.

  • Como Ucrânia e Rússia já estão em guerra há anos, nem existe muita necessidade de uma justificativa plausível (deniability).

  • Fico curioso sobre o que exatamente significaria “serviços de inteligência estrangeiros”, e, na prática, ataques acontecem o tempo todo no mundo inteiro, então não dá para ser ingênuo.

  • Alguém aponta que a matéria não menciona “serviços de inteligência estrangeiros”.

  • Ela especifica que se trata da inteligência militar ucraniana.