백서 기반 샌드박스를 - fireeye...그림 8의예제악성코드에서는 getcursorpos에서...

파일 기반 샌드박스를간단히 회피하는 악성코드

백서

2백서 | 파일 기반 샌드박스를 간단히 회피하는 악성코드

목차

Executive Summary ......................................................................................................................... 3

Introduction ............................................................................................................................................4

Human Interaction ............................................................................................................................4

Configuration ........................................................................................................................................11

Environment ..........................................................................................................................................19

VMware Evasion Techniques .................................................................................................23

Comparing Publicly Available ..............................................................................................26

Conclusion .............................................................................................................................................27


종합 요약 보고서조직을 노리는 사이버 공격이 쇄도하는 가운데 가상 머신 샌드박스가 수많은 파일에서 의심스러운 활동을 빠르게 탐지하는 인기 툴로 부상하고 있습니다. 샌드박스는 실행되는 파일의 실제 동작을 모니터링하는 격리된 가상 환경을 제공합니다. 이론적으로 이 환경에서는 보안 전문가가 기존의 시그니처 기반 방어 체계를 회피하는 악성코드를 찾아낼 수 있습니다.

하지만 샌드박스는 주변의 분석 기능이 뒷받침되지 않으면 소용이 없습니다. 샌드박스 자체로는 파일 활동을 모니터링하고 보고할 뿐이지 분석하지는 못합니다. 그리고 파일 기반 샌드박스에 의존하는 조직에는 안 된 일이지만, 파일 기반 샌드박스는 최신 악성코드를 인식하지 못하는 것으로 판명되었습니다. 공격자들은 다양한 기법을 이용하여 샌드박스의 레이더망을 통과하기 때문에 시스템이 샌드박스를 사용하기 전처럼 취약한 상태가 됩니다.

주: “샌드박스”라는 용어는 다양한 형태의 코드 격리 기술을 포함하는 포괄적인 개념입니다. 이 보고서에서는 기능화된 가상 머신(VM) 환경을 사용하여 표적 컴퓨터를 시뮬레이션하고, 알 수 없는 파일을 실행하며, 보고 및 분석을 위해 해당 파일의 활동을 모니터링하는 파일 기반 샌드박스를

중점적으로 설명합니다. 이 보고서에서 소개하는 수법은 이 범주의 샌드박스로 탐지되지 않는 VM 인식 악성코드를 나타냅니다. 이 악성코드를 탐지하려면 다중 흐름 분석을 통해 행동의 상황정보를 분석하고 서로 다른 공격 단계의 상관관계를 밝혀야 합니다. 바로, FireEye 연구원들이 이 보고서에서 설명하는 악성코드 샘플을 찾아내는 데 사용한 방법입니다.

이 보고서는 2014년 2월에 게시된 보고서의 업데이트된 버전입니다. 이번 업데이트에는 다음 내용이 추가되었습니다.

• 사람의 개입을 이용하여 파일 기반 샌드박스를 회피하는 새로운 회피 기법

• 구성 섹션에서 파일 기반 샌드박스를 회피하는 악성 동작을 수행하는 실행 파일을 숨기는 데 이미지 파일을 이용하는 기법에 대한 자세한 정보 제공

이 보고서에서는 다음 범주의 샌드박스 회피 기법을 자세히 설명합니다.

• 사람의 개입 - 마우스 클릭 및 대화상자

• 구성 관련 - 슬립 콜, 타임 트리거, 프로세스 숨기기, 악성 다운로더, 분석된 파일의 실행 이름, 볼륨 정보, 재부팅 후 실행

• 환경 관련 - 버전, 내장된 iframe(Flash, swf, jpg 파일에 내장), 이미지 파일 안에 내장된 실행 파일, DLL 로더

• VMware 관련 - 시스템 서비스 목록, 고유 파일, VMX 포트


머리말보안 전문가들은 기존 시그니처 기반 보안 수단이 오늘날의 지능형 공격 앞에서 무력화된다는 데 대체로 동의합니다.1 지능형 악성코드는 동적이고 형태가 다양하며 알려지지 않은 취약점을 이용한 조직화된 방식으로 여러 경로를 통해 공격합니다.

따라서 악성코드 방어 방식도 진화해야만 했습니다. 시그니처에 의존하는 대신 자동화된 분석 시스템이 샌드박스를 이용하여 악성코드 동작을 조사합니다. 자체적으로 구동되는 이 시뮬레이션 컴퓨터 환경에서는 실제 피해를 주지 않으면서 파일을 실행할 수 있습니다. 보안 시스템이 이 가상 환경에서 파일을 관찰하면서 운영 체제 변경이나 공격자의 명령 및 제어(CnC) 서버 호출 등 의심스러운 동작을 플래깅할 수 있습니다.

하지만 그동안 공격자들도 진화했습니다. 악성코드 작성자들은 공격자의 코드가 샌드박스에서 실행된 후 표적에 도달할 가능성을 염두에 두고, “실제” 표적에 도달할 때까지 명백한 동작을 숨기는 VMaware 코드를 작성하고 있습니다. 보안 분석에서는 샌드박스에서 의심스러운 동작이 관찰되지 않으면 무해한 코드로 간주합니다.

악성코드 작성자에게 가장 중요한 문제는 코드가 가상 환경과 실제 표적 시스템 중 어디에서 실행 중인지를 판별하는 것입니다. 이와 관련해 악성코드 작성자들은 다양한 기법을 개발했습니다.

사람의 개입파일 기반 샌드박스는 물리적 시스템을 에뮬레이션하지만 실제 사람은 배제되어 있습니다. 공격자들은 이 중요한 차이점을 이용하여 마우스 클릭, 대화상자에 대한 지능적인 반응 등 인간 사용자의 징후가 포착될 때까지 잠복하는 악성코드를 만들고 있습니다. 이 섹션에서는 이 같은 확인 수법을 자세하게 설명합니다.

