Microsoft Exchange, credenziali rubate abusando del modulo IIS: come mitigare il rischio

È in corso una campagna malevola mirata a installare un componente software dannoso ribattezzato “Owowa” sui moduli Outlook Web Access (OWA) di server Microsoft Exchange: l’obiettivo è rubare credenziali di accesso ed eseguire comandi da remoto sui server.

Sulla base dei dati di telemetria diffusi dai ricercatori Kaspersky che hanno isolato le attività della cyber gang, viene sottolineato che gli obiettivi di “Owowa” non sono limitati al sud-est asiatico, ma ci sono segni di infezione anche in Europa.

Owowa: l’antagonista fake di OWA

Owowa è un componente .NET che è stato sviluppato in C# e che viene caricato come modulo all’interno di un web server IIS che espone l’Outlook Web Access (OWA) di Microsoft Exchange (e quanti sono ancora in Italia i moduli OWA attivi? Basta una query sul portale Shodan.io per scoprirlo).

Quando questo modulo viene caricato, Owowa dumperà le credenziali immesse da qualsiasi utente nella pagina di accesso di OWA, consentendo ad un attacker remoto di eseguire comandi sul server sottostante.

Il modulo malevolo contiene un riferimento a un database di debug (PDB) leggibile nella proprietà File, mentre il relativo token della chiave pubblica è impostato su b07504c8144c2a49.

Owowa deve essere avviato come modulo IIS poiché il codice rilevante è inserito nella classe ExtenderControlDesigner, che implementa un’interfaccia specifica di IIS (IHttpModule).

Owowa è progettato specificamente per ispezionare richieste e risposte HTTP, facendo hook dell’evento PreSendRequestContent. Questo evento viene generato quando un’applicazione Web di IIS sta per inviare contenuto al client.

(Fonte: portale Kaspersky).

Owowa si rivolge specificamente alle applicazioni OWA dei server Microsoft Exchange, poiché il suo codice ignora intenzionalmente le richieste dal monitoraggio specifico di OWA dei nomi di account che iniziano con la stringa HealthMailbox.

Il modulo malevolo è progettato per registrare le credenziali degli utenti che si sono autenticati correttamente sulla pagina Web di autenticazione OWA. L’autenticazione viene verificata controllando che l’applicazione OWA stia inviando il token di autenticazione all’utente. In tal caso, il nome utente, la password, l’indirizzo IP dell’utente e il timestamp corrente vengono archiviati nel file C:WindowsTemp af397ef28e484961ba48646a5d38cf54.db.ses.

I dati vengono cifrati utilizzando l’algoritmo RSA, con una chiave pubblica hardcoded archiviata come dato blob XML:

<RSAKeyValue><Modulus>vTxV8wUJ0PoO2yu/Pm/aICbsT+nFwHXouNo623VIVMl6LY4R96a8cpMTHw92rs0foNcVJB8/SYQvL/6Ko9aOv1K3mm3Txa3Dfe6CmDjFb1wYoVJQ+wLksgd/MfMGXWK2rIuNTpUs1+UT1K+TNFSBAYTiiLAPczCmKkh6vcLO9iE=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>

Un attacker potrà interagire con Owowa immettendo da remoto (in un server compromesso) comandi appositamente predisposti all’interno dei campi username e password nella pagina di autenticazione OWA.

Owowa risponderà a questi comandi tramite il server IIS e mostrerà i risultati all’attacker, invece dei messaggi di errore di accesso OWA previsti:

1. se l’username di OWA è jFuLIXpzRdateYHoVwMlfc, Owowa restituirà log delle credenziali cifrate, log codificato in base64;
2. se l’username OWA è Fb8v91c6tHiKsWzrulCeqO, Owowa eliminerà i log delle credenziali cifrate, restituendo la stringa OK (cifrata tramite RSA);
3. se l’username OWA è dEUM3jZXaDiob8BrqSy2PQO1, sul server compromesso verrà eseguito il comando digitato nel campo password utilizzando PowerShell. Il risultato del comando verrà cifrato e restituito all’operatore.

Gestione dei moduli IIS: caricamento, ricerca e rimozione di Owowa

Per tutte le applicazioni compatibili eseguite da un determinato server IIS (incluso OWA), Owowa viene caricato dal seguente script in PowerShell:

[System.Reflection.Assembly]::Load(‘System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’);

$publish = New-Object System.EnterpriseServices.Internal.Publish;

$name = (Get-Item PATHExtenderControlDesigner.dll).FullName;

$publish.GacInstall($name);

