PowerShell : usages offensifs et opportunités défensives [3/3]

Retrouvez la partie 1 et la partie 2.

Quelles opportunités pour les défenseurs ?

L’usage de PowerShell par les attaquants n’a rien de neuf. Toutefois, en dépit de cette tendance affirmée et confirmée depuis des années, nombreuses sont les organisations ayant des difficultés à appréhender l’usage malveillant de PowerShell sur leur parc informatique. Comme identifié avec les précédents exemples, l’usage de PowerShell intervient souvent en “early phase”, aux premières étapes de la chaîne d’exécution d’une attaque (delivery, reconnaissance interne, déplacement latéraux, établissement de persistance…), avant l’exécution des “actions sur objectifs”. PowerShell pourra également être utilisé tout au long de l’attaque, mais cette fois dans un souci de flexibilité et d’adaptation de l’attaquant à sa cible, en permettant le « delivery » de modules complémentaires dans un timing plus tardif.

Détecter l’usage malveillant de PowerShell accroît donc les possibilités de contenir une attaque avant qu’elle soit menée à son terme.

Le challenge de la configuration

Adopter une configuration sur mesure va compliquer la tâche des attaquants et limiter les possibilités offensives s’offrant à eux. Ils seront contraints de tenter l’élévation de privilèges, afin de réajuster ces réglages. Ralentir ainsi le déroulement d’une attaque offre une fenêtre d’opportunité défensive importante. Quelques exemples :

• Installer la dernière version en date de PowerShell, et empêcher le downgrade ;
• Activer le mode ConstrainedLanguage afin d’empêcher l’Invoke de méthodes ;
• Controller l’accès à PowerShell via les Group Policies ;
• Empêcher l’usage de scripts non-signés via les GPOs.

Les « mitigations » proposées par MITRE ATT&CK peuvent donner une idée superficielle des actions à engager (ici, les M1045, M1042 et M1026).

L’indispensable journalisation

Par défaut, PowerShell ne logue quasiment rien. Dans un premier temps, la configuration de PowerShell peut donc être optimisée par l’activation de la journalisation. L’option de journalisation de blocks de scripts permet de journaliser les différentes commandes exécutées, et désobfusquées lors de leur exécution à la volée (argument de la commande `-EncodedCommand`). Cependant, elle ne fournit pas l’output des différentes cmdlets. Pour cela, il convient d’activer les transcriptions afin de journaliser l’input et l’output de chaque session, avec horodatage.

Un ‘fileless’ pas si ‘fileless’ que ça

« Invoke-Expression » permet d’exécuter des scripts récupérés sur serveurs distants, directement en mémoire, rendant l’analyse de la mémoire vive d’un poste potentiellement infecté l’un des seuls moyens de collecter des informations. Mais l’exécution « Fileless » peut malgré elle laisser des empreintes. Il existe plusieurs possibilité annexes permettant de retrouver des traces de l’exécution d’un script malveillant. Le script, s’il n’est pas récupéré sur un serveur distant, mais téléchargé sur le poste lors de l’étape de livraison (.txt, .ps1, .ps2…), pourra se retrouver dans des répertoires temporaires ; s’il n’est qu’un stage 2, il sera possible de retrouver le support de delivery (document Office avec macro, fichiers aux formats .iqy, .lnk, etc.).

La détection de schémas comportementaux

L’exécution « sans fichier » peut également être détectée par l’identification de patterns comportementaux. Le curseur dépendra de la « norme » prédéfinie en amont par les défenseurs. La détection comportementale est donc propre à chaque organisation, et à chaque utilisation (ou non-utilisation) de PowerShell. À la suite d’un audit des cas d’utilisation de PowerShell, les actions seront distinguées selon plusieurs critères :

• Elles ne sont pas intrinsèquement malveillantes, mais ne sont pas prévues comme « normales » (exemple : encodage en Base-64).
• Elles ne sont pas unitairement malveillantes, mais peuvent, si elles se multiplient ou sont précédées et succédées d’autres évènements, constituer le schéma d’un comportement malveillant (exemple : enchainement de cmdlets de reconnaissance interne, dans un temps très court/automatisé, schéma d’exécution en mémoire couplant Invoke-Expression et le téléchargement d’un script distant).
• Elles sont jugées manifestement malveillantes, avec un niveau de confiance élevé (mots-clés tels que « bypass », processus parent suspect ou absence de processus parent PowerShell, spawn de PowerShell depuis un document Office, exécutables non-signés, changement non-désiré de politique de profil, etc.).

Identifier les suites d’évènements pertinentes requiert cependant une bonne connaissance de l’utilisation de PowerShell par les modes opératoires adverses. L’analyse de l’usage de PowerShell à chaque étape de la Cyber Kill Chain© vient répondre à ce besoin. Une fois identifiés, ces comportements doivent être suivis afin d’être constamment mis à jour, mais aussi testés dans des conditions réelles dans une logique d’amélioration des défenses.

Le hunting OSINT et l’anticipation

Les attaquants ont tendance à réutiliser les mêmes snippets de code, les mêmes cmdlets, voire à employer des frameworks proposant du « prêt-à-déployer ». Pour ces cas précis, le hunting externe (à l’aide de règles YARA) permet de suivre l’évolution de leurs techniques, et les différentes campagnes en cours se basant sur PowerShell. Les recherches en sources ouvertes permettent également d’enrichir une collection de scripts PowerShell malveillants, afin de tester ses défenses à leur détection.

L’entrainement et la simulation

Intégrer l’usage de PowerShell lors de tests de sécurité (pentest ou red teaming) permet de repérer les traces laissées par l’exécution malveillante de PowerShell, et de s’entraîner à les détecter, dans le contexte de son propre parc informatique. Les tests red team et purple team de SEKOIA s’efforcent de reproduire le plus fidèlement possible les techniques adverses, telles que l’utilisation de PowerShell dans les phases de delivery et d’exploitation.