마우스 클릭2012년 12월에 분석된 트로이 목마 바이러스인 UpClicker는 가장 먼저 발견된 악성코드 샘플 중 하나로, 마우스 클릭을 이용하여 사람의 활동을 감지합니다.2 (이와 유사하지만 더 단순한 기법이 몇 달 전에 등장했습니다.3) 샌드박스를 속이기 위해 UpClicker는 왼쪽 마우스 버튼 클릭이 감지된 후에만 악성 CnC 서버와 통신합니다. UpClicker는 지능형 지속적 위협(APT) 공격과 밀접하게 연관된 원격 액세스 툴(RAT)인 Poison Ivy를 둘러싼 래퍼입니다.4

그림 1에는 0Eh를 매개 변수로 사용하여 SetWinodwsHookExA 함수를 호출하는 UpClicker 코드가 나와 있습니다. 이 설정은 낮은 수준의 마우스 입력을 모니터링하는 데 사용되는 Windows 후크 프로시저 WH_MOUSE_LL을 설치합니다.5

1 Gartner. “Best Practices for Mitigating Advanced Persistent Threats(지능형 지속적 위협을 완화하는 모범 사례).” 2012년 1월. 2 FireEye. “Don’t Click the Left Mouse Button: Introducing Trojan UpClicker(마우스 왼쪽 버튼 클릭 금지: 트로이 목마 바이러스 UpClicker 소개).” 2012년 12월. 3 Symantec. “Malware Authors Using New Techniques to Evade Automated Threat Analysis Systems(새로운 기법을 이용하여 자동화된 위협 분석 시스템을 회피하는 악성코드 작성자들).” 2012년 10월. 4 ZDNet. “‘Nitro’ targeted malware attacks hit chemical companies(화학 회사를 노린 ‘Nitro’ 표적 악성코드 공격).” 2011년 11월. 5 Microsoft. “SetWindowsHookEx function(SetWindowsHookEx 함수).” 2013년 6월.


그림 1에 강조 표시되어 있는 포인터 fn은 그림 2에 원으로 표시된 후크 프로시저를 지칭합니다.

이 코드는 마우스 왼쪽 클릭을 감지합니다. 좀 더 구체적으로 말하면, 업클릭을 포착하는 데 이 트로이 목마의 이름이 거기에서 유래했습니다. 이 코드는 업클릭이 발생하면 UnhookWindowsHookEx () 함수를 호출하여 마우스 모니터링을 중지하고 sub_401170 () 함수를 호출하여 악성코드를 실행합니다.

UpClicker 이후 6개월 만에 등장한 BaneChant라는 다른 APT 관련 악성코드 파일은 이 개념을 한층 더 발전시켰습니다.6 마우스 클릭이 3번 감지된 후에만 활성화됩니다.

대화상자실제 표적을 감지하는 다른 방법으로, 사용자의 응답을 요구하는 대화상자를 표시하는 방법이 있습니다. 일반적인 악성코드 기법으로는, Windows의 MessageBox 및 MessageBoxEx API 함수를 이용하여 EXE 및 DLL 파일에 대화상자를 만드는 방법이 있습니다. 이 악성코드는 사용자가 버튼을 클릭한 후에만 활성화됩니다.

같은 방식으로, JavaScript를 이용하여 Adobe Acrobat PDF 파일 내에 app.alert() 메서드(Acrobat API용 JavaScript에서 설명)를 사용한 대화상자를 열 수 있습니다. 그림 3에는 app.alert() API를 사용하여 대화상자를 여는 코드가 나와 있습니다. 사용자가 OK를 클릭하면 이 코드는 app.launchURL() 메서드를 사용하여 악성 URL을 엽니다.

그림 1: 마우스에 대한 후크를 보여주는 악성코드(포인터 fn이 강조 표시됨).

그림 2: 포인터 fn이 가리키는 코드(마우스 클릭 업 동작이 강조 표시됨).

6 FireEye. “Trojan.APT.BaneChant: In-Memory Trojan That Observes for Multiple Mouse Clicks(Trojan.APT.BaneChant: 여러 차례의 마우스 클릭을 감지하는 인메모리 트로이 목마).” 2013년 4월.

그림 3: 대화상자를 여는 JavaScript 코드(특정 웹사이트 표기는 지움).


그림 4: RTF pFragments 속성의 취약점을 악용하는 코드

스크롤하는 것은 사람7

FireEye가 발견한 어떤 악성코드는 사용자가 Rich Text Format(RTF) 문서의 두 번째 페이지로 스크롤할 때까지 잠복합니다. 따라서 무작위 또는 프로그래밍된 마우스 이동으로 사람의 개입을 시뮬레이션하더라도 악의적인 동작이 나타나지 않습니다.

이 악성코드의 작동 방식은 다음과 같습니다.

RTF 문서는 일반 텍스트, 제어 단어 및 그룹으로 이루어져 있습니다. Microsoft의 RTF 사양에는 다음 구문을 사용한 일련의 속성을 포함하는 모양 그리기 함수가 포함되어 있습니다.

{\sp {\sn propertyName } {\sv propertyValueInformation}}

이 코드에서 \sp는 그리기 속성의 제어 단어이고 \sn은 속성 이름이며 \sv에는 속성 값에 대한 정보가 들어 있습니다. 그림 4의 코드는 pFragments 모양 속성에 잘못된 \sv 값을 사용할 때 발생하는 취약점을 악용합니다.

이 익스플로잇 코드를 자세히 살펴보면, 그림 5.0과 같이 익스플로잇 코드 앞에 일련의 단락 표시(./ par)가 있는 것을 알 수 있습니다.


반복적으로 나타나는 이 단락 표시는 익스플로잇 코드를 RTF 문서의 두 번째 페이지로 푸시합니다. 따라서 이 악성코드는 문서가 아래로 스크롤되어 익스플로잇 코드가 활성 창에 나타날 때까지 실행되지 않습니다. 이는 가상 머신에서 시뮬레이션된 동작이 아니라 실제 인간 사용자의 의도적인 행동일 가능성이 더 높은 것입니다.

