Vol. 1 No. 20250930-952 (2025)

Indicators of Compromise (IOCs) possuem data de validade?

Hector Carlos Frigo | hector@cylo.com.br | 30/09/2025

Recentemente, venho trabalhando com a coleta e identificação de IOCs (Indicators of Compromise), analisando indicadores dos mais diversos tipos que, de alguma forma, foram ou estão sendo associados a atividades maliciosas ou ilícitas no ambiente digital. artefatos esses que podem ser endereços IP, domínios, hashes, chaves de registro e até e-mails.

Essa coleta é importante, pois, com ela, é possível garantir uma visibilidade mais abrangente em um ambiente, otimizando a detecção de, como o nome sugere, “indicadores de comprometimento” em um sistema ou rede de sistemas.

Durante a coleta desses artefatos, dúvidas foram levantadas internamente, sendo as principais:

  • A data de validade de um IOC deve ser a mesma, independentemente do tipo de artefato?
  • Um indicador de comprometimento deve possuir uma validade?
  • Qual é o prazo de validade ideal para um IOC?

Acredito que parte da resposta para essas perguntas pode ser encontrada na famosa “The Pyramid of Pain”, um modelo interessante que visa dividir tipos de indicadores em camadas, baseando-se no formato de uma pirâmide. A ideia é: quanto mais próximo um tipo de IOC está da base da pirâmide, maior será a facilidade de um adversário alterar esse indicador.

Como é possivel observar, na base da pirâmide encontramos “Endereços Hash” mas o que isso significa? Basicamente um endereço Hash tem a função de servir como uma “Impressão digital” de um arquivo ou processo no sistema, ou seja, cada arquivo existente, receberá um valor HASH único que tem o papel de identifica-lo (inclusive arquivos maliciosos).

Sem dúvidas, é uma fonte poderosa de informação, tornando possível a identificação de malwares conhecidos simplesmente com a coleta desse artefatos, porém, um fato que “enfraquece” a utilização de hash como IOC é que uma simples alteração de qualquer binário nesse arquivo acarretará na atribuição de um novo valor identificador completamente diferente para esse arquivo. Portanto, adversários podem, com muita facilidade, alterar o endereço hash de seus scripts maliciosos e evadir detecções previamente criadas em sistemas de segurança mais simples. Justamente por essa versatilidade de alteração nos valores, os endereços hash encontram-se na base da Pyramid of Pain.

Criação de um arquivo de texto nomeado “hash.txt” onde foi adicionado o valor “Isso é um malware cuidado!” é possivel ver o endereço HASH SHA-256 deste arquivo recém criado.
Modificação do arquivo “hash.txt” recém criado, adicionando mais um carácter ” ! “ alterando seu valor inicial, endereço HASH SHA-256 foi COMPLETAMENTE alterado

Sabendo da facilidade que um Adversário possui para modificar qualquer binário em seus scripts, surge uma dúvida: “Qual seria a validade ideal para um IOC do tipo HASH?” Na minha visão, a resposta mais adequada seria: “Depende do quão bem é possível identificar o objetivo do Adversário“. Essa lógica se aplica não apenas as HASHES, mas também a outros tipos de Indicadores, como IPs, chaves de registro, domínios etc..

Tendo como exemplo atacantes que têm como principal objetivo “lucrar sem olhar a quem”, são agentes de ameaça que irão desenvolver scripts maliciosos buscando atrair o máximo de usuários desavisados possível a executar o seu malware, por meio de ataques de cryptojacking, adwares ou infostealers, que geralmente ficam abertamente disponíveis para download em websites que possuem títulos chamativos, como “Baixe mais memória RAM” ou “Cupom grátis de R$100,00 na Amazon”.

