RemoteMonologue: usare DCOM per forzare l'autenticazione NTLM

I giorni in cui si ottenevano facilmente credenziali con Mimikatz stanno, nel bene e nel male, volgendo al termine. Mentre Microsoft rafforza le difese contro il furto delle credenziali e le soluzioni di Rilevamento e risposta degli endpoint (EDR) continuano a progredire, le tecniche tradizionali dei red team come il movimento laterale, l'esecuzione del payload e l'accesso diretto al Local Security Authority Subsystem Service (LSASS) sono sottoposte a un crescente controllo. Di conseguenza, la comunità Red Team è stata costretta a esplorare metodi alternativi per raccogliere credenziali sui sistemi Windows.

Immagina di ottenere risultati confrontabili senza la necessità di un payload "avanzato" o di dover accedere a LSASS, semplicemente "vivendo dei frutti della terra" e sfruttando gli oggetti Component Object Model (COM) sottoutilizzati. Se la cosa ti entusiasma, continua a seguirci, perché questo blog è pieno di trucchi divertenti che potrai usare nel tuo prossimo impegno.

Affronteremo brevemente i fondamenti di COM e della sua controparte distribuita, il Distributed Component Object Model (DCOM), approfondiremo l'ambito RunAs e perché le coercizioni di autenticazione sono efficaci, e presenteremo un nuovo strumento per il recupero delle credenziali: RemoteMonologue.

Il Component Object Model (COM) è una delle tecnologie più vecchie e diffuse di Windows, che opera silenziosamente dietro le quinte delle applicazioni e dei servizi di uso quotidiano. Nonostante la sua età, COM rimane una risorsa preziosa per gli autori degli attacchi, offrendo metodi alternativi per ottenere movimento laterale, escalation dei privilegi e persistenza. Tuttavia, la sua intrinseca complessità ha lasciato gran parte della sua superficie di attacco inesplorata.

Per questo blog, i concetti chiave da comprendere sono:

• COM: una tecnologia base di Windows che consente ai componenti software di interagire tra loro oltre i limiti del processo. COM consente ai programmi di riutilizzare funzionalità di altri programmi senza duplicare funzionalità. Ad esempio, un programma può utilizzare un oggetto COM per leggere i registri di sistema o aggiungere nuove voci a un file Excel, senza implementare queste caratteristiche in prima persona.
• Distributed Component Object Model (DCOM) Un'estensione di COM che consente la comunicazione basata su rete. Con DCOM, un processo in esecuzione su una macchina può richiamare funzioni su un oggetto COM situato su un'altra macchina. Questa funzionalità basata sulla rete ha reso DCOM uno strumento prezioso per il movimento laterale. L'accesso agli oggetti DCOM richiede in genere i privilegi di amministratore locale sul sistema remoto.

A un livello generale, pensa agli oggetti COM come unità autonome con due componenti principali:

• Proprietà: rappresentano lo stato o la configurazione dell'oggetto.
• Metodi: rappresentano azioni che l'oggetto può eseguire. Ad esempio, un oggetto COM potrebbe avere un metodo per lanciare un processo, creare un file o avviare una richiesta di autenticazione.

Gli autori degli attacchi possono abusare di questi metodi per facilitare il movimento laterale e, come illustreremo a breve, costringere le autenticazioni NTLM remote per la decifrazione delle password e gli attacchi a relay.

Prima di addentrarci nella parte divertente, è opportuno analizzare più in dettaglio un componente importante di COM. Un Application Identifier (AppID) in COM funge da meccanismo chiave per gestire la sicurezza, l'identità e il comportamento a tempo di esecuzione delle applicazioni COM, in particolare in scenari che coinvolgono DCOM o applicazioni che richiedono contesti di sicurezza specifici. Quando una classe COM viene registrata con un AppID, eredita le impostazioni di sicurezza definite per quell'AppID.

L'impostazione di sicurezza di particolare interesse è la chiave RunAs, che specifica quale account utente verrà utilizzato per eseguire un oggetto DCOM al momento dell'istanza. La chiave RunAs si trova nel registro sotto:

• HKEY_CLASSES_ROOT\AppID\{AppID_GUID}

Esaminando la documentazione Microsoft su DCOM e la chiave RunAs, è emerso un valore specifico: Interactive User. Questo valore configura l'oggetto DCOM per essere eseguito nel contesto di sicurezza dell'utente attualmente connesso alla sessione console del sistema. Dal punto di vista dell'attacco, questo è interessante perché potrebbe consentirci di utilizzare gli oggetti DCOM per operare come un altro utente senza conoscere le credenziali dell'utente interessato.

Non tutti gli oggetti DCOM con un AppID hanno un valore RunAs impostato su Interactive User. Infatti, circa la metà degli AppID non ha alcun valore RunAs impostato. Ma cosa succederebbe se il valore RunAs potesse essere aggiunto o modificato per adattarlo ai nostri scopi?

