들어가며
1편에서는 감염된 USB 드라이브의 최초 동작 방식부터, 1차 로더인 u364204.dll이 EDR 제품의 API 후킹을 어떻게 원천 우회하는지까지를 다뤘습니다.
PEB 직접 워킹, 해시 기반 API 리졸빙, Direct Syscall의 조합이 얼마나 정교하게 설계된 구조인지 확인할 수 있었습니다.
2편에서는 1차 로더가 최종적으로 시스템에 무엇을 설치하는지, 그리고 설치된 각 컴포넌트가 구체적으로 어떤 역할을 수행하는지를 순서대로 분석합니다.
아울러 왜 단순한 파일 삭제만으로는 이 악성코드를 완전히 제거할 수 없는지, 그 구조적 이유도 함께 살펴봅니다.
분석 대상이 된 악성코드는 AhnLab ASEC이 2025년 2월부터 추적 중인 PrintMiner 계열, Mandiant가 DIRTYBULK / CUTFAIL로 분류한 캠페인과 동일한 샘플임이 확인되었습니다.
시간을 많이 들여 분석한건 아니며 잘못 분석된 내용이 존재할 수 있습니다.
틀리더라도 너그러히 봐주시면 감사하겠습니다.
1. 다단계 드롭 체인 구조
마트료시카 구조 개요
이 악성코드의 가장 두드러진 특징 중 하나는 러시아 전통 인형인 마트료시카처럼, 파일 안에 파일이 반복적으로 내장되는 다단계 드롭 체인 구조입니다.
체인의 각 단계는 다음 단계를 내부에 암호화하거나 압축하여 내장하고 있으며, 실행 시 이를 꺼내 특정 경로에 기록한 뒤 실행하는 방식으로 최종 페이로드까지 도달합니다.
u364204.dll ← 1차 로더 (1편 분석 대상)
└─ svcin64.exe (6.81MB 암호화 내장) ← 2차 로더
└─ svctrl64.exe (6.58MB 내장) ← 서비스 설치 및 워치독
└─ C:\Windows\System32\wsvcz\
├─ u500603.exe ← XMRig 채굴기 본체
├─ u655385.dll ← 내부망 정찰 및 횡이동 모듈
├─ WinRing0x64.sys ← 취약 커널 드라이버 (BYOVD)
└─ wlogz.dat ← C&C 암호화 설정 파일
이 구조가 갖는 의미는 단순히 복잡하다는 것에 그치지 않습니다.
체인의 어느 한 단계 파일을 삭제하더라도, 상위 단계에 해당하는 파일이 살아있는 한 즉시 재설치가 이루어지는 자가 복구 구조가 완성됩니다.
단순한 파일 삭제만으로는 완전한 제거가 불가능한 근본적인 이유입니다.
wsvcz 설치 폴더 확인
최종적으로 악성코드의 핵심 파일들은 C:\Windows\System32\wsvcz\ 폴더에 집중되어 설치됩니다.
해당 폴더명은 svchost, svcwiz 등 실제 Windows 시스템 서비스 관련 폴더명과 유사하게 지어져 있어,
육안 검사에서 쉽게 간과될 수 있도록 설계되어 있습니다.

u500603.exe(채굴기), WinRing0x64.sys(커널 드라이버), wlogz.dat(C&C 설정), u185632.dat가 설치되어 있습니다.
감염 여부를 빠르게 확인하는 가장 간단한 방법은 이 폴더의 존재 여부를 확인하는 것입니다.
해당 폴더가 존재한다면 이미 드롭 체인의 최종 단계까지 실행이 완료된 감염 확정 상태로 판단할 수 있습니다.
2. svcin64.exe - 2차 로더 분석
기본 정보

VS2022 64비트 GUI 서브시스템, LTCG(Link-Time Code Generation) 최적화 빌드.
여러 개의 Operation system 항목이 감지되는 것은 내부에 복수의 PE 파일이 내장되어 있기 때문입니다.

