Translated ['src/generic-methodologies-and-resources/phishing-methodolog

2025-10-10 18:36:50 +00:00 · 2025-09-29 23:32:14 +00:00 · 2025-09-29 23:32:14 +00:00 · e6792c5b1c
commit e6792c5b1c
parent 714e79b2df
4 changed files with 240 additions and 118 deletions
--- a/.gitignore
+++ b/.gitignore
@ -11,3 +11,4 @@ book
 book/*
 hacktricks-preprocessor.log
 hacktricks-preprocessor-error.log
+searchindex.js
--- a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md
+++ b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md
@ -1,99 +1,112 @@
-# iOS Physical Use After Free przez IOSurface
+# iOS Physical Use After Free via IOSurface

 {{#include ../../banners/hacktricks-training.md}}


-## Fizyczny use-after-free
+## iOS Exploit Mitigations

-To podsumowanie wpisu z [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html). Dalsze informacje o exploitach wykorzystujących tę technikę można znaleźć w [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
+- **Code Signing** in iOS działa poprzez wymóg, że każdy kawałek wykonywalnego kodu (aplikacje, biblioteki, rozszerzenia itp.) musi być kryptograficznie podpisany certyfikatem wydanym przez Apple. Gdy kod jest ładowany, iOS weryfikuje podpis cyfrowy względem zaufanego rootu Apple. Jeśli podpis jest nieprawidłowy, brakujący lub zmodyfikowany, system odmówi jego uruchomienia. To uniemożliwia atakującym wstrzykiwanie złośliwego kodu do legalnych aplikacji lub uruchamianie niepodpisanych binarek, skutecznie blokując większość łańcuchów exploitów polegających na wykonywaniu dowolnego kodu.
+- **CoreTrust** to podsystem iOS odpowiedzialny za egzekwowanie code signing w czasie wykonywania. Weryfikuje podpisy bezpośrednio przy użyciu root certyfikatu Apple, nie polegając na lokalnych pamięciach zaufania, co oznacza, że tylko binaria podpisane przez Apple (lub z prawidłowymi entitlements) mogą się wykonać. CoreTrust zapewnia, że nawet jeśli atakujący zmodyfikował aplikację po instalacji, zmienił biblioteki systemowe lub próbował załadować niepodpisany kod, system zablokuje wykonanie, chyba że kod nadal ma poprawny podpis. Ta rygorystyczna egzekucja zamyka wiele wektorów post-exploitation, które starsze wersje iOS pozwalały obejść.
+- **Data Execution Prevention (DEP)** oznacza regiony pamięci jako nie-wykonywalne, chyba że explicite zawierają kod. To uniemożliwia atakującym wstrzykiwanie shellcode do regionów danych (np. stosu czy sterty) i jego uruchamianie, zmuszając do użycia bardziej złożonych technik jak ROP.
+- **ASLR (Address Space Layout Randomization)** losuje adresy pamięci kodu, bibliotek, stosu i sterty przy każdym uruchomieniu systemu. Utrudnia to przewidzenie lokalizacji przydatnych instrukcji lub gadgetów, łamiąc wiele łańcuchów exploitów zależnych od przewidywalnego układu pamięci.
+- **KASLR (Kernel ASLR)** stosuje tę samą losowość do jądra iOS. Przez przetasowanie bazowego adresu jądra przy każdym rozruchu uniemożliwia łatwe znalezienie funkcji lub struktur jądra, podnosząc trudność exploitów na poziomie jądra, które mogłyby uzyskać pełną kontrolę nad systemem.
+- **Kernel Patch Protection (KPP)**, znany również jako **AMCC (Apple Mobile File Integrity)** w iOS, ciągle monitoruje strony kodu jądra, aby upewnić się, że nie zostały zmodyfikowane. Jeśli wykryje manipulację — np. exploit próbujący załatać funkcje jądra lub wstawić złośliwy kod — urządzenie zasygnalizuje panic i zrestartuje się. Ta ochrona utrudnia trwałe exploity jądra, ponieważ atakujący nie mogą po prostu hookować czy modyfikować instrukcji jądra bez wywołania awarii systemu.
+- **Kernel Text Readonly Region (KTRR)** to sprzętowa funkcja bezpieczeństwa wprowadzona na urządzeniach iOS. Używa kontrolera pamięci CPU do oznaczenia sekcji kodu jądra (text) jako permanentnie tylko do odczytu po starcie. Po zablokowaniu nawet samo jądro nie może modyfikować tego regionu pamięci. To zapobiega atakom (i uprzywilejowanemu kodowi) patchowania instrukcji jądra w czasie działania, zamykając dużą klasę exploitów polegających na bezpośredniej modyfikacji kodu jądra.
+- **Pointer Authentication Codes (PAC)** używają podpisów kryptograficznych osadzonych w nieużywanych bitach wskaźników, aby weryfikować ich integralność przed użyciem. Gdy wskaźnik (np. adres powrotu lub wskaźnik funkcji) jest tworzony, CPU podpisuje go sekretnym kluczem; przed dereferencją CPU sprawdza podpis. Jeśli wskaźnik został zmodyfikowany, kontrola zawiedzie i wykonanie zostanie przerwane. To uniemożliwia atakującym fałszowanie lub ponowne użycie podrobionych wskaźników w exploitach korupcji pamięci, utrudniając techniki typu ROP czy JOP.
+- **Privilege Access never (PAN)** to funkcja sprzętowa, która uniemożliwia jądru (tryb uprzywilejowany) bezpośrednie odczytywanie pamięci user-space, chyba że explicite włączy dostęp. To zatrzymuje atakujących, którzy uzyskali wykonanie kodu jądra, przed łatwym czytaniem lub zapisywaniem pamięci użytkownika w celu eskalacji uprawnień lub kradzieży danych. Egzekwując ścisły podział, PAN zmniejsza skutki exploitów jądra i blokuje wiele powszechnych technik eskalacji uprawnień.
+- **Page Protection Layer (PPL)** to mechanizm bezpieczeństwa iOS, który chroni krytyczne regiony pamięci zarządzane przez jądro, szczególnie te związane z code signing i entitlements. Egzekwuje ścisłe ochrony zapisu używając MMU oraz dodatkowych sprawdzeń, zapewniając, że nawet uprzywilejowany kod jądra nie może dowolnie modyfikować wrażliwych stron. To zapobiega atakującym, którzy uzyskali wykonanie na poziomie jądra, przed manipulacją strukturami krytycznymi dla bezpieczeństwa, utrudniając utrzymanie trwałości i obejścia code signing.

-### Zarządzanie pamięcią w XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
+## Physical use-after-free

-Przestrzeń adresowa pamięci wirtualnej dla procesów użytkownika na iOS rozciąga się od **0x0 do 0x8000000000**. Jednak te adresy nie mapują się bezpośrednio na pamięć fizyczną. Zamiast tego jądro używa **tablic stron** do tłumaczenia adresów wirtualnych na rzeczywiste **adresy fizyczne**.
+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)

-#### Poziomy tablic stron w iOS
+### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>

-Tablice stron są zorganizowane hierarchicznie w trzech poziomach:
+The **virtual memory address space** for user processes on iOS spans from **0x0 to 0x8000000000**. However, these addresses don’t directly map to physical memory. Instead, the **kernel** uses **page tables** to translate virtual addresses into actual **physical addresses**.

-1. **L1 Tablica stron (Poziom 1)**:
-* Każdy wpis tutaj reprezentuje dużą przestrzeń pamięci wirtualnej.
-* Pokrywa **0x1000000000 bajtów** (czyli **256 GB**) pamięci wirtualnej.
-2. **L2 Tablica stron (Poziom 2)**:
-* Wpis tutaj reprezentuje mniejszy obszar pamięci wirtualnej, konkretnie **0x2000000 bajtów** (32 MB).
-* Wpis L1 może wskazywać na tablicę L2, jeśli nie może odwzorować całego regionu samodzielnie.
-3. **L3 Tablica stron (Poziom 3)**:
-* To najdrobniejszy poziom, gdzie każdy wpis mapuje pojedynczą stronę pamięci **4 KB**.
-* Wpis L2 może wskazywać na tablicę L3, jeśli potrzebna jest większa szczegółowość.
+#### Levels of Page Tables in iOS

-#### Mapowanie wirtualnego na fizyczne
+Page tables are organized hierarchically in three levels:

-* **Mapowanie bezpośrednie (Block Mapping)**:
-* Niektóre wpisy w tablicy stron bezpośrednio **mapują zakres adresów wirtualnych** na ciągły zakres adresów fizycznych (jak skrót).
-* **Wskaźnik do potomnej tablicy stron**:
-* Jeśli potrzebna jest większa kontrola, wpis na jednym poziomie (np. L1) może wskazywać na **potomną tablicę stron** na następnym poziomie (np. L2).
+1. **L1 Page Table (Level 1)**:
+* Each entry here represents a large range of virtual memory.
+* It covers **0x1000000000 bytes** (or **256 GB**) of virtual memory.
+2. **L2 Page Table (Level 2)**:
+* An entry here represents a smaller region of virtual memory, specifically **0x2000000 bytes** (32 MB).
+* An L1 entry may point to an L2 table if it can't map the entire region itself.
+3. **L3 Page Table (Level 3)**:
+* This is the finest level, where each entry maps a single **4 KB** memory page.
+* An L2 entry may point to an L3 table if more granular control is needed.

-#### Przykład: mapowanie adresu wirtualnego
+#### Mapping Virtual to Physical Memory

-Powiedzmy, że próbujesz uzyskać dostęp do adresu wirtualnego **0x1000000000**:
+* **Direct Mapping (Block Mapping)**:
+* Some entries in a page table directly **map a range of virtual addresses** to a contiguous range of physical addresses (like a shortcut).
+* **Pointer to Child Page Table**:
+* If finer control is needed, an entry in one level (e.g., L1) can point to a **child page table** at the next level (e.g., L2).

-1. **Tablica L1**:
-* Jądro sprawdza wpis w tablicy L1 odpowiadający temu adresowi wirtualnemu. Jeśli ma on **wskaźnik do tablicy L2**, przechodzi do tej tablicy L2.
-2. **Tablica L2**:
-* Jądro sprawdza tablicę L2 w poszukiwaniu bardziej szczegółowego mapowania. Jeśli ten wpis wskazuje na **tablicę L3**, przechodzi tam.
-3. **Tablica L3**:
-* Jądro odczytuje końcowy wpis L3, który wskazuje na **adres fizyczny** właściwej strony pamięci.
+#### Example: Mapping a Virtual Address

-#### Przykład mapowania adresów
+Let’s say you try to access the virtual address **0x1000000000**:

-Jeśli wpiszesz adres fizyczny **0x800004000** do pierwszego indeksu tablicy L2, to:
+1. **L1 Table**:
+* The kernel checks the L1 page table entry corresponding to this virtual address. If it has a **pointer to an L2 page table**, it goes to that L2 table.
+2. **L2 Table**:
+* The kernel checks the L2 page table for a more detailed mapping. If this entry points to an **L3 page table**, it proceeds there.
+3. **L3 Table**:
+* The kernel looks up the final L3 entry, which points to the **physical address** of the actual memory page.

-* Adresy wirtualne od **0x1000000000** do **0x1002000000** będą mapowane na adresy fizyczne od **0x800004000** do **0x802004000**.
-* To jest **mapowanie blokowe** na poziomie L2.
+#### Example of Address Mapping

-Alternatywnie, jeśli wpis L2 wskazuje na tablicę L3:
+If you write the physical address **0x800004000** into the first index of the L2 table, then:

-* Każda strona 4 KB w zakresie wirtualnym **0x1000000000 -> 0x1002000000** byłaby mapowana przez indywidualne wpisy w tablicy L3.
+* Virtual addresses from **0x1000000000** to **0x1002000000** map to physical addresses from **0x800004000** to **0x802004000**.
+* This is a **block mapping** at the L2 level.

-### Fizyczny use-after-free
+Alternatively, if the L2 entry points to an L3 table:

-Fizyczny use-after-free (UAF) występuje, gdy:
+* Each 4 KB page in the virtual address range **0x1000000000 -> 0x1002000000** would be mapped by individual entries in the L3 table.

-1. Proces **alokuje** pewną pamięć jako **do odczytu i zapisu**.
-2. **Tablice stron** zostają zaktualizowane, aby zmapować tę pamięć na konkretny adres fizyczny, do którego proces ma dostęp.
-3. Proces **dealokuje** (zwalnia) pamięć.
-4. Jednak z powodu **błędu** jądro **zapomina usunąć mapowanie** z tablic stron, chociaż oznacza odpowiadającą pamięć fizyczną jako wolną.
-5. Jądro może wtedy **ponownie przydzielić tę „zwolnioną” pamięć fizyczną** do innych celów, np. danych jądra.
-6. Ponieważ mapowanie nie zostało usunięte, proces wciąż może **odczytywać i zapisywać** tę pamięć fizyczną.
+### Physical use-after-free

-To oznacza, że proces może uzyskać dostęp do **stron pamięci jądra**, które mogą zawierać wrażliwe dane lub struktury, co potencjalnie pozwala atakującemu **manipulować pamięcią jądra**.
+A **physical use-after-free** (UAF) occurs when:
+
+1. A process **allocates** some memory as **readable and writable**.
+2. The **page tables** are updated to map this memory to a specific physical address that the process can access.
+3. The process **deallocates** (frees) the memory.
+4. However, due to a **bug**, the kernel **forgets to remove the mapping** from the page tables, even though it marks the corresponding physical memory as free.
+5. The kernel can then **reallocate this "freed" physical memory** for other purposes, like **kernel data**.
+6. Since the mapping wasn’t removed, the process can still **read and write** to this physical memory.
+
+This means the process can access **pages of kernel memory**, which could contain sensitive data or structures, potentially allowing an attacker to **manipulate kernel memory**.

 ### IOSurface Heap Spray

-Ponieważ atakujący nie może kontrolować, które konkretne strony jądra zostaną przydzielone do zwolnionej pamięci, używają techniki zwanej **heap spray**:
+Since the attacker can’t control which specific kernel pages will be allocated to freed memory, they use a technique called **heap spray**:

-1. Atakujący **tworzy dużą liczbę obiektów IOSurface** w pamięci jądra.
-2. Każdy obiekt IOSurface zawiera **magic value** w jednym ze swoich pól, co ułatwia identyfikację.
-3. Skanują one **zwolnione strony**, aby sprawdzić, czy któryś z tych obiektów IOSurface trafił na zwolnioną stronę.
-4. Gdy znajdą obiekt IOSurface na zwolnionej stronie, mogą go użyć do **odczytu i zapisu pamięci jądra**.
+1. The attacker **creates a large number of IOSurface objects** in kernel memory.
+2. Each IOSurface object contains a **magic value** in one of its fields, making it easy to identify.
+3. They **scan the freed pages** to see if any of these IOSurface objects landed on a freed page.
+4. When they find an IOSurface object on a freed page, they can use it to **read and write kernel memory**.

-Więcej informacji na ten temat w [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
+More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)

 > [!TIP]
-> Należy mieć świadomość, że urządzenia iOS 16+ (A12+) wprowadzają sprzętowe mechanizmy utrudniające (takie jak PPL czy SPTM), które znacząco ograniczają skuteczność technik fizycznego UAF.
-> PPL wymusza ścisłe ochrony MMU na stronach związanych z podpisywaniem kodu, uprawnieniami i wrażliwymi danymi jądra, więc nawet jeśli strona zostanie ponownie użyta, zapisy z userlandu lub skompromitowanego kodu jądra do stron chronionych przez PPL są blokowane.
-> Secure Page Table Monitor (SPTM) rozszerza PPL, wzmacniając same aktualizacje tablic stron. Zapewnia, że nawet uprzywilejowany kod jądra nie może cicho remapować zwolnionych stron ani manipulować mapowaniami bez przejścia przez bezpieczne sprawdzenia.
-> KTRR (Kernel Text Read-Only Region) blokuje sekcję kodu jądra jako tylko do odczytu po uruchomieniu. To uniemożliwia runtime’owe modyfikacje kodu jądra, zamykając istotny wektor ataku, na którym opierają się często fizyczne UAF.
-> Ponadto alokacje `IOSurface` są mniej przewidywalne i trudniejsze do zmapowania do regionów dostępnych dla użytkownika, co sprawia, że trik ze skanowaniem „magic value” jest znacznie mniej niezawodny. `IOSurface` jest teraz również chronione uprawnieniami i ograniczeniami sandboxu.
+> Be aware that iOS 16+ (A12+) devices bring hardware mitigations (like PPL or SPTM) that make physical UAF techniques far less viable.
+> PPL enforces strict MMU protections on pages related to code signing, entitlements, and sensitive kernel data, so, even if a page gets reused, writes from userland or compromised kernel code to PPL-protected pages are blocked.
+> Secure Page Table Monitor (SPTM) extends PPL by hardening page table updates themselves. It ensures that even privileged kernel code cannot silently remap freed pages or tamper with mappings without going through secure checks.
+> KTRR (Kernel Text Read-Only Region), which locks down the kernel’s code section as read-only after boot. This prevents any runtime modifications to kernel code, closing off a major attack vector that physical UAF exploits often rely on.
+> Moreover, `IOSurface` allocations are less predictable and harder to map into user-accessible regions, which makes the “magic value scanning” trick much less reliable. And `IOSurface` is now guarded by entitlements and sandbox restrictions.

-### Krok po kroku procesu Heap Spray
+### Step-by-Step Heap Spray Process

-1. **Spray obiektów IOSurface**: Atakujący tworzy wiele obiektów IOSurface ze specjalnym identyfikatorem (wartością "magic").
-2. **Skanowanie zwolnionych stron**: Sprawdzają, czy któryś z obiektów został przydzielony na zwolnionej stronie.
-3. **Odczyt/Zapis pamięci jądra**: Poprzez manipulację polami obiektu IOSurface uzyskują możliwość wykonania **dowolnych odczytów i zapisów** w pamięci jądra. Pozwala to:
-* Użyć jednego pola do **odczytu dowolnej 32-bitowej wartości** w pamięci jądra.
-* Użyć innego pola do **zapisania 64-bitowych wartości**, osiągając stabilny **prymityw odczytu/zapisu jądra**.
+1. **Spray IOSurface Objects**: The attacker creates many IOSurface objects with a special identifier ("magic value").
+2. **Scan Freed Pages**: They check if any of the objects have been allocated on a freed page.
+3. **Read/Write Kernel Memory**: By manipulating fields in the IOSurface object, they gain the ability to perform **arbitrary reads and writes** in kernel memory. This lets them:
+* Use one field to **read any 32-bit value** in kernel memory.
+* Use another field to **write 64-bit values**, achieving a stable **kernel read/write primitive**.

-Generuj obiekty IOSurface z magiczną wartością IOSURFACE\_MAGIC, aby później je wyszukać:
+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 +161,25 @@ free(surfaceIDs);
 return 0;
 }
 ```
-### Osiągnięcie odczytu/zapisu jądra przy użyciu IOSurface
+### Uzyskanie odczytu/zapisu jądra za pomocą IOSurface

 Po uzyskaniu kontroli nad obiektem IOSurface w pamięci jądra (zmapowanym do zwolnionej strony fizycznej dostępnej z userspace), możemy go użyć do **dowolnych operacji odczytu i zapisu w jądrze**.

-**Key Fields in IOSurface**
+**Kluczowe pola w IOSurface**

-The IOSurface object has two crucial fields:
+Obiekt IOSurface ma dwa kluczowe pola:

-1. **Use Count Pointer**: Pozwala na **32-bitowy odczyt**.
-2. **Indexed Timestamp Pointer**: Pozwala na **64-bitowy zapis**.
+1. **Use Count Pointer**: Pozwala na **32-bit read**.
+2. **Indexed Timestamp Pointer**: Pozwala na **64-bit write**.

-Nadpisując te wskaźniki, przekierowujemy je do dowolnych adresów w pamięci jądra, umożliwiając operacje odczytu/zapisu.
+Przez nadpisanie tych wskaźników przekierowujemy je na dowolne adresy w pamięci jądra, umożliwiając operacje odczytu/zapisu.

 #### 32-Bit Kernel Read

 Aby wykonać odczyt:

-1. Nadpisz **Use Count Pointer**, aby wskazywał na docelowy adres pomniejszony o offset 0x14 bajtów.
-2. Użyj metody `get_use_count`, aby odczytać wartość pod tym adresem.
+1. Nadpisz **use count pointer**, aby wskazywał na docelowy adres minus offset 0x14 bajtów.
+2. Użyj metody `get_use_count`, aby odczytać wartość spod tego adresu.
 ```c
 uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
 uint64_t args[1] = {surfaceID};
@ -184,12 +197,12 @@ iosurface_set_use_count_pointer(info.object, orig);
 return value;
 }
 ```
-#### 64-Bit Kernel Write
+#### 64-bitowy zapis w jądrze

 Aby wykonać zapis:

 1. Nadpisz **indexed timestamp pointer**, ustawiając go na docelowy adres.
-2. Użyj metody `set_indexed_timestamp`, aby zapisać 64-bitową wartość.
+2. Użyj metody `set_indexed_timestamp`, aby zapisać wartość 64-bitową.
 ```c
 void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
 uint64_t args[3] = {surfaceID, 0, value};
@ -205,11 +218,11 @@ iosurface_set_indexed_timestamp_pointer(info.object, orig);
 ```
 #### Podsumowanie przebiegu exploita

-1. **Trigger Physical Use-After-Free**: Wolne strony są dostępne do ponownego użycia.
-2. **Spray IOSurface Objects**: Alokuj wiele obiektów IOSurface z unikalną "magic value" w pamięci jądra.
-3. **Identify Accessible IOSurface**: Zlokalizuj IOSurface na zwolnionej stronie, którą kontrolujesz.
-4. **Abuse Use-After-Free**: Zmodyfikuj wskaźniki w obiekcie IOSurface, aby umożliwić dowolne **kernel read/write** za pomocą metod IOSurface.
+1. **Wywołaj Physical Use-After-Free**: Zwolnione strony są dostępne do ponownego użycia.
+2. **Spray IOSurface Objects**: Alokuj wiele obiektów IOSurface z unikalną "magic value" w kernel memory.
+3. **Identify Accessible IOSurface**: Znajdź IOSurface na zwolnionej stronie, którą kontrolujesz.
+4. **Abuse Use-After-Free**: Zmodyfikuj wskaźniki w obiekcie IOSurface, aby umożliwić arbitralne **kernel read/write** za pomocą metod IOSurface.

-Dzięki tym prymitywom exploit zapewnia kontrolowane **32-bit reads** i **64-bit writes** w pamięci jądra. Kolejne kroki jailbreak mogą obejmować bardziej stabilne prymitywy read/write, które mogą wymagać obejścia dodatkowych zabezpieczeń (np. PPL na nowszych urządzeniach arm64e).
+Dzięki tym prymitywom exploit zapewnia kontrolowane **32-bit reads** i **64-bit writes** do kernel memory. Dalsze kroki jailbreak mogą wymagać bardziej stabilnych read/write primitives, które mogą wymagać obejścia dodatkowych zabezpieczeń (np. PPL na nowszych urządzeniach arm64e).

 {{#include ../../banners/hacktricks-training.md}}
--- a/src/generic-methodologies-and-resources/phishing-methodology/detecting-phising.md
+++ b/src/generic-methodologies-and-resources/phishing-methodology/detecting-phising.md
@ -1,69 +1,147 @@
-# Wykrywanie Phishingu
+# Detecting Phishing

 {{#include ../../banners/hacktricks-training.md}}

 ## Wprowadzenie

-Aby wykryć próbę phishingu, ważne jest, aby **zrozumieć techniki phishingowe, które są obecnie stosowane**. Na stronie głównej tego wpisu można znaleźć te informacje, więc jeśli nie jesteś świadomy, które techniki są obecnie używane, zalecam przejście do strony głównej i przeczytanie przynajmniej tej sekcji.
+Aby wykryć próbę phishingu ważne jest, aby **zrozumieć techniki phishingu stosowane obecnie**. Na stronie nadrzędnej tego wpisu znajdziesz te informacje, więc jeśli nie wiesz, jakie techniki są dziś używane, polecam przejść na stronę nadrzędną i przeczytać przynajmniej tę sekcję.

-Ten wpis opiera się na pomyśle, że **napastnicy będą próbowali w jakiś sposób naśladować lub używać nazwy domeny ofiary**. Jeśli Twoja domena nazywa się `example.com`, a Ty jesteś ofiarą phishingu przy użyciu zupełnie innej nazwy domeny, na przykład `youwonthelottery.com`, te techniki nie ujawnią tego.
+Ten wpis opiera się na założeniu, że **atakujący spróbują w jakiś sposób naśladować lub użyć nazwy domeny ofiary**. Jeśli Twoja domena nazywa się `example.com` i padniesz ofiarą phishingu używając całkowicie innej nazwy domeny, takiej jak `youwonthelottery.com`, te techniki tego nie wykryją.

 ## Wariacje nazw domen

-Jest to dość **łatwe** do **ujawnienia** tych **prób phishingowych**, które będą używać **podobnej nazwy domeny** w e-mailu.\
-Wystarczy **wygenerować listę najbardziej prawdopodobnych nazw phishingowych**, które może użyć napastnik, i **sprawdzić**, czy są **zarejestrowane**, lub po prostu sprawdzić, czy jest jakiś **adres IP** używający tej nazwy.
+Dość łatwo jest **wykryć** te próby **phishingu**, które użyją **podobnej nazwy domeny** w wiadomości e-mail.\
+Wystarczy **wygenerować listę najbardziej prawdopodobnych nazw phishingowych**, których może użyć atakujący i **sprawdzić**, czy są **zarejestrowane** lub czy mają przypisane jakieś **IP**.

-### Znajdowanie podejrzanych domen
+### Wyszukiwanie podejrzanych domen

-W tym celu możesz użyć dowolnego z następujących narzędzi. Zauważ, że te narzędzia automatycznie wykonają również zapytania DNS, aby sprawdzić, czy domena ma przypisany jakiś adres IP:
+Do tego celu możesz użyć dowolnego z następujących narzędzi. Zauważ, że narzędzia te automatycznie wykonują zapytania DNS, aby sprawdzić, czy domena ma przypisane jakieś IP:

 - [**dnstwist**](https://github.com/elceef/dnstwist)
 - [**urlcrazy**](https://github.com/urbanadventurer/urlcrazy)

+Wskazówka: Jeśli wygenerujesz listę kandydatów, wrzuć ją także do logów Twojego DNS resolvera, aby wykryć zapytania **NXDOMAIN** z wnętrza Twojej organizacji (użytkownicy próbujący dotrzeć do literówki zanim atakujący ją zarejestruje). Przekieruj do sinkhole lub wstępnie zablokuj te domeny, jeśli polityka na to pozwala.
+
 ### Bitflipping

-**Możesz znaleźć krótkie wyjaśnienie tej techniki na stronie głównej. Lub przeczytać oryginalne badania w** [**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/)
+**Krótki opis tej techniki znajdziesz na stronie nadrzędnej. Lub przeczytaj oryginalne badania w** [**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/)

-Na przykład, modyfikacja 1 bitu w domenie microsoft.com może przekształcić ją w _windnws.com._\
-**Napastnicy mogą rejestrować tak wiele domen związanych z bit-flipping, jak to możliwe, aby przekierować legalnych użytkowników do swojej infrastruktury**.
+Na przykład modyfikacja 1 bitu w domenie microsoft.com może przekształcić ją w _windnws.com._\
+**Atakujący mogą zarejestrować jak najwięcej domen bit-flipping powiązanych z ofiarą, by przekierowywać prawdziwych użytkowników do swojej infrastruktury**.

-**Wszystkie możliwe nazwy domen związane z bit-flipping powinny być również monitorowane.**
+**Wszystkie możliwe domeny bit-flipping powinny być również monitorowane.**

-### Podstawowe kontrole
+Jeśli musisz również wziąć pod uwagę homoglyph/IDN lookalikes (np. mieszanie znaków łacińskich i cyrylicy), sprawdź:

-Gdy masz listę potencjalnych podejrzanych nazw domen, powinieneś je **sprawdzić** (głównie porty HTTP i HTTPS), aby **zobaczyć, czy używają jakiegoś formularza logowania podobnego** do któregoś z domen ofiary.\
-Możesz również sprawdzić port 3333, aby zobaczyć, czy jest otwarty i działa instancja `gophish`.\
-Interesujące jest również wiedzieć, **jak stara jest każda odkryta podejrzana domena**, im młodsza, tym bardziej ryzykowna.\
-Możesz również uzyskać **zrzuty ekranu** podejrzanej strony HTTP i/lub HTTPS, aby zobaczyć, czy jest podejrzana, a w takim przypadku **uzyskać dostęp, aby przyjrzeć się bliżej**.
+{{#ref}}
+homograph-attacks.md
+{{#endref}}

-### Zaawansowane kontrole
+### Podstawowe sprawdzenia

-Jeśli chcesz pójść o krok dalej, zalecałbym **monitorowanie tych podejrzanych domen i co jakiś czas szukać więcej** (codziennie? to zajmuje tylko kilka sekund/minut). Powinieneś również **sprawdzić** otwarte **porty** powiązanych adresów IP i **szukać instancji `gophish` lub podobnych narzędzi** (tak, napastnicy również popełniają błędy) oraz **monitorować strony HTTP i HTTPS podejrzanych domen i subdomen**, aby zobaczyć, czy skopiowały jakikolwiek formularz logowania z stron ofiary.\
-Aby **zautomatyzować to**, zalecałbym posiadanie listy formularzy logowania domen ofiary, przeszukiwanie podejrzanych stron internetowych i porównywanie każdego formularza logowania znalezionego w podejrzanych domenach z każdym formularzem logowania domeny ofiary przy użyciu czegoś takiego jak `ssdeep`.\
-Jeśli zlokalizowałeś formularze logowania podejrzanych domen, możesz spróbować **wysłać fałszywe dane logowania** i **sprawdzić, czy przekierowuje Cię do domeny ofiary**.
+Gdy masz listę potencjalnych podejrzanych domen, powinieneś je **sprawdzić** (głównie porty HTTP i HTTPS), aby **zobaczyć, czy używają jakiegoś formularza logowania podobnego** do tego z domeny ofiary.\
+Możesz też sprawdzić port 3333, czy jest otwarty i uruchomiony jest na nim `gophish`.\
+Warto także znać **jak stara jest każda wykryta podejrzana domena** — im młodsza, tym większe ryzyko.\
+Możesz również uzyskać **zrzuty ekranu** podejrzanej strony HTTP i/lub HTTPS, żeby zobaczyć, czy wygląda podejrzanie i w takim wypadku **wejść na nią, by przyjrzeć się dokładniej**.

-## Nazwy domen używające słów kluczowych
+### Zaawansowane sprawdzenia

-Strona główna wspomina również o technice wariacji nazw domen, która polega na umieszczaniu **nazwy domeny ofiary w większej domenie** (np. paypal-financial.com dla paypal.com).
+Jeśli chcesz pójść o krok dalej, polecam **monitorować te podejrzane domeny i od czasu do czasu wyszukiwać kolejne** (codziennie? to zajmuje tylko kilka sekund/minut). Powinieneś też **sprawdzić** otwarte **porty** powiązanych IP i **wyszukać instancje `gophish` lub podobnych narzędzi** (tak, atakujący też popełniają błędy) oraz **monitorować strony HTTP i HTTPS podejrzanych domen i subdomen**, aby sprawdzić, czy skopiowały jakieś formularze logowania z serwisów ofiary.\
+Aby to **zautomatyzować**, polecam mieć listę formularzy logowania domen ofiary, spiderować podejrzane strony i porównywać każdy znaleziony formularz logowania z formularzami domeny ofiary przy użyciu czegoś w rodzaju `ssdeep`.\
+Jeśli zlokalizujesz formularze logowania na podejrzanych domenach, możesz spróbować **wysłać fałszywe poświadczenia** i **sprawdzić, czy następuje przekierowanie do domeny ofiary**.

-### Przejrzystość certyfikatów
+---

-Nie jest możliwe zastosowanie wcześniejszego podejścia "Brute-Force", ale w rzeczywistości **możliwe jest ujawnienie takich prób phishingowych** również dzięki przejrzystości certyfikatów. Za każdym razem, gdy certyfikat jest wydawany przez CA, szczegóły są publikowane. Oznacza to, że czytając przejrzystość certyfikatów lub nawet ją monitorując, **możliwe jest znalezienie domen, które używają słowa kluczowego w swojej nazwie**. Na przykład, jeśli napastnik generuje certyfikat dla [https://paypal-financial.com](https://paypal-financial.com), przeglądając certyfikat, można znaleźć słowo kluczowe "paypal" i wiedzieć, że podejrzany e-mail jest używany.
+### Polowanie po favicon i web fingerprints (Shodan/ZoomEye/Censys)

-Wpis [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) sugeruje, że możesz użyć Censys do wyszukiwania certyfikatów dotyczących konkretnego słowa kluczowego i filtrować według daty (tylko "nowe" certyfikaty) oraz według wydawcy CA "Let's Encrypt":
+Wiele kitów phishingowych ponownie używa favicon marki, którą podszywają. Skanery ogólnokrajowe obliczają MurmurHash3 z base64-encoded faviconu. Możesz wygenerować hash i pivotować na niego:
+
+Python example (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
+```
+- Zapytanie do Shodan: `http.favicon.hash:309020573`
+- Z narzędziami: sprawdź narzędzia społecznościowe takie jak favfreak, aby generować hashes i dorks dla Shodan/ZoomEye/Censys.
+
+Uwagi
+- Favicons są ponownie używane; traktuj dopasowania jako leads i zweryfikuj zawartość i certs przed podjęciem działań.
+- Łącz z domain-age i heurystykami opartymi na słowach kluczowych, aby uzyskać lepszą precyzję.
+
+### Przeszukiwanie telemetrii URL (urlscan.io)
+
+`urlscan.io` przechowuje historyczne zrzuty ekranu, DOM, requests i metadane TLS przesłanych URL-i. Możesz wyszukiwać nadużycia marki i klony:
+
+Przykładowe zapytania (UI lub API):
+- Find lookalikes excluding your legit domains: `page.domain:(/.*yourbrand.*/ AND NOT yourbrand.com AND NOT www.yourbrand.com)`
+- Find sites hotlinking your assets: `domain:yourbrand.com AND NOT page.domain:yourbrand.com`
+- Ogranicz do niedawnych wyników: dołącz `AND date:>now-7d`
+
+Przykład API:
+```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'
+```
+Z JSON-a skup się na:
+- `page.tlsIssuer`, `page.tlsValidFrom`, `page.tlsAgeDays` — aby wykryć bardzo nowe certyfikaty używane do lookalikes
+- `task.source` values like `certstream-suspicious` — aby powiązać znaleziska z monitoringiem CT
+
+### Wiek domeny przez RDAP (skryptowalne)
+
+RDAP zwraca zdarzenia utworzenia w formacie czytelnym dla maszyn. Przydatne do oznaczania **nowo zarejestrowanych domen (NRDs)**.
+```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
+```
+Wzbogacaj swój pipeline, tagując domeny według przedziałów wieku rejestracji (np. <7 days, <30 days) i priorytetyzuj triage odpowiednio.
+
+### TLS/JAx fingerprints do wykrywania infrastruktury AiTM
+
+Nowoczesny credential-phishing coraz częściej wykorzystuje **Adversary-in-the-Middle (AiTM)** reverse proxies (np. Evilginx) do kradzieży session tokens. Możesz dodać detekcje po stronie sieci:
+
+- Loguj TLS/HTTP fingerprints (JA3/JA4/JA4S/JA4H) na egress. W niektórych buildach Evilginx zaobserwowano stabilne wartości JA4 client/server. Generuj alerty tylko na znane-bad fingerprints jako słaby sygnał i zawsze potwierdzaj treścią oraz intel domeny.
+- Proaktywnie rejestruj metadata certyfikatów TLS (issuer, SAN count, użycie wildcard, validity) dla lookalike hosts odkrytych przez CT lub urlscan i koreluj z wiekiem DNS i geolokalizacją.
+
+> Uwaga: Traktuj fingerprints jako wzbogacenie, nie jako jedyne blokady; frameworki ewoluują i mogą randomizować lub zacierać sygnatury.
+
+### Nazwy domen zawierające słowa kluczowe
+
+Strona nadrzędna wspomina też technikę wariacji nazwy domeny polegającą na umieszczeniu **domeny ofiary wewnątrz większej domeny** (np. paypal-financial.com dla paypal.com).
+
+#### Certificate Transparency
+
+Nie da się zastosować poprzedniego podejścia „Brute-Force”, ale faktycznie **można wykryć takie phishingowe próby** dzięki Certificate Transparency. Za każdym razem gdy CA wydaje certyfikat, szczegóły stają się publiczne. Oznacza to, że przeglądając lub monitorując Certificate Transparency (CT) można **odkryć domeny zawierające słowo kluczowe w swojej nazwie**. Na przykład, jeśli atakujący wygeneruje certyfikat dla [https://paypal-financial.com](https://paypal-financial.com), widząc ten certyfikat można znaleźć słowo kluczowe "paypal" i podejrzewać użycie domeny w kampanii phishingowej.
+
+Post [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) sugeruje, że możesz użyć Censys do wyszukiwania certyfikatów zawierających konkretne słowo kluczowe i filtrować po dacie (tylko „nowe” certyfikaty) oraz po issuerze CA "Let's Encrypt":

 ![https://0xpatrik.com/content/images/2018/07/cert_listing.png](<../../images/image (1115).png>)

-Jednak możesz zrobić "to samo" używając darmowej strony [**crt.sh**](https://crt.sh). Możesz **wyszukiwać słowo kluczowe** i **filtrować** wyniki **według daty i CA**, jeśli chcesz.
+Możesz jednak zrobić „to samo” używając darmowego serwisu [**crt.sh**](https://crt.sh). Możesz **wyszukać słowo kluczowe** i opcjonalnie **filtrować** wyniki **po dacie i CA**.

 ![](<../../images/image (519).png>)

-Korzystając z tej ostatniej opcji, możesz nawet użyć pola Matching Identities, aby sprawdzić, czy jakakolwiek tożsamość z prawdziwej domeny pasuje do którejkolwiek z podejrzanych domen (zauważ, że podejrzana domena może być fałszywym pozytywem).
+Korzystając z tej ostatniej opcji możesz też użyć pola Matching Identities, aby sprawdzić, czy któraś tożsamość z prawdziwej domeny pasuje do którejkolwiek ze podejrzanych domen (uwaga: domena podejrzana może być false positive).

-**Inną alternatywą** jest fantastyczny projekt o nazwie [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream zapewnia strumień na żywo nowo wygenerowanych certyfikatów, który możesz wykorzystać do wykrywania określonych słów kluczowych w (prawie) czasie rzeczywistym. W rzeczywistości istnieje projekt o nazwie [**phishing_catcher**](https://github.com/x0rz/phishing_catcher), który robi dokładnie to.
+**Inna alternatywa** to świetny projekt [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream dostarcza strumień w czasie rzeczywistym nowo wygenerowanych certyfikatów, który możesz wykorzystać do wykrywania określonych słów kluczowych (prawie) w czasie rzeczywistym. Istnieje też projekt [**phishing_catcher**](https://github.com/x0rz/phishing_catcher), który robi dokładnie to.

-### **Nowe domeny**
+Praktyczna wskazówka: przy triage trafień z CT priorytetyzuj NRDs, untrusted/unknown registrars, privacy-proxy WHOIS oraz certy z bardzo świeżymi czasami `NotBefore`. Utrzymuj allowlistę posiadanych domen/brandów, aby zmniejszyć szum.

-**Ostatnią alternatywą** jest zebranie listy **nowo zarejestrowanych domen** dla niektórych TLD ([Whoxy](https://www.whoxy.com/newly-registered-domains/) oferuje taką usługę) i **sprawdzenie słów kluczowych w tych domenach**. Jednak długie domeny zazwyczaj używają jednej lub więcej subdomen, dlatego słowo kluczowe nie pojawi się w FLD i nie będziesz w stanie znaleźć subdomeny phishingowej.
+#### **Nowe domeny**
+
+**Jeszcze jedna alternatywa** to zebranie listy **nowo zarejestrowanych domen** dla niektórych TLDs ([Whoxy](https://www.whoxy.com/newly-registered-domains/) oferuje taką usługę) i **sprawdzenie słów kluczowych w tych domenach**. Jednak długie domeny zwykle używają jednego lub więcej subdomen, więc słowo kluczowe nie pojawi się w FLD i nie będziesz w stanie znaleźć phishingowej subdomeny.
+
+Dodatkowy heurystyczny wskaźnik: traktuj niektóre file-extension TLDs (np. `.zip`, `.mov`) z dodatkową podejrzliwością przy generowaniu alertów. Często są mylone z nazwami plików w lure'ach; łącz sygnał z TLD z brand keywords i wiekiem NRD dla lepszej precyzji.
+
+## Referencje
+
+- 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}}
--- a/theme/ht_searcher.js
+++ b/theme/ht_searcher.js
@ -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; }