Crawlector

Crawlector (il nome Crawlector è una combinazione di Crawler & Detector) è un framework di threat-hunting progettato per scansionare siti web alla ricerca di oggetti malevoli.

Nota-1: Il framework è stato presentato per la prima volta alla conferenza No Hat a Bergamo, Italia, il 22 ottobre 2022 (Slides, Registrazione YouTube). Inoltre, è stato presentato per la seconda volta alla conferenza AVAR, a Singapore, il 2 dicembre 2022.

Nota-2: Lo strumento complementare EKFiddle2Yara (è uno strumento che prende le regole EKFiddle e le converte in regole Yara) menzionato nel talk è stato anch'esso rilasciato in entrambe le conferenze.

Nota-3: La versione 2.0 (Photoid Build:180923), una release milestone, è stata rilasciata il 18 settembre 2023.

Nota-4: La versione 2.1 (Universe-647 Build:031023) è stata rilasciata il 3 ottobre 2023. Una grande aggiunta è la funzionalità di notifica Slack Alert.

Nota-5: La versione 2.2 (Hallstatt Build:051123) è stata rilasciata il 5 novembre 2023. Una grande aggiunta è la funzionalità di controllo remoto Slack.

Nota-6: La versione 2.3 (Munich Build:241123) è stata rilasciata il 24 novembre 2023. Una grande aggiunta è la funzionalità DNS Nameservers.

Nota-6: La versione 2.3.1 {Nero Build:131225} è stata rilasciata il 13 dicembre 2025. Questa è una release di manutenzione.

Caratteristiche

• Supporta lo spidering dei siti web per trovare link aggiuntivi da scansionare (solo fino a 2 livelli)
• Integra Yara come motore backend per la scansione delle regole
• Supporta la scansione online e offline
• Supporta il crawling per i certificati digitali di domini/siti
• Supporta la query su URLhaus per trovare URL malevoli nella pagina
• Deep Object Extraction (DOE)
• Notifica Slack Alert
• Supporto parametrizzato per il reindirizzamento HTTP
• Recupero delle informazioni Whois
• Supporta l'hashing del contenuto della pagina con TLSH (Trend Micro Locality Sensitive Hash) e altre funzioni di hash crittografico standard come md5, sha1, sha256 e ripemd128, tra gli altri
  • TLSH non restituirà un valore se la dimensione della pagina è inferiore a 50 byte o se non è presente abbastanza casualità nei dati
• Supporta la query sul rating e sulla categoria di ogni URL
• Supporta l'espansione di un determinato sito tentando di trovare tutti i TLD e/o sottodomini disponibili per lo stesso dominio
  • Questa funzione utilizza l'API Omnisint Labs (questo sito non è disponibile dal 10 marzo 2023) e le API RapidAPI
  • L'implementazione dell'espansione TLD è nativa
  • Questa funzione, insieme al rating e alla categorizzazione, fornisce la capacità di trovare domini di scam/phishing/malevoli per il dominio originale
• Supporta la risoluzione del dominio (IPv4 e IPv6)
• Salva le pagine dei siti web scansionate per una scansione successiva (possono essere salvate come zip compresso)
• Tutte le impostazioni del framework sono controllate tramite un unico file di configurazione personalizzabile
• Tutte le sessioni di scansione vengono salvate in un file CSV ben strutturato con una miriade di informazioni sul sito web scansionato, oltre a informazioni sulle regole Yara che hanno attivato
• Molte altre funzionalità...
• Tutte le comunicazioni HTTP(S) sono proxy-aware
• Un singolo eseguibile
• Scritto in C++

Scansione URLHaus e Integrazione API

Serve per verificare la presenza di URL malevoli in ogni pagina scansionata. Il framework può interrogare l'elenco di URL malevoli dal server URLHaus (configurazione: url_list_web) o da un file su disco (configurazione: url_list_file); se quest'ultimo è specificato, ha la precedenza sul primo.

