Luiz Henrique Lima Campos – Microsoft MVP

2 de novembro de 2023
por luizhenriquelima
0 comentários

Como Gerar Logs de Segurança de Autenticação com Falha no Windows Server 2022 Usando PowerShell

A segurança da informação é um aspecto crítico da gestão de TI, especialmente em ambientes corporativos. Monitorar tentativas de autenticação com falha pode ajudar a identificar possíveis ataques ou vulnerabilidades na segurança. Este artigo guiará você através do processo de criação de um script PowerShell para gerar todos os logs de segurança relacionados a autenticações com falha no Windows Server 2022.

Pré-requisitos

Antes de iniciar, certifique-se de que você tem os seguintes pré-requisitos:

  • Acesso administrativo ao Windows Server 2022.
  • Conhecimento básico de PowerShell.

Passo a Passo

1. Abrir o PowerShell com Privilegios de Administrador

Inicie o PowerShell com privilégios elevados clicando com o botão direito no menu Iniciar e selecionando “Windows PowerShell (Admin)”.

2. Script para Coletar Logs de Autenticação com Falha

Insira o seguinte script no PowerShell. Este script usa o cmdlet Get-WinEvent para filtrar e coletar logs de segurança específicos de tentativas de autenticação com falha.

powershell
# Define o filtro para eventos de segurança de autenticação com falha
$filterHashtable = @{
    LogName='Security'
    ID=4625 # ID de evento para uma tentativa de logon falhada
}

# Coleta os eventos de segurança com base no filtro
$failedAuthLogs = Get-WinEvent -FilterHashtable $filterHashtable

# Exibe os logs coletados
foreach ($log in $failedAuthLogs) {
    Write-Output $log
}

3. Análise e Armazenamento dos Logs

O script acima coletará e exibirá os eventos de logon com falha. Para análises mais aprofundadas ou para armazenar esses logs para auditorias futuras, você pode redirecioná-los para um arquivo. Modifique a última parte do script para:

powershell
# Caminho do arquivo onde os logs serão salvos
$filePath = "C:\Logs\FailedAuthLogs.txt"

# Salva os logs no arquivo especificado
$failedAuthLogs | Out-File -FilePath $filePath

4. Agendamento do Script para Execução Automática

Para monitoramento contínuo, você pode agendar o script para executar automaticamente em intervalos regulares usando o Agendador de Tarefas do Windows ou o próprio PowerShell.

Conclusão

Monitorar tentativas de autenticação com falha é vital para a segurança da sua infraestrutura de TI. Com este script PowerShell, você pode facilmente coletar e analisar esses eventos no Windows Server 2022, ajudando a identificar e mitigar possíveis ameaças de segurança.

24 de outubro de 2023
por luizhenriquelima
0 comentários

Testando a Funcionalidade do Azure AD Connect com PowerShell

Para garantir a eficácia da sua sincronização Azure AD Connect (ADSync) no Windows Server 2022, o PowerShell oferece ferramentas robustas para testar e validar o processo. Este artigo apresenta uma abordagem detalhada para realizar esses testes, assegurando que seu ambiente de sincronização esteja operando sem falhas.

Verificação do Estado da Sincronização

O primeiro passo é verificar o estado atual da sincronização. Isso pode ser feito utilizando o comando Get-ADSyncSyncCycleStatus. Este comando fornece informações detalhadas sobre o último ciclo de sincronização, incluindo se foi concluído com sucesso.

Iniciando um Ciclo de Sincronização Manual

Para testar a sincronização de maneira manual e imediata, o comando Start-ADSyncSyncCycle -PolicyType Delta é utilizado. Este comando inicia um ciclo delta, que sincroniza apenas as alterações ocorridas desde a última sincronização, facilitando um teste rápido e eficiente.

Verificando a Configuração do Agendamento

O agendamento regular de sincronizações garante a atualidade dos dados entre o Active Directory local e o Azure AD. Utilize Get-ADSyncScheduler para revisar as configurações atuais do agendador, incluindo a frequência de sincronizações.

Analisando Logs de Sincronização

Logs de sincronização oferecem insights valiosos sobre o processo. Acessá-los pode ser feito através do Visualizador de Eventos do Windows ou via PowerShell, permitindo a análise de eventos específicos ou erros ocorridos durante a sincronização.

Conclusão

