Crawlector

Crawlector (o nome Crawlector é uma combinação de Crawler & Detector) é um framework de caça a ameaças projetado para escanear sites em busca de objetos maliciosos.

Nota-1: O framework foi apresentado pela primeira vez na conferência No Hat em Bergamo, Itália, em 22 de outubro de 2022 (Slides, Gravação no YouTube). Além disso, foi apresentado pela segunda vez na conferência AVAR, em Singapura, em 2 de dezembro de 2022.

Nota-2: A ferramenta acompanhante EKFiddle2Yara (é uma ferramenta que pega regras do EKFiddle e as converte em regras Yara) mencionada na palestra também foi lançada em ambas as conferências.

Nota-3: A versão 2.0 (Photoid Build:180923), um lançamento marco, foi lançada em 18 de setembro de 2023.

Nota-4: A versão 2.1 (Universe-647 Build:031023) foi lançada em 03 de outubro de 2023. Uma grande adição é o recurso de Notificação de Alerta do Slack.

Nota-5: A versão 2.2 (Hallstatt Build:051123) foi lançada em 05 de novembro de 2023. Uma grande adição é o recurso de Controle Remoto do Slack.

Nota-6: A versão 2.3 (Munich Build:241123) foi lançada em 24 de novembro de 2023. Uma grande adição é o recurso de Servidores DNS.

Nota-6: A versão 2.3.1 {Nero Build:131225} foi lançada em 13 de dezembro de 2025. Este é um lançamento de manutenção.

Recursos

• Suporte a spiderização de sites para encontrar links adicionais para escanear (apenas até 2 níveis)
• Integra Yara como mecanismo backend para varredura de regras
• Suporte a varredura online e offline
• Suporte a crawling para certificados digitais de domínios/sites
• Suporte a consultas ao URLhaus para encontrar URLs maliciosas na página
• Extração Profunda de Objetos (DOE)
• Notificação de Alerta do Slack
• Suporte parametrizado para redirecionamento HTTP
• Recuperação de informações Whois
• Suporte a hashing do conteúdo da página com TLSH (Trend Micro Locality Sensitive Hash) e outras funções hash criptográficas padrão, como md5, sha1, sha256 e ripemd128, entre outras
  • TLSH não retornará um valor se o tamanho da página for menor que 50 bytes, ou se não houver aleatoriedade suficiente nos dados
• Suporte a consulta da classificação e categoria de cada URL
• Suporte a expansão de um determinado site ao tentar encontrar todos os TLDs e/ou subdomínios disponíveis para o mesmo domínio
  • Este recurso usa as APIs do Omnisint Labs (este site está fora do ar desde 10 de março de 2023) e da RapidAPI
  • A implementação de expansão de TLD é nativa
  • Este recurso, juntamente com a classificação e categorização, fornece a capacidade de encontrar domínios de scam/phishing/maliciosos para o domínio original
• Suporte a resolução de domínio (IPv4 e IPv6)
• Salva páginas de sites escaneadas para varredura posterior (pode ser salvo como zip compactado)
• A totalidade das configurações do framework é controlada através de um único arquivo de configuração personalizável
• Todas as sessões de varredura são salvas em um arquivo CSV bem estruturado com uma infinidade de informações sobre o site sendo escaneado, além de informações sobre as regras Yara que foram acionadas
• Muitos outros recursos...
• Todas as comunicações HTTP(S) são cientes de proxy
• Um único executável
• Escrito em C++

Varredura URLHaus e Integração com API

Isso é para verificar URLs maliciosas em cada página sendo escaneada. O framework pode consultar a lista de URLs maliciosas do servidor do URLHaus (configuração: url_list_web), ou de um arquivo em disco (configuração: url_list_file), e se este último for especificado, ele terá precedência sobre o primeiro.

