Fichiers temporaires des outils d’agent : repérer et nettoyer les traces de secrets

Les fichiers temporaires d’un outil d’agent méritent la même attention qu’un dépôt de code source. Un agent de programmation peut créer un corps de requête, exécuter une commande, la relancer avec une journalisation détaillée, copier la sortie dans un cache et laisser le répertoire de travail d’origine apparemment propre. Les données sensibles sont toujours présentes sur la machine, souvent dans des emplacements que personne n’a inclus dans la revue.

L’idée reçue consiste à croire qu’un secret ne fuit que si l’agent l’affiche dans une conversation. En pratique, la fuite la plus banale vient d’une requête contenant des identifiants, copiée dans un fichier temporaire pour qu’un outil auxiliaire puisse l’envoyer, ou d’une commande ayant échoué et enregistrée dans un journal parce que quelqu’un a activé le mode de débogage la semaine précédente. Le nettoyage compte, mais la prévention compte davantage : ne donnez pas d’identifiants bruts à un agent lorsqu’un autre processus peut effectuer l’action.

Les outils d’agent créent des copies en dehors de l’arborescence de travail

Une exécution d’agent peut laisser des données à plusieurs niveaux, même si le répertoire du projet ne contient aucune trace évidente. L’arborescence de travail n’est qu’un emplacement d’écriture parmi d’autres, et les développeurs l’examinent souvent parce qu’ils la connaissent bien. L’agent, son environnement d’exécution, le shell, le gestionnaire de paquets, l’éditeur, le terminal et le système d’exploitation ont chacun leurs propres emplacements d’écriture.

Commencez par distinguer trois types de données. Les fichiers de charge utile contiennent ce que l’agent voulait envoyer, par exemple des corps de requête JSON, des lots SQL, des exports de prompts, des fichiers de correctifs ou une configuration SSH. Les fichiers de sortie contiennent ce que le système distant a renvoyé, par exemple des réponses d’API, des sorties de commande, des exports de base de données et des pages d’erreur. Les données de diagnostic contiennent les éléments associés : arguments de commande, détails de l’environnement, traces d’exécution, nouvelles tentatives et traces réseau.

Les trois catégories peuvent contenir des informations sensibles. Une charge utile peut inclure un jeton parce qu’un script l’a injecté avant l’envoi. Une sortie peut contenir une fiche client ou un secret de déploiement. Les diagnostics peuvent capturer les deux sur la même ligne. C’est pourquoi un journal de débogage cause souvent plus de dégâts que la commande qui a échoué.

Un inventaire utile couvre notamment les emplacements suivants :

• Le répertoire temporaire du processus et /private/tmp sur macOS.
• Les répertoires d’assistance, de cache et de journaux sous ~/Library.
• L’historique du shell, les exports du défilement du terminal et les wrappers de commandes.
• Les dossiers locaux au projet tels que .cache, tmp, logs, .agent et les répertoires de fixtures de test.
• Les couches inscriptibles des conteneurs, les montages liés, les espaces de travail CI et les artefacts de build téléversés.

Ne partez pas du principe qu’un agent utilise un répertoire prévisible. Les versions, plugins, environnements de programmation et chemins d’erreur peuvent faire des choix différents. Un outil peut utiliser le répertoire indiqué par TMPDIR, un auxiliaire appelé par cet outil peut utiliser /tmp, et une bibliothèque peut placer un cache dans le projet courant. La seule réponse fiable vient de l’observation de votre propre exécution.

Il en va de même pour les sorties de commande. Une redirection shell comme command > result.txt est évidente. Les journaux de multiplexeurs de terminal, les archives de débogage de gestionnaires de paquets, les fichiers de trace des clients HTTP et les fichiers de récupération d’un éditeur écrits après la modification d’un document par l’agent le sont moins. Si un agent peut appeler plusieurs outils, partez du principe que chacun possède son propre comportement de conservation jusqu’à ce que vous l’ayez testé.

Cartographiez les emplacements d’écriture réels avant de les nettoyer

Vous ne pouvez pas nettoyer correctement un chemin que vous avez mal deviné. Exécutez un agent avec un marqueur inoffensif et unique, puis recherchez ce marqueur dans les emplacements où l’exécution pourrait écrire. Utilisez des données fictives qui ressemblent suffisamment aux vraies pour suivre les mêmes chemins de code, mais n’utilisez jamais un jeton de production pour cet exercice.

Sur macOS, commencez par relever le répertoire temporaire hérité par le shell qui lance l’agent :

