Vol. 1 No. 20250620-619 (2025)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vol. 1 No. 20250502-389 (2025)

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

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

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

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

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

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

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

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

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

Cadeia de execução realizada pelo Malware

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

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

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

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