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
Ferramentas/GitHubGitHub/dahnutz/zimbra-cve-2026-73570-ir
Ferramentas DefensivasGerenciamento de Indicadores de Comprometimento (IOC)Análise de VulnerabilidadesForensia DigitalInteligência de AmeaçasResposta a IncidentesAnálise de Logs
GitHubdahnutz/zimbra-cve-2026-73570-ir

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 →

zimbra-cve-2026-73570-ir

Ver Repositório
há 8h 38mAinda não revisado

Sobre

Toolkit de resposta a incidentes com deteção em primeiro lugar para administradores do Zimbra a investigar o CVE-2026-73570. Pesquisa registos à procura de indicadores de exploração, examina locais de persistência e recolhe pacotes de evidências com carimbo temporal sem alterar o estado do anfitrião.

Compartilhar

Kit de Resposta a Incidentes da Comunidade para Zimbra CVE-2026-73570

Ferramentas de resposta a incidentes focadas em detecção e preservação de evidências para administradores de Zimbra que investigam suspeitas de exploração da CVE-2026-73570.

[!CAUTION] Este é um projeto comunitário independente, não um oráculo de comprometimento do fornecedor. O verificador é somente leitura e relata evidências por severidade; ele não pode provar que um host está limpo. Se o comprometimento de root for confirmado ou razoavelmente suspeito, trate o host como não confiável: preserve evidências, contenha, rotacione segredos a partir de um sistema limpo e reconstrua em uma plataforma suportada.

O que este repositório faz

  • Pesquisa logs locais de Zimbra/correio pela invariante de exploração Service status change: localhost e sintaxe suspeita de shell/download.
  • Examina o estado SNMP/swatch do Zimbra, locais conhecidos de persistência JSP, JSPs recentes inesperados e possíveis cópias de Zimbra.jsp.
  • Relata evidências de GSocket/gs-dbus, processos falsos, IRC/PowerBots, cron, rc.local, chaves SSH, sudo, arquivos temporários e conexões de saída ativas.
  • Coleta um pacote de evidências privado e com registro de data/hora, sem conteúdo de caixa de correio ou limpeza automática.
  • Publica indicadores derivados de incidentes com classe de evidência, confiança e status explícitos.
  • Ele não explora, busca payloads, contata infraestrutura de IOC, remove artefatos, envia dados, inspeciona conteúdo de caixa de correio ou substitui análise forense. A ausência de achados pode significar logs ausentes/rotacionados, persistência inativa, permissões insuficientes, uma variante não reconhecida ou coleta após a limpeza pelo atacante.

    Início rápido

    Execute no host Zimbra a partir de uma sessão administrativa confiável. Prefira coletar evidências antes de investigações extensas, pois o trabalho em sistemas ativos pode alterar o estado volátil e os tempos de acesso.

    root@kitploit:~
    sudo ./scripts/check-zimbra-73570.sh
    sudo ./scripts/check-zimbra-73570.sh --since-days 30 --json /secure/case/check-report.json
    sudo ./scripts/collect-evidence.sh --output /secure/case
    

    Os códigos de saída do verificador são:

    CódigoSignificado
    0Nenhum achado médio/alto/crítico (não é prova de segurança)
    1Um ou mais achados médios
    2Um ou mais achados altos ou críticos
    64Uso inválido

    A saída do verificador usa as categorias INFO, MEDIUM, HIGH e CRITICAL. Ele deliberadamente não colapsa evidências diferenciadas em um único sinalizador COMPROMISED. Um relatório JSON é gravado somente quando --json é solicitado. As verificações de arquivos podem ser testadas contra um fixture isolado com --root; verificações de processos ativos e rede são então ignoradas.

    O coletor cria um diretório com modo 0700 e um arquivo compactado ao lado dele, registra metadados de coleta e grava manifestos SHA-256. Ele lê arquivos suspeitos apenas para gerar hashes e não os coloca em quarentena, trunca, altera permissões, exclui ou executa. O pacote resultante pode conter nomes de host sensíveis, nomes de usuário, trechos de logs, configuração, endereços IP e chaves públicas: mantenha-o criptografado, com controle de acesso e fora deste repositório.

    Modelo de evidências

    Os indicadores são separados em:

    • confirmado-no-host — observado nas evidências sanitizadas do incidente do host afetado; isso prova uma observação, não necessariamente execução bem-sucedida ou atribuição.
    • confirmado-a-partir-de-payload-recuperado — presente no conteúdo do payload recuperado durante o incidente; isso não prova que o payload foi executado ou que a infraestrutura permanece ativa.
    • somente-tentativa-de-exploração — observado em evidências de solicitação de exploração/fonte; isso não estabelece por si só a execução de comandos.

    Consulte IOCS.md, iocs.csv e iocs.json. Nenhuma amostra de malware ou evidência específica de vítima está incluída. Nenhuma URL de payload foi contatada durante o desenvolvimento; o status das URLs é histórico/não verificado, a menos que um terceiro confiável estabeleça o contrário de forma independente.

    Cadeia analítica derivada do incidente

    As evidências sanitizadas suportam esta cadeia de trabalho:

    root@kitploit:~
    Tentativa de injeção de comandos SMTP
      -> execução como zimbra
      -> persistência JSP
      -> inventário/reconhecimento do sistema
      -> implantação de GSocket
      -> gs-dbus / [kcached]
      -> bot IRC em Perl
      -> possível escalonamento de privilégios ou persistência de root
    

    Esta é uma cadeia derivada do incidente, não um comportamento universal da CVE. No conjunto de evidências sanitizadas, download/execução como a conta de serviço, um shell interativo, uma configuração Nginx controlada pelo atacante iniciada por root, processos root gs-dbus/[kcached] e persistência de root por hora são diretamente corroborados. Os mecanismos exatos de escalonamento de privilégios, a linha do tempo de implantação do JSP, cada ramo do payload, a identidade do operador e a atribuição permanecem lacunas dependentes de evidências. Consulte docs/triage.md.

    Orientação de resposta

    • Triagem: interprete achados e preserve a incerteza.
    • Persistência: locais, disfarce de processos e validação.
    • Contenção: isolamento seguro e prioridades de tratamento de segredos.
    • Recuperação: orientação de reconstrução primeiro para comprometimento de root.

    Não publique evidências ao vivo de vítimas ou amostras de malware. Após validação interna e autorização, pacotes de indicadores defensivos podem ser compartilhados com o Shadowserver. Envios ao URLhaus devem ser limitados a URLs verificadas de forma independente como URLs ativas de entrega de malware; URLs históricas ou não verificadas não devem ser enviadas como ativas.

    Validação

    Todos os testes usam fixtures estáticos e não realizam nenhuma atividade de rede:

    root@kitploit:~
    make validate
    

    Isso verifica sintaxe Bash, consistência de esquema/CSV/JSON de IOC, detecção de fixtures, saída legível por máquina e higiene do repositório. shellcheck é usado quando instalado.

    Suporte e contribuições

    Revise CONTRIBUTING.md antes de propor indicadores ou mudanças de detecção. Relate problemas de segurança de forma privada conforme descrito em SECURITY.md. Licenciado sob Apache-2.0; consulte LICENSE.

    Baixar ferramenta