UPDATE : 2020-07-06 17:35 (월)
파일기반 샌드박스 회피 기술
상태바
파일기반 샌드박스 회피 기술
  • 이광재 기자
  • 승인 2013.10.07 14:08
  • 댓글 0
이 기사를 공유합니다

젱 부/파이어아이 연구팀 수석 이사

<자료 제공: 파이어아이 '파일 기반의 샌드박스를 쉽게 회피하는 악성코드 기법(Hot Knives Through Butter:How Malware Evades Automated File-based Sandboxes)' 보고서>

오늘날 기업들이 급증하는 사이버공격에 직면하게 되면서 의심스러운 활동을 하는 파일을 빠르게 탐지할 수 있는 VM(Virtual Machine) 기반의 가상 샌드박스가 각광 받고 있다. 이러한 샌드박스는 기존의 시그니처 기반의 악성코드 탐지를 하는 것 대신 가상의 환경에서 격리된 상태로 특정 파일이 실행되는 실제 행위를 포착한다. 이론상 보안 전문가들은 이러한 구조를 통해 기존의 시그니처 기반의 방어를 회피하는 악성코드를 탐지할 수 있게 됐다.

하지만 샌드박스만이 이러한 것을 가능하게 하는 플랫폼은 아니다. 샌드박스는 자체적으로 파일 활동에 대한 모니터링 및 보고는 가능하지만 분석을 하지는 못한다. 안타깝게도 여러 타 업체들이 제공하는 파일 기반의 샌드박스에만 의존하고 있는 많은 기업들은 최신의 악성코드를 탐지하는 것이 불가능하다는 것이 밝혀졌다. 공격자들은 샌드박스의 감시망을 뚫고 침입하기 위해 다양한 기술을 사용하고 있으며 이전과 마찬가지로 시스템의 취약성은 여전히 존재하게 된다.

이번 연구는 보안 전문가들이 진화하는 위협을 분석하는 데 필요한 샌드박스 회피 기술과 관련해 ▲휴먼 인터랙션 - 마우스 클릭 감지, 대화 상자 실행 ▲구성 설정 - 잠복기 설정, 특정 시간에 동작(시한폭탄), 실행 경로 및 프로세스 숨기기 ▲환경 설정 - 버전, 내장 아이프레임(iframe), DLL 로더 VM웨어 관련 - 시스템 서비스 리스트, 유니크 파일, VMX 포트 등 항목을 다루고 있다.

서론

보안 전문가들은 오늘날의 복합적인 공격에 있어 전통적인 시그너처 기반의 보안 방식은 더 이상 대응이 불가하다는 사실에 동의하고 있다.

지능화된 악성코드는 지속적으로 변화하고 변종이 만들어 지고 있으며 다양한 경로를 통해 알려지지 않은 취약점을 공격한다.

악성코드 방어도 진화해야 한다. 시그너처에 의존하는 대신 샌드박스를 통해 자동화된 분석 시스템으로 악성코드를 조사한다.

이렇게 외부와 격리된 가상 분석 환경은 실제 피해 없이 파일의 실행이 가능하다.

이러한 가상 환경에서 파일을 관찰함으로써 보안 시스템은 운영 시스템 변경이나 공격자의 CnC 서버와의 교신 등 의심스러운 행위를 파악한다.

하지만 공격자들 역시 진화하고 있다. 악성 코드가 목표에 이르기 전에 샌드박스에서 실행될 수 있기 때문에 악성코드 제작자들은 VM 감지 코드를 만들어 실제 공격 대상에 도달할 때까지 자신의 행위를 감출 수 있다. 샌드박스상에서는 의심스러운 행동이 감지되지 않기 때문에 보안 분석 코드를 무력화한다.

악성코드 제작자에게 있어 핵심은 이 코드가 가상 환경에서 작동하는지 아니면 실제 목표 환경 내에서 작동하는지 스스로 파악하는데 있다. 이러한 목적을 위해 악성코드 제작자는 다양한 기술을 개발하고 있다. 

휴먼 인터랙션

