mthcht/threathunting-keywordsAwesome list di parole chiave e artefatti per sessioni di Threat Hunting
🎯 Elenco di keyword per sessioni di ThreatHunting
Il threat hunting è un approccio proattivo e iterativo per rilevare attività dannose all'interno della rete o dei sistemi di un'organizzazione che potrebbero aver aggirato le misure di sicurezza automatizzate. A differenza delle indagini reattive innescate dagli alert di sicurezza, il threat hunting è guidato da controlli basati sulla threat intelligence (TI) e da ipotesi derivate da un'analisi sistematica e opportunistica. Queste ipotesi 💡 aiutano i cacciatori a scoprire minacce sconosciute, minacce potenziali o minacce note che potrebbero essere sfuggite ai rilevamenti di sicurezza, nonché vulnerabilità o indicatori di compromissione (IoC) che i sistemi automatizzati potrebbero non rilevare o escludere. Il processo si concentra inoltre sull'identificazione dei precursori di alert/dashboard e sul miglioramento dei flussi di lavoro SOC/triage, contribuendo anche alla gestione dell'inventario degli asset shadow e innalzando gli eventi a bassa/media fedeltà che richiedono ulteriori indagini. L'obiettivo principale è identificare le tattiche, le tecniche e le procedure (TTP) utilizzate dagli attori delle minacce, migliorando la capacità dell'organizzazione di rilevare e mitigare preventivamente potenziali attacchi.
La mia proposta di processo per organizzare sessioni di threat hunting parzialmente automatizzate al fine di mantenere regole di rilevamento di alta qualità all'interno di un SOC
I team SOC si concentrano sull'implementazione di rilevamenti ad alta fedeltà a tutti i livelli della Piramide di maturità del rilevamento, prendendo di mira le minacce note con un numero minimo di falsi positivi. Il threat hunting completa questo approccio affrontando minacce sconosciute, TTP avanzate e anomalie soggette a elevati tassi di falsi positivi, colmando le lacune e migliorando la copertura di rilevamento oltre le capacità standard del SOC.
Idealmente, ogni sessione di threat hunting dovrebbe avere obiettivi chiari. Questo diagramma di flusso fornisce un approccio strutturato per guidare il processo, dalla preparazione e l'indagine fino a raccomandazioni attuabili.
🎯 Elenco di keyword per sessioni di ThreatHunting
Le liste ThreatHunting-Keywords possono essere preziose per Threat Hunter, team SOC e CERT per l'analisi statica su SIEM, poiché aiutano a identificare gli attori delle minacce (o redteamers 😆) che utilizzano configurazioni predefinite di noti strumenti di exploit nei log. Si differenzia dai feed IoC per la sua rilevanza duratura: le keyword qui presenti non hanno 'date di scadenza' e possono rilevare minacce anni dopo la loro inclusione; sono flessibili, accettano corrispondenze con wildcard e senza distinzione tra maiuscole e minuscole e sono focalizzate solo su keyword predefinite.
Progettata principalmente per il Threat Hunting, questa lista può essere utile in scenari complessi. Che tu abbia accesso a un SIEM che non gestisci, con dati non parsati, o che tu faccia parte di un team SOC con un SIEM ben gestito, gli esempi forniti qui possono accelerare il processo di rilevamento di attività dannose senza la necessità di parsare nulla. Se i tuoi log sono già parsati, questa lista può essere utilizzata per confrontare i campi all'interno dei tuoi dati, trasformandosi potenzialmente in una regola di rilevamento basata sulla categoria del tipo di keyword selezionata, a condizione che il tasso di falsi positivi sia sufficientemente basso.
⚠️ Non tutto può essere aggiunto in questa lista: qui non creiamo rilevamenti di comportamenti complessi, solo semplici rilevamenti di keyword nei campi o nei log grezzi, finalizzati a individuare configurazioni predefinite
⚠️ Molti strumenti presenti nella lista hanno regole di rilevamento dedicate, che correlano eventi con soglie e relazioni di processo uniche... qui non tratteremo tutti i possibili rilevamenti per uno strumento, solo i rilevamenti tramite keyword
Se fai parte di un Security Operations Center (SOC) e gestisci centinaia di regole di rilevamento che si basano esclusivamente su semplici rilevamenti di keyword senza alcuna correlazione di campi o eventi, valuta di ripensare il tuo approccio. A mio parere, queste non dovrebbero costituire singole regole di rilevamento. Sarebbero invece più adatte a una lista consolidata come questa, anche se l'implementazione potrebbe essere più impegnativa se non utilizzi una piattaforma come Splunk.
Questo approccio incoraggia la creazione di regole di alta qualità e mirate, mantenendo al contempo i tuoi semplici rilevamenti di keyword nei campi organizzati e gestibili in un unico posto. Il risultato? Un'unica regola di rilevamento completa che li copre tutti. Questo snellisce il processo e ottimizza le capacità di rilevamento.
Per gli Incident Responder, puoi usare questa lista durante le indagini su log grezzi o file per identificare rapidamente strumenti di exploit noti con le regole Yara Yara Rules, uno script powershell o caricando rapidamente i tuoi log in Splunk con Splunk4DFIR
Per eludere il rilevamento tramite semplici keyword, è fondamentale ricompilare e rinominare tutte le stringhe personalizzate, i nomi di classi o funzioni, i nomi di variabili, i nomi degli argomenti, i nomi degli eseguibili, gli user-agent predefiniti, i certificati o qualsiasi altra stringa che potrebbe essere associata agli strumenti che stai utilizzando durante l'operazione. Usa i nomi più comuni per tutto per mimetizzarti con il traffico normale. Gli script disponibili qui possono aiutarti a identificare alcuni di questi elementi.
Tuttavia, se sviluppi "strumenti red team" pubblici, valuta di aiutare la blueteam utilizzando nomi distintivi. Impiega una configurazione predefinita con una porta esotica, certificati personalizzati, user-agent unici, nomi di funzioni e argomenti specifici che non siano comuni. Questo aiuta a creare una firma chiara che può essere utilizzata per semplici rilevamenti di keyword, così la blueteam può almeno rilevare facilmente gli script kiddie.
Intestazione: keyword,metadata_keyword_type,metadata_tool,metadata_description,metadata_tool_techniques,metadata_tool_tactics,metadata_malwares_name,metadata_groups_name,metadata_category,metadata_link,metadata_enable_endpoint_detection,metadata_enable_proxy_detection,metadata_tags,metadata_comment,metadata_severity_score,metadata_popularity_score,metadata_github_stars,metadata_github_forks,metadata_github_created_at,metadata_github_updated_at
keyword: Le voci in questa colonna rappresentano keyword non sensibili alle maiuscole/minuscole utilizzate per il Threat Hunting. Queste keyword sono flessibili e consentono l'uso di wildcard per ampliare o restringere i parametri di ricerca secondo necessità.
metadata_keyword_regex: Le voci in questa colonna rappresentano il pattern regex per il rilevamento della keyword; questi pattern sono raffinati per offrire capacità di rilevamento precise, adatte all'uso con YARA, ripgrep o strumenti di rilevamento simili.
metadata_keyword_type: Tipo delle keyword. Attualmente, ci sono tre tipi:
carica la lista threathunting-keywords.csv su Splunk
crea una definizione di lookup chiamata threathunting-keywords per la lookup threathunting-keywords.csv
WILDCARD(keyword) e assicurati che Case sensitive match non sia selezionato
transforms.conf``` [threathunting-keywords] batch_index_query = 0 case_sensitive_match = 0 filename = threathunting-keywords.csv match_type = WILDCARD(keyword)
- ora possiamo usare la nostra definizione di lookup per cacciare 🏹
- :warning: se le ricerche della sezione seguente sembrano non funzionare, potrebbe essere dovuto alle impostazioni di limitazione delle risorse di splunk, soprattutto se stai eseguendo splunk con la configurazione predefinita. Per cominciare, potresti dover considerare di aumentare il valore `max_memtable_bytes` della stanza `[lookup]`.
## Esempi di casi d'uso con `threathunting-keywords`:
### Caccia tutte le keyword nei log grezzi 😱```
`myendpointslogs`
| lookup threathunting-keywords keyword as _raw OUTPUT keyword as keyword_detection metadata_keyword_type metadata_tool metadata_description metadata_tool_techniques metadata_tool_tactics metadata_malwares_name metadata_groups_name metadata_category metadata_link metadata_enable_endpoint_detection metadata_enable_proxy_detection metadata_comment
| search metadata_description!="" AND metadata_enable_endpoint_detection=1
| stats count earliest(_time) as firsttime latest(_time) as lasttime values(_raw) as raw by metadata_keyword_type keyword_detection index sourcetype
| convert ctime(*time)
Send the job to background and keep the job ID.
myendpointslogs è una macro che cercherà in tutti i log dei tuoi endpoint, che potrebbero essere log Windows, telemetria EDR, sysmon, auditd, sessioni bastion, log di esecuzione di PowerShell o qualsiasi altro log che monitora l'attività di processi o file. (se non usi la macro, puoi sostituirla con il tuo indice, tag o datamodel)
TERM() per ricerche specifiche prima della |lookup se necessario| lookup è molto importante: per lookup di grandi dimensioni come questo, usa sempre |lookup invece di |inputlookup. |lookup userà il lookup distribuito sugli indexer quando il bundle viene replicato, mentre |inputlookup invierà agli indexer la ricerca con tutto il contenuto del lookup ogni volta. Usando |lookup otteniamo prestazioni enormemente migliori (questa ricerca verrà eseguita per ore su ambienti di grandi dimensioni, quindi è meglio ottimizzare la nostra ricerca)... keyword as _raw OUTPUT keyword as keyword_detection questa è la parte in cui confronteremo il campo chiamato con il campo nel nostro lookup; in Splunk è il log grezzo senza alcuna analisi (il nostro caso d'uso). Quando una keyword corrisponde, il campo mostrerà la keyword nel lookup che ha corrisposto sul campo ()Filtra il risultato``` | loadjob 1684146257.1495958 | search NOT (keyword_detection IN ("fixme","fixme","fixme")) NOT (metadata_keyword_type IN ("fixme","fixme")) NOT (raw IN ("fixme","fixme","fixme"))
Escludi le parole chiave richieste, il testo grezzo o i tipi di parole chiave.
Se decidiamo di escludere il tipo `greyware tool keyword` (parole chiave di strumenti legittimi che vengono abusate dagli attaccanti) perché questo ambiente ha troppi risultati per questo tipo di strumenti, abbiamo due opzioni:
- Filtrare all'inizio della nostra ricerca iniziale```
`myendpointslogs`
| lookup threathunting-keywords keyword as _raw OUTPUT keyword as keyword_detection metadata_keyword_type metadata_tool metadata_description metadata_tool_techniques metadata_tool_tactics metadata_malwares_name metadata_groups_name metadata_category metadata_link metadata_enable_endpoint_detection metadata_enable_proxy_detection metadata_comment
| search metadata_description!="" metadata_keyword_type="offensive tool keyword" metadata_enable_endpoint_detection=1
| stats count earliest(_time) as firsttime latest(_time) as lasttime values(_raw) as raw by metadata_keyword_type keyword_detection index sourcetype
| convert ctime(*time)
Ho aggiunto un metadata_keyword_type="offensive tool keyword" per concentrarmi solo su strumenti offensivi che sono sicuro vengano usati da attori malintenzionati
Quindi quello era il nostro caso d'uso per cercare nei log grezzi nei log degli endpoint; se vogliamo cercare le parole chiave per i log di rete (qualsiasi cosa che possa registrare una query o un url), lo cambiamo semplicemente in:```
`mynetworklogs`
| lookup threathunting-keywords keyword as _raw OUTPUT keyword as keyword_detection metadata_keyword_type metadata_tool metadata_description metadata_tool_techniques metadata_tool_tactics metadata_malwares_name metadata_groups_name metadata_category metadata_link metadata_enable_endpoint_detection metadata_enable_proxy_detection metadata_comment
| search metadata_description!="" AND metadata_enable_proxy_detection=1
| stats count earliest(_time) as firsttime latest(_time) as lasttime values(_raw) as raw by metadata_keyword_type keyword_detection index sourcetype
| convert ctime(*time)
Ora è uguale alla prima ricerca, ma ho cambiato la datasource per mynetworklogs e aggiunto metadata_enable_proxy_detection=1 per trovare le parole chiave rilevanti per i networklogs (meglio avere log proxy e DNS per questo)
mynetworklogs url=*
| lookup threathunting-keywords keyword as url OUTPUT keyword as keyword_detection metadata_keyword_type metadata_tool metadata_description metadata_tool_techniques metadata_tool_tactics metadata_malwares_name metadata_groups_name metadata_category metadata_link metadata_enable_endpoint_detection metadata_enable_proxy_detection metadata_comment
| search metadata_description!="" AND metadata_enable_proxy_detection=1
| stats count earliest(_time) as firsttime latest(_time) as lasttime values(url) as url by src_ip metadata_keyword_type keyword_detection index sourcetype
| convert ctime(*time)
#### Corrispondenza solo sul campo query:```
`mynetworklogs` query=*
| lookup threathunting-keywords keyword as query OUTPUT keyword as keyword_detection metadata_keyword_type metadata_tool metadata_description metadata_tool_techniques metadata_tool_tactics metadata_malwares_name metadata_groups_name metadata_category metadata_link metadata_enable_endpoint_detection metadata_enable_proxy_detection metadata_comment
| search metadata_description!="" AND metadata_enable_proxy_detection=1
| stats count earliest(_time) as firsttime latest(_time) as lasttime values(query) as query by src_ip metadata_keyword_type keyword_detection index sourcetype
| convert ctime(*time)
myendpointslogs
| eval myfields=mvappend(service, process, process_command, parent_process, parent_process_command, grand_parent_process, grand_parent_process_command, file_path, file_name)
| lookup threathunting-keywords keyword as myfields OUTPUT keyword as keyword_detection metadata_keyword_type metadata_tool metadata_description metadata_tool_techniques metadata_tool_tactics metadata_malwares_name metadata_groups_name metadata_category metadata_link metadata_enable_endpoint_detection metadata_enable_proxy_detection metadata_comment
| search metadata_description!="" AND metadata_enable_endpoint_detection=1
| stats count earliest(_time) as firsttime latest(_time) as lasttime values(process) values(service) values(process_command) values(file_name) values(file_path) values(parent_process) values(parent_process_command) values(grand_parent_process) values(grand_parent_process_command) by metadata_keyword_type keyword_detection index sourcetype
| convert ctime(*time)
#### Velocità:
Se la velocità è un problema o stai pianificando di implementare questo come regola di rilevamento pianificata, potresti prendere in considerazione l'idea di dividere la lookup in lookup diverse scegliendo la colonna metadata_keyword_type o metadata_tool che vuoi usare.
Nota che filtrare usando il comando search dopo la `|lookup` non accelera il processo di ricerca. Se vuoi concentrarti su una porzione specifica della lookup senza dividerla, dovresti usare il comando `|inputlookup` insieme alla clausola where. Anche se questo metodo può consumare più risorse della CPU, generalmente comporta un'esecuzione più rapida. Per maggiori dettagli, consulta la documentazione Splunk su inputlookup: https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Inputlookup
#### Con ELK:
Se lavori con lo Elastic Stack, ci sono molte restrizioni per le liste (non puoi usare caratteri speciali, spazi ...), hai 3 opzioni:
- Usa un'altra lista disponibile qui nello stesso repo https://github.com/mthcht/ThreatHunting-Keywords/tree/main/elk (non è un estratto diretto di threathunting-keywords.csv, è modificata per ELK e non aggiornata)
- Usa le regole Sigma "hunting", estratte direttamente da questo progetto https://github.com/mthcht/ThreatHunting-Keywords-sigma-rules con pysigma per la conversione
- Usa alcune delle mie liste come lista IOC con query wildcard https://www.elastic.co/guide/en/elasticsearch/reference/8.15/query-dsl-wildcard-query.html#wildcard-top-level-params
### Esempio di Dashboard
### Splunk4DFIR
Un altro esempio di utilizzo dei file csv del progetto con splunk per cacciare negli artefatti e nei log DFIR: https://github.com/mf1d3l/Splunk4DFIR
### Altre liste fantastiche per la detection
Conservo alcuni artefatti rilevanti in liste separate; queste liste sono più precise e possono essere usate nelle regole di detection, sono disponibili in questo [repo github](https://github.com/mthcht/awesome-lists/tree/main/Lists)
troverai:
La mia scheda di raccolta intelligence per pianificare sessioni di Threat Hunting
- 📋 Liste: https://github.com/mthcht/awesome-lists/tree/main/Lists
- 🕵️♂️ Guide di Threat Hunting: https://mthcht.medium.com/list/threat-hunting-708624e9266f
- 🚰 Named pipe sospette: [suspicious_named_pipe_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_named_pipe_list.csv)
- 🌐 TLD sospetti (aggiornati automaticamente): [[suspicious_TLDs]](https://github.com/mthcht/awesome-lists/tree/main/Lists/TLDs)
- 🌐 ASN sospetti (aggiornati automaticamente): [[suspicious ASNs]](https://github.com/mthcht/awesome-lists/tree/main/Lists/ASNs)
- 🔧 Servizi Windows sospetti: [suspicious_windows_services_names_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_windows_services_names_list.csv)
- ⏲️ Attività Windows sospette: [suspicious_windows_tasks_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_windows_tasks_list.csv)
- 🚪 Porte di destinazione sospette: [suspicious_ports_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_ports_list.csv)
- 🛡️ Regole firewall sospette: [suspicious_windows_firewall_rules_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_windows_firewall_rules_list.csv)
- 🆔 User-agent sospetti: [suspicious_http_user_agents_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_http_user_agents_list.csv)
- 📇 ID USB sospetti: [suspicious_usb_ids_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_usb_ids_list.csv)
- 🔢 Indirizzi MAC sospetti: [suspicious_mac_address_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_mac_address_list.csv)
- 📛 Hostname sospetti: [suspicious_hostnames_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_hostnames_list.csv)
- 🧮 Metadati degli eseguibili: [executables_metadata_informations_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/Windows%20Metadata/executables_metadata_informations_list.csv)
- 🕸️ Elenco server DNS over HTTPS: [dns_over_https_servers_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/dns_over_https_servers_list.csv)
- 📚 Hijacklibs (aggiornati automaticamente): [hijacklibs_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/Hijacklibs/hijacklibs_list.csv)
- 🌐 Elenchi di nodi TOR (aggiornati automaticamente): https://github.com/mthcht/awesome-lists/tree/main/Lists/TOR
- 🛠️ Elenco LOLDriver (aggiornato automaticamente): [loldrivers_only_hashes_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/Drivers/loldrivers_only_hashes_list.csv)
- 🛠️ Elenco bootloader dannosi (aggiornato automaticamente): [malicious_bootloaders_only_hashes_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/Drivers/malicious_bootloaders_only_hashes_list.csv)
- 📜 Elenco certificati SSL dannosi (aggiornato automaticamente): [ssl_certificates_malicious_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/SSL%20CERTS/ssl_certificates_malicious_list.csv)
- 🖥️ Rilevamento RMM: https://github.com/mthcht/awesome-lists/tree/main/Lists/RMM
- 👤🔑 Ruoli e gruppi importanti per AD/EntraID/AWS: [[permissions]](https://github.com/mthcht/awesome-lists/tree/main/Lists/permissions)
- 💻🔒 Estensioni file note del ransomware: [ransomware_extensions_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/ransomware_extensions_list.csv)
- 💻🔒 Nomi file noti delle note di riscatto del ransomware: [ransomware_notes_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/ransomware_notes_list.csv)
- 📝 Regole ASR di Windows: [windows_asr_rules.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/windows_asr_rules.csv)
- 🌐 Elenchi DNSTWIST (aggiornati automaticamente): [DNSTWIST Default Domains + script](https://github.com/mthcht/awesome-lists/tree/main/Lists/DNSTWIST)
- 🌍 Elenchi di indirizzi IP VPN (aggiornati automaticamente):
- 🛡️ NordVPN: [nordvpn_ips_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/VPN/NordVPN/nordvpn_ips_list.csv)
- 🛡️ ProtonVPN: [protonvpn_ip_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/VPN/ProtonVPN/protonvpn_ip_list.csv)
- 🏢 Elenchi di intervalli IP delle aziende (aggiornati automaticamente): [Default Lists + script](https://github.com/mthcht/awesome-lists/tree/main/Lists/Ranges_IP_Address_Company_List/bgp.he.net)
- 🔗 Altre liste di correlazione: https://github.com/mthcht/awesome-lists/tree/main/Lists/Others
- 📋 Liste che devo completare: https://github.com/mthcht/awesome-lists/tree/main/todo
Dai un'occhiata a queste [Guide](https://github.com/mthcht/awesome-lists/tree/main/Lists#how-to-use-the-lists) per usare alcune delle liste:
- [Ricerche sui servizi Windows](https://detect.fyi/threat-hunting-suspicious-windows-service-names-2f0dceea204c)
- [Ricerche sugli User-Agents](https://mthcht.medium.com/threat-hunting-suspicious-user-agents-3dd764470bd0)
- [Ricerche su DNS Over HTTPS](https://mthcht.medium.com/detecting-dns-over-https-30fddb55ac78)
- [Ricerche sui TLD sospetti](https://mthcht.medium.com/threat-hunting-suspicious-tlds-a742c2adbf58)
- [Ricerche su HijackLibs](https://mthcht.medium.com/detect-dll-hijacking-techniques-from-hijacklibs-with-splunk-c760d2e0656f)
- [Ricerche su Phishing & DNSTWIST](https://detect.fyi/detecting-phishing-attempts-with-dnstwist-37c426b3bbb8)
- [Ricerche sulle estensioni dei browser](https://mthcht.medium.com/detecting-browser-extensions-installations-e0ac2b45c46b)
- [C2 nascosto in bella vista](https://mthcht.medium.com/c2-hiding-in-plain-sight-7a83963b9344)
- [Artefatti di HTML Smuggling](https://mthcht.medium.com/detecting-html-smuggling-phishing-attempts-15af824e60e4)
- [Ricerche su PSEXEC e strumenti simili](https://mthcht.medium.com/detecting-psexec-and-similar-tools-c812bf3dca6c)
- [Rilevamento del Time Slipping](https://mthcht.medium.com/event-log-manipulations-1-time-slipping-55bf95631c40)
- [Named pipe sospette](https://medium.com/detect-fyi/threat-hunting-suspicious-named-pipes-a4206e8a4bc8)
... altri [qui](https://github.com/mthcht/awesome-lists/tree/main/Lists#how-to-use-the-lists)
## Caccia DFIR alle parole chiave nei file (senza SIEM)
Dopo un'attenta revisione di vari strumenti, ho scoperto che [ripgrep](https://github.com/BurntSushi/ripgrep) supera significativamente i suoi concorrenti quando si tratta di confrontare rapidamente un'ampia lista di pattern regex con ogni riga di un grande file di log o anche di più file contemporaneamente. Si è rivelato la soluzione più efficiente per gestire enormi quantità di dati, offrendo velocità e flessibilità senza pari.
### Caccia al male nei file di log con **Ripgrep** e la lista 'only_keywords_regex.txt'
#### `rg.exe -f .\only_keywords_regex.txt .\EvtxECmd_Output.csv --multiline --ignore-case`
- .\only_keywords_regex.txt funge da file sorgente per le parole chiave di threat hunting, trasformate in pattern regex per un abbinamento preciso. Questi pattern provengono dal file threathunting-keywords.csv, che ha subito un processo di conversione per una compatibilità ottimale con le operazioni regex.
- .\EvtxECmd_Output.csv rappresenta il file di destinazione in cui verrà effettuata la ricerca. In questo contesto, è un formato .csv di un log eventi di Windows, prodotto esportando i log evtx. Tuttavia, la flessibilità di ripgrep ti consente di sostituirlo con qualsiasi file tu scelga per operazioni di ricerca dettagliata di pattern.
- L'opzione --multiline consente a ripgrep di gestire e abbinare efficacemente pattern che si estendono su più righe, ampliando significativamente l'ambito della ricerca.
Otterrai le righe corrispondenti in questo modo con il numero di riga (ma senza la parola chiave corrispondente)
#### Opzione migliore per file molto grandi (su Windows):
[DFIR_hunt_in_file.ps1](https://github.com/mthcht/ThreatHunting-Keywords/blob/main/DFIR_hunt_in_file.ps1)
`powershell -ep Bypass -File .\DFIR_hunt_in_file.ps1 -patternFile "only_keywords_regex.txt" -targetFile "C:\Users\mthcht\collection\20230406154410_EvtxECmd_Output.csv" -rgPath "C:\Users\mthcht\Downloads\ripgrep-13.0.0-x86_64-pc-windows-msvc\ripgrep-13.0.0-x86_64-pc-windows-msvc\rg.exe"`
- `-targetFile`: specifica il file in cui cercare (nell'esempio, un estratto di log DFIR-ORC)
- `-patternFile`: il file contenente i pattern regex `only_keywords_regex.txt`
- `-rgPath`: il percorso dell'eseguibile di ripgrep
contenuto dello script powershell (incluso nel repo):```powershell
param (
[Parameter(Mandatory=$true)]
[string]$patternFile,
[Parameter(Mandatory=$true)]
[string]$targetFile,
[Parameter(Mandatory=$true)]
[string]$rgPath
)
Start-Transcript -Path "$PSScriptRoot\result_search.log" -Append -Force -Verbose
$totalLines = (Get-Content $patternFile | Measure-Object -Line).Lines
$currentLine = 0
Get-Content $patternFile | ForEach-Object {
$currentLine++
Write-Host "Searching for pattern $currentLine of $totalLines : $_"
& $rgPath --multiline --ignore-case $_ $targetFile | Write-Output
}
Stop-Transcript -Verbose
Il risultato della ricerca sarà in result_search.log nella stessa directory dello script.
todo
In powershell è molto più lento, ma se vuoi comunque farlo in questo modo, puoi usare lo script qui sotto: ti dirà il numero di riga corrispondente e la parola chiave corrispondente:
powershell.exe -ep Bypass -File .\hunt_keywords_windows.ps1 -k .\only_keywords.txt -f .\EvtxECmd_Output.csv
[Parameter(Mandatory=$true)]
[string]$kw
)
$Keywords = Get-Content $kw $result = @()
foreach ($Keyword in $Keywords) { $SearchTerm = $Keyword.Replace("", ".") $SearchTerm = [Regex]::Escape($SearchTerm).Replace(".*", ".*")
$reader = New-Object System.IO.StreamReader($file)
$lineNumber = 0
while (($line = $reader.ReadLine()) -ne $null) {
$lineNumber++
if ($line -match $SearchTerm) {
$result += New-Object PSObject -Property @{
'Keyword' = $Keyword
'LineNumber' = $lineNumber
'Line' = $line
}
}
}
$reader.Close()
}
$result | Out-GridView Read-Host -Prompt "Press Enter to exit"
</details>
### Regole YARA
Tutti i pattern di rilevamento di questo progetto vengono automaticamente esportati in regole yara in [ThreatHunting-Keywords-yara-rules](https://github.com/mthcht/ThreatHunting-Keywords-yara-rules)
Qualche esempio di hunting con le regole yara:
## Tabella dati rapida per la ricerca di parole chiave
https://mthcht.github.io/ThreatHunting-Keywords/
## Falsi positivi
Contribuisci e aggiungi i tuoi falsi positivi alla [lista](https://github.com/mthcht/ThreatHunting-Keywords/blob/main/_false_positives/false_positives_offensive_keywords.md) dei falsi positivi attesi
## Regole SIGMA
Dai un'occhiata alla lookup tradotta in [regole SIGMA](https://github.com/mthcht/ThreatHunting-Keywords-sigma-rules) di solito la aggiorno allo stesso tempo :)
## Mappatura delle tecniche MITRE ATT&CK
con l'addon splunk https://splunkbase.splunk.com/app/5742
Copertura per 2242 strumenti (aggiornata il 2024/08/30):
ricerca splunk:
<details>```
| inputlookup threathunting-keywords.csv
| stats count by metadata_tool metadata_tool_techniques
| makemv delim=" - " metadata_tool_techniques
| mvexpand metadata_tool_techniques
| stats count by metadata_tool_techniques
Dashboard Splunk (questo è solo un esempio; è possibile applicare un'ampia varietà di filtri utilizzando i campi disponibili nel file):
esempio di dashboard XML di Splunk:
Contributi, segnalazioni di problemi e richieste di funzionalità sono benvenuti!
``
Fornisci il nome dello strumento.
``
Fornisci un collegamento al sito web ufficiale dello strumento o al repository del codice sorgente (GitHub, GitLab, ecc.). Se è disponibile documentazione, includila.
``
Descrivi lo scopo, le funzionalità e le caratteristiche principali dello strumento. Se non sei sicuro, lascia vuoto questo campo e analizzerò lo strumento più in dettaglio.
``
Se disponi di informazioni su un uso noto o un potenziale uso improprio di questo strumento da parte di attori malintenzionati, condividile qui.
Scegli la categoria più appropriata per lo strumento:
Deciderò se uno strumento merita di essere aggiunto all'elenco. Gli strumenti ampiamente utilizzati e riconosciuti dalla community hanno maggiori probabilità di essere inclusi rispetto a quelli oscuri o nuovi
offensive tool keyword: Queste keyword si riferiscono a strumenti offensivi o presentano un'elevata confidenza di intento dannoso. È fondamentale che questi termini mantengano rilevanza e affidabilità nel rilevare potenziali minacce (basso tasso di falsi positivi)greyware tool keyword: Le keyword di questa categoria corrispondono a strumenti 'legittimi' che vengono abusati da attori malintenzionati. Poiché questi strumenti hanno anche usi legittimi, il potenziale di falsi positivi è intrinsecamente più elevato. È importante interpretare questi risultati tenendo presente che non tutti i rilevamenti possono indicare attività dannosesignature keyword: Queste keyword potrebbero non essere direttamente associate a strumenti, ma possono includere nomi di firme di prodotti di sicurezza, stringhe specifiche o parole significative nel rilevamento delle minacce.metadata_tool: Nome dello strumento che vogliamo rilevare
metadata_description: descrizione dello strumento che vogliamo rilevare
metadata_tool_techniques: tecniche MITRE correlate allo strumento che vogliamo rilevare
metadata_tool_tactics: tattiche MITRE correlate allo strumento che vogliamo rilevare
metadata_malwares_name: Nomi delle varianti di malware che utilizzano lo strumento in questione
metadata_groups_name: Nomi dei gruppi di attori delle minacce associati allo strumento
metadata_category: Nome della categoria globale dello strumento. Potrebbe cambiare in futuro e i suggerimenti sono benvenuti.
metadata_link: link allo strumento (codice sorgente, articoli, campioni, blog ...)
metadata_enable_endpoint_detection: Campo che indica se la keyword può essere utilizzata efficacemente nelle ricerche sui log degli endpoint. Include, ma non si limita a, log eventi di Windows, EDR, log PowerShell, auditd, sessioni bastion, Sysmon o qualsiasi fonte di dati contenente campi di attività di processi e file.
metadata_enable_proxy_detection: Campo che indica l'applicabilità della keyword per le ricerche nei log di rete (Proxy, log DNS o qualsiasi dato con query e URL provenienti dalla rete interna)
metadata_popularity_score: punteggio da 1 a 10 (da bassa ad alta popolarità)
metadata_severity_score: punteggio da 1 a 10 (da bassa ad alta severità)
metadata_tags: tag per identificare artefatti specifici; più tag possono essere associati a una keyword. Quando alcuni artefatti specifici non possono essere aggiunti alle liste senza un contesto di rilevamento maggiore, vengono aggiunti nelle mie altre liste awesome per il rilevamento
metadata_comment: Questo campo può contenere un commento utile aggiunto per la keyword.
metadata_github_stars: Numero di stelle sul progetto github (se lo strumento è su github, altrimenti il valore è N/A); viene utilizzato per calcolare il punteggio di popolarità
metadata_github_forks: Numero di fork sul progetto github (se lo strumento è su github, altrimenti il valore è N/A); può essere utilizzato per le statistiche della dashboard degli strumenti più utilizzati
metadata_github_created_at: Data di creazione del progetto github (se lo strumento è su github, altrimenti il valore è N/A); può essere utilizzata per le statistiche della dashboard
metadata_github_updated_at: Data dell'ultimo aggiornamento del progetto github (se lo strumento è su github, altrimenti il valore è N/A); può essere utilizzata per monitorare gli aggiornamenti importanti degli strumenti offensivi e adattare i rilevamenti delle keyword
_rawkeyword_rawkeyword_detection_raw| search metadata_description!="" AND metadata_enable_endpoint_detection=1 qui ci concentriamo solo sui log degli endpoint, quindi aggiungiamo metadata_enable_endpoint_detection=1 per corrispondere solo alle keyword rilevanti per i log degli endpoint e metadata_description!="" per avere solo le keyword corrispondenti| stats count earliest(_time) as firsttime latest(_time) as lasttime values(_raw) as raw by metadata_keyword_type keyword_detection index sourcetype qui ho creato un filtro rapido senza tutti i campi del lookup per l'esempio (ma puoi anche aggiungerli se vuoi avere più possibilità di esclusione), questo ci permette di avere facilmente un'idea di quale keyword corrisponde molto, così possiamo escludere facilmente la categoria o lo strumento se ci sono troppi falsi positivi!|loadjob myjobid possiamo ora manipolare l'output con i log rilevanti senza ricercare di nuovo su tutti i log.e usa questa visualizzazione Splunk: https://splunkbase.splunk.com/app/5742
