Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Event-ID-263-Arbitrary-File-Read-on-Checkpoint-Security-Gateway-CVE-2024-24919- | Kitploit
Ferramentas/GitHubGitHub/cyberbibs/event-id-263-arbitrary-file-read-on-checkpoint-security-gateway-cve-2024-24919-
Gerenciamento de Indicadores de Comprometimento (IOC)Análise de VulnerabilidadesAnálise ForenseInteligência de AmeaçasAprendizado e EducaçãoResposta a Incidentes
GitHubcyberbibs/event-id-263-arbitrary-file-read-on-checkpoint-security-gateway-cve-2024-24919-

Event-ID-263-Arbitrary-File-Read-on-Checkpoint-Security-Gateway-CVE-2024-24919-

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
Ver Repositório
há 1 anoAinda não revisado

Análise de Alerta SOC: Leitura Arbitrária de Arquivos no Checkpoint Security Gateway CVE-2024-24919

Introdução

O CVE-2024-24919 é uma vulnerabilidade crítica de dia zero nos Check Point Security Gateways que permite que atacantes remotos não autenticados leiam arquivos arbitrários de sistemas afetados. Descoberta em maio de 2024 e ativamente explorada no mundo real, a falha atinge dispositivos com Remote Access VPN ou Mobile Access Blade habilitados. Os atacantes podem aproveitar essa vulnerabilidade para acessar arquivos sensíveis, como hashes de senhas e chaves SSH, potencialmente levando ao comprometimento total do sistema. Devido à sua gravidade e status de exploração, a aplicação imediata de patches e medidas de mitigação é fortemente recomendada.

Investigação e Remediação

Para investigar e remediar o alerta, executei as seguintes etapas;

  • Verificar a fila de tickets do SOC e assumir a propriedade de um alerta
  • Criar um caso
  • Entender o ataque
  • Detecção
  • Análise
  • Contenção
  • Remediação
  • Reportar Artefatos e IOCs
  • Fechar o ticket

Essas etapas são explicadas em detalhes abaixo, com imagens.

Etapa 1: Verificando a Fila de Tickets do SOC

A fila de tickets do Security Operations Center (SOC) é um componente crítico no gerenciamento e na resposta a incidentes de segurança cibernética. Os motivos são: Rastreamento e Gerenciamento de Incidentes, Priorização e Triagem, Responsabilidade, Relatórios, Análise de Tendências e Conformidade e Prontidão para Auditoria.

Cada ticket na fila é normalmente atribuído a um analista ou equipe específica, garantindo clara responsabilidade e prestação de contas pela resolução do incidente. Isso promove uma abordagem estruturada e organizada para o gerenciamento de incidentes. Assumi a propriedade do Alerta com EventID: 263

Página Principal do SOC

Assumindo a Responsabilidade

Etapa 2: Criando um Caso

Ao assumir a propriedade do alerta, ele é enviado automaticamente para o canal de investigação, onde posso iniciar um caso para analisar e responder melhor ao incidente de segurança. Criei um caso para o alerta e pude visualizar os detalhes do incidente.

Assumindo a Responsabilidade

Etapa 3: Detecção

Com base nas informações fornecidas pelo alerta, parece haver um ataque web suspeito detectado em um servidor chamado “CP-Spark-Gateway-01” com endereço IP 172.16.20.146. O alerta é acionado pela regra SOC287 para Leitura Arbitrária de Arquivos no Checkpoint Security Gateway [CVE-2024–24919] e a ação do dispositivo foi permitida.

Assumindo a Responsabilidade

Para entender melhor esse alerta, realizei algumas atividades de Inteligência de Fontes Abertas (OSINT) a respeito do CVE-2024–24919 reportado e de informações importantes relacionadas ao CVE.

Assumindo a Responsabilidade

Em seguida, executei inteligência de ameaças usando a plataforma de inteligência de ameaças fornecida pelo LetsDefend, que oferece um banco de dados abrangente dedicado a catalogar informações utilizadas de forma maliciosa, como endereços IP, domínios e outros indicadores de comprometimento, usando o endereço IP de origem 203.160.68.12.

Assumindo a Responsabilidade

Além disso, usei o VirusTotal para inteligência de ameaças sobre o mesmo endereço IP e observei que o malware foi sinalizado por atividades maliciosas por 4 fornecedores de segurança e a geolocalização do IP é Hong Kong.