O ponto focal do tipo de kill chain adotado por esse adversário é que não há um alvo específico definido. Seu objetivo é infectar o máximo de vítimas e gerar lucro em um período de tempo pré-definido. Depois de esgotado esse tempo, o adversário provavelmente desaparecerá, não sendo muito relevante se o seu script for reconhecido e coletado como artefato em algum momento e bloqueado pela empresa “XYZ”, visto que muitos outros foram induzidos a serem infectados.

Para situações como a descrita acima, é sim importante coletar o máximo de indicadores possíveis e adicioná-los às suas regras de detecção. Porém, como essas campanhas “não direcionadas” costumam não ficar ativas por muito tempo, é plausível entender que não há necessidade da adoção de uma data de validade extensa, podendo, neste caso, configurar esses indicadores para serem detectados em um menor período de tempo.

Em contrapartida, há, de igual modo, cenários — ainda que mais raros — em que o agente de ameaça terá como alvo escolhido a dedo você ou a sua empresa.
Nesses casos, toda a cadeia de ataque desenvolvida pelos adversários será inspirada em vulnerabilidades encontradas em seu ambiente. Situações como essas são atribuídas a agentes de ameaça mais experientes, tornando provável que os seus analistas de segurança sejam os primeiros a coletar certos artefatos.
Cabe a eles identificá-los e entender seus graus de periculosidade.

Ao tomar ciência de que você está na mira de um atacante persistente, disposto a fazer de tudo para atingir seu objetivo final, os artefatos coletados devem, consequentemente, possuir um prazo de validade mais extenso. Pois, nesse cenário, não há como prever por quanto tempo você será um alvo. Campanhas direcionadas costumam durar meses ou até anos, e, nesse período, é de extrema importância coletar o máximo de IOCs possível.

Quanto mais indicadores forem detectados e bloqueados, maior será a necessidade de alteração dos artefatos utilizados pelo atacante, tornando-se um trabalho exaustivo para ele. Neste cenário, vale lembrar que a simples coleta de indicadores não é suficiente para mitigar um ataque persistente, sendo ainda necessária uma série de políticas bem desenvolvidas e ferramentas de segurança e monitoramento bem configuradas.

Para concluir, é certo que se faz necessária a adição de datas de validade para indicadores de comprometimento. Porém, deve-se levar em consideração sempre o cenário ao qual esses IOCs estão sendo atribuídos, assim como identificar se o tipo de ataque ao qual esses artefatos estão relacionados está direcionado exclusivamente a você ou ao seu ambiente, ou se está espalhado pela internet, a fim de atingir um alto volume de vítimas não relacionadas umas com as outras. A renovação de IOCs deve ser encarada como uma política de segurança essencial para o ambiente de toda empresa, e a definição do seu tempo de validade deve ser levantada e considerada com muita cautela.

Vol. 1 No. 20250808-803 (2025)

Detectando Técnicas de Persistência em Endpoints Windows

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

Comprometer um sistema não se trata apenas da quebra de uma credencial ou o upload de um malware em um endpoint, agentes de ameaça pensam muito além do acesso inicial, ele ou ela farão de tudo, a fim de alcançar seu objetivo final, podendo ser um vazamento de dados, roubo de propriedades intelectuais, ou em muitos casos uma infecção de ransomware.

Para que isso possa ocorrer, o atacante precisará permanecer vivo e operante no ambiente, uma vez que não é possível calcular quanto tempo ele levará para cumprir seu objetivo, portanto neste post eu gostaria de abordar algumas das técnicas de persistência mais comuns encontradas em ambientes que foram alvos de incidentes cibernéticos, observados em nosso dia a dia no SOC.

A grande realidade é que existem incontáveis técnicas utilizadas por agentes de ameaça para garantir persistência em um ambiente, muitas delas mapeadas pelo famoso framework “MITRE ATT&CK”. Primeiramente, gostaria de definir “O que é” uma técnica de persistência e por que ela é tão importante para um criminoso cibernético. Em seguida, exemplificarei algumas dessas técnicas me baseando em situações reais detectadas por nosso time de segurança.

