Bevisa exekvering av program – en guide till Windows forensik
Forensik är en vetenskaplig undersökning av spår för att kunna bevisa brott. It-forensik handlar alltså om att samla in, säkra och analysera digitala spår och bevis. Det här är den första artikeln i en serie av artiklar om undersökningsmetoder för att hitta och analysera digitala spår.
I denna artikel ska vi titta närmare på några metoder som finns för att hitta spår av exekvering av program i operativsystem Windows 10 och senare. Det finns en mängd olika källor att undersöka och tillsammans kan de ge en händelsekedja som visar på att ett program har exekverats, vilken användare som exekverat den och när det skett.
Jump List
Jump List är den funktion i Windows som ger användaren genvägar till senast eller ofta använda filer, mappar och applikationer. Exempelvis så visas en ”Jump list” i Windows 11 när du högerklickar på en applikation – filerna i ”senaste”-listan är en Jump List.
%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\*.automaticDestinations-ms
Under användarens profil hittas jumplist-innehållet. Filerna heter *.automaticDestinations-ms och är av filtypen OLE CF (Object Linking and Embedding Compound File. Det finns även jumpfiler för sådant som användaren själv ”pinnar”, dessa filer ligger i en annan mapp i \Recent\CustomDestinations\ och heter *.customDestinations-ms.

Ur dessa filer kan vi utvinna information om applikationer som exekverats samt vilka filer som öppnats i dem.
I exemplet nedan används Eric Zimmermans GUI verktyg JumpList explorer, men det finns även som kommandoradsverktyg, JLECmd om man så föredrar. Här har jag laddat in de 3 senast ändrade jumplist-filerna i verktyget och valt det andra objektet i listan som är en jumplist kopplad till applikationen Microsoft Word 2016 64-bit (App ID Description). Nedanför i gränssnittet ser vi en lista av de filer som öppnats i applikationen, varav den senaste filen är ”Entry #: 1564” som är ”Blogg forensik bevis exekvering…docx”.

Filerna som listas i Entry-listan när en jumplist är vald, är faktiskt en mängd .lnk filer (mer om det i nästa artikel….). Vid en analys är jumpfilens DestList Last Modified av intresse, eftersom det motsvarar tidsstämpeln ”senast använd” för applikationen och den specifika filen. Här kan vi alltså utläsa att den senaste filen öppnades 2025-03-24 kl 07:06:41 i applikationen Microsoft Windows 2016 64-bit.
Länkar:
- Mer läsning om OLE Compound File specifikationen från libolecf project
- JumpList Explorer från Eric Zimmerman (alternativt kommandoradsverktyget JLECmd)
Prefetch
Prefetch är en funktion i Windows för att snabba upp uppstartsprocessen av applikationer genom att förladda/cacha data.
%SystemRoot%\Prefetch\*.pf
Prefetch-filerna *.pf hittas under Windowsmappen. Varje prefetch-fil innehåller information om den exekverbara filens namn (upp till 29 tecken), antalet gånger applikationen har exekverats, information om lagringsplatsen (volym), andra filer och mappar som används vid applikationens uppstart samt prefetch-filens storlek.
I exemplet nedan används verktyget PECmd av Eric Zimmerman. I detta fall har vi matat in en specifik prefetch-fil som är associerad med WINWORD.EXE.

Det finns tre intressanta tidsstämplar att undersöka; ”Created on” som är tiden för när prefetch-filen skapades d.v.s. när applikationen exekverade första gången på volymen, ”Modified on” som innehåller den senaste exekveringen samt listan ”Other run times” som är de senaste 7 exekveringstillfällena. I skärmdumpen ovan så finns det en skillnad på ”Senast ändrad” (Utforskaren i bakgrunden) och ”Modified on” vilket orsakas av datorns lokala tidsinställning. Här kan vi exempelvis utläsa Words senaste exekveringstid WINWORD.EXE Last run: 2025:03:24 08:44:44.
Ett tips för verktyget är att om man vill processera alla prefetch-filer och få ut data i t.ex. csv format, vilket man sannolikt vill vid en analys, så används flaggorna -d <sökväg till prefetchmappen> och utdataformat –csv <filsökväg för utdata>. csv-flaggan producerar två filer, en med all information och en timeline-fil där en rad representerar ett exekveringstillfälle och innehåller kolumnerna ”RunTime” samt ”ExecutableName”. För att analysera timeline kan Timeline Explorer från Eric Zimmerman användas (se Srum-exemplet nedan för en titt på det verktyget).
Länkar:
System Resource Usage Monitor (SRUM)
SRUM, eller System Resource Usage Monitor, används för övervakning av applikationer, tjänster och nätverksanslutningar.
%SystemRoot%\System32\sru\SRUDB.dat
En del av den information som finns lagrat i SRUM-databasen presenteras i applikationen Aktivitetshanteraren. Notera att under ”Apphistorik” finns en länk att ta bort användningshistorik som ger en ledtråd till att information troligen lagras någonstans. Och vilken tur för oss att det gör det! Data lagras i en databas som heter SRUBD i 30-60 dagar, beroende på vilket data det handlar om.
Här nedan har jag kört Eric Zimmermans verktyg ScrumECmd på en kopia av SCUDB.dat och valt att skriva ut resultatet till csv-filer, detta produverar 7 csv filer med information (inklippt i hörnet).

Filerna går att öppna i Excel, men jag skulle rekommendera att analysera dem med Timeline Explorer. Analys av SRUDB-data kan ge svar på frågor om vilken typ av aktivitet som skett ungefär när, vilka tjänster som varit aktiva, vilka tjänster som nyttjat nätverket och vilken mängd data som skickats eller tagits emot. Detta i kombination med annan information kan alltså styrka en händelsekedja.
Nedan har jag öppnat NetworkUsages-filen i Timeline Explorer och utan något sammanhang så säger inte en rad särskilt mycket. Här ser vi att chrome.exe har mottagit och skickat data (vilket en webbläsare gör), även Teams har varit aktivt:

Notera att databasen skrivs till ungefär en gång i timmen, så den innehåller inga exakta tidsstämplar utan det ger en allmän lägesbild, detta kan vara av intresse om man t.ex. misstänker att en applikation har använts för att skicka eller ta emot data, men det går inte att peka på en exakt tidpunkt för en händelse.
Länkar:
BAM (Windows Background Monitor)
BAM finns för Windows 10+ och dess uppgift är att hålla koll på bakgrundsaktiviteter och värdena kopplade till denna finns i SYSTEM-registerfilen.
%SystemRoot%\System32\Config\SYSTEM
SYSTEM\CurrentControlSet*\Services\bam\state\UserSettings\{SID}
Informationen i BAM uppdateras när Windows bootar och är begränsad till de senaste ca 7 dagarna, den innehåller inte heller information om alla exekverade filer. Det kan trots sina begränsningar vara relevant information vid en utredning.
I exemplet nedan använder jag Registry Explorer för att läsa de lagrade värdena i registernyckeln.

Likt tidigare exempel så ser vi bevis av exekvering av bland annat PECmd.exe ”Execution time: 2025-03-24 kl 08:46:31” och WINWORD.EXE ”Execution time: 2025-03-24 kl 08:44:44”.
Länkar:
Analys av användarprofilinställningar NTUSER.DAT
Varje användare har en fil som lagrar inställningar för användarprofilen i sin användar-mapp, denna fil heter NTUSER.DAT och användarens registerfil. I denna lagras bland annat olika typer av värden kopplade till applikationer som är relevanta för användaren.
standardsökväg: C:\Users\<användarnamn>\NTUSER.DAT
UserAssist
UserAssist är en nyckel i NTUSER.DAT som innehåller användarens senast exekverade filer som har startats via gränssnittet Utforskaren (explorer.exe). Detta är en viktig begränsning att ha i åtanke när UserAssist analyseras.
NTUSER.DAT\Software\Microsoft\Windows\Currentversion\Explorer\UserAssist
Det finns flera sub-nycklar under UserAssist, men det är nyckeln som börjar med {CEBFF5CD…} som är intressant för exekverade program. Värdena i nyckeln är krypterade med ett enkelt substitutionsskiffer, ROT13, och nedan följer ett exempel på hur det kan se ut när man tittar på informationen i Registereditorn:

För att på ett effektivare sett analysera värden i UserAssist rekommenderas exempelvis Eric Zimmermans Registry Explorer, som automatiskt dekrypterar och tar ut intressant information åt oss och presenterar det på ett användbart sätt:

Här kan vi enkelt utläsa att PECmd.exe har ”Last Executed: 2025-03-24 08:45:47” och WINWORD.EXE ”Last Executed: 08:44:44”, som båda var ett exempel i prefetch-avsnittet.
Länkar:
- Registry Explorer från Eric Zimmerman
- Cyber Chef – ROT13 dekryptering (länk till online-verktyget, går att ladda ner och köra lokalt)
RunMRU
RunMRU (MRU är en förkortning av ”Most Recently Used”) är en registernyckel som innehåller information om de 26 senaste kommandona inmatade i ”Kör”-dialogen (Run dialog).
NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
I exemplet nedan används Registry Explorer för att öppna RunMRU-nyckeln.

Analysen av RunMRU värderna visar att ”cmd” har öppnats via Kör-dialogen ”Opened On: 2025-03-25 13:56:59”. I listan ser vi exekveringsordningen enligt värdet i ”Mru Position”.
Länkar:
Slutsats
Vid en forensisk utredning kan det finnas behov att styrka bevis med flera källor. I detta blogginlägg har jag visat att det kan finnas flera olika filer, register och databaser i operativsystemet som kan tillhandahålla information för att styrka att en applikation har exekverats. Det är också användbart att det finns alternativa källor eftersom en aktör kan önska att dölja sina spår, har vi tur så raderar de inte allt.
I många fall finns inte all data i all evighet – om det sker en incident eller annan händelse är det viktigt att ta en kopia på data för att sedan kunna analysera den i lugn och ro utan att oroa sig för att informationen raderas eller skrivs över efter en viss tid.
I nästa inlägg i denna serie tittar vi närmare på fil och mappåtkomst. Vi kommer även där stöta på andra sätt att hitta bevis på exekvering av applikationer kopplat till öppning av filer (om du undrar varför vi inte nämnt LastVisitedMRU redan här).
Mer läsning
Majoriteten av verktygen som används här är utvecklade av Eric Zimmerman och jag kan varmt rekommendera hans blogg och alla hans verktyg som du hittar på github. En annan rekommenderad referens är Harvey Cadet som har utvecklat RegRipper som är ett verktyg som processerar information i olika registerfiler (som är relevant till artikelns ämne!) och i hans blogg skriver han mycket om incidenthantering och forensik.