A L&L Solutions analisou os fatos e reuniu, nesta publicação, o que SentinelOne, CrowdStrike, Kaspersky, Acronis, Bitdefender, ESET e Trend Micro efetivamente comunicaram — e o que seus clientes devem verificar.
Devil October: o que realmente aconteceu?
Entre os dias 15 e 23 de outubro, fabricantes, pesquisadores e organizações afetadas divulgaram diversos acontecimentos relevantes. A expressão Devil October é adotada nesta análise como denominação editorial para organizar os acontecimentos do período. Não há evidência de que todos façam parte de uma única ofensiva coordenada. Alguns ataques ocorreram em outubro; outros começaram meses antes e só foram documentados agora.
Para entender o impacto, é essencial separar três situações: ataque confirmado (houve acesso indevido, distribuição de malware ou outra atividade demonstrada), tentativa de exploração (há evidências de investidas, mas não necessariamente de sucesso) e vulnerabilidade divulgada (existe uma falha, o que não comprova que um ambiente tenha sido invadido).
O ponto central para as empresas: o fato de um incidente não ter ocorrido dentro da sua organização não elimina o risco indireto. Credenciais de serviços em nuvem, integrações autorizadas, atualizações de software e aplicações publicadas podem abrir caminhos que não dependem da execução de um malware tradicional no computador do usuário.
Principais ataques e incidentes documentados em outubro
Selecionamos ocorrências com manifestações de seus responsáveis ou relatórios técnicos identificáveis. A data apresentada indica o evento ou a divulgação, conforme esclarecido em cada item.
1. ConnectWise e campanha automatizada com agentes de IA
Divulgação técnica: 21/10 — Tipo: intrusão e abuso de integrações.
A Microsoft atribuiu ao grupo Storm-0940 o uso do framework de testes ofensivos ARTEX para acelerar ataques contra ambientes em nuvem. Sua investigação associou a atividade a um comprometimento de cadeia de suprimentos envolvendo aplicações da ConnectWise. O acesso a identidades de aplicativos autorizados permitiu tentativas e operações posteriores em tenants Microsoft 365, sem exigir login interativo de usuários. A Microsoft destacou que observar autenticação suspeita não significa, por si só, comprovar acesso ou extração de dados.
Impacto para as empresas: revisar aplicativos empresariais, consentimentos OAuth, credenciais de service principals, permissões privilegiadas e registros do Entra ID e Microsoft Graph. ↗ Pesquisa oficial Microsoft — 21/10.
2. LiteLLM: distribuição de versão maliciosa
Ataque: 21/10 — Tipo: cadeia de suprimentos.
O projeto confirmou que a versão 1.107.0, distribuída por PyPI e por imagens de contêiner durante intervalos específicos, continha código para coleta de credenciais e carregamento de ferramentas maliciosas. Os artefatos foram retirados. A investigação posterior descreveu abuso de credenciais de desenvolvedores e do fluxo legítimo de publicação.
Impacto para as empresas: identificar instalações executadas nas janelas afetadas, tratar sistemas que carregaram o artefato como potencialmente comprometidos, investigar persistência e substituir credenciais que poderiam ser alcançadas. ↗ Comunicado do LiteLLM e ↗ investigação da cadeia de ataque, atualizada em 23/10.
3. Railway: acesso indevido a variáveis de ambiente
Incidente: 20–22/10 — Divulgação: 21/10 — Tipo: intrusão e exposição de segredos.
A Railway relatou acesso não autorizado a parte de seus sistemas internos e a variáveis de ambiente de clientes, algumas com conteúdo descriptografado. No relatório preliminar, estimou que até 1,85% dos workspaces poderiam ter variáveis afetadas; também recomendou uma rotação mais ampla, por precaução. O foco identificado pelo fornecedor incluía chaves de provedores de IA.
Impacto: revogar ou trocar chaves de API, segredos de aplicações, credenciais de repositório e banco de dados armazenados na plataforma; investigar uso indevido após a exposição. ↗ Relatório preliminar Railway — 22/10.
4. Zeabur: comprometimento de infraestrutura de hospedagem
Ataque: 14–15/10 — Relatório: 19/10 — Tipo: intrusão e exposição de dados.
A Zeabur descreveu o uso de credenciais internas comprometidas para acessar ambientes compartilhados, determinados servidores dedicados e registros de sua plataforma. Variáveis de ambiente e dados de projetos ficaram expostos. Após incidentes em 2026, a empresa também anunciou encerramento progressivo de suas operações até dezembro.
Impacto: revisar infraestrutura hospedada, chaves SSH, tokens, credenciais de banco e planos de continuidade ou migração, conforme o ambiente utilizado. ↗ Relatório oficial Zeabur e ↗ comunicado de encerramento.
5. OVHcloud CLI: binários oficiais adulterados
Ataque: 19/10 — Tipo: cadeia de suprimentos.
Segundo o aviso do fornecedor, o comprometimento de uma conta de desenvolvedor permitiu substituir arquivos binários de versões antigas da ferramenta OVHcloud CLI no GitHub, durante aproximadamente 1 hora e 33 minutos. A OVHcloud informou que o código-fonte e seu pipeline de construção não foram alterados; os downloads feitos anteriormente à janela identificada não eram afetados pelo episódio.
Impacto: conferir data e integridade das versões baixadas, seguir o procedimento oficial de resposta se um binário comprometido foi executado e utilizar uma versão comprovadamente íntegra. ↗ Advisory OVHcloud.
6. AOMEI Backupper: adulteração temporária de mecanismo de atualização
Ataques: abril–julho/2026 — Pesquisa divulgada: 15/10 — Tipo: cadeia de suprimentos.
Google Threat Intelligence Group e Mandiant documentaram alterações de curta duração na infraestrutura de atualização da AOMEI, empregadas para distribuir componentes maliciosos. O caso foi tornado público em outubro, mas não significa que a invasão tenha começado naquele mês. A AOMEI informou medidas de correção e nova versão de proteção.
Impacto: auditar atualizações provenientes de canais de terceiros e investigar sistemas que correspondam às condições descritas nos relatórios. ↗ Pesquisa Google/Mandiant e ↗ posicionamento AOMEI.
7. Fireworks AI: uso indevido de credenciais internas
Identificação: 06/10 — Divulgação: 09/10 — Tipo: acesso indevido a segredos.
A Fireworks AI comunicou acesso não autorizado a variáveis de ambiente de jobs de avaliação em um conjunto limitado de contas. A empresa disse não ter identificado, até o momento do informe, evidências de acesso indevido a modelos, conjuntos de treinamento ou tráfego de inferência dentro de sua área de controle.
Impacto: clientes notificados devem rotacionar os segredos indicados e revisar registros de uso dos serviços correspondentes. ↗ Boletim oficial Fireworks AI.
8. eMudhra: problema crítico de confiança em certificados digitais
Notificação: 17/10 — Divulgação: 20/10 — Tipo: comprometimento criptográfico, não invasão convencional.
O Google e a Mozilla confirmaram que as chaves privadas de oito certificados intermediários da autoridade certificadora eMudhra podiam ser recuperadas devido a geração criptográfica inadequada. Navegadores bloquearam as chaves afetadas. Em atualização de 26/10, a eMudhra afirmou que os intermediários não haviam emitido certificados públicos de usuário final e que não identificou comprometimento de sua infraestrutura ou dados de clientes.
Impacto: manter navegadores e cadeias de confiança atualizados; quem administra infraestrutura de certificados deve acompanhar mudanças de confiança e eventuais orientações para migração. ↗ Google, ↗ Mozilla e ↗ eMudhra — atualizado em 26/10.
9. GitLab: correção emergencial de falhas críticas
Correções: 21/10 — Tipo: divulgação de vulnerabilidades, não evidência automática de ataque.
O GitLab disponibilizou versões de segurança para instalações autogerenciadas e recomendou atualização imediata. Um produto possuir uma falha crítica não significa que todas as instâncias tenham sofrido invasão.
Impacto: confirmar versão e patches em instâncias self-managed, revisar exposição à internet e seguir orientações específicas do fabricante. ↗ Boletim de atualização GitLab.
PHP2Shell: por que o alerta mobilizou tantos fabricantes?
No dia 21 de outubro de 2026, o projeto PHP publicou correções para as falhas CVE-2026-109618 e CVE-2026-109619, ambas com CVSS v4.0 de 9,2 (crítico). Sob determinadas condições, um atacante não autenticado pode provocar execução de código ou divulgação de informações presentes na memória de processos PHP, incluindo segredos utilizados por aplicações.
A falha está no interpretador PHP. Assim, atualizar apenas WordPress, Drupal, Joomla ou plugins não é suficiente. Também é necessário verificar serviços PHP em painéis de hospedagem, sistemas internos, aplicações embarcadas, contêineres e equipamentos de terceiros.
Versões PHP corrigidas em 21/10
| Ramo | Primeira versão corrigida |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Distribuições Linux e outros fornecedores podem disponibilizar correções por backport sem alterar o número principal exibido pelo pacote. Versões antigas fora de suporte exigem atualização de ramo ou confirmação formal de correção pelo mantenedor. Reiniciar os processos PHP após a atualização é parte da remediação.
O que é confirmado sobre exploração? Diferentes fornecedores registraram varreduras e tentativas de exploração, algumas reportadas desde 17/10. Isso não autoriza afirmar que milhões de sistemas foram efetivamente invadidos. Em 23/10, a CrowdStrike ainda não identificava exploração bem-sucedida em sua telemetria e destacava a dificuldade de transformar algumas provas de conceito em ataques confiáveis. A ausência de invasões confirmadas nessa amostra não diminui a urgência de corrigir a falha.
Em 23/10, o projeto PHP também publicou um aviso informativo sobre CVE-2026-115560, relacionado a uma combinação incomum de configurações e código no mecanismo de progresso de upload de sessões. O projeto recomendou manter session.upload_progress.enabled=0 como mitigação provisória no cenário descrito e informou que trataria a correção em ciclo regular. Essa orientação adicional não substitui os patches das duas CVEs principais.
O que cada fabricante de EDR comunicou aos seus clientes?
Todos os sete fabricantes abaixo têm alguma publicação específica relacionada ao PHP2Shell localizada nesta análise. Porém, isso não equivale a anunciar bloqueio de todos os ataques discutidos nesta publicação. Em cada seção distinguimos o posicionamento público, as proteções documentadas e o limite que o cliente precisa conhecer.
Importante: proteção de endpoint, EDR, XDR, MDR, IPS, virtual patching e SIEM são recursos distintos. A cobertura efetiva depende da edição contratada, das políticas ativadas, do sistema operacional e de o ativo realmente possuir o sensor correto e estar enviando telemetria.
Panorama dos posicionamentos localizados até 26/10
Na pesquisa realizada, não identificamos um pronunciamento único de qualquer dos sete fabricantes abordando todos os episódios reunidos nesta publicação sob a denominação “Devil October”. Isso não significa ausência de resposta: todos publicaram informações relativas ao PHP2Shell ou seus produtos, com escopos diferentes. Veja o resumo e acesse o detalhamento de cada fabricante logo abaixo.
Resumo dos comunicados públicos localizados até 26/10/2026:
• SentinelOne — Comunicado sobre proteção contra PHP2Shell, publicado em 21/10. Foco na detecção de atividades posteriores à exploração.
• CrowdStrike — Artigos em 21 e 23/10 sobre prevenção e exploração do PHP2Shell; pesquisa separada sobre uso ofensivo de IA.
• Kaspersky — Orientações e análise sobre PHP2Shell, publicadas em 21 e 23/10. Não foi identificada garantia pública de bloqueio integral das duas CVEs.
• Acronis — Comunicado de 22/10 sobre impacto em produtos e ações do MDR, incluindo atualização de regras e buscas proativas.
• Bitdefender — Alerta técnico de 22/10 com regras para comportamentos pós-exploração e panorama das observações da fabricante.
• ESET — Alerta ALERT9029 de 22/10 referente especificamente ao ESET Endpoint Encryption Server.
• Trend Micro — Avisos até 23/10 sobre regras IPS e produtos próprios potencialmente afetados, com procedimentos específicos.
 |
