Przez lata wykrywanie aktywności PowerShella było stosunkowo proste. Wystarczyło monitorować powershell.exe, analizować command line i szukać charakterystycznych parametrów, typu -enc, bypass albo hidden.

Autor: 4 min czytania

Sęk w tym, że nowoczesne ataki coraz częściej w ogóle nie używają procesu powershell.exe. Właśnie tutaj zaczyna się problem dla wielu zespołów SOC.

PowerShell nie jest pojedynczym procesem

Większość administratorów i analityków traktuje PowerShell jako konkretny proces uruchamiany z terminala. W praktyce to znacznie bardziej rozbudowany, oparty o .NET framework, który może zostać załadowany bez uruchamiania klasycznego interpretera.

To oznacza, że kod PowerShell może działać:

  • wewnątrz innych procesów,
  • z pamięci,
  • poprzez bezpośrednie wywołania bibliotek .NET,

czyli bez pojawienia się powershell.exe w telemetrii.

W takich przypadkach wiele klasycznych reguł detekcji traci swoją skuteczność.

Unmanaged PowerShell

Jedną z popularniejszych technik jest dziś tzw. unmanaged PowerShell execution. W praktyce polega to na hostowaniu silnika PowerShell wewnątrz innego procesu.

Może to być:

  • rundll32.exe,
  • msbuild.exe,
  • installutil.exe
  • albo praktycznie dowolny proces działający w systemie.

Z punktu widzenia EDR wszystko wygląda znacznie mniej podejrzanie. Nie pojawia się klasyczne uruchomienie PowerShella, nie ma typowych argumentów, a aktywność często przypomina zwykłe operacje .NET.

To idealny przykład techniki Living Off the Land, gdzie atakujący wykorzystuje legalne komponenty systemu, zamiast dostarczać własny malware.

Dlaczego atakujący coraz częściej wybierają tę metodę? Powód jest bardzo prosty – skuteczność. Wiele organizacji nadal opiera detekcję PowerShella głównie na nazwie procesu lub command line. Jeśli więc PowerShell działa w pamięci innego procesu, ogromna część telemetryki przestaje mieć znaczenie.

Dodatkowo technika dobrze współgra z obfuskacją i fileless malware. Kod może zostać pobrany z sieci, zdekodowany w pamięci i wykonany bez tworzenia klasycznych artefaktów na dysku. To właśnie dlatego PowerShell od lat pozostaje jednym z ulubionych narzędzi atakujących.

MS AMSI pomaga… ale nie rozwiązuje problemu

Microsoft próbował ograniczyć problem poprzez AMSI, czyli Antimalware Scan Interface. Mechanizm pozwala skanować kod PowerShell przed jego wykonaniem. W teorii wygląda to dobrze. W praktyce AMSI bardzo często staje się pierwszym celem bypassów. Atakujący regularnie wykorzystują patchowanie pamięci, hookowanie funkcji czy manipulację bibliotekami .NET, żeby wyłączyć lub osłabić działanie AMSI.

W efekcie organizacja może mieć włączone logowanie PowerShella i AMSI, a mimo to nie widzieć najgroźniejszych fragmentów aktywności.

Problem z telemetryką

Największy problem unmanaged PowerShell polega na tym, że wiele źródeł logów zwyczajnie go nie widzi. Jeśli organizacja opiera monitoring głównie na Event ID 4104, klasycznym Script Block Logging czy audytowaniu komend, część aktywności może przejść całkowicie niezauważona. Dlatego coraz większe znaczenie ma analiza zachowania procesu, a nie samej nazwy binarki.

Jeśli rundll32.exe nagle:

  • wykonuje operacje sieciowe,
  • ładuje nietypowe assembly .NET,
  • tworzy remote thread,
  • uruchamia payload w pamięci,

to sam brak powershell.exe nie powinien kończyć analizy.

Nowoczesna detekcja PowerShella coraz częściej opiera się na korelacji zdarzeń i analizie behawioralnej.

Znaczenie mają m.in.:

  • ładowanie bibliotek System.Management.Automation.dll,
  • nietypowe child-parent relationships,
  • memory injection,
  • tworzenie runspace’ów PowerShell wewnątrz innych procesów,
  • anomalie AMSI i ETW.

W praktyce oznacza to odejście od prostych sygnatur na rzecz analizy kontekstu. Coraz większą rolę odgrywają też Sysmon, ETW oraz telemetryka EDR, potrafiąca obserwować zachowanie procesu na poziomie pamięci i wywołań API.

Podsumowanie

Przykład unmanaged PowerShell dobrze pokazuje, jak bardzo zmienia się współczesna detekcja. Kiedyś wystarczało monitorować proces powershell.exe – dziś to już zdecydowanie za mało. Trzeba pamiętać, że PowerShell nie jest procesem. Jest frameworkiem, który może działać praktycznie wszędzie w obrębie środowiska Microsoft.