편리함을 넘어: VMware vSphere Active Directory 통합의 위험성 탐구

해당 블로그의 원문은 2025년 7월 24일 Google Cloud 블로그(영문)에 게재되었습니다. 

작성자: Stuart Carrera, Brian Meyer

요약

브로드컴의 VMware vSphere는 프라이빗 클라우드 가상화를 위한 인기 있는 선택으로, 중요한 인프라를 뒷받침하고 있습니다. 이 솔루션은 사라지기는커녕, 기업들이 안정성과 제어를 위해 계속해서 크게 의존하고 있습니다. 또한, 바이모달 IT(bimodal IT)와 더 많은 운영적 감독 요구와 같은 전략의 영향을 받아 중요한 워크로드가 퍼블릭 클라우드 서비스에서 온프레미스 vSphere 환경으로 다시 이전되는 뚜렷한 추세도 보입니다.

vSphere를 Microsoft Active Directory(AD)와 직접 통합하는 일반적인 관행은 관리 작업을 단순화하지만, 오늘날 존재하는 내재된 위험에 대한 오해로 인해 종종 과소평가되는 공격 경로를 만듭니다. 이 구성은 AD 공격 표면을 하이퍼바이저에 직접 확장시킵니다. 위협 행위자의 관점에서 볼 때, 이 통합은 높은 가치를 지닌 기회입니다. 이는 상대적으로 흔한 AD 자격 증명 침해를 잠재적인 고가치 시나리오로 전환시키며, 서버를 호스팅하는 기본 인프라에 대한 접근을 허용하고, 결과적으로 ESXi 호스트와 vCenter에 대한 특권 관리 제어권을 획득하여 궁극적으로 가상화된 인프라를 완전히 장악하게 합니다.

ESXi 호스트와 vCenter Server를 모두 포함하는 vSphere 인프라를 겨냥한 랜섬웨어는 즉각적이고 광범위한 인프라 마비를 일으킬 수 있는 능력 때문에 특히 심각한 위험을 초래합니다. Mandiant가 대다수의 조직에서 실행되고 있다고 관찰한 vSphere 7.x 버전에 대한 일반 지원이 2025년 10월에 종료됨에 따라, 표적형 랜섬웨어의 위협이 시급해졌습니다. 이러한 공격으로부터 복구하는 데 상당한 시간과 자원이 필요하므로, 선제적인 방어가 가장 중요합니다. 따라서 조직이 이러한 핵심 구성 요소에 대한 특정 위협을 이해하고, 특히 지원 종료로 인해 추가적인 위험이 발생하기 전에, 침해를 방지하기 위한 효과적이고 통합된 대응책을 구현하는 것이 중요합니다.

이 블로그 게시물은 vSphere를 Microsoft AD와 통합할 때 발생하는 내재된 위험과 오해를 논리적으로 분석할 것입니다. Mandiant의 vSphere 랜섬웨어 사건 및 AD와 vSphere에 대한 선제적 평가 경험을 바탕으로, 기업 vSphere 관리와 관련하여 오늘날의 위협에 맞춰 위험을 이해하고 보안 태세를 높이기 위한 지침을 제공할 것입니다.

위험에 대해 알아본 후, 다음 블로그 게시물에서는 VMware vSphere 자산을 방어하는 방법에 대한 실행 가능한 지침을 담고 있습니다. 또한, Mandiant 전문가들로부터 이러한 전략을 직접 배우기 위한 웹 세미나에 등록하세요.

vSphere 인프라 개요

vSphere 환경의 보안 위험을 이해하려면, 그 아키텍처를 이해하는 것이 필수적입니다. 한 계층에서의 침해는 전체 가상화 환경에 연쇄적인 영향을 미칠 수 있습니다.

• ESXi (하이퍼바이저): ESXi는 vSphere의 기반 계층입니다. ESXi는 베어 메탈 하이퍼바이저로, 별도의 운영 체제 없이 물리적 서버 하드웨어에 직접 설치됩니다. 핵심 역할은 해당 서버를 여러 개의 격리된 가상 머신(VM)으로 분할하는 것입니다. VM은 본질적으로 파일 모음이며, 각각 독립적인 컴퓨터처럼 자체 운영 체제와 애플리케이션을 실행합니다. 하이퍼바이저의 최소화된 설계는 자체 공격 표면을 줄이면서 서버 리소스를 효율적으로 관리하기 위한 의도적인 접근입니다.

