Démantèlement du Smart App Control

Introduction

Les protections basées sur la réputation, comme le service de réputation d'Elastic, peuvent améliorer considérablement les capacités de détection tout en maintenant un faible taux de faux positifs. Toutefois, comme pour toute capacité de protection, il existe des faiblesses et des possibilités de contournement. La compréhension de ces faiblesses permet aux défenseurs de concentrer leur ingénierie de détection sur les principales lacunes de couverture. Cet article examine Windows Smart App Control et SmartScreen en tant qu'étude de cas pour rechercher des moyens de contourner les systèmes basés sur la réputation, puis présente des détections pour couvrir ces faiblesses.

Principaux points abordés dans cet article :

• Windows Smart App Control et SmartScreen présentent plusieurs faiblesses de conception qui permettent aux pirates d'obtenir un accès initial sans avertissement de sécurité ni fenêtre contextuelle.
• Un bogue dans le traitement des fichiers LNK peut également contourner ces contrôles de sécurité
• Les défenseurs doivent comprendre les limites de ces fonctions du système d'exploitation et mettre en place des détections dans leur pile de sécurité pour les compenser.

SmartScreen/SAC Contexte

Microsoft SmartScreen est une fonctionnalité intégrée au système d'exploitation depuis Windows 8. Il opère sur les fichiers qui portent la "Marque du Web" (MotW) et sur lesquels les utilisateurs cliquent. Microsoft a introduit le Smart App Control (SAC) avec la sortie de Windows 11. SAC est, d'une certaine manière, une évolution de SmartScreen. Microsoft affirme qu' elle "ajoute une protection significative contre les menaces nouvelles et émergentes en bloquant les applications malveillantes ou non fiables". Il fonctionne en interrogeant un service en nuage de Microsoft lorsque les applications sont exécutées. S'ils sont connus pour être sûrs, ils sont autorisés à s'exécuter ; cependant, s'ils sont inconnus, ils ne seront exécutés que s'ils ont une signature de code valide. Lorsque SAC est activé, il remplace et désactive Defender SmartScreen.

Microsoft expose des API non documentées permettant d'interroger le niveau de confiance des fichiers pour SmartScreen et Smart App Control. Pour vous aider dans cette recherche, nous avons développé un utilitaire qui affiche la confiance d'un fichier. Le code source de cet utilitaire est disponible ici.

Logiciels malveillants signés

L'un des moyens de contourner le Smart App Control consiste à signer les logiciels malveillants à l'aide d'un certificat de signature de code. Même avant le SAC, les attaquants avaient tendance à signer leurs logiciels malveillants pour échapper à la détection. Plus récemment, les attaquants ont régulièrement obtenu des certificats de signature Extend Validation (EV). Les certificats EV nécessitent une preuve d'identité pour obtenir l'accès et ne peuvent exister que sur des jetons matériels spécialement conçus, ce qui les rend difficiles à voler. Cependant, les pirates ont trouvé des moyens d'usurper l'identité d'entreprises et d'acheter ces certificats. Le groupe de menace à l'origine de SolarMarker a utilisé plus de 100 certificats de signature uniques dans le cadre de ses campagnes. Les autorités de certification (AC) devraient faire davantage pour réprimer les abus et réduire au minimum les certificats acquis frauduleusement. Des recherches publiques supplémentaires pourraient être nécessaires pour faire pression sur les autorités de certification qui vendent le plus souvent des certificats frauduleux.

Détournement de réputation

Le détournement de réputation est un paradigme d'attaque générique contre les systèmes de protection contre les logiciels malveillants basés sur la réputation. Elle est analogue à la recherche sur la confiance mal placée menée par Casey Smith et d'autres contre les systèmes de contrôle des applications, ainsi qu'à la recherche sur les pilotes vulnérables menée par Gabriel Landau et moi-même. Le détournement de réputation consiste à trouver et à réaffecter des applications jouissant d'une bonne réputation pour contourner le système. Pour fonctionner comme vecteur d'accès initial, l'une des contraintes est que l'application doit être contrôlée sans aucun paramètre de ligne de commande - par exemple, un hôte de script qui charge et exécute un script dans un chemin de fichier prévisible.

