Coraz więcej ataków nie polega już na dostarczeniu malware w klasycznej formie. Zamiast tego napastnicy wykorzystują narzędzia, które już znajdują się w systemie i są uznawane za w pełni zaufane. Jednym z takich przykładów jest MSBuild – komponent środowiska .NET, który w normalnych warunkach służy do budowania aplikacji.

Autor: 5 min czytania

Problem polega na tym, że w odpowiednim kontekście potrafi zrobić znacznie więcej. I właśnie ten kontekst staje się dziś największym wyzwaniem dla zespołów bezpieczeństwa.

Kiedy kończy się granica zaufania

MSBuild nie jest żadnym exploitem ani podejrzanym plikiem. To legalne narzędzie, podpisane cyfrowo i obecne w wielu środowiskach developerskich. Z punktu widzenia systemu jego uruchomienie nie budzi żadnych podejrzeń. Nie oznacza to jednak, że jest bezpieczne.

Atakujący wykorzystują fakt, że MSBuild potrafi wykonywać kod zawarty w plikach projektowych. Taki plik może wyglądać całkowicie niegroźnie, a jednocześnie zawierać instrukcje prowadzące do uruchomienia złośliwego payloadu. Wszystko odbywa się w ramach legalnego procesu, bez potrzeby instalowania dodatkowego oprogramowania.

W praktyce oznacza to, że granica między normalną aktywnością a atakiem zaczyna się zacierać.

To, co wyróżnia tego typu techniki, to brak oczywistych sygnałów ostrzegawczych. Nie ma podejrzanego pliku .exe, który można łatwo oznaczyć jako malware. Nie ma też jednoznacznej sygnatury, którą da się złapać w klasycznym skanerze.

Zamiast tego mamy proces, który działa dokładnie tak, jak powinien – przynajmniej na pierwszy rzut oka.

Dopiero głębsza analiza pokazuje, że coś jest nie tak. MSBuild może zostać uruchomiony w nietypowym kontekście, z podejrzanymi parametrami albo przez proces, który normalnie nie powinien mieć z nim nic wspólnego. Może też wykonywać operacje, które nie mają sensu z perspektywy standardowego użycia.

I właśnie w tych szczegółach ukrywa się cały atak. Szczegóły techniczne i przykład takiego ataku można zobaczyć na blogu ASEC.

Nowa rzeczywistość dla SOC

Problem z wykrywaniem takich technik polega na tym, że tradycyjne metody przestają działać. Sprawdzanie reputacji pliku, hashy czy sygnatur nie daje żadnych rezultatów, bo wszystko wygląda poprawnie.

MSBuild nie jest podejrzany sam w sobie. Podejrzane jest dopiero to, jak i kiedy jest używany.

Oznacza to konieczność zmiany podejścia. Zamiast pytać, czy coś jest złośliwe, trzeba zacząć analizować, czy dane zachowanie ma sens w danym kontekście. To subtelna, ale bardzo istotna różnica.

Dla zespołów SOC oznacza to spore komplikacje. Narzędzia, które kiedyś były traktowane jako „bezpieczne z definicji”, przestają mieć taki status. Każde ich użycie musi być potencjalnie analizowane, co znacząco zwiększa ilość danych i alertów.

Jednocześnie rośnie znaczenie narzędzi, które potrafią analizować zachowanie, a nie tylko statyczne cechy plików. Relacje między procesami, kontekst uruchomienia czy nietypowe wzorce działania zaczynają mieć większe znaczenie niż sama obecność konkretnego pliku w systemie.

Przesuwa to ciężar pracy z prostego filtrowania na głębszą analizę, wymagającą zarówno lepszych narzędzi, jak i większego doświadczenia analityków.

Podsumowanie

MSBuild to tylko jeden przykład, ale dobrze wpisuje się w szerszy trend. Atakujący coraz częściej wykorzystują tzw. Living Off the Land, czyli działają w oparciu o to, co jest już dostępne w systemie. Dzięki temu mogą omijać wiele mechanizmów bezpieczeństwa, które zostały zaprojektowane z myślą o wykrywaniu zewnętrznego malware. W efekcie atak staje się trudniejszy do zauważenia i bardziej „naturalny” z punktu widzenia systemu.

To podejście nie wymaga skomplikowanych exploitów. Wystarczy dobre zrozumienie środowiska i umiejętne wykorzystanie dostępnych narzędzi.

Historia z MSBuild pokazuje, jak bardzo zmienia się krajobraz zagrożeń. Ataki przestają być oczywiste i coraz częściej ukrywają się w czymś, co na pierwszy rzut oka wygląda całkowicie normalnie. Dla obrońców oznacza to jedno: samo wykrywanie malware przestaje wystarczać. Kluczowe staje się zrozumienie kontekstu i umiejętność wychwycenia subtelnych odchyleń od normy. Bo dziś problemem nie jest już tylko to, co trafia do systemu.

Problemem jest to, co robi w systemie – nawet jeśli wszystko wygląda poprawnie.