Deliverable

Di seguito riportiamo una sintesi dei contenuti dei Deliverable rilasciati nell’ambito dei vari WP.

D1.1 – Definizione dei requisiti funzionali e specifiche tecniche della piattaforma di virtualizzazione

Il Rapporto Tecnico D1.1 descrive le seguenti attività svolte nell’ambito del Work Package 1: 

  1. Progettazione e implementazione della piattaforma di virtualizzazione: il documento descrive le componenti sviluppate per la gestione dei dati, il deployment e il monitoraggio degli ambienti virtuali, nonché di strumenti sviluppati per il routing dei dati con cifratura end-to-end avanzata, il monitoraggio dei log di sistema e l’analisi dati. 
  2. Sviluppo della pipeline di elaborazione dati e integrazione stack ELK: il documento descrive la creazione di una pipeline di elaborazione e storicizzazione dei dati e l’integrazione dello stack ELK, con attenzione particolare alle chiamate di sistema, al traffico di rete e agli artefatti di malware. Viene anche data descrizione di un componente sviluppato per la cattura e la ricostruzione dinamica di codice malevolo. 
  3. Costruzioni di ambienti virtuali Windows e Linux, configurazione e dispiegamento dei sensori & data ingest: il rapporto presenta la creazione di ambienti virtuali su Linux e Windows, tesi a migliorare la raccolta e l’analisi dati dai sensori distribuiti.

D1.2 – Manuale d’uso e procedure operative DevOps della Piattaforma

Il Rapporto Tecnico D1.2, sviluppato nell’ambito del Work Package 1, presenta la metodologia DevOps (è un insieme di pratiche, strumenti e una filosofia culturale che automatizza e integra i processi tra i team di sviluppo Software e i team IT.) adottata per lo sviluppo del sistema EMPHAsis Evolution, esaminandone in dettaglio i vari componenti (Management by Code, GitLab, System Management, Network Management e Storage Management). Il documento presenta anche il manuale d’uso della metodologia, offrendo una guida pratica per la sua attuazione all’interno di un’organizzazione. Infine, offre una sintesi delle chiavi del successo, proponendo potenziali miglioramenti e sviluppi futuri.

D1.3 – Rapporto sugli esiti degli esperimenti di validazione presso potenziali utilizzatori

Il Rapporto Tecnico D1.3, sviluppato nell’ambito del Work Package 1, descrive la validazione di EMPHAsis Evolution effettuata presso un potenziale utilizzatore che opera nel settore siderurgico.

Il rapporto descrive l’infrastruttura, basata su  EMPHAsisICS, creata per simulare l’esposizione di un sistema industriale su Internet tramite IP pubblico. EMPHAsisICS è un’instanza di EMPHAsis Evolution atta a monitorare e studiare le interazioni con un honeypot nel contesto operativo dato, nonché della configurazione generale progettata per mantenere segreta la natura simulata dell’ambiente e catturare gli eventuali attacchi senza che gli aggressori ne siano consapevoli. 

Il rapporto fornisce dettagli sui risultati degli esperimenti di validazione, includendo le metodologie utilizzate, i contesti operativi testati e i feedback raccolti dagli utenti potenziali. 

D2.1 – Rapporto tecnico sui risultati relativi all’integrazione degli strumenti di Threat Intelligence e di Data Analysis

Il Rapporto Tecnico D2.1, sviluppato nell’ambito del Work Package 2, è focalizzato sull’integrazione di strumenti avanzati di Threat Intelligence e Data Analysis nel sistema EMPHAsis Evolution

Relativamente al Threat Intelligence, il rapporto fornisce un ventaglio di soluzioni, tra cui il noto framework MITRE ATT&CK, uno strumento fondamentale per comprendere e categorizzare tecniche, tattiche e procedure (TTP) utilizzate dagli aggressori. 

Il rapporto descrive anche gli indicatori di compromissione e la loro integrazione nella piattaforma EMPHAsis Evolution.

Per quanto riguarda gli strumenti di Data Analysis, il documento offre, oltre ad una panoramica ampia delle applicazioni del Process Mining e del Data Mining in ambito sicurezza informatica, soluzioni tecnico-architetturali per l’evoluzione della piattaforma EMPHAsis attraverso (i) tecniche di Online Process Discovery in grado di scoprire in tempo reale eventuali tentativi di attacco e (ii) tecniche di clustering per l’identificazione di attività sospette.

