Foi esse alcance que a falha nos serviços da Microsoft evidenciou entre 12 e 13 de novembro. Enquanto a empresa trabalhava para recuperar sua infraestrutura, organizações precisaram adaptar procedimentos para manter atividades essenciais.

O que aconteceu com os serviços da Microsoft

A interrupção começou na tarde de quinta-feira, 12 de novembro, e persistia na manhã de sexta-feira, mais de 16 horas depois. Os problemas se concentravam no Exchange Online, serviço responsável pelas caixas de correio do Microsoft 365, com impactos também no Outlook, Teams e Copilot.

Segundo a Microsoft, um grande número de servidores ficou inesperadamente indisponível, sobrecarregando os demais. A empresa descartou um ataque cibernético, mas a causa inicial ainda estava sob investigação.

A BBC informou que o Downdetector registrou cerca de 140 mil relatos de problemas com o Outlook em 74 países. Esse volume representa notificações de falha, não o total de pessoas afetadas, que não havia sido confirmado pela Microsoft.

Na manhã de sexta-feira, havia sinais de recuperação parcial, incluindo o restabelecimento do acesso a caixas de correio na região da Ásia-Pacífico. Ainda assim, a capacidade operacional permanecia abaixo do normal, sem previsão de resolução completa. A empresa também alertou que serviços recuperados poderiam voltar a apresentar falhas.

Como a interrupção se propagou para outras atividades

Governos do Japão e de Singapura, além de uma agência australiana, relataram impactos. No Reino Unido, consultórios médicos orientaram pacientes a encaminhar solicitações urgentes por telefone, substituindo e-mails e formulários online.

As dependências também alcançaram ferramentas de inteligência artificial. OpenAI e Anthropic informaram problemas nas integrações com serviços da Microsoft. Isso não significava uma indisponibilidade geral do ChatGPT ou do Claude, mas dificuldades nas conexões com o ambiente afetado.

O episódio evidencia a necessidade de conhecer quais processos dependem do mesmo fornecedor. Uma aplicação acessível perde parte de sua utilidade quando não consegue consultar informações, enviar notificações ou concluir etapas apoiadas em outro serviço.

A concentração dessas dependências amplia o alcance de uma interrupção e exige alternativas compatíveis com as prioridades do negócio.

O que a liderança precisa definir antes de uma falha prolongada

A decisão de acionar uma contingência precisa considerar o impacto sobre a operação, além das atualizações do fornecedor. Enquanto a recuperação avança, os efeitos sobre atendimento, receita e produtividade se acumulam.

Três definições ajudam a orientar a resposta:

• Prioridades: quais atividades precisam continuar e por quanto tempo cada processo tolera uma interrupção.
• Alternativas: quais canais, documentos e procedimentos estarão disponíveis sem depender do serviço afetado.
• Retomada: como conferir solicitações pendentes, mensagens atrasadas e tarefas realizadas durante a contingência, evitando duplicidade ou perda de registros.

Essas alternativas precisam ser testadas. Substituir o e-mail por telefone exige capacidade de atendimento e critérios para registrar demandas. Disponibilizar documentos em outro ambiente requer controle de acesso e identificação das versões utilizadas.

Backup Microsoft 365: proteção de e-mails, documentos e dados de colaboração

Históricos de negociação, anexos, contratos e arquivos compartilhados sustentam decisões e atividades diárias. A estratégia de backup deve contemplar essas informações nos diferentes serviços utilizados pela organização.

O Backup Microsoft 365 da Penso utiliza tecnologia Veeam e contempla dados do Exchange Online, SharePoint, OneDrive e Teams. A cobertura inclui caixas postais, anexos, contatos, calendários, documentos e conteúdos de colaboração, conforme o escopo contratado.

Manter cópias independentes oferece opções de recuperação diante de exclusões acidentais, ações maliciosas e outras situações que comprometam os dados. Para a gestão, isso exige definir quais informações serão protegidas, por quanto tempo serão mantidas e como sua restauração será validada.

Durante uma indisponibilidade do provedor, a contribuição do backup depende das condições de acesso às cópias e dos recursos de recuperação disponíveis. O backup não restabelece o Exchange Online nem normaliza o envio e o recebimento de e-mails durante uma falha da Microsoft.

Como o backup do SharePoint contribui para a contingência

No SharePoint, documentos como contratos, propostas e procedimentos internos merecem atenção pela sua relação direta com a execução do trabalho.

Quando a solução permite exportar arquivos protegidos e a infraestrutura de recuperação permanece acessível, esses conteúdos podem ser disponibilizados em um local alternativo autorizado. Isso permite consultar informações essenciais, respeitando as permissões de acesso e a versão disponível no backup.

Essa medida ajuda a sustentar atividades que dependem dos documentos, mas não reproduz a edição simultânea nem os fluxos automatizados da plataforma.

A reportagem não confirma perda de dados nem indisponibilidade generalizada do SharePoint neste episódio. A proteção desses conteúdos integra a preparação para situações em que o acesso ao Microsoft 365 fique comprometido.

Penso Mail: uma alternativa para o e-mail corporativo

A concentração da comunicação em um único ecossistema também merece avaliação. Empresas que utilizam aplicações Microsoft podem adotar outra plataforma para seu e-mail, considerando os requisitos de integração e administração.

O Penso Mail, serviço de e-mail corporativo da Penso baseado em Zimbra, reúne calendário, contatos, compartilhamento e acesso por diferentes dispositivos. A solução permite estruturar a comunicação fora do Exchange Online, preservando funcionalidades importantes para a rotina das equipes.

Sua infraestrutura está distribuída em cinco data centers Tier III no Brasil, com redundância e replicação. O serviço conta com suporte especializado e apoio à migração, oferecendo uma alternativa para empresas que buscam avaliar sua estrutura de e-mail com base em disponibilidade, segurança e atendimento.

A adoção exige planejamento e análise das integrações existentes. O Penso Mail atende às necessidades de e-mail e colaboração, sem pressupor a substituição de todas as aplicações do Microsoft 365 ou uma troca automática de plataforma durante uma falha.

O papel do Disaster Recovery na recuperação dos ambientes críticos

Além de proteger informações e avaliar a plataforma de comunicação, a empresa precisa organizar a recuperação dos sistemas sob sua responsabilidade.

O Disaster Recovery da Penso apoia essa preparação com prioridades de retomada, infraestrutura de contingência e testes, conforme os requisitos do negócio e os ambientes contemplados na solução. O planejamento considera o tempo aceitável de interrupção e a perda tolerável de dados para orientar a recuperação.

Em serviços SaaS, como o Microsoft 365, o restabelecimento da plataforma permanece sob responsabilidade do fornecedor. Cabe à organização preparar procedimentos para manter atividades essenciais durante esse intervalo e coordenar a retomada quando o acesso se estabilizar.

O caso da Microsoft reforça a importância de avaliar essas dependências antes de uma falha prolongada. Backup Microsoft 365, Penso Mail e Disaster Recovery atendem a necessidades complementares de proteção de dados, comunicação e recuperação. Sua aplicação deve partir dos processos que a empresa precisa preservar e dos prazos que consegue tolerar.

Fale com a Penso para avaliar o backup do Microsoft 365, o e-mail corporativo e a recuperação dos ambientes críticos da sua empresa.

Fonte: https://www.bbc.com/portuguese/articles/c6wy49w32epwo

The post Falha na Microsoft ultrapassa 16 horas e expõe dependências críticas das operações corporativas appeared first on Penso Tecnologia.

Isso acontece porque a validação do funcionamento de um código não comprova sua segurança. Uma funcionalidade pode executar exatamente o que foi solicitado e apresentar falhas que só se tornam evidentes diante de tentativas de exploração.