Les hôtes de script sont une cible idéale pour une attaque de détournement de réputation. C'est particulièrement vrai s'ils comprennent une interface de fonction étrangère (FFI). Avec FFI, les attaquants peuvent facilement charger et exécuter du code arbitraire et des logiciels malveillants dans la mémoire. En effectuant des recherches dans VirusTotal et GitHub, nous avons identifié de nombreux hôtes de scripts qui ont une bonne réputation et qui peuvent être cooptés pour une exécution complète du code. Cela inclut les interprètes Lua, Node.js et AutoHotkey. Un exemple de démonstration de cette technique est disponible ici.

La vidéo suivante montre un détournement avec l'utilitaire de construction JamPlus pour contourner le Smart App Control sans aucun avertissement de sécurité :

Dans un autre exemple, les avertissements de sécurité de SmartScreen ont été contournés en utilisant un interprète AutoHotkey connu :

Une autre façon de détourner la réputation d'une application connue est de l'exploiter. Cela peut être simple, comme un débordement de tampon classique dû à la lecture d'un fichier INI dans un chemin d'accès prévisible. Il pourrait s'agir de quelque chose de plus complexe qui enchaîne d'autres primitives (comme l'exécution de commandes, l'écriture dans le registre, etc.) En outre, il est possible d'enchaîner plusieurs applications connues afin d'obtenir une exécution complète du code. Par exemple, une application qui lit un fichier de configuration et exécute un paramètre de ligne de commande peut ensuite être utilisée pour lancer une autre application connue qui nécessite un ensemble de paramètres pour obtenir une exécution de code arbitraire.

Semis de réputation

Une autre attaque contre les protections de la réputation consiste à introduire dans le système des binaires contrôlés par l'attaquant. S'ils sont élaborés avec soin, ces binaires peuvent paraître inoffensifs et jouir d'une bonne réputation, tout en étant utiles aux attaquants par la suite. Il peut s'agir simplement d'un nouveau script binaire, d'une application présentant une vulnérabilité connue ou d'une application dotée d'une primitive utile. D'autre part, il peut s'agir d'un binaire contenant un code malveillant intégré, mais qui ne s'active qu'après une certaine date ou un déclencheur environnemental.

Smart App Control semble vulnérable à l'ensemencement. Après avoir exécuté un échantillon sur une machine, celle-ci a reçu une bonne étiquette après environ 2 heures. Nous avons constaté que les techniques de base de lutte contre l'émulation semblaient être un facteur permettant d'obtenir un verdict ou une réputation favorable. Heureusement, SmartScreen semble avoir une barre de prévalence globale plus élevée avant de faire confiance à une application. Un exemple de cette technique est disponible ici et est illustré ci-dessous :

Altération de la réputation

Une troisième catégorie d'attaques contre les systèmes de réputation est l'altération de la réputation. Normalement, les systèmes de réputation utilisent des systèmes de hachage cryptographiquement sécurisés pour rendre la falsification impossible. Cependant, nous avons remarqué que certaines modifications apportées à un fichier ne semblaient pas changer la réputation du SAC. SAC peut utiliser le hachage flou ou les comparaisons de similarité basées sur les caractéristiques à la place ou en plus du hachage standard des fichiers. Il peut également s'appuyer sur un modèle de ML dans le nuage pour autoriser les fichiers qui ont un score très bénin (par exemple, s'ils sont très similaires à des fichiers de qualité connue). Il est surprenant de constater que certaines sections du code peuvent être modifiées sans perdre la réputation qui leur est associée. En procédant par essais et erreurs, nous avons pu identifier les segments qui pouvaient être modifiés en toute sécurité tout en conservant la même réputation. Nous avons créé un binaire altéré avec un hachage unique qui n'a jamais été vu par Microsoft ou SAC. Il intègre un shellcode "execute calc" et peut être exécuté avec SAC en mode "enforcement" :

