Règles de réduction de la surface d'attaque pour les applications de productivité Microsoft

L'augmentation du travail à distance, ainsi que l'utilisation accrue de plusieurs appareils par les employés, créent une surface d'attaque d'entreprise en constante expansion. L'utilisation de la réduction de la surface d'attaque, ou ASR, peut aider les organisations à empêcher les acteurs malveillants d'exploiter les vulnérabilités et les faiblesses créées par ces deux variables.

Une variété de produits et de plates-formes sont disponibles pour aider à réduire la surface d'attaque. Les organisations qui cherchent à protéger et à gérer spécifiquement les points de terminaison peuvent envisager Microsoft Defender pour point de terminaison. Pour aider les professionnels de la sécurité à comprendre cette plate-forme Microsoft et ses fonctionnalités, les auteurs Paul Huijbregts, Joe Anich et Justen Graves ont écrit Microsoft Defender for Endpoint in Depth.

Le livre se penche spécifiquement sur la façon d'aborder l'ASR dans les applications de productivité courantes, y compris Microsoft Office et Outlook. Dans l'extrait suivant du chapitre 3, les auteurs expliquent comment utiliser les règles Microsoft Defender pour Endpoint ASR pour empêcher ces applications de productivité d'effectuer des actions spécifiques, telles que la création de contenu exécutable ou de processus enfants.

Téléchargez un PDF du chapitre 3 pour en savoir plus. Assurez-vous également de lire notre entretien avec Huijbregts, Anich et Graves, où ils discutent de l'utilisation de Microsoft Defender pour Endpoint pour la gestion de la posture de sécurité.

Ces règles sont utilisées pour bloquer les comportements ou les attaques qui tentent d'exploiter les applications de productivité :

Dans les attaques qui impliquent l'exploitation des vulnérabilités des processus Office ou l'abus des caractéristiques et fonctionnalités des applications Office, l'une des étapes successives courantes consiste à déposer et à exécuter un fichier malveillant sur l'appareil affecté. C'est là que l'attaquant réussit à s'introduire dans l'appareil et peut effectuer un certain nombre d'activités malveillantes à partir de ce moment.

Cette règle empêche les applications Office, Word, Excel, PowerPoint et OneNote de déposer le contenu exécutable sur le disque. Ce faisant, la règle vise à bloquer les attaques à un stade crucial où les attaquants cherchent à accéder et à prendre pied sur les machines.

Dans le cas des fichiers exécutables Windows, c'est-à-dire des fichiers exécutables portables (PE), la règle empêche uniquement l'écriture sur le disque des fichiers non approuvés et non signés. Cela évite que certains des cas d'utilisation prévus soient bloqués. Cependant, les fichiers de script sont carrément bloqués sans valider le statut de confiance ou de convivialité.

Quelques applications populaires ont déjà été exclues de la règle à l'aide d'exclusions principales ou d'exclusions globales. Cependant, pour vous protéger des attaques susceptibles d'abuser de ces exclusions, Microsoft s'est volontairement abstenu de publier une liste des applications/processus exclus. Malgré le déploiement d'exclusions globales, vous devrez peut-être toujours déployer des exclusions locales pour les applications métier internes ou tierces de première partie bloquées par la règle.

Comme mentionné précédemment, les attaquants qui utilisent les applications Office, c'est-à-dire Word, Excel, PowerPoint, OneNote et Access, comme vecteur de point d'entrée tentent souvent de télécharger et d'exécuter des fichiers malveillants sur l'appareil concerné ou les processus Office. sont utilisés pour exécuter des processus système ou des outils d'administration ou des processus tiers bénins pour approfondir ou élargir l'infection, par exemple, lancer l'invite de commande ou PowerShell pour désactiver un contrôle de sécurité important ou apporter des modifications au registre.

En tant que telle, cette règle fournit un autre contrôle important : elle empêche toutes les applications Office de lancer des processus enfants. Aucun fichier de confiance, fichier convivial, fichier système, outil d'administration ou application tierce bénigne n'est autorisé à s'exécuter.

L'injection de code dans des processus propres légitimes (principalement des processus signés) est une technique d'évasion de détection bien connue. Les processus de bureau n'ont pas été à l'abri de cette technique. Cependant, les chercheurs de Microsoft comprennent qu'il n'y a aucune bonne raison pour que les processus Office injectent du code dans d'autres processus en cours d'exécution. Cette règle empêche les processus liés aux applications Word, Excel et PowerPoint Office d'effectuer une activité d'injection de code.

Comme pour le reste des règles de l'application de productivité, cette règle prend également en charge les exclusions ASR.

La macro Office VBA est une fonctionnalité extrêmement populaire parmi les utilisateurs d'Office. Cependant, même si Office prend en charge l'appel des API Win32 à partir du code de macro VBA, la plupart des organisations n'utilisent pas la fonctionnalité aussi souvent. D'un autre côté, les attaquants peuvent l'utiliser pour effectuer une multitude d'activités malveillantes, notamment en effectuant une exécution sans fichier du code shell malveillant, ce qui le rend extrêmement difficile à détecter. Cette règle bloque l'exécution du code de macro contenant des appels d'API Win32.

