In questa analisi proponiamo di condividere le evidenze che abbiamo raccolto nel corso del tempo per cercare di far luce sulla natura di questo malware, anticipando sin da subito che le informazioni di cui disponiamo sono frammentarie e non permettono nè una ricostruzione esauriente nè soddisfacente.

Vogliamo però soffermarci, per dare valore a quanto pubblicato, solo su alcune evidenze confermabili da fonti interne ed esterne.

Riguardo sLoad vi sono due certezze:

1. in Italia veicola solo tramite PEC;
2. è molto elusivo.

Indice degli argomenti

• La longevità
• Quali paesi colpisce?
• Come si diffonde?
• Come si presenta?
• Come si comporta?
  • Protezione del file da scaricare
  • Il powershell e la persistenza
  • Rimozione di sLoad
  • L’installer
  • Come lavora il core
  • La pazienza
• Quali payload abbiamo osservato?
• Sugli autori?

La longevità

Partiamo cercando di capire la longevità di questo malware. Dalle informazioni estratte da vecchi articoli pubblicati dal CERT-PA (non più disponibili online) la prima campagna sLoad risale al 08/11/2018. Yoroi ha evidenze delle prime campagne di sLoad nell’analisi che fece a suo tempo. Secondo questa fonte, la prima campagna di cui si ha contezza risale al 08/10/2018, un mese prima della precedente data.

Inoltre, un articolo di Libero riporta una notizia del CERT-PA riguardo una campagna sLoad avvenuta proprio il 10/11/2018 (la data di modifica dell’articolo non è immediatamente visibile ma si trova nei sorgenti della pagina e corrisponde al 29/11/2018).

Sembra quindi che sLoad sia arrivato in Italia nell’ottobre del 2018 anche se altre fonti parlano di sLoad presente già dal giugno del 2018.

Un’analisi di Kremez dello stesso periodo indica il banker Ramnit come payload di sLoad. In quell’analisi non ci si sofferma su sLoad, sebbene venga citato, ma viene ripreso un tweet del ricercatore JAMESWT_MHT che contiene un URL che riporta il termine “sload”. Potrebbe trattarsi quindi effettivamente di una delle primissime campagne sLoad ma non è chiaro se sia o meno italiana anche se JAMESWT_MHT è un ricercatore italiano che pubblica principalmente malware italiani ma non esclusivamente.

Possiamo quindi sostenere che sLoad viene sicuramente veicolato in Italia da almeno ottobre del 2018 (quasi tre anni e mezzo fa), forse già a partire dal giugno del 2018.

L’anno del 2018 è confermato anche da un relativo articolo di Minerva che fornisce qualche informazione anche su un altro aspetto di sLoad: i paesi che colpisce.

Quali paesi colpisce?

Nell’articolo appena citato si fa riferimento all’Europa come obiettivo di sLoad per poi effettivamente citare solo Italia ed Inghilterra.

Il CERT-AGID, come già il CERT-PA, è focalizzato principalmente sul monitoraggio delle campagne italiane senza comunque trascurare il panorama internazionale. Durante questi anni non si sono mai riscontrate evidenze di campagne inglesi o straniere che usassero sLoad.

L’unica evidenza di campagne estere individuata è l’analisi di Kramez citata sopra di cui non è chiaro il paese target.

Anche riguardo il payload ci sono discrepanze con quanto osservato da CERT-PA/AGID: non abbiamo mai visto campagne di sLoad italiane che veicolassero Ramnit, considerando anche il fatto che i payload di sload sono piuttosto elusivi.

Una possibile ipotesi è che sLoad siano nato veicolando Ramnit in Inghilterra – e forse in Italia – ma si sia poi immediatamente focalizzato solo sul nostro paese – utilizzando altri payload – probabilmente a seguito del successo di alcune campagne.

Come si diffonde?

Come ampiamente descritto nel nostro sito sembra che sLoad si trasmetta esclusivamente tramite PEC. In realtà non è sempre stato così: la prima evidenza di una campagna sLoad rivolta esclusivamente verso la PEC si ha il 4 Giugno 2019, quindi circa 8 o 12 mesi dopo l’approdo in Italia. Evidenze sporadiche si hanno fin dalla primissime campagne come indicato nell’analisi di Yoroi.