LNK Stomping

Lorsqu'un utilisateur télécharge un fichier, le navigateur crée un fichier "Zone.Identifier" associé dans un flux de données alternatif connu sous le nom de "Mark of the Web" (MotW). Cela permet à d'autres logiciels (y compris AV et EDR) sur le système de savoir que le fichier est plus risqué. SmartScreen n'analyse que les fichiers portant la marque du Web. SAC bloque complètement certains types de fichiers s'ils existent. Les contournements de MotW constituent donc une cible de recherche intéressante, car ils permettent généralement de contourner ces systèmes de sécurité. Des groupes de menace à motivation financière ont découvert et exploité de multiples vulnérabilités pour contourner les contrôles du MotW. Ces techniques consistaient à apposer des signatures de signature de code élaborées et non valides à des fichiers javascript ou MSI.

Au cours de nos recherches, nous sommes tombés sur un autre contournement de MotW qui est trivial à exploiter. Il s'agit de créer des fichiers LNK dont les chemins d'accès ou les structures internes ne sont pas standard. Lorsqu'ils sont cliqués, ces fichiers LNK sont modifiés par explorer.exe avec le formatage canonique. Cette modification entraîne la suppression de l'étiquette MotW avant que les contrôles de sécurité ne soient effectués. La fonction qui écrase les fichiers LNK est _SaveAsLink(), comme le montre la pile d'appels suivante :

La fonction qui effectue le contrôle de sécurité est CheckSmartScreen(), comme le montre la pile d'appels suivante :

La démonstration la plus simple de ce problème consiste à ajouter un point ou un espace au chemin d'accès de l'exécutable cible (par exemple, powershell.exe.). Il est également possible de créer un fichier LNK contenant un chemin d'accès relatif tel que .\target.exe. Après avoir cliqué sur le lien, explorer.exe recherchera et trouvera le nom .exe correspondant, corrigera automatiquement le chemin d'accès complet, mettra à jour le fichier sur le disque (en supprimant MotW) et lancera finalement la cible. Une autre variante consiste à créer un chemin à plusieurs niveaux dans une seule entrée du tableau des chemins cibles du LNK. Le tableau des chemins cibles doit normalement comporter 1 entrées par répertoire. L'utilitaire pylnk3 montre la structure d'un exploit LNK (format non canonique) avant et après son exécution (format canonique) :

Un script Python démontrant ces techniques est disponible ici.

L'illustration suivante montre un fichier LNK qui contourne les restrictions MotW sous Smart App Control pour lancer Powershell et pop calc :

Dans un autre exemple, nous montrons cette technique enchaînée avec le débogueur de ligne de commande Microsoft cdb pour obtenir une exécution de code arbitraire et exécuter un shellcode pour pop calc :

Nous avons identifié de nombreux échantillons dans VirusTotal qui présentent ce bogue, ce qui prouve qu'il existe dans la nature. Le plus ancien échantillon identifié a été soumis il y a plus de 6 ans. Nous avons également divulgué les détails du bogue au CSEM. Il est possible que ce problème soit corrigé lors d'une prochaine mise à jour de Windows. Nous publions ces informations, ainsi que la logique de détection et les contre-mesures, pour aider les défenseurs à identifier cette activité jusqu'à ce qu'un correctif soit disponible.

Détections

Le détournement de réputation, de par sa nature, peut être difficile à détecter. D'innombrables applications peuvent être cooptées pour mettre en œuvre la technique. Le catalogage et le blocage des applications dont on sait qu'elles font l'objet d'abus constituent une première étape (et une étape continue).

process where process.parent.name == "explorer.exe" and process.hash.sha256 in (
"ba35b8b4346b79b8bb4f97360025cb6befaf501b03149a3b5fef8f07bdf265c7", // AutoHotKey
"4e213bd0a127f1bb24c4c0d971c2727097b04eed9c6e62a57110d168ccc3ba10" // JamPlus
)

