Segurança da Informação

Ataque hacker ao Porto de Santos: o que aconteceu e o que as empresas podem aprender.

Um ataque cibernético tirou do ar os sistemas administrativos da Autoridade Portuária de Santos, enquanto navios e cargas seguiram operando. Veja o que se sabe até agora e as lições de continuidade de negócios que valem para empresas de qualquer porte.

Por Vandeilson Souza13 de novembro de 202611 min de leitura
Ataque hacker ao Porto de Santos: o que aconteceu e o que as empresas podem aprender

Na última semana, o Porto de Santos, o maior da América Latina, virou notícia por um motivo que nada tem a ver com recordes de movimentação. Um ataque cibernético atingiu os sistemas administrativos da Autoridade Portuária de Santos (APS), a empresa pública que administra o porto. Sistemas de protocolo e de gestão, a intranet e o site institucional saíram do ar, a Polícia Federal abriu inquérito e a recuperação dos dados ainda está em andamento.

Ao mesmo tempo, segundo a APS, a entrada e a saída de navios, a movimentação de cargas e os acessos terrestres continuaram funcionando. É esse contraste que torna o caso tão instrutivo: ele mostra, quase em tempo real, o que separa um incidente grave de uma paralisação.

Neste post, reunimos o que se sabe até agora, com base nas informações divulgadas pela APS e pela imprensa, e as lições práticas de continuidade de negócios que valem para empresas de qualquer porte e setor.

O que aconteceu

A cronologia abaixo foi montada a partir de reportagens publicadas entre 10 e 13 de novembro de 2026.

  • Sexta-feira, 6 de novembro: uma queda de energia derruba os servidores da APS. Os sistemas administrativos voltam à noite, mas caem de novo. Segundo a Gazeta do Povo, a APS tem dois data centers: quando o primeiro parou, o segundo assumiu a carga, mas também caiu.
  • Sábado, 7 de novembro, por volta das 3h: a equipe identifica um vírus na rede. De acordo com a apuração interna da APS, o código malicioso já estava instalado antes da queda de energia e foi ativado quando os servidores foram religados. Ainda não se sabe quando nem como ele entrou.
  • Nos dias seguintes: um grupo que se apresenta como autor do ataque entra em contato com a APS por e-mail, orientando a empresa a procurá-lo para recuperar os dados. A APS não respondeu. Segundo o presidente da autoridade portuária, Anderson Pomini, o contato não chegou a apresentar exigências e não houve pagamento.
  • Segunda-feira, 9 de novembro: internet, e-mail e telefonia são restabelecidos.
  • Terça-feira, 10 de novembro: a APS confirma publicamente que sofreu um ataque cibernético e informa que ativou seu plano de contingência. A Polícia Federal abre inquérito.
  • Quinta-feira, 12 de novembro: a equipe de tecnologia informa ter recuperado cerca de 70% das cópias de segurança dos arquivos afetados.
  • Sexta-feira, 13 de novembro: o site da APS volta ao ar durante a madrugada. Outros sistemas seguem em recuperação.

Ao longo da semana, a comissão estadual responsável pela segurança pública nos portos (Cesportos) também elevou para o nível 2, em uma escala de 3, a proteção dos acessos ao porto, com mais controle de entrada e inspeções.

O que parou e o que continuou funcionando

Segundo a APS e as reportagens, foram afetados:

  • O sistema de protocolo, usado para receber solicitações.
  • O sistema de tramitação de documentos internos e a ferramenta de gestão administrativa.
  • O site institucional, a intranet e o atendimento online.
  • Servidores com informações sobre navios, clientes, pedidos de atracação e pagamentos. A APS ainda não sabe se os invasores tiveram acesso a esses dados.

Continuaram funcionando:

  • A entrada e a saída de navios, a movimentação de cargas e os acessos terrestres.
  • O Porto Sem Papel, sistema do governo federal que conecta agentes marítimos a órgãos como Receita Federal, Polícia Federal, Marinha e Anvisa. Ele não foi atingido e passou a ser usado, junto com celulares e e-mail, para trocar documentos e autorizar embarcações.
  • As operações dos terminais. Empresas ouvidas pela imprensa relataram, no máximo, lentidão pontual.

Isso não quer dizer que o incidente tenha sido pequeno. Processos administrativos ficaram mais lentos, a liberação de navios passou a depender de e-mails e a recuperação completa ainda não terminou. Mas o núcleo da operação seguiu de pé.