Plataforma Singularity
Posicionamento oficial — publicado em 21/10
A SentinelOne publicou Stopping PHP2SHELL: How SentinelOne Protects Customers From This Attack Technique. A análise reconhece a gravidade das CVEs, enfatiza a atualização do PHP como controle principal e explica que a plataforma identifica comportamentos posteriores à exploração em servidores monitorados: comandos anômalos, webshells, execução de payloads e conexões externas suspeitas.
Proteções e resposta disponíveis
• Detecção comportamental da plataforma Singularity para processos e execução maliciosa nos sistemas cobertos.
• Recursos de investigação e contenção conforme edição licenciada; telemetria ampliada e busca com Purple AI e AI SIEM quando disponíveis.
• Correlação de eventos de endpoint e aplicação para investigar a progressão de um ataque após a falha inicial.
O que a fabricante não garante: o caminho de exploração que apenas lê memória do PHP pode não gerar processos maliciosos detectáveis por um EDR. A SentinelOne não apresenta o agente como substituto do patch, do WAF ou da revisão de credenciais.
Orientação L&L: confirme sensores e política de proteção nos servidores web, avalie se os módulos necessários estão contratados e use a telemetria disponível para caçar processos filhos incomuns de serviços web.
Referências do fabricante
↗ SentinelOne — Como a plataforma protege contra técnicas associadas ao PHP2Shell (21/10)
 |
