테마

USN Journal — NTFS 변경 저널 ​

NTFS Change Journal은 파일 생성·삭제·이름변경·데이터 확장을 시간순으로 기록한다. SS는 이 기록으로 삭제된 치트의 흔적을 추적한다. USN은 "이 볼륨에서 무엇이 생기고 사라졌는가"를 보여 준다.

왜 중요한가 ​

Prefetch가 무엇이 실행됐는지를 보여 준다면, USN은 무엇이 생기고 사라졌는지를 보여 준다. 두 축을 합쳐야 타임라인 그림이 완성된다.

파일을 지우는 행위 자체가 USN에 기록된다. 삭제한 파일의 이름과 시각이 볼륨 수준에서 남기 때문에, "파일이 지금 없다"와 "파일이 존재한 적 없다"를 구분할 수 있다. Prefetch .pf 파일 자체의 삭제도 USN에 남으므로, Prefetch를 와이프하면 .pf DELETE 레코드가 생긴다.

역설적으로 USN은 안티포렌식의 최전선이다. 다른 축을 지우는 행위가 대부분 여기에 흔적을 남기고, 저널 자체를 지우는 행위는 저널 메타데이터와 이벤트 로그에 흔적을 남긴다.

무엇인가 ​

항목설명
정식 이름NTFS Change Journal (USN Journal)
위치\$Extend\$UsnJrnl:$J (+ $Max), 볼륨별
기록 내용파일 이름, 변경 유형, 타임스탬프, 부모 디렉터리 참조(FRN)
변경 유형 예FILE_CREATE, FILE_DELETE, RENAME_OLD_NAME/RENAME_NEW_NAME, DATA_OVERWRITE, DATA_EXTEND, BASIC_INFO_CHANGE(속성·타임스탬프), SECURITY_CHANGE(ACL), STREAM_CHANGE/NAMED_DATA_OVERWRITE(ADS)
크기·랩저널은 최대 크기로 제한된 스트림이다. 고활동 볼륨에서는 오래된 레코드가 랩(wrap)으로 밀려난다
한계NTFS와 ReFS가 저널을 지원하고 FAT32·exFAT에는 없다. ReFS에는 $MFT가 없어 $MFT를 직접 읽는 도구는 ReFS 볼륨에서 동작하지 않는다. Windows 11의 Dev Drive(빌드 22621.2338 이상)는 ReFS 볼륨이다

검색 인덱서, 백업 소프트웨어, 복제 엔진이 이 저널에 의존한다. SS 전용이 아니라 OS 인프라의 일부로, 볼륨이 NTFS면 기본으로 돌아간다.

저널의 상태 자체도 증거다. fsutil usn queryjournal C:는 저널 ID(생성 시각과 대응), First/Next/Lowest Valid USN, 최대 크기를 보여 준다. 저널 ID가 부팅·로그인 시각보다 늦으면 세션 중에 저널이 새로 시작된 것이다. First USN은 지금 읽을 수 있는 첫 레코드이고, Lowest Valid USN은 이 저널 인스턴스에 처음 기록된 레코드다. First USN이 Lowest Valid USN보다 크면 최대 크기를 넘어 오래된 레코드가 밀려난 것(랩)이다. First USN이 Lowest Valid USN보다 작으면 저널에 새 식별자가 찍힌 것이고, 그 사이의 변경은 저널에 기록되지 않았을 수 있다. 파서로는 JournalTrace(커뮤니티 계열 SS 도구), MFTECmd($J 직접 파싱), UsnJrnl2Csv, 상용 DFIR 제품을 쓴다.

SS에서 어떻게 쓰나 ​

  1. T+14에 시간 범위와 경로 키워드(.exe·.jar·.dll·제보명·클리너명)로 필터링해 USN을 export한다.
  2. 스캐너 히트·PF에 나온 이름을 USN에서 검색한다.
  3. FILE_DELETE 레코드가 있으면 삭제 시각을 기록하고 R3-AF로 넘긴다. 짧은 창에 .pf·exe가 몰려 지워졌으면 정리 클러스터다.
  4. CREATE만 있고 DELETE가 없으면 파일이 아직 어딘가에 있을 수 있다. RENAME 체인(OLD→NEW 쌍)이면 이동·이름 바꾸기를 본다.
  5. 결과가 없으면("USN에 없다") 반드시 두 번째 도구로 재확인하고 볼륨·권한을 점검한다.
  6. 저널 상태를 본다. fsutil usn queryjournal C:로 저널 ID와 USN 범위를 확인하고, 저널 생성 시각이 세션 도중이거나 $J 크기가 이상하게 작으면 삭제 정황을 R3-AF와 맞춘다.

