HWP 악성코드 공격 표면 지도 —
포맷 구조별 침투 벡터와 차단 지점

한국 공공·방산·연구 기관을 겨냥한 스피어피싱에서 한글(HWP) 문서는 오래된 미끼다. 그런데 'HWP 악성코드'는 하나의 기법이 아니라 서로 다른 공격 표면 여러 개를 묶어 부르는 이름이다. EPS 이미지, OLE 개체, 문서 스크립트, 하이퍼링크, 그리고 문서 해석기 자체의 취약점은 실행 조건도, 막을 수 있는 지점도 각각 다르다. 이 글은 HWP 5.0 바이너리와 HWPX의 구조를 기준으로 각 공격 표면이 파일 안 어디에 자리 잡는지 지도로 그리고, MITRE ATT&CK 매핑과 유입 경로별 차단 지점, 실무 점검표를 공개 자료에 근거해 정리한다.

HWP는 한국 행정·교육·연구 현장에서 일상적으로 주고받는 문서 형식이다. 공문, 회의 자료, 연구 계획서, 채용·인사 공고가 이 형식으로 오간다. 수신자가 업무상 열어야 하는 문서라는 점이 공격자에게는 가장 큰 이점이다. 미끼 문서의 설득력은 내용에서 나오고, 내용의 설득력은 그 조직이 실제로 쓰는 문서 형식을 그대로 흉내 낼 때 높아진다.

공개된 위협 행위자 프로파일도 같은 방향을 가리킨다. MITRE ATT&CK은 APT37을 2012년 무렵부터 활동해 온 북한 연계 사이버 첩보 그룹으로, 피해 대상이 주로 한국에 집중됐다고 기술한다^[3]. 같은 데이터베이스는 Kimsuky가 초기에 한국 정부 기관과 싱크탱크, 각 분야 전문가를 표적으로 삼았다고 정리한다^[4]. 미국 CISA는 2020년 경보 AA20-301A에서 Kimsuky의 주된 초기 침투 수단으로 스피어피싱을 꼽았다^[5]. 표적이 한국 공공·연구 부문이고 침투 수단이 이메일 첨부라면, 그 표적이 일상적으로 주고받는 HWP 문서가 미끼로 쓰이기 쉬운 조건이 갖춰진다.

이 조건은 이메일 첨부라는 전달 방식과 HWP라는 문서 형식이 겹치는 지점에서 성립한다. 공격자는 메일 제목과 본문으로 업무 맥락을 만들고, 첨부 문서로 그 맥락을 완성한다. 수신자 입장에서는 평소 받는 공문이나 자료 요청과 구별할 단서가 적다. 그래서 HWP 첨부를 다룰 때는 "이 문서가 악성인가"만이 아니라 "이 문서가 어떤 경로로, 어떤 맥락과 함께 들어왔는가"를 함께 봐야 한다. 6장에서 유입 경로별 차단 지점을 따로 정리하는 이유도 여기에 있다.

HWP 악성코드를 별도 주제로 다뤄야 하는 이유는 하나 더 있다. 문서를 검사하려면 먼저 형식을 해석할 수 있어야 한다. HWP는 국내에 사용이 집중된 형식이고, 검사 도구가 이 형식을 얼마나 깊이 해석하는지가 방어 효과를 좌우하는 변수가 된다. 이 글이 캠페인 연대기 대신 파일 구조에 집중하는 이유도 여기에 있다.

공격 표면을 그리기 전에 짚어야 할 혼동이 있다. 흔히 "HWP는 KS X 6101 표준을 따르는 OLE 복합 문서"라고 설명하지만, 이 문장은 서로 다른 두 형식을 섞은 것이다. 확장자 .hwp로 저장되는 HWP 5.0 바이너리와 확장자 .hwpx로 저장되는 HWPX는 컨테이너 자체가 다르다.