Plataforma Falcon
Posicionamento oficial — publicações em 21 e 23/10
A CrowdStrike publicou duas análises específicas: uma sobre a cobertura do Falcon para ameaças relacionadas ao PHP2Shell e outra sobre os desafios técnicos enfrentados por atacantes para transformar demonstrações de falha em exploração confiável. Em 23/10, a equipe de inteligência informou que não havia observado exploração bem-sucedida dessas CVEs em sua telemetria e honeypots até aquele momento. É uma constatação delimitada por data e visibilidade, não uma garantia universal.
Proteções e resposta disponíveis
• Falcon Prevent e capacidades comportamentais para reconhecer execuções maliciosas em endpoints e servidores protegidos, conforme políticas.
• Indicadores de ataque (IOAs) para identificar etapas como criação de shell, execução de comandos e instalação de payloads.
• Investigação e contenção com módulos Falcon compatíveis e habilitados.
Notícia associada: em 21/10, a área de inteligência da CrowdStrike divulgou pesquisa sobre quatro atores de ameaça que utilizavam agentes de IA em operações ofensivas. A atividade investigada ocorreu em períodos anteriores à divulgação; o relatório não demonstra que todos os ataques de outubro foram conduzidos por um mesmo grupo.
O que a fabricante não garante: a proteção contra execução posterior não comprova bloqueio de toda exploração PHP2Shell, de vazamentos de segredos ou de abuso de tokens obtidos em serviços externos.
Orientação L&L: revisar IOAs, políticas de prevenção, cobertura dos servidores e integrar eventos de identidade e nuvem à investigação.
Referências do fabricante
 |