듀얼 도구 규칙. "USN에 없다"고 주장하려면 반드시 다른 USN 파서로 재확인한다. 한 도구가 파싱에 실패할 수 있다. 음성 주장에는 도구 이름과 버전을 남긴다.

우회 기법과 남는 흔적 ​

공격자가 USN을 무력화하거나 USN에 남을 흔적을 줄이는 방법은 정해져 있고, 각각 다른 곳에 파생 흔적을 남긴다. 검사자는 기법 자체보다 그 기법이 남긴 파생 흔적을 본다.

저널 통째 삭제 ​

  • 공격자가 하는 일: 관리자 권한으로 fsutil usn deletejournal /D C: 실행. 저널 삭제·비활성화로 파일 변경 추적을 끊는다.
  • 남는 흔적: 저널이 새로 시작돼 가장 오래된 레코드가 로그인·게임 시작 이후다. queryjournal의 저널 ID가 부팅보다 최신이고, $J·$Max 수정 시각이 최근으로 급변하며 $J 크기가 매우 작다. Application 로그 3079는 저널 삭제 지표로 인용되는 이벤트다(단독 증거 금지, 저널 메타데이터와 교차). fsutil.exe의 Prefetch·BAM 실행 기록이 남는다.

선택적 파일 삭제 ​

  • 공격자가 하는 일: 의심 파일만 지우고 저널은 둔다. 저널 삭제보다 덜 눈에 띈다고 판단한다.
  • 남는 흔적: FILE_DELETE가 짧은 창에 몰린다. 제보 시간대와 겹치는 경로만 지워지고 시스템 노이즈는 그대로면 타겟 삭제 정황이다. BAM·메모리엔 실행이 있는데 디스크만 없으면 삭제를 의심한다.

휴지통 우회·즉시 삭제 ​

  • 공격자가 하는 일: 휴지통을 거치지 않는 "즉시 삭제" 설정을 켜거나 Shift+Del로 지워 복구 가능성을 없앤다.
  • 남는 흔적: 삭제 방식과 무관하게 USN의 FILE_DELETE는 그대로 기록된다. 즉시 삭제 설정(레지스트리) 자체와 $Recycle.Bin의 비정상적 부재가 추가 신호다. 검사자는 휴지통 설정 값을 확인하고, 휴지통이 비어 있어도 저널의 삭제 레코드로 삭제 사실을 입증한다.

이름 바꾸기 반복 ​

  • 공격자가 하는 일: 치트 파일명을 여러 번 바꿔 이름 검색을 끊는다.
  • 남는 흔적: RENAME_OLD_NAME → RENAME_NEW_NAME 레코드 쌍이 같은 FRN에서 연쇄로 남는다. 마지막 NEW_NAME이 현재 이름이다.

ADS 은닉 ​

  • 공격자가 하는 일: 정상 파일에 실행 파일을 대체 데이터 스트림으로 숨긴다.
  • 남는 흔적: STREAM_CHANGE·NAMED_DATA_OVERWRITE 이벤트가 호스트 파일에 기록된다. 검사자는 dir /r이나 스트림 열거 도구로 명명 스트림을 나열하고, 비정상 크기의 Zone.Identifier나 실행 파일 크기의 숨은 스트림을 가려낸다.

타임스탬프 조작 ​

  • 공격자가 하는 일: Timestomp·Set-ItemProperty로 $SI 타임스탬프를 과거로 위장한다.
  • 남는 흔적: 최근 BASIC_INFO_CHANGE 이벤트가 있는데 $SI가 오래된 조합이 강한 증거다. MFTECmd로 $SI와 $FILE_NAME을 비교하고, 시스템 시각 변경은 이벤트 4616과 대조한다.
  • 24H2 주의: Windows 11 24H2에서는 이름 바꾸기, 같은 볼륨 안의 탐색기 이동, 휴지통 이동 때 $FILE_NAME이 직전 $STANDARD_INFORMATION의 접근·수정 시각과 메타데이터를 물려받는다. 복사본도 원본의 $SI 메타데이터를 물려받는다. 조작된 $SI가 이런 동작으로 $FN에 옮겨지면 두 속성의 시각이 같아져 $SI·$FN 비교만으로는 조작이 보이지 않을 수 있다. 24H2에서는 비교 결과보다 BASIC_INFO_CHANGE·RENAME 레코드의 저널 시각을 먼저 본다.