RTF가 두 번째 페이지로 스크롤되면 익스플로잇 코드만 트리거되고, 그림 5.0과 같이 셸 코드의 URLDownloadToFileA 함수를 호출하여 실행 파일을 다운로드합니다.

무작위 또는 프로그래밍된 마우스 동작을 시뮬레이션하는 일반적인 파일 기반 샌드박스에서는 RTF 문서의 두 번째 페이지가 표시될 일이 없습니다. 따라서 악성코드가 실행되지 않고 샌드박스 분석에서도 문제가 발견되지 않습니다.

두 번(클릭)의 규칙최근 공격 사례에서 발견된 다른 샌드박스 회피 공격 기법은 마우스 클릭이 2회 이상 발생한 후에 실행하는 방식입니다.7 사람의 개입을 감지하는 이전 회피 기법을 차단하기 위해 일부 샌드박스는 코드를 실행할 때 마우스 클릭을 1회 시뮬레이션하도록 프로그래밍되기 시작했습니다. 하지만 대부분의 사람들은 하루 중에 여러 차례 마우스 버튼을 클릭합니다. 이 악성코드는 2회 이상의 클릭이 감지될 때까지 잠복해 있는 방법으로 샌드박스에서 모방된 동작이 아니라 실제 사람이 마우스를 클릭하는 동작에만 반응하도록 만들어졌습니다.

6 Abhishek Singh. Sai Omkar Vasisht, “Turing Test in Reverse: New Sandbox-Evasion Technique seeking Human Interaction(테스트를 뒤집다: 사람의 개입을 포착하는 새로운 샌드박스 회피 기법)” 2014년 6월 24일.

그림 5: 익스플로잇 코드 앞에 나타나는 일련의 \.par(단락 표시).

그림 6: 익스플로잇 코드.


이 기법의 작동 방식은 다음과 같습니다.

1. 이 악성코드는 루프에서 Get AsyncKeyState 함수를 호출합니다. 이 함수는 0x01, 0x02 또는 0x04 변수를 찾아 마우스 버튼이 클릭되었는지 확인합니다. (0x01 변수는 마우스 왼쪽 버튼의 가상 키 코드이고, 0x02는 오른쪽 버튼의 코드, 0x04는 가운데 버튼의 코드입니다.)

2. "xor edi edi" 명령은 edi를 0으로 설정합니다.

3. 버튼이 하나라도 눌리면 이 코드는 그림 7과 같이 "inc edi" 명령을 실행합니다.

4. 그런 다음 “cmp edi,2” 명령을 통해 왼쪽, 오른쪽 또는 가운데 마우스 버튼이 2번 이상 클릭되었는지 확인합니다. 2번 이상 클릭되었으면 루프에서 코드가 실행되어 실제 역할을 수행합니다. 클릭되지 않은 경우에는 마우스가 더 클릭되지 않는지 꾸준히 확인하면서 계속 잠복합니다.

그림 7: 왼쪽, 가운데 또는 오른쪽 마우스 클릭을 활용한 회피 어셈블리 코드.


느린 마우스와 빠른 샌드박스7

최근에 발견된 또 다른 회피 기법으로, 너무 빠른 마우스 움직임을 확인하는 방법이 있습니다. 실제 사람이 마우스 또는 트랙패드를 조작하고 있는지 확인하기 위해 악성코드가 커서의 이동 속도를 확인합니다. 인간의 능력을 초월한 속도는 코드가 샌드박스에서 실행되고 있음을 시사하는 명백한 징후입니다.

이 기법에서는 GetCursorPos라는 Windows 함수를 이용하는데, 이 함수는 시스템의 커서 위치를 검색합니다. 그림 8의 예제 악성코드에서는 GetCursorPos에서 x축 값으로 614, y축 값으로 185가 반환되었습니다.

명령이 몇 개 실행된 후에 악성코드는 GetCursorPos를 다시 호출하여 커서 위치가 바뀌었는지 확인합니다.

그림 6과 같이 이번에는 함수에서 x = 1019, y = 259라는 값이 반환되었습니다.

명령이 몇 개 실행된 후 두 번째 GetCursorPos 호출에서 악성코드는 “SUB EDI, DWORD PTR DS:[410F15]” 명령을 실행합니다. 그림 9.0에서 볼 수 있듯이, EDI의 값은 0x103(10진수 259), DS:[410F15] = 0xB9(10진수 185)입니다. 259와 185라는 값은 두 번의 GetCursorPos 호출에서 검색된 Y좌표입니다. 이 Y좌표 2개의 측정값 차이가 0이 아니면 악성코드가 종료됩니다.

그림 8: GetCursorPos 함수를 처음으로 호출하는 악성코드.


그림 9: GetCursorPos 함수를 두 번째 호출하는 악성코드.

그림 10: Y좌표를 빼기 연산하여 커서가 인간의 조작으로 보기에 너무 빨리 이동되지 않았는지 감지.

다시 말해, 두 번의 GetCursorPos 호출 간(명령 몇 개만 사이에 둔 간격)에 커서가 이동했다면 시뮬레이션된 마우스 이동이라고 판정하는 것입니다. 일반적인 사용 시의 실제 마우스 또는 트랙패드 조작이라고 하기에는 너무 빠르기 때문에 샌드박스에서 실행된 코드라는 것입니다.


구성보호 대상이 되는 물리적 컴퓨터를 모방하려는 샌드박스가 많기 때문에 이러한 가상 환경은 일련의 정의된 변수로 구성됩니다. 사이버 공격자들은 이 같은 구성을 알고, 피하는 법을 터득했습니다.

슬립 콜조사할 파일 샘플이 너무 많기 때문에, 일반적으로 파일 기반 샌드박스는 몇 분 동안만 파일을 모니터링하고 의심스러운 동작이 없으면 다음 파일로 넘어갑니다.

