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
badBANANA-threat-observatory — Observatório de inteligência de ameaças que agrega feeds da CISA KEV, ThreatFox, URLhaus e MalwareBazaar, com busca, rastreamento de alterações e exportação em STIX/CSV/JSONL. | Kitploit
Ferramentas/GitLabGitLab/gnomeman/badbanana-threat-observatory
Ferramentas DefensivasGerenciamento de Indicadores de Comprometimento (IOC)OSINT (Inteligência de Fontes Abertas)Feeds e Agregadores de AmeaçasAnálise de VulnerabilidadesColeta de InformaçõesInteligência de Ameaças
GitLab

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
gnomeman/badbanana-threat-observatory

badBANANA-threat-observatory

Observatório de inteligência de ameaças que agrega feeds da CISA KEV, ThreatFox, URLhaus e MalwareBazaar, com busca, rastreamento de alterações e exportação em STIX/CSV/JSONL.

Ver RepositórioSite
há 7h 34mAinda não revisado

badBANANA // OBSERVATÓRIO DE AMEAÇAS

Olho do Observatório badBANANA

Um sistema de observação de ameaças com foco em evidências que mantém o estado atual da fonte, os eventos de mudança material e a telemetria operacional de coleta semanticamente separados. Dados ausentes, desatualizados, desabilitados ou indisponíveis permanecem visivelmente ausentes. A interface nunca substitui registros de demonstração nem atribuição inferida.

Esta versão reforça as datas de evidência e o estado de confirmação local do dispositivo, torna todas as falhas importantes de leitura visivelmente distintas dos estados bem-sucedidos de zero resultados, estabiliza as solicitações de correlação e fortalece a gaveta de evidências, os filtros de investigação limitados, a interpretação de fontes, os controles móveis e a contabilização de exportação. Cada marca de replay animado ainda corresponde a um evento NEW, UPDATED ou REMOVED retido; não é tráfego de rede decorativo.

Visualizações de produção

Vista de relacionamentos Pulse do Observatório de Ameaças badBANANA

Pulse — relacionamentos entre fontes, saúde das fontes e análise do estado atual.

Replay de Transições do Observatório de Ameaças badBANANA

Replay — reconstrução limitada à página das transições NEW, UPDATED e REMOVED retidas.

Outras superfícies ao vivo incluem geografia aproximada de infraestrutura por IP público e visualizações de evidências URLhaus / MalwareBazaar de primeira parte. Essas superfícies intencionalmente não são representadas por capturas de tela de espaço reservado ou duplicadas neste README.

As capturas de produção são capturas de tela que preservam a fonte, obtidas do Observatório v1.2.0 ao vivo. Elas são recortadas e redimensionadas/compactadas para apresentação; as evidências exibidas, carimbos de data/hora, contagens, valores de IOC e estados da interface não são regenerados nem substituídos.

Implantação ao vivo

  • Produção: https://badbanana-threat-observatory.badbanana6969.workers.dev
  • Código-fonte atual: https://github.com/GnomeMan4201/badBANANA-threat-observatory/tree/main
  • Código-fonte congelado v1.2.0: https://github.com/GnomeMan4201/badBANANA-threat-observatory/tree/release/v1.2.0

O Worker de produção é respaldado pelo Cloudflare D1. As credenciais dos feeds permanecem como segredos exclusivos do servidor do Cloudflare Worker e nunca são exigidas no navegador.

Status da versão

  • Versão: 1.2.0
  • Runtime: Node.js 22.13.0 ou mais recente
  • Implantação: Next.js em Cloudflare Workers por meio do vinext e do plugin Cloudflare Vite
  • Persistência: Cloudflare D1 com degradação de memória de isolado explicitamente rotulada
  • Auditoria de dependências de produção: aplicada na CI com severidade alta

Modo de ingestão

Esta implantação opera no modo demand-driven. O repositório agora tem como alvo direto os Cloudflare Workers padrão; os acionadores agendados não estão habilitados intencionalmente no v1.2.0, portanto o aplicativo não afirma realizar coleta contínua. Um agendador futuro pode chamar a mesma operação runIngestionCycle() após verificação separada de correção e operacional.

O navegador faz uma solicitação explícita e limitada de manutenção no primeiro uso e a cada cinco minutos enquanto estiver aberto:

root@kitploit:~
POST /api/ingest
        ↓
runIngestionCycle()
        ↓
configuration → TTL → backoff → D1 lease → fetch → normalize → validate
        ↓
snapshot cache + current observations + material events + cycle statistics

