Verifica degli IoC tramite hashr e le group policy

Gli Indicatori di Compromissione (IoC) costituiscono un elemento chiave nei processi di threat detection e incident response. Tra le varie tipologie di IoC, gli hash dei file (MD5, SHA-1, SHA-256) sono particolarmente rilevanti in quanto permettono di identificare in maniera univoca un artefatto digitale e di confrontarlo con database di threat intelligence o con baseline interne. La loro validazione è essenziale per distinguere rapidamente file legittimi da file legati ad attività malevole, riducendo il rischio di falsi negativi e facilitando l’automazione delle attività di triage.

Figura 1: Indicatori di Compromissione basati su file hash

La verifica degli Indicatori di Compromissione basati su hash può essere eseguita tramite hashr, uno strumento sviluppato dal CERT-AGID (Computer Security Incident Response Team AGID) che in forza degli articoli 14bis e 51 del D. Lgs 5 marzo 2005 n. 82 (CAD) supporta AGID su tutti i temi riguardanti trasversalmente gli aspetti di sicurezza informatica relativi ai progetti interni ed esterni a cui AGID partecipa in maniera diretta o indiretta.

Grazie alla sua leggerezza e all’approccio “command-line oriented”, hashr può essere facilmente integrato in workflow automatizzati di sicurezza e in strumenti di gestione centralizzata, costituendo un tassello concreto nella costruzione di un processo di threat hunting e incident response più efficace.

In questo articolo vedremo come verificare gli IoC basati su hash tramite il tool a riga di comando hashr e come sfruttare script e Group Policy di Windows per automatizzare e centralizzare il rilevamento delle impronte digitali di attività malevole su tutti i computer della rete.

Attraverso questa sinergia, è possibile trasformare una strategia di sicurezza da puramente difensiva a proattiva, fornendo una difesa robusta contro le minacce informatiche più insidiose.

Sebbene il feed IoC rilasciato dal CERT-AGID sia disponibile solo per le Pubbliche Amministrazioni, le indicazioni fornite in questo articolo possono essere utili anche essere applicate in infrastrutture di aziende private.

Indicatori di Compromissione (IoC) forniti dal CERT-AGID

Tra i servizi offerti dal CERT-AGID (Computer Emergency Response Team dell’Agenzia per l’Italia Digitale) vi è il Feed IoC, uno strumento che fornisce indicatori di compromissione per aiutare le PA a prevenire e contrastare minacce come malware e phishing.

Il Feed IoC del CERT-AGID è una lista dinamica e aggiornata di informazioni relative a campagne malevole rilevate nello scenario italiano. Questi IoC sono il risultato di un’attività di monitoraggio e analisi costante svolta dal team, che raccoglie dati da fonti OSINT (Open Source Intelligence) e CLOSINT (Closed Source Intelligence).

L’adesione al Feed è riservata alle PA e avviene tramite un processo di accreditamento che richiede la compilazione di un apposito modulo. Una volta accreditata, l’amministrazione riceve un token di accesso che le permette di interrogare il Feed e integrarlo nei propri sistemi di sicurezza, come firewall, estensioni del browser o altri strumenti di rilevamento.

Il Feed include diverse tipologie di indicatori, tra cui:

  • Hash di file: identificativi univoci di file noti come dannosi o legati ad attività malevole.
    (ad esempio tramite <URL_ricevuto>&type=hash)
  • Indirizzi IP: indirizzi noti per essere associati a server di comando e controllo (C2) o a infrastrutture di attacco.
    (ad esempio tramite <URL_ricevuto>&type=ip)
  • Domini: domini noti per essere associati a campagne malevole.
    (ad esempio tramite <URL_ricevuto>&type=domain)
  • URL: indirizzi web utilizzati per veicolare malware o per campagne di phishing.
    (ad esempio tramite <URL_ricevuto>&type=url)

