Gli installatori ScreenConnect con trojan rilasciano più RAT su un singolo macchina

Autori: Ilia Dafchev, Eliad Kimhy

• Aumento dell'uso improprio di ScreenConnect: da marzo 2025, Acronis TRU ha rilevato un aumento degli attacchi che sfruttano i programmi di installazione con trojan di ConnectWise ScreenConnect per ottenere l'accesso iniziale alle organizzazioni con sede negli Stati Uniti. Quello che stiamo osservando è una tendenza continua a lungo termine all'uso improprio degli strumenti RMM che continua ad attirare gli aggressori, forse a causa della loro efficacia.

• Programmi di installazione ClickOnce evasivi: gli autori degli attacchi utilizzano ora un programma di installazione ClickOnce runner per ScreenConnect che non ha una configurazione integrata ma recupera i componenti all'avvio. Questa evoluzione rende i tradizionali metodi di rilevamento statico meno efficaci e complica la prevenzione, lasciando le risorse difensive con poche opzioni affidabili.

• Distribuzione automatizzata di Dual-RAT: subito dopo l'installazione di ScreenConnect, gli aggressori utilizzano le sue funzionalità automatiche per distribuire rapidamente due trojan di accesso remoto: il noto AsyncRAT e un RAT personalizzato basato su PowerShell. Questa doppia implementazione può fungere da ridondanza, test degli strumenti o riflettere l'infrastruttura condivisa tra più aggressori.

• PowerShell RAT personalizzato: il team TRU ha scoperto un nuovo RAT autoprodotto, non rilevato sui repository open source, che esegue la ricognizione del sistema, esfiltra i dati tramite Microsoft.XMLHTTP e utilizza diverse tecniche di offuscamento. Il codice di base unico suggerisce che sia stato sviluppato dall'aggressore, potenzialmente per eludere il rilevamento basato sulla firma.

• Catene di infezione in evoluzione: due settimane dopo la violazione, gli aggressori hanno aggiornato la loro catena di infezione utilizzando caricatori batch e VBS che recuperano ed eseguono gli assembly .NET codificati per distribuire AsyncRAT, dimostrando l'adattabilità e l'evoluzione dell'infrastruttura.

• Ingegneria sociale e riuso delle infrastrutture:i programmi di installazione dannosi vengono distribuiti utilizzando nomi di file che imitano documenti ufficiali o finanziari, generalmente tramite phishing. Gli aggressori riutilizzano anche le VM Windows Server 2022 preconfigurate (con nomi host coerenti) in tutte le campagne, consentendo una rapida ridistribuzione e rotazione dell'infrastruttura.

• Punti di forza difensivi: le organizzazioni devono monitorare attentamente l'utilizzo degli strumenti RMM ed esaminare attentamente le implementazioni di ScreenConnect.

Negli ultimi mesi, Acronis TRU (Threat Research Unit) ha identificato diverse campagne attive e in corso che sfruttano le versioni con i trojan di ConnectWise ScreenConnect per ottenere l'accesso iniziale alle reti delle vittime e compromettere le macchine di destinazione. La nostra ricerca mostra che la frequenza di queste campagne è aumentata da marzo 2025 e, al momento, la maggior parte delle aziende vittime si trova negli Stati Uniti, anche se attualmente non vi è alcuna indicazione di dove si trovino gli aggressori.

Sebbene l'uso di ConnectWise ScreenConnect per stabilire un punto d'appoggio iniziale non sia un fenomeno nuovo, queste recenti campagne introducono diversi cambiamenti, come l'implementazione dei programmi di installazione ClickOnce più piccoli invece dei programmi di installazione completi. Questi programmi di installazione ClickOnce sono più evasivi rispetto ai programmi di installazione rilevati in precedenza, in quanto non si basano più sulla configurazione integrata, che a sua volta offre meno opportunità di rilevamento. Una volta installato, gli aggressori sono in grado di ottenere il controllo della macchina compromessa, consentendo d'installare malware aggiuntivo, rubare informazioni, stabilire la persistenza e spostarsi lateralmente attraverso la rete.

