“기록은 거짓말을 덜 한다”는 말이 괜히 나온 게 아니에요
보안 사고가 터지면 다들 비슷한 질문부터 던져요. “누가, 언제, 어디서, 무엇을, 어떻게 했지?” 그런데 사람의 기억은 흐릿하고, 화면은 이미 닫혔고, 파일은 지워졌을 수도 있죠. 이때 마지막까지 남아 사건의 윤곽을 그려주는 게 바로 로그예요. 로그는 시스템이 남긴 ‘행동의 흔적’이라서, 제대로 모으고 읽기만 해도 사건 단서를 굉장히 빠르게 찾을 수 있어요.
오늘은 포렌식 관점에서 로그를 어떻게 접근해야 빠르게 “의미 있는 단서”를 건질 수 있는지, 현장에서 자주 쓰는 사고 흐름과 실용적인 방법들을 친근하게 풀어볼게요. (참고로 이 글은 교육 목적의 일반적인 방법론을 다루며, 실제 사건 대응에서는 조직 정책과 법적 절차를 반드시 따르는 게 중요해요.)
1) 포렌식에서 로그가 ‘단서의 지도’가 되는 이유
포렌식은 한마디로 “무슨 일이 있었는지 증거를 기반으로 재구성”하는 작업이에요. 그중 로그는 시간 흐름을 따라 사건을 연결해주는 타임라인 재료로 가장 많이 쓰여요. 특히 랜섬웨어, 계정 탈취, 내부자 유출, 웹 침해 같은 사건은 로그를 잘 엮으면 “침투 경로 → 권한 상승 → 수평 이동 → 데이터 접근/유출” 같은 흐름이 꽤 선명하게 드러납니다.
로그가 강한 이유: 흔적이 ‘여러 곳’에 남는다
공격자는 흔히 특정 로그를 지우거나 변조하려고 해요. 하지만 현대 인프라는 로그가 한 군데만 남지 않죠. 서버, 방화벽, EDR, 클라우드 감사 로그, 프록시, DNS, 인증 시스템 등 여러 레이어에 중복된 흔적이 남아요. 한 곳이 깨져도 다른 곳이 보완해주니, 포렌식에서는 이 ‘중복성’이 엄청난 힘이 됩니다.
숫자로 보는 로그의 가치(현장감 있는 맥락)
여러 보안 보고서에서 공통적으로 나오는 메시지는 “탐지와 대응이 늦어질수록 피해가 커진다”예요. 예를 들어 Mandiant의 연례 보고서에서는 침해 사실을 알아차리기까지 걸리는 시간이 꾸준히 줄어드는 추세라고 설명하지만, 여전히 조직별 편차가 크다고 강조해요. 결국 빨리 찾는 팀의 공통점은 ‘로그 기반 가시성’이 탄탄하다는 거죠.
- 로그가 풍부할수록 “추정”이 아니라 “증거”로 말할 수 있어요.
- 시간대(타임존)와 동기화(NTP)만 맞아도 타임라인 품질이 확 달라져요.
- 단일 증거보다 다중 증거(서로 다른 로그)의 교차검증이 훨씬 강해요.
2) 어떤 로그부터 봐야 빨리 잡힐까? 우선순위 정하는 법
사건이 나면 로그는 산처럼 쌓여 있어요. 처음부터 끝까지 다 읽으려 하면 시간만 날립니다. 포렌식에서 “빠르게 단서 찾기”의 핵심은 우선순위예요. 보통은 “계정/인증 → 네트워크 → 엔드포인트 → 애플리케이션 → 데이터” 순으로 넓혀가면 효율적입니다.
가장 먼저 확인할 로그 Top 5
- 인증/계정 로그: AD/LDAP, SSO, VPN, 클라우드 IAM 로그인 이력(성공/실패, MFA 우회 징후)
- 엔드포인트 이벤트: Windows 이벤트(예: 4624/4625, 4688), Sysmon, EDR 탐지/격리 기록
- 네트워크 경계: 방화벽, WAF, 프록시, IDS/IPS, 로드밸런서 접근 로그
- DNS/메일: DNS 쿼리, 메일 게이트웨이(피싱/악성 첨부) 흔적
- 클라우드 감사 로그: CloudTrail/Azure Activity/GCP Audit 등 리소스 변경과 API 호출 흔적
“무엇이 이상한가”를 빨리 찾는 질문 템플릿
로그를 볼 때는 감으로 보지 말고, 질문으로 쪼개면 속도가 붙어요.
- 평소와 다른 시간대에 로그인했나?
- 평소와 다른 지역/ASN/디바이스에서 접근했나?
- 실패 후 성공(브루트포스/크리덴셜 스터핑) 패턴이 있나?
- 권한이 바뀌었나? (관리자 그룹 추가, API 키 생성, MFA 해제)
- 단기간에 많은 데이터 접근/다운로드가 있었나?
3) 로그 포렌식의 기본기: 시간, 정규화, 그리고 교차검증
단서를 빨리 찾는 팀은 대개 기본기를 철저히 챙겨요. 특히 타임라인을 제대로 만들면 사건이 “영화처럼” 이어져 보이기 시작합니다.
시간이 어긋나면 결론도 어긋난다
서버마다 타임존이 다르고, 클라우드는 UTC, 방화벽은 로컬 타임… 이런 식이면 같은 사건이 서로 다른 시간에 일어난 것처럼 보일 수 있어요. 그래서 포렌식에서는 로그를 모으자마자 다음을 확인합니다.
- 각 장비/서비스의 타임존(UTC인지, KST인지)
- NTP 동기화 여부(드리프트가 있는지)
- 서머타임(DST) 적용 여부
정규화: 서로 다른 형식을 ‘같은 언어’로 바꾸기
로그는 포맷이 제각각이라, 필드 이름도 다르고 날짜 형식도 달라요. 그래서 SIEM/로그 플랫폼에서는 정규화가 필수예요. 예를 들어 “src_ip”, “client_ip”, “remoteAddress”가 사실상 같은 의미일 수 있죠. 이를 하나의 필드로 통일해야 검색이 빨라집니다.
교차검증: 한 줄의 로그를 믿지 말고, 두 줄로 확신하기
예를 들어 “VPN 로그인 성공” 로그가 있으면, 곧바로 내부망에서 어떤 시스템에 접근했는지(방화벽/서버 접속 로그), 그 직후 어떤 프로세스가 실행됐는지(엔드포인트 이벤트)로 이어져야 그림이 완성돼요.
- 인증 로그 ↔ 엔드포인트 프로세스 실행 로그
- 프록시 접속 로그 ↔ DNS 쿼리 ↔ EDR 네트워크 이벤트
- 클라우드 API 호출 ↔ 리소스 설정 변경 ↔ 접근 권한 변동
4) 사건 단서 “빠르게” 찾는 실전 탐색 전략 6가지
여기부터는 바로 써먹을 수 있는 방법들이에요. 포렌식은 정답이 하나가 아니라서, 상황에 맞게 조합해서 쓰면 됩니다.
전략 1: “마지막 정상 시점”을 기준으로 앞뒤를 자르기
장기간 로그를 다 보면 끝이 없어요. 그래서 마지막으로 정상 동작이 확인된 시점을 잡고, 그 이후 구간을 집중 분석해요. 예를 들어 “어제 18:00까지는 정상, 19:30에 이상 발생”이면 18:00~19:30 사이가 황금 구간이죠.
전략 2: 실패 로그를 보물처럼 다루기
공격은 대개 한 번에 성공하지 않아요. 실패(로그인 실패, 권한 거부, 404/500 급증)가 ‘시도’의 흔적이 됩니다. 실패가 쌓이다가 성공으로 바뀌는 순간이 종종 결정적 단서예요.
전략 3: 희소 이벤트(rare event)부터 잡기
평소에 잘 일어나지 않는 이벤트는 그 자체로 단서예요. 예를 들어 “새 관리자 계정 생성”, “MFA 비활성화”, “감사 로그 비활성화”, “새 API 키 생성”, “비정상 국가에서의 콘솔 로그인” 같은 것들이요.
전략 4: 피벗(pivot) 포인트를 정해 연쇄 추적하기
하나의 단서를 잡으면 그걸 중심으로 옆으로 계속 확장합니다. 대표적인 피벗 키는 아래예요.
- 사용자 계정(UPN, 이메일)
- IP(외부 IP, 내부 IP 모두)
- 호스트명/자산 ID
- 프로세스 해시/파일명
- 세션 ID/Request ID(애플리케이션/클라우드에서 특히 유용)
전략 5: “정상 베이스라인”과 비교하기
빠른 탐색의 숨은 치트키는 베이스라인이에요. 예를 들어 평소 특정 서버는 새벽에 백업 트래픽이 많다거나, 특정 계정은 주 1회만 로그인한다거나 하는 패턴이 있죠. 평소 패턴에서 벗어나는 지점을 찾으면 의심 구간이 좁혀집니다.
전략 6: 공격 전술(TTP) 관점으로 묶어서 보기
MITRE ATT&CK 같은 프레임워크를 참고하면 “이 공격이면 다음에 뭘 할 가능성이 큰지”가 보여요. 예를 들어 계정 탈취 후에는 권한 상승, 토큰 탈취, 수평 이동(원격 서비스 접속), 데이터 수집/압축, 외부 전송 같은 흐름이 자주 이어집니다. 로그를 TTP 묶음으로 보면 놓치는 게 줄어요.
5) 짧은 사례로 보는 로그 단서 추적: ‘의심 로그인’에서 ‘유출 경로’까지
가상의 사례로 한 번 따라가 볼게요. 어느 날 보안팀이 “특정 직원 계정으로 새벽에 로그인 성공” 알림을 받았다고 해요.
1단계: 인증 로그에서 이상 징후 확인
- 새벽 03:12 로그인 성공
- 직전 03:10~03:12 사이 로그인 실패 30회
- 접속 IP가 평소 직원의 지역과 다름
여기서 의심은 “크리덴셜 스터핑 또는 비밀번호 유출” 쪽으로 기울죠.
2단계: VPN/프록시/방화벽으로 내부 활동 확인
- 로그인 직후 VPN 연결 생성
- 내부 파일 서버로 SMB/HTTPS 접근 급증
- 평소 접근하지 않던 프로젝트 폴더 열람
3단계: 엔드포인트/서버 이벤트로 행위 구체화
- 서버에서 압축 도구 실행 흔적(프로세스 실행 로그)
- 대용량 파일 생성/수정 시간대가 로그인 직후와 일치
- 이후 외부로 나가는 트래픽(특정 도메인/클라우드 스토리지) 증가
4단계: DNS/클라우드 감사 로그로 ‘유출 경로’ 확정
DNS 로그에서 특정 파일 공유 서비스 도메인 질의가 반복되고, 프록시 로그에서 대용량 업로드가 확인돼요. 클라우드 환경이라면 “어떤 토큰/키로, 어떤 API를 호출했는지”까지 연결되기도 합니다.
이 과정의 핵심은 “하나의 로그로 결론 내리지 않고”, 로그인(인증) → 연결(VPN) → 접근(서버/파일) → 전송(프록시/DNS)으로 증거 사슬을 만든다는 점이에요. 이게 바로 포렌식에서 말하는 ‘재구성’이고, 단서를 빠르게 찾는 정석 루트이기도 하죠.
6) 로그 기반 포렌식을 더 강하게 만드는 운영 팁(미리 준비하면 속도가 달라져요)
사건이 터졌을 때 잘하는 것만큼, 터지기 전에 준비하는 것도 정말 중요해요. 아래는 실무에서 체감 효과가 큰 것들이에요.
로그 수집/보관 정책을 현실적으로 설계하기
- 중요 시스템(인증, 핵심 DB, 파일 서버, 클라우드 IAM)은 더 오래 보관
- 보관 기간은 규제/내부 정책/저장비용 균형으로 결정
- 원본 무결성(변조 방지)을 위해 WORM 스토리지나 접근 통제 적용
“검색 가능한 상태”가 되게 만들기
- 필드 정규화(사용자/호스트/IP/이벤트명 통일)
- 자산 인벤토리와 로그를 매핑(호스트명이 바뀌어도 추적 가능)
- 중요 이벤트에 태그/룰을 만들어 알림과 헌팅을 연결
전문가들이 자주 강조하는 포인트
디지털 포렌식과 사고대응 분야에서 반복적으로 강조되는 건 “가시성(Visibility)과 일관성(Consistency)”이에요. 어떤 연구나 보고서든, 결국 데이터가 없으면 분석이 멈추고, 데이터가 뒤죽박죽이면 시간이 늘어난다는 결론으로 수렴하거든요. 로그는 수집하는 순간보다, 사건이 났을 때 꺼내 쓰기 쉬운 형태로 준비돼 있을 때 가치가 폭발합니다.
중요한 자료가 사라졌다면, 빠르고 안전한 카카오톡 복구가 답입니다.
단서는 늘 로그에 있고, 속도는 습관에서 나온다
포렌식에서 로그는 사건을 복원하는 가장 현실적인 출발점이에요. 빠르게 단서를 찾으려면 (1) 우선순위를 정해 중요한 로그부터 보고, (2) 시간/정규화/교차검증으로 타임라인을 탄탄히 만들고, (3) 피벗 포인트와 희소 이벤트 중심으로 탐색 범위를 좁히는 게 핵심입니다. 여기에 평소 베이스라인과 보관/수집 체계를 잘 갖춰두면, 같은 사건도 훨씬 짧은 시간 안에 윤곽이 잡혀요.
원하시면 “윈도우 이벤트 ID 기준으로 꼭 모아야 할 로그 목록”, “클라우드(IAM/CloudTrail)에서 단서 찾는 체크리스트”, “SIEM 쿼리 작성 요령”처럼 더 실무형으로도 확장해서 정리해드릴게요.