Lateral förflyttning – En guide till Windowsforensik del 3

Nu har vi kommit till del 3 av artikelserien kring Windowsforensik. Vi har i Del 1 undersökt spår av applikationsexekvering och i Del 2 hur man kan bevisa filers existens på ett system. Men hur har hotaktören tagit sig dit? En angripare rör sig mellan system, exekverar kod och för över verktyg och filer mellan system för att nå sina mål. I denna bloggartikel tittar vi närmare på några metoder som kan användas i en Windows-baserad it-miljö och hur vi kan identifiera spår av sådan aktivitet vid en forensisk undersökning.

Windows levereras med några verktyg för att ansluta till fjärrsystem och för att exekvera kommandon på fjärrsystem. Här kommer vi att titta närmare på vilka spår som lämnas på ett målsystem när Windows Remote Desktop, Powershell Remoting (WinRM) och WMI/WMIC används. Värt att notera är att dessa funktioner måste aktiveras och inte är igång som standard, men oftast aktiveras i system som fjärradministreras på olika sätt.

Windows Remote Desktop (RDP)

Standardprogrammet för fjärranslutning är Windows Remote Desktop och använder sig av protokollet RDP för att skapa en anslutning från en enhet till en annan på port 3389. Aktiviteten kan identifieras genom att undersöka olika händelseloggar eller identifiera att processer relaterade till RDP anslutningen har exekverats – det är bra att kontrollera allting eftersom loggar kan roteras eller raderas, men någonstans kan det fortfarande finnas spår.

Händelseloggar

Aktiviteten kan identifieras i några olika Windows eventloggar på målsystemet:

%SYSTEMROOT%\System32\winevt\Logs\Security.evtx
%SYSTEMROOT%\System32\winevt\Logs\Microsoft-Windows-RemoteDesktopServices-RdpCoreTS%4Operational.evtx
%SYSTEMROOT%\System32\winevt\Logs\\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
%SYSTEMROOT%\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx

Security.evtx innehåller händelseoggar om autentiseringsförsök, privilegiad användning och policyförändringar. Det är alltså här vi kan utläsa om inloggningarna via RDP! I det här fallet letar vi efter lyckade inloggningar som har EventID ”4624” samt Logon Type ”10” som betyder att det har skett en fjärrinloggning med Remote Desktop (eller Terminal services). I den här händelsen finns även information om ip-adress för var anslutningen sker ifrån samt användarnamn som använts. Misslyckade inloggningar har EventID ”4625”. Andra EventID som kan vara av intresse för att identifiera RDP aktivitet är EventID ”4778” (session reconnect) och EventID ”4779” (session disconnect), i dessa events finns även värdnamn på den anslutande klienten, använd information i LogonID för att mappa till rätt session. Bilden nedan visar hur händelse med EventID 4624 där en inloggning med Remote desktop har skett:

I Microsoft-Windows-RemoteDesktopServices-RdpCoreTS%4Operational.evtx kan händelser för etablering av TCP anslutningen kopplad till RDP identifieras, loggen innehåller också vilken IP-adress anslutningen sker ifrån. Här finns EventID ”131” vilket är att RDP servern har accepterat en anslutning från en klient samt EventID ”98” som visar att en anslutning har etableras. Bilden nedan visar en händelse med EventID 131, en ny anslutning har accepterats från en specificerad källnätverksadress samt port:

Loggen Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx innehåller EventID “1149” som visar vilken användare som autentiserats samt källnätverksadressen för en lyckad autentisering via RDP.

Slutligen innehåller Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx även den information om källnätverksadress och användarnamn som försöker ansluta via RDP. Här finns EventID ”21”, ”22” och ”25” som är händelser för inloggning, sessionsstart och återanslutning samt EventID ”23” och ”24” som är händelser för frånkoppling och utloggning. Sessionerna får ett Sessions-ID vilket gör det möjligt att koppla de olika händelserna till en viss session. Bilden nedan visar att en återanslutning (EventID 25) till Session-ID 3 har skett, samt vilken källnätverksadress anslutningen har:

I tabellen nedan sammanfattas intressanta händelseloggar samt EventID för att identifiera RDP aktivitet på ett målsystem:

Eventlogg	EventID	Beskrivning
Security.evtx	4624 + Logontype 10	Lyckad autentisering med Remote Desktop/Terminal services.
	4625	Misslyckad autentisering
	4778	Återanslutning session
	4779	Nedkoppling session
RemoteDesktopServices-RdpCoreTS%4Operational.evtx	131	En RDP/TS anslutning har accepterats
	98	En RDP/TS anslutning har etablerats
TerminalServices-RemoteConnectionManager %4Operational.evtx	1149	Lyckad autententisering till med Remote Desktop Services
TerminalServices-LocalSessionManager %4Operational.evtx	21	Lyckad sessionsinloggning
	22	Shell start notifikation mottagen
	23	Sessionsutloggning
	24	Session nedkopplad
	25	Session återansluten

Övriga artefakter

I det system som initierat fjärranslutningen kan Remote Desktop klientens process mstsc.exe identifieras och på målsystemet för fjärranslutningen kan bevis kring användning av rdpclip.exe, som används för att hantera urklipp under en RDP session, eller tstheme.exe, som hanterar windows-temat under en RDP session identifieras. Referera till Del 1 för en djupdykning hur bevis på exekvering av program för att leta efter förekomsten av dessa.

Windows Remote Management (WinRM)