L'uso improprio di software RMM (monitoraggio e gestione remota) come ScreenConnect sta diventando sempre più comune, aggiungendosi alla crescente lista di strumenti legittimi riutilizzati per attività dannose. In questi tipi di attacchi, i programmi di installazione di ScreenConnect sono spesso firmati e appaiono come applicazioni affidabili, ma garantiscono all'aggressore un ampio controllo sulla macchina compromessa.

I team IT in genere utilizzano ScreenConnect per accedere da remoto ai sistemi per il supporto o la risposta agli incidenti. Gli aggressori possono utilizzare il software RMM come arma in diversi modi, dallo sfruttamento delle vulnerabilità al cracking o all'uso improprio del prodotto legittimo. In ogni caso, il risultato finale è un eseguibile che collega il computer della vittima a un server controllato dall'aggressore. Gli aggressori possono aspettare giorni o addirittura settimane prima di agire, purché il software RMM dannoso non venga rilevato.

Questa ricerca esamina le recenti campagne che sfruttano ScreenConnect per l'accesso iniziale e descrive in dettaglio il malware distribuito dopo la compromissione. I team di sicurezza possono utilizzare i risultati e i suggerimenti qui delineati per rafforzare le difese e contrastare le minacce simili.

L'attacco inizia con un eseguibile dannoso denominato agreement_support-pdf.Client.exe, che sembra essere stato scaricato tramite il browser Microsoft Edge. Questo file è un programma di installazione ClickOnce, mascherato da un documento di supporto legittimo, un metodo di ingegneria sociale spesso utilizzato per indurre gli utenti a eseguire codice non attendibile. È probabile che l'attacco abbia avuto origine da una campagna di ingegneria sociale, probabilmente diffusa tramite phishing via e-mail, ma forse anche attraverso altri strumenti.

Al termine dell'esecuzione, il programma di installazione avvia ScreenConnect.ClientSetup.exe che, una volta installato, connette la macchina attaccata al server C2 degli aggressori.

Come accennato, questi programmi di installazione differiscono dagli attacchi precedenti che coinvolgono ScreenConnect in quanto utilizzano un programma di installazione ClickOnce Runner. Questa versione del programma di installazione è di dimensioni inferiori e non ha una configurazione incorporata. Piuttosto, si collega direttamente al server ScreenConnect configurato, scaricando i componenti e le configurazioni necessarie per procedere con l'installazione. Questo migliora notevolmente l'evasività dei programmi di installazione. Nelle precedenti iterazioni di questi attacchi, un prodotto di sicurezza poteva cercare codice specifico trovato nella configurazione incorporata per rilevare e bloccare le esecuzioni sospette di ScreenConnect. Tuttavia, nella nuova versione, questo non è più possibile. Gli unici due metodi di prevenzione affidabili rimasti sarebbero l'inserimento del dominio C2 nella blacklist (che è difficile da conoscere in anticipo) o il blocco completo di ScreenConnect.

I ricercatori TRU hanno rilevato l'indirizzo dannoso tramite i parametri d'installazione presenti nel programma. Il programma di installazione è stato eseguito con i parametri: e=Support&y=Guest&h=morco[.]rovider[.]net&p=8041 che si connette a un dominio controllato dall'aggressore, morco.rovider[.]net. Il dominio è stato registrato recentemente ed è ospitato su un server virtuale privato (VPS) associato a stealthrdp[.]com. Ha anche distribuito altre risorse dannose, il che indica che fa parte di una più vasta infrastruttura di campagne malware.

