헬프데스크에서 하이퍼바이저까지: UNC3944로부터 VMware vSphere 환경 보호하기
Mandiant
해당 블로그의 원문은 2025년 7월 24일 Google Cloud 블로그(영문)에 게재되었습니다.
서론
2025년 중반, 구글 위협 인텔리전스 그룹(GTIG)은 유통, 항공, 보험을 포함한 여러 산업을 표적으로 삼는 정교하고 공격적인 사이버 캠페인을 식별했습니다. 이는 '0ktapus', 'Octo Tempest', 'Scattered Spider'와 관련된 공개 보고와 중복되는 금전적 동기의 위협 그룹 UNC3944의 소행이었습니다. 연방수사국(FBI)의 공개 경고 이후, 이 그룹의 표적은 명확해졌습니다. GTIG는 이 그룹이 랜섬웨어 및 갈취 운영을 미국 유통 부문으로 전환한 것으로 의심된다고 관찰했습니다. 이 캠페인은 곧 더 확대되어, 북미의 항공 및 운송 조직 또한 표적이 되었습니다.
이 그룹의 핵심 전술은 일관적이며 소프트웨어 취약점에 의존하지 않습니다. 대신, 그들은 IT 헬프데스크로의 전화에 초점을 맞춘 검증된 전략을 사용합니다. 이 공격자들은 공격적이고 창의적이며, 성숙한 보안 프로그램조차 우회하기 위해 사회 공학을 사용하는 데 특히 능숙합니다. 그들의 공격은 기회주의적이지 않고, 조직의 가장 중요한 시스템과 데이터를 목표로 하는 정밀한 캠페인 기반의 운영입니다.
그들의 전략은 'living-off-the-land(LoTL)' 접근 방식에 뿌리를 두고 있습니다. 사회 공학을 사용하여 하나 이상의 사용자 계정을 침해한 후, 그들은 신뢰할 수 있는 관리 시스템을 조작하고 Active Directory에 대한 통제권을 발판 삼아 VMware vSphere 환경으로 피벗합니다. 이를 통해 데이터를 유출하고 하이퍼바이저에서 직접 랜섬웨어를 배포하는 경로를 확보합니다. 이 방법은 전통적인 침해 지표(IoC)를 거의 생성하지 않고, ESXi 하이퍼바이저 및 vCenter Server Appliance(VCSA)에 대한 가시성이 제한적이거나 전혀 없는 엔드포인트 탐지 및 대응(EDR)과 같은 보안 도구를 우회하기 때문에 매우 효과적입니다.
이 블로그 게시물은 UNC3944의 vSphere 중심 공격 해부에 대한 심층 분석을 제공하고, 완화를 위해 필요한 강화된 다중 기둥 방어 전략을 개괄합니다. VMware vSphere를 Microsoft Active Directory와 통합할 때의 위험에 대해 더 자세히 알아보세요. 또한, Mandiant 전문가들로부터 이러한 전략을 직접 배우기 위한 예정된 웹 세미나를 확인하세요.
vSphere 로깅 기본
UNC3944의 vSphere 관련 운영과 관련된 주요 탐지 신호 및 보안 강화 전략을 논하기 전에, vSphere 로깅과 vCenter 이벤트 및 ESXi 호스트 로그 간의 차이점을 이해하는 것이 중요합니다. 중앙 syslog 서버로 전달될 때, vCenter 서버 이벤트와 ESXi 호스트 로그는 두 가지 뚜렷하면서도 상호 보완적인 데이터 소스를 나타냅니다. 그들의 근본적인 차이점은 범위, 출처, 그리고 vCenter 로그의 구조화되고 이벤트 기반적인 성격과 ESXi의 장황하고 파일 기반적인 출력에 있습니다.
1. vCenter Server (VC 이벤트)
vCenter 이벤트는 관리 영역에서 작동하며, 전체 가상 환경에 걸친 관리자 작업 및 자동화된 프로세스에 대한 구조화된 감사 추적을 제공합니다. 각 이벤트는 VmPoweredOnEvent
또는 UserLoginSessionEvent
와 같은 고유한 eventTypeId
로 식별되는 개별적이고 잘 정의된 객체입니다. 이러한 프로그래밍적 식별은 자동화된 파싱, 경고, 그리고 보안 분석을 위해 Splunk 또는 Google Chronicle과 같은 SIEM(보안 정보 및 이벤트 관리) 플랫폼에 수집하기에 이상적입니다.