파일 분석 위주의 샌드박스는 사용자(Human User) 없이 물리적 시스템인 것처럼 동작 된다. 공격자는 이러한 핵심적인 차이점에 착안해 사람의 활동을 나타내는 각종 징후가 감지될 때까지 잠복해 있는 악성코드를 개발했다.

사용자 행동의 징후로는 마우스 클릭, 대화 상자에 대한 지능적인 반응이 속한다. 이번 장에서는 이러한 휴먼 인터랙션에 대한 부분을 상세히 다루게 될 것이다. 

마우스 클릭 감지

2012년 12월에 분석된 'UpClicker'라는 트로이 목마 바이러스는 사용자의 마우스 클릭을 감지해 활동하는 최초의 악성코드다. UpClicker는 샌드박스를 회피하기 위해 마우스 왼쪽 클릭을 탐지한 이후 악성 CnC 서버와 통신하는 방식으로 설계됐다. UpClicker는 넓은 의미에서 지능형 지속 위협(APT)과 관련된 원격 접속 툴(RAT)인 포이즌 아이비(Poison Ivy )인 셈이다.

[특징1]은 UpCliker 코드 정보가 매개변수로 0Eh를 사용해 SetWinodwsHookExA을 호출하는 것을 보여준다. 이러한 설정은 윈도에서 WH_MOUSE_LL 연결절차(hook procedure)를 사용해 낮은 레벨의 마우스 입력을 감시하도록 한다.

[특징1]에서 강조된 포인터는 [특징2]에서 동그라미로 표시된 부분의 연결 절차와 관련이 있다.

특징 1. 마우스를 탐지하는 악성 코드(포인터, fn이라고 적혀진 강조된 부분)


특징 2. 포인터 fn가 지목한 코드, 마우스 클릭 행위 하이라이트


이 코드는 마우스 왼쪽 클릭을 감시한다. 더 자세히 보면 위 클릭(up-click)을 감시해 트로이 목마가 들어오게 한다. 위로 클릭하면 코드는 Unhook 윈도HookEx() 기능을 호출해 마우스 감시를 중단하고 sub_401170()를 호출해 악성 코드를 실행한다. 또 다른 APT 관련 악성코드인 'BaneChant'는 UpClicker보다 6개월 후에 더 발전된 형태로 등장했다. 단지 세번의 마우스 클릭 후에 활동했다. 

대화 상자 실행

현재 위치가 작동중인 목표 대상이라는 것을 탐지하는 또 다른 방법으로는 대화상자에 대해 사용자의 반응을 보여주는 것이다. 일반적인 악성코드 기술은 윈도의 메시지 박스와 메시지박스에프엑스 API 기능을 활용해 윈도 EXE와 DLL 파일에 대화상자를 생성하도록 하는 것이다. 악성코드는 사용자가 버튼을 클릭한 뒤에만 활동한다.

같은 방식으로 악성코드는 자바스크립트를 사용해 아크로뱃(Acrobat)API의 app.alert() 방법으로 어도비 아크로뱃 PDF 파일 내에 대화상자를 생성한다.

[특징3]은 대화상자를 열기 위해 app.alert() API 를 사용하는 것을 보여준다. OK를 클릭하면 코드는 app.launchURL() 방식으로 악성 URL을 연다.

특징 3. 자바스크립트 코드가 대화 박스를 연다(보기에 이용된 특정 웹사이트 주소 삭제처리)


설정

샌드박스가 점점 더 보호하고자 하는 물리적 컴퓨터와 유사해 지도록 가상 환경의 매개변수가 추가됐다.

사이버 공격자들은 이러한 구성을 인식하고 우회로를 찾아냈다. 

잠복기(Sleep Call)

파일 위주로 분석하는 샌드박스는 검사할 파일이 많으므로 파일을 몇 분간만 검사하고 의심스러운 활동이 없다면 다음으로 넘어간다. 이러한 방식은 결국 악성코드 제작자들이 간단하게 우회 기법을 생성하게 만들었다.