Da allora sLoad sembra essersi focalizzato solo in Italia e veicolato solo tramite PEC!

E’ significativo che questa prima campagna PEC sia avvenuta verso caselle appartenenti all’ordine degli ingegneri. L’ipotesi è che sLoad abbia trovato un ecosistema relativamente libero da malware nelle PEC. Le caselle PEC non sono infatti un obiettivo eccessivamente interessante per i criminali poichè un non trascurabile numero di queste caselle riceve solo da altre caselle PEC e non da PEO.

In quel periodo circolavano comunque malware su PEC: ad eccezione di FTCODE ed sLoad gli altri erano effetti collaterali di campagne ordinarie. Successivamente, l’innalzamento dei controlli effettuati dai Gestori con il coordinamento del CERT-PA/AGID ha permesso di ridurre notevolmente il numero di email malevole che circolano sulle PEC al punto che, dal 2019 ad oggi, escludendo eventi sporadici provenienti da altre campagne, sLoad risulta l’unico malware che effettua campagne sistematiche verso PEC.

Il panorama che si delinea è quello in cui sLoad sia partito come malware europeo quando ancora veniva chiamato “Starslord” per via dei riferimenti nel nome delle variabili e che poi si sia specializzato solo per l’italia in seguito al successo ottenuto nel nostro Paese.

Possiamo ipotizzare che qualche sorta di leak di PEC di professionisti (ingegneri, avvocati, architetti) abbia motivato gli autori a spostarsi sullo scenario delle PEC. Dato che molte persone ritengono – purtroppo – che la posta certificata sia automaticamente sicura, le campagne di sLoad hanno avuto successo nel recuperare informazioni e credenziali di sempre più un maggior numero di caselle PEC. Da allora sLoad non è più uscito da questo ecosistema.

Dalle informazioni che siamo riusciti a recuperare, i payload di sLoad sono volti a recuperare i file dove i browser salvano cookie e password (questo comportamento non è stato più osservato da qualche mese a questa parte) oppure i file che contengono domini appartenenti a banche italiane. Lo scopo sembra quindi quello di:

1. ottenere credenziali per realizzare altre campagne;
2. accedere alle informazioni di home banking. Sotto questo aspetto ha senso che sLoad colpisca professionisti.

Come si presenta?

Come indicato nelle analisi sopra, sLoad sfrutta principalmente il tema dei pagamenti e, nello specifico, di fatture da pagare. Le comunicazioni sembrano prese da email reali, probabilmente in seguito all’accesso alle caselle compromesse.

Immancabilmente queste e-mail contengono un allegato in formato zip con all’interno:

• Inizialmente ZIP con LNK;
• Poi è stato osservato lo ZIP contenente WSF o VBS o PS1;
• Per un lungo periodo è stato utilizzato un doppio ZIP;
• Oggi è tornato nuovamente a ZIP con WSF.

Come si comporta?

Osservando un campione moderno, dentro lo ZIP di sLoad ci sono solitamente dei file esca con estensioni innocue (jpeg, pdf) e un file eseguibile di tipo WSF.

All’interno del WSF troviamo il codice del dropper:

Non è difficile deoffuscare questo codice in:

dove è evidente che l’azione principale è eseguire il download per scaricare un file da

HTTPS://TUYTEHFAPP.EU/CAVE/<CF/PIVA>/NOVO.RTF in %APPDATA%\NOVO.RTF

tramite BitsAdmin.

Protezione del file da scaricare

Una prima difficoltà nell’analizzare sLoad consiste nel fatto che i link utilizzati dal dropper sono usa e getta. Una volta che il malware è stato scaricato il link non è più usabile.

Oltre a questo controllo, altri sono utilizzati per limitare la superficie di attacco usabile dagli analisti, in particolare il backend di sLoad è in grado di rilevare richieste che non sono generate dal dropper.

BitsAdmin è un servizio che prima di effettuare il download di un file tramite HTTP(S), con una o più GET, invia una richiesta HEAD per ottenere la dimensione del file.

