C:\myapplication\myapplication.exe
      C:\myapp\subfolder\myapp.exe
      C:\SoftwareCompany\software.exe
      C:\myapplication\myapplication.dll
      C:\myapp\subfolder\myapp.dll
      C:\SoftwareCompany\software.dll
           

**Un modèle mental pratique est :**

le processus charge libeay32.dll

→ le processus appelle OPENSSL_config(NULL)

→ OpenSSL lit openssl.cnf

→ la section engine provoque une tentative de chargement d'une dll spécifiée

→ le chargeur Windows accepte la dll et ses dépendances

***Si une étape manque, votre DLL ne se chargera pas.***

Une règle minimale que vous pouvez utiliser lors du débogage :

Si le processus ne charge que libeay32.dll, cela ne suffit pas.
Il doit également appeler le chargement de la configuration OpenSSL et ne pas le désactiver.

- Il doit appeler OPENSSL_config pour fonctionner ou
- CONF_modules_load_file ou
- OPENSSL_no_config n'est pas défini.


Aucune vérification de signature. Aucune vérification. Toute DLL spécifiée est chargée, si le processus appelle OPENSSL_config.
Nous pouvons interroger les noms de DLL typiques liés à OpenSSL pour énumérer les applications possibles à tester davantage. Nous voulons vérifier les DLL OPENSSLDIR et si le processus appelle OpenSSL_conf.
Nous pouvons vérifier OpenSSLDIR en comparant le hash du fichier à la liste de ce dépôt, ou obtenir une copie de la dll liée à la cryptographie et simplement exécuter openssldir_check sur la cryptodll (libeay32.dll etc).
Nous pouvons également utiliser ProcMon pour vérifier si le processus appelle un openssl.cnf. Si nous voyons openssl.cnf dans procmon, alors nous savons avec certitude que l'application l'appelle. Dans d'autres méthodes, ce que nous voulons obtenir est l'information de version (dans les champs de event.code 7) et depuis quel chemin il charge le fichier openssl.cnf en comparant le hash du fichier à la liste de ce dépôt, obtenir une copie de la même DLL et faire une vérification manuelle. 


**Exemple lors de l'exécution de openssldir_check.exe**

`openssldir_check32.exe libeay32.dll`

`openssldir_check v1.0 by 0xm1rch`

**Sortie :**

`SSLeay_version() returned OpenSSL 1.0.1g 7 Apr 2014`

`SSLeay_version() returned OPENSSLDIR: "/usr/local/ssl"`

- ref https://github.com/mirchr/openssldir_check
> Sortie similaire avec un openssldir_check modifié sur mesure qui est précompilé dans ce dépôt.

> La sortie donne la version OpenSSL 1.0.1g et indique que OpenSSLDIR est défini sur **/usr/local/ssl**, ce qui est **très intéressant !**

> **Sysmon event.code 7** vous donne les DLL OpenSSL chargées ainsi que l'information de version de la dll dans le champ file.pe.file_version.


#### Scénario d'escalade
1. Un service s'exécute en tant que **SYSTEM** et utilise OpenSSL
2. La DLL OpenSSL appelle openssl_conf et lit `C:\usr\local\ssl\openssl.cnf` au démarrage, mais ce fichier est modifiable ou manquant
3. Si un utilisateur peu privilégié peut écrire dans ce dossier, il peut :
   - Déposer un `openssl.cnf` malveillant
   - Déposer sa DLL
   - Attendre le redémarrage du service
   - Le code s'exécute en tant que **SYSTEM**

> Résultat : élévation de privilèges locale en plaçant un openssl.cnf que la dll openssl de l'application charge et qui aboutit au chargement d'une dll « malveillante » personnalisée.



### Vulnérabilité de l'installateur/désinstallateur NSIS

NSIS est un framework d'installation Windows largement utilisé. Le problème décrit ici est que, lorsqu'un installateur ou désinstallateur NSIS s'exécute avec des privilèges élevés, il peut utiliser des répertoires temporaires sous C:\Windows\Temp d'une manière qu'un utilisateur local normal peut perturber.

En pratique, cela signifie qu'un attaquant peu privilégié peut prendre le contrôle de fichiers auxquels l'installateur fait confiance, tels que des fichiers de plugin temporaires ou des fichiers de désinstallateur, et transformer cela en exécution de code en tant que SYSTEM. En d'autres termes, la faiblesse n'est pas « l'installateur s'exécute en tant qu'admin », mais que la gestion des fichiers temporaires de l'installateur peut permettre à un utilisateur non privilégié de détourner un flux d'installation ou de désinstallation élevé.

