Link Target: Link Target (T1608.005)
La tecnica Link Target rientra nella tattica Resource Development (TA0042) e descrive la fase in cui un attaccante predispone le risorse a cui punterà un link malevolo, prima di lanciare un attacco di phishing. Non si tratta ancora dell'invio dell'esca, ma della costruzione della destinazione: una pagina HTML, spesso arricchita di script lato client come JavaScript, che decide quali contenuti servire alla vittima in base al contesto.
Le declinazioni più diffuse sono due. Nella prima, l'aggressore clona una pagina di login legittima (un servizio cloud, il portale aziendale) per raccogliere credenziali durante uno Spearphishing Link. Nella seconda, il link punta a malware ospitato su servizi fidati come Dropbox o OneDrive, sfruttando la reputazione del provider per aggirare i filtri.
Per aumentare l'efficacia, gli attori registrano domini simili ai legittimi tramite typosquatting e omoglifi, mascherano la vera destinazione abusando dello schema URL, e abusano di accorciatori di link e piattaforme PaaS. Alcuni sfruttano URI monouso o l'InterPlanetary File System (IPFS), la cui natura decentralizzata rende difficile la rimozione dei contenuti.
L'impatto è indiretto ma sostanziale: 3 gruppi e 2 campagne documentate hanno impiegato questa preparazione come trampolino per l'accesso iniziale. Trattandosi di attività condotta interamente su infrastruttura esterna, la mitigazione preventiva è limitata e la detection si concentra sulle fasi successive del ciclo d'attacco.
Poiché questa è una tecnica di Resource Development, l'obiettivo in un ingaggio red team è simulare in modo controllato la preparazione del link target, mai colpire infrastrutture reali senza autorizzazione scritta. Tutto deve avvenire in un dominio di laboratorio dedicato e con scope definito.
Per clonare una pagina di login a scopo di credential harvesting, Gophish (open source) è lo standard: gestisce campagne, landing page e cattura delle credenziali con dashboard integrata. Per l'acquisizione statica di una pagina esistente da riprodurre in lab, wget --mirror --convert-links --page-requisites
La catena replica quanto osservato nei gruppi reali: si ospita un eseguibile su un servizio fidato (in lab, uno storage controllato che emula Dropbox o OneDrive) e si costruisce un link che reindirizza al download, come fatto da FIN7 e LuminousMoth con Dropbox e da MirrorFace con OneDrive durante Operation AkaiRyū.
Per il mascheramento del dominio, in laboratorio si generano varianti tramite dnstwist (open source), che produce permutazioni omoglifiche, typosquatting e TLD alternativi partendo dal dominio target:
dnstwist --registered dominio-target.com
Questo consente di verificare quali lookalike sono già registrati e di simulare la selezione infrastrutturale che un attaccante compirebbe.
Per il redirect e l'offuscamento della destinazione si possono usare accorciatori self-hosted come YOURLS (open source), evitando servizi pubblici reali che coinvolgerebbero terze parti. La logica di serving condizionale (mostrare contenuto benigno agli scanner e malevolo alla vittima) si implementa con semplice JavaScript o filtri server-side su User-Agent e geolocalizzazione, tecnica nota come cloaking.
Alcune note operative:
- IPFS: per riprodurre l'hosting decentralizzato si usa il client Kubo (open source) di IPFS in un nodo isolato, dimostrando la difficoltà di takedown.
- Payload staging: mantieni sempre i binari di test firmati e tracciabili, con hash documentati nel report.
L'output atteso di questa fase è la validazione della postura difensiva: quanto rapidamente il SOC individua il dominio lookalike, se i gateway bloccano il link accorciato e se gli utenti segnalano l'esca. Il valore del test non è nel link in sé, ma nella misurazione della reazione organizzativa.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo