Como Funciona o Ataque BYOEDR?

A cadeia de ataque é executada em três estágios, cada um abusando de um componente confiável diferente do SentinelOne :

1. Despejo da Memória de um Processo Protegido por PPL

Um administrador local usa o método Dump do objeto COM SentinelHelper.1 para despejar a memória de qualquer processo protegido por PPL (Protected Process Light). A interface SentinelHelper.1 é uma ferramenta administrativa legítima, mas foi exposta sem controle de acesso adequado. Isso permite que um atacante com direitos de admin local anule completamente as proteções do PPL, lendo o conteúdo da memória de processos como o Windows Defender .

2. Injeção de Código Não Assinado no Processo Elevado

Após despejar a memória do processo protegido por PPL, o atacante injeta código não assinado nesse processo elevado. Crucialmente, essa injeção de código se origina de um componente assinado pelo SentinelOne — o sistema operacional confia em códigos assinados pelo SentinelOne. O código não assinado injetado, encapsulado em um veículo confiável, burla as verificações de integridade de código do Windows .

3. Blindagem do Malware contra Detecção e Remoção

Por fim, o atacante usa os mesmos processos e interfaces confiáveis do SentinelOne para impedir que o EDR detecte ou remova o malware injetado. Como o malware roda dentro ou junto dos processos confiáveis do próprio SentinelOne, os mecanismos de proteção contra adulteração (anti-tamper) e autoproteção do EDR acabam blindando o malware contra si mesmo .

O atacante também pode instalar um agente SentinelOne malicioso sem uma licença válida e bloquear a telemetria de gerenciamento por meio de manipulação local de DNS, isolando o sistema comprometido do console de gerenciamento central .

Qual Vulnerabilidade é Explorada?

A raiz do problema é que a SentinelOne expôs interfaces poderosas do Component Object Model (COM) — especificamente o SentinelHelper.1 — a administradores locais sem controle de acesso adequado. Além disso, seus binários de instalação assinados podiam ser reaproveitados para executar ações privilegiadas que binários não assinados comuns não conseguem .

Até a data da divulgação, nenhum identificador público de CVE foi amplamente reportado para esse problema específico .

É importante notar que o ataque requer privilégios de administrador local na máquina alvo. Não é uma vulnerabilidade de execução remota de código. No entanto, uma vez que um atacante obtém acesso de admin local por meio de um comprometimento inicial separado (como explorar um aplicativo vulnerável ou usar credenciais roubadas), o BYOEDR permite que ele burle as proteções do PPL que foram criadas para conter tais comprometimentos .

A Correção: Agente SentinelOne 26.1.1

A SentinelOne corrigiu o problema relatado na versão 26.1.1 do Agente. A correção envolveu o endurecimento (hardening) das interfaces COM expostas e a restrição de como os binários de instalação e componentes confiáveis podem ser usados . As organizações devem garantir que todos os agentes SentinelOne sejam atualizados para a versão 26.1.1 ou superior imediatamente .

Implicações Mais Amplas para Software de Segurança Confiável

A técnica BYOEDR destaca um problema fundamental de confiança: o software de segurança recebe altos privilégios e acesso profundo ao sistema por design. Quando essas capacidades são expostas por meio de interfaces acessíveis ou binários assinados, os atacantes podem reaproveitá-las como ferramentas ofensivas .

• PPL não é uma defesa absoluta. As proteções do PPL podem ser contornadas se um componente assinado por PPL (como um EDR) expuser uma primitiva de despejo de memória ou injeção de código para usuários locais .
• Binários assinados são uma faca de dois gumes. A assinatura de código garante a origem, não a segurança. Atacantes podem usar produtos de segurança "living-off-the-land" (LOLSPs) da mesma forma que abusam de binários confiáveis do sistema operacional .
• A responsabilidade do fornecedor é primordial. Fornecedores de segurança devem auditar suas próprias interfaces COM, controles de acesso a drivers e lógica de validação de instaladores com o mesmo rigor que aplicam para encontrar falhas em software de terceiros .