Le Pubbliche Amministrazioni interessate possono esprimere la volontà di aderire al flusso di Indicatori di compromissione (Feed IoC) del CERT-AGID compilando il modulo di accreditamento che dovrà essere firmato e inviato per e-mail al CERT-AGID. Nel modulo di accreditamento occorre specificare i riferimenti della persona tecnica e l’elenco (max 20) di indirizzi IPv4 pubblici da abilitare per l’accesso al Feed IoC.

Una volta approvata la richiesta di accreditamento, l’Amministrazione richiedente riceverà due URL personali per l’accesso al servizio. L’URL indicato con la dicitura “Per firewall” può essere usato nella configurazione del firewall, mentre l’URL indicato con la dicitura “Per AdBlocker” può essere usato con estensioni browser content blocker tipo uBlock (Origin) rilasciato come open source e disponibile gratuitamente sia per Chrome che per Edge.

Entrambi gli URL contengono un Token di accesso personale e possono essere utilizzati solo tramite la connessione Internet dell’Amministrazione autorizzata (ovvero dagli indirizzi IPv4 pubblici abilitati), in caso contrario se si accede agli URL tramite un browser invece di ottenere una lista di indicatori viene restituito un codice di errore 404 o una pagina bianca.

Il servizio di pubblicazione del Feed IoC da parte del CERT-AGID Il servizio è gratuito, ma è rivolto esclusivamente alle Pubbliche Amministrazioni. Non possono essere evase richieste di adesione proveniente da privati o società in house. Per la precisione le società in house non possono essere accreditate, ma la richiesta deve essere effettuata dal referente dell’amministrazione interessata tramite email istituzionale. Ovviamente il servizio non può essere in alcun modo riutilizzato per fini commerciali ed eventuali utilizzi impropri comportano l’immediata revoca della fruizione del servizio.

Per indicazioni tecniche su come configurare l’utilizzo del Feed IoC di CERT-AGID su firewall, ClamAV, uBlock (Origin) e simili e per informazioni su come le PA possono richiedere l’accesso al Feed IoC si veda la pagina Indicatori di compromissione per la protezione della Pubblica Amministrazione – CERT-AGID e la sezione L’importanza degli IoC e procedura di accreditamento del Webinar IoC e Hashr: rafforzare la sicurezza informatica delle PA – Webinar.

Identificazione di file sospetti tramite il tool hashr rilasciato dal CERT-AGID

Il CERT-AGID ha sviluppato hashr, un tool in Python specificamente progettato per confrontare gli hash dei file, MD5, SHA1 o SHA256, presenti su un sistema con una lista di hash noti come ad esempio gli hash presenti nel Feed IoC fornito dal CERT-AGID.

Il tool risulta particolarmente utile per indagini di sicurezza informatica, analisi forense e verifica dell’integrità dei file su filesystem di grandi dimensioni. A tal proposito si ricordi che le Misure minime di sicurezza ICT per le pubbliche amministrazioni emanate dall’AgID prevedono la verifica dell’integrità dei file nelle seguenti misure:

  • ABSC 2.1.1: Utilizzare strumenti di verifica dell’integrità dei file per verificare che le applicazioni nella “whitelist” non siano state modificate. (Misura classificata con livello di attuazione Alto, ovvero deve essere adottata dalle PA maggiormente esposte a rischi, per la criticità delle informazioni trattate o dei servizi erogati, ma tale misure deve anche vista come obiettivo di miglioramento da parte di tutte le altre PA).
  • ABSC 3.5.1: Utilizzare strumenti di verifica dell’integrità dei file per assicurare che i file critici del sistema (compresi eseguibili di sistema e delle applicazioni sensibili, librerie e configurazioni) non siano stati alterati. (Misura classificata con livello di attuazione Standard, ovvero il livello, superiore al livello minimo, che ogni PA deve considerare come base di riferimento in termini di sicurezza e rappresenta la maggior parte delle realtà della PA italiana).

(Per approfondimenti si veda il mio articolo dedicato alle Misure minime di sicurezza ICT per le Pubbliche Amministrazioni).