A gravidade desse risco fica mais evidente diante dos dados do Verizon Data Breach Investigations Report (DBIR) 2026: a exploração de vulnerabilidades ultrapassou o uso de credenciais comprometidas e se tornou o principal vetor conhecido de acesso inicial nas violações analisadas.

Por que a inteligência artificial pode gerar código vulnerável?

Ferramentas de IA generativa produzem código a partir de padrões aprendidos e das instruções fornecidas pelos usuários. Embora consigam entregar implementações funcionais, podem reproduzir práticas inseguras quando requisitos de proteção não são considerados.

Entre as vulnerabilidades que podem aparecer no código gerado estão:

• Falhas de validação e injeção: entradas manipuladas podem provocar consultas indevidas ou operações não autorizadas.
• Credenciais expostas: senhas, tokens e chaves incorporados ao código podem permitir acessos indevidos quando compartilhados ou comprometidos.
• Controles de acesso insuficientes: falhas de autorização podem permitir que usuários consultem ou modifiquem informações além de suas permissões.

Imagine um portal desenvolvido com apoio de IA que autentica usuários e apresenta documentos normalmente. Uma falha na verificação de permissões, porém, permite acessar registros de outras contas.

Nesse caso, o código atende à funcionalidade solicitada, mas contém uma vulnerabilidade que pode expor informações confidenciais.

Por que essas vulnerabilidades passam pela revisão e chegam à produção?

A chegada de código vulnerável à produção está relacionada à forma como as organizações incorporam implementações geradas por IA aos seus processos de desenvolvimento.

Testes funcionais verificam se uma aplicação executa as tarefas previstas. Entretanto, podem deixar de identificar fragilidades relacionadas à proteção de informações, às permissões de acesso e à comunicação entre sistemas.

Em uma integração corporativa, por exemplo, o código pode transferir dados corretamente, mas utilizar credenciais com permissões excessivas ou aceitar solicitações sem validação adequada.

Se a aprovação considerar apenas o funcionamento da integração, a falha pode ser incorporada ao ambiente produtivo e expor sistemas conectados.

O aumento da velocidade de desenvolvimento torna esse processo mais sensível. Quanto maior o volume de implementações, maior a necessidade de estabelecer critérios claros sobre quais verificações devem ocorrer antes da publicação.

Para CIOs, CTOs e CISOs, o desafio está em assegurar que a produtividade proporcionada pela IA não reduza o rigor da validação de segurança, especialmente em aplicações que processam dados sensíveis ou sustentam operações críticas.

O que o DBIR 2026 revela sobre os riscos dessas falhas em produção?

O Verizon DBIR 2026 identifica a exploração de vulnerabilidades como o principal vetor conhecido de acesso inicial, representando 31% dos casos no recorte analisado.

O dado reforça a importância de impedir que falhas exploráveis permaneçam disponíveis em sistemas e aplicações corporativas.

O relatório também documenta o uso de inteligência artificial em atividades ofensivas, incluindo pesquisa sobre vulnerabilidades e desenvolvimento de recursos utilizados em ataques.

Isso amplia a pressão sobre as equipes de segurança: enquanto aplicações são publicadas em ciclos mais curtos, atacantes utilizam automação para acelerar determinadas atividades.

O DBIR não estabelece uma relação causal direta entre código gerado por IA e o crescimento da exploração de vulnerabilidades. Entretanto, seus resultados evidenciam a gravidade de permitir que aplicações sejam disponibilizadas com falhas conhecidas.

Incidentes envolvendo vulnerabilidades críticas em tecnologias amplamente utilizadas demonstram como problemas em componentes de aplicações podem exigir medidas urgentes de avaliação e correção.

Shadow AI pode dificultar a identificação dos riscos no desenvolvimento

A utilização de ferramentas de IA fora dos processos autorizados acrescenta outra dificuldade: a organização pode não ter visibilidade suficiente sobre como o código está sendo produzido e quais informações são compartilhadas durante esse processo.

O DBIR 2026 identifica a Shadow AI como a terceira ação interna não maliciosa mais frequente no conjunto de eventos de prevenção contra perda de dados analisado, com crescimento de quatro vezes em participação percentual.

No desenvolvimento, esse comportamento pode envolver o envio de código-fonte, informações sobre sistemas internos e detalhes de integrações para plataformas externas não homologadas.

Além da possível exposição de informações, o uso não supervisionado dessas ferramentas dificulta a aplicação consistente de critérios de segurança sobre o código gerado.

A necessidade de governança sobre o uso de inteligência artificial se torna relevante para estabelecer responsabilidades e dar visibilidade à utilização dessas tecnologias.

Como identificar vulnerabilidades antes que sejam exploradas?

Quando códigos vulneráveis chegam à produção, a organização precisa identificar as falhas existentes e avaliar sua exposição a possíveis ataques.

O Pentest permite realizar testes controlados para identificar vulnerabilidades exploráveis em aplicações, sistemas e infraestrutura. Os resultados contribuem para compreender os riscos e priorizar correções conforme a criticidade dos ambientes.

Esse trabalho complementa a gestão de vulnerabilidades, especialmente em aplicações sujeitas a atualizações e integrações frequentes.

O Firewall as a Service acrescenta controles de proteção e inspeção de tráfego, conforme a arquitetura e os recursos contratados, apoiando a restrição de acessos indevidos e a aplicação de políticas de segurança.

Em aplicações web, mecanismos específicos, como o Web Application Firewall (WAF), podem complementar essa proteção contra determinados padrões de requisições maliciosas.

Esses recursos ajudam a identificar e reduzir a exposição de ambientes corporativos, mas precisam atuar em conjunto com práticas de desenvolvimento seguro e correção de falhas no código.

A Penso oferece soluções de Pentest e Firewall as a Service para apoiar organizações na identificação de riscos e na proteção de aplicações e infraestrutura.

O que as empresas precisam mudar para evitar a publicação de código vulnerável?

Para as lideranças de tecnologia, a prioridade está em estabelecer critérios de segurança que orientem a avaliação e a aprovação de aplicações antes de sua entrada em produção, independentemente de terem sido desenvolvidas com apoio de IA.

Essa responsabilidade também exige visibilidade sobre as ferramentas utilizadas pelas equipes e as informações compartilhadas com plataformas externas. 

Sem esse controle, a organização pode ter dificuldades para identificar exposições, aplicar suas políticas de segurança e avaliar os riscos associados ao desenvolvimento assistido por inteligência artificial.

Penso, a gente resolve.

The post Código gerado por IA: por que vulnerabilidades estão chegando à produção? appeared first on Penso Tecnologia.

O resultado reúne quatro especializações reconhecidas pela Veeam, abrangendo a proteção de dados em aplicações SaaS, ambientes Kubernetes, nuvens públicas e estratégias de cybersegurança e Disaster Recovery.

O que representa conquistar todas as competências Veeam?

O Veeam Competency Program reconhece parceiros que atendem a requisitos de qualificação em áreas específicas de proteção e recuperação de dados, permitindo identificar empresas com conhecimentos especializados nas tecnologias da fabricante.

Na modalidade Value-Added Reseller (VAR), o programa contempla quatro competências: SaaS Protection, Cybersecurity & Disaster Recovery, Kubernetes Data Protection e Public Cloud Protection.

Ao conquistar todas elas, a Penso completa o conjunto de especializações dessa modalidade, com credenciais que contemplam diferentes arquiteturas e necessidades de proteção de dados corporativos.

Quais são os critérios para conquistar uma competência Veeam?

A concessão das competências está condicionada ao cumprimento de requisitos estabelecidos pela Veeam, relacionados à participação no programa de parceiros e à qualificação dos profissionais nas respectivas áreas de especialização.

Esses procedimentos contemplam treinamentos comerciais e técnicos, incluindo as trilhas Veeam Sales Professional (VMSP) e Veeam Technical Sales Professional (VMTSP), além de certificações avançadas em tecnologias Veeam.

