Agartha

Injection de Payloads (LFI, RCE, SQLi, avec BCheck optionnel), Problèmes d'authentification (Matrice d'accès, HTTP 403), Copier en JavaScript et Bambdas

Agartha est spécialisé dans la génération avancée de payloads et l'évaluation des contrôles d'accès. Il identifie avec précision les vulnérabilités liées aux attaques par injection et aux problèmes d'authentification/authorisation. Le générateur de payloads dynamique crée des wordlists étendues pour divers vecteurs d'injection, notamment l'injection SQL, l'inclusion de fichiers locaux (LFI) et l'exécution de code à distance (RCE). De plus, l'extension construit une matrice d'accès utilisateur complète, révélant les violations d'accès potentielles et les chemins d'escalade de privilèges. Elle aide également à effectuer des vérifications de contournement HTTP 403, mettant en lumière les erreurs de configuration d'authentification. De plus, elle peut convertir des requêtes HTTP en code JavaScript pour aider à creuser davantage les problèmes XSS.

En résumé :

• Générateur de Payloads : Il construit dynamiquement des wordlists complètes pour les attaques par injection, incorporant divers caractères d'encodage et d'échappement pour améliorer l'efficacité des tests de sécurité. Ces wordlists couvrent des vulnérabilités critiques telles que l'injection SQL (SQLi), l'inclusion de fichiers locaux (LFI), l'exécution de code à distance (RCE), et prennent désormais également en charge la syntaxe BCheck pour une intégration transparente avec le framework BCheck de Burp.
  • Inclusion de fichiers locaux, Path Traversal: Il aide à identifier les vulnérabilités permettant aux attaquants d'accéder aux fichiers du système de fichiers du serveur.
  • Exécution de code à distance, Injection de commandes: Il vise à détecter les points d'injection de commandes potentiels, permettant des tests robustes pour les vulnérabilités d'exécution de code.
  • Injection SQL: Il assiste à la découverte des vulnérabilités d'injection SQL, y compris les requêtes empilées, les injections booléennes, les injections basées sur UNION et les injections temporelles.
• Matrice d'authentification : En construisant une matrice d'accès complète, l'outil révèle les violations d'accès potentielles et les chemins d'escalade de privilèges. Cette fonctionnalité améliore la posture de sécurité en traitant les problèmes d'authentification et d'authorisation.
  • Vous pouvez utiliser la fonctionnalité Spider web pour générer une sitemap/une liste d'URL, et il explorera automatiquement les liens visibles depuis la session de l'utilisateur.
• Contournement 403 : Il vise à contourner les restrictions d'accès courantes, telles que les réponses HTTP 403 Forbidden. Il utilise des techniques comme la manipulation d'URL et la modification des en-têtes de requête pour contourner les limitations mises en place.
• Copier en JavaScript : Il convertit les requêtes HTTP en code JavaScript pour une exploitation XSS plus poussée et plus encore.
• Générateur de scripts Bambdas : La fonctionnalité prend en charge la génération automatique de scripts compatibles Bambdas à partir d'une entrée utilisateur. Elle élimine le besoin de codage manuel, permettant une création plus rapide de scripts personnalisés et rationalisant l'intégration avec le moteur Bambdas.
  
  

Voici un petit tutoriel sur la façon d'utiliser.

Installation

Vous devez d'abord télécharger le fichier 'Jython' et configurer votre environnement :

• Menu Burp > Extender > Options > Python Environment > Localiser le fichier jar autonome Jython.

Vous pouvez installer Agartha via le magasin officiel :

• Menu Burp > Extender > BApp Store > Agartha

Ou pour une installation manuelle :

• Menu Burp > Extender > Extensions > Add > Extension Type : Python > Extension file(.py) : Sélectionner le fichier 'Agartha.py'

Ensuite, vous verrez l'onglet 'Agartha' dans la fenêtre principale et il sera également enregistré dans le clic droit, sous :

• 'Extensions > Agartha', avec trois sous-menus :

  • 'Auth Matrix'

  • '403 Bypass'

  • 'Copy as JavaScript'

    

Inclusion de fichiers locaux / Path Traversal

Il prend en charge les syntaxes de fichiers Unix et Windows, permettant la génération dynamique de wordlists pour tout chemin souhaité. De plus, il peut tenter de contourner les implémentations de pare-feu d'applications Web (WAF), avec divers encodages et autres techniques.

