파일 무해화 원리, 제거보다 재생성 —
CDR이 남기는 것과 버리는 것

파일 무해화 원리를 한 문장으로 줄이면 "의심스러운 것을 찾아 지운다"가 아니라 "안전하다고 정의된 요소만으로 파일을 다시 쓴다"에 가깝다. 이 차이 때문에 무해화는 공격을 식별하지 못해도 효과를 낼 수 있고, 동시에 업무에 필요한 기능 일부를 잃는 대가를 치른다. 이 글은 문서 포맷 안에서 액티브 콘텐츠가 어디에 놓이는지, 왜 원본을 고치지 않고 새로 만드는지, 무엇이 남고 무엇이 사라지는지를 공개 규격과 실제 취약점 사례를 근거로 정리하고, 탐지와 무해화를 어떻게 함께 배치할지까지 다룬다.

보안 제품을 비교할 때 흔히 "무엇이 더 많이 잡는가"를 묻는다. 그런데 탐지와 무해화는 애초에 같은 질문에 답하는 기술이 아니다. 탐지는 "이 파일은 악성인가"에 답한다. 무해화는 "이 파일이 악성이든 아니든, 사용자에게 안전한 형태로 전달할 수 있는가"에 답한다.

탐지 계열 기술은 할 수 있는 일이 많다. 시그니처는 알려진 악성 파일을 빠르고 정확하게 식별한다. 휴리스틱과 머신러닝 기반 분류는 변형된 계열도 상당 부분 잡아낸다. 행위 기반(샌드박스) 방식은 파일이 실제로 무엇을 하는지 관찰해 페이로드, 접속 주소, 생성 파일 같은 침해 지표를 남기며, 이는 사고 대응과 위협 헌팅에 쓰인다. 판정 결과가 있다는 것 자체가 큰 가치다. 어떤 공격이 들어왔는지 알아야 다음 대응을 설계할 수 있기 때문이다.

한계도 분명하다. 판정은 결국 "아직 모르는 것"과 "판정을 피하도록 설계된 것" 앞에서 흔들린다. MITRE ATT&CK는 가상화·샌드박스 환경을 감지해 동작을 바꾸는 기법을 별도 기법(T1497)으로 분류하고 있다^[4]. 시간차 실행, 사용자 상호작용 조건, 특정 지역·언어 환경 확인 같은 조건부 동작은 관찰 기반 판정이 놓칠 여지를 만든다.

무해화는 판정을 내리지 않는다. 대신 파일이 담을 수 있는 능동 요소 중 업무에 필요하지 않다고 정의된 것을 구조적으로 걷어낸다. 공격이 그 요소에 실려 있었다면 공격을 식별하지 못했어도 전달 경로가 끊긴다. 이것이 파일 무해화 원리의 출발점이다. 다만 판정 결과를 남기지 않으므로, "무엇이 들어왔는가"를 알아야 하는 조직에는 탐지가 여전히 필요하다. 이 글의 7장에서 둘을 함께 배치하는 방식을 다룬다.

무해화가 무엇을 걷어내는지 이해하려면 먼저 문서 포맷이 어떻게 생겼는지 봐야 한다. 오늘날 업무 문서는 대부분 단일 데이터 덩어리가 아니라 여러 부분(part)이나 스트림을 묶은 컨테이너다. 그 안에는 본문 텍스트와 서식 같은 순수 데이터와, 열람 프로그램에게 "무언가를 실행하라"거나 "외부에서 무언가를 가져오라"고 지시하는 요소가 함께 들어 있다. 후자를 통칭해 액티브 콘텐츠라고 부른다.

OOXML(DOCX·XLSX·PPTX)은 ZIP 컨테이너 안에 XML 부분과 관계(relationship) 파일을 담는 구조다^[5]. VBA 매크로는 vbaProject.bin이라는 별도 바이너리 부분에 저장되고, [Content_Types].xml에서 application/vnd.ms-office.vbaProject 형식으로 선언된다. 매크로를 담은 워드 문서의 본문 부분은 application/vnd.ms-word.document.macroEnabled.main+xml 형식을 가진다. 매크로가 없는 DOCX라도 관계 파일에 외부 주소를 가리키는 항목을 넣어 원격 템플릿이나 원격 개체를 불러오게 할 수 있다. 원격 템플릿 관계 유형은 http://schemas.openxmlformats.org/officeDocument/2006/relationships/attachedTemplate이며, MITRE ATT&CK는 이를 템플릿 인젝션(T1221)으로 분류한다^[15].

