탐지율 60/79, 샌드박스는 무혐의… Amadey 탈취모듈의 판정 간극

탐지율 60/79, 그런데 샌드박스는 "undetected" — Amadey 크리덴셜 탈취 모듈의 이상한 판정 격차

정적 시그니처 기반 엔진 60개가 악성으로 판정한 파일을, 유일하게 수행된 동적 분석 샌드박스는 "undetected"·"UNKNOWN_VERDICT"로 흘려보냈다. CTX Team이 추적 중인 이번 인디케이터 세트의 핵심은 신원이 뚜렷한 위협 행위자나 정교한 인프라 은닉이 아니라, 바로 이 판정 격차다. 대상은 Amadey 계열 크리덴셜 탈취 모듈로 지목된 Win32 DLL cred.dll(SHA256 635f64b4…dcd0a9c2e)이며, VirusTotal 기준 79개 엔진 중 60개가 이를 트로이목마·Amadey/Decred 계열로 명확히 태깅했지만, 실제 실행 시 행위를 관찰해야 하는 샌드박스 판정은 단 1건뿐이었고 그 1건조차 악성으로 분류되지 않았다. 정적 탐지와 동적 검증 사이의 이 간극은, 수동적으로 대기하다가 로더나 호스트 프로세스에 의해 호출될 때만 진짜 행위를 드러내는 모듈형 악성코드의 특성을 그대로 보여주는 사례로 읽힌다.

이 기록 자체는 규모가 크지 않다. 카탈로그에 오른 파일은 단 2개, IP는 1개, URL은 1개뿐이고 도메인은 전혀 확인되지 않는다. 그럼에도 이 얇은 데이터 조각이 흥미로운 이유는, 그 안에 담긴 단 하나의 실체 있는 파일이 탐지·행위 분석 사이의 불일치를 명료하게 보여주는 표본이기 때문이다. CTX Team은 이 판정 격차를 캠페인 전체의 응집도를 입증하는 근거로 쓰기보다, Amadey류 모듈형 악성코드가 왜 자동화된 샌드박스 트리아지를 통과할 수 있는지를 보여주는 개별 사례로 다룬다.

서명 없는 126KB DLL이 감춘 Amadey 언패킹 경로

cred.dll은 서명되지 않은 Win32 DLL로, 크기는 126KB에 불과하다. 파일에는 임포트 테이블이 사실상 비어 있어(import_count 0) 정적 분석 관점에서는 기능을 짐작하기 어렵지만, 이 파일이 남긴 대체 경로명이 훨씬 구체적인 힌트를 준다. VirusTotal에 기록된 alt_names 중에는 C:\Users\DEVDAS\AppData\Roaming\a20732a67da3b4\cred.dll, %HOME%\unpack\cred.dll 같은 경로가 포함돼 있는데, 이는 Amadey 로더가 페이로드를 언패킹해 사용자 AppData 하위에 배치하는 전형적인 동작 패턴과 일치한다. 파일명 자체가 cred.dll이라는 점, 그리고 popular_names에 amadey, decred, dump가 함께 붙어 있는 점도 이 파일이 단순 다운로더가 아니라 자격증명 수집을 담당하는 서브 모듈이라는 정체성을 뒷받침한다.

빌드 프로비넌스 차원에서 보면 이 파일의 imphash는 557f0c64436e04f97f66ceeb0911cbf0이며, vhash는 1150766d5c0d1515651033z12z2a9z3bz4ez2, ssdeep은 3072:Qx7p5EJTJX/DL5nr0Z2fgnXKSxN07IXauEe… 로 기록돼 있다. PE 섹션을 뜯어보면 .CODE 섹션 엔트로피가 6.51, .reloc 섹션이 6.68로 다소 높게 나타나지만, 이는 강력한 패킹의 흔적이라 부를 정도는 아니다. 오히려 .edata 섹션 엔트로피가 0.78에 불과한 등 섹션별 엔트로피 분포가 극단적이지 않다는 점은, 이 모듈이 별도의 난독화 레이어를 두껍게 씌우기보다 Amadey 본체가 다운로드해 그대로 얹는 서브 페이로드 형태로 설계됐을 가능성을 시사한다. 다만 이 파일 하나만으로는 imphash나 vhash를 공유하는 형제 샘플을 이 기록 안에서 확인할 수 없다 — 카탈로그에 함께 오른 두 번째 파일(8f007bab…)은 타입·크기·탐지·라벨·태그가 전부 공란인, 사실상 아무 정보도 남기지 않은 항목이어서 교차 비교의 축으로 쓸 수 없다.