HWP 5.0 문서를 CFB 열람 도구로 열면 대략 다음과 같은 구성이 보인다^[6]. 파일 인식 정보와 압축·암호 여부를 담은 FileHeader, 글꼴·스타일·바이너리 데이터 목록 같은 문서 공통 정보를 담은 DocInfo, 실제 본문이 들어가는 BodyText 스토리지와 그 아래 Section0, Section1 같은 섹션 스트림이 있다. 여기에 문서 요약 정보, 미리보기 텍스트(PrvText)와 이미지(PrvImage), 그림·OLE 개체 등을 담는 BinData, 문서 옵션을 담는 DocOptions, 문서 스크립트를 담는 Scripts 스토리지가 문서에 따라 붙는다.

본문 스트림은 레코드의 연속이다. 각 레코드는 태그 ID, 계층 수준, 데이터 길이를 담은 헤더 뒤에 데이터가 이어지는 구조이고, 길이가 일정 값을 넘으면 별도의 확장 길이 필드를 쓴다^[6]. 보안 관점에서 이 구조가 중요한 이유는 간단하다. 해석기가 파일 안의 길이 값을 믿고 메모리를 읽고 쓰기 때문에, 길이와 실제 데이터가 어긋나는 레코드는 그 자체로 파서 취약점을 건드리는 입력이 될 수 있다. 3장의 파서 취약점 항목에서 이 점을 다시 다룬다.

HWP 문서 안에서 공격자가 활용할 수 있는 위치를 다섯 갈래로 나눌 수 있다. 각 표면은 파일 안의 위치가 다르고, 무엇이 실행을 일으키는지도 다르다. 아래 표는 이 글 전체에서 사용할 지도다.

3.1 EPS 이미지 — 그림 속의 프로그래밍 언어

EPS(Encapsulated PostScript)는 그림 형식처럼 보이지만 본질은 PostScript 프로그램이다. PostScript는 조건 분기와 반복을 갖춘 프로그래밍 언어이고, EPS 그림을 화면에 그리려면 해석기가 그 프로그램을 실행해야 한다. 따라서 문서 뷰어가 EPS를 렌더링하는 순간 파일이 만든 코드가 해석기 위에서 돌아간다. 해석기가 안전 모드를 제대로 강제하지 못하거나 메모리 처리에 결함이 있으면, 그림 하나가 임의 코드 실행으로 이어진다.

PostScript 해석기 취약점이 실제로 악용된 사례는 공개 취약점 데이터베이스에서 확인할 수 있다. NVD는 CVE-2017-8291을 조작된 EPS 문서를 통해 안전 모드 우회와 원격 명령 실행이 가능한 Ghostscript 취약점으로 기술하며, 2017년 4월 실제 공격에 악용됐다고 적고 있다^[9]. 이 사례가 보여 주는 핵심은 특정 CVE 번호가 아니라 구조다. 문서 프로그램이 그림 처리를 외부 해석기에 맡기면, 문서의 안전성은 그 해석기의 안전성에 묶인다.

방어 측면에서 EPS는 비교적 판단이 쉬운 표면이다. 업무 문서에 EPS 그림이 꼭 필요한 경우는 조직마다 다르지만, 대부분의 공문·보고서는 PNG·JPEG 같은 래스터 이미지로 충분하다. EPS가 포함된 문서를 별도 정책으로 분리하거나, 무해화 과정에서 래스터 이미지로 대체하는 선택지가 현실적이다. 다만 설계·출판 부서처럼 벡터 그림을 실제로 쓰는 곳이 있다면 예외 경로를 미리 정해 둬야 한다.

3.2 OLE 개체 — 문서 안에 넣은 다른 파일

HWP는 다른 프로그램의 데이터를 문서 안에 개체로 넣는 OLE 삽입을 지원한다. 차트·수식·스프레드시트 조각처럼 정상적인 용도가 분명하지만, 같은 기능으로 실행 파일이나 스크립트 파일을 패키지 개체로 감싸 넣을 수도 있다. 본문에는 그럴듯한 아이콘이나 "첨부 문서를 확인하세요" 같은 안내만 보이고, 사용자가 개체를 더블클릭하면 안에 든 파일이 풀려 실행된다.

