첨부파일 하나에서 인형이 계속 나왔다 — 로펌을 노린 HollowFrame 로더 분해기

이미지 출처: The Hacker News

러시아 인형 마트료시카를 열면 안에 또 인형이 있고, 그 안에 또 있음. 이번에 로펌을 겨냥한 스피어피싱 캠페인에서 발견된 백도어에 Matryoshka라는 이름이 붙은 이유가 딱 그거임. 메일 첨부 하나를 열었을 뿐인데 로더가 나오고, 로더 안에서 또 다른 단계가 나오고, 마지막에야 진짜 백도어가 메모리에 앉음. 그리고 그 첫 껍데기 역할을 한 게 HollowFrame이라는 로더임.

핵심 요약

• 로펌 임직원을 겨냥한 표적 스피어피싱 → 정상 서명 실행파일 + 악성 DLL 사이드로딩으로 HollowFrame 로더 실행
• 로더가 여러 겹으로 복호화·주입하는 다단계 구조라 디스크에는 최종 백도어가 거의 남지 않음
• 방어 포인트는 페이로드 시그니처가 아니라 비정상 부모-자식 프로세스, 낯선 경로의 서명 바이너리, 사용자 쓰기 가능 경로의 DLL 로드

1. 왜 하필 로펌인가

공격자 입장에서 로펌은 굉장히 맛있는 표적임. 이유가 몇 가지 겹침.

• 고객사의 M&A·소송·특허·내부조사 자료가 한 곳에 모여 있음. 정작 그 기업 본사를 뚫는 것보다 훨씬 쉬움
• 메일로 낯선 사람에게서 문서를 받는 게 업무 그 자체임. "모르는 첨부는 열지 마세요" 교육이 구조적으로 잘 안 먹히는 조직임
• 보안 인력·예산이 동급 규모 금융권보다 얇은 경우가 많음. EDR은 깔려 있어도 튜닝·헌팅까지 가는 경우는 드묾

그래서 이런 캠페인은 대량 살포가 아니라 특정 변호사 몇 명에게만 날아감. 사건번호, 진행 중인 계약 건, 담당자 실명 같은 게 메일에 들어있으면 의심 회로가 잘 안 돌아가는 게 사람인지라...

2. HollowFrame이 하는 일 (개념 수준)

세부 코드까지 파고들 필요는 없고, 방어자가 기억할 골격은 단순함.

• 1단계 — 정상 실행파일을 앞세움: 아카이브나 문서 형태의 첨부 안에 정식 서명된 벤더 실행파일과 악성 DLL을 같이 넣음. 사용자는 정상 프로그램을 실행했다고 믿지만, 그 프로그램이 옆에 있는 가짜 DLL을 먼저 로드함(사이드로딩)
• 2단계 — 껍질 벗기기: 로더는 암호화된 blob을 메모리에서 풀어 또 다른 모듈을 만들어냄. 이 과정이 한 번이 아니라 여러 겹임. 그래서 마트료시카
• 3단계 — 정상 프로세스에 심기: 최종 백도어는 자기 이름으로 뜨지 않고 신뢰받는 프로세스 안으로 들어감. 디스크 기반 스캐너 관점에선 "볼 게 없음"
• 4단계 — 조용한 C2: 백도어는 HTTPS나 정상 클라우드/CDN 도메인 뒤에 숨어 긴 주기로 비콘을 던짐. 명령 수신 → 파일 수집·추가 모듈 투입

여기서 중요한 건, 각 단계가 개별적으로는 전부 합법적인 OS 기능이라는 점임. 그래서 "악성 시그니처 탐지" 하나만 믿으면 계속 놓침.

3. 그럼 어디서 잡나 — 탐지 관점 정리

개인적으로는 아래 네 가지를 헌팅 쿼리로 만들어두는 걸 추천함. 특정 캠페인이 아니라 이 부류 전체에 걸리는 그물임.