La versione attualmente disponibile di hashr è la 2.0.1 rilasciata l’8 ottobre 2024 e prevede le seguenti funzionalità:

  • Supporto per le seguenti tipologie di hash: MD5, SHA1 e SHA256.
    Tramite il parametro –hash è possibile specificare il tipo di hash da utilizzare (md5, sha1, sha256) oppure specificare all (valore predefinito) per prendere in considerazione tutti e tre i tipi di hash.
  • Logging dei file scartati a causa delle dimensioni superiori a quella consentita o a causa di problemi di accesso dovuti a permessi o errori.
    Tramite il parametro –log è possibile personalizzare il percorso del file di log, per impostazione predefinita viene generato un file di log denominato log_{timestamp}.log.
  • Possibilità di salvataggio dei risultati su file per analisi successive.
    Tramite il parametro –output è possibile personalizzare il percorso del file di testo su cui salvare i risultati, inoltre tramite i seguenti parametri è possibile impostare un formato: –csv (Comma-Separated Values), –tsv (Tab-Separated Values), –json (JavaScript Object Notation)
  • Utilizzo degli IoC basati su hash del Feed IoC di CERT-AGID, ma è possibile anche utilizzare file provenienti da altri Feed IoC.
    Tramite il parametro —hashlist è possibile specificare il path o l’URL del file di testo contenente la lista di hash; in alternativa è possibile specificare un token per prelevare gli hash dal Feed IoC fornito dal CERT-AGID. Nel caso in cui tramite il parametro —hashlist venga specificato un URL o un token, gli hash scaricati sono salvati nel file hashlist.txt, che può essere riutilizzato per successive scansioni. hashr ricerca all’interno del Feed IoC specificato come file o URL le stringhe che formalmente possono essere un hash (cerca sequenze di caratteri alfanumerici esadecimali di lunghezza valida) quindi è in grato di interpretare i vari formati di un file di testo.
  • Possibilità di filtrare i file in base alle dimensioni per ottimizzare le prestazioni.
    Tramite il parametro –maxsize è possibile impostare la dimensione massima dei file da elaborare (il valore predefinito è 1 GB).

hashr è disponibile come script Python (hashr.py) e quindi può essere distribuito ovunque sia disponibile Python3.

In alternativa il tool è disponibile anche in versione eseguibile per sistemi Windows (hashr.exe) che consente di eseguire hashr senza dover installare Python o configurare dipendenze aggiuntive semplificandone l’utilizzo in ambiente Windows. Dal momento che hashr.exe è stato generato a partire da hashr.py tramite PyInstaller tutte le opzioni della versione Python sono disponibili anche nella versione Windows.

Di seguito un esempio di come utilizzare hashr.exe per scansionare i file nel volume di sistema di Windows confrontandoli con gli hash presenti in hashlist.txt e impostando una dimensione massima dei file da esaminare di 500MB, un file di output output.txt ed un file di log hashr.log:

hashr.exe –rootdir %SystemDrive%\ –hashlist hashlist.txt –maxsize 500MB –output out.txt –log hashr.log

Prima di eseguire hashr si tenga conto delle seguenti:

  • potrebbe essere opportuno eseguire il tool con privilegi amministrativi per poter scansionare anche file non accessibili o leggibili da utenti standard;
  • se eseguito su directory contenenti molti file e cartelle, il tool potrebbe impiegare diversi minuti nella fase iniziale di scansione;
  • il tool, ed in particolare la versione eseguibile per Windows, potrebbe essere rilevato come malevolo da antivirus o altri strumenti anti-malware, occorre quindi verificare la configurazione degli strumenti di sicurezza installati sui computer in cui hashr viene eseguito (l’analisi su VirusTotal alla data di pubblicazione dell’articolo ha indicato che SecureAge, Skyhigh e SentinelOne lo rilevano come malevolo e una delle cause è il rilevamento di “Python Core” in un processo non-Python);
  • dal monento che hashr fa accesso ai file per calcolare l’hash causando l’analisi dei file da parte dell’antivirus con la conseguenza di aumentare l’utilizzo del disco, per ovviare è possibile configura l’esclusione per hashr, tale comportamento, però, potrebbe essere sfruttato per eseguire di fatto, oltre ad un esame degli IoC, anche una scansione antivirus su tutti i file analizzati se questo non ha impatti importanti sull’usabilità del sistema o se l’attività viene schedulata in una fascia oraria opportuna;
  • Si tenga presente che se eseguito su directory contenenti molti file e cartelle il calcolo dell’hash implicherà un accesso ai file con conseguente intervento del software antivirus e quindi un aumento dell’utilizzo del disco e del processore, va quindi valutata la schedulazione dell’esecuzione del tool in fascie orarie opportune per non limitare la produttività degli utenti e l’esecuzione del tool con priorità inferiore a Normal.

