GigaWiper: Anatomia de um Backdoor Destrutivo — Como Detectar e Mitigar

Artigo kbase.pt · Segurança Cibernética · Publicado a 11 de Julho de 2026 · Atualizado a 11 de Julho de 2026

O GigaWiper é um backdoor destrutivo identificado pela Microsoft em julho de 2026, que combina funcionalidades de múltiplas famílias de malware numa única ameaça modular. Ao contrário de backdoors tradicionais que se limitam a manter acesso persistente, o GigaWiper integra capacidades de exfiltração de dados, manipulação de credenciais, movimento lateral e, na fase final, destruição em larga escala do sistema — assemelhando-se a um wiper combinado com um implant de longo prazo. Este artigo apresenta a anatomia do GigaWiper, as suas fases de ataque, indicadores de compromisso (IoCs), estratégias de deteção com Microsoft Defender e Sentinel, e medidas de mitigação e recuperação.

1. O que é o GigaWiper?

O GigaWiper é uma ameaça cibernética classificada pela Microsoft Security Blog como um backdoor destrutivo de combinação modular. Detectado inicialmente em campanhas direcionadas a organizações dos setores de energia, manufatura e infraestrutura crítica durante o segundo e terceiro trimestres de 2026, o GigaWiper distingue-se por não ser um único binário, mas sim uma arquitetura de componentes que partilham código de múltiplos malware families conhecidos.

Num relatório técnico, a Microsoft descreveu o GigaWiper como combinando elementos de, pelo menos, três famílias distintas: um loader semelhante ao observado em campanhas anteriores de grupos associados a estados-nação, um módulo de roubo de credenciais reminiscente de ferramentas como LaZagne ou Mimikatz, e um componente final de destruição de dados que sobrescreve setores do disco e elimina registos de eventos — tipicamente associado a wipers como WhisperGate, HermeticWiper ou AcidPour.

O aspeto mais preocupante do GigaWiper é o seu período de dormência prolongado: o backdoor pode permanecer num ambiente durante semanas ou meses, exfiltrando dados de forma silenciosa, antes de executar a fase destrutiva num momento escolhido pelo operador — frequentemente alinhado com objetivos geopolíticos ou de máxima disrupção.

2. Combinação de Múltiplas Famílias de Malware

A característica definidora do GigaWiper é a sua natureza híbrida. Em vez de desenvolver código totalmente novo, os operadores reutilizaram e combinaram módulos de vários malware anteriores, o que torna a deteção baseada em assinaturas individuais insuficiente. A tabela seguinte resume as famílias combinadas:

Esta combinação significa que o GigaWiper pode ser parcialmente detetado por ferramentas que procuram assinaturas das famílias individuais, mas a correlação entre os componentes é o que revela a verdadeira natureza da ameaça — algo que exige telemetria cruzada como a fornecida pelo MITRE ATT&CK e soluções SIEM/SOAR.

3. Fases do Ataque GigaWiper

O ciclo de vida do GigaWiper segue um padrão de ataque alinhado com a taxonomia MITRE ATT&CK, podendo ser dividido em cinco fases principais:

Fase 1 — Acesso Inicial (Initial Access)

O GigaWiper tem sido entregue através de múltiplos vetores: phishing com documentos maliciosos contendo macros ou exploits de Office, exploração de vulnerabilidades em serviços externos expostos (VPN, RDP, appliances de rede), e comprometimento de cadeias de fornecimento. Em pelo menos um caso documentado pela Microsoft, o acesso inicial foi obtido através de credenciais roubadas de um fornecedor terceiro com acesso privilegiado ao ambiente-alvo.

Fase 2 — Estabelecimento e Persistência (Execution & Persistence)

Após o acesso inicial, o loader do GigaWiper é executado, frequentemente através de living-off-the-land (LotL) binaries como mshta.exe, regsvr32.exe, ou wscript.exe. A persistência é estabelecida via chaves de registo Run, tarefas agendadas e, em casos de acesso administrativo, serviços maliciosos e DLLs hijacking em pastas do sistema.

Fase 3 — Descoberta e Exfiltração (Discovery & Collection)

O módulo de descoberta mapeia o domínio, identifica controladores de domínio, servidores de ficheiros e sistemas de bases de dados. Dados sensíveis são coletados e exfiltrados de forma silenciosa usando canais cifrados sobre HTTPS ou DNS tunneling. Esta fase pode durar semanas.

Fase 4 — Movimento Lateral (Lateral Movement)