Di default, un AppID nel registro è protetto con una Discrezionale Access Control List (DACL), che concede privilegi di proprietà a TrustedInstaller e limita gli amministratori locali all'accesso di sola lettura, come mostrato nella Figura 1.

Tuttavia, agli amministratori locali viene concesso il privilegio SeTakeOwnershipPrivilege, che consente loro di assumere la proprietà degli oggetti di sistema, comprese le chiavi del registro. Questo privilegio è rilevante per questo attacco perché ci permette di cambiare la proprietà di un AppID. Una volta cambiata la proprietà, possiamo assegnarci i permessi di Controllo completo sull'AppID e successivamente modificarne le impostazioni per aggiungere o modificare il valore RunAs.

Una volta che il valore RunAs viene modificato in Interactive User, l'attacco diventa semplice. Questo ci permette di forzare l'esecuzione di un oggetto DCOM nel contesto di un'altra sessione attiva. Tuttavia, il successo di questo attacco dipende in ultima analisi dalle Proprietà e dai Metodi esposti dallo specifico oggetto DCOM preso di mira.

Ora che sappiamo che è possibile convertire un oggetto DCOM in uno strumento di dirottamento sessione, il prossimo passo è identificare quali metodi e proprietà possono essere utilizzati per completare il dirottamento. Per questa ricerca, ho esaminato se fosse possibile raggiungere un compromesso con l'utente senza eseguire un payload, adottando un approccio diverso dalla maggior parte delle tecniche pubbliche di movimento laterale DCOM.

Mi sono concentrato sul raggiungimento di risultati comparabili in un formato "fileless", ovvero senza la necessità di trasferire o eseguire un payload sul sistema di destinazione. Questa distinzione è importante perché il trasferimento e l'esecuzione di payload su un sistema target è spesso considerato un'azione "costosa" nelle operazioni di Red Team. Evitando questo passaggio, il rischio di attivare controlli di sicurezza comuni si riduce significativamente. Pertanto, ho cercato di compromettere gli account utente remoti forzando un'autenticazione NTLM tramite DCOM.

Ci sono diversi vantaggi fondamentali nel forzare le autenticazioni NTLM piuttosto che eseguire le tecniche di movimento laterale tradizionali:

• acquisire gli hash NTLMv1/NTLMv2 e provare a decifrarli offline;
• ritrasmettere gli hash NTLMv1 o WebDAV NTLMv2 ad altri servizi di rete, come LDAP o SMB, per eseguire azioni come utente interessato;
• evitare di trasferire e gestire un payload sul sistema target, che di solito richiede maggiore attenzione dagli strumenti di sicurezza;
• evitare di toccare il processo LSASS, riducendo così i rischi di rilevamento.

Al momento della stesura di questo articolo, la firma LDAP e il channel binding non sono richiesti e applicati di default sulla maggior parte dei controller di dominio. Queste caratteristiche di sicurezza sono obbligatorie solo su Windows Server 2025. Questo significa che, se riusciamo a forzare un'autenticazione NTLMv1 o WebDAV dal sistema target, possiamo reindirizzarla a LDAP e svolgere azioni come utente interessato. Analogamente, la firma SMB non è richiesta di default sui server Windows, tranne che per i controller di dominio.

Un'altra considerazione importante è che gli hash NTLMv1 possono essere facilmente decifrati usando tabelle arcobaleno, che sono state pubblicamente condivise da Nic Losby a dicembre 2024. Queste tabelle riducono drasticamente il tempo e lo sforzo necessari per recuperare le credenziali NTLM dagli hash NTLMv1. Per ottenere un hash NTLMv1 invece di un hash NTLMv2, modifichiamo la seguente chiave del registro sul sistema target:

• HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Impostare LmCompatibilityLevel a un valore pari a 2 o meno costringe il sistema a tornare a NTLMv1 per l'autenticazione. Questa modifica è possibile con privilegi di amministratore locale ed è comunemente definita "attacco di downgrade NetNTLMv1".

In alternativa, possiamo catturare un'autenticazione WebDAV e ritrasmetterla a LDAP, poiché le autenticazioni basate su HTTP possono essere inoltrate a questo servizio. Se il servizio WebClient non è già in esecuzione con accesso privilegiato, possiamo abilitarlo da remoto sul sistema target. Una volta abilitato, possiamo costringere un'autenticazione NTLM WebDAV al nostro listener specificando il nome NetBIOS della macchina nel percorso UNC. Ad esempio:

• \\MYHACKERBOX@80\giveme\creds.txt

Per ulteriori informazioni sugli attacchi NTLM Relay e sui protocolli che possono essere inoltrati a diversi endpoint, fare riferimento alla seguente risorsa qui.

