Vol. 1 No. 20251022-1000 (2025)

Fique atento as configurações de BIOCs

Hector Carlos Frigo | hector@cylo.com.br | 22/10/2025

Recentemente, me deparei com um incidente gerado após a detecção de um BIOC, o qual possuía o seguinte título: “Windows LOLBIN executable connected to a rare external host”.

O incidente informava a detecção de uma conexão externa suspeita realizada por um processo nomeado como “sc.exe”. Isso me levou a pensar que o alerta estava fazendo referência ao software nativo e amplamente conhecido do Windows, responsável pelo gerenciamento de serviços, “Service Control” e que o mesmo estaria sendo utilizado para realizar conexões com servidores de Command and Control, uma vez que entendo não ser nada comum esse processo realizar conexões externas.

Bom… neste caso, a realidade era bem diferente. Ao aprofundar as investigações, identifiquei que o software nomeado como “sc.exe” e responsável por realizar a conexão externa nada tinha a ver com o processo nativo do Windows “Service Control”. Inclusive, era assinado por outro fabricante. Da mesma forma, realizei todas as verificações necessárias para me certificar de que a conexão detectada não apresentava qualquer risco para o ambiente.

Foi então que me veio a ideia: o fator que levou a essa detecção foi a existência de uma regra de BIOC configurada especificamente para detectar conexões realizadas por processos que possuem como fator de validação apenas “nomes conhecidos do sistema operacional Windows”. Porém, ao surgir um software de terceiros que possui o mesmo nome que um desses processos, a BIOC irá disparar sem qualquer validação prévia, aumentando a chance da geração de falsos positivos…

Ou seja, não seria mais prático e acertivo, adicionar também como um dos requisitos de validação para o disparo desta BIOC a verificação da “Assinatura Digital“? A fim de certificar que apenas processos do sistema Windows sejam responsáveis pela “Trigger” desta regra.

Vol. 1 No. 20250814-855 (2025)

O PwdLastSet pode confundir?

João Fuzinelli | joao@cylo.com.br | 14/08/2025

Trabalhando em uma resposta a um incidente onde o Domain Admin foi comprometido, comecei a fazer um levantamento do campo PwdLastSet no Active Directory Domain Services com o objetivo de identificar, logicamente, os usuários que realizaram trocas de senhas antes e/ou durante o incidente. Sendo assim, me surgiu uma dúvida:

O atributo PwdLastSet pode ser alterado?

Primeiro, vamos a definição:

A data e a hora em que a senha dessa conta foi alterada pela última vez. Esse valor é armazenado como um inteiro grande que representa o número de intervalos de 100 nanossegundos desde 1º de janeiro de 1601 (UTC). Se esse valor for definido como 0 e o atributo User-Account-Control não contiver o sinalizador UF_DONT_EXPIRE_PASSWD, o usuário deverá definir a senha no próximo logon.

FONTE: https://learn.microsoft.com/en-us/windows/win32/adschema/a-PwdLastSet

Partimos para um laboratório onde subi um Active Directory Domain Services sobre um Windows Server 2022. Criei um usuário chamado lab.user com uma senha definida. O campo pwdLastSet adicionou as informações de data, hora e GMT configuradas no sistema operacional

Aí vem o teste. A primeira coisa que tentei foi adicionar um epoch time no usuárioporém sem sucesso em um script powershell.

Verificando a documentação entendi que é possível setar duas flags o 0 indicando que a senha nunca foi trocada e o -1 que utiliza do tempo atual.

O script e os resultados

OBS.: O script apresentado neste artigo é destinado exclusivamente para fins educativos e de aprendizado. Não nos responsabilizamos pelo uso indevido, aplicação em contextos não autorizados ou quaisquer consequências decorrentes da utilização deste código. Recomendamos que os leitores utilizem o script de forma ética e em conformidade com todas as leis e regulamentos aplicáveis.

Import-Module ActiveDirectory
    Import-Module ActiveDirectory
    Set-ADUser -Identity "lab.user" -Replace @{PwdLastSet="0"}
    Get-ADUser -Identity lab.user -Properties PasswordLastSet

Utilizando 0 como flag
Import-Module ActiveDirectory
    Import-Module ActiveDirectory
    Set-ADUser -Identity "lab.user" -Replace @{PwdLastSet="-1"}
    Get-ADUser -Identity lab.user -Properties PasswordLastSet
Adicionando -1 como flag

Entendo que existem outros campos como WhenChanged que podem ser utilizados para investigação porém o que me trouxe até aqui foi quanto isso poderia ser confuso para quem está respondendo ao incidente de cibersegurança