Minnesforensik och SODDI försvaren: Tillvägagångssätt för att bemöta ett tekniskt SODDI försvar

(1)

Kandidatuppsats

IT-forensik och informationssäkerhet 180 hp

Minnesforensik och SODDI försvaren

Tillvägagångssätt för att bemöta ett tekniskt SODDI

försvar

IT-forensik 15 hp

Halmstad 2020-05-25

(2)

(3)

ii

Minnesforensik och SODDI försvaren

Tillvägagångssätt för att bemöta ett tekniskt SODDI försvar

Robin Elgström och Emil Andersson

Examensarbete teknologie kandidat

Akademin för informationsteknologi

Högskolan i Halmstad

Handledare: Stefan Axelsson

Examinator: Eric Järpe

(4)

(5)

iv

Abstract

This work has conducted through experiments and analysis where Windows 10 has been the main operating system. Throughout the work common artifacts available in RAM has been discussed and experimented with in order to see if these can be linked to specific user accounts. Through analysis and examinations this work has demonstrated, both theoretically and practically albeit in a simplified form how malware can be detected through memory analysis. Results from experiments and analysis that have been carried out are then presented with approaches for how this knowledge could possibly be used in the approach of a

(6)

(7)

vi

Sammanfattning

Det här arbetet har utförts genom experiment och analyser där Windows 10 har varit det huvudsakliga operativsystemet. Arbetet har utforskat vanligt förekommande artefakter som kan hittas i RAM-minnet för att se om dessa kan kopplas till specifika användare.

Undersökningar i arbetet har påvisat både teoretiskt och praktiskt om än i en simplifierad form hur malware kan upptäckas genom minnesanalyser. Genom resultat ifrån utförda

experiment och analyser presenteras sedan tillvägagångssätt för hur denna kunskap eventuellt skulle kunna nyttjas vid bemötandet av ett tekniskt SODDI försvar.

(8)

(9)

viii

Innehållsförteckning

Ordlista ... x 1 Introduktion ... 1 1.1 Inledning ... 1 1.2 Syfte ... 2 1.3 Bakgrund ... 2 1.3.1 Relaterade arbeten ... 2 1.4 Positionering ... 3 1.5 Problemformulering ... 4 1.5.1 Problematisering ... 4 1.5.2 Avgränsningar ... 5 2 Metod ... 7 2.1 Litteraturundersökning ... 7 2.2 Experiment ... 7 2.3 Positionering ... 7 2.4 Alternativa metodval ... 8 2.5 Motivering av metodval ... 8 2.6 Problematisering ... 9 3 Teori ... 11

3.1 Random Access Memory (RAM) ... 11

3.1.1 Virtuellt minne ... 12

3.1.2 Paging ... 12

3.1.3 Access tokens ... 12

3.2 Malware i minnet ... 13

3.2.1 Process injektioner ... 14

3.2.2 Praktisk malware detektering ... 14

3.3 Volatility ... 15

3.3.1 Pstree, Pslist och Psscan ... 15

3.3.2 Getsids ... 16

3.3.3 Memdump och Procdump ... 16

3.3.4 Cmdscan ... 16

3.3.5 Malfind ... 16

(10)

ix

3.4.1 Att ta ställning till SODDI försvaret ... 17

4 Experiment ... 19

4.1 Program och verktyg ... 19

4.2 Experimentuppställning (1) ... 19

4.2.1 Avgränsningar ... 20

4.2.2 Scenario och tillvägagångssätt ... 21

4.2.3 Analysmetod ... 21

4.3 Experimentuppställning (2) ... 23

4.3.1 Avgränsningar ... 23

4.3.2 Scenario och tillvägagångssätt ... 23

5 Resultatredovisning ... 25

5.1 Resultat - Experiment (1) ... 25

5.1.1 Del 1 ... 25

5.1.2 Del 2 ... 27

5.3 Resultat - Experiment (2) ... 28

5.4 Resultatens betydelse för SODDI ... 29

6 Diskussion ... 31 6.1 Resultatdiskussion ... 31 6.2 Metoddiskussion ... 33 6.3 Framtida arbeten... 33 7 Slutsats ... 35 Referenser ... 37 Bilagor ... 39

Bilaga 1 (Experiment 1, del 1) ... 39

Bilaga 2 (experiment 1, del 2) ... 42

(11)

x

Ordlista

Volatility

Ett CLI (Command Line Interface) verktyg som användes för att läsa och analysera minnesdumpar.

Plugin

Plugins defineras som tilläggsmoduler till Volatility som används för att utföra specifika ändamål, i detta arbete. Till exempel identifera processer (pslist) och se körde CMD kommandon (cmdscan).

Minnesdump

En datafil bestående av en fysisk avbildning av RAM-minnet som det ser ut just vid inhämtningstillfället.

Malware

Malware är ett samlingsnamn för skadlig programvara och involverar virus, trojaner, maskar, rootkits, spyware, med mera.

Opensource

Opensource är benämning som beskriver datorprogram skrivna med öppen källkod vilket medför att den som vill kan läsa eller ändra i källkoden. CMD

CMD eller kommandotolken är Windows terminalfönster som tillåter en användare att utföra specifika kommandon via ett textbaserat gränssnitt. Carving

Carving eller file carving, är en process där filer eftersöks i en dataström baserat utifrån kända fil headers. Headers är kända strängar eller kod som specifika filtyper startar med.

Hexeditor

En hexeditor är ett program som tillåter läsning och redigering av filer som representeras i ett hexadecimalt format.

Artefakt

Ordet artefakt kan ha lite olika betydelser inom IT-forensiken, men tolkas i detta arbete till data som kan hjälpa till att leda en utredning framåt.

(12)

(13)

1

1 Introduktion

Det här arbetet är skapat i syfte att bemöta ett av det äldsta och mest igenkända försvaren, det så kallade SODDI försvaret, Some Other Dude Did It. Även vid kriminella utredningar kring IT-brott förekommer detta försvar och kan då kallas för tekniskt SODDI försvar, ett av de mest kända tekniska SODDI försvaren är det så kallade The trojan horse defense. Arbetet har undersökt hur man med hjälp av att analysera en dators RAM-minne möjligen kan stärka eller motbevisa SODDI försvaret för olika situationer.

Rapportens första kapitel ger läsaren en inledning till ämnet, beskriver arbetets syfte och dess problemställning, detta följs av metoden som använts för att besvara frågeställning. Experiment är den huvudsakliga metoden för arbetet och för att ge läsaren en bättre förståelse av dessa finns ett kort teorikapitel. Teorikapitlet är skapat för att ge läsaren en bakgrundsförståelse om varför experimenten utförts och hur relevant data i förhållande till frågeställningen kan utvinnas ifrån minnet. Teorikapitlet följs av ett separat

experimentkapitel, där en genomgång av utförda experiment presenteras och förklaras. Resultat kapitlet som följer experimenten är indelade efter det utförda experimenten och ställs sedan emot den givna frågeställningen. Arbetet avslutas sedan med en diskussion och slutsats om det gångna arbetet och dess innebörd.

1.1 Inledning

Forensiska analyser av RAM har utförts sedan början av 2000-talet och anses fortfarande som ett relativt nytt område. Det är en del av IT-forensiken som är under ständig utveckling och det finns ett behov av ytterligare forskning inom området. Analyser av RAM-minne kan nyttjas för att hitta malware, webbläsarhistorik, data som har raderats eller skrivits över samt data som inte sparas till hårddisken [1, 2, 3]. Eftersom allt som en användare gör på en dator passerar datorns minne (även om det inte sparas till hårddisken) så kan det finnas information där som är väsentlig att utvinna för att driva en utredning framåt.

Det gamla och vanligt förekommande SODDI försvaret innebär att en misstänkt person skyller ifrån sig och säger att någon annan är ansvarig för handlingen (Some Other Dude Did It). I dagens utredningar förekommer det allt mer teknisk utrustning som måste

undersökas av IT-forensiker och SODDI försvaret förekommer även här. Misstänkta skyller ifrån sig på att de har blivit hackade, att det måste ha varit “virus” eller att någon annan har utnyttjat utrustningen. I det fall när den misstänkta skyller på någon form av malware kallas försvaret ibland istället för The trojan horse defense. Detta utifrån att man skyller ifrån sig på den vanligt förekommande malware typen trojan [11].