Funciona pesquisando o conteúdo de cada página em todas as entradas de URL em url_list_web ou url_list_file, verificando todas as ocorrências. Além disso, em caso de correspondência, e se a opção de configuração check_url_api estiver definida como true, o Crawlector enviará uma solicitação POST para a URL da API definida na opção de configuração url_api, que retorna um objeto JSON com informações extras sobre uma URL correspondente. Essas informações incluem urlh_status (ex., online, offline, unknown), urlh_threat (ex., malware_download), urlh_tags (ex., elf, Mozi) e urlh_reference (ex., https://urlhaus.abuse.ch/url/1116455/). Essas informações serão incluídas no arquivo de log cl_mlog_<current_date><current_time><(pm|am)>.csv (veja abaixo), apenas se check_url_api estiver definido como true. Caso contrário, o arquivo de log incluirá as colunas urlh_url (lista de URLs maliciosas correspondentes) e urlh_hit (número de ocorrências para cada URL maliciosa correspondente), condicionado a check_url estar definido como true.

O recurso URLHaus pode ser desabilitado por completo definindo a opção de configuração check_url como false.

É importante notar que este recurso pode desacelerar a varredura, considerando o enorme número de URLs maliciosas (~ 130 milhões de entradas no momento desta escrita) que precisam ser verificadas, e o tempo necessário para obter informações extras do servidor URLHaus (se a opção check_url_api estiver definida como true).

Estruturas de Arquivos e Pastas

1. \cl_sites
   • é onde a lista de sites a serem visitados ou rastreados é armazenada.
   • suporta múltiplos arquivos e diretórios.
2. \crawled
   • onde todas as URLs rastreadas/spiderizadas são salvas em um arquivo de texto.
3. \certs
   • onde todos os certificados digitais de domínios/sites são armazenados (no formato .der).
4. \results
   • onde os sites visitados são salvos. Isso é configurável através da opção results_dir
5. \pg_cache
   • cache do programa para sites que não fazem parte da funcionalidade de spider. Isso é configurável através da opção cache_dir, seção [default].
6. \cl_cache
   • cache do crawler para sites que fazem parte da funcionalidade de spider. Isso é configurável através da opção cache_dir, seção [spider].
7. \yara_rules
   • é onde todas as regras Yara são armazenadas. Todas as regras que existem neste diretório serão carregadas pelo mecanismo, analisadas, validadas e avaliadas antes da execução.
8. cl_config.ini
   • este arquivo contém todos os parâmetros de configuração que podem ser ajustados para influenciar o comportamento do framework.
9. cl_mlog_<current_date><current_time><(pm|am)>.csv
   • arquivo de log que contém uma infinidade de informações sobre sites visitados
   • data, hora, status da varredura Yara, lista de regras Yara disparadas com os deslocamentos e comprimentos de cada correspondência, id, URL, código de status HTTP, status da conexão, cabeçalhos HTTP, tamanho da página, caminho para uma página salva em disco e outras colunas relacionadas aos resultados do URLHaus.
   • o nome do arquivo é único por sessão.
10. cl_offl_mlog_<current_date><current_time><(pm|am)>.csv
    • arquivo de log que contém informações sobre arquivos escaneados offline.
    • lista de regras Yara disparadas com os deslocamentos e comprimentos das correspondências, e caminho para uma página salva em disco.
    • o nome do arquivo é único por sessão.
11. cl_certs_<current_date><current_time><(pm|am)>.csv
    • arquivo de log que contém uma infinidade de informações sobre certificados digitais encontrados
12. \expanded\exp_subdomain_<pm|am>.txt

Arquivo de Configuração (cl_config.ini)

Você deve se familiarizar com o arquivo de configuração cl_config.ini antes de executar qualquer sessão. Todas as seções e parâmetros estão documentados no próprio arquivo de configuração.

O recurso de varredura offline Yara é uma opção independente, ou seja, se ativado, o Crawlector executará apenas este recurso, independentemente de outros recursos ativados. E o mesmo é verdadeiro para o recurso de crawling para certificados digitais de domínios/sites. De qualquer forma, é recomendável desabilitar todos os recursos não utilizados no arquivo de configuração.

• Dependendo das configurações (log_to_file ou log_to_cons), se uma regra Yara referenciar apenas atributos de um módulo (ex., PE, ELF, Hash, etc), então o Crawlector exibirá apenas o nome da regra em uma correspondência, excluindo dados de deslocamento e comprimento.

Nota: para qualquer opção que aceite um caminho, forneça sempre o caminho absoluto.

Padrão de Formato dos Sites

Para visitar/escanear um site, a lista de URLs deve ser armazenada em arquivos de texto, no diretório “cl_sites”.

O Crawlector aceita três tipos de URLs:

1. Tipo 1: uma URL por linha
   • O Crawlector atribuirá um nome único a cada URL, derivado do hostname da URL
2. Tipo 2: uma URL por linha, com um nome único [a-zA-Z0-9_-]{1,128} = <url>
3. Tipo 3: para a funcionalidade de spider, um formato único é usado. Uma URL por linha é a seguinte:

<id>[depth:<0|1>-><\d+>,total:<\d+>,sleep:<\d+>] = <url>

Por exemplo,

mfmokbel[depth:1->3,total:10,sleep:0] = https://www.mfmokbel.com

que é equivalente a: mfmokbel[d:1->3,t:10,s:0] = https://www.mfmokbel.com

onde, <id> := [a-zA-Z0-9_-]{1,128}

depth, total e sleep também podem ser substituídos por suas versões abreviadas d, t e s, respectivamente.

• depth: o spider suporta ir a dois níveis de profundidade para encontrar URLs adicionais (esta é uma decisão de design).
• Um valor de 0 indica uma profundidade de nível 1, com o valor que vem após “->” ignorado.
• Uma profundidade de nível-1 é controlada pelo parâmetro total. Então, primeiro, o spider tenta encontrar quantas URLs adicionais puder a partir da URL especificada.
• O valor após “->” representa o número máximo de URLs para spider para cada uma das URLs encontradas (conforme o valor do parâmetro total).
• Um valor de 1 indica uma profundidade de nível 2, com o valor que vem após “->” representando o número máximo de URLs a encontrar, para cada URL encontrada conforme o parâmetro total. Para esclarecer, e como mostrado no exemplo acima, primeiro, o spider procurará 10 URLs (conforme especificado no parâmetro total), e então, cada uma dessas URLs encontradas será spiderizada até um máximo de 3 URLs; portanto, e no melhor cenário, terminaríamos com 40 (10 + (10*3)) URLs.
• O parâmetro sleep aceita um valor inteiro representando o número de milissegundos para pausar entre cada requisição HTTP.

Nota 1: Uma URL do Tipo 3 pode ser transformada em uma URL do Tipo 1 definindo o parâmetro de configuração live_crawler como false no arquivo de configuração, na seção spider.

Nota 2: Linhas vazias e linhas que começam com “;”, "#" ou “//” são ignoradas.

A Funcionalidade de Spider

A funcionalidade de spider é o que dá ao Crawlector a capacidade de encontrar links adicionais na página alvo. O Spider suporta os seguintes recursos:

• O domínio deve ser do Tipo 3 para que a funcionalidade Spider funcione
• Você pode especificar uma lista de padrões curinga (separados por pipe) para evitar que URLs correspondentes sejam spiderizadas através da opção de config. exclude_url. Por exemplo, *.zip|*.exe|*.rar|*.zip|*.7z|*.pdf|.*bat|*.db
• Você pode especificar uma lista de padrões curinga (separados por pipe) para spiderizar apenas URLs que correspondam ao padrão através da opção de config. include_url. Por exemplo, */checkout/*|*/products/*
• Você pode excluir URLs HTTPS através da opção de config. exclude_https
• Você pode considerar também links externos/de saída, apenas para a página principal, através da opção de config. add_ext_links. Este recurso respeita as opções de config. exclude_url e include_url.
• Você pode considerar apenas links externos/de saída da página principal, excluindo todas as outras URLs, através da opção de config. ext_links_only. Este recurso respeita as opções de config. exclude_url e .

Tipos de IDs

Na versão 2.0, os IDs têm seus tipos explicitamente atribuídos anexando um dos seguintes tipos ao próprio ID:

Ter cada id carregando seu tipo consigo facilita a navegação e filtragem dos resultados. Além disso, isso é usado internamente por vários motivos.

Funcionalidade de Classificação de Sites

• Isso é para verificar a classificação do site
• Você fornece um arquivo com uma lista de sites, com sua classificação, em formato de arquivo CSV
• Serviços que fornecem listas de classificação de sites incluem Alexa top-1m (descontinuado desde maio de 2022), Cisco Umbrella, Majestic, Quantcast, Farsight e Tranco, entre outros
• Formato do arquivo CSV (apenas 2 colunas): a primeira coluna contém a classificação, e a segunda coluna contém o nome do domínio
• Se uma célula contiver dados entre aspas, ela será automaticamente removida das aspas
• Quebras de linha não são permitidas em texto entre aspas
• Espaços iniciais e finais são removidos das células lidas
• Linhas vazias e de comentário são ignoradas
• A seção site_ranking no arquivo de configuração fornece algumas opções para alterar como o arquivo CSV deve ser lido
• O desempenho desta consulta depende do número de registros no arquivo CSV
• O Crawlector compara cada entrada no arquivo CSV com o domínio sob investigação, e não o contrário
• Apenas o domínio registrado/de nível de pagamento é comparado

Encontrando TLDs e Subdomínios - Seção [site]

• A seção site fornece a capacidade de expandir um determinado site ao tentar encontrar todos os domínios de topo (TLDs) e/ou subdomínios disponíveis para o mesmo domínio. Se encontrados, novos TLDs/subdomínios serão verificados como qualquer outro domínio
• Este recurso usa as APIs do Omnisint Labs (https://omnisint.io/) e da RapidAPI
• A API do Omnisint Labs retorna subdomínios e TLDs, enquanto a RapidAPI retorna apenas subdomínios (a API do Omnisint Labs está fora do ar desde 10 de março de 2023; no entanto, a implementação ainda está disponível caso o site volte)
• Para a RapidAPI, você precisa de uma chave de API válida "Domains records" que você pode solicitar da RapidAPI e inserir na chave rapid_api_key no arquivo de configuração
• Com find_tlds ativado, além dos resultados de tlds da API do Omnisint Labs, o framework tenta encontrar outros domínios ativos/registrados percorrendo cada entrada de tld, seja no tlds_file ou tlds_url
• Se tlds_url estiver definido, ele deve apontar para uma URL que hospeda tlds, cada um em uma nova linha (linhas que começam com qualquer um dos caracteres ';', '#' ou '//' são ignoradas)
• tlds_file contém o nome do arquivo que contém a lista de tlds (mesmo que para tlds_url; apenas o tld está presente, excluindo o '.', por ex., "com", "org")
• Se tlds_file estiver definido, ele tem precedência sobre

Funcionalidade de Redirecionamento

A funcionalidade de redirecionamento de URL em versões anteriores estava quebrada. Esta versão fornece uma reescrita completa do recurso de redirecionamento, com um alto grau de parametrização para controlar sua operação. Na versão 2.0, o redirecionamento tem uma seção dedicada no arquivo de configuração, chamada [redirect]. A totalidade da funcionalidade de redirecionamento pode ser ativada/desativada através da opção follow_redir, na seção [default].

A função de redirecionamento verifica os códigos de status de resposta HTTP: 301, 302, 303, 307 e 308. Em caso de correspondência, o Crawlector analisará o cabeçalho Location para a URL de redirecionamento, considerando URLs de redirecionamento absolutas e relativas. A funcionalidade de redirecionamento no Crawlector foi projetada para desempenho e agilidade. A seção [redirect] fornece a seguinte lista de opções:

[redirect]

• depth = all ; (t: string)
• max_redirect = 200 ; (t: uint16_t)
• visit = true ; (t: bool)
• skip_similar = true ; (t: bool)

A opção depth aceita um dos valores, last ou all. Ela controla quais URLs de redirecionamento encontradas visitar, dependendo se a opção visit está habilitada ou não. all é para visitar todas as URLs de redirecionamento encontradas. last é para visitar a última URL de redirecionamento. A visita a essas URLs ocorre na mesma sessão/atual. Tenha em mente que, independentemente do valor de depth, o Crawlector registrará a lista de todos os redirecionamentos encontrados para URLs, juntamente com o número total, em forma absoluta. Eles serão escritos no arquivo CSV cl_mlog, nas colunas redirect_urls e redirect_total.

A opção max_redirect define um limite superior no número total de redirecionamentos de URL a serem descobertos.

A opção skip_similar é melhor explicada através do seguinte exemplo:

Suponha que a URL original fornecida ao Crawlector para rastrear seja "https://www.mfa.gov.law" e uma das redirect_urls encontradas seja "https://mfa.gov.law/". Como você pode perceber, a única diferença é a barra no final da URL. Essas duas URLs são as mesmas, e o servidor responderá com a mesma página. Se a opção visit estiver definida como true, o Crawlector rastreará ambas as URLs, desperdiçando recursos e realizando a mesma tarefa duas vezes. Isso pode não ser um problema para 1 ou 2 URLs, mas se você tiver 1000s de URLs para rastrear e a opção visit estiver ativada, as chances de mais da metade delas terem uma URL descoberta como essa são muito altas; nesse caso, isso se torna um problema urgente a ser considerado. Assim, definir a opção skip_similar como true ajudará a resolver esse problema, pulando a visita a URLs semelhantes. Além do cenário da barra, a opção skip_similar também considera os dois cenários a seguir: se a URL de redirecionamento for diferente apenas por um ou ambos os prefixos, "https://" e "www.".

Extração Profunda de Objetos (DOE)

Uma das principais adições à versão 2.0 é a capacidade de extrair diferentes tipos de objetos da página, salvá-los em disco, escanear com Yara e URLHaus e salvar os resultados no arquivo CSV. Para ativar este recurso, defina a opção extract_obj como true, na seção [page].A implementação da funcionalidade de extração profunda de objetos funciona criando um arquivo de arquivo web MHT a partir da página web, incluindo scripts externos, imagens e arquivos CSS. Todos os arquivos incorporados serão extraídos para o caminho especificado pela opção obj_dir (caminho: obj_dir/objects/), onde cada arquivo será escaneado. A implementação não deve ser confundida com a funcionalidade de navegador headless. DOE é diferente e não envolve carregar a página para recuperar todas as URLs consultadas dinamicamente. Portanto, tem suas limitações.

Todos os objetos extraídos terão alguns de seus metadados escritos no arquivo CSV. Coisas a ter em mente ao ler o arquivo CSV: o ID do domínio com o objeto extraído tem um formato único, como segue, <domain_id>_p_obj (por exemplo, mfa_gov_cef40bc5-ba6a-41_t1_p_obj_0). E a url terá o seguinte formato, __<object_filename> (por exemplo, https://www.mfa.gov.law__bilmur.min.js).

Se a opção delete_obj for definida como true, todos os objetos extraídos que não estão sendo detectados pelo Yara serão excluídos do disco. Se a opção log_all_objs for definida como true, registre todos os metadados dos objetos extraídos no mesmo arquivo CSV cl_mlog. Se a opção check_urlhaus na seção [page] for definida como true, cada objeto extraído será escaneado pelo URLHaus. Observe que as opções desta opção são herdadas da seção [urlhaus].

Nota: se o domínio sendo rastreado redirecionar para outro domínio, então o último redirecionamento para URL deve ser passado para o DOE funcionar. Além disso, o domínio deve começar com "HTTP(S)://" para o DOE funcionar.

Notificação de Alerta do Slack

Às vezes, você pode querer executar sessões do Crawlector que podem levar dias para serem concluídas, por exemplo, rastreando os 1 milhão principais sites Alexa, e para tal cenário, você precisa de uma maneira de monitorar remotamente a operação e o progresso do framework. Portanto, no lançamento 2.1, adicionei o recurso de notificação de alerta do Slack para fornecer um mecanismo para monitorar a execução do Crawlector em tempo real, enviando alertas do Yara, eventos std::exit(), avisos e erros do processo para um canal do Slack de sua escolha. Além disso, o Crawlector instala um manipulador de console na tentativa de monitorar certos tipos de eventos, incluindo ctrl_c, ctrl_close, ctrl_break, ctrl_logoff e ctrl_shutdown. É importante ter em mente que o Crawlector não altera/modifica o comportamento do manipulador padrão; ele apenas reporta ao canal do Slack o recebimento de qualquer um dos eventos listados. Isso pode ser estendido no futuro para considerar outros tipos de eventos.

Este recurso usa a API REST do Slack e, para autenticação com o servidor, usa OAuth 2.0. Você precisará de um token da API do Slack para usá-lo e de um canal configurado com as permissões corretas. Este recurso apenas posta mensagens no canal do Slack e não recebe nem processa nenhuma mensagem recebida.

A seção [slack_alert] fornece a seguinte lista de opções:

[slack_alert]

• alert = true ; (t: bool)
• api_token = ; (t: string)
• channel = ; (t: string)
• sleep = ; (t: uint32_t) in milliseconds

Para desabilitar ou habilitar este recurso, simplesmente defina a opção alert como true ou false. Além disso, você precisa especificar o api_token, com um nome de channel.

Nota-1: Na fase de inicialização do Crawlector, ele testa se o token de autenticação fornecido é válido ou não, ou se o canal está definido, e em caso de falha, este recurso é desabilitado automaticamente.

Todos os alertas reportados ao canal do Slack são reportados sob o nome de usuário Crawlector v<número_da_versão>, por exemplo, Crawlector v2.1. O usuário tem o ícone de uma teia de aranha. Além disso, todos os alertas são encadeados, ou seja, todos os alertas subsequentes após a primeira mensagem inicial são postados como respostas. Esta foi uma decisão de design e ajuda caso você esteja executando várias sessões ao mesmo tempo, todas reportando ao mesmo canal. Alguns alertas usam a linguagem de marcação markdown para formatação.

Quando o processo termina com sucesso e está prestes a sair, ele posta a seguinte mensagem:

Crawlector terminou e está sendo encerrado com sucesso

Nota-2: O limite de taxa do Slack na API de postagem de mensagens é de uma mensagem por segundo, com margem para alguns surtos. O Crawlector não enfileira mensagens para contabilizar mais postagens por segundo. Isso pode mudar no futuro, se necessário; no entanto, a opção sleep permite que o processo durma por um período especificado após cada mensagem postada com sucesso.

Controle Remoto do Slack

Com o lançamento 2.2 (codinome Hallstatt), estou introduzindo a capacidade de controlar remotamente o Crawlector através de um conjunto selecionado de comandos de controle especialmente projetados. A razão para introduzir esta funcionalidade é monitorar e controlar certos comportamentos de sessões que devem durar horas ou dias. Por exemplo, você pode querer ativar/desativar a funcionalidade de alerta do Slack, encerrar o Crawlector e carregar um arquivo de configuração, entre outros.

Este recurso usa a API REST do Slack e, para autenticação com o servidor, usa OAuth 2.0. Você precisará de um token da API do Slack para usá-lo e de um canal configurado com as permissões corretas. O token da API é o mesmo usado na seção [slack_alert], opção api_token.

A seção [slack_alert] fornece a seguinte lista adicional de opções para a funcionalidade de controle remoto:

[slack_alert] (opções de controle)

• control = true ; (t: bool)
• ctrl_channel = ; (t: string) tem que ser o ID do canal e não o nome do canal
• ctrl_sleep = ; (t: uint32_t) em milissegundos

Para desabilitar ou habilitar este recurso, simplesmente defina a opção control como true ou false. O nome ctrl_channel tem que ser o ID do canal e não o nome do canal. Você pode obtê-lo clicando com o botão direito no nome do canal -> Ver detalhes do canal -> Role até o final da janela, e verá o campo ID do Canal: <channel_id>.

A opção ctrl_sleep determina a frequência de chamada ao canal de controle especificado na opção ctrl_channel para recuperar comandos de controle. Você também pode atualizar esta opção através do comando de controle cl_update_delay <time_in_ms>.

A lista de comandos de controle suportados é a seguinte:

Nota-1: Na fase de inicialização do Crawlector, ele testa se o token de autenticação fornecido é válido ou não, ou se o canal está definido, e em caso de falha, este recurso é desabilitado automaticamente.

Se esta funcionalidade estiver habilitada, e assim que passar na validação do token da API, o Crawlector envia a mensagem "Crawlector está pronto para receber comandos de controle. Digite o comando cl_help para obter uma lista de comandos de controle suportados." para o ctrl_channel designado.

Todas as respostas a um determinado comando de controle são encadeadas. Além disso, os comandos de controle são lidos por sessão, a partir do momento em que uma sessão é iniciada.

Nota-2: O limite de taxa do Slack na API de recuperação (histórico de conversas) é de uma requisição por segundo, com margem para alguns surtos. Portanto, se a opção ctrl_sleep estiver definida para um valor menor que um segundo ou maior que um segundo, o Crawlector enfileira mensagens para contabilizar mais comandos de controle por segundo, e os executa na ordem recebida.

Servidores de Nomes DNS

Com o lançamento 2.3 (codinome Munich), a capacidade de especificar uma lista de servidores de nomes DNS para todas as consultas DNS e resoluções DNS-para-IP tentadas pelo Crawlector é introduzida com alto nível de controle. Isso é importante caso você esteja rastreando sites bloqueados ou maliciosos. Este recurso se aplica a todas as funções no Crawlector onde uma consulta DNS ou solicitação DNS-para-IP é feita. Mais importante, ele fornece a capacidade de realizar DNS sobre TLS para cada servidor de nomes que o suporta.

A seção [dns_ns] fornece a seguinte lista de opções para administrar esta funcionalidade:

[dns_ns]

• enable = false ; (t: bool)
• name_servers = 8.8.8.8(e_tls),12.13.14.15(d_tls) ; (t: string)
• dns_tls = yes ; (t: string) (yes, no or force)
• keep_default = false ; (t: bool)
• conn_time_out = 3000 ; (t: uint32_t) em milissegundos (0 para esperar indefinidamente)

A opção name_servers recebe uma lista parametrizada de servidores de nomes DNS a serem usados, separados por vírgula. O valor desta opção tem o formato: <IPv4_address>(<tls_option>) onde <tls_option> assume um dos valores "d_tls" ou "e_tls". As opções "d_tls" ou "e_tls" indicam se o servidor de nomes em questão suporta DNS sobre TLS ou não, respectivamente. Esta opção será aplicada dependendo do valor definido para a opção dns_tls. Por exemplo, a entrada 8.8.8.8(e_tls) indica usar o servidor DNS Google 8.8.8.8 com suporte a TLS, enquanto a entrada 12.13.14.15(d_tls) indica usar o servidor DNS 12.13.14.15 sem suporte a TLS.

A opção dns_tls especifica o nível de aplicação de TLS necessário. Esta opção assume um dos valores, "yes" "no" ou "force".

• yes
  • Servidores de nomes DNS com suporte a TLS serão tentados primeiro, e se nenhum NS com suporte a TLS for encontrado, então a resolução UDP/TCP será tentada.
• no
  • sem suporte a TLS (não usar servidores de nomes DNS com suporte a TLS)
• force
  • apenas servidores de nomes DNS com suporte a TLS serão usados, e qualquer consulta DNS iniciada pelo Crawlector usará DoT (DNS sobre TLS).

A opção keep_default indica se deve adicionar o(s) servidor(es) de nomes padrão à lista de servidores de nomes. Um servidor de nomes padrão é assumido sem suporte a TLS.

A opção conn_time_out especifica o tempo em milissegundos para esperar por uma resposta a uma consulta DNS.

A opção enable ativa ou desativa esta funcionalidade.

Melhorias Diversas na Versão 2.0

• Adicionadas as opções de linha de comando "-v" e "-c". A opção "-v" é para imprimir informações da versão no console. A opção "-c" é para ler um arquivo de configuração diferente, que não o padrão "cl_config.ini".
• Várias otimizações de código e pequenas melhorias
• Para cada domínio lido (sem subdomínio), o Crawlector irá prefixar "www." a cada entrada de site lida, se já não existir. Por exemplo, no caso da consulta de enumeração de subdomínios do RapidAPI, o domínio consultado deve começar com "www.".
• Adicionadas as opções clear_dns e upg_2_https à seção [default]. A primeira limpa o cache DNS de nome de host para IP, e a segunda atualiza todos os sites para HTTPS prefixando "https://" a eles. Da mesma forma, a opção tld_upgrd_2_https foi adicionada à seção [site], para atualizar domínios ativos com diferentes TLDs para https.
• Adicionadas as opções rapid_api_weeks e rapid_api_limit à seção [site] para configurar a requisição à API do RapidAPI. Ambas as opções são opcionais. A primeira especifica o número de semanas a consultar no banco de dados, enquanto a segunda especifica o número de subdomínios a retornar por site.
• No lançamento 2.0, você pode especificar um diretório de cache diferente para as seções [spider] e [default], através da opção cache_dir.
• Muitas opções foram adicionadas à seção page no lançamento 2.0, incluindo:
• A opção whois_info recupera informações de domínio whois incluindo, registrador, registered_on, expires_on e updated_on. Estes dados são obtidos de https://www.whois.com/whois/. Os dados são salvos no arquivo CSV cl_mlog.
• A opção page_title salva o título da página no arquivo CSV cl_mlog.
• A opção results_dir foi adicionada para fornecer a capacidade de salvar páginas em um caminho diferente. Se não definida, a pasta "results" será criada no mesmo diretório do Crawlector.
• Atualizado o motor Yara para 4.3.2

Considerações de Design

• Uma página URL é recuperada enviando uma requisição GET para o servidor, lendo o corpo da resposta do servidor e passando-o para o motor Yara para detecção.
• Alguns dos atributos da requisição GET são definidos na seção [default] no arquivo de configuração, incluindo os cabeçalhos User-Agent e Referer, e o tempo limite de conexão, entre outras opções.
• Embora o Crawlector registre os dados de uma sessão em um arquivo CSV, convertê-lo para um arquivo SQL é recomendado para melhor desempenho, manipulação e recuperação dos dados. Isso se torna evidente quando você está rastreando milhares de domínios.
• Domínios/URLs repetidos em cl_sites são permitidos.

Limitações

• Monothread
• Detecção estática (sem avaliação dinâmica do conteúdo de uma página específica). Verifique o recurso DOE em vez disso.
• Sem suporte a navegador headless, ainda!

Bibliotecas de terceiros usadas

• Chilkat: biblioteca para spidering de sites, comunicações HTTP, hashing, parsing JSON e compressão de arquivos (ZIP), entre outros
• Yara: para varredura de regras (v4.5.4)
• CrossGuid: para geração de GUID/UUID
• Inih: para parsing de arquivos de configuração
• Rapidcsv: para parsing de arquivos CSV
• Color Console: para colorização de console
• TLSH (Trend Micro Locality Sensitive Hash) (v4.8.2)

Contribuição

Aberto para pull requests e issues. Comentários e sugestões são muito apreciados.

Autor

Mohamad Mokbel (@MFMokbel)