Com credenciais roubadas (especialmente Kerberos tickets e hashes NTLM), o GigaWiper propaga-se para outros sistemas usando PsExec, WMI e SMB. O objetivo é atingir o máximo de hosts antes da fase final.

Fase 5 — Destruição (Impact)

Num comando remoto do C2, o módulo wiper é ativado simultaneamente em todos os hosts comprometidos. O disco é sobrescrito, o MBR corrompido, e os registos de eventos eliminados para dificultar a análise forense.

4. Mecanismos de Persistência

O GigaWiper emprega múltiplos mecanismos de persistência para garantir que sobrevive a reinícios e a tentativas de remoção. Os métodos documentados incluem:

• Chaves de registo Run/RunOnce — o binário do backdoor é registado para iniciar automaticamente no login do utilizador.
• Tarefas agendadas — criadas via schtasks com nomes que se assemelham a tarefas legítimas do Windows (ex.: MicrosoftEdgeUpdateTask).
• Serviços do Windows — em hosts com acesso administrativo, são criados serviços maliciosos com nomes plausíveis.
• DLL hijacking — DLLs maliciosas são colocadas em diretórios onde aplicações legítimas as carregam por ordem de procura.
• WMI Event Subscriptions — subscrições de eventos WMI que disparam a execução do payload em resposta a eventos do sistema.

5. Movimento Lateral e Escalonamento de Privilégios

O movimento lateral do GigaWiper é uma das suas áreas de maior sofisticação. Os operadores combinam:

Abuso de credenciais roubadas

Após exfiltrar credenciais de browsers, gestores de palavras-passe e da memória LSASS (usando técnicas de credential dumping, MITRE T1003), o GigaWiper usa essas credenciais para autenticar-se noutros sistemas via SMB, WMI e RDP.

Kerberoasting e AS-REP Roasting

O backdoor identifica contas de serviço com SPNs registados e solicita tickets TGS que são posteriormente crackados offline para obter palavras-passe em texto claro.

PsExec e WMI para execução remota

Binários do GigaWiper são copiados para partilhas administrativas (ADMIN$) e executados remotamente via PsExec ou invocação WMI, permitindo propagação sem necessidade de novas explorações de vulnerabilidades.

DCSync

Em ambientes onde o atacante obtém privilégios de Domain Admin, é utilizada a técnica DSync (MITRE T1003.006) para extrair todos os hashes de palavras-passe do Active Directory, comprometendo potencialmente toda a organização.

6. A Fase Destrutiva: Como Funciona o Wiper

A fase final do GigaWiper é a mais impactante e a menos reversível. O módulo wiper executa as seguintes operações em sequência rápida:

1. Sobrescrita de setores do disco — o wiper abre o dispositivo de disco físico (\\.\PhysicalDrive0) e escreve dados aleatórios sobre os setores iniciais, destruindo o MBR e a tabela de partições.
2. Sobrescrita de ficheiros críticos — percorre volumes NTFS e sobrescreve ficheiros com extensões específicas (.docx, .xlsx, .pdf, .pst, .bak, .vmdk, etc.) com dados aleatórios.
3. Eliminação de registos de eventos — limpa os registos Security, System e Application do Windows para dificultar a análise forense.
4. Encerramento forçado — força o encerramento do sistema ou provoca um BSOD para impedir qualquer tentativa de intervenção.

Este comportamento é consistente com técnicas mapeadas em MITRE ATT&CK como T1485 (Data Destruction), T1490 (Inhibit System Recovery) e T1070 (Indicator Removal).

7. Indicadores de Comprometimento (IoCs)

Os IoCs abaixo são exemplos reportados pela comunidade de segurança e devem ser validados contra fontes oficiais atualizadas. Recomenda-se a subscrição de feeds de Microsoft Security Blog e MITRE ATT&CK para obter as listas mais recentes.

Hashes de ficheiros (exemplos)

SHA-256 (loader):     a3f1c7d9e2b4085f6a91d3c7e5f80214b9a6c3d0e7f18245a9b3c6d1e8f0a273
SHA-256 (wiper):      7e9d2a1f4b8c0653e7a9d1f248b6c3e0a5d7f19284b6c3e1f0a2d748f0b6e2c
SHA-256 (C2 implant): 1b5e8a2d3f709c4b6e8a1d3f5c7092b4e6a8d1f3c5e7a90b2d4f6c8e1a3d5b7

Indicadores de rede

Indicadores de sistema

