<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen** oder **HackTricks als PDF herunterladen** möchten, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
**Jede Anwendung erhält eine spezifische Benutzer-ID**. Dies wird während der Installation der App durchgeführt, damit **die App nur mit Dateien interagieren kann, die ihrer Benutzer-ID gehören oder gemeinsam genutzte** Dateien. Daher können nur die App selbst, bestimmte Komponenten des Betriebssystems und der Root-Benutzer auf die Daten der Apps zugreifen.
**Zwei Anwendungen können so konfiguriert werden, dass sie dieselbe UID verwenden**. Dies kann nützlich sein, um Informationen zu teilen, aber wenn eine von ihnen kompromittiert ist, werden die Daten beider Anwendungen kompromittiert. Deshalb wird dieses Verhalten **nicht empfohlen**.\
Das **Android Application Sandbox** ermöglicht es, **jede Anwendung** als **eigenen Prozess unter einer separaten Benutzer-ID** auszuführen. Jeder Prozess hat seine eigene virtuelle Maschine, sodass der Code einer App isoliert von anderen Apps ausgeführt wird.\
Ab Android 5.0(L) wird **SELinux** durchgesetzt. Grundsätzlich hat SELinux alle Prozessinteraktionen verweigert und dann Richtlinien erstellt, um **nur die erwarteten Interaktionen zwischen ihnen zuzulassen**.
Wenn Sie eine **App installieren und um Berechtigungen bitten**, fordert die App die in den **`uses-permission`**-Elementen in der **AndroidManifest.xml**-Datei konfigurierten Berechtigungen an. Das **uses-permission**-Element gibt den Namen der angeforderten Berechtigung im **name**-**Attribut** an. Es hat auch das **maxSdkVersion**-Attribut, das das Anfordern von Berechtigungen auf Versionen höher als die angegebene stoppt.\
Beachten Sie, dass Android-Anwendungen nicht alle Berechtigungen von Anfang an anfordern müssen, sie können auch **Berechtigungen dynamisch anfordern**, aber alle Berechtigungen müssen im **Manifest deklariert** sein.
* **Gefährlich**: Gibt an, dass die Berechtigung der anfordernden Anwendung einen **erhöhten Zugriff** gewährt. **Benutzer werden aufgefordert, sie zu genehmigen**.
* **Signature**: Nur **Apps, die vom selben Zertifikat wie das exportierende** Komponente signiert sind, können Berechtigungen erhalten. Dies ist die stärkste Schutzart.
* **SignatureOrSystem**: Nur **Apps, die vom selben Zertifikat wie das exportierende** Komponente signiert sind oder **Apps, die mit Systemzugriff ausgeführt werden**, können Berechtigungen erhalten.
Diese Apps befinden sich in der Regel in den Verzeichnissen **`/system/app`** oder **`/system/priv-app`** und einige von ihnen sind **optimiert** (Sie finden möglicherweise nicht einmal die Datei `classes.dex`). Diese Anwendungen sind es wert, überprüft zu werden, da sie manchmal mit zu vielen Berechtigungen (als Root) **ausgeführt werden**.
Um Root-Zugriff auf ein physisches Android-Gerät zu erhalten, müssen Sie in der Regel 1 oder 2 **Schwachstellen ausnutzen**, die normalerweise **spezifisch** für das **Gerät** und die **Version** sind.\
Sobald das su-Binär konfiguriert ist, wird eine andere Android-App verwendet, um mit dem `su`-Binär zu interagieren und **Anfragen für Root-Zugriff zu verarbeiten** wie **Superuser** und **SuperSU** (erhältlich im Google Play Store).
Es ist möglich, das Betriebssystem zu ersetzen, indem Sie eine benutzerdefinierte Firmware installieren. Dadurch ist es möglich, die Nützlichkeit eines alten Geräts zu erweitern, Softwarebeschränkungen zu umgehen oder Zugriff auf den neuesten Android-Code zu erhalten.\
Beachten Sie, dass **nicht immer eine Root-Berechtigung erforderlich ist**, um eine benutzerdefinierte Firmware zu installieren. **Einige Hersteller erlauben** das Entsperren ihrer Bootloader auf dokumentierte und sichere Weise.
Sobald ein Gerät gerootet ist, kann jede App Root-Zugriff anfordern. Wenn eine bösartige Anwendung dies erhält, kann sie auf fast alles zugreifen und das Telefon beschädigen.
## Grundlagen von Android-Anwendungen <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>
- Das Format von Android-Anwendungen wird als _APK-Dateiformat_ bezeichnet. Es handelt sich im Wesentlichen um eine **ZIP-Datei** (durch Umbenennen der Dateierweiterung in .zip können die Inhalte extrahiert und angezeigt werden).
- Enthält Dalvik-Bytecode, der den standardmäßig ausgeführten kompilierten Java- (oder Kotlin-)Code der Anwendung darstellt.
- lib/
- Enthält native Bibliotheken, aufgeteilt nach CPU-Architektur in Unterverzeichnissen.
-`armeabi`: Code für ARM-basierte Prozessoren
-`armeabi-v7a`: Code für ARMv7 und höhere Prozessoren
-`x86`: Code für X86-Prozessoren
-`mips`: Code nur für MIPS-Prozessoren
- assets/
- Speichert verschiedene Dateien, die von der App benötigt werden, möglicherweise einschließlich zusätzlicher nativer Bibliotheken oder DEX-Dateien, die manchmal von Malware-Autoren verwendet werden, um zusätzlichen Code zu verbergen.
- res/
- Enthält Ressourcen, die nicht in resources.arsc kompiliert sind.
In der Android-Entwicklung wird **Java oder Kotlin** zur Erstellung von Apps verwendet. Anstatt wie bei Desktop-Apps den JVM zu verwenden, kompiliert Android diesen Code in **Dalvik Executable (DEX) Bytecode**. Früher verarbeitete die Dalvik Virtual Machine diesen Bytecode, aber jetzt übernimmt in neueren Android-Versionen die Android-Laufzeitumgebung (ART).
Für Reverse Engineering wird **Smali** entscheidend. Es ist die menschenlesbare Version des DEX-Bytecodes und fungiert wie eine Assemblersprache, indem es den Quellcode in Bytecode-Anweisungen übersetzt. Smali und baksmali beziehen sich in diesem Kontext auf die Assemblierungs- und Disassemblierungstools.
Intents sind das Hauptmittel, mit dem Android-Apps zwischen ihren Komponenten oder mit anderen Apps kommunizieren. Diese Nachrichtenobjekte können auch Daten zwischen Apps oder Komponenten übertragen, ähnlich wie GET/POST-Anfragen bei HTTP-Kommunikationen verwendet werden.
Ein Intent ist also im Grunde genommen eine **Nachricht, die zwischen Komponenten übermittelt wird**. Intents **können an bestimmte Komponenten oder Apps gerichtet sein** oder ohne einen spezifischen Empfänger gesendet werden.\
**Intent-Filter** definieren **wie eine Aktivität, ein Dienst oder ein Broadcast-Empfänger mit verschiedenen Arten von Intents interagieren kann**. Im Wesentlichen beschreiben sie die Fähigkeiten dieser Komponenten, wie z. B. welche Aktionen sie ausführen können oder welche Arten von Broadcasts sie verarbeiten können. Der primäre Ort, um diese Filter zu deklarieren, ist die **AndroidManifest.xml-Datei**, obwohl es auch möglich ist, sie für Broadcast-Empfänger zu codieren.
Intent-Filter bestehen aus Kategorien, Aktionen und Datenfiltern, wobei die Möglichkeit besteht, zusätzliche Metadaten einzuschließen. Diese Konfiguration ermöglicht es Komponenten, spezifische Intents zu verarbeiten, die den deklarierten Kriterien entsprechen.
Ein entscheidender Aspekt von Android-Komponenten (Aktivitäten/Dienste/Content-Provider/Broadcast-Empfänger) ist ihre Sichtbarkeit oder **öffentlicher Status**. Eine Komponente gilt als öffentlich und kann mit anderen Apps interagieren, wenn sie mit einem Wert von **`true`** als **`exportiert`** markiert ist oder wenn für sie ein Intent-Filter im Manifest deklariert ist. Entwickler haben jedoch die Möglichkeit, diese Komponenten explizit privat zu halten, um sicherzustellen, dass sie nicht unbeabsichtigt mit anderen Apps interagieren. Dies wird erreicht, indem das Attribut **`exportiert`** in ihren Manifestdefinitionen auf **`false`** gesetzt wird.
Darüber hinaus haben Entwickler die Möglichkeit, den Zugriff auf diese Komponenten weiter abzusichern, indem sie spezifische Berechtigungen verlangen. Das Attribut **`permission`** kann festgelegt werden, um durchzusetzen, dass nur Apps mit der festgelegten Berechtigung auf die Komponente zugreifen können, was eine zusätzliche Sicherheitsebene und Kontrolle darüber bietet, wer mit ihr interagieren kann.
Die **Aktion** des zuvor deklarierten Intents ist **ACTION\_SEND** und das **Extra** ist eine mailto-**Uri** (das Extra ist die zusätzliche Information, die der Intent erwartet).
Der "Intent-Auflösungsprozess" bestimmt, welche App jede Nachricht erhalten soll. Dieser Prozess berücksichtigt das **Prioritätsattribut**, das in der **Intent-Filter-Deklaration** festgelegt werden kann, und **die mit der höheren Priorität wird ausgewählt**. Diese Priorität kann zwischen -1000 und 1000 festgelegt werden, und Anwendungen können den Wert `SYSTEM_HIGH_PRIORITY` verwenden. Bei einem **Konflikt** erscheint ein "Auswahlfenster", damit der **Benutzer entscheiden kann**.
Diese ermöglichen es anderen Anwendungen, **im Namen Ihrer Anwendung Aktionen auszuführen**, unter Verwendung der Identität und Berechtigungen Ihrer App. Beim Erstellen eines ausstehenden Intents sollte **ein Intent und die auszuführende Aktion angegeben werden**. Wenn der **deklarierte Intent nicht explizit ist** (nicht angibt, welcher Intent ihn aufrufen kann), könnte eine **bösartige Anwendung die deklarierte Aktion** im Namen der Opfer-App ausführen. Darüber hinaus, **wenn keine Aktion angegeben ist**, kann die bösartige App **beliebige Aktionen im Namen des Opfers** ausführen.
Im Gegensatz zu den vorherigen Intents, die nur von einer App empfangen werden, können Broadcast-Intents **von mehreren Apps empfangen werden**. Ab API-Version 14 ist es **möglich, die App anzugeben, die die Nachricht empfangen soll**, indem Intent.setPackage verwendet wird.
Es gibt **zwei Arten** von Broadcasts: **Normal** (asynchron) und **Geordnet** (synchron). Die **Reihenfolge** basiert auf der **konfigurierten Priorität innerhalb des Empfängerelements**. **Jede App kann den Broadcast verarbeiten, weiterleiten oder verwerfen**.
Sie könnten auch die Funktion **`sendBroadcast`** aus dem **`LocalBroadCastManager`** verwenden, um sicherzustellen, dass die **Nachricht die App nie verlässt**. Dadurch müssen Sie nicht einmal einen Empfänger exportieren.
Wenn Sie Funktionen finden, die das Wort "sticky" enthalten, wie **`sendStickyBroadcast`** oder **`sendStickyBroadcastAsUser`**, **überprüfen Sie die Auswirkungen und versuchen Sie, sie zu entfernen**.
In Android-Anwendungen werden **Deep Links** verwendet, um eine Aktion (Intent) direkt über eine URL zu initiieren. Dies wird durch Deklarieren eines spezifischen **URL-Schemas** innerhalb einer Aktivität erreicht. Wenn ein Android-Gerät versucht, **auf eine URL mit diesem Schema zuzugreifen**, wird die angegebene Aktivität innerhalb der Anwendung gestartet.
Um den **Code zu finden, der in der App ausgeführt wird**, gehen Sie zur Aktivität, die durch den Deeplink aufgerufen wird, und suchen Sie die Funktion **`onNewIntent`**.
Die **Android Interface Definition Language (AIDL)** ist darauf ausgelegt, die Kommunikation zwischen Client und Service in Android-Anwendungen durch **Interprozesskommunikation** (IPC) zu erleichtern. Da der direkte Zugriff auf den Speicher eines anderen Prozesses auf Android nicht zulässig ist, vereinfacht AIDL den Prozess, indem Objekte in ein vom Betriebssystem verstandenes Format umgewandelt werden, wodurch die Kommunikation zwischen verschiedenen Prozessen erleichtert wird.
- **Gebundene Dienste**: Diese Dienste nutzen AIDL für IPC, ermöglichen es Aktivitäten oder Komponenten, sich an einen Dienst zu binden, Anfragen zu stellen und Antworten zu erhalten. Die Methode `onBind` in der Klasse des Dienstes ist entscheidend für die Initiierung der Interaktion und markiert sie als einen wichtigen Bereich für die Sicherheitsüberprüfung auf der Suche nach Schwachstellen.
- **Messenger**: Als gebundener Dienst erleichtert Messenger die IPC mit dem Schwerpunkt auf der Verarbeitung von Daten durch die Methode `onBind`. Es ist wichtig, diese Methode genau auf unsichere Datenverarbeitung oder die Ausführung sensibler Funktionen zu überprüfen.
- **Binder**: Obwohl die direkte Verwendung der Binder-Klasse aufgrund der Abstraktion von AIDL weniger häufig ist, ist es nützlich zu verstehen, dass Binder als Treiber auf Kernel-Ebene fungiert und den Datentransfer zwischen den Speicherbereichen verschiedener Prozesse erleichtert. Zur weiteren Vertiefung steht ein Ressource unter [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8) zur Verfügung.
In Android-Apps sind **Aktivitäten** wie Bildschirme, die verschiedene Teile der Benutzeroberfläche der App anzeigen. Eine App kann viele Aktivitäten haben, von denen jede einen einzigartigen Bildschirm für den Benutzer darstellt.
Die **Startaktivität** ist das Haupttor zu einer App, das gestartet wird, wenn Sie auf das Symbol der App tippen. Sie ist in der Manifestdatei der App mit spezifischen MAIN- und LAUNCHER-Intents definiert:
Aktivitäten können anderen Apps oder Prozessen zur Verfügung gestellt werden, indem sie im Manifest als "exportiert" markiert werden. Diese Einstellung ermöglicht es anderen Apps, diese Aktivität zu starten:
Jedoch ist der Zugriff auf eine Aktivität von einer anderen App nicht immer ein Sicherheitsrisiko. Die Sorge entsteht, wenn sensible Daten unsachgemäß geteilt werden, was zu Informationslecks führen könnte.
Der Lebenszyklus einer Aktivität **beginnt mit der Methode onCreate**, die die Benutzeroberfläche einrichtet und die Aktivität auf die Interaktion mit dem Benutzer vorbereitet.
In der Android-Entwicklung hat eine App die Möglichkeit, eine **Teilklasse** der [Application](https://developer.android.com/reference/android/app/Application)-Klasse zu erstellen, obwohl dies nicht obligatorisch ist. Wenn eine solche Teilklasse definiert ist, wird sie als erste Klasse innerhalb der App instanziiert. Die Methode **`attachBaseContext`**, wenn sie in dieser Teilklasse implementiert ist, wird vor der **`onCreate`**-Methode ausgeführt. Diese Einrichtung ermöglicht eine frühe Initialisierung, bevor der Rest der Anwendung startet.
[Dienste](https://developer.android.com/guide/components/services) sind **Hintergrundoperationen**, die in der Lage sind, Aufgaben ohne Benutzeroberfläche auszuführen. Diese Aufgaben können auch dann weiterlaufen, wenn Benutzer zu anderen Anwendungen wechseln, wodurch Dienste für **lang laufende Operationen** unerlässlich sind.
Dienste sind vielseitig einsetzbar; sie können auf verschiedene Arten initiiert werden, wobei **Intents** die primäre Methode zum Starten sind, als Einstiegspunkt einer Anwendung. Sobald ein Dienst mit der Methode `startService` gestartet wird, wird seine `onStart`-Methode aktiviert und läuft weiter, bis die `stopService`-Methode explizit aufgerufen wird. Alternativ, wenn die Rolle eines Dienstes von einer aktiven Client-Verbindung abhängt, wird die Methode `bindService` verwendet, um den Client mit dem Dienst zu verbinden, wobei die `onBind`-Methode für den Datenaustausch verwendet wird.
Eine interessante Anwendung von Diensten umfasst die Wiedergabe von Hintergrundmusik oder das Abrufen von Netzwerkdaten, ohne die Interaktion des Benutzers mit einer App zu beeinträchtigen. Darüber hinaus können Dienste für andere Prozesse auf demselben Gerät über **Exportieren** zugänglich gemacht werden. Dies ist nicht das Standardverhalten und erfordert eine explizite Konfiguration in der Android-Manifestdatei:
**Broadcast-Empfänger** fungieren als Zuhörer in einem Nachrichtensystem und ermöglichen es mehreren Anwendungen, auf dieselben Nachrichten des Systems zu reagieren. Eine App kann einen **Empfänger registrieren** auf **zwei Hauptarten**: über das **Manifest** der App oder **dynamisch** im Code der App über die **`registerReceiver`** API. Im Manifest werden Broadcasts mit Berechtigungen gefiltert, während dynamisch registrierte Empfänger auch Berechtigungen bei der Registrierung angeben können.
**Intent-Filter** sind in beiden Registrierungsmethoden entscheidend und bestimmen, welche Broadcasts den Empfänger auslösen. Sobald ein übereinstimmender Broadcast gesendet wird, wird die Methode **`onReceive`** des Empfängers aufgerufen, sodass die App entsprechend reagieren kann, z. B. das Verhalten anpassen, um auf eine Benachrichtigung über einen niedrigen Akkustand zu reagieren.
Broadcasts können entweder **asynchron** sein und alle Empfänger ohne Reihenfolge erreichen oder **synchron**, wobei Empfänger den Broadcast basierend auf festgelegten Prioritäten erhalten. Es ist jedoch wichtig zu beachten, dass jede App sich selbst priorisieren kann, um einen Broadcast abzufangen.
Um die Funktionalität eines Empfängers zu verstehen, suchen Sie nach der Methode **`onReceive`** innerhalb seiner Klasse. Der Code dieser Methode kann das empfangene Intent manipulieren, was die Notwendigkeit der Datenvalidierung durch Empfänger hervorhebt, insbesondere bei **Geordneten Broadcasts**, die das Intent ändern oder verwerfen können.
**Content Provider** sind für das **Teilen strukturierter Daten** zwischen Apps unerlässlich und betonen die Bedeutung der Implementierung von **Berechtigungen**, um die Datensicherheit zu gewährleisten. Sie ermöglichen es Apps, auf Daten aus verschiedenen Quellen zuzugreifen, einschließlich Datenbanken, Dateisystemen oder dem Web. Spezifische Berechtigungen wie **`readPermission`** und **`writePermission`** sind entscheidend für die Kontrolle des Zugriffs. Darüber hinaus kann temporärer Zugriff durch **`grantUriPermission`**-Einstellungen im Manifest der App gewährt werden, wobei Attribute wie `path`, `pathPrefix` und `pathPattern` für eine detaillierte Zugriffskontrolle genutzt werden.
Die Eingabevalidierung ist entscheidend, um Sicherheitslücken wie SQL-Injektionen zu verhindern. Content Provider unterstützen grundlegende Operationen: `insert()`, `update()`, `delete()` und `query()`, die die Datenmanipulation und den Austausch zwischen Anwendungen erleichtern.
**FileProvider**, ein spezialisierter Content Provider, konzentriert sich auf das sichere Teilen von Dateien. Er wird im Manifest der App mit spezifischen Attributen definiert, um den Zugriff auf Ordner zu kontrollieren, die durch `android:exported` und `android:resource` auf Ordnerkonfigurationen verweisen. Es wird empfohlen, Vorsicht walten zu lassen, wenn Verzeichnisse freigegeben werden, um eine versehentliche Offenlegung sensibler Daten zu vermeiden.
WebViews sind wie **Mini-Webbrowser** innerhalb von Android-Apps, die Inhalte entweder aus dem Web oder aus lokalen Dateien abrufen. Sie sind ähnlichen Risiken wie reguläre Browser ausgesetzt, aber es gibt Möglichkeiten, diese Risiken durch spezifische **Einstellungen zu reduzieren**.
- **WebViewClient** eignet sich gut für grundlegendes HTML, unterstützt jedoch nicht die JavaScript-Alert-Funktion, was sich darauf auswirken kann, wie XSS-Angriffe getestet werden können.
Für das Laden von Inhalten stehen Methoden wie ````loadUrl````, ````loadData```` und ````loadDataWithBaseURL```` zur Verfügung. Es ist entscheidend sicherzustellen, dass diese URLs oder Dateien **sicher zu verwenden** sind. Sicherheitseinstellungen können über die Klasse ````WebSettings```` verwaltet werden. Beispielsweise kann das Deaktivieren von JavaScript mit ````setJavaScriptEnabled(false)```` XSS-Angriffe verhindern.
Die JavaScript-"Bridge" ermöglicht es Java-Objekten, mit JavaScript zu interagieren, wobei Methoden ab Android 4.2 mit ````@JavascriptInterface```` markiert werden müssen, um Sicherheit zu gewährleisten.
Das Zulassen des Zugriffs auf Inhalte (````setAllowContentAccess(true)````) ermöglicht es WebViews, auf Inhaltsanbieter zuzugreifen, was ein Risiko darstellen kann, es sei denn, die Inhalts-URLs sind als sicher verifiziert.
- Das Deaktivieren des Dateizugriffs (````setAllowFileAccess(false)````) beschränkt den Zugriff auf das Dateisystem, mit Ausnahmen für bestimmte Ressourcen, um sicherzustellen, dass sie nur für nicht-sensitive Inhalte verwendet werden.
- **Digitale Signierung** ist ein Muss für Android-Apps, um sicherzustellen, dass sie **authentisch autorisiert** sind, bevor sie installiert werden. Dieser Prozess verwendet ein Zertifikat zur App-Identifizierung und muss vom Paketmanager des Geräts bei der Installation überprüft werden. Apps können **selbst signiert oder von einer externen CA zertifiziert** sein, um unbefugten Zugriff zu verhindern und sicherzustellen, dass die App während der Bereitstellung auf dem Gerät unverändert bleibt.
- Ab **Android 4.2** ermöglicht eine Funktion namens **Apps überprüfen** Benutzern, Apps vor der Installation auf Sicherheit zu überprüfen. Dieser **Verifizierungsprozess** kann Benutzer vor potenziell schädlichen Apps warnen oder sogar die Installation besonders bösartiger Apps verhindern, um die Sicherheit der Benutzer zu erhöhen.
- **MDM-Lösungen** bieten **Überwachung und Sicherheit** für mobile Geräte über die **Device Administration API**. Sie erfordern die Installation einer Android-App, um mobile Geräte effektiv zu verwalten und zu sichern. Zu den Hauptfunktionen gehören die **Durchsetzung von Kennwortrichtlinien**, die **Verpflichtung zur Speicherung von Verschlüsselung** und die **Ermöglichung des Remote-Datenlöschens**, um umfassende Kontrolle und Sicherheit über mobile Geräte zu gewährleisten.
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositorys einreichen.