• 'Depth' spécifie l'étendue du parcours de répertoire pour la génération de la wordlist. Vous pouvez créer des wordlists qui atteignent jusqu'à ce niveau spécifié. La valeur par défaut est 5.
• 'Waf Bypass' demande si vous souhaitez activer toutes les fonctionnalités de contournement, telles que l'utilisation d'octets nuls, diverses techniques d'encodage et d'autres méthodes pour contourner les pare-feu d'applications Web.

Exécution de code à distance / Injection de commandes

Il génère dynamiquement des wordlists pour l'exécution de commandes en fonction de la commande fournie. Il combine divers séparateurs et terminateurs pour les environnements Unix et Windows.

• 'URL Encoding' encode la sortie.

Injection SQL

Il génère des payloads pour divers types d'attaques par injection SQL, y compris les requêtes empilées, les attaques booléennes, les attaques basées sur UNION et les attaques temporelles. Il n'exige aucune entrée utilisateur ; il vous suffit de sélectionner les types d'attaques SQL et les bases de données souhaités, et il génère une wordlist avec différentes combinaisons.

• 'URL Encoding' encode la sortie.
• 'Waf Bypass' demande si vous souhaitez activer toutes les fonctionnalités de contournement, telles que l'utilisation d'octets nuls, diverses techniques d'encodage et d'autres méthodes pour contourner les pare-feu d'applications Web.
• 'Union-Based' nécessite la profondeur spécifiée pour la génération des payloads. Vous pouvez créer des wordlists qui atteignent jusqu'à la valeur donnée. La valeur par défaut est 5.
• Les aspects restants concernent les types de bases de données et les différents vecteurs d'attaque.

Générateur de code BCheck

BCheck est le framework de Burp Suite pour créer et importer des vérifications de scan personnalisées. Ces vérifications définies par l'utilisateur s'exécutent parallèlement aux routines intégrées de Burp Scanner, vous permettant d'adapter les scans à des vulnérabilités ou besoins de test spécifiques. En utilisant BChecks, vous pouvez étendre les capacités de scan de Burp et rationaliser votre flux de travail pour des évaluations plus ciblées et efficaces. Vous pouvez maintenant générer le code automatiquement :

• Vous pouvez cliquer sur le bouton "Generate the Payloads" dans la boîte bleue ci-dessus pour créer une wordlist classique, qui peut être utilisée manuellement dans Intruder ou Repeater de Burp.
• Maintenant, vous avez également la possibilité de cliquer sur le bouton "Generate payloads for BCheck" dans la boîte rouge pour générer les mêmes payloads formatés en syntaxe BCheck, prêts à être utilisés dans les scans.

Veuillez noter que plus le script Bambdas est grand, plus il peut causer des problèmes de performance, en particulier lors des scans. Les scripts plus grands peuvent ralentir la réactivité, augmenter l'utilisation de la mémoire et entraîner des retards dans l'exécution des tâches.

Après avoir cliqué sur le bouton "Generate payloads for BCheck", le code BCheck sera automatiquement copié dans votre presse-papiers.

Ensuite, allez dans 'Extensions > BChecks > New > Blank' depuis le menu de Burp Suite, et collez simplement le code généré.

Vos payloads sont maintenant intégrés dans un BCheck. Vous pouvez soit envoyer ou scanner manuellement des requêtes HTTP, soit lancer un scan Burp qui intègre les contrôles BCheck pour tester automatiquement les payloads d'injection générés par l'outil.

• Scan manuel : Faites un clic droit sur une requête HTTP et sélectionnez "Send to BChecks Editor". Cliquez ensuite sur l'élément BCheck généré et sélectionnez "Run test".
• Scan automatique : Faites un clic droit sur une requête HTTP, choisissez 'Open Scan Launcher', puis allez dans 'Scan configuration > Select from library > Audit checks – BChecks only'. Fermez la boîte de dialogue, et votre scan s'exécutera désormais exclusivement avec les BChecks que vous avez définis.

Conseils d'affinage : Le code généré sert de modèle et peut nécessiter quelques ajustements, car le comportement peut varier entre différentes applications et serveurs.

Affiner les filtres—tels que les codes de réponse HTTP ou les mots-clés dans les réponses—peut aider à réduire les faux positifs et à rendre les résultats plus précis et moins bruyants.

Matrice d'autorisation / Tableau d'accès utilisateur

