VM이 CPU 팬을 가진 것처럼 인식하게 만들어서 악성코드를 속이기

• Malware들은 가상 환경에서 동작하는 것을 피하기 위해 CPU 팬 같은 하드웨어 존재 여부를 확인함
• CPU 팬 정보는 WMI의 Win32_Fan 클래스를 통해 확인 가능하며, 이 데이터는 SMBIOS에 저장됨
• Xen에서 커스텀 SMBIOS 데이터를 삽입하려면 패치와 별도의 설정이 필요하며, Cooling Device(Type 27) 와 Temperature Probe(Type 28) 테이블 모두 구성 필요함
• QEMU/KVM에서는 별도 패치 없이 -smbios 옵션으로 간단히 커스텀 SMBIOS 적용 가능함
• 이를 통해 가상 머신이 CPU 팬이 존재하는 것처럼 속여, 악성코드의 탐지 우회를 시도할 수 있음

---

왜 이런 작업을 하는가?

• 일부 악성코드는 가상 환경에서 실행되는지 확인하려고 특정 하드웨어(예: CPU 팬)의 존재 유무를 체크함
• Win32_Fan 등의 WMI 클래스로 하드웨어를 점검하며, 이러한 정보가 없으면 가상 머신이라고 판단하여 실행을 회피함
• 분석자들이 악성코드를 분석하지 못하게 하려는 의도임
• Win32_CacheMemory, Win32_VoltageProbe 등 다양한 WMI 클래스가 존재하지만 이번 글에서는 CPU 팬에 집중 설명함

컴퓨터는 어떻게 CPU 팬이 있는지 인식하는가?

• 컴퓨터는 SMBIOS 정보를 읽어 냉각 장치(CPU 팬) 존재를 인지함
• Win32_Fan 인스턴스는 cimwin32.dll에서 제공하며, 해당 DLL이 SMBIOS의 type 27 엔트리로부터 팬 정보를 읽음
• DLL 후킹 등도 가능하지만, SMBIOS 직접 조작이 보다 나은 접근임

SMBIOS Type 27

• SMBIOS type 27은 "Cooling Device" 를 의미함
• dmidecode 유틸리티로 SMBIOS의 Cooling Device 데이터를 직접 확인 가능
• 예시:
  • Type: Chip Fan
  • Status: OK
  • Description: CPU Fan
  • Nominal Speed: 5600 rpm 등

Xen에서 커스텀 SMBIOS 데이터 설정 방법

• Xen에서는 domain 설정 파일의 smbios_firmware 옵션을 사용해 바이너리 형태의 SMBIOS 데이터를 직접 지정할 수 있음
• smbios.bin 파일을 만들어 Cooling Device(type 27) 데이터를 삽입
• SMBIOS 구조체 크기(예: 24바이트)는 32비트 little-endian 정수로 앞에 붙여야 함

문제점: 구조체 오버라이드 제한

• Xen은 0, 1, 2, 3, 11, 22, 39번 구조체만 덮어쓸 수 있도록 제한하고 있음
• type 27은 기본적으로 허용되지 않아, 소스 패치가 필요함
• Xen 개발자 포럼에서도 관련 패치가 제안되었으나 공식적으로는 수용되지 않았음(패치 적용 및 빌드 필요)

Type 28도 필요함

• Cooling Device(type 27)은 Temperature Probe(type 28)과 연결됨
• SMBIOS에 type 28 엔트리가 없을 경우 Win32_Fan 클래스에서 정상적으로 표시되지 않음
• host 시스템의 type 28 데이터를 획득해 smbios.bin에 추가해야 정확한 인식 가능

최종 smbios.bin 구조

• Type 27과 Type 28 데이터를 모두 포함
• 각 구조체 앞에 사이즈 정보(little-endian) 삽입
• 예: 18 00 00 00 ... (type 27) ... 29 00 00 00 ... (type 28) ... 형태

Xen에서 적용 및 확인

• domain 생성 명령어로 Windows 가상 머신을 부팅한 후 WMI에서 Win32_Fan 클래스가 정상 인식되는지 확인
• Description: Cooling Device, Status: OK 표시를 통해 성공적으로 CPU 팬 인식

QEMU/KVM에서 SMBIOS 데이터 설정

• QEMU/KVM에서는 -smbios file=경로 옵션으로 손쉽게 커스텀 SMBIOS 설정 가능
• 구조체 크기 정보 없이 raw 데이터만 사용
• host의 SMBIOS 데이터를 그대로 활용해도 무방함