이 표면은 사용자 상호작용을 전제로 한다는 점에서 EPS·파서 취약점과 다르다. 프로그램 버전과 설정에 따라 실행 전에 경고 대화상자가 뜨는 경우도 있다. 그래서 공격자는 문서 본문에서 "보안상 내용이 숨겨져 있으니 아래 아이콘을 눌러 확인하라"는 식의 사회공학 문구로 클릭을 유도한다. 기술적 방어와 함께 사용자 교육이 실제로 효과를 내는 지점이기도 하다.

분석 관점에서는 BinData 스트림 이름에 붙은 확장자 표기를 그대로 믿지 않는 것이 중요하다. 스트림 이름은 데이터의 성격을 암시할 뿐이고, 실제 내용은 압축을 풀고 시그니처를 확인해야 알 수 있다. OLE 개체 안에 또 다른 CFB 구조나 실행 파일 헤더가 들어 있다면 그 내부까지 재귀적으로 들여다봐야 한다.

3.3 문서 스크립트 — HWP에도 매크로가 있다

매크로 위협을 Office 문서의 VBA로만 생각하기 쉽지만, HWP도 문서에 스크립트를 저장할 수 있다. HWP 5.0에서는 Scripts 스토리지가 그 자리이며, 문서 형식 문서는 이 스토리지 아래 스크립트 본문과 버전 정보를 담는 스트림을 정의한다^[6]. 스크립트는 문서 열기 같은 이벤트에 연결될 수 있다.

실제 실행 여부는 프로그램의 스크립트 보안 설정에 따라 달라진다. 설정에 따라 스크립트가 아예 실행되지 않거나, 실행 전 사용자에게 확인을 받거나, 경고 없이 실행될 수 있다. 따라서 "HWP 스크립트는 위험하다" 또는 "기본 설정이면 안전하다" 중 어느 쪽으로도 일반화할 수 없다. 조직이 배포한 버전과 설정값을 확인하고, 그 환경에서의 동작을 기준으로 위험을 판단해야 한다. 업무에 문서 스크립트가 필요 없는 조직이라면 수신 단계에서 스크립트를 제거하는 정책이 사용 편의를 거의 해치지 않는다.

3.4 하이퍼링크와 외부 참조 — 문서 밖으로 나가는 문

하이퍼링크는 가장 평범한 기능이자 가장 흔한 2단계 연결 수단이다. 문서 자체에는 악성 코드가 없고, 사용자가 링크를 누르면 피싱 페이지나 악성 파일 다운로드 주소로 이동한다. 첨부 파일 검사만으로는 이 구조를 악성으로 판정하기 어렵다. 파일 안에 실행 가능한 요소가 전혀 없을 수 있기 때문이다.

외부 자원을 참조하는 개체나 연결 문서도 비슷한 성격을 갖는다. 문서가 열릴 때 외부 자원에 접근하도록 구성되면, 수신자가 문서를 언제 어디서 열었는지가 외부로 드러날 수 있다. 이런 동작은 프로그램 버전·설정과 네트워크 환경에 따라 달라지므로 일률적으로 단정하기 어렵다. 다만 이 유형은 침투 자체보다 정찰에 가깝다는 점에서 의미가 있다. 실행 코드가 없는 문서가 "이 수신자는 메일을 열어 보는 사람"이라는 정보를 공격자에게 돌려줄 수 있다면, 그다음 단계의 미끼는 훨씬 정교해진다.

3.5 파서 취약점 — 기능이 아니라 결함을 노린다

앞의 네 가지는 모두 문서 형식이 정상적으로 제공하는 기능을 악용한다. 파서 취약점은 다르다. 문서 형식의 기능이 아니라 그 형식을 읽는 프로그램의 결함을 노린다. 2장에서 본 것처럼 HWP 레코드는 길이 필드를 갖고, 본문 스트림은 압축되어 있으며, 개체 데이터는 다시 다른 형식을 품는다. 이 각 단계에서 길이 검증이 빠지거나 경계 계산이 틀리면 메모리 손상이 생긴다.