O que ainda não se sabe

  • Como e quando o vírus entrou na rede.
  • Se houve acesso, cópia ou vazamento de dados. Até a publicação deste post, a APS não havia confirmado nenhum desses cenários.
  • Quem está por trás do ataque. O caso tem características de ransomware, o tipo de ataque em que os criminosos bloqueiam ou criptografam os dados e cobram para devolvê-los, mas isso não foi confirmado oficialmente.
  • O tamanho do prejuízo. Não há estimativa de perdas financeiras divulgada.

As informações deste post refletem o que foi divulgado até 13 de novembro de 2026. A investigação está a cargo da Polícia Federal, e novos fatos podem mudar parte deste quadro.

Lições para empresas de qualquer porte

Não é preciso operar um porto para estar exposto ao mesmo tipo de risco. Hospitais, cartórios, prefeituras, escolas e empresas de serviços dependem de sistemas administrativos que, quando param, travam atendimento, faturamento e comunicação. Sem entrar no mérito das decisões tomadas em Santos, que seguem sob investigação, o caso ilustra bem seis princípios de continuidade de negócios.

1. O invasor pode já estar dentro

Talvez o detalhe mais importante do caso seja este: segundo a APS, o código malicioso já estava na rede antes da queda de energia. Ataques desse tipo costumam ter uma fase silenciosa, em que o invasor entra, explora o ambiente e prepara o terreno antes de agir. Quanto mais cedo essa presença é detectada, menor o estrago.

  • Monitore servidores e estações de trabalho com ferramentas de detecção e resposta (EDR) e centralize os registros de atividade (logs), para identificar comportamentos estranhos antes que virem crise.
  • Revise com frequência as contas de acesso, principalmente as administrativas e as de fornecedores.
  • Mantenha tudo atualizado. Falhas conhecidas e não corrigidas continuam entre as portas de entrada mais usadas. Em novembro, pelo segundo mês seguido, a Microsoft corrigiu mais de mil falhas de uma só vez, e a CISA, agência de cibersegurança dos Estados Unidos, alertou para ataques ativos contra uma falha no núcleo do WordPress. Em outubro, falamos aqui no blog sobre o PHP2Shell, as falhas críticas do PHP, que começaram a ser exploradas em poucas horas.

2. Backup só vale se a restauração for testada

A recuperação de cerca de 70% das cópias de segurança mostra que havia backup, e isso faz toda a diferença. Sem cópias, a única saída seria negociar com criminosos, sem garantia nenhuma. Ao mesmo tempo, o caso mostra que restaurar ambientes inteiros leva dias, mesmo com as cópias disponíveis.

  • Siga a regra 3-2-1: três cópias dos dados, em dois tipos de mídia diferentes, sendo uma delas fora do ambiente principal. Pelo menos uma cópia deve ser offline ou imutável, fora do alcance de quem invadir a rede.
  • Teste a restauração com regularidade e meça o tempo real que leva para colocar cada sistema de volta no ar.
  • Defina, para cada sistema, quanto tempo ele pode ficar parado e quanto de dados a empresa aceita perder. São os indicadores conhecidos como RTO (Recovery Time Objective) e RPO (Recovery Point Objective), e eles orientam quanto investir em backup e redundância.
  • Decida antes a ordem de recuperação. Em Santos, a comunicação (internet, e-mail e telefonia) voltou primeiro, uma escolha que faz sentido: sem comunicação, nada mais se coordena.

3. Redundância precisa ser independente

De acordo com a Gazeta do Povo, quando o primeiro data center caiu, o segundo assumiu a carga e também parou. As causas ainda não foram esclarecidas, mas o episódio lembra um princípio importante: ambientes redundantes que compartilham a mesma rede elétrica, a mesma rede lógica ou as mesmas credenciais de acesso podem cair juntos.

  • Mantenha o ambiente de contingência separado do principal, seja em servidores próprios, seja na nuvem: outro local, outra alimentação elétrica, outra rede.
  • Use credenciais administrativas diferentes nos dois ambientes, para que uma senha roubada não abra as duas portas.
  • Faça testes de failover, simulando a queda do ambiente principal, e não apenas testes de funcionamento normal.

4. Separe o que é crítico do que é administrativo

O ponto mais positivo do caso é que a operação do porto continuou. Isso só é possível quando os sistemas que sustentam a atividade principal não dependem dos sistemas administrativos e quando existem alternativas fora do ambiente atingido, como o Porto Sem Papel.

  • Mapeie os processos críticos do negócio e os sistemas de que cada um depende.
  • Segmente a rede, isolando os sistemas críticos dos administrativos e das estações de trabalho.
  • Documente procedimentos alternativos (formulários, canais de contato, sistemas externos) e treine as equipes para usá-los. Um plano de contingência que só existe no papel, ou que está guardado justamente no servidor que caiu, não ajuda na hora da crise.