Se un analista prova a scaricare il malware tramite altri strumenti (es: un browser) che non fanno questa richiesta o non usano l’UA di BitsAdmin, l’indirizzo IP da cui proviene la richiesta è messo in blacklist ed il file che si intendeva scaricare viene contrassegnato come non più scaricabile.

E’ necessario quindi porre molta attenzione nel download di sLoad poichè non sono ammessi errori e si ha un solo tentativo per campione.

Il powershell e la persistenza

Il file scaricato dal dropper è uno script Powershell (PS1) il cui compito è quello di installare ed eseguire il vero core di sLoad. Si presenta come un file a prima vista molto offuscato (codice) ma è piuttosto semplice da deoffuscare (codice).

Dal codice deoffuscato è chiaro che sLoad si installa in APPDATA, in una cartella di nome casuale di 9 caratteri alfanumerici e che la persistenza si affidata ad un task il cui nome inizia per “S” seguito da un numero (sequenziale).

Rimozione di sLoad

Per rimuovere sLoad è quindi sufficiente:

1. Terminare ogni processo powershell;
2. Rimuovere ogni task il cui nome inizia per “S” seguita da un numero (in ogni caso tutti task che puntano all’interprete VBscript).

L’installer

L’installer rivela anche come è salvato il core di sLoad e la lista dei C2.

Nella cartella di installazione sono presenti quattro file:

• due file sono utilizzati per l’avvio: viene lanciato un file VBS che non fa altro che avviare un file PS1 che decodifica il core e lo esegue;
• il terzo è il core di sLoad;
• il quarto è la lista dei C2.

Ovviamente le estensioni usate possono cambiare e sono in genere casuali per campagna e dropper utilizato.

L’installer è quindi molto semplice e rende sLoad facile da disinstallare. Attenzione però: non è possibile arrivare alla stessa conclusione per eventuali payload scaricati dal core anche se al momento non abbiamo mai osservato un payload che non fosse uno script eseguito al volo per esfiltrare informazioni.

Come lavora il core

Una volta deoffuscato il core di sLoad (codice) risulta evidente che si tratta di un RAT e che i C2 sono contenuti nel file “sleep.sh” (nome variabile) che è decodificato allo stessa stregua del core.

Nella fase iniziale, sLoad cerca un C2 valido. Tutte le operazioni di rete di sLoad vengono effettuate tramite BitsAdmin, incluse le chiamate ai C2. Come già anticipato, se viene rilevata una richiesta non compatibile con BitsAdmin o con il core, l’IP che la effettua viene bannato. Per determinare se il C2 è attivo viene lanciata una richiesta all’URL:

 /<MD5(indirizzo mac || nome computer)>.html

La risposta a questa richiesta contiene un ID univoco che sLoad passerà al C2 per il download di payload successivi (ma non per la richiesta di nuovi comandi).

Da osservare che le richieste ai C2 sono fatte in modo asincrono: non sono testati sequenzialmente ma tutti in una sola volta e viene dato un tempo massimo di 5 minuti (in cicli di 5 secondi) per ottenere una risposta.

Qualora nessun C2 risulti essere valido, viene usato un semplice artificio che trasforma un dominio nel seguente modo:

domain.tld in domain1.tld -> domain2.tld -> … -> domain20.tld > … e così via.

Quindi, dato un C2 di sLoad, gli altri domini enumerati come appena descritto sono da considerarsi potenzialmente malevoli.

Una volta trovato un C2 valido, sLoad inizia a fare una ricognizione e, in particolare, recupera le seguenti informazioni:

• La lista di cartelle condivise nel formato {lettera_share1:percorso_di_rete_share1}…{lettera_shareN:percorso_di_rete_shareN};
• Il numero di shares (tramite netview) nel formato {in net:N};
• Nome della CPU e dell’O.S.;
• La lista di file OST di outlook posizionati in AppData\Local\Microsoft\Outlook nel formato file_ost1…*file_ostM (dove file_ostX non contiene l’estensione .ost);
• La lista dei processi in esecuzione (meno un insieme di processi noti) separati da asterisco: *process1…*processO