Experiment och analyser urfördes för att besvara den givna frågeställningen och undersökt hur malware kan detekteras, hur processer kan kopplas till användare och om olika

(14)

2

1.2 Syfte

Arbetets syfte var att belysa, hur och när minnesforensik kan nyttjas effektivt för att bemöta ett SODDI försvar genom att testa tidigare kunskap inom området. Förhoppningen med arbetet var att med hjälp av minnesanalys identifiera artefakter, användarkonton processer och malware. För att kunna bidra till och skapa förståelse för olika tillvägagångssätt för att bemöta ett eller flera typer av SODDI försvar, men också för att generellt stärka kunskapen om minnesforensiken.

1.3 Bakgrund

Minnesforensiken hade sin begynnelse i början av 2000-talet, minnet kunde då undersökas genom /dev/mem i Linux och Mac OSX och i Windows genom \Device\PhysicalMemory. Verktyg hade ännu inte utvecklats specifikt för att undersöka RAM och analytiker förlitade sig på verktyg som strings, grep och hexeditors för att manuellt undersöka minnets

innehåll. Dessa äldre metoder har än idag sitt värde trots dess ostrukturerade analysmetod men bör bistås av och förstärks av en strukturerad analys [3].

SODDI (Some Other Dude Did It) är ett vanligt och gammalt försvar som ofta används i rättsliga sammanhang av den som är misstänkt för brott. Försvaret har tidigare nyttjats i undersökningar av IT-relaterad brottslighet som barnpornografibrott eller fildelning. Detta försvar går generellt ut på att skapa rimligt tvivel om att den misstänkte har begått brottet i fråga. Inom IT-brott kan det förekomma i form av att den misstänkte hävdar att andra personer med tillgång till systemet har genomfört brottet, bevisen på datorn är planterade av en okänd person eller att polisen i undersökningen har planterat bevis. The trojan horse

defense är det vanligaste typen av tekniskt SODDI försvar där den misstänkte då hävdar att

bevisen planterats av ett virus på datorn vilket också har förekommit i flera dokumenterade fall [13]. Det kan också hävdas att ett virus eller en okänd aktör har haft kontroll över systemet och utfört den brottsliga aktiviteten. Det är därför inte den misstänkte som bär ansvar för det brott som begåtts eller utfört dessa handlingar [9, 10, 11].

1.3.1 Relaterade arbeten

Ett av de mer utförliga arbetena gällande minnesforensik är boken Art of memory forensics [1]. Boken ger en utförlig beskrivning av hur RAM-minnet fungerar, byggs upp och hur det interagerar med de övriga komponenterna i en dator. Boken är uppdelad i fyra delar, där första delen är en introduktion till minnesforensik och hur RAM fungerar. Det övriga tre delarna fokuserar på hur minnet kan utvinnas och analyseras i det tre stora operativsystem (Windows, Linux och OSX). Det här arbetet har dragit nytta av främst den första delen av boken för att få en djupare förståelse om hur RAM fungerar och nyttjas av operativ systemet Windows, detta reflekteras till viss del i teorikapitlet.

Stefan Vömel skrev sin doktorsavhandling Forensic Acquisition and Analysis of Volatile

(15)

3

uppbyggt och fungerar. Han beskriver även ingående ett flertal metoder för utvinning av RAM-minne ihop med deras fördelar, nackdelar och tillgänglighet. Arbetet diskuterar även minnesanalyser med fokus kring en rad olika ämnen bland annat hur malware och rootkits kan detekteras.

Chad Steel beskriver i sin publicerade artikel Tehcnical SODDI Defenses: The trojan Horse

Defense Revisited [11], hur The trojan horse defense har nyttjats mindre under de senare

åren och blivit en del av det bredare och mer allmänna tekniska SODDI försvaret. Steel förklarar att det tekniska SODDI försvaret syftar på bredare möjligheter än det klassiska

trojan horse defense. Tekniska SODDI försvaret täcker möjligheter som till exempel att

okända aktörer med hjälp av osäkrat WIFI eller fysisk tillgång till maskinen utför kriminella handlingar. Arbetet visar på vilka typer av brott som det tekniska SODDI försvaret och det tidigare mycket vanliga trojan horse defense använts vid och hur effektivt det varit genom tiderna för olika typer av brott och i specifika fall. Slutsatser och

konstateranden görs också kring civila copyrightbrott då det har visat sig vara en väldigt effektiv försvarsstrategi på det sättet att det ökar bevisbördan mot den anklagade till den graden att det till slut inte är kostnadseffektivt för målsägande att fortsätta med utredningen. Susan W. Brenner, Brian Carrier och Jef Henninger skriver i sin publicerade artikel The

Trojan Horse Defense in Cybercrime Cases [13], om hur the trojan horse defense tidigare

använts i rättsfall och vilken betydelse det har när försvaret lyfts fram av den anklagade. Den ytterligare bevisbörda som i de flesta fall faller på åklagarsidan då detta försvar nyttjas och vilka tillvägagångssätt som bör användas för att på bästa sätt kunna ta ställning till försvaret. Aspekter som ifall det finns skadlig kod eller inte, tid och förmåga att utföra brottet belyser författarna också i syfte att bemöta the trojan horse defense.

1.4 Positionering

Arbeten som är i direkt relation med den givna frågeställningen i detta arbete har inte upptäckts. Däremot finns den en del arbeten som relaterar mer eller mindre indirekt till denna studie. Chad Steel [11], har skrivit ett arbete med diskussioner kring the trojan horse

defense men inget angående minnesanalyser eller sätt att ta ställning till det. Detta gäller

också för “The Trojan Horse Defense in Cybercrime Cases” [13], där författarna beskriver

the trojan horse defense, ger exempel på fall där det använts och vilka implikationer det har

för åklagare i fall som dessa.

Andra arbeten som istället fokuserar på minnesanalyser tar inte specifikt upp SODDI försvaret eller the trojan horse defense i relation till minnesforensik [1–6, 8]. Tidigare tekniska arbeten där det demonstreras hur minnet kan undersökas i förhållande till

processer och ägare av dessa processer finns [1]. Det finns också flertal arbeten som går in på analys av malware [1, 4, 12].

Det här arbetet syftar till att kombinera dessa olika områden då det kan anses vara relaterade och kan nyttjas tillsammans. Genom detta utförs också en verifiering av de

(16)

4

tidigare tekniska arbeten som gjorts då detta arbete utförs i nyare miljöer. Eftersom IT snabbt förändras och uppdateras anses detta relevant då mycket av det som skrivits och gjorts är några år gammalt.

1.5 Problemformulering

Det finns begränsat med dokumentation om hur olika användares processer i minnet kan separeras, framförallt då flera unika användare har nyttjat samma system. Information gällande malware i minnet är däremot mycket mer välstuderat och dokumenterat, men inte i relation till SODDI. Därför vill detta arbete kombinera denna information och visa hur detta potentiellt kan nyttjas för att ta ställning till ett tekniskt SODDI försvar. SODDI försvaret är något som har utnyttjas länge och nyttjas nu även på cyberarenan. Genom att kombinera teorin bakom vanligt förekomna SODDI försvars fall med minnesforensik söker detta arbete att besvara följande frågor:

1. Hur kan specifika artefakter upptäckas i minnet som inte lagras till hårddisk på ett Windows 10 system?

a. Kan denna data kopplas till ett specifikt användarkonto?

2. Kan the trojan horse defense bemötas genom analys av RAM-minnet?

3. Kan ett SODDI försvar bemötas med minnesforensik, utifrån ovan angivna frågor?

1.5.1 Problematisering

Frågeställningen kunde eventuellt blivit problematiskt då RAM-minnet kontinuerligt skriver över sig självt i relation till tid och användning. Detta skulle kunna leda till ett varierade resultat ifrån arbetet där tiden, utvinningen samt att de bakgrundsprocesser som körts har möjlighet att påverka slutresultatet [1]. Detta bemöts till viss del genom att repetera de experiment som utförts tre gånger i en kontrollerad miljö för att ge ett mer pålitligt resultat.