La règle prend en charge les exclusions. Ainsi, les organisations qui ont besoin de macros pour effectuer des appels d'API Win32 peuvent exclure des fichiers Office spécifiques et continuer à bloquer le reste.

Comme pour les applications Office, les attaquants peuvent également utiliser diverses techniques pour effectuer des attaques à l'aide des processus Adobe Reader. Dans de telles attaques, le processus Adobe Reader lance souvent des charges utiles ou des outils d'administration supplémentaires. Cette règle bloque de telles attaques en empêchant Adobe Reader de lancer des processus enfants.

Comme pour les règles Office, quelques applications courantes ont déjà été exclues de la règle à l'aide d'exclusions globales. Comme toujours, vous pouvez également déployer des exclusions sur le client.

Ces deux règles se concentrent sur les clients de messagerie créant et lançant du contenu exécutable, ce qui est très populaire auprès des documents malveillants envoyés dans des campagnes de phishing ou de spearphishing :

L'obscurcissement des scripts (par exemple, contenant du code JavaScript/VBScript/PowerShell (PS)/macro) est une pratique courante chez les auteurs de scripts. Il fournit un moyen de masquer le contenu pour protéger les informations exclusives, car il peut parfois inclure la propriété intellectuelle. Cependant, les auteurs de logiciels malveillants abusent de cette capacité pour rendre leurs scripts malveillants difficiles à lire, à analyser et à détecter.

Cette règle recherche les propriétés qui indiquent une obfuscation et utilise des modèles d'apprentissage automatique (ML) en plus des propriétés identifiées pour classer et bloquer successivement les scripts.

Étant donné que la règle utilise des modèles ML, il y a toujours un certain degré de FP associés à cette règle. Pour atténuer l'impact négatif de ces FP, tels que les règles d'application de productivité, cette règle prend également en charge les exclusions.

Télécharger des scripts ou des binaires malveillants et les utiliser pour effectuer des activités malveillantes pendant les étapes d'une attaque est une pratique assez répandue. Comme son nom l'indique, le but de cette règle est d'empêcher les scripts JavaScript et VBScript de lancer du contenu malveillant téléchargé. Une fois activée, la règle empêche ces scripts de s'exécuter sur l'appareil protégé.

Cependant, plusieurs scénarios authentiques nécessitent des scripts pour pouvoir télécharger et exécuter du contenu hébergé. En tant que telle, la règle prend également en charge les exclusions ASR.

Ces règles visent à réduire le risque d'abus des applications de communication en tant que vecteur d'attaque initial :

Dans les attaques qui impliquent le courrier électronique comme vecteur, on constate souvent qu'une sorte de fichier exécutable malveillant est livré à l'appareil affecté sous la forme d'une pièce jointe à un courrier électronique. Par conséquent, cette règle a été créée pour bloquer tous les fichiers exécutables (tels que .exe, .dll et .scr) ainsi que les fichiers de script courants (tels que .ps1, .vbs et .js) envoyés par e-mail. Lorsque de tels e-mails sont ouverts et que l'exécutable ou le fichier de script est accessible, la règle inspecte et bloque les fichiers en question.

La règle fonctionne pour l'application client Outlook ainsi que Outlook.com et d'autres fournisseurs de messagerie Web populaires.

En général, la plupart des organisations n'approuvent pas le partage de fichiers exécutables ou de scripts par e-mail. Cependant, il existe toujours une poche d'utilisateurs ou d'appareils où l'activité est observée et successivement autorisée ou simplement ignorée. Il n'est jamais recommandé d'autoriser un tel partage par e-mail ; cependant, si vous avez besoin de l'autoriser, au moins pour un petit ensemble d'appareils, cette règle prend également en charge les exclusions ASR.

Comme mentionné précédemment, le courrier électronique a longtemps été utilisé comme vecteur de point d'entrée. Le blocage des fichiers exécutables livrés par e-mail n'est qu'un scénario parmi d'autres. D'autres scénarios populaires incluent l'exploitation de vulnérabilités ou l'utilisation abusive de failles dans l'application Outlook. Dans de tels cas, la chaîne de mise à mort d'attaque contient généralement l'application Outlook qui lance certains processus sur les appareils concernés. Dans la plupart des cas, il s'agit d'outils d'administration qui peuvent être utilisés de manière abusive pour réduire la sécurité de l'appareil et télécharger des fichiers binaires ou des outils malveillants supplémentaires nécessaires à l'attaque.

Cette règle protège contre de telles attaques en bloquant tous les processus enfants créés par l'application Outlook.

Notez que, comme pour les règles liées à Office de la section Règles de l'application de productivité, quelques applications courantes ont déjà été exclues de la règle à l'aide d'exclusions globales. La règle prend également en charge les exclusions ASR. Les utilisateurs peuvent toujours exclure les applications internes ou métier bloquées par cette règle.