CFB(복합 파일 바이너리) 기반 레거시 Office 포맷(DOC·XLS·PPT)은 파일 내부에 디렉터리와 스트림을 가진 작은 파일 시스템 형태다^[6]. VBA 프로젝트는 별도 스토리지에 압축된 소스와 함께 저장되며 그 구조는 공개 규격으로 문서화되어 있다^[7]. 임베디드 OLE 개체는 다른 프로그램이 처리할 데이터를 문서 안에 실어 나르는 통로다. 2017년 공개된 CVE-2017-11882는 문서에 포함된 수식 개체를 처리하는 수식 편집기 구성 요소의 메모리 손상 취약점이었고, 매크로 없이도 문서 열람만으로 코드 실행이 가능했다^[10].

PDF는 번호 붙은 객체와 상호 참조 테이블로 이루어진다^[8]. 문서를 열 때 동작을 지정하는 /OpenAction, 페이지·필드 이벤트에 동작을 거는 /AA, 스크립트를 담는 /JavaScript와 /JS, 외부 프로그램 실행을 지시하는 /Launch, 파일 첨부를 위한 /EmbeddedFile 등이 액티브 콘텐츠에 해당한다. 같은 객체를 뒤에서 다시 정의하는 증분 업데이트(incremental update)도 규격상 허용된다.

HWP 5.0은 CFB 구조 위에 본문 섹션, 바이너리 데이터(BinData), 스크립트 스토리지 등을 둔다^[9]. BinData에는 이미지와 임베디드 개체가, 스크립트 스토리지에는 문서 매크로용 스크립트가 담길 수 있다. XML 기반인 HWPX는 OOXML과 마찬가지로 압축 컨테이너 안에 XML 부분을 둔다.

무해화를 구현하는 방법은 크게 두 갈래로 나눌 수 있다. 하나는 원본 파일에서 위험하다고 알려진 요소를 찾아 그 부분만 잘라내는 제거(stripping) 방식이다. 다른 하나는 원본에서 허용된 요소만 추출해 새 파일을 처음부터 다시 만드는 재생성(reconstruction) 방식이다. 두 방식은 결과물이 비슷해 보여도 보안 성질이 다르다.

제거 방식은 사실상 거부 목록(denylist)이다. "JavaScript 객체를 지운다", "vbaProject.bin을 지운다"처럼 알려진 위험 요소를 열거한다. 구현이 단순하고 원본과의 차이가 작다는 장점이 있지만, 목록에 없는 요소나 목록이 예상하지 못한 위치에 숨은 요소는 그대로 남는다. 원본의 나머지 바이트는 손대지 않으므로, 열람 프로그램이 이상하게 해석할 수 있는 구조적 모호함도 함께 남는다.

재생성 방식은 허용 목록(allowlist)이다. "본문 텍스트, 서식, 표, 정적 이미지는 가져간다"처럼 안전하다고 정의한 요소만 새 파일로 옮긴다. 목록에 없는 것은 위험 여부를 판단하지 않아도 자동으로 빠진다. 공격자가 새로운 액티브 콘텐츠 위치를 찾아내더라도, 그 위치가 허용 목록 밖이라면 재생성된 파일에는 존재하지 않는다. 파일 무해화 원리가 알려지지 않은 공격에 대해 갖는 효과는 대부분 이 성질에서 나온다.

현실의 CDR 구현은 두 방식을 섞는 경우가 많다. 포맷 전체를 다시 쓰기 어려운 경우 일부 구간은 제거 방식으로 처리하고, 핵심 구조는 재생성하는 식이다. 따라서 제품을 평가할 때는 "CDR을 지원한다"는 표현보다 포맷별로 어떤 방식으로 처리하는지, 결과 파일이 새로 직렬화되는지를 물어야 한다. 9장 점검표에 이 질문을 넣었다.

재생성을 택하는 이유가 허용 목록 하나만은 아니다. 더 근본적인 이유는 파서 불일치(parser differential)다. 같은 파일을 보안 장비의 파서와 사용자 PC의 열람 프로그램이 서로 다르게 해석하면, 보안 장비는 무해하다고 본 파일이 사용자 쪽에서는 다른 내용으로 열릴 수 있다.