Det kanske främsta problemet med frågeställningen var hur relevant arbetet blir om det sätts i en realistisk situation. Finns artefakter kvar i minnet tillräckligt länge mellan olika användares in och utloggning för att det ska vara relevant att undersöka det? Kan malware uteslutas ifrån att det finns på ett system? Detta är frågor som eventuellt inte har något definitivt svar, men som arbetet försöker att undersöka och skapa klarhet kring med hjälp av frågeställningen. På grund av de ovan nämnda förutsättningar kommer avgränsningar också att sättas för experimenten som utförs i arbetet.

(17)

5

1.5.2 Avgränsningar

För att avgränsa arbetets första fråga, har endast ett par specifika program och dess processer valts ut som ska undersökas närmare genom experiment. För att avgränsa följdfrågan är det sedan samma processer som testas vidare för att besvara frågan “Kan denna data kopplas till ett specifikt användarkonto?”.

För att begränsa arbetets omfattning gällande arbetets andra fråga har analysen av skadlig programvara begränsats till att undersöka ett par befintliga minnesavbildningar med malware. Där ett fall exemplifieras genom experiment och stärks upp av teoretiska beskrivningar kring ämnet.

SODDI fall där personer skyller ifrån sig på att det blivit hackade kommer inte att undersökas eller bemötas teoretiskt. Vidare begränsningar involverar de program som används, miljöer där experimenten utförs och antal utföranden per experiment, allt detta specificeras ytterligare under de enskilda experimenten.

(18)

(19)

7

2 Metod

Metodkapitlet redogör för de två metoder som använts för att undersöka området samt till att besvara frågeställningen. Arbetets huvudsakliga metod består av experiment och stärks upp av en mindre litteraturstudie.

2.1 Litteraturundersökning

Som grund för arbetet gjordes en mindre litteraturundersökning. Undersökningen gjordes i syfte att förstärka författarnas kunskap om området. Men även för att samla in information om vad som redan gjorts relaterat till arbetets frågeställning. Denna teori och bakgrund användes även till viss del som underlag för experimentuppställningarna. Undersökningen utfördes genom att söka efter vetenskapliga artiklar, böcker och annan information ifrån relevanta och accepterade källor. Litteratursökningen begränsade sig inte till en specifik databas utan utfördes genom att söka globalt efter publicerad information kring ämnet. Resultatet av litteraturundersökaningen blev den grundläggande teorin bakom RAM-minnets funktioner och SODDI försvaret som presenteras i arbetet. Denna information användes också för att utforma experimenten vilket i sin tur var den huvudsakliga metoden som använts för att besvara frågeställningen.

2.2 Experiment

Experimenten utfördes med flera syften i åtanke. Delvis för att demonstrera den tidigare kunskapen inom minnesforensiken, vilket har använts som teoretiskt underlag för detta arbete [1, 6, 12]. Detta för att validera att dessa metoder för minnesanalys fortfarande är relevanta. Men också i syfte att se vilken information som kan utvinnas i ett specifikt scenario. Resultaten användes sedan för att se hur den information som utvunnits kan sättas i perspektiv till arbetets frågeställning kring SODDI försvaret.

Experimenten utfördes på det sätt att olika händelseförlopp simulerades på ett system. Händelseförloppen utfördes med hjälp av en eller flera användare och under experimentets gång utfördes ett flertal minnesavbildningar. Dessa avbildningar analyserades efter

experimentets genomförande för att få fram ett relevant resultat. Resultatet användes sedan för att försöka ge svar åt arbetets frågeställning och för att föra en diskussion kring hur ett SODDI försvar kan bemötas genom det givna resultatet.

Experimenten och experimentuppställningarna beskrivs i kapitel 4, för att läsaren först ska få möjligheten att bli mer insatt inom området genom teorikapitlet (kapitel 3).

2.3 Positionering

Att utföra litteraturstudier av tidigare genomförd forskning för att kartlägga fältet som undersöks är en erkänd och välanvänd metod vilket denna rapport till viss del drar nytta av. Detta genom att skapa ett teoretiskt underlag som arbetet kan förhålla sig till. Det

(20)

8

huvudsakliga metodvalet var att utföra experiment i syfte att testa, verifiera och skapa egna resultat för att sedan kunna svara på frågeställningen. Att utföra experiment för att besvara den givna frågeställningen är också en väletablerad metod som används inom forskning generellt, men används också flitigt inom IT-forensiken. Detta gäller också för artiklar och arbeten som specifikt undersöker RAM-minnet ur ett forensiskt perspektiv [4, 5]. Därav skulle det kunna argumenteras för att metodvalet som gjorts ligger i linje med tidigare forskning inom området.

2.4 Alternativa metodval

Att utföra en strikt litteraturstudie kan tänkas vara ett alternativt metodval för arbetet. Där undersökningar av tidigare utförda arbeten inom minnesforensik, malware detektering i minnet och SODDI försvaret undersöks för att besvara frågeställningen. Att enbart förlita sig på en litteraturanalys hade troligtvis blivit problematisk, då delar av frågeställningen är dåligt dokumenterad i dagsläget. Bland annat har det skrivits väldigt lite om hur processer i minnet kan kopplas samman med användarkonton och vilken betydelse det kan ha för utredningar, framförallt i det fall när flera användare nyttjat samma system.

Ett annat alternativt metodval var att utföra en fallstudie. Det är inte lika vanligt

förekommande inom IT-forensiska arbeten och hade kunnat blivit problematiskt på grund av bristen på tidigare underlag. För arbetes syfte ansågs det mer effektivt att genomföra experiment i ett demonstrativt syfte där förhållanden och avgränsningar enklare kan kontrolleras.

Den bristande tillgången till information gällande minnesforensik i relation till SODDI försvaret och information kring hur användare kan kopplas samman med specifika processer, var den huvudsakliga motivationen till att utföra experiment. Genom att utföra experiment och tester utformade efter frågeställningen, kan den information som söks i frågeställningen också besvaras.

2.5 Motivering av metodval

Vid undersökning av publicerade IT-forensiska artiklar framgår det sällan en formulerad och specifik metod som används för att undersöka den ställde frågan. Det som ofta är gemensamt för dessa artiklar är att experiment ihop med analyser utförts [4, 5]. Baserat på de arbeten och de tillvägagångssätt som undersökts ansågs det att frågeställningen skulle ha störst chans att besvaras genom utförandet av experiment. Experimenten kommer likt många andra arbeten att utföras med hjälp av VMs. En stor fördel med att utföra

experimenten i en kontrollerad miljö baserad på VMs (Virtuella Maskiner) är att systemet snabbt kan återställas för kontroll samt återskapande av experiment. Vilket kan minimera risken för att experimenten påverkar varandra.

(21)

9

Av dessa anledningar ansågs frågeställningen ha störst chans att kunna besvaras genom utförandet av ett flertal sammanhängande experiment.

2.6 Problematisering

Metodvalet skulle eventuellt kunna resultera i att viss information av vikt förbises eller att det givna resultaten inte är helt applicerbara i verkligheten. Dels på grund av att

experimenten utförts på VMs men också eftersom experimentuppställningarna är väldigt specifik. Experimenten utfördes på ett återställt eller nyinstallerat VM med minimalt antal systemaktiviteter vilket inte alltid stämmer överens med ett mer verklighetstroget scenario. Ett av de större problemen med den valda metoden ihop med frågeställningen är den mängd av variabler som kan påverka experimenten. Faktorer som tid, storlek på minne,

användaraktivitet, bakgrundsprocesser och val av verktyg kommer alla att ha viss inverkan på experimentens resultat precis som i ett verkligt scenario. Verktyg för utvinning påverkar alltid det aktiva minnet genom att en viss del (en väldigt liten del) av minnet blir