Leituras comuns são separadas e locais:

root@kitploit:~
GET /api/observations → D1 current state, scoped before pagination
GET /api/search       → D1 current state, scoped before pagination
GET /api/kev          → D1 current CISA catalog
GET /api/events       → D1 material change ledger
GET /api/geo          → local observations + bounded cached IP enrichment

Nenhuma dessas rotas GET chama um adaptador de fonte. Se este projeto ganhar futuramente um agendador genuinamente suportado, ele poderá chamar a mesma operação runIngestionCycle() sem criar uma segunda implementação de atualização.

Cobertura de fontes

A cobertura é exibida por fonte. APIs limitadas nunca são apresentadas como catálogos completos.

Modelo de armazenamento

O binding DB é proprietário de conjuntos de dados distintos:

  • threat_source_cache e threat_source_cache_chunks: o snapshot validado mais recente por fonte, armazenado em blocos com chave de geração.
  • observations: estado atual normalizado mais recente por identidade de fonte estável. Preserva a primeira ingestão, a última aparição na fonte, a última mudança material, o hash atual, a contagem de revisões e o resultado da ingestão mais recente.
  • observation_events: eventos de evidência significativos do tipo NEW e UPDATED, e de REMOVED defensável. Payloads normalizados anteriores e atuais, hashes e diffs determinísticos de campos tornam os estados anteriores reconstruíveis.
  • source_fetch_log: telemetria limitada de tentativas de coleta, sem corpos de resposta ou credenciais.
  • source_ingest_cycles: contagens limitadas por atualização de registros coletados, válidos, rejeitados, novos, atualizados, inalterados e removidos.
  • source_refresh_lease: leases curtos respaldados por D1 por fonte, impedindo que isolados simultâneos dupliquem atualizações upstream.
  • ingestion_runtime: a saúde mais recente do ciclo geral de ingestão.

As definições de esquema do runtime estão em db/schema.ts. A inicialização adiciona as novas colunas de estado atual a uma tabela de observações existente antes de criar índices dependentes.

Semântica de estado e retenção

Estas perguntas são intencionalmente diferentes:

  1. O que a fonte diz agora? observations e o snapshot validado da fonte respondem a isso.
  2. O que o badBANANA observou durante esta janela de tempo da fonte? /api/observations?window=... filtra as observações atuais por observedAt upstream.
  3. O que mudou entre observações? observation_events e /api/revisions respondem a isso.

O estado atual não é descrito incorretamente como uma tabela de histórico de sete dias. O livro-razão de eventos materiais é retido por sete dias. A telemetria de coleta e ciclos é retida por dois dias e limitada a 200 linhas por fonte. Observações atuais não catalogadas que não reapareceram por sete dias são removidas. A CISA permanece atual porque toda resposta bem-sucedida é um catálogo completo; linhas removidas desse catálogo permanecem disponíveis por 30 dias antes da remoção. Apenas a ausência na CISA pode atualmente gerar um evento REMOVED, pois seu adaptador recupera um catálogo atual completo. A ausência em resultados limitados do ThreatFox, URLhaus ou MalwareBazaar não é tratada como exclusão.

Uma aparição inalterada avança os campos atuais lastObservedInSnapshotAt/lastIngestedAt, mas não cria um evento nem incrementa revisionCount. lastChangedAt sobrevive a aparições inalteradas posteriores.

Espaço de trabalho do analista CISA

A visualização Exploited separa:

  • Catálogo KEV Atual: estado atual completo e validado, independente da janela de tempo do painel.
  • KEV Recente: registros cujo dateAdded da CISA, com granularidade diária, cai dentro de um intervalo explícito de TODAY, 7D ou 30D. Janelas do Observatório inferiores a um dia nunca são apresentadas como precisão da CISA.

O catálogo atual oferece suporte a pesquisa no servidor, fornecedor, produto, adicionados recentemente, associação a ransomware, filtros de data de adição e paginação por cursor opaco. Exibe CVE, fornecedor, produto, nome da vulnerabilidade, data de adição, data de vencimento, associação a ransomware e ação necessária. Ele não inventa pontuações CVSS.

Livro-razão de mudanças e revisões

Os hashes de conteúdo cobrem campos de evidência normalizados, não a contabilidade do Observatório. Um hash alterado produz um evento UPDATED com o payload normalizado anterior, o novo payload normalizado, hashes anterior/novo e um diff determinístico sobre:

  • título
  • família de malware
  • tipo de ameaça
  • confiança
  • primeira/última aparição na fonte
  • tags
  • referência
  • chaves de metadados normalizados