그림 1: VC 이벤트 로그 구조
- 기본 스토리지 및 syslog 전달: 이러한 이벤트는 vCenter Server에 의해 생성되어 내부 VCSA 데이터베이스(PostgreSQL) 내에 저장됩니다. 전달 시, vCenter는 이러한 구조화된 이벤트의 실시간 복사본을 syslog 서버로 스트리밍합니다. 결과적으로 생성되는 로그 메시지에는 일반적으로 공식적인
eventTypeId
와 함께 사람이 읽을 수 있는 설명이 포함되어 정밀한 분석이 가능합니다. -
주요 사용 사례:
-
보안 감사 및 포렌식: 사용자 작업, 권한 변경 및 인증 추적
-
변경 관리: 클러스터, 호스트 및 가상 머신(VM)에 대한 모든 구성 변경에 대한 명확한 기록 제공
-
자동화된 경고: 특정
eventTypeId
(HostCnxFailedEvent
등)를 기반으로 SIEM 또는 모니터링 도구에서 경고 트리거
-
-
vCenter 이벤트 예시: vCenter 이벤트 매핑 저장소와 같은 자료에 문서화된 바와 같이, 각 이벤트에는 특정 프로그래밍 식별자가 있습니다
-
UserLoginSessionEvent
-
설명: "사용자
{userName}@{ipAddress}
가{locale}
로 로그인했습니다" -
중요성: vCenter 관리 영역에 대한 모든 사용자 접근을 추적하는 데 중요한 보안 이벤트
-
-
VmCreatedEvent
-
설명: "데이터센터
{datacenter.name}
의 호스트{host.name}
에 가상 머신{vm.name}
이 생성되었습니다" -
중요성: 자산 관리 및 변경 제어에 필수적인 새 인벤토리 객체 생성을 기록
-
-
VmPoweredOffEvent
-
설명: "데이터센터
{datacenter.name}
의 호스트{host.name}
에 있는 가상 머신{vm.name}
이 전원이 꺼졌습니다" -
중요성: 워크로드의 운영 상태 및 가용성을 추적합니다. 예상치 못한 전원 차단 이벤트는 문제 해결의 핵심 지표입니다
-
-
VCSA 로깅 제한 사항: VCSA는 기본적으로 거부된 네트워크 연결 또는 셸 명령어 활동에 대한 중요한 보안 로그 전달을 지원하지 않습니다. 이 비기본 기능을 활성화하려면, 기본 Photon OS 수준에서 맞춤형 구성이 필요합니다. 이는 내장된 리눅스 도구(iptables
및 logger
등)만을 활용하고 제3자 소프트웨어를 설치하지 않는 에이전트 없는 접근 방식입니다. 이 구성은 방화벽 및 셸 이벤트를 VCSA의 표준 rsyslog
서비스로 파이프하여, 내장된 원격 로깅 메커니즘이 이를 중앙 SIEM으로 전달할 수 있게 합니다.
2. ESXi 호스트 로그
ESXi 로그는 하이퍼바이저 수준에서 작동하며, 세분화된 호스트별 운영 데이터를 제공합니다. 이들은 커널, 하드웨어, 스토리지, 네트워킹, 그리고 ESXi 호스트에서 직접 실행되는 서비스에 대한 상세한 진단 정보를 포함합니다.
- 기본 스토리지: 이 로그는 기본적으로 활성화되어 있으며, ESXi 호스트 자체의
/var/log/
디렉터리 내에 주로 일반 텍스트 파일 모음으로 저장됩니다. 이 스토리지는 종종 로컬 디스크 또는 지속적인 스크래치 파티션입니다. 지속적인 위치가 구성되지 않은 경우, 이 로그들은 일시적이며 재부팅 시 손실되므로, 포렌식을 위해서는 syslog 전달이 필수적입니다.


그림 2: ESXi 표준 로그 구조
- 주요 사용 사례:
- 성능 문제에 대한 심층적인 문제 해
- 하드웨어 오류 또는 드라이버 문제 진단
- 스토리지 및 네트워크 연결 문제 분석
- syslog로 전송되는 ESXi 로그 항목 예시:
(vmkernel.log)
: 스토리지 장치 지연에 대한 상세 로그(hostd.log)
: API 호출, 호스트에서 시작된 VM 상태 변경, 호스트 서비스 활동을 포함한 호스트 에이전트의 로그(auth.log)
: SSH 또는 DCUI를 통해 호스트에 직접 시도된 성공 또는 실패한 로그인 기록
3. ESXi 호스트 감사 로그
ESXi 감사 기록은 ESXi 호스트에서 직접 수행된 작업에 대한 높은 신뢰도의 보안 중심 로그를 제공합니다. 아래 제공된 예시 분석은 왜 이 로그 소스가 보안 조사에서 표준 로그보다 포렌식적으로 더 우수한지를 보여줍니다. 이 로그는 기본적으로 활성화되어 있지 않습니다.
- 기본 스토리지 및 지속성: 이 기록은 호스트의 로컬 파일 시스템에 있는
audit.*.log
파일에 기록되며,Syslog.global.auditRecord.storageEnable = TRUE
매개변수에 의해 관리됩니다. 이 감사 기록이 재부팅 후에도 유지되도록 하려면 지속적인 스토리지 구성이 중요합니다.


그림 3: ESXi 감사 로그 구조
-
포렌식 분석: 표준 로그 vs. 감사 로그: 제공된 시나리오에서 위협 행위자는 ESXi 호스트에 로그인하여 악성코드를 실행하려고 시도하고,
execInstalledOnly
보안 설정을 비활성화합니다. 각 로그 유형이 이 이벤트를 어떻게 기록하는지는 다음과 같습니다. - 표준 syslog
shell.log
분석: T표준 로그는 셸에 입력된 명령어에 대한 간단한 시간순 기록을 제공합니다.


그림 4: ESXi 표준 로그 출력
-
- 제한 사항:
- 로그인 컨텍스트 부재: 위협 행위자의 소스 IP 주소나 초기 SSH 로그인이 성공했는지 여부를 보여주지 않습니다.
- 결과 부재:
./malware
명령이 입력되었음은 보여주지만, 성공했는지 실패했는지에 대한 정보는 제공하지 않습니다. - 불완전한 이야기: 이는 단순한 명령어 기록일 뿐이며, 완전한 보안 조사에 필요한 필수적인 맥락이 부족합니다.
- 제한 사항:
- ESXi 감사 로그 분석: ESXi 감사 로그는 연결부터 종료까지, 그리고 각 명령어의 결과를 포함한 전체 세션에 대해 풍부하고, 구조화되었으며, 검증 가능한 기록을 제공합니다.