$type = ‘System.Web.Extensions.Resource.ExtenderControlDesigner,’ + [System.Reflection.AssemblyName]::GetAssemblyName($name).FullName;

Appcmd.exe add module /name:ExtenderControlDesigner /type:”$type”

Il modulo viene prima registrato nella cache globale, in seguito potrà essere caricato dal server IIS che esegue l’applicazione OWA.

Questa tecnica di configurazione ricorda molto quella utilizzata in precedenza da un threat actor sconosciuto ma descritto da RSA come parte di un’indagine sugli incidenti che coinvolgeva anche moduli HTTP dannosi.

I moduli IIS dannosi, e Owowa in particolare, possono essere identificati utilizzando il comando appcmd.exe o lo strumento di configurazione IIS che elenca tutti i moduli caricati su una determinata istanza del server:

C:WindowsSystem32inetsrv>appcmd.exe list modules | findstr ExtenderControl

MODULE “ExtenderControlDesigner” ( type:System.Web.Extensions.Resource.ExtenderControlDesigner,ExtenderControlDesigner, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b07504c8144c2a49, preCondition: )

Riflessioni utili per la mitigazione del rischio

I ricercatori non sono ancora riusciti a trovare dei collegamenti tra Owowa e i threat actors conosciuti, tuttavia lo sviluppatore dietro Owowa non è riuscito a rimuovere i percorsi PDB nei due campioni identificati, che iniziano entrambi con C:UsersS3crtsourcereposClassLibrary2, suggerendo un nome utente specifico.

Sfruttando questi (i percorsi PDB e il nome utente corrispondente) e altri indizi (che è possibile visionare nella pagina ufficiale del blog di Kaspersky) i ricercatori hanno identificato ulteriori file binari dannosi che potrebbero essere stati sviluppati o impacchettati dallo stesso sviluppatore:

• un loader binario (dal checksum MD5 D4BDFB90D9AA6D573F3FF3A755E2E630) contenente un percorso PDB che condivide un percorso comune con Owowa: C:UsersS3crtsourcereposShellcode_injectReleaseartifact32.pdb;
• un altro loader binario, simile al precedente ma con avente MD5 3C5654DDD7998AE39717F7E3D079BD93;
• un loader binario aggiuntivo (MD5: 3DB7101794CB166CA672814728F4E8D7) che è stato rilevato nel marzo 2021 collegandosi al dominio s3crt[.]biz che ha anche attivato l’esecuzione dei payload Cobalt Strike. Il PDB del caricatore è C:UsersAdministratorsourcereposArtifactx64Aritfact_bigArtifact.pdb, che è simile nella struttura a quelli che coinvolgono s3crt.

Il modulo Owowa rappresenta un’opzione di sabotaggio che costituisce un efficace punto d’appoggio per un attacker, per essere persistente (v. anche APT) all’interno di un server Microsoft Exchange, infatti:

• un modulo IIS rimane persistente su un sistema compromesso anche dopo un aggiornamento di Microsoft Exchange;
• le funzionalità dannose possono essere facilmente attivate inviando richieste dirette apparentemente innocue a servizi Web esposti (in questo caso le richieste di autenticazione all’interfaccia OWA). Richieste dannose come queste, per essere rilevate richiedono la scrittura di regole customizzate per gli IDS (ergo, richiedono la competenza di chi sappia scrivere/personalizzare anche le regex);
• i moduli IIS non sono un formato comune per le backdoor, soprattutto se confrontati con le tipiche minacce delle applicazioni Web (come le shell Web) e possono quindi essere facilmente persi di vista durante le attività di Cyber Detection (soprattutto se appunto gli IDS non vengono istruiti adeguatamente);
• gli attackers possono sfruttare il modulo per rubare passivamente le credenziali degli utenti che accedono legittimamente ai servizi Web, il che rappresenta un’alternativa anche più efficace rispetto alle più classiche tecniche di phishing.

Sebbene il vero autore di Owowa rimanga al momento sconosciuto, le opportunità di sfruttamento di Owowa costituiscono un ulteriore promemoria dell’importanza di verificare anche le configurazioni dei webserver (in questo caso i moduli di IIS) al fine di prevenire compromissioni da remoto.

A tal fine, per chi non avesse già avuto l’opportunità di consultarli per lavoro o per passione, invito alla lettura dei seguenti testi:

• “What does it take to Harden an IIS web server?“, SANS Institute, 2021;
• Threat Visibility and Analytics with NGINX Controller App Security;
• ModSecurity Handbook, seconda edizione;
• Securing Networks Against Unpatchable and Unknown Vulnerabilities Using Heterogeneous Hardening Options, NIST press.