Il DLL search order hijacking rimane rilevante negli ambienti enterprise moderni perché:

• Abusa di binari legittimi e flussi di esecuzione attendibili.
• Spesso bypassa il rilevamento basato su firme.
• Può operare in ambienti con EDR e application control.
• Consente un'affidabile escalation dei privilegi.
• Supporta scenari di attacco tramite supply-chain e ingegneria sociale.

Questa tecnica è mappata su MITRE ATT&CK:

• T1574 (Hijack Execution Flow)
• T1574.001 (DLL Search Order Hijacking)

⸻

Obiettivi della Ricerca

Questo repository mira a:

1. Documentare il comportamento tecnico dell'installer vulnerabile.
2. Analizzare la risoluzione delle librerie e il comportamento di caricamento.
3. Identificare la causa principale e i pattern di caricamento non sicuri.
4. Fornire una PoC minima che dimostri l'esecuzione di codice.
5. Esplorare strategie di rilevamento e telemetria.
6. Supportare la simulazione dell'avversario e scenari BAS.
7. Contribuire alla ricerca difensiva e alla consapevolezza.

Questo non è inteso a fornire sfruttamento weaponizzato.

⸻

Proof of Concept

La PoC inclusa dimostra che una DLL dannosa può essere caricata durante l'installazione. Invece di eseguire un payload dannoso, la DLL crea un file marker benigno nella directory temporanea per confermare l'esecuzione di codice.

La PoC:

• Genera una DLL dannosa.
• La posiziona accanto all'installer vulnerabile.
• Esegue l'installer.
• Verifica l'esecuzione riuscita tramite la creazione dell'artefatto.

Questo approccio consente una validazione sicura in ambienti controllati.

⸻

Contesto Tecnico

Windows risolve le DLL utilizzando un ordine di ricerca quando una libreria viene referenziata senza un percorso assoluto. L'ordine include tipicamente:

1. Directory dell'applicazione
2. Directory di sistema
3. Percorsi di ambiente
4. Directory di lavoro corrente

Se l'applicazione utilizza funzioni di caricamento non sicure (ad esempio, il comportamento predefinito di LoadLibrary), gli attaccanti possono influenzare la risoluzione.

Le cause comuni includono:

• Percorsi relativi
• Mancanza di validazione dell'integrità
• Dipendenze legacy
• Utilizzo non sicuro delle API
• Flag di caricamento sicuro delle DLL mancanti

⸻

Modello di Minaccia

Gli scenari di attacco tipici includono:

• Compromissione della supply chain
• Distribuzione tramite ingegneria sociale
• Bundling di software
• USB o supporti rimovibili
• Persistenza locale tramite software attendibile

L'obiettivo dell'attaccante è ottenere l'esecuzione in un contesto privilegiato.

⸻

Opportunità di Rilevamento

I difensori possono rilevare questa classe di attività monitorando:

• Caricamenti di DLL da directory non standard
• Librerie non firmate o non attendibili
• Manipolazione sospetta della directory di lavoro
• Processi elevati che caricano dipendenze inaspettate
• Caricamenti di librerie provenienti da percorsi controllati dall'utente

Le fonti di telemetria rilevanti includono:

• Sysmon
• ETW
• Segnali comportamentali EDR
• Tracciamento dei processi e dei caricamenti dei moduli

⸻

Mitigazioni Difensive

Controlli raccomandati:

• Applicare SafeDllSearchMode
• Utilizzare percorsi assoluti per le librerie
• Validare le firme digitali
• Rafforzare i flussi di lavoro di installazione
• Limitare l'accesso in scrittura alle directory eseguibili
• Monitorare le catene di esecuzione privilegiate

⸻

Roadmap della Ricerca

Il lavoro futuro può includere:

• Reverse engineering statico e dinamico dell'installer
• Tracciamento delle dipendenze e patch diffing
• Identificazione di moduli vulnerabili aggiuntivi
• Confronto con vulnerabilità simili negli installer
• Sviluppo di scenari BAS per la validazione
• Ingegneria del rilevamento e sviluppo di regole

⸻

Uso Responsabile

Questo repository è fornito per la ricerca e la sicurezza difensiva. Deve essere utilizzato solo in ambienti autorizzati e in condizioni di laboratorio controllate.

⸻

Disclaimer

L'autore non è responsabile per l'uso improprio di questo materiale. Gli utenti sono responsabili di garantire la conformità legale ed etica.

⸻

Come Eseguire la Proof of Concept

Questa PoC è progettata per essere eseguita solo in un ambiente di test isolato e autorizzato. Non eseguirla su sistemi di produzione.

Requisiti

Prima di eseguire la PoC, assicurarsi di avere:

• Un ambiente di test Windows (macchina virtuale consigliata).
• L'installer vulnerabile: M-Track Duo HD 1.0.0.
• Python 3 installato.
• Privilegi di amministratore.
• Antivirus o EDR disabilitato o configurato per consentire test controllati.
• Il sistema non deve contenere dati sensibili o di produzione.

Uno snapshot della VM usa e getta è fortemente consigliato.

Passo 1 – Preparare l'Ambiente

Creare una directory di lavoro pulita e copiarvi l'installer vulnerabile.

Esempio:

C:\lab\cve-2026-25676\

Posizionare l'installer in questa cartella.

Passo 2 – Configurare la DLL Incorporata

Lo script della PoC contiene una DLL incorporata codificata in base64. Prima dell'esecuzione:

1. Compilare il codice sorgente della DLL fornito utilizzando una toolchain compatibile con Windows (come MinGW).
2. Codificare la DLL generata in base64.
3. Sostituire il segnaposto all'interno dello script.

Questa DLL è intenzionalmente benigna. Crea solo un file marker per dimostrare l'esecuzione di codice.

⸻

Passo 3 – Eseguire lo Script

Eseguire la PoC:

python poc_cve-2026-25676.py <path_to_installer> [dll_name]

esempio:

python poc_cve-2026-25676.py M-Track_Duo_HD_1.0.0.exe version.dll

Se l'installer richiede elevazione, accettare il prompt UAC.

Passo 4 – Validare l'Esecuzione

Se la vulnerabilità viene attivata con successo, la DLL dannosa verrà caricata durante il processo di installazione. La PoC creerà un file marker:

%TEMP%\poc_cve-2026-25676.txt

La presenza di questo file conferma che l'esecuzione di codice è avvenuta nel contesto dell'installer.

⸻

Passo 5 – Risoluzione dei Problemi

Se il file marker non viene creato, considerare quanto segue:

• Il nome della DLL potrebbe non corrispondere alla dipendenza prevista.
• L'installer potrebbe non caricare la libreria target.
• Disallineamento dell'architettura (32-bit vs 64-bit).
• Controlli di sicurezza che bloccano l'esecuzione della DLL.
• La directory di lavoro potrebbe non influenzare il percorso di ricerca.
• L'installer potrebbe utilizzare meccanismi di caricamento sicuri.

Potrebbe essere necessaria un'ulteriore analisi delle dipendenze delle librerie.

⸻

Passo 6 – Pulizia

Lo script tenta di rimuovere automaticamente la DLL generata. Tuttavia, si consiglia una pulizia manuale per ripristinare l'ambiente di test.

Il ripristino dello snapshot della VM dopo il test è l'opzione più sicura.