Ovviamente l’utilizzo di hashr in combinazione con il Feed IoC del CERT-AGID offre un semplice metodo per analizzare i propri sistemi per rilevare file sospetti relativi a campagne malevole rilevate nello scenario italiano. hashr infatti può essere uno strumento aggiuntivo a soluzioni Endpoint Protection, EDR (Endpoint Detection and Response) e XDR (eXtended Detection and Response).

Gli hash dei file forniti dai Feed IoC, infatti, non sono sempre relativi a file malevoli, ma anche a file che indicano attività di preparazione all’attacco tramite l’installazione o la consegna di software in apparenza legittimi e quindi non segnalati da soluzioni di Endpoint Security. A riguardo si veda ad esempio Falsa patch per firma digitale diffonde malware, una delle campagne segnalate dal CERT-AGID, in cui viene appunto descritto come non sia stato identificato il malware o il payload finale in quanto gli attori malevoli attendono il momento più opportuno per rilasciarlo.

Sebbene dell’infrastruttura venga implementato l’uso di Feed IoC sui firewall il controllo pianificato degli hash è comunque opportuno per almeno due buone ragioni.

Una prima ragione è che sebbene i Feed IoC vengano aggiornati velocemente, compreso quello del CERT-AGID, sono comunque necessarie alcune ore affinché la campagna malevola venga rilevata e analizzata in modo da poter individuare gli opportuni IoC. Di conseguenza prima che il firewall sia in grado di bloccare l’accesso agli IP e dominii malevoli appartenenti alla campagna alcuni utenti potrebbero esserne stati vittima e per rilevare tale situazione è necessario l’analisi degli hash.

Un’altra ragione è che l’utente potrebbe aver aperto una mail malevola mentre non era connesso alla rete aziendale localmente o tramite VPN e di conseguenza il firewall non poteva bloccare gli accessi a IP o dominii malevoli specificati dagli IoC. Anche in questo caso alcuni utenti potrebbero esserne stati vittima della campagna malevola e per rilevare tale situazione è necessario l’analisi degli hash.

La possibilità di poter usare con hashr anche Feed IoC diversi da quello del CERT-AGID inoltre lo rende uno strumento utile anche per infrastrutture private, inoltre si tenga conto che il CERT-AGID in caso di campagne malevole rilevanti nello scenario italiano pubblica specifici avvisi in cui normalmente vengono resi disponibili gli IoC in formato Json contenti IP, dominii e hash dei file relativi che possono essere passati ad hashr per l’analisi dei file. A titolo di esempio si vedano i seguenti avvisi Falsa patch per firma digitale diffonde malware e Formbook diffuso via macro Office: nel mirino aziende coinvolte in gare e progetti.

Di seguito alcuni siti in cui è possibile trovare Feed IoC utilizzabili liberamente da cui è possibile ricavare hash di file correlati a campagne malevole, si noti che le fonti sono internazionali e quindi generati sulla base di campagne che potrebbero non riguardare lo scenario italiano, al contrario del Feed IoC del CERT-AGID:

hashr è distribuito come software libero e aperto distribuito secondo i termini della European Union Public Licence (EUPL) quindi chiunque può utilizzarlo, studiarne il funzionamento, modificarlo e redistribuirlo sotto le stesse condizioni.