파서 취약점 공격은 사용자에게 아무 행동도 요구하지 않을 수 있다. 문서를 여는 순간, 혹은 미리보기가 생성되는 순간 해석이 일어나기 때문이다. 문서 프로그램의 취약점은 공개 취약점 데이터베이스에 꾸준히 등록되고, 패치가 배포된 뒤에도 업데이트가 늦은 단말은 계속 노출된다. 패치 이전의 취약점, 즉 제로데이라면 업데이트를 성실히 적용한 단말도 예외가 아니다.

3.6 HWP 바깥의 연쇄

최근의 HWP 관련 공격을 이해하려면 HWP 파일 밖도 함께 봐야 한다. 압축 파일 안에 정상 HWP 문서와 바로가기(LNK)·스크립트 파일을 함께 넣거나, 실행 파일에 HWP 아이콘과 문서처럼 보이는 이름을 붙이는 방식이 그 예다. 이 경우 HWP는 공격 코드를 담는 그릇이 아니라 사용자를 안심시키는 위장 장치로 쓰인다. ATT&CK에서는 이런 위장을 Masquerading(T1036)으로 분류한다^[14].

이 유형에서 HWP 파일 자체는 완전히 정상일 수 있다. 따라서 "첨부된 HWP가 깨끗한가"만 묻는 검사는 공격 전체를 보지 못한다. 압축 파일 내부 구성, 실행 형식 파일의 위장 여부, 이중 확장자 같은 요소를 함께 판단해야 한다.

HWP 악성코드에 대한 설명이 서로 어긋나 보이는 이유는 대부분 실행 조건을 생략하기 때문이다. "문서를 열기만 해도 감염된다"는 설명과 "클릭하지 않으면 안전하다"는 설명은 각각 다른 표면에 대해서는 맞다. 아래 표는 위험 판단에 영향을 주는 조건을 정리한 것이다.

이 표에서 실무적으로 읽어야 할 점은 두 가지다. 첫째, 사용자 PC의 버전과 설정이 위험을 크게 바꾼다. 같은 문서라도 업데이트 상태와 스크립트 보안 설정에 따라 결과가 다르다. 둘째, 버전과 설정에 영향을 덜 받는 표면이 있다. 파서 취약점은 열람만으로 성립할 수 있고, 제로데이라면 버전 관리로도 막지 못한다. 단말 관리만으로 다룰 수 있는 표면과 그렇지 않은 표면을 구분해야 방어 투자의 우선순위가 정해진다.

망분리 환경도 이 표를 다르게 읽게 만든다. 인터넷이 차단된 업무망 단말에서는 외부 참조와 C2 통신이 원칙적으로 성립하기 어렵다. 그렇다고 위험이 사라지는 것은 아니다. 업무망으로 넘어온 문서가 다른 경로로 인터넷망 단말에서 다시 열릴 수 있고, 파서 취약점을 통한 코드 실행은 내부망 정찰의 발판이 될 수 있다. 망분리는 후속 단계를 어렵게 만들 뿐, 문서 해석 단계의 위험을 없애지는 않는다.

공격 표면을 ATT&CK 기법에 연결해 두면 탐지 규칙, 사고 보고서, 위협 인텔리전스를 같은 언어로 엮을 수 있다. HWP 관련 공격에서 반복적으로 연결되는 기법은 다음과 같다.

매핑에서 눈여겨볼 부분은 T1204.002와 T1203의 구분이다. 전자는 사용자의 행동에 기대고, 후자는 프로그램의 결함에 기댄다. 사용자 교육과 실행 확인 정책은 T1204.002 계열에 효과가 있지만 T1203 계열에는 거의 영향을 주지 못한다. 반대로 패치 관리는 이미 알려진 T1203 취약점에는 효과적이지만 사용자가 스스로 실행하는 OLE 개체는 막지 못한다. 한 가지 통제로 모든 기법을 덮을 수 없다는 점이 매핑으로 드러난다.