#### DLL courantes observées dans les installateurs NSIS

> Remarque : certaines d'entre elles sont des **plugins NSIS officiels**, tandis que d'autres sont des **plugins tiers courants** souvent utilisés par les installateurs NSIS.  
> Voir l'une de ces DLL est un indice, mais pas une preuve absolue, qu'un installateur utilise NSIS. Un chemin de fichier de type `C:\Windows\Temp\*.tmp\*.dll` est une forte indication.

| DLL | Objectif typique | Type | Notes |
|---|---|---|---|
| `System.dll` | Appelle les API Win32 et les fonctions DLL externes depuis les scripts NSIS | Plugin NSIS officiel | L'un des indicateurs les plus forts de NSIS |
| `nsDialogs.dll` | Construit des boîtes de dialogue et contrôles d'installation personnalisés | Plugin NSIS officiel | Courant dans les installateurs NSIS modernes |
| `nsExec.dll` | Exécute des commandes console et capture la sortie | Plugin NSIS officiel | Souvent utilisé pour des commandes auxiliaires silencieuses |
| `StartMenu.dll` | Permet à l'utilisateur de choisir un dossier du menu Démarrer | Plugin NSIS officiel | Courant dans les installateurs classiques |
| `LangDLL.dll` | Affiche une boîte de dialogue de sélection de langue | Plugin NSIS officiel | Apparaît souvent dans les installateurs multilingues |
| `Banner.dll` | Affiche une bannière/UI de progression pendant les étapes d'installation | Plugin NSIS officiel | Principalement cosmétique |
| `InstallOptions.dll` | Crée des pages personnalisées de style ancien à partir de définitions INI | Plugin NSIS officiel | Largement remplacé par `nsDialogs.dll` |
| `UserInfo.dll` | Récupère des informations sur l'utilisateur/le compte actuel | Plugin NSIS officiel | Utilisé pour les vérifications de privilèges ou de compte |
| `Dialer.dll` | Gère le comportement de connexion dial-up/réseau | Plugin NSIS officiel | Principalement hérité |
| `Math.dll` | Fournit des assistants arithmétiques pour les scripts NSIS | Plugin NSIS officiel | Moins souvent nécessaire dans les scripts récents |
| `NSISdl.dll` | Télécharge des fichiers depuis Internet | Plugin NSIS officiel | Ancien plugin de téléchargement ; souvent remplacé par `inetc.dll` |
| `Splash.dll` | Affiche un écran de démarrage | Plugin NSIS officiel | Principalement hérité/cosmétique |
| `AdvSplash.dll` | Affiche un écran de démarrage plus avancé | Plugin NSIS courant | Rôle similaire à `Splash.dll` |
| `BgImage.dll` | Affiche une image d'arrière-plan dans l'UI de l'installateur | Plugin NSIS officiel / courant | Principalement cosmétique |
| `inetc.dll` | Télécharge des fichiers via HTTP/FTP | Plugin NSIS tiers courant | Très courant dans les installateurs web |
| `InetLoad.dll` | Télécharge des fichiers depuis Internet | Plugin NSIS tiers courant | Alternative à `NSISdl.dll` / `inetc.dll` |
| `UAC.dll` | Gère l'élévation et le comportement lié à l'UAC | Plugin NSIS tiers courant | Fort indice lié à NSIS |
| `AccessControl.dll` | Modifie les ACL et permissions de fichiers/dossiers | Plugin NSIS tiers courant | Utilisé dans les installations sensibles à l'admin |
| `Registry.dll` | Opérations avancées sur le registre Windows | Plugin NSIS tiers courant | Plus performant que les commandes de registre intégrées dans certains cas |
| `ShellLink.dll` | Crée ou modifie des raccourcis Windows (`.lnk`) | Plugin NSIS tiers courant | Assistant de gestion des raccourcis |
| `SimpleFC.dll` | Compare des fichiers ou vérifie les différences entre fichiers | Plugin NSIS tiers courant | Plugin utilitaire/assistant |
| `FindProcDLL.dll` | Détecte si un processus est en cours d'exécution | Plugin NSIS tiers courant | Souvent utilisé avant les mises à niveau |
| `KillProcDLL.dll` | Termine les processus en cours d'exécution | Plugin NSIS tiers courant | Courant dans les désinstallateurs/metteurs à jour |
| `NScurl.dll` | Télécharge/transfère des données avec une fonctionnalité de style curl | Plugin NSIS tiers courant | Assistant réseau plus récent/plus performant |
| `ZipDLL.dll` | Gère l'extraction ou la création d'archives ZIP | Plugin NSIS tiers courant | Utilitaire d'archive |
| `unzipdll.dll` | Extrait les archives ZIP | Plugin NSIS tiers courant | Ancien plugin d'archive |
| `untgz.dll` | Extrait les archives `.tar.gz` | Plugin NSIS tiers courant | Moins courant, mais vu dans certains paquets |
| `VPatch.dll` | Applique des correctifs/mises à jour binaires | Plugin lié à NSIS courant | Souvent utilisé dans les installateurs de correctifs |
| `CabDLL.dll` | Travaille avec les archives CAB | Plugin lié à NSIS courant | Principalement vu dans les anciens flux de packaging |
| `nsJSON.dll` | Analyse ou génère des données JSON | Plugin NSIS tiers courant | Plus courant dans les installateurs scriptés modernes |
| `StdUtils.dll` | Utilitaires généraux pour NSIS | Plugin NSIS tiers courant | Souvent utilisé pour les assistants OS/version/chemin |
| `ExecDos.dll` | Exécute des commandes avec un meilleur contrôle des E/S et de l'attente | Plugin NSIS tiers courant | Alternative/extension à `nsExec.dll` |