Funziona cercando il contenuto di ogni pagina in tutte le voci URL presenti in url_list_web o url_list_file, verificando tutte le occorrenze. Inoltre, in caso di corrispondenza e se l'opzione di configurazione check_url_api è impostata su true, Crawlector invierà una richiesta POST all'URL dell'API impostato nell'opzione di configurazione url_api, che restituisce un oggetto JSON con informazioni extra sull'URL corrispondente. Tali informazioni includono urlh_status (es., online, offline, unknown), urlh_threat (es., malware_download), urlh_tags (es., elf, Mozi) e urlh_reference (es., https://urlhaus.abuse.ch/url/1116455/). Queste informazioni saranno incluse nel file di log cl_mlog_<data_corrente><ora_corrente><(am|pm)>.csv (vedi sotto), solo se check_url_api è impostato su true. Altrimenti, il file di log includerà le colonne urlh_url (elenco di URL malevoli corrispondenti) e urlh_hit (numero di occorrenze per ogni URL malevolo corrispondente), a condizione che check_url sia impostato su true.

La funzionalità URLHaus può essere completamente disabilitata impostando l'opzione di configurazione check_url su false.

È importante notare che questa funzione potrebbe rallentare la scansione, considerando l'enorme numero di URL malevoli (~ 130 milioni di voci al momento della stesura) che devono essere controllati e il tempo necessario per ottenere informazioni extra dal server URLHaus (se l'opzione check_url_api è impostata su true).

Strutture di File e Cartelle

1. \cl_sites
   • qui è memorizzato l'elenco dei siti da visitare o analizzare.
   • supporta più file e directory.
2. \crawled
   • dove tutti gli URL analizzati/spiderati vengono salvati in un file di testo.
3. \certs
   • dove sono memorizzati tutti i certificati digitali di domini/siti (in formato .der).
4. \results
   • dove vengono salvati i siti web visitati. Questo è configurabile tramite l'opzione results_dir
5. \pg_cache
   • cache del programma per i siti che non fanno parte della funzionalità spider. Questo è configurabile tramite l'opzione cache_dir, sezione [default].
6. \cl_cache
   • cache del crawler per i siti che fanno parte della funzionalità spider. Questo è configurabile tramite l'opzione cache_dir, sezione [spider].
7. \yara_rules
   • qui sono memorizzate tutte le regole Yara. Tutte le regole presenti in questa directory verranno caricate dal motore, analizzate, validate e valutate prima dell'esecuzione.
8. cl_config.ini
   • questo file contiene tutti i parametri di configurazione che possono essere regolati per influenzare il comportamento del framework.
9. cl_mlog_<data_corrente><ora_corrente><(am|pm)>.csv
   • file di log che contiene una miriade di informazioni sui siti web visitati
   • data, ora, stato della scansione Yara, elenco delle regole Yara attivate con offset e lunghezza di ogni corrispondenza, id, URL, codice di stato HTTP, stato della connessione, intestazioni HTTP, dimensione della pagina, percorso della pagina salvata su disco e altre colonne relative ai risultati di URLHaus.
   • il nome del file è univoco per sessione.
10. cl_offl_mlog_<data_corrente><ora_corrente><(am|pm)>.csv
    • file di log che contiene informazioni sui file scansionati offline.
    • elenco delle regole Yara attivate con offset e lunghezza delle corrispondenze e percorso della pagina salvata su disco.
    • il nome del file è univoco per sessione.
11. cl_certs_<data_corrente><ora_corrente><(am|pm)>.csv
    • file di log che contiene una miriade di informazioni sui certificati digitali trovati
12. \expanded\exp_subdomain_<am|pm>.txt
    • contiene i sottodomini scoperti (parte della sezione [site])

File di Configurazione (cl_config.ini)

È necessario familiarizzare con il file di configurazione cl_config.ini prima di eseguire qualsiasi sessione. Tutte le sezioni e i parametri sono documentati nel file di configurazione stesso.

La funzionalità di scansione offline Yara è un'opzione autonoma; ciò significa che, se abilitata, Crawlector eseguirà solo questa funzionalità, indipendentemente dalle altre funzionalità abilitate. Lo stesso vale per la funzionalità di crawling per i certificati digitali di domini/siti. In ogni caso, si consiglia di disabilitare tutte le funzionalità inutilizzate nel file di configurazione.

