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

.gitignore

@@ -11,3 +11,4 @@ book
 book/*
 hacktricks-preprocessor.log
 hacktricks-preprocessor-error.log
+searchindex.js

src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md

@@ -3,97 +3,111 @@
 {{#include ../../banners/hacktricks-training.md}}
 
 
+## Mitigazioni degli exploit iOS
+
+- **Code Signing** in iOS funziona richiedendo che ogni porzione di codice eseguibile (app, librerie, estensioni, ecc.) sia firmata crittograficamente con un certificato rilasciato da Apple. Quando il codice viene caricato, iOS verifica la firma digitale rispetto alla root di fiducia di Apple. Se la firma è invalida, assente o modificata, il sistema operativo rifiuta l'esecuzione. Questo impedisce agli attaccanti di iniettare codice malevolo in app legittime o di eseguire binari non firmati, bloccando efficacemente molte catene di exploit che si basano sull'esecuzione di codice arbitrario o manomesso.
+- **CoreTrust** è il sottosistema iOS responsabile dell'applicazione della code signing a runtime. Verifica direttamente le firme usando il certificato root di Apple senza fare affidamento su store di fiducia memorizzati, il che significa che solo i binari firmati da Apple (o con entitlement validi) possono essere eseguiti. CoreTrust garantisce che anche se un attaccante manomette un'app dopo l'installazione, modifica librerie di sistema o tenta di caricare codice non firmato, il sistema bloccherà l'esecuzione a meno che il codice non sia ancora correttamente firmato. Questa applicazione rigorosa chiude molti vettori di post-exploitation che versioni più vecchie di iOS permettevano tramite controlli di firma più deboli o aggirabili.
+- **Data Execution Prevention (DEP)** marca le regioni di memoria come non eseguibili a meno che non contengano esplicitamente codice. Questo impedisce agli attaccanti di iniettare shellcode in regioni di dati (come lo stack o l'heap) e di eseguirlo, costringendoli a ricorrere a tecniche più complesse come ROP (Return-Oriented Programming).
+- **ASLR (Address Space Layout Randomization)** randomizza gli indirizzi di memoria di codice, librerie, stack e heap ad ogni esecuzione del sistema. Questo rende molto più difficile per gli attaccanti prevedere dove si trovino istruzioni o gadget utili, interrompendo molte catene di exploit che dipendono da layout di memoria fissi.
+- **KASLR (Kernel ASLR)** applica lo stesso concetto di randomizzazione al kernel iOS. Mescolando l'indirizzo base del kernel ad ogni avvio, impedisce agli attaccanti di localizzare in modo affidabile funzioni o strutture del kernel, aumentando la difficoltà degli exploit a livello kernel che altrimenti otterrebbero il controllo completo del sistema.
+- **Kernel Patch Protection (KPP)**, noto anche come **AMCC (Apple Mobile File Integrity)** in iOS, monitora continuamente le pagine di codice del kernel per assicurarsi che non siano state modificate. Se viene rilevata una manomissione—ad esempio un exploit che prova a patchare funzioni del kernel o inserire codice malevolo—il dispositivo paniccherà e si riavvierà immediatamente. Questa protezione rende molto più difficili gli exploit persistenti a livello kernel, poiché gli attaccanti non possono semplicemente fare hook o patch alle istruzioni del kernel senza innescare un crash del sistema.
+- **Kernel Text Readonly Region (KTRR)** è una funzionalità hardware-based introdotta sui dispositivi iOS. Utilizza il memory controller della CPU per marcare la sezione di codice (text) del kernel come permanentemente read-only dopo il boot. Una volta bloccata, nemmeno il kernel stesso può modificare questa regione di memoria. Questo impedisce agli attaccanti—e persino al codice privilegiato—from di patchare le istruzioni del kernel a runtime, chiudendo una classe importante di exploit che si basavano sulla modifica diretta del codice kernel.
+- **Pointer Authentication Codes (PAC)** usano firme crittografiche incorporate nei bit inutilizzati dei puntatori per verificarne l'integrità prima dell'uso. Quando un puntatore (ad esempio un return address o un function pointer) viene creato, la CPU lo firma con una chiave segreta; prima della dereferenziazione, la CPU controlla la firma. Se il puntatore è stato manomesso, il controllo fallisce e l'esecuzione si interrompe. Questo impedisce agli attaccanti di forgiare o riutilizzare puntatori corrotti in exploit di corruzione della memoria, rendendo tecniche come ROP o JOP molto più difficili da effettuare in modo affidabile.
+- **Privilege Access never (PAN)** è una funzionalità hardware che impedisce al kernel (modalità privilegiata) di accedere direttamente alla memoria user-space a meno che non abiliti esplicitamente l'accesso. Questo blocca gli attaccanti che hanno ottenuto code execution nel kernel dal leggere o scrivere facilmente la memoria utente per scalare exploit o rubare dati sensibili. Facendo rispettare una separazione rigorosa, PAN riduce l'impatto degli exploit kernel e blocca molte tecniche comuni di escalation di privilegi.
+- **Page Protection Layer (PPL)** è un meccanismo di sicurezza di iOS che protegge regioni critiche di memoria gestite dal kernel, specialmente quelle legate a code signing ed entitlements. Applica protezioni di scrittura rigorose usando la MMU (Memory Management Unit) e controlli aggiuntivi, assicurando che anche codice kernel privilegiato non possa modificare arbitrariamente pagine sensibili. Questo impedisce agli attaccanti che ottengono esecuzione a livello kernel di manomettere strutture critiche per la sicurezza, rendendo significativamente più difficili persistenza e bypass della code signing.
+
+
 ## Physical use-after-free
 
-Questo è un riassunto del post [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html); inoltre ulteriori informazioni su exploit che usano questa tecnica si trovano in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
+Questa è una sintesi del post su [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html); ulteriori informazioni sull'exploit che usa questa tecnica si trovano anche in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
 
-### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
+### Gestione della memoria in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
 
-Lo spazio di indirizzamento della virtual memory per i processi utente su iOS va da **0x0 a 0x8000000000**. Tuttavia, questi indirizzi non mappano direttamente sulla memoria fisica. Invece, il kernel usa i page tables per tradurre gli virtual addresses in effettivi physical addresses.
+Lo spazio di indirizzi della **virtual memory address space** per i processi utente su iOS va da **0x0 a 0x8000000000**. Tuttavia, questi indirizzi non mappano direttamente alla memoria fisica. Invece, il **kernel** usa **page tables** per tradurre indirizzi virtuali in effettivi **physical addresses**.
 
-#### Levels of Page Tables in iOS
+#### Livelli delle Page Tables in iOS
 
-I page tables sono organizzati gerarchicamente in tre livelli:
+Le page tables sono organizzate gerarchicamente in tre livelli:
 
 1. **L1 Page Table (Level 1)**:
 * Ogni entry qui rappresenta un ampio intervallo di virtual memory.
 * Copre **0x1000000000 bytes** (o **256 GB**) di virtual memory.
 2. **L2 Page Table (Level 2)**:
-* Un’entry qui rappresenta una regione più piccola di virtual memory, specificamente **0x2000000 bytes** (32 MB).
-* Un entry L1 può puntare a una tabella L2 se non può mappare l’intera regione da sola.
+* Un'entry qui rappresenta una regione più piccola di virtual memory, specificamente **0x2000000 bytes** (32 MB).
+* Un'entry L1 può puntare a una L2 table se non riesce a mappare l'intera regione da sola.
 3. **L3 Page Table (Level 3)**:
-* Questo è il livello più fine, dove ogni entry mappa una singola pagina di memoria da **4 KB**.
-* Un entry L2 può puntare a una tabella L3 se è necessario un controllo più granulare.
+* Questo è il livello più fine, dove ogni entry mappa una singola pagina di **4 KB**.
+* Un'entry L2 può puntare a una L3 table se è necessario un controllo più granulare.
 
-#### Mapping Virtual to Physical Memory
+#### Mappare la Virtual alla Physical Memory
 
 * **Direct Mapping (Block Mapping)**:
-* Alcune entry in un page table mappano direttamente un intervallo di virtual addresses a un intervallo contiguo di physical addresses (come una scorciatoia).
+* Alcune entry in una page table mappano direttamente un intervallo di indirizzi virtuali a un intervallo contiguo di indirizzi fisici (come una scorciatoia).
 * **Pointer to Child Page Table**:
-* Se serve un controllo più fine, un entry in un livello (es. L1) può puntare a un child page table al livello successivo (es. L2).
+* Se è necessario un controllo più fine, un'entry in un livello (es. L1) può puntare a una **child page table** al livello successivo (es. L2).
 
-#### Example: Mapping a Virtual Address
+#### Esempio: Mappare un Virtual Address
 
-Supponiamo di accedere all’indirizzo virtuale **0x1000000000**:
+Supponiamo di provare ad accedere all'indirizzo virtuale **0x1000000000**:
 
 1. **L1 Table**:
-* Il kernel controlla l’entry della L1 page table corrispondente a questo virtual address. Se contiene un pointer a una L2 page table, passa a quella L2.
+* Il kernel controlla l'entry della L1 page table corrispondente a questo virtual address. Se ha un **pointer to an L2 page table**, passa alla L2.
 2. **L2 Table**:
-* Il kernel controlla la L2 page table per una mappatura più dettagliata. Se questa entry punta a una L3 page table, procede lì.
+* Il kernel controlla la L2 page table per una mappatura più dettagliata. Se questa entry punta a una **L3 page table**, procede lì.
 3. **L3 Table**:
-* Il kernel consulta l’entry finale L3, che punta al physical address della pagina di memoria effettiva.
+* Il kernel cerca l'entry finale L3, che punta al **physical address** della pagina di memoria reale.
 
-#### Example of Address Mapping
+#### Esempio di mappatura di indirizzi
 
 Se scrivi il physical address **0x800004000** nel primo indice della L2 table, allora:
 
-* Gli virtual addresses da **0x1000000000** a **0x1002000000** sono mappati ai physical addresses da **0x800004000** a **0x802004000**.
-* Questa è una block mapping al livello L2.
+* Gli indirizzi virtuali da **0x1000000000** a **0x1002000000** mappano agli indirizzi fisici da **0x800004000** a **0x802004000**.
+* Questa è una **block mapping** a livello L2.
 
-In alternativa, se l’entry L2 punta a una L3 table:
+In alternativa, se l'entry L2 punta a una L3 table:
 
-* Ogni pagina da 4 KB nell’intervallo virtuale **0x1000000000 -> 0x1002000000** sarebbe mappata da entry individuali nella L3 table.
+* Ogni pagina da 4 KB nell'intervallo virtuale **0x1000000000 -> 0x1002000000** sarebbe mappata da entry individuali nella L3 table.
 
 ### Physical use-after-free
 
-Un **physical use-after-free** (UAF) avviene quando:
+Un **physical use-after-free** (UAF) si verifica quando:
 
 1. Un processo **alloca** della memoria come **readable e writable**.
-2. I page tables vengono aggiornati per mappare questa memoria a un specifico physical address che il processo può accedere.
+2. Le **page tables** vengono aggiornate per mappare questa memoria a un specifico physical address che il processo può accedere.
 3. Il processo **dealloca** (free) la memoria.
-4. Tuttavia, a causa di un **bug**, il kernel **dimentica di rimuovere la mapping** dai page tables, anche se marca la corrispondente memoria fisica come libera.
-5. Il kernel può quindi **riallocare questa memoria fisica "liberata"** per altri scopi, come dati del kernel.
+4. Tuttavia, a causa di un **bug**, il kernel **dimentica di rimuovere la mapping** dalle page tables, anche se marca la corrispondente memoria fisica come libera.
+5. Il kernel può quindi **riallocare questa memoria fisica "freed"** per altri scopi, come dati del kernel.
 6. Poiché la mapping non è stata rimossa, il processo può ancora **leggere e scrivere** su quella memoria fisica.
 
-Questo significa che il processo può accedere a **pagine di kernel memory**, che potrebbero contenere dati sensibili o strutture, permettendo potenzialmente a un attaccante di **manipolare la kernel memory**.
+Questo significa che il processo può accedere a **pagine di memoria kernel**, che potrebbero contenere dati o strutture sensibili, potenzialmente permettendo a un attaccante di **manipolare la memoria del kernel**.
 
 ### IOSurface Heap Spray
 
-Poiché l’attaccante non può controllare quali specifiche kernel pages verranno allocate sulla memoria liberata, usa una tecnica chiamata **heap spray**:
+Poiché l'attaccante non può controllare quali specifiche pagine kernel verranno allocate alla memoria liberata, usa una tecnica chiamata **heap spray**:
 
-1. L’attaccante **crea un gran numero di IOSurface objects** nella kernel memory.
-2. Ogni IOSurface object contiene un **valore magico** in uno dei suoi campi, rendendolo facile da identificare.
-3. Scansionano le pagine liberate per vedere se uno di questi IOSurface objects è stato allocato su una pagina liberata.
-4. Quando trovano un IOSurface object su una pagina liberata, possono usarlo per **leggere e scrivere kernel memory**.
+1. L'attaccante **crea un grande numero di oggetti IOSurface** nella memoria kernel.
+2. Ogni oggetto IOSurface contiene un **valore magico** in uno dei suoi campi, rendendolo facile da identificare.
+3. Scansionano le pagine liberate per vedere se uno di questi oggetti IOSurface è stato collocato su una pagina liberata.
+4. Quando trovano un oggetto IOSurface su una pagina liberata, possono usarlo per **leggere e scrivere la memoria kernel**.
 
-Ulteriori informazioni su questo in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
+Maggiori informazioni su questo si trovano in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
 
 > [!TIP]
 > Tieni presente che i dispositivi iOS 16+ (A12+) introducono mitigazioni hardware (come PPL o SPTM) che rendono le tecniche di physical UAF molto meno praticabili.
-> PPL impone protezioni MMU rigide sulle pagine relative al code signing, alle entitlements e ai dati sensibili del kernel, quindi, anche se una pagina viene riutilizzata, le scritture da userland o da codice kernel compromesso verso pagine protette da PPL vengono bloccate.
-> Secure Page Table Monitor (SPTM) estende PPL rafforzando gli aggiornamenti dei page tables stessi. Assicura che anche codice kernel privilegiato non possa rimappare silenziosamente pagine liberate o manomettere le mappings senza passare per controlli sicuri.
-> KTRR (Kernel Text Read-Only Region) blocca la sezione di codice del kernel come read-only dopo il boot. Questo impedisce qualsiasi modifica a runtime al codice del kernel, chiudendo una grande superficie d’attacco su cui gli exploit physical UAF spesso fanno affidamento.
-> Inoltre, le allocazioni IOSurface sono meno prevedibili e più difficili da mappare in regioni accessibili da userland, il che rende il trucco della scansione per il valore magico molto meno affidabile. E IOSurface ora è protetto da entitlements e restrizioni di sandbox.
+> PPL applica protezioni MMU rigorose sulle pagine relative a code signing, entitlements e dati sensibili del kernel, quindi anche se una pagina viene riutilizzata, le scritture da userland o da codice kernel compromesso verso pagine protette da PPL sono bloccate.
+> Secure Page Table Monitor (SPTM) estende PPL irrobustendo gli stessi aggiornamenti delle page table. Assicura che anche il codice kernel privilegiato non possa rimappare silenziosamente pagine liberate o manomettere le mapping senza passare per controlli sicuri.
+> KTRR (Kernel Text Read-Only Region) blocca la sezione di codice del kernel come read-only dopo il boot. Questo impedisce qualsiasi modifica a runtime al codice del kernel, chiudendo un importante vettore di attacco su cui spesso fanno affidamento gli exploit physical UAF.
+> Inoltre, le allocazioni di `IOSurface` sono meno prevedibili e più difficili da mappare in regioni accessibili dall'utente, il che rende il trucco della scansione del "valore magico" molto meno affidabile. E `IOSurface` è ora protetto da entitlements e restrizioni di sandbox.
 
-### Step-by-Step Heap Spray Process
+### Processo passo-passo di Heap Spray
 
-1. **Spray IOSurface Objects**: L’attaccante crea molti IOSurface objects con un identificatore speciale ("magic value").
-2. **Scan Freed Pages**: Controllano se uno qualsiasi degli oggetti è stato allocato su una pagina liberata.
-3. **Read/Write Kernel Memory**: Manipolando i campi dell’IOSurface object, ottengono la capacità di eseguire **arbitrary reads and writes** nella kernel memory. Questo permette di:
-* Usare un campo per **leggere qualsiasi valore a 32-bit** nella kernel memory.
-* Usare un altro campo per **scrivere valori a 64-bit**, ottenendo un stabile **kernel read/write primitive**.
+1. **Spray IOSurface Objects**: l'attaccante crea molti oggetti IOSurface con un identificatore speciale ("magic value").
+2. **Scan Freed Pages**: verifica se uno di questi oggetti è stato allocato su una pagina liberata.
+3. **Read/Write Kernel Memory**: manipolando i campi dell'oggetto IOSurface, ottiene la capacità di eseguire **letture e scritture arbitrarie** nella memoria kernel. Questo permette di:
+* Usare un campo per **leggere qualsiasi valore a 32-bit** nella memoria kernel.
+* Usare un altro campo per **scrivere valori a 64-bit**, ottenendo un primitivo stabile di **kernel read/write**.
 
-Genera oggetti IOSurface con il valore magico IOSURFACE\_MAGIC per cercarli in seguito:
+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;
 }
 ```
-### Ottenere lettura/scrittura del kernel con IOSurface
+### Ottenere lettura/scrittura nel kernel con IOSurface
 
-Dopo aver ottenuto il controllo di un oggetto IOSurface nella memoria del kernel (mappato su una pagina fisica liberata accessibile da userspace), possiamo usarlo per **operazioni arbitrarie di lettura e scrittura sul kernel**.
+Dopo aver ottenuto il controllo di un oggetto IOSurface nella memoria kernel (mappato su una pagina fisica liberata accessibile da userspace), possiamo usarlo per **operazioni arbitrarie di lettura e scrittura nel kernel**.
 
 **Key Fields in IOSurface**
 
 L'oggetto IOSurface ha due campi cruciali:
 
-1. **Use Count Pointer**: Consente una **lettura 32-bit**.
-2. **Indexed Timestamp Pointer**: Consente una **scrittura 64-bit**.
+1. **Use Count Pointer**: Permette una **lettura a 32-bit**.
+2. **Indexed Timestamp Pointer**: Permette una **scrittura a 64-bit**.
 
-Sovrascrivendo questi puntatori, li reindirizziamo verso indirizzi arbitrari nella memoria del kernel, abilitando capacità di lettura/scrittura.
+Sovrascrivendo questi puntatori, li reindirizziamo a indirizzi arbitrari nella memoria kernel, abilitando capacità di lettura/scrittura.
 
-#### Lettura 32-bit del kernel
+#### Lettura a 32-bit nel kernel
 
-Per eseguire una lettura:
+Per effettuare una lettura:
 
-1. Sovrascrivere il **use count pointer** per puntare all'indirizzo target meno un offset di 0x14 byte.
-2. Usare il metodo `get_use_count` per leggere il valore a quell'indirizzo.
+1. Sovrascrivi il **use count pointer** per puntare all'indirizzo target meno un offset di 0x14 byte.
+2. Usa il metodo `get_use_count` per leggere il valore a quell'indirizzo.
 ```c
 uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
 uint64_t args[1] = {surfaceID};
@@ -184,12 +198,12 @@ iosurface_set_use_count_pointer(info.object, orig);
 return value;
 }
 ```
-#### Scrittura del kernel a 64 bit
+#### Scrittura Kernel a 64 bit
 
-Per effettuare una scrittura:
+Per eseguire una scrittura:
 
-1. Sovrascrivere il **indexed timestamp pointer** con l'indirizzo di destinazione.
-2. Usare il metodo `set_indexed_timestamp` per scrivere un valore a 64 bit.
+1. Sovrascrivi il **indexed timestamp pointer** con l'indirizzo di destinazione.
+2. Usa il metodo `set_indexed_timestamp` per scrivere un valore a 64 bit.
 ```c
 void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
 uint64_t args[3] = {surfaceID, 0, value};
@@ -207,9 +221,9 @@ iosurface_set_indexed_timestamp_pointer(info.object, orig);
 
 1. **Trigger Physical Use-After-Free**: Le pagine liberate sono disponibili per il riutilizzo.
 2. **Spray IOSurface Objects**: Allocare molti oggetti IOSurface con un unico "magic value" nella memoria kernel.
-3. **Identify Accessible IOSurface**: Individua un IOSurface su una pagina liberata che controlli.
-4. **Abuse Use-After-Free**: Modifica i puntatori nell'oggetto IOSurface per abilitare **kernel read/write** arbitrari tramite i metodi di IOSurface.
+3. **Identify Accessible IOSurface**: Individuare un IOSurface su una pagina liberata che controlli.
+4. **Abuse Use-After-Free**: Modificare i puntatori nell'oggetto IOSurface per consentire **kernel read/write** arbitrari tramite i metodi IOSurface.
 
-Con queste primitive, l'exploit fornisce **32-bit reads** controllate e **64-bit writes** alla memoria kernel. Passi successivi del jailbreak potrebbero richiedere primitive di read/write più stabili, che potrebbero richiedere il bypass di protezioni aggiuntive (es. PPL su dispositivi arm64e più recenti).
+Con queste primitive, l'exploit fornisce **32-bit reads** controllate e **64-bit writes** alla memoria kernel. Passi successivi per il jailbreak potrebbero comportare primitive di read/write più stabili, che potrebbero richiedere il bypass di protezioni aggiuntive (es., PPL su dispositivi arm64e più recenti).
 
 {{#include ../../banners/hacktricks-training.md}}

src/generic-methodologies-and-resources/phishing-methodology/detecting-phising.md

@@ -1,69 +1,147 @@
-# Rilevamento del Phishing
+# Detecting Phishing
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Introduzione
+## Introduction
 
-Per rilevare un tentativo di phishing è importante **comprendere le tecniche di phishing che vengono utilizzate al giorno d'oggi**. Nella pagina principale di questo post, puoi trovare queste informazioni, quindi se non sei a conoscenza delle tecniche utilizzate oggi ti consiglio di andare alla pagina principale e leggere almeno quella sezione.
+To detect a phishing attempt it's important to **understand the phishing techniques that are being used nowadays**. On the parent page of this post, you can find this information, so if you aren't aware of which techniques are being used today I recommend you to go to the parent page and read at least that section.
 
-Questo post si basa sull'idea che **gli attaccanti cercheranno in qualche modo di imitare o utilizzare il nome di dominio della vittima**. Se il tuo dominio si chiama `example.com` e sei vittima di phishing utilizzando un nome di dominio completamente diverso per qualche motivo come `youwonthelottery.com`, queste tecniche non lo sveleranno.
+This post is based on the idea that the **attaccanti cercheranno in qualche modo di imitare o usare il dominio della vittima**. If your domain is called `example.com` and you are phished using a completely different domain name for some reason like `youwonthelottery.com`, these techniques aren't going to uncover it.
 
-## Variazioni del nome di dominio
+## Domain name variations
 
-È piuttosto **facile** **svelare** quei **tentativi di phishing** che utilizzeranno un **nome di dominio simile** all'interno dell'email.\
-È sufficiente **generare un elenco dei nomi di phishing più probabili** che un attaccante potrebbe utilizzare e **controllare** se è **registrato** o semplicemente controllare se c'è qualche **IP** che lo utilizza.
+È piuttosto **facile** **scoprire** quei tentativi di **phishing** che useranno un **nome di dominio simile** all'interno dell'email.\
+Basta **generare una lista dei nomi di phishing più probabili** che un attaccante potrebbe utilizzare e **controllare** se è **registrato** o semplicemente verificare se esiste qualche **IP** che lo sta usando.
 
-### Trovare domini sospetti
+### Finding suspicious domains
 
-A questo scopo, puoi utilizzare uno dei seguenti strumenti. Nota che questi strumenti eseguiranno anche richieste DNS automaticamente per controllare se il dominio ha qualche IP assegnato:
+A questo scopo puoi usare uno qualsiasi dei seguenti tool. Nota che questi strumenti effettueranno automaticamente richieste DNS per verificare se il dominio ha un IP assegnato:
 
 - [**dnstwist**](https://github.com/elceef/dnstwist)
 - [**urlcrazy**](https://github.com/urbanadventurer/urlcrazy)
 
+Suggerimento: Se generi una lista di candidati, inseriscila anche nei log del tuo resolver DNS per rilevare **NXDOMAIN lookups dall'interno della tua org** (utenti che cercano di raggiungere un typo prima che l'attaccante lo registri). Se la policy lo consente, sinkhole o pre-block questi domini.
+
 ### Bitflipping
 
-**Puoi trovare una breve spiegazione di questa tecnica nella pagina principale. Oppure leggi la ricerca originale in** [**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/)
+**You can find a short the explanation of this technique in the parent page. Or read the original research in** [**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/)
 
-Ad esempio, una modifica di 1 bit nel dominio microsoft.com può trasformarlo in _windnws.com._\
-**Gli attaccanti possono registrare quanti più domini di bit-flipping possibile relativi alla vittima per reindirizzare gli utenti legittimi alla loro infrastruttura**.
+Per esempio, una modifica di 1 bit nel dominio microsoft.com può trasformarlo in _windnws.com._\
+**Gli attaccanti possono registrare quanti più domini bit-flipping possibile correlati alla vittima per reindirizzare utenti legittimi alla loro infrastruttura**.
 
-**Tutti i possibili nomi di dominio di bit-flipping dovrebbero essere monitorati.**
+**Tutti i possibili nomi di dominio bit-flipping dovrebbero essere monitorati.**
 
-### Controlli di base
+Se devi anche considerare lookalike homoglyph/IDN (ad es., mescolare caratteri Latini/Cirillici), controlla:
 
-Una volta che hai un elenco di potenziali nomi di dominio sospetti, dovresti **controllarli** (principalmente le porte HTTP e HTTPS) per **vedere se stanno utilizzando qualche modulo di accesso simile** a quello di uno dei domini della vittima.\
-Potresti anche controllare la porta 3333 per vedere se è aperta e sta eseguendo un'istanza di `gophish`.\
-È anche interessante sapere **quanto è vecchio ciascun dominio sospetto scoperto**, più è giovane, più è rischioso.\
-Puoi anche ottenere **screenshot** della pagina web sospetta HTTP e/o HTTPS per vedere se è sospetta e in tal caso **accederci per dare un'occhiata più approfondita**.
+{{#ref}}
+homograph-attacks.md
+{{#endref}}
 
-### Controlli avanzati
+### Basic checks
 
-Se vuoi fare un passo in più, ti consiglio di **monitorare quei domini sospetti e cercarne di più** di tanto in tanto (ogni giorno? ci vogliono solo pochi secondi/minuti). Dovresti anche **controllare** le **porte** aperte degli IP correlati e **cercare istanze di `gophish` o strumenti simili** (sì, anche gli attaccanti commettono errori) e **monitorare le pagine web HTTP e HTTPS dei domini e sottodomini sospetti** per vedere se hanno copiato qualche modulo di accesso dalle pagine web della vittima.\
-Per **automatizzare questo** ti consiglio di avere un elenco di moduli di accesso dei domini della vittima, eseguire uno spider delle pagine web sospette e confrontare ciascun modulo di accesso trovato all'interno dei domini sospetti con ciascun modulo di accesso del dominio della vittima utilizzando qualcosa come `ssdeep`.\
-Se hai localizzato i moduli di accesso dei domini sospetti, puoi provare a **inviare credenziali spazzatura** e **controllare se ti reindirizza al dominio della vittima**.
+Una volta che hai una lista di potenziali nomi di dominio sospetti dovresti **controllarli** (principalmente le porte HTTP e HTTPS) per **vedere se stanno usando qualche login form simile** a quelli del dominio della vittima.\
+Potresti anche verificare la porta 3333 per vedere se è aperta ed esegue un'istanza di `gophish`.\
+È anche interessante sapere **da quanto tempo ciascun dominio sospetto è stato registrato**: più è giovane, più è rischioso.\
+Puoi anche ottenere **screenshot** della pagina web HTTP e/o HTTPS sospetta per vedere se è sospetta e in tal caso **accedervi per esaminarla più a fondo**.
 
-## Nomi di dominio che utilizzano parole chiave
+### Advanced checks
 
-La pagina principale menziona anche una tecnica di variazione del nome di dominio che consiste nel mettere il **nome di dominio della vittima all'interno di un dominio più grande** (ad es. paypal-financial.com per paypal.com).
+Se vuoi fare un passo in più ti raccomanderei di **monitorare quei domini sospetti e cercarne di nuovi** di tanto in tanto (ogni giorno? ci vuole solo qualche secondo/minuto). Dovresti anche **controllare** le **porte** aperte degli IP correlati e **cercare istanze di `gophish` o tool simili** (sì, anche gli attaccanti commettono errori) e **monitorare le pagine HTTP e HTTPS dei domini e sottodomini sospetti** per vedere se hanno copiato qualche login form dalle pagine della vittima.\
+Per **automatizzare questo** consiglierei di avere una lista dei login form dei domini della vittima, spiderare le pagine sospette e confrontare ogni login form trovato all'interno dei domini sospetti con ogni login form del dominio della vittima usando qualcosa come `ssdeep`.\
+Se hai localizzato i login form dei domini sospetti, puoi provare a **inviare credenziali fittizie** e **verificare se ti reindirizzano al dominio della vittima**.
 
-### Trasparenza del certificato
+---
 
-Non è possibile adottare il precedente approccio "Brute-Force", ma è effettivamente **possibile svelare tali tentativi di phishing** anche grazie alla trasparenza del certificato. Ogni volta che un certificato viene emesso da un CA, i dettagli vengono resi pubblici. Questo significa che leggendo la trasparenza del certificato o anche monitorandola, è **possibile trovare domini che utilizzano una parola chiave all'interno del loro nome**. Ad esempio, se un attaccante genera un certificato di [https://paypal-financial.com](https://paypal-financial.com), vedendo il certificato è possibile trovare la parola chiave "paypal" e sapere che un'email sospetta viene utilizzata.
+### Hunting by favicon and web fingerprints (Shodan/ZoomEye/Censys)
 
-Il post [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) suggerisce che puoi utilizzare Censys per cercare certificati che influenzano una parola chiave specifica e filtrare per data (solo certificati "nuovi") e per l'emittente CA "Let's Encrypt":
+Molti kit di phishing riutilizzano i favicon del brand che imitano. Gli scanner a livello Internet calcolano un MurmurHash3 del favicon codificato in base64. Puoi generare l'hash e pivotare su di esso:
+
+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
+```
+- Interroga Shodan: `http.favicon.hash:309020573`
+- Con gli strumenti: guarda tool della community come favfreak per generare hashes e dorks per Shodan/ZoomEye/Censys.
+
+Note
+- I favicon vengono riutilizzati; tratta le corrispondenze come lead e valida il contenuto e i certs prima di agire.
+- Combina con domain-age e keyword heuristics per maggiore precisione.
+
+### Ricerca telemetria URL (urlscan.io)
+
+`urlscan.io` memorizza screenshot storici, DOM, requests e metadata TLS degli URL inviati. Puoi cercare brand abuse e clone:
+
+Esempi di query (UI o API):
+- Trova lookalike escludendo i tuoi domini legittimi: `page.domain:(/.*yourbrand.*/ AND NOT yourbrand.com AND NOT www.yourbrand.com)`
+- Trova siti che hotlinkano i tuoi asset: `domain:yourbrand.com AND NOT page.domain:yourbrand.com`
+- Restringi ai risultati recenti: aggiungi `AND date:>now-7d`
+
+Esempio 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'
+```
+Dal JSON, pivot on:
+- `page.tlsIssuer`, `page.tlsValidFrom`, `page.tlsAgeDays` per individuare certificati molto nuovi per lookalikes
+- `task.source` valori come `certstream-suspicious` per collegare i riscontri al CT monitoring
+
+### Domain age via RDAP (scriptable)
+
+RDAP restituisce eventi di creazione leggibili dalle macchine. Utile per segnalare **domini appena registrati (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
+```
+Arricchisci la tua pipeline taggando i domini con fasce d'età di registrazione (es. <7 giorni, <30 giorni) e prioritizza la triage di conseguenza.
+
+### Fingerprint TLS/JAx per individuare infrastrutture AiTM
+
+Il moderno credential-phishing utilizza sempre più spesso proxy inversi **Adversary-in-the-Middle (AiTM)** (es. Evilginx) per rubare i token di sessione. Puoi aggiungere rilevazioni lato rete:
+
+- Registra i fingerprint TLS/HTTP (JA3/JA4/JA4S/JA4H) in uscita. Alcune build di Evilginx sono state osservate con valori JA4 client/server stabili. Allerta sui fingerprint noti come malevoli solo come indicatore debole e conferma sempre con il contenuto e l'intelligence sui domini.
+- Registra proattivamente i metadata dei certificati TLS (issuer, numero di SAN, uso di wildcard, validità) per host lookalike scoperti tramite CT o urlscan e correlali con l'età DNS e la geolocalizzazione.
+
+> Nota: considera i fingerprint come arricchimento, non come unici blocchi; i framework evolvono e possono randomizzare o offuscare.
+
+### Nomi di dominio che contengono keyword
+
+La pagina principale menziona anche una tecnica di variazione del nome di dominio che consiste nell'inserire il **nome di dominio della vittima all'interno di un dominio più grande** (es. paypal-financial.com per paypal.com).
+
+#### Certificate Transparency
+
+Non è possibile adottare il precedente approccio "Brute-Force", ma è invece possibile scoprire questi tentativi di phishing anche grazie a Certificate Transparency. Ogni volta che un certificato viene emesso da una CA, i dettagli sono resi pubblici. Questo significa che leggendo la certificate transparency o monitorandola è possibile trovare domini che usano una keyword all'interno del loro nome. Per esempio, se un attaccante genera un certificato di [https://paypal-financial.com](https://paypal-financial.com), vedendo il certificato è possibile trovare la keyword "paypal" e sapere che un dominio sospetto è in uso.
+
+Il post [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) suggerisce che puoi usare Censys per cercare certificati contenenti una specifica keyword e filtrare per data (solo certificati "nuovi") e per CA issuer "Let's Encrypt":
 
 ![https://0xpatrik.com/content/images/2018/07/cert_listing.png](<../../images/image (1115).png>)
 
-Tuttavia, puoi fare "la stessa cosa" utilizzando il web gratuito [**crt.sh**](https://crt.sh). Puoi **cercare la parola chiave** e **filtrare** i risultati **per data e CA** se lo desideri.
+Tuttavia, puoi fare la "stessa cosa" usando il sito web gratuito [**crt.sh**](https://crt.sh). Puoi **cercare la keyword** e **filtrare** i risultati **per data e CA** se desideri.
 
 ![](<../../images/image (519).png>)
 
-Utilizzando quest'ultima opzione puoi persino utilizzare il campo Matching Identities per vedere se qualche identità del dominio reale corrisponde a uno dei domini sospetti (nota che un dominio sospetto può essere un falso positivo).
+Usando quest'ultima opzione puoi anche utilizzare il campo Matching Identities per vedere se qualche identity del dominio reale corrisponde a uno dei domini sospetti (nota che un dominio sospetto può essere un falso positivo).
 
-**Un'altra alternativa** è il fantastico progetto chiamato [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream fornisce un flusso in tempo reale di certificati appena generati che puoi utilizzare per rilevare parole chiave specificate in tempo (quasi) reale. Infatti, c'è un progetto chiamato [**phishing_catcher**](https://github.com/x0rz/phishing_catcher) che fa proprio questo.
+**Un'altra alternativa** è il fantastico progetto chiamato [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream fornisce uno stream in tempo reale di certificati appena generati che puoi usare per rilevare keyword specifiche in (quasi) tempo reale. Infatti, c'è un progetto chiamato [**phishing_catcher**](https://github.com/x0rz/phishing_catcher) che fa proprio questo.
 
-### **Nuovi domini**
+Practical tip: quando triaghi i ritrovamenti CT, prioritizza NRD, registrar non affidabili/sconosciuti, WHOIS con privacy-proxy e certificati con tempi `NotBefore` molto recenti. Mantieni una allowlist dei domini/marchi di tua proprietà per ridurre il rumore.
 
-**Un'ultima alternativa** è raccogliere un elenco di **domini appena registrati** per alcuni TLD ([Whoxy](https://www.whoxy.com/newly-registered-domains/) fornisce tale servizio) e **controllare le parole chiave in questi domini**. Tuttavia, i domini lunghi di solito utilizzano uno o più sottodomini, quindi la parola chiave non apparirà all'interno del FLD e non sarai in grado di trovare il sottodominio di phishing.
+#### **Nuovi domini**
+
+**Un'ultima alternativa** è raccogliere una lista di **domini appena registrati** per alcuni TLD ([Whoxy](https://www.whoxy.com/newly-registered-domains/) fornisce questo servizio) e **controllare le keyword in questi domini**. Tuttavia, i domini lunghi di solito usano uno o più sottodomini, quindi la keyword potrebbe non apparire all'interno del FLD e non riuscirai a trovare il sottodominio di phishing.
+
+Heuristica aggiuntiva: considera con sospetto alcune **TLD da estensione file** (es., `.zip`, `.mov`) negli avvisi. Questi vengono comunemente confusi con nomi di file nelle esche; combina il segnale del TLD con keyword del brand e l'età NRD per maggiore precisione.
+
+## Riferimenti
+
+- 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}}

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; }