Violação de segurança da Northflank: O que rodar a seguir

Violação de segurança da Northflank: O que rodar após o incidente

Última atualização: 5 de novembro de 2026. A página de incidentes da Northflank foi verificada novamente a 5 de novembro; a última atualização publicada continuava a ser a de 2 de novembro de 2026.

Na violação de segurança da Northflank, que a empresa designa como incidente de segurança e divulgou a 30 de outubro de 2026, a plataforma pediu aos clientes que, por precaução, assumissem que todas as variáveis de ambiente tinham sido decifradas, ou seja, desbloqueadas de forma a que os atacantes as pudessem ler.

As variáveis de ambiente são definições armazenadas que as aplicações leem quando são executadas. Contêm frequentemente chaves de API, os códigos secretos que permitem ao software utilizar um serviço. Os utilizadores também comunicaram a utilização não autorizada das suas chaves de API de IA. A página de estado não indica que todas as variáveis armazenadas tenham sido roubadas.

Em seguida: o que a Northflank, a Railway e a Huntress comunicaram e as verificações a fazer já.

Northflank: a 30 de outubro de 2026, pediu aos clientes que assumissem que todas as variáveis de ambiente tinham sido decifradas e que rodassem todos os segredos (Northflank).
Black October: a Wiz, empresa de segurança na nuvem, contabilizou pelo menos nove plataformas de desenvolvimento de IA (serviços para criar e executar aplicações de IA) que divulgaram incidentes entre 6 e 30 de outubro. As explicações públicas diferiam, várias eram preliminares e algumas causas de raiz eram desconhecidas (Wiz).
Railway: a 21 de outubro de 2026, afirmou que um terceiro não autorizado pode ter acedido a variáveis de ambiente encriptadas de clientes e, no caso de algumas delas, obtido o conteúdo decifrado (Railway).
Token spraying: a Huntress detetou tokens de sessão do Microsoft 365 (M365) roubados, que mantêm o utilizador com sessão iniciada, a ser reutilizados em 79 organizações entre 14 de julho e 22 de setembro de 2026 (Huntress).

Violação de segurança da Northflank: Clientes instruídos a assumir que todas as variáveis de ambiente foram decifradas

O que aconteceu: a Northflank é uma plataforma na nuvem onde as equipas executam aplicações e bases de dados. A 30 de outubro de 2026, abriu um incidente de segurança na sua página de estado. Os momentos-chave, em UTC:

11:43: chegou um alerta de ameaça da Wiz.
13:40: a Northflank pediu aos clientes que rodassem imediatamente as variáveis de ambiente. Rodar um segredo significa substituí-lo por um novo e cancelar o antigo.
13:58: por precaução, pediu aos clientes que assumissem que todas as variáveis de ambiente tinham sido decifradas e que desativassem e rodassem todas as chaves.
Mais tarde, a 30 de outubro: acrescentou que os utilizadores tinham comunicado a utilização não autorizada de chaves de API de IA fornecidas à plataforma.
01:04 de 31 de outubro: ativou os registos de auditoria para todos os clientes, incluindo os utilizadores gratuitos. Os registos de auditoria indicam quem fez o quê numa conta.
30 e 31 de outubro: ativou, por fases, a rotação de segredos para bases de dados e outros add-ons.

A página não indica o número de clientes afetados.

Numa atualização de 2 de novembro, a Northflank afirmou:

Considerava que o vetor de ataque tinha sido contido no espaço de uma hora após o primeiro alerta.
Não via, nessa altura, qualquer indício de acesso a cargas de trabalho ou aos respetivos dados.
As provas sugeriam que o ataque se concentrou nos segredos guardados no seu plano de controlo (control plane), a parte da plataforma que gere os projetos dos clientes.
Auditores forenses independentes continuavam a analisar o ataque.
Os clientes deviam continuar a rodar todos os segredos, e seria publicada uma análise da causa de raiz depois de as conclusões serem confirmadas.

Continuava sem indicar o número de clientes afetados.

Porque é importante: a Wiz contabilizou pelo menos nove plataformas de desenvolvimento de IA que divulgaram incidentes entre 6 e 30 de outubro: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode e Northflank. Mais tarde, a 2 e 3 de novembro, a Wiz atualizou a publicação para acrescentar incidentes comunicados na Brev, na Trigger.dev e na Chainstack.