echo "TMPDIR=$TMPDIR"
ls -ld "$TMPDIR" /private/tmp /tmp

macOS attribue couramment à chaque utilisateur un répertoire sous /var/folders, et /tmp pointe vers /private/tmp. Le chemin généré exact n’est pas une frontière de sécurité et peut changer. Relevez sa valeur au lieu d’inscrire un chemin en dur dans un script de nettoyage.

Créez un marqueur facile à retrouver, puis demandez à l’agent d’effectuer une action représentative qui le fait passer dans un corps de requête, un argument de commande et une sortie de commande. Cet exemple utilise volontairement une chaîne qui n’est pas un secret :

export AGENT_TRACE_MARKER='TEMP-PAYLOAD-CANARY-9f2a7c'
printf '%s\n' "$AGENT_TRACE_MARKER" > /tmp/agent-canary.txt

Après l’exécution, recherchez les emplacements courants de l’utilisateur. grep peut rencontrer des fichiers binaires et des erreurs d’autorisation : utilisez-le comme outil de découverte, pas comme preuve de l’absence de toute trace.

grep -RIl --exclude='*.sqlite*' \
  'TEMP-PAYLOAD-CANARY-9f2a7c' \
  "$TMPDIR" /private/tmp \
  "$HOME/Library/Caches" \
  "$HOME/Library/Logs" \
  "$HOME/Library/Application Support" 2>/dev/null

Le résultat doit être une liste de chemins de fichiers. Pour chaque chemin, répondez à quatre questions : quel processus l’a écrit, quelle catégorie de contenu il contient, qui peut le lire et quand il disparaît. Si vous ne pouvez pas relier un fichier à un processus, examinez sa date de modification et relancez le test avec un nouveau marqueur. Ne supprimez pas d’abord les fichiers inexpliqués. Vous pourriez effacer l’indice qui indique quel composant doit être reconfiguré.

Utilisez fs_usage lorsqu’un fichier n’apparaît que brièvement. Cet outil peut montrer l’activité du système de fichiers d’un processus pendant l’exécution de l’agent :

sudo fs_usage -w -f filesystem | grep -iE 'agent|tmp|cache|log'

Cette commande produit beaucoup de bruit. Lancez-la pendant un test court, enregistrez les chemins observés en dehors d’un projet partagé, puis arrêtez-la. Un processus qui écrit et supprime un fichier en moins d’une seconde ne sera plus visible dans une liste de répertoires ultérieure, mais son contenu a peut-être déjà atteint une sauvegarde, un outil de surveillance ou un autre collecteur de journaux.

La construction des requêtes est l’endroit où les identifiants fuient le plus souvent

Le fichier temporaire le plus dangereux est souvent créé avant l’appel réseau. Beaucoup de scripts construisent une requête dans un fichier parce que les guillemets JSON sont difficiles à gérer dans un shell. Le fichier est d’abord inoffensif, puis quelqu’un ajoute un champ Authorization, un cookie ou une chaîne de connexion complète pour faire fonctionner la requête. Il devient accidentellement un conteneur durable de secrets.

Évitez ce modèle :

cat > /tmp/request.json <<'EOF'
{"endpoint":"https://api.example.invalid/export","token":"$PRODUCTION_TOKEN"}
EOF

Le heredoc entre guillemets simples ci-dessus ne développe pas la variable, ce qui peut sembler sûr. Une modification ultérieure change souvent le délimiteur ou utilise une autre méthode de construction. Surtout, cette conception habitue à placer un identifiant dans un artefact de requête. Une copie de débogage de la requête terminée le révélera.

Placez les identifiants dans la couche de transport lorsque le protocole le permet et assurez-vous que le transport n’enregistre pas les en-têtes. Les en-têtes d’autorisation HTTP sont préférables à un jeton dans une chaîne de requête, mais ils ne sont pas automatiquement sûrs. Les clients verbeux, les paramètres de proxy, les gestionnaires d’exception et le code personnalisé de nouvelle tentative peuvent toujours les enregistrer.

La spécification HTTP Semantics, RFC 9110, indique que les agents utilisateurs ne devraient pas envoyer dans l’en-tête Referer une URI contenant des informations sensibles. Cette recommandation reflète un fait plus général : les URL circulent plus loin qu’on ne l’imagine. Elles se retrouvent dans les journaux d’accès, l’historique du navigateur, les commandes copiées dans le terminal, les tickets d’assistance et les systèmes d’analyse. Ne placez pas de jetons porteurs, d’URL signées disposant d’autorisations étendues, de mots de passe ou de chaînes de connexion à une base de données dans une URL, sauf si le protocole ne laisse aucune autre possibilité et si l’identifiant expire très rapidement.