Assumindo a Responsabilidade

Isso confirma que o tráfego proveniente do IP 203.160.68.12 é malicioso. Portanto, preciso realizar uma investigação mais aprofundada analisando os logs para ver quantos hosts na minha rede tiveram qualquer comunicação com esse IP malicioso.

Etapa 4: Análise

Comecei minha análise investigando os logs de acesso, com foco em endereços IP, user-agents, caminhos, códigos de status HTTP e carimbos de data/hora para me ajudar a identificar qualquer atividade suspeita ou maliciosa.

Antes de examinar o tráfego HTTP, investiguei os payloads usados na exploração da vulnerabilidade relevante. Encontrei este POC (Prova de Conceito) disponível publicamente, usado pelo [CVE-2024–24919], neste repositório do github https://github.com/seed1337/CVE-2024-24919-POC/blob/main/exploit.py

Assumindo a Responsabilidade

Em seguida, acessei a página de gerenciamento de logs e filtrei por log do endereço IP de origem malicioso 203.160.68.12 para ver quantos hosts estiveram em contato com ele. Ao pesquisar na rede, descobri que apenas o host chamado “CP-Spark-Gateway-01” com endereço IP 172.16.20.146 esteve em contato com o IP malicioso.

Assumindo a Responsabilidade

As informações de log abaixo mostram que o endereço IP malicioso 172.16.20.146 usou o método POST para enviar o payload malicioso aCSHELL/../../../../../../../../../../etc/shadow — que tenta ler o arquivo sensível /etc/shadow por meio de traversia de diretório no host “CP-Spark-Gateway-01” com endereço IP 172.16.20.146 em 06/junho/2024.

Assumindo a Responsabilidade

Assumindo a Responsabilidade

O arquivo /etc/shadow é um arquivo crítico em sistemas operacionais baseados em Unix/Linux que armazena senhas com hash e detalhes de expiração de contas de usuário. Portanto, posso concluir que o atacante está tentando roubar credenciais de usuários e que a solicitação foi concedida com o código de status 200, conforme observado no log acima.

Isso comprova ainda mais que o ataque é malicioso.

Assumindo a Responsabilidade

Etapa 5: Contenção

A contenção desempenha um papel fundamental na segurança cibernética, limitando o impacto de incidentes de segurança, protegendo dados e operações, facilitando uma resposta eficaz a incidentes, preservando evidências para análise forense e garantindo conformidade com requisitos legais e regulamentares.

Como detectei que o dispositivo está comprometido, procedi ao isolamento do dispositivo "CP-Spark-Gateway-01” com endereço IP 172.16.20.146 para evitar danos adicionais.

Assumindo a Responsabilidade

Assumindo a Responsabilidade

Etapa 6: Remediação

A remediação é um componente fundamental de uma estratégia robusta de segurança cibernética. Ela envolve corrigir vulnerabilidades e resolver problemas de segurança para evitar exploração, proteger dados, manter as operações e cumprir regulamentações, contribuindo, em última análise, para uma organização mais segura e resiliente. Para remediar e evitar futuras recorrências, as seguintes etapas devem ser tomadas;

  • Aplicar patches ou atualizações de segurança para resolver a vulnerabilidade CVE-2024–24919 em nosso servidor “CP-Spark-Gateway-01” para eliminar o vetor de ataque.
  • Configurar/escrever regras de firewall para negar/bloquear o tráfego do endereço IP malicioso 203.160.68.12
  • Se um Security Gateway / Cluster estiver configurado para usar uma Unidade de Conta LDAP, recomendo alterar a senha da conta LDAP.

Etapa 7: Relatar Artefatos e IOCs

Após concluir a análise, documentei minhas descobertas na seção “Analyst Note”, relatei Artefatos e IOCs.

Assumindo a Responsabilidade

Etapa : Fechando o Alerta

Após concluir minha investigação, concluí que o alerta é um falso positivo verdadeiro. Redigi uma nota de fechamento explicando a causa do alerta, as etapas que executei para analisar o alerta, o resultado das análises, as etapas tomadas para remediar o alerta e fechei o alerta com sucesso.

Assumindo a Responsabilidade

Baixar ferramenta