VMware vCenter 뚫렸다…중국계 해킹조직, Babuk 변종 랜섬웨어로 47개국 361대 감염

지난 7월 29일 브로드컴(Broadcom)이 VMware vCenter의 심각한 취약점 두 건에 대한 패치를 배포했지만, 채 일주일도 지나지 않은 8월 1일부터 중국어권으로 추정되는 해킹조직이 실제 공격에 나선 정황이 포착됐다. 독일의 침해사고 대응 전문업체 QUIRSO에 따르면 이 조직은 인증 우회 취약점(CVE-2026-59309)과 원격 코드 실행 취약점(CVE-2026-59310, CVSS 9.8)을 연이어 악용해 47개국 361개 시스템에 침투했다. 

특히 일부 피해 시스템에서는 파일 확장자가 .babyk로 바뀐 흔적이 발견됐는데, 이는 유출된 바붑(Babuk) 랜섬웨어 소스코드를 변형해 만든 랜섬웨어의 특징이다. 연구진은 이 랜섬웨어가 돈을 노린 것이 아니라 침입 흔적을 지우기 위한 연막이었을 가능성에 무게를 두고 있다.

무슨 일이 있었나

공격은 두 단계로 진행됐다. 먼저 공격자는 인증 절차 없이 관리자 권한을 얻을 수 있는 CVE-2026-59309를 이용해 vCenter에 침투한 뒤, 8월 3일경 자신들만 접근할 수 있는 관리자 계정을 새로 만들었다. 이어 vCenter의 syslog 서버 기능을 악용해 /etc/cron.d 경로에 조작된 크론(cron) 작업 파일을 심었는데, 이 방식은 별도의 로그인 절차 없이 root 권한으로 즉시 명령을 실행할 수 있게 해준다. 이후 리버스 SSH와 systemd 서비스로 지속 접근 권한을 확보하고 linuxFile이라는 이름의 백도어를 설치해 자격증명을 훔쳤다. 피해는 독일(55건), 미국(41건), 튀르키예(38건), 이란(26건), 프랑스(25건) 순으로 많았으며, 흥미롭게도 중국 본토는 피해 목록에서 빠져 있었다. 연구진은 공격자가 UTC+8 시간대에서 활동하는 중국어권 조직일 가능성이 높다고 봤다.

왜 위험한가

이번 사건이 특히 우려스러운 이유는 랜섬웨어가 목적이 아니라 도구로 쓰였을 가능성 때문이다. 연구진이 분석한 시스템에서는 ESXi 로그 파일들이 암호화돼 있었는데, 이는 몸값을 받아내기 위한 협박이라기보다 포렌식 분석을 방해해 침입 흔적을 지우려는 목적에 가까웠다. 다시 말해 실제 목표는 장기간에 걸친 첩보 활동이나 지속적인 접근 권한 확보였고, 랜섬웨어는 이를 감추기 위한 위장막이었을 가능성이 크다는 뜻이다. 여기에 더해 하이퍼바이저(vCenter·ESXi) 자체가 공격당했다는 점도 파장을 키운다. 하이퍼바이저 한 대가 뚫리면 그 위에서 가동되는 수십~수백 대의 가상서버가 동시에 위험에 노출되는데, 실제로 유출된 바붑 랜섬웨어 소스코드를 재활용해 자체 ESXi 전용 랜섬웨어를 만드는 조직이 늘고 있다는 보안업계 분석도 나온다. 즉 이번 사건은 특정 조직 한 곳의 일회성 사고가 아니라, 가상화 인프라를 노리는 공격이 하나의 트렌드로 자리잡고 있음을 보여주는 사례다.

비슷한 조직이 대비하려면?

가장 먼저 해야 할 일은 당연하지만 자주 지켜지지 않는 것, 바로 패치다. 이번 공격은 패치가 배포된 지 불과 며칠 만에 시작됐다. 보안 패치를 받고도 실제 적용까지 몇 주씩 걸리는 조직이 여전히 많은데, vCenter처럼 인프라 전체를 관장하는 관리 콘솔은 패치 공개 즉시 최우선으로 적용해야 한다.