Les arguments du shell nécessitent la même prudence. Sur les systèmes de type Unix, un autre processus local peut parfois observer les arguments, selon les autorisations et les réglages de la plateforme. Les arguments peuvent aussi finir dans l’historique du shell lorsqu’une personne les copie, dans le journal d’un exécuteur de tâches ou dans la transcription des outils de l’agent. Les variables d’environnement réduisent certains chemins, mais en créent d’autres, notamment par les processus enfants hérités et les rapports de diagnostic. Aucune des deux solutions n’est un coffre-fort sûr.

La meilleure séparation est simple : l’agent demande une opération en indiquant la destination et les données non sensibles. Un détenteur distinct des identifiants ajoute l’authentification juste avant l’appel. L’agent reçoit la réponse ou une erreur expurgée, pas l’identifiant utilisé pour l’obtenir.

Sallyport applique cette séparation aux actions HTTP et SSH : l’identifiant reste dans son coffre chiffré et l’agent demande à l’application locale d’effectuer l’action. Le secret brut sort ainsi du contexte de l’agent, mais cela ne rend pas inoffensifs les corps de réponse ni les fichiers de débogage créés par l’agent. Vous devez toujours contrôler ce que l’action renvoie et l’endroit où l’agent l’écrit.

Le mode de débogage transforme les échecs ordinaires en relevés de secrets

La journalisation de débogage est utile pour diagnostiquer une intégration défaillante. Elle est aussi conçue pour conserver les éléments que la journalisation ordinaire omet. Il s’agit souvent des en-têtes, des corps complets des requêtes et réponses, des lignes de commande, des paramètres issus de l’environnement, de l’état des nouvelles tentatives et des traces d’exécution.

L’erreur consiste à laisser un indicateur de débogage général activé parce qu’un problème s’est produit une fois. Cet indicateur s’applique alors à une tâche sans rapport plusieurs semaines plus tard, lorsqu’une personne lance un export ou un déploiement avec de vraies autorisations. Le fichier qui en résulte peut se trouver dans un cache dont personne ne sait qu’il appartient à l’outil.

Traitez les diagnostics comme une catégorie de données distincte, avec une durée de vie courte et explicite. Avant d’activer une trace, déterminez la question à laquelle elle doit répondre. S’il s’agit de vérifier la résolution DNS, capturez la sortie du résolveur. S’il faut savoir pourquoi le serveur rejette un champ JSON, enregistrez le code d’état et un extrait de réponse expurgé. La journalisation complète des échanges doit rester exceptionnelle, car elle conserve des données inutiles pour résoudre le problème.

Intégrez la suppression des secrets à l’écriture, pas après coup. Une tâche de nettoyage qui recherche Authorization: dans les journaux manquera les en-têtes personnalisés, les champs JSON, les paramètres d’URL, les valeurs multilignes, les blocs base64 et les réponses contenant des secrets. Une fois que le collecteur de journaux ou le service de sauvegarde a copié le fichier non expurgé, nettoyer l’original ne suffit presque plus.

Un wrapper de diagnostic sûr possède une liste blanche des champs qu’il peut écrire. Par exemple, enregistrez la méthode HTTP, l’hôte, le chemin sans paramètres de requête, le code d’état, la durée, le nombre d’octets de la réponse et un identifiant de requête. N’enregistrez pas tous les en-têtes en promettant de masquer ensuite les mauvais. Les formats d’identifiants évoluent plus vite que les scripts de nettoyage.

Cette distinction compte avec les outils qui affichent une commande avant de l’exécuter. Afficher une commande n’est pas la même chose qu’enregistrer l’environnement effectif de la commande, et ni l’un ni l’autre ne correspond à une trace réseau. Demandez quelle représentation l’outil conserve. Il peut masquer sa sortie dans la console tout en laissant un journal détaillé intact.

Testez volontairement les chemins d’échec. Annulez une requête à mi-parcours. Envoyez un JSON mal formé. Provoquez un échec d’authentification avec un identifiant fictif. Déclenchez un délai d’attente pour exercer les nouvelles tentatives. Ces chemins créent des fichiers temporaires et des exceptions que les appels réussis ne créent pas toujours. Ce sont aussi les chemins qu’un attaquant peut provoquer pour amener un système à divulguer davantage que lors d’un fonctionnement normal.