이런 불일치가 생기는 지점은 포맷 규격 곳곳에 있다. PDF는 증분 업데이트로 같은 번호의 객체를 여러 번 정의할 수 있고, 상호 참조 테이블이 손상되었을 때 열람 프로그램마다 복구 방식이 다르다^[8]. ZIP 기반 포맷은 파일 끝의 중앙 디렉터리와 각 항목 앞의 로컬 헤더에 정보가 중복 기록되는데, 둘이 어긋나면 어느 쪽을 믿느냐에 따라 다른 파일이 보인다. CFB 기반 포맷은 디렉터리 항목과 실제 섹터 체인이 맞지 않거나 어떤 디렉터리에도 연결되지 않은 섹터가 존재할 수 있다^[6]. 이미지 파일은 종료 표식 뒤에 임의 데이터를 덧붙여도 대부분의 뷰어가 정상적으로 표시한다. 하나의 바이트열이 두 가지 포맷으로 동시에 유효한 폴리글랏(polyglot) 파일도 있다.

제거 방식은 원본 바이트를 대부분 유지하므로 이런 모호함을 그대로 물려준다. 보안 장비가 첫 번째 객체 정의를 보고 깨끗하다고 판단했는데 열람 프로그램은 마지막 정의를 따른다면, 제거 작업은 엉뚱한 곳에 적용된 셈이다.

재생성 방식은 이 문제를 구조적으로 다룬다. CDR 방식은 일반적으로 원본을 파싱해 내부 모델을 만들고, 그 모델에서 허용된 요소만 골라 자체 작성기(writer)로 새 파일을 직렬화한다. 이 과정에서 몇 가지가 함께 일어난다.

• 모호함의 해소: 중복 정의, 어긋난 헤더, 손상된 참조는 파서가 하나의 해석으로 확정하고, 작성기는 그 해석만 규격에 맞는 형태로 기록한다.
• 잔여 데이터의 소멸: 어떤 구조에도 연결되지 않은 섹터, 종료 표식 뒤의 덧붙은 데이터처럼 모델에 들어오지 못한 바이트는 새 파일에 존재하지 않는다.
• 값의 정규화: 길이·개수·오프셋 같은 필드가 작성기가 계산한 값으로 다시 기록된다. 비정상적인 필드 값을 이용해 열람 프로그램의 파싱 코드를 공격하는 기법은 이 단계에서 영향을 받는다.

이 성질은 영국 국가사이버보안센터(NCSC)가 외부 데이터를 안전하게 들여오는 설계 패턴에서 변환(transformation)과 구문 검증을 핵심 단계로 제시하는 것과 같은 맥락이다^[13]. 외부에서 온 데이터를 그대로 통과시키지 않고, 신뢰할 수 있는 표현으로 바꾼 뒤 내부로 들인다는 생각이다.

CDR의 처리 흐름은 일반적으로 파일 스캔(액티브 콘텐츠 분석) → 액티브 콘텐츠 제거 → 파일 재생성의 세 단계로 설명된다. 3장의 허용 목록과 4장의 정규화가 실제로 적용되는 자리가 바로 이 흐름이다. 아래 타임라인은 CDR 방식에서 각 단계가 일반적으로 다루는 작업을 기술 일반론으로 풀어 쓴 것이다. 특정 제품의 내부 처리 순서를 설명하는 것이 아니라, 평가자가 각 단계에서 무엇을 확인해야 하는지를 정리한 것이다.

속도는 이 흐름이 실제 업무 경로에 들어갈 수 있느냐를 결정한다. 시큐레터 CDR의 평균 무해화 소요 시간은 파일당 34ms로 공개되어 있다^[1]. 이는 평균값이며, 개별 파일의 처리 시간은 크기, 페이지 수, 임베디드 개체와 중첩 깊이에 따라 달라진다. 따라서 PoC에서는 평균뿐 아니라 실제 업무 파일 중 큰 파일과 복잡한 파일의 처리 시간 분포를 따로 측정하는 것이 좋다.

