A partire dal 22 ottobre 2024, il gruppo APT Midnight Blizzard (APT29, UNC2452, Cozy Bear), attribuito al Servizio Intelligence Estero russo (SVR), ha condotto una campagna di spear-phishing su larga scala sfruttando file di configurazione RDP malevoli. Le email, inviate a migliaia di utenti in oltre 100 organizzazioni, impersonavano dipendenti di Microsoft e Amazon Web Services con temi tecnici come "Zero Trust Architecture" e "AWS IAM Quick Start". L'apertura dell'allegato attivava una connessione RDP outbound verso server controllati dagli attaccanti, esponendo risorse locali bidirezionalmente.
- La campagna è iniziata il 22 ottobre 2024 con preparazione infrastrutturale risalente ad agosto 2024, secondo CERT-UA
- I file .RDP erano firmati con certificato Let's Encrypt e configuravano mappatura completa di dischi, stampanti, porte COM, audio e clipboard verso server attaccante
- Amazon ha sequestrato domini abusati che impersonavano AWS, confermando l'obiettivo: furto di credenziali Windows via Microsoft RDP
- I settori target includono governo, accademia, difesa, ONG e IT in UK, Europa, Australia, Giappone e Ucraina
Come funziona l'ingegneria della "fiducia invertita"
La tecnica si distingue per un'inversione pericolosa del paradigma di sicurezza. I certificati Let's Encrypt e i framework Zero Trust sono simboli riconosciuti di protezione digitale. Midnight Blizzard li ha weaponizzati: il certificato firmava file RDP apparentemente legittimi, mentre i temi di phishing sfruttavano la familiarità degli amministratori con questi concetti per abbassare la soglia di attenzione.
L'elemento tecnico critico risiede nella natura stessa del protocollo RDP. A differenza di allegati Office macro-enabled — ormai filtrati aggressivamente dai gateway email — i file .RDP sono configurazioni testuali che Windows interpreta nativamente. L'apertura non richiede exploit: stabilisce semplicemente una connessione verso un endpoint remoto, con la complicazione decisiva della "device and resource redirection".
Secondo CERT-UA e le ricostruzioni tecniche convergenti, la configurazione malevola abilitava accesso a dischi locali, risorse di rete, stampanti, porte COM, dispositivi audio e clipboard. La mappatura era bidirezionale: l'attaccante non solo visualizzava il desktop remoto, ma poteva attingere direttamente ai dati presenti sulla macchina vittima. Le credenziali Windows — incluse smart card, Windows Hello e security keys — risultavano esponibili durante la sessione.
La linea temporale e l'indicatore UAC-0215
CERT-UA ha classificato l'attività con l'identificatore UAC-0215 e documentato una linea temporale precisa. La preparazione infrastrutturale è risalente almeno ad agosto 2024, con registrazione e staging di domini e server. Il 22 ottobre 2024 è iniziata la distribuzione massiva, rilevata quasi in tempo reale da Microsoft Threat Intelligence e dal CERT ucraino.
La geografia di targeting riflette gli interessi storici di APT29: Regno Unito, Europa continentale, Australia, Giappone e Ucraina. I settori — governo, istruzione superiore, difesa, organizzazioni non governative e tecnologia — confermano un pattern di intelligence collection piuttosto che monetizzazione immediata. Non emergono sovrapposizioni infrastrutturali con campagne storiche di FOGGYWEB, MAGICWEB o GraphicalProton nello specifico di questa operazione.
"APT29 sought its targets' Windows credentials through Microsoft Remote Desktop" — CJ Moses, CISO Amazon
La risposta di Amazon e i limiti della visibilità
Il 24 ottobre 2024, CJ Moses ha pubblicato sul blog ufficiale AWS Security la risposta dell'azienda: "we immediately initiated the process of seizing the domains APT29 was abusing which impersonated AWS in order to interrupt the operation". Amazon ha chiarito esplicitamente che né l'azienda né le credenziali dei clienti AWS erano l'obiettivo finale; l'impersonazione era strumentale al furto di credenziali Windows attraverso il protocollo Microsoft.
Il dossier non specifica l'identità dei domini sequestrati né il numero esatto di vittime con accesso effettivamente compromesso. Questo limite è significativo: il sequestro di domini interrompe l'operatività futura su quella infrastruttura, ma non retrocede su sessioni già stabilite né quantifica l'esposizione storica.
Cosa fare adesso
Le fonti primarie convergono su quattro azioni prioritarie:
Bloccare i file .RDP sui gateway email. CISA raccomanda esplicitamente di impedire la distribuzione di allegati Remote Desktop attraverso i filtri del gateway di posta, trattandoli con la stessa severità riservata agli eseguibili.
Restringere le connessioni RDP outbound. Le organizzazioni devono limitare le sessioni RDP in uscita verso endpoint non autorizzati, con particolare attenzione alle configurazioni che abilitano redirect di dispositivi e risorse locali.
Verificare le connessioni RDP nell'ultimo anno. La preparazione infrastrutturale da agosto 2024 e l'inizio campagna a ottobre impongono una finestra di lookback estesa, non limitata ai mesi recenti.
Ispezionare le configurazioni RDP ricevute via email. Anche file apparentemente innocui devono essere analizzati per endpoint nascosti e flag di resource redirection attivati.
Perché questo cambia il perimetro di difesa
La campagna Midnight Blizzard segnala uno spostamento tattico rilevante. Per anni, le difende si sono concentrate su allegati Office, PDF con JavaScript e link a pagine di phishing. La scelta del file RDP aggira questa specializzazione: utilizza un protocollo nativo del sistema operativo, con una catena di trust che parte dal certificato Let's Encrypt e si conclude nell'esecuzione automatica di Windows.
Il vero insight per le redazioni di sicurezza è il gap tra percezione e controllo. Gli utenti vedono un certificato valido e un tema Zero Trust; i sistemi vedono una connessione legittima. Né l'uno né l'altro rilevano la direzione outbound verso un server attaccante, né la mappatura silenziosa di risorse locali. La tecnica non innova il protocollo, ma ne espone le assunzioni implicithe: che chi configuri una connessione RDP sia parte del dominio di trust, e che la direzione della sessione — inbound tradizionale o outbound insidiosa — sia irrilevante per la valutazione del rischio.
Per le organizzazioni enterprise, il messaggio è che il perimetro non è più ciò che filtra l'inbound. È ciò che autorizza l'outbound, con quali risorse, verso chi.
Domande frequenti
Perché i file RDP non vengono bloccati dai filtri antimalware standard?
I file .RDP sono file di configurazione testuali, non eseguibili: non contengono payload binario né macro, e possono risultare invisibili alle firme tradizionali. La minaccia risiede nell'endpoint remoto a cui puntano e nelle opzioni di redirect che attivano.
Il certificato Let's Encrypt è stato revocato o compromesso?
Il dossier non riporta compromissione dell'infrastruttura Let's Encrypt. Il certificato è stato emesso regolarmente e ha funto da meccanismo di trust visivo, non di exploit crittografico.
La campagna è ancora attiva?
Le fonti si riferiscono all'attività di ottobre 2024. Il sequestro dei domini da parte di Amazon ha interrotto quella specifica infrastruttura, ma il dossier non documenta lo stato attuale di eventuali operazioni parallele o riattivazione su nuovi endpoint.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://www.picussecurity.com/resource/blog/understanding-and-mitigating-midnight-blizzards-rdp-based-spearphishing-campaign
- https://www.cisa.gov/news-events/alerts/2024/10/31/foreign-threat-actor-conducting-large-scale-spear-phishing-campaign-rdp-attachments
- https://cert.gov.ua/article/6281076
- https://aws.amazon.com/blogs/security/amazon-identified-internet-domains-abused-by-apt29/
- https://discover.picussecurity.com/start-your-free-trial
- https://cert.gov.ua/