참고 자료

• Xen domain 설정 파일 문서, mcnewton의 세팅 노트, rejected된 Xen 패치 아카이브, System Management BIOS Reference, QEMU Anti Detection 패치 등

[GN⁺]

Hacker News 의견

• 새로운 안티멀웨어 방법으로는 수동 쿨링 PC를 구매하는 방법도 있고, 러시아어 키보드를 설정하는 것도 사기성 멀웨어를 막는 팁이라는 언급 포함, 관련 링크 참고 가능

  • 나는 실제로 Streacom FC8 Evo 수동 쿨링 Linux PC와 러시아어 키보드를 사용하고 있음, 하지만 dmidecode 명령어로 본 결과 쿨링 장치 정보가 여전히 존재하고 냉각 장치가 실제로 감지됨, 센서 데이터로 온도 정보도 확인 가능

  • 수동 쿨링 PC를 써도 메인보드에는 보통 팬 헤더가 남아 있어서 실제 연결이 안 되어 있어도 큰 차이는 없을 것이라는 의견

• “smol pp” 같은 언어를 쓰지 말자고 언급, 몸에 대한 조롱이 언어에 포함되는 부분을 지적

  • 내 도시에는 “SML PP” 커스텀 번호판을 가진 사람이 있음, 왜 그런지 이유는 모르겠음

  • “우리의 언어”라는 표현을 쓰면서도, 블로그 댓글란에 있는 사람이 ‘우리’라고 하는 것 자체가 모호하다는 의견

• 운영체제가 마치 가상머신처럼 보이게 하면 보안성이 올라가고 연구자에게 도움이 될 수 있다는 의견, 비가상화 접근을 원하면 반드시 권한을 받아야 하고, 이렇게 하면 멀웨어가 연구자 분석을 피하기 위해 일반 사용자도 타겟팅하지 않을 수 있음, 결국 멀웨어 제작자를 제외한 모두가 이득이라는 주장

  • 보통의 운영체제를 VM 처럼 보이게 하는 게 아니라, 오히려 가상머신이 자신이 가상화된 걸 아예 모르게 하는 것, IBM의 lpars 시스템이 그런 식으로 동작한다는 의견

  • 이런 방식이면 안티치트 소프트웨어 회사들도 손해일 것이라는 언급, 나는 내 소프트웨어가 어디서 도는지 명확히 알기를 원하지만, 부정행위보다 치트 유저를 더 싫어하는 멀티플레이어 유저들도 많아서 현실적으로 변화는 쉽지 않다는 의견

  • 모바일 개발 세계에서는 이미 이런 틀이 현실이 되었음이라는 의견

• 나는 지금껏 소비자용 메인보드에서 SMBIOS 설명이 진짜 하드웨어와 일치하는 경우를 본 적이 없음, 이런 SMBIOS를 체크하는 멀웨어는 실제 하드웨어의 50%에서 실패할 수도 있지만, 100%의 VM이나 디버거에서만 확실히 막으면 멀웨어 입장에서는 실패하더라도 충분히 가치가 있다는 생각, 하지만 이러한 접근보다 시간 측정으로 확인하는 편이 더 신뢰도 높을 것으로 예상

  • SMBIOS 설명이 실제 하드웨어랑 안 맞는 현상은 특히 저가형 중국산 박스에서 심함, “to be filled in by OEM” 같은 미기입 값이 실제 라이브 BIOS 이미지에서 코딩할 때 자주 보여서, 이런 값들만으로도 충분히 웃긴 상황이라는 피드백

  • 멀웨어는 버그도 많음, 과거 네트워크 코드에 버그가 있어서 바이러스가 본래 의도보다 절반 속도로 퍼진 사례처럼, 멀웨어가 모든 기기를 다 감염시키지 않아도 엄청난 피해는 얼마든지 줄 수 있음

  • 요즘은 리눅스가 팬을 어떻게 인식하는지 궁금함, ACPI나 EFI를 사용하는지 모르겠고, 내 기기들은 대부분 팬/센서가 정확하게 인식되는 상태라는 질문

  • 이 SMBIOS 체크는 실제 멀웨어가 하는 건지, 아니면 연구자가 만든 샘플에서만 쓰이는 건지 궁금하다는 질문