#### Indicateurs NSIS plus forts

Les DLL suivantes sont particulièrement évocatrices de NSIS :

- `System.dll`
- `nsDialogs.dll`
- `nsExec.dll`
- `LangDLL.dll`
- `StartMenu.dll`
- `NSISdl.dll`
- `inetc.dll`
- `UAC.dll`

#### Attention

Certains installateurs extraient ces DLL temporairement dans un dossier comme :

- `$PLUGINSDIR`

Elles peuvent donc n'apparaître qu'à l'exécution, et non à côté de l'exécutable de l'installateur sur le disque.


### Vulnérabilités de redirection DotLocal
**L'abus de redirection DotLocal est un problème de détournement de DLL Windows où un dossier d'application accessible en écriture permet à un attaquant d'amener un programme légitime à charger une DLL malveillante en premier**

La vulnérabilité de redirection DotLocal exploite la fonctionnalité intégrée de redirection DLL .local / DotLocal de Windows. Windows prend en charge la redirection DLL en honorant un fichier ou dossier nommé comme App.exe.local ; lorsqu'il est présent, le chargeur vérifie d'abord le dossier de l'exécutable ou ce dossier .local pour les DLL, et cela peut s'appliquer même lorsqu'un chemin DLL complet est spécifié. Microsoft documente cela comme une fonctionnalité légitime pour rediriger les chargements de DLL.

Pourquoi cela devient une vulnérabilité : si un attaquant peut écrire dans le répertoire de l'exécutable (chemins accessibles en écriture par l'utilisateur), ou dans un répertoire d'extraction temporaire utilisé par un processus privilégié, il peut créer un dossier Target.exe.local et y placer une DLL malveillante que Windows préférera. Cela transforme la fonctionnalité en détournement de DLL, de sorte que le processus de confiance charge la bibliothèque de l'attaquant au lieu de la bibliothèque prévue.

#### Contrôle manuel
Les processus à privilèges élevés identifiés dans des chemins accessibles en écriture par tous devraient être examinés pour déterminer s'ils sont vulnérables à la redirection DotLocal. Si vous les interrogez et trouvez des applications. Effectuez le dernier contrôle avec ProcMon pour voir si le processus tente de charger des bibliothèques depuis le dossier .exe.local créé. Vous pouvez utiliser l'outil GetSxsPath pour déterminer le chemin complet du fichier. Procmon devrait vous montrer des événements NAME NOT FOUND / PATH NOT FOUND pointant vers un répertoire .exe.local s'il est vulnérable. D'après les rapports publics, les applications sont particulièrement vulnérables pendant le processus d'installation.

**Une bonne règle empirique est :**
ProcMon peut fournir des preuves de sondage .local, mais l'absence d'un échec .exe.local visible ne prouve pas que l'application n'est pas sensible. Pour comctl32.dll en particulier, la trace reflète souvent une liaison manifest/SxS plutôt qu'une simple recherche DLL dans le dossier de l'application. 


#### Si un programme charge :

`C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

#### Vérifiez ceci :

`C:\Path\To\Application.exe.local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

**Déterminer le chemin de redirection pour le détournement de DLL SxS DotLocal** - https://gist.github.com/rxwx/1717e95e5ec11bea12d33e93a3832508

