* ¿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).
Encuentra las vulnerabilidades que más importan para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, realiza escaneos proactivos de amenazas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. [**Pruébalo gratis**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoy.
* El **SO**, que mantiene las aplicaciones instaladas aisladas entre sí.
* La **aplicación en sí**, que permite a los desarrolladores **exponer ciertas funcionalidades** y configurar las capacidades de la aplicación.
### Separación de UID
**A cada aplicación se le asigna un ID de usuario específico**. Esto se hace durante la instalación de la aplicación para que la aplicación solo pueda interactuar con archivos propiedad de su ID de usuario o archivos compartidos. Por lo tanto, solo la aplicación en sí, ciertos componentes del SO y el usuario root pueden acceder a los datos de las aplicaciones.
**Dos aplicaciones pueden configurarse para usar el mismo UID**. Esto puede ser útil para compartir información, pero si una de ellas se ve comprometida, los datos de ambas aplicaciones se verán comprometidos. Por eso, este comportamiento está **desaconsejado**.\
El **Sandbox de Aplicaciones de Android** permite ejecutar **cada aplicación** como un **proceso separado bajo un ID de usuario separado**. Cada proceso tiene su propia máquina virtual, por lo que el código de una aplicación se ejecuta de forma aislada de otras aplicaciones.\
A partir de Android 5.0(L), se aplica **SELinux**. Básicamente, SELinux deniega todas las interacciones entre procesos y luego crea políticas para **permitir solo las interacciones esperadas entre ellos**.
Cuando instalas una **aplicación y solicita permisos**, la aplicación está solicitando los permisos configurados en los elementos **`uses-permission`** en el archivo **AndroidManifest.xml**. El elemento **uses-permission** indica el nombre del permiso solicitado dentro del atributo **name**. También tiene el atributo **maxSdkVersion**, que deja de solicitar permisos en versiones superiores a la especificada.\
Ten en cuenta que las aplicaciones de Android no necesitan solicitar todos los permisos al principio, también pueden **solicitar permisos dinámicamente**, pero todos los permisos deben estar **declarados** en el manifiesto.
* **Firma**: Solo las **aplicaciones firmadas con el mismo certificado que la que** exporta el componente pueden obtener permiso. Este es el tipo de protección más fuerte.
* **FirmaOSystema**: Solo las **aplicaciones firmadas con el mismo certificado que la que** exporta el componente o **aplicaciones que se ejecutan con acceso de nivel de sistema** pueden obtener permisos.
Estas aplicaciones generalmente se encuentran en los directorios **`/system/app`** o **`/system/priv-app`** y algunas de ellas están **optimizadas** (es posible que ni siquiera encuentres el archivo `classes.dex`). Vale la pena verificar estas aplicaciones porque a veces se están **ejecutando con demasiados permisos** (como root).
Para obtener acceso root en un dispositivo Android físico, generalmente necesitas **explotar** 1 o 2 **vulnerabilidades** que suelen ser **específicas** para el **dispositivo** y la **versión**.\
Una vez que la explotación ha funcionado, generalmente se copia el binario `su` de Linux en una ubicación especificada en la variable de entorno PATH del usuario, como `/system/xbin`.
Una vez configurado el binario su, se utiliza otra aplicación de Android para interactuar con el binario `su` y **procesar solicitudes de acceso root** como **Superuser** y **SuperSU** (disponibles en Google Play Store).
Es posible **reemplazar el sistema operativo instalando un firmware personalizado**. Al hacer esto, es posible extender la utilidad de un dispositivo antiguo, evadir restricciones de software o acceder al código más reciente de Android.\
**OmniROM** y **LineageOS** son dos de los firmwares más populares para usar.
Tenga en cuenta que **no siempre es necesario rootear el dispositivo** para instalar un firmware personalizado. **Algunos fabricantes permiten** el desbloqueo de sus cargadores de arranque de manera documentada y segura.
Una vez que un dispositivo está rooteado, cualquier aplicación puede solicitar acceso como root. Si una aplicación maliciosa lo obtiene, tendrá acceso a casi todo y podrá dañar el teléfono.
## Fundamentos de las aplicaciones de Android <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>
Esta introducción se toma de [https://maddiestone.github.io/AndroidAppRE/app\_fundamentals.html](https://maddiestone.github.io/AndroidAppRE/app\_fundamentals.html)
* Las aplicaciones de Android están en formato de archivo _APK_. **APK es básicamente un archivo ZIP**. (Puede cambiar la extensión del archivo a .zip y usar unzip para abrirlo y ver su contenido).
* Código de bytes Dalvik para la aplicación en formato de archivo DEX. **Este es el código Java (o Kotlin)** compilado que la aplicación ejecutará de forma predeterminada.
* Cualquier otro archivo que pueda ser necesario para la aplicación.
* Aquí se pueden incluir bibliotecas nativas adicionales o archivos DEX. Esto puede suceder especialmente cuando los autores de malware quieren intentar "ocultar" código adicional, nativo o Dalvik, al no incluirlo en las ubicaciones predeterminadas.
* res/
* el directorio que contiene recursos no compilados en resources.arsc
La mayoría de las aplicaciones de Android están escritas en Java. Kotlin también es compatible e interoperable con Java. Para mayor facilidad, para el resto de este taller, cuando me refiero a "Java", puedes asumir que me refiero a "Java o Kotlin". **En lugar de que el código Java se ejecute en la Máquina Virtual de Java** (JVM) como las aplicaciones de escritorio, en Android, el **Java se compila al bytecode \_Dalvik Executable (DEX)**\_\* formato\*\*. Para versiones anteriores de Android, el bytecode era traducido por la máquina virtual Dalvik. Para versiones más recientes de Android, se utiliza el Tiempo de Ejecución de Android (ART).\
Si los desarrolladores escriben en Java y el código se compila a bytecode DEX, para ingeniería inversa, trabajamos en la dirección opuesta.\
**Smali es la versión legible por humanos del bytecode Dalvik**. Técnicamente, Smali y baksmali son los nombres de las herramientas (ensamblador y desensamblador, respectivamente), pero en Android, a menudo usamos el término "Smali" para referirnos a las instrucciones. Si has realizado ingeniería inversa o arquitectura de computadoras en código C/C++ compilado. **SMALI es como el lenguaje ensamblador: entre el código fuente de nivel superior y el bytecode**.
Encuentra las vulnerabilidades que más importan para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, realiza escaneos de amenazas proactivos, encuentra problemas en toda tu pila tecnológica, desde API hasta aplicaciones web y sistemas en la nube. [**Pruébalo gratis**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoy.
Los Intents son el principal medio por el cual las aplicaciones de Android se comunican entre sus componentes o con otras aplicaciones. Estos objetos de mensaje también pueden transportar datos entre aplicaciones o componentes, de manera similar a cómo se utilizan las solicitudes GET/POST en las comunicaciones HTTP.
Entonces, un Intent es básicamente un **mensaje que se pasa entre componentes**. Los Intents **pueden dirigirse** a componentes o aplicaciones específicas, **o pueden enviarse sin un destinatario específico**.\
Un filtro de Intent especifica los **tipos de Intent a los que una actividad, servicio o receptor de transmisiones puede responder**. Especifica lo que una actividad o servicio puede hacer y qué tipos de transmisiones puede manejar un receptor. Permite que el componente correspondiente reciba Intents del tipo declarado. Los filtros de Intents generalmente se **definen a través del archivo AndroidManifest.xml**. Para **receptor de transmisiones**, también es posible definirlos en **código**. Un filtro de Intent se define por su categoría, acción y filtros de datos. También puede contener metadatos adicionales.
En Android, una actividad/servicio/proveedor de contenido/receptor de transmisiones es **público** cuando **`exported`** se establece en **`true`**, pero un componente también es **público** si el **manifiesto especifica un filtro de Intent** para él. Sin embargo,\
los desarrolladores pueden **hacer que los componentes sean privados explícitamente** (independientemente de cualquier filtro de Intent)\
estableciendo el atributo \*\* `exported` en `false`\*\* para cada componente en el archivo del manifiesto.\
Los desarrolladores también pueden establecer el atributo **`permission`** para **requerir un permiso específico para acceder** al componente, restringiendo así el acceso al componente.
La **Acción** del intent previamente declarado es **ACTION\_SEND** y el **Extra** es un **Uri** de correo electrónico (el Extra es la información adicional que el intent espera).
El proceso de "resolución de intenciones" determina qué aplicación debe recibir cada mensaje. Este proceso considera el atributo de **prioridad**, que se puede establecer en la **declaración del intent-filter**, y **se seleccionará el que tenga la prioridad más alta**. Esta prioridad se puede establecer entre -1000 y 1000 y las aplicaciones pueden usar el valor `SYSTEM_HIGH_PRIORITY`. Si surge un **conflicto**, aparece una ventana de "selector" para que el **usuario pueda decidir**.
Estas permiten que otras aplicaciones **realicen acciones en nombre de tu aplicación**, utilizando la identidad y los permisos de tu aplicación. Al construir una Intención Pendiente, se debe **especificar una intención y la acción a realizar**. Si la **intención declarada no es explícita** (no declara qué intención puede llamarla), una **aplicación maliciosa podría realizar la acción declarada** en nombre de la aplicación víctima. Además, **si no se especifica una acción**, la aplicación maliciosa podrá realizar **cualquier acción en nombre de la víctima**.
A diferencia de las intenciones anteriores, que solo son recibidas por una aplicación, las intenciones de difusión **pueden ser recibidas por varias aplicaciones**. Sin embargo, a partir de la versión 14 de la API, es **posible especificar la aplicación que debe recibir** el mensaje utilizando Intent.setPackage.
Existen **dos tipos** de difusiones: **Normales** (asincrónicas) y **Ordenadas** (sincrónicas). El **orden** se basa en la **prioridad configurada dentro del receptor**. **Cada aplicación puede procesar, retransmitir o descartar la difusión**.
También se puede utilizar la función **`sendBroadcast`** del **`LocalBroadCastManager`** que asegura que el **mensaje nunca salga de la aplicación**. Utilizando esto, ni siquiera necesitarás exportar un componente receptor.
Si encuentras funciones que contienen la palabra "sticky" como **`sendStickyBroadcast`** o **`sendStickyBroadcastAsUser`**, **verifica el impacto e intenta eliminarlas**.
**Los enlaces profundos permiten activar una Intención a través de una URL**. Una aplicación puede declarar un **esquema de URL** dentro de una actividad para que cada vez que el dispositivo Android intente **acceder a una dirección utilizando ese esquema**, se llame a la actividad de la aplicación:
Significará que está esperando una URL que comienza con `example://gizmos`\
En este caso, podrías intentar abusar de la funcionalidad creando una página web con las siguientes cargas útiles. Intentará navegar a páginas arbitrarias e intentará ejecutar JS:
El **Lenguaje de Definición de Interfaz de Android** (AIDL) te permite definir la interfaz de programación en la que tanto el cliente como el servicio acuerdan para **comunicarse entre sí utilizando la comunicación entre procesos** (IPC). En Android, **un proceso normalmente no puede acceder a la memoria de otro proceso**. Por lo tanto, para comunicarse, necesitan descomponer sus objetos en primitivas que el **sistema operativo** pueda entender y transmitir los objetos a través de esa barrera por ti. El código para realizar esa transmisión es tedioso de escribir, por lo que Android lo maneja por ti con AIDL.
Los servicios que utilizan AIDL se denominan **Servicios Vinculados**. En la clase del servicio encontrarás el método **`onBind`**. Aquí es **donde comienza la interacción**, por lo que es la parte inicial del código que debes revisar en busca de posibles vulnerabilidades.
Un servicio vinculado es el servidor en una interfaz cliente-servidor. **Permite que los componentes (como las actividades) se vinculen al servicio, envíen solicitudes, reciban respuestas y realicen comunicación entre procesos** (IPC). Un servicio vinculado generalmente solo existe mientras sirve a otro componente de la aplicación y no se ejecuta indefinidamente en segundo plano.
Un Messenger es otro tipo de mecanismo de IPC. Dado que el **Messenger también es un "Servicio Vinculado"**, los datos enviados desde la aplicación cliente también se procesan a través del método `onBind`. Por lo tanto, la revisión del código debe comenzar en este método y debes buscar la invocación de funcionalidades sensibles o el manejo inseguro de datos.
Es raro encontrar una clase Binder invocada directamente, ya que es mucho más fácil usar AIDL (que abstrae la clase Binder). Sin embargo, es bueno saber que **Binder es un controlador de nivel de kernel que mueve datos de la memoria de un proceso a otro** ([https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8)).
Una **actividad de Android** es una pantalla de la interfaz de usuario de la aplicación de Android. De esa manera, una **actividad de Android** es muy similar a las ventanas en una aplicación de escritorio. Una aplicación de Android puede contener una o más actividades, lo que significa una o más pantallas.
La **actividad de inicio** es lo que la mayoría de las personas consideran como el **punto de entrada** de una aplicación de Android. La actividad de inicio es la actividad que se inicia cuando un usuario hace clic en el icono de una aplicación. Puedes determinar la actividad de inicio mirando el manifiesto de la aplicación. La actividad de inicio tendrá los siguientes intents MAIN y LAUNCHER enumerados.
Ten en cuenta que no todas las aplicaciones tendrán una actividad de inicio, especialmente las aplicaciones sin una interfaz de usuario. Ejemplos de aplicaciones sin una interfaz de usuario (y, por lo tanto, sin una actividad de inicio) son las aplicaciones preinstaladas que realizan servicios en segundo plano, como el correo de voz.
Las actividades pueden ser exportadas permitiendo que otros procesos en el dispositivo inicien la actividad. Por defecto, no están exportadas, pero puedes exportarlas configurando:
Ten en cuenta que la capacidad de **burlar las protecciones de actividad no siempre es una vulnerabilidad**, debes verificar a qué datos has obtenido acceso.
Además, **algunas actividades devuelven datos a un llamador**. En estos escenarios, debes buscar el método **`setResult`** y verificar los datos que se pasan al parámetro Intent. Si son datos sensibles, puede haber una vulnerabilidad de filtración de información y es explotable con aplicaciones capaces de comunicarse con la actividad.
Las aplicaciones de Android pueden definir una **subclase** de [Application](https://developer.android.com/reference/android/app/Application). Las aplicaciones pueden, pero no tienen que definir una subclase personalizada de Application. Si una aplicación de Android define una subclase de Application, **esta clase se instancia antes que cualquier otra clase en la aplicación**.
[Los servicios](https://developer.android.com/guide/components/services) **se ejecutan en segundo plano sin una interfaz de usuario**. Se utilizan para realizar **procesos de larga duración, incluso si el usuario comienza a usar una aplicación diferente**.
Hay muchas formas en las que se pueden iniciar y, por lo tanto, son un punto de entrada para las aplicaciones. La forma predeterminada en que un servicio puede iniciarse como punto de entrada a una aplicación es a través de **Intents**.
Cuando se llama al método **`startService`** para iniciar un servicio, se ejecuta el método **`onStart`** en el servicio. Se ejecutará indefinidamente hasta que se llame al método **`stopService`**. Si el servicio solo se necesita mientras el cliente está conectado, el cliente debe "vincularse" a él utilizando el método **`bindService`**.
Por ejemplo, un servicio podría reproducir música en segundo plano mientras el usuario está en una aplicación diferente, o podría obtener datos a través de la red sin bloquear la interacción del usuario con una actividad.
Un **servicio puede ser exportado, lo que permite que otros procesos en el dispositivo inicien el servicio**. Por defecto, los servicios no están exportados, pero se pueden configurar en el Manifiesto:
Las difusiones se pueden considerar como un sistema de mensajería y los **receptores de difusión son los oyentes**. Si una aplicación ha registrado un receptor para una difusión específica, el código de ese receptor se ejecuta cuando el sistema envía la difusión. Tenga en cuenta que en este caso **varias aplicaciones pueden recibir el mismo mensaje**.
Hay **2 formas** en las que una aplicación puede **registrar un receptor**: en el **manifiesto de la aplicación o registrado dinámicamente** en el código de la aplicación utilizando la llamada de API **`registerReceiver`**. En el manifiesto, puede limitar las difusiones que acepta mediante el **uso de permisos dentro del elemento receptor**. Cuando se define de forma dinámica, puede **pasar el permiso al método `registerReceiver`**.
En ambos casos, para registrar el receptor, se establecen los **filtros de intención para el receptor**. Estos filtros de intención son las difusiones que deben activar el receptor.
Cuando se envían las difusiones específicas para las que el receptor está registrado, se **ejecuta** el método **`onReceive`** en la clase BroadcastReceiver.
Las difusiones pueden ser **asincrónicas** (cada receptor las recibe) o **sincrónicas** (la difusión se recibe de manera ordenada según la prioridad establecida para recibirla).
Tenga en cuenta que las difusiones ordenadas pueden descartar la intención recibida o incluso modificarla utilizando uno de los métodos setter. Por lo tanto, los **receptores deben validar los datos**.
Los proveedores de contenido son la forma en que las aplicaciones comparten datos estructurados, como bases de datos relacionales. Por lo tanto, es muy importante utilizar **permisos** y establecer el nivel de protección adecuado para protegerlos.\
Los proveedores de contenido pueden utilizar los atributos **`readPermission`** y **`writePermission`** para especificar qué permisos debe tener una aplicación. **Estos permisos tienen prioridad sobre el atributo de permiso**.\
Además, también pueden **permitir excepciones temporales** estableciendo **`grantUriPermission`** en true y luego configurando los parámetros adecuados en el elemento **`grant-uri-permission`** dentro del elemento proveedor en el archivo de manifiesto.
* Puede almacenar los datos en el sistema de archivos, una base de datos SQLite, en la web o en cualquier otra ubicación de almacenamiento persistente a la que su aplicación pueda acceder.
* A través del proveedor de contenido, otras aplicaciones pueden consultar o incluso modificar los datos (si el proveedor de contenido lo permite).
* El proveedor de contenido es útil en casos en los que una aplicación desea compartir datos con otra aplicación.
* Es muy similar a las bases de datos y tiene cuatro métodos.
Este es un tipo de proveedor de contenido que **compartirá archivos** desde una carpeta. Puede declarar un proveedor de archivos de la siguiente manera:
Ten en cuenta que la configuración `android:resource="@xml/filepaths"` indica que el archivo _res/xml/filepaths.xml_ contiene la configuración de **qué carpetas** va a **compartir** este **FileProvider**. Este es un ejemplo de cómo indicar la compartición de una carpeta en ese archivo:
Compartir algo como **`path="."`** podría ser **peligroso** incluso si el proveedor no está exportado, si hay alguna otra vulnerabilidad en alguna parte del código que intente acceder a este proveedor.\
Puedes **acceder** a una **imagen** dentro de esa carpeta con `content://com.example.myapp.fileprovider/myimages/default_image.jpg`
El elemento `<paths>` puede tener varios hijos, cada uno especificando un directorio diferente para compartir. Además del elemento **`<files-path>`**, puedes usar el elemento **`<external-path>`** para compartir directorios en el **almacenamiento externo**, y el elemento **`<cache-path>`** para compartir directorios en tu **directorio de caché interno**.\
[Para obtener más información sobre los atributos específicos de los proveedores de archivos, ve aquí.](https://developer.android.com/reference/androidx/core/content/FileProvider)
[Más información sobre FileProviders aquí](https://developer.android.com/training/secure-file-sharing/setup-sharing).
El contenido de las WebViews puede provenir de sitios remotos o pueden ser archivos incluidos en la aplicación.\
Las WebViews son **vulnerables a las mismas vulnerabilidades que afectan a cualquier navegador web**. Sin embargo, hay algunas **configuraciones** que pueden ser útiles para **limitar** la **superficie de ataque**.
* El **WebViewClient**, más adecuado para la representación de HTML simple. Esto no ejecutará la función de alerta de JS. Por lo tanto, las pruebas de XSS que utilicen esa función serán inválidas.
Para cargar una URL o un archivo, es posible utilizar las funciones **`loadUrl`**, **`loadData`** o **`loadDataWithBaseURL`**. **Es importante acceder solo a URLs sanitizadas.**\
Por ejemplo, la ejecución de código JS se puede desactivar utilizando el método **`setJavaScriptEnabled`** con el valor **`false`**. Esto eliminará la posibilidad de XSS y otras vulnerabilidades relacionadas con JS.
La funcionalidad de JavaScript "**Bridge**" **inyecta objetos Java en un WebView haciéndolos accesibles desde JS**. A partir de Android 4.2, los métodos deben estar anotados con **`@JavascriptInterface`** para que sean accesibles desde JavaScript.
Si se pasa **`true`** a **`setAllowContentAccess`**, las WebViews podrán acceder a los Proveedores de Contenido a través del esquema **`content://`**. Esto obviamente plantea un riesgo de seguridad. Ten en cuenta que si se otorga este acceso, es muy importante **asegurarse** de que la URL **`content://`** sea **segura**.
De forma predeterminada, los archivos locales pueden ser accedidos por las WebViews a través de las URL file://, pero hay varias formas de evitar este comportamiento:
* Pasar **`false`** a **`setAllowFileAccess`**, evita el acceso al sistema de archivos con la excepción de los activos a través de `file:///android_asset`_y_`file:///android_res`. Estas rutas deben utilizarse solo para datos no sensibles (como imágenes), por lo que esto debería ser seguro.
* Android requiere que **todas las aplicaciones estén firmadas digitalmente con un certificado** antes de que puedan ser instaladas. Android utiliza este certificado para identificar al autor de una aplicación.
* Para ejecutar una aplicación en el dispositivo, debe estar firmada. Cuando se instala una aplicación en un dispositivo, el **administrador de paquetes verifica** si la aplicación ha sido firmada correctamente con el certificado del archivo APK o no.
* La firma de la aplicación garantiza que una aplicación no pueda acceder a ninguna otra aplicación excepto a través de IPC bien definido y también que se pase sin modificaciones al dispositivo.
* Android 4.2 y versiones posteriores admiten la verificación de aplicaciones. Los usuarios pueden optar por habilitar "Verificar aplicaciones" y hacer que las aplicaciones sean evaluadas por un verificador de aplicaciones antes de la instalación.
* La verificación de aplicaciones puede alertar al usuario si intentan instalar una aplicación que podría ser dañina; si una aplicación es especialmente mala, puede bloquear la instalación.
MDM o Mobile Device Management son suites de software que se utilizan para **garantizar un control y requisitos de seguridad** sobre dispositivos móviles. Estas suites utilizan las características denominadas API de Administración de Dispositivos y requieren la instalación de una aplicación de Android.
Generalmente, las soluciones de MDM realizan funciones como hacer cumplir políticas de contraseñas, forzar el cifrado del almacenamiento y permitir el borrado remoto de los datos del dispositivo.
Encuentra las vulnerabilidades que más importan para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, realiza escaneos de amenazas proactivas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. [**Pruébalo gratis**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoy mismo.
* ¿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)!
* 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 PR al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
