In che modo l'interfaccia di analisi antimalware (AMSI) consente di difendersi dal malware

Per un'introduzione all'interfaccia AMSI (Windows Antimalware Scan Interface), vedere Antimalware Scan Interface (AMSI).For an introduction to the Windows Antimalware Scan Interface (AMSI).

Gli sviluppatori di applicazioni possono partecipare attivamente alla difesa da malware. In particolare, è possibile proteggere i clienti da malware basato su script dinamici e da vie non tradizionali di attacco informatico.

Per un esempio, si supponga che l'applicazione sia scriptabile: accetta uno script arbitrario e la esegue tramite un motore di scripting. Quando uno script è pronto per essere fornito al motore di scripting, l'applicazione può chiamare le API AMSI di Windows per richiedere un'analisi del contenuto. In questo modo, è possibile determinare in modo sicuro se lo script è dannoso prima di decidere di procedere ed eseguirlo.

Questo vale anche se lo script è stato generato in fase di esecuzione. Lo script (dannoso o in altro modo) potrebbe superare diversi passaggi di defuscazione. Tuttavia, è necessario fornire al motore di scripting codice semplice e non offuscato. E questo è il punto in cui si richiamano le API AMSI.

Ecco un'illustrazione dell'architettura AMSI, in cui la propria applicazione è rappresentata da una delle caselle "Other Application".

L'interfaccia AMSI di Windows è aperta. Ciò significa che qualsiasi applicazione può chiamarla; e qualsiasi motore antimalware registrato può elaborare il contenuto inviato.

Non è necessario limitare la discussione ai motori di scripting. Forse l'applicazione è un'app di comunicazione e analizza i messaggi istantanei per individuare virus prima che li mostri ai clienti. O forse il software è un gioco che convalida i plug-in prima di installarli. Ci sono molte opportunità e scenari per l'uso di AMSI.

AMSI in azione

Diamo un'occhiata ad AMSI in azione. In questo esempio Windows Defender è l'applicazione che chiama le API AMSI. Tuttavia, è possibile chiamare le stesse API dall'interno della propria applicazione.

Di seguito è riportato un esempio di script che usa la tecnica di codifica XOR per nascondere la finalità (indipendentemente dal fatto che tale finalità sia benigna o meno). Per questa illustrazione, è possibile immaginare che questo script sia stato scaricato da Internet.

Per rendere le cose più interessanti, è possibile immettere questo script manualmente nella riga di comando in modo che non sia presente alcun file effettivo da monitorare. Questo rispecchia ciò che è noto come una "minaccia senza file". Non è semplice come l'analisi dei file su disco. La minaccia potrebbe essere una backdoor che vive solo nella memoria di una macchina.

Di seguito viene visualizzato il risultato dell'esecuzione dello script in Windows PowerShell. Si noterà che Windows Defender è in grado di rilevare l'esempio di test AMSI in questo scenario complicato, semplicemente usando la firma di esempio di test AMSI standard.

Integrazione AMSI con JavaScript/VBA

Il flusso di lavoro illustrato di seguito descrive il flusso end-to-end di un altro esempio, in cui viene illustrata l'integrazione di AMSI con l'esecuzione di macro in Microsoft Office.

• L'utente riceve un documento contenente una macro (dannosa) che evase le analisi software antivirus statiche usando tecniche come offuscamento, file protetti da password o altro.
• L'utente apre quindi il documento contenente la macro (dannosa). Se il documento viene aperto in Visualizzazione protetta, l'utente fa clic su Abilita modifica per uscire da Visualizzazione protetta.
• L'utente fa clic su Abilita macro per consentire l'esecuzione delle macro.
• Durante l'esecuzione della macro, il runtime VBA usa un buffer circolare per registrare [1] dati e parametri correlati alle chiamate alle API Win32, COM e VBA.
• Quando vengono osservate API Win32 o COM specifiche considerate ad alto rischio (note anche come trigger) [2] vengono osservate, l'esecuzione di macro viene interrotta e il contenuto del buffer circolare viene passato ad AMSI.
• Il provider di servizi antimalware AMSI registrato risponde con un verdetto per indicare se il comportamento della macro è dannoso.
• Se il comportamento non è dannoso, l'esecuzione di macro procede.
• In caso contrario, se il comportamento è dannoso, Microsoft Office chiude la sessione in risposta all'avviso [3] e av può mettere in quarantena il file.

Che cosa significa?

Per gli utenti di Windows, qualsiasi software dannoso che usa tecniche di offuscamento e evasione negli host di scripting predefiniti di Windows viene controllato automaticamente a un livello molto più profondo che mai, fornendo livelli di protezione aggiuntivi.