#### DotLocal Wiz Installer
**WiX Burn EXE bootstrapper** Versions affectées >= 4, < 4.0.4 < 3.14.0. Cela impacte tout installateur construit avec le framework d'installation WiX.
WiX permet également aux auteurs de remplacer l'icône par défaut et d'utiliser soit l'UI WixStdBA standard, soit une application bootstrapper personnalisée, de sorte que l'EXE peut être personnalisé pour ressembler au vendeur plutôt qu'à « WiX »

##### Détails
Si le bundle n'est pas exécuté en tant qu'admin, le dossier TEMP de l'utilisateur est utilisé et non le dossier TEMP système. Un utilitaire est capable de surveiller le dossier TEMP de l'utilisateur pour détecter les changements et déposer sa propre DLL dans le dossier .be/.Local immédiatement lorsque le dossier .be est créé. Lorsque le moteur burn s'élève, la DLL malveillante reçoit des privilèges élevés.

> **Ref** https://github.com/wixtoolset/issues/security/advisories/GHSA-7wh2-wxc7-9ph5

« Un processus wixstdba.exe séparé est une bonne empreinte de WiX Burn, mais l'indicateur le plus fort pour les versions affectées est la version du moteur Burn elle-même : vulnérable si elle s'identifie comme <3.14.0 ou 4.0.0–4.0.3. »


## Prérequis
Une configuration SYSMON bien configurée pour capturer les événements intéressants, comme event.code 1, 7, 11 et 13 pour les chemins accessibles en écriture par l'utilisateur et les ruches de registre mentionnées.
 - https://github.com/SwiftOnSecurity/sysmon-config
 - https://github.com/olafhartong/sysmon-modular

Audit avancé activé pour certains des événements Windows.

L'Event ID 4688 (création de processus) doit être explicitement activé pour journaliser les processus nouvellement créés. 
Par défaut, il ne capture pas la ligne de commande utilisée pour démarrer le processus ; cette fonctionnalité doit être spécifiquement activée dans la politique de sécurité.

Tâche planifiée - 4698 n'est pas activé par défaut.


## ACL ⭐
### 🔹 Quelques principaux ACL courants couvrant les utilisateurs connectés

| Principal               | Description                                                                 |
|--------------------------|-----------------------------------------------------------------------------|
| **Everyone**             | Tous les utilisateurs, y compris les invités (et dans les anciennes versions de Windows, même Anonymous Logon). Très large, généralement limité à l'accès en lecture. |
| **Authenticated Users**  | Tout compte qui s'est connecté avec succès (local ou domaine). Exclut les utilisateurs anonymes. |
| **BUILTIN\Users**        | Le groupe local **Users** sur la machine. Inclut tous les comptes locaux standard (non-admin). |
| **INTERACTIVE**          | Tout utilisateur connecté **localement à la console** (clavier/session). Utile pour différencier l'accès local de l'accès distant. |
| **COMPUTERNAME\\Username** | Un **compte local** spécifique sur cet ordinateur (par exemple, `LAPTOP01\Bob`). Les permissions s'appliquent uniquement lorsque cet utilisateur se connecte localement. |
| **DOMAIN\\Username**     | Un **compte de domaine** spécifique (par exemple, `CORP\Alice`). Les permissions suivent l'utilisateur sur toutes les machines jointes au domaine. |


### 📑 Attributs ACL (certains des plus intéressants à examiner)

Les attributs de liste de contrôle d'accès (ACL) définissent les actions qu'un utilisateur ou un groupe peut effectuer sur des fichiers ou dossiers.  
Voici quelques-uns des principaux à noter :

| Attribut | Nom / Signification           | Pourquoi c'est intéressant                                                                 |
|-----------|--------------------------|--------------------------------------------------------------------------------------|
| **F**     | Accès complet              | Accorde **tous les droits possibles** (lecture, écriture, exécution, suppression, modification des permissions, prise de propriété). Équivalent à un contrôle « niveau propriétaire ». |
| **M**     | Accès de modification            | Permet de lire, écrire et supprimer des fichiers/dossiers, mais **pas de modifier les ACL** ni la propriété. Le plus courant pour les utilisateurs réguliers. |
| **W**     | Accès en écriture seule        | L'utilisateur peut **créer ou modifier du contenu** mais ne peut pas le relire. Rare, mais utile dans les scénarios de « boîte de dépôt » (par exemple, soumissions sécurisées de fichiers). |
| **WD**    | Write Data / Add File    | Permet spécifiquement de **créer ou écrire dans des fichiers d'un répertoire**. Essentiel pour pouvoir ajouter ou écraser des fichiers dans un dossier. |
| **AD**    | Append Data / Add Subdirectory | Sur les fichiers : ajouter des données à la fin d'un fichier (impossible d'écraser). Sur les dossiers : créer de nouveaux sous-répertoires à l'intérieur. |