Segundo a Wiz, os relatos públicos apontavam de forma coerente para tentativas direcionadas de obter variáveis de ambiente armazenadas, sobretudo chaves que dão acesso a serviços de IA. A Wiz não encontrou nenhuma vulnerabilidade única nem dependência partilhada que ligasse os incidentes. Esse padrão não prova a existência de um atacante comum nem de uma única campanha.

A Wiz resumiu também as primeiras explicações:

Acesso a credenciais na Fireworks, na Zeabur e na Lightning.
Possível escalada de privilégios nos sistemas de compilação da Railway.
Um problema de um fornecedor na Warp.
Acesso através de um sistema antigo na OpenCode.

Várias destas explicações eram preliminares, e algumas causas de raiz continuavam desconhecidas.

A Wiz descreveu ainda o valor que uma chave roubada pode ter. Observou a primeira atividade não autorizada em cada uma de duas chaves empresariais no espaço de 30 minutos após o acesso a credenciais do lado do fornecedor que tinha sido comunicado. Num dos casos, o agente fez cerca de 800 000 chamadas ao Amazon Bedrock, o serviço da Amazon para executar modelos de IA, ao longo de 30 horas, e cerca de 90 % foram bem-sucedidas.

A Wiz estimou que os dois casos, em conjunto, terão provavelmente gerado mais de 100 000 dólares em utilização a preços de tabela, ou seja, segundo a tabela de preços pública. Trata-se de uma estimativa, não de uma fatura confirmada.

Medidas de defesa: as orientações da Northflank têm três partes:

Revogar, ou seja, cancelar, as credenciais existentes junto da empresa que as emitiu. Criar substitutas e atualizar os segredos e as cargas de trabalho afetados na Northflank.
Rever os registos de utilização e de faturação do fornecedor de IA para detetar atividade que não reconheça.
Desativar o acesso público aos add-ons, os serviços adicionais como bases de dados, onde estiver ativado.

Recomendação: sempre que o fornecedor o permita, atribua a cada plataforma uma chave própria, limitada às permissões de que essa plataforma necessita. Configure alertas de utilização e, se disponível, um limite rígido (hard limit), que bloqueia os pedidos ao atingir um determinado valor de gastos.

Chaves separadas facilitam o cancelamento. Os controlos de gastos variam consoante o fornecedor e podem não travar todos os excessos, pelo que deve verificar como funcionam no seu caso.

Fontes: Página de estado da Northflank; Wiz

Incidente de segurança da Railway: Substituir todas as variáveis de ambiente, incluindo credenciais de registo

O que aconteceu: a Railway é outra plataforma para executar aplicações. A 21 de outubro de 2026, afirmou ter detetado atividade invulgar relacionada com os sistemas que armazenam as variáveis de ambiente dos clientes. Um terceiro não autorizado pode ter acedido às variáveis encriptadas e, no caso de algumas delas, obtido o conteúdo decifrado.

A Railway começou por dizer que o impacto poderia limitar-se a um subconjunto de utilizadores. O relatório preliminar de 22 de outubro acrescentou:

No máximo 1,85 % dos espaços de trabalho, cerca de 100 000, tiveram algumas variáveis de ambiente potencialmente comprometidas.
A Railway não conseguia determinar que variáveis específicas tinham sido decifradas.
As implementações existentes, as versões das aplicações já em execução, mantiveram-se online. As novas compilações e implementações foram suspensas.

A Railway afirmou considerar que o incidente fazia parte de «uma série de ataques dirigidos recentemente a empresas de plataformas» com o objetivo de comprometer fornecedores de inferência de IA, ou seja, empresas que executam modelos de IA para clientes. Disse ter notificado antecipadamente esses fornecedores a montante para revogarem chaves.

Porque é importante: a Cloud Security Alliance, um grupo de investigação do setor, afirmou a 23 de outubro que nenhuma empresa tinha associado publicamente os incidentes a um único atacante. Referiu também que o enquadramento como campanha partia apenas da Railway. Segundo essa avaliação, a existência de uma única campanha não estava comprovada.