Anche il CISA (Cybersecurity and Infrastructure Security Agency), l’agenzia per la cybersecurity degli Stati Uniti, ha sviluppato ioc-scanner un tool simile ad hashr sempre distribuito tramite tramite script Python (ioc_scanner.py).

Automatizzare l’esecuzione di hashr tramite script

Per analizzare tramite hashr i computer dell’infrastruttura è possibile utilizzare uno script che permetta di raccogliere i dati delle analisi permettendo al reparto IT di identificare i sistemi su cui sono stati rilevati file con hash presenti negli IoC utilizzati nella scansione.

Nel mio repository su GitHub BatchScripts/hashr è possibile trovare lo script batch Run-hashr.cmd che permette appunto di automatizzare l’esecuzione di hashr generando file di log e di output che permettano di comprendere l’esito l’analisi.

Dal momento l’automazione può essere implementata tramite una semplice gestione di sottocartelle, file di output e log creati in modo da centralizzare l’analisi tramite una semplice copia ho optato per lo sviluppo di uno script batch. Per un approfondimento su quale e in quale scenario utilizzare una determinata tecnologia di scripting si veda il mio post Scripting su Windows: Batch, PowerShell, VBScript quale usare e quale abbandonare – DevAdmin Blog.

Scendendo nel dettaglio lo script Run-hashr.cmd richiede di essere eseguito in una cartella in cui sia presente anche il tool hashr.exe ed una sottocartella denominata IoC contenente i file con gli hash dei file da verificare.

Run-hashr.cmd esegue hashr.exe per ogni file di IoC presente nella cartella IoC e crea le sottocartelle denominate Out e Log dove memorizza rispettivamente i file output e i file di log.

Durante la scansione nella cartella Out verrà creato un file temporaneo denominato iocfilename.hostname dove verranno memorizzati gli eventuali IoC rilevati, tale file al termine della scansione verrà poi rinominato a seconda che siano stati rilevati file con hash contenuto nel file IoC o meno.

Nel caso in cui la scansione abbia dato esito negativo nella cartella Out sarà presente un file vuoto denominato iocfilename.hostname.IoCAbsent.yyyy-MM-dd. Se invece la scansione rileva file con hash contenuto nel file IoC verrà sarà presente un file iocfilename.hostname.IoCFound.yyyy-MM-dd.txt contenente le informazioni circa i file con un hash pari ad uno presente nel file IoC.

Se durante la scansione si verifica un errore nella cartella Out sarà presente un file vuoto denominato iocfilename.hostname.IoCError.yyyy-MM-dd. Per comprendere il motivo dell’errore è possibile analizzare il corrispondente file di log iocfilename.log e il file Run-hashr.cmd.

Figura 2: Funzionamento dello script Run-hashr.cmd

In questo modo sarà possibile identificare possibili compromissioni in base ad un rapido esame basato sui nomi dei file nella cartella Out e sfruttare la ricerca basata sul nome di file per condurre analisi per nome computer, per identificativo di un IoC o per esito della scansione.

Lo script Run-hashr.cmd per impostazione predefinita esegue l’analisi del drive di sistema, ovvero il volume identificato dalla variabile d’ambiente %SystemDrive%. Volendo è anche possibile avviare lo script specificando un path in cui eseguire l’analisi.

Utilizzo delle Group Policy per la distribuzione di hashr

Di seguito illustrerò un possibile semplice esempio di distribuzione di hashr tramite Group Policy e della relativa esecuzione sfruttando lo script Run-hashr.cmd descritto precedentemente. Inoltre, vedremo anche come raccogliere i report di analisi in una posizione centrale in modo il reparto IT possa analizzarli e se necessario intervenire sui computer su cui sono è stata rilevata la presenza di IoC.

Lo schema di riferimento su cui è bastato lo scenario dell’esempio che esamineremo è rappresentato in Figura 3.

Figura 3: Schema dello scenario di esempio per la distribuzione di hashr basata su Group Policies

Per la distribuzione dei file necessari all’esecuzione di hashr è possibile predisporre una directory condivisa su un file server che conterrà i seguenti file:

  • hashr.exe
  • I file degli IoC (ad esempio iocs-20250824.txt)
  • Run-hashr.cmd