Endpoint Security e Next EDR
Posicionamento oficial — publicações em 21 e 23/10
A Kaspersky divulgou orientação sobre as vulnerabilidades críticas do PHP em 21/10 e atualizou uma análise de alcance mais amplo em 23/10. Os textos tratam do risco para servidores e aplicações web, da priorização das correções e da importância de analisar tentativas de exploração. Portanto, há manifestação oficial da Kaspersky sobre o cenário PHP2Shell, embora isso não represente uma declaração de bloqueio integral das duas CVEs pelo endpoint.
Proteções e resposta disponíveis
• Kaspersky Endpoint Security: detecção de comportamento, prevenção de exploits e proteção contra arquivos, scripts e execuções maliciosas, conforme plataforma e política.
• Kaspersky Next EDR Optimum: capacidade adicional de investigar incidentes e executar medidas de resposta quando o componente EDR está efetivamente licenciado, instalado e operacional.
• Os mecanismos podem reduzir a progressão de ataques que executem processos ou artefatos maliciosos em máquinas protegidas.
O que não foi confirmado nesta pesquisa: não identificamos declaração da Kaspersky garantindo bloqueio específico de ambas as CVEs PHP2Shell pelo agente em todos os produtos e configurações. O risco de leitura de memória ou uso posterior de credenciais continua a exigir controles externos ao EDR.
Orientação L&L: diferenciar agente KES instalado de EDR realmente habilitado; confirmar versões, módulos, política, telemetria e cobertura de servidores críticos. Atualização de aplicações, WAF e logs web seguem prioritários.
Referências do fabricante
 |
Cyber Protect, EDR e MDR
Posicionamento oficial — publicado em 22/10
A Acronis informou que o produto Acronis Cyber Protect não utiliza PHP e, portanto, não exige atualização do próprio produto por causa dessas duas CVEs. Também relatou que algumas propriedades web da companhia utilizavam PHP e foram retiradas temporariamente do ar para correção. A empresa atualizou regras de detecção do serviço Acronis MDR e declarou estar realizando buscas proativas nos ambientes cobertos por esse serviço.
Proteções e resposta disponíveis
• Acronis EDR: telemetria e detecção comportamental para investigar ações suspeitas no endpoint coberto, conforme edição e configuração.
• Acronis MDR: regras de detecção atualizadas para a ameaça e atividade de threat hunting, segundo o comunicado de 22/10.
• Integração com camadas de antimalware, backup e recuperação, dependendo dos serviços contratados.
O que essa declaração não significa: o fato de o produto Cyber Protect não usar PHP não elimina a exposição de aplicações, servidores ou serviços de clientes que utilizem o interpretador. EDR e MDR também não garantem detectar exfiltração por leitura de memória sem comportamento observável.
Orientação L&L: separar o estado de segurança da plataforma Acronis da situação dos servidores PHP do cliente e confirmar se a organização possui EDR, MDR ou somente outros módulos contratados.
Referências do fabricante
 |
