Domanda Associazione Registri HKCU con applicazioni

[NSteel]

Buonasera,
Ho trovato che dei registri sono associati a delle applicazioni.
Ad esempio il registro Software\Classes\Launcher.SystemSettings\Shell\Open\Command è associato all'applicazione changepk.exe
Mentre il registro Software\Classes\Folder\shell\open\command all'applicazione sdctl.exe
Dato che questi bind li ho ritrovati su internet.. Come faccio a capire, ad esempio, l'applicazione "control.exe" a che registro è abbinato??

Grazie a chiunque mi aiuta!

 

[0xbro]

Tutti i vari registri li puoi ispezionare dal Registry Editor di windows

 

[NSteel]

Tutti i vari registri li puoi ispezionare dal Registry Editor di windows

Grazie mille ma come faccio a capire il registro che utilizza tale comando.
Provo a spiegare meglio: Ad esempio io vado ad injectare il valore "cmd.exe" all'interno del registro HKCU\Software\Classes\Folder\shell\open\command. A questo punto se faccio "start sdctl.exe" non mi apre il programma ma mi apre cmd.exe. La mia domanda è: come hanno fatto a capire che quel registro viene triggerato da sdctl.exe? A tal proposito vorrei capire da quale registro l'applicazione di sistema control.exe viene triggerata

Messaggio unito automaticamente: 9 Marzo 2023

Diciamo che la teoria dietro non l'ho capita e mi piacerebbe scoprire come si fa a dire che sdctl.exe triggera tutti quei registri.. Comunque tralasciando questo e, parlando di cose pratica, perché se vado ad iniettare il valore cmd.exe all'interno del registro HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe quando runno sdctl.exe non mi appare la shell ma il seguente programma?

Invece, se inietto lo stesso valore nel registro HKCU\Software\Classes\Folder\shell\open\command (Il perchè proprio questo? Bho vorrei capirlo - sempre parlando della teoria che ci sta dietro) mi apre il cmd e non il vero programma. Il problema di usare questo al posto di quello sopra è che mi triggera anche Window Defender, cosa che non fa se riuscissi a startarlo dal primo caso

 

[0xbro]

A tal proposito vorrei capire da quale registro l'applicazione di sistema control.exe viene triggerata

Con Process Monitor, un tool della Sysinternal, puoi analizzare tutte le chiamate e i registri invocati da un programma. Non so bene il motivo, non ho mai approfondito bene le internals di Windows ma suppongo che in un caso venga usato un registro e nell'altra caso no. Prova a farci su un po' d'analisi

 

[JunkCoder]

Se la subkey nel registro finisce per \shell\open\command allora hai a che fare con uno shell handler. Questi valori vengono utilizzati da Windows per capire con quale programma aprire determinati tipi di file. 0xbro ha detto bene e la maggior parte dei ricercatori usa procmon per trovare chi accede a quale registro. Nel primo esempio c'è Launcher.SystemSettings, changepk lo usa indirettamente per aprire il pannello di impostazioni di sistema, Folder invece riguarda le cartelle. Di solito questi valori sono utilizzati dall'API ShellExecute ma non è l'unico modo. App Paths invece riguarda le variabili d'ambiente e serve a far trovare eseguibili all'infuori di PATH.

 

[NSteel]

Grazie mille ad entrambi!
L'unica cosa che non riesco proprio a capire è come mai non mi viene triggerato il cmd.exe e mi attiva il normale comportamento, cioè l'applicazione sdctl.exe.
Sostanzialmente ero interessato proprio al path HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe perchè è bypassabile Windows Defender (Dalle guide che ho trovato online). Voi conoscete altre subkey che WD lascia eseguire senza rilevarli come virus???