A utilização do PowerShell para testar e verificar a funcionalidade do Azure AD Connect é uma prática recomendada que assegura a integridade e eficiência da sincronização de diretórios. Seguindo estes passos, administradores podem proativamente gerenciar e resolver qualquer questão, mantendo a sincronia perfeita entre ambientes locais e na nuvem.

1 de outubro de 2023
por luizhenriquelima
0 comentários

Falha na inicialização do Windows Server 2022 para o sistema operacional, copiando os dados do servidor problemático

Sintomas

Falha na inicialização do Windows Server 2022 no sistema operacional- o cliente gostaria de copiar os dados do servidor com problema.

Causa

Sistema operacional windows server 2022 corrompido.

Resolução

  1. Reinicie o computador ou o servidor.
  2. À medida que o computador ou o servidor estiver inicializando, pressione e mantenha pressionada a tecla F8 até que o menu Opções avançadas de inicialização seja exibido. Em seguida, escolha a opção Troubleshoot (Solução de problemas) e o Prompt de comando.
  3. No prompt de comando, use o comando robocopy, por exemplo: robocopy para copiar os dados do servidor problemático para uma unidade USB externa

28 de setembro de 2023
por luizhenriquelima
0 comentários

Vulnerabilidade DOS em servidores Windows executando SMB sobre QUIC

Resumo executivo

  • O pesquisador da Akamai, Ben Barnea, encontrou uma vulnerabilidade importante no Microsoft Windows Server 2022, que foi atribuída CVE-2023-24898 com uma pontuação básica de 7,5.
  • A vulnerabilidade está em uma verificação ausente em uma alocação de buffer no driver srvnet.sys.
  • A vulnerabilidade pode levar a ataques remotos de negação de serviço (DOS) contra máquinas Windows Server 2022. A vulnerabilidade pode ser acionada por um invasor não autenticado pela internet.
  • Somente os servidores que usam SMB sobre QUIC, um recurso relativamente novo, estão vulneráveis. Para ativar esse recurso, o servidor deve ser um Windows Server 2022 Azure Edition.
  • As vulnerabilidades foram divulgadas de forma responsável à Microsoft e abordadas na Patch Tuesday de maio de 2023.
  • Nós fornecemos uma consulta Insight para Akamai Guardicore Segmentation usuários para detectar servidores potencialmente vulneráveis em suas redes.

Introdução

QUIC é um protocolo de camada de transporte relativamente novo que foi originalmente projetado pelo Google, mas tem várias implementações. O objetivo do QUIC é fornecer uma conexão mais confiável e segura e, ao mesmo tempo, superar problemas comuns da Internet, como latência e perda de pacotes. Ele é transmitido sobre UDP.

A implementação da Microsoft do QUIC é chamada MsQuic. O Windows também incorpora o QUIC, usando-o como uma camada de transporte para o protocolo SMB (um recurso chamado SMB sobre QUIC) e com HTTP/3 no IIS. SMB sobre QUIC só está disponível no Windows Server 2022 Edição do Azure, enquanto o HTTP/3 está disponível para todas as implantações do IIS em execução no Windows Server 2022.

A vulnerabilidade discutida nesta postagem do blog está localizada no driver que implementa a camada de transporte do SMB, srvnet.sys.

A vulnerabilidade

Para manter o estado de uma conexão, o QUIC usa um identificador de conexão, que identifica exclusivamente uma conexão entre o cliente e o servidor. Um cliente pode criar várias conexões simultâneas. Uma conexão QUIC também é multiplexada; isto é, um cliente e um servidor podem trocar dados em vários fluxos simultaneamente pela mesma conexão.

O código para SMB sobre QUIC é implementado no srvnet.sys. Quando o servidor recebe novos dados em um fluxo, a função SrvNetQuicServerReceveEvent é chamada. O objetivo da função é ler uma mensagem SMB completa enviada pelo cliente. Depois de fazer isso com sucesso, ela transfere a mensagem para a lista de mensagens SMB para processamento posterior.

Para ler uma mensagem SMB, o código primeiro tenta ler o tamanho da mensagem SMB, que é representado por um número inteiro de quatro bytes. Se isso for feito com êxito, ele verifica se o tamanho não é maior do que o tamanho máximo permitido para uma alocação. Se a verificação passar, o código aloca um buffer com esse tamanho e tenta ler os bytes restantes do pacote no buffer recém-alocado. Se terminar de ler toda a mensagem SMB, ele indica à camada SMB que uma nova mensagem SMB foi recebida.

