Vol. 1 No. 20250606-613 (2025)

De Botnet para… jogo online?

Yuri Augusto | yuri@cylo.com.br | 06/06/2025

Recentemente o IPS detectou diversos alertas suspeitos, onde alguns dispositivos, móveis estavam se conectando à botnets. Bom… no mínimo preocupante. A botnet? Sality botnet. Isso já pareceu estranho, pois todos os artigos encontrados na internet referentes à essa bonet, são datados de 10 anos atrás ou mais ainda mais antigos que isso. Mas é aquele negócio, melhor um falso positivo investigado do que um positivo não investigado, correto?

Todas as conexões que o IPS pegou (e algumas outras não alertadas pelo sistema) eram destinadas à porta 7500 UDP. O endereço? Tencent e Zenlayer, duas empresas de cloud. O maior problema ao realizar essas investigações é a teimosia do ser humano, e aqui não foi diferente. Bati cabeça com os endereços de destino e portas usadas, nenhum resultado. Afinal, os endereços não são maliciosos.

Ao parar e descansar um pouco, as sinapses voltaram a ocorrer, descansar a mente também ajuda a assimilar a informação. Se não encontrei nada referente à essas portas, hora de olhar outros logs, por exemplo, application control. E lá estava uma nova informação relevante, “Call of Duty Mobile”, apesar de ainda não ter certeza do que estava ocorrendo, pelo menos não é algo malicioso (ufa).

Agora a pesquisa ficou mais fácil, fazer a verificação dos endereços e portas utilizadas pelo jogo. E lá estava, as informações coincidem com todas as comunicações observadas no alerta.

Informações de endereços e portas retiradas do site do jogo.

Já cheguei até aqui, então vamos fazer a prova final? Instalar no próprio celular e avaliar as conexões de rede através do firewall (de quebra ainda tira um lazer). Pronto, paranoia controlada, todas as conexões “suspeitas” estão sendo realizadas pelo jogo.

Validação realizada pelo pcap, capturado pelo firewall.

Por fim, fica aquele questionamento “excesso de zelo” ou “perca de tempo”? Em um ambiente crítico, onde uma pequena falha pode levar à danos irreparáveis, com certeza é melhor prezar pelo excesso de zelo. Nunca assuma nada, sempre investigue.

Vol. 1 No. 20250530-596 (2025)

A importância do SOC na Cibersegurança.

João Paulo Gonsales | jgonsales@cylo.com.br | 30/05/2025

Durante um treinamento recente em Cibersegurança, focado em “Foundations of Incident Management”, entre muitos temas importantes abordados no treinamento, um ponto crucial se destacou: a importância de uma resposta rápida e coordenada a eventos de Segurança da Informação.

Em um cenário onde a tecnologia está em constante evolução, com a área de cibersegurança não seria diferente, a rápida evolução das ameaças e a forma de como os ataques cibernéticos são realizados, a segurança digital para as organizações deixou de ser um diferencial para se tornar uma necessidade e, uma pergunta que não podemos ignorar para as organizações é, “não é se a sua empresa será atacada ou não, mas quando. O ataque será efetivo?” Seguindo neste contexto, um Security Operations Center (SOC) se destaca como uma peça fundamental na estratégia de defesa para as organizações, adicionando uma camada de proteção no ambiente de tecnologia e se tornando essencial para uma melhor resiliência cibernética. 

Podemos definir o SOC como um centro especializado em segurança cibernética, responsável pelo monitoramento, detecção e resposta para incidentes de segurança. Utilizando tecnologias avançadas e composto por equipes de especialistas em cibersegurança, tecnologias em geral e processos, ele opera com o objetivo de identificar e responder as ameaças em tempo real, adicionando uma camada essencial para a resiliência cibernética das organizações e minimizando os riscos que possam causar danos significativos.  