Cependant, cette approche sera toujours en retard sur les attaquants. Une approche un peu plus robuste consiste à développer des signatures comportementales pour identifier les catégories générales de logiciels abusifs. Par exemple, nous pouvons rechercher des noms de fonctions ou de modules Lua ou Node.js communs dans des piles d'appels suspectes :

sequence by process.entity_id with maxspan=1m
[library where
  (dll.Ext.relative_file_creation_time <= 3600 or
   dll.Ext.relative_file_name_modify_time <= 3600 or
   (dll.Ext.device.product_id : ("Virtual DVD-ROM", "Virtual Disk","USB *") and not dll.path : "C:\\*")) and
   _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info: "*!luaopen_*")] by dll.hash.sha256
[api where
 process.Ext.api.behaviors : ("shellcode", "allocate_shellcode", "execute_shellcode", "unbacked_rwx", "rwx", "hook_api") and
 process.thread.Ext.call_stack_final_user_module.hash.sha256 : "?*"] by process.thread.Ext.call_stack_final_user_module.hash.sha256

api where process.Ext.api.name : ("VirtualProtect*", "WriteProcessMemory", "VirtualAlloc*", "MapViewOfFile*") and
 process.Ext.api.behaviors : ("shellcode", "allocate_shellcode", "execute_shellcode", "unbacked_rwx", "rwx", "hook_api") and
 process.thread.Ext.call_stack_final_user_module.name : "ffi_bindings.node"

Les équipes de sécurité doivent accorder une attention particulière aux fichiers téléchargés. Ils peuvent utiliser la réputation locale pour identifier les valeurs aberrantes dans leur environnement afin de les examiner de plus près.

from logs-* | 
where host.os.type == "windows"
and event.category == "process" and event.action == "start"
and process.parent.name == "explorer.exe"
and (process.executable like "*Downloads*" or process.executable like "*Temp*")
and process.hash.sha256 is not null
| eval process.name = replace(process.name, " \\(1\\).", ".")
| stats hosts = count_distinct(agent.id) by process.name, process.hash.sha256
| where hosts == 1

LNK stomping peut avoir de nombreuses variantes, ce qui rend difficile la détection basée sur la signature des fichiers LNK. Cependant, ils devraient tous déclencher un signal comportemental similaire : explorer.exe en écrasant un fichier LNK. Ce phénomène est particulièrement anormal dans le dossier des téléchargements ou lorsque le LNK porte la marque du Web.

file where event.action == "overwrite" and file.extension : "lnk" and
 process.name : "explorer.exe" and process.thread.Ext.call_stack_summary : "ntdll.dll|*|windows.storage.dll|shell32.dll|*" and
 (
  file.path : ("?:\\Users\\*\\Downloads\\*.lnk", "?:\\Users\\*\\AppData\\Local\\Temp\\*.lnk") or
  file.Ext.windows.zone_identifier == 3
  )

Enfin, une couverture comportementale solide autour de techniques d'attaque courantes telles que l'évasion en mémoire, la persistance, l'accès aux informations d'identification, l'énumération et le déplacement latéral permet de détecter des intrusions réalistes, y compris à partir du détournement de réputation.

Conclusion

Les systèmes de protection basés sur la réputation constituent une couche puissante pour bloquer les logiciels malveillants de base. Cependant, comme toute technique de protection, elles présentent des faiblesses qui peuvent être contournées avec un peu d'attention. Smart App Control et SmartScreen présentent un certain nombre de faiblesses de conception fondamentales qui peuvent permettre un accès initial sans avertissement de sécurité et avec une interaction minimale de l'utilisateur. Les équipes de sécurité devraient examiner attentivement les téléchargements dans leur pile de détection et ne pas compter uniquement sur les fonctions de sécurité natives du système d'exploitation pour assurer la protection dans ce domaine.