악성코드 제작자는 이 점을 노려 샌드박스 실행이 끝날 대까지 기다리는 단순한 회피 전략을 이용하게 되었습니다. 장시간의 슬립 콜을 추가하여

모니터링 프로세스가 진행되는 동안 악성코드가 악의적인 동작을 하지 않도록 하는 방법입니다.

2013년 2월에 발견된 트로이 목마 바이러스 Nap8이 바로 이 수법을 이용합니다. 이 트로이 목마는 Microsoft와 Kaspersky가 2011년에 무력화되었다고 선언한 Kelihos 봇넷과 연관이 있습니다.9

그림 11에는 Nap 트로이 목마의 코드가 나와 있습니다. 이 악성코드는 실행되면 악성으로 알려진 “wowrizep.ru” 도메인에서 “newbos2.exe” 파일에 대한 HTTP 요청을 보냅니다.

8 FireEye. “An Encounter with Trojan Nap(Nap 트로이 목마와의 조우).” 2013년 2월. 9 Microsoft. “Microsoft Neutralizes Kelihos Botnet, Names Defendant in Case(Microsoft Neutralizes Kelihos 봇넷 무력화, 사건의 용의자들을 밝혀내다).” 2011년 9월.

그림 11: 악성 도메인과 다운로드되는 실행 파일.


그리고 그림 12처럼, 제한 시간 변수 값 0x0927C0(600,000밀리초 또는 10분)을 사용하여 SleepEx() 메서드를 호출합니다. 또한 “alterable” 필드 특성을 false로 설정하여 10분이 경과되기 전에 프로그래밍 함수가 반환되지 않게 합니다. 10분은 대부분의 샌드박스가 파일 샘플을 실행하는 시간보다 긴 시간입니다. 또한 이 코드는 의심스러운 동작을 지연시키기 위한 추가 조치로서, 문서화되지 않은 API 메서드 NtDelayExecution()을 호출합니다.

악성 PDF 파일도 app. setTimeout()이라는Acrobat API용 JavaScript에서 비슷한 방법을 사용할 수 있습니다. 그림 13에는 이 방법으로 100,000,000밀리초 또는 약 16분간 기다린 후 mystr()이라는 악성 함수를 호출하는 악성 PDF 파일이 나와 있습니다.

타임 트리거슬립 API 호출을 타임 트리거와 함께 사용하여 지정된 날짜 및 시간 후에만 악성코드를 실행하는 사례도 있습니다. 그 시간 전에 파일을 모니터링하는 샌드박스는 이상 징후를 탐지하지 못합니다.

해당 사례: 2013년 3월 한국에서 발생한 대규모 데이터 파괴 공격에 Hastati라는 트로이 목마가 사용되었습니다. Hastati는 Windows SystemTime 구조에 대한 포인터를 가져와 현재 현지 날짜 및 시간을 확인하는 GetLocalTime() API 메서드를 이용합니다. 가상 머신이 그 특정 시간에 파일을 모니터링하고 있지 않으면 악성코드는 감시망을 피하게 됩니다.

그림 12: SleepEx 메서드를 호출하는 Nap 트로이 목마.

그림 13: app.setTimeout() 메서드를 사용하여 1,000,000밀리초 동안 기다린 후 mystr() 함수를 호출하는 Acrobat용 JavaScript 코드.


그림 7에서 볼 수 있듯이, SystemTime 구조는 다음 값을 반환합니다(메모리 내에서 16진수 쌍은 역순으로 저장됨).

• 07 DD (wYear)—2013(연도에 해당)

• 00 06 (wMonth)—June(월에 해당)

• 00 01 (wDayofWeek)—Monday(요일에 해당)

• 00 11 (wDay)—17(일에 해당)

이 예에서는 현재 시간(2013년 6월 17일 월요일)이 폭발 트리거(2013년 3월 20일 오후 2:00)보다 지난 시점이므로 악성코드가 실행됩니다. 하지만 현재 시간이 폭발 트리거보다 이전이면, 그림 15와 같이 악성코드는 0EA60(60,000밀리초)을 값으로 사용하여 Sleep() 함수를 호출합니다. 이 시간 동안 기다린 후 코드는 시간을 다시 확인합니다. 현재 시간이 아직 폭발 트리거에 도달하지 않았으면 슬립 함수를 다시 호출합니다. 이런 식으로 폭발 시점이 지날 때까지 루프를 반복합니다.

그림 14: 현재 시간을 확인하는 GetLocalTime() 메서드에 대한 호출이 강조 표시된 Hastati 코드.

그림 15: 트리거 조건을 충족하지 않는 경우 Sleep() 호출을 사용하는 악성코드.


프로세스 숨기기파일 기반 샌드박스는 운영 체제에서 발생하는 모든 프로세스를 모니터링하는 방식으로 의심스러운 악성코드 활동을 찾아냅니다. Microsoft에서 제공하는 PsSetCreateProcessNotifyRoutine이라는 커널 루틴을 사용하여 이 작업을 수행하도록 구성되는 샌드박스가 많습니다. 이 루틴은 하드웨어 드라이버가 Windows 프로세스 생성 또는 종료 시에 호출할 소프트웨어 루틴의 목록을 생성하거나 수정할 수 있게 합니다. 파일 기반 샌드박스는 이 정보를 사용하여 시스템 활동을 추적하고 중요 리소스를 보호할 수 있습니다.

Windows는 PsSetCreateProcessNotifyRoutine을 시작 주소로 하는 다양한 내부 콜백 객체를 유지합니다. (Windows XP SP2에서는 최대 8개까지 콜백이 등록될수 있습니다.) 비Microsoft 개발자에게는 안타깝게도, 초기 루틴의 내부 포인터는 내보내지지 않습니다. 그리고

공개적으로 노출되는 메서드 중에는 타사 애플리케이션이 이러한 알림을 받도록 손쉽게 등록할 수 있는 메서드가 없습니다.