이는 샌드박스 검사가 끝나기를 기다리는 것이다. 잠복기를 설정해 해당 악성코드는 샌드박스의 모니터링 과정에서 의심스러운 활동을 하지 않게 된다.

2013년 2월 발견된 'Trojan Nap'이 이런 방식을 사용했다. 해당 트로이 목마 바이러스는 2011년 MS와 카스퍼스키가 해체한 'Kelihos Botnet'과 관련이 있다.

[특징4]는 Trojan Nap 코드 경로 정보다. 실행되면 악성코드는 악성으로 알려져 있는 'wowrizep.ru'로부터 HTTP 요청을 'newbos2.exe'에 보낸다.

[특징5]에 보이는 것 같이 코드는 타임아웃 매개변수 0x0927C0(600,000 milliseconds, 또는10 분)로 SleepEx() 방식을 호출한다. 또한 'alterable' 필드 속성을 바꾸어 10분 동안 프로그래밍 기능이 작동하지 않게 한다. 이는 대부분의 샌드박스가 파일 샘플을 실행하는 것보다 긴 시간이다.

코드는 비문서화 API 방식NtDelayExecution()을 호출해 의심스러운 활동에 대한 탐색을 지연시킨다. 악성 PDF 파일은 유사한 방식으로 자바스크립트에서 아크로뱃 API를 써서 app.setTimeout()를 호출한다.

[특징6]은 이러한 방식으로 악성 기능 mystr()을 호출하기 까지 1억밀리세컨드(milliseconds: 1000분의 1초) 또는 16분을 기다리는 악성 PDF 파일을 나타낸다.

특징 4. 악성 도메인과 다운로드, 실행가능


특징 5.Nap Trojan 코드-SleepEx 방법 호출


특징 6. 자바스크립트 - 아크로뱃 코드가 app.setTimeout() 방식을 사용해 악성 mystr() 기능을 탐지하기 까지 100만밀리세컨드가 걸린다.



특정 시간 동작 (Time Trigger: 시한폭탄)

슬립 API 콜은 가끔 특정 일자 및 시간에 악성코드를 실행시키는 타임 트리거(시한폭탄)에 사용된다.

정해진 일자 전에는 파일 분석 위주의 샌드박스는 어떤 특이사항도 발견하지 못한다.

사례: 'Hastati'로 불리는 Trojan은 2013년 3월 한국에서 대량의 데이터 파괴 공격을 했다. Hastati는 GetLocalTime() API 방식을 사용하는데 이는 윈도 시스템타임(SystemTime)의 내용을 참조해서 현재 날짜와 시간을 확인하게 된다.

샌드박스가 그 특정 시간에 파일 모니터링을 하지 않으면 악성코드는 감시망을 벗어나 잠입할 수 있다. [특징7]에서와 같이 시스템타임 구조는 다음 수치(메모리에 16진 페어는 역순으로 저장된다)와 같다. 

- 07 DD (wYear) - 2013(연도에 대응)

- 00 06 (wMonth) - 6(6월에 대응)

- 00 01 (wDayofWeek) - 월요일에 대응

- 00 11 (wDay) - 17(날짜에 대응) 

이와 같은 경우 현재 시각이(Monday, June 17, 2013) 정해진 실행 시간(March 20, 2013 at 2:00 P.M.)을 지났기 때문에 악성코드는 실행된다.

하지만 현재 시간이 실행 시점에 도달하지 않으면 악성코드는 Sleep() 모드로 있으며 [특징8]에서와 같이 0EA60(6만밀리세컨드)의 시간을 기다린 후에 코드는 시간을 다시 체크한다. 현재 시간이 여전히 실행 시점 이전이면 다시 슬립 기능으로 들어가 실 시점이 될 때까지 이를 반복한다.

특징 7.Hastati 코드 정도, 하이라이트 된 부분은 현재 시각을 정하기 위해 GetLocalTime() 방식으로 호출


특징 8. 트리거 조건이 충족되지 않으면 악성코드는 Sleep() 기능으로 돌아간다.


실행 경로

