5 Experimentuppställning
5.2 Genomförande
Figur 3. Matematisk formel för beräkning av den procentuella kontaminationen
5.2 Genomförande
Jämförelsetestet är precis som vårt huvudexperiment uppdelat i tre moment där det vid olika tidsintervall [Figur 1] genererades RAM-dumpar som innehöll den virtuella maskinens volatila minne vid just den tidpunkt denna fil skapades, det vill säga .vmem filen. När den virtuella maskinen sedan startades upp skapades den första .vmem filen genom menyn "Debug" och därefter "Kommandorad...", följt av kommandot ".pgmphystofile" [11]. Detta för att spara det volatila minnet till den angivna filen, vilket genomfördes vid samtliga tidsangivelser enligt tidsintervallet.
Efter att de tre .vmem filerna genererades som behövdes för vårt jämförelsetest kunde analys [Figur 2, Figur 3] av dessa utföras med ändamål att få fram hur mycket kontamination som är rimligt att ske på en maskin under en tidsbestämd period.
Huvudexperimentet var uppdelat i tre moment där det vid olika tidsintervall [Figur 1] skapades RAM-dumpar av systemet. Det första steget i experimentet var att direkt vid start generera en ögonblicksbild för att få systemet i exakt samma tillstånd för nästkommande RAM-dump. Därefter genererades första RAM-dumpen i form av en fil med filändelsen .mem, och sparades därefter över på ett externt
lagringsmedia. Vidare efter att .mem filen sparades över laddades ögonblicksbilden in som tidigare skapats. Därefter hibernerades den virtuella maskinen i 15 minuter för att därefter generera RAM-dump 2. Innan andra RAM-dumpen skapades
genererades en ny ögonblicksbild, då syftet med experimentet är att påvisa
kontamination, samt att åstadkomma så många mätvärden som möjligt och leverera ett pålitligt resultat. Andra RAM-dumpen skapades nu och filen .mem, sparades likaså här över på ett externt lagringsmedia. Då jämförelse skedde mellan RAM-dump 1 och RAM-dump 2, följt av RAM-dump 2 och RAM-dump 3 laddades därefter den andra ögonblicksbilden in och den virtuella maskinen hibernerades i ytterligare 15 minuter. Slutligen var det dags för tredje och sista RAM-dumpen att skapas. Filen,
Experimentuppställning
21
Nu kunde vi jämföra två dump-filer i taget och tänkte därför eftersom vi har 3 st dump-filer för varje program att vi jämförde start mot pågående, sedan pågående mot den sista. Detta gjordes för att kontrollera om det skett kontamination i den enskilda programvaran där RAM-dumparna har genererats. Vidare behövde vi kontrollera kontaminationen genom att jämföra RAM-dump 1 av diverse IT-forensiskt program gentemot varandra för att se ifall det redan där gick att påvisa skillnader i det volatila minnet som har utvunnits. Detta gjordes också för RAM-dump 2 och slutligen RAM-dump 3.
Vid genomförandet av det första praktiska experimentet som vi valde att utföra med FTK Imager Version 4.2.0 startade vi upp den virtuella maskinen med den första ögonblicksbilden och skapade våra dump-filer enligt tidsintervallet [Figur 1]. Dump-filerna skapades i programvaran genom funktionen “Capture memory”. Detta genererade då en .mem fil som sparades över på ett externt lagringsmedia för senare analys.
Då vi hade våra ögonblicksbilder att utgå ifrån genomfördes samma process för OSForensics. I OSForensics 5.2.1007 skapades RAM-dumparna av det volatila minnet genom funktionen “Memory Viewer” och därefter “Dump Physical Memory”.
Detta kom då att generera en .mem fil. Dessa filer som skapats under tidsintervallet [Figur 1] sparades sedan över på ett externt lagringsmedia för senare analys.
Resultat
23
6 Resultat
Till att börja med kommer redovisning av jämförelsetestet ske då vi ville jämföra hur mycket kontamination som skett på en virtuell maskins volatila minne både utan och med IT-forensiska verktyg. För detta jämförde vi våra tre .vmem filer [Figur 2, Figur 3] som genererats enligt tidsintervallet [Figur 1] och presenteras i Tabell 1 och Diagram 1:
Tid (minuter)
Förändring (Bytes) Procent (%)
24353651
2,27
30
33930957
3,16
Tabell 1. Tabell över jämförelse-testets förändringar över angivna tidsperioder. Hänvisar till Bilaga B.
Diagram 1. Översiktlig förändring i jämförelse-testet i procent från 0–4 %. Hänvisar till Bilaga B.
Resultat Det som kan konstateras från huvudexperimentet av samtliga RAM-dumpar gjorda av programvarorna FTK Imager och OSForensics på det volatila minnet var att förändringar skett på systemet, både vid jämförelse av olika program samt vid jämförelse av program mot program. Skillnaden var att det hade skett större förändring vid användning av enskilda program, framförallt för OSForensics, men även för FTK Imager vid olika tidsintervall [Diagram 2]. Det blev mer förändringar på OSForensics ju längre processen pågick [Tabell 5]. I Diagram 2 följer en
redovisning av det fullständiga resultatet av samtliga RAM-dumpar gjorda av båda programvarorna:
Diagram 2: Översiktlig förändring i procent från 0–15 %. Hänvisar till Bilaga B.
Det första verktyget, FTK Imager, visade mindre kontamination (8,54 %) jämfört med vad OSForensics gjorde (14,61 %). Jämförelse av program mot program, det vill säga FTK Imager mot OSForensics visade endast en total skillnad på 8,09 %.
Resultat
25
Det som kan konstateras vid användning av FTK Imager och vid den första RAM-dumpen, som skedde efter 0 minuter användning, var att ingen kontaminering skett.
Efter 15 minuter skedde däremot förändringar i det volatila minnet, närmare bestämt 4,11 %. Slutligen efter 30 minuter hade ytterligare förändringar påvisats, 4,43 %. Tabell 2 visar tydligare på förändringen i tidsintervallet 0–30 minuter:
Tid (minuter)
Förändring (Bytes) Procent (%)
4,11
30
47572725
4,43
Tabell 2. Resultat för FTK Imager över förändring i det volatila minnet över angivna tidsperioder. Hänvisar till Bilaga B.
Resultat Programvaran OSForensics visade ännu tydligare förändringar i minnesstrukturen [Tabell 3] jämfört med vad FTK Imager gjorde under samma tidsintervall. Från start visade programvaran på 0 % förändring precis som FTK Imager. Efter 15 minuter var det relativt mycket skillnad, 5,59 %. Efter 30 minuter visades den mest
procentuella skillnaden från alla jämförelser som utförts, närmare bestämt 9,02 %.
Detta resulterade i att FTK Imager inte kontaminerar lika mycket som OSForensics gjorde, vilket betyder att OSForensics kan komma att vara mindre effektivt vid en RAM-dump då den visar på mer förändringar i det volatila minnet. Att det skett en förändring på 9,02 % från RAM-dump 2 till RAM-dump 3 bevisade att viktig information som kan vara betydande för en utredning kan ha utsatts för
kontamination. Här följer en tabell [Tabell 3] som visar tydligare på förändringen i tidsintervallet 0–30 minuter vid användning av OSForensics:
Tid (minuter)
Förändring (Bytes) Procent (%)
59970664
5,59
30
96851760
9,02
Tabell 3. Resultat för OSForensics över förändring i det volatila minnet över angivna tidsperioder. Hänvisar till Bilaga B.
Resultat
27
Vid den slutliga jämförelsen, där vi istället jämförde programvarorna mot varandra, det vill säga RAM Dump 1-3 i FTK Imager och RAM-dump 1-3 i OSForensics, för att se vilket program som bidrog till mest kontamination. Då fick vi reda på hur programvarorna skiljer sig åt med hjälp av att se hur mycket information varje program tar med [Tabell 5]. Tabell 4 visar denna förändring.
Tid (minuter)
Förändring (Bytes) Procent (%)
0
18139381
1,69
15
32341646
3,01
30
35176065
3,39
Tabell 4. Resultat för FTK Imager mot OSForensics över förändring i det volatila minnet över angivna tidsperioder. Hänvisar till Bilaga B.
Resultat För att ge en mer översiktlig illustration över de totala förändringar som skett i det volatila minnet från RAM-dump 1 - 3 från de IT-forensiska mjukvarorna, FTK
Imager och OSForensics, redovisar vi detta med ett diagram samt en tabell [Diagram 3, Tabell 5].
Diagram 3. Illustration över förändringen i det volatila minnet från RAM-dump 1 - 3.
Resultat
29 Programvara
Dump 1-Dump 2 Förändring (Bytes)
Procent (%) Dump 2-Dump 3 Förändring (Bytes)
Procent (%)
FTK Imager 4.2.0
44236046
4,11
47572725
4,43
OSForensics 5.2.1007
59970664
5,59
96851760
9,02
Tabell 5. Resultat från de IT-forensiska mjukvarorna med 3 RAM-dump-filer. Hänvisar till Bilaga B.
När jämförelse av programvarorna emellan utfördes, det vill säga RAM-dump 1 - 2
och RAM-dump 2 - 3, visar FTK Imager en kontinuerlig förändring när RAM-dumparna sker. Däremot i OSForensics ökade förändringen i det volatila minnet betydligt mer än vad samma dump på samma tidsintervall gjorde i FTK Imager. Då det skedde en markant ökning av förändring i minnet med OSForensics gjorde detta oss förvånande. Då FTK Imager var betydligt mer stabilt dumparna emellan jämfört med OSForensics var detta inget vi förväntade oss. Eftersom OSForensics nästintill var det dubbla efter 30 minuter jämfört med vad det först var efter 15 minuter krävde detta en mer noggrann analys som redovisas nedan, om vad det faktiskt var som kontaminerats och varför denna förändring har skett. Detta bidrog till följande fundering: varför sker det mer förändringar på OSForensics självt [Tabell 3] jämfört med när vi jämförde program mot program [Tabell 6]?
Resultat När vi därefter jämförde programvaran mot varandra [Diagram 4] var det betydligt mindre förändringar jämfört med det tidigare resultatet [Tabell 5]. När dumparna av respektive mjukvara jämfördes mot varandra fick vi ut ett tydligt resultat på att programvaran var väldigt lik i sin process vid skapande av RAM-dumpar. Eftersom OSForensics nästintill var det dubbla efter 30 minuter än vad det först var efter 15 minuter kräver detta en mer noggrann analys om vad det faktiskt är som
kontaminerats och varför denna förändring har skett.
Diagram 4. Illustration över förändringar i det volatila minnet från RAM-dump 1 – 3 programvarorna mot varandra. Hänvisar till Bilaga B.
Resultat
31 Programvara
Dump 1 - Dump 1 Förändring (Bytes)
Procent (%)
Dump 2 - Dump 2 Förändring (Bytes)
Procent (%)
Dump 3 - Dump 3 Förändring (Bytes)
Procent (%) FTK Imager
4.2.0 mot
OSForensics 5.2.1007
18139381
1,69
32341646
3,02
35176065
3,39
Tabell 6. Resultat vid jämförelse av mjukvarorna emellan. Från RAM-dump 1 - 3.
När analys av programvarorna emellan utfördes blev resultaten förvånansvärt bra.
Då det endast skiljde 1,69% procent mellan RAM-dump 1 av diverse program visade att både FTK Imager och OSForensics var lika i sin process med att dumpa det volatila minnet av en enhet, vilket den lilla procentskillnaden också visar på. Det som kan komma att påverka den stora procentskillnaden i ovanstående resultat [Tabell 5] var att OSForensics förmodligen fick med mer information i skapandet av RAM-dumparna jämfört med FTK Imager. Som anges i ovanstående tabell [Tabell 6]
var det en ökning av nästintill det dubbla mellan RAM-dump 2 av diverse program vilket kan hänvisas till att det sker kontinuerliga förändringar i det volatila minnet utan någon påverkan på systemet [Diagram 1]. Vid jämförelse av de sista RAM-dumparna, dump 3 mot 3 blev det endast en ökning av 0,37%. Då de procentuella skillnaderna programvarorna emellan var så pass låga bevisar att programvarorna är väldigt lika i sin process vid skapandet av RAM-dumpar.
Resultat
6.1 Vad förändrades i det volatila minnet?
När den procentuella skillnaden sedan var färdig var nästa steg att granska vad som hade kontaminerats. Detta utfördes med hjälp av verktyget Volatility i OSForensics, där ett flertal kommandon kan göras, bland annat sökning på specifika filer, körande processer och IP-adresser. Vidare använde vi FTK för ytterligare String-sökning.
Slutligen granskade vi vad som hade kontaminerats med hjälp av “file-compare” i en HxD Hex Editor, där två filer läggs in i programvaran och jämförs.
Den mest relevanta informationen som hade förändrats var drivrutiner och IP-adresser. Det var häpnadsväckande hur många bakgrundsprocesser som var aktiva trots att ett system är inaktivt. Något som också var förvånande var hur lätt det är att få fram exakt vad som gjorts på systemet under en viss tid genom samtliga tidsstämplar som loggas, samt vilket användarnamn som gjort vad medan det volatila minnet varit aktivt.
Den vanligaste förändringen som gjordes vid jämförelse av samtliga RAM-dumpar var filer som låg på operativsystemet. De filer vi noterade som försvunna var följande:
• Spaceport.sys. En Windows drivrutin som är en viktig del av
operativsystemet. Denna drivrutin hade kontaminerats från RAM-dump 2 i FTK Imager men fanns på övriga RAM-dumpar.
• Mpksl. En drivrutin som används av Microsoft Security Essential. Denna drivrutin hade kontaminerats på RAM-dump 1 i FTK Imager, men fanns på de övriga RAM-dumparna.
• Rtcdyn.mdf. En användarfil som registreras i en transaktionslogg om vad användaren har utfört på systemet. Denna fil hade kontaminerats från RAM-dump 1 i FTK Imager men fanns på övriga RAM-dumpar.
• Ett flertal IPv4 adresser saknades på RAM-dump 1 i OSForensics som fanns på övriga RAM-dumpar för samma program. Detta bevisar att OSForensics inte alltid lägger fokus på samma ställen i minnesstruktren vid skapande av en RAM-dump.
• Ett flertal TCPv4 adresser fanns med på RAM-dump 1 i FTK Imager men inte på övriga RAM-dumpar.
• Mutexobjekt. Detta är ett synkroniseringsobjekt vars tillstånd är att signalera när denna inte ägs av någon tråd. Mutexobjekt hittades på RAM-dump 2 i OSForensics men inte på de övriga dumparna.
• VBoxGuest. En drivrutin som består av systemprogram som optimerar operativsystemet för bättre prestanda och användbarhet. Denna drivrutin
Resultat
33
• Crash dump. En drivrutin som finns på systemet för att ge åtkomst till disken under en krasch. Denna drivrutin fanns inte med på RAM-dump 2 i FTK Imager, men fanns med på övriga dumpar.
• Kernel memory. Genomsökning av den ökända regionen i kärnans minne.
Här hittades två filer med namnen vmswitch.sys och storport.sys. Dessa filerna fanns inte med på RAM-dump 1 i FTK Imager, men på övriga i FTK Imager.
Vilken av denna information är viktig respektive mindre viktig ur ett IT-forensiskt perspektiv?
Från våra egna erfarenheter vet vi att IP-adresser är väldigt givande information då IP-adressen kopplas till en fysisk plats och därmed en person. Det vi kan konstatera från de bevis på kontaminationen vi har fått ut ser vi att ett flertal IP-adresser har utsatts för kontamination vid användning av de IT-forensiska verktygen. Vidare är användarfiler viktig information vid bevisinsamling då detta kan ge information om vad en specifik användare har utfört på systemet. Ett exempel på detta är
rtcdyn.mdf som hade kontaminerats. Slutligen är Windowsfiler och drivrutiner bland de viktiga bevis som har kontaminerats i vår undersökning. Detta eftersom att denna information är viktig för operativsystem och kan leda till att datorn inte fungerar korrekt om dessa filer/drivrutiner inte finns tillgängliga. I en dator samspelar alla Windowsfiler och drivrutiner. Skulle däremot något av de nämnda försvinna eller inte finnas tillgängliga kan det ge effekt på andra ställen vilket kan leda till kontamination av viktiga bevis vid en utredning.
Diskussion
35
7 Diskussion
I detta kapitel resonerar vi kring incidenter, funderingar och följder som uppstått under arbetets gång. Vi relaterar till litteraturstudier och tidigare experiment inom detta område för att framhäva vårt mål med denna rapport.
De resultat som våra experiment gav var till en början till vår förvåning. Vårt
jämförelsetest gav en procentuell skillnad på 2,27% och 3,16%. Då det skulle ske en förändring i det volatila minnet är vi fullt medvetna om, men att det skulle skilja 2,27% och 3,16% under tidsintervallet utan användning av systemet var
förvånande. Detta resultat kunde vi sedan använda som en grund i nästkommande experiment som kontroll för den förväntade förändringen vid användning av FTK Imager och OSForensics.
Huvudexperimentet gav oss vid analys av RAM-dumparna gjorda av FTK Imager relativt hög kontamination, mer än vad vi förväntat oss, och OSForensics gav en betydligt högre procentuell skillnad [Tabell 5]. Då den procentuella skillnaden i FTK Imager, 4,11% och 4,43% bevisar att i samband med den kontinuerliga
förändringen som sker i det volatila minnet [Tabell 1] och med de förändringar som sker vid skapande av RAM-dumparna med FTK Imager inte har någon direkt
påverkan på systemet. OSForensics hade däremot betydligt högre siffror, 5,59% och 9,02% vilket bevisar att OSForensics inte är lika stabil i sin process i skapandet av RAM-dumpar. Denna stora förändring kan delvis bero på att programstorleken hos OSForensics är större jämfört med FTK Imager, men även att OSForensics fokuserar på olika delar i minnesstrukturen i sin process att dumpa det volatila minnet av ett system.
Hur utvecklingen av vårt experiment skulle gå tillväga var en utmaning, då vi klargjorde tidigt vad vi ville uppnå med arbetet kunde detta fortfarande utföras på olika sätt. Vi ville påvisa förändringar i det volatila minnet för två stycken enskilda program och se hur dessa förändringar skiljer sig åt för olika tidsintervall, samt hur detta behandlas med operativsystemet Windows 10. När vi däremot kommit en bit på vägen frågade vi oss varför vi ska jämföra programmets RAM-dumpar mot varandra. Efter vidare analys valde vi att genomföra detta för att få ett ännu tydligare resultat och försöka ta reda på om programvarorna emellan skiljer sig åt eller ej i processen för utvinning av volatila minnet.
Diskussion Då det ska ske så lite förändringar på systemet som möjligt vid utförandet av RAM-dumparna, var valet av virtuell miljö självklar, då vi med hjälp av detta kan ta ögonblicksbilder och utgå från exakt samma tidpunkt och läge i maskinen från samtliga RAM-dumpar och undvika eventuella felmarginaler. Detta resultatet blir då mer intressant, jämfört med om vi inte hade använt oss av en virtuell maskin samt haft igång processer i bakgrunden vid RAM-dumparna, just för att det hade varit självklart att kontamination hade skett [Diagram 1]. Å andra sidan hade detta varit en intressant studie, just för att granska hur mycket en specifik process kan
förändra det volatila minnet. Däremot kände vi att fokus på hur kontamination sker vid paus av systemet är mer intressant. Anledningen till att vi valde 1GB (1024 MB) RAM-minne på den virtuella maskinen är på grund av metoden som valdes för att jämföra dump-filernas binära uppbyggnad mot varandra är en tidskrävande process och kommandona för detta matades manuellt in i Linux. Valet att begränsa storleken på RAM-minnet till 1GB gjorde att vi på ett mer strukturerat sätt kunde analysera dump-filerna och därmed få ut ett bra resultat på vad det faktiskt är som har
kontaminerats. I moderna hemdatorer finns det stöd för betydligt mer RAM-minne, något som kan vara ett stort problem för IT-forensiker vid analysering av dump-filer vid ett eventuellt brott. Att veta tillvägagångssättet och var en IT-forensiker ska leta efter information gör att eventuella fel undviks vid en live-respons.
Själva analyseringen av RAM-dumpar kan i många fall anses komplicerad då dump-filens innehåll inte står i klartext, utan i binärkod. Detta är en anledning till varför användning av analyseringsverktyg underlättar, då dessa gör det möjligt att få ut data i klartext och avkoda binärkoden som filen består av. Volatility är ett väldigt bra designat program med ett givande grafiskt gränssnitt och inprogrammerade skript som gör det möjligt att utföra kommandon på ett enkelt och smidigt sätt och därmed få ut viktig information om det körande systemet vid en live-respons.
Själva utförandet av RAM-dumparna var en utdragen process, då det var många dumpar som skulle göras på många tidsintervall. För att förtydliga oss om att resultatet av samtliga RAM-dumpar var exakta, gjorde vi experimenten ett flertal gånger. När vi väl hade fått fram samtliga RAM-dumpar, noterade vi att det fanns väldigt många parametrar av de kommandon som vi valt att använda oss av i Linux.
Metoden vi valde för att göra denna jämförelse av filerna valdes efter att vi testat flera olika kommandon och funktioner, såsom WinDiff i Windows 10. Däremot gav denna funktion oss inte riktigt det resultat vi var ute efter och detta ledde till att vi valde att använda oss av cmp och wc kommandot med parametrarna -l på båda.
Dessa valdes på grund av att utdatan av dessa parametrar på diverse kommando gav oss en direkt skillnad på antalet bytes två dump-filer emellan.
Diskussion
37
Ur ett IT-forensiskt perspektiv är kontamination väldigt känsligt, då näst intill allt vi gör på en dator lämnar någon form av kontamination efter sig. Det hela handlar om att så lite förändring på RAM-minnet som möjligt ska ske. Det vi fokuserade på kallas för beviskontaminering, där vi kontrollerar om förändring skett före, under och efter en incident. Förändringar som brukar ske i RAM-minnet är olika typer av data [3.3 Volatilt minne].
Då vi var medvetna om att det krävs en bra metod för att påvisa kontamination utöver de procentuella skillnaderna [Diagram 2] var metodvalet med Volatility självklart. Planen från start var att hitta och lokalisera exakt var i minnesstrukturen som kontaminationen har skett. Det var en utmaning att hitta och lokalisera exakt var och vilken data som har förändrats. Det vi fick ut med Volatility var mer som en pekning i rätt riktning om vart kontaminationen har skett, men det fanns
svårigheter med att hitta exakt vilken data som hade förändrats. Detta ledde till att vi fick ta till andra åtgärder, såsom analysering i HxD Hex Editor där det finns stöd
svårigheter med att hitta exakt vilken data som hade förändrats. Detta ledde till att vi fick ta till andra åtgärder, såsom analysering i HxD Hex Editor där det finns stöd