D3.1 – Rapporto sulle tecniche di code similarity adottate

Il rapporto tecnico D3-1, sviluppato nell’ambito del Work Package 3,  è focalizzato sullo studio delle rappresentazioni grafiche dei programmi, come i grafi di controllo (CFG) e i grafi di dipendenza (CDG), per individuare codice maligno. Queste rappresentazioni sono utilizzate come base per valutare la somiglianza tra codici. 

Il documento propone un metodo generale per analizzare la somiglianza dei programmi attraverso l’astrazione delle loro rappresentazioni CFG, in particolare, focalizzandosi sulle astrazioni dei blocchi di base di un CFG

D3.2 – Rapporto tecnico su requisiti, progettazione, sviluppo e integrazione della Sandbox

Il Rapporto Tecnico D3.2 descrive le attività svolte per il task WP3.2, la cui finalità è realizzare uno strumento, da integrare in un ambiente virtuale isolato creato e ospitato opportunamente all’interno della piattaforma EMPHAsis Evolution, per l’estrazione di firme dai malware catturati dalla piattaforma mediante rappresentazione a grafo del codice dell’entità malevola.

D3.3 – Rapporto tecnico sugli algoritmi di machine learning per analisi di Big Data individuati e integrati

Il Rapporto Tecnico D3.3, sviluppato nell’ambito del Work Package 3, presenta un approccio per l’identificazione di una nuova e pericolosa tipologia di minaccia basata sull’uso dell’IA offensiva per la realizzazione di malware in grado di adattare il proprio comportamento rispetto all’ambiente in cui si trovano e di nascondersi al suo interno. L’approccio proposto  sfrutta algoritmi di apprendimento automatico per lo sviluppo di agenti autonomi basati sul Reinforcement Learning e su tecniche innovative di riconoscimento di attività malevoli data-driven. Più nello specifico, il rapporto descrive la progettazione e l’implementazione di un agente autonomo in grado di apprendere, attraverso tecniche di Reinforcement Learning, le metodologie di attacco degli Advanced Persistent Threat (APT). Questi algoritmi sono utili in quei contesti dove è necessario costruire in tempo reale una propria base di conoscenza, basata sulle osservazioni dei risultati delle azioni compiute. 

D 4.1 Rapporto tecnico su requisiti e specifiche degli ambienti virtuali per sistemi mobili e IOT

Il Rapporto Tecnico 4.1, sviluppato nel Work Package 4, descrive l’integrazione di ambienti virtuali progettati appositamente per i sistemi mobili IoT e ICS, con l’obiettivo di espandere e migliorare le funzionalità della piattaforma EMPHAsis Evolution. A tal fine, il documento riporta un’approfondita analisi architetturale e implementativa di ambienti virtuali specifici per il mobile e l’IoT, con un focus particolare sulle minacce emergenti in questi ambiti.

D4.2 – Rapporto tecnico sull’integrazione, validazione e sperimentazione degli ambienti virtuali realizzati

Il Rapporto Tecnico D4.2 dà conto delle attività svolte nell’ambito del Work Package 4. In particolare, esso è focalizzato sull’integrazione di EMPHAsis Evolution in contesti di Mobile Application & IoT. 

In questo contesto, viene fornita una panoramica sulla rapida proliferazione dei dispositivi Android in ambito Internet of Things (IoT), ed una descrizione dell’importanza degli honeypot come strumento di sicurezza emergente. Viene quindi presentata un’architettura per la realizzazione di un ambiente virtuale trappola utilizzando un proxy TCP e un dispositivo Android, con l’obiettivo di raccogliere informazioni sul comportamento degli attaccanti e studiare come questi cercano di sfruttare le vulnerabilità nel sistema Android. Il documento infine descrive la validazione degli approcci proposti, e l’ambiente virtuale “Mobile-Based” definito al fine di replicare un attacco realistico in condizioni controllate. 

D5.1 Rapporto tecnico sui miglioramenti introdotti alla dashboard, e sull’integrazione dei componenti sviluppati