överskriven, detta är något som har funnits i åtanke men som troligtvis inte haft signifikant inverkan på experimenten [5]. Valet av verktyg för analys spelar också en viss roll. Det här arbetet kommer enbart att förlita sig på volatility för analyser, vilket är ett av det mest använda och erkända verktygen för analyser av RAM dumpar [1, 12]. Utöver volatility användes Magnet RAM capture för att utvinna minnet. Ett ytterligare problem med metoden är att de få antal utföranden av experimentet som utförts kan ha en överdrivet negativ eller positiv inverkan på resultatet. Det upptäckter som gjorts eller inte gjorts kan därav dels bero på tillfälligheter.

(22)

(23)

11

3 Teori

För att ge läsaren en ökad förståelse för experimenten och innebörden av resultaten behövs en kortare teoridel. Syftet bakom kapitlet är att beskriva bakomliggande information om hur och vart data lagras i minnet och hur denna kunskap nyttjas i experimenten. Vidare förklaras hur processer som relaterar till användarkonton kan hittas i minnet och varför det finns i minnet. Denna del är särskilt viktig då arbetets fokus är att tydliggöra hur detta kan genomföras och potentiellt nyttjas i verkliga fall. Även hur processer relaterar till andra processer, varifrån de vanligaste processerna körs och till viss del information om dess struktur kommer att beskrivas. Detta förklaras för att skapa en förståelse om hur till exempel malware och andra artefakter av intresse kan upptäckas vid minnesanalyser. Det finns redan mycket skrivet kring malware i minnet och att lista samt beskriva samtliga processer i Windows 10 är utanför arbetes omfattning. Därför ges bara en övergripande beskrivning av hur malware detektering kan utföras. Samt att endast det vanligaste

processerna diskuteras och presenteras för att vidare bygga en förståelse över hur malware kan detekteras i minnet.

Därefter ges en kortare beskrivning av det valda verktyg och program som använts under arbetets gång. Volatility som är det huvudsakliga programmet som använts vid analyser av minnet beskrivs mer utförligt där också det mest använda pluginsen beskrivs.

En kortare del om SODDI och framförallt det tekniska SODDI försvaret beskrivs sist i teorikapitlet. I syfte att knyta samman hur teorin om minnet kan utnyttjas för att hitta relevant information i det fall där ett SODDI försvar förekommer.

3.1 Random Access Memory (RAM)

All data som används på ett system passerar någon gång RAM-minnet, nätverkstrafik, bilder som öppnas, filer som kopieras, kod som exekveras, och så vidare. Mycket av all denna data lagras aldrig till hårddisk och det är därför analys av minnet kan vara så

värdefullt. RAM är volatilt och det innebär att data finns bara kvar så länge som minnet har tillgång till ström. Därav kan också minnet enbart inhämtas från ett körande system, ett undantag till detta är vid cold boot attacker. Minnet är under konstant förändring när ett system är igång och data som finns där är ostrukturerad och generellt svårare att analysera än data som finns på en hårddisk eller USB minne [2, 8].

En vanlig metod vid IT-forensiska undersökningar av hårddiskar är att en hårddisk avbildas och sedan skapas en hashsumma utifrån avbildningen. Syftet bakom detta är att det fynd som görs ifrån avbildningen ska kunna verifieras. En annan IT-forensiker ska kunna avbilda hårddisken igen, få samma hashsumma och kunna reproducera det tidigare resultatet ifrån den nya avbildningen. Den här metoden fungerar däremot inte vid en avbildning av RAM-minnet eftersom data kontinuerligt passerar in och ur RAM-minnet. Vilket leder till att en hashsumma ifrån en minnesdump aldrig kommer att bli densamma igen.

(24)

12

3.1.1 Virtuellt minne

Operativsystem har normalt sett inte direkt tillgång till minnet, utan använder sig istället av ett abstraktions lager som kallas för virtuellt minne. Med hjälp av det virtuella minnet får varje process sin egen virtuella minnesadress. Detta görs möjligt genom en hårdvarudel som kallas MMU (Memory Management Unit). Anledningen till att detta abstraktionslager används är bland annat för att program ska kunna få ett eget kontinuerligt minnesblock, förhindra överskrivning av andra delar i minnet och för att begränsa åtkomst av andra delar i minnet. Allokeringen av data mellan det fysiska (riktiga) minnet och det virtuella minnet behöver därför inte heller motsvara varandra. Det som ser ut att vara ett långt allokerat minnesblock i virtuella minnet kan istället vara uppdelat och utspritt över flera sektorer i det fysiska minnet. Detta innebär att data som olika filtyper inte alltid kan hämtas direkt ifrån en minnesavbildning genom till exempel carving metoder, eftersom det inte alltid finns skrivet som ett kontinuerligt block av data [1].

3.1.2 Paging

I Windows har varje process sin egen virtuella minnesadress som är separerad ifrån andra processer. För att MMU ska kunna manipulera data i det fysiska minnet måste därför data adresser i det virtuella minnet översättas eller kartläggas till det fysiska minnets adress. För att underlätta denna process har minnet delats in i regioner som kallas för pages, dessa varierar i storlek beroende på datorns arkitektur och är 2^2 KB som minst. I det fall när det virtuella minnets storlek överstiger det fysiska minnets kapacitet kan operativsystemet lagra delar (pages) av minnet till hårddisk. Detta kallas för paging och lagras till pagefile.sys som normalt finns under C:\pagefile.sys. Det kan därför även relevant att undersöka pagefile.sys vid analyser av minnet [6].

3.1.3 Access tokens

En access token eller process token avgör vilka rättigheter eller tillåtelser en process har på ett system. En access token är relaterad till den aktiva användaren på ett system och har information om vilka rättigheter användaren har, vilka grupper den tillhör, ett session värde för den aktuella inloggningen med mera. Informationen som finns i access token sparas till stor del i form av SIDs och nyttjas för att avgöra vilka aktiviteter användaren och dennes processer har tillåtelse till att utföra på systemet. Det innebär också att varje process har en access token kopplad till sig och genom att undersöka den går det att avgöra vilken

användare det är som äger processen. Volatility har en specifik plugin avsedd för just detta som kallas getsids [1, 19].

(25)

13

3.2 Malware i minnet

För att detektera malware i minnet är kunskap om vad som är “normalt” en nyckelkunskap. Har analytikern till exempel en kunskap om vilka processer och nätverksanslutningar som är att anse som normala så kan anomalier lättare upptäckas. “Effective memory analysis

requires the ability to detect anomalies” [12].

Varje process i ett Windows system får ett nummer tilldelat som kallas PID (Process ID), utöver det har samtliga processer också ett PPID (Parent Process ID). Genom att veta om vilka processer som ska vara föräldrar till specifika och vanligt förekommande processer kan enklare avvikelser upptäckas [12].

Två vanliga metoder som malware använder för att dölja sin närvaro i minnet inkluderar att namnge dessa processer med snarlika namn till Windows egna processer eller med process namn ifrån äldre Windows system. Ett exempel på det är att malware döljer sig bakom

svchost.exe, genom en felstavning som scvhost.exe. Då denna process förekommer ett

flertal gånger på ett Windows 10 system kan det vara enkelt att missa. Det förekommer också att processer innehållande skadlig kod har namn som överensstämmer med ett system, men att processen har startats ifrån en felaktig plats. Svchost.exe som normalt sätt ska köras ifrån \Windows\System32 kan ha startats ifrån \Windows, vilket i så fall är direkt suspekt och bör undersökas [12].

En kortare summering av viktiga och vanligt förekommande processer i ett Windows system presenteras i figuren nedan [figur 1]. Figuren listar processerna efter deras förälder-barn relation och ordningen dessa startas i Windows 10. Session 0 startas alltid i och med uppstarten av Windows. Session 1 startas vid varje inloggning av en användare, vilket innebär att det kan finnas flera processer enligt session 1 vid flera snabba in och ut loggningar [12].

(26)

14

När processer använder sig av legitima namn blir det svårare att upptäcka. Det kan då också vara värt att kolla upp nätverksanslutningar via plugins som, connscan (för äldre Windows OS) och netscan (för nyare Windows OS). Tecken på malware kan då vara processer med nätverksanslutningar som inte bör ha det eller om processer ansluter till suspekta IP adresser.

3.2.1 Process injektioner

