Elastic per analisti della sicurezza. Parte 1: Ricerca di stringhe.
Indice:
Scopo:
Con Elastic che aumenta la propria presenza nello spazio della cybersecurity grazie alla velocità e scalabilità della loro soluzione, ci aspettiamo più nuovi utenti Elastic. Questi utenti si avvicineranno a Elastic armati di un’intuizione costruita dall’esperienza con altre piattaforme e SIEM. Spesso questa intuizione sarà sfidata direttamente dopo alcune ricerche in Elastic. Lo scopo di questa serie è portare gli analisti di sicurezza a velocizzare con le unicità di Elastic. Questo post fornisce ai lettori una guida per costruire ricerche adeguate sui dati stringa in Elastic.Incomprendere come i tipi di dati analizzati Testo e non analizzati Parola chiave influenzano la ricerca dei dati basati su stringa porterà a risultati fuorvianti. Leggendo questo post sarai meglio attrezzato per eseguire ricerche su stringhe che corrispondono alle tue intenzioni analitiche.
Sommario:
- Prima di Iniziare
- Quale Tipo di Dato Stai Usando?
- Riassunto delle Differenze
- Differenza 1: Tokenizzazione e Termini
- Differenza 2: Sensibilità al Maiuscolo/Minuscolo
- Differenza 3: Corrispondenza con i Simboli
Prima di Iniziare:
Lucene
Questo post del blog utilizza Lucene. KQL non supporta ancora le espressioni regolari e ne abbiamo bisogno.
Termini: Tipi di Dati, Mapping e Analizzatori:
Quando si discute come i dati sono archiviati negli indici di Elastic, bisogna essere familiari con i termini Mapping, Tipi di Dati e Analizzatori.
- Tipo di dato – Il “tipo”, “tipo di dato”, o “data type” per cui un valore è archiviato/indicizzato. Esempi di tipi di dati sono: String, Boolean, Integer, e IP. Le stringhe sono archiviate/indicizzate come un “Testo” o “Parola chiave” tipo di dato.
- Mapping – Questa è l’impostazione che assegna (mappa) ogni campo a un tipo di dati. Accessibile tramite l’API get mapping. Quando “si ottiene il mapping” si riceve il campo e il tipo di dati a cui è mappato.
- Analizzatore – prima che i dati stringa siano archiviati/indicizzati, il valore è pre-processato per ottimizzare l’archiviazione e la ricerca. Gli analizzatori aiutano a rendere veloce la ricerca delle stringhe.
Come le Stringhe sono Archiviati:
Ci sono due tipi di dati principali per le stringhe: Parola chiave and Testo.
- Parola chiave – stringhe del tipo Parola chiave sono archiviate come il loro valore grezzo. Nessun analizzatore è applicato.
- Testo – stringhe del tipo Testo sono analizzate. L’analizzatore predefinito e più comune è lo standard (analizzatore di testo). In questo post quando ci riferiamo al tipo di dato “Testo” ci riferiamo al tipo di dato con l’analizzatore standard. Esistono altri analizzatori e sono possibili analizzatori personalizzati. Testo datatype with the standard analyzer. There are other analyzers, and custom analyzers are possible.
Quale Tipo di Dato Stai Usando?
È molto probabile che la tua istanza di Elastic stia usando entrambi i tipi di Testo and Parola chiave dati per stringhe. Tuttavia, lo Schema Comune di Elastic (ECS) e Winlogbeat usano principalmente il tipo di dato Parola chiave .
Anche se utilizzi ECS, gli amministratori possono personalizzare i mapping! Per sapere con certezza come un campo è mappato, dovresti interrogare la tua istanza di Elastic. Per fare questo puoi usare l’API get field mapping o get mapping API. È buona pratica tenersi aggiornati sugli ultimi mapping per i campi che cerchi regolarmente o contro cui hai costruito contenuti. I mapping possono cambiare mentre i nomi dei campi possono rimanere gli stessi. Detto in altre parole, il campo Parola chiave di oggi potrebbe essere un campo Testo domani.
Le differenze degne di nota tra Parola chiave and Testo sono dettagliate nella sezione seguente. Inoltre, ogni differenza che influenzerà i risultati della ricerca sarà esplorata nella loro sezione.
Riassunto delle Differenze
Non ci aspettiamo che tu guardi questa sezione e comprenda immediatamente perché i tipi corrispondano quando lo fanno. Ciascuna delle differenze è ampliata nella propria sezione. Ciascuno degli esempi nelle tabelle è anche inserito in una tabella all’interno della sezione che spiega il comportamento.
Differenze
La seguente tabella fornisce una breve panoramica delle principali differenze nei tipi di dati.
| Differenza | Standard (testo) | Parola chiave |
| Tokenizzato | Diviso in termini (tokenizzato), valore originale perso ma è più veloce | Non tokenizzato, valore originale mantenuto |
| Sensibilità al Maiuscolo/Minuscolo | Insensibile al maiuscolo/minuscolo, ricerche sensibili al maiuscolo/minuscolo non sono possibili | Sensibile al maiuscolo/minuscolo, ricerche insensibili al maiuscolo/minuscolo possibili tramite regex |
| Simboli | Generalmente, caratteri non alfanumerici non sono memorizzati. Ma, conserva caratteri non alfanumerici in determinati contesti | Conserva i caratteri non alfanumerici / Conserva i simboli |
Differenze nel Comportamento
La seguente tabella fornisce esempi del mondo reale su come i tipi influenzano il comportamento delle ricerche.
| Valore Esempio | Query | Corrispondenza Testo | Corrispondenza Parola Chiave |
| Powershell.exe –encoded TvqQAAMA | process.args:encoded | Yes | No |
| Powershell.exe –encoded TvqQAAMA | process.args:/.*[Ee][Nn][Cc][Oo][Dd][Ee][Dd].*/ | Yes | Yes |
| Powershell.exe –encoded TvqQAAMA | process.args:*Powershell.exe*Tvq* | No | Yes |
| TVqQAAMA | process.args:*TVqQAAMA* | Yes | Yes |
| TVqQAAMA | process.args:*tvqqaama* | Yes | No |
| cmd.exe | process.name:cmd.exe | Yes | Yes |
| CmD.ExE | process.name:cmd.exe | Yes | No |
| CmD.ExE | process.name:/[Cc][Mm][Dd].[Ee][Xx][Ee]/ | Yes | Yes |
| \*$* | process.args:*\\*$* | No | Yes |
| \C$WindowsSystem32 | process.args:*C$\* | Yes | Yes |
_
Differenza 1: Analizzatore, Tokenizzazione & Termini
Differenza
| Differenza | Testo (analizzatore standard) | Parola chiave |
| Tokenizzato | Diviso in termini (tokenizzato) | Non Analizzato, Non Tokenizzato. Valore originale mantenuto. |
Perché…?
The Testo il tipo di dato / analizzatore standard usa la tokenizzazione che divide una stringa in pezzi (token). Questi token sono basati su confini di parole (es. uno spazio), punteggiatura e altro.
Ad esempio, se tokenizzassimo la seguente stringa con l’analizzatore standard:“cercare cose con Elastic è semplice”I termini risultanti sarebbero:“cercare” | “cose” | “con” | “elastic” | “è” | “semplice”Nota come tutto sia tokenizzato su spazi (confini di parole), ora è minuscolo e la “s” è stata rimossa da cose.
La tokenizzazione permette la corrispondenza su singoli termini senza contenere o caratteri jolly. Per esempio, se eseguissimo una ricerca per “Elastic” the Testo una stringa di tipo dato contenente “cercare cose con Elastic è semplice” corrisponderebbe. Questo è diverso da altri SIEM che si basano molto su caratteri jolly o logiche ‘contiene’.
Tuttavia, la tokenizzazione si rompe sui caratteri jolly tra i termini. Per esempio, “*cercare*Elastic*” non coinciderebbe con la stringa analizzata standard “cercare con Elastic è semplice”.Nota: Puoi affrontare questo con la prossimità, ma l’ordine non è mantenuto. Per esempio, “cercare Elastic”~1 corrisponderebbe a “cercare con Elastic” e “Elastic con cercare”.
Spesso nella sicurezza abbiamo bisogno di corrispondenza esatta e della capacità di usare caratteri jolly tra i termini. Questo è uno dei motivi per cui il Parola chiave tipo di dato è diventato il tipo di dato de facto in ECS. Per quello che perdi in velocità guadagni la capacità di eseguire ricerche più precise.
Esempi
| Valore Esempio | Query | Corrispondenza Testo | Corrispondenza Parola Chiave |
| Powershell.exe –encoded | process.args:”Powershell.exe –encoded” | Yes | Yes |
| Powershell.exe –encoded TvqQAAMA | process.args:/.*[Ee][Nn][Cc][Oo][Dd][Ee][Dd].*/ | Yes | Yes |
| Powershell.exe –encoded TvqQAAMA | process.args:encoded | Yes | No |
| Powershell.exe –encoded TvqQAAMA | process.args:*Powershell.exe*encoded* | No | Yes |
_
Differenza 2: Sensibilità al Maiuscolo/Minuscolo
Differenza
| Differenza | Testo (analizzatore standard) | Parola chiave |
| Sensibilità al Maiuscolo/Minuscolo | Memorizzato interamente in minuscolo ed è quindi insensibile al maiuscolo/minuscolo. Le ricerche sensibili al maiuscolo/minuscolo non sono possibili. | Sensibile al maiuscolo/minuscolo. Ricerche insensibili al maiuscolo/minuscolo possibili tramite espressioni regolari. |
Perché…?
Problemi di sensibilità al maiuscolo/minuscolo sono una delle principali cause di confusione nel comportamento di Elastic per un analista di sicurezza. Questo è particolarmente vero per il Parola chiave tipo di dato (ciao folla ECS). Un singolo carattere fuori caso in un log può bypassare una query costruita in modo improprio contro i campi Parola chiave . Quando un attaccante controlla parti dei dati che finiscono nei campi Parola chiave (pensa agli eventi Windows 4688 e 4104) dovresti usare espressioni regolari per garantire l’insensibilità al maiuscolo/minuscolo!Inoltre, Elastic non ti avviserà se un documento è stato appena perso a causa di un singolo carattere fuori caso. Pertanto, risultati mancanti o ottenere più risultati del previsto è una delle principali cause di confusione per un analista di sicurezza.
Ecco un esempio di base di corrispondenza contro “PoWeRsHeLl”. Nota come basti un solo carattere fuori caso per impedire alla query di corrispondere.
| Valore Esempio | Query | Corrispondenza Testo | Corrispondenza Parola Chiave |
| PoWeRsHeLl | process.args:PoWeRsHell | Yes | No |
| PoWeRsHeLl | process.args:PoWeRsHeLl | yes | yes |
| PoWeRsHeLl | process.args:/[Pp][Oo][Ww][Ee][Rr][Ss][Hh][Ee][Ll][Ll]/ | yes | Sì (corrisponde a tutti i casi) |
Per un esempio reale in Kibana. Nell’immagine qui sotto, il campo di tipo “process.args” è interrogato per la stringa “windows”. A un analista inconsapevole ciò potrebbe sembrare abbastanza buono… Sono stati restituiti 42 risultati. Bene, se speravano di ottenere qualsiasi documento contenente “windows” si sbagliavano. Poiché la ricerca è sensibile al maiuscolo/minuscolo, quindi “Windows” non combacerebbe. Parola chiave type field “process.args” is queried for the string “windows”. To an unsuspecting analyst this may seem good enough… 42 results were returned. Well if they were hoping to obtain any document containing “windows” they would be wrong. As the search is case sensitive, therefore “Windows” would not match.
Risultati limitati dalla ricerca con distinzione maiuscole/minuscole
Nella query seguente, l’uso di un’espressione regolare per cercare “windows” restituisce opportunamente 567 risultati che erano precedentemente “mancanti”!
Risultati massimi
Si spera che ora sia chiaro che se stiamo cercando usando il tipo Parola chiave e non stiamo usando un’espressione regolare allora perderemo variazioni di “powershell” oltre a una corrispondenza esatta. Sii avvisato di non usare KQL (che non supporta regex) per cercare contro dati che l’attaccante controlla.Nota: ci sono casi d’uso in cui vorrai corrispondenze sensibili al maiuscolo/minuscolo nei campi Parola Chiave come con il base64.Puoi rendere qualsiasi query insensibile al maiuscolo/minuscolo usando i set di caratteri regolari. Ecco degli esempi:
| encoded | /[Ee][Nn][Cc][Oo][Dd][Ee][Dd]/ |
| cmd.exe | /[Cc][Mm][Dd].[Ee][Xx][Ee]/ |
| C:windowssystem32* | /[Cc]:\[Ww][Ii][Nn][Dd][Oo][Ww][Ss]\[Ss][Yy][Ss][Tt][Ee][Mm]32\.*/ |
Esempi
| Valore Esempio | Query | Corrispondenza Testo | Corrispondenza Parola Chiave |
| TVqQAAMA | process.args::*TVqQAAMA* | Yes | Yes |
| TVqQAAMA | process.args:*tvqqaama* | Yes | No |
| cmd.exe | process.name:cmd.exe | Yes | Yes |
| CmD.ExE | process.name:cmd.exe | Yes | No |
| CmD.ExE | process.name:/[Cc][Mm][Dd].[Ee][Xx][Ee]/ | Yes | Yes |
_
Differenza 3: Corrispondenza con i Simboli
Differenza
| Differenza | Testo (analizzatore standard) | Parola chiave |
| Simboli | Generalmente, caratteri non alfanumerici non sono memorizzati. Ma, conserva caratteri non alfanumerici in determinati contesti | Conserva i caratteri non alfanumerici / Conserva i simboli |
Perché?
Tutti i simboli sono mantenuti dal tipo Parola chiave poiché l’intero campo è mantenuto esattamente come i dati sono inseriti (vedi nota). Tuttavia, per l’analizzatore standard, una regola generale da seguire è che i simboli non saranno mantenuti. Questo perché l’analizzatore è stato realizzato per la corrispondenza di parole intere e i simboli non sono parole. Detto in altre parole, i simboli sono (per la maggior parte) non memorizzati nell’analizzatore standard. Quindi, Se intendi corrispondere sui simboli, è meglio usare il Parola chiave tipo di dato, se hai solo un campo di testo e hai bisogno di corrispondere su un gruppo di simboli sei senza fortuna. Tuttavia, ci sono contesti in cui i simboli saranno mantenuti nell’analizzatore standard. Ad esempio, i punti saranno mantenuti in termini come “cmd.exe”. Gli autori hanno scoperto che il modo più semplice per comprendere quando i simboli saranno mantenuti nell’analizzatore standard è semplicemente eseguire dati di test nell’API di analisi.
Esempi
| Valore Esempio | Query | Corrispondenza Testo | Corrispondenza Parola Chiave |
| \*$* | process.args:*\\*$* | No | Yes |
| \C$WindowsSystem32 | process.args:*C$\* | Yes | Yes |
| cmd.exe | process.name:cmd.exe | Yes | Yes |
_
Conclusione
Elastic è uno strumento potente. Tuttavia, può anche essere fuorviante. Speriamo di averti armato con un po’ più di conoscenza e potere per cercare con fiducia contro i dati basati su stringhe.
Se senti di aver bisogno di aiuto per scrivere contenuti per Elastic, il Threat Detection Marketplace di SOC Prime è pieno di contenuti di rilevamento che funzionano con la nostra configurazione Elastic suggerita. Post Futuros
Resta sintonizzato per ulteriori post del blog che esplorano i fondamenti e non solo dei fondamenti dell’uso di Elastic come analista di sicurezza.
Stay tuned for further blog posts exploring the fundamentals & not so fundamentals of using Elastic as a security analyst.
Risorse Aggiuntive per la Ricerca:
Questa serie si concentra sui punti dolenti comuni per gli analisti rispetto all’approfondimento nel tema della sintassi. Elastic fornisce documentazione dettagliata sulla loro sintassi Lucene. Inoltre, ci sono diversi cheat sheet di qualità nella comunità: in particolare di McAndre and di Florian Roth e Thomas Patzke.
Meta:
Pubblicato – Marzo 2020
Ultimo Aggiornamento – 12 Marzo
Autori – Adam Swan (@acalarch) con aiuto da Nate Guagenti (@neu5ron)
Versione Elastic Usata: 7.5.2
Log Usati negli Esempi: https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES
