# Toma de control de dominio/subdominio
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
\
Utiliza [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir y **automatizar flujos de trabajo** con las herramientas comunitarias más avanzadas del mundo.\
Obtén acceso hoy mismo:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Toma de control de dominio
Si descubres que algún dominio (dominio.tld) está siendo utilizado por algún servicio dentro del alcance, pero la **empresa** ha **perdido la propiedad** del mismo, puedes intentar **registrarlo** (si es lo suficientemente barato) y notificar a la empresa. Si este dominio está recibiendo alguna **información sensible**, como una cookie de sesión a través de un parámetro **GET** o en la cabecera **Referer**, esto es sin duda una **vulnerabilidad**.
### Toma de control de subdominio
Un subdominio de la empresa apunta a un **servicio de terceros con un nombre no registrado**. Si puedes **crear** una **cuenta** en este **servicio de terceros** y **registras** el **nombre** que está en uso, puedes llevar a cabo la toma de control del subdominio.
Existen varias herramientas con diccionarios para verificar posibles tomas de control:
* [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz)
* [https://github.com/blacklanternsecurity/bbot](https://github.com/blacklanternsecurity/bbot)
* [https://github.com/punk-security/dnsReaper](https://github.com/punk-security/dnsReaper)
* [https://github.com/haccer/subjack](https://github.com/haccer/subjack)
* [https://github.com/anshumanbh/tko-sub](https://github.com/anshumanbh/tko-subs)
* [https://github.com/ArifulProtik/sub-domain-takeover](https://github.com/ArifulProtik/sub-domain-takeover)
* [https://github.com/SaadAhmedx/Subdomain-Takeover](https://github.com/SaadAhmedx/Subdomain-Takeover)
* [https://github.com/Ice3man543/SubOver](https://github.com/Ice3man543/SubOver)
* [https://github.com/m4ll0k/takeover](https://github.com/m4ll0k/takeover)
* [https://github.com/antichown/subdomain-takeover](https://github.com/antichown/subdomain-takeover)
* [https://github.com/musana/mx-takeover](https://github.com/musana/mx-takeover)
#### Escaneo de subdominios secuestrables con [BBOT](https://github.com/blacklanternsecurity/bbot):
Las comprobaciones de toma de control de subdominios están incluidas en la enumeración de subdominios predeterminada de BBOT. Las firmas se obtienen directamente de [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz).
~~~bash
bbot -t evilcorp.com -f subdomain-enum
~~~
### Generación de toma de control de subdominio mediante DNS Wildcard
Cuando se utiliza un comodín DNS en un dominio, cualquier subdominio solicitado de ese dominio que no tenga una dirección diferente explícitamente se **resolverá con la misma información**. Esto puede ser una dirección IP A, un CNAME...
Por ejemplo, si `*.testing.com` está comodinado a `1.1.1.1`. Entonces, `not-existent.testing.com` apuntará a `1.1.1.1`.
Sin embargo, si en lugar de apuntar a una dirección IP, el administrador del sistema lo apunta a un **servicio de terceros a través de CNAME**, como un **subdominio de GitHub**, por ejemplo (`sohomdatta1.github.io`). Un atacante podría **crear su propia página de terceros** (en este caso, en GitHub) y decir que `something.testing.com` apunta allí. Debido a que el **comodín CNAME** lo permite, el atacante podrá **generar subdominios arbitrarios para el dominio de la víctima que apunten a sus páginas**.
Puedes encontrar un ejemplo de esta vulnerabilidad en el informe de CTF: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
## Explotando una toma de control de subdominio
**Esta información fue copiada de** [**https://0xpatrik.com/subdomain-takeover/**](https://0xpatrik.com/subdomain-takeover/)
Recientemente, [escribí](https://0xpatrik.com/subdomain-takeover-basics/) sobre los conceptos básicos de la toma de control de subdominios. Aunque el concepto ahora se comprende en general, noté que las personas suelen tener dificultades para entender los riesgos que implica la toma de control de subdominios. En esta publicación, profundizo y cubro los riesgos más notables de la _toma de control de subdominios_ desde mi perspectiva.
_Nota: Algunos riesgos se mitigan implícitamente por el proveedor de la nube. Por ejemplo, cuando es posible la toma de control de subdominios en Amazon CloudFront, no hay forma de configurar registros TXT para omitir las comprobaciones SPF. Por lo tanto, el objetivo de esta publicación es proporcionar riesgos sobre la toma de control de subdominios en general. Sin embargo, la mayoría de estos también se aplican a los proveedores de la nube._
### Transparencia para un navegador
Para empezar, veamos la resolución DNS cuando está involucrado un CNAME:
Ten en cuenta que el paso #7 solicita _sub.example.com_ en lugar de _anotherdomain.com_. Esto se debe a que el navegador web no sabe que _anotherdomain.com_ existe. Aunque se utiliza el registro CNAME, la barra de URL del navegador aún contiene _sub.example.com_. Esta es la **transparencia** para el navegador. Si lo piensas, el navegador confía en el resolutor DNS para proporcionar información precisa sobre el dominio. Simplificando, la toma de control de subdominios es un envenenamiento DNS para un dominio en particular en Internet. ¿Por qué? Porque cualquier navegador que realice la resolución DNS en el dominio afectado recibe un conjunto de registros A establecido por un atacante. El navegador luego muestra felizmente lo que recibe de este servidor (pensando que es legítimo).
Un dominio así es perfecto para un escenario de phishing. Los atacantes suelen utilizar [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) o los llamados [_dominios Doppelganger_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) para imitar el dominio/sitio web legítimo con fines de phishing. Después de que un atacante se apodera de un nombre de dominio legítimo, es casi imposible para un usuario regular saber si el contenido del dominio es proporcionado por una parte legítima o por un atacante. Tomemos, por ejemplo, un banco al azar. Si uno de los subdominios del banco es vulnerable a la toma de control de subdominios, un atacante puede crear un formulario HTML que imite el formulario de inicio de sesión del sistema de banca en línea del banco. Luego, un atacante puede ejecutar una campaña de spear phishing o phishing masivo pidiendo a los usuarios que inicien sesión y cambien sus contraseñas. En esta etapa, las contraseñas son capturadas por un atacante que tiene el control del dominio en cuestión. La URL proporcionada en el correo electrónico de phishing es un subdominio legítimo de un banco. Por lo tanto, los usuarios no son conscientes de que algo malicioso está sucediendo. Los filtros de spam y otras medidas de seguridad también tienen menos probabilidades de detectar el correo electrónico como spam o malicioso porque contiene nombres de dominio con mayor confianza.
De hecho, el nombre de dominio en sí juega un papel importante en una campaña exitosa. Tener un subdominio de quinto nivel vulnerable a la toma de control de subdominios es mucho menos _"legítimo"_ que tener un subdominio de segundo nivel con un nombre de subdominio amigable. He visto varios casos de subdominios perfectos para phishing, incluyendo:
* _purchases.SOMETHING.com_
* _www.SOMETHING.com_
* _online.SOMETHING.com_
* _shop.SOMETHING.com_
Todos ellos son vulnerables a la toma de control de subdominios. Todos ellos eran grandes marcas. ¿Hablando de phishing perfecto?
Sin embargo, las campañas de phishing recientes alojan contenido en dominios con nombres de dominio largos que incluyen el nombre de la marca (ver ejemplo de [Apple](https://www.phishtank.com/target\_search.php?target\_id=183\&valid=y\&active=All\&Search=Search)). Al tener un certificado SSL válido (más sobre eso a continuación), una palabra clave en el nombre de dominio y un sitio web que imita el sitio web de la marca objetivo, las personas tienden a caer en estos ataques. Piensa en las posibilidades con un subdominio legítimo de esta marca.
\
Usa [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias más avanzadas del mundo.\
Obtén acceso hoy mismo:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
### Certificados SSL
El ataque anterior puede mejorarse generando un certificado SSL válido. Las autoridades de certificación como [_Let's Encrypt_](https://letsencrypt.org/) permiten la verificación automática de la propiedad del dominio mediante la verificación de contenido:
Es decir, si hay un contenido específico ubicado en una ruta de URL específica, Let's Encrypt aprobará la emisión de un certificado para un dominio determinado. Dado que un atacante tiene control total sobre el contenido del dominio que es vulnerable a la toma de control de subdominios, esta verificación se puede hacer en cuestión de minutos. Por lo tanto, los atacantes también pueden generar un certificado SSL para dicho dominio, lo que reduce la sospecha de un ataque de phishing.
### Robo de cookies
Esto va de la mano con la transparencia del navegador pero tiene consecuencias diferentes. El navegador web implementa muchas políticas de seguridad para evitar que los sitios web maliciosos causen daño. Esto incluye cosas como la [política de mismo origen](https://en.wikipedia.org/wiki/Same-origin\_policy). Una de las principales responsabilidades de seguridad de un navegador es proteger las cookies guardadas. ¿Por qué? Si bien HTTP es un protocolo sin estado, las cookies se utilizan para realizar un seguimiento de las sesiones. Por conveniencia, los usuarios suelen guardar las cookies durante un período prolongado para evitar iniciar sesión cada vez. Estas cookies, por lo tanto, actúan como un token de inicio de sesión que se presenta al servidor web y se identifica al usuario. Los ataques como el [_secuestro de sesión_](https://en.wikipedia.org/wiki/Session\_hijacking) evolucionaron naturalmente a partir de este concepto.
El navegador presenta automáticamente las cookies almacenadas con cada solicitud al dominio que las emitió. Existe una excepción a esto, de modo que las cookies pueden compartirse entre subdominios ([leer aquí](https://tools.ietf.org/html/rfc6265#section-8.6), también observa la sección 8.7). Esto suele ocurrir cuando el sitio web utiliza un sistema de inicio de sesión único basado en cookies ([SSO](https://en.wikipedia.org/wiki/Single\_sign-on)). Con SSO, un usuario puede iniciar sesión utilizando un subdominio y compartir el mismo token de sesión en una amplia gama de subdominios. La sintaxis para establecer una cookie regular es la siguiente:
```
HTTP/1.1 200 OK
Set-Cookie: name=value
```
Si esta cookie es emitida por un servidor web que reside en _example.com_, solo este servidor puede acceder a esta cookie más adelante. Sin embargo, la cookie puede ser emitida para un dominio comodín (por las razones explicadas anteriormente) de la siguiente manera:
```
HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com
```
La cookie se incluirá en las solicitudes HTTP a _example.com_, pero también a cualquier otro subdominio como _subdominio.example.com_. Este comportamiento crea la posibilidad de ataques de alta gravedad utilizando la toma de subdominios. Supongamos que un dominio en particular está utilizando cookies de sesión para un dominio comodín. Si hay un subdominio vulnerable a la toma de subdominios, lo único necesario para recopilar el token de sesión del usuario es engañarlo para que visite el subdominio vulnerable. La cookie de sesión se envía automáticamente con la solicitud HTTP.
El navegador también implementa mecanismos de seguridad adicionales para las cookies:
* **Cookie HttpOnly** - Las cookies, por defecto, pueden ser accedidas por el código Javascript que se ejecuta en el contexto del sitio web que creó las cookies. Javascript puede leer, actualizar y eliminar las cookies. La bandera de cookie _HttpOnly_ (establecida por el servidor web) indica que la cookie en particular no puede ser accedida por el código Javascript. La única forma de obtenerla es a través de las cabeceras de solicitud y respuesta HTTP.
* **Cookie segura** - Cuando la cookie tiene la bandera _Secure_ establecida por el servidor web, solo puede ser comunicada de vuelta al servidor web si se utiliza HTTPS.
Si el dominio es vulnerable a la toma de subdominios, un atacante puede recopilar cookies emitidas por ese dominio en el pasado simplemente engañando a los usuarios para que visiten ese sitio web. Las banderas HttpOnly y Secure no ayudan, ya que la cookie no se está accediendo mediante Javascript y el certificado SSL se puede generar fácilmente para el dominio tomado.
El robo de cookies utilizando la toma de subdominios fue explicado en un informe de recompensa por errores [aquí](https://hackerone.com/reports/172137) por Arne Swinnen. El informe explica el problema con uno de los subdominios de _Ubiquiti Networks_ (_ping.ubnt.com_). Este subdominio era vulnerable a la toma de subdominios, apuntando a una distribución no reclamada de AWS CloudFront. Dado que Ubiquiti Networks utiliza SSO con cookies de sesión comodín, todos los usuarios que visiten _ping.ubnt.com_ podrían tener sus cookies de sesión robadas. Aunque este dominio apunta a AWS CloudFront, la configuración de la distribución de CloudFront permite registrar cookies con cada solicitud. Por lo tanto, el escenario de extracción de cookies de sesión es completamente posible incluso con subdominios que apuntan a AWS CloudFront. En 2017, Arne también demostró un vector de ataque similar contra el sistema SSO de [Uber](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/).
El comportamiento explicado anteriormente no se limita a las cookies. Dado que los scripts de Javascript tienen control total sobre los sitios web en los que se ejecutan, tener la capacidad de reemplazar dichos scripts en el sitio web legítimo podría tener consecuencias catastróficas. Supongamos que un sitio web está utilizando código Javascript de un proveedor externo utilizando la etiqueta _script_ y el atributo _src_. Cuando el dominio del proveedor externo caduca, el navegador falla silenciosamente, es decir, no activa ninguna alerta visible para los usuarios regulares. Si el código externo no realiza ninguna tarea importante (por ejemplo, se utiliza solo para rastrear), dicho proveedor externo puede permanecer en el sitio web durante un período prolongado. Un atacante puede tomar el control de este dominio caducado, coincidir con la ruta de URL del código Javascript proporcionado y así obtener el control sobre cada visitante que visite el sitio web original.
Sin embargo, hay una forma de proteger la integridad de los archivos de Javascript en un navegador. _Subresource Integrity_ [fue propuesto](https://www.w3.org/TR/2016/REC-SRI-20160623/) como un mecanismo para incluir un hash criptográfico como atributo _integrity_ en la etiqueta _script_ en HTML5. Cuando el hash criptográfico proporcionado no coincide con el archivo descargado, el navegador se niega a ejecutarlo.
### Correos electrónicos
Cuando es posible la toma de subdominios CNAME, los registros MX también pueden configurarse por parte de un atacante en un servidor web arbitrario. Esto permite recibir correos electrónicos en un subdominio legítimo de una marca, lo cual es particularmente útil en ataques de (spear) phishing donde se requiere interacción entre el atacante y la víctima. Los atacantes suelen falsificar la cabecera `Return-Path` para recibir una respuesta al correo electrónico. Con los registros MX correctos, se evita este problema.
Por otro lado, también es posible enviar correos electrónicos. Aunque es trivial falsificar la cabecera `From` para incluir cualquier dirección de correo electrónico, los filtros SPF suelen verificar la cabecera `Return-Path` y los hosts permitidos para enviar correos electrónicos para el dominio. SPF almacena la configuración en registros TXT de DNS. Con la toma de subdominios, los registros TXT también están bajo el control del atacante, por lo que las verificaciones SPF se pueden pasar fácilmente.
_Como mencioné al principio, estas tácticas generalmente no funcionan con la mayoría de los proveedores de servicios en la nube, ya que no se tiene control directo sobre la zona DNS._
### Riesgos de orden superior
El concepto de toma de subdominios se puede extender naturalmente a los registros NS: si el dominio base de al menos un registro NS está disponible para su registro, el nombre de dominio de origen es vulnerable a la toma de subdominios.
Uno de los problemas en la toma de subdominios utilizando registros NS es que el nombre de dominio de origen generalmente tiene múltiples registros NS. Se utilizan múltiples registros NS para redundancia y equilibrio de carga. El servidor de nombres se elige al azar antes de la resolución DNS. Supongamos que el dominio _sub.example.com_ tiene dos registros NS: _ns.vulnerable.com_ y _ns.nonvulnerable.com_. Si un atacante toma el control de _ns.vulnerable.com_, la situación desde la perspectiva del usuario que consulta _sub.example.com_ es la siguiente:
1. Dado que hay dos servidores de nombres, se elige uno al azar. Esto significa que la probabilidad de consultar un servidor de nombres controlado por un atacante es del 50%.
2. Si el resolutor DNS del usuario elige _ns.nonvulnerable.com_ (servidor de nombres legítimo), se devuelve el resultado correcto y es probable que se almacene en caché en algún lugar entre 6 y 24 horas.
3. Si el resolutor DNS del usuario elige _ns.vulnerable.com_ (servidor de nombres propiedad de un atacante), un atacante puede proporcionar un resultado falso que también se almacenará en caché. Dado que el atacante tiene el control del servidor de nombres, puede establecer el TTL para este resultado en particular, por ejemplo, una semana.
El proceso anterior se repite cada vez que caduca la entrada de caché. Cuando un atacante elige utilizar un TTL con un valor alto, el resultado falso permanecerá en la caché DNS durante ese período. Durante este tiempo, todas las solicitudes a _sub.example.com_ utilizarán el resultado DNS falso almacenado en caché por el atacante. Esta idea se amplifica aún más cuando se utilizan resolutores DNS públicos (por ejemplo, Google DNS). En este caso, es probable que los resolutores públicos almacenen en caché los resultados falsos, lo que significa que todos los usuarios que utilicen el mismo resolutor DNS obtendrán resultados falsos hasta que se revoque la caché.
Además del control sobre el nombre de dominio de origen, también se obtiene el control sobre todos los dominios de nivel superior del nombre de dominio de origen. Esto se debe a que ser propietario de un nombre de dominio canónico de un registro NS significa ser propietario de la zona DNS completa del nombre de dominio de origen.
En 2016, Matthew Bryant [demostró](https://thehackerblog.com/the-international-incident-gaining-control-of-a-int-domain-name-with-dns-trickery/index.html) una toma de subdominios utilizando un registro NS en _maris.int_. El dominio de nivel superior .INT es un TLD especial y solo unos pocos dominios lo utilizan. Bryant mostró que aunque el registro de dichos nombres de dominio está aprobado exclusivamente por IANA, los servidores de nombres se pueden configurar en dominios arbitrarios. Dado que uno de los servidores de nombres de _maris.int_ estaba disponible para su registro (_cobalt.aliis.be_), fue posible la toma de subdominios incluso en este TLD restringido.
Matthew también [demostró](https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/index.html) un ataque de mayor gravedad donde pudo obtener el control sobre el servidor de nombres del dominio de nivel superior .IO. Obtener el control sobre .IO significa controlar las respuestas para todos los nombres de dominio .IO. En este caso, uno de los servidores de nombres de .IO era _ns-a1.io_, que estaba disponible para su registro. Al registrar _ns-a1.io_, Bryant pudo recibir consultas DNS y controlar sus respuestas para todos los dominios .IO.
### Mitigación
Las estrategias de mitigación para los nombres de dominio que ya son vulnerables a la toma de subdominios son bastante sencillas:
* **Eliminar el registro DNS afectado** - La solución más simple es eliminar el registro afectado de la zona DNS. Este paso se suele utilizar si la organización concluye que el nombre de dominio fuente afectado ya no es necesario.
* **Reclamar el nombre de dominio** - Esto significa registrar el recurso en un proveedor de nube en particular o, en el caso de un dominio de Internet regular, volver a comprar el dominio caducado.
Para prevenir la toma de subdominios en el futuro, las organizaciones deben cambiar el proceso de creación y destrucción de recursos en su infraestructura. En el caso de la creación de recursos, la creación del registro DNS debe ser el _último paso_ de este proceso. Esta condición evita que el registro DNS apunte a un dominio que no existe en ningún momento. Para la destrucción de recursos, se aplica lo contrario: el registro DNS debe eliminarse como el _primer paso_ en este proceso. Herramientas como [aquatone](https://github.com/michenriksen/aquatone) incluyen comprobaciones de toma de subdominios. Estas comprobaciones deben realizarse periódicamente por parte del equipo de seguridad de una organización para verificar que no haya dominios vulnerables. Los procesos de recopilación centralizada de nombres de dominio expuestos a menudo no son eficientes dentro de las organizaciones (debido a equipos globales, etc.) y, por lo general, la monitorización externa es la mejor opción.
También se debe considerar la estrategia de mitigación para los proveedores de servicios en la nube. Los servicios en la nube no verifican la propiedad del dominio. La razón detrás de esto es principalmente la comodidad. El proveedor de la nube no introduce ninguna vulnerabilidad al no verificar la propiedad de un nombre de dominio fuente. Por lo tanto, depende del usuario supervisar sus registros DNS. Otra razón es que cuando se elimina un recurso en la nube, el usuario generalmente deja de ser cliente de ese servicio. Entonces, la pregunta que se hacen los proveedores de servicios en la nube es: ¿Por qué deberíamos preocuparnos?
Proveedores como [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/) se dieron cuenta de que la toma de subdominios es un problema e implementaron un mecanismo de verificación de dominio.
_Algunas partes de esta publicación son extractos de mi_ [_Tesis de Maestría_](https://is.muni.cz/th/byrdn/Thesis.pdf).
¡Hasta la próxima!
[Patrik](https://twitter.com/0xpatrik)
\
Utiliza [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir y automatizar fácilmente flujos de trabajo con las herramientas comunitarias más avanzadas del mundo.\
Obtén acceso hoy mismo:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres que tu **empresa sea anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**merchandising oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PR al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
.png)