Det finns även ett flertal olika metoder av process injektioner som skadliga program kan använda sig av för att hålla sig dolda. Till exempel, legitima processer urholkas (process hollowing), laddas med skadliga dll-filer (dll injection) och skadlig kod kopieras direkt in i processen (PE injection) [22].

En av det vanligaste metoderna av process injektion är dll injektion. För att denna metod ska fungera krävs det att en skadlig dll-fil placeras på ett system. Det skadliga programmet skriver sedan in sökvägen till den skadliga dll-filen i en legitim process virtuella minne, och på så sätt körs programmet ifrån en äkta process. Denna metod kan vara svår att upptäcka men i vissa fall kan plugins som malfind eller ldrmodules hjälpa till att identifiera den nu skadliga processen [1, 22].

PE injection eller portable executable injection använder sig inte av filer på ett system utan kopierar istället direkt in kod i en körande process, i övrigt är denna metod ganska lik dll injektion. Volatilitys plugin malfind är skapat i syfte att specifikt upptäcka denna typ av injektion [1, 22].

Process urholkning eller process hollowing är en till metod där skadlig kod förs in i en legitim process. Det utförs genom att en genuin process urholkas från den korrekta data som finns där och ersätts av skadlig kod. Pluginen hollowfind är skapad i syfte att upptäcka just denna form av attack [1, 22].

Det ovan nämnda formerna av process injektioner är bara några av det vanligaste, det finns åtminstone närmare tiotal olika metoder till. Alla dessa tekniker medför att den nu skadliga processen har ett korrekt namn, sökväg och behörigheter ifrån den övertagna processen. Teknikerna kan upptäckas på flera sätt bland annat genom att undersöka processens föräldrar, kod och tillhörande dll-filer. Det finns även ett flertal plugins till Volatility som kan hjälpa till med detta till exempel, hollowfind, malfind, dlllist och ldrmodules [1, 22].

3.2.2 Praktisk malware detektering

Genom att applicera den korta information som givits ovan kan enklare malware detektering i minnet utföras. Att först undersöka namnen på processerna så att de är

korrekta och så att det inte finns fler än vad det ska göra av dessa processer är en enkel men god start. Detta kan följas upp med att undersöka så att processerna har korrekta föräldrar och att processerna har startats ifrån rätt platser. Eventuella nätverksanslutningar och vilka processer som har uppkopplingar bör också undersökas.

(27)

15

Ytterligare analys för att detektera processer av intresse kan göras genom att använda plugins till Volatility som malfind, ldrmodules, handles, dlllist, hollowfind med flera. Mer information om några av dessa plugins kan läsas genom [1, 15]. Malfinds syfte och hur den fungerar är däremot kort beskrivet under rubriken Volatility. När väl suspekta processer har hittats kan dessa analyseras noggrannare med till exempel memdump, procdump eller

malfind. Används procdump eller malfind så kan en hash tas på den filen som extraheras

och jämföras emot en databas som “virustotal” för att se om det är en igenkänd malware fil. Observera att detta är väldigt kort summerat och förenklad beskrivning av hur skadlig kod kan detekteras i minnet och utesluter inte att malware finns på systemet.

3.3 Volatility

Volatility är det största och mest använda verktyg och är skapat för att göra avancerade analyser av minnesdumpar. Verktygets fördelar i förhållande till andra verktyg innefattar bland annat en involverad och aktiv användarbas. Volatility är opensource och tillåter användare att både använda och skapa olika plugins för att analysera minnesdumpar. Verktyget är erkänt som ett av de mest avancerade verktygen för minnesanalyser och den öppna källkoden gör att verktyget kan hållas uppdaterad och undersökas av den som vill [1, 14].

Verktygets ledande roll inom minnesanalyser, dess mångsidighet samt att det är opensource är bara ett par av det anledningar som lett oss till att använda detta verktyg. Eftersom Volatility använts vid samtliga av arbetets analyser är det nödvändigt att läsaren förstår hur det plugins som frekvent används fungerar.

Nedan listas en kort presentation av hur det plugins som främst har använts fungerar och kan nyttjas vid minnesanalyser. Ytterligare information om Volatilitys plugins finns på deras github [15], böckerna [1, 12] diskuterar mer utförligt om en del utav dessa plugins också.

3.3.1 Pstree, Pslist och Psscan

Pstree listar upp processerna i ett trädformat som visualiserar processer och

föräldraprocesser. Den data som kan avläsas med pstree är, offset för platsen där processen finns i minnet, namn, PID, PPID, threads, handles och tid för skapande av processen. Pslist fungerar likadant och har samma funktion som pstree. Pslist listar dock inte ut processerna i trädformat utan endast i ett mer klassiskt listformat.

Psscan söker igenom minnesdumpen och listar upp de processer som kan hittas. Till skillnad ifrån pstree och pslist så kan den även lista avslutade processer som fortfarande finns kvar i minnet [15]. Den data som kan avläsas med psscan är offset för platsen där processen finns i minnet, namn, PID, PPID, PDB, tid för skapande och avslut av processen.

(28)

16

3.3.2 Getsids

Getsids använder sig av processers PID som argument och ger ut det SID (Security Identifier) som är ansvarig för processen [15]. I Windows 10 tilldelar operativsystemet ett unikt SID till alla användare och grupper som skapas på systemet [16]. Detta medför att det med hjälp av Getsids är möjligt att identifiera det användarkonto på systemet som startat en specifik process.

3.3.3 Memdump och Procdump

Memdump skapar och extraherar en kopia av den del av minnet som tillhör en specifik process [15]. Med hjälp av denna plugin och den data tas fram ur minnesdumpen kan filer som relaterar till processen i form av öppnade pdf-filer eller bilder tas fram med hjälp av en hexeditor eller ett carving verktyg.

Procdump är ytterligare en plugin för att dumpa information, till skillnad från memdump hjälper procdump användaren att dumpa ut körfilen som startade en process, detta görs med hjälp av processens PID [15]. Detta kan vara användbart för analyser av malware där suspekta processers “.exe” filer kan dumpas ut och analyseras.

3.3.4 Cmdscan

Cmdscan letar genom minnet efter csrss.exe på Windows XP/2003/Vista/2008 och

conhost.exe för Windows 7 och 10 system. Dessa är namnen för respektive operativsystems konsol. Denna plugin gör det möjligt att printa ut konsolhistoriken om detta finns

tillgängligt i minnet. Denna plugin är till stor fördel i situationer då en dator blivit attackerad och man vill ta reda på vad som gjorts på systemet [15].

3.3.5 Malfind

Malfind kan användas för att upptäcka processer som har blivit injicerade med kod eller dll-filer. Syftet med malfind är att hitta dessa processer med tekniker som andra metoder inte enkelt kan upptäcka. Malfind kan användas emot samtliga processer i en minnesavbildning, eller specificeras till att undersöka utvalda processer. Denna plugin har även möjlighet att dumpa det minnes regioner som upptäcks som suspekta, vilket sedan enkelt kan jämföras med en databas som Virustotal [15, 20].

(29)

17

3.4 The trojan horse defense och SODDI försvaren

SODDI (Some Other Dude Did It) är ett försvar som används i rättsliga sammanhang av den som är misstänkt för brott. Försvaret har tidigare nyttjats i undersökningar av IT-relaterad brottslighet som bland annat barnpornografibrott och fildelning. Men även för andra typer av brott där bevisen för att ett brott begåtts inte går att förneka, men vem den skyldige är inte är självklart. Försvaret går ut på att neka till, eller skapa rimligt tvivel kring att den misstänkte har begått brottet i fråga. Inom IT-brott kan det förekomma i form av att den misstänkte hävdar att andra personer med tillgång till systemet har genomfört brottet, att bevisen på datorn är planterade av en okänd person eller att polisen i undersökningen har planterat bevis [9, 10, 11].

The trojan horse defense är ett vanligt förekommande tekniskt SODDI försvar där den

misstänkte hävdar att bevisen planterats på datorn av ett virus eller annan form av skadlig programvara. Det kan också innebära att det skylls på en okänd aktör som har haft kontroll över systemet och kunnat utföra de brottsliga handlingarna. Den misstänkte menar att det därför inte är den som bär ansvar för det brott som begåtts [9, 11, 13].