A estrutura de uma mensagem SMB é ilustrada na Figura 1.Mensagem SMBFig. 1: Uma estrutura de mensagens SMB em srvnet.sys

A vulnerabilidade ocorre se forem recebidos menos de quatro bytes para o tamanho da mensagem SMB (Figura 2). Nesse caso, o código salvará os X bytes recebidos e também será definido PendingMessageSize a 4 menos X — X o numero  de bytes recebidos para o tamanho da mensagem. Na próxima vez que um pacote for recebido, ele lerá os 4 – X bytes restantes necessários para o tamanho da mensagem SMB.A vulnerabilidade ocorre se forem recebidos menos de quatro bytes para o tamanho da mensagem SMBFig. 2: Um pacote malicioso teria menos de quatro bytes para o tamanho da mensagem

Uma vez que o código termina de ler o tamanho da mensagem, ele aloca imediatamente uma mensagem SMB sem executar a verificação deste tamanho em relação ao tamanho máximo permitido. Portanto, enviando o tamanho da mensagem SMB em dois pacotes em vez de um, um invasor pode ignorar a verificação de tamanho máximo permitido e solicitar uma alocação excepcionalmente grande.

Exploração

Para transformar esse bug em uma vulnerabilidade de DOS, precisamos enviar continuamente pacotes que acionem o problema descrito.

Mas mesmo com a capacidade de contornar o tamanho máximo permitido, ainda há duas restrições:

1. SrvNetAllocateBuffer teTem um limite rígido de 16 MB para alocações.
2. O número de conexões simultâneas não autenticadas permitidas é limitado de acordo com a RAM disponível no servidor. Essa restrição limita a exploração a servidores com até 32 GB de RAM. (Na próxima seção, vamos teorizar sobre como essa limitação pode ser contornada.)

Para explorar essa vulnerabilidade, primeiro tentamos criar várias conexões e enviar dois pacotes de cada vez para fazer com que o servidor alocasse 16 MB. Fazer isso repetidamente leva à exaustão da memória. Como essa vulnerabilidade está em um driver e é executada no modo kernel, todo o sistema se torna instável e não responde.

Uma exploração otimizada?

Essa exploração requer o envio de muitos pacotes. Acreditamos que, abusando dos recursos do QUIC, é possível reduzir o número de pacotes necessários.

Embora o QUIC permita vários fluxos em uma única conexão, ele também permite limitar esse número por meio da propriedade initial_max_streams_bidi . O SMB sobre QUIC limita a um o número de fluxos simultâneos para uma conexão.

Embora não seja possível aprimorar a exploração usando vários fluxos simultâneos, podemos tentar explorar a vulnerabilidade de uma maneira diferente. Em vez de criar vários fluxos simultâneos, criamos um pacote QUIC com vários quadros, de modo que a seguinte sequência ocorra em série e repetidamente:

1. Crie um fluxo
2. Acione a alocação de 16 MB enviando dois quadros DATA
3. Feche o fluxo

Dessa forma, também podemos contornar o limite de conexões não autenticadas. Deixaremos isso como um desafio para o leitor.

Detecção e mitigação

Para localizar um servidor SMB sobre QUIC em execução, os usuários do Akamai Guardicore Segmentation podem executar a seguinte consulta simples do Insight:

  select * from registry where 
path="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableSMBQUIC" and data=1

Copy

Recomendamos a aplicação de patches em seu computador Windows Server, pois não há outras atenuações ou soluções alternativas disponíveis para essa vulnerabilidade, exceto a desativação do recurso SMB sobre QUIC.

Resumo

O QUIC é um protocolo de rede relativamente novo que garante melhor desempenho e menor latência. Evidentemente, ele já foi adotado e incorporado em dois protocolos muito importantes: IIS (para HTTP/3) e SMB.

Acreditamos que o QUIC é uma nova e interessante superfície de ataque no Windows e de modo geral. Além do problema descrito aqui, outra vulnerabilidade, CVE-2023-23392, foi corrigida em HTTP/3.

Incentivamos outros pesquisadores a examinar os diferentes componentes que usam o MsQuic e o próprio MsQuic.