• vCenter (제어 영역): ESXi 호스트가 '작업자'라면, vCenter Server는 전체 환경의 '두뇌' 또는 제어 영역입니다. 이는 모든 연결된 ESXi 호스트와 그들이 실행하는 VM을 관리하기 위한 단일 웹 기반 인터페이스를 제공합니다. ESXi 호스트는 vCenter에 등록되며, vCenter는 각 호스트의 에이전트를 사용하여 작업을 관리하고 자동화된 워크로드 분산 및 고가용성(High Availability)과 같은 고급 기능을 활성화합니다.

vSphere와 AD를 통합하면 ID 관리를 간소화하는 유연한 환경을 만들 수 있지만, 이는 동시에 심각한 보안 위험을 초래합니다. 이 직접적인 연결은 AD 침해를 전체 vSphere 배포에 대한 중대한 위협으로 전환시킬 수 있습니다. 

오래된 청사진: vSphere의 근본적인 보안 재검토

가상화는 거의 20년 동안 엔터프라이즈 IT의 초석이었으며, 서버 확산 문제를 해결하고 혁신적인 운영 민첩성을 제공했습니다. 이와 함께 AD는 엔터프라이즈 IT의 핵심 기둥으로 남아 있습니다. 이로 인해 vSphere와 같은 중요 인프라를 포함한 모든 엔터프라이즈 기술이 중앙 집중식 인증을 위해 AD와 통합되어야 한다는 오랜 지침이 이어졌습니다. 그 결과, 위험한 종속성이 생겨났습니다. 이제 기반 인프라의 보안이 AD의 보안에 직접적으로 연결되어, AD 내의 어떤 침해도 전체 가상화 환경에 대한 직접적인 위협이 됩니다.

과거에는 vSphere 보안이 종종 뚜렷하게 분리된 계층으로 접근되었습니다. 경계 보안은 엄격했으며, 위협은 외부 공격자보다는 구성 오류와 같은 내부적인 것으로 주로 간주되었습니다. 이는 이미지 기반 백업의 편리함과 결합되어, 보안 노력이 선제적인 방어보다는 주로 견고한 비즈니스 연속성 및 재해 복구 기능에 초점을 맞추게 만들었습니다. 환경이 확장됨에 따라 로컬 사용자 계정을 관리하는 데 상당한 관리 오버헤드가 발생하여, 중앙 집중식 ID 관리를 위해 AD 통합 지원이 도입되었습니다.

광범위한 사고 대응 경험을 바탕으로 한 Mandiant의 관찰에 따르면, 오늘날 많은 vSphere 환경은 여전히 이러한 근본적인 아키텍처 위에서 운영되며, 진화하는 위협 환경을 따라잡지 못하는 보안 가정을 그대로 유지하고 있습니다. Mandiant의 평가가 자주 확인하듯이, 이러한 아키텍처는 오늘날의 위협에 기반한 보안 설계보다는 기능성과 안정성을 우선시합니다.

결과적으로, 대부분의 조직은 보안 노력과 EDR 배포를 게스트 운영 체제 내부에 집중합니다. 이는 전체 가상화 환경의 기반인 ESXi 하이퍼바이저를 보안팀의 중대한 사각지대로 남겨둡니다.

vSphere 위협 환경

이전 섹션에서 상세히 설명한 하이퍼바이저 계층의 보안 공백은 공격자들의 눈에 띄지 않았을 리 없습니다. EDR 솔루션으로 윈도우 기반 운영 체제의 보안이 성숙해지자, 공격자들은 더 취약하고 가치가 높은 표적인 ESXi 하이퍼바이저 자체로 피벗했습니다.

이러한 피벗은 일반적인 운영 현실에 의해 더욱 심화됩니다. ESXi 호스트의 중요한 역할 때문에 운영 중단에 대한 두려움으로 패치를 신속하게 적용하는 것에 주저하게 됩니다. 많은 조직이 위험을 완화할 수 있는 시간이 빠르게 줄어들고 있습니다. 그러나 공격자들은 단순히 패치되지 않은 취약점에만 의존하는 것이 아닙니다. 그들은 종종 탈취한 자격 증명, MFA(다중 인증)의 부재, 그리고 간단한 잘못된 구성을 활용하여 접근 권한을 얻습니다.

하이퍼바이저 인식 랜섬웨어의 부상

vSphere를 표적으로 하는 랜섬웨어는 근본적으로 전통적인 윈도우 랜섬웨어보다 훨씬 더 파괴적입니다. 서버나 최종 사용자 컴퓨터의 파일을 암호화하는 대신, 이러한 공격은 가상 디스크 파일(VMDK)을 암호화하여 수십 개의 VM을 한 번에 마비시킴으로써 전체 인프라를 무력화시키는 것을 목표로 합니다.