Questo attacco usufruisce in modo improprio di un tipo di programma di installazione in locale per ScreenConnect. Poiché le installazioni in locale devono essere indipendenti dall'infrastruttura cloud, ConnectWise fornisce ai clienti le risorse per configurare un server e i client all'interno della loro rete, senza dover fare affidamento su alcun componente cloud. Questo sistema ha due componenti, un programma di installazione del server e un programma di installazione del client e, nelle applicazioni legittime, il programma di installazione del server verrà configurato con un indirizzo e sarà di conseguenza in grado di creare programmi di installazione per i client.

In questo attacco, gli aggressori hanno probabilmente ottenuto una versione crackata del programma di installazione del server che ha permesso loro di modificare l'indirizzo del server. Questa modifica consente agli aggressori di creare programmi di installazione che si collegano al proprio server ScreenConnect dannoso mentre appaiono legittimi ai prodotti di sicurezza. Senza la conoscenza dell'indirizzo incorporato del server, il rilevamento è difficile.

Con ScreenConnect installato e collegato al server C2 dell'aggressore, si sviluppa un complesso schema di attacco nell'arco di circa due mesi. I ricercatori TRU hanno analizzato la progressione dell'attacco nel tempo e hanno scoperto che l'aggressore distribuiva più RAT contemporaneamente e li utilizzava in modo interscambiabile. Uno era un RAT basato su PowerShell con funzionalità di base, mentre gli altri erano strumenti consolidati e ampiamente utilizzati come AsyncRAT. Questa sovrapposizione rende poco chiaro se sia responsabile un singolo utente malintenzionato o se l'infrastruttura sia condivisa tra più operatori, con l'accesso venduto a più individui che potrebbero non essere a conoscenza l'uno dell'altro.

Mentre ScreenConnect si installa, vengono scaricati due payload in pochi minuti. Ciò è dovuto alla funzionalità di ScreenConnect che consente agli amministratori di definire automazioni specifiche, come l'esecuzione di uno script quando l'utente si connette per la prima volta al server. Ciò consente all'aggressore di installare automaticamente una serie di RAT diversi in pochi minuti dopo l'installazione.

Per il suo primo payload malevolo, l'aggressore utilizza ScreenConnect per rilasciare ed eseguire un file batch, BypaasaUpdate.bat. Questo file batch iniziale funge da downloader e da stager per tutte le fasi rimanenti della prima infezione del payload, scaricando e quindi estraendo dal file zip il contenuto:

• 1.txt- Un file di testo contenente AsyncRAT.

• Pe.txt- Un file di testo contenente un bypass AMSI .NET e uno strumento di persistenza.

• Skype.PS1- Uno script PowerShell per elaborare e caricare i file TXT sopra come assembly .NET.

• b.bat- Uno script batch utilizzato per eseguire lo script PowerShell precedente.

Con i file estratti, viene richiamato per primo b.bat, che a sua volta esegue Skype.ps1. Skype.ps1 carica quindi pe.txt e 1.txt come assembly .NET nella memoria.

Il secondo, 1.txt, è AsyncRAT, un noto e popolare trojan di accesso remoto (RAT) ampiamente utilizzato sia dai penetration tester legittimi che dai criminali informatici, mentre il primo, pe.txt, viene utilizzato sia per aggirare l'AMSI (interfaccia di scansione anti-malware), consentendo così allo script di continuare a eseguire script dannosi, sia per stabilire la persistenza.

La persistenza si ottiene creando un file aggiuntivo denominato Microsoft.vbs, il cui unico scopo è quello di eseguire nuovamente Skype.ps1. Viene quindi creata un'attività pianificata per l'esecuzione di Microsoft.vbs, una sola volta, dopo un minuto. Quando l'attività viene eseguita, Microsoft.vbs esegue nuovamente Skype.ps1, che a sua volta carica AsyncRAT e pe.txt di nuovo, che imposta una nuova attività pianificata dopo un minuto, creando così uno strumento di persistenza in cui ogni minuto AsyncRAT viene ricaricato in memoria e dove viene ricreato l'intero strumento di persistenza.