내용 덮어쓰기·Hex 편집 ​

  • 공격자가 하는 일: 해시·문자열 기반 탐지 회피를 위해 바이너리를 직접 수정한다.
  • 남는 흔적: DATA_OVERWRITE|CLOSE·DATA_EXTEND|CLOSE 이벤트가 수정 시각을 남긴다.

.pf 내용 비우기 ​

  • 공격자가 하는 일: .pf를 메모장으로 열어 내용을 지우고 저장한다. 파일은 지우지 않아 삭제 레코드만으로는 드러나지 않는다고 판단한다.
  • 남는 흔적: 파일 크기를 0으로 줄이는 수정이 DATA_OVERWRITE·DATA_TRUNCATION 계열 이벤트로 기록되고, JournalTrace 같은 파서가 DATA_TRUNCATION으로 표기한다. 검사자는 Prefetch 폴더에서 내용이 빈 .pf를 플래그하고 저널의 수정 시각과 대조한다. 파서 관점의 설명은 Prefetch 카드에 있다.

파일 교체·경로 스왑 ​

  • 공격자가 하는 일: 치트 삭제 후 같은 이름의 정상 파일을 그 자리에 두거나, 실행 뒤 치트를 다른 폴더로 옮기고 원 경로에 동명의 정상 파일을 둔다.
  • 남는 흔적: FILE_DELETE 직후 동일명 FILE_CREATE 또는 RENAME이 결정적 패턴이다. 다른 폴더로 옮기는 경로 스왑 변형은 RENAME_OLD_NAME → RENAME_NEW_NAME이 이동을 보여 주고 원 경로에 다시 CREATE가 떨어지는 연쇄로 남는다. 현재 파일의 생성 시각이 실행 시각(PF·BAM)보다 늦으면 교체를 의심하고, 동명 파일의 해시·크기·생성 시각을 실행 시각과 대조한다. Windows 11 24H2부터는 복사한 파일이 원본의 타임스탬프를 물려받으므로 저널의 DELETE→CREATE 연쇄를 먼저 본다.

저널 없는 공간으로 회피 ​

  • 공격자가 하는 일: FAT32·exFAT USB나 별도 파티션에서 작업하거나, 가상 디스크(VHD·VHDX)를 만들어 FAT32로 포맷한 뒤 그 안에서 작업한다. 저널이 없는 파일시스템이면 기록 자체가 생기지 않는다는 계산이다. VHD는 더블클릭만으로도 마운트된다.
  • 남는 흔적: 볼륨에 USN이 없는 것 자체가 리드(재검증이 필요한 단서)다. 가상 디스크 우회는 NTFS 볼륨에 수백 MB짜리 .vhd·.vhdx 파일 본체, diskpart 실행 기록(PF·BAM), MountedDevices·SetupAPI·Mountmgr의 마운트·장치 이벤트, 탐색기 탐색 기록을 남긴다. USBDeview·PnP 로그의 USB 연결 기록, diskmgmt의 "할당되지 않은 공간"이 보조 증거다. 검사자는 저널이 없는 볼륨을 확인한 뒤 NTFS 쪽에서 VHD 파일과 마운트 기록을 찾는다.
  • ReFS·Dev Drive: Dev Drive 같은 ReFS 볼륨은 USN 저널을 지원하는 파일시스템이다. 저널이 없다고 적기 전에 볼륨 파일시스템과 저널 상태를 확인한다. ReFS에는 $MFT가 없으므로 $MFT 기반 도구가 낸 빈 결과를 저널 부재로 읽지 않는다.