Por isso, a obtenção de uma competência constitui uma validação formal da qualificação do parceiro naquela especialidade, oferecendo ao mercado uma referência adicional para a avaliação de fornecedores tecnológicos.

Conheça as quatro competências Veeam conquistadas pela Penso

As duas novas conquistas ampliam o reconhecimento da Penso para ambientes Kubernetes e nuvens públicas, complementando as especializações anteriormente obtidas em SaaS Protection e Cybersecurity & Disaster Recovery.

Kubernetes Data Protection

A competência Kubernetes Data Protection contempla a proteção de aplicações e dados executados em ambientes Kubernetes, tecnologia utilizada para orquestrar aplicações baseadas em contêineres.

Essas arquiteturas exigem estratégias específicas para preservar dados persistentes, configurações e a capacidade de recuperação das aplicações. 

A especialização abrange conhecimentos relacionados à proteção e à mobilidade dessas cargas de trabalho, especialmente relevantes para organizações que utilizam aplicações nativas em nuvem.

Public Cloud Protection

A competência Public Cloud Protection está relacionada à proteção e recuperação de dados e workloads hospedados em plataformas de nuvem pública.

Sua abrangência engloba tecnologias voltadas a backup, retenção e recuperação, considerando as características desses ambientes e as responsabilidades das organizações sobre seus dados.

O reconhecimento atesta a qualificação do parceiro nessa área de especialização da Veeam.

SaaS Protection

A competência SaaS Protection contempla a proteção de informações armazenadas e processadas em aplicações disponibilizadas como serviço, incluindo plataformas corporativas de produtividade e colaboração.

Embora os provedores SaaS sejam responsáveis pela operação de suas plataformas conforme as condições contratadas, as organizações precisam estabelecer políticas próprias de proteção, retenção e recuperação de dados.

Essa especialização já havia sido conquistada pela Penso ao lado de Cybersecurity & Disaster Recovery.

Cybersecurity & Disaster Recovery

A competência Cybersecurity & Disaster Recovery abrange tecnologias relacionadas à proteção de dados diante de incidentes de segurança e à recuperação de ambientes corporativos após interrupções.

Entre as necessidades atendidas estão a proteção das cópias de backup, a identificação de atividades suspeitas e a recuperação de informações e sistemas comprometidos.

A especialização possui relevância para organizações que precisam estruturar estratégias de resiliência de dados e reduzir os impactos operacionais de ataques cibernéticos, falhas tecnológicas e outros eventos de indisponibilidade.

Pioneirismo no Brasil e premiações internacionais ampliam a trajetória da Penso com a Veeam

A conquista integral das competências VAR se soma a um histórico de reconhecimentos da Penso no ecossistema Veeam.

Somos pioneiros no Brasil ao conquistar três competências do programa Veeam Cloud & Service Provider (VCSP), destinado a provedores de serviços:

• BaaS for Microsoft 365: backup e recuperação de dados do Microsoft 365 como serviço.
• DRaaS: recuperação de ambientes corporativos por meio de Disaster Recovery como serviço.
• Off-site Backup for Ransomware Resiliency: proteção de cópias de backup armazenadas fora do ambiente principal, com foco em resiliência contra ransomware.

Essas especializações pertencem ao programa VCSP, modalidade distinta do VAR, com requisitos e finalidades específicos para provedores de serviços.

A trajetória da parceria também inclui os prêmios Veeam Impact VCSP Partner of the Year, recebidos pela Penso em 2024 e 2025, que reconhecem seu desempenho no ecossistema de provedores de serviços da fabricante.

Qual a importância dessas competências para as empresas que buscam proteção de dados?

Para organizações que utilizam aplicações SaaS, nuvens públicas, Kubernetes e sistemas críticos, a qualificação dos parceiros tecnológicos constitui um fator relevante na definição de estratégias de proteção.

As competências Veeam oferecem uma referência formal da especialização reconhecida pela fabricante em cada uma dessas áreas. 

Ao reunir as quatro competências VAR, a Penso amplia o conjunto de credenciais que respaldam sua atuação em projetos de proteção e recuperação de dados corporativos, dando continuidade a uma trajetória de investimentos em capacitação técnica e especialização nas tecnologias Veeam.

Conte com a expertise da Penso para avaliar as necessidades de proteção e recuperação dos dados da sua empresa. 

Converse com nossos especialistas e conheça nossas soluções.

Penso, a gente resolve.

The post Penso conquista 100% das competências Veeam e consolida sua especialização em proteção de dados appeared first on Penso Tecnologia.

Uma semana depois, parte das operações ainda funcionava com restrições.

O alcance do incidente colocou em evidência uma questão crítica para a gestão empresarial: como uma invasão à infraestrutura de TI conseguiu comprometer operações industriais em diferentes unidades da companhia?

Como o LockerGoga comprometeu a infraestrutura da Norsk Hydro?

Embora identificado em 19 de março, o ataque começou meses antes. 

Segundo informações divulgadas pela Microsoft, o acesso inicial ocorreu aproximadamente três meses antes da execução do ransomware, quando um funcionário abriu um e-mail malicioso que aparentava ter sido enviado por um cliente confiável.

Os invasores aproveitaram esse acesso para avançar pela infraestrutura, ampliar seus privilégios e preparar a distribuição do malware.

O papel do Active Directory no ataque

O comprometimento de privilégios administrativos associados ao Active Directory permitiu utilizar recursos de gerenciamento para distribuir o LockerGoga entre servidores e estações de trabalho.

O malware não dependia de propagação automática. Seu alcance estava associado ao uso indevido de permissões elevadas e ferramentas administrativas da infraestrutura corporativa.

Esse mecanismo evidencia o risco de concentrar permissões capazes de alcançar diversos sistemas. 

Para as lideranças de TI e segurança, controlar o acesso privilegiado e limitar seu alcance são medidas essenciais para reduzir a extensão de um comprometimento.

Como o ransomware afetou a produção industrial?

Para conter o ataque, a Norsk Hydro isolou sistemas e reduziu a conectividade entre unidades, restringindo o acesso a aplicações utilizadas na produção e em processos comerciais.

As divisões de energia, produção primária de alumínio e bauxita mantiveram atividades próximas da normalidade, embora com maior dependência de procedimentos manuais.

As operações de produtos extrudados sofreram impactos mais severos, com redução de capacidade e interrupções em determinadas instalações.

Uma semana depois, parte da produção ainda estava comprometida

Em 26 de março, sete dias após a identificação do ataque, a maior parte das operações havia retornado à capacidade normal.

Entretanto, determinadas unidades da divisão Extruded Solutions ainda operavam entre 70% e 80% de sua capacidade. Na área de Building Systems, as atividades permaneciam praticamente paralisadas.

A infraestrutura de TI continuou em recuperação mesmo após a retomada parcial da produção. O incidente também afetou o processamento de pedidos, a produtividade e a capacidade de atendimento.

As diferenças entre as unidades evidenciam a importância de mapear dependências tecnológicas, identificar processos prioritários e prever alternativas operacionais para períodos de indisponibilidade.

Como a Norsk Hydro recuperou seus sistemas sem pagar resgate?

A companhia mobilizou equipes internas, especialistas externos e autoridades norueguesas para investigar o comprometimento, conter a ameaça e reconstruir os ambientes afetados.

A resposta contou com apoio da Microsoft e colaboração de órgãos como o serviço nacional de investigação criminal da Noruega, Kripos, e a Autoridade Nacional de Segurança, NSM.

O papel dos backups na recuperação

A disponibilidade de backups próprios permitiu restaurar dados e sistemas sem utilizar ferramentas de descriptografia dos criminosos.

A reconstrução exigiu remover componentes maliciosos, verificar as condições de segurança e restabelecer gradualmente os serviços necessários à operação.

Com dados recuperáveis e apoio técnico especializado, a empresa conseguiu conduzir a retomada conforme suas prioridades.