그림 5: ESXi 감사 로그 출력
-
- 성공적인 로그인: 소스 IP 주소를 포함하여 성공적인 인증을 명시적으로 기록합니다.
- 악성코드 실행 실패: 이것이 가장 중요한 차이점입니다. 감사 로그는 악성코드 실행이 종료 상태
126
으로 실패했음을 보여줍니다. - 성공적인 보안 기능 비활성화: 이후 핵심 보안 기능을 비활성화하려는 명령이 성공했음을 확인합니다.
이러한 비교는 표준 ESXi 로그가 위협 행위자의 의도를 보여주는 반면, ESXi 감사 로그는 실제 결과를 드러내어 실행 가능한 인텔리전스와 결정적인 포렌식 흔적을 제공한다는 것을 증명합니다. vSphere 환경을 위한 포괄적인 로깅 전략은 세 가지 뚜렷하면서도 상호 보완적인 데이터 소스의 수집 및 분석을 요구합니다. 중앙 syslog 서버로 전달될 때, vCenter 서버 이벤트, ESXi 호스트 감사 기록, 그리고 표준 ESXi 운영 로그는 환경의 보안, 관리 변경 사항, 그리고 운영 상태에 대한 다층적인 관점을 제공합니다.
표 1: ESXi 로그 및 vCenter 이벤트 비교
공격 해부: UNC3944의 공격 전략
UNC3944의 공격은 다섯 가지 뚜렷한 단계를 거쳐, 낮은 수준의 침투에서 하이퍼바이저를 완전히 장악하는 데까지 체계적으로 진행됩니다.


