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
subcrawl — Framework modular para descobrir e analisar diretórios abertos na web. Varre URLs, extrai conteúdo, aplica varredura YARA/ClamAV e gera resultados para MISP, SQLite ou console para inteligência de ameaças. | Kitploit
Ferramentas/GitHubGitHub/hpthreatresearch/subcrawl
OSINT (Inteligência de Fontes Abertas)Análise de VulnerabilidadesColeta de InformaçõesSegurança WebInteligência de AmeaçasRastreador
GitHubhpthreatresearch/subcrawl

subcrawl

Framework modular para descobrir e analisar diretórios abertos na web. Varre URLs, extrai conteúdo, aplica varredura YARA/ClamAV e gera resultados para MISP, SQLite ou console para inteligência de ameaças.

Ver Repositório
150368há 2 anosRevisado pelo Kitploit

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

SubCrawl

SubCrawl é um framework desenvolvido por Patrick Schläpfer, Josh Stroschein e Alex Holland da equipe de Pesquisa de Ameaças da HP Inc. O SubCrawl foi projetado para encontrar, escanear e analisar diretórios abertos. O framework é modular, consistindo em quatro componentes: módulos de entrada, módulos de processamento, módulos de saída e o mecanismo principal de crawling. As URLs são os valores de entrada primários, que o framework analisa e adiciona a um sistema de filas antes de rastreá-las. A análise sintática (parsing) das URLs é um primeiro passo importante, pois pega uma URL submetida e gera URLs adicionais a serem rastreadas, removendo subdiretórios, um de cada vez, até que não reste nenhum. Este processo garante uma tentativa de varredura mais completa de um servidor web e pode levar à descoberta de conteúdo adicional. Notavelmente, o SubCrawl não usa um método de força bruta para descobrir URLs. Todo o conteúdo varrido vem das URLs de entrada, do processo de análise da URL e da descoberta durante o crawling. Quando um diretório aberto é descoberto, o mecanismo de crawling extrai links do diretório para avaliação. O mecanismo de crawling determina se o link é outro diretório ou se é um arquivo. Diretórios são adicionados à fila de crawling, enquanto arquivos passam por análise adicional pelos módulos de processamento. Os resultados são gerados e armazenados para cada URL varrida, como os hashes SHA256 e fuzzy do conteúdo, se um diretório aberto foi encontrado, ou correspondências com regras YARA. Finalmente, os dados de resultado são processados de acordo com um ou mais módulos de saída, dos quais existem atualmente três. O primeiro fornece integração com MISP, o segundo simplesmente imprime os dados no console e o terceiro armazena os dados em um banco de dados SQLite. Como o framework é modular, não é apenas fácil configurar quais módulos de entrada, processamento e saída são desejados, mas também é direto desenvolver novos módulos.

Arquitetura do Framework Figura 1 - Arquitetura do SubCrawl

O SubCrawl suporta dois modos diferentes de operação. Primeiro, o SubCrawl pode ser iniciado no modo execução única (run-once). Neste modo, o usuário fornece as URLs a serem varridas em um arquivo onde cada valor de entrada é separado por uma quebra de linha. O segundo modo de operação é o modo serviço. Neste modo, o SubCrawl é executado em segundo plano e depende dos módulos de entrada para fornecer as URLs a serem varridas. A Figura 1 mostra uma visão geral da arquitetura do SubCrawl. Os componentes que são usados em ambos os modos de operação são azuis, os componentes do modo execução única são amarelos e os componentes do modo serviço são verdes.

Requisitos

Com base no modo de execução escolhido, outras pré-condições devem ser atendidas.

Requisitos do Modo Execução Única

O SubCrawl é escrito em Python3. Além disso, existem vários pacotes que são necessários antes de executar o SubCrawl. O seguinte comando pode ser usado para instalar todos os pacotes necessários antes de executar o SubCrawl. A partir do diretório crawler, execute o seguinte comando:

root@kitploit:~
$ sudo apt install build-essential
$ pip3 install -r requirements.txt

Requisitos do Modo Serviço