Medidas de Mitigação para Organizações

Para se defender contra ataques BYOEDR, as organizações devem tomar as seguintes ações:

1. Atualize imediatamente — Certifique-se de que todos os agentes SentinelOne estejam na versão 26.1.1 ou superior .
2. Endureça o acesso de administrador local — Como o ataque requer privilégios de admin local, limite e controle rigidamente as contas administrativas. Implemente acesso administrador just-in-time (JIT) e monitore elevações de privilégio incomuns .
3. Monitore o abuso de COM — Implemente regras de detecção para uso suspeito das interfaces COM do SentinelOne (ex.: SentinelHelper.1 ou chamadas inesperadas ao método Dump) por processos que não são do SentinelOne .
4. Aplique o princípio do menor privilégio amplamente — Trate todos os agentes de segurança como superfícies de ataque em potencial. Restrinja logins interativos, aplique controle de aplicativos (ex.: WDAC ou AppLocker) e segmente fluxos de trabalho administrativos .
5. Revise as práticas de hardening do fornecedor — Ao avaliar produtos EDR/XDR, pergunte aos fornecedores como eles protegem suas próprias interfaces privilegiadas contra abusos locais, não apenas contra explorações remotas .

Uma Família Crescente de Ataques de Abuso de Confiança

O BYOEDR não é um incidente isolado. Uma técnica semelhante chamada "Bring Your Own Installer" (BYOI), descoberta pela Stroz Friedberg (da Aon) em 2025, explora o processo de atualização/rebaixamento do SentinelOne para desabilitar as proteções anti-adulteração, deixando os endpoints desprotegidos para execução de malware . O BYOI foi observado em ataques reais que implantavam o ransomware Babuk .

A combinação de BYOEDR e BYOI demonstra que os atacantes estão cada vez mais mirando a confiança depositada no próprio software de segurança, e não apenas as vulnerabilidades nos aplicativos que ele protege.

Como Funciona o Ataque BYOEDR?

A cadeia de ataque é executada em três estágios, cada um abusando de um componente confiável diferente do SentinelOne :

1. Despejo da Memória de um Processo Protegido por PPL

Um administrador local usa o método Dump do objeto COM SentinelHelper.1 para despejar a memória de qualquer processo protegido por PPL (Protected Process Light). A interface SentinelHelper.1 é uma ferramenta administrativa legítima, mas foi exposta sem controle de acesso adequado. Isso permite que um atacante com direitos de admin local anule completamente as proteções do PPL, lendo o conteúdo da memória de processos como o Windows Defender .

2. Injeção de Código Não Assinado no Processo Elevado

Após despejar a memória do processo protegido por PPL, o atacante injeta código não assinado nesse processo elevado. Crucialmente, essa injeção de código se origina de um componente assinado pelo SentinelOne — o sistema operacional confia em códigos assinados pelo SentinelOne. O código não assinado injetado, encapsulado em um veículo confiável, burla as verificações de integridade de código do Windows .

3. Blindagem do Malware contra Detecção e Remoção

Por fim, o atacante usa os mesmos processos e interfaces confiáveis do SentinelOne para impedir que o EDR detecte ou remova o malware injetado. Como o malware roda dentro ou junto dos processos confiáveis do próprio SentinelOne, os mecanismos de proteção contra adulteração (anti-tamper) e autoproteção do EDR acabam blindando o malware contra si mesmo .

O atacante também pode instalar um agente SentinelOne malicioso sem uma licença válida e bloquear a telemetria de gerenciamento por meio de manipulação local de DNS, isolando o sistema comprometido do console de gerenciamento central .

Qual Vulnerabilidade é Explorada?

A raiz do problema é que a SentinelOne expôs interfaces poderosas do Component Object Model (COM) — especificamente o SentinelHelper.1 — a administradores locais sem controle de acesso adequado. Além disso, seus binários de instalação assinados podiam ser reaproveitados para executar ações privilegiadas que binários não assinados comuns não conseguem .