그림 6: 일반적인 UNC3944 공격 체인
1단계: 초기 침투, 정찰 및 권한 상승
이 초기 단계는 인간적 요소를 악용하는 것에 중점을 둡니다.
- 전술: 위협 행위자는 IT 헬프데스크에 전화하여 일반 직원으로 가장하며 접촉을 시작합니다. 이전 데이터 침해로 쉽게 얻을 수 있는 개인 정보를 사용하고 설득력 있거나 위협적인 사회 공학 기술을 동원하여, 상담원과의 관계를 형성하고 직원의 Active Directory(AD) 비밀번호를 재설정하도록 설득합니다. 이 초기 발판을 확보한 후, 그들은 두 갈래의 내부 정찰 임무를 시작합니다.
- 경로 A (정보 저장소): 새로운 접근 권한을 사용하여 내부 SharePoint 사이트, 네트워크 드라이브, 위키를 스캔합니다. 이들은 고가치 표적을 드러내는 IT 문서, 지원 가이드, 조직도, 프로젝트 계획을 찾아다닙니다. 여기에는 개별 도메인 또는 vSphere 관리자의 이름뿐만 아니라, 가상 환경에 대한 관리자 권한을 부여하는 "vSphere Admins" 또는 "ESX Admins"와 같이 명확하게 명명된 강력한 Active Directory 보안 그룹의 발견이 포함됩니다.
- 경로 B (비밀 저장소): 동시에 HashiCorp Vault와 같은 비밀번호 관리자 또는 다른 PAM(Privileged Access Management) 솔루션에 대한 접근을 스캔합니다. 접근 제어가 취약한 곳을 발견하면, 자격 증명을 열거하려고 시도합니다.
특정 고가치 관리자의 이름을 손에 넣은 공격자는 헬프데스크에 추가 전화를 겁니다. 이번에는 특권 사용자를 가장하여 비밀번호 재설정을 요청함으로써 특권 계정에 대한 통제권을 확보합니다.
-
효과적인 이유: 이 2단계 프로세스는 초기 권한 상승을 위해 Kerberoasting과 같은 기술적 해킹의 필요성을 우회합니다. 핵심적인 취약점은 비밀번호 재설정을 위한 강력하고 양도 불가능한 신원 확인 절차가 부족한 헬프데데스크 프로세스입니다. 위협 행위자는 두 번째 전화에서 더 자신감 있고 정보에 정통하여 가장 성공 확률이 훨씬 높아집니다.
-
주요 탐지 신호:
-
[로그] 명령줄 및 프로세스 실행 모니터링: 강력한 명령줄 로깅을 구현합니다(예: 감사 프로세스 생성, Sysmon 이벤트 ID 1 또는 EDR을 통해).
wsmprovhost.exe
(WinRM)가net.exe
와 같은 기본 도구를 실행하여 민감한 그룹(예:net group "ESX Admins" /add
)을 질의하거나 수정하는 등 의심스러운 원격 프로세스 실행에 대한 경고를 생성합니다. -
[로그] 그룹 멤버십 변경 모니터링: "vSphere Admins", "ESX Admins" 또는 유사한 이름의 그룹에 대한 변경에 대해 AD 이벤트 ID 4728(보안 사용 전역 그룹에 구성원이 추가됨) 또는 4732(로컬 그룹)에 대한 높은 우선순위 경고를 생성합니다.
-
[로그] AD 비밀번호 재설정과 헬프데스크 활동 상관관계 분석: AD 이벤트 ID 4724(비밀번호 재설정) 및 이후의 새로운 다중 인증(MFA) 장치 추가를 헬프데스크 티켓 로그 및 통화 기록과 상관관계 분석합니다.
-
[행동] 비정상적인 파일 접근에 대한 경고: UNC3944 활동에서 볼 수 있는 정찰의 강력한 지표인, 단일 사용자가 비정상적으로 많은 수의 이질적인 파일 또는 SharePoint 사이트에 접근하는 것에 대해 경고합니다.
-
[중요 행동] Tier 0 계정 활동 모니터링: Tier 0 계정(도메인 관리자, 엔터프라이즈 관리자, vSphere)에 대한 비밀번호 재설정은 달리 입증될 때까지는 중요 사고로 취급해야 합니다.
-
-
중요한 보안 강화 및 완화:
-
[중요] 특권 계정에 대한 전화 기반 재설정 금지: 모든 Tier 0 계정에 대해 "전화를 통한 비밀번호 재설정 금지" 정책을 엄격하게 시행합니다. 이러한 작업은 대면, 다단계 또는 고신뢰 신원 확인 절차를 요구해야 합니다.
-
특권 AD 그룹 보호 및 모니터링: 이러한 그룹을 Tier 0 자산으로 취급합니다. 누가 멤버십을 수정할 수 있는지 엄격하게 통제하고, 모든 멤버십 변경에 대해 높은 정확도의 경고(AD 이벤트 ID 4728/4732)를 구현합니다. 위협 행위자들이 이 조작을 수행하기 위해 종종 WinRM과 같은 원격 프로토콜을 통해
net.exe
와 같은 기본 도구를 사용하므로 이는 매우 중요합니다. 높은 수준의 권한을 부여하는 보안 그룹에 "vSphere Admins"와 같이 명확하고 모호하지 않은 이름을 사용하는 것을 피해야 합니다. -
정보 저장소 강화: 데이터 유출 방지(DLP) 및 데이터 분류를 구현하여 고가치 표적을 드러낼 수 있는 민감한 IT 문서를 식별하고 잠급니다. 비밀 저장소를 Tier 0 자산으로 취급하고, 엄격한 최소 권한 접근 정책을 적용합니다.
-
원격 관리 도구 제한 또는 모니터링: WinRM 및 vSphere 관리 API와 같은 원격 관리 프로토콜의 사용을 승인된 관리 서브넷 및 전용 PAW로 제한합니다. 모든 원격 명령을 검토 및 이상 탐지를 위해 로깅합니다.
-
표 2는 Active Directory 권한 상승을 지원하는 위협 행위자의 행동과, 조직이 이 활동을 탐지하는 데 사용할 수 있는 프로세스 및 명령줄 데이터를 보여줍니다.
표 2: Active Directory 사용자 권한 상승
2단계: vCenter 피벗 - 제어 영역 침해
vSphere 자격 증명에 매핑된 Active Directory를 확보한 위협 행위자는 이제 가상 환경의 핵심을 노립니다.
- 전술: 그들은 탈취한 자격 증명을 사용하여 vSphere vCenter Server GUI에 로그인합니다. 여기에서 vCenter 관리자 권한을 활용하여 VCSA(vCenter Server Appliance) 자체에 대한 '가상 물리적 접근' 권한을 얻습니다. 원격 콘솔을 열고 어플라이언스를 재부팅한 다음, GRUB 부트로더를 수정하여 루트 셸(
init=/bin/bash
)로 시작하게 함으로써 비밀번호 없이 루트 권한을 얻습니다. 그런 다음 재부팅 시 SSH 접근을 가능하게 하기 위해 루트 비밀번호를 변경합니다. 그들의 발판을 유지하기 위해, 그들은 합법적인 오픈 소스 원격 접근 도구인 teleport를 업로드하고 실행하여, 대부분의 방화벽 송신 규칙을 우회하는 지속적이고 암호화된 리버스 셸(C2 채널)을 생성합니다 - 효과적인 이유: Active Directory에 대한 vCenter의 신뢰 위임은 종종 LDAP(S)를 통해 이루어지며, 이는 초기 로그인이 MFA(다중 인증)로 보호되지 않음을 의미합니다. VCSA 장악은 가상 환경 관리자의 근본적인 권한, 즉 부팅 전에 VM의 콘솔과 상호 작용하는 능력을 악용합니다.
- 주요 탐지 신호:
- [로그] 로그인(
com.vSphere.vc.UserLoginSessionLoginSuccessEvent
) (com.vSphere.vc.UserLoginSessionLoginFailureEvent
) 및 재부팅(com.vSphere.vc.appliance.ApplianceRebootEvent
)에 대한 vCenter 이벤트를 모니터링 합니다. - [로그] 원격 VCSA syslog에서 "SSH"와 같은 접두사가 있는 로그 항목을 모니터링하여,
iptables
를 통해 차단된 SSH 시도 또는 기타 차단된 트래픽을 탐지합니다. - [로그] VCSA에서
journald
를 모니터링하고 로그의 원격 전달을 SIEM에 구현하여 무단 셸 접근 및 SSH와 셸 서비스의 활성화를 탐지합니다.
- [로그] 로그인(


그림 7: VCSA SSH 서비스 활성화에 대한 원격 syslog 이벤트
-
- [네트워크] VCSA의 IP 주소에서 발생하는 비정상적인 아웃바운드 연결을 탐지하기 위해 네트워크 흐름 로그를 사용하세요.
- [네트워크] vCenter의 비정상적인 DNS 요청: 이 탐지는 vSphere vCenter 서버가 알려진 신뢰할 수 있는 사이트(예:
vSphere.com
,ntp.org
또는 내부 도메인)의 명시적 허용 목록에 없는 도메인에 대해 DNS 요청을 할 때 이를 식별합니다 - [로그] cURL 또는 Wget을 사용하여 도구 다운로드: 이 탐지는 중요 서버(vCenter, 도메인 컨트롤러 또는 데이터베이스 서버 등)에서 cURL 또는 Wget과 같은 명령줄 유틸리티를 사용하여 외부 URL에서 파일을 다운로드할 때 이를 식별할 수 있습니다
- 중요한 보안 강화 및 완화:
- [중요] VCSA 원격 로깅 활성화: VCSA 어플라이언스에서 원격 syslog 전달을 구현합니다.
- [중요] vCenter에 피싱에 강한 MFA 적용: 지원되는 ID 공급자와 인증을 연동하여 모든 vCenter 로그인에 FIDO2/WebAuthn과 같은 피싱에 강한 MFA 솔루션을 구현합니다. 이는 자격 증명 탈취 위협을 직접적으로 무력화하여 vCenter 사용자를 대상으로 한 피싱 공격을 비효율적으로 만드는 중요한 통제입니다.
- [중요] vCenter에 최소 권한 원칙 적용: Administrator 역할 사용을 엄격하게 제한하고,
administrator@vsphere.local
과 같은 전용 "비상 탈출(break glass)" 계정에만 사용하도록 합니다. 대신, 특정 직무 기능을 위한 세분화된 맞춤형 역할을 생성하여 사용자와 그룹이 필요한 최소한의 권한만 갖도록 함으로써, 침해된 AD 계정과 vCenter 완전 장악 간의 연결 고리를 끊습니다 - [중요] VCSA 방화벽 사용 및 셸 접근 차단: 이그레스 필터링 및 내장된 방화벽을 사용하여 VCSA에서 나가는 불필요한 인터넷 트래픽을 모두 차단합니다. SSH 및 BASH 셸을 기본적으로 비활성화합니다. 이는
teleport
백도어를 저지하고 VCSA 장악을 상당히 어렵게 만듭니다 - [중요] VCSA의 기본 iptables 방화벽 구성: 모든 관리 인터페이스(443, 5480, 22)에 대해 제로 트러스트 허용 목록을 강제하고, 거부된 모든 연결에 대한 로깅을 활성화합니다. 기본 VCSA GUI 방화벽은 침해된 웹 세션이 있는 공격자에 의해 비활성화될 수 있으며, 결정적으로 차단된 연결 시도를 로깅하지 않습니다. OS 수준에서
iptables
를 구성함으로써, 규칙은 GUI 변조에 영향을 받지 않게 되며, 모든 거부된 연결이 로깅되어 SIEM으로 전달됩니다.
표 3은 teleport 설치를 지원하는 위협 행위자의 행동과, 조직이 이 활동을 탐지하는 데 사용할 수 있는 핵심 증거를 보여줍니다.
표 3: VCSA Teleport 설치
3단계: 하이퍼바이저 탈취 - 오프라인 자격 증명 탈취 및 데이터 유출
이 단계에서 위협 행위자는 vSphere 제어 권한을 활용하여 VM(가상 머신) 내부의 보안 도구 및 EDR(엔드포인트 탐지 및 대응)의 감시를 피해 공격을 수행합니다.
- 전술: 위협 행위자는 vCenter에서 ESXi 호스트에 대한 SSH를 활성화하고 루트 비밀번호를 재설정합니다. 그런 다음, 오프라인 공격을 실행하여 도메인 컨트롤러 VM을 식별하고, 전원을 끈 후 가상 디스크(
.vmdk
)를 분리합니다. 이 디스크는 공격자가 제어하는 방치된 '고아 VM(orphaned VM)'에 보조 드라이브로 연결됩니다. 공격자는 감시되지 않는 이 머신에서 NTDS.dit Active Directory 데이터베이스를 복사합니다. 이후, 원래의 프로세스를 역순으로 실행하여 도메인 컨트롤러의 전원을 다시 켭니다. 탈취한 데이터는 두 단계에 걸쳐 이동됩니다. 먼저 고아 VM에서 침해된 VCSA로sftp
를 사용하여 전송합니다. 그리고 이미 설정된teleport
C2 채널을 통해 VCSA에서 공격자가 통제하는 클라우드 서비스로 유출합니다. - 효과적인 이유: 이 전체 작업은 하이퍼바이저 계층에서 발생하므로, 도메인 컨트롤러의 운영 체제 내에서 실행되는 어떤 EDR이나 보안 에이전트에도 보이지 않습니다. VCSA를 데이터 유출 경로로 사용함으로써 네트워크 분리 규칙까지 우회할 수 있습니다.
표 4는 VM 데이터 유출을 지원하는 위협 행위자의 행동과, 조직이 이 활동을 탐지하는 데 사용할 수 있는 핵심 증거를 보여줍니다.
표 4: 가상 머신 데이터 노출
- 주요 탐지 신호:
- [행동] vSphere UI 정찰 모니터링: 공격자는 공격 전에 vSphere 클라이언트를 탐색하여 대상(예: ACME-DC01 VM)과 스테이징 VM(OLD-APPSRV-01)을 식별합니다. UI 접근 로그 또는 관리자 워크스테이션의 브라우저 기록이 있다면, 의심스러운 탐색 패턴을 후속 재구성 이벤트와 연결하여 매우 이른 경고를 제공할 수 있습니다.
- [로그] 재구성 이벤트 정밀 조사: 익명화된 실제 사례에서 보듯이, 스테이징 VM(예: OLD-APPSRV-01)에 대한
vim.event.VmReconfiguredEvent
에는 구성 세부 정보에 대상 VM 디스크의 파일 경로(예:backing = (fileName = '.../ACME-DC01/ACME-DC01_4.vmdk' ...)
)가 포함됩니다. 이 이벤트 데이터를 파싱하여 중요 자산의 디스크가 비표준 머신에 연결될 때를 탐지하는 높은 우선순위의 경고를 생성하세요. - [로그] 전체 이벤트 시퀀스 상관관계 분석:
VmPoweredOffEvent
로 시작하여 이전에 상세히 설명된VmReconfiguredEvent
, 그리고vmtoolsd.exe
에 의해 시작된 재시작과 결합된VmPoweredOnEvent
및 윈도우 게스트 이벤트(6006: 종료, 6005: 시작)와 같은 지원 이벤트를 상관관계 분석하여 중요 자산에 대한 전체 vCenter 이벤트 시퀀스를 기반으로 높은 신뢰도의 경고를 만들 수 있습니다. - [행동] 긴급 경고 생성: 위협 행위자의 스테이징 VM 타겟이 되기 때문에 "서비스 중지됨" 또는 "고아" 폴더에 위치한 VM에 대한 전원 켜기 또는 재구성 이벤트에 대해 긴급 경고를 생성하세요.
- [로그] ESXi 호스트 변경 모니터링: vCenter 이벤트(
vim.event.HostServiceStartedEvent
)를 통한 SSH 서비스 시작, 방화벽 구성 변경(vim.event.HostFirewallInfoChangedEvent
), 그리고 ESXi 호스트 자체에 대한 직접적인 루트 셸 접근 로그에 대해 경고하세요.
- 중요한 보안 강화 및 완화:
- [중요] vSphere VM 암호화 사용: 모든 Tier 0 가상화 자산을 암호화하세요. 이는 탈취된
.vmdk
파일을 읽을 수 없게 만들어 오프라인 "디스크 교체" 공격에 대한 결정적인 기술적 방어책이 됩니다. - [중요] 엄격한 VM 서비스 중지 프로세스 구현: 오래된 VM은 디스크를 삭제하여 공식적으로 서비스 중지하세요. 데이터스토어에 전원이 꺼진 "고아" VM을 남겨두지 마세요. 이는 위협 행위자에게 이상적인 작업 공간이 됩니다.
- [중요] ESXi 계정 강화: 기본 ESXi 루트 계정을 비활성화하고, 매우 복잡한 비밀번호를 가진 명명된 "비상 탈출(break glass)" 계정을 선호하세요. ESXi 8.0+에서는
esxcli system account set -i vpxuser -s false
를 실행하여 침해된 vCenter 사용자가 ESXi 루트 비밀번호를 변경하는 것을 방지하세요. - [중요] ESXi 원격 감사 로깅 활성화: 원격 ESXi 감사 로깅(
vpxa.log
,hostd.log
,audit_records
)을 SIEM으로 전송하여 호스트 자체에서 발생하는 보안 중심 이벤트에 대한 상세하고 중앙 집중적인 정보를 확보하세요.
- [중요] vSphere VM 암호화 사용: 모든 Tier 0 가상화 자산을 암호화하세요. 이는 탈취된


그림 8: ESXi에 대한 SSH 접근의 원격 syslog 이벤트
4단계: 백업 사보타주 - 안전망 제거
랜섬웨어를 배포하기 전에, 공격자는 표적이 복구할 수 없도록 만듭니다.
- 전술: Active Directory에 대한 완전한 통제권을 활용하여, 공격자는 백업 인프라(예: 가상화된 백업 서버)를 표적으로 삼습니다. 그들은 침해된 도메인 관리자 자격 증명을 재사용하여 RDP를 통해 로그인하거나, 더 은밀하게는 그들이 통제하는 사용자를 AD의 "Veeam Administrators" 보안 그룹에 추가합니다. 일단 접근하면, 그들은 모든 백업 작업, 스냅샷, 그리고 저장소를 삭제합니다.
- 효과적인 이유: 이는 관리자 역할의 계층화 부족(동일한 강력한 계정이 가상화와 백업을 모두 관리하는 경우)과 중요한 AD 보안 그룹의 변경 사항에 대한 불충분한 모니터링 때문에 가능합니다.
- 주요 탐지 신호:
- [경로 A 탐지] 높은 권한을 가진 계정이 백업 서버에 대화형으로 로그인하는 것(Windows 이벤트 ID 4624)을 모니터링합니다.
- [경로 B 탐지] "Veeam Administrators" 그룹에 대한 변경 사항에 대해 AD 로그에서 이벤트 ID 4728("구성원이 보안 사용 전역 그룹에 추가되었습니다")에 대한 긴급 경고를 트리거합니다
- [로그] 백업 애플리케이션 자체의 감사 로그에서 대량 삭제 이벤트를 모니터링합니다.
- 중요한 보안 강화 및 완화:
- [중요] 백업 인프라 격리: Veeam 서버와 그 저장소는 별도의 MFA로 보호된 고도로 제한된 보안 도메인에 있거나, AD에 조인되지 않은 전용 자격 증명을 사용해야 합니다. 이는 위협 행위자가 악용하는 AD 신뢰 관계를 단절시킵니다.
- [중요] 불변(Immutable) 저장소 활용: 이는 백업 삭제에 대한 기술적 방어책입니다. 공격자가 백업 콘솔에 대한 완전한 관리자 접근 권한을 얻더라도, 설정된 기간 동안 백업 데이터를 삭제할 수 없게 만듭니다.
5단계: 암호화 - 하이퍼바이저로부터의 랜섬웨어 공격
표적이 눈이 멀고 안전망이 사라지면, 마지막 단계가 시작됩니다.
- 전술: 위협 행위자는 ESXi 호스트에 대한 SSH 접근을 사용하여 SCP/SFTP를 통해
tmp
와 같이 쓰기 가능한 디렉터리에 맞춤형 랜섬웨어 바이너리를 밀어 넣습니다. 그런 다음, 기본 ESXi 명령줄 도구인vim-cmd
를 사용하여 호스트의 모든 VM을 강제로 전원 차단하는 스크립트를 실행합니다. 마지막으로, 데이터스토어를 스캔하고 모든 VM 파일(.vmdk
,.vmx
등)을 암호화하는 랜섬웨어 바이너리를 실행합니다(로그아웃 후에도 계속 실행되도록 종종nohup
과 함께 사용됨).
표 5는 ESXi 랜섬웨어 실행을 지원하는 위협 행위자의 행동과, 조직이 이 활동을 탐지하는 데 사용할 수 있는 핵심 증거를 보여줍니다.
표 5: ESXi 랜섬웨어 실행
- 왜 효과적인가: ESXi 셸에 대한 루트 접근 권한은 가상 환경에서 가장 높은 수준의 권한입니다. 하이퍼바이저 수준에서 암호화를 실행함으로써, 모든 VM 내부 보안을 우회하고 단일 행동으로 서버를 침해합니다.
- 주요 탐지 신호:
- [네트워크] SSH/SCP를 통해 ESXi 호스트와 주고받는 대용량 파일 전송에 대해 네트워크 흐름 로그를 모니터링합니다.
- [행동] 단일 ESXi 호스트에서 시작된 대량의 VM 전원 끄기 명령에 대한 SIEM 경고는 진행 중인 공격의 높은 신뢰도 지표입니다.
- [로그]
esxcli system settings kernel set -s execInstalledOnly -v FALSE
(공격자가 핵심 방어 기능을 비활성화하려는 시도) 및 대량의vmsvc/power.off
명령 실행에 대해 ESXi 호스트 로그를 모니터링합니다. 이 설정은 재부팅 후에만 적용되므로, 이 경고를 짧은 시간 내에 발생하는 후속 호스트 재부팅과 상관관계 분석합니다.
- 중요한 보안 강화 및 완화:
- [중요] vSphere 잠금 모드 활성화: 이는 페이로드를 푸시하고 실행하는 데 필요한 대화형 SSH 접근을 차단하므로, 이 단계에 대한 주요 예방책입니다.
- [중요]
execInstalledOnly
실행 정책 적용: 이 ESXi 커널 설정은 결정적인 기술적 예방책입니다. 서명되지 않은 바이너리 실행을 차단하여, 공격자의 맞춤형 랜섬웨어 실행 시도를 실패하게 만듭니다. 이 설정을 비활성화할 수 없도록 TPM 2.0 칩을 Secure Boot와 함께 활성화합니다.
3단계 방어: 강화된 전략
1단계: 선제적 보안 강화 (가장 신뢰할 수 있는 방어)
-
중앙 집중식 접근 아키텍처: ESXi 호스트를 Active Directory에 직접 연결하지 마세요. 모든 호스트 접근은 오직 vCenter 역할 및 권한을 통해서만 관리하세요. 이는 공격 표면을 획기적으로 줄입니다.
-
vSphere 잠금 모드 활성화: 이는 ESXi 관리를 제한하고, SSH를 통한 직접 셸 접근을 차단하며, vCenter 외부에서의 변경을 방지하는 중요한 통제 수단입니다.
-
execInstalledOnly
적용: 이 강력한 ESXi 커널 설정은 서명되고 패키지화된 vSphere 설치 번들(VIB)의 일부로 설치되지 않은 바이너리의 실행을 막습니다. 이는 공격자의 맞춤형 랜섬웨어 실행을 직접적으로 차단했을 것입니다. -
vSphere VM 암호화 사용: Tier 0 가상화 자산(도메인 컨트롤러, PKI 등)을 암호화하세요. 이는 탈취된 디스크 파일을 읽을 수 없게 만들어 오프라인 '디스크 교체' 공격에 대한 결정적인 기술적 방어책입니다.
-
엄격한 인프라 위생 관리: 단순히 오래된 VM의 전원을 끄는 데 그치지 마세요. 잠재적인 '스테이징' 머신을 제거하기 위해 디스크를 데이터스토어에서 삭제하거나 분리된 아카이브 스토리지로 이동시키는 엄격한 서비스 중지 프로세스를 구현하세요.
-
자세 관리: 보안 강화는 일회성 작업이 아니라, '구성 이탈'에 맞서 지속적으로 유지해야 하는 보안 상태입니다. UNC3944의 전략은 SSH 활성화나 방화벽 규칙 변경과 같은 이러한 정책 위반을 만드는 데 근본적으로 의존합니다. 이는 vSphere Aria Operations Compliance Pack, Wiz와 같은 전용 하이브리드 클라우드 보안 자세 관리(CSPM) 도구를 통하거나, PowerShell/PowerCLI를 통해 vSphere API를 활용하는 맞춤형 스크립트를 개발하여 환경을 정기적으로 감사함으로써 달성할 수 있습니다.
-
헬프데스크 강화: 특권 계정의 MFA 등록 또는 비밀번호 재설정에는 대면, 다단계 또는 고신뢰 다중 요소 확인 절차를 의무화하세요.
2단계: ID 및 아키텍처 무결성 (공격 사슬 끊기)
-
모든 곳에 피싱 방지 MFA 적용: VPN, vCenter 로그인, 모든 특권 AD 계정에 적용해야 합니다. 가상 센터에 대한 독점적이고 방화벽으로 보호된 접근 권한을 가진 강화된 PAW(Privileged Access Workstation)를 사용하세요.
-
중요 ID 인프라 격리: Tier 0 자산(도메인 컨트롤러, PAM, Veeam 등)을 일반적인 워크로드와 분리된, 자체적인 엄격한 접근 정책을 가진 전용의 고도로 보안된 'ID 클러스터'에서 실행하세요.
-
인증 루프 방지: 인증 제공자(AD), 복구 시스템(Veeam) 또는 특권 접근 관리(PAM)를 이들이 보호하고 인증하는 바로 그 가상화 플랫폼에 호스팅하는 것은 치명적인 아키텍처적 결함입니다. 기반 ESXi 호스트가 침해되면, 종속 서비스와 이를 복원하는 수단 모두의 연관된 실패를 초래하여 재해 복구를 상당히 복잡하게 만들거나 불가능하게 만들 수 있습니다.
-
대체 ID 제공자(IdP) 고려: 'AD-만능'의 연결 고리를 끊기 위해, 인프라 인증을 위해 Azure Entra ID와 같은 별도의 클라우드 네이티브 IdP를 사용하는 것을 고려하세요.
3단계: 고급 탐지 및 복구 (최후의 안전망)
-
보안 강화 후 탐지 구축: 가장 효과적인 경고는 구축한 보안 강화 통제 수단을 조작하려는 시도를 탐지하는 것입니다. 먼저 보안을 강화한 다음, 탐지 로직을 구축하세요.
-
핵심 로그 중앙 집중화 및 모니터링: AD, vCenter, ESXi, 네트워킹 인프라, 방화벽, 백업의 모든 로그를 SIEM으로 전달하세요. 이러한 이질적인 소스들의 로그를 상관관계 분석하여 공격자의 체계적인 움직임을 포착할 수 있는 높은 신뢰도의 탐지 시나리오를 만드세요.
-
높은 신뢰도의 경고에 집중: 1~3단계의 이벤트에 대한 경고를 우선시하세요. 호스트에 대한 SSH 활성화, VCSA 장악, 또는 'Veeam Admins' 그룹의 멤버십 변경을 탐지하면 데이터 유출 및 랜섬웨어 배포 이전에 조치를 취할 수 있습니다.
-
생존을 위한 아키텍처 설계: 최악의 시나리오를 가정하세요. 불변성과 에어갭이 있는 백업은 최후의 방어선입니다. 이들은 프로덕션 AD와 격리되어야 하며, 침해된 관리자가 접근할 수 없어야 합니다. 이 특정 위협 모델에 대해 복구 계획을 테스트하여 작동하는지 확인하세요.
결론: 방어자의 의무 - 강화하고 경고하라
UNC3944의 공격 전략은 EDR 기반의 위협 헌팅에서 선제적이고 인프라 중심적인 방어로의 근본적인 전환을 요구합니다. 이 위협은 속도와 은밀성이라는 두 가지 면에서 전통적인 윈도우 랜섬웨어와 다릅니다. 전통적인 공격자는 정찰을 위해 며칠 또는 몇 주를 머무르지만, UNC3944는 극도의 속도로 운영됩니다. 초기 접근부터 데이터 유출, 최종 랜섬웨어 배포까지의 전체 공격 사슬이 단 몇 시간 만에 발생할 수 있습니다. 이러한 속도와 최소한의 포렌식 증거의 조합은 의심스러운 행동 패턴이 본격적인 침해로 확대되기 전에 이를 식별하고 즉시 차단하는 것을 필수적으로 만듭니다.
이러한 Living-off-the-land (LotL) 접근 방식이 매우 효과적인 이유는 vCenter Appliance와 ESXi 하이퍼바이저가 전통적인 EDR 에이전트를 실행할 수 없어 가상화 계층에 중대한 가시성 격차가 생기기 때문입니다. 결과적으로, SIEM 내의 정교한 탐지 설계가 능동적인 방어를 위한 주요하고 가장 필수적인 방법이 됩니다.
이러한 현실은 방어자에게 가장 중요한 핵심을 제시합니다. 즉, 초기 경고를 탐지하고 조치를 취하는 능력이 가장 중요합니다. 최종 랜섬웨어 실행 중에 생성된 경고는 성공적인 장악에 대한 단순한 알림일 뿐입니다. 이와 대조적으로, 공격자가 처음 헬프데스크 계정을 침해하거나 비정상적인 위치에서 vCenter에 접근할 때 트리거되는 경고는 조사에 대한 실행 가능한 출발점이며, 공격자가 완전한 관리자 제어권을 획득하기 전에 위협을 제거할 수 있는 결정적인 기회의 창입니다.
따라서, 탄력적인 방어는 광범위하고 시끄러운 경고의 바다를 헤매는 것에 의존할 수 없습니다. 이러한 반응적 접근은 종종 많은 vSphere 환경이 지나치게 관대한 역할이나 활성화된 SSH와 같은 불안전한 기본 설정에 기반하고, ESXi 호스트 및 vCenter로부터의 중앙 집중식 로깅 가시성 부족으로 어려움을 겪을 때 특히 비효율적입니다. 이러한 시스템들의 적절한 맥락이 없다면, 보안팀은 위협 행위자의 체계적인 LotL 움직임에 대해 너무 늦을 때까지 눈이 멀게 됩니다.
대신, 전략은 두 가지로 구성되어야 합니다. 첫째, 근본적인 격차를 체계적으로 수정하고 공격 표면을 줄이기 위한 선제적이고 심층 방어적인 기술 강화가 필요합니다. 둘째, 이 강화는 위협 행위자의 TTP(전술, 기술 및 절차)에 대한 깊은 분석으로 보완되어, 그들의 가장 초기 움직임을 포착하는 데 필요한 높은 신뢰도의 상관관계 규칙과 로깅 인프라를 구축해야 합니다. 이는 단일 이벤트 경고를 넘어, 헬프데스크 티켓, Active Directory의 비밀번호 재설정, 그리고 vCenter에 대한 후속 비정상적인 로그인 사이의 점을 연결하는 규칙을 만드는 것을 의미합니다.
이 두 전략은 상호 보완적이며, 방어가 탐지를 가능하게 하는 시스템을 만듭니다. 견고한 보안 강화는 단순히 장벽이 아닙니다. 이는 또한 위협 행위자에게 마찰을 일으켜 본질적으로 의심스러운 행동을 시도하도록 강제합니다. 예를 들어, 잠금 모드가 활성화된 경우(강화), 공격자가 ESXi 호스트에 대한 SSH 세션을 열려고 시도하면 실패하지만, 이는 또한 특정하고 높은 우선순위의 이벤트를 생성할 것입니다. 통제 자체가 제대로 구성된 SIEM이 포착하도록 구축된 깨끗한 신호를 생성하는 것입니다.
vSphere에 대한 중요한 의존성을 가진 모든 조직에게, 이것은 이론적인 훈련이 아닙니다. 이 위협이 유난히 위험한 이유는 전체 보안 전략을 무력화시킬 수 있는 능력 때문입니다. 이는 모든 가상화된 Tier 0 자산(도메인 컨트롤러, 인증 기관, PAM 솔루션 포함)을 호스팅하는 기반 하이퍼바이저를 공격함으로써 전통적인 계층화 모델을 우회하고, 계층화의 논리적 분리를 완전히 비효율적으로 만듭니다. 동시에, VM이 오프라인 상태일 때 가상 디스크를 조작함으로써, EDR, 백신(AV), DLP, 호스트 기반 침입 방지 시스템(HIPS)과 같은 VM 내부 보안 솔루션들을 전복시킵니다. 왜냐하면 이들의 에이전트는 ESXi 수준의 직접적인 변경을 모니터링할 수 없기 때문입니다.
위협은 즉각적이며, 공격 사슬은 검증되었습니다. Mandiant는 UNC3944와 같은 그룹이 활용한 성공적인 하이퍼바이저 수준 전술이 더 이상 독점적이지 않다는 것을 관찰했습니다. 이와 동일한 TTP들이 이제 다른 랜섬웨어 그룹들에 의해 적극적으로 채택되고 있습니다. 이러한 확산은 전문화된 위협을 주류 공격 벡터로 바꾸고 있으며, 지금이 바로 행동해야 할 때입니다.