안티분석 3종·자가삭제·WMI, 한 바이너리의 정석 침투

실행 유예, 자기 삭제, WMI 호출 — 하나의 바이너리가 그리는 정석적인 침투 시나리오

Win32 PE32 실행파일 하나가 VirusTotal 76개 엔진 중 61개로부터 탐지되고, 동적 분석 샌드박스 2곳(Dr.Web vxCube, Lastline) 모두에서 malicious 판정을 받았다. 이 위협에는 trojan.python/fkuk라는 이름이 붙어 있고, 추적 패밀리명은 stitch로 확인된다. 눈에 띄는 것은 탐지율 자체가 아니라 이 샘플이 담고 있는 행동 지문의 조합이다 — 디버거 탐지, CPU 타이머 직접 판독, CPU 모델 문자열 조회로 이어지는 3단 안티분석 루틴이 한 실행파일 안에 나란히 박혀 있고, 재부팅 생존 설치와 자가 삭제, WMI 호출을 통한 환경 열거가 순서대로 이어진다. 이 기사는 이 한 개의 지표가 보여주는 공격 기법의 결을 따라간다 — 인프라나 행위자 귀속이 아니라, 이 바이너리가 실제로 무엇을 하도록 설계됐는지가 이번 분석의 척추다.

이 지표를 캠페인이라 부르기엔 아직 조심스럽다. 같은 데이터셋 안에서 이 파일은 imphash·서명자·위협 라벨 어느 축으로도 다른 지표와 묶이지 않는 유일한 항목이며, 내부 신뢰도 평가 자체도 '낮음(16점)'으로 매겨져 있다. 그럼에도 이 파일 자체가 담고 있는 행위 정보량은 상당하다. 아래에서는 이 샘플이 어떤 경로로 실행에 이르렀을 것으로 추정되는지, 실행 이후 무엇을 관측했는지, 그리고 그 관측이 어디까지가 확인된 사실이고 어디부터가 해석인지를 구분해 짚는다.

위장 파일명이 말해주는 유통 방식

이 실행파일은 2016-11-03에 처음 관측된 이래 2026-08-02까지 총 85건이 제출됐고 66개의 서로 다른 제출 경로를 거쳤다. 흥미로운 것은 동일한 SHA256(4d651f1030ec2c17597a7c1ebf788e67a8eb22d74144f3ebe597d7313d615df6)이 서로 전혀 무관한 위장 파일명 아래 반복 등장한다는 점이다 — 스프레드시트 함수 강의를 가리키는 In-Session Advanced Formulas and Functions.exe, 개인 이름을 딴 Hamid Baroudi - City No Mad.exe, 프랑스어 억양 표기가 섞인 파일명, 그리고 내부적으로는 C:\boots\syswin.exe라는 이름으로도 관측된다.

이 파일명 다양성을 그 자체로 유포 경로에 대한 확정적 증거로 보기는 어렵다. 다만 동일한 바이너리가 언어권과 주제가 전혀 다른 위장 이름을 달고 반복 유통됐다는 관측은, 배포 측이 특정 산업이나 지역을 겨냥한 맞춤 미끼가 아니라 범용 소셜엔지니어링 미끼를 여러 개 돌려쓰는 방식을 택했을 가능성을 시사한다. 이는 이 캠페인이 정교한 스피어피싱보다는 광범위한 사용자 실행 유도(T1204.002)에 의존했을 것이라는 추론으로 이어지는데, 실제 전달 경로(이메일 첨부·다운로드 링크·번들 설치파일 등) 자체는 이 데이터에서 직접 관측되지 않았다는 점은 분명히 해 둬야 한다. 즉 여기서 말할 수 있는 것은 "위장 파일명이 반복 재사용됐다"는 관측이고, "그래서 스피어피싱이었다"는 것은 그 관측 위에 얹은 해석이다.