• A seconda delle impostazioni di configurazione (log_to_file o log_to_cons), se una regola Yara fa riferimento solo agli attributi di un modulo (es., PE, ELF, Hash, ecc.), allora Crawlector mostrerà solo il nome della regola in caso di corrispondenza, escludendo i dati di offset e lunghezza.

Nota: per qualsiasi opzione che accetta un percorso, fornire sempre il percorso assoluto.

Formato del Pattern dei Siti

Per visitare/scansionare un sito web, l'elenco degli URL deve essere memorizzato in file di testo, nella directory "cl_sites".

Crawlector accetta tre tipi di URL:

1. Tipo 1: un URL per riga
   • Crawlector assegnerà un nome univoco a ogni URL, derivato dal nome host dell'URL
2. Tipo 2: un URL per riga, con un nome univoco [a-zA-Z0-9_-]{1,128} = <url>
3. Tipo 3: per la funzionalità spider, viene utilizzato un formato univoco. Un URL per riga è il seguente:

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

Ad esempio,

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

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

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

depth, total e sleep possono anche essere sostituiti con le loro versioni abbreviate d, t e s, rispettivamente.

• depth: lo spider supporta un approfondimento fino a due livelli per trovare URL aggiuntivi (questa è una decisione di progettazione).
• Un valore di 0 indica una profondità di livello 1, con il valore dopo "->" ignorato.
• Una profondità di livello 1 è controllata dal parametro total. Quindi, prima, lo spider cerca di trovare quanti più URL aggiuntivi possibile dall'URL specificato.
• Il valore dopo "->" rappresenta il numero massimo di URL da spiderare per ciascuno degli URL trovati (in base al valore del parametro total).
• Un valore di 1 indica una profondità di livello 2, con il valore dopo "->" che rappresenta il numero massimo di URL da trovare, per ogni URL trovato in base al parametro total. Per chiarimenti, come mostrato nell'esempio sopra, prima, lo spider cercherà 10 URL (come specificato nel parametro total), e poi, ciascuno di quegli URL trovati verrà spiderato fino a un massimo di 3 URL; quindi, nello scenario migliore, otterremmo 40 (10 + (10*3)) URL.
• Il parametro sleep accetta un valore intero che rappresenta il numero di millisecondi di attesa tra ogni richiesta HTTP.

Nota 1: un URL di Tipo 3 può essere trasformato in un URL di Tipo 1 impostando il parametro di configurazione live_crawler su false nel file di configurazione, nella sezione spider.

Nota 2: le righe vuote e le righe che iniziano con ";", "#" o "//" vengono ignorate.

La Funzionalità Spider

La funzionalità spider è ciò che dà a Crawlector la capacità di trovare link aggiuntivi nella pagina di destinazione. Lo Spider supporta le seguenti caratteristiche:

• Il dominio deve essere di Tipo 3 affinché la funzionalità Spider funzioni
• È possibile specificare un elenco di pattern con wildcard (delimitati da pipe) per evitare che lo spider segua URL corrispondenti tramite l'opzione di configurazione exclude_url. Ad esempio, *.zip|*.exe|*.rar|*.zip|*.7z|*.pdf|.*bat|*.db
• È possibile specificare un elenco di pattern con wildcard (delimitati da pipe) per spider solo gli URL che corrispondono al pattern tramite l'opzione di configurazione include_url. Ad esempio, */checkout/*|*/products/*
• È possibile escludere gli URL HTTPS tramite l'opzione di configurazione exclude_https
• È possibile includere anche i link esterni/in uscita, solo per la pagina principale, tramite l'opzione di configurazione add_ext_links. Questa funzione rispetta le opzioni di configurazione exclude_url e include_url.
• È possibile includere solo i link esterni/in uscita della pagina principale, escludendo tutti gli altri URL, tramite l'opzione di configurazione ext_links_only. Questa funzione rispetta le opzioni di configurazione e .

Tipi di ID

