{"id":160,"date":"2021-05-16T19:50:45","date_gmt":"2021-05-16T17:50:45","guid":{"rendered":"https:\/\/theredwindows.net\/?p=160"},"modified":"2021-07-30T19:18:07","modified_gmt":"2021-07-30T17:18:07","slug":"contournement-des-protections-de-powershell-1-ep-amsi-clm","status":"publish","type":"post","link":"https:\/\/theredwindows.net\/index.php\/2021\/05\/16\/contournement-des-protections-de-powershell-1-ep-amsi-clm\/","title":{"rendered":"Contournement des Protections de PowerShell #1\u00a0: EP, AMSI, CLM"},"content":{"rendered":"\n

Microsoft n\u2019\u00e9tait clairement pas aveugle concernant l\u2019usage malveillant qu\u2019il \u00e9tait fait de son nouveau Shell. Ainsi, pour aider les d\u00e9fenseurs, l\u2019\u00e9quipe PowerShell a travaill\u00e9 sur diff\u00e9rentes protections (sur lesquelles vous pouvez bri\u00e8vement vous renseigner en consultant l\u2019article de documentation sur PowerShell, disponible sur le blog). Chacune permettant de limiter l\u2019impact de PowerShell sur un environnement Windows. Dans cet article, nous traiterons des contournements des r\u00e8gles d\u2019ex\u00e9cutions, de l’ “AntiMalware Scan Interface” et du mode de langage contraint.<\/p>\n\n\n\n

PowerShell depuis C#<\/h2>\n\n\n\n

A plusieurs reprises dans l\u2019article, on aura la n\u00e9cessit\u00e9 de contr\u00f4ler les instructions que PowerShell ex\u00e9cute. Pour r\u00e9soudre ce probl\u00e8me, on va simplement construire un programme C# qui utilise System.Management.Automation.dll<\/code>. On va dans un premier temps indiquer que le programme utilisera les namespaces System.Management.Automation<\/code> pour le c\u0153ur de PowerShell et System.Management.Automation.Runspaces<\/code> qui permet de rendre persistante les entr\u00e9es (si on cr\u00e9e une variable, elle est sauvegard\u00e9e en m\u00e9moire). On d\u00e9finit deux m\u00e9thodes, la premi\u00e8re lance simplement une commande PowerShell unique en utilisant un objet de la classe PowerShell et la m\u00e9thode .Invoke()<\/code><\/code>. La deuxi\u00e8me cr\u00e9e un runspace, puis lui ajoute une pipeline qui permet l\u2019ex\u00e9cution d\u2019une commande PowerShell via la m\u00e9thode d\u00e9j\u00e0 cit\u00e9e.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

ExecutionPolicy<\/h2>\n\n\n\n

Officiellement l\u2019ExecutionPolicy est d\u00e9fini ainsi\u00a0: “La strat\u00e9gie d\u2019ex\u00e9cution de PowerShell est une fonctionnalit\u00e9 de s\u00e9curit\u00e9 qui contr\u00f4le les conditions dans lesquelles PowerShell charge les fichiers de configuration et ex\u00e9cute des scripts”. C\u2019est cette derni\u00e8re qui vous interdit donc, dans un syst\u00e8me natif, d\u2019effectuer des commandes comme PS>.\\script.ps1<\/code> . En r\u00e9alit\u00e9 il ne s\u2019agit pas vraiment d\u2019une protection, un script n\u2019est rien de moins qu\u2019une cha\u00eene de caract\u00e8re interpr\u00e9t\u00e9e pr\u00e9sente dans un fichier. Un contournement de cette restriction serait Invoke-Expression $(Get-Content .\\script.ps1)<\/code><\/code> ou de faire un DownloadCradle. S\u2019il est souhait\u00e9 de pouvoir s\u2019affranchir directement au lancement, PowerShell propose un argument -ExecutionPolicy<\/code> (abr\u00e9g\u00e9 exec<\/code>) qui permet de contr\u00f4ler les r\u00e8gles d\u2019ex\u00e9cutions adopt\u00e9es pour la session qui s\u2019ouvrira. Il n\u2019est absolument pas n\u00e9cessaire d\u2019\u00eatre administrateur pour pouvoir influer sur cet argument, ainsi lorsqu\u2019on lui fournit la valeur “Bypass”, PowerShell appliquera cette ExecutionPolicy qui nous autorise le lancement de script. S\u2019il est souhait\u00e9 de contourner cette restriction en “RunTime”, alors on peut utiliser ceci\u00a0:<\/p>\n\n\n\n

Set-ExecutionPolicy Bypass -Force -Scope Process\n\n# ou pour faire styl\u00e9\n\n$ctx = $ExecutionContext.GetType().GetField(\"_context\",\"NonPublic,Instance\").GetValue($ExecutionContext)\n$ctx.GetType().GetField(\"_authorizationManager\",\"NonPublic,Instance\").SetValue($ctx, (New-Object System.Management.Automation.AuthorizationManager(\"Microsoft.PowerShell\")))<\/pre>\n\n\n\n
Je ne d\u00e9taillerai pas l\u2019origine de ces courtes lignes et pourquoi elles permettent de contourner la restriction souhait\u00e9e car ce n\u2019est pas le plus int\u00e9ressant et comme mentionn\u00e9, l\u2019ExecutionPolicy est une restriction et non une protection. De surcro\u00eet en RedTeam on \u00e9vite le plus possible de d\u00e9poser des fichiers\/binaires sur le disque.<\/p>\n\n\n\n
AMSI<\/h2>\n\n\n\n
L\u2019AMSI (pour “AntiMalware Scan Interface”) est une solution apport\u00e9e par Microsoft pour pouvoir analyser le contenu de la m\u00e9moire afin de parer au mieux les attaques usant de langage de Scripting tel PowerShell, Jscript, VBA et plus r\u00e9cemment certaines API .NET. <\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Il s\u2019agit d\u2019une DLL situ\u00e9e en C:\\Windows\\System32\\amsi.dll<\/code> et qui n\u2019a pas \u00e9t\u00e9 con\u00e7ue en C#. Pour PowerShell, son impl\u00e9mentation se situe comme habituellement dans System.Management.Automation.dll<\/code>, et cette derni\u00e8re est une dll .NET. On lance ILSpy et on d\u00e9compile la dll sus-mentionn\u00e9e depuis GAC et on regarde la classe AmsiUtils<\/code>. <\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Cette derni\u00e8re charge plusieurs fonctions de amsi.dll<\/code>. Certaines parties de la classe semblent plus int\u00e9ressantes que d\u2019autres: la d\u00e9finition des variables de la classe et la m\u00e9thode ScanContent<\/code>. <\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
On charge dans DNSpy notre runspace PowerShell ainsi que PowerShell.exe et ajoutons les points d\u2019arr\u00eat suivants directement dans Sysem.Management.Automation<\/code>:<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Ainsi les points d\u2019arr\u00eat suivants dans notre m\u00e9thode RunspaceExec<\/code>:<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
En suivant l\u2019ex\u00e9cution d\u2019une commande, on remarque que notre commande est pass\u00e9e \u00e0 ScanContent<\/code> qui dans un premier temps va v\u00e9rifier si l\u2019AMSI est bien en place avant que l\u2019antivirus analyse notre instruction et retourne si oui ou non elle a le droit d\u2019\u00eatre ex\u00e9cut\u00e9e.<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
On peut alors \u00e9tudier le comportement de PowerShell lorsque des commandes plus agressives sont donn\u00e9es.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
La technique mise en place n\u2019est finalement pas magique, si la fonction ScanBuffer<\/code> n\u2019est pas appel\u00e9e, l\u2019antivirus est totalement aveugle \u00e0 ce qu\u2019il se passe. On remarque en revanche que certains court-circuits existent. Si l\u2019AMSI n\u2019est pas correctement initialis\u00e9e, la variable de classe amsiInitFailed<\/code> est mise a true<\/code> qui r\u00e9sultera en le retour syst\u00e9matique de AMSI_RESULT NOT_DETECTED<\/code>. Or nous avons le total contr\u00f4le sur la m\u00e9moire de notre processus, mieux encore, les possibilit\u00e9s d\u2019interaction avec .NET nous permettent de modifier le comportement intrins\u00e8que de PowerShell. Construisons un Bypass. Comme vous l\u2019aurez peut-\u00eatre remarqu\u00e9, la classe AmsiUtils<\/code> est une classe priv\u00e9e, c\u2019est-\u00e0-dire qu\u2019elle n\u2019est pas accessible ais\u00e9ment depuis l\u2019ext\u00e9rieur de la dll. En revanche, le type est toujours utilisable ce qui nous permet d\u2019acc\u00e9der \u00e0 la classe AmsiUtils<\/code> en utilisant une r\u00e9f\u00e9rence \u00e0 l\u2019assembly<\/code> ce qui peut \u00eatre fait comme ceci\u00a0:<\/p>\n\n\n\n
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')<\/pre>\n\n\n\n
En utilisant la m\u00e9thode .GetField()<\/code><\/code>, on peut acc\u00e9der \u00e0 amsiInitFailed<\/code>, ce qui nous permet de manipuler sa valeur:<\/p>\n\n\n\n
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed', 'NonStatic,Public').SetValue($null, $true)<\/pre>\n\n\n\n
Ce bypass nous provient de Matt Graebers<\/a>, qui l’a publi\u00e9 dans un tweet et a donc utilis\u00e9 tout les moyens possibles pour le maintenir concis. Pour l\u2019offusquer par exemple, changer l\u2019acc\u00e9l\u00e9rateur de type ou la classe pour acc\u00e9der \u00e0 System.Management.Automation<\/code> est une excellente id\u00e9e (puisque c\u2019est g\u00e9n\u00e9ralement cela qui est flag)\u00a0:<\/p>\n\n\n\n
[PSObject].Assembly\n(New-Object PSObject).GetType().Assembly \n([System.AppDomain]::CurrentDomain.GetAssemblies() | ? {try{$_.Location.Contains(\u2018Automation\\\u2019)} catch {}})<\/pre>\n\n\n\n
En r\u00e9alit\u00e9 il est simplement exig\u00e9 d\u2019obtenir une r\u00e9f\u00e9rence de type RuntimeAssembly<\/code> \u00e0 System.Management.Automation<\/code>. Avec un peu d’offuscation, on parvient \u00e0 contourner l’AMSI.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Cette m\u00e9thode, bien que rapide, a depuis perdu beaucoup de son efficacit\u00e9. Defender \u00e9tant particuli\u00e8rement \u00e0 l\u2019aise pour d\u00e9tecter ce dernier (m\u00eame offusquer par moment). Ainsi on voudrait trouver une autre mani\u00e8re pour proc\u00e9der. Retournons voir le code de la classe AmsiUtils<\/code>. Une variable relativement \u00e9trange est cr\u00e9\u00e9e AmsiContext<\/code>, qui est pass\u00e9 en argument \u00e0 ScanBuffer<\/code>. On lance Ghidra et on regarde \u00e0 quoi correspond cette valeur. <\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Rapidement on trouve que si cette derni\u00e8re est diff\u00e9rente de 0 alors une erreur est lev\u00e9e (la valeur 0x80070057<\/code> est retourn\u00e9e, qui est un code HRESULT<\/code> signifiant qu’un argument est invalide) et l\u2019analyse de notre commande n\u2019est pas effectu\u00e9e. En utilisant le m\u00eame proc\u00e9d\u00e9 de changement de variable que le bypass pr\u00e9c\u00e9dent il vient naturellement:<\/p>\n\n\n\n
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiContext', 'NonPublic,Static').SetValue($null, [System.IntPtr]::new(1234))<\/pre>\n\n\n\n
Vous l\u2019aurez compris, ces bypass ne s\u2019appliquent uniquement qu’\u00e0 PowerShell ce qui peut donc poser probl\u00e8me pour les autres langages de Scripting ou d\u00e9sormais du chargement d\u2019assembly<\/code> .NET. Puisque depuis la version 4.8, la m\u00e9thode [System.Reflection.Assembly]::Load()<\/code><\/code> (qui permet le chargement en m\u00e9moire d\u2019assembly .NET) est surveill\u00e9e par l\u2019AMSI.<\/p>\n\n\n\n
ConstrainLanguageMode<\/h2>\n\n\n\n
Sous PowerShell il existe principalement 4 types de “langage” d\u2019ex\u00e9cution. Ces derniers changent notre rapport au Scripting et \u00e0 l\u2019interaction avec .NET:<\/p>\n\n\n\n