두 번째는 관리 콘솔의 인터넷 노출을 최소화하는 것이다. vCenter나 ESXi 관리 인터페이스를 외부 인터넷에서 직접 접근할 수 있게 열어두는 구성은 이번처럼 인증 우회 취약점 하나로 전체 인프라가 뚫리는 결과로 이어진다. 반드시 VPN이나 별도 관리망을 통해서만 접근하도록 제한해야 한다.

세 번째는 로그·계정 감사 체계다. 이번 공격자는 관리자 계정을 새로 만들고 크론 작업을 조작하는 방식으로 흔적을 남겼다. 정기적으로 관리자 계정 목록과 예약 작업 내역을 점검하는 절차만 있었어도 더 빨리 이상 징후를 발견할 수 있었을 것이다. 마지막으로 백업은 반드시 운영 인프라와 물리적·논리적으로 분리해 보관해야 한다. 하이퍼바이저가 통째로 장악당하는 시나리오에서는 같은 네트워크에 있는 백업도 함께 훼손될 위험이 크기 때문이다.

• vCenter·ESXi 관리 콘솔이 별도 인증 절차 없이 외부 인터넷에서 바로 접속되는지 확인한다
• 최근 본인이 만들지 않은 관리자 계정이 새로 생겨나 있지 않은지 점검한다
• /etc/cron.d 등 예약 작업 목록에 낯선 스크립트나 실행 파일이 등록돼 있지 않은지 확인한다
• syslog 전송 설정이나 로그 서버 구성이 임의로 변경된 흔적이 있는지 점검한다
• 가상서버 파일 확장자가 갑자기 .babyk 등 낯선 확장자로 바뀌어 있지 않은지 확인한다
• 알 수 없는 외부 IP로 향하는 리버스 SSH·아웃바운드 연결이 있는지 점검한다

Q. 랜섬웨어 감염 흔적(.babyk)이 없으면 안전한 건가요?

안심할 수 없다. 이번 사건에서 랜섬웨어는 목적이 아니라 흔적을 지우는 도구로 쓰였을 가능성이 크다. 몸값 요구 메시지나 암호화된 파일이 없더라도, 공격자가 이미 관리자 권한을 확보하고 자격증명을 빼돌렸을 수 있다는 뜻이다. 관리자 계정과 예약 작업, 로그 설정을 별도로 점검해야 하는 이유다.

Q. 전산 인력이 1~2명뿐인 중견기업도 VMware를 쓰면 위험한가요?

오히려 더 위험할 수 있다. 대기업은 패치 관리 전담 인력이 있어 며칠 안에 대응이 가능하지만, 전산 인력이 적은 조직은 패치 공지를 인지하고 실제 적용하기까지 훨씬 오래 걸리는 경우가 많다. 이번 공격처럼 패치 공개 후 3~5일 만에 실공격이 시작되는 상황에서는 그 며칠의 지연이 곧바로 피해로 이어진다.

Q. vCenter만 패치하면 충분한가요?

아니다. vCenter는 관리 콘솔이지만 실제 가상서버가 돌아가는 것은 ESXi 호스트다. 관리 콘솔이 뚫리면 그 아래 연결된 ESXi 호스트 전체가 함께 위험해지므로, vCenter와 ESXi 양쪽 모두의 패치 현황과 접근 권한을 함께 점검해야 한다.

이번 사건은 랜섬웨어가 더 이상 돈을 노리는 범죄로만 설명되지 않는다는 걸 보여준다. 국가 배후로 의심되는 조직이 장기 침투의 흔적을 지우는 용도로 랜섬웨어를 활용했다는 정황은, 앞으로 비슷한 사고를 마주했을 때 몸값을 낼 것인가보다 얼마나 오래 무엇을 도둑맞았는가를 먼저 물어야 한다는 뜻이기도 하다. 가상화 인프라는 한 번 뚫리면 그 위의 모든 시스템이 동시에 위험해지는 구조인 만큼, 패치 주기를 앞당기고 관리 콘솔의 노출을 최소화하는 기본기부터 다시 점검할 때다.