3.4.1 Att ta ställning till SODDI försvaret

Det SODDI försvaret gör är som tidigare nämnt att skapa tvivel i utredningen kring vem den riktiga gärningsmannen är och lägger över ytterligare bevisbörda till åklagaren

eller forensikern. Det innebär i många fall att det måste bevisas att den enda personen med fysisk tillgång till systemet vid tillfälle av brott var den anklagade. Eller visas på att det är högst osannoprlikt att någon annan haft tillgång till systemet vid denna tid [13].

Då den anklagade använder sig av the trojan horse defense ger det åklagarsidan den ytterligare bördan att bevisa avsaknad av malware på systemet vid tillfället av

brott. Möjliga tillvägagångssätt att forensiskt undersöka datorn i syfte att visa avsaknad av malware. Om malware skulle upptäckas bör åklagare ha viruset analyserat av experter för att ta reda på ifall just detta virus kunnat bära ansvar för de brottsliga handlingarna. Och sedan också att det var den anklagade som begick gärningen och ingen annan. Ytterligare sätt att motbevisa SODDI försvar kan också innefatta mer traditionella metoder som förhör, i syfte att få bevis som talar emot försvaret [13].

(30)

(31)

19

4 Experiment

I detta kapitel presenteras experimentuppställningarna för varje enskilt experiment, dess genomföranden och till viss del de verktyg och mjukvara som användes. Varje experiment beskrivs ihop med enskilda avgränsningar och tillvägagångssätt. Ytterligare kan denna dokumentation också möjliggöra framtida replikeringar av det experiment under så lika omständigheter som möjligt.

4.1 Program och verktyg

I denna sektion beskrivs de övriga verktygen och mjukvaran som användes vid utförandet av experiment och analyser.

Program Version Syfte/Typ av program Oracle VM Virtualbox 6.1 Virtualisering

Windows 10 Home Build 17 763 Valt operativ system för experiment 1 Sift Workstation Operativ system som använts vid analyser Google Chrome 80.0.3987.163 Webbläsare

Mozilla Firefox 75.0 (x64 sv-SE) Webbläsare Magnet RAM Capturer 1.2 Skapa minnesavbildningar [17] Scalpel 2.0 Verktyg som kan ”carva” filer. Hex Workshop

hexeditor

6.7 Verktyg för att läsa filers kod

Volatility 2.6.1 Analysverktyg för minnesavbildningar.

(Tabell 1. Översikt av verktyg och annan mjukvara som använts under arbetets gång.)

4.2 Experimentuppställning (1)

Experiment ett är uppdelat i två delar och varje del har tre utföranden i syfte att validera de givna resultaten. Del 1 och del 2 relaterar nära till varandra då inhämtning av dess data gjordes under ett långt utförande och analysen utfördes på samma sätt. Däremot så har resultaten olika betydelser för rapportens slutsats, och därför presenteras resultaten ifrån dessa delar under separata rubriker.

Gemensamt för samtliga delar av experiment 1 inkluderar att de utförts i kontrollerade miljöer i form av virtuella maskiner med nyinstallerade operativsystem. Med motivationen att minimera inverkan av utomstående faktorer och för att enkelt kunna återställa till ett tidigare icke kontaminerat stadie. Genom att använda virtuella maskiner för experimenten kunde kontaminering av resultat och verifiering till stor del att undvikas [7].

(32)

20 Del 1

Det första experimentet syftade till att identifiera och påvisa vilka artefakter som kan upptäckas i minnet som eventuellt inte skulle ha lagrats

till hårddisken. Experimentet testade att öppna olika filtyper ifrån en USB, köra CMD kommandon och surfa med olika typer av webbläsare genom dess privata funktioner. För att sedan dumpa minnet och analysera det i syfte att se vilken data som kan hittas. Vidare undersöks det även om denna data kan kopplas till det användarkontot som är inloggat vid inhämtningstillfället i syfte att bemöta SODDI försvaret.

Del 2

Den andra delen i första experimentet byggde vidare där det första experimentet avslutas. Syftet bakom detta experiment är att se om det är möjligt att fortsatt identifiera relevanta processer, ägare till dessa och relaterade data efter att användaren har loggat ut. Detta för att potentiellt kunna bemöta ett SODDI försvar där en misstänkt skyller ifrån sig på någon annan och har loggat ut ifrån en dator som också nyttjas av andra.

4.2.1 Avgränsningar

Del 1 och del 2

Experimentet utfördes tre gånger per del under samma omständigheter i syfte att validera resultaten. Fler artefakter som nätverksanslutningar, flera filtyper och webbläsare som skulle kunna ha undersökts men uteslöts på grund av brist på tid. Den första delen är avgränsad till att enbart undersöka ett aktivt användarkonto som för tillfället vid

inhämtningen av minnet är inloggat. Den andra delen är avgränsat till två användarkonton där inhämtningen utförs nästan omgående efter att användare två har loggat in.

Valet att till viss del avgränsa experimentet ifrån tidsaspekten och frågor kring hur länge denna data finns kvar i minnet gjordes. Däremot ansågs det nödvändigt att skapa flera minnesdumpar i syfte att bedöma om data fanns kvar tillräckligt länge i minnet och verifiera resultaten. Beslutet togs att endast låta 20 till 30 minuter passera

mellan inhämtningarna för att bespara tid.

Ytterligare gjordes också avgränsningar kring antal utföranden och använda verktyg samt analysernas djup. Dels på grund av tid dels då det inte ansågs vara högst relevant för arbetets generella syfte. Genom att sätta avgränsningar som dessa kunde relevant information snabbt identifieras och på så sätt föra studien framåt på ett effektivt sätt.

(33)

21

4.2.2 Scenario och tillvägagångssätt

Den första delen och andra delens tillvägagångssätt av experimentet är listat under “del 1” respektive “del 2”, i punktlistan nedan. Processen nedan har genomförts tre gånger, vilket resulterade i nio minnesdumpar att analysera. Nedan listas utförandet steg för steg. Del 1

1. Användaren Evil loggar in på systemet och kopplar in ett USB minne.

2. En pdf-fil, ett textdokument och en bildfil öppnas ifrån USB minnet per utförande [Tabell 1].

3. Chrome och Firefox öppnas med deras privata webbläsare alternativ, en hemsida per webbläsare och utförande öppnades [Tabell 1].

4. Cmd startas där användaren navigerar till desktop och utför ett kommando per utförande [Tabell 1].

5. Samtliga program stängs ner och USB minnet kopplas ifrån, därefter skapas en minnesdump.

6. Efter att 20 minuter har passerat skapas en andra minnesdump. Del 2

7. Evil loggar ut och Friendly loggar in.

8. Efter att ungefär 5 minuter har passerat så dumpas minnet.

Applikation Namn (Utförande 1) Namn (Utförande 2) Namn (Utförande 3) Adobe acrobat reader

Computing1.pdf Malware2.pdf Research3.pdf Photos (microsoft) PicOne.jpg PicTwo.jpg PicThree.jpg Notepad OneWord.txt TwoWord.txt ThreeWord.txt

CMD Ping tracert netstat

Chrome Incognito www.klart.se www.yr.se www.smhi.se Firefox Inprivate www.hackthebox.eu www.tryhackme.com www.root-me.org

(Tabell 1. Visar vilka program som har körts, namn på filer som öppnats, webbsidor som besökts och CMD kommando som körts utifrån utförande under experiment 1.)

4.2.3 Analysmetod

Efter att samtliga dumpar skapats påbörjades analysen av dessa. Analysen utfördes främst i Sift workstation med Volatility, men även i Windows med Hex Workshop hexeditor. Dokumentation av resultaten har främst sparats genom skärm dumpar och dokumentation. Det första steget inför varje analys var att kopiera den aktuella minnesdumpen in till Sift workstation. Därefter påbörjades sökningar med Volatility plugins som pstree, pslist, psscan och psxview efter processer av intresse. Upptäcktes processer av intresse så kördes

(34)

22

pluginen getsids för att identifiera ägaren till processen. När väl samtliga processer av intresse och dess ägare upptäckts så dumpades data som relaterade till dessa processer med memdump.