Il Rapporto Tecnico D5.1 si colloca nell’ambito del Work Package 5 e tratta della dashboard della piattaforma EMPHAsis Evolution. Questa svolge un ruolo cruciale nella gestione e nel rilevamento delle minacce informatiche, ed è progettata per fornire una panoramica chiara e immediata della situazione di sicurezza di un’organizzazione, consentendo agli operatori di sicurezza di prendere decisioni tempestive.

In particolare, il documento presenta una descrizione dettagliata dell’architettura a micro-servizi della dashboard e dei suoi moduli costitutivi, nonché l’interazione dei vari componenti che lavorano sinergicamente per fornire una visione completa della sicurezza informatica.

D5.2 Manuale d’uso della dashboard

Il documento D5.2 è il manuale della dashboard del sistema EMPHAsis Evolution. Esso fornisce agli utenti una guida completa e dettagliata sull’utilizzo efficace della dashboard. In particolare, il manuale illustra l’interfaccia utente, le funzionalità chiave e le procedure operative necessarie per sfruttare appieno la dashboard e mostra come accedere alla dashboard, personalizzare le visualizzazioni, monitorare eventi in tempo reale, analizzare dati di sicurezza, generare report e molto altro.

D5.3 Rapporto tecnico su definizione del caso d’uso IAM

Il Rapporto Tecnico D5.3, sviluppato nell’ambito del Work Package 5 (WP5), si occupa di tecniche di sicurezza atte a rilevare accessi non autorizzati e violazioni delle credenziali d’accesso. Questo è un tema oggi di grande interesse per organizzazioni, enti governativi e utenti finali. 

A tal fine, il documento presenta uno studio dello state dell’arte della lettura scientifica sulle vulnerabilità dei sistemi IAM (Identity and Access Management), una descrizione approfondita delle potenziali minacce per i sistemi IAM e dei principali framework che implementano questo paradigma e, infine, il caso di studio implementato nel corso del WP5, con il relativo stack tecnologico ed il modello di attacco usato. Particolare enfasi viene dato al modello di attacco, caratterizzato da una serie di fasi distinte e interdipendenti, ottenute tramite concatenazione e sfruttamento di vulnerabilità presenti nell’applicazione su cui si basa il caso di studio o nei sistemi esterni integrati.

D5.4 Rapporto sui risultati della sperimentazione

Nel rapporto D5.4 vengono presentati i risultati della sperimentazione relativa all’integrazione dell’applicazione (IAM) “WINTED” come ambiente virtuale all’interno della piattaforma EMPHAsis Evolution, con particolare attenzione alle problematiche di scalabilità, sicurezza e interoperabilità.

In particolare, il documento descrive la metodologia adottata, nonché i risultati della sperimentazione effettuata per valutare le performance, la robustezza e l’efficacia della soluzione integrata, fornendo considerazioni per ulteriori sviluppi. 

* Esempio di Cattura di un Malware *

Componenti:

  • Dropper.

  • Malware-Core.

Caratteristiche Dropper:

  • Il dropper è programmato interamente in Assembly per arch x86_64/AMD64 e sfrutta le linux ABI per compiere le operazioni di download ed esecuzione del malware.

  • All’avvio esegue due processi, il processo figlio avvia wget ed esegue il download del malware mentre il padre attende la terminazione di quest’ultimo per poi eseguire il malware.

  • Il dropper passa al malware come argomenti dalla riga di comando l’ftp server cui connettersi, il nome utente e la password.

Caratteristiche Malware-Core:

  • Il malware varia parte del suo comportamento in base all’uid del processo che lo esegue:

  • Se l’uid == 0, il malware si riproduce in /usr/lib/libmlwr1.so.

  • Se l’uid != 0, il malware si riproduce nella home dell’utente che ha eseguito il processo.

  • Se il malware dovesse già essere presente all’interno del file system la riproduzione non avviene, si limita ed eseguire le sue funzioni dalla locazione sul file system in cui si trova.

  • Una volta avviato, il malware cerca all’interno del file system su cui è localizzato vari tipi di documenti ed esegue l’upload verso un ftp server controllato dall’attaccante.

  • Il malware è dotato di un semplice algoritmo di crittografia che impedisce a tools quali strings di identificare le stringhe all’iterno del file binario, inoltre contiene alcuni decoys che lasciano erroneamente presupporre l’utilizzo di alcuni username e password.

 

Analisi Statica Malware Captured:

 