당연히, 악성코드 작성자들은 이러한 문서화되지 않은 내부 포인터를 악용할 방법을 찾아냈습니다. 가장 악명 높은 사례는 6년 전에 등장한 악성코드군인 Pushdo로, 특히 파괴적이고 차단 수단을 회피하는 능력이 뛰어난 것으로 알려져 있습니다.10

Pushdo는 PsCreateProcessNotifyRoutine에 액세스하여 보안 소프트웨어의 콜백을 포함하여 등록된 모든 콜백을 제거합니다. 콜백을 제거하고 나면 경고를 발생시키지 않으면서 프로세스를 생성하고 종료할 수 있습니다.

악성코드 작성자에게는 PsSetCreateProcessNotifyRoutine의 내부 포인터를 찾는 것이 중요합니다. 그림 14에는 IDA라는 분해 툴을 사용하여 Windows 커널 이미지(ntoskrnl.exe)에서 추출한 코드가 나와 있습니다. 이 코드는 이 루틴의 x86 어셈블리에 포인터 오프셋이 포함되어 있음을 보여 줍니다.

10 Gunter Ollmann(Security Dark Reading). “Much Ado About PushDo(PushDo가 불러온 소동).” 2013년 5월.

그림 16: ntoskrnl.exe의 PsSetCreateProcessNotifyRoutine.


Pushdo는 이 정보를 사용하여 보안 소프트웨어가 인식하지 못하도록 프로세스 알림을 손쉽게 숨길 수 있습니다. 그림 17의 Pushdo 코드는 다음과 같이 작동합니다.

1. 이 악성코드는 NtBuildNumber 함수를 사용하여 Windows 빌드 번호를 확인합니다. Windows XP의 빌드 번호는 2600(32비트)과 3790(64비트)입니다.

2. PsSetCreateProcessNotifyRoutine의 런타임 주소를 가져옵니다. 그림 18에 나와 있는 jmp_PsSetCreateProcessNotifyRoutine 어셈블리 코드 조각에는 외부 PsSetCreateProcessNotifyRoutine 루틴에 대한 jmp 명령이 포함되어 있습니다. jmp 연산 코드는 길이가 2바이트입니다. 따라서 PsSetCreateProcess NotifyRoutine(인메모리)의 런타임 주소는 jmp PsSetCreateProcessNotifyRoutine + 2입니다.

3. 이 악성코드는 0xBF의 어셈블리 코드를 선형적으로 스캔합니다. 이 어셈블리 코드의 5바이트 뒤에는 0x57이 따라옵니다. 0xBF의

4. 바로 뒤에 오는 값은 내부 PspCreateProcessNotifyRoutine 주소입니다.

5. 여기서 악성코드는 간단히 PsCreateProcessNotifyRoutine 포인터를 종료하고 모든 콜백 객체를

6. NULL로 처리합니다. Windows XP에서 연산 코드 0xBF는 ‘mov edi”이고 0x57은 “push edi”입니다.

그림 17: PsCreateProcessNotifyRoutine 검색.

그림 18: jmp PsSetCreateProcessNotifyRoutine 어셈블리 코드 조각.


악성 다운로더일반적으로 악성 다운로더에는 공격자가 제어하는 서버에 대한 HTTP 요청을 실행하여 악성코드 페이로드를 다운로드하는 코드가 들어 있습니다. 그림 19에는 PDF 문서에 내장되어 고위험 도메인에 대한 HTTP 요청을 실행하여 악성코드를 가져오는 JavaScript 코드의 예제가 나와 있습니다.

분석된 파일의 실행 이름샌드박스는 실행하는 동안 파일에 미리 정의된 이름을 할당하는 경우가 많습니다. 공격자는 이 같은 이름 중 하나로 실행되는지를 확인하며 그러한 경우 노출될 위험이 있는 동작을 하기 전에 종료되도록 코드를 작성하여 탐지를 피할 수 있습니다.

파일 기반 샌드박스는 인터넷에 연결되지 않은 상태로 구성되는 경우가 많습니다. 그러한 샌드박스에서 관찰되는 악성 다운로더는 HTTP 요청을 실행하지만 악성코드를 다운로드하지 못합니다. 따라서 샌드박스는 HTTP 요청만 탐지하고 실제 악성코드 다운로드와 뒤이은 악의적인 활동은 탐지하지 못합니다.

그림 20에는 이 회피 기법의 실제 작동 방식을 보여 주는 예가 나와 있습니다. 이 예제 코드는 Windows의 GetModuleFilenameW() 함수를 호출하여 자신의 파일 경로를 검색합니다. 그런 다음 해당 경로에 “sample”(샌드박스에서 실행되는 모듈에 주로 할당되는 이름)이라는 문자열이 있는지 확인합니다. “sample”이라는 문자열이 있으면 악성코드가 종료됩니다.11

그림 19: 고위험 URL에 대한 HTTP 요청을 실행하는 악성 JavaScript 코드.

그림 20: 실행 경로에 sample 문자열이 있는지 확인한 악성코드.

11 Gunter Ollmann(Security Dark Reading). “Much Ado About PushDo(PushDo가 불러온 소동).” 2013년 5월.


볼륨 정보모든 컴퓨터 하드 드라이브에는 대개 드라이브를 포맷할 때 할당되는 볼륨 일련번호가 있습니다. 이 4바이트 값은 포맷 작업의 날짜와 시간을 조합하여 생성됩니다. 따라서 2개의 볼륨에 같은 일련번호가 할당될 가능성은 낮습니다.

하지만 샌드박스는 서로의 가상화된 복제본인 경우가 많습니다. 즉, 원본 시스템 이미지가 생성될 당시의 볼륨 일련번호까지 복제됩니다. 악성코드는 자신이 실행되고 있는 시스템의 볼륨 일련번호가 널리 사용되는 VM의 볼륨 일련번호와 일치하는지를 확인하여 여러 샌드박스의 존재를 감지할 수 있습니다.11