Se o SubCrawl for iniciado no modo serviço, isso pode ser feito usando Docker. Por esse motivo, a instalação do Docker e do Docker Compose é necessária. Boas instruções de instalação podem ser encontradas diretamente no site do Docker.com.

  • Instalando o Docker Engine
  • Instalando o Docker Compose

Obtendo Ajuda

O SubCrawl possui ajuda embutida através do argumento -h/--help ou simplesmente executando o script sem nenhum argumento.

root@kitploit:~
  ********         **        ******                               **
 **//////         /**       **////**                             /**
/**        **   **/**      **    //  ******  ******   ***     ** /**
/*********/**  /**/****** /**       //**//* //////** //**  * /** /**
////////**/**  /**/**///**/**        /** /   *******  /** ***/** /**
       /**/**  /**/**  /**//**    ** /**    **////**  /****/**** /**
 ******** //******/******  //****** /***   //******** ***/ ///** ***
////////   ////// /////     //////  ///     //////// ///    /// /// 
~~ Harvesting the Open Web ~~

usage: subcrawl.py [-h] [-f FILE_PATH] [-k] [-p PROCESSING_MODULES] [-s STORAGE_MODULES]

optional arguments:
  -h, --help            show this help message and exit
  -f FILE_PATH, --file FILE_PATH
                        Path of input URL file
  -k, --kafka           Use Kafka Queue as input
  -p PROCESSING_MODULES, --processing PROCESSING_MODULES
                        Processing modules to be executed comma separated.
  -s STORAGE_MODULES, --storage STORAGE_MODULES
                        Storage modules to be executed comma separated.

  Available processing modules: 
  - ClamAVProcessing
  - JARMProcessing
  - PayloadProcessing
  - TLSHProcessing
  - YARAProcessing

  Available storage modules: 
  - ConsoleStorage
  - MISPStorage
  - SqliteStorage

Modo Execução Única

Este modo é adequado se você deseja escanear rapidamente uma quantidade gerenciável de domínios. Para isso, as URLs a serem varridas devem ser salvas em um arquivo, que então serve como entrada para o crawler. Segue um exemplo de execução no modo execução única; note que o argumento -f é usado com um caminho para um arquivo.

root@kitploit:~
python3 subcrawl.py -f urls.txt -p YARAProcessing,PayloadProcessing -s ConsoleStorage

Modo Serviço

Com o modo serviço, uma quantidade maior de domínios pode ser varrida e os resultados salvos. Com base no módulo de armazenamento selecionado, os dados podem então ser analisados e avaliados em mais detalhes. Para tornar a execução do modo serviço o mais fácil possível para o usuário, construímos todas as funcionalidades em uma imagem Docker. No modo serviço, os domínios a serem varridos são obtidos através dos módulos de entrada. Por padrão, novas URLs de malware e phishing são baixadas de URLhaus e PhishTank e enfileiradas para varredura. Os módulos de processamento e armazenamento desejados podem ser inseridos diretamente no config.yml. Por padrão, os seguintes módulos de processamento são ativados, utilizando o armazenamento SQLite:

  • ClamAVProcessing
  • JARMProcessing
  • TLSHProcessing
  • YARAProcessing

Além do módulo de armazenamento SQLite, uma interface web simples foi desenvolvida que permite visualizar e gerenciar os domínios e URLs varridos.

Interface web para o módulo de armazenamento SQLite

No entanto, se esta interface não for suficiente para a avaliação subsequente dos dados, o módulo de armazenamento MISP pode ser ativado alternativamente ou adicionalmente. As configurações correspondentes devem ser feitas no config.yml na seção MISP.

Os dois comandos a seguir são suficientes para clonar o repositório GIT, criar o contêiner Docker e iniciá-lo diretamente. Depois disso, a interface web pode ser acessada no endereço https://localhost:8000/. Observe que, uma vez que os contêineres sejam iniciados, os módulos de entrada começarão a adicionar URLs à fila de processamento e o mecanismo começará a rastrear hosts.

root@kitploit:~
git clone https://github.com/hpthreatresearch/subcrawl.git

docker-compose up --build 

Módulos do SubCrawl

Módulos de Entrada