Cette partie se concentre sur l'analyse des sessions utilisateur et des relations URL pour identifier les violations d'accès. L'outil visite systématiquement toutes les URL associées aux sessions utilisateur prédéfinies et remplit un tableau avec les réponses HTTP. Essentiellement, il crée une matrice d'accès, qui aide à identifier les problèmes d'authentification et d'autorisation. Finalement, ce processus révèle quels utilisateurs peuvent accéder à quels contenus de page.

• Vous pouvez faire un clic droit sur n'importe quelle requête et naviguer vers 'Extensions > Agartha > Auth Matrix' pour définir des sessions utilisateur.
• Ensuite, vous devez fournir les adresses URL auxquelles l'utilisateur (propriétaire de l'en-tête/session HTTP) peut accéder. Vous pouvez utiliser la fonctionnalité 'Spider' Web pour un crawl automatique ou fournir une liste d'URLs organisée manuellement.
• Après cela, vous pouvez utiliser le bouton 'Add User' pour inclure les sessions utilisateur.
• Maintenant, c'est prêt pour l'exécution. Cliquez simplement sur le bouton 'Run', et le tableau se remplira en conséquence.

Un peu plus de détails :

1. C'est le champ où vous entrez le nom d'utilisateur pour la session que vous fournissez. Vous pouvez ajouter jusqu'à quatre utilisateurs différents, chaque utilisateur recevant une couleur unique pour améliorer la lisibilité.
   • Le bouton 'Add User' vous permet d'inclure des sessions utilisateur dans la matrice.
   • Vous pouvez changer la méthode de requête HTTP en 'GET', 'POST' ou 'Dynamic', cette dernière étant basée sur l'historique du proxy.
   • Le bouton 'Reset' efface tout le contenu.
   • Le bouton 'Run' exécute la tâche, affichant les résultats dans la matrice d'accès utilisateur.
   • La section 'Warnings' met en évidence les problèmes potentiels en utilisant différentes couleurs pour une identification facile.
   • Le bouton 'Spider (SiteMap)' génère automatiquement une liste d'URL basée sur l'en-tête/session de l'utilisateur. Les URL visibles seront remplies dans la prochaine zone de texte, où vous pouvez toujours apporter des modifications si nécessaire.
   • 'Crawl Depth' définit le nombre maximum de sous-liens que le 'Spider' doit explorer pour détecter les liens.
2. Le champ sert à spécifier les en-têtes de requête, et toutes les URL seront accédées en utilisant la session définie ici.
3. Spécifiez les adresses URL que les utilisateurs peuvent visiter. Vous pouvez créer cette liste manuellement ou utiliser la fonctionnalité de crawler 'Spider'. Assurez-vous de fournir une liste d'URL visitables pour chaque utilisateur.
4. Toutes les URL fournies seront listées ici et tentées d'être accédées en utilisant les sessions utilisateur correspondantes.
5. La première colonne représente un scénario sans tentative d'authentification. Tous les cookies, jetons et paramètres de session potentiels seront supprimés des appels HTTP.
6. Les colonnes restantes correspondent aux utilisateurs précédemment générés, chacun marqué d'une couleur unique pour indiquer le propriétaire respectif de l'URL.
7. Les titres des cellules affichent les 'codes:longueurs' de réponse HTTP pour chaque session utilisateur, fournissant un aperçu clair des détails de réponse pour chaque tentative d'accès.
8. Cliquez simplement sur la cellule que vous souhaitez examiner, et les détails HTTP s'afficheront en bas.

Veuillez noter que les terminateurs de session potentiels (tels que logoff, déconnexion, etc.) et certains types de fichiers (tels que CSS, images, JavaScript, etc.) seront filtrés à la fois du 'Spider' et de la liste d'URL de l'utilisateur.

Après avoir cliqué sur 'RUN', l'outil remplira la matrice utilisateur et URL avec différentes couleurs. En plus des couleurs spécifiques à l'utilisateur, vous verrez des cellules rouges, oranges et jaunes indiquant des problèmes d'accès possibles.

• Rouge met en évidence une violation d'accès critique, indiquée par la réponse renvoyant 'HTTP 200' avec la même longueur de contenu.
• Orange signifie un problème modéré nécessitant une attention, marqué par la réponse renvoyant 'HTTP 200' mais avec une longueur de contenu différente.
• Jaune indique que la réponse renvoie un statut 'HTTP 302', signifiant une redirection.