Vamos relacionar um SOC como uma “torre de controle” com foco para a segurança da informação da sua empresa, onde com uma equipe especializada, são realizados a monitoração dos dados do ambiente,  comportamentos suspeitos , tráfego de rede, sistemas, aplicativos e dispositivos em busca de qualquer atividade suspeita. 

Oferecendo uma camada de proteção proativa, o trabalho e a importância de um SOC vai muito além da simples detecção de ameaças, onde podemos destacar um pouco mais das suas atividades ; 

  • Detecção rápida de eventos de segurança : Pesquisas indicam que o tempo médio de permanência de um invasor no ambiente de rede pode chegar em 200 dias ou mais antes de ser identificado e, conseguir garantir a capacidade de identificar a ameaça rapidamente é crucial. O SOC utiliza ferramentas avançadas para garantir uma rápida detecção, como a utilização de ferramentas de XDR, SIEM (Security Information and Event Management) e SOAR (Security Orchestration, Automation and Response) para identificar padrões maliciosos, correlacionar eventos, automatizar e gerar alertas em tempo real para a equipe à possíveis ameaças, minimizando o tempo que um atacante tem para causar danos para as organizações. 

  RSA Conference 2022 – 2022_USA22_HTA-M05_01_Strong-Story-to-Tell-Top-10-Mistakes-by-Administrators-About-Remote-Work_1654099348955001KxG2.pdf 

  • Resposta a Incidentes : Quando um incidente ocorre, uma equipe bem coordenada faz toda a diferença na resposta do incidente, com um SOC estruturado e treinado, possuir um plano e treinamento para realizar a resposta de incidentes faz toda a diferença, os processos são rapidamente colocados em pratica, gerando a contenção e a erradicação da ameaça. Aplicar o plano de recuperação quando for necessário , realizar relatórios pós-incidente e a identificação da causa raiz, evitando futuras ocorrências. A falta de um plano de resposta eficiente pode levar a grandes perdas financeiras e gerar danos irreparáveis à reputação da empresa.  
  • Monitoração do ambiente 24hx7: Diferente de uma abordagem reativa, o SOC mantém um monitoramento constante, identificando ameaças comportamentais , processuais , físicas e evitando que vulnerabilidades sejam exploradas. Com a utilização de informações de threat intelligence, a detecção no estágio inicial faz toda a diferença para mitigar possíveis ataques. 
  • Políticas e Processos:  Uma equipe de SOC realiza o suporte durante o desenvolvimento da política de segurança da informação (PSI), planos de comunicação, planos de recuperação (backup e restore), apoio também em auditorias e fornecimento de relatórios, garantindo que os processos estabelecidos sejam seguidos para que tenhamos um aumento da postura de segurança do ambiente. 

Uma pesquisa disponibilizada pela empresa Palo Alto Networks, lider global em segurança cibernética, indicam números alarmantes para o Brasil. O pais tem sido um alvo frequente de ataques cibernéticos, sofrendo bilhões de tentativas de ataques no último ano e isso reforça a necessidade de manter um ambiente de segurança robusto. O apoio do SOC é fundamental nesta jornada e vem se tornando um elemento estratégico para as organizações.  