La suppression sur macOS exige du confinement, pas un déchiquetage magique

Sur les supports modernes de macOS, la suppression sécurisée ne consiste pas à écraser plusieurs fois un nom de fichier. La répartition de l’usure des SSD, le comportement de copie sur écriture, les instantanés, la synchronisation cloud et les sauvegardes empêchent les logiciels de garantir qu’un écrasement a touché chaque copie physique. L’ancienne habitude consistant à lancer un utilitaire de déchiquetage donne l’impression que le travail est terminé, sans traiter les copies importantes.

Utilisez la suppression pour retirer les fichiers encore présents et accessibles. Utilisez le confinement pour limiter les endroits où les données sensibles peuvent exister. Utilisez le chiffrement et le renouvellement des identifiants si vous soupçonnez une exposition.

Pour un répertoire temporaire réservé à un agent, créez-le avec des permissions restrictives avant l’exécution et supprimez-le ensuite :

run_dir="$(mktemp -d "${TMPDIR%/}/agent-run.XXXXXX")" || exit 1
chmod 700 "$run_dir"
trap 'rm -rf "$run_dir"' EXIT HUP INT TERM
export TMPDIR="$run_dir"

# launch the agent from this same shell
# agent-command

L’exécution dispose ainsi d’un espace de travail temporaire connu et les sorties ordinaires le suppriment. Cela ne force pas toutes les dépendances à respecter TMPDIR et ne supprime pas le contenu copié ailleurs. C’est pourquoi l’exercice de découverte doit venir en premier.