Nella release 2.0, i tipi di ID sono assegnati esplicitamente aggiungendo uno dei seguenti tipi all'ID stesso:

Il fatto che ogni id porti con sé il suo tipo rende più facile navigare e filtrare i risultati. Inoltre, questo viene utilizzato internamente per vari motivi.

Funzionalità di Ranking del Sito

• Serve per verificare il ranking del sito web
• Si fornisce un file con un elenco di siti web, con il loro ranking, in formato file CSV
• I servizi che forniscono elenchi di ranking di siti web includono Alexa top-1m (interrotto a maggio 2022), Cisco Umbrella, Majestic, Quantcast, Farsight e Tranco, tra gli altri
• Formato file CSV (solo 2 colonne): la prima colonna contiene il ranking, la seconda colonna contiene il nome del dominio
• Se una cella contiene dati tra virgolette, verranno automaticamente rimossi
• Le interruzioni di riga non sono consentite nel testo tra virgolette
• Gli spazi iniziali e finali vengono rimossi dalle celle lette
• Le righe vuote e quelle di commento vengono saltate
• La sezione site_ranking nel file di configurazione fornisce alcune opzioni per modificare il modo in cui il file CSV deve essere letto
• Le prestazioni di questa query dipendono dal numero di record nel file CSV
• Crawlector confronta ogni voce nel file CSV con il dominio in esame, e non viceversa
• Viene confrontato solo il dominio registrato/livello pagamento

Trovare TLD e Sottodomini - Sezione [site]