Referencias : 

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. 20250520-590 (2025)

    Pessoas, a linha de frente

    Anísio José Moreira Neto | anisio@cylo.com.br | 20/05/2025

    Dentro dos conhecimentos de cybersecurity tenho para como escrito em pedra “os três Ps”, PPP:

    Pessoa

    Processo

    Produto

    Como pessoas, temos que entender o elemento humano, o tomador de decisão final, a que consome a tecnologia.

    A decisão da pessoa é a que vale quando o Produto não teve posicionamento, quando o processo não previu. O treinamento das pessoas nunca pode ser visto como despesa; elas precisam saber o que fazer, como fazer (processo) e onde fazer (produto).

    Em uma situação, após o almoço, renovei o certificado SSL de uma empresa cliente em um popular serviço de hospedagem brasileiro. Durante o atendimento, conversei com a pessoa do financeiro e lhe informei o valor que lhe seria cobrado por tal renovação. Ela me relatou a rotina de pagamento trimestral que faz para este serviço de hospedagem. Tudo certo.

    Ao final do dia, a pessoa do financeiro me ligou questionando-me se um boleto de um valor expressivo que recebeu havia sido emitido em decorrência da renovação que eu havia feito. A minha resposta foi não, mas solicitei-lhe que o e-mail fosse enviado como anexo para análise.

    Disse-lhe: “Arraste a mensagem para a área de trabalho e, depois, arraste o arquivo para um novo e-mail e me envie”.

    Como parecia dentro do contexto, comecei a me questionar: “Será que estão cobrando mais coisas??? Será que o preço mudou???”.

    Quando o e-mail chegou na minha caixa de entrada, não me contive e em pensamento já julguei o usuário, pois o assunto começava com “ENC:”. A pessoa me encaminhou o e-mail, sem seguir as orientações que eu havia dado no sentido de anexar a mensagem a um novo e-mail. Eu não tinha, então, o cabeçalho.

    Durante a leitura do e-mail, o remetente parecia real. Entendo o usuário não duvidar da mensagem com base neste campo. Fiquei intrigado: “Deve ter alguém dentro do provedor de hospedagem, um Insider, que viu o cliente adicionar o serviço e mandou um boleto falso antes do real???”

     Ainda lendo o e-mail, o corpo não tinha como ter contexto. Estava informando que o domínio seria desativado por falta de pagamento. Neste momento, já notifiquei a pessoa para ela não pagar o boleto, pois se tratava de golpe.

    Mas, no SOC, não podemos assumir nada. Como eu não tinha o cabeçalho, acessei a ferramenta de administração do e-mail em nuvem do cliente (aqui sendo o outro “P” – Produto) e realizei o rastreio dos e-mails recebidos pela pessoa do financeiro no dia, seguindo aqui um Processo (o outro “P”).

    Logo de início, estranhei o fato de ter que buscar o e-mail entre todos os recebidos naquele dia, pois ele estava no final da lista, indicando que havia sido recebido nas primeiras horas do dia, enquanto a renovação havia sido feita após o almoço. Com essa constatação, já descartei a possibilidade de se tratar de um Insider, como havia pensado anteriormente.

    Ao expandir os detalhes da mensagem na tela de rastreio, notei que a ferramenta de e-mail tinha colocado a mensagem do golpe no lixo eletrônico da caixa de correio do financeiro.

    No calor do momento, mais julgamentos: “COMO QUE ELA FOI CAVAR ISSO NO SPAM DELA?????”. Em instantes, porém, já o alívio: “pelo menos ela não pagou, consultou os envolvidos, foi prudente.”

    Cheguei à conclusão de que o atacante quase teve sucesso por ter enviado muitos e-mails destes para os clientes da empresa de hospedagem, pois em um deles, neste caso o meu cliente, existiu uma compra real no mesmo dia; horas depois, mas no mesmo dia. Mesmo o produto do cliente – a solução de e-mail na nuvem – tendo feito corretamente a parte dele e colocando o e-mail falso no lixo eletrônico, a pessoa atravessou a linha, abrindo a mensagem e a encaminhando.

    Ao encaminhar a mensagem, ao invés de anexar como eu havia solicitado, todas as imagens do e-mail falso foram carregadas. Com isso, o atacante soube que este alvo leu o e-mail e, provavelmente, o colocou em uma lista de alvos com mais chances de sucesso.

    A solução oferecida pelo produto quase não fora suficiente para garantir a proteção do cliente. A linha de frente, isto é, o primeiro P – Pessoa, ignorou a proteção fornecida pelo terceiro P – Produto, o que quase gerou prejuízos à empresa.

    Desta forma, não podemos nos esquecer da importância de treinar as pessoas, pois o produto por si só, por vezes, não basta.

    Vol. 1 No. 20250513-583 (2025)

    Vulnerabilidades sendo exploradas em roteadores D-Link

    Adriano Cansian | adriano.cansian@unesp.br | 13/05/2025

    Nas últimas 72 horas estamos observando uma onda de ataques focados em roteadores D-Link, especificamente nos modelos D-Link DIR-600L, DIR-605L e DIR-619L. Essas vulnerabilidades são preocupantes porque muitos desses dispositivos atingiram o fim de seu suporte (EOL – End of Life), o que significa que não receberão atualizações de firmware para corrigir os problemas.

    Esses roteadores foram lançados entre 2010 e 2013, quando o padrão 802.11n era amplamente adotado em dispositivos de entrada. Eles foram amplamente comercializados, especialmente em mercados emergentes como Índia, Brasil e Filipinas, devido ao seu baixo custo e funcionalidades básicas. Continuam em uso em residências e pequenas empresas, especialmente em regiões onde o custo de substituição é uma barreira, ou onde os usuários não estão cientes das vulnerabilidades.

    Alguns exemplos de vulnerabilidades recentes nesses dispositivos:

    1. D-Link DIR-600L

    Vulnerabilidades muito recentes

    • CVE-2025-4349 (05/05/2025): Uma vulnerabilidade crítica no firmware até a versão 2.07B01, afetando a função formSysCmd. A manipulação do argumento host permite a execução remota de comandos, possibilitando que um atacante assuma o controle do roteador sem autenticação.
    • CVE-2025-4350 (05/05/2025): Outra falha crítica na função wake_on_lan do mesmo firmware. A manipulação de argumentos pode levar à execução de código arbitrário, permitindo ataques remotos.

    2. D-Link DIR-605L

    Vulnerabilidades muito recentes

    • CVE-2025-4441 (08/05/2025): Vulnerabilidade de estouro de buffer (buffer overflow) que pode ser explorada remotamente manipulando o parâmetro curTime. Isso permite a execução de código arbitrário, comprometendo o roteador.
    • CVE-2025-4442 (08/05/2025): Outro estouro de buffer remoto, desta vez via manipulação de configurações WAN, também permitindo execução de código malicioso.

    3. D-Link DIR-619L

    Vulnerabilidades muito recentes

    • CVE-2025-4454 (08/05/2025): Vulnerabilidade crítica no firmware 2.04B04, afetando a função wake_on_lan. A manipulação de argumentos permite execução remota de código, possibilitando o controle total do roteador.
    • CVE-2025-4453 (09/05/2025): Injeção remota de comandos no mesmo firmware, explorável via manipulação de parâmetros, permitindo que atacantes executem comandos arbitrários.
    • CVE-2025-4452 (09/05/2025): Estouro de buffer na função formSetWizard2, que pode ser explorado remotamente para comprometer o roteador.
    • CVE-2025-4449 (09/05/2025): Estouro de buffer na função EasySetupWizard3, presente em firmware não suportados, permitindo execução de código malicioso.

    Possíveis impactos:

    De forma bastante resumida, essas vulnerabilidades permitem que atacantes:

    • Executem comandos remotamente, comprometendo completamente o roteador.
    • Alterem configurações, como senhas Wi-Fi ou regras de firewall.
    • Obtenham credenciais de administrador, possibilitando o controle total do dispositivo.
    • Realizem ataques de rede, como redirecionamento de tráfego ou monitoramento de dados.
    • Obtenham controle total do roteador incluindo alterações de configuração e execução de código malicioso.
    • Realizem sequestro de sessões administrativas, comprometendo a segurança da rede.

    O que fazer?

    Infelizmente não há muito que possa ser feito que permita continuar utilizando esses equipamentos. A única solução definitiba é comprar um roteador moderno de um fabricante que ofereça suporte contínuo e atualizações regulares. Algumas ações configurações de segurança podem ajudar a reduzir um pouco o problema. De forma genérica, são elas:

    • Instalar o firmware mais recente disponível para o roteador.
    • Desativar o acesso remoto ao painel de administração.
    • Usar senhas fortes e exclusivas para o roteador e a rede Wi-Fi.
    • Desativar recursos como UPnP e WPS, que são alvos comuns de exploits.
    • Considerar usar um firewall ou software de monitoramento de rede.
    • Configurar redes separadas para dispositivos móveis e IoT, separando dos computadores para limitar o impacto de um eventual roteador comprometido.

    Observações:

    Conforme mencionado, estamos discutindo aqui as vulnerabilidades que estão sendo exploradas em roteadores D-Link D-Link DIR-600L, DIR-605L e DIR-619L nas últimas 72 horas, no momento de elaboração desse artigo. Existem diversos outros modelos de roteadores D-Link com problemas de vulnerabilidades. Porém, tais modelos continuam com o ciclo de vida ativo e recebem atualizações de segurança. Para uma busca completa de vulnerabilidades que estejam afetando os dispositivos D-Link, classificadas das mais recentes para as mais antigas, utilize essa [BUSCA] que irá abrir em outra janela.

    Conclusão

    Apesar da ausência de estatísticas precisas, pelas nossas obaservações, é plausível estimar que uma quantidade significativa de roteadores dos modelos D-Link DIR-600L, DIR-605L e DIR-619L permaneça em operação, particularmente em mercados emergentes, em função do seu baixo custo e das funcionalidades básicas que oferecem. No entanto, esses equipamentos encontram-se tecnicamente obsoletos e apresentam vulnerabilidades de segurança conhecidas e críticas.

    Diante desse cenário, recomenda-se fortemente sua substituição por dispositivos mais modernos, que contem com atualizações de firmware e suporte contínuo por parte do fabricante. A manutenção desses modelos em redes ativas representa um vetor considerável de risco à segurança da informação.


    Vol. 1 No. 20250509-262 (2025)

    Quais as técnicas mais utilizadas por grupos de ransomware?

    Matheus Augusto da Silva Santos | matheus@cylo.com.br | 09/05/2025

    Se proteção contra ataques de ransomware for um objetivo almejado, a análise das técnicas mais utilizadas para tal é um caminho para priorização de medidas de defesa. Em particular, no framework MITRE ATT&CK1, existem associações entre as técnicas nele documentadas e:

    1. Fontes de dados (Data Sources) configuráveis para monitoramento e CTI;
    2. Mitigações (Mitigations) para defesa direta; e
    3. Recursos (Assets) afetados (este, porém, exclusivamente para técnicas da matriz ICS.)

    Para a análise de dados neste post, utilizei os dados disponibilizados por Ransomware.live2. Em particular, seu endpoint de grupos de ransomware consta com mapeamentos de táticas, técnicas e procedimentos (TTPs) para um subconjunto dos grupos.

    Infelizmente a parcela de grupos com TTPs mapeadas constitui somente aproximadamente 7% de todos os grupos disponíveis pela API. Torço que com o tempo, mais grupos sejam analisados.

    Os 19 grupos com TTPs mapeadas analisados nesse post estão listados abaixo:

    8base
    BrainCipher
    akira
    alphv
    bianlian
    blackbasta
    blacksuit
    cactus
    clop
    crosslock
    cuba
    donex
    dragonforce
    hunters
    medusa
    ransomhub
    royal
    safepay
    threeam

    Análise da distribuição de táticas

    Abaixo, o número de ocorrências de todas as táticas associadas a atividades dos grupos:

    Curiosamente, não há mapeamentos para técnicas de TA0043 — Reconnaissance. Isso potencialmente incorre que os grupos analisados utilizam primariamente técnicas passivas3 para esse fim.

    Análise da distribuição de técnicas

    Abaixo, o número de ocorrências das técnicas mais frequentes (com associações a 5 ou mais grupos):

    Não surpreendentemente, a técnica mais frequentemente associada é T1486 — Data Encrypted for Impact. Os únicos dois grupos não associados a ela foram blackbasta e cuba.

    Dentre as técnicas listadas, uma que me chamou atenção é T1078 — Valid Accounts: por fazer parte de múltiplas tácticas (quatro no total), observa-se que grupos diferentes foram mapeados à mesma técnica, porém com objetivos distintos. Neste caso, especificamente, temos a seguinte partição:

    TA001
    Initial Access
    TA003
    Persistence
    TA004
    Privilege Escalation
    akira🎯
    alphv🎯🎯🎯
    blacksuit🎯
    clop🎯
    medusa🎯
    safepay🎯🎯🎯
    Mapeamento das táticas de grupos utilizando a técnica T1078 — Valid Accounts

    Interessantemente, nenhum grupo foi associado a esta técnica almejando a tática TA0005 — Defense Evasion.

    Uma partição de táticas similar ocorreu com T1543.003 — Create or Modify System Process: Windows Service, porém em menor grau por esta técnica fazer parte de somente duas táticas.

    A proporção entre técnicas base e sub-técnicas dentre as 15 mais frequentes também me intrigou. Técnicas base, por serem mais gerais, possuem maior chance de serem mapeadas a um comportamento observado. Naturalmente, portanto, elas representam a maioria das técnicas mais comuns.

    Notavelmente, dentre as sete sub-técnicas presentes nesta listagem, quatro se referem a ações específicas para Windows/PowerShell. Considerando a popularidade do Windows no mercado4, suponho que faça sentido técnicas tão específicas fazerem parte da distribuição das mais comuns.

    Conclusão

    É importante relevar que os dados aqui analisados não representam a totalidade das complexidades do mundo de cibersegurança. Primeiramente, um mapeamento completo e estático para o comportamento de grupos de ransomware é impraticável. Adicionalmente, o framework ATT&CK não afirma ser uma fonte completa para todos os potenciais comportamentos de adversários5. Em particular, enfatizo o seguinte trecho:

    “Don’t limit yourself to the matrix. Remember the ATT&CK matrix only documents observed real-world behaviors. Adversaries may have a series of other behaviors they use that have not been documented yet.”

    Apesar da quantidade de dados limitados, foi possível fazer algumas inferências interessantes com as distribuições observadas.

    A aplicabilidade dos dados observados para priorização de medidas de segurança, porém, necessita ainda da análise dos mapeamentos entre técnicas e outros elementos. Como citado no início, associações com mitigações seriam um ponto de estudo interessante.

    Referências

    1. MITRE. MITRE ATT&CK®. Disponível em: <https://attack.mitre.org>. ↩︎
    2. Ransomware.live 👀. Disponível em: <https://www.ransomware.live>. ↩︎
    3. OGIDI U. O. C. Passive Reconnaissance Techniques. Disponível em: <https://pentescope.com/passive-reconnaissance-techniques/>. ↩︎
    4. SHERIF, A. Windows operating system market share by version 2017-2019 | Statista. Disponível em: <https://www.statista.com/statistics/993868/worldwide-windows-operating-system-market-share/>. ↩︎
    5. General Information | MITRE ATT&CK®. Disponível em: <https://attack.mitre.org/resources/>. ↩︎

    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.

    Vol. 1 No. 20250429-410 (2025)

    Fortalecimento dos Aspectos de Segurança em Firewalls Palo Alto Networks

    Giuliano Cardozo Medalha | giuliano@wztech.com.br | 29/04/2025


    O fortalecimento de configurações relacionadas a segurança de acesso, dos firewalls Palo Alto Networks, requer uma abordagem multifacetada para aprimorar a postura de segurança, focando em configuração segura, controle de acesso e manutenção contínua.

    As principais etapas incluem alterar senhas padrão, implementar políticas de senhas robustas, estabelecer administração baseada em papéis e limitar o acesso por meio de listas de controle de acesso (ACLs). Além disso, é crucial monitorar regularmente os logs do sistema e de configuração, manter atualizações de software e conteúdo em dia e proteger a interface de gerenciamento.

    Abaixo seguem alguns tópicos considerados importantes, no sentido desse fortalecimento:

    1. Configuração Segura e Controle de Acesso
    • Alterar Senhas Padrão

    Nunca utilize a senha padrão de administrador. Crie senhas fortes e únicas para todas as contas administrativas, evitando senhas fáceis de adivinhar.

    • Habilitar Perfis e Grupos de Administradores

    Restrinja o acesso com base em papéis e responsabilidades. Configure perfis administrativos para limitar o que cada administrador pode modificar, garantindo o princípio do menor privilégio.

    • Aplicar Políticas de Senhas Fortes

    Exija senhas complexas, com combinações de letras, maiúsculas, minúsculas, números e caracteres especiais.

    Implemente trocas frequentes de senhas e considere métodos de autenticação externa, como LDAP ou SAML, para maior segurança.

    • Perfis de Gerenciamento de Interfaces

    Desative serviços desnecessários, como ping, SSH e acesso web, em interfaces que não os requerem ( principamente as interfaces que ficam expostas pra internet ).

    Configure controles de acesso baseados em IP. Restrinja o acesso às interfaces de gerenciamento apenas a endereços IP específicos e VLANs autorizados.

    Coloque a interface de gerenciamento em uma VLAN segura. Limite o acesso à interface de gerenciamento apenas para o pessoal ou time autorizado. Lembrar de remover perfis de autenticação, autorizações e permissões, quando um colaborador se desligar da empresa ou do ambiente.

    • Limitar Acesso via Listas de Controle de Acesso (ACLs)

    Configure regras de firewall para restringir o fluxo de tráfego com base na origem, destino e protocolo, reduzindo a superfície de ataque.

    1. Manutenção Contínua e Monitoramento
    • Manter Atualizações de Conteúdo e Software

    Atualize regularmente o software e os pacotes de conteúdo do firewall para corrigir vulnerabilidades conhecidas e melhorar a proteção contra ameaças emergentes.

    • Configurar Notificações para Logs de Sistema e Configuração

    Configure o firewall para enviar alertas sobre eventos críticos, como tentativas de login não autorizadas ou alterações de configuração.

    • Monitorar Logs de Sistema e Configuração

    Revise regularmente os logs para identificar atividades suspeitas ou tentativas de acesso não autorizado, permitindo uma resposta rápida a incidentes.

    • Utilizar a Ferramenta de Avaliação de Melhores Práticas (BPA) da Palo Alto Networks

    Essa ferramenta realiza verificações de segurança e fornece uma pontuação, ajudando a identificar áreas que precisam de melhorias na configuração do firewall.

    1. Medidas Adicionais de Segurança
    • Usar uma String de Comunidade SNMP Forte

    Caso o SNMP seja necessário, escolha uma string de comunidade única e difícil de adivinhar para evitar acessos não autorizados.

    • Habilitar SNMP Apenas em Interfaces Necessárias

    Ative o SNMP somente em interfaces internas onde ele é estritamente necessário, reduzindo a exposição.

    • Considerar Autenticação Externa

    Utilize métodos de autenticação robustos, como LDAP ou SAML, para reforçar a segurança das credenciais administrativas.

    • Proteger a Interface de Gerenciamento

    A Palo Alto Networks destaca a importância de proteger a interface de gerenciamento, que é um ponto de entrada potencial para atacantes.

    • Implementar um Mecanismo Abrangente de Logs e Alertas

    Configure logs detalhados e alertas para rastrear todos os eventos significativos, facilitando a identificação de ameaças potenciais.

    • Estabelecer Protocolos de Backup e Restauração

    Faça backups regulares da configuração do firewall e tenha um plano claro para restauração em caso de falhas ou incidentes.

    • Alinhar Políticas com Padrões de Conformidade

    Garanta que as configurações do firewall estejam alinhadas com padrões e regulamentações do setor, como GDPR, HIPAA ou PCI-DSS, conforme aplicável.

    • Submeter Firewalls a Testes Regulares

    Realize testes de penetração e auditorias de segurança periódicas para identificar e corrigir vulnerabilidades.

    • Considerar o Uso de um Centro de Operações de Segurança (SOC)

    Capacidades de SOC para monitoramento e resposta a eventos de segurança, o que pode ser uma opção para organizações com recursos limitados.

    Conclusão:

    Ao seguir estas diretrizes de fortalecimento, é possível melhorar significativamente a postura de segurança dos firewalls Palo Alto Networks, reduzindo o risco de acesso não autorizado e atividades maliciosas. A combinação de configuração segura, monitoramento contínuo e conformidade com melhores práticas é essencial para proteger redes corporativas contra ameaças cibernéticas em constante evolução.

    
    
    
    
    

    Vol. 1 No. 20250425-385 (2025)

    Utilização de ferramentas de acesso remoto (RMM)

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

    Ataques de phishing é uma das formas mais simples de conseguir um meio de transporte para dentro de um ambiente corporativo. O ataque utiliza de técnicas comportamentais e até sentimentais dos colaboradores, justificando um clique que pode dar uma boa dor de cabeça para a empresa.

    Esse tipo de tática executado com sucesso, é seguido por uma técnica de persistência e temos observado que agentes maliciosos estão utilizando ferramentas conhecidas para acesso remoto ao ambiente, dentre elas, Anydesk, TeamViewer, Atera e outros.

    Com isso, é possível passar por diversas camadas de segurança, visto que comumente são ferramentas utilizadas pelo próprio time de infraestrutura interno.

    Dicas para se proteger desse tipo de tática.

    1 – Utilizar software pago com customizações pelo time de infraestrutura, assim você consegue limitar somente de determinados lugares suas estações deverão aceitar conexões;

    2 – Bloquear conexões de qualquer outra ferramenta de acesso remoto no firewall, permitindo apenas a que utiliza, isso se ainda for necessário liberar acesso externo;

    3 – Seguindo nessa linha, caso sua plataforma permita um servidor interno ou um gateway interno dessa conexão, você limita as conexões apenas internas na rede;

    4 – Utilize seu MDM (Mobile Device Management) para permitir apenas execuções dos softwares permitidos;

    5 – Configure seu XDR para bloquear executáveis conhecidos diferente do utilizado internamente;

    6 – Treinamentos com os colaboradores, essa etapa para mim é essencial a que mais protege o ambiente corporativo.

    Referências:

    https://www.csoonline.com/article/3487743/attackers-increasingly-using-legitimate-remote-management-tools-to-hack-enterprises.html

    https://www.solissecurity.com/en-gb/insights/the-growing-threat-from-remote-access-tools-used-in-ransomware-attacks/

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

    Vol. 1 No. 20250423-381 (2025)

    LOLBIN Windows

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

    Nos últimos dias trabalhamos em cima de um incidente relacionado a um executável assinado dentro do sistema operacional Microsoft Windows interagindo com agentes maliciosos, sim é isso mesmo que leu, um aplicativo oficial da Microsoft sendo utilizado como parte de um ataque, essa é a teoria dos LOLBIN (Living Off the Land Binaries).

    O ataque trabalhado utilizava do LOLBIN PowerShell.exe para transferir os arquivos e persistência no host. Já passou em nossas mãos por exemplo o serviço BITS (Background Intelligent Transfer Service) ao qual é responsável por gerenciar os pacotes de rede que são solicitados pelo sistema operacional, nesse serviço também é passível de ocorrer a mesma situação.

    Fica uma recomendação, acompanhem esse projeto mantido pela comunidade chamado LOLBAS Project. Estão focados em manter uma lista de aplicativos dentro do Microsoft Windows que é comum ser utilizados em ataques, com detalhes sabemos comandos e parâmetros que utilizam para passar por times de segurança e ferramentas despreparadas.

    Referências:

    https://lolbas-project.github.io