Windows 10: quase três vezes mais vulnerabilidades por dispositivo que o Windows 11

[De acordo com a Lansweeper](https://www.lansweeper.com/blog/insights/windows-10-holdouts-carry-three-times-the-risk-of-windows-11/), o Windows 10 ainda está em execução em 16,9% dos dispositivos Windows corporativos, apesar do fim do suporte regular — aproximadamente um em cada seis.

O problema é particularmente agudo entre pequenas e médias empresas: o Windows 10 ainda é usado em 21,4% dos dispositivos, comparado com 16,6% em grandes organizações. A participação também permanece alta em setores que utilizam amplamente equipamentos projetados para operação de longo prazo: 23% em saúde e farmacêutica, 22,7% em varejo e setor de consumo, e 18% em manufatura.

Pesquisadores descobriram que cada dispositivo Windows 10 tem, em média:

• 1.903 vulnerabilidades contra 652 em um dispositivo Windows 11 médio;
• 66,6% das vulnerabilidades do total acima com classificação de severidade alta ou crítica;
• 2,4% das vulnerabilidades do total acima com exploração confirmada por atacantes (1,7 vezes o valor para Windows 11).

Ao mesmo tempo, 2,8% dos dispositivos Windows 10 restantes não podem ser atualizados porque seu hardware não atende aos requisitos do Windows 11. Os setores mencionados anteriormente têm números especialmente altos de dispositivos desatualizados.

Para cada dispositivo Windows 10, as organizações devem determinar seu próximo passo a curto prazo: atualizar para o Windows 11, usar suporte estendido temporariamente até 2027, ou substituir o hardware. Sistemas que não podem ser desativados rapidamente devem ser tratados como riscos elevados e protegidos com controles compensatórios — segmentação de rede, restrições de acesso, monitoramento aprimorado e controles de execução de aplicativos.

Pesquisa da Lansweeper indica que dispositivos Windows 10 têm quase três vezes mais vulnerabilidades que Windows 11. Muitos dispositivos corporativos ainda usam Windows 10, criando riscos de segurança, especialmente em saúde e varejo.

Windows 10: quase três vezes mais vulnerabilidades por dispositivo que o Windows 11

Apenas para fins informativos.

Tipo de vulnerabilidade: contorno da proteção do Google Safe Browsing
SO afetado: macOS 12 (Monterey) — macOS 27 (Golden Gate)

O vendedor reivindica possuir uma vulnerabilidade 0-dia do macOS que permite que os usuários contornem o aviso do Google Chrome exibido pelo Google Safe Browsing ao baixar um arquivo potencialmente malicioso. Segundo o vendedor, a vítima baixa o arquivo malicioso sem disparar um alerta do navegador, aumentando a probabilidade de entrega bem-sucedida por meio de download por ação indireta e engenharia social.

[Google Safe Browsing](https://safebrowsing.google.com/) — um serviço do Google que protege os usuários de sites e arquivos maliciosos. No Chrome, verifica os downloads e exibe avisos quando um usuário tenta baixar um arquivo considerado inseguro. Além disso, o modo de proteção avançada do serviço envia metadados de downloads suspeitos para os servidores do Google para análise em tempo real.

Preço: $13.000

Venda de exploit 0-day para Google Chrome em macOS. Permite contornar a proteção Google Safe Browsing ao baixar arquivos maliciosos. Preço: 13.000 dólares.

Venda de um exploit 0-dia para Google Chrome no macOS

Os pesquisadores da Bitdefender foram profundos na análise de um mecanismo pouco conhecido do Windows — Bind Links, implementado por `bindflt.sys`. O Windows usa esse driver no Sandbox do Windows, contêineres e aplicativos UWP para virtualizar o sistema de arquivos, mas com privilégios de administrador local, também pode ser usado para contornar controles de segurança.

Os autores descreveram três técnicas:
• File-Binding — substituição do conteúdo de um caminho confiável (por exemplo, `amsi.dll` ou uma DLL do agente EDR), fazendo com que um processo carregue um arquivo malicioso enquanto as ferramentas de segurança continuam a ver o original.
• Process-Binding — iniciação de um executável malicioso sob a fachada de um processo confiável, comprometendo mecanismos que dependem de verificar o caminho, assinatura ou hash da imagem.
• Silo-Binding — a técnica mais interessante, que exploita a separação entre duas visões do mesmo sistema de arquivos. Dentro de um contêiner isolado, um processo que parece confiável executa código controlado pelo atacante. Fora dele, todas as ferramentas que examinam o processo veem um arquivo legítimo e limpo.

A pesquisa é significativa porque demonstra o abuso de um mecanismo nativo do Windows que viola uma suposição básica subjacente a muitas ferramentas de segurança: o mesmo caminho sempre aponta para o mesmo arquivo. O AppLocker, o AMSI, o Sysmon, vários produtos EDR e outros controles de segurança baseiam suas verificações nessa suposição.

A Microsoft avaliou o risco como baixo, pois o ataque requer privilégios de administrador local. No entanto, a Bitdefender observa que grupos de ransomware modernos geralmente obtêm tais privilégios nas etapas iniciais de uma comprometimento, tornando os Bind Links mais uma ferramenta para executar ações cobertas sem usar drivers vulneráveis.

Artigo: https://www.bitdefender.com/en-us/blog/businessinsights/bind-link-abuses-windows-feature-edr-evasion-technique

PoC (pesquisa completa e a utilitário bindutil): https://github.com/bitdefender/bindutil-toolset

Os pesquisadores da Bitdefender analisaram o mecanismo Bind Links do Windows, que pode ser usado para evadir ferramentas de segurança. São descritas três técnicas de abuso. A Microsoft avaliou o risco como baixo.

Abuso de Bind Link: uma funcionalidade do Windows, muitas maneiras de enganar seu EDR

Segurança de Identidade em Instituições Financeiras

Analistas da Secret Double Octopus lançaram um [estudo](https://5325697.fs1.hubspotusercontent-na1.net/hubfs/5325697/2026%20Identity%20Security%20Survey%20Report.pdf) sobre autenticação no setor financeiro. O relatório baseia-se numa pesquisa com 200 líderes e profissionais de IAM, TI e cibersegurança de organizações financeiras nos Estados Unidos e Canadá, representando 80% e 20% da amostra, respetivamente.

Principais números e descobertas:

Os métodos de autenticação primários usados pelas organizações são senha + OTP (77%), senha + notificação push (76%) e chaves de hardware/FIDO2 (72%). As opções menos populares foram autenticação apenas com senha e links mágicos (ambos citados em 1% das respostas). Senha + OTP é mais popular entre organizações relativamente pequenas com 100–500 funcionários. Este método foi citado em 90% das respostas de organizações deste tamanho, depois declinou gradualmente para 66% entre organizações com mais de 5.001 funcionários.

Em média, aproximadamente 74% das aplicações SaaS são protegidas por MFA. Entre aplicações legadas que não são baseadas na nuvem ou SaaS, o número foi 50%. A maioria dos respondentes (54%) relatou que aplicações legadas e infraestrutura representam 50–74% do seu ambiente de TI. Notavelmente, a motivação mais comum para modernizar o MFA entre este grupo foi conformidade com requisitos regulatórios e de conformidade.

Em média, apenas 28% dos métodos MFA usados pelas organizações são resistentes a phishing. Os principais obstáculos para implementar mais ferramentas resistentes a phishing são desafios técnicos ou arquiteturais (79%), restrições financeiras (53%), incapacidade de suportar aplicações e arquitetura legadas (51%), e a presença de múltiplas soluções IAM (51%). O último destes preocupa gestores e líderes de equipa (62%) e diretores (56%) mais do que altos executivos (19%).

_Este estudo destaca o desafio da segurança de contas no setor financeiro. A adoção relativamente baixa de métodos MFA resistentes a phishing deixa organizações em risco elevado de compromisso de contas através de phishing. Ao mesmo tempo, as descobertas mostram que as práticas de autenticação variam por tamanho da organização, com organizações maiores mudando dos métodos mais populares para outras abordagens—potencialmente indicando oportunidades mais amplas para fortalecer a segurança._

Secret Double Octopus pesquisou líderes financeiros sobre autenticação. A maioria usa senha mais OTP ou push. A adoção de MFA resistente a phishing é baixa devido a obstáculos técnicos e financeiros, elevando riscos de compromisso.

Segurança de Identidade em Instituições Financeiras

CVE-2026-6644: Injeção de Comando no Cliente VPN NAS da ASUSTOR

Um pesquisador analisou a vulnerabilidade [CVE-2026-6644](https://dbugs.ptsecurity.com/vulnerability/CVE-2026-6644) no cliente VPN da ASUSTOR e descobriu um detalhe de implementação interessante.

Ao criar uma configuração PPTP, a função vulnerável `FUN_00403f21` no script `vpn.cgi` escapou corretamente o nome de usuário e a senha antes de gravá-los no `pppd`, mas não o endereço IP do servidor VPN. Como resultado, o campo do servidor tornou-se a fonte da injeção de comando.

O erro é notável porque os campos controlados pelo usuário mais óbvios (credenciais) foram protegidos, mas outro campo foi considerado "seguro", mesmo aceitando entrada do usuário através da interface web de administração. Como resultado, o código poderia ser executado no sistema operacional ASUSTOR Data Master (ADM) com privilégios `root`.

As versões do ADM 4.1.0 a 4.3.3.RR42 e 5.0.0 a 5.1.2.REO1 são vulneráveis. A análise baseada em Censys do pesquisador mostrou que o problema afeta 19.000 nós.

Artigo: https://nefariousplan.com/posts/asustor-vpn-escapes-credentials-not-server

PoC: https://github.com/uky007/CVE-2026-6644

Uma vulnerabilidade no cliente VPN NAS da ASUSTOR permite injeção de comando via campo IP do servidor. Versões afetadas do ADM permitem execução de código root, impactando aproximadamente 19.000 nós globalmente.

CVE-2026-6644: Injeção de Comando no Cliente VPN NAS da ASUSTOR

CVE-2026-57239: Escalonando Todos os Privilégios com o Foxit PDF Reader

A maioria dos LPEs locais do Windows requer uma cadeia de exploração complexa. Mas às vezes tudo o que é preciso é olhar como um aplicativo se atualiza. O pesquisador Luke Paris (Paradoxis) descobriu que o mecanismo de atualização do Foxit PDF Reader / PDF Editor permite que um usuário padrão eleve privilégios para `NT AUTHORITY\SYSTEM`. A vulnerabilidade recebeu o identificador [CVE-2026-57239](https://dbugs.ptsecurity.com/vulnerability/CVE-2026-57239).

Durante as verificações de atualização, o serviço Foxit, executando com privilégios elevados, baixou e executou binários cujos caminhos podiam ser controlados por um usuário sem privilégios. Como resultado, um processo confiável executou efetivamente código arbitrário com privilégios `SYSTEM`.

A vulnerabilidade afeta o Foxit PDF Reader versão 2026.1.1 e anterior, bem como várias gerações do Foxit PDF Editor (13.x, 14.x, 2023–2026). A correção foi lançada como parte do Foxit PDF Reader 2026.1.2 e as atualizações correspondentes do PDF Editor.

Artigo: https://blog.paradoxis.nl/escalating-all-the-privileges-with-foxit-pdf-reader-cve-2026-57239-582a78b60492

PoC: https://github.com/Paradoxis/CVE-2026-57239

Pesquisador Luke Paris encontrou falha de escalonamento de privilégio nas atualizações do Foxit PDF Reader e Editor. CVE-2026-57239 permite usuários padrão ganharem privilégios SYSTEM. Correções disponíveis na versão 2026.1.2.

CVE-2026-57239: Escalonando Todos os Privilégios com o Foxit PDF Reader

Três novos estudos foram publicados analisando vulnerabilidades recentes do WordPress. Embora duas das vulnerabilidades tenham sido encontradas no núcleo e a terceira no plugin Temporary Login, elas compartilham uma causa raiz comum: todas surgem de interações entre diferentes componentes do WordPress.

• Vulnerabilidades de núcleo WP2shell

[CVE-2026-63030](https://dbugs.ptsecurity.com/vulnerability/CVE-2026-63030) — uma vulnerabilidade que surge quando várias chamadas REST Batch API são combinadas através de `/wp-json/batch/v1` (também disponível via `?rest_route=/batch/v1`) em uma única solicitação HTTP. A solicitação pode ser validada contra as regras de um endpoint, mas executada pelo manipulador de outro endpoint, ignorando a tipagem e sanitização de parâmetros.

[CVE-2026-60137](https://dbugs.ptsecurity.com/vulnerability/CVE-2026-60137) — uma vulnerabilidade de injeção SQL em `WP_Query`: o valor da string `author__not_in` não foi sanitizado, mas ainda foi incluído na consulta SQL.

Na cadeia WP2shell, a primeira vulnerabilidade entrega uma string não verificada ao `WP_Query`, enquanto a segunda a transforma em uma injeção SQL pré-auth e, sob uma configuração adequada, potencial RCE:
>REST Batch API → dessincronização de rota e resultado de validação → bypass de validação e sanitização de esquema REST → string reaches author__not_in → WP_Query insere no SQL → injeção SQL → RCE (sob uma configuração adequada)
Pesquisadores da Fullhunt apresentaram um [scanner](https://github.com/fullhunt/wp2shell-scan) para verificar se os sistemas são vulneráveis ao WP2shell.

Uma descoberta interessante da pesquisa da Hacktron é que a revisão de IA e SAST frequentemente detectavam a dessincronização de array, mas a tratavam como um erro comum resultando em uma resposta HTTP 500. Seu impacto na segurança tornou-se aparente apenas ao analisar a interação entre o roteamento REST e `WP_Query`.

• Vulnerabilidade do plugin Temporary Login

[CVE-2026-7567](https://dbugs.ptsecurity.com/vulnerability/CVE-2026-7567) está na maneira como o plugin procura um usuário:
>get_users([ 'meta_key' => '_temporary_login_token', 'meta_value' => $token, ]);
Os desenvolvedores esperavam uma correspondência exata de token. No entanto, no WordPress, um `meta_value` vazio desativa a filtragem de valor, e `WP_User_Query` verifica apenas a condição `meta_key = '_temporary_login_token'`.
Para bypassar a verificação `empty($_GET['temp-login-token'])`, é suficiente passar o parâmetro como um array. É considerado não vazio por `empty()`, mas após `sanitize_key()` torna-se uma string vazia. Como resultado, a consulta retorna qualquer usuário com um `_temporary_login_token` definido.
O plugin trata o primeiro usuário encontrado como o proprietário de um token válido e passa esse usuário para a API de Autenticação do WordPress, que cria uma sessão totalmente autenticada.

Todos esses estudos destacam mais uma vez a importância de testar não apenas componentes individuais, mas também suas interações.

Artigo 1: https://fullhunt.io/blog/2026/07/17/wp2shell-wordpress-core-pre-auth-rce-cve-2026-63030.html

Artigo 2: https://www.hacktron.ai/blog/wp2shell

Artigo 3: https://nefariousplan.com/posts/temp-login-token-field-is-a-filter

Pesquisadores identificaram bugs críticos no WordPress no núcleo e plugins provenientes de interações de componentes. Falhas permitem injeção SQL e execução remota de código via bypasses de validação REST API e métodos de consulta.

WordPress: bugs críticos na interseção de componentes

Pesquisadores da depthfirst demonstraram uma cadeia de RCE no GitLab através do processamento de diffs para Jupyter Notebooks. Um arquivo `.ipynb` especialmente criado é passado para `ipynbdiff` e depois para o parser JSON nativo Oj, onde a primeira vulnerabilidade permite uma escrita fora dos limites do array, enquanto a segunda permite um vazamento de endereço heap para bypass de ASLR.
Como resultado, um atacante pode substituir o callback do parser e alcançar a execução de `system()` dentro de um worker Puma rodando como usuário `git`.

A cadeia:
>.ipynb em um repositório Git → diff do notebook GitLab → ipynbdiff → extensão C Oj → escrita OOB → substituição de p->start → vazamento de ponteiro heap → recuperação da base libc/libruby → chamada para system()

O ataque não requer privilégios de administrador, acesso ao CI ou interação do usuário—é suficiente ser capaz de pushar commits para um projeto e abrir o diff. Versões do GitLab CE/EE a partir de 15.2.0 são afetadas. Correções foram incluídas em 18.10.8, 18.11.5 e 19.0.2, enquanto a versão segura do Oj é 3.17.3.

Artigo: https://depthfirst.com/research/going-depthfirst-achieving-gitlab-rce-via-two-ruby-memory-corruption-vulnerabilities

PoC: https://github.com/wupco/gitlab-rce-demo

Pesquisadores da Depthfirst demonstraram execução remota de código no GitLab via vulnerabilidades na gem Ruby Oj. Atacantes executam comandos do sistema enviando arquivos Jupyter Notebook manipulados. Correções disponíveis em versões recentes.

GitLab RCE via duas vulnerabilidades de corrupção de memória na gem Ruby Oj

CVE-2026-42208: Por que os Gateways de IA Estão Se Tornando uma Nova Superfície de Ataque

A vulnerabilidade [CVE-2026-42208](https://dbugs.ptsecurity.com/vulnerability/CVE-2026-42208) no LiteLLM Proxy expôs um problema que vai muito além de uma injeção de SQL convencional. Os Gateways de IA tornaram-se pontos centrais através dos quais chaves de API, roteamento de solicitações e autenticação para vários provedores de LLM são gerenciados.
A causa raiz foi arquitetural. Como mostrou a investigação da NefariousPlan, os desenvolvedores assumiram que a variável `hashed_token` sempre continha um hash da chave de API. No entanto, nos manipuladores `/key/block` e `/key/unblock`, para chaves sem o prefixo `sk-`, ela recebia o valor não hash do cabeçalho `Authorization: Bearer`. O código então continuou a tratá-lo como um hash seguro e o usou para construir uma consulta SQL, resultando em uma vulnerabilidade de injeção de SQL.

A vulnerabilidade afeta as versões 1.81.16–1.83.6 do LiteLLM Proxy e permite que um atacante não autenticado execute injeção de SQL através de um cabeçalho `Authorization: Bearer` especialmente crafted, potencialmente ganhando acesso ao banco de dados e credenciais do Gateway de IA. O problema é corrigido na versão 1.83.7 (atualizar para a versão estável mais recente é recomendado).

Como observado na pesquisa da CriminalIP, o LiteLLM armazena centralmente chaves de provedores de LLM em nuvem, configurações de roteamento de modelos e parâmetros do Gateway de IA. Portanto, a exploração bem-sucedida significa efetivamente o comprometimento de toda a infraestrutura de IA, não apenas da aplicação web. Dentro de 36 horas após a publicação do advisory, as primeiras tentativas de exploração apareceram, e a CISA adicionou [CVE-2026-42208](https://dbugs.ptsecurity.com/vulnerability/CVE-2026-42208) ao catálogo de Vulnerabilidades Exploradas Conhecidas (KEV).

No entanto, o problema se estende além de um único CVE. Outro estudo da Criminal IP mostrou que milhares de Gateways de IA e Relés de IA já estão expostos à Internet e disponíveis para reconhecimento. Em julho de 2026, uma busca por título HTML usando o serviço CriminalIP (consultas como `title: AI Gateway`, `title: Claude API`, `title: Claude Relay`) identificou mais de 16.000 serviços publicamente acessíveis. Muitos divulgam informações sobre os modelos (OpenAI, Claude, Gemini, DeepSeek), tecnologias em uso (Nginx, Gunicorn), portas abertas, certificados e interfaces de gerenciamento — informações que facilitam a identificação de CVEs conhecidos, misconfigurações e mecanismos de autenticação fracos.

Artigo 1 (análise da NefariousPlan do CVE-2026-42208): https://nefariousplan.com/posts/litellm-cve-2026-42208-hashed-token-was-a-parameter-name

Artigo 2 (análise breve da CriminalIP do CVE-2026-42208): https://www.criminalip.io/knowledge-hub/blog/34580

Artigo 3 (identificando Gateways de IA na CriminalIP): https://www.criminalip.io/knowledge-hub/blog/35989

CVE-2026-42208 no LiteLLM Proxy permite injeção SQL via cabeçalhos de Autorização, comprometendo credenciais do Gateway de IA. CISA listou como explorada. Milhares de Gateways de IA expostos arriscam comprometimento total da infraestrutura.

CVE-2026-42208: Por que os Gateways de IA Estão Se Tornando uma Nova Superfície de Ataque

Pesquisadores da Universidade da Califórnia (Santa Bárbara) e UCLA apresentaram uma construção universal para Criptografia Inclonável com uma chave clássica — o primeiro esquema que simultaneamente alcança criptografia e descriptografia eficientes e vantagem de indistinguibilidade inclonável exponencialmente pequena.

A criptografia inclonável é um ramo da criptografia quântica que aproveita o princípio de não clonagem da mecânica quântica. No mundo clássico, se um adversário intercepta uma mensagem criptografada e depois obtém a chave, pode descriptografá-la. No mundo quântico, no entanto, o texto cifrado existe como um estado quântico — uma coleção de qubits — que não pode ser copiado. A chave permanece uma string de bits clássica comum. Assim, mesmo que a chave secreta seja revelada posteriormente, apenas a parte na posse do estado quântico original pode recuperar a mensagem.

A ideia de criptografia quântica inclonável foi proposta pela primeira vez por Daniel Gottesman em 2003. No entanto, sua construção exigia que a chave fosse tão longa quanto a mensagem. Pelos próximos 20 anos, pesquisadores tentaram criar um esquema de criptografia inclonável eficiente em que os tempos de criptografia e descriptografia não crescessem exponencialmente com o tamanho da mensagem. No entanto, todos os esquemas existentes eram ineficientes, confiavam em abstrações matemáticas que não existem na realidade (como um oráculo aleatório quântico) ou forneciam proteção insuficiente.

O que os autores fizeram?
Outro grupo de pesquisadores em 2026 introduziu uma nova construção de criptografia, mas seu esquema apenas forneceu segurança inverso-polinomial e foi verificado apenas para pequenos parâmetros — uma prova completa de segurança negligenciável permaneceu elusiva.
Os autores do novo artigo pegaram a mesma construção e criaram um esquema que combina três propriedades anteriormente consideradas incompatíveis:
• seguro information-theoretically — mesmo com poder de computação ilimitado, a probabilidade de um ataque bem-sucedido se aproxima de zero;
• exfficient — os tempos de criptografia e descriptografia crescem polinomialmente em vez de exponencialmente;
• no modelo plain — o esquema funciona sem suposições idealizadas ou abstrações matemáticas.

A notícia é notável não apenas pelo resultado em si, mas também por como foi alcançada.
A construção e as principais ideias por trás da prova foram geradas inteiramente pelo Codex baseado no GPT 5.6 Sol Ultra. A IA encontrou uma linha alternativa de raciocínio para resolver um problema matemacional excepcionalmente difícil que escapou aos humanos por anos. O papel dos pesquisadores foi criar um ambiente para o modelo trabalhar e depois verificar manualmente cada afirmação, assumindo total responsabilidade pelo resultado.

Embora este seja um trabalho teórico e não um produto de engenharia, a pesquisa poderia abrir um novo caminho para protocolos que são impossíveis de quebrar mesmo em teoria — não apenas por causa da complexidade computacional, mas por causa das leis fundamentais da física. Implementar tais esquemas em sistemas de troca de chaves e autenticação poderia remodelar completamente os ataques aos canais de comunicação.

Pesquisadores da Califórnia e UCLA apresentaram Criptografia Inclonável com chave clássica. Codex baseado no GPT 5.6 Sol Ultra gerou construção, alcançando criptografia quântica segura eficiente sem suposições idealizadas.

Um novo capítulo na criptografia quântica

HiveOracle é uma ferramenta de linha de comando Windows x64 que analisa dados brutos de volume NTFS para reconstruir arquivos bloqueados, hives de registro offline e hashes NTLM de contas locais sem acessar o LSASS. Suporta volumes ativos, discos físicos, partições e imagens de disco brutas, exigindo privilégios de `Administrador` ou `SYSTEM` para acesso ao volume.

Recursos:
• Reconstrói arquivos NTFS e Fluxos de Dados Alternados (ADS) diretamente de dados brutos de volume NTFS
• Extrai hives de registro `SAM`, `SYSTEM`, `SECURITY` e opcionalmente `NTDS`
• Realiza parsing offline `REGF`, recuperação de BootKey e descriptografia de hash SAM
• Inclui limpeza de dump offline com sobrescrita e exclusão

Ferramenta: https://github.com/sailay1996/HiveOracle

HiveOracle é uma ferramenta CLI Windows x64 analisando dados NTFS brutos para reconstruir arquivos bloqueados, hives de registro offline e hashes NTLM locais sem acessar LSASS, exigindo privilégios de Administrador.

HiveOracle — Kit de ferramentas Windows para extração offline de registro e credenciais

Lá e Back Again: Um Guia de Operadores sobre NTLM Relaying Egress

Especialistas da SpecterOps publicaram um guia prático sobre a técnica NTLM Relay para situações onde um ataque convencional é impossível devido a restrições de infraestrutura. Os pesquisadores propõem usar autenticação NTLM de saída (egress) e um nó na nuvem como intermediário para receber e depois retransmitir o tráfego de volta para a rede interna.

Qual é a ideia?
Um ataque NTLM Relay convencional geralmente requer que o atacante esteja na mesma rede que o alvo ou possa receber tráfego SMB/WebDAV localmente. Ao operar através de C2, isso é frequentemente impossível: pode não haver acesso L2, privilégios de administrador local, ou o ataque de relay pode ser bloqueado por um firewall.

Os autores propõem a seguinte cadeia de ataque:
• forçar uma tentativa de autenticação SMB ou WebDAV NTLM;
• enviar esta autenticação para uma rede externa;
• receber o tráfego em um servidor na nuvem controlado;
• encaminhar o tráfego através de um túnel SSH para a infraestrutura da Red Team;
• retornar a sessão NTLM através de um proxy SOCKS para a rede interna e realizar o ataque de relay contra o serviço alvo.

Onde isso é especialmente eficaz?
Os autores examinam os dois cenários mais comuns:
1. Inscrição na Web AD CS (ESC8) — retransmitir autenticação para um endpoint HTTP em uma autoridade de certificado sem Proteção Estendida para Autenticação (EPA), tornando possível obter um certificado em nome de um computador ou usuário e depois usar PKINIT para comprometer a conta.
2. LDAP/LDAPS — quando a Assinatura LDAP ou Vinculação de Canal não está habilitada, a autenticação WebDAV pode ser retransmitida para um controlador de domínio, permitindo escalonamento de privilégio local ou de domínio. Para contornar restrições de rede, WebDAV sobre TCP/443 é usado porque é muito mais comumente permitido para tráfego de saída do que SMB sobre 445/TCP.

Artigo: https://specterops.io/blog/2026/07/15/there-and-back-again-an-operators-guide-on-ntlm-relaying-egress

Especialistas da SpecterOps lançaram um guia sobre ataques de relay NTLM usando autenticação de saída via nós na nuvem. Esta técnica contorna restrições de rede para visar AD CS e LDAP para escalonamento de privilégio.

Lá e Back Again: Um Guia de Operadores sobre NTLM Relaying Egress

Furtex é um kit de ferramentas Linux construído em torno de operações brutas `io_uring` e eBPF sem depender de `liburing` ou frameworks externos.

Recursos:
• Operações de arquivo, rede, injeção de processo e exfiltração de dados via `io_uring`
• Programas e carregadores eBPF para interceptação de entrada, ocultação de PID e ocultação de porta
• Reconhecimento, modificação e persistência de mapas BPF
• Técnicas de evasão de regras EDR e Falco

Ferramenta: https://github.com/MatheuZSecurity/Furtex

Furtex é um kit de pós-exploração Linux usando io_uring e eBPF brutos. Permite operações de arquivo, injeção de processo e ocultação, contornando regras EDR e Falco sem frameworks externos.

Furtex — Kit de ferramentas de pesquisa para pós-exploração e evasão no Linux

Criptografia de Hardware: Promessas vs. Realidade

Pesquisadores da Masaryk University, Red Hat e OpenSSL [examinaram](https://www.helpnetsecurity.com/2026/07/21/hdd-self-encrypting-drive-security/) 38 SSDs de criptografia automática que afirmam suportar o padrão TCG Opal2. Essas unidades oferecem criptografia de hardware — os dados são criptografados usando lógica criptográfica integrada. Os testes revelaram que afirmar conformidade com Opal2 não garante segurança real. O estudo completo está disponível [aqui](https://arxiv.org/pdf/2607.11563).

Algumas das fraquezas identificadas:
• Cinco unidades exibiram falhas de implementação de criptografia, produzindo padrões de blocos repetidos mesmo após a alteração da chave de criptografia.
• Sete dispositivos falharam nos testes de aleatoriedade, e dois deles produziram sequências especialmente previsíveis.
• Um lote da SanDisk tinha códigos de reset de fábrica (PSID) gerados sequencialmente, tornando possível adivinhar códigos válidos para outras unidades do mesmo lote.
• Outras seis unidades validaram incorretamente o comprimento do PSID e aceitaram códigos legítimos preenchidos com caracteres arbitrários.

Os pesquisadores também notaram problemas de compatibilidade. Três das 38 unidades eram incompatíveis com LUKS2 (o formato de criptografia de disco amplamente usado no Linux) devido a bugs e limitações de firmware. Entre 24 unidades anunciando modo SUM — destinado a impedir acesso de admin aos dados do usuário — apenas 14 realmente funcionavam com LUKS2.

Os pesquisadores também encontraram 12 modelos comercializados como unidades de criptografia de hardware, mas baseados em Pyrite2, que apenas impõe controle de acesso por senha e não criptografa dados.

As respostas dos fornecedores destacaram o problema. Apenas uma unidade recebeu uma atualização de firmware, enquanto outras respostas (se houver) diziam:
• O problema é conhecido, mas não corrigido.
• O modelo afetado está fora de suporte.
• A função vulnerável não é mais suportada, e os usuários são aconselhados a confiar na criptografia de software.

_Organizações frequentemente compram tais unidades simplesmente para atender aos requisitos de proteção de dados em repouso — se a especificação diz "criptografia de hardware", isso é suficiente para marcar a caixa de conformidade. Na prática, a verificação independente do comportamento real desses dispositivos tem sido rara por anos, e obter correções de firmware é frequentemente complicado. Os autores enfatizam que os recursos de segurança de hardware devem ser validados tão rigorosamente quanto qualquer outro controle e não devem ser tratados como substitutos da criptografia de software._

Pesquisadores testaram 38 SSDs autocifrados claiming TCG Opal2. Muitos falharam testes de segurança, tinham bugs ou careciam de criptografia. Fornecedores ofereceram poucos corriges, aconselhando criptografia de software.

Criptografia de Hardware: Promessas vs. Realidade

Venda de acesso à Elektromreza Srbije

Apenas para fins informativos.

A empresa é responsável pela transmissão de eletricidade, gestão e desenvolvimento do sistema elétrico da Sérvia, bem como pela coordenação de operações com sistemas elétricos vizinhos.

País: Sérvia
Setor: transmissão de energia elétrica
Tipo de acesso: FTP
Receita: ~43,1 bilhões RSD (~414 milhões USD)
Preço: $4000

Acesso à Elektromreza Srbije está à venda via FTP por 4000 dólares. A empresa lida com transmissão de eletricidade na Sérvia e coordena com sistemas elétricos vizinhos.