mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/phishing-methodolog
This commit is contained in:
Translator
parent
8ba296acbe
commit
8daeabb02a
1
.gitignore
vendored
1
.gitignore
vendored
@ -11,3 +11,4 @@ book
|
||||
book/*
|
||||
hacktricks-preprocessor.log
|
||||
hacktricks-preprocessor-error.log
|
||||
searchindex.js
|
||||
|
||||
@ -1,99 +1,113 @@
|
||||
# iOS Physische use-after-free via IOSurface
|
||||
# iOS Physical Use After Free via IOSurface
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Physischer use-after-free
|
||||
## iOS Exploit-Schutzmaßnahmen
|
||||
|
||||
Dies ist eine Zusammenfassung des Beitrags von [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html). Weitere Informationen zu Exploits, die diese Technik verwenden, finden sich in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
|
||||
- **Code Signing** in iOS funktioniert, indem jedes ausführbare Stück Code (Apps, Libraries, Extensions usw.) kryptografisch mit einem von Apple ausgestellten Zertifikat signiert sein muss. Beim Laden von Code überprüft iOS die digitale Signatur gegen Apples vertrauenswürdige Root. Ist die Signatur ungültig, fehlt oder wurde verändert, verweigert das OS die Ausführung. Das verhindert, dass Angreifer bösartigen Code in legitime Apps injizieren oder unsignierte Binärdateien ausführen, und bricht damit die meisten Exploit-Ketten, die auf das Ausführen beliebigen oder manipulierten Codes angewiesen sind.
|
||||
- **CoreTrust** ist das iOS-Subsystem, das die Code-Signierung zur Laufzeit durchsetzt. Es validiert Signaturen direkt mit Apples Root-Zertifikat, ohne sich auf zwischengespeicherte Trust-Stores zu verlassen. Das bedeutet, dass nur Binärdateien, die von Apple signiert sind (oder gültige Entitlements haben), ausgeführt werden können. CoreTrust stellt sicher, dass selbst wenn ein Angreifer eine App nach der Installation manipuliert, Systembibliotheken ändert oder versucht, unsignierten Code zu laden, die Ausführung blockiert wird, sofern der Code nicht korrekt signiert ist. Diese strikte Durchsetzung schließt viele Post-Exploitation-Vektoren, die ältere iOS-Versionen durch schwächere oder umgehbare Signaturprüfungen erlaubten.
|
||||
- **Data Execution Prevention (DEP)** markiert Speicherbereiche als nicht ausführbar, sofern sie nicht explizit Code enthalten. Das verhindert, dass Angreifer Shellcode in Datenbereiche (wie Stack oder Heap) injizieren und ausführen; sie müssen auf kompliziertere Techniken wie ROP (Return-Oriented Programming) ausweichen.
|
||||
- **ASLR (Address Space Layout Randomization)** randomisiert die Speicheradressen von Code, Libraries, Stack und Heap bei jedem Start. Das macht es deutlich schwieriger für Angreifer, vorherzusagen, wo nützliche Instruktionen oder Gadgets liegen, und zerstört viele Exploit-Ketten, die auf feste Speicherlayouts angewiesen sind.
|
||||
- **KASLR (Kernel ASLR)** wendet dasselbe Randomisierungskonzept auf den iOS-Kernel an. Durch das Verschieben der Kernel-Basisadresse bei jedem Boot verhindert es, dass Angreifer verlässlich Kernel-Funktionen oder -Strukturen lokalisieren, und erhöht die Schwierigkeit von Kernel-Level-Exploits, die sonst vollständige Systemkontrolle erlangen würden.
|
||||
- **Kernel Patch Protection (KPP)**, auch bekannt als **AMCC (Apple Mobile File Integrity)** in iOS, überwacht dauerhaft die Kernel-Code-Seiten, um sicherzustellen, dass sie nicht modifiziert wurden. Wenn eine Manipulation erkannt wird — etwa ein Exploit, der versucht, Kernel-Funktionen zu patchen oder bösartigen Code einzufügen — panict das Gerät sofort und startet neu. Dieser Schutz macht persistente Kernel-Exploits deutlich schwerer, da Angreifer Kernel-Instruktionen nicht einfach hooken oder patchen können, ohne einen Systemabsturz auszulösen.
|
||||
- **Kernel Text Readonly Region (KTRR)** ist eine hardwarebasierte Sicherheitsfunktion, die auf iOS-Geräten eingeführt wurde. Sie nutzt den Speichercontroller der CPU, um den Code-(text)-Bereich des Kernels nach dem Boot dauerhaft als schreibgeschützt zu markieren. Einmal gesperrt, kann selbst der Kernel diesen Speicherbereich nicht mehr verändern. Das verhindert, dass Angreifer — und sogar privilegierter Code — Kernel-Instruktionen zur Laufzeit patchen, und schließt damit eine große Klasse von Exploits, die auf direkte Modifikation von Kernel-Code angewiesen waren.
|
||||
- **Pointer Authentication Codes (PAC)** verwenden kryptografische Signaturen, die in ungenutzte Bits von Pointern eingebettet sind, um deren Integrität vor der Nutzung zu verifizieren. Wenn ein Pointer (z. B. eine Rücksprungadresse oder ein Funktionspointer) erstellt wird, signiert die CPU ihn mit einem geheimen Schlüssel; vor dem Dereferenzieren prüft die CPU die Signatur. Wurde der Pointer manipuliert, schlägt die Prüfung fehl und die Ausführung stoppt. Das verhindert, dass Angreifer Pointer in Memory-Corruption-Exploits fälschen oder wiederverwenden und erschwert Techniken wie ROP oder JOP erheblich.
|
||||
- **Privilege Access Never (PAN)** ist eine Hardwarefunktion, die verhindert, dass der Kernel (privilegierter Modus) direkt auf User-Space-Speicher zugreift, es sei denn, er aktiviert den Zugriff explizit. Das stoppt Angreifer, die Kernel-Codeausführung erlangt haben, daran, User-Speicher einfach zu lesen oder zu schreiben, um Exploits zu eskalieren oder sensible Daten zu stehlen. Durch strikte Trennung reduziert PAN die Auswirkungen von Kernel-Exploits und blockiert viele gängige Privilege-Escalation-Techniken.
|
||||
- **Page Protection Layer (PPL)** ist ein iOS-Sicherheitsmechanismus, der kritische kernelverwaltete Speicherbereiche schützt, insbesondere solche, die mit Code-Signing und Entitlements zu tun haben. Er setzt strikte Schreibschutzmaßnahmen mithilfe der MMU (Memory Management Unit) und zusätzlicher Prüfungen durch und stellt sicher, dass selbst privilegierter Kernel-Code nicht beliebig sensible Seiten ändern kann. Das verhindert, dass Angreifer mit Kernel-Level-Ausführung sicherheitskritische Strukturen manipulieren, und macht Persistenz und Code-Signing-Bypasses deutlich schwieriger.
|
||||
|
||||
|
||||
## Physical use-after-free
|
||||
|
||||
This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
|
||||
|
||||
### Speicherverwaltung in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
|
||||
|
||||
Der **virtuelle Adressraum** für Benutzerprozesse unter iOS reicht von **0x0 bis 0x8000000000**. Diese Adressen werden jedoch nicht direkt auf physischen Speicher abgebildet. Stattdessen verwendet der **Kernel** **Seitentabellen**, um virtuelle Adressen in tatsächliche **physische Adressen** zu übersetzen.
|
||||
Der **virtuelle Adressraum** für User-Prozesse auf iOS reicht von **0x0 bis 0x8000000000**. Diese Adressen bilden jedoch nicht direkt den physischen Speicher ab. Stattdessen verwendet der **Kernel** **Seitentabellen**, um virtuelle Adressen in tatsächliche **physische Adressen** zu übersetzen.
|
||||
|
||||
#### Ebenen der Seitentabellen in iOS
|
||||
|
||||
Seitentabellen sind hierarchisch in drei Ebenen organisiert:
|
||||
|
||||
1. **L1 Page Table (Level 1)**:
|
||||
* Jeder Eintrag repräsentiert hier einen großen Bereich des virtuellen Speichers.
|
||||
* Jeder Eintrag repräsentiert einen großen Bereich des virtuellen Speichers.
|
||||
* Er deckt **0x1000000000 Bytes** (oder **256 GB**) virtuellen Speicher ab.
|
||||
2. **L2 Page Table (Level 2)**:
|
||||
* Ein Eintrag repräsentiert hier einen kleineren Bereich des virtuellen Speichers, nämlich **0x2000000 Bytes** (32 MB).
|
||||
* Ein Eintrag hier repräsentiert eine kleinere Region virtuellen Speichers, nämlich **0x2000000 Bytes** (32 MB).
|
||||
* Ein L1-Eintrag kann auf eine L2-Tabelle zeigen, wenn er den gesamten Bereich nicht selbst abbilden kann.
|
||||
3. **L3 Page Table (Level 3)**:
|
||||
* Dies ist die feinste Ebene, in der jeder Eintrag eine einzelne **4 KB** Speicherseite abbildet.
|
||||
* Ein L2-Eintrag kann auf eine L3-Tabelle zeigen, wenn eine feinere Auflösung erforderlich ist.
|
||||
* Dies ist die feinste Ebene, in der jeder Eintrag eine einzelne **4 KB**-Speicherseite abbildet.
|
||||
* Ein L2-Eintrag kann auf eine L3-Tabelle zeigen, wenn eine feinere Kontrolle erforderlich ist.
|
||||
|
||||
#### Abbildung von virtuellem zu physischem Speicher
|
||||
#### Abbildung von Virtuell zu Physisch
|
||||
|
||||
* **Direkte Abbildung (Block Mapping)**:
|
||||
* Einige Einträge in einer Seitentabelle **bilden direkt einen Bereich virtueller Adressen** auf einen zusammenhängenden Bereich physischer Adressen ab (wie eine Abkürzung).
|
||||
* **Zeiger auf untergeordnete Seitentabelle**:
|
||||
* Wenn eine feinere Steuerung notwendig ist, kann ein Eintrag einer Ebene (z. B. L1) auf eine **untergeordnete Seitentabelle** der nächsten Ebene (z. B. L2) zeigen.
|
||||
* Einige Einträge in einer Seitentabelle bilden direkt einen Bereich virtueller Adressen auf einen zusammenhängenden Bereich physischer Adressen ab (wie eine Abkürzung).
|
||||
* **Pointer auf Kind-Seitentabelle**:
|
||||
* Wenn eine feinere Steuerung nötig ist, kann ein Eintrag auf einer Ebene (z. B. L1) auf eine **Kind-Seitentabelle** der nächsten Ebene (z. B. L2) zeigen.
|
||||
|
||||
#### Beispiel: Abbildung einer virtuellen Adresse
|
||||
|
||||
Angenommen, Sie greifen auf die virtuelle Adresse **0x1000000000** zu:
|
||||
|
||||
1. **L1 Table**:
|
||||
* Der Kernel prüft den L1-Seitentabelleneintrag, der dieser virtuellen Adresse entspricht. Wenn dieser einen **Zeiger auf eine L2-Seitentabelle** enthält, geht er zu dieser L2-Tabelle.
|
||||
2. **L2 Table**:
|
||||
* Der Kernel prüft die L2-Seitentabelle für eine detailliertere Abbildung. Wenn dieser Eintrag auf eine **L3-Seitentabelle** zeigt, geht er dorthin.
|
||||
3. **L3 Table**:
|
||||
1. **L1-Tabelle**:
|
||||
* Der Kernel prüft den L1-Seitentabelleneintrag, der dieser virtuellen Adresse entspricht. Wenn er einen **Pointer zu einer L2-Seitentabelle** enthält, geht er zu dieser L2-Tabelle.
|
||||
2. **L2-Tabelle**:
|
||||
* Der Kernel prüft die L2-Seitentabelle für eine detailliertere Abbildung. Wenn dieser Eintrag auf eine **L3-Seitentabelle** zeigt, fährt er dort fort.
|
||||
3. **L3-Tabelle**:
|
||||
* Der Kernel sucht den finalen L3-Eintrag, der auf die **physische Adresse** der tatsächlichen Speicherseite zeigt.
|
||||
|
||||
#### Beispiel einer Adressabbildung
|
||||
#### Beispiel für Adressabbildung
|
||||
|
||||
Wenn Sie die physische Adresse **0x800004000** in den ersten Index der L2-Tabelle schreiben, dann:
|
||||
|
||||
* Virtuelle Adressen von **0x1000000000** bis **0x1002000000** werden auf physische Adressen von **0x800004000** bis **0x802004000** abgebildet.
|
||||
* Das ist eine **Block-Abbildung** auf L2-Ebene.
|
||||
* Dies ist eine **Block-Abbildung** auf L2-Ebene.
|
||||
|
||||
Alternativ, wenn der L2-Eintrag auf eine L3-Tabelle zeigt:
|
||||
|
||||
* Jede 4 KB-Seite im virtuellen Adressbereich **0x1000000000 -> 0x1002000000** würde durch einzelne Einträge in der L3-Tabelle abgebildet werden.
|
||||
* Würde jede 4 KB-Seite im virtuellen Adressbereich **0x1000000000 -> 0x1002000000** durch einzelne Einträge in der L3-Tabelle abgebildet werden.
|
||||
|
||||
### Physischer use-after-free
|
||||
### Physical use-after-free
|
||||
|
||||
Ein **physischer use-after-free** (UAF) tritt auf, wenn:
|
||||
Ein **physical use-after-free** (UAF) tritt auf, wenn:
|
||||
|
||||
1. Ein Prozess etwas Speicher als **lesbar und beschreibbar** alloziert.
|
||||
1. Ein Prozess etwas Speicher als **lesbar und beschreibbar** **allociert**.
|
||||
2. Die **Seitentabellen** werden aktualisiert, um diesen Speicher auf eine bestimmte physische Adresse abzubilden, auf die der Prozess zugreifen kann.
|
||||
3. Der Prozess **deallokiert** (freigibt) den Speicher.
|
||||
4. Aufgrund eines **Fehlers** vergisst der Kernel jedoch, die Abbildung aus den Seitentabellen zu entfernen, obwohl er den entsprechenden physischen Speicher als frei markiert.
|
||||
5. Der Kernel kann diesen "freigegebenen" physischen Speicher dann für andere Zwecke neu verwenden, z. B. für **Kernel-Daten**.
|
||||
6. Da die Abbildung nicht entfernt wurde, kann der Prozess weiterhin **auf diesen physischen Speicher lesen und schreiben**.
|
||||
3. Der Prozess **deallociert** (freigibt) den Speicher.
|
||||
4. Aufgrund eines **Bugs** vergisst der Kernel jedoch, die Abbildung aus den Seitentabellen zu entfernen, obwohl er den entsprechenden physischen Speicher als frei markiert.
|
||||
5. Der Kernel kann diesen „freigegebenen“ physischen Speicher dann **wiederverwenden** (reallocieren) für andere Zwecke, z. B. **Kernel-Daten**.
|
||||
6. Da die Abbildung nicht entfernt wurde, kann der Prozess weiterhin **lesen und schreiben** auf diesen physischen Speicher.
|
||||
|
||||
Das bedeutet, dass der Prozess auf **Seiten des Kernel-Speichers** zugreifen kann, die sensible Daten oder Strukturen enthalten könnten, und einem Angreifer möglicherweise erlauben, **Kernel-Speicher zu manipulieren**.
|
||||
Das bedeutet, dass der Prozess **auf Kernel-Speicherseiten** zugreifen kann, die sensible Daten oder Strukturen enthalten können, und einem Angreifer potenziell erlauben, **Kernel-Speicher zu manipulieren**.
|
||||
|
||||
### IOSurface Heap Spray
|
||||
|
||||
Da der Angreifer nicht kontrollieren kann, welche spezifischen Kernel-Seiten für den freigegebenen Speicher verwendet werden, nutzt er eine Technik namens **Heap Spray**:
|
||||
Da der Angreifer nicht kontrollieren kann, welche spezifischen Kernel-Seiten dem freigegebenen Speicher zugewiesen werden, benutzt er eine Technik namens **heap spray**:
|
||||
|
||||
1. Der Angreifer **erstellt eine große Anzahl von IOSurface-Objekten** im Kernel-Speicher.
|
||||
2. Jedes IOSurface-Objekt enthält einen **magischen Wert** in einem seiner Felder, wodurch es leicht zu identifizieren ist.
|
||||
3. Sie **scannen die freigegebenen Seiten**, um zu sehen, ob sich eines dieser IOSurface-Objekte auf einer freigegebenen Seite niedergelassen hat.
|
||||
4. Wenn sie ein IOSurface-Objekt auf einer freigegebenen Seite finden, können sie es nutzen, um **Kernel-Speicher zu lesen und zu schreiben**.
|
||||
2. Jedes IOSurface-Objekt enthält einen **magic value** in einem seiner Felder, was es leicht identifizierbar macht.
|
||||
3. Sie **scannen die freigegebenen Seiten**, um zu prüfen, ob eines dieser IOSurface-Objekte auf einer freigegebenen Seite gelandet ist.
|
||||
4. Wenn sie ein IOSurface-Objekt auf einer freigegebenen Seite finden, können sie es verwenden, um **Kernel-Speicher zu lesen und zu schreiben**.
|
||||
|
||||
Mehr Infos dazu in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
||||
Mehr Informationen dazu in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
||||
|
||||
> [!TIP]
|
||||
> Beachte, dass iOS 16+ (A12+) Geräte Hardware-Mitigationen (wie PPL oder SPTM) mitbringen, die physische UAF-Techniken deutlich weniger praktikabel machen.
|
||||
> PPL erzwingt strikte MMU-Schutzmaßnahmen für Seiten, die mit code signing, entitlements und sensiblen Kernel-Daten zusammenhängen. Somit werden Schreibzugriffe aus userland oder von kompromittiertem Kernel-Code auf PPL-geschützte Seiten blockiert.
|
||||
> Secure Page Table Monitor (SPTM) erweitert PPL, indem es die Seitentabellenupdates selbst härtert. Es stellt sicher, dass selbst privilegierter Kernel-Code nicht stillschweigend freigegebene Seiten remappen oder Abbildungen manipulieren kann, ohne sichere Prüfungen zu durchlaufen.
|
||||
> KTRR (Kernel Text Read-Only Region) sperrt den Code-Bereich des Kernels nach dem Boot als read-only. Das verhindert Laufzeitänderungen am Kernel-Code und schließt damit einen großen Angriffsvektor, auf den physische UAF-Exploits oft angewiesen sind.
|
||||
> Außerdem sind `IOSurface`-Allokationen weniger vorhersehbar und schwieriger in benutzerzugängliche Regionen zu mappen, was den „magischer Wert“-Scan wesentlich unzuverlässiger macht. Und `IOSurface` ist jetzt durch entitlements und sandbox-Beschränkungen geschützt.
|
||||
> Beachte, dass iOS 16+ (A12+) Geräte hardwarebasierte Schutzmaßnahmen (wie PPL oder SPTM) einführen, die physical UAF-Techniken deutlich weniger praktikabel machen.
|
||||
> PPL erzwingt strikte MMU-Schutzmechanismen für Seiten, die mit Code-Signing, Entitlements und sensiblen Kernel-Daten zusammenhängen; selbst wenn eine Seite wiederverwendet wird, werden Schreibzugriffe aus Userland oder kompromittiertem Kernel-Code auf PPL-geschützte Seiten blockiert.
|
||||
> Secure Page Table Monitor (SPTM) erweitert PPL, indem es Seitentabellen-Updates selbst härtert. Es stellt sicher, dass selbst privilegierter Kernel-Code nicht stillschweigend freigegebene Seiten remappen oder Abbildungen manipulieren kann, ohne sichere Prüfungen zu durchlaufen.
|
||||
> KTRR (Kernel Text Read-Only Region) sperrt den Code-Bereich des Kernels nach dem Boot als schreibgeschützt. Das verhindert jegliche Laufzeit-Modifikationen am Kernel-Code und schließt damit einen großen Angriffsvektor, auf den physical UAF-Exploits oft angewiesen sind.
|
||||
> Darüber hinaus sind `IOSurface`-Allokationen weniger vorhersehbar und schwerer in benutzerzugängliche Regionen zu mappen, was den „Magic Value“-Scan-Trick deutlich unzuverlässiger macht. Und `IOSurface` wird mittlerweile durch Entitlements und Sandbox-Beschränkungen geschützt.
|
||||
|
||||
### Schritt-für-Schritt Heap Spray-Prozess
|
||||
|
||||
1. **Spray IOSurface Objects**: Der Angreifer erstellt viele IOSurface-Objekte mit einem speziellen Bezeichner ("magischer Wert").
|
||||
1. **Spray IOSurface Objects**: Der Angreifer erstellt viele IOSurface-Objekte mit einem speziellen Identifikator ("magic value").
|
||||
2. **Scan Freed Pages**: Sie prüfen, ob eines der Objekte auf einer freigegebenen Seite alloziert wurde.
|
||||
3. **Read/Write Kernel Memory**: Durch Manipulation von Feldern im IOSurface-Objekt erlangen sie die Fähigkeit zu **beliebigen Reads und Writes** im Kernel-Speicher. Das erlaubt ihnen:
|
||||
* Ein Feld zu verwenden, um **jeden 32-Bit-Wert** im Kernel-Speicher zu lesen.
|
||||
3. **Read/Write Kernel Memory**: Durch Manipulation von Feldern im IOSurface-Objekt erhalten sie die Möglichkeit, **beliebige Reads und Writes** im Kernel-Speicher durchzuführen. Dies erlaubt ihnen:
|
||||
* Ein Feld zu verwenden, um **beliebige 32-Bit-Werte** im Kernel-Speicher zu lesen.
|
||||
* Ein anderes Feld zu verwenden, um **64-Bit-Werte zu schreiben**, wodurch ein stabiler **Kernel read/write primitive** entsteht.
|
||||
|
||||
Erzeuge IOSurface-Objekte mit dem magischen Wert IOSURFACE\_MAGIC, um später danach zu suchen:
|
||||
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
|
||||
```c
|
||||
void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
|
||||
if (*nClients >= 0x4000) return;
|
||||
@ -148,25 +162,25 @@ free(surfaceIDs);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
### Kernel-Lese-/Schreibzugriff mit IOSurface erreichen
|
||||
### Erreichen von Kernel-Lese-/Schreibzugriff mit IOSurface
|
||||
|
||||
Nachdem Kontrolle über ein IOSurface-Objekt im Kernel-Speicher erreicht wurde (auf eine freigegebene physische Seite abgebildet, die vom userspace zugänglich ist), können wir es für **beliebige Kernel-Lese- und Schreiboperationen** verwenden.
|
||||
Nachdem Kontrolle über ein IOSurface-Objekt im Kernel-Speicher (auf eine freigegebene physische Seite gemappt, die aus dem userspace zugreifbar ist) erlangt wurde, können wir es für **beliebige Kernel-Lese- und Schreiboperationen** verwenden.
|
||||
|
||||
**Wichtige Felder in IOSurface**
|
||||
**Key Fields in IOSurface**
|
||||
|
||||
Die IOSurface hat zwei entscheidende Felder:
|
||||
Das IOSurface-Objekt hat zwei entscheidende Felder:
|
||||
|
||||
1. **Use Count Pointer**: Ermöglicht ein **32-bit read**.
|
||||
2. **Indexed Timestamp Pointer**: Ermöglicht ein **64-bit write**.
|
||||
1. **Use Count Pointer**: Ermöglicht einen **32-bit read**.
|
||||
2. **Indexed Timestamp Pointer**: Ermöglicht einen **64-bit write**.
|
||||
|
||||
Durch Überschreiben dieser Pointer leiten wir sie auf beliebige Adressen im Kernel-Speicher um und ermöglichen so Lese-/Schreibzugriff.
|
||||
Durch Überschreiben dieser Pointer leiten wir sie auf beliebige Adressen im Kernel-Speicher um und ermöglichen so Lese-/Schreibfähigkeiten.
|
||||
|
||||
#### 32-Bit Kernel-Lesezugriff
|
||||
|
||||
Um einen Lesezugriff durchzuführen:
|
||||
|
||||
1. Überschreibe den **use count pointer**, sodass er auf die Zieladresse minus einem 0x14-Byte-Offset zeigt.
|
||||
2. Benutze die Methode `get_use_count`, um den Wert an dieser Adresse zu lesen.
|
||||
1. Überschreibe den **use count pointer**, sodass er auf die Zieladresse minus einem 0x14-Byte-Offset zeigt.
|
||||
2. Verwende die Methode `get_use_count`, um den Wert an dieser Adresse auszulesen.
|
||||
```c
|
||||
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
|
||||
uint64_t args[1] = {surfaceID};
|
||||
@ -184,11 +198,11 @@ iosurface_set_use_count_pointer(info.object, orig);
|
||||
return value;
|
||||
}
|
||||
```
|
||||
#### 64-Bit Kernel Write
|
||||
#### 64-Bit Kernel-Schreibvorgang
|
||||
|
||||
Um einen Schreibvorgang durchzuführen:
|
||||
|
||||
1. Überschreibe den **indexed timestamp pointer** auf die Zieladresse.
|
||||
1. Überschreibe den **Pointer für den indexierten Zeitstempel** mit der Zieladresse.
|
||||
2. Verwende die Methode `set_indexed_timestamp`, um einen 64-Bit-Wert zu schreiben.
|
||||
```c
|
||||
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
|
||||
@ -203,13 +217,13 @@ set_indexed_timestamp(info.client, info.surface, value);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, orig);
|
||||
}
|
||||
```
|
||||
#### Zusammenfassung des Exploit-Ablaufs
|
||||
#### Exploit-Ablauf (Zusammenfassung)
|
||||
|
||||
1. **Trigger Physical Use-After-Free**: Freie Seiten stehen zur Wiederverwendung zur Verfügung.
|
||||
2. **Spray IOSurface Objects**: Allokiere viele IOSurface-Objekte mit einem eindeutigen "magic value" im Kernel-Speicher.
|
||||
1. **Trigger Physical Use-After-Free**: Freigegebene Seiten stehen zur Wiederverwendung zur Verfügung.
|
||||
2. **Spray IOSurface Objects**: Weise viele IOSurface-Objekte mit einem eindeutigen "magic value" im Kernel-Speicher zu.
|
||||
3. **Identify Accessible IOSurface**: Finde ein IOSurface auf einer freigegebenen Seite, die du kontrollierst.
|
||||
4. **Abuse Use-After-Free**: Ändere Pointer im IOSurface-Objekt, um über IOSurface-Methoden beliebige **kernel read/write** zu ermöglichen.
|
||||
4. **Abuse Use-After-Free**: Ändere Pointer im IOSurface-Objekt, um beliebige **kernel read/write** über IOSurface-Methoden zu ermöglichen.
|
||||
|
||||
Mit diesen Primitiven ermöglicht der Exploit kontrollierte **32-bit reads** und **64-bit writes** auf den Kernel-Speicher. Weitere jailbreak-Schritte könnten stabilere read/write primitives erfordern, die das Umgehen zusätzlicher Schutzmechanismen nötig machen (z. B. PPL auf neueren arm64e-Geräten).
|
||||
Mit diesen Primitiven liefert der Exploit kontrollierte **32-bit reads** und **64-bit writes** im Kernel-Speicher. Weitere jailbreak-Schritte könnten stabilere read/write-Primitiven erfordern, die das Umgehen zusätzlicher Schutzmechanismen (z. B. PPL auf neueren arm64e-Geräten) notwendig machen.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,69 +1,147 @@
|
||||
# Phishing erkennen
|
||||
# Erkennen von Phishing
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Einführung
|
||||
## Einleitung
|
||||
|
||||
Um einen Phishing-Versuch zu erkennen, ist es wichtig, die **Phishing-Techniken zu verstehen, die heutzutage verwendet werden**. Auf der übergeordneten Seite dieses Beitrags finden Sie diese Informationen. Wenn Sie sich nicht bewusst sind, welche Techniken heute verwendet werden, empfehle ich Ihnen, zur übergeordneten Seite zu gehen und mindestens diesen Abschnitt zu lesen.
|
||||
Um einen Phishing-Versuch zu erkennen, ist es wichtig, die **Phishing-Techniken zu verstehen, die heutzutage verwendet werden**. Auf der übergeordneten Seite dieses Beitrags findest du diese Informationen; wenn du nicht weißt, welche Techniken heute verwendet werden, empfehle ich, die übergeordnete Seite zu lesen und zumindest diesen Abschnitt zu prüfen.
|
||||
|
||||
Dieser Beitrag basiert auf der Idee, dass die **Angreifer versuchen werden, den Domainnamen des Opfers irgendwie nachzuahmen oder zu verwenden**. Wenn Ihre Domain `example.com` heißt und Sie aus irgendeinem Grund mit einem völlig anderen Domainnamen wie `youwonthelottery.com` gefischt werden, werden diese Techniken es nicht aufdecken.
|
||||
Dieser Beitrag basiert auf der Idee, dass die **Angreifer versuchen werden, irgendwie den Domainnamen des Opfers zu imitieren oder zu nutzen**. Wenn deine Domain `example.com` heißt und du mit einer völlig anderen Domain wie `youwonthelottery.com` gephisht wirst, werden diese Techniken das nicht aufdecken.
|
||||
|
||||
## Variationen von Domainnamen
|
||||
## Domain name variations
|
||||
|
||||
Es ist ziemlich **einfach**, diese **Phishing**-Versuche aufzudecken, die einen **ähnlichen Domainnamen** in der E-Mail verwenden.\
|
||||
Es reicht aus, eine **Liste der wahrscheinlichsten Phishing-Namen** zu erstellen, die ein Angreifer verwenden könnte, und zu **überprüfen**, ob sie **registriert** sind oder einfach zu überprüfen, ob es eine **IP** gibt, die sie verwendet.
|
||||
Es ist recht **einfach**, diese **Phishing**-Versuche aufzudecken, die einen **ähnlichen Domain**-Namen in der E-Mail verwenden.\
|
||||
Es reicht aus, eine Liste der wahrscheinlichsten Phishing-Namen zu **generieren**, die ein Angreifer verwenden könnte, und zu **prüfen**, ob sie **registriert** sind oder ob irgendeine **IP** sie verwendet.
|
||||
|
||||
### Verdächtige Domains finden
|
||||
### Finding suspicious domains
|
||||
|
||||
Zu diesem Zweck können Sie eines der folgenden Tools verwenden. Beachten Sie, dass diese Tools auch automatisch DNS-Anfragen durchführen, um zu überprüfen, ob der Domainname eine zugewiesene IP hat:
|
||||
Für diesen Zweck kannst du eines der folgenden Tools verwenden. Beachte, dass diese Tools automatisch DNS-Anfragen durchführen, um zu prüfen, ob der Domain eine IP zugewiesen ist:
|
||||
|
||||
- [**dnstwist**](https://github.com/elceef/dnstwist)
|
||||
- [**urlcrazy**](https://github.com/urbanadventurer/urlcrazy)
|
||||
|
||||
Tipp: Wenn du eine Kandidatenliste erzeugst, füttere sie auch in deine DNS-Resolver-Logs, um **NXDOMAIN-Abfragen aus deinem Unternehmen** zu erkennen (Benutzer, die versuchen, einen Tippfehler aufzurufen, bevor der Angreifer ihn tatsächlich registriert). Sinkhole oder blockiere diese Domains vorab, wenn die Richtlinie das erlaubt.
|
||||
|
||||
### Bitflipping
|
||||
|
||||
**Eine kurze Erklärung dieser Technik finden Sie auf der übergeordneten Seite. Oder lesen Sie die ursprüngliche Forschung unter** [**https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/**](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)
|
||||
**Einer kurzen Erklärung dieser Technik findest du auf der übergeordneten Seite. Oder lies die Originalforschung unter** [**https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/**](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)
|
||||
|
||||
Zum Beispiel kann eine 1-Bit-Modifikation in der Domain microsoft.com sie in _windnws.com_ verwandeln.\
|
||||
**Angreifer können so viele Bit-Flipping-Domains wie möglich registrieren, die mit dem Opfer in Verbindung stehen, um legitime Benutzer auf ihre Infrastruktur umzuleiten**.
|
||||
Zum Beispiel kann eine 1-Bit-Änderung in der Domain microsoft.com sie in _windnws.com._ verwandeln.\
|
||||
**Angreifer können so viele bit-flipping-Domains wie möglich im Zusammenhang mit dem Opfer registrieren, um legitime Benutzer auf ihre Infrastruktur umzuleiten.**
|
||||
|
||||
**Alle möglichen Bit-Flipping-Domainnamen sollten ebenfalls überwacht werden.**
|
||||
**Alle möglichen bit-flipping-Domainnamen sollten ebenfalls überwacht werden.**
|
||||
|
||||
### Grundlegende Überprüfungen
|
||||
Wenn du auch Homoglyph/IDN-Lookalikes (z. B. Mischung aus lateinischen/kyrillischen Zeichen) berücksichtigen musst, schau nach:
|
||||
|
||||
Sobald Sie eine Liste potenziell verdächtiger Domainnamen haben, sollten Sie sie **überprüfen** (hauptsächlich die Ports HTTP und HTTPS), um **zu sehen, ob sie ein Login-Formular verwenden, das dem eines der Opfer-Domains ähnlich ist**.\
|
||||
Sie könnten auch Port 3333 überprüfen, um zu sehen, ob er offen ist und eine Instanz von `gophish` ausführt.\
|
||||
Es ist auch interessant zu wissen, **wie alt jede entdeckte verdächtige Domain ist**, je jünger sie ist, desto riskanter ist sie.\
|
||||
Sie können auch **Screenshots** der verdächtigen HTTP- und/oder HTTPS-Webseite machen, um zu sehen, ob sie verdächtig ist, und in diesem Fall **darauf zugreifen, um einen genaueren Blick zu werfen**.
|
||||
{{#ref}}
|
||||
homograph-attacks.md
|
||||
{{#endref}}
|
||||
|
||||
### Erweiterte Überprüfungen
|
||||
### Basic checks
|
||||
|
||||
Wenn Sie einen Schritt weiter gehen möchten, empfehle ich Ihnen, **diese verdächtigen Domains zu überwachen und von Zeit zu Zeit nach weiteren zu suchen** (jeden Tag? Es dauert nur ein paar Sekunden/Minuten). Sie sollten auch die offenen **Ports** der zugehörigen IPs **überprüfen** und **nach Instanzen von `gophish` oder ähnlichen Tools suchen** (ja, Angreifer machen auch Fehler) und die HTTP- und HTTPS-Webseiten der verdächtigen Domains und Subdomains **überwachen**, um zu sehen, ob sie ein Login-Formular von den Webseiten des Opfers kopiert haben.\
|
||||
Um dies zu **automatisieren**, empfehle ich, eine Liste von Login-Formularen der Domains des Opfers zu haben, die verdächtigen Webseiten zu durchsuchen und jedes gefundene Login-Formular in den verdächtigen Domains mit jedem Login-Formular der Domain des Opfers mit etwas wie `ssdeep` zu vergleichen.\
|
||||
Wenn Sie die Login-Formulare der verdächtigen Domains gefunden haben, können Sie versuchen, **Müllanmeldeinformationen zu senden** und **zu überprüfen, ob Sie auf die Domain des Opfers umgeleitet werden**.
|
||||
Sobald du eine Liste potenziell verdächtiger Domainnamen hast, solltest du sie **prüfen** (hauptsächlich die Ports HTTP und HTTPS), um **zu sehen, ob sie ein Login-Formular verwenden, das dem einer Domain des Opfers ähnelt**.\
|
||||
Du könntest auch Port 3333 prüfen, um zu sehen, ob er offen ist und eine Instanz von `gophish` läuft.\
|
||||
Es ist außerdem interessant zu wissen, **wie alt jede entdeckte verdächtige Domain ist** — je jünger, desto riskanter.\
|
||||
Du kannst auch **Screenshots** der HTTP- und/oder HTTPS-Seite der verdächtigen Domain erstellen, um zu prüfen, ob sie verdächtig ist, und in diesem Fall **diese Seite aufrufen, um sie genauer zu untersuchen**.
|
||||
|
||||
## Domainnamen mit Schlüsselwörtern
|
||||
### Advanced checks
|
||||
|
||||
Die übergeordnete Seite erwähnt auch eine Technik zur Variation von Domainnamen, die darin besteht, den **Domainnamen des Opfers in eine größere Domain** einzufügen (z. B. paypal-financial.com für paypal.com).
|
||||
Wenn du einen Schritt weiter gehen willst, empfehle ich, diese verdächtigen Domains zu **überwachen und gelegentlich nach weiteren zu suchen** (täglich? es dauert nur ein paar Sekunden/Minuten). Du solltest auch die offenen **Ports** der zugehörigen IPs prüfen und **nach Instanzen von `gophish` oder ähnlichen Tools suchen** (ja, Angreifer machen auch Fehler) und die HTTP- und HTTPS-Webseiten der verdächtigen Domains und Subdomains **überwachen**, um zu sehen, ob sie ein Login-Formular von den Seiten des Opfers kopiert haben.\
|
||||
Um dies zu **automatisieren**, empfehle ich, eine Liste der Login-Formulare der Domains des Opfers zu haben, die verdächtigen Webseiten zu crawlen und jedes gefundene Login-Formular auf den verdächtigen Domains mit jedem Login-Formular der Opfer-Domain mittels etwas wie `ssdeep` zu vergleichen.\
|
||||
Wenn du die Login-Formulare der verdächtigen Domains gefunden hast, kannst du versuchen, **verfälschte Zugangsdaten zu senden** und **zu prüfen, ob sie dich auf die Domain des Opfers umleiten**.
|
||||
|
||||
### Zertifikatstransparenz
|
||||
---
|
||||
|
||||
Es ist nicht möglich, den vorherigen "Brute-Force"-Ansatz zu verfolgen, aber es ist tatsächlich **möglich, solche Phishing-Versuche aufzudecken**, auch dank der Zertifikatstransparenz. Jedes Mal, wenn ein Zertifikat von einer CA ausgestellt wird, werden die Details öffentlich gemacht. Das bedeutet, dass es durch das Lesen der Zertifikatstransparenz oder sogar durch deren Überwachung **möglich ist, Domains zu finden, die ein Schlüsselwort in ihrem Namen verwenden**. Zum Beispiel, wenn ein Angreifer ein Zertifikat für [https://paypal-financial.com](https://paypal-financial.com) generiert, ist es möglich, durch das Ansehen des Zertifikats das Schlüsselwort "paypal" zu finden und zu wissen, dass eine verdächtige E-Mail verwendet wird.
|
||||
### Hunting by favicon and web fingerprints (Shodan/ZoomEye/Censys)
|
||||
|
||||
Der Beitrag [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) schlägt vor, dass Sie Censys verwenden können, um nach Zertifikaten zu suchen, die ein bestimmtes Schlüsselwort betreffen, und nach Datum (nur "neue" Zertifikate) und nach dem CA-Aussteller "Let's Encrypt" zu filtern:
|
||||
Viele Phishing-Kits verwenden Favicons der Marke, die sie imitieren, wieder. Internetweite Scanner berechnen einen MurmurHash3 des base64-encodierten Favicons. Du kannst den Hash erzeugen und darauf pivotieren:
|
||||
|
||||
Python-Beispiel (mmh3):
|
||||
```python
|
||||
import base64, requests, mmh3
|
||||
url = "https://www.paypal.com/favicon.ico" # change to your brand icon
|
||||
b64 = base64.encodebytes(requests.get(url, timeout=10).content)
|
||||
print(mmh3.hash(b64)) # e.g., 309020573
|
||||
```
|
||||
- Shodan abfragen: `http.favicon.hash:309020573`
|
||||
- Mit Tools: Schau dir Community-Tools wie favfreak an, um Hashes und Dorks für Shodan/ZoomEye/Censys zu generieren.
|
||||
|
||||
Hinweise
|
||||
- Favicons werden wiederverwendet; behandle Treffer als Leads und validiere Inhalt und Zertifikate, bevor du handelst.
|
||||
- Kombiniere mit domain-age und Keyword-Heuristiken für bessere Präzision.
|
||||
|
||||
### URL-Telemetrie-Suche (urlscan.io)
|
||||
|
||||
`urlscan.io` speichert historische Screenshots, DOM, Requests und TLS-Metadaten von übermittelten URLs. Du kannst nach Markenmissbrauch und Kopien suchen:
|
||||
|
||||
Beispielabfragen (UI oder API):
|
||||
- Finde Lookalikes unter Ausschluss deiner legitimen Domains: `page.domain:(/.*yourbrand.*/ AND NOT yourbrand.com AND NOT www.yourbrand.com)`
|
||||
- Finde Seiten, die deine Assets hotlinken: `domain:yourbrand.com AND NOT page.domain:yourbrand.com`
|
||||
- Auf jüngste Ergebnisse beschränken: füge `AND date:>now-7d` hinzu
|
||||
|
||||
API-Beispiel:
|
||||
```bash
|
||||
# Search recent scans mentioning your brand
|
||||
curl -s 'https://urlscan.io/api/v1/search/?q=page.domain:(/.*yourbrand.*/%20AND%20NOT%20yourbrand.com)%20AND%20date:>now-7d' \
|
||||
-H 'API-Key: <YOUR_URLSCAN_KEY>' | jq '.results[].page.url'
|
||||
```
|
||||
Aus dem JSON, pivot auf:
|
||||
- `page.tlsIssuer`, `page.tlsValidFrom`, `page.tlsAgeDays` um sehr neue certs bei Lookalikes zu erkennen
|
||||
- `task.source` Werte wie `certstream-suspicious` um Funde mit CT-Überwachung zu verknüpfen
|
||||
|
||||
### Domainalter via RDAP (skriptbar)
|
||||
|
||||
RDAP liefert maschinenlesbare Erstellungsereignisse. Nützlich, um **neu registrierte Domains (NRDs)** zu kennzeichnen.
|
||||
```bash
|
||||
# .com/.net RDAP (Verisign)
|
||||
curl -s https://rdap.verisign.com/com/v1/domain/suspicious-example.com | \
|
||||
jq -r '.events[] | select(.eventAction=="registration") | .eventDate'
|
||||
|
||||
# Generic helper using rdap.net redirector
|
||||
curl -s https://www.rdap.net/domain/suspicious-example.com | jq
|
||||
```
|
||||
Ergänzen Sie Ihre Pipeline, indem Sie Domains nach Registrierungsalter gruppieren (z. B. <7 days, <30 days) und die Triage entsprechend priorisieren.
|
||||
|
||||
### TLS/JAx fingerprints to spot AiTM infrastructure
|
||||
|
||||
Moderne Credential-Phishing-Kampagnen nutzen zunehmend **Adversary-in-the-Middle (AiTM)** Reverse-Proxies (z. B. Evilginx), um Session-Tokens zu stehlen. Sie können netzwerkseitige Erkennungen hinzufügen:
|
||||
|
||||
- Protokollieren Sie TLS/HTTP-Fingerprints (JA3/JA4/JA4S/JA4H) am Egress. Einige Evilginx-Builds wurden mit stabilen JA4-Client/Server-Werten beobachtet. Generieren Sie Alarme nur bei bekannten bösartigen Fingerprints als schwaches Signal und bestätigen Sie immer mit Content- und Domain-Intel.
|
||||
- Zeichnen Sie proaktiv TLS-Zertifikat-Metadaten auf (Issuer, SAN-Anzahl, Wildcard-Nutzung, Gültigkeit) für Lookalike-Hosts, die über CT oder urlscan entdeckt wurden, und korrelieren Sie diese mit DNS-Alter und Geolocation.
|
||||
|
||||
> Hinweis: Behandeln Sie Fingerprints als Enrichment, nicht als alleinige Blocker; Frameworks entwickeln sich weiter und können randomisieren oder verschleiern.
|
||||
|
||||
### Domain names using keywords
|
||||
|
||||
Die übergeordnete Seite erwähnt außerdem eine Domain-Name-Variationstechnik, die darin besteht, den **Domainnamen des Opfers in eine größere Domain einzubetten** (z. B. paypal-financial.com statt paypal.com).
|
||||
|
||||
#### Certificate Transparency
|
||||
|
||||
Der vorherige "Brute-Force"-Ansatz ist nicht möglich, aber es ist tatsächlich **möglich, solche Phishing-Versuche aufzudecken**, und zwar dank Certificate Transparency. Jedes Mal, wenn ein Zertifikat von einer CA ausgestellt wird, werden die Details öffentlich gemacht. Das bedeutet, dass man durch das Lesen der Certificate Transparency oder sogar durch deren Überwachung **Domains finden kann, die ein Schlüsselwort in ihrem Namen verwenden**. Wenn ein Angreifer beispielsweise ein Zertifikat für [https://paypal-financial.com](https://paypal-financial.com) erzeugt, kann man beim Sichtbarmachen des Zertifikats das Schlüsselwort "paypal" erkennen und wissen, dass eine verdächtige E-Mail verwendet wird.
|
||||
|
||||
Der Beitrag [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) schlägt vor, Censys zu verwenden, um nach Zertifikaten mit einem bestimmten Schlüsselwort zu suchen und nach Datum (nur "neue" Zertifikate) und nach dem CA-Issuer "Let's Encrypt" zu filtern:
|
||||
|
||||
.png>)
|
||||
|
||||
Sie können jedoch "das Gleiche" mit dem kostenlosen Web-Tool [**crt.sh**](https://crt.sh) tun. Sie können **nach dem Schlüsselwort suchen** und die **Ergebnisse nach Datum und CA filtern**, wenn Sie möchten.
|
||||
Sie können das Gleiche jedoch mit dem kostenlosen Webdienst [**crt.sh**](https://crt.sh) tun. Sie können **nach dem Schlüsselwort suchen** und die **Ergebnisse bei Bedarf nach Datum und CA filtern**.
|
||||
|
||||
.png>)
|
||||
|
||||
Mit dieser letzten Option können Sie sogar das Feld Matching Identities verwenden, um zu sehen, ob eine Identität der echten Domain mit einer der verdächtigen Domains übereinstimmt (beachten Sie, dass eine verdächtige Domain ein falsch positives Ergebnis sein kann).
|
||||
Mit dieser letzten Option können Sie sogar das Feld Matching Identities verwenden, um zu prüfen, ob eine Identity der echten Domain mit einer der verdächtigen Domains übereinstimmt (beachten Sie, dass eine verdächtige Domain ein False Positive sein kann).
|
||||
|
||||
**Eine weitere Alternative** ist das fantastische Projekt namens [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream bietet einen Echtzeit-Stream neu generierter Zertifikate, den Sie verwenden können, um bestimmte Schlüsselwörter in (nahezu) Echtzeit zu erkennen. Tatsächlich gibt es ein Projekt namens [**phishing_catcher**](https://github.com/x0rz/phishing_catcher), das genau das tut.
|
||||
**Eine weitere Alternative** ist das großartige Projekt [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream liefert einen Echtzeit-Stream neu erzeugter Zertifikate, den Sie verwenden können, um bestimmte Schlüsselwörter in (nahezu) Echtzeit zu erkennen. Tatsächlich gibt es ein Projekt namens [**phishing_catcher**](https://github.com/x0rz/phishing_catcher), das genau das tut.
|
||||
|
||||
### **Neue Domains**
|
||||
Praktischer Tipp: Wenn Sie CT-Treffer triagieren, priorisieren Sie NRDs, untrusted/unknown Registrare, privacy-proxy WHOIS und Zertifikate mit sehr aktuellen NotBefore-Zeiten. Führen Sie eine Allowlist Ihrer eigenen Domains/Marken, um Rauschen zu reduzieren.
|
||||
|
||||
**Eine letzte Alternative** besteht darin, eine Liste von **neu registrierten Domains** für einige TLDs zu sammeln ([Whoxy](https://www.whoxy.com/newly-registered-domains/) bietet einen solchen Service) und die **Schlüsselwörter in diesen Domains zu überprüfen**. Allerdings verwenden lange Domains normalerweise einen oder mehrere Subdomains, daher wird das Schlüsselwort nicht innerhalb der FLD erscheinen und Sie werden die Phishing-Subdomain nicht finden können.
|
||||
#### **New domains**
|
||||
|
||||
**Eine letzte Alternative** ist, eine Liste neu registrierter Domains für einige TLDs zu sammeln ([Whoxy](https://www.whoxy.com/newly-registered-domains/) bietet einen solchen Service) und **die Schlüsselwörter in diesen Domains zu prüfen**. Lange Domains verwenden jedoch oft ein oder mehrere Subdomains, daher erscheint das Schlüsselwort nicht im FLD und Sie können die Phishing-Subdomain nicht finden.
|
||||
|
||||
Zusätzliche Heuristik: Behandeln Sie bestimmte **file-extension TLDs** (z. B. `.zip`, `.mov`) bei Alarmierung mit zusätzlicher Vorsicht. Diese werden in Lures häufig mit Dateinamen verwechselt; kombinieren Sie das TLD-Signal mit Marken-Keywords und NRD-Alter für bessere Präzision.
|
||||
|
||||
## References
|
||||
|
||||
- urlscan.io – Search API reference: https://urlscan.io/docs/search/
|
||||
- APNIC Blog – JA4+ network fingerprinting (includes Evilginx example): https://blog.apnic.net/2023/11/22/ja4-network-fingerprinting/
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -24,13 +24,15 @@
|
||||
/* 2 — load a single index (remote → local) */
|
||||
async function loadIndex(remote, local, isCloud=false){
|
||||
let rawLoaded = false;
|
||||
try {
|
||||
const r = await fetch(remote,{mode:'cors'});
|
||||
if (!r.ok) throw new Error('HTTP '+r.status);
|
||||
importScripts(URL.createObjectURL(new Blob([await r.text()],{type:'application/javascript'})));
|
||||
rawLoaded = true;
|
||||
} catch(e){ console.warn('remote',remote,'failed →',e); }
|
||||
if(!rawLoaded){
|
||||
if(remote){
|
||||
try {
|
||||
const r = await fetch(remote,{mode:'cors'});
|
||||
if (!r.ok) throw new Error('HTTP '+r.status);
|
||||
importScripts(URL.createObjectURL(new Blob([await r.text()],{type:'application/javascript'})));
|
||||
rawLoaded = true;
|
||||
} catch(e){ console.warn('remote',remote,'failed →',e); }
|
||||
}
|
||||
if(!rawLoaded && local){
|
||||
try { importScripts(abs(local)); rawLoaded = true; }
|
||||
catch(e){ console.error('local',local,'failed →',e); }
|
||||
}
|
||||
@ -40,13 +42,41 @@
|
||||
return data;
|
||||
}
|
||||
|
||||
async function loadWithFallback(remotes, local, isCloud=false){
|
||||
if(remotes.length){
|
||||
const [primary, ...secondary] = remotes;
|
||||
const primaryData = await loadIndex(primary, null, isCloud);
|
||||
if(primaryData) return primaryData;
|
||||
|
||||
if(local){
|
||||
const localData = await loadIndex(null, local, isCloud);
|
||||
if(localData) return localData;
|
||||
}
|
||||
|
||||
for (const remote of secondary){
|
||||
const data = await loadIndex(remote, null, isCloud);
|
||||
if(data) return data;
|
||||
}
|
||||
}
|
||||
|
||||
return local ? loadIndex(null, local, isCloud) : null;
|
||||
}
|
||||
|
||||
(async () => {
|
||||
const MAIN_RAW = 'https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/refs/heads/master/searchindex.js';
|
||||
const CLOUD_RAW = 'https://raw.githubusercontent.com/HackTricks-wiki/hacktricks-cloud/refs/heads/master/searchindex.js';
|
||||
const htmlLang = (document.documentElement.lang || 'en').toLowerCase();
|
||||
const lang = htmlLang.split('-')[0];
|
||||
const mainReleaseBase = 'https://github.com/HackTricks-wiki/hacktricks/releases/download';
|
||||
const cloudReleaseBase = 'https://github.com/HackTricks-wiki/hacktricks-cloud/releases/download';
|
||||
|
||||
const mainTags = Array.from(new Set([`searchindex-${lang}`, 'searchindex-en', 'searchindex-master']));
|
||||
const cloudTags = Array.from(new Set([`searchindex-${lang}`, 'searchindex-en', 'searchindex-master']));
|
||||
|
||||
const MAIN_REMOTE_SOURCES = mainTags.map(tag => `${mainReleaseBase}/${tag}/searchindex.js`);
|
||||
const CLOUD_REMOTE_SOURCES = cloudTags.map(tag => `${cloudReleaseBase}/${tag}/searchindex.js`);
|
||||
|
||||
const indices = [];
|
||||
const main = await loadIndex(MAIN_RAW , '/searchindex.js', false); if(main) indices.push(main);
|
||||
const cloud= await loadIndex(CLOUD_RAW, '/searchindex-cloud.js', true ); if(cloud) indices.push(cloud);
|
||||
const main = await loadWithFallback(MAIN_REMOTE_SOURCES , '/searchindex.js', false); if(main) indices.push(main);
|
||||
const cloud= await loadWithFallback(CLOUD_REMOTE_SOURCES, '/searchindex-cloud.js', true ); if(cloud) indices.push(cloud);
|
||||
|
||||
if(!indices.length){ postMessage({ready:false, error:'no-index'}); return; }
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user