Per gli sviluppatori di applicazioni, valuta la possibilità di chiamare l'interfaccia AMSI di Windows se vuoi trarre vantaggio da (e proteggere i tuoi clienti con) analisi e analisi aggiuntive di contenuti potenzialmente dannosi.

In qualità di fornitore di software antivirus, è possibile prendere in considerazione l'implementazione del supporto per l'interfaccia AMSI. Quando si esegue questa operazione, il motore avrà informazioni più approfondite sui dati che le applicazioni (inclusi gli host di scripting predefiniti di Windows) considereranno potenzialmente dannose.

Altre informazioni generali sulle minacce senza file

Potresti essere curioso di altre informazioni di sfondo sui tipi di minacce senza file che Windows AMSI è progettato per aiutarti a difendersi. In questa sezione esamineremo il tradizionale gioco di gatti e mouse che si svolge nell'ecosistema malware.

Si userà PowerShell come esempio. Ma è possibile sfruttare le stesse tecniche e processi che verranno illustrati con qualsiasi linguaggio dinamico: VBScript, Perl, Python, Ruby e altro ancora.

Ecco un esempio di script di PowerShell dannoso.

Mentre questo script scrive semplicemente un messaggio sullo schermo, il malware è in genere più dannoso. Ma è possibile scrivere facilmente una firma per rilevare questo. Ad esempio, la firma potrebbe cercare la stringa "Write-Host 'pwnd!' in qualsiasi file aperto dall'utente. Grande: abbiamo rilevato il nostro primo malware!

Dopo essere stato rilevato dalla prima firma, tuttavia, autori di malware risponderanno. Rispondono creando script dinamici come questo esempio.

In questo scenario, gli autori di malware creano una stringa che rappresenta lo script di PowerShell da eseguire. Ma usano una semplice tecnica di concatenazione di stringhe per interrompere la firma precedente. Se visualizzi l'origine di una pagina Web ad-laden, vedrai molte istanze di questa tecnica usata per evitare il software di blocco degli annunci.

Infine, l'autore del malware passa questa stringa concatenata al cmdlet, ovvero il Invoke-Expression meccanismo di PowerShell per valutare gli script composti o creati in fase di esecuzione.

In risposta, il software antimalware inizia a eseguire l'emulazione del linguaggio di base. Ad esempio, se vengono visualizzate due stringhe concatenate, si emula la concatenazione di queste due stringhe e quindi si eseguono le firme sul risultato. Sfortunatamente, si tratta di un approccio piuttosto fragile, perché le lingue tendono ad avere molti modi per rappresentare e concatenare stringhe.

Quindi, dopo essere stati rilevati da questa firma, gli autori di malware passeranno a qualcosa di più complicato, ad esempio codificare il contenuto dello script in Base64, come in questo esempio successivo.

Essendo resourceful, la maggior parte dei motori antimalware implementa anche l'emulazione di decodifica Base64. Quindi, poiché implementiamo anche l'emulazione di decodifica Base64, siamo in anticipo per un periodo di tempo.

In risposta, gli autori di malware passano all'offuscamento algoritmico, ad esempio un semplice meccanismo di codifica XOR negli script eseguiti.

A questo punto, in genere abbiamo passato ciò che i motori antivirus emuleranno o rileveranno, quindi non rileveremo necessariamente cosa sta facendo questo script. Tuttavia, è possibile iniziare a scrivere firme in base alle tecniche di offuscamento e codifica. Infatti, questo è ciò che rappresenta la maggior parte delle firme per il malware basato su script.

Ma cosa succede se l'offuscatore è così banale che assomiglia a molti script ben comportati? Una firma per questo genererebbe un numero inaccettabile di falsi positivi. Ecco uno script di stager di esempio troppo dannoso da rilevare autonomamente.

In questo esempio si sta scaricando una pagina Web e richiamando alcuni contenuti da esso. Ecco l'equivalente nello script di Visual Basic.

Ciò che rende peggio in entrambi questi esempi è che il motore antivirus controlla i file aperti dall'utente. Se il contenuto dannoso vive solo in memoria, l'attacco può potenzialmente non essere rilevato.

In questa sezione sono illustrate le limitazioni del rilevamento usando le firme tradizionali. Tuttavia, anche se uno script dannoso potrebbe superare diversi passaggi di defuscazione, in definitiva deve fornire al motore di scripting codice semplice e non offuscato. A questo punto, come descritto nella prima sezione precedente, gli host di scripting predefiniti di Windows chiamano le API AMSI per richiedere un'analisi di questo contenuto non protetto. E l'applicazione può eseguire la stessa operazione.

Risorse correlate

• Minacce senza file
• Office VBA + AMSI: parti del velo su macro dannose
• Fuori dalla vista, ma non invisibile: sconfiggere il malware senza file con monitoraggio del comportamento, AMSI e AV di prossima generazione