Durante la mia ricerca, ho analizzato l'oggetto DCOM ServerDataCollectorSet, che ha il CLSID {03837546-098B-11D8-9414-505054503030}, per identificare metodi e proprietà che potessero essere utilizzati per forzare l'autenticazione. Una proprietà che si è distinta è stata DataManager e, fortunatamente, questo oggetto COM includeva una libreria di tipi, che definisce i suoi metodi e proprietà in modo più dettagliato.

Usando OleView.NET, ho esaminato la libreria di tipi di ServerDataCollectorSet e ho scoperto che la proprietà DataManager aveva un metodo Extract che prevede due parametri:

1. CabFilename – Il nome di un file CAB da estrarre.
2. DestinationPath – Il percorso per estrarre il contenuto del file CAB.

La presenza del parametro CabFilename era particolarmente interessante perché suggeriva la possibilità di fornire un percorso UNC, che poteva comportare un'azione di autenticazione di rete.

Per testare questa teoria, ho fornito un percorso UNC per il parametro CabFilename che puntava al mio sistema (172.22.164.58) con Responder, come mostrato nella Figura 4. Il risultato? Operazione riuscita. Siamo riusciti ad acquisire un hash NTLMv2, come mostrato nella Figura 5.

Successivamente, ho testato se fosse possibile acquisire le credenziali da un altro utente su un sistema remoto (172.22.166.170) modificando la chiave RunAs del ServerDataCollectorSet. Per raggiungere questo obiettivo, ho utilizzato il servizio di Registro remoto per aggiungere il valore Interactive User per l'AppID {03837503-098B-11D8-9414-505054503030}.

Una volta che un utente diverso aveva effettuato l'accesso nel sistema di destinazione (in questo caso, GALAXY\yoda), accedevo all'oggetto DCOM ServerDataCollectorSet come GALAXY\Administrator ed eseguivo lo stesso metodo Extract mostrato nella Figura 6. Ancora una volta, sono riuscito a ottenere un'autenticazione; tuttavia, questa volta da GALAXY\yoda, come mostrato nella Figura 7. Questo dimostra che la modifica della chiave RunAs in Interactive User ci consente di utilizzare gli oggetti DCOM per dirottare le sessioni di altri utenti.

Questo flusso di attacco è mostrato nel diagramma sottostante.

Un altro interessante oggetto DCOM suscettibile alla forzatura dell'autenticazione è FileSystemImage, che ha il CLSID {2C941FC5-975B-59BE-A960-9A2A262853A5}. Questo oggetto è unico perché la forzatura viene attivata semplicemente modificando una proprietà invece di richiamare un metodo, una tecnica meno comune negli attacchi basati su DCOM.

La proprietà in questione è WorkingDirectory che, per impostazione predefinita, punta alla cartella %TEMP% dell'utente interattivo. Tuttavia, cambiando il valore WorkingDirectory in un percorso UNC che punta al nostro ascoltatore, è possibile acquisire un'autenticazione NTLMv2, come mostrato nelle Figure 9 e 10.

Per convalidare le funzionalità di session hijacking, ho testato questo da remoto impostando la chiave RunAs per l'AppID {2C941FD1-975B-59BE-A960-9A2A262853A5} su Interactive User. Questa configurazione attivava l'esecuzione dell'oggetto DCOM FileSystemImage nel contesto di sicurezza dell'utente attivo sul sistema target. E, come previsto, sono riuscito ad acquisire l'hash NTLMv2 per quell'utente.

Questa tecnica dimostra che le forzature di autenticazione possono essere ottenute modificando le proprietà e i metodi, ampliando così la potenziale superficie di attacco degli oggetti DCOM.

Un ultimo oggetto DCOM che vale la pena condividere è UpdateSession, che ha il CLSID {4CB43D7F-7EEE-4906-8698-60DA1C38F2FE}. Esaminando la sua libreria di tipi, il metodo AddScanPackageService si è distinto perché richiedeva un argomento serviceName e, cosa ancora più interessante, un argomento scanFileLocation . La presenza di scanFileLocation suggeriva che avrebbe potuto accettare un percorso UNC.

Durante il test di questa teoria, siamo riusciti ad acquisire un'autenticazione NTLMv2, ma invece di ricevere le credenziali dell'account utente, abbiamo ricevuto le credenziali dell'account macchina, come illustrato di seguito.

Questa scoperta è particolarmente interessante perché, anche dopo aver aggiunto una chiave RunAs e averla impostata su Interactive User, l'oggetto DCOM UpdateSession continuava a eseguire operazioni di rete come account macchina. Perché succedeva questo? La risposta semplice è che, mentre l'oggetto DCOM stesso funziona nel contesto di sicurezza dell'utente interattivo o dell'istanza, le operazioni di rete sono eseguite da un processo separato: svchost.exe. Il percorso UNC viene consegnato a svchost.exe, che si affida sempre all'account SYSTEM per queste operazioni. Pertanto, l'impostazione della chiave RunAs non influisce su questo comportamento.

