NTFS aktivitás logja visszamenőlegesen

Microsoft Windows

Sziasztok. Kicsit forensic témájú is lehetne a kérdés.

(Árpi remélem olvasod, hátha van erre ötleted)

Szóval van egy W10 Pro gép, file "szerver" / NAS minőségben. Van egy C: meg egy D: meghajtó. A C: 1TB, a D: pedig egy 18TB-os NTFS partició. Múlt héten a D:-n kb. 150 GB körüli szabad hellyel. Aztán most hét elején mikor ránéztem, hirtelen lett a D:-n kb. 550 GB szabad terület. Én nem töröltem róla (ennyit biztosan nem), a másik user elvileg törölt róla, de az ő cuccai főleg a C:-n vannak. Látszólag nem tűnt el olyan dolog, aminek meg kellene lennie, de mégis bosszant h. nem tudom kideríteni mik törlődtek. Ez már az a nagyságrendű diffi egyik napról a másikra, ami feltűnik.

Sajnos full backup nincs a D:-ről, h. biztosra meg tudjam mondani mi tűnt el, csak néhány fontosabb könyvtár tartalmát mentem. Keresgéltem az even viewer-ben, és meglepő de van ott elég részletes NTFS log:

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-Ntfs%4Operational.evtx

illetve van egy recovery-bb jellegű %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-Ntfs%4WHC.evtx is, de ez inkább talán csak arra jó h. az ember lássa mikor volt FS sérülés (pl. áramszünet / szabálytalan leállítás után).

Az NTFS Operational log szerint az EventID 142 egy naponta 1x generált bejegyzés, ami összesítést ad az elmúlt 24 órában látott legmagasabb+legalacsonyabb szabad területről, külön bejegyzés particiónként. Ezek alapján kb. be lehet határolni melyik 2 bejegyzés között törlődtek a fájlok (== lett a maximum free space 500 GB először).

Az EventID 152-ben jegyzi h. az elmúlt 1 órában mennyi fájltörlés volt, és ebből annyi külön bejegyzés van, ahány különböző processz (.exe) végzett ilyen törlést és látszódott is h. melyik processz volt a felelős (talán mert lehet olyan eset is ahol anonim megy a törlés vagy ha a SYSTEM nevében akkor az nem került loggolásra?).

Az EventID 158 mutat egy összesítést az NTFS/MFT műveletekről (hány darab write / hány darab read stb.), tehát ezek alapján elvileg ki lehet sakkozni mikor voltak a nagy törlések.

Kérdés h. vajon részletesebb log pl. összes törölt fájl mérete mennyi volt, TOP10 legnagyobb méretű törölt fájlok neve, vagy hasonló beszédesebb statisztikákat meg tudok-e szerezni valahonnan.

Egyelőre itt tartok. Jó lecke volt h. kellene valami reporting a jövőre nézvést.

( neutrino v | 2024. 05. 24., p – 10:55 )

Szerkesztve: 2024. 05. 24., p – 11:02

Az NTFS Operational logok alapján valóban meg lehet próbálni nyomon követni a fájl törlését vagy mozgatását a D: meghajtón. Az Event Viewer hasznos eszköz ilyen esetekben, és az általad említett EventID-k is segíthetnek abban, hogy jobban megértsd, mi történt a meghajtón.

Lépésről lépésre ellenőrzés az Event Viewer-ben:

  1. EventID 142 és 152 ellenőrzése:

    • EventID 142: Ezzel az eseménnyel naponta egyszer loggolja a rendszer az egyes meghajtók legmagasabb és legalacsonyabb szabad hely értékeit az elmúlt 24 órában. Ezzel meg tudod határozni azt az időablakot, amelyben a szabad terület hirtelen növekedett.
    • EventID 152: Ezzel az eseménnyel óránként rögzíti a fájltörlések számát különböző folyamatok szerint. Ez segíthet azonosítani, hogy melyik folyamatok felelősek a jelentős törlésekért.

  2. Logok szűrése és elemzése:

    • Nyisd meg az Event Viewert és navigálj a Applications and Services Logs > Microsoft > Windows > Ntfs > Operational fához.
    • Szűrd le az eseményeket az EventID alapján (142 és 152). Az időbélyegek alapján határozd meg az időablakot, amelyben a változások történtek.

  3. Folyamatok azonosítása:

    • Az EventID 152 részletes információkat nyújt a fájltörlő folyamatokról. Keresd meg azokat az eseményeket, amelyek nagy számú fájltörlést jeleznek, és figyeld meg, mely folyamatok (pl. explorer.exe, cmd.exe stb.) voltak érintettek.