이는 이론적인 위협이 아닙니다. 구글 위협 인텔리전스 그룹(GTIG)에 따르면, vSphere에 대한 공격은 빠르게 증가하고 있습니다. 관찰된 새로운 랜섬웨어 계열 중 vSphere ESXi 시스템을 위해 특별히 맞춤 제작된 랜섬웨어의 비율은 2022년 약 2%에서 2024년에는 10% 이상으로 증가했습니다. 이는 공격자들이 하이퍼바이저를 구체적으로 표적으로 하는 도구를 구축하는 데 자원을 적극적으로 할애하고 있음을 보여주는 분명하고 가속화되는 추세입니다. GTIG가 조사한 사건에서 공격자들은 가장 빈번하게 REDBIKE, RANSOMHUB, 그리고 LOCKBIT.BLACK 변종을 배포했습니다.

GTIG 분석가들은 위협 행위자들이 vCenter에 배포된 리버스 셸을 통해 vSphere 환경에 지속성을 확보하는 최근 추세에 주목했습니다. 이를 통해 vSphere 제어 영역 내에 발판을 마련하고 모든 인프라에 대한 완전한 통제권을 얻을 수 있습니다. 이는 일반적으로 두 갈래의 접근 방식으로 나타납니다. Active Directory 데이터베이스(NTDS.dit)와 같은 전술적 데이터 유출, 그리고 랜섬웨어 배포 및 모든 VM의 대량 암호화입니다.

vSphere Active Directory 통합 이해하기

vSphere를 AD와 통합하기로 결정할 때, 이 연결이 실제로 어떻게 작동하는지에 대한 구체적인 부분을 간과하는 경우가 많습니다. 위험을 제대로 평가하려면, 이 기능을 가능하게 하는 기술적 구성 요소들을 심층적으로 살펴보아야 합니다. 이 분석은 인증을 담당하는 레거시 에이전트, 다중 인증(MFA)과 같은 최신 보안 제어를 지원하지 못하는 본질적인 한계, 그리고 에이전트가 설정하는 안전하지 않은 기본 신뢰 관계와 같은 핵심 부분을 해체할 것입니다. 이러한 근본적인 메커니즘을 검토함으로써, 자격 증명 침해로부터 인프라 장악으로 이어지는 직접적인 경로를 노출할 수 있습니다.

vSphere의 Likewise 에이전트

vSphere의 AD 통합을 논할 때, 두 개의 별도 구성 요소인 vCenter Server와 ESXi 호스트를 구분하는 것이 중요합니다. 이들의 AD 통합 옵션은 독립적이며 다른 기능을 가지고 있습니다. 이 연결은 전적으로 Likewise 에이전트에 의해 수행됩니다.

Likewise 에이전트는 원래 Likewise Software에 의해 리눅스 및 유닉스 기반 시스템이 AD 환경에 조인하여 Kerberos, NTLM, LDAP/(S)와 같은 표준 프로토콜을 사용하여 중앙 집중식 ID 관리를 할 수 있도록 개발되었습니다. 오픈 소스 에디션인 Likewise Open에는 domainjoin-cli와 lsassd와 같은 시스템 데몬이 포함되어 있으며, 이는 여전히 ESXi와 vCenter Server Appliance(VCSA) 내부에서 발견됩니다. vSphere는 통합 Windows 인증(IWA)을 용이하게 하기 위해 ESX 4.1(2010년 출시)부터 이 에이전트를 내장했습니다. 그러나 그 기능은 다릅니다.

• ESXi에서는 Likewise 에이전트가 구성될 때 AD 사용자 인증을 적극적으로 처리합니다.

• vCenter에서는 통합 Windows 인증(IWA)이 ID 소스로 선택될 때 초기 도메인 조인에만 사용되며, 모든 실제 인증은 vCenter Single Sign On(SSO) 서브시스템에 의해 처리됩니다.

다음 표는 vCenter와 ESXi의 기본 Active Directory 연결 방법을 비교한 것입니다.

Likewise 기반 AD 통합(ESXi/vCenter)을 사용해서는 안 되는 이유

vSphere Likewise 에이전트를 통해 Active Directory(AD) 기반 연결을 사용할 때 다음과 같은 문제점들을 고려해야 합니다.

• 더 이상 지원되지 않는 소프트웨어: Likewise는 레거시 소프트웨어로, 더 이상 유지보수되거나 지원되지 않습니다.

• 최신 인증 미지원: Likewise는 통합 Windows 인증(Kerberos)만 지원하며, SAML, OIDC, FIDO2와 같은 최신 인증 프로토콜을 지원하지 않습니다.

• MFA 미지원: Likewise는 MFA(다중 인증), 지리적 위치 제한 또는 시간 기반 접근과 같은 상황별 정책을 적용할 수 없습니다.