Até a data da divulgação, nenhum identificador público de CVE foi amplamente reportado para esse problema específico .

É importante notar que o ataque requer privilégios de administrador local na máquina alvo. Não é uma vulnerabilidade de execução remota de código. No entanto, uma vez que um atacante obtém acesso de admin local por meio de um comprometimento inicial separado (como explorar um aplicativo vulnerável ou usar credenciais roubadas), o BYOEDR permite que ele burle as proteções do PPL que foram criadas para conter tais comprometimentos .

A Correção: Agente SentinelOne 26.1.1

A SentinelOne corrigiu o problema relatado na versão 26.1.1 do Agente. A correção envolveu o endurecimento (hardening) das interfaces COM expostas e a restrição de como os binários de instalação e componentes confiáveis podem ser usados . As organizações devem garantir que todos os agentes SentinelOne sejam atualizados para a versão 26.1.1 ou superior imediatamente .

Implicações Mais Amplas para Software de Segurança Confiável

A técnica BYOEDR destaca um problema fundamental de confiança: o software de segurança recebe altos privilégios e acesso profundo ao sistema por design. Quando essas capacidades são expostas por meio de interfaces acessíveis ou binários assinados, os atacantes podem reaproveitá-las como ferramentas ofensivas .

• PPL não é uma defesa absoluta. As proteções do PPL podem ser contornadas se um componente assinado por PPL (como um EDR) expuser uma primitiva de despejo de memória ou injeção de código para usuários locais .
• Binários assinados são uma faca de dois gumes. A assinatura de código garante a origem, não a segurança. Atacantes podem usar produtos de segurança "living-off-the-land" (LOLSPs) da mesma forma que abusam de binários confiáveis do sistema operacional .
• A responsabilidade do fornecedor é primordial. Fornecedores de segurança devem auditar suas próprias interfaces COM, controles de acesso a drivers e lógica de validação de instaladores com o mesmo rigor que aplicam para encontrar falhas em software de terceiros .

Medidas de Mitigação para Organizações

Para se defender contra ataques BYOEDR, as organizações devem tomar as seguintes ações:

1. Atualize imediatamente — Certifique-se de que todos os agentes SentinelOne estejam na versão 26.1.1 ou superior .
2. Endureça o acesso de administrador local — Como o ataque requer privilégios de admin local, limite e controle rigidamente as contas administrativas. Implemente acesso administrador just-in-time (JIT) e monitore elevações de privilégio incomuns .
3. Monitore o abuso de COM — Implemente regras de detecção para uso suspeito das interfaces COM do SentinelOne (ex.: SentinelHelper.1 ou chamadas inesperadas ao método Dump) por processos que não são do SentinelOne .
4. Aplique o princípio do menor privilégio amplamente — Trate todos os agentes de segurança como superfícies de ataque em potencial. Restrinja logins interativos, aplique controle de aplicativos (ex.: WDAC ou AppLocker) e segmente fluxos de trabalho administrativos .
5. Revise as práticas de hardening do fornecedor — Ao avaliar produtos EDR/XDR, pergunte aos fornecedores como eles protegem suas próprias interfaces privilegiadas contra abusos locais, não apenas contra explorações remotas .

Uma Família Crescente de Ataques de Abuso de Confiança

O BYOEDR não é um incidente isolado. Uma técnica semelhante chamada "Bring Your Own Installer" (BYOI), descoberta pela Stroz Friedberg (da Aon) em 2025, explora o processo de atualização/rebaixamento do SentinelOne para desabilitar as proteções anti-adulteração, deixando os endpoints desprotegidos para execução de malware . O BYOI foi observado em ataques reais que implantavam o ransomware Babuk .

A combinação de BYOEDR e BYOI demonstra que os atacantes estão cada vez mais mirando a confiança depositada no próprio software de segurança, e não apenas as vulnerabilidades nos aplicativos que ele protege.