Évitez rm -rf /tmp/* et les commandes générales similaires. Elles peuvent interrompre d’autres processus, supprimer des éléments nécessaires à une enquête et donner la fausse impression que /tmp était le seul endroit à examiner. Supprimez uniquement les répertoires créés par votre lanceur et les noms dont votre code de nettoyage peut prouver qu’il en est propriétaire.

Si un secret a pu s’échapper, renouvelez ou révoquez-le avant d’entreprendre une longue campagne de nettoyage. Un jeton API actif copié dans un journal inconnu est une voie d’accès actuelle. Son nom de fichier est moins urgent que les autorisations qu’il accorde. Recherchez ensuite les copies en aval dans les outils de sauvegarde, les lecteurs partagés, les artefacts CI, l’agrégation de journaux et les systèmes de recherche des terminaux. Supprimer l’original sans traiter les copies laisse la fuite intacte.

Le stockage local chiffré réduit les risques liés à la perte d’un appareil, mais ne protège pas contre un autre processus exécuté sous le même compte utilisateur déverrouillé. Les permissions des fichiers restent importantes. Le mode 700 d’un répertoire indique que les autres comptes locaux ne doivent pas le parcourir. Il n’empêche pas un agent déjà exécuté sous votre compte d’y accéder et n’arrête pas un client de synchronisation que vous avez autorisé à lire votre dossier personnel.

Une frontière d’identifiants élimine les charges utiles les plus dangereuses

Le nettoyage a ses limites. Si l’agent reçoit un jeton de production dans un prompt, une variable d’environnement, un fichier de configuration ou une sortie de commande, il peut placer ce jeton dans n’importe quel fichier qu’il peut écrire. Vous pouvez réduire les conséquences, mais vous ne pouvez pas rendre cette architecture sûre par un entretien plus rigoureux.

Conservez la propriété des secrets en dehors du processus de l’agent. L’agent doit exprimer une intention comme « envoyer cette demande de déploiement à ce point de terminaison approuvé » ou « exécuter cette commande SSH avec cette connexion nommée ». Un détenteur local des identifiants doit décider d’autoriser l’action, injecter l’identifiant, l’exécuter et enregistrer le résultat. L’agent n’a pas besoin d’un jeton fictif s’il n’a pas besoin du jeton lui-même.

Cela rend aussi la revue des fichiers temporaires plus précise. Vous pouvez inspecter les répertoires de travail de l’agent à la recherche des entrées utilisateur, du code généré et des données renvoyées. Vous n’avez pas à supposer que chaque fichier peut contenir tous les secrets de production accessibles à l’agent.

Un modèle d’approbation fixe présente un avantage opérationnel par rapport à un ensemble de règles personnalisées. Les personnes peuvent l’expliquer pendant un incident. Sallyport garde son coffre verrouillé jusqu’à son ouverture par authentification locale, demande une autorisation lorsqu’un nouveau processus d’agent agit pour la première fois et peut exiger une approbation à chaque utilisation de certains identifiants. Il s’agit d’un contrôle clair des autorisations, plutôt que d’une tentative de deviner si une commande générée semble suspecte.

Ne confondez pas l’autorisation d’une action et la minimisation des données. Un appel approuvé peut renvoyer un corps de réponse sensible, que l’agent peut écrire dans un fichier du projet, un cache ou une transcription. Concevez les réponses pour obtenir le plus petit résultat utile. Si une tâche n’a besoin que d’un identifiant de déploiement et d’un état, ne renvoyez pas un document de configuration complet. Si l’API prend en charge le filtrage côté serveur, utilisez-le.

SSH mérite une attention particulière, car la sortie d’une commande distante n’est pas limitée. Une commande qui lit un fichier de configuration, affiche des variables d’environnement après une erreur ou exécute un utilitaire de déploiement verbeux peut renvoyer des secrets à l’agent. Traitez la sortie SSH comme une donnée à laquelle il faut attribuer une destination, une durée de conservation et une règle de revue. L’identifiant peut être protégé tandis que la sortie renvoyée reste dangereuse.

Donnez à chaque exécution un responsable, un répertoire et une expiration

Une politique de nettoyage fonctionne lorsqu’elle rattache les fichiers à une exécution précise. Un script nocturne général ne peut pas déterminer si un répertoire temporaire appartient à un processus actif, à une tâche échouée qui mérite une enquête ou à une application sans rapport. Un lanceur d’agent le peut.

Utilisez un identifiant d’exécution dans le nom du répertoire temporaire, notez l’heure de début et conservez en dehors de ce répertoire un petit manifeste contenant uniquement des métadonnées non sensibles. Le manifeste doit indiquer quel répertoire le lanceur a créé, quel processus en est responsable, quand il doit expirer et si l’exécution est terminée. N’y placez pas les arguments de commande, les corps de requête ou les valeurs d’environnement.

Un cycle de vie pratique comporte quatre actions :

1. Créer un répertoire temporaire privé avant le démarrage de l’agent.
2. Définir les variables d’environnement de chemin temporaire pour l’agent et les auxiliaires que vous contrôlez.
3. Supprimer ce répertoire à la sortie normale et marquer le manifeste comme terminé.
4. Demander à une tâche planifiée de signaler les répertoires abandonnés qui dépassent un seuil défini, afin qu’une personne les examine.

La tâche planifiée doit signaler, et non supprimer automatiquement, les répertoires d’exécutions incomplètes. Un processus peut encore être en train d’écrire. Un déploiement échoué peut nécessiter des preuves. Une fois qu’une personne a confirmé que le répertoire est abandonné et inutile pour un incident, supprimez-le en appliquant la même règle de propriété.

Ne placez pas le répertoire temporaire dans un dépôt. La recherche dans le projet, les commandes d’état du contrôle de version, l’indexation de l’IDE, les outils de surveillance des fichiers et les clients de sauvegarde s’intéressent tous aux dépôts. Un répertoire voisin, situé dans un emplacement temporaire contrôlé par l’utilisateur, est généralement plus facile à exclure des outils de développement et à supprimer en une seule fois.

Soyez prudent avec le nettoyage automatique lancé par l’agent lui-même. Un agent capable de choisir des chemins de nettoyage arbitraires peut supprimer des fichiers source ou des preuves. Le lanceur doit construire le chemin, le conserver dans son propre état et ne supprimer que les chemins correspondant à son modèle de nommage après les avoir canonisés. L’interpolation shell dans le code de nettoyage cause déjà suffisamment d’accidents sans y ajouter la génération autonome de texte.

Le but n’est pas de ne rien conserver. Vous devez disposer d’assez d’éléments opérationnels pour déterminer quelle exécution a produit une requête et si elle a réussi. Conservez ces éléments séparément des charges utiles brutes et des sorties complètes, avec des champs volontairement simples.

Les journaux et les sauvegardes exigent une décision de conservation

Un fichier temporaire devient un enregistrement conservé dès qu’un autre système le copie. Les logiciels de sauvegarde, les dossiers synchronisés dans le cloud, les outils de protection des terminaux, les rapports de plantage, l’envoi d’artefacts CI et la journalisation centralisée peuvent tous prolonger sa durée de vie. Le chemin d’origine peut disparaître tandis qu’une copie utile subsiste ailleurs.

Listez chaque processus capable de lire les répertoires utilisés par les exécutions d’agent. Sur une machine de développement, il peut s’agir d’un client de sauvegarde, d’un indexeur d’éditeur, d’une interface de contrôle de version, d’un enregistreur de terminal et d’un antivirus. Certaines copies sont souhaitables. L’essentiel est de les choisir et de définir leur durée de conservation, plutôt que de les découvrir après l’apparition d’un jeton dans une archive de restauration.

Gardez les sorties brutes de diagnostic hors des répertoires synchronisés automatiquement. Cela inclut les dossiers du bureau, les dossiers de projet partagés et tout espace de travail qu’un client CI regroupe comme artefact. Si un outil doit produire une réponse volumineuse pour examen, stockez-la dans un répertoire privé aux permissions restreintes, définissez une date d’expiration et excluez-le de la synchronisation courante lorsque vos outils le permettent.

Un journal d’audit chaîné par hachage est différent d’une copie de débogage. Il doit indiquer qui a demandé une action, quand elle a été exécutée et quelle catégorie de résultat a été obtenue, sans dupliquer les secrets. Sallyport génère ses journaux Sessions et Activity à partir d’un journal d’audit chiffré, et sp audit verify peut vérifier la chaîne de hachage hors ligne sans clé de coffre. Il est ainsi possible de conserver des preuves de l’activité de l’agent sans traiter chaque charge utile brute comme une exigence d’audit.

La conservation doit couvrir les exceptions. Pendant un incident, ne laissez pas le délai de nettoyage habituel détruire les preuves nécessaires pour comprendre ce qui s’est passé. Restreignez l’accès, préservez volontairement les fichiers pertinents et documentez leur emplacement. Renouvelez ensuite les identifiants concernés et supprimez les éléments préservés lorsque le processus d’incident n’en a plus besoin. La conservation liée à un incident ne justifie pas de verser toutes les sorties ordinaires de l’agent dans un stockage permanent.

Examinez aussi les sauvegardes après avoir modifié la politique. L’exclusion récente d’un répertoire temporaire ne concerne que les prochaines sauvegardes. Les instantanés existants peuvent encore contenir les anciennes données jusqu’à l’expiration de la durée de conservation du fournisseur. Notez ce fait dans la réponse à l’exposition au lieu de prétendre qu’une commande rm a réécrit l’historique.

Testez le nettoyage comme le ferait un attaquant local curieux

Une politique de nettoyage qui n’a jamais été soumise à une recherche est une promesse, pas un contrôle. Testez-la avec un faux marqueur qui ressemble aux chaînes que vous craignez de perdre, puis inspectez la machine comme si un autre processus local cherchait à le retrouver.

Commencez dans des conditions normales. Placez le marqueur dans un fichier d’entrée, un champ de requête et une sortie de commande simulée. Exécutez l’agent jusqu’au bout, attendez son mécanisme de nettoyage et recherchez le marqueur dans l’espace de travail, les caches, les journaux, le répertoire du projet, l’historique du shell et les dossiers d’assistance probables. Notez chaque résultat et expliquez-le.

Testez ensuite les cas difficiles. Provoquez le plantage d’un processus. Annulez-le pendant une requête réseau. Activez la journalisation la plus détaillée prise en charge par l’outil. Lancez-le depuis un IDE plutôt que depuis un terminal. Utilisez un conteneur avec un montage lié vers l’hôte. Chaque variante peut envoyer les sorties vers un emplacement différent.

Recherchez le marqueur plutôt que le nom du fichier. Une charge utile copiée peut recevoir un nom aléatoire, entrer dans une base SQLite ou être compressée dans une archive. Si un fichier binaire ou une base de données contient le marqueur, identifiez le processus qui l’a écrit et déterminez s’il faut le configurer, l’exclure, expurger ses données ou modifier la séparation d’exécution.

Conservez un petit relevé de test avec la version de l’agent, la version du système d’exploitation, les plugins activés, les commandes exécutées, les chemins trouvés et le résultat du nettoyage. Mettez-le à jour lorsque vous ajoutez un outil capable d’exécuter des commandes ou d’envoyer des requêtes. Ce travail est banal, mais il permet de détecter des régressions qu’une revue de sécurité du code source ne verra pas.

Effectuez aujourd’hui un premier test avec un marqueur inoffensif. S’il apparaît dans un emplacement inattendu, corrigez le processus qui l’écrit avant de concevoir un script de suppression plus sophistiqué. Le fichier temporaire le plus sûr est celui qui n’a jamais reçu d’identifiant ni de réponse sensible.