• 로컬에 저장되는 자격 증명 자료: Kerberos keytab 및 캐시된 자격 증명은 암호화되지 않은 상태로 디스크에 저장됩니다.

VMware는 레거시 Likewise 기반 스택의 한계를 우회하기 위해 최신 ID 제공업체와의 ID 연합(identity federation)을 활용할 것을 권장합니다. 브로드컴은 3월 25일, 통합 Windows 인증(IWA)이 다음 주요 릴리스에서 제거될 것이라고 발표했습니다.

MFA의 간극

AD 통합은 관리 편의성을 제공하지만, 특히 MFA와 관련하여 심각한 보안적 한계를 초래합니다. Kerberos 및 NTLM을 포함한 전통적인 AD 인증 방식은 본질적으로 단일 요소 인증입니다. 이러한 프로토콜은 MFA를 기본적으로 지원하지 않으며, vCenter Likewise 통합은 AD MFA 적용을 vCenter나 ESXi로 확장하지 않습니다. 

결정적으로, ESXi는 어떤 형태의 MFA도 지원하지 않으며, ID 연합, SAML, 또는 OIDC, FIDO2와 같은 최신 프로토콜도 지원하지 않습니다. vCenter의 경우에도 MFA는 vSphere.local 도메인 내의 사용자에게만 적용될 수 있으며(RSA SecurID 또는 RADIUS와 같은 메커니즘 사용), IWA 또는 LDAP/S를 통해 인증된 AD 조인 사용자에게는 적용할 수 없습니다.

VMware vSphere에서 Active Directory Federation Services(ADFS)를 통해 MFA를 적용하는 것이 기술적으로 가능하지만, 이 접근 방식은 신중한 고려가 필요합니다. ADFS는 여전히 Windows Server 2025에 포함된 기능이며, 공식적인 사용 중단 목록에 있거나 지원 종료일이 정해진 것은 아닙니다. 그러나 Microsoft Entra ID의 빠른 혁신에 비해 새로운 기능 개발이 미미하다는 점은 ADFS가 레거시 기술임을 보여줍니다. 마이크로소프트가 ADFS에서 Entra ID로 애플리케이션을 마이그레이션하기 위해 광범위한 자료를 제공하는 점도 이를 뒷받침합니다.

따라서 ADFS가 여전히 지원되는 기능임에도 불구하고, vSphere 보안을 위한 복잡한 우회책이며 ESXi 직접 접근에는 적용되지 않습니다. 또한, 마이크로소프트가 현대적인 클라우드 기반 ID 솔루션으로 나아가려는 명확한 전략적 방향과도 상반됩니다.

또 다른 일반적인 접근 방식은 **Privileged Access Management(PAM)**를 활용하는 것입니다. PAM 중심의 전략은 중앙 집중식 제어 및 세션 감사와 같은 이점을 제공하지만, 몇 가지 주의할 점이 있습니다. PAM 시스템은 운영 복잡성을 더하며, vCenter 세션 자체는 일반적으로 주요 엔터프라이즈 ID 제공자(Entra ID 또는 Okta 등)와 직접 연동되지 않습니다. 결과적으로, 상황 인식 조건부 접근 정책은 vCenter 세션 내에서가 아니라 초기 PAM 로그인 시에만 적용되는 경우가 많습니다.

2024년 7월, 마이크로소프트는 "ESXi 취약점"으로 간주되었던 치명적인 문제인 CVE-2024-37085에 대한 블로그 게시물을 발표했고, vSphere는 즉시 패치를 배포하여 이 문제를 해결했습니다. 수년 동안 vSphere ESXi에 존재했던 이 CVE는 여러 ESXi 고급 설정이 안전하지 않은 기본 구성을 사용하면서 발생했습니다. ESXi 호스트를 AD(Active Directory) 도메인에 연결하면, "ESX Admins" AD 그룹에 자동으로 ESXi 관리자 역할이 부여되어 의도된 사용자 외에 관리 접근 범위가 확장될 수 있었습니다.

이러한 설정은 다음 ESXi 컨트롤에 의해 구성됩니다.

1. Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd
   • 기능: 지정된 관리자 그룹의 사용자가 호스트의 로컬 관리 그룹에 자동으로 추가될지 여부를 제어합니다.
2. Config.HostAgent.plugins.vimsvc.authValidateInterval
   • 기능: 호스트의 관리 서비스가 연결된 클라이언트의 인증 자격 증명(또는 티켓)을 검증하는 시간 간격을 정의합니다.
3. Config.HostAgent.plugins.hostsvc.esxAdminsGroup
   • 기능: 어떤 그룹의 구성원이 자동으로 호스트 관리 권한을 부여받을지(첫 번째 설정에 의해 자동 추가가 활성화된 경우) 그룹의 이름(또는 식별자)을 지정하는 매개변수입니다.

