Pourquoi les EDRs bloquent l'automatisation
Les EDRs (Endpoint Detection and Response) analysent le comportement des processus en temps réel. Certains patterns légitimes d'automatisation ressemblent à des comportements malveillants : injection de processus, énumération des processus actifs, modification de clés de registre, spawn de sous-processus. Sans précautions, un outil d'automatisation peut déclencher des alertes sur Cortex XDR, SentinelOne ou Defender for Endpoint même pour des tâches parfaitement légitimes.
Un EDR ne juge pas l'intention — il juge le comportement. Un script qui fait exactement la même chose qu'un malware (même sans l'être) sera traité comme tel.
Ce que détecte un EDR
Les heuristiques EDR les plus courantes qui créent des faux positifs en automatisation :
- Spawn de sous-processus en chaîne — Python → cmd.exe → powershell.exe : pattern classique de living-off-the-land.
- Écriture + exécution — écrire un fichier dans un répertoire temp puis l'exécuter immédiatement.
- Injection de DLL / code —
ctypes.windllavec chargement dynamique de modules inconnus. - Énumération de processus — parcourir la liste des processus actifs trop fréquemment.
- Modification du registre — clés sensibles (Run, Services, AppInit_DLLs).
- Réseau + exécution — télécharger puis exécuter dans la même session.
- Obfuscation base64 — commandes PowerShell encodées base64 dans des arguments.
Patterns problématiques à éviter
# ❌ Problématique : spawn cmd + powershell en chaîne
subprocess.run(['cmd', '/c', 'powershell', '-enc', BASE64_CMD])
# ❌ Problématique : écriture + exécution immédiate dans temp
script = tempfile.NamedTemporaryFile(suffix='.ps1', delete=False)
script.write(content); script.close()
subprocess.run(['powershell', script.name])
# ❌ Problématique : énumération processus en boucle rapide
while True:
procs = psutil.process_iter()
time.sleep(0.1) # trop fréquent
Patterns compatibles EDR
# ✓ Utiliser les API Python directement (pas de sous-processus)
import winreg # au lieu de reg.exe
import shutil # au lieu de robocopy via subprocess
import zipfile # au lieu de 7z via subprocess
# ✓ Si subprocess nécessaire : appeler directement l'exécutable
# sans passer par cmd ou powershell comme intermédiaire
subprocess.run([r'C:\Tools\myapp.exe', '--arg', 'val'])
# ✓ Espacer les énumérations de processus
# (AutomationSequence le fait automatiquement : min 30s entre scans)
# ✓ Signer les scripts avec un certificat de code signing
# Les EDRs font confiance aux binaires signés connus
Comment AutomationSequence V8 gère ça
AutomationSequence V8 a été développé et testé sous Cortex XDR dans un environnement hospitalier. Plusieurs décisions architecturales ont été prises spécifiquement pour la compatibilité EDR :
- Pas d'injection de code — toutes les actions utilisent des APIs Python standard (os, shutil, winreg, paramiko). Aucun
ctypesdynamique non justifié. - DispatcherTimer pour la GUI — le moteur d'actions est déclenché via un timer événementiel, pas une boucle while avec sleep. Pattern plus proche d'une application légitime.
- Pas de base64 dans les commandes — les paramètres sont passés en clair dans les appels API, jamais encodés en base64 dans des arguments de ligne de commande.
- Signature numérique des séquences — chaque séquence
.asencpeut être signée. L'EDR peut être configuré pour faire confiance aux séquences signées. - Manifest d'autorisation — un fichier XML signé déclare les capacités de la séquence, lisible par l'EDR via une règle d'exception.
Whitelisting et signatures
Si des faux positifs persistent malgré les bonnes pratiques, la procédure de whitelisting recommandée :
- Identifier le hash SHA-256 du binaire AutomationSequence (
automation-sequence.exe). - Créer une exception basée sur le hash dans la console EDR (pas une exception sur le nom de processus — trop large).
- Limiter l'exception aux machines concernées — groupe de machines, pas toute l'organisation.
- Revalider à chaque mise à jour — le hash change à chaque nouvelle version. Intégrer la mise à jour du hash dans le processus de déploiement.
# Obtenir le hash SHA-256 du binaire
automation-sequence --version-hash
# → SHA256: a3f8c2e1d4b7... version: 8.2.1
# Ou via PowerShell
Get-FileHash "C:\Program Files\AutomationSequenceutomation-sequence.exe" -Algorithm SHA256
Conclusion
La compatibilité EDR n'est pas un accident — c'est une décision de conception. AutomationSequence V8 évite les patterns comportementaux que les EDRs classifient comme suspects : chaîne cmd/powershell, écriture+exécution immédiate, injection dynamique. Pour les environnements les plus stricts, la combinaison signature numérique + manifest + exception basée sur hash SHA-256 garantit un fonctionnement sans faux positif.