A experiência demonstra que a decisão de não pagar um resgate precisa estar sustentada por recursos efetivos de restauração e procedimentos capazes de reconstruir ambientes comprometidos. 

Essa capacidade de recuperar a operação após um ransomware depende da integração entre proteção de dados, infraestrutura e processos de recuperação.

Quanto custou o ataque de ransomware à Norsk Hydro?

No relatório anual de 2019, a Norsk Hydro estimou o impacto financeiro entre 650 milhões e 750 milhões de coroas norueguesas. 

Uma atualização posterior apontou uma estimativa próxima de 800 milhões de coroas, equivalente a dezenas de milhões de dólares.

Os principais impactos envolveram:

• Produção: redução da capacidade operacional e perda de volumes comercializados.
• Processos comerciais: dificuldades no recebimento e processamento de pedidos.
• Infraestrutura: custos de investigação, contenção e reconstrução de sistemas.
• Operação: mobilização de equipes e adoção de procedimentos alternativos.

Parte das perdas contou com cobertura de seguros cibernéticos, mas a indenização não eliminou os efeitos da indisponibilidade.

Para a gestão executiva, os números demonstram como o tempo de paralisação influencia os custos de um incidente. 

Essa relação deve orientar a definição de prioridades de recuperação e a alocação de recursos para proteger processos essenciais.

Quatro medidas para fortalecer a recuperação após um ransomware

A experiência da Norsk Hydro oferece referências para avaliar a capacidade de uma organização de recuperar sistemas e manter atividades essenciais diante de um comprometimento de grande escala.

1. Proteger os backups contra exclusões e alterações

Invasores com acesso privilegiado podem tentar comprometer os repositórios de backup.

Backups imutáveis restringem alterações e exclusões durante períodos de retenção definidos. Cópias isoladas reduzem a exposição aos sistemas comprometidos.

A estratégia deve assegurar a disponibilidade de pontos de restauração mesmo quando o ambiente principal estiver indisponível.

2. Separar os controles administrativos

Os recursos de backup devem possuir controles de acesso independentes dos utilizados na infraestrutura principal.

A separação de privilégios, a autenticação multifator e a segmentação de rede ajudam a limitar o alcance de credenciais comprometidas.

Em ambientes integrados ao Active Directory, também é necessário avaliar as dependências de autenticação e gerenciamento dos sistemas de recuperação.

3. Testar a recuperação de aplicações críticas

Os testes devem verificar a integridade dos dados, a disponibilidade dos recursos computacionais e a sequência de restauração das aplicações, inclusive quando servidores ou serviços de autenticação estiverem indisponíveis.

Dois indicadores orientam o planejamento:

RPO (Recovery Point Objective): perda máxima tolerável de dados, expressa em tempo.

RTO (Recovery Time Objective): objetivo de tempo para restabelecer um serviço após uma interrupção.

Esses parâmetros devem refletir a criticidade de cada aplicação e ser validados periodicamente para verificar se os recursos disponíveis atendem às necessidades operacionais.

4. Integrar Disaster Recovery e resposta a incidentes

A recuperação exige coordenação entre investigação, contenção e retomada dos serviços.

O plano de Disaster Recovery deve estabelecer responsabilidades, recursos necessários, dependências entre aplicações e prioridades de restauração.

Sua integração com a resposta a incidentes permite alinhar decisões técnicas às necessidades do negócio e organizar a retomada das operações.

Sua empresa conseguiria recuperar a operação a tempo de mitigar prejuízos?

A Norsk Hydro conseguiu reconstruir seus sistemas sem pagar o resgate, mas enfrentou prejuízos milionários e interrupções significativas.

O caso reforça a importância de estabelecer prazos de recuperação compatíveis com a criticidade dos processos e com os impactos financeiros que a empresa pode suportar.

Avalie se sua infraestrutura está preparada para recuperar sistemas críticos com agilidade após um ataque de ransomware.

Converse com os especialistas da Penso sobre estratégias de proteção de dados, backup e Disaster Recovery, considerando seus objetivos de recuperação (RPO e RTO) e as prioridades operacionais do negócio.

Penso, a gente resolve.

The post Ataque de Ransomware à Norsk Hydro: Produção Comprometida e Prejuízos Milionários appeared first on Penso Tecnologia.

Na matéria “Entre o hype da IA e a máfia do phishing: as lições dos 10 anos do Cybersecurity Summit”, a cobertura do evento realizado em São Paulo discute como a rápida adoção da inteligência artificial exige governança rigorosa, ao mesmo tempo em que as empresas brasileiras continuam enfrentando ameaças operacionais básicas, como phishing e ransomware. O texto destaca que o Brasil — país mais visado por cibercriminosos na América Latina e entre os cinco mais atacados do mundo — lida com ataques de motivação financeira direta, exploração de brechas em sistemas legados e os riscos da IA agêntica, que amplia e escala falhas humanas ao invés de atuar como uma solução mágica.

Para combater essas vulnerabilidades, especialistas e C-levels enfatizam que as organizações precisam ir além do entusiasmo com novas tecnologias e estruturar estratégias práticas de governança e controle de ativos, priorizando a cibersegurança como métrica central de sobrevivência dos negócios. Especialistas reforçam a importância de manter a visibilidade do parque de dispositivos, classificar modelos de IA por matriz de risco (“defensable by design”) e adotar uma evolução gradual da maturidade de segurança, em vez de projetos excessivamente complexos e inacessíveis para as médias empresas. O debate também destaca que segurança e inovação precisam caminhar juntas, assegurando que o fator humano permaneça no centro das decisões para validar processos críticos. A matéria conclui que, diante da corrida tecnológica, as organizações precisam estar preparadas não apenas para experimentar ferramentas de IA, mas para sustentar bases sólidas de governança, cultura e proteção contínua.

Confira a matéria completa em:

The post CEO da Penso destaca caminhos para a maturidade em cybersegurança appeared first on Penso Tecnologia.

A ferramenta permite resumir reuniões, elaborar documentos, localizar informações, analisar conteúdos e reduzir o tempo dedicado a tarefas operacionais.

Essa capacidade também exige uma pergunta objetiva: como controlar o uso do Microsoft Copilot sem limitar os ganhos de produtividade que justificam sua adoção?

A resposta envolve preparar o ambiente antes da ativação, definir com clareza como a ferramenta será utilizada e acompanhar a expansão do acesso com base nos resultados alcançados.

O Copilot respeita as permissões existentes e facilita o uso desses acessos

O Microsoft Copilot utiliza os conteúdos aos quais o usuário já possui acesso no ambiente do Microsoft 365.

Isso significa que a ferramenta não ignora as permissões configuradas nem concede automaticamente acesso a documentos protegidos.

As respostas são construídas a partir de arquivos, e-mails, reuniões, conversas e demais informações que o usuário já está autorizado a consultar.

Com a inteligência artificial, porém, o esforço necessário para encontrar e relacionar esses conteúdos diminui.

Antes do Copilot, localizar determinada informação podia exigir pesquisas em bibliotecas do SharePoint, consultas a e-mails antigos, navegação por pastas ou conhecimento prévio sobre onde o arquivo estava armazenado.

Agora, o usuário formula uma pergunta em linguagem natural e recebe uma resposta baseada nos conteúdos disponíveis em seu escopo de acesso.

Por isso, acessos excessivos, grupos desatualizados e compartilhamentos herdados passam a ter maior relevância. 

Um documento antes disperso entre diferentes repositórios torna-se mais fácil de localizar, relacionar e utilizar.

O que revisar no Microsoft 365 antes da implantação

A preparação do ambiente deve acontecer antes da ampliação do acesso ao Copilot.

Entre os principais pontos de revisão estão:

