“디스크는 조용한데, 메모리는 시끄럽다”
보안 사고를 겪어본 조직들이 공통으로 하는 말이 있어요. “로그도 없고, 디스크에도 별 흔적이 없더라”는 이야기죠. 공격자는 점점 더 ‘흔적을 남기지 않는 방식’을 선호하고, 그중 대표가 메모리 상에서만 동작하는 악성코드(파일리스, in-memory) 기법입니다. 그래서 포렌식 관점에서 RAM은 사건 현장의 “현재 진행형”을 보여주는 아주 중요한 증거물이 됩니다.
흥미로운 점은, 메모리는 휘발성이지만 그만큼 ‘방금 전까지 무슨 일이 있었는지’가 생생하게 남아 있다는 거예요. 프로세스가 어떤 DLL을 로드했는지, 네트워크 연결이 어디로 열려 있는지, 권한 상승이 어떤 토큰으로 이뤄졌는지, 심지어 암호화 키나 명령어 조각이 남는 경우도 있죠. 이번 글에서는 포렌식의 관점으로 메모리 분석을 어떻게 시작하고, 거기서 침해 징후(IOC/IOA)를 어떻게 끝까지 추적하는지 친근하게 풀어볼게요.
1) 메모리 포렌식이 중요한 이유: 공격 트렌드가 바뀌었다
과거에는 악성코드가 파일 형태로 떨어지고, 레지스트리나 시작 프로그램에 흔적을 남기는 경우가 많았어요. 하지만 최근에는 합법 도구(LOLbins)와 스크립트, 메모리 인젝션을 섞어서 “디스크에 남는 증거를 최소화”하는 방식이 흔해졌습니다. 특히 랜섬웨어 운영 조직이나 APT 캠페인에서 메모리 기반 기술을 적극적으로 활용하죠.
메모리에서만 보이는 대표 징후들
디스크 포렌식만으로는 놓치기 쉬운 단서들이 메모리에는 남습니다. 예를 들어 아래 같은 것들이요.
- 프로세스 인젝션 흔적(정상 프로세스에 쉘코드/악성 DLL 주입)
- 비정상적인 네트워크 세션(의심 IP/도메인으로의 연결, 터널링)
- 권한 토큰 변조 및 임퍼소네이션(가짜/도용된 자격으로 실행)
- PowerShell/스크립트 실행 흔적(명령어, 인코딩된 페이로드 조각)
- 암호화 키/인증 토큰/세션 쿠키 등 민감정보 잔존
간단한 수치로 보는 현실
정확한 비율은 기관과 산업별로 다르지만, 여러 위협 인텔리전스 보고서에서 “정상 도구를 악용하는 공격(예: PowerShell, WMI, rundll32 등)이 지속적으로 증가”한다고 반복해서 언급돼요. Mandiant, Microsoft, CrowdStrike 같은 주요 보안 리포트들이 공통적으로 강조하는 포인트도 비슷합니다. 공격자는 ‘새 악성 파일’보다 ‘기존에 있는 것처럼 보이게 만들기’를 좋아하고, 그 결과 메모리 분석의 중요도는 계속 올라갑니다.
2) 시작은 증거 보존부터: 메모리 수집 절차와 실무 팁
메모리 포렌식에서 가장 자주 하는 실수는 “일단 재부팅해보자”예요. 재부팅은 휘발성 증거를 날려버릴 수 있어요. 따라서 의심 상황에서의 1순위는 메모리 덤프 확보와 무결성 관리입니다. 단, 현장 환경(서버/업무PC/OT 등)에 따라 서비스 중단 리스크도 고려해야 하니, 조직의 IR(침해사고 대응) 정책과 함께 움직이는 게 좋아요.
수집 시 체크리스트(현장형)
- 가능하면 즉시 메모리 덤프 수집(재부팅/로그오프 전에)
- 덤프 파일 해시(SHA-256 등) 산출 및 기록(증거 무결성)
- 수집 시각, 시스템 시간 오차, 타임존 기록(타임라인 정확도)
- 동시에 네트워크 연결 정보, 실행 중 프로세스 목록도 별도 수집(교차검증)
- 수집 도구 자체가 남기는 흔적도 최소화(표준 절차 준수)
수집 도구와 방식(개념 중심)
Windows 환경에서는 메모리 덤프 수집을 돕는 여러 도구들이 있고, Linux도 /proc 기반 정보와 함께 메모리 캡처 체계를 구성할 수 있어요. 어떤 도구를 쓰든 핵심은 “일관된 절차”와 “재현 가능한 기록”입니다. 법적 분쟁 가능성이 있는 사건이라면, 체인 오브 커스터디(누가 언제 어떻게 증거를 취급했는지) 문서화까지 포함하는 게 안전합니다.
3) 분석의 지도 만들기: Volatility 계열 프레임워크로 큰 그림 잡기
메모리 분석을 처음 접하면 어디부터 봐야 할지 막막해요. 이럴 때는 프레임워크(예: Volatility 2/3 같은 메모리 분석 도구)로 ‘큰 그림’을 먼저 그리는 게 효율적입니다. 핵심은 “정상 베이스라인 대비 무엇이 이상한가”를 단계적으로 좁혀가는 거예요.
초반에 꼭 보는 기본 축 4가지
- 프로세스 트리: 누가 누구를 실행했는가(부모-자식 관계)
- 네트워크: 어떤 프로세스가 어디에 연결했는가
- 모듈/DLL: 프로세스에 어떤 라이브러리가 로드됐는가
- 지속성/권한: 권한 상승, 토큰, 서비스/스케줄러 흔적의 단서
“정상처럼 보이게” 위장하는 패턴
공격자는 svchost.exe, rundll32.exe, explorer.exe 같은 정상 프로세스 이름을 악용하거나, 정상 프로세스에 코드를 주입해 겉보기에는 자연스럽게 보이게 만들어요. 그래서 단순히 “이름이 수상하다”보다 아래의 관점이 더 중요합니다.
- 실행 경로가 정상 시스템 경로가 맞는지(예: System32 vs 사용자 임시 폴더)
- 부모 프로세스가 자연스러운지(워드가 갑자기 cmd를 부르는 등)
- 서명/모듈 로딩 패턴이 정상적인지(낯선 DLL, 비정상 메모리 영역)
- 네트워크 목적지가 업무상 타당한지(새벽 시간대 해외 IP 연결 등)
4) 침해 징후(IOC/IOA) 추적: 메모리에서 단서를 “연결”하는 법
메모리 포렌식의 매력은 점 단서를 선으로 연결할 수 있다는 거예요. 예를 들어 “수상한 프로세스 하나”를 발견했을 때, 그 프로세스가 어떤 명령 줄로 실행됐는지, 어떤 DLL을 로드했는지, 어떤 소켓을 열었는지, 어떤 권한 토큰을 썼는지까지 엮어서 이야기로 만들 수 있습니다. 이게 바로 침해 징후를 추적하는 실전 흐름이에요.
사례 1: 문서 매크로 → PowerShell → 인메모리 페이로드
현장에서 흔히 보는 흐름 중 하나예요. 사용자가 문서를 열고 매크로를 허용한 뒤, PowerShell이 숨겨진 창으로 실행되고, 인코딩된 명령이 메모리에서 디코딩되어 페이로드가 로딩되는 형태죠. 디스크에는 “다운로드된 exe”가 없는데도 감염이 진행됩니다.
- 단서 A: winword.exe(또는 excel.exe)가 powershell.exe를 자식으로 실행
- 단서 B: PowerShell 명령 줄에 -enc, FromBase64String 같은 패턴
- 단서 C: 이후 정상 프로세스(예: explorer.exe)에 비정상 메모리 영역 생성/주입
- 단서 D: 외부 C2로의 주기적 비콘(특정 간격 통신)
이때 포렌식 관점에서는 A~D를 한 줄 타임라인으로 꿰어 “사용자 행위 기반 감염 경로”로 정리할 수 있어요. 그리고 이 흐름 자체가 재발 방지 정책(매크로 정책, PowerShell 로깅, AMSI, EDR 규칙)에 바로 연결됩니다.
사례 2: LSASS 접근 흔적과 자격 증명 탈취 의심
자격 증명 탈취는 여전히 사고의 핵심 축입니다. 공격자가 lsass.exe에 접근하거나 덤프를 시도하면, 이후 측면 이동(내부 확산)으로 이어질 가능성이 커요. 메모리 분석에서는 의심 프로세스가 어떤 권한으로 LSASS에 접근했는지, 관련 핸들이 열렸는지, 비정상 모듈이 로드됐는지 등을 단서로 볼 수 있습니다.
- lsass.exe에 대한 비정상 접근 시도(업무상 필요 없는 프로세스)
- 디버그 권한(SeDebugPrivilege) 관련 이상 징후
- 보안 제품 우회 흔적(보호 프로세스 회피, 의심 드라이버)
이 영역은 민감하고 위험도가 높아서, 실제 대응에서는 법적/정책적 범위 내에서 증거 확보와 추가 피해 확산 차단을 병행하는 게 중요해요.
IOC보다 IOA를 함께 보는 이유
IOC(해시, IP, 도메인)는 빠르게 바뀔 수 있어요. 반면 IOA(행위 패턴)는 상대적으로 오래 갑니다. 예를 들어 “오피스 → PowerShell 인코딩 실행 → 정상 프로세스 인젝션” 같은 체인은 공격자가 쉽게 바꾸기 어렵죠. 그래서 메모리 포렌식 결과를 정리할 때는 IOC와 IOA를 함께 적어두면 재탐지/재발 방지에 훨씬 도움이 됩니다.
5) 타임라인과 교차검증: 메모리 단서를 로그/디스크와 맞춰보기
메모리에서 얻은 증거는 강력하지만, 단독으로 끝내면 아쉬울 때가 많아요. 최고의 결과는 “메모리-디스크-로그”를 교차검증해서 하나의 사건 타임라인으로 엮는 것입니다. 특히 경영진 보고나 외부 감사, 법적 이슈까지 고려하면 ‘설명 가능한 스토리’가 필요하거든요.
교차검증 포인트
- 프로세스 생성 시간과 Windows 이벤트 로그(프로세스 감사, PowerShell 로그) 비교
- 네트워크 연결 정보와 방화벽/프록시/DNS 로그 비교
- 의심 실행 파일 경로가 있다면 디스크에서 실제 존재 여부 및 타임스탬프 확인
- 계정 사용 흔적(로그온 이벤트, 원격 접속 기록)과 권한 상승 징후 매칭
연구/전문가 관점: “단일 증거에 의존하지 말라”
디지털 포렌식 분야에서 반복적으로 강조되는 원칙 중 하나는 단일 아티팩트만으로 결론을 내리지 말라는 거예요. 메모리에서 의심 정황이 나왔더라도, 로그나 다른 증거로 보강하면 오탐을 줄이고 결론의 신뢰도를 높일 수 있습니다. 보안 사고 분석이 ‘추리’가 아니라 ‘증명’에 가까워지려면, 이런 교차검증 습관이 정말 큰 차이를 만들어요.
6) 실무에서 바로 쓰는 정리법: 보고서, 재탐지, 재발 방지까지
분석을 잘해도 정리가 안 되면 팀 내 공유가 어렵고, 대응 속도도 느려져요. 그래서 마지막은 “결과물을 어떻게 남길 것인가”가 중요합니다. 포렌식 결과는 보통 두 갈래로 쓰입니다. 하나는 사고 보고/원인 분석, 다른 하나는 재탐지 룰과 보안 강화 정책이에요.
보고서에 꼭 들어가면 좋은 항목
- 사고 개요: 발견 경위, 영향 범위, 의심 기간
- 핵심 증거: 의심 프로세스/네트워크/권한 관련 스냅샷
- 침해 경로 가설과 근거: A→B→C 형태의 체인
- 확산 여부 판단: 추가 호스트/계정/세그먼트 조사 결과
- 조치 사항: 격리, 차단, 계정 초기화, 패치 등
- 재발 방지: 로깅 강화, 정책 변경, 탐지 룰(IOC/IOA) 제안
재탐지를 위한 “행동 기반” 체크 아이디어
메모리에서 확인한 공격 흐름을 바탕으로, 환경에 맞는 탐지 포인트를 뽑아두면 다음 대응이 훨씬 빨라집니다.
- 오피스 프로세스가 스크립트 엔진/쉘을 실행하는 행위 탐지
- 비정상 경로에서 실행되는 시스템 유사 프로세스 탐지
- 정상 프로세스의 비정상 네트워크 통신(새 목적지, 주기적 비콘) 탐지
- 권한 상승/토큰 이상 사용, 디버그 권한 사용 탐지
초보자가 흔히 겪는 시행착오와 해결책
- 덤프만 떠놓고 분석을 미루다 타임라인을 놓침 → 수집 직후 1차 트리아지(핵심 아티팩트)부터
- 수상한 것만 찾다가 정상 기준을 모름 → “정상 서버/PC 메모리 베이스라인” 샘플 확보
- 결론을 너무 빨리 냄 → 최소 2개 이상의 독립 증거로 교차확인
- 기술 분석으로 끝남 → 차단/탐지/정책으로 연결해 ‘재발 방지’까지 마무리
업무용 대화도 안심, 정확한 카카오톡 복구로 데이터 지키기.
메모리는 휘발되지만, 단서는 휘발되지 않게 만들 수 있다
메모리 분석은 한 번 익숙해지면 “디스크에 흔적이 없는데도 왜 감염인지”를 설명해주는 강력한 도구가 됩니다. 핵심은 세 가지예요. 첫째, 빠르고 정확한 메모리 수집으로 증거를 지키기. 둘째, 프로세스/네트워크/권한 축으로 큰 그림을 만든 뒤 의심 지점을 좁히기. 셋째, 메모리에서 찾은 단서를 로그와 디스크로 교차검증해 신뢰도 높은 타임라인으로 완성하기.
그리고 마지막으로, 포렌식은 “사고를 끝내는 기술”이 아니라 “다음 사고를 더 빨리 끝내게 해주는 습관”에 가깝습니다. 오늘 정리한 흐름대로 한 번만이라도 메모리 덤프를 놓고 직접 단서를 연결해보면, 침해 징후를 바라보는 시야가 확 달라질 거예요.