A gaveta de proveniência consulta /api/revisions?id=... e expõe o hash atual, a última mudança material, a contagem de revisões, os eventos retidos e os diffs em nível de campo. Carimbos de data/hora voláteis de ingestão não aparecem nos diffs de conteúdo.

A gaveta também expõe um rastro de evidências versionado para cada registro aceito: campos normalizados aceitos, campos opcionais que permaneceram ausentes, transformações apenas de exibição, a base de classificação e a base de identidade estável. Este rastro descreve apenas evidências retidas. Valores upstream rejeitados não são retidos e nunca recebem identidades sintéticas do Observatório. As rejeições são representadas separadamente como contagens agregadas por ciclo, com códigos limitados de campo e motivo; ciclos antigos coletados antes desse esquema são rotulados como sem detalhamento, em vez de reconstruídos.

Eventos Recentes mostra apenas mudanças materiais. Não emite centenas de linhas SEEN inalteradas após uma atualização completa da CISA. Essas aparições são resumidas nas estatísticas do ciclo da fonte.

Briefing local do dispositivo

A visualização padrão Briefing compara o livro-razão de eventos materiais retido com um cursor de confirmação versionado armazenado apenas no navegador atual. O primeiro uso e o armazenamento limpo são rotulados como uma linha de base inicial, em vez de nova atividade. Se um cursor salvo for anterior ao livro-razão retido, a interface declara que um delta completo não pode ser comprovado.

A confirmação nunca altera nem exclui eventos do servidor. O cursor pode ser exportado e importado como JSON para transferência deliberada entre dispositivos; ele não é apresentado como um estado sincronizado por conta, e o identificador de dispositivo gerado nunca é enviado ao servidor.

Os totais do Briefing descrevem a página do livro-razão atualmente retornada e são rotulados como exibidos/limitados à página. Eles não são apresentados como totais do livro-razão completo retido.

Carimbos de data/hora de confirmação importados são estritamente validados e canonizados para UTC ISO-8601 antes do armazenamento ou comparação. O armazenamento do navegador é tratado como opcional: armazenamento local bloqueado ou com falha produz um erro inline compacto e nunca derruba o Briefing.

Exportações com política aplicada

O workbench Export formata a página visível validada já carregada como CSV, JSONL, STIX 2.1, texto desarmado (defanged) ou um manifesto de evidências contendo a política aplicada e os hashes de registros disponíveis. A pesquisa local ativa e o escopo de fontes são transferidos para o Export. Uma lista de permissões de fontes vazia exporta zero registros. O STIX representa CVEs da CISA como objetos Vulnerability e hashes de arquivo validados — incluindo valores SHA-256 do MalwareBazaar — como objetos Indicator. As contagens de selecionados, emitidos e não suportados são distintas; registros não suportados são divulgados nos metadados do bundle, em vez de descartados silenciosamente. O Export não realiza coleta upstream. Confiança ausente permanece ausente, divergências entre fontes permanecem como registros separados, e eventos removidos do livro-razão nunca entram silenciosamente nas exportações de estado atual. Esses artefatos são transportes de evidência, não recomendações de bloqueio para firewall.

Backoff e concorrência

Fontes expiradas usam atrasos limitados de nova tentativa de 1, 2, 5, 15 e 30 minutos. Um Retry-After válido maior é respeitado por até uma hora. Durante o backoff, um snapshot anterior válido é servido como obsoleto; uma fonte vazia com falha permanece offline.

Antes de buscar, uma fonte elegível adquire um lease condicional curto no D1. Outro isolado não pode substituir um detentor não expirado, portanto apenas uma atualização prossegue. Se o D1 estiver indisponível, o sistema relata explicitamente o modo degradado somente com snapshot e um lease de memória de isolado; esse fallback não é descrito como distribuído.

Paginação

Observações atuais, espaços de trabalho específicos de fonte, pesquisa local, o catálogo da CISA, eventos materiais e revisões de registros usam consultas limitadas por cursor no servidor. Restrições de fonte e tipo são aplicadas antes da ordenação e paginação. Os cursores codificam a tupla estável de ordenação, são validados quanto a comprimento/caracteres/esquema e falham de forma fechada (fail closed) com HTTP 400 quando malformados. O navegador nunca recebe o conjunto completo de dados de sete dias apenas para paginar localmente.