Passamos por um exercício parecido em 2025, durante a falha global da Cloudflare: ter protocolos de contingência definidos antes do problema foi o que garantiu a continuidade dos serviços.

5. Não negocie no escuro e acione as autoridades

A APS não respondeu ao contato dos criminosos e o caso está com a Polícia Federal. Pagar resgate não garante a devolução dos dados, como alerta o CERT.br, e ainda financia novos ataques.

  • Registre a ocorrência na polícia. Órgãos públicos contam também com o CTIR Gov, centro de prevenção e resposta a incidentes cibernéticos do governo federal.
  • Preserve as evidências (registros de atividade, máquinas afetadas) antes de reinstalar tudo. Elas são essenciais para entender o que aconteceu e evitar que se repita.
  • Tenha definidos, antes da crise, os contatos de especialistas em resposta a incidentes, da assessoria jurídica e do seguro, se houver.

6. Comunique com transparência, inclusive à ANPD

Nas primeiras horas de um incidente, é comum que o diagnóstico ainda não esteja claro. Em Santos, a interrupção foi associada primeiro a uma queda de energia, e o ataque foi confirmado depois, com o avanço da apuração. Por isso, vale ter um plano de comunicação pronto, que permita informar com rapidez o que se sabe e o que ainda está sendo apurado.

  • Prepare mensagens-modelo para clientes, parceiros, imprensa e equipes internas.
  • Defina quem fala em nome da empresa e por quais canais, incluindo canais que funcionem mesmo com o e-mail corporativo fora do ar.
  • Conheça as obrigações da LGPD. Quando um incidente pode trazer risco ou dano relevante aos titulares de dados pessoais, o controlador deve comunicar a ANPD e os titulares em até três dias úteis, contados a partir do momento em que soube que o incidente afetou dados pessoais, conforme a Resolução CD/ANPD nº 15/2024. Agentes de pequeno porte têm o prazo em dobro.
  • Registre o incidente internamente, mesmo quando não houver obrigação de comunicar. A mesma resolução exige que esse registro seja mantido por pelo menos cinco anos.

Perguntas para levar à próxima reunião de diretoria

Se o caso de Santos acontecesse na sua empresa amanhã, as respostas para estas perguntas fariam diferença:

  • Sabemos quais sistemas são críticos e quanto tempo cada um pode ficar parado?
  • Temos pelo menos uma cópia de backup offline ou imutável? Quando foi o último teste de restauração completo?
  • Nosso ambiente de contingência cairia junto com o principal?
  • A operação consegue seguir por alguns dias com procedimentos alternativos?
  • Quem decide e quem comunica em caso de incidente? Os contatos dessas pessoas estão acessíveis fora dos sistemas da empresa?
  • Sabemos como e em quanto tempo comunicar a ANPD?

Preparo faz a diferença

Nenhuma organização está imune a um ataque cibernético. O que muda o desfecho é o preparo: detectar cedo, ter cópias de segurança que de fato funcionam, separar o que é crítico e saber exatamente o que fazer quando algo dá errado. O caso do Porto de Santos mostra os dois lados dessa equação, com sistemas importantes fora do ar e, ao mesmo tempo, uma operação que não parou.

Para se aprofundar, leia também nossos posts sobre segurança da informação e engenharia social, segurança da informação em plataformas web e hospedagem segura na AWS.

Se a sua empresa quer revisar o plano de continuidade, a estratégia de backup ou a segurança dos seus sistemas, fale com a gente.

Fontes

Tags

#ataque hacker#ransomware#Porto de Santos#continuidade de negócios#plano de contingência#backup#LGPD

Sobre o Autor

Vandeilson Souza

Vandeilson Souza

Gerente de Operações e Analista de Negócios Pleno da Mupi Systems

Vandeilson Souza é Gerente de Operações e Analista de Negócios Pleno da Mupi Systems, onde atua desde 2024 na ponte entre clientes, áreas de negócio e o time de desenvolvimento. Técnico em Informática pelo IFNMG, cursa Administração e Gestão Pública e traz da AeC a experiência em gestão de processos, indicadores e equipes de atendimento.

Categorias

Segurança da Informação

Gostou deste conteúdo?

Assine nossa newsletter e receba mais insights como este diretamente no seu e-mail.

Falar com especialistas
Ataque hacker ao Porto de Santos: o que aconteceu e o que as empresas podem aprender | Mupi Systems Blog | MUPI Systems