• grupos e permissões que permanecem ativos sem necessidade;
• bibliotecas do SharePoint com compartilhamentos excessivamente amplos;
• documentos no OneDrive acessíveis além do necessário;
• equipes do Microsoft Teams vinculadas a projetos encerrados;
• links de compartilhamento que continuam válidos;
• acessos concedidos a convidados externos;
• permissões herdadas que não refletem a função atual do usuário;
• informações confidenciais sem classificação adequada.

Essa análise ajuda a identificar conteúdos disponíveis por conveniência administrativa, e não por uma necessidade real de negócio.

Também permite corrigir acessos antes que o Copilot facilite a descoberta dessas informações.

A revisão deve considerar não apenas quem acessa cada documento, mas também como os compartilhamentos foram concedidos e se ainda correspondem à estrutura atual da organização.

Comece com um projeto-piloto e um grupo bem definido

Liberar o Copilot para toda a organização desde o primeiro momento dificulta a identificação de problemas, a comparação de resultados e o ajuste das permissões.

Um projeto-piloto permite testar a ferramenta em um ambiente mais controlado.

O grupo inicial deve reunir usuários com necessidades claras, atividades recorrentes e acesso a informações cuja estrutura de permissões já tenha sido revisada.

Também é importante incluir funções diferentes, desde que seus casos de uso possam ser acompanhados de forma consistente.

Durante essa etapa, a empresa consegue observar:

• quais tarefas realmente se beneficiam da ferramenta;
• quais dúvidas surgem entre os usuários;
• onde as permissões precisam ser corrigidas;
• quais orientações ainda não estão claras;
• quais recursos geram valor;
• quais funcionalidades apresentam pouca adesão.

O piloto transforma a adoção em um processo de aprendizado, em vez de uma simples distribuição de licenças.

Defina casos de uso ligados a resultados concretos

O projeto-piloto precisa começar com tarefas específicas.

Sem essa definição, cada usuário experimenta a ferramenta de uma forma diferente, dificultando a comparação entre produtividade, qualidade e risco.

Casos de uso adequados para uma etapa inicial incluem:

• preparação de resumos de reuniões;
• elaboração de primeiras versões de documentos;
• organização de tarefas e comunicações;
• pesquisa em bases internas já revisadas;
• consolidação de informações para apresentações;
• localização de conteúdos distribuídos pelo Microsoft 365;
• síntese de documentos acessíveis ao grupo-piloto.

Cada caso deve estar associado a um resultado esperado.

A empresa pode verificar, por exemplo, se o Copilot reduziu o tempo necessário para preparar uma ata, localizar um documento, organizar uma reunião ou estruturar uma apresentação.

Essa abordagem desloca o foco da frequência de uso para o valor gerado em processos concretos.

Quando os usuários sabem para quais atividades o Copilot foi disponibilizado, a adoção ocorre com maior previsibilidade e a empresa reduz o risco de utilizar a ferramenta em situações que ainda não foram avaliadas.

O piloto precisa medir produtividade e riscos

O número de acessos ou de interações com o Copilot não demonstra, sozinho, que a ferramenta melhorou a operação.

A avaliação precisa considerar os resultados obtidos e os problemas identificados durante o uso.

Entre os indicadores de produtividade estão:

• tempo economizado em tarefas recorrentes;
• redução do esforço necessário para localizar informações;
• qualidade das primeiras versões produzidas;
• diminuição de retrabalho;
• adesão aos casos de uso definidos;
• percepção dos usuários sobre a utilidade da ferramenta;
• necessidade de correções manuais;
• volume de suporte solicitado durante o piloto.

A análise também deve registrar situações em que o Copilot localizou informações inesperadas, revelou permissões excessivas ou evidenciou compartilhamentos que já deveriam ter sido encerrados.

Entre os pontos de atenção estão:

• documentos encontrados por usuários que já não deveriam consultá-los;
• grupos com acesso além do necessário;
• links antigos ainda ativos;
• convidados externos mantidos em equipes ou bibliotecas;
• conteúdos sem classificação adequada;
• dúvidas recorrentes sobre os usos autorizados.

Essas ocorrências não indicam necessariamente uma falha do Copilot. Em muitos casos, revelam problemas antigos no ambiente corporativo que se tornaram mais visíveis com a IA.

Cada situação identificada deve gerar uma ação concreta: corrigir uma permissão, encerrar um compartilhamento, ajustar uma orientação ou redefinir o caso de uso.

Além da revisão dos acessos, a empresa precisa manter visibilidade sobre a utilização corporativa da inteligência artificial para identificar mudanças de comportamento e situações que exijam ajustes nas políticas de governança.

Resultados devem orientar a expansão e a distribuição de licenças

A próxima etapa da implantação deve depender das evidências produzidas pelo projeto-piloto.

Quando o grupo inicial apresenta ganhos mensuráveis, baixa incidência de problemas e boa compreensão das regras, a empresa pode ampliar o acesso para novas equipes.

Caso contrário, o ambiente precisa ser corrigido antes do avanço.

A expansão pode priorizar:

• áreas com casos de uso semelhantes aos já validados;
• processos com grande volume de tarefas repetitivas;
• grupos cujas permissões já foram revisadas;
• equipes que concluíram o treinamento;
• atividades com resultados fáceis de acompanhar;
• ambientes com menor exposição de informações críticas.

A distribuição de licenças deve seguir a mesma lógica.

Conceder acesso de forma ampla antes de conhecer a demanda pode aumentar custos sem produzir ganhos equivalentes.

Os resultados do piloto ajudam a identificar quais funções utilizam o Copilot com frequência, quais tarefas justificam o investimento e quais áreas ainda não possuem processos preparados para aproveitar a ferramenta.

Cada nova etapa deve repetir o mesmo ciclo: revisar acessos, definir casos de uso, medir resultados e corrigir problemas.

The post Como controlar o uso do Microsoft Copilot sem prejudicar a produtividade appeared first on Penso Tecnologia.

Embora a investigação ainda estivesse em andamento nos comunicados de 30 de outubro, uma hipótese já merecia atenção das lideranças de TI: o comprometimento de um computador teria permitido alcançar um serviço responsável por movimentar recursos.

O que a Binance informou sobre o ataque

Segundo a corretora, a investigação inicial indicava que o notebook comprometido de um engenheiro de DevOps teria permitido a um invasor acessar um contêiner de serviço e enviar transações de saque não autorizadas.

A empresa estimou o impacto em US$ 6,3 bilhões e informou que aproximadamente US$ 3 bilhões em ativos haviam sido congelados com apoio de parceiros. O congelamento restringe a movimentação desses recursos, mas não equivale à sua recuperação definitiva.

A Binance também declarou não ter encontrado evidências de vazamento das chaves privadas das carteiras e afirmou que cobriria as perdas com recursos próprios e de seu fundo de proteção aos usuários, o SAFU.

Após suspender depósitos e saques preventivamente, a corretora anunciou a normalização dos depósitos. Na atualização consultada de 30 de outubro, os saques permaneciam interrompidos, com previsão de retomada em até 48 horas.

A causa completa e o percurso do ataque ainda dependiam da conclusão da análise técnica. Portanto, a hipótese sobre o notebook não permite atribuir o incidente a erro humano, phishing ou ausência de um controle específico.

O que um computador comprometido consegue alcançar na sua empresa?

Profissionais de desenvolvimento e infraestrutura utilizam ferramentas com acesso a servidores, aplicações e ambientes de produção. Dependendo da arquitetura, uma estação comprometida oferece ao invasor oportunidades para explorar sessões autenticadas, credenciais ou permissões já disponíveis.

O risco depende tanto da proteção do dispositivo quanto do alcance desses acessos. Uma conta autorizada a executar tarefas administrativas exige restrições e monitoramento compatíveis com o impacto das ações que consegue realizar.

A questão para a gestão é identificar quais barreiras permanecem eficazes quando um dispositivo ou uma identidade deixa de ser confiável.