Powershell remoting använder WinRM tjänsten för att exekvera Powershell kommandon på ett fjärrsystem. Detta initierar en process WSMProvHost.exe på målsystemet, som sedan exekverar det kommando som skickas. Om Powershell kan användas på detta sätt rekommenderas det starkt att Powershell script block loggning aktiveras för då loggas även information om exakt vad som exekverats.

Händelseloggar

Händelser kopplade till inloggning och initiering av Powershell kan undersökas på målsystemet:

%SYSTEMROOT%\System32\winevt\Logs\Security.evtx
%SYSTEMROOT%\System32\winevt\Logs\Microsoft-WindowsPowerShell%4Operational.evtx
%SYSTEMROOT%\System32\winevt\Logs\Windows PowerShell.evtx
%SYSTEMROOT%\System32\winevt\Logs\Microsoft-WindowsWinRM%4Operational.evtx

Notera att beroende av Powershell version kan filerna också heta PowerShellCore.

Security.evtx innehåller loggar om autentiseringsförsök, privilegiad användning och policyförändringar och i detta fall letar vi efter lyckade inloggningar som har EventID ”4624” samt Logon Type ”3” som betyder att det var en nätverksinloggning. Detta ger information om användarnamn som används vid inloggningen och IP-adress för var anslutningen sker ifrån. Att detta inloggningsevent förekommer betyder däremot inte att det är Powershell remoting som används utan det finns andra anledningar att Logon Type = 3 förekommer, händelsen måste därför undersökas i kombination med andra artefakter.

Microsoft-WindowsPowerShell%4Operational.evtx innehåller Powershell aktivitet och om Powershell loggning är aktiverad innehåller Event ID ”4104” den exekverade koden. Event ID 4101 är händelsen för Script Block Logging. En mycket värdefull informationskälla – förutsatt att loggningen är aktiverad på systemet som undersöks! Event ID ”4103” (Module loggning) innehåller också viss loggning, men inte fullständig på samma sätt som Event ID ”4104”.

Windows PowerShell.evtx är en legacy version av händelseloggen för Powershell. I denna indikerar Event ID ”400” att en Powershell session startas, Event ID ”800” kan innehålla delar av skriptkoden.

Microsoft-WindowsWinRM%4Operational.evtx innehåller händelser kopplat till WinRM processen, Event ID “6” på det anslutande systemet när en anslutning initieras. Event ID ”91” skapas på målsystemet när en anslutning skapas.

Övriga artefakter

Powershell remoting med WinRM lyssnar på portarna 5985 (http) och 5986 (https), trafik på dessa indikerar potentiell användning av Powershell remoting. Vid post-mortem forensik syns inte detta, men vid live-forensik eller annan loggning kan aktiviteten upptäckas. Exekvering av processer kopplade till Powershell remoting, förekomsten av WSMProvHost.exe, kan undersökas med metoderna beskrivna tidigare.

WMI

Windows Management Instrumentation (WMI) används i normala fall för att administrera fjärrsystem men kan utnyttjas av hotaktörer för att exekvera kommandon och kod. Hotaktörerna använder ofta Powershell cmdlets för att exekvera fjärrkod, men WMI kan användas på även andra sätt. Det är WmiPrvSE.exe, ”WMI Provider Host”, som är den process som används på målsystemet för att processera kommandona som mottagits och ska exekveras.

Händelseloggar

Vanligt är att WMI används med Powershell, då kan events kopplade till inloggning och initiering av Powershell kan undersökas på målsystemet, på samma sätt som WinRM. Undersök följande händelseloggar enligt beskrivningen för WinRM:

%SYSTEMROOT%\System32\winevt\Logs\Security.evtx
%SYSTEMROOT%\System32\winevt\Logs\Microsoft-WindowsPowerShell%4Operational.evtx
%SYSTEMROOT%\System32\winevt\Logs\Windows PowerShell.evtx

Utöver detta finns det specifika händelseloggar för WMI:

%SYSTEMROOT%\System32\winevt\Logs\Microsoft-Windows-WMI-Activity%4Operational.evtx

Denna loggar händelser kopplade till WMI-aktivitet. Event ID ”5857” innehåller tidpunkt för exekvering av WmiPrvSE och sökvägen till en provider. Event ID ”5861” är en händelse för att registrera en tillfällig provider samt Event ID ”5860” är ett event för registrering till en permanent provider.

Övriga artefakter

Precis som för övriga metoder, kan bevis för exekvering av undersökas, i detta fall processen WmiPrvSE.exe.

Det finns mängder av artefakter att söka efter därefter, eftersom WinRM inte nödvändigtvis behöver användas tillsammans med Powershell, men detta lämnas till läsaren att undersöka vidare.

Slutsats

I denna bloggartikel har några metoder för lateral förflyttning presenterats och hur dessa kan upptäckas i Windows händelseloggar. Detta innebär inte att det är de enda metoderna som finns, men dessa är vanligt förekommande. Dessa verktyg används ofta i Windows-miljöer för olika typer av fjärranvändning eller fjärradministration men de kräver att funktionerna aktiveras för att fungera. Om ni inte behöver dessa funktioner – aktivera dem inte i onödan. Ett hett tips är också att alltid aktivera Powershell Script Block Logging, som loggar hela Powershellscriptet som exekveras.

Vad nästa del av En guide till Windowsforensik kommer att handla om återstår att se, så missa inte den!