## Faux positifs
#### Faites vos requêtes, affinez-les et, au final, créez des alertes à partir de celles-ci. 
Vous devrez peut-être effectuer une liste blanche (voir ci-dessous pour les chemins typiques dans ProgramData). L'idée est d'interroger les chemins typiques accessibles en écriture par l'utilisateur, mais il arrive que les (fichiers ou dossiers) aient une ACL correctement définie. Si l'état d'esprit offensif n'aide pas à élever les privilèges - mettez-les en liste blanche.
Filtrez les moins intéressants : ceux avec une ACL correcte, les noms de fichiers aléatoires (filtrez le dossier). Nous voulons réduire le bruit et avoir une base de référence. Il est important de le faire après avoir vérifié qu'il ne s'agit pas d'une vulnérabilité. Ainsi, vous ne manquerez pas une tâche planifiée vulnérable sur chaque client.


## Liste blanche
Vous devrez probablement mettre les requêtes en liste blanche. Faites votre chasse, affinez les requêtes et créez des alertes à partir de celles-ci pour capturer les nouveaux événements que vous n'avez pas examinés.
##### Nécessiteront probablement une liste blanche :
      C:\ProgramData\Microsoft
      C:\ProgramData\Package Cache
      C:\ProgramData\Packages
      etc.

D'autres qui peuvent nécessiter une liste blanche, ce qui peut être courant, sont les pilotes liés au matériel et autres éléments similaires qui ont des noms aléatoires.
      

## Méthodologie
N'oubliez pas d'interroger dans la plage temporelle de votre « période de rétention des journaux ».
Une bonne méthodologie consiste à interroger au début une courte période, puis à l'augmenter progressivement.
1) 1 jour
2) 1 semaine
3) 2 semaines
4) 1 mois
5) 2 mois
6) etc..

Faites votre chasse et vérifiez les intéressants, affinez et mettez en liste blanche.. au final, créez des alertes à partir de ceux-ci pour capturer les nouveaux événements..

## Astuces et conseils
Si un remplacement de binaire n'est pas possible à cause d'une ACL correcte. Vérifiez les permissions du dossier et si vous avez les permissions d'écrire des fichiers,
vérifiez si l'exécutable tente de charger des dll qui n'existent pas. Si c'est le cas, créez-les et vous avez votre exécution de code. Si le remplacement de binaire n'est pas possible parce qu'il s'agit d'un processus en cours d'exécution. Vérifiez un possible DLL sideloading ou vérifiez si vous, en tant qu'utilisateur régulier, avez les permissions de redémarrer le service lui-même. Une autre façon est de vérifier si vous, en tant qu'utilisateur régulier, pouvez effectuer un « shutdown » dont vous vous échappez à la dernière seconde. Une initiation de shutdown arrête les processus et si vous vous en échappez, vous pourriez être en mesure de remplacer le binaire du processus terminé. Si le service est en mode Autostart et que vous n'avez pas les permissions de démarrer/arrêter le service, ce que vous pouvez vérifier est si vous avez SeShutdownPrivilege et, si c'est le cas, initier un redémarrage avec shutdown /r /t 0.

Si un service lance le processus et s'il n'est pas possible de remplacer le binaire, le binaire ne tente pas de charger de DLL manquantes. N'abandonnez pas - peut-être que le chemin n'est pas entre guillemets et que vous avez les permissions d'écriture et que vous pouvez l'utiliser ?