Conforme a definição do MITRE ATT&CK “Persistência consiste em técnicas utilizadas por adversários para manter acesso a um sistema, indiferente a reinicializações, alterações de credenciais e/ou outras interrupções capazes de cortar seu acesso ao ambiente[…]” basicamente, essa tática ocorre somente após a invasão de um sistema, onde o descrito “adversário” planeja manter-se ativo na infraestrutura da vítima que pode ou não, estar ciente da ocorrência do incidente, essas técnicas são essenciais para a resiliência do atacante, que ainda não atingiu seu objetivo final.

Entendendo agora o “por que” de um agente de ameaça utilizar essas técnicas, agora devemos esclarecer “COMO” isso geralmente é feito… A grande realidade é que os Sistemas Operacionais atuais, facilitam muito o emprego de persistência, devido a diversos recursos nativos, criados em tese para auxiliar no funcionamento de softwares e processos legítimos, utilizados pelos usuários finais, mas quando configurados corretamente em favor do atacante, são ferramentas-chave para seu sucesso no ambiente.

Irei abordar algumas das técnicas mais comuns encontradas em incidentes cibernéticos reais voltados a ambientes “Microsoft Windows”, lembrando que para o “hacker” experiente, “o céu é o limite”, portanto não devemos nos apegar somente ao que será apresentado aqui, ou somente as técnicas já mapeadas pelo MITRE ATT&CK, mas sim compreender que, a medida que as tecnologias evoluem, inevitavelmente maneiras de se conquistar persistência, também irão seguir esse rumo.

Outro fato que devemos considerar é sobre a existência de inumeras táticas e técnicas utilizadas em ambientes “Unix” e também em outros Sistemas Operacionais, porém neste artigo abordarei somente o emprego das mesmas em sistemas “Windows”.

Startup Folder

Para iniciar, introduzirei uma técnica muito interessante e efetiva em ambientes sem monitoramento e análise comportamental. Por padrão, o sistema operacional Windows possui diretórios de startup que são críticos e comumente utilizados por agentes de ameaça que buscam persistência no ambiente, sendo eles:

Startup global (todos os usuários):
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

Startup de usuário especifico:
C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

A inclusão de programas ou scripts como arquivos com extensões ps1, .bat, .cmd, entre outros… nestes diretórios do sistema irá resultar em sua execução automática sempre que um usuário se autenticar. Essa prática é frequentemente explorada por agentes maliciosos como uma forma eficaz de garantir persistência no ambiente comprometido. Ao configurar esses arquivos para serem executados em momentos estratégicos, como o logon do usuário, o invasor assegura que seu código continue ativo, mesmo após reinicializações ou tentativas de limpeza, mantendo o controle sobre o sistema de forma discreta e contínua.

Observamos a utilização desta técnica em um ataque recentemente presenciado pela nossa equipe, onde, após ganhar acesso ao endpoint, o agente de ameaça realizou o upload de um malware nomeado como “explorer.exe” no sistema e imediatamente adicionou um arquivo .lnk referenciando ao malware no diretório: C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\

Tarefas agendadas

A criação e utilização de tarefas agendadas, poderia ser considerada a técnica de persistência mais conhecida e comumente utilizada em um ambiente comprometido, a técnica consiste na utilização do recurso de criação de tarefas agendadas nativo do Windows para realizar a execução periódica de arquivos ou scripts maliciosos, desta forma garantindo que, mesmo que o processo malicioso seja finalizado por um usuário do sistema, o mesmo volte a ser executado através da utilização deste recurso.

No mesmo incidente citado anteriormente, foi também possível presenciar a criação de uma tarefa agendada cujo a finalidade era executar um software malicioso a cada 1 minuto no ambiente, como mostrado na imagem abaixo:

“C:\Windows\System32\schtasks.exe” /create /f /RL HIGHEST /sc minute /mo 1 /tn “explorer” /tr “C:\Users\Administrator\AppData\Roaming\explorer.exe”