A Wiz, por seu lado, não encontrou nenhuma vulnerabilidade ou dependência partilhada entre os incidentes. O risco é o mesmo em qualquer dos casos: os segredos estão numa plataforma da qual a empresa depende, e outra pessoa pode tê-los lido.

Medidas de defesa: a Railway recomenda renovar todas as variáveis de ambiente, ou seja, substituir cada uma, incluindo as chaves de API e as credenciais de registos privados armazenadas na Railway. Uma credencial de registo privado é o início de sessão que uma aplicação utiliza para obter as suas imagens de contentor a partir de um repositório privado. A Railway recomenda também verificar os registos desses serviços para detetar atividade invulgar.

Recomendação: mantenha uma lista das chaves de fornecedores guardadas em cada plataforma, para que a rotação seja uma lista de verificação e não uma pesquisa.

Fontes: Divulgação da Railway; Relatório preliminar da Railway; Cloud Security Alliance

Roubo de tokens do Microsoft 365: Huntress detetou tokens reutilizados em 79 organizações

O que aconteceu: a Huntress, empresa de segurança, divulgou a 22 de outubro de 2026 uma campanha que decorreu entre 14 de julho e 22 de setembro de 2026. Afirmou ter respondido a incidentes relacionados em 79 organizações. Contabilizou 497 inícios de sessão bem-sucedidos no Microsoft 365 e mais de 200 000 tentativas de início de sessão falhadas.

Três termos ajudam a perceber o caso:

Token de sessão: dados emitidos após o início de sessão que permitem ao dispositivo manter a sessão iniciada ou obter acesso sem repetir todos os passos de autenticação. O tempo durante o qual funciona depende do token, da aplicação, da expiração, da revogação e dos controlos de política.
Token spraying: o nome que a Huntress dá à reutilização de tokens de sessão roubados em muitas contas, à semelhança do password spraying, que testa palavras-passe adivinhadas em muitas contas.
MFA: abreviatura de autenticação multifator, um início de sessão que verifica pelo menos dois tipos diferentes de prova, como uma palavra-passe e um código ou uma aprovação numa aplicação de autenticação.

Destacam-se duas conclusões:

Em 19 organizações, os métodos de MFA existentes da vítima foram apagados e foi registado um novo método no espaço de três horas após o primeiro início de sessão a partir de um endereço da campanha.
Num caso analisado em pormenor, um novo autenticador com o nome «iPhone 13» foi ativado cerca de 38 minutos depois de a sessão ter sido sequestrada, de acordo com as marcas temporais da cronologia da Huntress.

Porque é importante: a Huntress descreveu três origens dos tokens:

Um intermediário do tipo adversary-in-the-middle, uma página de início de sessão falsa que encaminha o verdadeiro início de sessão da vítima para a Microsoft.
Phishing por código de dispositivo (device-code phishing), que leva o utilizador a aprovar um início de sessão iniciado pelo atacante.
Engenharia social durante um início de sessão real.

Nos casos com intermediário, os atacantes guardaram um token emitido depois de a vítima concluir a MFA e reutilizaram-no sem novo pedido de MFA.

Um token reutilizado pode retomar uma sessão iniciada, mas a duração do acesso depende do token, da aplicação, da expiração ou revogação e dos controlos de política ou de risco. Um token roubado acaba por expirar ou ser revogado. Um método de MFA adicionado pelo atacante permanece na conta até alguém o remover.

O título do Help Net Security afirmava que as contas foram comprometidas sem necessidade de palavras-passe. Isso descreve a utilização da sessão roubada pelo atacante, não todos os passos da forma como foi obtida.

Medidas de defesa: perante uma suspeita de comprometimento, a Huntress recomenda três passos:

Revogar as sessões do utilizador.
Redefinir a palavra-passe.
Remover os dispositivos e os métodos de MFA adicionados pelo atacante. A redefinição da palavra-passe, por si só, deixa-os ativos.

A Microsoft recomenda também desativar ou bloquear a conta sempre que possível e procurar outras formas de os atacantes manterem o acesso: palavras-passe de aplicação, concessões de consentimento, funções e regras de reencaminhamento de correio. A revogação de sessões pode não terminar de imediato todas as sessões de aplicações, porque os tokens de acesso já emitidos podem continuar a funcionar até expirarem.