이 파일명 패턴과 별개로 확인되는 사실은 파일 자체가 사용자 상호작용을 기다리도록 설계돼 있다는 점이다. 실행 직후 곧바로 페이로드를 전개하는 것이 아니라 사용자 입력을 대기하는 거동은, 앞서 언급한 위장 파일명 전략과 맞물려 하나의 그림을 완성한다 — 미끼 이름으로 사용자를 속여 더블클릭을 유도한 뒤, 자동화된 배포 스크립트가 아니라 사람의 실행 행위 자체를 트리거로 삼는 구조다(T1204). 파일명 변형과 실행 대기 거동, 이 두 가지 서로 다른 증거를 겹쳐 보면 "이 샘플은 자동 전파형 웜이 아니라 사람을 속여 실행시키는 방식에 의존했다"는 판단이 자연스럽게 나온다.

F-PROT 패킹과 8년 벌어진 컴파일 타임스탬프

빌드 흔적을 보면 이 파일은 F-PROT 패커로 처리돼 있고, PE 헤더에 기록된 컴파일 타임스탬프는 2008-11-10로 찍혀 있다. 그런데 이 샘플이 실제로 처음 관측된 시점은 2016-11-03이다 — 컴파일 시각과 최초 관측 시점 사이에 8년의 간극이 존재한다. 이 간극을 두고 단정적으로 결론 내리기는 어렵다. 오래된 빌드 도구체인을 그대로 재사용했을 수도 있고, 타임스탬프 필드 자체가 위조·재활용됐을 가능성도 배제할 수 없다. 다만 어느 쪽이든 이 파일이 "방금 만들어진 신선한 빌드"는 아니라는 점은 분명하며, 이는 이 도구가 상당히 오래된 코드베이스 위에서 계속 재활용돼 왔을 가능성과 결이 맞는다.

PE 섹션 구성을 보면 .text 섹션 엔트로피는 6.22, 반면 .rsrc 섹션은 엔트로피 6.55에 크기가 3,007,488바이트로 전체 파일(약 4.6MB)의 대부분을 차지한다. 실행 코드 자체보다 리소스 섹션이 압도적으로 비대한 이 구조는, 파일 태그에 명시된 "실행파일 끝(EOF) 이후에 추가 데이터가 덧붙여져 있다"는 관측과 함께 읽을 필요가 있다. 코드 섹션은 작고 가볍게 유지하면서 리소스 영역에 별도 데이터를 쌓아두는 방식은 드로퍼가 2차 페이로드나 설정값을 리소스로 위장해 담아두는 전형적 수법과 겹치는데, 이 데이터셋만으로 그 리소스 내부의 실제 내용을 확인할 수는 없다는 한계는 남아 있다.

이 8년의 간극은 방어 체계 운영 관점에서 별도의 함의를 갖는다. 다수의 자동화된 위협 헌팅 파이프라인은 '최근 컴파일된 파일'을 신규 위협의 신호로 삼아 조사 우선순위를 배정하는데, 이 샘플처럼 PE 타임스탬프가 실제 관측 시점보다 훨씬 앞선 값을 갖는 경우 그런 규칙에서는 오히려 낮은 우선순위로 분류될 위험이 있다. 이 타임스탬프 이상 하나만 보면 단순한 필드 오류로 넘길 수도 있지만, 85건의 제출과 66개의 서로 다른 제출 경로라는 확산 규모를 함께 놓고 보면 다른 그림이 그려진다 — 이 파일이 짧은 기간에 폭발적으로 유포된 것이 아니라, 오래된 빌드가 긴 시간에 걸쳐 조용히 순환해왔고 그 순환 속에서 여러 위장 이름을 덧입었을 가능성이 더 설득력을 얻는다. 타임스탬프 이상과 제출 빈도라는 서로 다른 두 축의 증거가 같은 결론을 가리킨다는 점에서, 이는 '신선함'을 기준으로 위협을 걸러내는 방어 로직이 이런 장기 순환형 샘플 앞에서는 무력해질 수 있다는 경고로 읽을 수 있다.

안티분석 3종 세트가 실제 판정으로 이어진 흔적