ESXi 호스트를 Microsoft AD와 통합하면 종종 간과되는 근본적인 보안 문제가 발생합니다. 바로 IdP(ID 제공자)의 관리자가 ESXi 호스트와 신뢰 관계에 있는 다른 모든 시스템에 대한 관리 제어권을 효과적으로 획득하게 된다는 것입니다. 보안 취약점이 엔드포인트 자체에 있다는 일반적인 인식과는 달리, 더 심각한 문제는 신뢰할 수 있는 ID 제공자의 관리자가 행사하는 광범위한 암묵적 관리 권한입니다. 특히 AD 인증을 ESXi와 함께 사용할 때, 이 문제는 ESXi 호스트 자체의 취약성보다 훨씬 더 중요한 보안 위협이 됩니다.

결과적으로, 기본 설정만 조정하는 우회책이나 구성 수정으로는 ESXi 호스트가 AD에 조인될 때 발생하는 이 핵심적인 문제를 해결할 수 없습니다. 이 문제는 특정 CVE를 초월합니다. 이는 ESXi와 AD와 같이 이미 자체적인 보안 취약점을 가지고 있으며 공격자들의 빈번한 표적이 되는 시스템과 관련된 암묵적 신뢰 모델 자체의 내재된 보안 영향에서 비롯됩니다.

ESXi와 관련하여 다음 사항들이 고려되어야 합니다.

• 자동으로 완전한 관리자 접근 권한 부여: ESXi 호스트가 AD에 조인되면, 기본(또는 맞춤 구성된) AD 그룹(예: "ESX Admins")에 ESXi 호스트에 대한 완전한 루트 수준 관리자 권한이 부여됩니다. 이 AD 그룹의 모든 구성원은 즉시 ESXi 호스트에 대한 무제한적인 통제권을 얻습니다.
• 그룹 이름: AD가 침해되면, 공격자는 Config.HostAgent.plugins.hostsvc.esxAdminsGroup 고급 설정을 통해 사용되는 그룹 이름을 조작할 수 있습니다. 이는 "ESX Admins" 그룹 이름에 국한되지 않습니다.
• 보안 식별자(SID) 추적 부족: ESXi에 추가된 AD 그룹 이름은 SID로 추적되지 않습니다. 이는 공격자가 "ESX Admins"와 같은 삭제된 AD 그룹의 이름을 바꾸거나 다시 생성하여 Config.HostAgent.plugins.hostsvc.esxAdminsGroup을 통해 ESXi에서 동일한 이름을 유지하고 권한을 유지할 수 있음을 의미합니다. 이는 Likewise ESXi 에이전트의 한계입니다.
• Active Directory 그룹 관리: 도메인에 조인된 ESXi 호스트에 접근하려는 모든 공격자는 Config.HostAgent.plugins.hostsvc.esxAdminsGroup을 통해 정의된 AD 그룹에 자신을 추가할 수 있는 충분한 권한만 있으면 됩니다.

CVE-2024-37085와 같은 취약점을 둘러싼 최근 논의는 이 보안 문제를 전면에 내세웠습니다. 즉, vSphere ESXi 호스트를 AD 도메인에 직접 조인하는 것에 내재된 위험성입니다. 이러한 통합이 관리 편의성을 제공하는 것으로 인식되지만, 이는 쉽게 악용될 수 있는 수준의 신뢰를 구축합니다.

ESXi 호스트를 Active Directory 도메인에 조인해서는 안 되는 이유

이전 논의를 바탕으로 우리는 ESXi 호스트를 AD에 조인하는 것이 상당한 위험을 초래한다는 것을 확신할 수 있습니다. 이는 Secure Boot, TPM, execInstalledOnly, vCenter 통합, 포괄적인 로깅 및 SIEM 통합과 같은 ESXi 보안 제어가 부재할 때 더욱 강화됩니다. ESXi에 조인된 그룹에 연결된 침해된 AD 자격 증명은 원격 공격자가 권한을 쉽게 악용하여 가상 머신 종료 및 SSH를 통한 랜섬웨어 배포와 같은 작업을 수행하도록 허용합니다. 이러한 위험은 다음과 같이 요약할 수 있습니다.