Se la subkey nel registro finisce per \shell\open\command allora hai a che fare con uno shell handler. Questi valori vengono utilizzati da Windows per capire con quale programma aprire determinati tipi di file. 0xbro ha detto bene e la maggior parte dei ricercatori usa procmon per trovare chi accede a quale registro. Nel primo esempio c'è Launcher.SystemSettings, changepk lo usa indirettamente per aprire il pannello di impostazioni di sistema, Folder invece riguarda le cartelle. Di solito questi valori sono utilizzati dall'API ShellExecute ma non è l'unico modo. App Paths invece riguarda le variabili d'ambiente e serve a far trovare eseguibili all'infuori di PATH.

Con Process Monitor, un tool della Sysinternal, puoi analizzare tutte le chiamate e i registri invocati da un programma. Non so bene il motivo, non ho mai approfondito bene le internals di Windows ma suppongo che in un caso venga usato un registro e nell'altra caso no. Prova a farci su un po' d'analisi

 

[JunkCoder]

Voi conoscete altre subkey che WD lascia eseguire senza rilevarli come virus???

Questa informazione vale più soldi di quelli che pensi. Come ti dicevo nell'altro thread tutti usano UAC bypass pubblici ben noti ai malware developer come a i dev degli antivirus. Per essere veramente invisibile ne devi trovare uno non pubblico e certe entità sarebbero disposte a sborsare parecchi soldi per questa informazione, questo dovrebbe farti capire che non è un compito facile.

perchè è bypassabile Windows Defender (Dalle guide che ho trovato online).

Piano piano se continuerai a provare scoprirai che Defender Cloud inizierà a beccarti dopo un paio di giorni che hai implementato un altro metodo di bypass UAC noto.

L'unica cosa che non riesco proprio a capire è come mai non mi viene triggerato il cmd.exe e mi attiva il normale comportamento, cioè l'applicazione sdctl.exe.

Quello che vedi nello screenshot non è sdclt.exe, è una finestra di explorer.exe! Può sembrarti strano ma su Windows è pieno di queste porcate, quel bypass funziona perché è control.exe ad essere invocato da sdclt e che a sua volta tramite un giro pazzesco apre quella finestra in explorer. La vulnerabilità sfrutta il fatto che tu puoi ingannare sdclt nell'eseguire un altro programma al posto del vero control. Detto questo devi avere ben chiaro in mente come funziona tutto il giro e pensare fuori dagli schemi altrimenti scordati di passare inosservato all'antivirus con un trucco del genere.

 

[NSteel]

Questa informazione vale più soldi di quelli che pensi. Come ti dicevo nell'altro thread tutti usano UAC bypass pubblici ben noti ai malware developer come a i dev degli antivirus. Per essere veramente invisibile ne devi trovare uno non pubblico e certe entità sarebbero disposte a sborsare parecchi soldi per questa informazione, questo dovrebbe farti capire che non è un compito facile.



Piano piano se continuerai a provare scoprirai che Defender Cloud inizierà a beccarti dopo un paio di giorni che hai implementato un altro metodo di bypass UAC noto.



Quello che vedi nello screenshot non è sdclt.exe, è una finestra di explorer.exe! Può sembrarti strano ma su Windows è pieno di queste porcate, quel bypass funziona perché è control.exe ad essere invocato da sdclt e che a sua volta tramite un giro pazzesco apre quella finestra in explorer. La vulnerabilità sfrutta il fatto che tu puoi ingannare sdclt nell'eseguire un altro programma al posto del vero control. Detto questo devi avere ben chiaro in mente come funziona tutto il giro e pensare fuori dagli schemi altrimenti scordati di passare inosservato all'antivirus con un trucco del genere.

Grazie mille, sempre molto esaustivo!
Stavo giocando un pò con process monitor e volevo chiederti una cosa che magari può risultarti banale ma a me ancora no:

Tutti questi path (Subkeys) vengono chiamati da sdclt.exe? Quindi ipoteticamente se io modificassi anche solo un registro con, ad esempio, cmd.exe quando vado a far partire sdclt.exe mi apre una shell? Perchè onestamente ho provato e non funziona.. Mi pareva strano fosse così semplice

 

