Discussione Problema con standalone working VBS script e AMSI

[ReV3rS1ng26]

Buonasera ragazzi, ho un problema con un codice pulito in VBS, pulito nel senso che non triggera virus o altra roba. Cosa fa questo script? E' un container che rilascia ed esegue automaticamente un setup (un .exe arbitrario, in questo caso siccome il codice è in fase di sviluppo ho messo un setup di winrar) senza privilegi, e per di più a maggior riprova che non è un virus potete notare che l'exe viene rilasciato nella stessa folder dove lo script viene eseguito (differentemente dai veri script nefasti, che rilasciano file infetti in folder sperdute in background). Inoltre, nello script non vengono invocate nemmeno variabili pericolose come "vbHide".

Qual è il problema? Lo script sta bene lì dov'è finché non ci clicco sopra, appena lo faccio scatta una detection (di AMSI penso) che fa riferimento alla riga 25 "binaryStream.SaveToFile FilePath", e se provo a cancellare questa stringa lo script viene nuovamente troncato da AMSI alla riga 3 "CreateObject" ecc.
Si tratta di un blocco che ritengo completamente insensato, dal momento che non è uno script nefasto. Come posso aggirare il problema? Le tecniche di scripting in VBS purtroppo non le conosco, so solamente le basi. Il codice ha senso, ma se rimuovo le stringhe identificate come "virus", la logica si rompe e lo script non funziona.

Non riesco neppure ad allegare il file, provate a scaricarlo da qui: https://file.io/atgtAVHShexC
tranquilli che non succede un *azzo a parte ispezionare il codice perché è un .txt, non sono qui per prendere per i fondelli nessuno, ci mancherebbe

 

[0xbro]

Buonasera ragazzi, ho un problema con un codice pulito in VBS, pulito nel senso che non triggera virus o altra roba. Cosa fa questo script? E' un container che rilascia ed esegue automaticamente un setup (un .exe arbitrario, in questo caso siccome il codice è in fase di sviluppo ho messo un setup di winrar) senza privilegi, e per di più a maggior riprova che non è un virus potete notare che l'exe viene rilasciato nella stessa folder dove lo script viene eseguito (differentemente dai veri script nefasti, che rilasciano file infetti in folder sperdute in background). Inoltre, nello script non vengono invocate nemmeno variabili pericolose come "vbHide".

Qual è il problema? Lo script sta bene lì dov'è finché non ci clicco sopra, appena lo faccio scatta una detection (di AMSI penso) che fa riferimento alla riga 25 "binaryStream.SaveToFile FilePath", e se provo a cancellare questa stringa lo script viene nuovamente troncato da AMSI alla riga 3 "CreateObject" ecc.
Si tratta di un blocco che ritengo completamente insensato, dal momento che non è uno script nefasto. Come posso aggirare il problema? Le tecniche di scripting in VBS purtroppo non le conosco, so solamente le basi. Il codice ha senso, ma se rimuovo le stringhe identificate come "virus", la logica si rompe e lo script non funziona.

Non riesco neppure ad allegare il file, provate a scaricarlo da qui: https://file.io/atgtAVHShexC
tranquilli che non succede un *azzo a parte ispezionare il codice perché è un .txt, non sono qui per prendere per i fondelli nessuno, ci mancherebbe

Il file è stato eliminato, utilizza PasteBin per condividere il codice, non dovrebbe dare problemi

 

[ReV3rS1ng26]

E' troppo lungo perché contiene tutto l'exe spacchettato in hex e codificato in base64 per ottimizzare l'esecuzione, proviamo con mediafire

setup

MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.

www.mediafire.com

 

[JunkCoder]

Anche se il file droppato è innoquo resta un pattern molto sospetto per l'anti-virus: creare, scrivere su disco ed invocare un eseguibile (magari non firmato) da wscript.exe è allarme rosso per un buon motivo. Di solito i programmi legittimi non si comportano in questo modo ed è un buon metodo d'attacco e semplice da comporre. Puoi decidere di cambiare metodo oppure di cimentarti nell'evasion e trovare il modo di aggirarlo.

 

[ReV3rS1ng26]

Non puoi indurre qualcuno a cliccare direttamente su un file vbs a meno che non sta veramente messo male, questa cosa fa parte di un progetto più grande.
Poi se pensi che sto facendo attacchi con le macro con questo script ti sbagli, un conto è uno script che sta da solo per "conto suo", ben altro è trovarlo ben nascosto in una macro, lì penso che scatti il blocco e l'eliminazione del file, altro che amsi.