Os módulos de entrada são usados apenas no modo serviço. Se o SubCrawl for iniciado usando o modo execução única, então um arquivo contendo as URLs para varredura deve ser fornecido. Os dois módulos de entrada a seguir foram implementados.

URLhaus

URLhaus é um proeminente serviço web que rastreia URLs maliciosas. O serviço web também fornece exportações contendo novas URLs detectadas. Essas URLs de malware servem como entrada perfeita para o nosso crawler, já que queremos principalmente analisar domínios maliciosos. URLs submetidas recentemente são recuperadas e os resultados da pesquisa não são refinados através da requisição da API (ou seja, através de tags ou outros parâmetros disponíveis). A requisição HTTP feita neste módulo de entrada para a API do URLHaus pode ser modificada para refinar ainda mais os resultados obtidos.

PhishTank

PhishTank é um site que coleta URLs de phishing. Os usuários têm a possibilidade de enviar novas páginas de phishing encontradas. Uma exportação com URLs de phishing ativas pode ser gerada e baixada deste serviço web via API. Portanto, esta também é uma coleção ideal para o nosso crawler.

Módulos de Processamento

O SubCrawl vem com vários módulos de processamento. Os módulos de processamento seguem um comportamento semelhante na forma como fornecem resultados de volta ao mecanismo principal. Se correspondências são encontradas, os resultados são retornados ao mecanismo principal e posteriormente fornecidos aos módulos de armazenamento. Abaixo está uma lista dos módulos de processamento.

SDHash

O módulo de processamento SDHash é usado para calcular um hash de similaridade da resposta HTTP. O tamanho mínimo do conteúdo deve ser de 512 bytes para ser capaz de calcular um hash com sucesso. Este é provavelmente o módulo de processamento mais complicado de instalar, pois requer Protobuf e, dependendo do host alvo, deve ser recompilado. Portanto, este módulo de processamento está desativado por padrão. Uma versão já compilada pode ser encontrada em crawler/processing/minisdhash/, que requer protobuf-2.5.0 e python3.6. Esses binários foram compilados em um Ubuntu 18.04.5 LTS x64. Seguindo as instruções de instalação:

root@kitploit:~
# Instalação do Protobuf
> apt-get update
> apt-get -y install libssl-dev libevent-pthreads-2.1-6 libomp-dev g++
> apt-get -y install autoconf automake libtool curl make g++ unzip
> wget https://github.com/protocolbuffers/protobuf/releases/download/v2.5.0/protobuf-2.5.0.zip
> unzip protobuf-2.5.0.zip
> cd protobuf-2.5.0
> ./configure
> make
> sudo make install

# Instalação do Python3.6
> apt-get install python3.6-dev
> sudo ldconfig

# Instalação do SDHash
> git clone https://github.com/sdhash/sdhash.git
> cd sdhash
> make
> make install
> ldconfig

JARM

JARM é uma ferramenta que faz a impressão digital de conexões TLS, desenvolvida pela Salesforce. O módulo de processamento JARM realiza uma varredura do domínio e retorna um hash JARM com o domínio para o mecanismo principal. Dependendo da configuração de um servidor web, o handshake TLS tem propriedades diferentes. Ao calcular um hash dos atributos deste handshake, essas diferenças podem ser usadas para rastrear configurações de servidores web.

TLSH

O módulo de processamento TLSH é semelhante ao módulo de processamento SDHash, usado para calcular um hash de similaridade. A vantagem do TLSH é que a instalação é muito mais simples e a entrada mínima é menor, com 50 bytes. Como a maioria dos logins de webshells é relativamente pequena e foi o foco de nossa pesquisa, ativamos este módulo de processamento por padrão.

YARA

O módulo de processamento YARA é usado para escanear o conteúdo da resposta HTTP com regras YARA. Para invocar este módulo de processamento, forneça o valor YARAProcessing como argumento do módulo de processamento. Por exemplo, o comando a seguir carregará o módulo de processamento YARA e produzirá saída no console através do módulo de armazenamento ConsoleStorage.

root@kitploit:~
python3 subcrawl.py -p YARAProcessing -s ConsoleStorage