포맷 커버리지도 같은 무게로 봐야 한다. 무해화는 파서와 작성기가 존재하는 포맷에만 적용된다. 시큐레터가 지원하는 파일 포맷은 309종 이상이다^[2]. 커버리지가 넓다는 것은 "처리할 수 없어 통째로 차단하거나 그대로 통과시켜야 하는 파일"이 그만큼 줄어든다는 뜻이다. 국내 환경에서는 HWP·HWPX 처리 품질이 특히 중요하다.

허용 목록 방식은 목록 밖의 모든 것을 뺀다. 여기에는 공격에 쓰이는 요소뿐 아니라 정상 업무에 쓰이는 기능도 포함된다. 도입 후 불만은 대부분 이 지점에서 나온다. 문제를 줄이는 방법은 도입 전에 무엇이 사라지는지 목록으로 보고, 각 항목에 대한 운영 대안을 정해 두는 것이다.

디지털 서명은 따로 짚어 둘 필요가 있다. 서명은 원본 바이트에 대해 계산되므로, 재생성으로 바이트가 바뀌면 서명은 검증되지 않는다. 이는 특정 제품의 결함이 아니라 재생성 방식의 본질적 성질이다. 계약서, 전자 세금계산서처럼 서명 검증이 업무 요건인 문서 유형이 있다면, 원본을 격리 보관하고 서명 검증은 별도 절차로 수행하는 설계가 필요하다.

반대로 재생성이 업무에 도움이 되는 경우도 있다. 숨은 메타데이터, 변경 내용 추적 기록, 사용되지 않는 내부 스트림이 정리되면서 의도치 않은 정보 노출이 줄어든다. 손상된 구조가 정규화되어 일부 열람 프로그램에서 열리지 않던 파일이 열리는 경우도 있다.

무해화의 장점을 정확히 쓰려면 적용되지 않는 영역도 같은 정확도로 써야 한다. 아래는 파일 무해화 원리상 재생성으로 해결되지 않거나 효과가 제한되는 영역이다.

이 목록은 무해화의 약점이라기보다 역할 분담의 경계다. 시큐레터는 100% 탐지가 불가능하다는 전제에서 출발해, 탐지와 무해화를 함께 쓰는 구조를 택하고 있다. 탐지가 놓친 것은 CDR 무해화가 막는다. 반대로 실행 파일처럼 무해화라는 개념이 성립하지 않는 대상은 탐지가 맡으며, 그 범위는 아래 MARS 설명에서 다룬다. 피싱 문구나 위조 송금 요청 같은 내용 기반 공격은 주로 이메일로 들어오므로 이메일 구간에서 다룬다. 구축형 메일 서버용 SLE는 스팸·악성·피싱·BEC 등 이메일 공격 전반을 막는다. 위 목록의 나머지 항목, 곧 암호화 파일과 미지원 포맷은 8장에서 다루는 처리 실패 시 기본값 정책으로 대응한다.

시큐레터의 탐지 엔진 MARS는 자동화된 리버스 엔지니어링으로 문서를 어셈블리 수준까지 분해해, 악성 행위가 일어나기 전에 취약점의 근원(Exploit)을 찾아낸다. 행위나 결과를 지켜보는 대신 근본 원인을 분석하기 때문에, 행위 기반(샌드박스) 방식이 놓치는 가상환경 회피·시간차 공격·사용자 행위 조건 같은 우회 기법에 흔들리지 않는다. 탐지 범위는 문서형에 국한되지 않는다. 문서·이미지·압축 파일은 리버스 엔지니어링으로, 실행 파일은 백신·YARA·평판 분석으로 탐지한다. MARS의 탐지 성능은 KISA 인증에서 악성코드 탐지율 100%로 평가받았다(2020)^[2]. 이 수치는 인증 시험 조건에서의 결과이며, 실제 환경의 모든 공격을 탐지한다는 의미로 읽어서는 안 된다. 그래서 무해화가 함께 필요하다.

제품별로 탐지와 무해화의 조합은 다음과 같다.

SLCDR은 CDR 전용 제품이며 리버스 엔지니어링 기반 탐지 엔진을 포함하지 않는다. 탐지는 백신·YARA·평판(TI)으로 이루어진다. 문서형 공격의 근본 원인(Exploit)까지 분석해야 하는 구간이라면 MARS가 함께 들어가는 SLF나 SLE 구성을 검토하는 것이 맞고, 이미 다른 탐지 계층이 있어 무해화만 보강하려는 구간이라면 SLCDR이 맞다. 어느 쪽이든 판단 기준은 "그 구간에 문서의 근본 원인 분석까지 필요한가"다.