이 샘플에서 가장 확실하게 뒷받침되는 것은 방어 회피 단계다. 파일에 부여된 행위 태그는 "디버거가 붙어 있는지 확인한다", "CPU 타이머를 직접 읽어 분석 환경 여부를 판별한다", "CPU 모델 문자열을 조회한다"는 세 가지 루틴을 명시하고 있다. 이 세 가지는 각각 독립적으로 봐도 표준적인 샌드박스·VM 탐지 기법이지만, 세 가지가 하나의 바이너리에 동시에 들어 있다는 점은 분석 환경 판별에 상당한 공을 들였다는 뜻으로 읽힌다(T1497).

그런데 이 회피 루틴이 실제로 분석을 완전히 무력화하지는 못했다는 점이 흥미롭다. Dr.Web vxCube와 Lastline 두 샌드박스 모두 이 샘플을 malicious로 판정했다 — 즉 안티분석 계측이 존재한다는 정적 관측과, 그 계측을 뚫고 동적 판정이 내려졌다는 행위 분석 결과가 서로 다른 증거 축에서 나와 같은 결론을 가리킨다. 방어자 시점에서 보면 이 지점이 중요하다. 만약 이 샘플이 실제 표적 환경의 샌드박스형 게이트웨이를 통과했다면, 회피 루틴이 분석 환경을 오탐하지 못하고 페이로드를 그대로 전개했을 가능성이 높다는 뜻이고, 이는 공격자가 회피 코드를 넣고도 실질적인 탐지 회피 효과를 온전히 누리지 못했을 수 있다는 해석으로 이어진다. 안티분석 계측을 넣는 선택은 공짜가 아니다 — 코드 크기와 복잡도를 늘리고 정적 탐지 시그니처에 걸릴 표면을 넓히는 대가를 치르는데, 이번 사례에서는 그 투자가 동적 판정 자체를 막아내지는 못한 셈이다.

재부팅 생존 설치와 자가 삭제 — 흔적을 지우는 대가

실행 이후 관측되는 지속성 메커니즘도 이 기사에서 다룰 만한 무게를 가진다. 태그 목록에는 "재부팅 이후에도 살아남도록 스스로를 설치한다"와 "실행 후 스스로를 삭제한다"는 두 가지 행위가 나란히 기록돼 있다. 이 두 행위를 붙여서 읽으면 하나의 운영 논리가 드러난다 — 최초 진입점 역할을 한 실행파일은 자신을 지워 증거를 없애는 동시에, 별도의 상주 구성요소를 재부팅 생존 형태로 남겨 둔다(T1547). 이는 초기 진입에 쓰인 위장 파일명(Hamid Baroudi - City No Mad.exe 같은 미끼)이 사고 대응 조사 시점에는 이미 사라져 있을 가능성을 의미한다.

방어자 입장에서 이 조합이 가진 함의는 분명하다. 사고 조사관이 사용자 PC에서 이상 행위를 포착했을 즈음에는 최초 실행파일 자체가 디스크에서 사라진 뒤일 가능성이 높고, 남아 있는 흔적은 재부팅 시점에 다시 활성화되는 별도 구성요소일 가능성이 크다. 즉 최초 진입 파일 하나만 놓고 포렌식을 진행하면 실제 지속성 메커니즘을 놓칠 수 있는 구조다. 다만 이 데이터에서는 재부팅 생존 대상이 구체적으로 어떤 형태(서비스, 레지스트리 런키, 스케줄 작업 등)를 취하는지까지는 확인되지 않으며, 이는 이 샘플이 가진 정보량의 한계로 남는다.

이어지는 태그는 "WMI를 호출한다"와 "실행 중 추가 모듈을 런타임에 로드한다"는 두 가지다. 이 둘을 순서대로 놓고 보면, 지속성이 확보된 이후 환경 정보를 WMI로 열거하고 그 결과에 따라 추가 모듈을 끌어오는 단계형 구조가 그려진다(T1047). 이는 이 샘플이 처음부터 모든 기능을 내장한 단일 완결형 페이로드가 아니라, 호스트 환경을 먼저 파악한 뒤 그에 맞는 후속 모듈을 선택적으로 적재하는 구조일 가능성을 시사한다. 다만 이 후속 모듈이 실제로 무엇을 수행하는지는 이번 지표 자체에서 관측되지 않으며, 이 대목에서 단정적 결론을 내리기는 이르다.