사이버 킬체인 모델은 침입을 정찰부터 목적 달성까지의 단계로 나누고, 앞 단계에서 끊을수록 방어자에게 유리하다고 본다^[15]. HWP 악성코드에 이 모델을 적용하면 문서가 조직 안으로 들어오는 전달 단계가 핵심이 된다. 문서가 단말에서 열리기 전에 처리하면, 3장의 다섯 표면 중 어느 것이 쓰였든 사용자 PC의 버전과 설정에 덜 의존하게 된다.

조직에서 HWP 문서가 들어오는 경로는 대체로 네 갈래다. 각 경로마다 처리 시점과 적용 가능한 통제가 다르다.

경로를 나눠 보면 한 가지 원칙이 드러난다. 문서가 반드시 지나가는 관문을 만들고, 그 관문에서 처리한다. 처리 지점이 많아질수록 정책이 일관되지 않을 가능성도 커지므로, 경로별 처리 결과를 같은 기준으로 기록하고 비교할 수 있어야 한다. 같은 발신 패턴이나 주제의 미끼 문서가 메일과 웹 업로드처럼 서로 다른 구간에서 동시에 나타날 수 있기 때문이다. 경로별 기록을 한곳에서 대조할 수 있으면, 따로 처리된 차단 건들을 하나의 캠페인으로 묶어 보고 대응 범위를 정할 수 있다.

공공기관이라면 국가망 보안체계(N2SF) 관련 문서도 함께 검토 대상이다. 국가사이버안보센터가 공개한 N2SF 가이드라인^[16]과 KISA가 2026년 4월 발간한 실증 사례집^[17]은 망 경계에서 자료를 다루는 방식을 설계할 때 참고할 수 있는 자료다. 문서 유입 지점의 처리 방식을 정할 때는 이 자료들의 요구사항과 조직 등급 분류를 함께 대조해야 한다.

관문에서 문서를 처리하는 방식은 크게 네 가지다. 각 방식은 잘하는 것과 구조적으로 어려운 것이 다르다. 어느 하나가 다른 것을 완전히 대체한다고 보기보다, HWP 공격 표면별로 무엇이 어디서 강한지를 보는 편이 정확하다.

시큐레터의 MARS 엔진은 이 가운데 리버스 엔지니어링을 문서형 공격 탐지의 축으로 삼는다. 자동화된 리버스 엔지니어링으로 문서를 어셈블리 수준까지 분해해, 악성 행위가 일어나기 전에 취약점의 근원을 찾아낸다. 위 표에서 샌드박스 기반 동적 분석의 어려움으로 꼽은 가상환경 회피, 시간차 공격, 사용자 행위 조건 같은 우회 기법은 행위 기반 방식이 놓치기 쉬운 지점이고, MARS는 이를 근본 원인 분석으로 잡는다. 탐지 범위는 문서에 한정되지 않는다. 문서·이미지·압축 파일은 리버스 엔지니어링으로, 실행 파일은 백신·YARA·평판 분석으로 탐지한다. 3.6절처럼 정상 HWP 미끼와 위장 실행 파일이 함께 오는 공격에서는 이 두 갈래가 함께 필요하다. 그럼에도 어떤 탐지도 모든 공격을 잡을 수는 없으므로, 시큐레터는 탐지와 무해화를 함께 쓴다. 탐지가 놓친 것은 CDR 무해화가 막는 구조다.

CDR 방식은 일반적으로 파일을 스캔해 액티브 콘텐츠를 찾고, 이를 제거한 뒤 파일을 재생성하는 흐름을 따른다. 탐지와 무해화를 관문에 함께 둘 때는 두 단계의 처리 시간이 정책 선택에 직접 영향을 준다. 시큐레터 자료는 CDR 평균 무해화 소요시간을 파일당 34ms로 제시하고^[2], 분석 시간은 TTA GS 인증 실측 기준 12초로 제시한다^[1]. 무해화는 밀리초 단위, 분석은 초 단위라는 차이가 있으므로, 구간별로 어떤 결과를 먼저 사용자에게 전달하고 어떤 결과를 기록으로 남길지도 함께 설계해야 한다. 메일·망간 전송처럼 사용자가 결과를 기다리는 구간에서는 이런 처리 시간이 곧 업무 흐름의 문제다. 처리가 느리면 운영 부서가 예외 경로를 요구하게 되고, 예외 경로는 그 자체로 공격 경로가 된다.