Segurança de referências e IOCs

  • URLs de IOC são desarmadas (defanged) por padrão e nunca renderizadas como âncoras.
  • Referências devem ser interpretadas como HTTP ou HTTPS.
  • Páginas de fonte de primeira parte conhecidas da CISA e do abuse.ch podem ser abertas normalmente.
  • Referências arbitrárias de HTTP(S) de terceiros são rotuladas como externas, exibem seu nome de host e oferecem comportamento somente cópia.
  • Octetos IPv4, estrutura IPv6, portas, domínios, URLs e hashes são estritamente validados.
  • O MalwareBazaar permanece somente com metadados; nenhuma amostra é baixada ou servida.
  • Todas as URLs upstream são fixas no servidor; nenhuma API faz proxy de destinos fornecidos pelo usuário.

Limitação de taxa

O limitador da API é um contador em memória de janela fixa com escopo de isolado do Worker. É relatado com precisão como proteção local de isolado de melhor esforço, não um limite de taxa globalmente autoritativo do Cloudflare. Leituras comuns são limitadas a 120 solicitações por minuto por IP de cliente relatado; a ingestão tem um bucket separado de seis solicitações por minuto, e a geografia tem um bucket separado de doze solicitações por minuto. Escritas no D1 não são adicionadas a cada leitura meramente para superestimar esse controle.

API

  • POST /api/ingest — ciclo explícito de manutenção orientado por demanda; respeita TTL, backoff e leases D1.
  • GET /api/observations?window=24h&scope=urlhaus&limit=100&cursor=... — janela local paginada do estado atual; escopos validados são all, urlhaus, malwarebazaar e infrastructure.
  • GET /api/search?q=indicator&window=24h&scope=urlhaus&limit=100&cursor=... — pesquisa local paginada com escopo; zero chamadas upstream.
  • GET /api/kev?limit=50&q=...&vendor=...&product=...&ransomware=known&addedSince=YYYY-MM-DD&cursor=... — catálogo CISA atual completo.
  • GET /api/events?limit=50&cursor=... — livro-razão de eventos materiais.
  • GET /api/revisions?id=...&limit=50&cursor=... — registro atual mais revisões retidas.
  • GET /api/correlations?id=... — pares de mesmo indicador exato no estado atual em nível de conjunto de dados.

Ambiente e implantação

O desenvolvimento local do Cloudflare lê credenciais exclusivas do servidor de .dev.vars. Copie .dev.vars.example para .dev.vars e preencha apenas os feeds que você está autorizado a usar:

root@kitploit:~
THREATFOX_AUTH_KEY=
URLHAUS_AUTH_KEY=
MALWAREBAZAAR_AUTH_KEY=

As credenciais de produção devem ser armazenadas como segredos do Cloudflare Worker, nunca no código-fonte versionado nem em variáveis do GitHub expostas ao cliente. O aplicativo as acessa somente por meio da superfície de bindings do runtime Workers. Elas nunca devem aparecer em NEXT_PUBLIC_*, componentes de cliente, HTML, logs, fixtures ou arquivos versionados.

O repositório tem como alvo direto os Cloudflare Workers padrão. wrangler.jsonc é a fonte de verdade da configuração do Worker e declara um binding D1 de rascunho chamado DB. O Wrangler 4 provisiona automaticamente esse recurso D1 na primeira implantação autenticada e mantém o binding vinculado nas implantações posteriores. Nenhum identificador D1 específico de conta é versionado.

Comandos de desenvolvimento e produção:

root@kitploit:~
npm ci
npm run dev
npm run build
npm run preview
# authenticated Cloudflare session / CI only
npm run deploy

A verificação do GitHub Actions é executada em cada pull request e push para main. A implantação de produção é deliberadamente manual por meio do workflow deploy production e exige segredos de repositório chamados CLOUDFLARE_API_TOKEN e CLOUDFLARE_ACCOUNT_ID. Isso impede que um branch não revisado ou uma configuração de credenciais incompleta publique automaticamente.

Verificação

root@kitploit:~
npm ci
npm audit --omit=dev --audit-level=high
npm audit --audit-level=high
npm test
npm run lint