이 파일에 붙은 YARA 룰도 정체성 판단에 결정적이다. 룰 INDICATOR_TOOL_PWS_Amady(ditekSHen 작성, indicator_tools 룰셋)는 설명란에 "Detects password stealer DLL. Dropped by Amadey"라고 명시하고 있다. 이는 추정이 아니라 룰 자체가 명문화한 정체성 규정이며, 이 파일이 Amadey에 의해 드롭되는 크리덴셜 탈취 전용 DLL이라는 점을 구조적으로 확인해 준다. VirusTotal 최초 제출 시점은 2022년 3월 30일로 기록돼 있고, 20회 제출·8개의 고유 소스가 확인돼 이 샘플이 일회성 노이즈가 아니라 어느 정도 유통돼 온 표본이라는 점도 드러난다.

정적 탐지 60/79 vs 동적 판정 0/1 — 무엇이 이 간극을 만드는가

industry_view 데이터를 자세히 들여다보면 격차의 윤곽이 더 선명해진다. cred.dll의 탐지 통계는 malicious 60건, undetected 15건, type_unsupported 4건으로 나뉜다. ALYac, AVG, AhnLab-V3, Alibaba, Antiy-AVL, Arcabit, Avast, Avira, BitDefender, CrowdStrike, Cylance, ESET-NOD32, Kaspersky 등 주요 벤더 대부분이 이 파일을 악성으로 태깅했다. 반면 이 파일에 대해 실행된 샌드박스는 단 1건("C2AE" 환경)뿐이고, 그 결과는 category "undetected", malware_classification "UNKNOWN_VERDICT"로 종료됐다. 샌드박스 컨센서스는 총 1건 중 malicious 0건 — 즉 이 파일이 실제로 자격증명을 훔치는 동작을 하는 순간을 담은 실행 로그가 이 기록 안에는 존재하지 않는다.

이 간극이 왜 발생하는지는 파일의 구조에서 이미 힌트가 나온다. import_count가 0인 DLL은 스스로 완결된 실행 흐름을 갖추고 있지 않을 가능성이 크다 — 즉 정상적으로 동작하려면 Amadey 로더 프로세스가 특정 함수를 호출해 이 모듈을 붙여야 한다. 단독으로 실행되거나 자동화된 샌드박스에 그대로 투입될 경우 진입점만 통과한 채 아무 행위도 나타내지 않을 수 있다. 이는 로더/호스트 프로세스의 개입이 있어야만 자격증명 탈취 행위가 발현되는 수동적 DLL 모듈의 특성과 부합하는 관측이며, 방어 측 관점에서는 정적 시그니처가 잡아낸 위협을 동적 행위 기반 트리아지가 놓칠 수 있다는 구체적 사례로 남는다. 다만 이 해석은 이 하나의 샌드박스 로그와 파일 구조로부터 끌어낸 분석가의 추론이며, 로더 프로세스 자체의 실행 체인이 이 기록에 직접 캡처돼 있는 것은 아니라는 점은 분명히 해둘 필요가 있다.

러시아 소재 IP의 Plesk 인증서 — 발판인가 흔적인가

이 파일과 연동된 유일한 네트워크 인디케이터는 IP 193.106.191.201(러시아, RIPE NCC 관리)이며, 상위 위협 메타데이터는 이를 "c2-servers" 카테고리, Amadey 패밀리로 분류해 두었다. 그러나 VirusTotal 원시 탐지 데이터를 보면 이 IP의 탐지율은 12/91, 커뮤니티 reputation은 -37에 그친다. 상위 라벨이 부여한 "C2 서버"라는 확정적 지위와, 실제 원시 텔레메트리가 보여주는 상대적으로 낮은 탐지 신호 사이에는 눈에 띄는 낙차가 있다 — 외부 위협 인텔리전스 라벨링이 근거가 되는 원시 데이터보다 앞서 나간 사례로 볼 수 있으며, 이 IP를 확정적 C2 인프라로 단정하기보다는 신중하게 접근할 필요가 있다는 해석이 가능하다.