Anche se ciò significa che Skype.ps1 tenta di caricare AsyncRAT in memoria ogni minuto, 1.txt (noto anche come AsyncRAT) verifica la presenza di un mutex specifico, AsyncMutex_al026, per verificare se AsyncRAT è già in esecuzione e, in caso affermativo, termina. In questo modo AsyncRAT non verrà ricaricato ogni minuto, ma solo quando non è già in esecuzione.

Va anche notato che questo strumento di persistenza è incredibilmente rumoroso. L'esecuzione di uno script di PowerShell ogni minuto lascia un numero enorme di tracce, che gli aggressori correggeranno in una fase successiva dell'attacco.

Pochi minuti dopo il caricamento e la configurazione di AsyncRAT, osserviamo che un altro script viene eliminato ed eseguito da ScreenConnect. Ma mentre il primo script ha rilasciato uno strumento ben noto, AsyncRAT, questo secondo script ha rilasciato un nuovo sorprendente payload: una sorta di RAT autoprodotto. Questo RAT è scritto come uno script PowerShell e fornisce alcune funzionalità di base come l'esecuzione di programmi, il download e l'esecuzione di file e un semplice strumento di persistenza. Non sembra uno strumento open source già visto in passato, ed è stato, forse, scritto dall'aggressore.

Questa è molto probabilmente un'altra esecuzione automatica, il che pone la domanda: perché rilasciare due RAT sulla stessa macchina infetta? Non ci sono risposte chiare, ma ci sono alcune possibilità:

1.      Gli aggressori potrebbero agire con molta cautela. Se uno strumento viene rilevato, un altro potrebbe essere utilizzato per mantenere una backdoor. O forse questo secondo RAT è evasivo in modi diversi dal primo.

2.      Potrebbe essere che gli aggressori stiamo testando un nuovo strumento che stanno sviluppando e hanno deciso di rilasciare entrambi.