• La sezione site fornisce la capacità di espandere un determinato sito tentando di trovare tutti i top-level domain (TLD) e/o sottodomini disponibili per lo stesso dominio. Se trovati, i nuovi TLD/sottodomini verranno controllati come qualsiasi altro dominio
• Questa funzione utilizza le API Omnisint Labs (https://omnisint.io/) e RapidAPI
• L'API Omnisint Labs restituisce sottodomini e TLD, mentre RapidAPI restituisce solo sottodomini (l'API Omnisint Labs non è disponibile dal 10 marzo 2023; tuttavia, l'implementazione è ancora disponibile nel caso il sito torni attivo)
• Per RapidAPI, è necessaria una chiave API "Domains records" valida che può essere richiesta da RapidAPI e inserita nella chiave rapid_api_key nel file di configurazione
• Con find_tlds abilitato, oltre ai risultati dei tld dell'API Omnisint Labs, il framework tenta di trovare altri domini attivi/registrati esaminando ogni voce tld, sia nel file tlds_file che nell'URL tlds_url
• Se tlds_url è impostato, deve puntare a un URL che ospita i tld, ciascuno su una nuova riga (le righe che iniziano con uno dei caratteri ';', '#' o '//' vengono ignorate)
• tlds_file, contiene il nome del file con l'elenco dei tld (come per tlds_url; è presente solo il tld, escluso il '.', ad es., "com", "org")
• Se tlds_file è impostato, ha la precedenza su

Funzionalità di Reindirizzamento

La funzionalità di reindirizzamento degli URL nelle release precedenti era difettosa. Questa release fornisce una riscrittura completa della funzionalità di reindirizzamento, con un alto grado di parametrizzazione per controllarne il funzionamento. Nella versione 2.0, il reindirizzamento ha una sezione dedicata nel file di configurazione, denominata [redirect]. L'intera funzionalità di reindirizzamento può essere attivata/disattivata tramite l'opzione follow_redir, nella sezione [default].

La funzione di reindirizzamento controlla i codici di stato della risposta HTTP: 301, 302, 303, 307 e 308. In caso di corrispondenza, Crawlector analizzerà l'intestazione Location per l'URL di reindirizzamento, considerando sia gli URL assoluti che quelli relativi. La funzionalità di reindirizzamento in Crawlector è stata progettata per prestazioni e agilità. La sezione [redirect] fornisce il seguente elenco di opzioni:

[redirect]

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

L'opzione depth accetta uno dei valori, last o all. Controlla quali URL di reindirizzamento trovati visitare, a seconda che l'opzione visit sia abilitata o meno. all serve per visitare tutti gli URL di reindirizzamento trovati. last serve per visitare l'ultimo URL di reindirizzamento. La visita di questi URL avviene nella stessa sessione corrente. Tieni presente che, indipendentemente dal valore di depth, Crawlector registrerà l'elenco di tutti i reindirizzamenti trovati agli URL, insieme al numero totale, in forma assoluta. Verranno scritti nel file CSV cl_mlog, nelle colonne redirect_urls e redirect_total.

L'opzione max_redirect imposta un limite massimo al numero totale di reindirizzamenti di URL da scoprire.

L'opzione skip_similar è meglio spiegata con il seguente esempio:

Supponiamo che l'URL originale fornito a Crawlector da analizzare sia "https://www.mfa.gov.law" e uno degli url di reindirizzamento trovati sia "https://mfa.gov.law/". Come puoi notare, l'unica differenza è la barra finale nell'URL. Questi due URL sono identici e il server risponderà con la stessa pagina. Se l'opzione visit è impostata su true, Crawlector analizzerà entrambi gli URL, sprecando risorse ed eseguendo la stessa attività due volte. Questo potrebbe non essere un problema per 1 o 2 URL, ma se hai migliaia di URL da analizzare e l'opzione visit è abilitata, le probabilità che più della metà di essi abbiano un URL scoperto di questo tipo sono molto alte, nel qual caso diventa un problema urgente da considerare. Pertanto, impostare l'opzione skip_similar su true aiuterà a risolvere questo problema saltando la visita di URL simili. Oltre allo scenario della barra finale, l'opzione skip_similar tiene conto anche dei seguenti due scenari: se l'URL di reindirizzamento differisce solo per uno o entrambi i prefissi "https://" e "www.".

Deep Object Extraction (DOE)

Una delle principali aggiunte alla release 2.0 è la capacità di estrarre diversi tipi di oggetti dalla pagina, salvarli su disco, scansionarli con Yara e URLHaus e salvare i risultati nel file CSV. Per abilitare questa funzionalità, impostare l'opzione extract_obj su true, nella sezione [page].L'implementazione della funzionalità di estrazione profonda degli oggetti funziona creando un file di archivio web MHT dalla pagina web, includendo script esterni, immagini e file CSS. Tutti i file incorporati verranno estratti nel percorso specificato dall'opzione obj_dir (percorso: obj_dir/objects/), dove ogni file verrà scansionato. L'implementazione non va confusa con la funzionalità del browser headless. DOE è diverso e non comporta il caricamento della pagina per recuperare tutti gli URL richiesti dinamicamente. Pertanto, ha i suoi limiti.

Tutti gli oggetti estratti avranno alcuni dei loro metadati scritti nel file CSV. Cose da tenere a mente durante la lettura del file CSV: l'ID del dominio con l'oggetto estratto ha un formato unico, come segue, <domain_id>_<type>_p_obj_<counter> (ad esempio, _mfa_gov_cef40bc5-ba6a-41_t1_p_obj_0_). E l'url avrà il seguente formato, <url>__<object_filename> (ad esempio, https://www.mfa.gov.law\_\_bilmur.min.js).

Se l'opzione delete_obj è impostata su true, tutti gli oggetti estratti che non vengono rilevati da Yara vengono eliminati dal disco. Se l'opzione log_all_objs è impostata su true, registra tutti i metadati degli oggetti estratti nello stesso file CSV cl_mlog. Se l'opzione check_urlhaus nella sezione [page] è impostata su true, ogni oggetto estratto verrà scansionato da URLHaus. Nota che le opzioni di questa opzione sono ereditate dalla sezione [urlhaus].

Nota: se il dominio sottoposto a crawling reindirizza a un altro dominio, l'ultimo reindirizzamento all'URL deve essere passato a DOE per funzionare. Inoltre, il dominio deve iniziare con "HTTP(S)://" affinché DOE funzioni.

Notifica di avviso Slack

A volte, potresti voler eseguire sessioni di Crawlector che potrebbero richiedere giorni per essere completate, ad esempio eseguendo il crawling dei primi 1 milione di siti web Alexa, e per uno scenario del genere, hai bisogno di un modo per monitorare il funzionamento e l'avanzamento del framework da remoto. Pertanto, nella versione 2.1, ho aggiunto la funzionalità di notifica di avviso Slack per fornire un meccanismo per monitorare l'esecuzione di Crawlector in tempo reale, inviando gli avvisi di Yara, gli eventi std::exit() e gli avvisi e gli errori di processo, a un canale Slack di tua scelta. In aggiunta a ciò, Crawlector installa un handler della console nel tentativo di monitorare determinati tipi di eventi, inclusi ctrl_c, ctrl_close, ctrl_break, ctrl_logoff e ctrl_shutdown. È importante tenere a mente che Crawlector non modifica/altera il comportamento dell'handler predefinito; si limita a segnalare al canale Slack la ricezione di uno qualsiasi degli eventi elencati. Questo potrebbe essere esteso in futuro per includere altri tipi di eventi.

Questa funzionalità utilizza l'API REST di Slack e per l'autenticazione con il server utilizza OAuth 2.0. Avrai bisogno di un token API Slack per usarlo e di un canale configurato con le autorizzazioni corrette. Questa funzionalità invia solo messaggi al canale Slack e non riceve né elabora alcun messaggio in arrivo.

La sezione [slack_alert] fornisce il seguente elenco di opzioni:

[slack_alert]

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

Per disabilitare o abilitare questa funzionalità, basta impostare l'opzione alert su true o false. Inoltre, devi specificare api_token con un nome channel.

Nota-1: nella fase di inizializzazione di Crawlector, verifica se il token di autenticazione fornito è valido o meno, o se il canale è impostato e in caso di fallimento, questa funzionalità viene disabilitata automaticamente.

Tutti gli avvisi segnalati al canale Slack vengono segnalati con il nome utente Crawlector v<numero_versione>, ad esempio, Crawlector v2.1. L'utente ha l'icona di una ragnatela. Inoltre, tutti gli avvisi sono raggruppati in thread, il che significa che tutti gli avvisi successivi al primo messaggio di avvio vengono pubblicati come risposte. Questa è stata una decisione progettuale e aiuta nel caso in cui tu stia eseguendo più sessioni contemporaneamente, tutte che segnalano allo stesso canale. Alcuni avvisi utilizzano il linguaggio di markup markdown per la formattazione.

Quando il processo termina con successo e sta per uscire, pubblica il seguente messaggio:

Crawlector ha terminato e si sta arrestando correttamente

Nota-2: il limite di velocità di Slack sull'API di pubblicazione dei messaggi è di un messaggio al secondo, con un margine per alcuni picchi. Crawlector non mette in coda i messaggi per gestire più pubblicazioni al secondo. Questo potrebbe cambiare in futuro se necessario; tuttavia, l'opzione sleep consente al processo di attendere per un periodo di tempo specificato dopo ogni messaggio pubblicato con successo.

Controllo remoto Slack

Con la versione 2.2 (nome in codice Hallstatt), introduco la possibilità di controllare da remoto Crawlector tramite un insieme selezionato di comandi di controllo appositamente progettati. Il motivo per cui introduco questa funzionalità è monitorare e controllare determinati comportamenti di sessioni che dovrebbero durare ore o giorni. Ad esempio, potresti voler attivare/disattivare la funzionalità di avviso Slack, terminare Crawlector e caricare un file di configurazione, tra gli altri.

Questa funzionalità utilizza l'API REST di Slack e per l'autenticazione con il server utilizza OAuth 2.0. Avrai bisogno di un token API Slack per usarlo e di un canale configurato con le autorizzazioni corrette. Il token API è lo stesso utilizzato nella sezione [slack_alert], opzione api_token.

La sezione [slack_alert] fornisce il seguente elenco aggiuntivo di opzioni per la funzionalità di controllo remoto:

[slack_alert] (opzioni di controllo)

• control = true ; (t: bool)
• ctrl_channel = ; (t: string) deve essere l'ID del canale e non il nome del canale
• ctrl_sleep = ; (t: uint32_t) in millisecondi

Per disabilitare o abilitare questa funzionalità, basta impostare l'opzione control su true o false. Il nome ctrl_channel deve essere l'ID del canale e non il nome del canale. Puoi ottenerlo facendo clic con il pulsante destro del mouse sul nome del canale -> Visualizza dettagli canale -> Scorri verso il basso fino alla fine della finestra e vedrai il campo ID canale: <channel_id>.

L'opzione ctrl_sleep determina la frequenza con cui chiamare il canale di controllo specificato nell'opzione ctrl_channel per recuperare i comandi di controllo. Puoi anche aggiornare questa opzione tramite il comando di controllo cl_update_delay <tempo_in_ms>.

L'elenco dei comandi di controllo supportati è il seguente:

Nota-1: nella fase di inizializzazione di Crawlector, verifica se il token di autenticazione fornito è valido o meno, o se il canale è impostato e in caso di fallimento, questa funzionalità viene disabilitata automaticamente.

Se questa funzionalità è abilitata e una volta superata la convalida del token API, Crawlector invia il messaggio "Crawlector è pronto per ricevere comandi di controllo. Digita il comando cl_help per un elenco dei comandi di controllo supportati." al ctrl_channel designato.

Tutte le risposte a un dato comando di controllo sono raggruppate in thread. Inoltre, i comandi di controllo vengono letti su base sessione per sessione, dal momento in cui una sessione viene avviata.

Nota-2: il limite di velocità di Slack sull'API di recupero (cronologia della conversazione) dei messaggi è di una richiesta al secondo, con un margine per alcuni picchi. Quindi, se l'opzione ctrl_sleep è impostata su un valore inferiore a un secondo o superiore a un secondo, Crawlector mette in coda i messaggi per gestire più comandi di controllo al secondo e li esegue nell'ordine ricevuto.

Server DNS

Con la versione 2.3 (nome in codice Monaco), viene introdotta la possibilità di specificare un elenco di server DNS per tutte le query DNS e le risoluzioni DNS-in-IP tentate da Crawlector con un alto livello di controllo. Questo è importante nel caso in cui stai eseguendo il crawling di siti web bloccati o dannosi. Questa funzionalità si applica a ogni funzione in Crawlector in cui viene effettuata una query DNS o una richiesta DNS-in-IP. Ancora più importante, fornisce la possibilità di eseguire DNS su TLS per ogni server di nomi che lo supporta.

La sezione [dns_ns] fornisce il seguente elenco di opzioni per amministrare questa funzionalità:

[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 o force)
• keep_default = false ; (t: bool)
• conn_time_out = 3000 ; (t: uint32_t) in millisecondi (0 per attendere indefinitamente)

L'opzione name_servers accetta un elenco parametrizzato di server DNS da utilizzare, separati da virgole. Il valore di questa opzione ha il formato: <indirizzo_IPv4>(<opzione_tls>) dove <opzione_tls> assume uno dei valori "d_tls" o "e_tls". Le opzioni "d_tls" o "e_tls" indicano rispettivamente se il server di nomi in questione supporta o meno DNS su TLS. Questa opzione verrà applicata in base al valore impostato per l'opzione dns_tls. Ad esempio, la voce 8.8.8.8(e_tls) indica di utilizzare il server DNS Google 8.8.8.8 con supporto TLS, mentre la voce 12.13.14.15(d_tls) indica di utilizzare il server DNS 12.13.14.15 senza supporto TLS.

L'opzione dns_tls specifica il livello richiesto di applicazione di TLS. Questa opzione assume uno dei valori "yes" "no" o "force".

• yes
  • Verranno tentati prima i server DNS con supporto TLS e, se non viene trovato alcun NS con supporto TLS, verrà tentata la risoluzione UDP/TCP.
• no
  • nessun supporto TLS (non utilizzare server DNS con supporto TLS)
• force
  • verranno utilizzati solo server DNS con supporto TLS e qualsiasi query DNS avviata da Crawlector utilizzerà DoT (DNS su TLS).

L'opzione keep_default serve per aggiungere o meno i server di nomi predefiniti all'elenco dei server di nomi. Si presuppone che un server di nomi predefinito non supporti TLS.

L'opzione conn_time_out specifica il tempo in millisecondi da attendere per una risposta a una query DNS.

L'opzione enable attiva o disattiva questa funzionalità.

Miglioramenti vari nella versione 2.0

• Aggiunte le opzioni da riga di comando "-v" e "-c". L'opzione "-v" serve per stampare le informazioni sulla versione nella console. L'opzione "-c" serve per leggere un file di configurazione diverso da quello predefinito "cl_config.ini".
• Varie ottimizzazioni del codice e miglioramenti minori
• Per ogni dominio letto (non con un sottodominio), Crawlector anteporrà "www." a ogni voce di sito letta, se non esiste già. Ad esempio, nel caso di una query di enumerazione dei sottodomini di RapidAPI, il dominio sottoposto a query deve iniziare con "www.".
• Aggiunte le opzioni clear_dns e upg_2_https alla sezione [default]. La prima cancella la cache DNS del nome host all'indirizzo IP, e la seconda aggiorna ogni sito a HTTPS anteponendo "https://" allo stesso. Analogamente, l'opzione tld_upgrd_2_https è stata aggiunta alla sezione [site], per aggiornare i domini attivi con diversi TLD a https.
• Aggiunte le opzioni rapid_api_weeks e rapid_api_limit alla sezione [site] per configurare la richiesta API a RapidAPI. Entrambe le opzioni sono opzionali. La prima specifica il numero di settimane da interrogare dal DB, mentre la seconda specifica il numero di sottodomini da restituire per sito.
• Nella versione 2.0, puoi specificare una directory cache diversa per le sezioni [spider] e [default], tramite l'opzione cache_dir.
• Molte opzioni sono state aggiunte alla sezione page nella versione 2.0, inclusi:
• L'opzione whois_info recupera le informazioni whois del dominio, tra cui registrar, registered_on, expires_on e updated_on. Questi dati vengono estratti da https://www.whois.com/whois/. I dati vengono salvati nel file CSV cl_mlog.
• L'opzione page_title salva il titolo della pagina nel file CSV cl_mlog.
• L'opzione results_dir è stata aggiunta per fornire la possibilità di salvare le pagine in un percorso diverso. Se non impostata, la cartella "results" verrà creata nella stessa directory di Crawlector.
• Aggiornato il motore Yara alla versione 4.3.2

Considerazioni progettuali

• Una pagina URL viene recuperata inviando una richiesta GET al server, leggendo il corpo della risposta del server e passandolo al motore Yara per il rilevamento.
• Alcuni attributi della richiesta GET sono definiti nella sezione [default] del file di configurazione, incluse le intestazioni User-Agent e Referer e il timeout di connessione, tra le altre opzioni.
• Sebbene Crawlector registri i dati di una sessione in un file CSV, si consiglia di convertirlo in un file SQL per migliori prestazioni, manipolazione e recupero dei dati. Ciò diventa evidente quando si esegue il crawling di migliaia di domini.
• I domini/URL ripetuti in cl_sites sono consentiti.

Limitazioni

• Monothread
• Rilevamento statico (nessuna valutazione dinamica del contenuto di una determinata pagina). Si prega di controllare invece la funzionalità DOE.
• Nessun supporto per browser headless, ancora!

Librerie di terze parti utilizzate

• Chilkat: libreria per lo spidering di siti web, comunicazioni HTTP, hashing, parsing JSON e compressione di file (ZIP), tra gli altri
• Yara: per la scansione delle regole (v4.5.4)
• CrossGuid: per la generazione di GUID/UUID
• Inih: per il parsing del file di configurazione
• Rapidcsv: per il parsing dei file CSV
• Color Console: per la colorazione della console
• TLSH (Trend Micro Locality Sensitive Hash) (v4.8.2)

Contribuire

Aperto a pull request e segnalazioni di problemi. Commenti e suggerimenti sono molto apprezzati.

Autore

Mohamad Mokbel (@MFMokbel)