코드가 샌드박스에서 실행되는 또 다른 방식으로는 파일 구조에 따른 위치에 의해 결정되기도 한다. 여러 샌드박스 카피 파일 샘플은 루트 디렉토리에 저장돼 실행된다.

실제 컴퓨터에서 대부분의 파일은 사용자 다운로드 폴더 윈도 'TemporaryInternet Files' 폴더나 사용자 지정 폴더에 저장되며 루트 디렉토리에는 거의 저장되지 않는다.

윈도 API 내에서 적어도 두 가지 방법으로 인해 코드가 루트 디렉토리에서 실행될지 아닐지 판한다.

이 두 가지 방법으로는 mmioOpen()과 GetCommadLineA()이 있다. 

mmioOpen()

대체적으로 mmioOpen() 기능은 다음에서 멀티미디어 파일에 사용된다. 

- 파일 실행 (unbuffered or buffered) I/O

- 파일 생성

- 파일 삭제

- 파일 존재 여부 표시 

mmioOpen()로 연 파일은 MMIINFO 구조를 사용해 오픈 파일 상태를 전달한다. 이 구조의 adwInfo 멤버는 I/O 절차를 통해 상태 정보를 파악한다.

악성 코드는 다음과 같은 일련의 순서에 의해 작동된다. 

- 파일이 mmiOpenA 기능을 사용해 '..' szFilename 매개변수로 열고자 시도할 때(최대 하나의 상위 폴더 디렉터리까지)

- 파일이 루트 디렉토리에 있으면 한 레벨 이상 가지 못한다. 그러면 'ACCESS_DENIED'라는 에러 메시지가 뜬다. 윈도는 MMIINFO 구조를 에러로 식별한다(조건 5).

- 악성코드 파일은 'CMP DWORD PTR SS:[LOCAL.5] , 0' 지시에 따라 mmioOpenA 파일 리턴을 체크한다.

- 리턴 수치 mmiOpenA가 NULL이 아닐 경우(즉, 에러가 발생한 경우) MMIOINFO 구조의 wErrorRet 멤버는 에러를 포함한다.

- 코드는 윈도 KERNEL32.GetLastError를 호출해 에러 수치를 파악한다. 에러 수치가 5 (ACCESS_DENIED)이면 코드가 루트 디렉토리에서 작동하고 샌드박스에 있다는 의미다. 악성코드는 작동하지 않는다.

특징 9.
악성코드가 mmioOpen 기능을 사용해 커멘드 경로를 체크한다.


GetCommadLineA()

GetCommadLineA() API 방식을 사용해 악성코드가 루트 디렉토리에서 작동하는지 여부를 파악할 수 있다. 이 방식은 현재 프로세스의 command-line을 검색 하는 방식이다. 악성코드가 루트 디렉토리에서 작동하면 샌드박스 하나의 백슬래시('/')만 스트링에 나타난다.

[특징10]은 API 방식을 사용한 코드를 보여준다. 백슬래시가 하나만 보이면 악성코드는 탐지 회피를 중단한다.

특징 10. 악성코드가 GetCommadLineA()를 사용해 패스를 찾는다.


프로세스 숨기기

파일 분석 위주의 샌드박스는 운영시스템의 프로세스 전부를 모니터링해 의심스러운 악성코드 활동을 탐지한다.

여러 샌드박스는 MS가 제공하는 'PsSetCreateProcessNotifyRoutine'라고 불리는 기능을 사용해 탐지한다.

이러한 루틴은 윈도 프로세스 생성 또는 종료시 하드웨어 드라이버에서 호출할 소프트웨어 루틴을 생성하고 수정한다. 파일 기반 샌드박스는 이 정보를 사용해 중요 정보를 보호하고 시스템 활동을 추적할 수 있다.

윈도는 PsSetCreateProcessNotifyRoutine를 시작 어드레스로 해 내부 콜백 대상의 조합을 유지한다.(윈도 XP SP2에서는 최대 8개의 콜백 등록이 가능) 안타깝게도 비 MS 개발자들에게 이니셜 루틴 내부 포인터는 전달되지 않는다. 제3자 애플리케이션이 이러한 통지에 쉽게 등록될 수 있는 공식적인 방식은 없다.