Queste informazioni sono ricomposte in un JSON della forma:

{
	"self": "<percorso script>",
	"m": "<dimensione script kickstarter VBS>",
	"b": "<dimensione script kickstarter PS1>",
	"c": "<stringa casuale ma fissa per esecuzione>",
	"ver": "<versione di sload: 4.3.2>",
	"td": "<ultimo comando eseguito>",
	"tds": "<numero parametri ultimo comando eseguito>",
	"lnk": "<hostname c2>",
	"s": "<numero sequenziale della richiesta>",
	"g": "<nome della versione o campagna: x2401>",
	"id": "<id vittima: mac address>",
	"v": <OS>,
	"a": <PROC>,
	"fm": <OST>,
	"d": <SHARES><NSHARES>,
	"n": "<nome computer>",
	"cput": <CPU>,
	"o": "<1 se ha outlook 0 altrimenti>"
}

Il JSON viene convertito in base64 ed inviato al C2 ricomponendo la URL nel seguente modo:

 /<MD5(indirizzo mac || nome computer)>/<base64>

Il file scaricato contiene un comando da eseguire. Il formato dei comandi è il seguente:

parametro*azione*id*pausa

azione è uno dei seguenti valori tra:

• eval: scarica lo script dall’URL indicato nel parametro ed eseguilo come processo a parte;
• sch: scarica lo script dall’URL indicato nel parametro ed eseguilo come task schedulato tra 3 minuti ed eseguito una singola volta;
• ops: scarica lo script dall’URL indicato nel parametro ed eseguilo nello script corrente con IEX.

id è l’id da passare nel parametro “td” del JSON riportato sopra.
pausa è il tempo di attesa prima di chiedere il prossimo comando.

Il ciclo principale di sLoad consiste nell’effettuare richieste al C2 con il formato JSON sopra descritto per ricevere un comando ed eseguirlo. La pausa di default tra queste richieste è di 40 minuti ma già dopo il primo comando sale a 4 ore.

I file scaricati – ricordando che sLoad usa BitsAdmin – sono salvati in una cartella con un nome casuale in APPDATA . Anche il file stesso ha nome casuale ma l’estensione rimane quella indicata nell’URL.

Nel ciclo successivo questi file vengono cancellati. L’azione ops non crea questi file in APPDATA ma nel file eval_stringacasuale dentro la directory di installazione di sLoad. E’ quindi possibile, in alcuni casi, recuperare l’ultimo payload eseguito

La pazienza

Una delle caratteristiche di sLoad è quell di essere molto … paziente. Il primo payload è generalmente servito dopo un’ora circa dall’infezione e, successivamente, ogni 4 ore.

Inoltre i parametri “b” ed “m” del JSON sono utilizzati per determinare se è necessario procedere con una nuova installazione di sLoad. In questo caso viene inviato un comando eval con un URL con una variante di sLoad della campagna.

E’ possibile che il download della variante – che contiene C2 diversi ma che per il resto è identico alla versione di sLoad in esecuzione – sia realizzato per rendere più difficile la simulazione del malware.

In base alle informazioni ricevute (cartelle di rete, file di posta, nome computer, comando eseguito) il backend decide il payload da fornire.

Non è quindi immediato capire le intenzioni nascoste dietro una campagna sLoad poichè i payload scaricati dipendono dalle informazioni inviate di volta in volta al server.

Quali payload abbiamo osservato?

Fino ad oggi abbiamo osservato solo due payload:

Il primo payload (codice) è uno script che non fa altro che cercare in APPDATA i file contenenti i domini di alcune banche italiane:

1. cbi.bpergroup.net
2. business.bnl.it
3. ibk.nexi.it
4. inbiz.intesasanpaolo.com
5. bpergroup.net
6. inbank.it
7. finecobank.com

e

1. aziendaonline.mps.it
2. banking-imprese.credem.it
3. clienti.chebanca.it

Queste ultime tre sono ricercate solo se nessuna delle prime sette è stata trovata. Quello che viene inviato al C2 non sono i file contenenti questi domini ma l’informazione sulla loro presenza (come una mappa di 7 bit).

