‘증거’처럼 보이지만, 그대로 믿으면 위험한 데이터
포렌식 업무를 하다 보면 “로그에 남아 있으니 사실이다”, “해시가 같으니 동일 파일이다”, “타임라인이 이렇게 나오니 사용자가 그때 뭘 했다” 같은 말을 정말 자주 듣게 돼요. 그런데 실무에서는 이 말들이 절반만 맞거나, 아예 틀릴 때도 많습니다. 왜냐하면 디지털 흔적은 사람이 남긴 ‘기록’이 아니라, 운영체제·앱·클라우드·보안 솔루션이 제각각의 규칙으로 만들어낸 ‘결과물’이기 때문이에요.
특히 사건 대응(DFIR)이나 내부감사, 소송 지원(eDiscovery) 현장에서는 작은 해석 실수 하나가 결론을 뒤집어 버리기도 합니다. 실제로 ENISA(유럽연합 사이버보안청)나 NIST 계열 가이드에서도 “단일 아티팩트에 의존하지 말고 상호 검증(corroboration)을 하라”는 원칙을 반복해서 강조하죠. 이번 글에서는 현장에서 많이 헷갈리는 해석 포인트들을 ‘왜 헷갈리는지’와 ‘어떻게 확인하면 좋은지’ 관점으로 풀어볼게요.
1) 타임스탬프 3종 세트(MAC Time)를 ‘행동’으로 착각하는 문제
가장 흔한 함정이 파일의 M(Modified), A(Accessed), C(Created/Changed) 시간을 사용자 행동과 1:1로 매칭하는 거예요. 예를 들어 “Created가 02:13이니 사용자가 그때 파일을 만들었다”라고 단정해버리는 식이죠. 하지만 이 값들은 파일 시스템과 OS가 정의한 이벤트에 따라 자동 갱신되며, 복사/다운로드/압축해제/동기화 같은 과정에서도 얼마든지 바뀝니다.
왜 헷갈릴까?
윈도우 NTFS의 경우 ‘Created time’이 “해당 볼륨에 생긴 시점”을 의미하는 경우가 많아요. 외부에서 들어온 파일을 복사하면 원본 생성 시간이 아니라 복사된 시점이 Created로 찍히기도 하고, 도구나 설정에 따라 반대 상황도 발생합니다. 맥OS(APFS)나 리눅스(ext4)에서도 시간 필드 정의가 달라서, 같은 행위를 해도 서로 다른 형태의 흔적이 남죠.
실무 팁: 타임라인은 ‘교차 검증’이 기본
- 파일 시간만 보지 말고, 관련 로그(이벤트 로그, 앱 로그, 브라우저 기록)와 함께 묶어 확인
- 다운로드라면 브라우저 다운로드 DB/기록, 메신저라면 첨부파일 캐시/DB, 클라우드라면 동기화 로그를 같이 확인
- 시간대(Time zone), DST(서머타임), 시스템 시간 조작 가능성까지 체크
2) “로그에 있으니 사실” vs 로그의 공백과 회전(rotate), 수집 누락
로그는 굉장히 강력한 증거가 될 수 있지만, 동시에 “없다고 해서 안 한 게 아니다”라는 대표적인 영역이기도 해요. 실무에서는 로그가 아예 꺼져 있거나, 보관 기간이 짧거나, 용량 제한으로 인해 자동 삭제되는 경우가 정말 흔합니다.
현장에서 자주 보는 오해
- 특정 시간대 로그가 없으니 그 시간엔 활동이 없었다고 결론
- SIEM에 수집된 로그만 보고 원본 시스템 로그는 확인하지 않음
- EDR이 탐지하지 않았으니 악성행위가 없었다고 판단
전문가들이 강조하는 ‘로그 신뢰도’ 체크리스트
NIST SP 800-61(Incident Handling Guide) 같은 사고 대응 가이드에서 반복적으로 등장하는 포인트가 “가시성(visibility)의 한계”예요. 그래서 아래처럼 로그 자체의 품질을 먼저 평가하는 게 좋아요.
- 해당 로그의 보관 정책(기간/용량/회전 방식)
- 로그 생성 설정(감사 정책, 상세 수준)
- 수집 경로(에이전트/포워더/중계 서버) 중 누락 지점 여부
- 시간 동기화(NTP) 상태
3) 해시가 같으면 ‘완전 동일’, 해시가 다르면 ‘완전 다른’이라는 단정
포렌식에서 해시는 정말 중요한 도구죠. 동일성 확인, 무결성 검증, 증거 보존에서 거의 기본값이에요. 하지만 해시를 해석할 때도 함정이 있습니다. 해시가 같다는 건 “해시 입력이 동일했다”는 뜻이지, 우리가 기대하는 ‘의미’까지 자동으로 보장해주진 않아요.
해시 해석에서 생기는 대표 혼동
- 파일이 동일하니, 사용자가 동일 파일을 ‘같은 방식으로’ 사용했다고 해석
- 해시가 다르니 완전히 다른 콘텐츠라고 단정(메타데이터/컨테이너 구조 차이로 달라질 수 있음)
- 아카이브(zip), 문서(docx), 이미지(jpg)처럼 내부 구조가 달라질 수 있는 파일의 특성을 무시
실무 팁: “콘텐츠 동일성”과 “파일 동일성”을 나눠 보기
예를 들어 문서 파일은 열었다가 저장만 해도 내부 구조가 바뀌어 해시가 달라질 수 있어요. 반대로 내용은 같지만 EXIF, 타임스탬프, 압축 방식이 달라 해시가 달라지는 이미지도 흔합니다. 이런 경우엔 아래 방식이 유용해요.
- 가능하면 ‘정규화(normalization)’ 후 비교(예: 텍스트 추출 후 비교)
- 유사도 분석(퍼지 해시, ssdeep 등)로 “비슷한 계열” 탐색
- 문서라면 작성자/수정 이력, PDF라면 객체 스트림 구조까지 함께 확인
4) 삭제 파일은 “없어진 증거”가 아니라 “형태가 바뀐 흔적”
삭제는 곧 소멸이라고 생각하기 쉽지만, 디지털에서 삭제는 대개 “참조를 지운 것”에 가깝습니다. 파일 시스템은 공간을 재사용하기 전까지 흔적을 남겨두기도 하고, 반대로 TRIM/GC(가비지 컬렉션) 같은 기능으로 빠르게 사라지기도 해요. 즉, ‘삭제’라는 행위의 결과는 저장매체 종류와 설정에 따라 천차만별입니다.
SSD vs HDD, 그리고 클라우드의 삭제는 완전히 다르다
- HDD: 미사용 영역에 데이터가 남아 있을 가능성이 상대적으로 높음
- SSD: TRIM이 활성화되어 있으면 일정 시간 후 복구 가능성이 급격히 낮아질 수 있음
- 클라우드/메신저: 로컬에서 지웠어도 서버에 남거나, 반대로 서버 정책상 빠르게 삭제될 수 있음
실무 팁: “삭제 여부”보다 “삭제의 경로”를 복원하자
복구 성공/실패 자체보다, 삭제가 어떻게 일어났는지(휴지통 이동, Shift+Delete, 앱 내부 삭제, 동기화에 의한 반영)를 밝히는 게 사건 해석에 더 도움이 되는 경우가 많아요.
- 윈도우: 휴지통 관련 메타데이터, 바로가기(.lnk), 점프리스트(Jumplist) 등으로 사용 흔적 추적
- 브라우저/앱: 캐시 DB, 로컬 스토리지, SQLite WAL/SHM 같은 잔존 데이터 확인
- 동기화 툴: 동기화 로그와 서버 측 이벤트(가능한 범위 내) 교차 확인
5) 아티팩트가 가리키는 건 ‘사용’이 아니라 ‘시스템 반응’일 수 있다
많이들 헷갈리는 포인트가 “이 아티팩트가 있으니 사용자가 실행했다” 같은 결론이에요. 예를 들어 프리패치(Prefetch), 레지스트리 흔적, 캐시 파일은 실행/열람의 강력한 단서가 되지만, 때로는 시스템 서비스나 자동화 작업, 백그라운드 스캔(백신/인덱서)이 생성했을 수도 있어요.
대표 사례: 실행 흔적의 오해
프리패치가 있다고 해서 항상 ‘사용자가 더블클릭’했다고 말할 수는 없어요. 스케줄러 작업이나 다른 프로세스가 호출했을 수도 있고, 원격 관리 도구가 실행했을 수도 있죠. 반대로 프리패치가 없다고 실행되지 않았다고 단정하는 것도 위험해요(설정 비활성화, OS 버전/정책 차이, 정리 도구에 의한 삭제 등).
실무 팁: “사용자 의도”를 뒷받침하는 증거를 추가로 찾기
- 동일 시각대의 입력 이벤트, 인터랙티브 로그인, RDP 세션 등과 연결
- 프로세스 트리(가능 시), 작업 스케줄러 기록, 서비스 로그로 ‘누가 실행했는지’ 추적
- 문서 열람이라면 최근 문서 목록, 앱 내부 MRU, 파일 경로 흔적을 함께 확인
6) 보고서 문구 하나가 결론을 바꾼다: 확정/추정/가능의 경계
실무에서 가장 큰 혼란은 기술이 아니라 ‘표현’에서 생기기도 해요. 같은 데이터를 두고도 “확인됨”, “추정됨”, “가능성 있음”을 어떻게 쓰느냐에 따라 의사결정이 달라지죠. 특히 내부감사나 법적 분쟁이 걸린 포렌식 결과라면, 문구의 강도는 사실상 리스크 관리입니다.
자주 발생하는 커뮤니케이션 문제
- 상대방(비기술 이해관계자)이 “정황”을 “증명”으로 받아들임
- 분석자가 자신도 모르게 단정형 표현을 사용
- 반대로 지나치게 완곡하게 써서 핵심이 전달되지 않음
실무 팁: 결론을 ‘증거-해석-한계’ 3단으로 쓰기
보고서나 구두 브리핑에서 아래 구조를 습관처럼 가져가면 오해가 줄어요.
- 증거: 무엇을 관찰했는가(아티팩트/로그/해시/경로/시간)
- 해석: 그 증거가 의미하는 바(가장 그럴듯한 시나리오)
- 한계: 다른 가능성/누락 가능성/추가 확인 필요사항
데이터는 사라져도 방법은 있습니다. 믿을 수 있는 카카오톡 복구 서비스 ✨
헷갈림을 줄이는 가장 현실적인 방법
포렌식 결과 해석에서 반복되는 혼란은 결국 “단일 지표에 과도하게 의존”하거나 “아티팩트를 사람의 행동으로 직번역”할 때 생기는 경우가 많아요. 타임스탬프는 시스템과 파일 시스템의 규칙을 타고 변하고, 로그는 남을 수도/안 남을 수도 있으며, 해시는 동일성과 유사성의 층위가 다르고, 삭제는 매체와 정책에 따라 결과가 갈립니다. 마지막으로 보고서 표현은 기술만큼이나 중요한 ‘결론의 안전장치’가 되고요.
실무에서 가장 효과적인 접근은 간단합니다. 하나의 증거로 결론을 내리지 말고, 서로 성격이 다른 증거(로그·아티팩트·네트워크·사용자 세션·클라우드 기록)를 묶어서 같은 이야기를 하는지 확인하는 것. 그리고 결론을 쓸 때는 “무엇을 봤고, 그래서 무엇이라 해석하지만, 어떤 한계가 있다”를 명확히 나누는 것. 이 두 가지만 지켜도 헷갈리는 포인트의 절반은 깔끔하게 정리될 거예요.