• 낯선 경로에서 실행되는 서명 바이너리: 정상 서명 EXE가 %TEMP%, %APPDATA%, 다운로드 폴더, 압축 해제 경로에서 뜨면 그 자체로 이상함. 서명 유효성만 보고 화이트리스트 하면 그대로 뚫림
• 사용자 쓰기 가능 경로의 DLL 로드: 이미지 로드 이벤트에서 DLL 경로가 사용자 프로필 하위인 경우. 사이드로딩 탐지의 핵심 신호임
• 비정상 부모-자식 관계: 메일 클라이언트·브라우저·아카이브 프로그램이 스크립트 호스트나 프로세스를 낳는 체인. Outlook → 압축프로그램 → 낯선 EXE 같은 흐름
• 주기성 있는 아웃바운드: 지터가 섞여 있어도 결국 규칙적임. 사용자 활동이 없는 시간대(퇴근 후·주말)에 특정 호스트만 계속 밖으로 말을 거는 패턴을 찾는 게 제일 확실함

지속성 쪽은 Run 키, 예약 작업, 서비스 등록, 시작 폴더 바로가기 정도를 기본으로 훑고, 특히 사용자 계정으로 만들어진 예약 작업은 평소 베이스라인이 있어야 이상함이 보임. 베이스라인 없이 알람만 켜두면 결국 소음에 묻힘.

4. 완화 — 지금 당장 손댈 수 있는 것들

• 첨부 정책부터: ISO·IMG·VHD·LNK 같은 컨테이너 계열은 메일 게이트웨이에서 기본 차단. 업무상 필요한 부서만 예외 처리
• Mark-of-the-Web 유지: 인터넷에서 온 파일 표식이 살아 있어야 오피스·OS 경고가 작동함. 컨테이너 포맷은 이 표식을 벗기는 데 자주 악용됨
• ASR 규칙 활성화: 오피스·메일 클라이언트의 자식 프로세스 생성 차단, 스크립트 호스트 제한. 감사 모드로 먼저 돌려보고 소음 확인한 뒤 차단 전환
• 애플리케이션 제어: 사용자 쓰기 가능 경로에서의 실행 자체를 막는 게 가장 근본적임. 도입 난도는 높지만 이 공격 계열 대부분이 여기서 죽음
• 이그레스 통제: 엔드포인트가 임의 도메인으로 직접 나가지 못하게 프록시 경유 강제. 최소한 로그라도 남아야 나중에 되짚음
• 훈련은 "열지 마세요"가 아니라 "이렇게 신고하세요": 로펌처럼 첨부를 열어야만 일이 되는 조직에선 차단 교육이 안 먹힘. 대신 열고 나서 이상하면 30초 안에 신고하는 경로를 만들어주는 게 훨씬 효과적임

5. 이미 열었다면 — 대응 순서

• 해당 단말 네트워크 격리(전원은 끄지 말 것 — 메모리에만 있는 최종 단계가 날아감)
• 메모리 덤프 확보 후 프로세스 트리·로드된 모듈·네트워크 연결 수집
• 같은 메일을 받은 다른 수신자 전수 조회. 표적형이라 대상이 소수이고, 그 소수는 대개 권한이 높음
• 해당 사용자 자격증명·세션 토큰 전부 무효화. 문서관리시스템(DMS)·메일함 접근 로그 역추적
• 고객 고지 의무 검토. 로펌은 사고 자체보다 고지 지연이 더 큰 문제가 되는 업종임

마무리

이 캠페인에서 제일 무서운 건 새로운 제로데이가 아니라, 전부 이미 알려진 기법의 조합이라는 점인 것 같음. 서명된 EXE, DLL 사이드로딩, 메모리 내 언패킹, 정상 도메인 뒤의 C2 — 하나하나는 몇 년 된 얘기인데 겹겹이 쌓으니 웬만한 스택을 그냥 통과함. 결국 방어도 한 겹으로는 안 되고, 프로세스 계보·모듈 경로·네트워크 주기성이라는 서로 다른 층의 신호를 같이 봐야 잡히는 구조임.

오늘 당장 다 못 하겠으면 딱 하나만 해보는 걸 개인적으로 추천함 — "사용자 프로필 경로에서 로드되는 DLL" 헌팅 쿼리 하나. 만들어서 일주일만 돌려보면 우리 조직에 원래 뭐가 돌고 있었는지부터 보이기 시작함. 거기서부터 차차 좁혀가면 됨. 다들 각자 환경에서 돌려보고 어떤 게 걸렸는지 댓글로 공유해주시면 좋겠음. 같이 해보아요!