그림 21의 코드는 이 기법으로 Windows의 GetVolumeInformation 함수를 이용합니다. 이 함수는 지정된 루트 디렉토리와 관련한 파일 시스템 및 볼륨에 대한 정보를 검색합니다.

“cmp DWORD PTR [EBP-8], 0CD1A40” 명령은 GetVolumeInformation()으로 검색된 볼륨 번호를 알려진 파일 기반 샌드박스의 볼륨 번호와 비교합니다. 일치하는 볼륨 번호가 있으면 악성코드가 종료됩니다.

재부팅 후 실행파일 기반 샌드박스는 일반적으로 연이어 파일 샘플을 실행하도록 설정되며, 보통 VM은 분석 중에 재부팅되지 않습니다. 공격자들은 이를 고려해 재부팅되기 전까지는 명백한 징후를 보이지 않는 악성코드를 배포하고 있습니다. 샌드박스는 분석 중에 재부팅되지 않으므로 악의적인 동작이 포착되지 않습니다.

이 기법의 대표적인 예는 다양한 캠페인에서 등장한 Terminator RAT입니다. Terminator는 다음과 같이 작동합니다.

1. 일반적으로 무기화된 Microsoft Word 문서를 이용하여 공격이 시작되는데, 이 문서를 열면 DW20.exe라는 악성 실행 파일이 설치됩니다.

2. DW20.exe는 “%UserProfile%\Microsoft”와 “%AppData%\2019”라는 2개의 작업 폴더를 생성합니다. “Microsoft” 폴더에는 Terminator의 구성과 실행 파일(svchost_.exe 및 sss.exe)이 저장되고 “2019” 폴더에는 관련 바로 가기 링크 파일이 저장됩니다.

3. 그런 다음 이 악성코드는 그림 19와 같이 다음 레지스트리 값을 수정하여 “2019”를 Windows의 시작 폴더로 설정합니다(이 폴더의 파일이 Windows 시작 시에 자동으로 실행됨): (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ Shell Folders\Startup).

4. DWE20.exe는 PC의 하드 드라이브에서 자신을 삭제하고 종료됩니다(그림 22 참조).

5. 컴퓨터가 재시작되어 현재 Windows 시작 폴더로 설정된 “2019” 폴더에 저장된 악성코드 바로 가기가 트리거된 후에만 악성코드가 활동을 개시합니다.12

그림 21: GetVolumeInformation 함수를 이용하여 파일 기반 샌드박스를 감지하는 코드.

11 Gunter Ollmann(Security Dark Reading). “Much Ado About PushDo(PushDo가 불러온 소동).” 2013년 5월. 12 FireEye. “Evasion Tactics by Terminator Rat(Terminator Rat의 회피 전술).” 2013년 10월.


그림 22: Terminator가 수정한 시작 폴더.

그림 23: 자신을 삭제하고 종료되는 DW20.exe.


환경이론적으로, 샌드박스에서 실행되는 코드는 물리적 컴퓨터에서와 같은 방식으로 실행되어야 합니다. 하지만 실제로는 대부분의 샌드박스가 명확한 특성을 띠기 때문에 공격자가 이 같은 가상 환경을 확인하는 기능을 악성코드에 포함할 수 있습니다. 이 섹션에서는 이 같은 확인 기능 몇 가지를 자세히 설명합니다.

버전 확인악성 코드 파일은 애플리케이션 또는 운영 체제의 특정 버전에서만 실행되도록 설정되는 경우가 많습니다. 이 같은 자체적인 제한은 딱히 샌드박스를 회피하기 위한 시도가 아닌 경우도 있습니다. 예를 들어 특정 애플리케이션 버전의 결함을 악용하려는 목적인 경우도 많습니다.

하지만 그 효과는 대체로 동일합니다. 모든 샌드박스에는 미리 정의된 구성이 있습니다. 일부 악성코드는 구성에 특정한 운영 체제와 애플리케이션의 조합이 없는 경우 탐지를 피하기 위해 실행되지 않습니다.

Flash그림 24에는 악성 Flash 다운로더의 ActionScript 코드가 나와 있습니다. 시스템에 설치된 Flash 플레이어의 버전 번호는 getUrl() 함수의 입력(변수 v)입니다. 이 코드는 특정 Flash 버전의 결함을 악용하기 위해 고위험 도메인에 대한 GET 요청을 실행하여 f.swf라는 악성 파일을 다운로드합니다.

샌드박스에 표적 버전이 설치되어 있지 않으면 악성 Flash 파일이 다운로드되지 않고 샌드박스에서 악의적인 활동이 탐지되지 않습니다.

그림 24: 버전 확인 기능이 있는 DW20.Malicious Flash 다운로더.


PDF그림 21의 JavaScript 코드는 비슷한 방식으로 app.viewerVersion()이라는 API 메서드를 이용하여 설치된 Acrobat Reader의 버전을 확인합니다. 이 코드는 시스템에 표적 버전(이 예의 경우 버전 6.0 이상)이 설치되어 있을 때에만 실행되고 일치하는 버전이 없는 샌드박스는 우회합니다.

GIF 및 Flash 파일에 내장된 iframe악성코드가 무해해 보이는 파일을 이용하여 방어를 뚫고 악성 페이로드를 다운로드하는 사례가 많습니다. 흔한 방법 중 하나는 GIF 사진이나 Acrobat Flash 같은 비실행 파일에 iframe HTML 요소를 숨기는 방법입니다.

이들 파일은 그 자체로는 실행되지 않기 때문에 샌드박스에서 의심스러운 동작을 보이지 않습니다. 대신 데이터를 숨기는 역할을 합니다. 이 데이터는 침해된 물리적 컴퓨터에 들어갈 때까지 기다리는 별도의 파일에 의해 “잠금 해제”되고 실행됩니다.