탐지율 61/76이 가려주지 못하는 것

VirusTotal 기준 이 샘플의 탐지율은 61/76이며, ALYac·AhnLab-V3·Kaspersky·BitDefender·ESET-NOD32를 비롯한 주요 엔진 30여 개가 악성으로 표시한다. 반면 Acronis, Avast-Mobile, ClamAV, Jiangmin, TACHYON 등 14개 엔진은 여전히 미탐 상태로 남아 있다. 커뮤니티 투표 역시 malicious 8건, harmless 0건으로 평판 점수는 -34를 기록한다. 표면적으로 이는 압도적 탐지 합의로 보이지만, 8년 가까이 유통된 파일임에도 여전히 일부 엔진이 이를 놓친다는 사실은 시그니처 기반 탐지가 오래된 샘플에도 완전한 커버리지를 보장하지 않는다는 점을 보여준다.

룰 매칭 측면에서는 InQuest Labs가 작성한 YARA 룰 Windows_API_Function이 이 파일에서 히트했다. 이 룰은 임베디드 실행파일 내부에서 흔히 관측되는 Windows API 호출 패턴을 잡아내는 용도로, 이 룰 자체가 단독으로 악성 여부를 판별하는 것은 아니지만 다른 실행파일을 내부에 담고 있을 가능성과 결이 맞는다는 점에서 앞서 언급한 비대한 리소스 섹션 관측과 겹쳐 볼 여지가 있다. Sigma 룰 세트에서는 중간(medium) 심각도 매칭이 1건 확인됐다. 이 정도의 룰 매칭 밀도는 이 샘플이 정교하게 시그니처를 회피하도록 설계된 것이 아니라, 표준적인 패킹·리소스 은닉 기법을 그대로 사용한 결과로 보는 것이 자연스럽다.

미탐 엔진 목록과 이 지표에 부여된 유일한 산업 태그를 겹쳐보면 짚어볼 만한 지점이 하나 더 있다. 미탐 목록에는 ClamAV처럼 학술·연구 기관의 리눅스 기반 메일 게이트웨이나 웹 서버에서 흔히 쓰이는 오픈소스 엔진이 포함돼 있는데, 이 자료에 달린 유일한 산업 태그가 education_research라는 점과 나란히 놓으면 우연으로 보기엔 걸리는 조합이다. 물론 이 데이터셋은 특정 기관이 실제로 어떤 백신 스택을 운용했는지를 알려주지 않으므로 이를 인과관계로 단정할 수는 없다. 다만 30여 개 주요 상용 엔진이 이 파일을 붙잡아내는 상황에서도 일부 오픈소스·경량 엔진이 여전히 놓치고 있다는 사실은, 이 파일이 관측된 산업군에서 흔히 쓰이는 방어 스택의 구성에 따라 실제 체감 탐지율이 61/76보다 낮게 나타날 수 있다는 가능성을 열어둔다.

고립된 지표 — 캠페인이 아니라 기법 표본

이 데이터셋에서 반드시 짚어야 할 특징은, 이 파일이 imphash·서명자·위협 라벨 어느 축으로도 다른 지표와 묶이지 않는 유일한 항목이라는 점이다. IP·도메인·URL 지표는 이 카탈로그 안에 하나도 없고, 이 실행파일 역시 코드 서명 없이 배포됐다(signed: false). 서명이 없다는 사실 자체는 이례적인 일이 아니지만, 그 결과로 공급망 신뢰 남용이나 인증서 재사용 같은 서사를 이 사례에 얹을 근거는 없다는 점을 분명히 해야 한다. 이 지표에 부여된 신뢰도 평가가 '낮음(16점)'으로 매겨져 있는 것도 같은 이유에서다 — 단일 지표, 서명 정보 부재, 교차 코호트 부재라는 세 가지 조건이 겹치면서 이 자료가 뒷받침할 수 있는 범위는 명확히 이 파일 한 개의 행위 프로파일로 제한된다.

