2009. október 29., csütörtök

Nyomozás a disk defrag után

Olvasható a SANS forensics blogon két kiváló bejegyzés arról, hogy milyen módon lehet kideríteni egy munkaállomásról, hogy futtatták-e rajta a töredezettségmentesítőt. Mielőtt rátérnénk a konkrét módszerekre, kicsit járjuk körül a probémát.

Defrag 1x1
Induljunk messziről. Amikor az operációs rendszerünk letöröl egy fájlt az eleinte (jó közelítéssel) szépen, sorfolytonosan elhelyezkedő fájlok közül, akkor keletkezik egy valamekkora méretű "lyuk", azaz szabadon felhasználható terület a lemezen. Amikor úgy dönt az oprendszer, hogy ebbe a területbe fog adatot írni legközelebb, akkor ha az éppen írni akart fájl nagyobb, mint a "lyuk", akkor csak egy része fér ide bele, a maradékot máshová kell tennie, tehát fragmentálódás következik be.

A fájlrendszer feljegyzi az egyes fájlokhoz tartozó fragmentek helyét, tehát a felhasználó számára gyakorlatilag transzparens a folyamat - egészen addig, amíg az összevissza található apró fragmentek okozta lemezműveleti overhead el nem éri a türelemküszöbét. A tünet meglehetően sztereotip: bármit kezdeményez a felhasználó, bárhová kattint, a lemez elkezd kerepelni, azonban elképesztően lassan történik bármi is. A defrag pontosan ezt a problémát orvosolja: megkeresi, hogy hol vannak a fájlok fragmentjei, és egymás mögé rendezi őket.

Forensic szempontból nézve a dolgot az egyik szemünk sír, a másik viszont nem feltétlenül. Egyrészt a defrag nagyon intenzív írással járó lemezművelet, emiatt a törölhető, ám visszanyerhető adatokban gazdag részekben sokszor egyszerű eszközökkel jóvátehetetlen roncsolást okoz (még egyszer: forensic szempontból, tehát most az a célunk, hogy minél több törölt fájlt hozzunk vissza, legitim működés szempontjából ez nem számít). A másik oldalon viszont a slackekben található adatokat nem semmisíti meg a defrag, tehát teljes védelmet semmiképp sem jelent az adatvisszahozás ellen. Slacknek nevezzük azt a területet, ami az operációs által kisméretű fájok (fragmentek) esetében a lefoglalt allokációs egységben a fizikailag felülírt területen kívül helyezkedik el. Xp esetében 4096byte az allokációs egység, az NTFS-sel viszont 512byte-os szeletekben írjuk felül a lemez tartalmát - emiatt, ha egy 1byte-os fájlt írunk, akkor annak 4096byte helyet foglal le az oprendszer, aminek az első 511byte-ját nullázza ki, tehát a maradékban érintetlen marad a lemezfelület.

Vadászat a defrag.exe artifactjai után
Az újabb Windows verziókban (Xp és frissebb) a defragmentálás korlátozott mértékben bár, de automatikusan lefutó taszkként lett definiálva. Emiatt egy-egy munkaállomás vizsgálatakor el kell tudnunk különíteni, hogy mely futtatások történtek a felhasználó kezdeményezésére, és melyek az operációs rendszer automatikus karbantartási folyamatainak keretében.

Sajnos nincs egyszerű mód a defrag indításának utólagos rekonstrukciójára, ugyanis az Event logokban egészen egyszerűen nem keletkeznek bejegyzések a töredezettségmentesítéshez Xp-n. Vistán és 7-ben már igen.

A töredezettségmentesítőt alapvetően kétféleképp lehet elindítani:
  • GUI-val (Start->Programs->Accessories->System Tools)
  • parancssorból a defrag parancs kiadásával (ezt használja a rendszerfolyamat)
Bármelyik módon is történik, két bejegyzés generálódik a Prefetch mappában (C:\Windows\Prefetch), az egyik a DFRGNTFS.exe-nek, a másik a Defrag.exe-nek. A Prefetchben található információk elárulják, hogy melyik végrehajtható fájlt mikor indították el utoljára és hányszor törént előzőleg indítás.

Mit mondhatunk a két elindítási módról?

GUI
A GUI tulajdonképpen egy snap-in a Microsoft Management Console-hoz, emiatt több helyen is megtalálhatóak elindításának nyomai:
  • Prefetch-ben az MMC.exe
  • UserAssist kulcsban a dfrg.msc
  • Az MMC Recent snap-ins registry-bejegyzésében a dfrg.msc, Disk Defragmenter.lnk
  • Időpecsétek a fájlokon (dfrgntfs.exe)
  • A Disk Defragmenter.lnk linkjében
Parancssori mód
A parancssoros indítás a defrag c: paranccsal lehetséges. Keletkező nyomok:
  • Prefetch
  • layout.ini a prefetch mappában. Kis magyarázat: a fájlt a menetrend szerinti defrag nem nyitja meg, nem használja, ellentétben a felhasználó által kezdeményezettel.
  • Timeline analízissel viszonylag munkásan bár, de jól következtethetünk manuális defragmentálásra (tipikusan egymáshoz közel helyezkednek el a CMD.exe, a defrag.exe és esetleg még valami, amit megpróbált elrejteni a felhasználó/támadó)

5 megjegyzés:

  1. miért is jó nekem ez?

    VálaszTörlés
  2. Nagyon jók a postok, gratula. Egy kukkot sem értek mégis izgalmas!!

    VálaszTörlés
  3. @névtelen:
    A fentiek ott hasznosak, hogy sok betörésnél egyfajta nyomelemzést megnehezítő/megelőző eszközként használják a defragmentálást, emiatt amikor incidenst vizsgálunk, fontos terület lehet a defragmentálások vizsgálata.

    VálaszTörlés
  4. Gratula a cikkhez, ez így mind szép és jó, de még nem következik belőle egyértelműen, hogy emberünk azért defragmentált, mert nyomokat akart eltüntetni :).

    Van egy rakat más töredezettségmentesítő is a beépítetten kívül (amelyek akár tetszés szerint beállítható sorrendben helyezik el az állományokat), nem is beszélve a wipe-free-space típusú módszerekről. Ezek használata során automatikusan "gyanús" személy leszel?

    VálaszTörlés
  5. @dagenham:
    Nem, nem leszel automatikusan gyanús.

    Minden a kontextustól függ: ha egy feltételezett gyilkossági helyszínen a tulajdonos főbérlő alaposan, hipóval fertőtleníti át az egész lakást, gyanús - annk ellenére, hogy a takarítás önmagában nyilvánvalóan nem az.

    VálaszTörlés

Kommentek