3.      Più utenti malintenzionati utilizzano la stessa infrastruttura (o hanno ricevuto l'accesso alla stessa infrastruttura).

Qualunque sia la ragione, vediamo un nuovo indirizzo C2 e abbiamo visto entrambi i RAT utilizzati nelle settimane successive nella nostra analisi dell'attacco.

Anche la catena di attacco sembra più semplice: inizia con un file JavaScript, apparentemente chiamato come la porta dell'indirizzo C2, che viene rilasciato in una cartella temporanea. Lo script esegue quindi essenzialmente l'intero RAT come comando di PowerShell.

Il comando stesso, una volta reso visibile, rivela uno script che agisce come una sorta di RAT autoprodotto: disabilita AMSI, imposta un listener per i comandi, fa alcune ricognizioni iniziali, stabilisce la persistenza e avvia un ciclo infinito che funge da gestore dei comandi.

Lo script esegue innanzitutto la ricognizione del sistema, raccogliendo informazioni relative ai nomi degli antivirus interrogando WMI per i prodotti antivirus installati, nonché il nome e l'architettura del sistema operativo, l'UUID, il nome del computer e il nome utente. Tutto questo viene quindi segnalato al C2 dell'aggressore, utilizzando Microsoft.XMLHTTP, che viene utilizzato anche per carpire i comandi. Si tratta di un utilizzo piuttosto inusuale di questo oggetto COM, in quanto viene utilizzato più comunemente negli script VBS. È possibile che l'aggressore abbia scelto di utilizzare questo comando rispetto a quelli integrati di PowerShell per eludere il rilevamento, poiché molti prodotti di sicurezza cercheranno i comandi di PowerShell che stabiliscono le comunicazioni Internet.

Il gestore dei comandi è composto da un ciclo che invia richieste POST al server C2 ogni tre secondi e aspetta una risposta. Il ciclo esegue quindi i seguenti comandi in base alla risposta:

1.      RF (run file): questo comando consente all'aggressore di scrivere un file binario in una cartella temporanea ed eseguirlo.

2.      TR: riceve il codice PowerShell dall'aggressore, lo scrive su disco come file .ps1 e lo esegue. Inoltre, imposta un strumento di persistenza tramite uno script VBS. Lo script VBS è impostato per l'esecuzione all'avvio tramite la cartella di avvio e serve per avviare lo script di PowerShell. Questo può essere utilizzato per impostare un numero qualsiasi di backdoor aggiuntive o qualsiasi altro script che l'utente malintenzionato potrebbe voler mantenere.

3.      Exc: consente all'aggressore di scrivere uno script VBS in una cartella temporanea ed eseguirlo.

4.      Sc: esegue un'azione simile al comando RF, ma viene utilizzato per scrivere in testo normale e probabilmente per scrivere ed eseguire lo script.

5.      Cl: termina il ciclo e chiude lo script.

6.      Un: termina il ciclo e chiude lo script.

La persistenza viene stabilita creando una copia di 8911.js (il file JavaScript che originariamente avvia lo script RAT) nella cartella di avvio con il nome FirefoxUpdate.js.

Lo script utilizza diverse tecniche di offuscamento per eludere il rilevamento e ostacolare l'analisi. I nomi delle variabili e delle funzioni sono volutamente lunghi, senza senso o non correlati al loro scopo, mentre l'esecuzione dei comandi è nascosta dietro alias calcolati dinamicamente. I payload delle chiavi, ad esempio lo script di persistenza VBS, vengono archiviati come matrici di codice charcode e decodificati solo in fase di esecuzione, mentre il bypass AMSI viene archiviato come assembly .NET con codifica base64. Il gestore dei comandi utilizza codici brevi e criptici (come RF, TR, SC) invece di nomi descrittivi e ai file eliminati vengono assegnati nomi casuali o basati su GUID.

Lo script sfrutta gli oggetti incorporati in Windows, ad esempio Microsoft.XMLHTTP per la comunicazione C2 e Microsoft.VisualBasic.Interaction per la creazione di oggetti, che si fonde con l'attività legittima. I dati di ricognizione del sistema vengono esfiltrati tramite intestazioni HTTP anziché con parametri ovvi e i messaggi di errore vengono eliminati per evitare di attirare l'attenzione. Insieme, queste strategie di offuscamento stratificate rendono più difficile per i prodotti di sicurezza rilevare e prevenire automaticamente il vero comportamento dello script.

Tutto sommato, questo script è abbastanza complicato da vedere, soprattutto perché non siamo riusciti a vederlo utilizzato da nessun'altra parte. Anche se alcune parti del codice sembrano essere state riutilizzate, questo RAT autoprodotto sembra essere stato scritto per la maggior parte dall'aggressore. Questo forse avvantaggia l'aggressore in quanto può mettere a punto lo strumento in base alle proprie esigenze ed evitare il rilevamento basato su modelli o firme specifici e ben conosciuti, mentre d'altra parte potrebbe mancare di alcune delle funzionalità più avanzate offerte da altri strumenti. Si tratta, tutto sommato, di una scoperta interessante e solleva la questione se più di un utente malintenzionato stia utilizzando la stessa infrastruttura.

Due settimane dopo la compromissione iniziale, gli aggressori hanno sfruttato il loro accesso a ScreenConnect per distribuire una nuova versione di AsyncRAT, insieme a una rinnovata catena d'infezione.

La catena di infezione aggiornata inizia con uno script batch che avvia MicrosoftUpdate.vbs, un semplice wrapper per una riga di PowerShell che funge da caricatore. Questo script di PowerShell scarica due file, logs.ldr e logs.ldk, nella directory C:\Users\Public.

Entrambi i file, logs.ldk e logs.ldr, sono assembly .NET codificati. Lo script di PowerShell decodifica ed esegue prima logs.ldk, che è una DLL .NET denominata Obfuscator.dll e ha un duplice scopo: stabilire la persistenza e fungere da caricatore secondario per logs.ldr, il payload AsyncRAT effettivo.

La persistenza si ottiene tramite un'attività programmata denominata “Skype Updater”, configurata per eseguire C:\Users\Public\Ab.vbs all'accesso dell'utente. Questo script VBS rispecchia il comportamento di MicrosoftUpdate.vbs, funzionando come wrapper che richiama il caricatore basato su PowerShell.

AsyncRAT (logs.ldr) viene infine decodificato e caricato in memoria tramite la chiamata al metodo Obfuscator.dll [Obfuscator.A]::Main($f 2) usata dall'interno dello script di PowerShell.

L'istanza di AsyncRAT appena distribuita presentava una configurazione aggiornata. In particolare, utilizzava una nuova stringa mutex: “AsyncMutex_alosh20215” e comunicava con il server di comando e controllo (C2) tramite le seguenti porte: 4501, 4502 e 4503.

L'infrastruttura C2 è rimasta inalterata, ancora su host 185.196.9.158.

Diversi giorni dopo la distribuzione dell'aggiornamento di AsyncRAT, è stato osservato un ulteriore RAT distribuito tramite WMI. L'attività si è verificata pochi minuti dopo l'esecuzione degli script correlati ad AsyncRAT e, sebbene l'attribuzione definitiva non sia possibile con le prove disponibili, la vicinanza temporale suggerisce con forte probabilità che i due possano essere correlati.

È stato osservato il processo WmiPrvSE.exe eseguire un comando PowerShell che utilizzava Invoke-WebRequest per scaricare uno script denominato NvContainerRecovery.ps1 nella directory C:\Users\Public. Subito dopo, lo stesso processo WMI ha richiamato nuovamente PowerShell per eseguire lo script scaricato.

Lo script NvContainerRecovery.ps1 stabilisce la persistenza creando innanzitutto uno script VBS nella cartella di avvio. Questo file VBS funge semplicemente da wrapper per eseguire lo stesso script PowerShell su ogni accesso utente.

Dopo la configurazione della persistenza, lo script di PowerShell carica una DLL .NET che implementa lo svuotamento del processo. Questo metodo viene usato per inserire un altro assembly .NET in un'istanza generata di RegAsm.exe. L'assembly inserito è responsabile della decrittografia e del caricamento di un payload .NET finale, identificato come PureHVNC RAT.

L'istanza di PureHVNC è configurata per connettersi a 169.156.208.185 sulla porta 8020.

Un'indagine sull'infrastruttura di attacco rivela diversi domini che riteniamo possano essere utilizzati dall'aggressore. Questi includono, oltre a morco.rovider.net, altri due domini: gaza.rovider.net e lightc.rovider.net. Entrambi sono correlati ai programmi di installazione di ScreenConnect, con server ospitati su stealthrdp.com. Vengono osservati in relazione a XWorm e DCRat, il che potrebbe indicare un'infrastruttura di attacco più ampia di quella che abbiamo osservato finora.

Abbiamo identificato numerosi casi che coinvolgono l'uso di programmi di installazione ScreenConnect collegati a server locali probabilmente violati. La stragrande maggioranza di questi incidenti si è verificata negli Stati Uniti e i nomi dei file di installazione suggeriscono fortemente la distribuzione tramite phishing o altre tecniche di ingegneria sociale.

Gli eseguibili sono stati in genere nominati in modo da apparire come documenti legittimi, probabilmente per indurre gli utenti a eseguirli. Gli esempi includono:

• Social_Security_Statement_Documents_386267.exe MD5: 2EECA7166487DDC0B4C36B718DF31C93

• ssa_view.exe MD5: C92D37BC45F6088458C70C1CF53C06F6

• Social-Security-Available-Statement-3025147.ClientSetup.exe MD5: BA261666A657BDE2E8E071EE6E7D5357

• agreement_support-pdf.Client.exe MD5: 34ED21AC2399CC08BD051A283FD59FCE

• SSADocumentViewer-nXpJ2.exe MD5: A58719D9DDE0179C25215637766C2AB0

• 2024 BUSINESS SCHEDULE COMPLETE ORGANIZERpdf.exe MD5: 316119C77032A24822A64C86C1E4B2A0

Questo modello di denominazione indica un chiaro tentativo di impersonare documenti ufficiali o finanziari, principalmente a tema di previdenza sociale o di accordi legali.

In questi casi, abbiamo osservato principalmente la distribuzione di AsyncRAT e Remcos RAT.

Per quanto riguarda Remcos, abbiamo identificato che l'autore della minaccia ha riutilizzato la stessa macchina virtuale in più campagne, anche se era ospitata in indirizzi IP diversi. Secondo i risultati di Shodan, la VM eseguiva Windows Server 2022, aveva RDP abilitato e ospitava un server ScreenConnect. Il nome host della macchina era coerente in tutti gli avvistamenti: WIN-BUNS25TD77J.

Raccogliendo ulteriori campioni da fonti di intelligence sulle minacce, abbiamo anche scoperto un altro nome host comune utilizzato in varie campagne: COPY-OF-VM-2022. Sembra che gli aggressori possano avere macchine virtuali preconfigurate che ospitano in indirizzi diversi, consentendo una rapida configurazione e modifica all'infrastruttura.

Rete:

• 169.156.208.185

• 185.196.9.158

• 185.196.8.100

• morco[.]rovider[.]net

• hxxps://eywordvailabom[.]com/sa/16-05.txt

• hxxps://systemwindowsupdate[.]com/alosh/logs.ldk

• hxxps://guilloton[.]fr/x.zip

Mutex:

• AsyncMutex_al026

• AsyncMutex_alosh20215

File:

• agreement_support-pdf.Client

67A32455A94B3396AD956CBDDA81D8ED1CD3727315159E025299057118DEB6AC

• Skype.ps1

BB182B8545B8C825811C6D09C738C230FE54BC96ADF1F10A3683B7E5294B5289

• 1.txt

C260779FB1C9FF775739F6CF1853C9C33131ECF176737F6AF26B0AC60A6081DC

• Pe.txt

53AAD05571E86F22E2C75ED4FA6C8F553C3EBD58DCA8BE9FE8A143784AEF29D7

• BypaasaUpdate.bat

973A02FF597864E3920ED1041D24D629A0762CDE932EB69AEA066CD2235404F8

• Pe.txt decodificato (Amsi Patcher)

1DA9428DF9A04E6CA1D836D1E941B61E30B6AF952D24D7B451A8D1E906ECE0C0

• 1.txt decodificato (AsyncRAT)

E7C482E66EFA99EA98E2C79BEB0A31C5120B73E4951A5F33133066B17E009DA1

• logs.ldr

A4BF71F97C3A2F3FDA496D204B5E744D6F1DA8D888ACE3867DA08D072AF01245

• logs.ldk

6FA549F446A541856784695DB808DE2E5C67DA271C64ECC966C7C0B02622D58B

• Logs.ldr (decodificato)

10EEB21202E7EB055F9FAC37DAB96F86DFEB9F28C0510F33E4324D12087CACF2

• Logs.ldk (decodificato)

6AE546DA4D6D78D4262F3A2FF5E4F58C345294383ED9FF5E4DAA52466FE79E2F

• Powershell RAT

B82E616E956A956FF5D9AFFCC13C907CF5054439FB5EE5A6F7AA5FFEE030DA56

• NvContainerRecovery.ps1

EF66D80511CD46C5173BF13E750C51114EE891E833F4F256A23E7DE4790ACC73

• PureHVNC RAT

068504CB4AC18D504247EF7A2C19A76B17A85E795B52E541FA8A49DE69B91F01