Construisez vos requêtes couche par couche.. vérifiez donc les créations de service/tâche planifiée, vérifiez la création de processus avec comme parent services ou un processus lié à une tâche planifiée (svchost.exe avec l'argument Schedule). Il est possible que certains systèmes créent le service ou la tâche planifiée mais que le chemin du binaire etc. n'existe pas et que la création de processus n'ait jamais lieu. Mais la vulnérabilité est toujours là et différents événements peuvent être créés en lien avec elle.

Pour réduire la charge des requêtes (performance) et probablement la liste blanche.. cela peut être une bonne idée d'avoir des requêtes séparées pour les clients/serveurs. Donc un ensemble de requêtes utilisé uniquement pour les endpoints clients et le même ensemble utilisé pour les endpoints serveurs.

La création générique de processus par SYSTEM est une requête à forte valeur. Elle capture beaucoup de scénarios.. outre les services et les schtasks lançant des processus enfants, elle capture aussi msiexec.exe lançant un processus enfant. Elle capture aussi si un exécutable depuis c:\windows\ccmcache lance un processus enfant depuis un chemin accessible en écriture par l'utilisateur. Si nous devions classer les exécutables par vulnérabilité, je dirais quand même que services.exe est lié aux erreurs de configuration logicielles et que schtasks est davantage une erreur de configuration administrateur..

Si vous avez essayé toutes les requêtes et que vous n'avez pas réussi. si vous voulez chasser plus profondément, et faire un peu plus de travail - allez chercher chaque processus enfant de services.exe et schtasks (svchost.exe avec l'argument Schedule), quel que soit l'endroit. Énumérez l'entreprise et cherchez aussi ceux dans les chemins typiquement protégés pour les administrateurs (Program Files & Program Files (x86)). Il est plus courant que vous ne le pensez que les éditeurs de logiciels gâchent l'ACL même dans les chemins typiquement protégés. Utilisez les événements de création de processus et les événements pour les services et les tâches planifiées. Pour les tâches planifiées - interrogez chaque champ Command et champ Argument. Le champ argument peut pointer vers un fichier script dans un chemin accessible en écriture par l'utilisateur ou à la racine C. Les champs command peuvent pointer vers un binaire qui a une ACL non sécurisée. Vous pourriez aussi examiner C:\PROGRA~3 qui est la représentation en nom court 8.3 (DOS) de C:\ProgramData.

## Processus de désinstallation
Il est probable que si un utilisateur peut déclencher une installation, il peut aussi déclencher une désinstallation. Les processus de désinstallation sont intéressants quel que soit l'emplacement du chemin de fichier.
Si l'ACL n'est pas correcte - un remplacement de binaire causera probablement des problèmes.
Interrogez aussi la création de fichiers de désinstallation typiques en utilisant Sysmon event.code:11.
Nous voulons faire cela pour capturer chaque désinstallateur sans faire confiance aux événements de création de processus. C'est parce qu'il n'est pas courant que les utilisateurs effectuent réellement la désinstallation des applications installées.. Ils ne s'en soucient tout simplement pas et il sera donc plus facile de manquer certains événements de désinstallation qui existent mais ne sont jamais déclenchés.

### Exemple de noms de processus de désinstallation
#### Noms génériques courantsuninstall.exe – Le plus générique et le plus largement utilisé.
          unins000.exe, unins001.exe – Courant avec les installateurs Inno Setup.
          unwise.exe – Souvent utilisé par les anciens packages Wise Installer.
          uninst.exe – Version raccourcie, souvent trouvée dans les logiciels hérités.
          uninstaller.exe – Variante légèrement plus longue et descriptive.
          remove.exe – Parfois utilisé pour les installateurs minimaux.
          setup.exe (avec le paramètre /uninstall ou /remove) – Certaines applications réutilisent l'exécutable d'installation pour la désinstallation.
          appname_uninstall.exe (par ex., chrome_uninstall.exe)
          update.exe (avec --uninstall) – Observé avec des applications comme Slack ou Discord utilisant les installateurs Squirrel.

#### Motifs à considérer

          *_uninstall.exe – De nombreuses applications préfixent le nom de l'application, par ex., teams_uninstall.exe, zoom_uninstall.exe.
          *_cleanup.exe – Les outils de suppression ont souvent des variantes cleanup, par ex., driver_cleanup.exe.
          *_remover.exe – Un autre style de nommage courant d'AV/éditeur.