Atualmente, o módulo de processamento YARA é usado para identificar logins de webshells e vários outros conteúdos interessantes. As regras YARA incluídas neste projeto:

  • protected_webshell: Identifica páginas de login de webshells protegidos por senha
  • js_webshell_tracking_script: Identifica plugins/temas backdoorados que usam JavaScript para notificar o atacante quando o webshell se torna ativo
  • open_webshell: Identifica webshells abertos (ou seja, webshells que não são protegidos por login)
  • php_webshell_backend: Identifica backend de webshell PHP usado pelo atacante

Exemplo de saída: Saída do processamento YARA

Para adicionar regras YARA adicionais, você pode adicionar arquivos .YAR à pasta yara-rules e, em seguida, incluir o arquivo de regra adicionando uma instrução include em combined-rules.yar.

ClamAV

O módulo de processamento ClamAV é usado para escanear o conteúdo da resposta HTTP durante a varredura com o ClamAV. Se uma correspondência for encontrada, ela é fornecida aos vários módulos de saída. Para invocar este módulo de processamento, forneça o valor ClamAVProcessing como argumento do módulo de processamento. Por exemplo, o comando a seguir carregará o módulo de processamento ClamAV e produzirá saída no console através do módulo de armazenamento ConsoleStorage.

root@kitploit:~
python3 subcrawl.py -p ClamAVProcessing -s ConsoleStorage

Exemplo de saída: Módulo de Processamento ClamAV

Para utilizar este módulo, o ClamAV deve estar instalado. A partir de um terminal, instale o ClamAV usando o gerenciador de pacotes APT:

root@kitploit:~
$ sudo apt-get install clamav-daemon clamav-freshclam clamav-unofficial-sigs

Uma vez instalado, o serviço de atualização do ClamAV já deve estar em execução. No entanto, se você quiser atualizar manualmente usando freshclam, certifique-se de que o serviço esteja parado:

root@kitploit:~
sudo systemctl stop clamav-freshclam.service

E então execute freshclam manualmente:

root@kitploit:~
$ sudo freshclam

Finalmente, verifique o status do serviço ClamAV:

root@kitploit:~
$ sudo systemctl status clamav-daemon.service

Se o serviço não estiver em execução, você pode usar systemctl para iniciá-lo:

root@kitploit:~
$ sudo systemctl start clamav-daemon.service

Payload

O módulo de processamento Payload é usado para identificar o conteúdo da resposta HTTP usando a biblioteca libmagic. Além disso, o SubCrawl pode ser configurado para salvar conteúdo de interesse, como arquivos PE ou arquivos compactados. Para invocar este módulo de processamento, forneça o valor PayloadProcessing como argumento do módulo de processamento. Por exemplo, o comando a seguir carregará o módulo de processamento Payload e produzirá saída no console:

root@kitploit:~
python3 subcrawl.py -p PayloadProcessing -s ConsoleStorage

Não há dependências adicionais para este módulo.

Exemplo de saída: Saída do processamento Payload

Módulos de Armazenamento

Os módulos de armazenamento são chamados pelo mecanismo SubCrawl após todas as URLs da fila terem sido varridas. Eles foram projetados com dois objetivos em mente. Primeiro, obter os resultados da varredura imediatamente após finalizar a fila de varredura e, em segundo lugar, permitir armazenamento e análise de longo prazo. Portanto, implementamos não apenas um módulo ConsoleStorage, mas também uma integração para MISP e um módulo de armazenamento SQLite.

Console

Para analisar rapidamente os resultados diretamente após a varredura de URLs, uma saída bem formatada é impressa no console. Esta saída é mais adequada quando o SubCrawl é usado no modo execução única. Embora essa abordagem tenha funcionado bem para escanear domínios únicos ou gerar saída rápida, ela é difícil de usar para pesquisa e análise de longo prazo.

Console Storage UI

Elastic

