Il ritorno dei loader modulari: plugin cifrati AES, COM hijacking e C2 su HTTPS

Il loader segue il paradigma modulare: un componente minimale e furtivo il cui unico compito è stabilire la persistenza, contattare il C2 e scaricare plugin cifrati (AES-256) eseguiti in memoria. La separazione tra stager e moduli riduce la superficie d'analisi: a riposo, sul disco c'è pochissimo.

Catena d'infezione

La catena osservata: documento civetta → sideloading di una DLL dannosa tramite un eseguibile firmato e legittimo (DLL search-order hijacking) → decifratura dello stager → persistenza via COM hijacking → beacon HTTPS verso il C2 con domain fronting.

Pochissimo su disco, quasi tutto in memoria: il loader modulare è progettato per sopravvivere all'analisi statica.

Detection (concetto YARA)

Firma concettuale per la caccia su endpoint — stringhe e pattern tipici dello stager (da adattare al campione reale):

rule UMBRA_Modular_Loader_Generic {
  meta:
    description = "Euristica loader modulare — AES plugin + COM hijack"
    tlp = "CLEAR"
  strings:
    $aes  = { 63 7C 77 7B F2 6B 6F C5 }   // AES S-box (frammento)
    $com  = "Software\\Classes\\CLSID\\" ascii wide
    $ldr  = "LoadLibraryA" ascii
  condition:
    uint16(0) == 0x5A4D and 2 of ($aes,$com,$ldr)
}

Caccia su rete ed endpoint

# COM hijacking: CLSID con InprocServer32 verso path utente (Sysmon ID 13)
TargetObject|contains: '\CLSID\' and '\InprocServer32'
Details|contains: ['\AppData\','\Temp\','\ProgramData\']

# Beacon regolare verso pochi host in HTTPS con intervallo costante
- Analisi di periodicità (beaconing) sui flussi TLS in uscita

Perché conta. Il modello modulare rende il malware un bersaglio mobile: lo stager cambia poco, i plugin cambiano di continuo. La detection efficace si sposta dal file al comportamento — side-loading da path anomali, modifiche COM, beaconing regolare.