• 멀웨어가 분석을 어렵게 만들려고 API를 쓰는 트릭이 귀엽게 느껴질 수 있지만, 대부분 이런 API 호출은 정적 분석에서 쉽게 탐지되고, 바이너리가 난독화되지 않으면 오히려 역효과라는 의견, 진짜 목적 있는 프로그램은 보통 신뢰받는 CA의 서명을 받아서 배포되기에, 보안 분석상으로는 수상한 행동으로 잘 탐지된다는 경험 공유, 주니어 시절 regex 패턴으로 이런 API 사용을 잡아내는 일도 했는데, 대량 배포된 기본적인 악성코드를 잡는 데 꽤 효과적이었음

  • 최근에는 멀웨어도 꽤 자주 파일에 서명함, 더이상 멀웨어 업체들이 바이너리에 서명을 안 할 거란 기대는 틀렸다는 점, 탈취된 코드 서명 인증서가 흔하고 Microsoft가 기존 고객 소프트웨어가 깨질까봐 인증서 폐기에 소극적인 점도 언급, 멀웨어가 커널로 침투하기 위해 취약한 드라이버를 활용하는 경우도 많음, 그래서 WMI 호출을 하는 수상한 작은 바이너리보다, 취약점이 많은 오버클럭 유틸리티가 똑같은 쿼리를 해도 별 의심을 안 받는 현실, 실제로 이 방식은 탐지 회피보다는 분석가 PC에서 멀웨어 페이로드가 활성화되지 않게 하려는 의도, 탐지되면 2차 페이로드가 내려오지 않고 실제 공격을 일으킬만한 C&C 동작이 보류되는 구조

  • 보안 관점에서는 모든 소프트웨어를 VM에서 돌리는 게 더 낫지 않을까 하는 제안

  • 안티바이러스가 정적 분석만으로 멀웨어 여부를 추정하는 것도 애매함, 그러면 아예 화이트리스트 방식으로 신뢰된 소프트웨어만 허용하고 나머진 모두 멀웨어로 보는 게 결과가 똑같을 것이라는 주장

  • CrowdStrike 같은 업체가 커널 수준에서 돌아가는 허접한 소프트웨어를 공식적으로 서명받아 시스템 콜을 다 해도 아무도 신경 안 쓰는 현실, VM 여부는 상관없이 그냥 프로덕션에 검증되지 않은 코드와 릴리스를 배포해 놓고 실제로 세상이 망가지고 항공편이 지연되거나 주요 인프라에 사고가 나도 책임을 제대로 지지 않는 문제, 정작 합법적인 기업들이 해커나 국가 수준 공격자보다 더 큰 피해를 줄 수 있다는 비판, xz 유틸 사태도 SolarWinds, ClownStrike와 비교될 만큼 대형 보안사고라는 의견

• 나는 인포섹 업계 친구가 멀웨어 허니팟을 진짜 하드웨어와 완전히 유사하게 만드느라 대부분의 시간을 쏟는 걸 봤음, 윈도우 XP 기반 온도조절기부터 Siemens PLC 컨트롤러, 뱅킹 데스크탑까지 정말 다양한 기기를 엄청나게 정교하게 세팅하는 모습이 놀랍다는 설명

  • 제발 세상에 윈도우 XP로 동작하는 온도조절기는 없길 바란다는 걱정

• 해킨토시를 세팅할 때 적절한 SMBIOS가 반드시 필요했던 것이 생각남, 많은 비교적 마이너한 PC API들이 지난 수십 년간 도입되었고, 가상화 소프트웨어나 멀웨어에서 이런 부분을 얼마나 잘 반영했는지 테스트하는 데 자주 사용됨, 한 단계 더 나아가려면 실제 CPU 부하에 맞춰 동적으로 변화하는 온도센서 시뮬레이션도 필요하다는 분석

• Mitre ATT&CK T1497.001 (VM Detection) 기준으로 SMBIOS 체크가 알려진 벡터임, 나도 실험해보니 파워서플라이를 ‘HotReplaceable=Yes’, ‘Status=OK’로 세팅해서 $5,000짜리 베어메탈 서버처럼 표시되게 할 수 있었음, 사용한 명령어는 pip install dmigen 이후 dmigen -o smbios.bin --type0 vendor="American Megatrends",version="F.1" --type1 manufacturer="Dell Inc.",product="PowerEdge T630" --type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1

  • 참고로, Hacker News에서는 실제 줄바꿈을 위해 두 번 이상 개행하거나 각 줄을 두 칸 들여쓰기해서 코드 모드로 쓰는 게 필요하다는 팁