CountLoader emerge come malware loader legato a gang di ransomware russe, distribuito tramite campagne di phishing localizzate che impersonano la polizia ucraina. La catena d’infezione prende di mira ambienti Windows con allegati PDF e archivi .zip che innescano varianti .NET, PowerShell e JScript, capaci di scaricare payload aggiuntivi come Cobalt Strike, Lumma Stealer e componenti di accesso remoto. Le comunicazioni con il C2 sfruttano HTTP con XOR e Base64 per offuscamento, mentre la persistenza si ancora a task pianificati e Run keys di registro per resistere ai riavvii. Telemetrie attribuite da Silent Push indicano campagne attive da giugno 2025, con domini malevoli tra cui ms-team-ping[.]com e infrastrutture tipo app-updater[.]app, che sostengono un modello di beaconing resiliente e provisioning modulare dei componenti. Gli analisti osservano tattiche sovrapponibili a ecosistemi come LockBit, BlackBasta e Qilin, confermando un trend 2025 in cui loader flessibili preparano il terreno a lateral movement, esfiltrazione e cifratura finale. In risposta, i team enterprise puntano su EDR, hunting proattivo e hardening del canale email, mentre processi SBOM e controllo IOC consolidano la difesa in profondità.
Cosa leggere
Catena d’infezione: phishing mirato e lure locali
Le campagne sfruttano email che richiamano verbali, convocazioni o presunte sanzioni della polizia ucraina, includendo allegati PDF e archivi .zip che simulano modulistica ufficiale. L’utente, attratto da messaggi persuasivi e localizzati, sblocca l’esecuzione del loader tramite file .hta, script PowerShell o eseguibili .NET travestiti da documenti. Il flusso impiega redirect e URL dinamici per recuperare componenti di staging, con una sequenza che minimizza l’impronta su disco e privilegia operazioni in memoria.
Il social engineering resta il grimaldello: diciture reali, lessico istituzionale e orari d’ufficio verosimili aumentano il tasso di apertura, mentre la firma dell’ente viene imitata per superare controlli superficiali degli utenti.
Architettura di CountLoader: .NET, PowerShell e JScript
La famiglia CountLoader adotta un’architettura a plugin. La variante .NET funge da orchestratore con funzioni di profilazione dell’host, recupero file da /api/getFile e predisposizione della persistenza tramite task scheduler. La variante PowerShell concentra download e esecuzione riflessiva in poche righe, ideale per aggirare controlli basati su firma o su estensioni vietate. La variante JScript, veicolata via .hta, offre una superficie API più ampia verso WinHTTP, MSXML2, BITSAdmin e utility come certutil e curl, moltiplicando i metodi di trasporto per resistere a blocchi selettivi. Questa ridondanza dei canali di recupero e l’eterogeneità dei linguaggi aumentano la sopravvivenza della campagna in presenza di difese parziali.
Analisi JScript: esecuzione HTA e download multipli
La variante JScript carica file .hta per forzare l’esecuzione tramite mshta.exe, aggirando limitazioni applicate ai frammenti script tradizionali. Prima della fase di fetch, il codice altera parametri di registro per consentire script di grandi dimensioni, quindi attiva una catena di downloader in fallback: WinHTTP, MSXML2, BITS, PowerShell, curl e certutil. Il payload viene collocato in cartelle insolite come Music, scelta che complica i criteri di detection basati esclusivamente su percorsi temporanei standard. La logica del tasking impiega Bearer auth e JSON con campi come TaskType per distinguere il comportamento atteso: dal semplice download all’esecuzione di EXE/DLL, fino a comandi di ricognizione su host domain-joined.
Analisi .NET: helper “twitter1.exe” e API /api/getFile
La variante .NET adotta metadati falsi per apparire legittima e invoca eseguibili ausiliari, come twitter1.exe, per frammentare la catena ed eludere regole statiche. Il dialogo col C2 utilizza endpoint come /connect e /api/getFile per scambiare configurazioni, aggiornare moduli e recuperare payload firmati internamente alla campagna. L’uso sistematico di XOR e Base64 per offuscare stringhe e URL riduce la visibilità nei log, mentre la generazione di Victim ID consente telemetria puntuale per ogni host compromesso. La persistenza si realizza con Run keys e task mascherati da GoogleUpdater o servizi simil-legittimi, garantendo esecuzione a boot.
Analisi PowerShell: loader leggero e staging in memoria
Gli operatori impiegano script PowerShell estremamente concisi, spesso sotto le 20 righe, per costruire loop di contatto con il C2, scaricare binari e avviarli in modalità memory-resident. L’uso di Start-Process, reflection e invocazioni dirette di API Windows minimizza la scrittura su filesystem, degradando l’efficacia di controlli che monitorano solo eseguibili su disco. Lo staging in cartelle utente e l’abuso di Policy di esecuzione rilassate, frequenti in ambienti di sviluppo o amministrazione, permettono rapidità di compromissione e basso profilo.
C2, offuscamento e protocolli: dall’XOR al Bearer
Il canale C2 privilegia HTTP in chiaro con header coerenti a traffico applicativo, mascherando le operazioni come aggiornamenti o scambi legittimi. I payload e i comandi viaggiano offuscati con XOR e successiva Base64, una combinazione leggera che sopravvive bene in proxy e IDS poco sensibili al contenuto. I domini ruotano su pattern come ms-team-ping[.]com con varianti numeriche, mentre asset come app-updater[.]app simulano CDN o servizi di distribuzione. La presenza di Bearer token nella negoziazione fornisce un minimo di statefulness lato server, utile a tracciare lo stato della vittima e imporre task differenziati in base alla postura dell’host.
Persistenza e stealth su Windows enterprise
La persistenza avviene con Scheduled Tasks dai nomi verosimili (per esempio GoogleUpdaterTaskSystem…) e chiavi Run come HKCU\Software\Microsoft\Windows\CurrentVersion\Run\OneDriver, riciclando brand popolari per confondere triage manuale. Il ricorso a mshta.exe per il rilancio del loader, unito a self-deletion condizionale, riduce artefatti post-esecuzione. Il risultato è un impianto silente che sopravvive ai riavvii, conserva beaconing regolare e mantiene aperto il corridoio per payload di seconda fase, inclusi stealer e beacon post-sfruttamento.
Raccolta dati e preparazione al ransomware
CountLoader esegue una ricognizione mirata: raccoglie versione di Windows, architettura, antivirus, hostname, username, gruppi e ruoli di dominio. Su macchine domain-joined enumera Domain Admins, Computers e metadati di rete, utile per pianificare movimenti laterali e valutare la redditività del target. In alcuni scenari comprime directory in archivi per inviarli all’endpoint /archivo, indicando una predisposizione alla esfiltrazione preventiva o al furto di credenziali necessario a privilege escalation. Questo preposizionamento allinea la kill chain a tattiche ransomware moderne, in cui lo stealth iniziale aumenta la leva negoziale nella fase di attacco dichiarato.
Infrastruttura malevola e domini osservati
Oltre a ms-team-ping[.]com, l’infrastruttura comprende asset come app-updater[.]app e varianti numerate, con registrazioni recenti e cicli di fast-flux che complicano l’attribuzione. Gli operatori ruotano IP e host mantenendo costanti le API applicative, un segnale di tooling centralizzato e pipeline automatizzate di deploy. La scelta di stringhe ed endpoint /connect, /api/getFile, /archivo e /respuesta suggerisce una semantica stabile celata da una facciata variabile a livello DNS.
Relazioni con ecosistema ransomware russo
Le TTP di CountLoader convergono con quelle di affiliate russi in ambiti LockBit, BlackBasta e Qilin: loader iniziale flessibile, ricognizione approfondita, beaconing robusto e tool di seconda fase standardizzati (Cobalt Strike, PureHVNC, stealer). Le lure localizzate sull’Ucraina, il calendario giugno–agosto 2025 e l’uso coordinato di domini “enterprise-like” rafforzano la tesi di operatori esperti che riciclano framework collaudati, adattandoli al contesto linguistico e normativo del teatro operativo.
Varianti, kill switch e cronologia 2025
L’osservazione di kill switch basati su date di scadenza o divisioni per zero punta a una gestione controllata dei lotti in circolazione: il codice inattivo limita esposizione e analisi oltre una finestra temporale, stimolando il turnover rapido delle build. Tra giugno e agosto 2025 si registra un susseguirsi di versioni ravvicinate: la .NET con helper dedicati, la PowerShell super-leggera e la JScript più verbosa, ricca di fallback su transport multipli. La tendenza è iterativa: ogni ciclo riduce la superficie di signature e aumenta la resilienza del canale di download.
Indicatori e segnali di compromissione operativi
Gli IOC includono task con nomenclature software-like, chiavi Run denominate come OneDriver, file di staging in cartelle utente non canoniche (ad esempio Music), richieste HTTP verso host ms-team-ping[.]com e domini app-updater con Bearer token. Nel traffico compaiono pattern di Base64 e reply pseudo-applicativi trattati con parsing atipico. In endpoint compromessi, l’EDR rileva mshta.exe in cascata su wscript.exe o rundll32.exe, sequenze che, se correlate, alzano il rischio. La presenza di eseguibili come twitter1.exe e funzioni di self-delete dopo errore aggiunge rumore utile all’hunting.
Mitigazioni tecniche per team enterprise
La riduzione del rischio passa da filtro email con detonazione preventiva di PDF/ZIP, blocco o limitazione dell’uso di mshta.exe e wscript.exe dove non strettamente necessari, e convalida dei contenuti tramite sandbox. La telemetria EDR deve coprire catene mshta → HTA → PowerShell/.NET, correlando process tree, scriptblocks e network in uscita. L’uso di DNS sinkhole e firewall con blocco di domini IOC come ms-team-ping[.]com e famiglie app-updater[.]app interrompe il beaconing e impedisce il second stage. È cruciale l’hardening delle policy PowerShell, imponendo Constrained Language Mode, registrazione ScriptBlockLogging e controllo di AMSI, così da aumentare l’attrito operativo del loader.
Best practice per hardening e detection avanzata
L’adozione di SBOM e verifiche d’integrità sui componenti interni, l’uso di allowlist applicative e la segregazione di account con MFA riducono l’impatto del lateral movement. Regole YARA orientate a XOR+Base64, Bearer auth in contesti non-HTTPS, chiamate a /api/getFile e /archivo, e pattern di staging in cartelle utente, migliorano la copertura del threat hunting. Reportistica SIEM con soglie su mshta.exe, rundll32.exe, wscript.exe e bitsadmin.exe in orari anomali anticipa l’incidente. Back-up offline testati e playbook di isolamento rapido impediscono che CountLoader sfoci in cifratura massiva prima della contenzione. CountLoader incarna il loader contemporaneo: leggero, multi-linguaggio, con fallback di trasporto, persistenza mimetica e telemetria sullo stato della vittima. La combinazione di phishing localizzato, offuscamento minimale e C2 semantico costruisce una kill chain che normalizza il passaggio da ricognizione a impianto di payload come Cobalt Strike e stealer, anticamera di ransomware affiliati. Le difese efficaci non si limitano al blocco del file: servono policy d’esecuzione restrittive, telemetria olistica di processo+rete, sandbox integrate al mail gateway, e playbook di containment automatizzati. In un anno dominato dal ransomware-as-a-service, il valore aggiunto è la visibilità: senza logging script, scheduled tasks e DNS, il loader resta invisibile finché non è tardi. La strategia vincente unisce prevenzione (hardening email e host), rilevazione basata su comportamento e risposta rapida con segregazione e remediation guidata da IOC. In questo equilibrio, ridurre il dwell time del loader significa disinnescare l’intera catena prima che diventi un breach conclamato.
