Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=domain-subdomain-takeover) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Se scopri un dominio (domain.tld) che è **utilizzato da qualche servizio all'interno dell'ambito** ma la **società** ha p**e**rduto la **proprietà** di esso, puoi provare a **registrarlo** (se abbastanza economico) e far sapere alla società. Se questo dominio sta ricevendo alcune **informazioni sensibili** come un cookie di sessione tramite il parametro **GET** o nell'intestazione **Referer**, questa è sicuramente una **vulnerabilità**.
Un sottodominio della società punta a un **servizio di terze parti con un nome non registrato**. Se puoi **creare** un **account** in questo **servizio di terze parti** e **registrare** il **nome** in uso, puoi eseguire il takeover del sottodominio.
I controlli per il takeover dei sottodomini sono inclusi nell'enumerazione predefinita dei sottodomini di BBOT. Le firme sono estratte direttamente da [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz).
Quando viene utilizzato un wildcard DNS in un dominio, qualsiasi sottodominio richiesto di quel dominio che non ha un indirizzo diverso esplicitamente sarà **risolto alle stesse informazioni**. Questo potrebbe essere un indirizzo IP A, un CNAME...
Tuttavia, se invece di puntare a un indirizzo IP, l'amministratore di sistema lo punta a un **servizio di terze parti tramite CNAME**, come un **sottodominio github** per esempio (`sohomdatta1.github.io`). Un attaccante potrebbe **creare la propria pagina di terze parti** (in Github in questo caso) e dire che `something.testing.com` punta lì. Perché, il **CNAME wildcard** consentirà all'attaccante di **generare sottodomini arbitrari per il dominio della vittima che puntano alle sue pagine**.
Puoi trovare un esempio di questa vulnerabilità nel report CTF: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
Il takeover di sottodominio è essenzialmente uno spoofing DNS per un dominio specifico su Internet, consentendo agli attaccanti di impostare record A per un dominio, portando i browser a visualizzare contenuti dal server dell'attaccante. Questa **trasparenza** nei browser rende i domini vulnerabili al phishing. Gli attaccanti possono impiegare [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) o [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) per questo scopo. Sono particolarmente vulnerabili i domini in cui l'URL in un'email di phishing appare legittimo, ingannando gli utenti e eludendo i filtri antispam a causa della fiducia intrinseca del dominio.
I certificati SSL, se generati dagli attaccanti tramite servizi come [_Let's Encrypt_](https://letsencrypt.org/), aggiungono legittimità a questi domini falsi, rendendo gli attacchi di phishing più convincenti.
La trasparenza del browser si estende anche alla sicurezza dei cookie, governata da politiche come la [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). I cookie, spesso utilizzati per gestire sessioni e memorizzare token di accesso, possono essere sfruttati tramite takeover di sottodominio. Gli attaccanti possono **raccogliere cookie di sessione** semplicemente indirizzando gli utenti a un sottodominio compromesso, mettendo a rischio i dati e la privacy degli utenti.
Un altro aspetto del takeover di sottodominio coinvolge i servizi email. Gli attaccanti possono manipolare **record MX** per ricevere o inviare email da un sottodominio legittimo, aumentando l'efficacia degli attacchi di phishing.
Ulteriori rischi includono il **takeover di record NS**. Se un attaccante ottiene il controllo su un record NS di un dominio, può potenzialmente indirizzare una parte del traffico a un server sotto il proprio controllo. Questo rischio è amplificato se l'attaccante imposta un alto **TTL (Time to Live)** per i record DNS, prolungando la durata dell'attacco.
Gli attaccanti potrebbero sfruttare record CNAME non reclamati che puntano a servizi esterni che non sono più utilizzati o sono stati dismessi. Questo consente loro di creare una pagina sotto il dominio fidato, facilitando ulteriormente il phishing o la distribuzione di malware.
1.**Rimuovere i record DNS vulnerabili** - Questo è efficace se il sottodominio non è più necessario.
2.**Reclamare il nome di dominio** - Registrare la risorsa con il rispettivo fornitore di cloud o riacquistare un dominio scaduto.
3.**Monitoraggio regolare per vulnerabilità** - Strumenti come [aquatone](https://github.com/michenriksen/aquatone) possono aiutare a identificare domini suscettibili. Le organizzazioni dovrebbero anche rivedere i loro processi di gestione dell'infrastruttura, assicurandosi che la creazione di record DNS sia l'ultimo passo nella creazione delle risorse e il primo passo nella distruzione delle risorse.
Per i fornitori di cloud, verificare la proprietà del dominio è cruciale per prevenire takeover di sottodomini. Alcuni, come [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), hanno riconosciuto questo problema e implementato meccanismi di verifica del dominio.
Usa [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=domain-subdomain-takeover) per costruire e **automatizzare flussi di lavoro** alimentati dagli **strumenti comunitari più avanzati** del mondo.\
Impara e pratica Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Impara e pratica Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.