Sebbene la chiave RunAs non influenzi l'account utilizzato per le operazioni di rete, la cattura delle credenziali dell'account macchina è comunque preziosa per diversi scenari di attacco:

1. Accesso a permessi DACL interessanti in Active Directory:
   gli account macchina (ad esempio, DOMAIN\MACHINE$) potrebbero avere permessi su specifici oggetti nell'Active Directory che possono essere utili per movimenti laterali o escalation di privilegi.
2. Falsificare i silver ticket per un'ulteriore evasione:
   possiamo utilizzare l'hash NTLM di un account macchina per falsificare un silver ticket, permettendoci di impersonare qualsiasi utente del sistema e di eseguire azioni con un rischio ridotto di rilevamento.

Questo attacco è stato chiamato RemoteMonologue, poiché funziona in modo simile a InternalMonologue, con la principale distinzione che esegue l'attacco a distanza. Lo strumento è stato sviluppato in Python utilizzando la libreria Impacket e automatizza il processo di attacco.

RemoteMonologue offre la possibilità di puntare a uno qualsiasi dei tre oggetti DCOM sopra citati(-dcom) per eseguire la forzatura dell'autenticazione contro un listener specificato(-auth-to). Inoltre, presenta un modulo di spraying (-spray) per convalidare le credenziali su più sistemi, con il beneficio aggiuntivo di acquisire le credenziali. Lo strumento supporta anche un attacco di downgrade NetNTLMv1(-downgrade) e ha un'opzione per abilitare il servizio WebClient per facilitare le autenticazioni HTTP(-webclient). Infine, lo strumento include un modulo di query (-query) per enumerare gli utenti con una sessione attiva sul sistema di destinazione.

Di seguito è mostrato un esempio di esecuzione di RemoteMonologue con l'attacco di downgrade NetNTLMv1 usando Responder come listener. Di default, se non viene specificata alcuna opzione DCOM, lo strumento utilizza l'oggetto DCOM ServerDataCollectorSet.

Di seguito è riportato un altro esempio. Questa volta, l'attacco viene eseguito utilizzando l'oggetto FileSystemImage DCOM e permettendo al servizio WebClient di ottenere un'autenticazione HTTP, che viene poi ritrasmessa a LDAP tramite ntlmrelayx.

Per proteggere e rilevare le tecniche descritte in questo blog, possono essere implementate diverse misure preventive e di rilevamento.

Misure preventive:

1. Abilita la firma LDAP e il channel binding: configura l'applicazione della firma LDAP e il channel binding sui controller di dominio per proteggere l'endpoint LDAP dagli attacchi a relay. Nota: queste impostazioni saranno applicate di default a partire da Windows Server 2025.
2. Aggiorna alle ultime versioni di Windows: aggiorna i server a Windows Server 2025 e le workstation a Windows 11 versione 24H2 per mitigare gli attacchi di downgrade di NetNTLM, poiché NTLMv1 è stato rimosso in queste versioni.
3. Applica la firma SMB: abilita e applica la firma SMB sui server Windows per prevenire gli attacchi relay SMB.
4. Implementare criteri per password complesse: applicare requisiti per password complesse per rendere più difficili gli attacchi di decifrazione delle password.

Opportunità di rilevamento:

1. Monitora l'accesso remoto agli oggetti DCOM: traccia l'accesso agli oggetti DCOM interessati e alle loro proprietà e metodi specifici per identificare attività insolite.
2. Monitora le modifiche del registro: monitora le modifiche alle chiavi del registro RunAs e LmCompatibilityLevel.
3. Monitora l'attività del servizio WebClient: monitora le istanze in cui il servizio WebClient è abilitato da remoto, poiché questo viene utilizzato per facilitare le autenticazioni NTLM basate su HTTP.

L'attacco RemoteMonologue mostra come gli oggetti DCOM poco utilizzati possano essere strumentalizzati per eseguire attacchi di forzatura stealth e di autenticazione fileless. Modificando proprietà specifiche e sfruttando tecniche come il downgrade di NetNTLMv1, gli autori degli attacchi possono compromettere gli account utente e aumentare i privilegi senza dover implementare payload o accedere direttamente a processi sensibili come LSASS.

Concentrandosi sul rafforzamento dei sistemi chiave, ad esempio applicando la firma LDAP, la firma SMB e disabilitando protocolli legacy come NTLMv1, chi si difende può ridurre significativamente la superficie di attacco. Inoltre, un monitoraggio rigoroso delle modifiche al registro, dell'attività DCOM e dei cambiamenti nei servizi remoti può aiutare a rilevare queste tecniche nelle fasi iniziali e mitigarne l'impatto.