A integração com um cluster Elastic também está disponível. Cada URL, juntamente com seus dados, será indexada como um evento, o que incluirá a saída de outros módulos, como Yara. Um painel padrão também foi adicionado para ajudar a começar a usar este módulo. Atualizações na seção elasticsearch precisarão ser feitas, o que incluirá:

  • Elastic search host (padrão localhost)
  • Porta para encontrar o elastic (padrão 9200)
  • Nome do índice (padrão subcrawl)
  • Archive response content - salva o corpo da resposta HTTP no disco (padrão False)
  • Archive log location - localização para salvar o conteúdo da resposta (padrão log/)

Para usar este módulo de saída, forneça o valor ElasticStorage com o argumento -s.

SQLite

Como a instalação e configuração do MISP podem ser demoradas, implementamos outro módulo que armazena os dados em um banco de dados SQLite. Para apresentar os dados ao usuário de forma simples e clara, também desenvolvemos uma interface web simples. Usando esta aplicação web, os domínios e URLs varridos podem ser visualizados e pesquisados com todos os seus atributos. Como esta é apenas uma versão inicial, nenhum recurso complexo de comparação foi implementado ainda.

SQLite UI

MISP

MISP é uma plataforma de inteligência de ameaças de código aberto com um modelo de dados flexível e API para armazenar e analisar dados de ameaças. O SubCrawl armazena dados rastreados em eventos MISP, publicando um evento por domínio e adicionando quaisquer diretórios abertos identificados como atributos. O MISP também permite que os usuários definam tags para eventos e atributos. Isso é útil para comparação de eventos e análises de links. Como este foi um dos nossos principais objetivos de pesquisa, enriquecemos os dados do URLHaus ao exportar a saída do SubCrawl para o MISP. O URLHaus anota seus dados usando tags que podem ser usadas para identificar uma família de malware ou ator de ameaça associado a uma URL. Para cada URL de diretório aberto, o módulo consulta os dados do URLHaus armazenados localmente e adiciona tags do URLHaus ao evento MISP se houver correspondência. Para evitar uma coleção de atributos não relacionados para cada evento MISP, criamos um novo objeto MISP para URLs varridas, chamado opendir-url. Isso garante que atributos relacionados sejam mantidos juntos, facilitando a obtenção de uma visão geral dos dados.

MISP UI

Construindo seus Próprios Módulos

Modelos para módulos de processamento e armazenamento são fornecidos como parte do framework.

Módulos de Processamento

Os módulos de processamento podem ser encontrados em crawler->processing e um arquivo de módulo de exemplo example_processing.py é encontrado neste diretório. O modelo fornece a herança e importações necessárias para garantir a execução pelo framework. A função init fornece a inicialização do módulo e recebe uma instância do logger e da configuração global. O logger é usado para fornecer informações de log dos módulos de processamento, bem como em todo o framework.

A função process é implementada para processar cada resposta HTTP. Para esse fim, ela recebe a URL e o conteúdo bruto da resposta. É aqui que o trabalho do módulo é implementado. Esta função deve retornar um dicionário com os seguintes campos:

  • hash: o sha256 do conteúdo
  • url: a URL da qual o conteúdo foi recuperado
  • matches: quaisquer resultados de correspondência no módulo, por exemplo, resultados de libmagic ou YARA.

Um nome de classe único deve ser definido e é usado para definir este módulo ao incluí-lo através do argumento -p ou como um módulo de processamento padrão no arquivo de configuração.

Finalmente, adicione uma instrução de importação em __init__.py, usando o nome da sua classe:

root@kitploit:~
from .<REPLACE>_processing import <REPLACE>Processing

Módulos de Armazenamento

Os módulos de armazenamento podem ser encontrados em crawler->storage e um arquivo de módulo de exemplo example_storage.py é encontrado neste diretório. Semelhante aos módulos de processamento, a função init fornece a inicialização do módulo e recebe uma instância do logger e da configuração global. A função store_results recebe dados estruturados do mecanismo em intervalos definidos pelo tamanho do lote no arquivo de configuração.

Um nome de classe único deve ser definido e é usado para carregar o módulo ao incluí-lo através do argumento -s ou como um módulo de processamento padrão no arquivo de configuração.

Apresentações e Outros Recursos

2021:

  • BlackHat Arsenal USA
  • VirusBulletin Localhost - Em breve

Licença

SubCrawl é licenciado sob a licença MIT.

Baixar ferramenta