Essa avaliação deve considerar o caminho entre o acesso inicial e os processos essenciais do negócio: movimentações financeiras, bases de clientes, sistemas de produção e ferramentas de administração. A existência de controles precisa ser acompanhada de evidências de que eles funcionam em conjunto.

Três frentes para limitar o alcance de um incidente

Proteção dos dispositivos e das identidades

Atualizações, proteção de endpoints e monitoramento de comportamentos suspeitos ajudam a reduzir a exposição das estações de trabalho. O controle de identidades deve acompanhar essa proteção, com autenticação adequada, revisão de permissões e capacidade de revogar sessões e acessos comprometidos.

A autenticação multifator é uma camada relevante, mas sua presença não encerra a análise. Sessões já autenticadas e permissões excessivas também precisam entrar na avaliação.

Restrição de privilégios e segmentação

Os acessos devem corresponder às necessidades de cada função. Separar contas administrativas das contas de uso cotidiano e restringir a comunicação entre ambientes reduz as possibilidades de avanço após uma invasão.

Processos sensíveis também exigem controles próprios de autorização e verificação. O comprometimento de uma estação não deveria, por si só, conceder acesso irrestrito às operações mais críticas da organização.

Detecção e contenção testadas

Registros de acesso, alterações de privilégios e operações fora do padrão precisam produzir sinais que a equipe consiga investigar e tratar. A resposta exige responsáveis definidos e procedimentos para isolar dispositivos, bloquear contas e restringir serviços.

Testes de segurança ajudam a verificar se essas barreiras resistem a cenários reais e onde existem caminhos de acesso que precisam ser corrigidos.

Suspender um serviço também é uma decisão de negócio

A interrupção dos saques mostra que a contenção de um incidente tem consequências operacionais. Mesmo quando necessária para limitar perdas, a suspensão afeta clientes, compromissos e confiança.

Por isso, o plano de resposta deve estabelecer quem decide pela interrupção, quais dependências serão afetadas e como a organização comunicará a situação. A retomada precisa seguir critérios técnicos de segurança, além da pressão por restabelecer o atendimento.

Para a diretoria, isso significa avaliar previamente o impacto de diferentes cenários e dar às equipes condições para agir com rapidez e responsabilidade.

Como a Penso apoia a proteção e a recuperação de operações críticas

Uma resposta completa precisa contemplar a contenção do ataque e as condições para restabelecer os serviços com segurança. Quando sistemas precisam ser isolados, a organização deve conhecer suas prioridades de recuperação, as dependências entre aplicações e o tempo de interrupção tolerável para cada processo.

O Disaster Recovery da Penso apoia o planejamento e a recuperação de ambientes críticos diante de incidentes e indisponibilidades. A estratégia considera objetivos de tempo de recuperação e de perda aceitável de dados, infraestrutura de contingência e testes que ajudam a verificar a capacidade de retomada.

Em um incidente de cybersegurança, essa recuperação exige validar a integridade dos ambientes e tratar os acessos comprometidos antes de restabelecer a operação. A disponibilidade do ambiente de contingência precisa estar acompanhada de condições seguras para utilizá-lo.

Na prevenção, soluções de firewall e serviços gerenciados de cybersegurança ajudam a controlar a exposição da infraestrutura. O Penso Threat Scan complementa essa atuação com análises recorrentes de vulnerabilidades conhecidas, orientando a priorização das correções.

O caso Binance evidencia o impacto de interromper serviços essenciais durante uma investigação. Para as empresas, preparar a recuperação significa definir antecipadamente quais operações precisam voltar primeiro, em quanto tempo e sob quais condições de segurança.

Fale com a Penso para avaliar as vulnerabilidades e os controles de segurança da sua infraestrutura.

*Informações sobre o incidente baseadas nos comunicados da Binance de 30 de outubro de 2026. Valores, hipóteses e situação dos serviços refletem as atualizações consultadas.

The post Ataque à Binance: impacto estimado em US$ 6,3 bilhões expõe riscos de acesso a sistemas críticos appeared first on Penso Tecnologia.

Quando um ataque de ransomware atinge os sistemas que sustentam a operação, a emissão de notas fiscais, o atendimento e as entregas podem ser afetados.

Enquanto o negócio acumula as consequências da indisponibilidade, a empresa precisa investigar a invasão, conter o comprometimento e recuperar o ambiente com segurança. As despesas de resposta se somam às perdas da operação interrompida. ^{[6] [2]}

A resposta exige conhecer as dependências entre sistemas, serviços e áreas de negócio. Identificar quais processos podem parar, como os acessos são protegidos e o que os testes de recuperação já demonstraram permite à liderança avaliar a exposição e dar prioridade aos investimentos em continuidade.

Como o phishing pode abrir caminho para o ransomware

O phishing explora a confiança em uma comunicação aparentemente legítima para induzir a entrega de credenciais ou a execução de um arquivo malicioso.

Um falso aviso de segurança, por exemplo, pode direcionar o usuário a uma página de login criada para capturar sua identificação e senha. A conta comprometida ou o programa instalado dessa forma pode oferecer aos invasores um ponto de entrada no ambiente corporativo. ^[5]

Com esse acesso, os atacantes podem buscar outros sistemas, copiar informações e criptografar arquivos para exigir um resgate. A ameaça de divulgar os dados roubados também pode ser usada para pressionar a empresa. A estratégia de proteção precisa considerar o bloqueio dos sistemas e a exposição das informações, pois ambos podem ampliar as consequências do incidente. ^[3]

O phishing é um dos caminhos possíveis para o ransomware. A CISA também descreve a exploração de vulnerabilidades em sistemas expostos à internet e o comprometimento de acessos remotos entre os vetores de entrada. A preparação da empresa precisa abranger as diferentes formas de acesso utilizadas no ambiente. ^[3]

Onde o prejuízo se acumula enquanto a operação está parada

A cada período de indisponibilidade, a empresa pode acumular atrasos, perda de produtividade e interrupções no atendimento.

Ao mesmo tempo, precisa mobilizar recursos para investigar o ataque, conter seu avanço, comunicar o incidente e recuperar o ambiente. Para dimensionar esse impacto financeiro, é necessário considerar a duração da parada e os processos atingidos. ^[2]

A IBM organiza os custos de uma violação de dados em quatro grupos: detecção e investigação, notificações, resposta após a violação e perda de negócios.

Essa composição ajuda a dimensionar o esforço exigido de TI, operação, atendimento e gestão, incluindo consequências que se estendem além das despesas de recuperação técnica. ^[2]

Como interpretar o custo médio de US$ 4,99 milhões por violação

O Cost of a Data Breach Report 2026, da IBM, registra custo médio global de US$ 4,99 milhões por violação de dados. O levantamento reúne 602 organizações que sofreram violações entre março de 2025 e fevereiro de 2026.

Esse valor abrange diferentes causas de violação e serve como referência geral de impacto econômico. Seu uso exige preservar esse recorte, sem tratá-lo como custo específico de ransomware ou como valor de resgate. ^[1]

Em saúde, a média chegou a US$ 6,64 milhões. Nos serviços financeiros, ficou em aproximadamente US$ 6,3 milhões. Para empresas desses setores, a continuidade de serviços críticos e a proteção de informações sensíveis precisam integrar a avaliação de risco e o planejamento da recuperação. ^{[2] [1]}

Para estimar a exposição da sua empresa, direção e TI precisam relacionar cada sistema aos serviços que ele sustenta, às perdas que uma interrupção pode causar e aos recursos necessários à retomada.

Documentar as premissas e as dependências entre áreas permite justificar prioridades de investimento, dimensionar a recuperação e discutir os riscos com a gestão a partir da realidade da operação.

O que a liderança precisa verificar antes de um incidente