이 IP에 걸린 HTTPS 인증서는 인프라 측 분석에서 가장 구체적인 물증이다. 인증서 발급자는 Let's Encrypt(issuer CN R3)이고, subject CN은 cool-murdock.193-106-191-201.plesk.page, 유효기간은 2022년 12월 3일부터 2023년 3월 3일까지 89일이다. serial number는 044c2b0ad3ecf2a7dda2ad9c91df5f86fa15로 기록돼 있다. 이 호스트명 구조 — IP 주소 숫자열이 그대로 서브도메인에 박혀 있고, .plesk.page로 끝나는 형태 — 는 오퍼레이터가 별도로 등록한 캠페인 전용 도메인이 아니라, Plesk 관리형 호스팅 패널이 자동으로 발급하는 기본 호스트명 인증서의 전형적인 패턴이다. 89일이라는 유효기간 역시 Let's Encrypt의 표준 발급 주기와 일치할 뿐, 오퍼레이터가 의도적으로 설계한 인증서 회전 전략의 증거로 보기는 어렵다. 즉 이 인증서는 캠페인을 특정 운영팀에 귀속시킬 만한 고유한 지문이라기보다, 공유 호스팅 환경에서 흔히 관측되는 배경 잡음에 가깝다고 해석하는 편이 안전하다.

WHOIS 레코드에도 눈에 띄는 균열이 있다. 이 IP가 속한 inetnum 193.106.191.0 - 193.106.191.255의 레코드는 netname RU-MTU-20231204, created 필드가 2025-12-09T12:26:26Z로 찍혀 있는 반면, 이를 소유한 조직 레코드(org: ORG-ZM1-RIPE, org-name MTS PJSC)의 created 필드는 2004-04-17T11:55:44Z로 20년 이상 차이가 난다. 이는 RIPE 데이터베이스 내부의 통상적인 재할당·재기록 절차에서 발생할 수 있는 시점 불일치일 수도 있지만, 최소한 이 IP 블록의 실제 사용 이력을 인증서 유효기간(2022년 말)과 단순 대응시켜 "언제부터 이 IP가 이 목적으로 쓰였는가"를 확정하기 어렵게 만드는 요인이다. 결과적으로 인프라 측 증거는 캠페인의 독립적인 이야기를 구성하기보다, 파일 측에서 확인된 판정 격차에 곁들여지는 배경 맥락 정도로 자리매김한다.

Amadey 표준 파이프라인 위에서 발생한 신호 하나

이 기록이 담고 있는 공격 흐름은 특별히 새로운 기법 조합이라기보다 Amadey 계열이 반복해 온 표준적인 전달-탈취 파이프라인에 가깝다. 실행 단계에서는 서명되지 않은 cred.dll이 Amadey 로더에 의해 로드되는 구조로 추정된다 — 이는 정상 실행 파일에 악성 DLL을 얹어 실행을 위탁하는 System Binary Proxy Execution(T1218, T1218.011) 계열 기법과 궤를 같이하지만, 이 특정 샘플에 대해 rundll32 같은 프로세스가 실제로 이 DLL을 호출하는 로그가 이 기록 안에 직접 캡처돼 있지는 않다는 점에서 이 단계는 관측이 아닌 추론으로 남는다.

자격증명 접근 단계는 반대로 직접적인 물증을 갖고 있다. 앞서 인용한 YARA 룰 INDICATOR_TOOL_PWS_Amady가 "password stealer DLL. Dropped by Amadey"라고 명시한 것이 그대로 Credentials In Files(T1552, T1552.001) 기법과 대응된다 — 이는 룰 매치 자체가 증거이므로 단정적으로 서술할 수 있는 부분이다. 상위 메타데이터에 함께 태깅된 MITRE 기법 목록에는 방어 회피 계열(T1562, T1562.001, Impair Defenses), 디버거 탐지 회피(T1622), 레지스트리 질의(T1012, Query Registry), 네이티브 API 호출(T1106)도 포함돼 있다. 이들은 Amadey 패밀리 전반에서 관측돼 온 특성이지만, 이 특정 파일의 샌드박스 로그가 사실상 비어 있는 상태이기 때문에 해당 기법들이 이 샘플에서 실제로 발화했다는 것을 직접 뒷받침하는 실행 증거는 없다 — 패밀리 수준의 태깅에서 끌어온 추론으로 다뤄야 한다.