npm test é o ponto de entrada de teste suportado: ele executa um build completo de produção antes da suíte determinística, para que o isolamento de segredos de cliente em nível de artefato possa inspecionar dist/client. Executar node --test diretamente em um checkout limpo omite intencionalmente esse artefato de build obrigatório. Os testes cobrem análise estrita de datas de calendário e de carimbos de data/hora de confirmação, armazenamento opcional de dispositivo, dependências estáveis de correlação, evidências normalizadas, hashing canônico de tags, criação de eventos materiais, reingestão inalterada, preservação de payload anterior, durabilidade da última mudança, diffs de campos, retenção de eventos e lacunas no livro-razão, rastros de evidências, política de exportação de fonte vazia, integridade de representação/contagem STIX, elegibilidade de TTL/backoff, leases de atualização, fiação de escopo-antes-de-paginação no servidor, consultas dedicadas GEO/KEV-Recente, validação de cursor, isolamento do caminho de leitura, cobertura de fontes, política de referência externa, precisão de limite de taxa, isolamento de falha de fonte e isolamento de segredos de cliente.

Enriquecimento geográfico

O modo GEO plota apenas observações validadas de IPv4/IPv6 públicos. Uma consulta D1 dedicada seleciona registros de IP elegíveis em toda a janela solicitada do estado atual, em vez de reutilizar a página genérica de observações. A resposta relata os totais de registros candidatos e se o limite de segurança de 2.000 registros foi atingido. Os chamadores não podem fornecer destinos upstream arbitrários nem listas de IP. GeoJS é o provedor primário fixo e FreeIPAPI é o fallback fixo; URLs upstream arbitrárias são impossíveis. O aplicativo limita o trabalho externo por meio de um teto de 12 endereços por solicitação, cache de sucesso D1 de 30 dias, cache de nova tentativa de cinco minutos e um limitador de rota dedicado. Cada ponto plotado mantém sua proveniência real de provedor e pode abrir o registro local subjacente.

Licença

Lançado sob a Licença MIT. Consulte LICENSE.

Selecionar o modo GEO faz com que o servidor envie cada candidato validado de IP público, juntamente com metadados comuns de solicitação HTTPS, ao GeoJS e depois ao FreeIPAPI quando o fallback for necessário. Esses provedores podem, portanto, observar quais endereços públicos são consultados. Endereços privados, reservados, de documentação e fornecidos pelo cliente nunca são enviados; o modo de relacionamentos não realiza solicitações de geolocalização.

O workspace Replay reconstrói a página atual das transições do livro-razão material na ordem de tempo de detecção do Observatório. O movimento NEW, UPDATED e REMOVED é conduzido exclusivamente por eventos armazenados. É explicitamente limitado à página e não afirma reconstruir um snapshot histórico completo nem o volume de tráfego de rede.

O pacote world-atlas, derivado do Natural Earth, fornece o mapa base local. O mapa agrupa IPs colocalizados, suporta detalhes ao passar o mouse e clique para a proveniência, e relata contagens de geolocalizados, excluídos, indisponíveis e pendentes. Faixas privadas, reservadas, de documentação, multicast e demais faixas não públicas são excluídas antes de qualquer chamada ao provedor.

A geolocalização de IP é explicitamente apresentada como localização aproximada de infraestrutura. Não é uma localização de ator, origem de evento, nacionalidade, conclusão de propriedade nem alegação de atribuição. Enriquecimento com falha permanece ausente; o aplicativo nunca gera coordenadas substitutas.

A visualização padrão permanece um campo interativo orientado por forças de observações individuais, vinculadas à sua fonte e à família de malware fornecida explicitamente. A tela suporta arrastar nós, pan do campo, zoom, tráfego animado de links e inspeção direta de proveniência. GEO é uma superfície de evidências separada, com sua própria proveniência e semântica de falha.

Baixar ferramenta
FonteCredencialTTLCobertura real
CISA KEVNenhuma30 minutosCatálogo validado atual completo
ThreatFoxTHREATFOX_AUTH_KEY15 minutosJanela de IOC de 24 horas solicitada
URLhausURLHAUS_AUTH_KEY15 minutosÚltimos 500 registros retornados pelo endpoint recent
MalwareBazaarMALWAREBAZAAR_AUTH_KEY15 minutosÚltimos 100 registros de metadados retornados pelo endpoint
  • geo_ip_cache: resultados validados de geolocalização aproximada de IP e entradas limitadas de cache negativo. Resultados bem-sucedidos expiram após 30 dias; consultas com falha são repetidas após cinco minutos. Linhas D1 expiradas são removidas oportunisticamente durante solicitações GEO, e o fallback de isolado é limitado a 2.000 entradas.
  • GET /api/geo?window=24h — deriva candidatos apenas de observações locais validadas de IP público, recupera no máximo 12 resultados de provedor não armazenados em cache por solicitação e retorna pontos WGS84 aproximados em cache com proveniência.
  • GET /api/status — semântica de fonte, estado atual, frescor, modo de ingestão, ciclo, lease e limite de taxa.