Nell’esempio seguente verrà predisposta su di un file server denominato fs01.labtest.local una cartella GPO-Computers, su un volume diverso da quello di sistema per ragioni di sicurezza, per la memorizzazione e la distribuzione dei file tramite GPO che sarà condivisa come \\fs01.labtest.local\GPO-Computers$, con i seguenti privilegi di accesso.

Impostazioni di sicurezza della cartella GPO-Computers condivisa come GPO-Computers$
Privilegi a livello File System Privilegi a livello di condivisione
Utente/Gruppo Privilegio Utente/Gruppo Privilegio
SYSTEM Full Control Domain Computers Read
Domain Computers Read & Execute
Administrators Full Control

La distribuzione dei file può essere implementata utilizzando le Group Policies preferences computer per creare le cartelle e copiare i file necessari all’esecuzione di hashr sui client.

Nella Figura 4 è possibile vedere le impostazioni per una Group Policy preference per la creazione nel volume di sistema del client, identificabile tramite la variabile d’ambiente %SystemDrive%, di una cartella nascosta denominata hashr in cui verranno copiati i file necessari per il funzionamento di hashr.exe tramite lo script Run-hashr.cmd.

Figura 4: Group policy preference per la creazione della cartella hashr sul client

Dal momento che lo script Run-hashr.cmd verrà eseguito tramite le credenziali NT AUTHORITY\SYSTEM, per far sì che hashr possa esaminare tutti i file del sistema, occorre fare in modo che i file nella cartella non possano essere manomessi creando i presupposti per un privilege escalation.

Per tale ragione tramite Group Policy si vanno ad impostare sulla cartella hashr i criteri di accesso File System per consentire l’accesso solo all’account SYSTEM e agli utenti amministratori locali.

Cartella %SystemDrive%\hashr
Privilegi a livello File System
Utente/Gruppo Privilegio
SYSTEM Full Control
Administrators Full Control

Figura 5: Group policy per l’impostazione dei criteri di sicurezza della cartella hashr sul client

Predisposta la cartella hashr sui client sempre tramite Group Policies preferences è possibile copiare i file necessari dalla share \\fs01.labtest.local\GPO-Computers$ in cui sarà creata una sottocartella hashr contente i file necessari già descritti precedentemente, ovvero:

  • hashr.exe
  • I file degli IoC (ad esempio iocs-20250824.txt)
  • Run-hashr.cmd

In Figura 6 sono mostrate le impostazioni necessarie per le Group Policy preferences che si occupano di copiare i file necessari all’esecuzione di hashr dalla share \\fs01.labtest.local\GPO-Computers$\hashr nella cartella %SystemDrive%\hashr dei client. In particolare si noti che tramite Group Policy preferences è anche possibile copiare tutti i file iocs-*.txt nella cartella %SystemDrive%\IoC, in questo modo quando si vorrà verificare un nuovo elenco hash di file sarà sufficiente memorizzare nella share \\fs01.labtest.local\GPO-Computers$\hashr il relativo file IoC con un nome di file che rispetti il formato iocs-*.txt e questo verrà distribuito sui client e verificato alla prossima esecuzione di hashr.exe tramite lo script Run-hashr.cmd.

Figura 6: Group Policy preferences per la copia dei file necessari all’esecuzione di hashr

Utilizzo delle Group Policy per l’esecuzione di hashr

Sebbene gli approcci per l’esecuzione di hashr tramite lo script Run-hashr.cm possono essere molteplici, in questo esempio propongo un approccio basato sulla creazione di un’operazione pianifica tramite Group Policy preference.

L’operazione pianifica eseguirà lo script Run-hashr.cmd memorizzato in %Systemdrive%\hashr con i privilegi dell’account SYSTEM all’avvio del sistema.

La scelta di copiare i file necessari all’esecuzione di hashr in locale sui client si basa su voler far si che l’esecuzione possa avvenire anche in assenza di connessione di rete o di interruzione della connessione di rete.