악성코드 제작자들은 이러한 비문서화 내부 포인터를 활용했다. 가장 악명 높은 사례로는 6년 된 악성코드군인  'Pushdo'로 매우 파괴적인 특징을 보인다.

Pushdo는 PsCreateProcessNotifyRoutine에 엑세스해 보안 소프트웨어 포함 모든 등록된 콜백을 삭제한다.

모든 콜백을 삭제한 후 프로세스를 생성 및 정지시킨다.

악성코드 제작자들에게 있어 핵심은 PsSetCreateProcessNotifyRoutine 내부 포인터를 어떻게 찾느냐 하는 것이다.

[특징11]은 IDA라는 해체 툴을 사용해 윈도 커널 이미지(ntoskrnl.exe)에서 코드를 추출해 내는 것을 보여준다. 코드는 포인터 오프셋이 이러한 루틴의 x86 조합에 있다는 것을 보여준다.

이 정보를 가지고 Pushdo는 보안 소프트웨어에 프로세스 공지를 취소했다. [특징12]에 나오는 Pushdo는 아래와 같이 작동한다. 

- 악성코드는 NtBuildNumber를 사용해 윈도 빌드 번호를 찾는다. 윈도XP의 빌드 번호는 2600(32비트)과 3790(64비트)이다.

- 악성코드는 PsSetCreateProcessNotifyRoutine의 루틴 어드레스를 찾는다. [특징13]의 jmp_PsSetCreateProcessNotifyRoutine 어셈블리 코드는 jmp command 포함하며 외부 PsSetCreateProcessNotifyRoutine 루틴을 생성한다. jmp op-code는 2바이트다. 그러므로 PsSetCreateProcessNotifyRoutine(메모리) 루틴어드레스는 jmp__PsSetCreateProcessNotifyRoutine+2이다.

- 악성코드는 0xBF 어셈블리 코드를 스캔하고 5바이트와 0x57씩 스캔한다. 0xBF 뒤의 숫자는 내부 PspCreateProcessNotifyRoutine 어드레스다.

- 거기에서 악성코드는 PsCreateProcessNotifyRoutine 포인터를 작동하고 콜백 대상을 NULL로 한다. 윈도XP에서 오퍼레이션 코드0xBF는 'mov edi,'이고 0x57는 'push edi.'이다.  

특징 11. PsSetCreateProcessNotifyRoutine 내의 ntoskrnl.exe


특징 12. Retrieval of the PsCreateProcessNotifyRoutine


특징 13. jmp__PsSetCreateProcessNotifyRoutine 어셈블리 코드


환경

이론적으로 샌드박스에서 실행된 코드는 물리적 컴퓨터와 동일한 방식으로 작동해야 한다.

실제로 대부분 샌드박스는 탐지형으로써 공격자들이 해당 가상 환경을 체크해 악성코드 공격을 하도록 한다. 이번 장에서는 이러한 공격을 자세히 설명한다.  

 버전 체크

여러 악성 파일은 애플리케이션이나 운영체제의 특정 버전에서만 작동한다. 이처럼 스스로 정한 제한성은 항상 샌드박스 회피를 시도 하는 것은 아니다.

예를 들어 많은 악성코드는 특정 버전의 애플리케이션에서만 작동하는 경우가 많다. 하지만 효과는 대체로 같다. 모든 샌드박스는 미리 설정한 환경이 있다. 만약 기존의 설정한 환경이 특정 운영 시스템이나 애플리케이션을 갖추고 있지 않다면 악성코드는 실행되지 않고 탐지를 회피하게 될 것이다.  

플래시

[특징14]는 악성 플래시(Flash) 다운로더용 액션스크립트 코드다.

시스템에 설치된 플래시 플레이어 버전은 getUrl() 인풋이다. 코드는 GET 명령어를 통해 대단히 위험한 도메인으로부터 악성 파일을 다운로드 받게 한다. f.swf,은 플래시 특정 버전의 오류를 활용한다.