Innan vidare analys av processernas minne utfördes så kördes övriga kommandon som mftparser, cmdscan och consoles för att hitta kommandon som körts av användare och filnamn av intresse. Flödesschemat nedan illustrerar analysens process.

(35)

23

4.3 Experimentuppställning (2)

Experiment två söker tillvägagångssätt för att bemöta the trojan horse defense. Om en misstänkt skyller ifrån sig på malware behöver systemet undersökas för att ta reda på om det blivit utsatt för någon form av attack. Genom att skanna ett system med

antivirusprogram, undersöka vanliga platser för malware i registry ihop med analys av RAM kan en analytiker med ganska god sannolikhet säga om systemet är infekterat eller ej. Skulle systemet visa sig vara infekterat eller på annat sätt påverkat utifrån, behöver det istället undersökas när detta har skett och vad för typ av malware det rör sig om. I syfte att se om det kan ha någon påverkan på utredningen.

Inför detta experiment har minnesdumpar laddats ner som innehåller malware i syfte att undersöka hur dessa kan upptäckas genom analys med hjälp av Volatility.

4.3.1 Avgränsningar

Arbetets syfte är att hitta information för att bemöta ett SODDI försvar genom

minnesanalyser. Därför kommer inte vanliga undersökningar efter skadliga program på hårddisk att utföras eller beskrivas i detta arbete. Inte heller undersöks det när malware kan ha kommit till systemet. Däremot så söker arbetet tillvägagångssätt för att hitta vart på systemet det skadliga programmet kan finnas eller funnits. Vidare analyser för när malware har kommit till systemet förenklas däremot genom att veta dess namn och vart på systemet det finns eller har funnits.

Vidare finns det tusentals olika varianter av malware och nya utvecklas ständigt, därför kan detta experiment omöjligt visa alla tekniker för att detektera malware i minnet. Syftet är att visa exempel och testa tekniker för att bemöta ett SODDI försvar som skyller på malware.

4.3.2 Scenario och tillvägagångssätt

Infekterade minnesdumpar laddades ner ifrån [15], dessa importeras sedan till ett VM med Sift workstation för analys i Volatility. Av det minnesdumpar som undersöktes utsågs en som särskilt passande och intressant för detta arbete och valdes ut för dokumentation. En generell analysmetod som användes för att undersöka minnesdumparna listas nedan.

1. Först laddas minnesdumpen ner och importeras till ett VM med Sift workstation. 2. Därefter kördes pstree, psscan och psxview för att försöka upptäcka avvikande

processer. Detta gjordes genom att undersöka processers namn och dess hierarkiska struktur.

3. Har inte processer av intresse upptäckts i steget innan så körs malfind och hollowfind.

4. För att få reda på mer information om processer av intresse eller för att upptäcka ytterligare processer som kan vara av intresse så kördes, cmdline, connections

(36)

24

(netscan), dlllist, vadinfo, envars, med mera. Dessa plugins kan även köras emot hela dumpen med hjälp av grep.

5. När suspekta processer har upptäckts så dumpas dessa ut ihop med relaterade filer. Dessa filer används sedan emot en databas som virustotal för att få mer information om vad för malware det rör sig om.

6. Om det dumpade filerna ger resultat ifrån databasen, så eftersöks mer information om det aktuella skadliga programmet online. I vissa fall ges en del dokumentation ihop med resultaten ifrån databasen.

I det exemplet som presenteras i resultaten, ledde steg 6 till ett återkommande resultat med namnet zbot. Ytterligare information om detta malware eftersöktes online vilket ledde till att malware filen på hårddisk kunde identifieras och extraheras ifrån minnesdumpen. Filen undersöktes kort med strängsökningar och jämfördes emot databasen en gång till vilket ytterligare verifierade att det rörde sig om zeus malware.

(37)

25

5 Resultatredovisning

I detta kapitel presenteras resultat ifrån de experiment som utfördes i det föregående

kapitlet. Kapitlet är indelat efter det experiment som utförts och avslutas med ett avsnitt där resultaten ifrån experimenten ställs i relation till SODDI försvaret.

5.1 Resultat - Experiment (1)

Här presenteras resultaten ifrån samtliga delar av det första experimentet. Del 1 undersökte om processer, relaterade data och ägare till dessa kunde identifieras för en enskild

användare. Del 2 undersökte om denna data kunde fortsatt identifieras och kopplas till ägaren efter att en ny användare loggat in.

5.1.1 Del 1

Tabellerna nedan presenterar följande resultat, avstängda processer (process), ägare till processerna (användare) och relevant data (data) i förhållande till processerna [Tabell 2–4]. Relevant data syftar till en pdf-fils innehåll, besökta URL:er ifrån webbläsare, utförda kommandon med CMD, och så vidare. Tabellerna nedan listar om en identifiering av denna data var möjlig utifrån utförande och aktuell minnesdump.

Utförande 1 Applikation Process Dump 1 Användare Dump 1 Data Dump 1 Process Dump2 Användare Dump 2 Data Dump 2 Adobe pdf reader JA JA NEJ JA JA NEJ Photos (microsoft)

NEJ NEJ NEJ NEJ NEJ NEJ

Notepad NEJ NEJ NEJ NEJ NEJ NEJ

CMD NEJ NEJ NEJ NEJ NEJ NEJ

Chrome Incognito

JA JA JA JA JA JA

Firefox Inprivate

(Tabell 2, listar körda program ifrån utförande 1, tillhörande minnesdumpar och om processer, användare och relevant data kunde identifieras.)

(38)

26 Utförande 2 Applikation Process Dump 1 Användare Dump 1 Data Dump 1 Process Dump2 Användare Dump 2 Data Dump 2 Adobe pdf reader JA JA NEJ JA JA NEJ Photos (microsoft)

Chrome Incognito JA JA JA JA JA JA Firefox Inprivate JA JA JA JA JA JA

Utförande 3 Applikation Process Dump 1 Användare Dump 1 Data Dump 1 Process Dump2 Användare Dump 2 Data Dump 2 Adobe pdf reader JA JA NEJ JA JA NEJ Photos (microsoft)

NEJ NEJ NEJ JA JA NEJ

Chrome Incognito

JA JA JA JA JA JA

Firefox Inprivate

Från samtliga utföranden kunde processen tillhörande Chrome och Adobe reader samt dess ägare identifieras. URL:er som besökts med Chrome och i två fall Firefox kunde också utläsas med hjälp av att minnet som relaterade till processen dumpades och genomsöktes. Anledningen till att någon relevant data till Adobe reader inte kunde utläsas är att pdf-filer inte sparar sin text som klartext. Ett screenshot taget ifrån en pdf-fil som öppnats med en hexeditor finns i [Bilaga 1.8]. Det hade varit möjligt att hitta relevant data för pdf-filerna om dessa hade kunnat “carvats” ut ifrån minnet, vid varje försök misslyckades detta dock. Teoretiskt ska detta vara möjligt med korrekt utförande och under rätt omständigheter [21].

(39)

27

Utförande ett kunde identifiera Adobe reader och Chrome processen samt dess ägare och vissa data. Under utförande två kunde även Firefox ses utöver Adobe reader och Chrome, även dess ägare och relevant data i form av URL:er kunde identifieras. Utförande tre gav liknande resultat som utförande ett, med undantaget att i andra minnesdumpen kunde processen för Microsoft Photos och dess ägare identifieras. Ett försök att carva ut bilden gjordes både för hand med en hexeditor och med verktyget Scalpel. Bilden gick inte att utvinna till ett läsbart format.

Vid strängsökningarna som utfördes mot data som hämtats med pluginen memdump rörande webbläsare. Så kunde URL:er ifrån Firefox hittas i minnet rörande Chrome och vice versa. Detta gör det problematiskt att koppla dessa URL:er till en specifik användare [Bilaga 1.7]. Under samtliga utförande gjordes även försök att utvinna data rörande CMD kommandon som körts av användaren. Plugins som cmdscan och consoles testades men gav inga resultat. Vidare gjordes tester där strängsökningar på hela minnesdumpen utfördes för att hitta filnamn och sökvägar av intresse. Syftet bakom dessa var att se om denna data fanns på minnesdumpen [Bilaga 1.5]. Övriga bilder som relaterar till resultaten ifrån tabellerna för del 1 finns med i bilaga 1.