Nella Figure 7,8,9 e 10 sono riportate le configurazioni della Group Policy preference per la creazione dell’operazione pianificata.

Nella configurazione dell’operazione pianificata ho impostato l’opzione per l’esecuzione della stessa a richiesta, funzionalità che può essere utile nel caso si intenda forzare l’avvio di hashr manualmente su determinati computer senza attendere che vengano riavviati.

Figura 7: Group Policy preference per la creazione dell’operazione pianificata

Figura 8: Impostazione dell’esecuzione dell’operazione pianificata all’avvio del sistema

Figura 9: Impostazione dell’operazione pianificata per l’esecuzione dello script Run-hashr.cmd

Figura 10: Impostazione dell’operazione pianificata per l’esecuzione a richiesta e l’avvio appena possibile in caso di mancata esecuzione

Utilizzo delle Group Policy per la gestione dei report prodotti da hashr

Per quanto riguarda la memorizzazione dei report di analisi degli IoC prodotti tramite lo script Run-hashr.cmd, che a sua volta utilizza hashr.exe, è possibile utilizzare una directory condivisa su un file server.

Nel seguente esempio verrà creata su di un file server denominato fs01.labtest.local una directory IoC, su un volume diverso da quello di sistema per ragioni di sicurezza, che sarà condivisa come \\fs01.labtest.local\IoC$, con i seguenti privilegi di accesso.

Impostazioni di sicurezza della cartella IoC condivisa come IoC$
Privilegi a livello File System Privilegi a livello di condivisione
Utente/Gruppo Privilegio Utente/Gruppo Privilegio
SYSTEM Full Control Domain Computers Modify
Domain Computers Modify
IoC Operators (*) Read & Execute Ioc Operators Read
Administrators Full Control

(*) Il gruppo IoC Operators identificherà gli utenti del reparto IT reparto IT che si occuperanno di analizzare report prodotti da hashr. La condivisione della cartella contenente i file dei report di analisi prodotti da hashr sarà accessibile in modifica solo tramite la’ccount computer dei client e in lettura solo dagli utenti IT designati evitando possibili errori di cancellazione o modifica o eventuali manomissioni.

Per memorizzare i file dei report di analisi degli IoC prodotti tramite lo script Run-hashr.cmd sulla share è possibile utilizzare delle Group Policy preferences che eseguiranno le seguenti operazioni:

  • Copia dei file %SystemDrive%\Hashr\Out\*.*.IoC* in \\fs01.labtest.local\IoC$
    (in questo modo verranno copiati solo i file relativi alle scansioni che hanno rilevato IoC e i file relativi alle scansioni che non hanno rilevato IoC, mentre i file relativi alle scansioni in corso non verranno copiati)
  • Copia dei file %SystemDrive%\Hashr\Log\*.* copiati in \\fs01.labtest.local\IoC$\Log
    (in questo modo verranno copiati tutti i log delle scansioni, tali file verranno copiati in una sottocartella Log per consentire un’analisi dei risultati di analisi basata sui nomi dei file più semplice)

Figura 11: Group Policy preferences per la copia dei file di report generati da Run-Hashr.cmd su share

Verifica del funzionamento dell’automazione di hashr tramite Group Policy

Terminata la configurazione di una GPO che contenga le Group Policy, descritte precedentemente, per la distribuzione e l’esecuzione di hashr e la raccolta dei report e dei log prodotti su una share è possibile provare ad applicarla ad un gruppo di computer di test.

Dopo aver riavviato due volte i computer su cui stata applicata la GPO (il primo riavvio serve per applicare la GPO copiando in %SystemDrive%\Hashr i file necessari e creare l’operazione pianifica per l’avvio dello script Run-hashr.cmd, mentre il secondo riavvio per eseguire lo script all’avvio del computer) aprendo la Gestione Attività si dovrebbero vedere due processi hashr.exe in esecuzione con l’account SYSTEM (il primo processo è lo stub che server per avviare poi lo script Python di hashr convertito in exe)

