Kolejny LOLBIN umożliwia niekontrolowane uruchomienie malware na Windows

Autor postu podaje, że za wykonanie (przy pewnych warunkach) zewnętrznego kodu odpowiada uruchamiana funkcja Windows API „CreateProcessAsUserW”. Na poniższym ekranie widać ją w kodzie.

Według autora, po ustawieniu zmiennej wskazującej na nieistniejący katalog oraz podaniu w parametrze wywołania programu ścieżki do zewnętrznego procesu (np. aplikacji notepad.exe) powinniśmy mieć możliwość uruchomienia tej aplikacji. Jako dowód, pokazane jest to na poniższym ekranie w Process Monitor’ze.

Postanowiliśmy sprawdzić, czy po prawie roku nadal występuje taka możliwość w Microsoft Windows.

Uruchomienie zewnętrznego kodu

W naszym teście będziemy starali się za pomocą „runexehelper.exe” uruchomić zewnętrzny program (kalkulator w Windows).
Pierwszym krokiem, jaki musimy wykonać to ustawienie zmiennej środowiskowej o nazwie „diagtrack_action_output”, której wartość musi odpowiadać nieistniejącemu w systemie katalogowi. Według Freddiego tylko w przypadku takiej konfiguracji kod runexehelper . exe będzie w stanie uruchomić zewnętrzny proces aplikacji, do której ścieżkę podamy w wywołaniu linii komend cmd . exe.

Ustawiamy zmienną „diagtrack_action_output”, aby wskazywała na nieistniejący katalog „Fake”.

„Set diagtrack_action_output=c:\Fake\:”

Następnie wykonujemy poniższe polecenie

Runexehelper c:\\windows\\system32\\calc.exe

Program wykonał się bezbłędnie, lecz ku naszemu zdziwieniu w procesach systemowych w Proces Monitorze nie pojawia się nowy proces, jak sugeruje wcześniej autor. Czyżby Microsoft poprawił swój błąd? Jedno jest na pewno pewne – działa ustawienie zmiennej „diagtrack_action_output” na nieistniejący katalog, bo aplikacja próbuje w nim utworzyć plik tekstowy o nazwie „runexewithargs_output.txt” Widać to na poniższym ekranie z Process Monitor’a.

Po tym zdarzeniu nie następuje jednak kolejne – uruchomienie procesu kalkulatora, którego byśmy się spodziewali. Ścieżkę do binarki kalkulatora podaliśmy we wcześniejszym wywołaniu z linii komend. Być może Microsoft poprawił ten błąd. Nie zaglądaliśmy do kodu, więc może Ty drogi czytelniku skusisz się na głębszą analizę i coś znajdziesz?