svcin64.exe(약 6,977KB)와 함께 u655385.dll 등 추가 파일이 확인됩니다.
DIE 로 분석한 결과 svcin64.exe는 1차 로더인 u364204.dll과 마찬가지로 Visual Studio 2022 환경에서 빌드된 64비트 파일임을 확인했습니다.
LTCG(Link-Time Code Generation) 최적화가 적용된 GUI 서브시스템 실행 파일이며,
DIE 분석 결과에 여러 개의 Operation system 항목이 감지되는 것은 내부에 복수의 PE 파일이 내장되어 있음을 나타내는 징후입니다.
자가 복구 구조와 무결성 검증
svcin64.exe의 WinMain 진입 후 가장 먼저 수행되는 작업은 CreateMutexW를 통한 뮤텍스 생성입니다.
이미 동일한 뮤텍스가 시스템에 존재할 경우 GetLastError가 ERROR_ALREADY_EXISTS(183)를 반환하고,
중복 실행 방지를 위해 프로세스가 즉시 종료됩니다.
이어서 핵심 동작이 수행됩니다.
C:\Windows\System32\svctrl64.exe 파일의 존재 여부를 확인하고, 파일이 존재할 경우 내장된 원본 데이터와 4KB 단위로 바이트를 비교하는 무결성 검사를 진행합니다.
// 파일 크기가 정확히 6,904,320바이트인지 먼저 확인합니다.
if (*(_QWORD *)Buffer + ... != 6904320) goto 재설치;
// 4KB 청크 단위로 내장 원본과 1:1 바이트 비교를 수행합니다.
for (i = 0; i < 0x695A00; i += chunk_size) {
memcmp(Buf1, (char *)&unk_140031CE0 + i, chunk_size);
// 불일치 발생 시 재설치 분기
}
파일이 존재하지 않거나, 크기가 다르거나, 내용이 단 1바이트라도 변조된 것이 감지되면 내장된 원본을 즉시 다시 기록합니다.
백신이 svctrl64.exe를 탐지하여 치료하거나 격리하더라도,
svcin64.exe가 살아있는 한 곧바로 원래 상태로 복원됩니다.
이 자가 복구 구조는 이후 나올 svctrl64.exe의 워치독 루프와 함께 이중의 복원 체계를 형성합니다.
COM 기반 스텔스 실행
파일 기록이 완료된 이후 svctrl64.exe를 실행할 때 CreateProcessW를 직접 사용하지 않는다는 점이 주목할 부분입니다.
대신 CoInitializeEx와 CoCreateInstance를 통한 COM 오브젝트 방식으로 실행합니다.
대부분의 보안 솔루션은 CreateProcessW 계열 API 호출을 감시하여 신규 프로세스 생성 이벤트를 탐지합니다.
COM 인터페이스를 통한 실행은 이 감시 레이어를 우회하는 방식으로, 프로세스 생성 탐지 기반의 EDR 제품에 대한 추가적인 우회 기법이 적용된 것입니다.
3. svctrl64.exe 와 서비스 설치 및 워치독
기본 정보 확인