Figura 12: Verifica esecuzione del processo hashr.exe con credenziali SYSTEM

Come ulteriore verifica di funzionamento sui computer su cui è stata distribuita la GPO è possibile verificare l’esistenza e il contenuto del file %SystemDrive%\Hashr\Run-hashr.log.

Figura 13: File Run-hashr.log

Nel caso su di un computer venisse rilevato uno o più file il cui hash sia presente in file IoC verificato verrà visualizzato sul sistema un messaggio indipendentemente che vi si sia o meno un utente connesso. Nel caso il computer sia avviato ma non vi sia alcun utente autenticato il messaggio sarà visualizzato nella schermata di login.

Figura 14: Messaggio di avviso rilevamento IoC

Per i dettagli sugli IoC rilevati relativi al file iocfilename.txt è possibile esaminare il file denominato iocfilename.hostname.IoCFound.yyyy-MM-dd.txt. In Figura 15 è possibile vedere un esempio di rilevamento in cui è stato inserito l’hash del file hashr-v2.0.1.zip tra quelli da controllare.

Figura 15: Esempio di report di rilevamento IoC

Nei file di log è invece possibile esaminare quali file non sono stati esaminati, di solito perché in uso.

Figura 16: File di log dettagliato dell’analisi

Grazie al fatto che le Group Policy impostate copieranno i file relativi agli esiti del rilevamento e i file di log su una share sarà possibile esaminare periodicamente tale share per avere la panoramica degli esiti della ricerca degli IoC sui computer a cui è stata applicata la GPO.

Figura 17: Share contenente gli esiti delle rilevazioni degli IoC

Considerazioni finali

Nell’articolo oltre a fornire informazioni dettagliate su hashr, lo strumento sviluppato dal CERT-AGID (Computer Security Incident Response Team AGID) per la verifica degli Indicatori di Compromissione basati su hash, si è anche voluto approfondire come tramite l’uso di script e Group Policy sia possibile automatizzare semplicemente attività di threat hunting e incident response.

Infatti sebbene esistano software che permettono la gestione di rilevazione e verifica degli IoC, in realtà informatiche di ridotte dimensioni, come infrastrutture IT di piccole e medie PA e aziende private, l’approccio descritto nell’articolo risulta di semplice, rapida ed economica implementazione e gestione.

Inoltre, qualora l’infrastruttura subisse un attacco informatico, la ricerca e l’analisi degli Indicatori di Compromissione (IoC) rappresentano uno dei primi step fondamentali per la gestione dell’incidente. Disporre di un sistema automatizzato per la verifica degli IoC basati su hash, sia su server che su client, è pertanto un elemento cruciale per una difesa proattiva.

Si tenga inoltre presente una PA è tenuta a segnalare un attacco informatico o una campagna malevola di cui è ogetto presso gli organi competenti quali Agenzia per la Cybersicurezza Nazionale (ACN), il CSIRT Italia (Computer Security Incident Response Team) o il Centro Nazionale Anticrimine Informatico per la Protezione delle Infrastrutture Critiche (CNAIPIC). Normalmente a fronte di queste segnalazioni il Centro Operativo per la Sicurezza Cibernetica della Polizia Postale e delle Comunicazioni di competenza richiede al segnalante di effettuare le opportune verifiche tecniche atte a stabilire se l’attività malevola segnalata ha determinato l’eventuale compromissione dei sistemi. Per eseguire i controlli richiesti dal Centro Operativo per la Sicurezza Cibernetica della Polizia Postale e delle Comunicazioni l’utilizzo di hashr gestito centralmente tramite Group Policy, come descritto nell’articolo, può essere un strumento estremente utile per fornire rapidamente un riscontro.

Ne consegue che, a prescindere dal fatto che si debba gestire l’infrastruttura IT di una PA o di un’azienda privata, se non si dispone di un sistema per l’analisi degli IoC l’utilizzo di hashr e dell’automazione proposta nell’articolo tramite lo script Run-hashr.cmd e le Group Policy permette di non farsi trovare impreparati in caso si debba gestire un incidente di sicurezza.