위 표의 등급은 방식 간 상대적 성격을 나타낸 것이고, 개별 제품의 성능을 뜻하지 않는다. 같은 방식이라도 구현에 따라 결과는 크게 다르다. CDR이 파서 취약점에 대해 갖는 효과도 일반론으로 이해해야 한다. CDR 방식은 일반적으로 원본 바이트를 그대로 전달하지 않고 필요한 내용만으로 문서를 새로 만들기 때문에, 원본의 조작된 레코드가 사용자 PC의 해석기에 직접 도달하지 않는다. 다만 재생성 과정에서 원본을 해석하는 쪽 역시 해석기이므로, CDR 엔진 자체의 형식 해석 안정성이 함께 검증되어야 한다.

CDR을 HWP에 적용할 때 기술보다 먼저 부딪히는 것은 정책 결정이다. 무엇을 지우고 무엇을 남길지, 처리할 수 없는 파일은 어떻게 할지를 미리 정하지 않으면 운영 첫 주에 예외 요청이 쏟아진다. 다음은 HWP 환경에서 자주 나오는 쟁점이다.

쟁점 대부분은 "보안이냐 편의냐"의 양자택일처럼 보이지만, 실제로는 원본 보관과 요청 기반 복원 절차로 상당 부분 풀린다. 무해화된 문서를 기본으로 전달하고, 원본이 꼭 필요한 사용자는 승인 절차를 거쳐 원본을 받도록 하면, 기본값은 안전하게 유지하면서 업무 예외를 통제된 방식으로 처리할 수 있다. 이때 원본 요청 이력은 그 자체로 유용한 감사 기록이 된다.

관문 통제와 별개로, 보안 담당자는 신고된 의심 문서를 직접 확인해야 할 때가 있다. 아래 절차는 문서를 실행하지 않고 구조만으로 1차 분류하는 순서다. 분석은 반드시 격리된 분석용 환경에서 하고, 분석 대상 파일은 업무 단말의 문서 프로그램으로 열지 않는다.

이 절차의 목적은 최종 판정이 아니라 어느 공격 표면을 의심해야 하는지 좁히는 것이다. 1~4단계에서 스크립트·OLE·EPS가 하나도 없고 링크도 평범하다면, 남는 의심은 파서 취약점이나 HWP 바깥의 연쇄다. 이 두 범주는 수작업 확인으로 결론을 내기 어렵고, 형식 명세 수준의 정합성 검사가 필요하다. 1차 분류 결과는 3장의 지도 기준으로 기록해 두면 이후 유사 문서를 비교할 때 기준이 된다.

지금까지의 내용을 운영 점검 항목으로 정리한다. 관문 통제, 단말 통제, 탐지·대응 체계로 나눴다. 각 항목 옆의 표기는 3장 지도의 어느 공격 표면과 연결되는지를 나타낸다.

점검표를 처음 적용하는 조직이라면 우선순위를 두는 편이 현실적이다. 가장 먼저 할 일은 경로 목록화다. 경로를 모르면 어디에 통제를 두어야 할지 정할 수 없다. 그다음은 이메일 경로 처리다. 1장에서 본 것처럼 한국 공공·연구 부문을 노리는 위협 그룹의 주된 초기 침투 수단으로 스피어피싱이 보고된 만큼, 메일 첨부를 먼저 관문으로 묶는 것이 우선순위를 정하는 합리적인 출발점이 된다. 단말 통제는 관문 통제와 병행하되, 관문을 우회하는 경로를 줄이는 정책과 짝을 이뤄야 의미가 있다.