Para a prevenção, a Huntress recomenda políticas de Acesso Condicional, as regras da Microsoft que definem quem pode iniciar sessão e em que condições. Estas políticas devem exigir MFA ou bloquear o acesso para todos os utilizadores, aplicações na nuvem e tipos de aplicações cliente. Aplicar com cuidado:

Excluir as contas de emergência «break-glass», as contas de administração reservadas para situações de bloqueio, das políticas que bloqueiam ou restringem o início de sessão. As orientações da Microsoft indicam que devem ser protegidas e monitorizadas separadamente.
As contas de sincronização podem precisar de uma exclusão explícita da política de utilizadores. Os principais de serviço (service principals), ou seja, identidades de aplicações e de automatização, não são abrangidos pelo Acesso Condicional dirigido a utilizadores, pelo que devem ser governados com controlos próprios para identidades de carga de trabalho.
Bloquear a autenticação legada, os métodos antigos de início de sessão que não permitem MFA, com a condição específica para clientes legados.
Testar o impacto no modo apenas de relatório (report-only) antes de aplicar as políticas.

Fontes: Huntress; Help Net Security; Infosecurity Magazine; Microsoft: revogar o acesso de utilizadores; Microsoft: conta de e-mail comprometida; Microsoft: contas de acesso de emergência; Microsoft: MFA para todos os utilizadores; Microsoft: bloquear a autenticação legada

O que rodar após a violação de segurança da Northflank

Nestes incidentes, as credenciais e os tokens roubados podem ser aceites como válidos, pelo que os pedidos não autorizados podem parecer atividade normal com sessão iniciada. Isso não os torna invisíveis: os registos de utilização, os registos de início de sessão e os controlos de risco podem revelar atividade invulgar.

Verificações a fazer já:

Fazer uma lista dos segredos guardados nas plataformas. Registe todas as chaves de API, palavras-passe de bases de dados e tokens armazenados como variáveis de ambiente numa plataforma de alojamento ou de CI, bem como a empresa que emitiu cada um. A CI é o conjunto de ferramentas automatizadas que compila e implementa o código.
Revogar primeiro na origem e depois atualizar a plataforma. Siga a ordem indicada pela Northflank: revogue a credencial existente junto do fornecedor que a emitiu, crie uma substituta e, em seguida, atualize o segredo e as cargas de trabalho afetados na Northflank.
Limitar o que uma chave roubada pode fazer e gastar. Sempre que possível, utilize uma chave ou um projeto separado para cada plataforma, limitado às permissões necessárias, com alertas de utilização e um limite rígido. Os alertas podem não travar os pedidos, e a aplicação dos limites pode sofrer atrasos. Analise os registos de utilização à procura de chamadas que não consiga explicar.
Terminar as sessões e depois verificar os métodos de início de sessão. Em qualquer conta do Microsoft 365 sob suspeita, revogue as sessões e redefina a palavra-passe e, depois, remova os dispositivos e autenticadores que não reconheça. Verifique também as palavras-passe de aplicação, as concessões de consentimento, as funções e as regras de reencaminhamento.
Rever a cobertura do Acesso Condicional. Exija MFA nos inícios de sessão normais de utilizadores, para todos os utilizadores e recursos. Bloqueie a autenticação legada depois de testes no modo apenas de relatório. Documente as exclusões de contas de emergência e de eventuais contas de sincronização, e proteja-as e monitorize-as. Utilize um Acesso Condicional próprio para identidades de carga de trabalho no caso dos principais de serviço, em vez de tratar uma exclusão como cobertura.
Ativar os registos de que vai precisar. Ative os registos de auditoria que as plataformas disponibilizam e confirme o que abrangem e durante quanto tempo conservam os dados. A Northflank só ativou os registos de auditoria para todos os clientes, incluindo os utilizadores gratuitos, a 31 de outubro, depois do incidente.

O Passwork documenta o armazenamento de chaves de API e tokens em cofres, com acesso baseado em funções, para que cada pessoa veja apenas o que a sua função permite. A REST API e a CLI permitem que scripts e pipelines de CI leiam segredos a partir do cofre. Experimentar o Passwork grátis e ver como se adapta à sua configuração.