5.1.2 Del 2

Resultaten visar att ungefär hälften av det processer som tidigare kunde identifierats inte längre syns när en liknande analys utförs igen efter att användaren loggat ut [Tabell 5–7]. Utförande 1

Applikation Process Användare Data

Adobe pdf reader JA JA NEJ

Photos (microsoft) NEJ NEJ NEJ

Notepad NEJ NEJ NEJ

CMD NEJ NEJ NEJ

Chrome Incognito NEJ NEJ NEJ

Firefox Inprivate NEJ NEJ NEJ

(Tabell 5, listar körda program ifrån utförande 1 och om processer, användare och relevant data kunde identifieras.)

(40)

28 Utförande 2

Adobe pdf reader NEJ NEJ NEJ

Notepad NEJ NEJ NEJ

CMD NEJ NEJ NEJ

Chrome Incognito JA JA JA

Utförande 3

Adobe pdf reader JA JA NEJ

Notepad NEJ NEJ NEJ

CMD NEJ NEJ NEJ

Chrome Incognito JA JA JA

För utförande ett kunde processen till Adobe pdf reader fortsatt hittas i minnet och användaren Evil kunde kopplas till denna process, Chrome processen syntes däremot inte längre. Utförande två kunde identifiera processen Chrome, dess ägare och relaterade data i form av besökta URL:er. Utförande tre lyckades hitta både Chrome och Adobe reader i minnet, dess ägare och för Chrome kunde även URL:en hittas.

I samtliga fall där Adobe reader detekterades kunde dock inte pdf-filen “carvas” ut. Hur resultaten har utvunnits ifrån minnet för del 2 finns dokumenterat med bilder i bilaga 2.

5.3 Resultat - Experiment (2)

Filen som undersöktes i detta experiment var zeus.vmem som laddats ner ifrån [15], filen innehåller en minnesdump ifrån Windows XP servicepack 2 som blivit infekterat av malware typen zeus. Undersökningar med pstree, pscan och psxview gav inga suspekta processer, däremot kunde en suspekt uppkoppling ses med connscan [Bilaga 3.1]. Denna uppkoppling visade sig komma ifrån en svchost.exe process. Processens minnesregioner dumpades och genomsöktes kort där IP adressen påträffades igen [Bilaga 3.2]. IP adressen undersöktes men i dagsläget är denna IP adress inte svartlistad. Hade en sökning gjorts för

(41)

29

några år sedan när detta malware var mer aktuellt så hade denna IP adress troligtvis varit svartlistad. Vilket hade varit en god indikation på att det rör sig om skadlig programvara. Malfind kördes också och gav utslag på ett flertal processer [Bilaga 3.3], dessa processer dumpades med malfind och testades mot virustotal.com [20]. Vilket resulterade i flera träffar däribland ett flertal zbot.

Vid online sökningar relaterade till zbot framkommer det att zbot eller zeus modifierar ett flertal filer på systemet. Bland annat modifieras ett flertal registry nycklar i syfte att behålla sitt fäste på systemet och tillgodose administratörs rättigheter åt det skadliga programmet. Det framkommer att en av dess huvudsakliga filer heter sdra64.exe på infekterade system. Genom att använda pluginen handles med sökningar efter sdra64 kunde filen hittas och sedan dumpas med dumpfiles [Bilaga 3.5]. Även denna fil testades emot virustotal vilket gav ett ännu högre träffresultat [Bilaga 3.6]. Det finns även en viss dokumentation om malware-filen på virustotal [20], där det framgår vad malwaret gör på systemet, vilka filer den ändrar, raderar och så vidare. Beroende på vad det skadliga programmet gör på ett system så skulle denna information eventuellt kunna användas för att bemöta ett SODDI försvar.

I det här fallet rör det sig om ett välkänt malware som har använts främst för ekonomisk vinning men även för att stjäla känsliga data, bygga botnets och ladda ner samt köra diverse skadliga program [23].

5.4 Resultatens betydelse för SODDI

Det är möjligt att knyta ett användarkonto till en specifik process och även viss tillhörande data då en ensam användare nyttjat ett system. Det betyder endast att vi med säkerhet vet vilket användarkonto som är ansvarigt för det givna resultatet. Det säger inte att den som är anklagad för ett brott är skyldig men det ökar sannolikheten för det signifikant. Och ett SODDI försvar skulle potentiell kunna ifrågasättas.

I de fall där fler användare nyttjat ett system är visar resultaten att det är möjligt

att särskilja användarnas processer men också att den data som kan i relation till dem är opålitlig. Detta kan betyda att det inte går att säga vilken användare som eventuellt bär anvar.

Malwareanalys av minnet kan användas för att till viss del bemöta the trojan

horse defense vilket teorin och resultaten ifrån experiment två visar. Det finns mycket

faktorer som påverkar hur undersökningen bör utföras och hur resultatet ska tolkas för att bemöta försvaret. Det finns alltid en chans för att missa saker men generellt sätt så kan minnesanalys öka eller minska tvivlet.

(42)

(43)

31

6 Diskussion

Detta kapitel inleds med en diskussion kring resultaten från experimenten och hur de potentiellt kan nyttjas för att bemöta olika former av SODDI försvar. Diskussioner kring minnesforensikens styrkor och svagheter i förhållande till detta berörs också.

En diskussion förs också kring den valda metoden, ifall den utnyttjades till fullo och förslag till alternativa metoder. Framtida arbeten diskuteras också i detta kapitel.

6.1 Resultatdiskussion

Den givna frågeställningen som arbetet haft har till viss del besvarats. Den första frågan som arbetet sökte att besvara var “Hur kan specifika artefakter upptäckas i minnet som inte

lagras till hårddisk på ett Windows 10 system?” Genom det första experimentet kunde vissa

data upptäckas som inte lagras till hårddisk. URL:er som besökts, data ifrån pdf-filer (om än oläsbar) som under rätt omständigheter skulle kunna utvinnas, CMD kommandon kunde ses med strängsökningar och filnamn samt sökvägar upptäcktes. Filnamn och sökvägar skulle troligtvis ändå kunna hittats genom en analys av hårddisken så länge inte särskilda registry keys och andra filer raderats ifrån hårddisken. Vilket inte är ett otroligt scenario om det rör sig om ett SODDI fall där den misstänkte är tekniskt kunnig.

Den andra frågan där undersökningar kring huruvida denna data kunde kopplas till ett specifikt användarkonto har också kunnat besvarats till viss del positivt. Samtliga av de processer som var av ett särskilt intresse för experimentet kunde ses tillhöra användaren. Resultaten ifrån experiment ett, del två talar för detta och visar att det är möjligt att särskilja olika användares processer när flera användare nyttjat ett system tätt efter varandra. Detta då resultaten visar att data fortfarande kan hämtas ut i relation till användare Evil efter att användare Friendly loggat in på systemet. Detta kan ha relevans när ett SODDI- försvar nyttjas i fall som involverar system med flera olika aktiva användare. Detta 

innebär också att Windows 10 inte raderar eller på annat sätt skriver över hela minnet då en ny användare loggar in.

Däremot sågs ett motstridigt resultat gällande data tillhörande vissa processer när URL:er ifrån Chrome kunde hittas i minnesregioner tillhörande Firefox. Vad detta innebär är svårt att avgöra utifrån det avgränsningar och antal utföranden som gjordes under experimenten. Om en annan användare hade öppnat en webbläsare, hade då dennes URL:er setts under den första användarens minnesregioner? För vidare undersökningar av detta skulle en djupare förståelse av exakt hur memdump fungerar behövas. Om detta enbart gäller för webbläsare eller också för andra processer har inte undersökts.

Den data som hittas i minnet kan vara svår att koppla till en specifik användare

enbart genom minnesanalyser. Det betyder däremot inte att fyndet är värdelöst. Data som bilder, textfiler och URL:er som identifierats i minnet kan kopplas till artefakter som finns i tex registry eller webbläsardatabaser för att avgöra vilket användarkonto det är som nyttjat dessa.