디지털 포렌식 분석 보고서 — 단정하지 않고 쓰는 법

분석 과정과 도구 사용법은 삭제해도 증거는 남는다 — 윈도우 아티팩트 3종 교차 검증에 적었다. 이 글은 그 결과를 보고서로 옮기면서 문장 하나하나를 어떻게 골랐는지에 대한 기록이다.

포렌식 보고서는 모의해킹 보고서와 성격이 다르다. 모의해킹은 “내가 이걸 했다”를 쓰는 문서라 사실 관계가 명확한데, 포렌식은 “남이 뭘 했는지”를 남은 흔적으로 추정하는 문서다. 그래서 어디까지 말할 수 있고 어디부터는 말하면 안 되는지를 정하는 게 작업의 절반이었다.

사건 정보

항목	내용
사건명	Backdoor 실행 흔적 분석
분석 대상	침해 의심 Windows 시스템 아티팩트
사건 발생 시점	2021-06-20 (KST, UTC+09:00)
분석 수행일	2026-07-07
분석 환경	Windows 11 (ARM64) 가상머신 / UTM
사용 도구	WinPrefetchView, REGA v1.6.0.0, NTFS Log Tracker v1.4

분석 대상 아티팩트는 Prefetch(.pf), 레지스트리 하이브(SYSTEM / NTUSER 등), $MFT·$LogFile 세 종류다. 주요 시간대는 2021-06-20 19:41:59 ~ 20:41:34.

핵심 증거

구분	도구	확인 내용	시각
실행 흔적	WinPrefetchView	BACKDOOR.EXE-500565FB.pf (Run Counter 1)	19:42:18
재실행 흔적	WinPrefetchView	BACKDOOR.EXE-D0C8C9F8.pf (Run Counter 2)	20:41:07
사용자 활동	REGA (UserAssist)	Backdoor.exe / 바로가기 .lnk, 실행 횟수 3	20:41:17
파일시스템	NTFS Log Tracker	Backdoor.bat 생성·수정·삭제, Prefetch 생성	19:42 / 20:41
매체 이력	REGA (장치관리자)	USB Mass Storage Device 연결 이력	(상시 누적)

보고서를 쓰면서 판단한 것들

1. “실행했다”가 아니라 “실행 정황이 확인된다”

가장 많이 고친 게 서술어였다. 초안에는 공격자가 Backdoor.exe를 실행하였다라고 썼는데, 내가 확인한 건 실행 흔적이지 실행 주체가 아니다.

• Prefetch는 무엇이 실행됐는지를 말한다
• UserAssist는 사용자 GUI 조작으로 실행됐는지를 말한다
• 둘 다 누가 실행했는지는 말하지 않는다

계정 Bum의 세션에서 실행된 건 맞지만, 그 계정을 그 시각에 조작한 사람이 계정 주인인지 침입자인지는 이 세 아티팩트로 알 수 없다. 그래서 전부 ~ 정황이 확인된다, ~ 개연성이 높다로 바꾸고, 한계 챕터에 이렇게 못박았다.

본 보고서의 표현은 ‘공격자가 실행하였다’와 같은 단정이 아니라 ‘실행 정황이 확인된다’는 개연성 판단에 기반한다. 행위 주체의 특정을 위해서는 계정 인증 로그, 네트워크 로그 등 추가 증거가 필요하다.

읽는 사람이 그다음에 뭘 더 확보해야 하는지까지 알려주는 게 한계를 적는 이유다.

2. 타임라인에서 뺀 것들

$LogFile을 파싱하면 수천 행이 나온다. 전부 넣으면 아무도 안 읽는다. 그래서 보고서 본문 타임라인에는 Backdoor와 직접 관련된 행만 넣고, 해석까지 붙인 전체 타임라인은 별첨 스프레드시트로 뺐다.

정리하면서 알게 된 건, 같은 시각(19:42:18 / 20:41:07 / 20:41:17)에 서로 다른 도구가 같은 사건을 독립적으로 기록하고 있다는 점이었다. 행을 시간순으로 붙여놓으니 그게 눈에 보였다. 이게 이 사건의 결론을 지탱하는 구조라서, 타임라인 표의 ‘출처(도구)’ 칼럼을 일부러 앞쪽에 뒀다.

3. 삭제 행위가 오히려 증거가 된다는 것

Backdoor.bat은 세 시각에 걸쳐 생성 → 기록 → 삭제가 반복됐다. 파일 자체는 남지 않았다.

그런데 그 삭제 행위 자체가 $LogFile에 기록되고, 실행은 Prefetch와 UserAssist에 남는다. 결론 챕터의 핵심 문장을 여기에 뒀다.

단일 파일 삭제만으로는 침해 흔적이 완전히 제거되지 않으며, 오히려 삭제 행위 자체가 아티팩트에 기록되어 인멸 정황의 근거가 된다.

4. 못 한 것을 적기

• $UsnJrnl은 확보된 데이터가 비어 있어(0KB) 쓰지 못했다
• USB 연결 이력은 확인했지만 정확한 연결 시각은 별도 분석이 필요해, 악성코드 반입 경로로 단정하지 않았다
• 원본 디스크 전체의 무결성 검증(해시 비교)은 이번 분석 범위 밖이었다

USB 항목이 특히 유혹이 컸다. 연결 이력이 있고 바탕화면에서 실행된 파일이 있으니 “USB로 반입되어 실행됐다”고 쓰면 이야기가 깔끔하게 완성된다. 하지만 그 둘을 잇는 증거가 없었다. 이야기가 완성되는 방향으로 쓰고 싶은 유혹이 포렌식 보고서에서 가장 위험한 지점이라는 걸 이때 알았다.

5. 권고사항은 이번 사건에서 도출되게

일반론(백신 설치, 패치 적용)을 나열하는 대신, 이번 분석에서 실제로 근거가 나온 것만 적었다.

• Prefetch·UserAssist·파일시스템 변경 이벤트를 EDR로 상시 수집 → 이번에 실행을 잡아낸 아티팩트가 그것들이라서
• 일반 사용자 계정이 바탕화면 등에서 임의 실행파일을 구동하지 못하도록 AppLocker 등 적용 → 실행 경로가 사용자 바탕화면이었으므로
• USB 등 외부 저장매체 연결 정책 수립 → 연결 이력이 확인됐으므로 (반입 경로로 단정하지는 않되)
• 침해 의심 시 원본 디스크 이미지 확보 후 사본으로 분석 → 이번엔 추출본만 받아 무결성 검증을 못 했으므로

문서 구조

사건 개요 → 분석 개요 → 분석 방법 및 절차 → 사건 타임라인 → 핵심 증거 요약 → 종합 분석 → 결론 → 분석의 한계 및 유의사항 → 대응 권고사항 순서다.

한계 챕터를 결론 뒤에 둘지 앞에 둘지 고민했는데, 뒤에 뒀다. 앞에 두면 결론을 읽기 전에 김이 빠지고, 뒤에 두면 결론의 적용 범위를 정하는 역할을 한다. 다만 한계가 결론을 뒤집을 만큼 크다면 앞으로 올려야 한다고 생각한다. 이번엔 3종 아티팩트가 서로를 받쳐주고 있어서 그렇지 않았다.