GravityZone EDR
Posicionamento oficial — publicado em 22/10
A Bitdefender publicou um Technical Advisory dedicado ao PHP2Shell. Informou que sua telemetria não havia identificado tentativas de exploração até a data da publicação e que Bitdefender Labs e a operação MDR acompanhavam o cenário. O alerta especifica que a ausência de observações não é motivo para adiar a atualização.
Proteções e resposta disponíveis
• GravityZone oferece mecanismos de detecção para atividades de pós-exploração, como execução de shells, conexões reversas e criação de webshells.
• O comunicado identifica exemplos de detecções, como EDR.PhpReverseShell e ATC.BashReverseShell.X, aplicáveis segundo a plataforma e as regras pertinentes.
• Controles bloqueantes e recursos adicionais, como PHASR, dependem de suporte, licenciamento e ativação.
O que a fabricante não garante: bloquear uma reverse shell ou outro comportamento posterior não equivale a bloquear a vulnerabilidade inicial. Um acesso indevido à memória do PHP pode não produzir o mesmo tipo de sinal.
Orientação L&L: validar cobertura dos servidores, regras de detecção ativas e telemetria Linux/Windows aplicável, sem dispensar patch e correlação com WAF.
Referências do fabricante
 |
PROTECT, Inspect e Endpoint Encryption Server
Posicionamento oficial — alerta atualizado em 22/10
A ESET publicou o aviso ALERT9029 confirmando que o ESET Endpoint Encryption Server utiliza componentes PHP afetados pelas duas CVEs. No texto consultado, a fabricante informou estar desenvolvendo uma versão corrigida e orientou acompanhar o canal oficial de suporte. Esse alerta é específico do Endpoint Encryption Server: ele não afirma que todo ESET PROTECT ou ESET Inspect seja vulnerável.
Proteções e resposta disponíveis
• Proteção multicamada do endpoint ESET para arquivos, scripts, exploits e atividades suspeitas, conforme o produto.
• ESET Inspect, quando contratado, acrescenta investigação comportamental, correlação e recursos de resposta nos sistemas compatíveis.
• É necessário avaliar separadamente a exposição de serviços PHP e as versões do Endpoint Encryption Server eventualmente instaladas.
O que ainda não foi confirmado nesta pesquisa: não localizamos declaração pública da ESET assegurando bloqueio específico das duas CVEs PHP2Shell pelo ESET PROTECT ou ESET Inspect. Também não é correto afirmar que o Endpoint Encryption Server já recebeu uma correção definitiva sem verificar a página de suporte e a versão instalada.
Orientação L&L: clientes ESET devem manter suas camadas de endpoint ativas, mas quem utiliza Endpoint Encryption Server precisa de uma verificação adicional e acompanhamento do aviso de correção.
Referências do fabricante
 |