La tâche implique un traitement en masse, et il convient de mentionner quelles méthodes de requête HTTP seront utilisées. L'outil propose trois options différentes pour effectuer des appels HTTP :

• GET, Toutes les requêtes sont envoyées en utilisant la méthode GET.
• POST, Toutes les requêtes sont envoyées en utilisant la méthode POST.
• Dynamic, La méthode de requête est déterminée par l'historique du proxy. Si aucune information n'est disponible, la méthode de l'en-tête de base sera utilisée par défaut.
  
  

Contournement 403

Le code de statut HTTP 403 Forbidden indique que le serveur comprend la requête mais refuse de l'autoriser. Essentiellement, cela signifie : « Je reconnais qui vous êtes, mais vous n'avez pas la permission d'accéder à cette ressource. » Ce statut indique souvent des problèmes tels que « autorisations insuffisantes », « authentification requise », « restrictions IP », etc.

L'outil traite l'erreur d'accès interdit courante en employant diverses techniques, telles que la manipulation d'URL et la modification des en-têtes de requête. Ces stratégies visent à contourner les restrictions d'accès et à récupérer le contenu souhaité.

Il convient de mentionner deux cas d'utilisation différents :

1. Dans les scénarios liés aux Problèmes d'authentification, il est essentiel de supprimer tous les identifiants de session. Après cela, testez si des sources deviennent accessibles publiquement. Cette approche aide à identifier les accès non authentifiés et garantit que les informations sensibles restent protégées.
2. Pour les tests d'Escalade de privilèges et d'autorisation, conservez les identifiants de session mais limitez leur utilisation à des rôles utilisateur spécifiques. Par exemple, vous pouvez utiliser la session d'un utilisateur normal tout en substituant une URL administrative. Cette approche ciblée permet des tests plus précis et efficaces, garantissant que les sources privilégiées ne sont pas accessibles sans les rôles appropriés.

Il existe 2 façons d'envoyer des requêtes HTTP à l'outil.

1. Vous pouvez charger des requêtes depuis l'historique du proxy en cliquant sur le bouton 'Load Requests'. Cela supprimera automatiquement tous les identifiants de session, le rendant adapté à l'attaque Cas 1. Les terminateurs de session potentiels (tels que logoff, déconnexion, etc.) et certains types de fichiers (tels que CSS, images, JavaScript, etc.) seront également filtrés. Veuillez noter qu'il s'agira d'un processus en masse et peut prendre plus de temps car il implique de revisiter chaque requête HTTP de l'historique. Cependant, cette vérification complète de tous les points de terminaison est essentielle pour garantir la sécurité des mécanismes d'authentification.
2. Vous pouvez envoyer des requêtes individuelles en faisant un clic droit. Les identifiants de session seront conservés/intacts, rendant cette approche adaptée à l'attaque Cas 2. Cette approche contrôlée vous permet d'évaluer si les sources privilégiées sont accessibles sans les rôles appropriés. Elle sera plus spécifique et plus rapide, car les utilisateurs sélectionneront les URL à tester plutôt que de tout copier depuis l'historique.

La page que nous souhaitons accéder appartient à un groupe d'utilisateurs privilégiés, et nous conservons nos identifiants de session pour vérifier si une escalade de privilèges est possible.

Il suffit de cliquer sur le bouton 'RUN' pour exécuter la tâche.

La figure ci-dessous illustre qu'une URL peut avoir un problème d'accès, la couleur 'Rouge' indiquant un avertissement.

1. Chargez les requêtes depuis l'historique du proxy en sélectionnant le nom d'hôte cible et en cliquant sur le bouton 'Load Requests'.
   • Activer les filtres : Comme le traitement de toutes les URL de l'historique HTTP est une tâche en masse, cette section propose des options pour appliquer des critères de correspondance.
     • La fonctionnalité Activer le regroupement d'URL (expérimentale) vise à éliminer les points de terminaison similaires qui ne diffèrent que par des identifiants uniques, en les comptant comme une seule entrée.
     • Vous pouvez choisir de charger uniquement les URL des n derniers jours.
     • Vous pouvez également spécifier certains mots-clés pour contrôler quelles URL sont chargées, par exemple : /admin/, user
2. Détails de l'URL et de l'en-tête
3. Tentatives de requête et résultats
4. Requêtes et réponses HTTP