체인의 마지막 단계인 명령제어는 앞서 다룬 193.106.191.201이 담당하는 것으로 보인다. 이 IP가 "c2-servers" 카테고리와 Amadey 패밀리 태그를 동시에 갖고 있고 HTTPS 인증서를 운용 중이라는 점은 이 IP가 크리덴셜 탈취 모듈의 비콘 종착점이었을 개연성을 뒷받침하지만, 앞 절에서 짚었듯 이 인증서 패턴 자체는 범용 관리형 호스팅의 산물이라 오퍼레이터를 특정할 만한 지문으로는 부족하다. 종합하면 이 공격 흐름은 Amadey 특유의 전달-탈취 구조를 그대로 따르는 비교적 표준적인 패턴이며, 특별히 새로 관찰할 만한 지점은 정적 탐지와 동적 판정 사이의 간극 그 자체에 집중돼 있다.

행위자 공백과 "espionage" 태그의 어색한 동거

이 기록에는 명시적으로 귀속된 위협 행위자가 없다. 상위 메타데이터의 actors 항목은 비어 있고, 유일하게 채워진 라벨은 악성코드 패밀리 amadey와 동기 분류 espionage뿐이다. Amadey는 일반적으로 특정 국가 배후 행위자에 전속되기보다 다수의 사이버 범죄 그룹이 재사용하는 범용 로더·크리덴셜 탈취 도구로 알려져 있으며, 이 기록에서 확인된 증거 — 서명되지 않은 크리덴셜 탈취 DLL, ASN 정보조차 없는 러시아 소재 IP, Plesk가 자동 발급한 범용 인증서 — 는 특정 오퍼레이터를 특징짓는 정교한 트레이드크래프트라기보다 상업적으로 유통되는 도구 세트의 통상적인 사용 흔적에 더 가깝다.

이 때문에 상위 메타데이터가 붙여 놓은 "espionage" 동기 태그는 실제 관측된 아티팩트와 다소 어긋난다. 자격증명 탈취 기능 자체는 첩보 목적에도, 금전적 목적의 계정 탈취에도 똑같이 쓰일 수 있는 범용 기능이기 때문에, 이 태그 하나만으로 이번 활동을 국가 배후 첩보 작전으로 규정하는 것은 성급하다. 현재 확인 가능한 단서만으로는 이 크리덴셜 탈취 시도가 첩보 목적의 정밀 표적화인지, 아니면 Amadey를 활용하는 다수의 범죄 오퍼레이터 중 하나가 벌인 기회주의적 계정 탈취인지 판단하기 어렵다 — 단정적 결론은 현 단계에서 어렵다고 보는 것이 타당하다.

판정 격차가 남기는 함의

이 기록이 던지는 시사점은 캠페인의 규모나 정교함이 아니라, 탐지 계층 간의 신뢰 격차에 있다. cred.dll 사례는 정적 시그니처 기반 엔진 60개가 일치된 판정을 내린 파일을, 단 한 번의 동적 분석이 "undetected"로 흘려보낼 수 있음을 구체적으로 보여준다. 자동화된 샌드박스 트리아지에 크게 의존하는 탐지 파이프라인이라면, 로더 프로세스 없이 단독으로 투입된 모듈형 페이로드가 이런 식으로 걸러질 수 있다는 점을 이번 사례가 다시 확인시켜 준다.

또한 이 IP가 보여준 "C2 카테고리 라벨 vs 원시 탐지율 12/91"의 낙차는, 위협 인텔리전스 소비자들이 상위 카테고리 태그를 그대로 신뢰하기보다 그 밑에 깔린 원시 텔레메트리를 함께 확인해야 한다는 점을 일깨운다. Plesk 자동 인증서나 내부적으로 불일치하는 WHOIS 타임스탬프처럼, 겉보기엔 인프라 프로파일링에 쓸 만해 보이는 아티팩트가 실제로는 공유 호스팅 환경의 잡음일 수 있다는 사실도 이번 기록이 남긴 실질적인 교훈이다. 결국 이번 슬라이스가 보여주는 것은 거대한 캠페인의 전모가 아니라, Amadey 같은 상용 도구가 유통되는 생태계에서 탐지 신호 하나하나를 얼마나 신중하게 검증해야 하는지를 보여주는 축소판이라 할 수 있다.