GIFGIF 그래픽 파일은 다음 요소로 이루어져 있습니다.

• 헤더

• 이미지 데이터

• 선택적 메타데이터

• 푸터(트레일러라고도 함)

푸터는 GIF 데이터 스트림의 끝을 나타내는 단일 필드 블록으로, 보통 값이 0x3B로 고정되어 있습니다. 악성 GIF 코드 파일에는 이 푸터 뒤에 iframe 태그가 추가되어 있는 경우가 많습니다.

FlashGIF 파일과 마찬가지로 Flash 파일도 악성 웹사이트의 iframe 링크를 숨길 수 있습니다. 그림 24에는 악성 iframe 요소가 포함된 Flash 파일 코드가 나와 있습니다.

Flash는 HTML 렌더링 엔진이 아니므로 샌드박스에서 Flash 파일을 열 때 숨겨진 iframe은 어떠한 동작도 실행하지 않습니다. 따라서 이 경우에도 샌드박스는 악의적인 동작을 탐지하지 못합니다.

그림 25: 버전 확인 기능이 있는 악성 Acrobat JavaScript 코드.

그림 26: GIF 파일의 악성 iframe 태그.


같은 방식으로, JPEG 파일도 파일 기반 샌드박스를 피해 잠복하는 데이터를 포함할 수 있습니다. 그림 25의 JPEG 데이터에는 파일의 교환 가능한 이미지 파일 형식(Exif) 헤더에 “eval(base64_decode)”이라는 문자열이 있습니다. 이는 PHP 스크립팅 명령이 숨겨져 있음을 시사하는 유력한 증거입니다.

통상적으로 PHP 명령 Exif_read_data는 이미지를 읽는데 사용됩니다. preg_ replace라는 다른 PHP 명령은 프로그래머가 문자열의 컨텐츠를 찾아 바꿀 수 있게 합니다. 하지만 preg_replace에는 단순히 검색하고 교체하는 대신 컨텐츠를 실행하는 옵션이 있습니다. (eval이라는 이 옵션은 명령 수정자 “/e/”로 트리거됩니다.) 공격자는 이 eval 함수를 사용하여 침입한 웹사이트에서 JPEG 헤더에 숨겨진 악성 PHP 명령을 실행할 수 있습니다.

그림 27: Flash 파일의 악성 iframe 태그.

그림 28: eval 및 base 64가 있는 JPG.


일반적으로 파일 기반 샌드박스는 파일 뷰어 또는 웹 브라우저에서 JPEG 파일을 엽니다. 샌드박스에서는 숨겨진 코드를 실행할 PHP 명령이 없으므로 JPEG 파일이 악의적인 동작을 보이지 않습니다.

GIF, PNG 이미지 파일에 내장된 실행 파일iframe 태그를 포함하는 방법 외에 GIF, PNG 등의 이미지에도 숨겨진 실행 파일이 저장될 수 있습니다. 그림 29에는 제로데이 공격에서 2단계 다운로더로 사용된 gif 파일이 나와 있습니다. 이 gif 파일에는 싱글 바이트 xored 실행 파일이 있습니다. 이 실행 파일을 복호화하는 키는 0x75입니다.

그림 26.0에서 볼 수 있듯이, “21 1D 1C 06 55”는 0x75가 설정된 “This” xored를 나타냅니다. 0x75 키는 “dos 모드에서는 이 파일을 실행할 수 없음”을 나타내는 문자열로 실행 파일 헤더에서 흔히 볼 수 있습니다.

이 이미지 파일이 파일 기반 샌드박스로 옮겨지면 샌드박스는 이미지 뷰어 또는 웹 브라우저에서 이 파일을 엽니다. 숨겨진 실행 파일은 웹 브라우저 또는 이미지 뷰어에서 실행되지 않으므로 샌드박스에서는 악의적인 동작이 포착되지 않고 파일은 문제가 없는 것으로 간주됩니다.

DLL 로더 확인일반적으로 동적 링크 라이브러리(DLL) 파일을 실행하려면 run32dll.exe를 사용하거나 이를 실행하는 프로세스에서 DLL을 로드해야 합니다. 일부 악성코드는 다른 프로세스를 사용함으로써 DLL을 실행하기 위해 특정 로더가 필요하도록 합니다. 필요한 로더가 없으면 DLL이 실행되지 않고 샌드박스에서 악성코드가 탐지되지 않습니다.

그림 29에는 로더의 해시를 계산하여 필요한 로더인지를 확인하는 악성코드가 나와 있습니다.

그림 29: 싱글 바이트 xored 실행 파일이 있는 이미지.


VMware 회피 기법이 보고서에서 지금까지 설명한 샌드박스 회피 기법들은 지능형 악성코드와 APT의 전형적인 형태라고 할 수 있습니다. 하지만 FireEye의 원격측정 데이터를 보면 몇몇 전통적인 회피 기법도 악성코드 작성자들이 여전히 유용하게 이용하고 있는 것으로 나타납니다.13 널리 사용되는 가상 머신 툴인 VMware는 독특한 구성 때문에 감지하기가 특히 쉽습니다.

시스템 서비스 목록VMware로 생성된 샌드박스의 존재를 감지하기 위해 일부 악성코드는 vmicheatbeat, vmci, vmdebug, vmmouse, vmscis, VMTools, vmware, vmx86, vmhgfs, vmxnet 등 VMware의 고유한 서비스를 확인합니다.

그림 30: 로더의 해시를 계산하는 악성코드.

11 Virus Bulletin. “Techniques for Evading Automated Analysis(자동화된 분석을 회피하는 기법).” 2013년 2월


그림 31의 코드는 RegOpenKeyExA() 함수를 사용하여 VMware 가상 머신에 사용되는 서비스가 있는지 확인합니다. RegOpenKeyExA() 함수가 성공적으로 실행되면 0이 아닌 오류 코드가 값으로 반환됩니다.