Na imagem e linha de comando acima é possivel observar a utilização do processo nativo “schtasks.exe” para criar uma tarefa agendada com os seguintes parametros:

  • /create: Cria uma nova tarefa.
  • /f: Força a criação, sobrescrevendo qualquer tarefa existente com o mesmo nome.
  • /RL HIGHEST: Define o nível de privilégio como máximo (executa com privilégios de administrador).
  • /sc minute: Define a frequência da tarefa como a cada minuto.
  • /mo 1: Modificador da frequência — neste caso, a cada 1 minuto.
  • /tn "explorer": Nome da tarefa será "explorer".
  • /tr "C:\Users\Administrator\AppData\Roaming\explorer.exe": Caminho do arquivo malicioso nomeado como “explorer.exe”.

Por mais que os parâmetros definidos aparentam ser bem “barulhentos” ainda assim há dificuldade em sua detecção sem o auxílio de ferramentas que estejam configuradas corretamente para realizar a busca por esses comportamentos característicos.

Chaves de registro.

Chaves de registro são peças fundamentais no sistema operacional, por serem responsáveis por garantir o funcionamento de praticamente todos os processos, serviços e conexões existentes no sistema, incluindo também a inicialização dos programas, por esse motivo, alterações e criações de novas chaves de registro no Windows são técnicas extremamente comuns de serem utilizadas por agentes de ameaça para se manter vivo no ambiente, sendo bem semelhante com a primeira técnica discutida neste post, as seguintes chaves de registro geralmente tornam-se alvo de cibercriminosos que buscam adicionar a elas um “valor” que posteriormente irão realizar a execução de processos maliciosos.

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

As chaves de registro apresentadas acima são apenas um exemplo de muitas outras, que possuem capacidades semelhantes, portanto é sempre recomendado configurar ferramentas de detecção para monitorar qualquer alteração ou criação suspeita de chaves de registro que possam ter ocorrido no sistema.

Como podem ver, no incidente analisado por nossa equipe, também foram detectadas mudanças em chaves de registro, onde as alterações realizadas tinham como objetivo executar o conhecido malware nomeado como “explorer.exe” no sistema, utilizando as chaves citadas anteriormente.

Criação de usuários.

A criação de novos usuários em sistemas comprometidos é uma prática comum em incidentes de segurança. Essa técnica é frequentemente usada para garantir persistência no ambiente invadido. Quando um atacante cria contas adicionais no endpoint afetado, ele estabelece uma forma de retorno fácil ao sistema, mesmo que as credenciais originais sejam alteradas ou revogadas. Assim, caso o usuário legítimo tente mitigar o ataque trocando senhas ou removendo acessos, o invasor ainda pode retomar o controle utilizando os usuários previamente criados, dando continuidade às suas ações maliciosas.

Portanto, é sempre muito recomendado realizar a detecção e homologação de todos os usuários criados no ambiente, independentemente se são locais, de serviço ou do domínio, além de definir precisamente quem possuirá o nível de privilégio necessário para realizar criações de novos usuários no sistema.

Conclusão

Após analisar algumas das mais famosas técnicas de persistência utilizadas “world-wide”, entende-se que um Adversário bem preparado irá quase sempre, utilizar mais de uma técnica de persistencia em um ambiente comprometido, e que não existe grande complexidade em desenvolve-las e coloca-las em operação, portanto o analista de SOC treinado a buscar e reconhecer essas praticas, tende a estar sempre um passo a frente dos cibercriminosos.

Referências

https://attack.mitre.org/techniques/T1547/001

https://attack.mitre.org/techniques/T1136

https://attack.mitre.org/techniques/T1078/003

https://attack.mitre.org/tactics/TA0003

Vol. 1 No. 20250620-619 (2025)

O Poder do SSL Deep Inspection nas Investigações de exfiltração de Dados