Forse non avete capito che il mio problema non è che lo script viene eliminato, viene semplicemente troncato da AMSI alle righe 3 e 25. E non ne capisco il motivo. Una volta che ci clicco l'esecuzione viene troncata, ma il file rimane lì, nemmeno viene quarantenato. E' palesemente un falso positivo.

L'exe originale pesa 4,0 MB e il mio script ne fa 2,2 esatti. Ho raggiunto il primo obiettivo, ovvero quello di ottimizzare il trasporto comprimendo il contenuto, ma non arrivo alla sostanza (cioè l'esecuzione) per colpa di una vera sciocchezza, mi dispiace.

 

[JunkCoder]

Non volevo insinuare che stai facendo un attacco, ma ci sono attacchi che si comportano in modo identico per cui non mi stupisce che l'av intervenga. Non credo che si tratti di amsi, quello è attivo su powershell ed è un metodo statico di scansione, su wscript invece c'è la protezione realtime del behavior. Ti stupiresti a sapere quante persone cliccano volentieri sui vbs, ma comunque negli attacchi potrebbero essere anche solo una parte in mezzo alla catena di infezione.

Ti ho suggerito di cambiare metodo o fare evasion perché l'unica alternativa è caricare lo script alle case di av segnalandolo come falso positivo e dovresti farlo per ogni modifica (soprattutto se cambi exe embedded) ed essendo una tecnica tanto usata nel male non è detto che lo mettano in whitelist.

 

[ReV3rS1ng26]

No no è AMSI, l'hanno aggiornato. A partire da aprile 2022 è stato integrato sugli script vbs e su Office 365. Non è più come una volta

Messaggio unito automaticamente: 3 Maggio 2022

Real time protection quando interviene prende l'intero file e lo elimina istant, dichiarando il nome della minaccia che ha rilevato, AMSI invece trova una stringa di codice che ritiene nefasta (nel mio caso le 2 dichiarate nel post) e chiede all'antivirus di fermare tutto, tuttavia senza eliminare lo script.

 

[JunkCoder]

Se fosse amsi vedrebbe subito la stringa, non interromperebbe l'esecuzione arrivato a quei punti (righe 3 e 25) ma ben prima di eseguire qualunque istruzione.

La realtime protection vede tramite hooking, callback e minifilter una CreateFile, WriteFile e ShellExecute su quel file (eseguibile) da parte di wscript che viene considerato malevolo e il processo terminato. Infatti nella riga 3 fai la ShellExecute (chiamata internamente dal metodo Run) e alla 25 CreateFile, WriteFile, CloseHandle (chiamate internamente da SaveToFile). Non è detto che l'av elimini il file vbs, potrebbe limitarsi a terminare il processo, dal punto di vista di chi scrive l'antivirus interrompe comunque "l'infezione" e l'ho visto capitare più volte, specie con i file non PE.

Ho fatto una cosa simile un paio di mesi fa e alla fine mi è toccato fare evasion (io tra l'altro scrivevo un PE ma nemmeno lo eseguivo).

PS: aggiungo che il motivo per cui gli AV spesso non eliminano file eseguiti da altri tool è una questione di contesto: la real-time protection per ottenere il percorso al file dovrebbe leggere i command-line arguments nel PEB del processo (wscript) ma essendo quella memoria scrivibile in usermode può essere contraffatta a run-time, in più alcuni programmi hanno opzioni e flag che rendono più complesso parsarla correttamente, per cui per evitare problemi (tipo arbitrary file deletion) si limitano a terminare il processo qualora si ritenga dannoso. Questa cosa non accade con gli eseguibili perché il percorso alla sua immagine non può essere contraffatto.

 

[ReV3rS1ng26]

Veramente non ho capito cosa cerchi esattamente l'AV dal mio script, perché ci ho impacchettato dentro due app diverse (ma entrambe legittime, non infette, e firmate), la prima app è stata troncata alle stringhe che ho già dichiarato, nel secondo caso invece no, ha lasciato buildare l'exe tranquillamente. Entrambi i file firmati con DigiCert. Non so nemmeno io come ho fatto a bypassarlo. Senza i codici sorgenti dell'app non flaggata dall'AV non posso nemmeno capirlo, ho provato a visualizzare comunque il codice con Notepad++ direttamente dall'exe, ma spuntano fuori solo null characters. Rimarrà un mistero.