TrendAI Vision One e produtos relacionados
Posicionamento oficial — avisos atualizados até 23/10
A TrendAI publicou comunicados técnicos detalhados e orientações específicas de exposição. Informou disponibilidade de regras de IPS e virtual patching para produtos compatíveis, além de um PHP2Shell Exposure Checker para identificação passiva de possíveis sinais de exposição em páginas públicas. Ao mesmo tempo, a fabricante reconheceu que determinados produtos próprios também podem ser afetados.
Proteções e resposta disponíveis
• TrendAI Vision One Endpoint/Server & Workload Protection e Deep Security: regras IPS 1012749 e 1012754, quando suportadas e ativas.
• TippingPoint: filtros 48514 e 48534; Network Detection and Response: regras 6021 e 6023, conforme o aviso técnico.
• Recursos de detecção comportamental e investigação do Vision One, dependendo dos módulos e políticas utilizados.
Atenção à segurança do próprio fabricante: a TrendAI identificou exposição nas instalações locais do Apex Central e Apex One on-premises, com procedimentos temporários enquanto preparava correções definitivas. O aviso geral relaciona outros produtos e serviços com estados individuais; por isso, a orientação é conferir a tabela atualizada para a versão realmente utilizada.
O que não se deve presumir: um cliente possuir a marca Trend Micro não significa ter automaticamente as regras IPS necessárias. E um resultado de verificação passiva sem evidências não comprova que o servidor está seguro.
Orientação L&L: verificar o produto exato, a implantação on-premises ou em nuvem, a ativação das regras, os hotfixes ou medidas temporárias e a atualização do PHP de serviços externos.
Referências do fabricante
↗ Situação de produtos afetados (23/10)
Ter EDR instalado significa estar protegido contra o Devil October?
Não integralmente. A presença de EDR é uma camada relevante para impedir ou detectar atividades maliciosas em ativos monitorados. Contudo, alguns incidentes descritos neste relatório ocorreram em serviços terceirizados, repositórios, pipelines de atualização, certificados digitais e credenciais na nuvem. Outros exploram falhas de aplicações que podem ser acionadas antes da execução de novos processos visíveis ao agente.
Isso não significa que os EDRs falharam. Significa que o local do risco e a cobertura do controle precisam coincidir. Cada organização deve validar em quais etapas de ataque tem prevenção, detecção e capacidade de resposta, sem confundir uma capacidade documentada com uma garantia de cobertura universal.
Orientação técnica da L&L Solutions: o cliente pode ter confiança na proteção oferecida por sua solução quando ela está corretamente implantada, licenciada, monitorada e associada a um processo ativo de resposta. Essa confiança não dispensa correção de vulnerabilidades, segurança de identidades e gestão de terceiros.
O que as empresas devem fazer agora?
1. Priorizar PHP publicado na internet. Inventariar instâncias, confirmar o pacote corrigido e a versão realmente carregada pelo servidor; reiniciar serviços e contêineres.
2. Investigar exposição anterior à correção. Analisar logs de aplicação, proxy e WAF, falhas anormais, processos filhos de servidores web, conexões externas e arquivos suspeitos.
3. Validar seu EDR. Confirmar instalação, funcionamento do sensor, licença correta, módulos habilitados, exceções e recebimento de eventos pelos consoles ou SOC.
4. Revisar fornecedores e dependências. Identificar utilização de LiteLLM, Railway, Zeabur, OVHcloud CLI, AOMEI ou outros produtos realmente abrangidos pelos comunicados; agir segundo as janelas e versões indicadas.
5. Reforçar identidade e proteção de segredos. Revisar aplicações OAuth, service principals, permissões no Entra ID, tokens de API e credenciais potencialmente expostas em serviços externos.
6. Confirmar avisos específicos do fabricante. Usuários de ESET Endpoint Encryption Server e determinados produtos TrendAI on-premises devem conferir os procedimentos de mitigação e correção do fornecedor, além dos controles de endpoint.
7. Manter observação contínua. Correlacionar EDR, firewall, WAF, identidade, cloud e logs de aplicações. O objetivo é identificar o início, a progressão e os efeitos de um ataque, inclusive quando não há arquivo malicioso convencional.
Organizações sem exposição aos produtos citados não precisam presumir comprometimento. A resposta mais eficiente é começar pelo inventário, verificar o que realmente utilizam e aplicar as orientações pertinentes.
Fontes técnicas e transparência da análise
Este conteúdo foi elaborado pela L&L Solutions — Inteligência de Ameaças com base em comunicados de fabricantes, relatórios de vítimas e pesquisas publicadas até 26 de outubro de 2026. As URLs oficiais estão incluídas em cada seção para que os leitores verifiquem atualizações. Os sete comunicados técnicos anteriormente preparados pela L&L também serviram de base para a avaliação dos recursos dos EDRs, complementados por posicionamentos oficiais publicados posteriormente ou localizados nesta revisão.
As principais referências do cenário geral podem ser consultadas diretamente nas publicações abaixo:
↗ Microsoft Threat Intelligence
Limites da publicação: esta seleção não é um inventário exaustivo de todos os incidentes de outubro. Ausência de notícia pública específica não comprova ausência de detecção ou de proteção. Da mesma forma, não é possível concluir que um cliente está seguro ou comprometido sem avaliação técnica de seus ativos e sua telemetria. Declarações de fabricantes sobre tentativas observadas referem-se às datas, ambientes e conjuntos de dados descritos por eles.
Última revisão editorial: 26/10/2026. Comunicado de caráter preventivo. A publicação não indica comprometimento dos ambientes de clientes da L&L Solutions.
Logotipos utilizados apenas para identificação editorial dos fabricantes. As avaliações são independentes e se referem às informações públicas citadas.