## Fichiers PE / binaires avec exécution de code au chargement
### Envisagez une requête pour ceux de la liste à la fois dans les journaux windows/sysmon et aussi dans les journaux procmon
| Extension | Type PE | Exécution de code au chargement ? | Point d'entrée / mécanisme | Notes |
|-----------|---------|--------------------------|-------------------------|-------|
| `.exe` | Exécutable PE | Oui | PE `AddressOfEntryPoint` | Le code démarre lorsque l'exécutable est lancé |
| `.dll` | DLL PE | Oui | `DllMain` / callbacks TLS | Le code peut s'exécuter lorsqu'une DLL est chargée dans un processus |
| `.sys` | Pilote noyau PE | Oui | `DriverEntry` | Le code d'initialisation du pilote s'exécute lorsque le pilote est chargé |
| `.scr` | Exécutable PE | Oui | PE `AddressOfEntryPoint` | Essentiellement un exécutable ; `.scr` est principalement une convention |
| `.cpl` | DLL PE | Oui | `DllMain` + `CPlApplet` | Chargé par l'infrastructure du Panneau de configuration |
| `.ocx` | DLL PE / ActiveX | Oui | `DllMain` + points d'entrée COM/ActiveX | L'initialisation de la DLL se produit au chargement |
| `.drv` | DLL PE / pilote hérité | Généralement | `DllMain` ou point d'entrée spécifique au pilote | Dépend du type spécifique de `.drv` |
| `.efi` | Binaire PE/COFF EFI | Oui | Point d'entrée EFI | Le code s'exécute lorsqu'il est chargé par UEFI |
| `.ax` | DLL PE | Oui | `DllMain` + interfaces DirectShow | L'initialisation de la DLL se produit au chargement |
| `.acm` | DLL PE | Oui | `DllMain` + points d'entrée ACM | Chargé en tant que codec Audio Compression Manager |
| `.ime` | DLL PE | Oui | `DllMain` + points d'entrée IME | L'initialisation de la DLL se produit au chargement |
| `.tsp` | DLL PE | Oui | `DllMain` + points d'entrée TAPI | L'initialisation de la DLL se produit au chargement |
| `.pyd` | DLL PE | Oui | `DllMain` + initialisation du module Python | Extension Python native |
| `.node` | DLL PE | Oui | `DllMain` + initialisation de l'addon Node.js | Addon Node.js natif |
| `.xll` | DLL PE | Oui | `DllMain` + points d'entrée Excel XLL | Chargé par `EXCEL.EXE` |
| `.wll` | DLL PE | Oui | `DllMain` + chargement de complément Word | Chargé par `WINWORD.EXE` |



## Fichiers de script
### Envisagez une requête pour ceux de la liste
| Extension | Langage / Type           | Objectif / Utilisation                                         | Contexte d'exécution                                          |
|-----------|---------------------------|---------------------------------------------------------|------------------------------------------------------------|
| .bat      | Script Batch               | Tâches d'automatisation en ligne de commande héritées, scripts simples     | `cmd.exe` (Invite de commandes)                                  |
| .cmd      | Script Batch (style NT)    | Similaire à `.bat`, préféré sur les systèmes basés sur NT         | `cmd.exe` (Invite de commandes)                                  |
| .vbs      | VBScript                   | Tâches d'automatisation, scripts d'ouverture de session, scripts d'administration           | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .vbe      | VBScript (encodé)         | Version encodée de `.vbs` pour l'obfuscation              | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .ps1      | Script PowerShell          | Tâches modernes d'automatisation et de configuration Windows       | PowerShell (`powershell.exe`, `pwsh.exe`)                   |
| .js       | JScript                    | Version Microsoft de JavaScript pour les tâches WSH          | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .jse      | JScript (encodé)           | Version chiffrée de `.js` pour l'obfuscation               | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .wsf      | Fichier de script Windows (XML)  | Mélange VBScript, JScript, autres scripts au format XML       | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .wsh      | Paramètres Windows Script Host | Paramètres de configuration pour les scripts WSH                  | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .jar      | Archive Java               | Applications Java empaquetées en un seul fichier             | `java.exe` (console) / `javaw.exe` (sans fenêtre de console)       |
| .hta      | Application HTML (HTA)     | Scripts Windows basés sur GUI utilisant HTML, CSS et JScript/VBScript | `mshta.exe` (Microsoft HTML Application Host)          |
| .com      | Application MS-DOS / Exécutable DOS | Programmes exécutables hérités, petits utilitaires en ligne de commande | Exécuté directement comme un programme ; sur Windows moderne, les programmes classiques 16 bits .com s'exécutent via NTVDM sur Windows 32 bits, et ne sont pas pris en charge nativement sur Windows x64/ARM |
| .chm     | Aide HTML compilée          | Fichiers d'aide/documentation hors ligne pour les programmes Windows   | `hh.exe` (Microsoft HTML Help Viewer)                           |

## Scripts de démarrage/ouverture de session

Les scripts de démarrage et d'ouverture de session (ainsi que d'arrêt ou de fermeture de session) sont des scripts d'automatisation qui s'exécutent (gpscript.exe) automatiquement sur les ordinateurs joints au domaine ou lorsque les utilisateurs se connectent, et ils sont couramment déployés à l'aide d'objets de stratégie de groupe (GPO) depuis un contrôleur de domaine dans un environnement Windows Active Directory.

Démarrage/Arrêt
- Exécuté en tant que : Compte Système local (privilèges élevés).