Hector Carlos Frigo | hector@cylo.com.br | 20/06/2025

Nos últimos meses temos recebido inúmeros alertas relatando possíveis vazamentos de dados, por se tratar de um tópico extremamente sensível, podendo comprometer operações do cliente e com alto potencial de afetar diretamente sua propriedade intelectual, aos poucos começamos a desenvolver técnicas que otimizaram nosso tempo de resposta, nos ajudando a detectar, qual volume de dados foi exfiltrado do ambiente, e o que na minha opinião é o mais importante.. QUAIS dados foram exfiltrados. Desafio que tínhamos sempre ao lidar com esse tipo de incidente (identificar quais arquivos foram movimentados para fora da empresa, sempre foi uma grande dificuldade). Com essa evolução, foi possível realizar uma melhor distinção entre os casos de incidentes reais e casos falsos positivos.

Como ponto chave da melhora do nosso processo, identificamos que a adoção do uso de SSL Deep-Inspection para todo trafego de rede, possibilita uma visualização única e mais assertiva no trafego suspeito que será investigado por nós, Analistas de SOC, essa tecnologia viabiliza o monitoramento do trafego na camada de aplicação, tornando possível observar acesso a subdiretórios, e também identificar quais ARQUIVOS estão sendo movimentados para destinos fora do ambiente da empresa.

Para uma melhor visualização desta solução em funcionamento, realizei alguns testes com um firewall da Fortinet em um ambiente de teste, o qual será descrito abaixo (Lembrando que a aplicação do Deep-Inspection deve ser semelhante independente do serviço de Firewall adotado)

Primeiro criei alguns arquivos com nomes bem tendenciosos, para realizar o teste

Após isso, realizei a criação de uma regra no firewall batizando-a de “Teste Deep Inspection”, permitindo todo trafego LAN to WAN sem restrições e por fim habilitar a função de Deep-inspection na regra.

Após a criação da regra, devemos testá-la, para isso, basta entrar em um site que possua SSL ativo e observar seu certificado digital, acessei o Google.com, que originalmente possui o certificado atribuído pelo Google Trust Services.

Com a regra de SSL Deep Inspection funcionando, espera-se observar um certificado digital emitido por nosso serviço de Firewall, e não mais o certificado original criado pela provedora do site

Certificado do google.com SEM Deep-Inspection habilitado
Certificado do google.com COM Deep-Inspection habilitado

Com a regra funcionando, vamos dar inicio ao teste prático, onde realizei o UPLOAD dos 4 arquivos que criei em minha estação de teste, para o meu Google Drive PARTICULAR (Comportamento muito comum observado em diversos alertas de Exfiltração de dados)

Upload de arquivos realizados com sucesso! Vamos ver o que os logs do Firewall têm a nos dizer…

Realizei um filtro baseado no endereço MAC da minha estação de teste, para facilitar encontrar os logs do Upload, e depois de alguns segundos de espera, lá estava… Todos os arquivos que foram movimentados para o meu Google Drive particular por meio de conexões realizadas utilizando a rede da empresa, com a regra de Deep-Inspection ativa e operante, identificados por nome e extensão do arquivo (sendo possivel também adicionar o filtro do tamanho do arquivo) simplesmente com a aplicação de uma regra facilmente configurada em nosso Firewall.

Imaginando a aplicação deste exemplo em um ambiente real, onde é extremamente necessário monitorar as ações realizadas em todos os endpoints, justamente para prevenir vazamento de propriedade intelectual, e evitar perdas devastadoras para a empresa, empregar o SSL Deep Inspection como aliado nas investigações de alerta de exfiltração de dados é altamente recomendado

É importante ressaltar que, o emprego desta tecnologia deve somente ocorrer, após o consentimento dos usuários, ou seja, os colaboradores conectados a rede, devem saber que estão sendo monitorados por sua equipe de SOC, fato pode ser adicionado a uma cláusula do contrato de trabalho por exemplo, pois a ausência desse consentimento, pode implicar diretamente a quebra do direito a privacidade, garantida principalmente pela LGPD porem abordada também em diversos outros textos de lei.

