특정 환경에서만 동작하는 새로운 동적 분석 우회 기법

ASEC 분석팀은 활발하게 유포되고 있는 악성코드들을 모니터링하던 중 새로운 형태의 동적 분석 우회 기법을 확인하였다. 최근 다수 유포되고 있는 악성코드들은 진단을 회피하기 위한 목적으로 악성코드 실행 환경을 확인 후 조건에 부합하면 Crash를 발생시켜 동작하지 않도록 한다.

 

이번에 소개될 기법은 특정 어셈블리 명령어를 사용하는 방법과 사이즈가 큰 메모리를 할당 가능한지에 대한 여부를 확인하는 방법이다.

 

1.     AVX 지원 여부(VXORPS 명령어)

‘VXORPS’ 명령어를 사용하여 AVX를 지원하지 않는 환경에서 동작하는 경우 Crash가 발생하는 악성코드는 주로 Visual Basic으로 만들어진 악성코드다. 최근에 소개된 ‘국내 기업을 사칭하여 이메일로 유포되는 Visual Basic 악성코드’ 블로그 글(https://asec.ahnlab.com/1286)에서도 언급된 것처럼 최근 유포되는 악성코드 중 Visual Basic을 활용한 악성코드들이 많다.

국내 기업을 사칭하여 이메일로 유포되는 Visual Basic 악성코드

 

[ 그림  1.] Crash 가 발생하는  AVX  명령어 (VXORPS)

 

이 ‘VXORPS’ 명령어는 AVX(Advanced Vector eXtensions) 명령어 셋에 포함된 것으로, 부동소수점을 이용한 XOR 논리 연산자다. 해당 명령어를 CPU가 처리하기 위해선 AVX 명령어 셋을 지원하는 CPU 및 OS를 사용해야 한다.

 

AVX를 지원하지 않는 환경이라면 악성코드를 실행했을 때 아래 [그림 2.]와 같이 Illegal instruction으로 인해 Crash가 발생한다.

 

[ 그림  2.] AVX 가 지원되지 않는 환경에서 실행 시 화면

 

동적 분석 장비에서는 다양한 취약점을 발생시키기 위해 의도적으로 보안 업데이트를 하지 않은 구 버전의 환경으로 구성하는 경우가 있으며, 이로 인해 특정 기술들이 지원되지 않는 환경일 수 있다. 이러한 환경에서는 해당 명령어가 포함된 샘플들이 실행될 때 AppCrash 로 악성코드가 동작하지 않아 동적 분석이 우회된다.

 

2011년도 이후 만들어진 대부분의 CPU는 해당 명령어 셋을 지원하며, 지원되는 주요 OS로는 [표 1.]과 같다.

운영체제	지원 버전
Windows	Windows 7 SP1, Windows Server 2008 R2 SP1, Windows 8, Windows 10 에서 지원
Linux	커널 버전 2.6.30 이후 지원
macOS	10.6.8(Snow Leopard) 업데이트 이후 지원

[표 1.] AVX를 지원하는 주요 OS

 

현재 사용하고 있는 환경의 AVX 지원 여부를 확인하려면 Windows Sysinternals에서 제공하는 Coreinfo 툴을 통해 확인할 수 있다.

(https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo)

Coreinfo - Windows Sysinternals

[ 그림  3.] Coreinfo  결과  AVX  미지원 (-)

[ 그림  4.] Coreinfo  결과  AVX  지원 (*)

 

2.     메모리 할당 가능 여부

 

[ 그림  5.] VirtualAlloc() API 의 메모리 할당 크기가 약  1GB

해당 기법은 VirtualAlloc() API를 이용해 0x3B9AC00(대략 1GB)만큼의 메모리를 할당한다. 만약 해당 크기를 할당하지 못하면 잘못된 주소를 참조하게 만들어 강제로 Crash를 발생시킨다.

 

우선 일반적인 동적 분석 환경(Sandbox)의 경우 한 컴퓨터 안에서 다수의 가상 머신(VM)을 동시에 구동하기 때문에 많은 자원을 필요로 한다. 그래서 리소스를 가상 머신(VM)마다 적절하게 분배해야만 가장 높은 효율을 발휘할 수 있으며, 이 과정에서 보통 RAM의 크기는 악성코드 동작할 수 있을 정도로만 할당한다.

 

그러기 때문에 1GB 이하로 할당하는 경우가 많으며, 해당 악성코드는 이러한 부분을 고안한 것이다. 메모리 크기를 확인하는 방법과 유사한 기법은 이전에도 소개된 적이 있다.

https://asec.ahnlab.com/1147

 

새롭게 등장한 GandCrab v4.2 (안티VM + RigEK)

여기서는 컴퓨터의 CPU나 디스크의 용량을 확인하였다. 이러한 악성코드를 동작하기 위해서는 충분한 RAM을 할당하거나 윈도우에서 지원하는 가상 메모리를 활용하면 동작이 가능하다.

 

[ 그림  6.]  윈도우의 가상 메모리 설정 ( 페이징 파일 )

 

해당 기능을 사용하면 VM에 256MB정도의 적은 RAM 크기를 할당하였더라도, 프로세스에 1GB 이상의 메모리 공간을 할당 받을 수 있어 동적 분석이 가능하다.

 

 

[ 그림  7.]  자사 동적 분석 머신 (RAPIT) 의 동적 분석 결과 중 일부

 

자사 동적 머신인 RAPIT의 결과([그림 7.] 참조)를 확인해보면 악성코드는 해당 기법 이후에 svchost.exe에 인젝션 및 시간 지연 기능이 있으며, 특정 C2서버와 통신하는 NetWiredRC Backdoor인 것을 확인할 수 있다.

 

3.     결과

과거, 악성코드는 실행되는 환경을 검사해 VM이거나 Sandbox임이 감지된다면, 바로 종료하는 방식을 사용했었다. 그러나 최근에는 분석 환경임이 감지되면 강제로 Crash를 발생시켜, 원인 파악에 시간을 소비하게 만든다.

 

Crash는 손상 파일인 경우에도 발생할 수 있지만, 위와 같은 기법으로 Crash가 발생한 경우 악성코드 내부에서 문제를 일으킨 코드를 찾아야 하며, 해결 방법을 모색해 가상 머신을 수정해야 한다. 이뿐만 아니라 이전에 소개된 방법과 같이(https://asec.ahnlab.com/1202)

GandCrab v5.2 랜섬웨어에서 사용된 동적분석 우회기법

가상 머신의 설계 문제까지 이어지면 더 많은 시간을 허비하게 되어 동적 분석의 효율이 떨어지게 된다.

 

 

[ 그림  8.]  환경을 탐지하는 악성코드의 동작 흐름

 

더 나아가 흔히 알려진 Cuckoo Sandbox의 경우 모니터링 프로세스를 대상으로 Crash를 일으키는 방법도 존재하기 때문에 앞으로도 다양한 우회 기법이 나올 것으로 보인다.

(https://github.com/David-Reguera-Garcia-Dreg/anticuckoo)

David-Reguera-Garcia-Dreg/anticuckoo

 

현재 안랩에선 해당 악성코드를 아래와 같은 진단명으로 진단하고 있다.

• Trojan/Win32.Inject (2020.02.20.00)
• Malware/Win32.RL_Gerneric (2020.02.14.00)