mthcht/threathunting-keywordsAwesome-Liste mit Schlüsselwörtern und Artefakten für Threat-Hunting-Sitzungen
🎯 Liste von Keywords für ThreatHunting-Sessions
Threat Hunting ist ein proaktiver und iterativer Ansatz zur Erkennung bösartiger Aktivitäten im Netzwerk oder in den Systemen einer Organisation, die automatisierte Sicherheitsmaßnahmen umgangen haben könnten. Im Gegensatz zu reaktiven Untersuchungen, die durch Sicherheitswarnungen ausgelöst werden, wird Threat Hunting durch Threat-Intelligence (TI)-gestützte Prüfungen und Hypothesen angetrieben, die aus systematischer und opportunistischer Analyse abgeleitet werden. Diese Hypothesen 💡 helfen Jägern, unbekannte Bedrohungen, potenzielle Bedrohungen oder bekannte Bedrohungen aufzudecken, die Sicherheitserkennungen umgangen haben könnten, sowie Schwachstellen oder Kompromittierungsindikatoren (Indicators of Compromise, IoCs), die automatisierte Systeme möglicherweise übersehen oder ausschließen. Der Prozess konzentriert sich außerdem auf die Identifizierung von Vorläufern von Warnungen/Dashboards und die Verbesserung von SOC-/Triage-Workflows, trägt gleichzeitig zur Inventarverwaltung von Schatten-Assets bei und eskaliert Ereignisse mit niedriger/mittlerer Zuverlässigkeit, die weiterer Untersuchungen bedürfen. Das Hauptziel besteht darin, die von Bedrohungsakteuren verwendeten Taktiken, Techniken und Verfahren (TTPs) zu identifizieren und so die Fähigkeit der Organisation zu verbessern, potenzielle Angriffe vorbeugend zu erkennen und abzumildern.
Mein Prozessvorschlag zur Organisation teilautomatisierter Threat-Hunting-Sessions, um qualitativ hochwertige Erkennungsregeln innerhalb eines SOC zu pflegen
SOC-Teams konzentrieren sich darauf, hochzuverlässige Erkennungen auf allen Ebenen der Detection-Maturity-Pyramide zu implementieren und bekannte Bedrohungen mit minimalen False Positives zu adressieren. Threat Hunting ergänzt dies, indem es sich unbekannten Bedrohungen, fortgeschrittenen TTPs und Anomalien widmet, die anfällig für hohe False-Positive-Raten sind, Lücken schließt und die Erkennungsabdeckung über die Standardfähigkeiten des SOC hinaus erweitert.
Idealerweise sollte jede Threat-Hunting-Session klare Ziele haben. Dieses Flussdiagramm bietet einen strukturierten Ansatz, der Ihren Prozess von der Vorbereitung und Untersuchung bis hin zu umsetzbaren Empfehlungen leitet.
🎯 Liste von Keywords für ThreatHunting-Sessions
Die ThreatHunting-Keywords-Listen können für Threat Hunter, SOC- und CERT-Teams bei der statischen Analyse in SIEM-Systemen wertvoll sein, da sie dabei helfen, Bedrohungsakteure (oder Redteamer 😆) zu identifizieren, die in Logs Standardkonfigurationen bekannter Exploitation-Tools verwenden. Sie unterscheiden sich von IOC-Feeds durch ihre dauerhafte Relevanz: Die Keywords hier haben kein 'Ablaufdatum' und können Bedrohungen noch Jahre nach ihrer Aufnahme erkennen. Sie sind flexibel, akzeptieren Wildcards, ignorieren Groß-/Kleinschreibung und konzentrieren sich ausschließlich auf Standard-Keywords.
In erster Linie für Threat Hunting konzipiert, kann diese Liste in komplexen Szenarien nützlich sein. Ob Sie Zugriff auf eine SIEM haben, die Sie nicht verwalten, mit ungeparsten Daten, oder ob Sie Teil eines SOC-Teams mit einer gut verwalteten SIEM sind – die hier bereitgestellten Beispiele können den Prozess der Erkennung bösartiger Aktivitäten beschleunigen, ohne dass etwas geparst werden muss. Wenn Ihre Logs bereits geparst sind, kann diese Liste verwendet werden, um Felder in Ihren Daten abzugleichen und möglicherweise in eine Erkennungsregel auf Basis der von Ihnen gewählten Keyword-Typ-Kategorie umgewandelt zu werden, sofern die False-Positive-Rate ausreichend niedrig ist.
⚠️ Nicht alles kann in diese Liste aufgenommen werden. Wir erstellen hier keine komplexen Verhaltenserkennungen, sondern nur einfache Keyword-Erkennungen in Feldern oder Rohdaten-Logs, die darauf abzielen, Standardkonfigurationen zu erkennen
⚠️ Viele Tools in der Liste haben eigene Erkennungsregeln, die Ereignisse mit Schwellenwerten und eindeutigen Prozessbeziehungen korrelieren ... Wir werden hier nicht alle möglichen Erkennungen für ein Tool abdecken, sondern nur Keyword-Erkennungen
Wenn Sie Teil eines Security Operations Center (SOC) sind und Hunderte von Erkennungsregeln verwalten, die ausschließlich auf einfachen Keyword-Erkennungen ohne Feld- oder Ereigniskorrelation basieren, sollten Sie Ihren Ansatz überdenken. Meiner Meinung nach sollten diese keine einzelnen Erkennungsregeln darstellen. Stattdessen sind sie möglicherweise besser in einer konsolidierten Liste wie dieser aufgehoben, auch wenn die Implementierung schwieriger sein könnte, wenn Sie keine Plattform wie Splunk verwenden.
Dieser Ansatz fördert die Erstellung hochwertiger, zielgerichteter Regeln und hält gleichzeitig Ihre einfachen Feld-Keyword-Erkennungen an einem Ort organisiert und verwaltbar. Das Endergebnis? Eine umfassende Erkennungsregel, die alle abdeckt. Das optimiert Ihren Prozess und Ihre Erkennungsfähigkeiten.
Für Incident Responder: Sie können diese Liste während Ihrer Untersuchung von Rohdaten-Logs oder Dateien verwenden, um bekannte Exploitation-Tools schnell zu identifizieren – mit den Yara-Regeln, einem Powershell-Skript oder indem Sie Ihre Logs schnell mit Splunk4DFIR in Splunk aufnehmen.
Um einer Erkennung durch einfache Keyword-Erkennung zu entgehen, ist es entscheidend, alle benutzerdefinierten Zeichenfolgen, Klassen- oder Funktionsnamen, Variablennamen, Argumentnamen, Namen ausführbarer Dateien, Standard-User-Agents, Zertifikate oder andere Zeichenfolgen, die möglicherweise mit den von Ihnen während Ihrer Operation verwendeten Tools in Verbindung gebracht werden könnten, neu zu kompilieren und umzubenennen. Verwenden Sie für alles die gebräuchlichsten Namen, um sich in den normalen Datenverkehr einzufügen. Skripte hier können Ihnen helfen, einige davon zu identifizieren.
Wenn Sie jedoch öffentliche „Red-Team-Tools“ entwickeln, sollten Sie das Blue Team unterstützen, indem Sie eindeutige Namen verwenden. Verwenden Sie eine Standardkonfiguration mit einem exotischen Port, benutzerdefinierten Zertifikaten, einzigartigen User-Agents, spezifischen Funktionsnamen und Argumenten, die nicht üblich sind. Dies hilft, eine klare Signatur zu erstellen, die für einfache Keyword-Erkennungen verwendet werden kann, sodass das Blue Team zumindest die Script Kiddies leicht erkennen kann.
Header: 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: Die Einträge in dieser Spalte stellen Keywords dar, bei denen die Groß-/Kleinschreibung nicht beachtet wird und die für Threat Hunting verwendet werden. Diese Keywords sind flexibel und erlauben die Verwendung von Wildcards, um Ihre Suchparameter nach Bedarf zu erweitern oder einzugrenzen.
metadata_keyword_regex: Die Einträge in dieser Spalte stellen die Regex-Mustererkennung für das Keyword dar; diese Muster sind verfeinert, um präzise Erkennungsfähigkeiten zu bieten, und eignen sich für die Verwendung mit YARA, ripgrep oder ähnlichen Erkennungswerkzeugen.
metadata_keyword_type: Typ der Keywords. Derzeit gibt es drei Typen:
Laden Sie die Liste threathunting-keywords.csv in Splunk hoch
Erstellen Sie eine Lookup-Definition mit dem Namen threathunting-keywords für das Lookup threathunting-keywords.csv
WILDCARD(keyword) hinzu und stellen Sie sicher, dass Case sensitive match nicht aktiviert ist
transforms.conf``` [threathunting-keywords] batch_index_query = 0 case_sensitive_match = 0 filename = threathunting-keywords.csv match_type = WILDCARD(keyword)
- jetzt können wir unsere Lookup-Definition verwenden, um zu jagen 🏹
- :warning: Wenn die Suchen im folgenden Abschnitt nicht zu funktionieren scheinen, kann dies an den Ressourcenbegrenzungseinstellungen von Splunk liegen, insbesondere wenn Sie Splunk mit der Standardkonfiguration ausführen. Für den Anfang sollten Sie in Betracht ziehen, den Wert des Parameters `max_memtable_bytes` in der `[lookup]`-Stanza zu erhöhen.
## Beispielanwendungsfälle mit `threathunting-keywords`:
### Alle Keywords in Roh-Logs jagen 😱```
`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)
Sende den Job in den Hintergrund und behalte die Job-ID.
myendpointslogs ist ein Makro, das alle Endpoint-Logs durchsucht – das können Windows-Logs, EDR-Telemetrie, Sysmon, auditd, Bastion-Sitzungen, PowerShell-Ausführungsprotokolle oder andere Logs sein, die Prozess- oder Dateiaktivitäten überwachen. (Wenn du kein Makro verwendest, kannst du das Makro durch deinen Index, dein Tag oder dein Datenmodell ersetzen)
TERM() nach bestimmten Suchen, bevor du |lookup verwendest| lookup Das ist sehr wichtig. Verwende bei großen Lookups wie diesem immer |lookup anstelle von |inputlookup. |lookup verwendet das Lookup, das bei der Replikation des Bundles auf die Indexer übertragen wird, während |inputlookup bei jeder Suche die gesamten Lookup-Inhalte an die Indexer sendet. Mit |lookup erzielen wir hier massive Leistungsgewinne (diese Suche wird in großen Umgebungen stundenlang laufen, also optimieren wir unsere Suche besser.... keyword as _raw OUTPUT keyword as keyword_detection Das ist der Teil, in dem wir das Feld mit dem Feld in unserem Lookup abgleichen. In Splunk ist das Rohprotokoll ohne Parsing (unser Anwendungsfall). Wenn ein Keyword übereinstimmt, zeigt das Feld das Keyword aus dem Lookup, das hier mit dem Feld () übereinstimmt.Filtere das Ergebnis``` | loadjob 1684146257.1495958 | search NOT (keyword_detection IN ("fixme","fixme","fixme")) NOT (metadata_keyword_type IN ("fixme","fixme")) NOT (raw IN ("fixme","fixme","fixme"))
Schließen Sie die erforderlichen Schlüsselwörter, Rohtext oder Schlüsselworttypen aus.
Wenn wir uns entscheiden, den Typ `greyware tool keyword` auszuschließen (legitime Tools-Schlüsselwörter, die von Angreifern missbraucht werden), weil diese Umgebung zu viele Ergebnisse für diese Art von Tools liefert, haben wir zwei Optionen:
- Filtern am Anfang unserer ursprünglichen Suche```
`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)
Ich habe ein metadata_keyword_type="offensive tool keyword" hinzugefügt, um mich nur auf offensive Tools zu konzentrieren, von denen ich sicher bin, dass sie von böswilligen Akteuren verwendet werden.
Das war also unser Anwendungsfall, um in Endpunkt-Logs nach Roh-Logs zu suchen. Wenn wir die Schlüsselwörter für Netzwerk-Logs (alles, was eine Abfrage oder eine URL protokollieren kann) suchen möchten, ändern wir es einfach 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)
Jetzt ist es dasselbe wie bei der ersten Suche, aber ich habe die Datenquelle für mynetworklogs geändert und metadata_enable_proxy_detection=1 hinzugefügt, um die relevanten Schlüsselwörter für Netzwerkprotokolle abzugleichen (am besten hat man Proxy- und DNS-Protokolle dafür)
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)
#### Nur auf Abfragefeld abgleichen:```
`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)
#### Geschwindigkeit:
Falls die Geschwindigkeit eine Rolle spielt oder Sie dies als geplante Erkennungsregel implementieren möchten, sollten Sie in Erwägung ziehen, den Lookup in verschiedene Lookups aufzuteilen, indem Sie die Spalte `metadata_keyword_type` oder `metadata_tool` auswählen, die Sie verwenden möchten.
Beachten Sie, dass das Filtern mit dem search-Befehl nach `|lookup` den Suchprozess nicht beschleunigt. Wenn Sie sich auf einen bestimmten Teil des Lookups konzentrieren möchten, ohne ihn zu teilen, sollten Sie den Befehl `|inputlookup` zusammen mit der where-Klausel verwenden. Diese Methode verbraucht zwar mehr CPU-Ressourcen, führt aber in der Regel zu einer schnelleren Ausführung. Weitere Einzelheiten finden Sie in der Splunk-Dokumentation zu inputlookup: https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Inputlookup
#### Mit ELK:
Wenn Sie mit dem Elastic Stack arbeiten, gibt es viele Einschränkungen für Listen (Sie können keine Sonderzeichen, Leerzeichen usw. verwenden). Sie haben 3 Optionen:
- Verwenden Sie eine andere Liste, die hier im selben Repository verfügbar ist: https://github.com/mthcht/ThreatHunting-Keywords/tree/main/elk (es ist kein direkter Extrakt von threathunting-keywords.csv, sondern für ELK modifiziert und nicht aktualisiert)
- Verwenden Sie Sigma-„Hunting“-Regeln, die direkt aus diesem Projekt https://github.com/mthcht/ThreatHunting-Keywords-sigma-rules extrahiert und mit pysigma konvertiert werden
- Verwenden Sie einige meiner Listen als IOC-Liste mit Wildcard-Abfragen: https://www.elastic.co/guide/en/elasticsearch/reference/8.15/query-dsl-wildcard-query.html#wildcard-top-level-params
### Dashboard-Beispiel
### Splunk4DFIR
Ein weiteres Beispiel für die Verwendung der Projekt-CSV-Dateien mit Splunk zur Suche in DFIR-Artefakten und Protokollen: https://github.com/mf1d3l/Splunk4DFIR
### Weitere großartige Listen für die Erkennung
Ich pflege einige relevante Artefakte in separaten Listen. Diese Listen sind präziser und können in Erkennungsregeln verwendet werden. Sie sind in diesem [GitHub-Repository](https://github.com/mthcht/awesome-lists/tree/main/Lists) verfügbar. Dort finden Sie:
Mein Intelligence-Gathering-Blatt zur Planung von Threat-Hunting-Sitzungen
- 📋 Listen: https://github.com/mthcht/awesome-lists/tree/main/Lists
- 🕵️♂️ Threat-Hunting-Anleitungen: https://mthcht.medium.com/list/threat-hunting-708624e9266f
- 🚰 Verdächtige Named Pipes: [suspicious_named_pipe_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_named_pipe_list.csv)
- 🌐 Verdächtige TLDs (automatisch aktualisiert): [[suspicious_TLDs]](https://github.com/mthcht/awesome-lists/tree/main/Lists/TLDs)
- 🌐 Verdächtige ASNs (automatisch aktualisiert): [[suspicious ASNs]](https://github.com/mthcht/awesome-lists/tree/main/Lists/ASNs)
- 🔧 Verdächtige Windows-Dienste: [suspicious_windows_services_names_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_windows_services_names_list.csv)
- ⏲️ Verdächtige Windows-Aufgaben: [suspicious_windows_tasks_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_windows_tasks_list.csv)
- 🚪 Verdächtiger Zielport: [suspicious_ports_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_ports_list.csv)
- 🛡️ Verdächtige Firewall-Regeln: [suspicious_windows_firewall_rules_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_windows_firewall_rules_list.csv)
- 🆔 Verdächtige User-Agents: [suspicious_http_user_agents_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_http_user_agents_list.csv)
- 📇 Verdächtige USB-IDs: [suspicious_usb_ids_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_usb_ids_list.csv)
- 🔢 Verdächtige MAC-Adresse: [suspicious_mac_address_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_mac_address_list.csv)
- 📛 Verdächtiger Hostname: [suspicious_hostnames_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_hostnames_list.csv)
- 🧮 Metadaten ausführbarer Dateien: [executables_metadata_informations_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/Windows%20Metadata/executables_metadata_informations_list.csv)
- 🕸️ DNS-over-HTTPS-Serverliste: [dns_over_https_servers_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/dns_over_https_servers_list.csv)
- 📚 Hijacklibs (automatisch aktualisiert): [hijacklibs_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/Hijacklibs/hijacklibs_list.csv)
- 🌐 TOR-Knotenlisten (automatisch aktualisiert): https://github.com/mthcht/awesome-lists/tree/main/Lists/TOR
- 🛠️ LOLDriver-Liste (automatisch aktualisiert): [loldrivers_only_hashes_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/Drivers/loldrivers_only_hashes_list.csv)
- 🛠️ Liste schädlicher Bootloader (automatisch aktualisiert): [malicious_bootloaders_only_hashes_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/Drivers/malicious_bootloaders_only_hashes_list.csv)
- 📜 Liste schädlicher SSL-Zertifikate (automatisch aktualisiert): [ssl_certificates_malicious_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/SSL%20CERTS/ssl_certificates_malicious_list.csv)
- 🖥️ RMM-Erkennung: https://github.com/mthcht/awesome-lists/tree/main/Lists/RMM
- 👤🔑 Wichtige Rollen und Gruppen für AD/EntraID/AWS: [[permissions]](https://github.com/mthcht/awesome-lists/tree/main/Lists/permissions)
- 💻🔒 Bekannte Ransomware-Dateierweiterungen: [ransomware_extensions_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/ransomware_extensions_list.csv)
- 💻🔒 Bekannte Ransomware-Lösegeldnotizen-Dateinamen: [ransomware_notes_list.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/ransomware_notes_list.csv)
- 📝 Windows-ASR-Regeln: [windows_asr_rules.csv](https://github.com/mthcht/awesome-lists/blob/main/Lists/windows_asr_rules.csv)
- 🌐 DNSTWIST-Listen (automatisch aktualisiert): [DNSTWIST-Standarddomänen + Skript](https://github.com/mthcht/awesome-lists/tree/main/Lists/DNSTWIST)
- 🌍 VPN-IP-Adresslisten (automatisch aktualisiert):
- 🛡️ 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)
- 🏢 IP-Bereichslisten von Unternehmen (automatisch aktualisiert): [Standardlisten + Skript](https://github.com/mthcht/awesome-lists/tree/main/Lists/Ranges_IP_Address_Company_List/bgp.he.net)
- 🔗 Weitere Korrelationslisten: https://github.com/mthcht/awesome-lists/tree/main/Lists/Others
- 📋 Listen, die ich noch fertigstellen muss: https://github.com/mthcht/awesome-lists/tree/main/todo
Schauen Sie sich diese [Anleitungen](https://github.com/mthcht/awesome-lists/tree/main/Lists#how-to-use-the-lists) an, um einige der Listen zu verwenden:
- [Suchen nach Windows-Diensten](https://detect.fyi/threat-hunting-suspicious-windows-service-names-2f0dceea204c)
- [Suchen nach User-Agents](https://mthcht.medium.com/threat-hunting-suspicious-user-agents-3dd764470bd0)
- [DNS-over-HTTPS-Suchen](https://mthcht.medium.com/detecting-dns-over-https-30fddb55ac78)
- [Suchen nach verdächtigen TLDs](https://mthcht.medium.com/threat-hunting-suspicious-tlds-a742c2adbf58)
- [HijackLibs-Suchen](https://mthcht.medium.com/detect-dll-hijacking-techniques-from-hijacklibs-with-splunk-c760d2e0656f)
- [Phishing- und DNSTWIST-Suchen](https://detect.fyi/detecting-phishing-attempts-with-dnstwist-37c426b3bbb8)
- [Suchen nach Browsererweiterungen](https://mthcht.medium.com/detecting-browser-extensions-installations-e0ac2b45c46b)
- [C2 versteckt sich in aller Öffentlichkeit](https://mthcht.medium.com/c2-hiding-in-plain-sight-7a83963b9344)
- [HTML-Smuggling-Artefakte](https://mthcht.medium.com/detecting-html-smuggling-phishing-attempts-15af824e60e4)
- [Suchen nach PSEXEC und ähnlichen Tools](https://mthcht.medium.com/detecting-psexec-and-similar-tools-c812bf3dca6c)
- [Erkennung von Time Slipping](https://mthcht.medium.com/event-log-manipulations-1-time-slipping-55bf95631c40)
- [Verdächtige Named Pipes](https://medium.com/detect-fyi/threat-hunting-suspicious-named-pipes-a4206e8a4bc8)
... mehr [hier](https://github.com/mthcht/awesome-lists/tree/main/Lists#how-to-use-the-lists)
## DFIR-Suche nach Schlüsselwörtern in Dateien (ohne SIEM)
Nach einer gründlichen Untersuchung verschiedener Tools habe ich festgestellt, dass [ripgrep](https://github.com/BurntSushi/ripgrep) seine Konkurrenten deutlich übertrifft, wenn es darum geht, eine umfangreiche Liste von Regex-Mustern schnell gegen jede Zeile einer großen Protokolldatei oder sogar mehrerer Dateien gleichzeitig abzugleichen. Es erwies sich als die effizienteste Lösung für die Verarbeitung großer Datenmengen und bietet unvergleichliche Geschwindigkeit und Flexibilität.
### Suche nach Schadcode in Protokolldateien mit **Ripgrep** und der Liste 'only_keywords_regex.txt'
#### `rg.exe -f .\only_keywords_regex.txt .\EvtxECmd_Output.csv --multiline --ignore-case`
- .\only_keywords_regex.txt dient als Quelldatei für die Threat-Hunting-Schlüsselwörter, die in Regex-Muster für präzises Matching umgewandelt werden. Diese Muster stammen aus der Datei threathunting-keywords.csv, die einem Konvertierungsprozess unterzogen wurde, um eine optimale Kompatibilität mit Regex-Operationen zu gewährleisten.
- .\EvtxECmd_Output.csv stellt die Zieldatei dar, in der die Suche durchgeführt wird. In diesem Kontext handelt es sich um ein .csv-Format eines Windows-Ereignisprotokolls, das durch den Export von EVTX-Protokollen erzeugt wurde. Die Flexibilität von ripgrep erlaubt es jedoch, diese Datei durch eine beliebige Datei Ihrer Wahl für detaillierte Mustersucheoperationen zu ersetzen.
- Die Option --multiline ermöglicht es ripgrep, Muster, die sich über mehrere Zeilen erstrecken, effektiv zu verarbeiten und abzugleichen, wodurch der Suchbereich erheblich erweitert wird.
Sie erhalten die übereinstimmenden Zeilen auf diese Weise mit der Zeilennummer (jedoch ohne das übereinstimmende Schlüsselwort)
#### Bessere Option für sehr große Dateien (unter 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`: gibt die Datei an, in der gesucht werden soll (im Beispiel ein DFIR-ORC-Extrakt von Protokollen)
- `-patternFile`: die Datei, die die Regex-Muster enthält `only_keywords_regex.txt`
- `-rgPath`: der Pfad zur ausführbaren Ripgrep-Datei
Inhalt des PowerShell-Skripts (im Repository enthalten):```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
Das Ergebnis der Suche wird in result_search.log im selben Verzeichnis wie das Skript abgelegt.
todo
In PowerShell ist es viel langsamer, aber wenn du es trotzdem auf diese Weise tun möchtest, kannst du das untenstehende Skript verwenden. Es zeigt dir die übereinstimmende Zeilennummer und das zugehörige Schlüsselwort an:
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>
### YARA-Regeln
Alle Erkennungsmuster dieses Projekts werden automatisch als YARA-Regeln in [ThreatHunting-Keywords-yara-rules](https://github.com/mthcht/ThreatHunting-Keywords-yara-rules) exportiert.
Einige Beispiele für die Jagd mit den YARA-Regeln:
## Schnelle Datentabelle zur Suche nach Schlüsselwörtern
https://mthcht.github.io/ThreatHunting-Keywords/
## Fehlalarme
Hilf mit und füge deine Fehlalarme zur [Liste](https://github.com/mthcht/ThreatHunting-Keywords/blob/main/_false_positives/false_positives_offensive_keywords.md) der erwarteten Fehlalarme hinzu.
## SIGMA-Regeln
Schau dir die in [SIGMA-Regeln](https://github.com/mthcht/ThreatHunting-Keywords-sigma-rules) übersetzte Lookup-Tabelle an. Ich aktualisiere sie normalerweise zur gleichen Zeit :)
## MITRE ATT&CK-Technik-Mapping
mit dem Splunk-Addon https://splunkbase.splunk.com/app/5742
Abdeckung für 2242 Tools (aktualisiert am 30.08.2024):
Splunk-Suche:
<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
Splunk-Dashboards (dies ist nur ein Beispiel; eine große Auswahl an Filtern kann mithilfe der in der Datei verfügbaren Felder angewendet werden):
Splunk-XML-Dashboard-Beispiel:
Beiträge, Issues und Feature-Anfragen sind willkommen!
``
Bitte gib den Namen des Tools an.
``
Gib einen Link zur offiziellen Website des Tools oder zum Quellcode-Repository an (GitHub, GitLab usw.). Falls eine Dokumentation verfügbar ist, füge sie bitte hinzu.
``
Beschreibe den Zweck, die Funktionalität und die bemerkenswerten Funktionen des Tools. Wenn du dir unsicher bist, lasse dieses Feld leer, und ich werde das Tool genauer prüfen.
``
Wenn du Informationen über bekannten oder potenziellen Missbrauch dieses Tools durch böswillige Akteure hast, teile sie bitte hier mit.
Bitte wähle die am besten geeignete Kategorie für das Tool:
Ich entscheide, ob ein Tool es wert ist, in die Liste aufgenommen zu werden. Tools, die in der Community weit verbreitet und anerkannt sind, werden eher aufgenommen als wenig bekannte oder neue.
offensive tool keyword: Diese Keywords beziehen sich auf offensive Tools oder weisen eine hohe Wahrscheinlichkeit böswilliger Absicht auf. Es ist entscheidend, dass diese Begriffe für die Erkennung potenzieller Bedrohungen relevant und zuverlässig sind (niedrige False-Positive-Rate)greyware tool keyword: Keywords in dieser Kategorie entsprechen „legitimen“ Tools, die von böswilligen Akteuren missbraucht werden. Da diese Tools auch legitime Verwendungszwecke haben, ist das Potenzial für False Positives von Natur aus höher. Es ist wichtig, diese Ergebnisse mit dem Verständnis zu interpretieren, dass nicht jede Erkennung auf böswillige Aktivität hindeuten musssignature keyword: Diese Keywords stehen möglicherweise nicht direkt in Verbindung mit Tools, können aber Signaturnamen von Sicherheitsprodukten, spezifische Zeichenfolgen oder Wörter umfassen, die für die Bedrohungserkennung von Bedeutung sind.metadata_tool: Name des Tools, das wir erkennen möchten
metadata_description: Beschreibung des Tools, das wir erkennen möchten
metadata_tool_techniques: MITRE-Techniken, die mit dem Tool in Verbindung stehen, das wir erkennen möchten
metadata_tool_tactics: MITRE-Taktiken, die mit dem Tool in Verbindung stehen, das wir erkennen möchten
metadata_malwares_name: Namen von Malware-Varianten, die das betreffende Tool verwenden
metadata_groups_name: Namen von Bedrohungsakteursgruppen, die mit dem Tool in Verbindung stehen
metadata_category: Globaler Kategoriename des Tools. Dies kann sich später ändern; Vorschläge sind willkommen.
metadata_link: Link zum Tool (Quellcode, Artikel, Samples, Blog ...)
metadata_enable_endpoint_detection: Feld, das angibt, ob das Keyword effektiv bei Suchvorgängen in Endpoint-Logs verwendet werden kann. Dies umfasst unter anderem Windows-Ereignisprotokolle, EDR, PowerShell-Logs, auditd, Bastion-Sitzungen, Sysmon oder jede Datenquelle, die Prozess- und Dateiaktivitätsfelder enthält.
metadata_enable_proxy_detection: Feld, das die Anwendbarkeit des Keywords für Suchvorgänge in Netzwerk-Logs angibt (Proxy-, DNS-Logs oder alle Daten mit Abfragen und URLs, die aus dem internen Netzwerk stammen)
metadata_popularity_score: Bewertung von 1 bis 10 (niedrige bis hohe Beliebtheit)
metadata_severity_score: Bewertung von 1 bis 10 (niedriger bis hoher Schweregrad)
metadata_tags: Tags zur Identifizierung spezifischer Artefakte; einem Keyword können mehrere Tags zugeordnet werden. Wenn einige der spezifischen Artefakte ohne weiteren Erkennungskontext nicht in die Listen aufgenommen werden können, werden sie in meinen anderen großartigen Listen zur Erkennung ergänzt.
metadata_comment: Dieses Feld kann einen nützlichen Kommentar enthalten, der für das Keyword hinzugefügt wurde.
metadata_github_stars: Anzahl der Sterne des GitHub-Projekts (wenn das Tool auf GitHub ist; andernfalls lautet der Wert N/A). Dies wird verwendet, um den Beliebtheits-Score zu berechnen
metadata_github_forks: Anzahl der Forks des GitHub-Projekts (wenn das Tool auf GitHub ist; andernfalls lautet der Wert N/A). Kann für Dashboard-Statistiken der am häufigsten verwendeten Tools verwendet werden
metadata_github_created_at: Erstellungsdatum des GitHub-Projekts (wenn das Tool auf GitHub ist; andernfalls lautet der Wert N/A). Kann für Dashboard-Statistiken verwendet werden
metadata_github_updated_at: Datum der letzten Aktualisierung des GitHub-Projekts (wenn das Tool auf GitHub ist; andernfalls lautet der Wert N/A). Kann verwendet werden, um wichtige Updates offensiver Tools zu verfolgen und Keyword-Erkennungen anzupassen
_rawkeyword_rawkeyword_detection_raw| search metadata_description!="" AND metadata_enable_endpoint_detection=1 Wir konzentrieren uns hier nur auf Endpoint-Logs, daher fügen wir metadata_enable_endpoint_detection=1 hinzu, um nur die relevanten Keywords für Endpoint-Logs zu treffen, und metadata_description!="", um nur die übereinstimmenden Keywords zu erhalten| stats count earliest(_time) as firsttime latest(_time) as lasttime values(_raw) as raw by metadata_keyword_type keyword_detection index sourcetype Hier habe ich für das Beispiel einen schnellen Filter ohne alle Felder des Lookups erstellt (du kannst sie aber auch hinzufügen, wenn du mehr Ausschlussmöglichkeiten haben möchtest). Das erleichtert es uns, eine Vorstellung davon zu bekommen, welches Keyword besonders häufig übereinstimmt, sodass wir die Kategorie oder das Tool leicht ausschließen können, wenn es zu viele Fehlalarme gibt!|loadjob myjobid können wir die Ausgabe nun mit den relevanten Logs bearbeiten, ohne erneut alle Logs durchsuchen zu müssen.und verwende diese Splunk-Visualisierung: https://splunkbase.splunk.com/app/5742