원리를 이해했다면 다음은 정책이다. 같은 엔진이라도 정책 설계에 따라 보안 수준과 업무 마찰이 크게 달라진다. 실무에서 결정해야 할 항목은 대체로 다섯 가지로 정리된다.

첫째, 원본 처리. 무해화된 파일을 전달한 뒤 원본을 어떻게 할지 정해야 한다. 원본을 즉시 폐기하면 6장의 디지털 서명이나 매크로 의존 업무에 대응할 수 없다. 격리 저장소에 일정 기간 보관하고 승인 절차를 거쳐 원본을 내려받게 하는 방식이 흔히 쓰인다. 보관 기간과 접근 권한, 원본 반출 시 추가 검사 여부를 함께 정한다.

둘째, 처리 실패 시 기본값. 파싱이 실패하거나 지원하지 않는 포맷이 들어왔을 때 통과시킬지 차단할지를 정한다. 보안 관점에서는 차단 후 격리(fail-closed)가 원칙이지만, 업무상 반드시 받아야 하는 특수 포맷이 있다면 해당 포맷만 예외로 열고 탐지 계층을 거치게 한다.

셋째, 포맷·경로별 차등. 외부 메일 첨부, 망연계 반입, 웹 게시판 업로드는 위험도와 업무 요구가 다르다. 외부 메일은 엄격하게, 협력사 전용 전송 경로는 매크로 보존 예외를 두는 식으로 경로마다 허용 목록을 달리 설계할 수 있다.

넷째, 기록. 어떤 파일에서 어떤 요소가 제거되었는지 남겨야 한다. 이 기록은 사용자 문의 대응의 근거이자, "우리 조직에 들어오는 파일에 액티브 콘텐츠가 얼마나 섞여 있는가"를 보여주는 위협 지표다. 탐지 결과와 함께 보관하면 사고 조사 때 유입 경로를 거슬러 올라가는 데 쓰인다.

다섯째, 사용자 안내. 사용자가 "파일이 이상해졌다"고 느끼는 순간이 가장 큰 마찰이다. 무해화된 파일임을 알리고 원본 요청 방법을 함께 안내하면 문의가 줄어든다.

무해화 제품은 문서 소개만으로 비교하기 어렵다. 처리 방식과 품질은 실제 파일로 돌려봐야 드러난다. 아래 점검표는 PoC·BMT 단계에서 원리 수준의 차이를 확인하기 위한 항목이다.

PoC 샘플은 공개 악성 샘플만으로 구성하지 않는 것이 좋다. 무해화의 진짜 시험대는 악성 파일이 아니라 정상 업무 파일이다. 악성 요소를 얼마나 잘 걷어내는지만큼이나, 정상 파일을 얼마나 손상 없이 돌려주는지가 도입 후 운영 부담을 결정한다. 부서별로 자주 쓰는 양식, 복잡한 표가 들어간 보고서, 대용량 프레젠테이션을 섞어 넣는다.

무해화를 검토하는 과정에서 현업과 경영진에게서 반복해서 나오는 반론이 있다. 각각에 대해 과장도 축소도 없이 답할 수 있어야 도입 논의가 진전된다.

이 반론들의 공통점은 무해화를 탐지의 상위 호환이나 하위 호환으로 보는 시각이다. 파일 무해화 원리를 정확히 이해하면 둘은 같은 축 위에서 비교할 대상이 아니라는 결론에 이른다. 탐지는 파일에 대해 판단하고, 무해화는 파일을 다시 만든다. 공격자는 판단을 피하는 데 많은 노력을 들이지만, 허용되지 않은 요소가 빠진 새 파일에서 그 노력은 의미를 잃는다. 반대로 무해화가 손댈 수 없는 영역에서는 판단이 필요하다.

스피어피싱 첨부파일(T1566.001)과 사용자의 악성 파일 실행(T1204.002)은 MITRE ATT&CK가 각각 초기 접근과 실행 단계의 대표 기법으로 분류한다^[3][14]. 두 기법 모두 문서가 사용자의 손에 닿는 순간에 성패가 갈린다. 그 순간 직전에 문서를 다시 쓰는 것이 무해화의 자리다.