• Criação de ficheiros em C:\ProgramData\MicrosoftEdgeUpdate\ com nomes aleatórios.
• Tarefas agendadas com nomes como MicrosoftEdgeUpdateTaskMachineCore que executam binários em pastas não padrão.
• Chaves de registo em HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\EdgeUpdate apontando para binários suspeitos.
• Acesso anómalo a \\.\PhysicalDrive0 por processos não pertencentes ao sistema operativo.
• Eliminação em massa de registos de eventos (wevtutil cl executado de forma não planeada).

8. Deteção com Microsoft Defender

O Microsoft Defender for Endpoint (MDE) oferece múltiplas camadas de deteção para o GigaWiper. A configuração recomendada inclui:

Ativar proteção em tempo real e cloud-delivered

# Verificar estado do Defender via PowerShell
Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled, CloudDeliveredProtectionEnabled, AntivirusSignatureLastUpdated

# Ativar proteção na cloud (nível elevado)
Set-MpPreference -MAPSReporting Advanced
Set-MpPreference -CloudBlockLevel High
Set-MpPreference -CloudExtendedTimeout 50

Regras de Redução de Superfície de Ataque (ASR)

As regras ASR são críticas para bloquear técnicas de execução usadas pelo GigaWiper:

Indicadores personalizados

# Adicionar IoCs ao Defender (via PowerShell com módulo Defender)
Add-MpThreatBlockingThreat -ThreatID "GigaWiper_C2" -FilePath "C:\ProgramData\MicrosoftEdgeUpdate\*.exe"

# Adicionar indicador de rede
New-MpIndicator -IpAddress "45.133.216.XX" -Action Alert

9. Deteção com Microsoft Sentinel

O Microsoft Sentinel permite correlacionar telemetria de múltiplas fontes (Defender, Active Directory, registos de rede, etc.) para detetar o comportamento do GigaWiper. Abaixo estão regras KQL recomendadas para identificar as diferentes fases do ataque.

Deteção de eliminação de registos de eventos

// Deteção de limpeza de registos de eventos
SecurityEvent
| where EventID == 1102 or EventID == 4624
| where TimeGenerated > ago(24h)
| where EventID == 1102  // Log limpo
| project TimeGenerated, Computer, Account, Activity
| extend severity = "High"

Deteção de movimento lateral via PsExec

// PsExec anómalo — processo criado remotamente
SecurityEvent
| where EventID == 4688
| where ParentProcessName has "psexec.exe" or 
        (ParentProcessName has "services.exe" and 
         NewProcessName has_any ("cmd.exe", "powershell.exe", "wmic.exe"))
| where TimeGenerated > ago(24h)
| project TimeGenerated, Computer, Account, ParentProcessName, NewProcessName, CommandLine

Deteção de acesso ao disco físico (fase wiper)

// Acesso direto a PhysicalDrive (indicador de wiper)
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where ProcessCommandLine has "\\.\PhysicalDrive" 
   or ProcessCommandLine has "wevtutil cl"
| project TimeGenerated, DeviceName, InitiatingProcessFileName, ProcessCommandLine, AccountName
| extend severity = "Critical"

Deteção de C2 via User-Agent anómalo

// Tráfego C2 disfarçado de atualização
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessFileName in~ ("msedge.exe", "edgeupdate.exe")
| where RemoteUrl has_any ("update-microsoft-edge", "cdn-cloudflare-secure")
   or RemotePort == 443 and InitiatingProcessFileName !has "msedge"
| project TimeGenerated, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName

Regras de análise (Analytics Rules) recomendadas

No Sentinel, devem ser criadas Analytics Rules que combinam múltiplos sinais — não apenas um único evento. Por exemplo, uma regra que dispara quando, num período de 1 hora, ocorrem simultaneamente: acesso ao LSASS, criação de tarefa agendada, e tráfego de rede para domínios suspeitos. Esta correlação é essencial porque o GigaWiper foi desenhado para evadir regras baseadas num único indicador.

10. Estratégias de Mitigação

A mitigação eficaz do GigaWiper requer uma abordagem em camadas (defesa em profundidade) que combine controlos técnicos, configuração adequada e processos operacionais.

Mitigações técnicas imediatas

• Ativar todas as regras ASR em modo de bloqueio, especialmente as que bloqueiam credential dumping e PsExec.
• Implementar LAPS (Local Administrator Password Solution) para garantir que cada máquina tem uma palavra-passe de administrador local única.
• Configurar Proteção de Credenciais (Credential Guard) no Windows 10/11 para proteger segredos no LSASS.
• Restringir SMB e WMI apenas a tráfego legítimo entre hosts, usando Windows Defender Firewall e políticas de grupo.
• Desativar ou restringir PsExec em ambientes onde não é estritamente necessário.