A preparação começa com um levantamento dos serviços críticos, de seus responsáveis e dos sistemas necessários para mantê-los funcionando. Com essas informações, a empresa consegue definir a ordem de recuperação e avaliar, junto às áreas de negócio, o impacto de uma interrupção. ^[3]

1. Proteção dos acessos

Na proteção dos acessos, a CISA recomenda autenticação multifator resistente a phishing, privilégios limitados e treinamento para identificar e reportar mensagens suspeitas. A avaliação desses controles deve mostrar quais serviços estão cobertos e onde ainda existem lacunas que exigem atenção. ^[3]

2. Recuperação e integridade dos dados

Para a recuperação, o NIST recomenda cópias isoladas, testes regulares de restauração e um plano com papéis e decisões definidos.

A integridade dos dados recuperados também precisa ser confiável. O teste deve permitir verificar se os sistemas e as informações necessários ao processo voltaram a funcionar de forma adequada. ^{[4] [6]}

3. Evidências dos testes de recuperação

Ao revisar os testes com a TI, a liderança precisa conhecer o tempo de recuperação observado, as falhas encontradas, as dependências ainda sem solução e os responsáveis pelos ajustes.

Esses registros mostram se a capacidade de retomada demonstrada atende às prioridades da operação e quais limitações precisam de investimento. ^[4]

Na próxima revisão do plano de continuidade, reúna os serviços críticos, os controles de acesso e os resultados dos testes de recuperação. Essa análise dá à direção e à TI condições de identificar os riscos que exigem ação e de direcionar o investimento às limitações concretas de proteção e retomada.

Como a Penso apoia a proteção dos dados e a retomada da operação

Diante do risco de ransomware, a proteção precisa preservar as cópias de segurança e estabelecer um caminho de recuperação para os sistemas que sustentam o negócio. Essas duas frentes devem acompanhar as prioridades de continuidade definidas pela empresa.

A Penso oferece Backup em Nuvem e Backup Imutável com tecnologia Veeam, além de Disaster Recovery como serviço (DRaaS). O backup apoia a proteção e a restauração dos dados; o DRaaS organiza a recuperação de ambientes críticos por meio de um plano documentado e testado. ^{[7] [8]}

Ao avaliar essas soluções, direção e TI podem relacionar os sistemas prioritários, as dependências da operação e os resultados dos testes às necessidades de proteção e recuperação do ambiente.

Converse com os especialistas da Penso para avaliar a proteção das suas cópias e planejar a recuperação dos sistemas que sustentam sua operação.

Penso, a gente resolve.

Fontes e referências

[1] IBM: Comunicado do Cost of a Data Breach Report 2026

[2] IBM: What Is a Data Breach?

[3] CISA, FBI, NSA e MS-ISAC: #StopRansomware Guide

[4] NIST: Tips and Tactics: Preparing Your Organization for Ransomware Attacks

[5] IBM: What Is Phishing?

[6] NIST: SP 1800-11: Recovering from Ransomware and Other Destructive Events

[7] Penso Tecnologia: Veeam Backup: soluções de backup e recuperação

[8] Penso Tecnologia: Veeam Disaster Recovery

The post Phishing e ransomware: uma credencial comprometida pode interromper a sua operação appeared first on Penso Tecnologia.

O acesso ocorreu por meio de credenciais comprometidas em um portal remoto que não exigia autenticação multifator (MFA).

Durante os nove dias seguintes, os invasores permaneceram no ambiente, realizaram movimentações laterais e tiveram acesso a informações sensíveis. 

A intrusão só foi identificada em 21 de fevereiro, quando o ransomware foi implantado e a empresa iniciou medidas emergenciais de contenção.

O resultado foi uma crise de grandes proporções: interrupções no processamento de pagamentos e solicitações médicas, dificuldades na dispensação de medicamentos e exposição de informações pessoais e de saúde de aproximadamente 192,7 milhões de pessoas.

O caso evidencia uma questão crítica para a segurança corporativa: o intervalo entre o acesso indevido e sua identificação pode determinar a extensão do comprometimento e a capacidade de resposta da organização.

Como aconteceu o ataque à Change Healthcare?

A Change Healthcare desempenhava uma função estratégica na infraestrutura de saúde norte-americana, intermediando operações entre hospitais, clínicas, farmácias, seguradoras e outros prestadores de serviços.

Sua plataforma participava de processos como autorização de procedimentos, faturamento, processamento de solicitações de reembolso e transações relacionadas a prescrições médicas.

Essa concentração de serviços tornou o comprometimento especialmente grave, porque milhares de organizações dependiam de sistemas operados pela empresa.

O ataque foi associado ao grupo de ransomware ALPHV/BlackCat, conhecido por operações de extorsão envolvendo criptografia de sistemas e roubo de informações.

Segundo depoimento de Andrew Witty, então CEO da UnitedHealth Group, ao Congresso norte-americano, os criminosos utilizaram credenciais comprometidas para acessar um portal Citrix de conexão remota.

O ponto decisivo foi a ausência de MFA naquele acesso. Com as credenciais em mãos, os invasores conseguiram entrar no ambiente sem precisar superar uma segunda etapa de autenticação.

A cronologia dos nove dias

• 12 de fevereiro de 2024 | Acesso inicial: Credenciais comprometidas permitiram a entrada dos invasores em um portal remoto sem MFA.

• 12 a 20 de fevereiro | Permanência e movimentação lateral: Os criminosos avançaram pelo ambiente e tiveram acesso a dados sensíveis. O grupo ALPHV/BlackCat alegou posteriormente ter extraído aproximadamente 6 TB de informações.

• 21 de fevereiro | Detecção e contenção: A implantação do ransomware levou à identificação do comprometimento. A empresa desconectou sistemas para conter o incidente.

• Março e abril | Resgate e nova extorsão: A UnitedHealth confirmou o pagamento de US$ 22 milhões. Posteriormente, o grupo RansomHub alegou possuir parte dos dados e exigiu um novo pagamento.

• Julho de 2025 | Atualização do alcance: O número de pessoas afetadas informado ao HHS chegou a aproximadamente 192,7 milhões.

A estimativa de 6 TB corresponde à alegação divulgada pelo grupo criminoso e não deve ser tratada como volume independentemente confirmado. 

A tentativa posterior de extorsão pelo RansomHub também foi documentada, embora as alegações do grupo sobre a posse e o volume dos dados tenham exigido investigação.

O impacto: hospitais, clínicas e farmácias com serviços interrompidos

Quando a invasão foi identificada, a Change Healthcare precisou desconectar mais de 100 plataformas tecnológicas para conter o comprometimento.

A medida de contenção afetou processos fundamentais para o funcionamento do setor de saúde.

Hospitais e clínicas enfrentaram dificuldades para processar solicitações de reembolso e receber pagamentos. 

Farmácias precisaram adotar procedimentos alternativos para determinadas transações, enquanto pacientes encontraram obstáculos para obter medicamentos e acessar serviços.

O incidente também expôs a dependência de fornecedores tecnológicos compartilhados por diferentes organizações. 

Mesmo instituições que não tiveram seus próprios sistemas diretamente comprometidos sofreram consequências operacionais devido à indisponibilidade da infraestrutura da Change Healthcare.

A American Hospital Association classificou o episódio como um dos ataques cibernéticos de maior consequência já registrados no sistema de saúde norte-americano.

O pagamento do resgate não encerrou a exposição

A UnitedHealth confirmou o pagamento de US$ 22 milhões aos criminosos responsáveis pelo ataque.

Entretanto, o pagamento não eliminou o risco associado aos dados comprometidos.

Posteriormente, o grupo RansomHub afirmou possuir informações extraídas da Change Healthcare e iniciou uma nova tentativa de extorsão, ameaçando divulgar ou comercializar o material.

O episódio demonstra a dificuldade de assegurar a eliminação de informações que já foram copiadas por agentes maliciosos. 

