Julläsning – VBA som persistence-mekanism

Här kommer lite jullektyr som är tänkt att lysa upp lite i stugorna inför denna högtid! Denna blogg kommer beskriva hur man kan använda ett Office-dokument som persistence-mekanism i en målmiljö.

Officepaketet används av de flesta företag runt om i hela världen och inkluderar program såsom Word, Excel, Powerpoint etc. Inom säkerhetssfären så pratar vi ofta om Officepaketet när vi pratar om att leverera skadlig kod genom VBA-makron. Men vi ska visa i denna blogg att det även går att uppnå persistence genom Office-paketet genom att installera skadlig kod i dokumentmallar. Vi kommer använda Microsoft Word som exempel. Det finns fler sätt att erhålla persistence via Office-paketet, t.ex. via Office Add-ins, men det blir en annan blogg.

Standardmallen för Word heter ”Normal.dotm” och kan hittas under C:\Users\USERNAME\AppData\Roaming\Microsoft\Templates. Denna fil är det dokument som öppnas varje gång du klickar på nytt tomt dokument i Word. Det går att redigera detta dokument så att man får den stil och utseende man vill ha, vilket vi kommer göra fast för antagonistiska syften.

Innan vi går in i mallen skapar vi den skadliga koden som vi vill köra. Jag har valt att skapa en bat fil som öppnar Kalkylatorn (inte så skadligt utan i demonstrationssyfte). Genom att öppna Anteckningar (Notepad.exe) och skriva in calc.exe som enda rad i filen och kalla filen OfficeUpdate.bat för att minska risken för upptäckt.

Nu vill vi redigera Normal.dotm för att vår kod ska sättas igång varje gång Word öppnas. För att redigera Normal.dotm måste man högerklicka på ikonen och välja Öppna för annars så öppnar man ett standard Word dokument.

När vi väl har öppnat det tomma Normal.dotm så söker i sökfältet efter Visual Basic Editor och lägger in följande kod som VBA och sedan sparar filen.

Sub AutoOpen()
Dim strProgramName As String

strProgramName = "C:\Users\Dennis Sjöström\Documents\OfficeUpdate.bat"

Call Shell("""" & strProgramName & """", vbHide)
End Sub

Nu testar vi att öppna Word och vi får då upp ett tomt dokument, men Kalkylator öppnas också samtidigt.

Hmm, märkligt tänker vi, borde inte det här stoppas av makroskyddet i Office?

Vi tittar i Trust Center och ser att makron är avaktiverade så det borde inte kunna köra.

Tittar vi lite mer i Trust Center ser vi att makrot tillåts köras då den körs från en tillförlitlig plats.

Det innebär att om du har tillgång till en Windows-enhet kan du förändra Normal.dotm för erhålla persistence på en Windows-enhet i din målmiljö. Du behöver inte ens administratörsättigheter!

Nu valde jag att inte köra något skadligt men man kan tänka sig att till exempel koden istället kommunicerar med en C2-server eller liknande.

Upptäckt

Så hur ska man då kunna upptäcka detta? Attacken kräver inte administratörsrättigheter och är därmed svår att förhindra och upptäcka. Det går heller inte att blockera makron som körs från tillförlitliga platser och skulle vi periodiskt återställa mallar för att de skall förbli ”rena” så kan det påverka användare som nyttjar mallarna.

Det enklaste sättet, och bästa, är att genom Sysmon övervaka Event ID 1: Process creation och titta på förälder-barn (parent-child) relationer och på processer som härstammar från, i vårt exempel, winword.exe.

I vårt exempel så ser vi att föräldraprocessen WINWORD.EXE har startat barnprocessen OfficeUpdate.bat, mycket suspekt.

Det finns bra Sigma-regler för denna typ av aktivitet för implementering i diverse SIEM-verktyg, se Florian Roths SIGMA-repository (https://github.com/neo23x0) för mer information. Det ska dock nämnas att denna typ av attack kan kringgås genom användning av olika föräldra-barn spoofing-tekniker, men det tar vi i en annan blogg.

Inför högtiderna så vill vi på Simovits Consulting önska alla kära läsare en God Jul och ett Gott Nytt År!