Ouverture/Fermeture de session
- Exécuté en tant que : Utilisateur actuel (privilèges élevés si administrateur).
### Utilisations courantes :
- Mappage de lecteurs réseau pour tous les utilisateurs
- Installation de logiciels
- Application de paramètres à l'échelle du système
- Démarrage ou configuration de services
- Exécution de scripts ou d'exécutables

### Ruches de registre affectées

Lorsqu'un script de démarrage/ouverture de session s'exécute via GPO :

| Ruche / Chemin | Objectif |
|-------------|---------|
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logon | Suit les scripts d'ouverture de session utilisateur, leur ordre d'exécution, leur statut, leur heure de dernière exécution et leurs paramètres. |
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logoff | Suivi similaire pour les scripts de fermeture de session. |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Startup | Informations de suivi des scripts de démarrage (s'applique à tous les utilisateurs). |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown | Informations sur les scripts d'arrêt. |

#### Recherchez des chemins inscriptibles par l'utilisateur pour les scripts et exécutables dans le processus enfant de gpscript.exe, ou des partages réseau inscriptibles ou génériques (SYSVOL). 
Lisez les scripts qui sont exécutés et vérifiez s'il existe des erreurs de configuration comme d'autres chemins inscriptibles par l'utilisateur ou des chemins qui n'existent pas ou des informations sensibles. Recherchez d'éventuels mots de passe utilisés (net use z: \\server\share /user:domain\username password) ou d'autres informations sensibles. 

**Catégories de mauvaise configuration des scripts d'ouverture de session**
- SS1 – Identifiants en clair
- SS2 – Autorisations non sécurisées (script d'ouverture de session modifiable par un utilisateur ordinaire)
- SS3 – Partages inexistants (qui peuvent être créables par un utilisateur ordinaire)
- SS4 - Administrateurs avec scripts d'ouverture de session

**Mauvaises configurations des scripts d'ouverture de session**

1. SS1 - Identifiants en clair dans un script d'ouverture de session
2. SS2 - Autorisations de partage non sécurisées
3. SS2 - Autorisations de fichier non sécurisées
4. SS2 - Autorisations NETLOGON/SYSVOL non sécurisées
5. SS2 - Autorisations de script d'ouverture de session non sécurisées
6. SS2 - Autorisations de script d'ouverture de session GPO non sécurisées
7. SS3 - Partages inexistants
8. SS4 - Administrateurs avec script d'ouverture de session
9. SS4 - Administrateurs avec scripts d'ouverture de session mappés depuis un partage inexistant



## MSIExec / Réparations MSI
##### Nos tests n'ont donné aucun résultat en matière d'élévation de privilèges dans les scénarios où nous pouvions lancer edge et nous échapper vers une invite de commandes. Cela est probablement dû au fait que les navigateurs basés sur chromium usurpent l'identité de l'utilisateur/restreignent le processus de rendu pour qu'il s'exécute en tant que SYSTEM et ne permettent pas à internet explorer/edge de lancer cmd ou d'autres processus en tant qu'utilisateur SYSTEM. Nous pensons que si aucun navigateur basé sur chromium n'est installé (comme firefox) ou des versions plus anciennes. Une élévation de privilèges pourrait être possible si vous pouviez lancer un tel processus et vous échapper de celui-ci vers une invite de commandes.

Si vous souhaitez énumérer les événements possibles liés à cela, interrogez msiexec.exe en tant que processus parent avec cmd.exe OU conhost.exe OU powershell.exe OU pwsh.exe en tant que processus enfant.
Contactez les utilisateurs dont votre requête renvoie des résultats et demandez-leur ce qu'ils ont installé/réparé. Vous pouvez également vérifier event.provider: "MsiInstaller" et event.code: (1033 OR 11707) ou similaire pour obtenir plus de contexte sur l'installateur msi qui a été installé autour du même horodatage.
Vous pouvez également essayer cela vous-même dans Software Center et installer les applications et rechercher les invites de commandes que vous pouvez mettre en pause avant qu'elles ne disparaissent en marquant une section dans la fenêtre. Puis vous échapper en utilisant les mêmes techniques mentionnées dans le lien ci-dessous.



##### Exemple de requête```
(event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1 AND winlog.event_data.IntegrityLevel: System AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))
OR
(event.provider: Microsoft-Windows-Security-Auditing AND event.code: 4688 AND winlog.event_data.TokenElevationType: "%%1936" AND winlog.event_data.MandatoryLabel: "S-1-16-16384" AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))