Uma vez exfiltrados, os dados podem permanecer disponíveis para novas tentativas de extorsão, fraudes e outros usos indevidos.

Por isso, a resposta a um incidente precisa considerar tanto a recuperação dos sistemas quanto a investigação do acesso, a extensão do comprometimento e a proteção das informações afetadas.

Por que o tempo de detecção é tão importante em um ataque de ransomware?

Um dos principais aprendizados do caso Change Healthcare está no período de permanência dos invasores dentro da infraestrutura.

Em operações de ransomware, o comprometimento pode começar muito antes da criptografia dos sistemas.

Após obter acesso inicial, o atacante pode investigar a rede, identificar contas privilegiadas, mapear servidores, buscar informações confidenciais e explorar conexões entre diferentes ambientes.

Esse intervalo é conhecido como dwell time, ou tempo de permanência do invasor.

Quanto maior esse período, maiores podem ser as oportunidades para ampliar privilégios, alcançar aplicações críticas, comprometer credenciais e identificar repositórios de backup.

Entretanto, o tempo de permanência isoladamente não determina a gravidade do ataque. 

O alcance depende também das permissões disponíveis, da segmentação da rede, das vulnerabilidades existentes e dos controles de segurança implementados.

O desafio para as empresas é reduzir o tempo necessário para identificar comportamentos suspeitos e iniciar uma resposta eficaz.

O risco também pode alcançar os backups

Durante uma invasão prolongada, criminosos podem tentar localizar e comprometer mecanismos de recuperação, incluindo servidores de backup, consoles de administração e credenciais com privilégios elevados.

O objetivo pode ser excluir cópias, modificar políticas de retenção, desabilitar tarefas ou dificultar a restauração após a implantação do ransomware.

A existência de backups protegidos, segregados e imutáveis ajuda a limitar essas possibilidades. 

Ainda assim, a recuperação depende de controles de acesso, integridade das cópias, disponibilidade da infraestrutura necessária e testes periódicos de restauração.

No caso Change Healthcare, não há evidência apresentada aqui de que os invasores tenham comprometido especificamente os backups da empresa. 

Esse é um risco técnico associado à permanência prolongada em ambientes corporativos, e merece ser considerado na análise de segurança.

MFA, monitoramento ativo e pentest: três controles para reduzir a exposição

A análise do incidente permite identificar três frentes de proteção que devem integrar uma estratégia corporativa de cybersegurança.

1. MFA: fortalecer a proteção contra o uso indevido de credenciais

A autenticação multifator acrescenta uma etapa de verificação ao processo de acesso, dificultando que uma credencial comprometida seja suficiente para autenticar um invasor.

Sua aplicação deve priorizar acessos remotos, contas administrativas, sistemas críticos e ambientes que armazenam informações sensíveis.

Também é necessário revisar exceções, contas legadas, autenticações de serviço e aplicações que ainda permitem acesso apenas com usuário e senha.

A ausência de MFA no portal utilizado pelos criminosos foi uma das falhas centrais identificadas no caso Change Healthcare.

Embora não elimine todas as possibilidades de comprometimento, especialmente diante de ataques de phishing avançado e sequestro de sessões, o MFA reduz a exposição associada ao roubo de credenciais.

2. Monitoramento ativo: identificar atividades suspeitas antes que o ataque avance

O monitoramento de segurança permite acompanhar eventos relevantes na infraestrutura e identificar indícios de comportamento malicioso.

Entre os sinais que merecem atenção estão autenticações atípicas, alterações inesperadas de privilégios, movimentações laterais, acessos incomuns a servidores e transferências anormais de dados.

Para que esse monitoramento seja efetivo, é necessário combinar coleta de logs, correlação de eventos, critérios de priorização e procedimentos definidos de investigação e resposta.

Também é fundamental estabelecer responsabilidades claras sobre a análise dos alertas e os mecanismos de escalonamento de incidentes.

Um ambiente que gera alertas, mas não dispõe de capacidade adequada para investigá-los, pode continuar exposto por períodos prolongados.

Dois indicadores ajudam a avaliar essa capacidade: o tempo médio de detecção (MTTD) e o tempo médio de resposta (MTTR). 

Ambos devem ser acompanhados conforme a criticidade dos incidentes e os objetivos de segurança da organização.

3. Pentest: identificar caminhos de exploração antes dos criminosos

O teste de intrusão, ou pentest, consiste em uma avaliação controlada da segurança de sistemas, aplicações e infraestrutura.

Seu objetivo é identificar e validar vulnerabilidades que possam ser exploradas por agentes maliciosos, demonstrando os riscos associados às falhas encontradas.

Em ambientes corporativos, um pentest pode avaliar exposições em serviços remotos, configurações inadequadas, falhas de autenticação, possibilidades de escalonamento de privilégios e caminhos de movimentação lateral, conforme o escopo contratado.

Os resultados oferecem informações para priorizar correções com base na possibilidade de exploração e no impacto potencial sobre a operação.

O pentest deve ser realizado periodicamente e após mudanças relevantes na infraestrutura, especialmente quando envolvem novos sistemas, integrações ou mecanismos de acesso.

O que as empresas devem revisar após o caso Change Healthcare?

O episódio demonstra que a avaliação da segurança corporativa precisa considerar a trajetória completa de um ataque, desde a tentativa inicial de acesso até a capacidade de contenção e recuperação.

Para lideranças de tecnologia e segurança, algumas verificações merecem prioridade:

Autenticação e acessos: identificar sistemas sem MFA, contas privilegiadas e mecanismos de acesso remoto que necessitam de controles adicionais.

Visibilidade da infraestrutura: verificar se eventos relevantes são registrados, correlacionados e analisados em tempo adequado.

Superfície de ataque: realizar avaliações periódicas para identificar vulnerabilidades e caminhos de exploração.

Resposta a incidentes: estabelecer procedimentos de investigação, isolamento, comunicação e recuperação, com responsáveis definidos.

Proteção dos backups: avaliar segregação, imutabilidade, permissões administrativas e capacidade comprovada de restauração.

Dependência de terceiros: mapear fornecedores críticos e os impactos que sua indisponibilidade pode provocar sobre processos essenciais.

Essas verificações ajudam a direcionar investimentos e estabelecer prioridades com base na exposição real da organização.

Como a Penso pode apoiar a proteção da infraestrutura corporativa?

O caso Change Healthcare reforça a necessidade de integrar controles preventivos, capacidade de detecção e processos de resposta.

A Penso apoia empresas na avaliação e no fortalecimento da segurança de seus ambientes, considerando a criticidade dos sistemas e os riscos associados à operação.

Entre as frentes que podem compor essa estratégia estão o monitoramento ativo de segurança, os testes de intrusão e a implementação de mecanismos de autenticação multifator.

O monitoramento contribui para identificar atividades suspeitas e direcionar investigações. O pentest permite avaliar vulnerabilidades e oportunidades de exploração. Já o MFA fortalece o controle de acesso a sistemas e recursos corporativos.

A combinação desses mecanismos, associada a políticas de segurança, gestão de privilégios e procedimentos de resposta, contribui para reduzir a exposição e melhorar a capacidade de reação diante de incidentes.

A experiência da Change Healthcare demonstra como uma falha inicial de autenticação, associada a um período prolongado sem detecção, pode resultar em consequências que ultrapassam os limites da infraestrutura comprometida.

Identificar e conter uma invasão antes que ela alcance sistemas críticos deve ser uma prioridade mensurável na estratégia de cybersegurança.

Fale com os especialistas da Penso e conheça as possibilidades de monitoramento ativo, pentest e autenticação multifator para o ambiente da sua empresa.

Penso, a gente resolve.

The post Ataque à Change Healthcare: 9 Dias Sem Detecção e Dados de 192,7 Milhões de Pessoas Comprometidos appeared first on Penso Tecnologia.