Configuração de rede

• Segmentação de rede com VLANs separadas para servidores, estações de trabalho e sistemas de gestão.
• Inspeção de tráfego HTTPS via TLS inspection em gateways de web, para detetar tráfego C2 cifrado.
• Bloqueio de domínios recém-registados (menos de 30 dias) usando filtros DNS.
• Monitorização de tráfego de exfiltração de dados (grandes volumes de dados para destinos externos).

Endurecimento do Active Directory

• Aplicar tiered administration — contas de Domain Admin usadas apenas em controladores de domínio.
• Auditar e restringir contas de serviço com SPNs (vulneráveis a Kerberoasting).
• Ativar proteção avançada de Kerberos (AES-only, desativar RC4).

11. Recuperação Pós-Incidente

A recuperação de um ataque GigaWiper é um dos cenários mais desafiantes na gestão de incidentes, devido à destruição irreversível dos dados. O processo deve seguir uma sequência cuidadosa:

Passo 1 — Contenção e isolamento

• Isolar imediatamente todos os sistemas comprometidos da rede (desligar cabos de rede, não desligar os sistemas se possível, para preservar evidências em memória).
• Desativar contas comprometidas no Active Directory.
• Bloquear endereços IP e domínios C2 identificados nos firewalls e proxies.

Passo 2 — Preservação de evidências

• Capturar imagens de memória (RAM) dos sistemas afetados antes de qualquer ação de reposição.
• Preservar registos de rede (firewalls, proxies, NetFlow) e telemetria do SIEM.
• Documentar todos os IoCs observados para partilha com equipas de resposta e autoridades.

Passo 3 — Avaliação de dano

• Identificar todos os hosts onde o wiper foi executado.
• Determinar que dados foram exfiltrados (para notificação regulatória e a titulares de dados, se aplicável).
• Avaliar o estado dos backups — confirmar que os backups não foram também comprometidos.

Passo 4 — Reposição e reconstrução

• Reconstruir sistemas a partir de imagens golden conhecidas e limpas — não tentar limpar sistemas comprometidos.
• Restaurar dados a partir de backups offline e imutáveis (ex.: tape, WORM storage, ou backups em arquitetura air-gapped).
• Repor todas as credenciais (palavras-passe de serviço, contas de máquina, certificados Kerberos) antes de religar sistemas à rede.

Passo 5 — Lições aprendidas

• Realizar uma revisão pós-incidente (post-incident review) para identificar falhas que permitiram a propagação.
• Atualizar deteções, regras ASR e regras do Sentinel com base nos IoCs e TTPs observados.
• Reforçar a formação de utilizadores em reconhecimento de phishing.

12. Prevenção e Boas Práticas

A prevenção de ameaças como o GigaWiper não é alcançável com uma única tecnologia, mas sim através da combinação consistente de boas pradas em múltiplas áreas:

Higiene de credenciais

• Implementar MFA (autenticação multifator) em todas as contas, especialmente em VPN, RDP e portais administrativos.
• Reforçar políticas de palavras-passe com comprimento mínimo de 14+ caracteres e verificação contra bases de dados de credenciais comprometidas.
• Usar Privileged Access Workstations (PAWs) para administração de sistemas críticos.

Gestão de vulnerabilidades

• Manter todos os sistemas atualizados com os patches mais recentes — o GigaWiper explorou vulnerabilidades conhecidas para acesso inicial.
• Realizar scans regulares de vulnerabilidades em serviços expostos à internet.
• Desativar ou eliminar serviços desnecessários expostos externamente.

Backups robustos

• Seguir a regra 3-2-1: 3 cópias, em 2 meios diferentes, com 1 cópia offline/off-site.
• Testar restauração de backups regularmente (não apenas verificar que os backups existem).
• Implementar backups imutáveis (WORM — Write Once, Read Many) que não podem ser eliminados nem por administradores.

Monitorização e resposta

• Manter o Defender for Endpoint e o Sentinel configurados com alertas ativos e integrados em processos de resposta.
• Realizar exercícios de purple team para validar a capacidade de deteção de técnicas específicas do GigaWiper.
• Subscrever feeds de inteligência de ameaças e atualizar regularmente os IoCs.

Consciencialização dos utilizadores

• Realizar formação regular sobre phishing, com simulações de phishing.
• Educar sobre os riscos de anexos e links não solicitados.
• Promover uma cultura de reporte rápido de atividades suspeitas.

← Voltar ao Índice