• • MFA 미지원: ESXi는 AD 사용자에 대한 MFA를 지원하지 않습니다. 도메인 조인은 중요한 하이퍼바이저 접근을 단일 요소 비밀번호 기반 인증에 노출시킵니다.

  • 레거시 인증 프로토콜: ESXi는 IWA 및 Kerberos / NTLM / Windows 세션 인증(SSPI)에 의존합니다. 이는 pass-the-hash 및 자격 증명 릴레이를 포함한 다양한 공격에 취약한 시대에 뒤떨어진 프로토콜입니다.

  • Likewise 에이전트의 지원 중단: 기반이 되는 Likewise 에이전트는 중단된 오픈 소스 프로젝트입니다. 이에 계속 의존하는 것은 유지보수 및 보안 위험을 초래합니다.

  • 최신 인증 통합 부재: ESXi는 연합 ID, SAML, OIDC, FIDO2 또는 조건부 접근을 지원하지 않습니다.

  • AD 정책 적용 부재: GPO(그룹 정책 객체), 조건부 접근, 로그인 시간 제한은 AD 조인을 통해 ESXi로 확장되지 않아 중앙 집중식 보안 제어를 약화시킵니다.

  • 이점 없는 복잡성: 도메인 조인은 의미 있는 보안 이점 없이 관리 오버헤드를 추가합니다. 특히 vCenter를 주요 접근 지점으로 사용할 때 더욱 그렇습니다.

  • 제한된 역할 매핑 세분성: ESXi의 그룹 기반 역할 매핑은 기본적이며 vCenter에서 사용할 수 있는 RBAC의 정밀도를 따라갈 수 없어 접근 제어의 정확도를 떨어뜨립니다.

vSphere Virtual Center — 주요 공격 대상

VMware vCenter Server는 가상화 인프라의 중앙 집중식 관리자 역할을 하므로, 공격자에게 전략적인 목표물이 됩니다. vCenter가 침해당하면 모든 연결된 ESXi 하이퍼바이저, 가상 머신, 데이터스토어 및 가상 네트워크 구성에 대한 포괄적인 관리 제어권을 넘겨주게 됩니다.

광범위한 API를 통해 공격자는 관리되는 모든 ESXi 호스트와 가상 머신을 프로그래밍 방식으로 조작할 수 있습니다. 이를 통해 대량의 랜섬웨어를 배포하고, 데이터를 대규모로 유출하며, 악성 가상 자산을 프로비저닝하거나, 보안 태세를 변경하여 탐지를 회피하고 광범위한 운영 중단을 유발할 수 있습니다.

게다가, vCenter Server 어플라이언스 자체에 지속적인 백도어를 심어 은밀한 명령 및 제어(C2) 채널을 구축함으로써, 확고한 지속성과 악성 운영을 계속할 수 있습니다. 결과적으로, vCenter의 중요한 기능은 이를 고가치 목표물로 만듭니다. 다음 사항을 고려해야 합니다.

• 결합된 보안 종속성 (침해 증폭 위험): vCenter를 AD에 직접 연결하면 vSphere 보안이 AD의 무결성에 의존하게 됩니다. AD는 주요 목표물이므로, vCenter에 매핑된 특권 AD 계정이 침해되면, vSphere 특정 보안 계층을 우회하고 가상 인프라에 대한 즉각적이고 잠재적으로 무제한적인 관리 접근 권한을 부여하게 됩니다. vSphere에서 AD 계정에 대한 최소 권한 원칙을 불충분하게 적용하면 이 위험이 증폭됩니다.

• 단일 요소 인증의 취약점 (자격 증명 침해 위험): 오직 AD 비밀번호 검증에만 의존하는 것은 vCenter를 일반적인 자격 증명 침해 방법(피싱, 무차별 대입 공격, 비밀번호 분사, 자격 증명 스터핑, 악성코드)에 매우 취약하게 만듭니다. 필수적인 MFA가 없으면, 특권 AD 계정의 단일 비밀번호가 도난당했을 때 완전한 인증 우회가 가능해져 무단 접근, 데이터 유출, 랜섬웨어 또는 주요 운영 중단을 초래할 수 있습니다.

• 기본 MFA 부재: vSphere.local에서 AD로의 직접적인 통합은 피싱에 강한 FIDO2와 같은 강력한 인증의 내장된 적용을 제공하지 않습니다. 외부 시스템(스마트 카드, RSA SecurID)과의 호환성은 존재하지만, 이들은 별도의 전용 인프라를 필요로 하며 고유 기능이 아니므로, 구현되지 않을 경우 중대한 인증 보장 공백을 남깁니다.

• 횡적 이동 및 권한 상승 용이성: 최소한의 vSphere 권한을 가진 비관리자 AD 자격 증명조차도 위협 행위자에게 vCenter에 대한 초기 접근을 허용합니다. vCenter는 이후 추가적인 네트워크 침투, 가상 환경 내에서의 권한 상승, 또는 콘솔/API 접근을 통한 게스트 시스템 공격의 피벗 지점으로 악용될 수 있으며, 이 모든 것은 초기 단일 요소 자격 증명 침해에서 비롯됩니다.