샌드박스가 타깃 버전을 가지고 있지 않다면 악성 플래시 파일은 다운로드 되지 않으며 샌드박스는 악성 활동을 탐지할 수 없다. 

PDF

유사한 방식으로 [특징15]에 나오는 자바스크립트 코드는 API 방식의 app.viewerVersion()를 사용해 설치된 아크로뱃 리더 버전을 파악한다.

코드는 특정 버전이 있는 경우에만 실행돼 - 이 경우 6.0 이상의 버전 - 해당 버전이 없는 샌드박스는 우회한다. 

GIF와 플래시 파일에 내장된 아이프레임

주로 악성코드는 악성이 아닌 것처럼 보이는 파일을 사용해 탐지를 피하고 악성 파일을 다운로드한다.

이러한 일반적인 접근으로 GIF나 아크로뱃 플래시와 같은 아이프레임 HTML 을 비실행 파일로 숨기는 것이다.

이들 파일은 스스로 실행될 수 없으며 샌드박스에서 의심스러운 행위를 보이지 않는 대신 데이터를 숨긴다.

이 데이터는 'unlocked'된 것으로 물리적 컴퓨터에서 분리 파일로 실행한다. 

GIF

GIF 다음 같이 구성된 그래픽 파일부터는 싱글 필드 블록으로 GIF 데이터 스트림의 끝임을 보여준다.

- 헤더(Header)

- 이미지 데이터(Image data)

- 최적 메타데이터 (Optional metadata)

- 푸터(Footer: 트레일러로도 불린다)

일반적으로 고정된 수치인 0x3B를 가진다. 많은 악성 GIF 파일에서 아이프레임 태그는 푸터 뒤에 붙는다([특징16]).

플래시

GIF 파일과 유사하게 플래시 파일은 아이프레임 링크를 악성 웹사이트로부터 숨길 수 있다.

[특징17]은 악성 아이프레임 요소를 갖춘 플래시 파일 코드를 나타낸다. 플래시는 HTML 렌더링 엔진이 아니기 때문에 숨겨진 아이프레임은 플래시 파일이 샌드박스상에 열려 있을 때도 아무런 작동도 하지 않는다. 따라서 샌드박스 또한 악성 행위를 탐지하지 못한다. 

DLL 로더 체크

일반적으로 DLL(dynamic-link library) 파일을 실행하기 위해서는 run32dll.exe을 사용하거나 프로세스 상에서 DLL을 실행한다. 일부 악성코드는 다른 프로세스를 사용하며 특정 로더가 DLL를 실행하게 한다.

필요한 로더가 나타나지 않으면 DLL은 실행되지 않으며 샌드박스상에서 탐지되지 않은 채 남아 있는다. [특징18]은 악성코드 코드가 해시 로더인지 여부를 계산한다.
 

특징 14. 악성 플래시 다운로드와 버전 체크


특징 15. 악성 아크로뱃 자바스크립트 코드와 버전 체크


특징 16. GIF 파일의 악성 아이프레임 태그


특징 17.악성 아이프레임 태그 - 플래시 파일


특징 18. 악성코드 해시 로더 컴퓨팅


VM웨어 회피 기술

이번 보고서에서 이제까지 설명한 샌드박스 회피 기술은 진화한 악성코드와 APT의 전형을 보여준다. 하지만 자사의 텔레메트리 데이터에 기반한 기존의 여러 전형적인 회피 기술은 악성코드 제작자들에게 효과가 있음을 계속해서 증명하고 있다.

VM웨어는 대중적인 VM 툴로서 특정 설정으로 인해 탐지가 용이하다. 

시스템-서비스 리스트

VM웨어를 사용하는 샌드박스를 탐지하기 위해 일부 악성코드는 vmicheatbeat, vmci, vmdebug, vmmouse, vmscis, VMTools, VMware, vmx86, vmhgfs, and vmxnet 등을 포함한 VM웨어를 체크한다.