[JunkCoder]

Ovviamente no, RegOpenKey serve solo ad ottenere un handle per operare in una subkey del registro. RegQueryValue e simili servono ad interrogare un valore contenuto in una subkey. Per essere vulnerabile non basta che apra una key e legga un valore, deve eseguire ciò che è contenuto in un valore che puoi taroccare da medium integrity. La chiamata che eseguirà la tua shell sarà qualcosa come CreateProcess, CoCreateInstance o ShellExecute alla fine dei giochi.

 

[NSteel]

Però allora perchè paradossalmente qua non trovo il path HKCU\Software\Classes\Folder\shell\open\command? eppure sono sicuro al 100% che viene utilizzato da sdclt.exe perchè l'ho testato e funziona! Il problema di questo bypass è che non funziona con "notify always", nè tantomeno con WD attivo

 

[JunkCoder]

Però allora perchè paradossalmente qua non trovo il path HKCU\Software\Classes\Folder\shell\open\command? eppure sono sicuro al 100% che viene utilizzato da sdclt.exe perchè l'ho testato e funziona! Il problema di questo bypass è che non funziona con "notify always", nè tantomeno con WD attivo

è chiaro che non funziona, non c'è alcun paradosso. C'è n'è da studiare su questo argomento e non possiamo coprirlo in un thread. Eseguibili come sdclt ottengono in automatico i privilegi di amministratore senza popup dell'UAC quando il livello non è "notify always". Come fanno? Nel file exe c'è una direttiva nel manifest chiamata "autoElevate" che può essere impostata a true, tuttavia ha valore solo in eseguibili firmati Microsoft. Quando metti notify always quella direttiva viene totalmente ignorata e quindi apparirà sempre il popup, inoltre il tuo hijacking non può più funzionare perché se appare il popup e faccio si ora il processo è high-integrity, quindi leggerà i valori da HKLM invece che da HKCU.

Se provi ad alterare lo shell handler delle folder anche un antivirus del 2000 per windows xp dovrebbe arrabbiarsi, è una tattica vecchia quanto windows e un tempo permetteva di fare più di un UAC bypass. Se non lo vedi in procmon comunque sarà perché è opera di un altro programma invocato da sdclt ad usare quella chiave e i filtri attuali non te lo mostrano (spoiler: è control.exe)

 

[NSteel]

è chiaro che non funziona, non c'è alcun paradosso. C'è n'è da studiare su questo argomento e non possiamo coprirlo in un thread. Eseguibili come sdclt ottengono in automatico i privilegi di amministratore senza popup dell'UAC quando il livello non è "notify always". Come fanno? Nel file exe c'è una direttiva nel manifest chiamata "autoElevate" che può essere impostata a true, tuttavia ha valore solo in eseguibili firmati Microsoft. Quando metti notify always quella direttiva viene totalmente ignorata e quindi apparirà sempre il popup, inoltre il tuo hijacking non può più funzionare perché se appare il popup e faccio si ora il processo è high-integrity, quindi leggerà i valori da HKLM invece che da HKCU.

Grazie mille, del manifest lo sapevo. Infatti ho trovato pure altri binari che utilizzano l'autoelevate.
Quello che non sapevo (e ti ringrazio) è il fatto dei valori tra HKLM e HKCU quindi un processo high-integrity mi leggerà da HKLM.. figo!

Se provi ad alterare lo shell handler delle folder anche un antivirus del 2000 per windows xp dovrebbe arrabbiarsi, è una tattica vecchia quanto windows e un tempo permetteva di fare più di un UAC bypass. Se non lo vedi in procmon comunque sarà perché è opera di un altro programma invocato da sdclt ad usare quella chiave e i filtri attuali non te lo mostrano (spoiler: è control.exe)

Grazie mille!
Ma la domanda cruciale che vorrei porre è: è possibile, in qualche modo bypassare pure windows defender/notify always oppure si ma è un task molto complicato?