Veuillez noter que le nombre de tentatives dépend de l'URL cible spécifique.

Copier en JavaScript

Cette fonctionnalité permet de convertir des requêtes HTTP en code JavaScript, ce qui peut être particulièrement utile pour aller au-delà des vulnérabilités XSS et contourner les restrictions d'en-tête.

Pour utiliser cette fonctionnalité, faites simplement un clic droit sur n'importe quelle requête HTTP et sélectionnez 'Extensions > Agartha > Copy as JavaScript'.

Il sera automatiquement enregistré dans votre presse-papiers, avec quelques remarques supplémentaires pour votre référence. Par exemple :``` Http request with minimal parameters:

Http request with header fields:

Veuillez noter que le code JavaScript s'exécutera dans la session utilisateur d'origine, avec de nombreux champs d'en-tête automatiquement renseignés par le navigateur. Cependant, dans certains cas, le serveur peut exiger des champs d'en-tête obligatoires spécifiques. Par exemple, certaines requêtes peuvent échouer si le 'Content-Type' est incorrect. Par conséquent, vous devrez peut-être ajuster le code pour assurer la compatibilité avec les exigences du serveur.
<br/><br/>

## Générateur de code Bambdas
Les Bambdas sont des scripts légers qui s'exécutent directement dans Burp Suite, permettant aux utilisateurs de personnaliser et d'automatiser rapidement diverses tâches. Ils peuvent être utilisés pour définir des règles de correspondance et remplacement personnalisées, ajouter des colonnes dynamiques aux tableaux, appliquer des filtres et adapter l'interface pour mieux répondre à des flux de travail de test spécifiques. 

<img width="1000" alt="Bambdas Code Generator" src="https://assets.kitploit.com/production/public/readmes/5162/1f24e30531216aea02630b65422c79753e12e44148338735a51450ba4d42be03.png">

Explications, un peu plus de détails :
1. Concernant l'interface graphique de création de scripts, vous pouvez sélectionner les paramètres généraux ici. Par exemple :
 	- Traiter uniquement les adresses dans le périmètre ou toutes les adresses de domaine.
 	- Masquer ou non des extensions de fichier spécifiques.
 	- Couleurs pour les URL définies dans la section de périmètre, situées dans la première partie du Groupe 3.
   	- Couleurs pour les URL déjà testées, situées dans la deuxième partie du Groupe 3.
   	- Couleurs pour les filtres définis principalement dans le Groupe 2.
   	- Nombre de jours passés à afficher.
 	- Nombre de jours passés à traiter par le script.
2. Les options dans la deuxième section concernent principalement le traitement des requêtes et réponses HTTP :
 	- Fournit des options pour spécifier si les critères de recherche doivent être appliqués à l'URL, à la requête ou à la réponse. La sélection de l'une d'elles activera les options correspondantes ci-dessous. Par exemple, si vous souhaitez rechercher des 'Fonctions JavaScript vulnérables', cela ne sera possible que dans les réponses HTTP.
 	- Option pour masquer des méthodes HTTP spécifiques.
 	- "Rechercher les commentaires HTML", "Extensions de fichier téléchargeables" et "Fonctions JS vulnérables" sont généralement recherchées dans les réponses HTTP.
 	- Les recherches de "Mots-clés précieux" peuvent être appliquées aux URL, aux requêtes et aux réponses.
   	- "Identifiants suspects SQLi, identifiants suspects XSS, identifiants suspects LFI, identifiants suspects SSRF, identifiants suspects Open Redirect et identifiants suspects RCE" peuvent être recherchés dans les URL ou les requêtes. Contrairement aux "Mots-clés précieux" qui recherchent du texte libre, ces options détectent spécifiquement les paramètres.
3. Les options de la troisième section sont principalement pour définir le périmètre, les URL déjà testées et les URL que vous souhaitez masquer.
 	- Vous pouvez définir les URL à tester dans la section "Définition du périmètre de test". Si vous entrez /, l'ensemble de l'application sera considéré comme dans le périmètre ; si vous ajoutez un chemin spécifique comme /users, seuls ce répertoire et son contenu seront dans le périmètre. L'option "Couleur pour le périmètre de test" s'applique à cette section.
   	- La section "URL déjà testées" contient la liste des URL qui ont déjà été testées. L'option "Couleur pour les éléments testés" s'applique ici.
 	- La section "URL sur liste noire" contient les URL que vous souhaitez masquer de l'historique du proxy.

    **Exemples de définitions :** 
    - /
 	    - Chemin racine — inclut tout.  
   			Remarque : En plus des définitions de périmètre de test et testé, il peut également être appliqué dans la section URL sur liste noire, où il exclut tout sauf si un critère de correspondance est défini.
    - /portal/users
 	    - Inclut spécifiquement ce chemin et ses sous-chemins, par exemple :
 	 	    - /portal/users?id=1
 	 	    - /portal/users/?id=1
 	 	    - /portal/users/dashboard
    - /admin/\*/users/\*/class
     	- L'astérisque (*) agit comme un espace réservé pour les ID, UUID, etc., et le reste du chemin sera inclus.
    - /api/v\*/user
     	- L'astérisque (*) agit comme un caractère générique qui correspond à toute séquence de caractères suivant **v**, jusqu'au prochain '/', par exemple :
 	 	    - /api/v1/user
 	 	    - /api/v2/user
    - /health-check
 	    - Inclut spécifiquement ce chemin et ses sous-chemins, par exemple :
 	 	    - /health-check
 	 	    - /health-check/Monitor
 	 	    - /health-check/?Level=Info
4. Enfin, la quatrième section est l'endroit où le script généré en cliquant sur le bouton "Exécuter" est affiché, et le script est maintenant prêt à être utilisé. En général, ce script peut être ajouté de deux manières différentes :
 	- Temporaire (basé sur le projet) : Depuis le menu de l'application, allez dans Proxy > HTTP History > Bambda Mode > Apply & Close.
   	- Permanent (à l'échelle de l'application) : Depuis le menu de l'application, allez dans Extensions > Bambda Library > New > Blank > View filter + HTTP history > Save & Close.
 	

**Veuillez noter** : L'activation de toutes les options, en particulier pour les grands projets, peut entraîner une utilisation importante des ressources système et un temps de traitement accru. Si le script que vous avez créé ne se termine pas dans un délai raisonnable, il peut être bénéfique de le réviser.

<img width="1000" alt="Bambdas Code Generator" src="https://assets.kitploit.com/production/public/readmes/5162/cb116ad18bc53ebf770b5bc1cb2b920cc9ef3a4569fab9b12d5fb9979823a58c.png">

**Priorité des options** : La priorité la plus élevée est 'Couleur pour les éléments testés', suivie de 'Couleur pour le périmètre de test', et enfin 'Couleur pour les paramètres/mots-clés'.

La figure ci-dessus illustre ce qui suit :
- **Rose** indique le périmètre de test (la première partie du groupe 3).
- **Jaune** représente le périmètre testé (la deuxième partie du groupe 3).
- **Cyan** met en évidence les correspondances pour les critères de recherche (Groupe 2). De plus, vous pouvez voir quel critère a correspondu dans la section 'Notes' de chaque appel HTTP.

Si vous mettez à jour ou modifiez ultérieurement un script qui a déjà été créé, il y a quelques points importants à garder à l'esprit :
- Si vous définissez votre script comme Permanent (à l'échelle de l'application), vous devrez le recharger en suivant ces étapes :

		Bambda Script mode > Load
  
  <img width="800" alt="Bambdas Code Generator" src="https://assets.kitploit.com/production/public/readmes/5162/5a840779ef9b2df5ac22e94d8ebf6771a677d5d45d49f35cae6f4b3a2e820cd2.png">

- Si vous utilisez votre script comme Temporaire (basé sur le projet), vous avez généralement deux options :
 	1. Si vous souhaitez que le script modifié soit actif à partir de ce moment, aucune étape supplémentaire n'est nécessaire — cliquez simplement sur Apply.
 	2. Si vous souhaitez que le script modifié traite tout l'historique du proxy, vous devez soit réactiver le mode Bambda, soit basculer le paramètre booléen resetScreen dans le script :
		```
		// 'true' efface les couleurs/notes
		// 'false' exécute le script  
		boolean resetScreen = false; // or true
		
		```
		<img width="800" alt="Bambdas Code Generator" src="https://assets.kitploit.com/production/public/readmes/5162/cf2dac03f0dd6f1db5d8950b0162eda9e18862b1fb9da7a57f4cc119ec233c57.png">

<br/><br/>
[Un autre lien de tutoriel](https://www.linkedin.com/pulse/agartha-lfi-rce-auth-sqli-http-js-volkan-dindar)