클라우드 Vault 회피 ​

  • 공격자가 하는 일: 치트를 OneDrive Personal Vault 같은 동기화 잠금 영역에 둔다. "삭제·교체가 저널에 안 뜬다"는 주장이 보고된 우회다.
  • 남는 흔적: 주장과 달리 Vault 잠금·해제 상태, OneDrive 동기화 로그, 자리표시자(placeholder) 파일 잔재, Vault 접근 이벤트가 남는다. 검사자는 OneDrive 클라이언트의 동기화 로그와 Vault 상태를 확인하고, 자리표시자만 남은 파일의 동기화 이력을 본다.

정상 vs 이상 ​

구분정상이상
레코드 양많음(게이밍 PC는 대량 활동)극소 또는 저널 비활성화
삭제 패턴산발적, 다양한 경로의심 경로만 표적 삭제 후 클리너
저널 상태저널 ID가 부팅보다 이전저널 ID가 부팅·로그인 이후(재생성 의심), $J 크기 급변
랩·불연속First USN ≥ Lowest Valid USN (랩이 있으면 First가 더 크다)First USN < Lowest Valid USN(기록 불연속). 오래된 구간이 통째로 없으면 저널 ID 시각과 함께 queryjournal로 랩인지 삭제인지 구분
사용자 진술파일 설명이 일치"그 파일 본 적 없다"는데 USN에 경로

오탐 ​

  • 저널 랩(wrap): 고활동 디스크에서 오래된 이벤트가 사라진다. 이 경우는 Insufficient이며 와이프의 근거로 쓰지 않는다.
  • 도구 권한 미상승 또는 잘못된 볼륨: 관리자 권한이 없거나 다른 드라이브를 읽은 경우다.
  • 서드파티 싱크·백업 폭풍(OneDrive, Dropbox 등이 대량 변경을 만든다).
  • 저널을 삭제·재생성하는 정당한 절차(디스크 정리, 일부 복구 도구)가 있다. 시각과 다른 축의 정황이 함께여야 한다.

교차 검증 ​

교차 카드확인 내용
R3-PF같은 경로의 실행 기록. .pf 삭제는 USN에서 확인
R3-BAM실행 증거 보완(USN은 파일 변경이지 실행이 아니다)
R3-RECLNK·Recent가 삭제된 경로를 여전히 가리키는지
R3-AF의도적 저널 와이프 여부(Application 3079, 1102/104와 병기)

USN 레코드 단독으로는 Confirmed를 내릴 수 없다. 실행 축(PF·BAM)이나 서명·경로 위생 같은 두 번째 축이 받쳐야 한다.

증거 캡처 ​

  1. 시간 필터와 키워드 히트가 보이는 도구 화면(JournalTrace·MFTECmd 등)
  2. fsutil usn queryjournal C: 출력 — 저널 ID·USN 범위·최대 크기
  3. 결과가 없을 경우 두 번째 도구 확인 스크린샷
  4. 볼륨 문자와 파일 시스템 유형 메모(NTFS/ReFS/FAT32)
  5. 저널 삭제 정황 시 Application 로그 3079 필터 화면과 $J·$Max 메타데이터

흔한 실수 ​

  • USN이 없는 볼륨(FAT32)에서 USN 절차를 강행한다.
  • 저널 랩을 "와이프 증거"로 단정한다.
  • 관리자 권한 없이 실행한 도구 결과를 최종 결론으로 쓴다.
  • 저널 삭제 흔적(3079·저널 ID)을 확인하지 않고 "저널이 비어 있다"고만 적는다.
  • DELETE 레코드를 "현재도 존재"로 읽는다. DELETE는 사라졌다는 뜻이다.

Community. 커뮤니티에서는 fsutil usn deletejournal 후 저널 생성 시각이 마지막 부팅보다 늦어진다는 점이 공유되고, Application 로그 3079가 저널 삭제 지표로 반복 인용된다. 3079는 MS 공식 카탈로그의 단일 근거로 단정하기보다 저널 메타데이터·fsutil 실행 기록과 교차 검증하는 것이 권장된다.

FAT32 가상 디스크나 OneDrive Vault에 두면 저널을 통째로 우회할 수 있다는 주장도 보고된다. 실제로는 저널이 없는 볼륨 자체가 신호이고, VHD 파일·마운트 이벤트·동기화 로그가 NTFS와 클라이언트 쪽에 남는다. .pf를 메모장으로 비우는 우회도 보고되는데, 저널에는 DATA_TRUNCATION 변경이 그대로 남는다.

Sources ​

Next ​