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