Questo dimostra ancora una volta che gli autori di sLoad danno molta importanza alla fase di ricognizione: non si limitano a rubare informazioni massive ma scelgono attentamente le informazioni di dettaglio.

Il secondo payload (codice) effettua effettivamente l’esfiltrazione dei dati: crea un file ZIP delle cartelle di Internet Explorer che contengono i dati di sessione dell’utente e di quelle di Chrome e quindi lo invia al C2.

Sugli autori?

Non abbiamo riscontrato evidenze sulla natura degli autori. Non vi sono elementi che possano far intuire la nazionalità di chi elabora questa campagne. I domini usati come C2 raramente sono significativi in questo tipo di analisi e sLoad non fa eccezione.

Nel codice non sono presenti elementi che possano aiutare ad identificarne la mano così come non sono presenti commenti o funzionalità di controllo della nazionalità.

I nomi delle variabili (offuscate) sono ispirate alla saga di Star Wars (prima) e da Rick and Morty (fino ad oggi), entrambe serie destinate ad un pubblico più tecnofilo. Rick and Morty è popolare tra la generazione Y anche se questi nomi potrebbero non indicare niente ed essere solo delle impostazioni predefinite dell’offuscatore.

Il fatto che sLoad presti particolare attenzione alle richieste ricevute dal C2 e che disponga di avanzata fase di ricognizione fa pensare ad un attore più oculato. Difficile dire se sia di matrice governativa o meno ma sicuramente non è un attore di quelli che si vedono dietro le campagne quotidiane che infestano il panorama italiano.

Chiunque sia dietro sLoad sembra scegliere accuratamente le sue vittime. Dai payload che siamo riusciti ad ottenere sembra che lo scopo sia quello di rubare informazioni bancarie ma non è chiaro se sia uno scopo secondario opportunisticamente colto o che sia quello principale.

Infatti è difficile usare le informazioni bancarie: questo tipo di credenziali è più utilizzato nelle campagne di phishing dove una persona fisica segue la vittima in tempo reale per ottenere da questa tutte le informazioni necessarie a superare i controlli aggiuntivi (come per 2FA).

L’utilizzo delle PEC e la focalizzazione su alcuni applicativi Microsoft potrebbe far pensare che sLoad sia interessato ad aziende o PA dove generalmente sono utilizzati applicativi come Outlook e dove sono presenti condivisioni di rete.

Le PEC inoltre sono più diffuse tra professionisti e PA che tra privati cittadini – anche se ovviamente vi è un consistente numero di questi ultimi che utilizza le PEC – e quindi ci si chiede se sLoad possa o abbia anche funzionalità, magari opportunistiche, di spionaggio.

Secondo quanto ipotizzato in un articolo, dietro sLoad ci sarebbe l’APT TA554, almeno dietro le campagne del 2018. Tuttavia il prefisso TA indica semplicemente un Threat Actor non identificato.

Inoltre, al tempo, sLoad veniva usato per installare Ramnit mentre fino ad oggi non abbiamo più osservato tale comportamento sebbene sia possibile che nessuna delle nostre esche abbia superato la ricognizione.

Sempre nell’articolo si fa riferimento ad altri malware, tra cui Ursnif, che nel panorama italiano non abbiamo visto associato ad altri malware: Ursnif è un ecosistema a sè!

Inoltre sLoad descritto qui – un campione di febbraio 2022 e simile alle campagne degli ultimi 3 anni – è piuttosto diverso da quello descritto nell’articolo anche se sono presenti non poche somiglianze tanto da stabilire facilmente che si tratta di un’evoluzione del solito malware.

C’è da chiedersi quindi se il gruppo dietro sLoad, che adesso ha cambiato non solo le vittime (solo PEC) ma anche tipo di ricognizione ed i payload usati, sia lo stesso di 3 anni e mezzo fa.

L’affermazione che dietro sLoad ci sia TA554, per quanto possa valere, non sembra trovare conferma online: tutte le fonti sono infatti autoreferenziali, al punto che TA554 sembra associato solo ad sLoad e sembra essere nominato solo nella seconda metà del 2018.