이런 조건에서 이 지표를 특정 캠페인의 일부로 단정하는 것은 성급하다. 대신 이 자료가 실제로 잘 보여주는 것은 하나의 완결된 공격 기법 조합이다 — 위장 파일명을 통한 사용자 실행 유도, 사용자 입력 대기를 통한 실행 시점 제어, 3종 안티분석 계측, 재부팅 생존과 자가 삭제, WMI 기반 환경 열거와 후속 모듈 로딩까지, 다섯 단계가 하나의 실행파일 안에서 순서대로 관측된다. 이 정도로 완결된 기법 체인이 단 하나의 지표에서 확인된다는 사실 자체가 이례적이며, 다른 샘플과의 연결이 확인되기 전까지는 이를 "기법의 표본"으로 읽는 것이 가장 정확한 접근이다.

이름표의 모순 — python 계열 라벨과 네이티브 PE32의 간극

이 파일에 붙은 위협 라벨 trojan.python/fkuk와 별칭 목록의 python 표기는 다소 눈에 걸리는 대목이다. 실제 관측된 바이너리는 Python 인터프리터가 아니라 순수한 Win32 PE32 GUI 실행파일이며, 매직 바이트 역시 표준 MS Windows 실행파일 형식을 가리킨다. 추적 패밀리명으로 붙은 stitch를 함께 놓고 보면, 이 라벨링은 원본이 Python으로 작성된 코드를 PyInstaller류의 도구로 네이티브 실행파일로 컴파일한 결과물일 가능성을 암시한다. 다만 이 데이터셋에는 이 계보를 확정할 만한 참조 보고나 별도 근거가 없으므로, 이는 확정된 계열 분류가 아니라 라벨링 정황에 대한 조심스러운 추론으로 남겨 둬야 한다.

이 라벨과 패밀리명 자체가 이 샘플이 가진 행위 프로파일을 바꾸지는 않는다. 관측된 안티분석 루틴, 지속성 메커니즘, WMI 기반 열거는 원본 언어가 Python이든 C/C++이든 동일하게 유효한 사실이다. 다만 이 이름표의 존재는 향후 이 계열의 다른 샘플이 발견될 경우 교차 비교를 시도할 하나의 실마리를 제공한다는 점에서 기록해 둘 가치가 있다.

Python 기반 코드를 굳이 네이티브 Win32 PE로 컴파일해 배포하는 선택에는 뚜렷한 손익 구조가 있다. 얻는 쪽에서 보면, 표적 호스트에 별도의 Python 런타임이 설치돼 있을 필요가 없어지고 이중 클릭만으로 실행되는 완결형 바이너리를 확보할 수 있으며, 스크립트 형태로 유포할 때보다 정적 분석 장벽이 한 단계 높아진다. 반대로 대가도 분명하다 — 인터프리터와 라이브러리를 통째로 묶어 넣은 결과물은 파일 크기가 4.6MB에 달할 만큼 비대해지고, 이는 .rsrc 섹션이 전체 파일의 대부분을 차지하는 이례적 구조로 그대로 드러난다. 즉 실행 편의성과 런타임 의존성 제거라는 이득을 챙기는 대신, 파일 크기와 리소스 섹션 비율이라는 정적 탐지 관점의 이상 신호를 스스로 노출시킨 셈이다. 이 교환은 이번 샘플이 정교한 은닉보다 범용성과 즉시 실행 가능성을 우선시하는 도구였음을 시사한다.

행위자 라벨의 무게 — 확인보다 표시

이 지표에는 행위자 이름 HolyWater(별칭 Storm Cloud)와 espionage·financial-gain이라는 두 가지 동기가 함께 태깅돼 있다. 그러나 이 지표를 뒷받침하는 지역 정보, 인프라 지표, 혹은 이 행위자와 연결되는 두 번째 지표는 이 자료 안에 존재하지 않는다. 첩보 목적과 금전 목적이 동시에 부여된 조합은 흔치 않은 편인데, 이를 확정된 이중 임무 수행 조직으로 단정하기보다는 라벨링 과정에서의 표기 관행이거나, 서로 다른 임무를 넘나드는 하이브리드형 운영 조직일 가능성 둘 다를 열어두는 것이 현재로서는 더 안전한 해석이다. 이 행위자명 자체를 근거로 삼아 본문의 다른 분석 결론을 강화하지는 않았다는 점을 밝혀둔다 — 이번 분석의 무게는 처음부터 끝까지 관측된 기법 자체에 있다.