vSphere vCenter를 ID 관리를 위해 AD와 직접 통합하는 것은 일반적이지만, 본질적으로 결합된 종속성, 단일 요소 인증 의존성, 강력한 네이티브 MFA의 부재, 그리고 공격 경로 용이성에서 비롯된 중대한 보안 취약점을 초래합니다. 이는 가상 인프라를 심각하게 노출시킬 뿐만 아니라, 기반 리눅스 셸과 포괄적인 EDR(엔드포인트 탐지 및 대응) 기능의 부족과 같은 VCSA 어플라이언스의 공격 표면을 악용할 경로를 제공합니다.

vSphere 보안: Tier 0의 도전

가장 중요한 AD 도메인 컨트롤러(종종 직접적인 ID 통합에 사용됨)와 같은 Tier 0 서비스를 vSphere 하이퍼바이저에서 직접 실행하는 광범위한 관행은 중대하고 종종 간과되는 보안 위험을 초래합니다. Active Directory 도메인 컨트롤러를 vSphere에 배치함으로써, 하이퍼바이저에 대한 성공적인 모든 공격은 공격자에게 전체 AD 환경의 열쇠를 효과적으로 넘겨주게 되어 완전한 도메인 장악을 가능하게 합니다. Mandiant는 이에 대한 전반적인 인식 부족과 선제적인 완화 노력이 지속되고 있음을 관찰합니다.

위험은 상당하며, 예를 들어 위험이 낮거나 운영적으로 일반적인 것으로 보이는 vSphere 권한에도 존재합니다. 예를 들어, AD 가상 머신에 스냅샷을 찍을 수 있는 권한은 완전한 AD 장악을 위해 악용될 수 있습니다. 종종 백업 루틴을 위해 할당되는 이 특정 vSphere 기능은 오프라인 NTDS.dit(AD 데이터베이스) 유출을 가능하게 합니다. 이 vSphere 수준의 행동은 많은 게스트 내부 Windows Server 보안 통제를 비효과적으로 만들어, 강력한 비밀번호 및 MFA와 같은 전통적인 조치뿐만 아니라, 주로 운영 체제 내 활동을 모니터링하는 LSASS 자격 증명 보호 및 EDR과 같은 고급 보호 기능까지 우회합니다. 이는 이 특정 권한을 가진 위협 행위자에게 전체 도메인 침해로 이어지는 직접적인 경로를 효과적으로 열어줍니다.

Mandiant는 여러 사건에서 다양한 랜섬웨어 그룹에 의해 이러한 전술, 기술 및 절차(TTP)가 사용되는 것을 관찰했습니다. VM 암호화 및 로깅의 부재는 탐지되지 않고 AD 데이터베이스를 얻는 것을 상대적으로 간단한 작업으로 만듭니다.

신뢰 관계를 가진 vSphere vCenter와 Active Directory(AD) 간의 위임은 AD 도메인 관리자에게 신뢰 시스템에 대한 암묵적인 관리자 권한을 부여하여 AD 침해의 위험을 높이고 전체 인프라에 영향을 미칩니다. 이를 완화하기 위해서는 두 갈래의 전략을 구현해야 합니다. 첫째, AD를 포함한 가장 중요한 Tier 0 자산을 위해 별도의 전용 vSphere 환경을 만듭니다. 이 격리된 환경은 다른 시스템과 물리적 또는 논리적으로 분리되어야 하며, 강력한 네트워크 분할로 보안을 강화해야 합니다. 둘째, 이 환경의 제어 영역에 대해 제로 트러스트 보안 모델을 구현하여 출처에 관계없이 모든 접근 요청을 확인해야 합니다. 이 격리된 환경 내에는 전용 '인프라 전용' ID 제공자(온프레미스 또는 클라우드)를 배포합니다. 최소 권한의 원칙을 구현하는 것이 가장 중요합니다.

Tier 0 자산(예: Active Directory)을 위한 전용의 격리된 vSphere 환경은 관리자 접근을 엄격하게 제한하고(PAW를 통해), 인프라를 직접 관리하는 사람에게만 권한을 부여해야 합니다. 이는 횡적 이동을 방지하고 피해를 최소화함으로써 침해의 영향을 크게 줄입니다. 환경의 보안을 유지하고 최소 권한 모델을 준수하기 위해 불필요한 통합은 피해야 합니다.