További lépések a részletes nyomozáshoz:

  1. Fájlrendszer-ellenőrzés:

    • Használj egy dedikált fájlrendszer-ellenőrző eszközt (pl. TreeSize Free vagy WinDirStat), amely segíthet részletesen megvizsgálni a meghajtón lévő fájlokat és könyvtárakat. Ezek az eszközök grafikus felületen mutatják meg a meghajtó tartalmát és a fájlok méretét.

  2. Fájlrendszer naplózás engedélyezése:

    • Ha még nem tetted, érdemes lehet engedélyezni az NTFS Auditálást, amely részletesebb naplózást biztosít a fájlrendszer műveleteiről. Ezt az Group Policy Editor segítségével teheted meg:
      • Menj a Start menübe, írd be, hogy gpedit.msc és nyomj Enter-t.
      • Navigálj a következő útvonalra: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Object Access.
      • Engedélyezd a Audit File System beállítást.

  3. Shadow Copies ellenőrzése:

    • Ha a Shadow Copies szolgáltatás engedélyezve van a D: meghajtón, ellenőrizd, hogy van-e elérhető korábbi verzió. Ezek segíthetnek visszaállítani az elveszett fájlokat vagy megnézni a korábbi állapotot.
      • Kattints jobb gombbal a D: meghajtóra, válaszd a Properties lehetőséget, majd a Previous Versions fület.

Szóval, ha nem volt bekapcsolva az NTFS audit, akkor nem tudod kideríteni.

Aláírás _Franko_ miatt törölve.
neut @

( Imo | 2024. 05. 24., p – 11:11 )

Tranzakciós logban ($LogFile) esetleg benne lehet még, de minél tovább használod, annál hamarabb fog kikopni belőle, csinálj gyorsan egy másolatot belőle. (pl. winhex-el)

A logot parse-olni pl. ezzel tudod https://github.com/jschicht/LogFileParser

Egyébként nem volt a volume-on shadow copy? (ha nem, miért nem? :)

Ha volt, akkor akár az is okozhatott ekkora mozgást, hogy régi shadow-t törölt, de igazából nem veszett el semmi adatod.

Windows 10-en már nincs Shadow Copy. Az szerver-only fícsör lett. File history lett helyette. Az meg kb használhatatlan arra amire nekem kellene (ugyanazon a meghajtón nem tud historyt fenntartani a fájlokról, külön pl. külső drive-ra kellene mutatnia).

A logfile szerintem már veszett fejesze nyele ennyi idő után, de teszek vele 1 próbát, ha adsz egy pár soros tippet a Winhex-el hogyan kell lementeni.

Windows 10-en már nincs Shadow Copy. Az szerver-only fícsör lett

Hogyne lenne, System Restore és az összes backup solution ezen alapúl.
Ha a System Restore be van kapcsolva, a Shadow Copy Explorer-ek böngészni tudod a snapshot-okat vagy parancssorban a "vssadmin list shadows".

Most vakarom a fejem elég keményen. Mert valószínűleg igazat mondasz. Közben rájöttem h. csak a C:-re engedélyeztem a system protection-t, a D:-re nem. Ezért nem is jelent meg a D: properties-ben a Previous Versions tab. Valahogy összekavarodott a fejemben a system restore feature meg a system protection, h. az csak system file-ok védelmére használható ha restore point-ot készítek. User file-ok nem lesznek benne. Így valószínűleg pont ezért nem is kapcsoltam be a D:-re, amin ugye elvileg nincsenek system file-ok, csak user fileok.

Viszont akkor az öreg faszságot beszél itt: https://youtu.be/okV3ZojWyN0?t=589

Mert szerinte csak registry-t ment a restore point és system fájlokat. A user fájlokat ezek alapján nem lehetne belőle helyreállítani.

Vagy én értem félre: a System restore varázsló lefuttatása csak a registry-t állítja vissza a restore point alapján, viszont a user fájlokat is védi ugyanaz a Restore Point, csak azokat meg a previous versions-ön keresztül lehet elérni és szelektíven visszaállítani. Ha ez utóbbi, akkor kurvára félrevezető ahogy ez a faszi magyarázza.

Vagy én értem félre: a System restore varázsló lefuttatása csak a registry-t állítja vissza a restore point alapján, viszont a user fájlokat is védi ugyanaz a Restore Point

System Restore a registry-t, a userhome-okat, pár belső DB-t és a monitorozott kiterjesztéssel rendelkező fájlokat állítja vissza.
Viszont, a motorháztető alatt szerintem teljes snapshot készül amit kézzel tudsz browse-olni és visszaállítani (lásd Shadow Copy Explorer felül).

Hajlamos vagyok úgy érteni, hogy a Volume Shadow Copy az valóban a teljes volume-ra vonatkozik. Tehát a Restore point alapján bármilyen file visszaállítható kellene legyen.

Na ez a monitorozott kiterjesztések listája is jó mikroszoft-idiótán van megfogalmazva. Most akkor ezeket a kiterjesztéseket miért monitorozza? Hogy utána ne kerüljenek bele a restore point-ba? Vagy csak ezek kerülnek bele? Vagy ezeknek a módosítását is trackeli? Nem értem.

( Tassadar v | 2024. 05. 24., p – 11:43 )

Szerkesztve: 2024. 05. 24., p – 11:43

Kérdés h. vajon részletesebb log pl. összes törölt fájl mérete mennyi volt, TOP10 legnagyobb méretű törölt fájlok neve, vagy hasonló beszédesebb statisztikákat meg tudok-e szerezni valahonnan.

Ha az NFTS Auditing nincs bekapcsolva a konkrét mappára, szerintem nem.
Ha ezt bekapcsolod, minden kiválasztott fájlműveletről bejegyzést küld eventlog-ba.