Import 테이블에 CreateServiceW, OpenSCManagerW, StartServiceW, ControlService, DeleteService 등 서비스 관리 API 전체가 포함되어 있습니다.
svctrl64.exe의 Import 테이블을 확인하면 이 파일의 역할이 명확하게 드러납니다.
CreateServiceW, OpenSCManagerW, StartServiceW, QueryServiceStatusEx, ControlService, DeleteService 등 Windows 서비스 제어 관리자(SCM)와 직접 상호작용하는 API 전체가 포함되어 있습니다.
반면 네트워크 통신이나 파일 암호화 관련 API는 존재하지 않습니다. 서비스 설치와 상태 감시라는 두 가지 역할에 완전히 특화된 구조입니다.
Windows 서비스 등록
WinMain 진입 후 OpenSCManagerW로 서비스 제어 관리자(SCM)에 접근한 뒤, 두 개의 서비스를 등록하고 즉시 시작합니다.
OpenSCManagerW(0, 0, 0xF003Fu); // 전체 권한으로 SCM에 접근합니다.
CreateServiceW(...WinRing0x64...); // 취약 커널 드라이버를 서비스로 등록합니다.
StartServiceW(WinRing0x64_handle); // 등록 즉시 서비스를 시작합니다.
CreateServiceW(...u500603...); // XMRig 채굴기를 서비스로 등록합니다.
StartServiceW(u500603_handle); // 등록 즉시 서비스를 시작합니다.
서비스 등록과 더불어 RegCreateKeyExW와 RegSetValueExW를 통해 레지스트리 Run 키에도 동시에 등록합니다.
서비스 기반과 레지스트리 기반의 지속성을 이중으로 확보하는 구조로, 재부팅 이후에도 두 가지 경로를 통해 자동으로 시작됩니다.
자가 복구 워치독 루프
svctrl64.exe의 두 번째 핵심 역할은 등록된 서비스들의 상태를 지속적으로 감시하는 워치독(Watchdog) 루프입니다.
WinMain 분석 결과를 통해 이 루프의 동작 방식이 명확하게 확인됩니다.
while (1) {
OpenSCManagerW(0, 0, 0xF003Fu);
OpenServiceW(handle, service_name, 4u);
// 서비스 현재 상태를 조회합니다.
QueryServiceStatusEx(v14, SC_STATUS_PROCESS_INFO, Buffer, ...);
v15 = *(_DWORD *)&Buffer[4] == 4; // 4 = SERVICE_RUNNING 상태인지 확인합니다.
// 서비스가 실행 중이면 파일 무결성도 추가 검사합니다.
memcmp(Buf1, (char *)&unk_14003A7C0 + i, chunk_size);
// 중지 상태이거나 파일 변조가 감지되면 즉시 재설치합니다.
if (!v4) sub_14000E940();
}
서비스가 중지된 것이 감지되거나, 파일 내용이 내장 원본과 달라진 것이 확인되면 즉시 재설치 함수를 호출합니다.
이 워치독 루프가 실행되고 있는 한, 외부에서 XMRig 서비스를 중지하거나 파일을 삭제하더라도 짧은 시간 안에 원래 상태로 복원됩니다.
완전한 제거를 위해서는 반드시 svctrl64.exe 자체의 프로세스와 서비스를 가장 먼저 중지해야 하는 이유가 바로 이 때문입니다. 제거 절차에 대해서는 9장에서 상세히 다룹니다.
4. u500603.exe 그리고 XMRig 채굴기 본체 분석
정체 확인
Strings 분석에서 정체가 즉시 드러납니다.
cryptonight-monerov7
cryptonight-monerov8
stratum+tcp://
stratum+ssl://
stratum+ssl://randomx.xmrig.com:443
.?AVEthStratumClient@xmrig@@
Monero(XMR)와 ETH를 모두 지원하는 XMRig 커스텀 빌드임이 확인됩니다. .?AVEthStratumClient@xmrig@@는 C++ RTTI(Run-Time Type Information) 데이터로, 소스 코드의 네임스페이스 이름인 xmrig가 바이너리에 그대로 잔존하는 것입니다.
stratum+ssl://randomx.xmrig.com:443은 XMRig 오픈소스 코드에 기본값으로 포함된 테스트용 풀 주소이며, 실제 공격자가 사용하는 풀 주소와 지갑 주소는 런타임에 wlogz.dat에서 읽어오는 방식으로 분리되어 있어 정적 분석으로는 확인이 불가능합니다.
Import 테이블에서도 XMRig 특유의 API 사용 패턴이 그대로 나타납니다.
GetLargePageMinimum, LsaAddAccountRights, DeviceIoControl, GetLastInputInfo 등이 핵심적인 항목들입니다.
스텔스 채굴 기법
사용자 활동 감지 및 유휴 시 채굴
GetLastInputInfo를 통해 사용자의 키보드·마우스 마지막 입력 시간을 주기적으로 확인합니다.
사용자가 PC를 사용 중인 상태에서는 채굴을 중지하고, 일정 시간 이상 입력이 없는 유휴 상태에서만 채굴을 재개합니다.
사용자가 PC를 직접 사용할 때는 성능 저하를 체감하기 어렵도록 설계된 스텔스 채굴 방식입니다.
Huge Pages 채굴 성능 최적화
GetLargePageMinimum과 LsaAddAccountRights를 통해 SeLockMemoryPrivilege 권한을 스스로 부여하고 Large Page(Huge Pages) 메모리 할당을 활성화합니다.
XMRig 공식 문서에 따르면 Huge Pages 활성화 시 RandomX 알고리즘 기준으로 해시레이트가 최대 15~50%까지 향상됩니다. 이 최적화를 수행하기 위해 WinRing0x64.sys와의 연계가 필요하며, 두 컴포넌트가 함께 설치되는 이유 중 하나입니다.
커널 드라이버와의 직접 통신
DeviceIoControl을 통해 WinRing0x64.sys 드라이버와 직접 IOCTL 통신을 수행합니다.
이를 통해 CPU의 MSR(Model Specific Register) 레지스터를 읽고 씀으로써 채굴에 최적화된 저수준 CPU 설정이 적용됩니다.
커널 드라이버를 통한 설정이 적용된 후에는 채굴 성능이 눈에 띄게 향상됩니다.
C&C 연동 구조
u500603.exe는 libcurl + OpenSSL 3.x를 정적 링크하고 있습니다. Boost.ASIO 네임스페이스와 libcurl 내부 디버그 메시지 포맷이 Strings에서 그대로 확인됩니다.
[CPOOL] added connection %lld. The cache now contains %zu members
[CPOOL] destroy, %zu connections
# Netscape HTTP Cookie File... generated by libcurl!
.onion
[CPOOL]로 시작하는 문자열은 libcurl 커넥션 풀의 내부 디버그 메시지로, libcurl이 정적 링크되어 있음을 확정하는 증거입니다. .onion 주소 지원 기능도 내장되어 있어, 필요 시 Tor 네트워크를 통한 C&C 통신으로 공격자 서버의 추적을 어렵게 만들 수 있습니다.
5. WinRing0x64.sys 그리고 BYOVD 커널 드라이버 악용
BYOVD 기법이란
BYOVD(Bring Your Own Vulnerable Driver) 는 Microsoft에 이미 취약점이 공개·보고된 정상 드라이버를 악성코드가 직접 패키지에 포함하여 배포하는 공격 기법입니다. 드라이버는 정상적으로 디지털 서명된 파일이기 때문에 Windows의 드라이버 서명 검증을 통과합니다. 그러나 해당 드라이버의 취약점을 통해 커널(Ring-0) 수준의 권한을 획득하거나 임의 코드를 실행하는 것이 핵심입니다.