Poichè parte dei simboli sono stati rimossi tramite stripping, il reverse engineer potrebbe procedere tramite una prima analisi statica del malware identificando l’entry point del programma usando ad esempio readelf/eu-readelf:

Ad es:

ELF Header:

Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00

Class:                             ELF64

Data:                              2’s complement, little endian

Ident Version:                 1 (current)

OS/ABI:                         UNIX – System V

ABI Version:                   0

Type:                              EXEC (Executable file)

Machine:                        AMD x86-64

Version:                           1 (current)

Entry point address:               0x400ce0

Start of program headers:          64 (bytes into file)

Start of section headers:          8848 (bytes into file)

Flags:                            

Size of this header:               64 (bytes)

Size of program header entries:    56 (bytes)

Number of program headers entries: 9

Size of section header entries:    64 (bytes)

Number of section headers entries: 28

Section header string table index: 27

Una volta individuato l’entrypoint (in questo caso l’indirizzo 0x400ce0), si può procedere con il disassembling:

0x400ce0:    xor    ebp,ebp

0x400ce2:    mov    r9,rdx

0x400ce5:    pop    rsi

0x400ce6:    mov    rdx,rsp

0x400ce9:    and    rsp,0xfffffffffffffff0

0x400ced:    push   rax

0x400cee:    push   rsp

0x400cef:    mov    r8,0x4012e0

0x400cf6:    mov    rcx,0x401270

0x400cfd:    mov    rdi,0x400cb0

0x400d04:    call   0x400bd0 <__libc_start_main@plt>

0x400d09:    hlt   

0x400d0a:    nop    WORD PTR [rax+rax*1+0x0]

0x400d10:    mov    eax,0x60216f

0x400d15:    push   rbp

0x400d16:    sub    rax,0x602168

0x400d1c:    cmp    rax,0xe

0x400d20:    mov    rbp,rsp

0x400d23:    jbe    0x400d40

0x400d25:    mov    eax,0x0

0x400d2a:    test   rax,rax

0x400d2d:    je     0x400d40

0x400d2f:    pop    rbp

0x400d30:    mov    edi,0x602168

0x400d35:    jmp    rax

0x400d37:    nop    WORD PTR [rax+rax*1+0x0]

0x400d40:    pop    rbp

0x400d41:    ret

La SYSV calling convention per x86-64 impone che i parametri alle funzioni vengano passati tramite registri nel seguente ordine RDI, RSI, RDX, RCX, R8, R9, i restanti sullo stack, ed il valore di ritorno in RAX.

Di conseguenza conoscendo la signature di __libc_start_main (funzione di ingresso nella glibc di Linux) si individua che il primo parametro passato prima della call instruction è proprio l’indirizzo del main del malware.

Eseguendo il disassemble all’indirizzo 0x400cb0 si ottiene il codice del main:

0x400cb0:    sub    rsp,0x8

0x400cb4:    cmp    edi,0x3

0x400cb7:    jle    0x400cd7

0x400cb9:    mov    rax,rsi

0x400cbc:    mov    rdx,QWORD PTR [rsi+0x18]

0x400cc0:    mov    rsi,QWORD PTR [rsi+0x10]

0x400cc4:    mov    rdi,QWORD PTR [rax+0x8]

0x400cc8:    call   0x400fb0

0x400ccd:    mov    eax,0x6

0x400cd2:    add    rsp,0x8

0x400cd6:    ret   

0x400cd7:    or     edi,0xffffffff

0x400cda:    call   0x400c60 <exit@plt>

Dal Main si può continuare il Reverse Engineering del codice seguendo semplicemente il Control Flow.

Altri spunto per capire l’andamento e le funzioni adoperate dal malware è la “.dynsym” section, dove è possibile trovare il listing di tutte le funzioni referenziate dal malware nelle librerie che utilizza.


Analisi Dinamica Malware Captured:

 

I criteri che potrebbero essere adoperati nell’analisi dinamica del malware per capirne le funzionalità sono:

  • Il tracing tramite debugger

  • L’analisi di rete tramite uno sniffer mostrerebbe il traffico verso l’ftp server dell’attaccante. Inoltre il comportamento del malware verrebbe individuato considerando che il protocollo ftp agisce in chiaro.

  • Il listing dei files aperti dal processo. Essendo inviati tramite la rete è necessario che i file vengano aperti, bufferizzati ed inviati all’ftp server dell’attaccante.