[특징19]에 나타난 코드는 RegOpenKeyExA() 기능을 사용해 VM웨어 가상 머신 서비스를 체크한다. RegOpenKeyExA() 기능이 성공하면 리턴 수치는 'nonzero' 에러코드를 나타낸다. 

독특한 파일(Unique File)

악성코드가 VM웨어를 사용하는 샌드박스를 확인 하는 또 다른 방법은 VM웨어에서만 존재하는 파일을 확인 하는 것이다. [특징20]은 악성코드가 GetFileAttributeA()를 사용해 VM웨어 마우스 드라이버를 탐지하는 것을 보여준다.

GetFileAttributeA() 기능은 시스템 속성을 검색하여 특정 파일이나 디렉토리를 파악한다.

기능 호출후 코드 cmp eax, 0FFFFFFFh는 이 수치가 -1인지를 판단한다.

이 수치는 파일이 시스템에 존재하지 않으므로 파일 vmmouse.sys를 판단할 수 없다는 의미다. 그러므로 코드는 VM웨어 환경에서 실행되지 않는다. 

VMX 커뮤니케이션 포트

VM웨어가 가상머신(VM)과 커뮤니케이션 하는 데 사용하는 또 다른 명확한 지표는 VMX 포트다. 포트가 존재한다면 악성코드는 탐지를 피하기 위해 '죽은상태(plays dead)'가 된다. [특징21]은 악성코드가 포트 체크하는 것을 보여준다.

코드 작동은 다음과 같다. 

- move eax, 'VMXh'가 0x564D5868을 EAX 레지스터로 로딩 한다.

- EBX는 특정 수치로 로딩 한다.

- ECX는 0Ah로 설정돼 있어 VM웨어 버전을 검색한다.

- 레지스터 DX는 포트 VX로 설정돼 있어 VM웨어와 접속한다.

- 코드는 in eax, dx을 포트에서 EAX 정보를 읽도록 지시한다. 코드가 VM웨어 환경에서 작동하면 호출이 성공한다. 악성코드는 탐지를 회피하기 위해 작동하지 않는다.  

공개 샌드박스와 비교

아래 [표1]은 악성코드를 탐지하기 위해 파일 분석 위주 샌드박스를 사용하는 3가지 유명한 온라인 악성코드 분석 서비스를 보여주고 있다.

성공의 정도가 다양하기 때문에 무료로 제공되는 서비스 중에서 샌드박스 회피 기술을 갖고 있는 악성코드를 탐지하기도 했다.

하지만 어떠한 무료 서비스도 모든 회피 기술을 탐지하지는 못했으며 아래 3가지 모두 버전 체크 및 임베디드 아이프레임 악성코드는 탐지하지 못했다.

특징 19. RegOpenKeyExA() 기능을 사용해 VM웨어 툴을 탐지하는 악성코드


특징 20. 악성코드가 GetFileAttributeA()를 사용해 VM웨어 마우스 드라이버를 판단한다.


특징 21. 악성코드가 IO 포트를 사용해 VM웨어 탐지


표 1. 샌드박스 비교


결론

파일 분석 위주 샌드박스가 오늘날 정교화된 공격자들을 방어하기 위한 최선의 방법은 아니다. 만약 가상화가 파일의 행위를 관찰하기 위해 활용되는 가치 있는 툴이라면 그것은 단지 툴일 뿐이라는 것이다.

지능화된 악성코드들은 기존의 여러 업체에서 제공하고 있는 획일화된 샌드박스상에서 공격을 실행할지 않을지에 대한 정도는 탐지가 가능하며 매우 조심스럽게 행동한다.

오늘날의 지능화된 위협을 탐지하기 위해서는 IT보안에 있어 더욱 종합적인 접근을 할 필요가 있다. 복합적인 방식에서의 분석을 통해 사이버 공격의 문맥을 분석하기 위해 VM 환경은 다양한 플랫폼 중 일부가 돼야 한다. 행위 기반 및 정적 분석 동시에 사용하고 이와 더불어 각각의 단편적인 공격들이 어떻게 함께 동작되는지를 포괄적으로 이해가게 되면 이러한 공백을 채울 수 있을 것이다. 



댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.