WinRing0x64.sys는 원래 HWiNFO64, CPU-Z, OCCT 같은 하드웨어 모니터링 도구들이 저수준 하드웨어 접근을 위해 사용하는 정상 커널 드라이버입니다. 그러나 CVE-2020-14979(CVSS 7.8) 취약점을 통해 낮은 권한의 사용자 프로세스에서도 커널 메모리 읽기·쓰기 및 MSR 레지스터 접근이 가능하다는 것이 2020년에 공개되었습니다.
이전 취약드라이버를 이용한 커널 레벨 안티치트 우회 포스팅에서 심도있게 다루었습니다.
https://imoracle.tistory.com/70
[AntiCheat] 취약 드라이버를 이용한 커널 레벨 안티치트 우회 -1-
들어가며게임 해킹과 보안의 역사는 끊임없는 '창과 방패'의 대결입니다. 과거의 게임 핵(Hack)들이 단순히 유저 모드(User-Mode, Ring 3)에서 메모리를 변조하는 수준에 머물렀다면, 오늘날의 안티치
imoracle.tistory.com
https://imoracle.tistory.com/71
[AntiCheat] 취약 드라이버를 이용한 커널레벨 안티치트 우회 -2-
들어가며일반적으로 게임 보안 프로세스인 안티치트(Anti-Cheat)는 크게 유저 모드(User-Mode)와 커널 모드(Kernel-Mode) 기반으로 나뉩니다. 유저 모드 안티치트는 과거부터 메모리 후킹이나 코드 인젝
imoracle.tistory.com
Windows10에서 왜 동작했는가
이 시점에서 당연한 의문이 생깁니다. "취약점이 공개된 드라이버라면 Microsoft가 이미 차단하지 않았을까?"
Microsoft는 실제로 알려진 취약 드라이버를 차단하는 WDBL(Windows Defender Driver Block List)을 운용하고 있습니다. WinRing0x64.sys 역시 이 차단 목록에 등재되어 있습니다.
그러나 이 목록이 실제로 적용되어 드라이버 로드를 막으려면, HVCI(Hypervisor Protected Code Integrity, 메모리 무결성 / 핵심 격리) 기능이 반드시 활성화되어 있어야 합니다.
HVCI가 꺼져 있는 환경에서는 차단 목록 자체가 의미를 갖지 못합니다.
| Windows 버전 | HVCI 기본 설정 | BYOVD 동작 여부 |
| Windows 10 전체 | 꺼짐 | 동작함 |
| Windows 11 21H2 | 꺼짐 | 동작함 |
| Windows 11 22H2 이상 | 켜짐 | 차단됨 |
PC가 Windows 10 환경이었고, HVCI를 별도로 활성화한 이력이 없었습니다.
차단 목록은 존재했지만 이를 집행할 수단이 없었던 것입니다.
비유하자면 출입 금지 명단은 붙어있는데, 그 명단을 확인하는 경비원이 없는 상태였습니다.
더불어 이 악성코드는 WinRing0x64.sys로 수행하는 작업 중에 HVCI 자체를 비활성화하는 기능도 포함하고 있습니다.
설령 HVCI가 활성화된 환경에서 초기 로드에 실패하더라도, 다른 경로로 HVCI를 무력화한 뒤 재시도하는 대응까지 갖추고 있습니다.
드라이버가 수행하는 작업
WinRing0x64.sys가 로드된 이후 악성코드가 수행하는 작업은 크게 세 가지입니다.
- 채굴 성능 극대화: CPU의 MSR 레지스터를 직접 읽고 씀으로써 XMRig의 RandomX 채굴 알고리즘에 최적화된 저수준 CPU 설정을 적용합니다. 공식적으로 확인된 성능 향상 수치는 해시레이트 기준 15~50%입니다. 이 최적화는 일반 사용자 권한으로는 불가능한 작업으로, 커널 드라이버를 통해서만 접근 가능합니다.
- 보안 솔루션 프로세스 강제 종료: Ring-0 커널 레벨의 권한을 이용하면 사용자 공간에서 보호받고 있는 보안 솔루션 프로세스도 강제로 종료할 수 있습니다. 이는 설치된 EDR이나 안티바이러스 제품을 무력화하는 최후의 수단으로 활용될 수 있습니다.
- HVCI 비활성화: 시스템 보안 설정 중 HVCI를 비활성화합니다. 이미 꺼져있는 환경에서는 다시 켜지지 않도록 잠그는 역할을 합니다. 이로 인해 향후 보안 솔루션이나 관리자가 HVCI를 활성화하려 해도 재부팅 없이는 적용되지 않습니다.
6. u655385.dll 그리고 내부망 정찰 및 횡이동 모듈
정체 확인
wsvcz 폴더 내의 u655385.dll Import 테이블을 확인하는 순간, 단순한 채굴 보조 모듈이 아니라는 것을 즉시 알 수 있었습니다. WLDAP32.dll이 Import에 포함되어 있었기 때문입니다.
채굴기가 Active Directory에 접근할 이유는 없습니다. 이 DLL의 목적은 채굴 지원이 아닙니다.
확인된 Import 구성을 기능별로 분류하면 다음과 같습니다.
| 기능 분류 | 관련 API | 위협 수준 |
| AD 정찰 | ldap_search_s, ldap_bind_s, ldap_sslinit | 최고 |
| 네트워크 스캔 | NetShareEnum, GetIpNetTable2 | 높음 |
| 세션 탈취 | WTSQueryUserToken | 높음 |
| 횡이동 | CreateProcessAsUserW | 높음 |
| TLS 통신 | OpenSSL 3.6.1 정적 링크 | - |
| 인증서 접근 | CertOpenSystemStoreW, CertEnumCertificatesInStore | 높음 |
Active Directory 정찰
도메인 환경이 구성된 네트워크에서 ldap_search_s와 ldap_bind_s가 실행되었을 경우의 영향은 단순한 채굴 피해와는 차원이 다릅니다.
ldap_bind_s로 도메인 컨트롤러에 인증을 시도하고, ldap_search_s로 LDAP 쿼리를 수행하면 도메인 내 전체 사용자 계정 목록, 컴퓨터 목록, 조직 단위(OU) 구조, 그룹 멤버십, 권한 설정 정보가 조회됩니다.
이 정보는 이후 내부망 횡이동, 권한 상승, 추가 시스템 침투를 위한 정찰 데이터로 활용될 수 있습니다.
GetIpNetTable2를 통한 ARP 테이블 수집과 NetShareEnum을 통한 SMB 공유 폴더 열거는 내부 네트워크 지도를 완성하는 데 사용됩니다. 감염된 PC 한 대가 내부망 전체의 구조를 공격자에게 넘겨주는 정보원이 될 수 있는 것입니다.
WTSQueryUserToken과 CreateProcessAsUserW의 조합은 현재 다른 세션에 로그인되어 있는 사용자의 토큰을 탈취하고, 그 권한으로 임의의 코드를 실행하는 횡이동 기법에 사용됩니다.
모든 통신은 OpenSSL 3.6.1을 정적 링크한 TLS 암호화 채널을 통해 이루어집니다. 외부로 나가는 트래픽이 암호화되어 있어 내용 기반 탐지가 어렵습니다.
공격자 빌드 경로 노출과 IOC 가치
u655385.dll 바이너리 내에서 눈에 띄는 흔적이 하나 발견되었습니다. 빌드 과정에서 컴파일러가 소스 파일의 절대 경로를 바이너리에 자동으로 기록하는데, 이 경로가 그대로 잔존하고 있었습니다.
D:\CFILES\Projects\WinSSL\build\versions\3.6\3.6.1\temp_x64\crypto\err\err_local.h
공격자 개발 PC의 실제 폴더 구조가 그대로 노출된 것입니다. D:\CFILES\Projects\WinSSL\ 이라는 프로젝트 경로와 WinSSL이라는 프로젝트 명칭은 동일한 공격자 그룹이 제작한 다른 샘플을 식별하는 데 활용할 수 있는 IOC입니다. KISA에 침해사고를 신고할 때 이 경로를 함께 제출하면 유용하지 않을까 생각합니다.
7. wlogz.dat 그리고 C&C 통신 완료의 증거
파일 크기 변화가 말해주는 것
wlogz.dat는 svcin64.exe가 최초로 시스템에 기록할 때 32바이트 크기의 초기 설정값을 씁니다.
그런데 분석 시점에 실제 파일을 확인했을 때 크기가 272바이트로 증가해 있었습니다.
초기 드롭 시 크기: 32바이트 (svcin64.exe 내장 초기값)
분석 시점 크기: 272바이트 (+240바이트, C&C 수신 데이터)
차이인 240바이트는 C&C 서버에 성공적으로 접속하여 수신한 설정 데이터가 기록된 것입니다.
파일 크기 하나가 명확하게 말해주는 사실이 있습니다.
이 시스템은 이미 공격자 서버와 통신을 완료했으며, 공격자는 이 PC의 감염을 인지하고 있는 상태라는 것입니다.
암호화 구조
wlogz.dat 파일 내용은 AES로 암호화되어 있으며 272바이트는 정확히 17개의 AES 블록(17 × 16 = 272)으로 구성됩니다.
복호화에 필요한 키는 해당 시스템의 Windows 인증서 저장소에 종속되어 있어, 감염된 원본 PC가 아닌 환경에서는 복호화가 불가능합니다.
파일 내에는 실제 채굴 풀 서버 주소, 공격자의 모네로(XMR) 지갑 주소, XMRig 실행 파라미터, C&C 서버 IP가 포함된 것으로 추정됩니다. 내용을 확인하기 위해서는 u500603.exe 내부의 복호화 로직을 분석하거나, 감염 PC에서 메모리 덤프를 통해 복호화된 상태의 데이터를 추출하는 방법을 사용해야 합니다.
8. 침해지표 (IOC) 정리
악성 파일 경로
감염 확인 시 아래 경로에 해당 파일이 존재하는지 확인합니다.
| 파일명 | 경로 | 역할 |
| u364204.dll | C:\Windows\System32\ | 1차 로더 |
| svcin64.exe | C:\Windows\System32\ | 2차 로더 |
| svctrl64.exe | C:\Windows\System32\ | 서비스 설치 및 워치독 |
| u655385.dll | C:\Windows\System32\ | 정찰·횡이동 모듈 |
| u500603.exe | C:\Windows\System32\wsvcz\ | XMRig 채굴기 |
| WinRing0x64.sys | C:\Windows\System32\wsvcz\ | BYOVD 취약 드라이버 |
| wlogz.dat | C:\Windows\System32\wsvcz\ | C&C 암호화 설정 |
wsvcz 폴더 자체의 존재가 가장 빠른 감염 확인 수단입니다.
레지스트리 및 서비스 지표
아래 항목을 확인하여 지속성 등록 여부를 점검합니다.
:: Windows Defender 예외 목록에 System32가 등록되어 있는지 확인합니다.
powershell -Command "Get-MpPreference | Select-Object ExclusionPath"
:: 악성 서비스 등록 여부를 확인합니다.
sc query WinRing0x64
sc query | findstr /i "svc"
:: 레지스트리 자동 시작 항목을 확인합니다.
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
reg query HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
네트워크 지표
감염PC에서 외부로 향하는 비정상 연결을 확인합니다.
:: 현재 외부 연결 목록을 확인합니다.
netstat -ano | findstr ESTABLISHED
wlogz.dat가 복호화된 상태에서 메모리 덤프를 통해 C&C IP를 추출했다면, 해당 IP를 방화벽에서 즉시 차단합니다
공격자 식별 IOC
빌드 경로: D:\CFILES\Projects\WinSSL\build\versions\3.6\3.6.1\temp_x64\
관련 캠페인: PrintMiner (AhnLab ASEC), DIRTYBULK / CUTFAIL (Mandiant)
논리폭탄: 2025년 12월 23일 기점 자폭 시퀀스 ("barusu" 커맨드)
9. 제거 절차
제거 순서가 중요한 이유
앞서 분석한 것처럼 이 악성코드는 워치독 루프를 통해 파일 삭제 또는 서비스 중지가 감지되면 즉시 재설치를 수행합니다. 잘못된 순서로 제거를 시도하면 삭제한 파일이 곧바로 복원되는 상황이 반복됩니다. 반드시 워치독 역할을 하는 svctrl64.exe 서비스를 최우선으로 중지한 뒤 나머지 제거를 진행해야 합니다.
단계별 제거 명령어
1단계 : 워치독(svctrl64) 서비스 먼저 중지합니다.
sc stop [svctrl64 서비스명]
sc delete [svctrl64 서비스명]
2단계 : 채굴기와 커널 드라이버 서비스를 중지합니다.
sc stop WinRing0x64 && sc delete WinRing0x64
sc stop [u500603 서비스명] && sc delete [u500603 서비스명]
3단계 : 악성 파일을 삭제합니다.
del /f /q C:\Windows\System32\svcin64.exe
del /f /q C:\Windows\System32\svctrl64.exe
del /f /q C:\Windows\System32\u364204.dll
del /f /q C:\Windows\System32\u655385.dll
rmdir /s /q C:\Windows\System32\wsvcz
4단계 : Defender 예외 등록을 해제합니다.
powershell -Command "Remove-MpPreference -ExclusionPath 'C:\Windows\System32'"
5단계 : 레지스트리 Run 키 잔존 여부를 최종 확인합니다.
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
reg query HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
가장 확실한 제거 방법은 완전 포맷 후 OS 재설치입니다. 특히 Active Directory 도메인에 연결된 PC라면, 제거 후에도 도메인 관리자 계정 비밀번호 변경 및 도메인 내 다른 PC 전수 조사를 병행하는 것을 강력히 권장합니다.
마치며
단순한 USB 웜인줄 알았더니, 커널 드라이버 취약점 악용(BYOVD), EDR 완전 우회, Active Directory 정찰, 자가 복구 워치독까지 갖춘 다단계 공격 플랫폼을 마주하게 되었습니다.
분석 전 과정을 통해 확인된 가장 중요한 사실 두 가지를 정리하며 마칩니다.
첫째, wlogz.dat 파일 크기가 32바이트에서 272바이트로 증가한 상태였습니다. C&C 서버와의 통신이 이미 완료되었고, 공격자는 이 PC의 감염을 인지하고 있습니다. 이 사실이 확인된 순간부터 네트워크 분리가 최우선 과제입니다.
둘째, Windows 10 환경에서 HVCI가 활성화되어 있지 않은 한, CVE-2020-14979로 취약점이 공개된 드라이버도 차단 없이 커널에 로드됩니다. Windows 11 22H2 이상으로의 업그레이드 또는 Windows 10에서의 HVCI 수동 활성화가 이 계열 공격에 대한 가장 근본적인 대응입니다.
외부에서 유입된 USB 장치를 보안 검사 없이 PC에 직접 연결하는 관행 자체를 제도적으로 차단하는 것이 재발 방지의 핵심입니다.
잘못된 분석이 존재할 수 있습니다만 개인 공부 및 기록용이기에... 틀린점이 있더라도 너그러히 봐주시기 바랍니다
감사합니다.
1편: USB 전파형 코인채굴 악성코드 분석 (1) - EDR 우회와 3단계 드롭 구조
[PrintMiner] USB 전파형 코인채굴 악성코드 분석 (1) - EDR 우회와 3단계 드롭 구조
들어가며얼마 전 지인에게서 PC를 사용하다가 시스템이 갑자기 둔해지고 이상한 동작을 보인다며 연락이 왔습니다.USB를 꽂고 나면 탐색기에서 파일이 하나도 보이지않는데, 용량은 가득 차있는
imoracle.tistory.com
'Reverse Engineering > 악성코드 분석' 카테고리의 다른 글
| [PrintMiner] USB 전파형 코인채굴 악성코드 분석 (1) - EDR 우회와 3단계 드롭 구조 (0) | 2026.09.16 |
|---|---|
| [CodeEngn] Malware Analysis L01 (0) | 2024.07.04 |