vSphere 환경 내에서 운영되는 중요한 Tier 0 자산, 특히 Privileged Access Management(PAM), Security Information and Event Management(SIEM) 가상 어플라이언스 및 관련 AD 도구와 같은 시스템을 효과적으로 보호하기 위해서는 다층적인 보안 접근 방식이 필수적입니다. 이러한 자산은 독립적이고 자립적인 환경으로 취급되어야 합니다. 이는 네트워크 트래픽과 운영 종속성을 격리하는 것뿐만 아니라, 인증 및 권한 부여 프로세스를 위해 전용의 완전히 분리된 ID 제공자(IdP)를 구현하는 것이 중요합니다. 최고 수준의 보장을 위해서는 이러한 Tier 0 가상 머신을 전용 물리적 서버에 직접 호스팅해야 합니다. 이러한 물리적 및 논리적 분리 관행은 공유 가상화 환경보다 훨씬 더 높은 수준의 분리를 제공합니다.

여기서의 핵심 목표는 권한 부여 종속성 사슬을 끊어, 네트워크의 다른 곳에서 침해된 자격 증명이나 권한이 Tier 0 시스템에 접근하는 데 악용될 수 없도록 보장하는 것입니다. 이 설계는 심층 방어 보안 장벽을 만들어 시스템 전체 침해의 가능성과 영향을 근본적으로 줄입니다.

결론

Mandiant는 공격자들이 랜섬웨어 배포뿐만 아니라 데이터 악용 및 유출을 위한 주요 경로로 vSphere를 점점 더 많이 표적으로 삼고 있음을 관찰했습니다. 이러한 변화는 GTIG가 관찰한 최근 위협 행위자 활동에서 드러났는데, 공격자들은 랜섬웨어 실행 전 또는 실행과 함께 침해된 vSphere 환경을 악용하여 AD 데이터베이스와 같은 민감한 데이터를 유출했습니다.

이 문서에서 상세히 설명했듯이, vSphere에 대한 광범위한 의존성은 AD와의 통합에 내재된 종종 과소평가되는 위험과 안전하지 않은 기본 구성의 지속성과 결합되어 위험한 취약한 환경을 만듭니다. 공격자들은 이러한 약점을 인지하고 있을 뿐만 아니라, 최대의 영향을 달성하기 위해 ESXi와 vCenter를 점점 더 표적으로 삼는 정교한 공격으로 이를 적극적으로 악용하고 있습니다.

vSphere가 온프레미스 및 프라이빗 클라우드의 기본 표준이 되게 하는 유용성과 안정성은 오해를 불러일으킬 수 있습니다. 이는 내재된 보안과 동일하지 않습니다. 특히 전통적인 엔드포인트 방어를 우회하는 하이퍼바이저 계층을 직접 표적으로 삼는 위협 환경의 진화는 vSphere 보안에 접근하는 방식에 근본적인 변화를 요구합니다. 시대에 뒤떨어진 관행, 백업, 경계 방어에만 의존하거나, 게스트 VM의 EDR이 기본 인프라에 대한 충분한 보호를 제공한다고 가정하는 것은 심각한 보안 공백을 만들고 조직을 심각한 위험에 노출시킵니다.

ID 통합 취약점은 악용될 것입니다. 따라서 조직은 vSphere 환경의 AD 통합 상태를 즉시 평가하고, 이 문서에 제시된 완화 전략 구현을 단호하게 우선시할 것을 강력히 촉구합니다. 이러한 선제적인 태도는 현대의 위협에 효과적으로 대응하는 데 중요하며, 다음 사항을 포함합니다.

1. 중요 종속성 분리: AD 공격 표면을 줄이기 위해 ESXi 호스트 통합을 AD와 직접적으로 분리하는 것이 가장 중요합니다.

2. 인증 현대화: 현대적인 IdP와의 ID 연합을 통해 피싱에 강한 강력한 MFA를 vCenter에 구현하는 것은 더 이상 선택 사항이 아니라 필수적입니다.

3. 체계적인 보안 강화: ESXi와 vCenter에 대한 안전하지 않은 기본 설정을 선제적으로 해결하고, execInstalledOnly, Secure Boot, TPM, Lockdown Mode와 같은 기능을 활성화하며, 엄격한 방화벽 규칙을 구성합니다.

4. 향상된 가시성: ESXi와 vCenter 모두에 대한 포괄적인 원격 로깅을 구현하고, 하이퍼바이저 수준 공격을 탐지하기 위해 특별히 설계된 사용 사례와 함께 SIEM으로 전달합니다.

5. Tier 0 자산 보호: Active Directory 도메인 컨트롤러와 같은 중요 워크로드를 엄격하고 최소화된 접근 제어 및 암호화된 VM과 vMotion을 갖춘 전용의 고도로 보안된 vSphere 환경에 전략적으로 격리합니다.