고유 파일악성코드가 VMware로 생성된 샌드박스에서 실행되고 있음을 보여주는 다른 증거로, VMware 전용 파일의 존재를 들 수 있습니다. 그림 32에는 GetFileAttributeA() 함수를 사용하여 VMware 마우스 드라이버의 존재를 확인하는 악성코드가 나와 있습니다.

GetFileAttributeA() 함수는 지정된 파일 또는 디렉토리의 시스템 특성을 검색합니다. 이 함수가 실행된 후 cmp eax 코드 0FFFFFFFh가 반환된 값이 –1인지 확인합니다. -1 값은 함수가 vmmouse.sys 파일의 특성을 검색할 수 없음을 나타냅니다. 이는 해당 파일이 시스템에 없음을 의미하고 따라서 코드가 VMware 환경에서 실행되고 있지 않음을 의미합니다.

그림 31: RegOpenKeyExA() 함수를 사용하여 VMware 툴이 있는지 확인하는 악성코드.

그림 32: GetFileAttributeA( )를 사용하여 VMware 마우스 드라이버의 존재 유무를 확인하는 악성코드.


VMX 통신 포트또 다른 명백한 증거로, VMware가 가상 머신과 통신하는 데 사용하는 VMX 포트가 있습니다. 이 포트가 있으면 악성코드는 “잠복”하면서 탐지를 피합니다. 그림 33에는 이 포트를 확인하는 악성코드가 나와 있습니다.

이 코드는 다음과 같이 작동합니다.

1. move eax 명령, ‘VMXh’가 EAX 레지스터에 0x564D5868이라는 값을 로드합니다.

2. EBX는 임의의 값을 사용하여 로드됩니다.

3. ECX는 VMware 버전을 검색하도록 0Ah로 설정됩니다.

4. Register DX는 port VX로 설정되어 VMware와의 통신을 활성화합니다.

5. 이 코드는 eax의 명령 dx를 호출하여 포트로부터 EAX로 데이터를 읽습니다. 이 코드가 VMware 환경에서 실행 중인 경우 호출이 성공합니다. 그러면 탐지를 피하기 위해 악성코드가 실행되지 않습니다.

그림 33: 입출력 포트를 이용하여 VMware를 감지하는 악성코드.


표 1. 다양한 샌드박스 회피 기법을 탐지하는 샌드박스의 기능 비교.

사람의 개입 Flash/JPG 파일에 내장된 iframe 슬립 콜 버전 확인 전용 프로세스 통신 포트 확인

샌드박스 1에서 탐지 여부 아니요 아니요 예 아니요 예 예

샌드박스 2에서 탐지 여부

후크를 식별했지만 동작을 놓침 아니요 예 아니요 예 예

샌드박스 3에서 탐지 여부 예 아니요 예 아니요 예 예

공개적으로 사용 가능한 샌드박스 비교표 1에서는 파일 기반 샌드박스를 통해 악성코드를 탐지하는 세 가지 유명 온라인 악성코드 분석 서비스를 비교합니다. 탐지율은 서로 다르지만 이들 무료 서비스는 샌드박스 회피 기법을 이용하는 몇 가지 악성코드를 포착했습니다. 하지만 모든 기법을 인식한 서비스는 없었으며, 세 가지 서비스 모두 버전 확인 및 내장된 iframe을 이용하는 악성코드는 놓쳤습니다. (해당 파일은 FireEye Multi-Vector Virtual Execution™(MVX) 엔진, 정적 검사 및 콜백 모니터링을 함께 사용하여 탐지되었습니다.)


맺음말파일 기반 샌드박스에서 지능형 공격이 완벽하게 탐지되지는 않습니다. 가상화가 파일 동작을 관찰하는 유용한 툴이기는 하지만 여러 가지 툴 중 하나일 뿐입니다. 악성코드는 대부분의 보안 벤더가 사용하는 규격화된 샌드박스에서 실행 중인지를 스스로 손쉽게 감지하여 결과에 따라 동작을 제한할 수 있습니다.

오늘날의 지능형 위협을 탐지하려면 위협 차단에 대한 보다 종합적인 접근 방식이 필요합니다. VM 환경은 공격의 다중 흐름 분석을 통해 공격의 정황을 분석하는 더 광범위한 플랫폼의 일부여야 합니다. 동작 기반 기법과 정적 분석 기법의 조합과 개별 공격이 어떻게 유기적으로 작용하는지에 대한 심층적인 지식을 함께 활용하면 허점을 해소하는 데 도움이 됩니다.

일반적인 샌드박스에서 탐지하지 못하는 위협을 FireEye MVX 엔진이 어떻게 탐지하는지 알아보려면 FireEye 웹사이트 (http://www.fireeye.com/products-and-solutions/ virtual-execution-engine.html)를 참조하십시오.

FireEye Korea 서울 특별시 강남구 테헤란로 534 글라스타워 20층 02.2092.6580 [email protected]

FireEye에 대한 자세한 정보: www.FireEye.com

FireEye, Inc. 소개 FireEye는 인텔리전스 기반의 보안 회사입니다. FireEye는 혁신적인 보안 기술, 국가 수준의 위협 인텔리전스 및 세계적으로 유명한 Mandiant® 컨설팅을 결합한 단일 플랫폼을 제공하여 고객 보안 운영의 완벽한 확장을 지원합니다. 이를 통해 FireEye는 사이버 공격에 대비하고 이를 방어 및 대응하고자 노력하는 조직의 사이버 보안 부담을 줄이고 간소화합니다.

©2019 FireEye, Inc. 저작권 소유. FireEye는 FireEye, Inc.의 등록상표입니다. 다른 모든 브랜드, 제품 또는 서비스 명칭은 각 소유자의 상표 또는 서비스 마크입니다. F-EXT-RT-US-EN-000227-01

백서 기반 샌드박스를 - fireeye...그림 8의예제악성코드에서는 getcursorpos에서...

Documents