이 행위자 라벨을 다르게 읽을 여지도 남아 있다. 데이터셋에는 이 파일과 'HolyWater'를 직접 연결하는 어떤 기법적 증거 — 공유 인프라, 서명 코호트, 별도의 두 번째 지표 — 도 없고, 지역·모티프 필드도 비어 있다는 점을 감안하면, 이 라벨은 분석가가 이 파일 하나를 놓고 개별적으로 내린 귀속 판단이 아니라 상위 트래킹 체계에서 상속된 자동 태그일 가능성을 배제할 수 없다. 그렇다면 방어자 입장에서 취해야 할 태도는 명확하다 — 이 라벨을 근거로 'HolyWater' 연관 차단 규칙이나 탐지 우선순위를 이 파일 하나에 맞춰 조정하는 것은, 그 라벨이 실제로는 이 지표의 기법적 실체와 무관하게 부여됐을 위험을 그대로 조직의 대응 체계에 이식하는 결과가 될 수 있다. 이번 자료가 뒷받침하는 것은 행위자 식별이 아니라 행위 프로파일이라는 점을 다시 강조할 필요가 있다.

이 표본이 위협 지형에 던지는 질문

단일 지표라는 제약 안에서도 이 샘플이 시사하는 바는 분명하다. 61/76이라는 높은 탐지율과 2개 샌드박스의 malicious 합의가 있다고 해서 그 지표가 곧바로 잘 이해된 캠페인으로 이어지는 것은 아니라는 점을, 이 사례가 정확히 보여준다. 탐지 합의는 "악성이라는 사실"에 대한 확신을 주지만, "누구의 캠페인이고 어떤 인프라 위에서 작동하는지"에 대한 확신은 전혀 다른 종류의 증거 — 서명 코호트, 인증서 재사용, 공유 인프라 — 를 필요로 한다. 이번 지표는 그 두 번째 층위의 증거를 전혀 남기지 않은 채 유일하게 첫 번째 층위, 즉 기법 자체의 완결성만을 남겼다.

교육·연구 분야가 이 지표에 부여된 유일한 표적 산업 태그라는 점도 짚어둘 만하다. 다만 위장 파일명의 폭이 스프레드시트 강의 자료부터 개인 이름 파일까지 걸쳐 있다는 점을 함께 고려하면, 이 태그를 특정 섹터를 정밀 타겟팅한 결과로 읽기보다는 교육·연구 환경에서 실제로 실행이 관측된 결과일 가능성 쪽에 무게를 두는 것이 자연스럽다. 즉 이 유포 방식은 넓게 뿌려진 뒤 우연히 관측 지점이 특정 산업에 걸렸을 가능성과, 애초에 그 산업을 노렸을 가능성을 현재 증거로는 구분하기 어렵다.

결국 이번 사례가 CTX Team의 분석 관점에서 갖는 의미는, 위협 인텔리전스가 종종 "탐지가 잘 되는 샘플=잘 이해된 위협"이라는 착시에 빠지기 쉽다는 점을 되짚어준다는 데 있다. 안티분석 계측, 실행 시점 제어, 지속성과 자가 삭제, 환경 열거로 이어지는 다섯 단계는 실전에서 충분히 위협적인 조합이며, 이 조합이 앞으로 다른 지표에서 재관측된다면 그때는 서명·인프라 코호트를 엮어 훨씬 확신 있는 캠페인 서사를 쓸 수 있을 것이다. 지금 시점에서는 이 기법 조합 자체를 하나의 참조 표본으로 기록해 두는 것이, 성급한 귀속보다 훨씬 정직한 결론이다.