Neste pequeno exemplo, foi possivel observar o quão importante o SSL Deep-Inspection pode ser para detecção de exfiltração de dados, Ouso dizer que é uma técnologia essencial contra vazamento de informações, em um mundo onde a propriedade intelectual com certeza é um dos ativos mais valiosos da sua empresa.

Vol. 1 No. 20250502-389 (2025)

Políticas de Endpoint irão salvar seu ambiente!

Hector Carlos Frigo | hector@cylo.com.br | 02/05/2025

Recentemente participei da investigação de um incidente interessante que poderia ter levado a um fim extremamente desastroso. Recebemos diversos alertas que relatavam uma atividade suspeita realizada por um usuário desorientado, ao conectar um dispositivo removível desconhecido em sua estação de trabalho, e em seguida, tentar executar um arquivo suspeito presente no mesmo. A ação foi imediatamente bloqueada devido a política existente na estação e reportada ao nosso time.

Iniciamos nossas investigações, onde a princípio, identificamos, que o arquivo, estava nomeado exatamente como um software legitimo conhecido, e confirmadamente utilizado nas operações do cliente. Como de prática, partindo do princípio de “Nunca confiar, sempre verificar” realizamos uma “primeira” análise no arquivo, coletando sua hash SHA-256 e submetendo-a, a sandboxes online, com objetivo de verificar se essa hash já era conhecida, quais conexões externas são realizadas caso haja, relações com outros executaveis, versionamento, entre outras informações necessárias para a investigação.

Arquivo suspeito se encontrava no dispositivo removivel mapeado no disco D:

A hash submetida apresentou resultados alarmantes, multiplos indicadores classificaram o arquivo suspeito submetido, como TROJAN, apontando diversos comportamentos suspeitos, além do fato de já ter sido submetido as sandboxes anteriormente, com nomes diferentes, tentando se passar por processos legítimos do Windows ou arquivos genéricos nomeados em português.

Resultado da Analise realizada no VirusTotal
Lista de nomes que foram associados a esse arquivo

Após o recebimento destes resultados, realizamos uma análise mais aprofundada neste arquivo em um ambiente isolado e preparado para detectar cada ação realizada pelo software , ao executa-lo, imediatamente identificamos uma série de comportamentos suspeitos bem característicos adotados por malwares, como:

capacidade do software se “autor replicar” e “auto deletar”

Cadeia de execução realizada pelo Malware

Sessões com alta entropia e emprego de pacote UPX para dificultar engenharia reversa

“****_9_400**21.exe” has a section named “UPX0”
“****_9_400**21.exe” has a section named “UPX1”
“****_9_400**21.exe” has section name UPX1 with entropy “7.928493634034875”

Além de realizar conexões com servidores DNS dinâmicos, criação de arquivos no diretório reservado para o sistema operacional, entre outras ações que minimizaram ainda mais as dúvidas de que o software presente nesta mídia removível de fato possuía intenções maliciosas.

Sem dúvidas estávamos lidando com um Malware de alta periculosidade e complexidade, que com certeza teria um grande impacto e causaria grandes danos ao ambiente em que fosse executado, porém graças a adoção de políticas de segurança rígidas de endpoint, anteriormente definidas e empregadas em todo o ambiente da empresa, esse incidente pode ser evitado. Desta maneira gostaria de despertar uma reflexão; qual seria o impacto causado no ambiente, se houvesse a ausência dessas políticas?
Assim como o ciclo de resposta a incidente do NIST nos apresenta, fases como “lições aprendidas” e “preparação” são voltadas justamente para estabelecer regras e estratégias que dificultem as ações tomadas por agentes de ameaça, garantindo um ambiente mais resiliente e robusto.