Introdução
Instituições de ensino são alvos frequentes de cibercriminosos devido à quantidade de dados que podem ser obtidos e ao grande impacto que ataques bem-sucedidos podem causar. Escolas e universidades públicas e privadas dependem de software para gerenciar PII (informações pessoais identificáveis), que muitas vezes não é seguro ou não foi suficientemente testado contra vulnerabilidades conhecidas. Além disso, máquinas usadas por várias pessoas sem possibilidade de responsabilização podem se tornar alvos de ameaças internas.
Esse risco é ampliado pela complexidade dos ambientes acadêmicos. Ao contrário das redes corporativas, as instituições de ensino precisam oferecer uma infraestrutura de rede que atenda alunos, professores, pesquisadores, equipes administrativas, prestadores de serviços terceirizados e visitantes. Cada um desses grupos tem requisitos de segurança e níveis de acesso diferentes, o que aumenta a dificuldade em se aplicar políticas de segurança de forma consistente.
As consequências de uma violação podem ser graves, já que um comprometimento bem-sucedido pode expor milhares de informações confidenciais, como CPFs, endereços, números de telefone e até mesmo os nomes dos pais. Com essas informações em mãos, os invasores podem realizar ataques de phishing, além de se passarem pelas vítimas em ataques de troca de chip (SIM swap), uma prática comum no Brasil.
Neste artigo, apresentamos detalhes sobre os ataques observados pelo nosso Global Emergency Response Team (GERT) contra instituições de ensino no Brasil desde 2025. Compartilhamos estatísticas gerais, as ameaças mais comuns, os vetores de acesso inicial e os impactos causados por essas violações. Além disso, destacamos casos interessantes enfrentados por nossa equipe e as TTPs identificadas. Por fim, fornecemos recomendações para que as instituições possam se proteger contra ataques futuros.
Principais descobertas e estatísticas
Nosso conjunto de dados abrange casos de resposta a incidentes ocorridos entre janeiro de 2025 e junho de 2026. Como exposto no gráfico abaixo, a maioria dos ataques tiveram como alvos instituições do estado de São Paulo, que concentra a maior parte da população do Brasil e uma parcela significativa da atividade econômica e financeira do país. Também registramos casos no Rio de Janeiro e em Pernambuco.
Distribuição geográfica de solicitações de resposta a incidentes em instituições de ensino (download)
Entre os clientes que solicitaram serviços de resposta a incidentes, 60% eram instituições privadas e 40%, instituições públicas.
Instituições públicas e privadas (download)
Os motivos mais comuns para solicitar serviços de resposta a incidentes estão associados a atividades suspeitas em endpoints, arquivos criptografados e a presença de artefatos suspeitos.
Motivos da solicitação de resposta a incidentes (download)
Os incidentes de alta severidade representaram 40% dos casos; os de média severidade, os 60% restantes.
Distribuição de incidentes por gravidade (download)
Os incidentes de alta severidade se relacionavam principalmente a ataques de ransomware. Curiosamente, as instituições privadas foram as principais vítimas de ransomware, enquanto os incidentes em instituições públicas estiveram, em sua maioria, relacionados a atividades suspeitas em endpoints e tentativas de escalonamento de privilégios. As famílias de ransomware mais comuns encontradas em nosso conjunto de dados foram DragonForce e LockBit 3, cujo builder vazou em 2022. Ao utilizar o builder vazado do LockBit com uma conta privilegiada válida, os atacantes conseguem criar variantes capazes de desativar mecanismos de defesa e apagar logs.
Os vetores iniciais de acesso mais comuns incluem o uso de contas válidas, a exploração de aplicações expostas à Internet e ameaças internas (insiders).
Vetores de acesso inicial (download)
Para escalação de privilégios, os invasores frequentemente recorreram a variantes da família Potato (como GodPotato, SweetPotato e BadPotato).
Também identificamos o uso do AnyDesk para acesso remoto, PsExec para movimentação lateral em infraestruturas comprometidas e malware do tipo AV-killer para desativar as defesas dos sistemas. Este último foi utilizado principalmente em incidentes relacionados a ransomware, com o intuito de evitar detecções.
Esses dados revelam um padrão relevante no cenário de ameaças às instituições de ensino da região: muitos incidentes exploram fragilidades comuns (como contas válidas, aplicações expostas, gerenciamento inadequado de patches, entre outras) e utilizam ferramentas amplamente conhecidas pelos invasores e profissionais de cibersegurança. A predominância de ransomware em instituições privadas indica uma motivação financeira mais forte, já que os invasores podem considerar que essas organizações têm maior capacidade de pagar pelo resgate dos dados do que escolas e universidades públicas.
Embora a maioria dos ataques tenha sido detectada rapidamente e durado de alguns minutos a poucas horas, as atividades técnicas de resposta a incidentes levaram, em média, cerca de 9,6 horas. Isso indica que o impacto causado por um incidente frequentemente se estende além da duração do ataque em si, exigindo extensas atividades de triagem e análise por parte dos investigadores forenses para restaurar completamente as operações da organização.
Um fato interessante é que ainda observamos o uso do Windows 10 nas infraestruturas de instituições de ensino, mesmo após o término oficial do suporte pela Microsoft em outubro de 2025. Além disso, encontramos, em algumas organizações, o uso do Windows Server 2016 sem patches e correções de segurança.
Sistemas operacionais desatualizados e sem suporte aumentam a superfície de ataque da infraestrutura, pois os invasores podem explorar vulnerabilidades publicamente conhecidas para obter acesso a sistemas vulneráveis e ampliar sua presença na rede. Além disso, sistemas operacionais legados podem apresentar problemas de compatibilidade com ferramentas modernas para coleta de evidências, exigindo mais tempo e procedimentos alternativos para a aquisição forense.
Sistemas obsoletos nas organizações (download)
Casos interessantes
Caso 01 – Builder vazado do LockBit
Em um dos casos, identificamos o uso de uma versão personalizada do LockBit gerada com o builder vazado. O ransomware foi introduzido na infraestrutura da instituição por meio de uma conta válida vazada. Ele criptografou os sistemas internos da organização, incluindo servidores de arquivos e bancos de dados que armazenavam perfis de alunos e outras informações. Não foram encontradas evidências de extração de dados das máquinas afetadas.
Durante a análise da amostra do LockBit, conseguimos extrair sua configuração. Curiosamente, ele estava configurado sem as opções de personificação e propagação. Assim, o invasor precisou realizar a movimentação lateral manual para distribuir o malware pela rede.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
"config": { "settings": { "impersonation": false, "local_disks": true, "network_shares": true, "kill_processes": true, "kill_services": true, "set_wallpaper": true, "self_destruct": true, "kill_defender": true, "wipe_freespace": true, "psexec_netspread": false, "gpo_netspread": false, … |
Análises posteriores mostraram que o invasor utilizou o PsExec para essa movimentação lateral. Ao analisar o Update Sequence Number (USN) Journal, conseguimos identificar arquivos .KEY associados ao PsExec, que revelaram as máquinas previamente comprometidas e utilizadas pelo invasor.
Depois de obter acesso às máquinas-alvo, os invasores implantaram um batch script para desativar as defesas do sistema. A análise desse artefato mostrou que eles já possuíam as credenciais administrativas necessárias para desabilitar a solução de EDR em uso. Além disso, o script habilitava o RDP para conceder acesso remoto à máquina-alvo. A lista abaixo mostra um trecho desse script:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f netsh advfirewall firewall add rule name="allow RemoteDesktop" dir=in protocol=TCP localport=3389 action=allow reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v DisableRealtimeMonitoring /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableBehaviorMonitoring /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableOnRealTimeProtection /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableIOAVProtection /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableScriptScanning /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" /v SpyNetReporting /t REG_DWORD /d 0 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" /v SubmitSamplesConsent /t REG_DWORD /d 2 /f reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "SecurityHealth" /t REG_SZ /d "" /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{UUID}" /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v ServiceKeepAlive /t REG_DWORD /d 0 /f sc stop WinDefend sc config WinDefend start= disabled |
Por fim, ao cruzarmos as informações dos arquivos Prefetch, conseguimos identificar as datas e horários exatos de execução do PsExecSvc.exe e do LBB.exe (LockBit). Isso mostrou que, na máquina analisada, o invasor realizou a primeira conexão por volta das 5h30 (UTC) e executou o LBB.exe pela última vez às 10h (UTC) do mesmo dia, resultando em uma janela de atividade de aproximadamente quatro horas e trinta minutos. Conseguimos identificar o escopo comprometido pelo invasor e outras máquinas que precisavam ser isoladas da rede para análises forenses adicionais, contenção e remediação.
Caso 02 – DragonForce implantado via AnyDesk
Em outro incidente, identificamos uma conta de usuário comprometida que foi utilizada para instalar o AnyDesk, permitindo aos invasores acesso remoto ao ambiente. Embora os logs do sistema tenham sido apagados pelo invasor após criptografar os arquivos da vítima, conseguimos identificar o evento de execução do ransomware por meio dos arquivos de Prefetch e Amcache.hve, que nos forneceu o hash SHA-1 da amostra.
Com o SHA-1 do artefato malicioso (nomeado pelo invasor como 1.EXE), confirmamos que se tratava de uma variante do DragonForce. Apesar da falta de evidências ter tornado a análise mais difícil, esse caso demonstra que investigadores forenses precisam estar preparados para identificar informações justamente naquilo que não foi alterado ou foi esquecido pelos invasores.
Caso 03 – Keylogger em Python utilizado por um agente interno
O terceiro incidente mostra como uma série de más práticas permitiu que um agente interno coletasse senhas de outros usuários dentro da infraestrutura. Inicialmente, o cliente entrou em contato informando que uma máquina apresentava um comportamento suspeito, especificamente a criação de arquivos contendo senhas. Começamos pela coleta inicial de evidências em uma das máquinas afetadas.
A evidência no Assistente de Compatibilidade de Programas (PCA) mostrou a execução dos arquivos suspeitos Windows Host Widgets.exe e Windows Host Widgets_.exe, ambos do diretório C:\Users\<usuário>\.vscode\dlo, em que <usuário> representa um usuário comum compartilhado por todas as pessoas que utilizavam a máquina. Os mesmos artefatos também foram identificados no arquivo Amcache.hve; várias execuções foram igualmente confirmadas pela análise dos arquivos Prefetch. Outra fonte interessante de evidências, o UserAssist, confirmou que o agente de ameaça também executou os arquivos EXE por meio de um duplo clique.
A análise da MFT mostrou que diversos arquivos de log foram criados no diretório mencionado anteriormente, com nomes no formato cacheX.txt, em que X corresponde a um número incrementado a cada execução do malware. Em seguida, analisamos os arquivos EXE para confirmar seu comportamento. Felizmente, ambos se mostraram ser o mesmo script em Python, que conseguimos descompilar com facilidade.
Como mostrado no trecho abaixo, o script contém métodos e strings em português. Ele também é capaz de ocultar os arquivos de log para que não apareçam no Explorer. O desenvolvedor também implementou um procedimento para identificar quando a tecla Caps Lock era pressionada, garantindo que as senhas fossem registradas corretamente.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
def get_base_path(): ... def encontrar_proximo_nome(base='cache'): ... def set_file_hidden(filepath): ... ctypes.windll.kernel32.SetFileAttributesW(str(filepath), FILE_ATTRIBUTE_HIDDEN) ... with open(log_file, 'a', encoding='utf-8') as f: f.write(f'\n\n--- Registro iniciado em {datetime.datetime.now()} ---\n') set_file_hidden(log_file) ... def is_capslock_on(): return bool(ctypes.windll.user32.GetKeyState(20) & 1) ... def on_press(key): ... def on_release(key): ... def main(): with keyboard.Listener(on_press=on_press, on_release=on_release) as listener: listener.join() if __name__ == '__main__': main() |
Esse script simples não implementava nenhum mecanismo de persistência nem de exfiltração automática de dados. Assim, o agente interno provavelmente precisava recuperar manualmente os arquivos de log gerados, que continham o texto digitado pelas vítimas. Ao revisarmos as evidências coletadas anteriormente, identificamos conexões de dispositivos USB no mesmo período em que o script foi executado. Isso indica o provável uso de mídias removíveis para coletar os logs de keylogging gerados no ambiente. Como resultado da investigação, o cliente alterou as senhas de todas as contas afetadas. No entanto, sem evidências adicionais ou imagens de câmeras de segurança, não foi possível atribuir de forma conclusiva as atividades a um indivíduo específico para a adoção das medidas disciplinares e legais cabíveis.
Conclusões e recomendações
Os incidentes destacados neste artigo demonstram que as instituições brasileiras estão expostas a um conjunto diversificado de ameaças, que vão desde operações de ransomware até atividades de agentes internos. Em muitos casos, em vez de recorrer a malware avançado ou novas técnicas, os invasores exploraram credenciais válidas, serviços expostos, ferramentas de acesso remoto, gerenciamento inadequado de patches e proteção insuficiente dos endpoints.
Diante desse cenário, as instituições de ensino devem priorizar controles que reduzam a probabilidade de comprometimento de contas e o impacto da execução de ransomware, além de aprimorar a visibilidade forense após um incidente.
As instituições devem exigir o uso de autenticação multifator (MFA) em todos os serviços acessíveis pela Internet, especialmente VPNs, portais de acesso remoto e contas de e-mail. Como as contas válidas foram um dos vetores de acesso inicial mais frequentes observados em nosso conjunto de dados, o MFA pode reduzir significativamente a probabilidade de que credenciais roubadas ou reutilizadas sejam suficientes para comprometer todo o ambiente. Também recomendamos revisar periodicamente as contas privilegiadas, removendo permissões administrativas desnecessárias e evitando o uso de contas compartilhadas, especialmente em máquinas acessadas por vários usuários, já que isso dificulta significativamente a responsabilização. Cada usuário deve ter uma conta individual, seguindo o princípio do menor privilégio, para evitar a execução não autorizada de software. Além disso, é recomendado restringir e monitorar o uso de ferramentas de acesso remoto, como AnyDesk e TeamViewer. Instalações ou execuções inesperadas dessas ferramentas devem ser tratadas como alertas de alta prioridade.
Para minimizar o impacto de ataques de ransomware, as instituições devem fortalecer suas estratégias de backup e recuperação. Os backups devem permanecer isolados do ambiente de produção (preferencialmente em mais de um local) e ser testados regularmente. A centralização dos logs, a retenção da telemetria de EDR e a sincronização adequada do horário entre os hosts também podem melhorar a capacidade de reconstruir a linha do tempo do ataque e implementar as medidas de resposta necessárias.
O uso de sistemas desatualizados aumenta a superfície de ataque; por isso, recomendamos que as organizações adotem uma política eficaz de atualização e gerenciamento de patches. A conscientização em segurança também é fundamental, pois os usuários precisam compreender os riscos associados ao vazamento de credenciais, à execução de arquivos desconhecidos e ao uso de software não autorizado.
Sob a perspectiva da perícia digital e resposta a incidentes (DFIR), os incidentes analisados mostram que atividades eficazes de resposta a incidentes dependem da correlação de vários artefatos forenses para reconstruir as ações dos invasores. Os investigadores devem saber como encontrar informações mesmo quando os logs não estão disponíveis. Diversos outros artefatos são preservados e podem ser utilizados para esse fim, como Amcache, PCA, Prefetch, UserAssist, MFT e USN Journal. Os invasores podem não conseguir apagar todos os rastros de suas atividades; por isso, uma abordagem forense abrangente é essencial para determinar a extensão do comprometimento e apoiar as ações de contenção e remediação.
TTPs observadas
A tabela abaixo apresenta as TTPs observadas em nosso conjunto de dados (incluindo casos que não foram detalhados neste artigo).
| Tática | Técnica | ID |
| Desenvolvimento de Recursos | Contas Comprometidas | T1586 |
| Coleta | Captura de Entrada: Keylogging | T1056.001 |
| Execução | Serviços do Sistema: Execução de Serviço | T1569.002 |
| Execução | Manipulação do Fluxo de Execução: DLL | T1574.001 |
| Escalação de Privilégios | Exploração para Escalação de Privilégios | T1068 |
| Movimentação Lateral | Serviços Remotos: Protocolo de Área de Trabalho Remota | T1021.001 |
| Comando e Controle | Ferramentas de Acesso Remoto | T1219 |
| Exfiltração | Exfiltração por Meio Físico: Exfiltração por USB | T1052.001 |
| Impacto | Dados Criptografados para Impacto | T1486 |



Uma análise de incidentes em instituições de ensino no Brasil