매그니베르 랜섬웨어의 변화, 무엇을 노리나
매그니베르 랜섬웨어(Magniber Ransomware)의 움직임이 심상치 않다. 2017년 중반 국내에 유입된 매그니베르 랜섬웨어는 2018년 4월 폭발적으로 증가했다. 그렇게 정점(?)을 찍은 것도 잠시, 안랩이 복구 툴을 배포하는 등 발 빠르게 대응하면서 급격히 세력이 약해졌다. 그러나 매그니베르 랜섬웨어가 활동을 중단한 적은 없다. 파괴력은 그때만하지 못하지만 이후에도 지속적으로 유포되며 피해를 입혀왔다. 그런데 최근 매그니베르 랜섬웨어의 공격 방식이 빠르게 변화하기 시작했다. 취약점 변경부터 쉘코드 변화까지, 최신 매그니베르 랜섬웨어의 움직임을 상세히 살펴본다.

매그니베르 랜섬웨어는 대표적인 파일리스(Fileless) 형태의 악성코드로, 웹브라우저 취약점을 이용하는 매그니튜드 익스플로잇킷(Magnitude Exploit Kit)을 통해 웹사이트에 접속하면 감염되는 방식으로 유포된다. 국내에서는 주로 인터넷 익스플로러(Internet Explorer, 이하 IE) 웹브라우저의 취약점을 이용한다.
최근 바이러스 토탈(Virus Total)에 IE 취약점인 CVE-2019-1367를 이용한 매그니베르 랜섬웨어의 PoC가 공개되었으며, 매그니튜드 익스플로잇킷도 해당 취약점을 이용하는 것이 확인되었다. CVE-2019-1367 취약점은 IE의 스크립트 엔진인 jscript.dll에서 발생하는 취약점으로, 구글 위협 분석 그룹이 최초로 제보했다. 마이크로소프트는 2019년 10월 해당 취약점에 대한 보안 업데이트를 배포했다.
안랩은 지난 2017년이후 지속적으로 매그니베르 랜섬웨어를 모니터링하며 유포 코드가 지속적으로 변경되는 것을 확인했다. 특히 2019년 9월부터 2020년 2월 현재까지 변화가 계속되고 있다. 쉘코드의 API 인자를 변경하거나 [그림 1], [그림 2]에서 볼 수 있는 것처럼 랜섬웨어를 인젝션하는 프로세스를 변경하기도 했다. 그러나 이는 상대적으로 작은 변화에 불과한 것으로, 올해 2월에는 유포에 이용하는 취약점 자체를 바꿨다. 지금까지의 소소한 변화와 달리 취약점 변경이라는 변화를 택한 것은 랜섬웨어 프로세스를 은닉하고 백신(Anti-virus) 등 보안 솔루션의 탐지를 우회하기 위한 것으로 짐작할 수 있다.
공격 방식의 변화
지난 2월 확인된 매그니베르 랜섬웨어의 취약점 변경과 이에 따른 공격 프로세스의 흐름 변화를 먼저 살펴보자. [그림 4]는 최신 매그니베르 랜섬웨어 유포 사이트에 접속했을 때 전달되는 HTML 스크립트로, 취약점 변경 이전과 이후 모두 인코딩되어 있다.
인코딩된 스크립트를 디코딩하면 [그림 5]와 같이 CVE-2019-1367 취약점을 익스플로잇하는 스크립트를 확인할 수 있다. 현재 매그니튜드 익스플로잇킷이 유포하는 CVE-2019-1367 스크립트는 기존과 마찬가지로 변수명과 쉘코드를 난독화하는 기법을 사용하고 있다. 여기에서 주목할만한 변화는 이전에 이용하던 IE의 비주얼 베이직 스크립트(Visual Basic Script, VBS) 엔진 취약점(CVE-2018-8174) 대신 자바스크립트(Java Script, JS) 엔진 취약점(CVE-2019-1367)을 사용했다는 점이다.
CVE-2019-1367 취약점 분석
CVE-2019-1367 취약점은 자바스크립트 어레이(Array) 객체의 콜백 함수인 Sort 메소드에서 가비지 콜렉터가 아규먼트(argument) 객체, 즉 Sort 메소드에 전달된 인수를 해제(Free)하지 못하여 발생하는 UAF(Use After Free) 취약점이다.
[그림 6]은 매그니튜드 익스플로잇킷의 CVE-2019-1367 취약점 관련 스크립트 일부를 디코딩한 것으로, 이 취약점이 발생하는 근본적인 원인을 설명하기 위해 순서대로 번호를 표시하였다.
먼저 해당 스크립트 코드가 실행되면 (1)u 배열 객체의 sort 메소드에 의해 UAF 콜백 함수가 호출된다. 이후(2)콜백 함수에서 아규먼트 객체가 t 배열 객체에 저장되고 (3)UAF 취약점을 위해 미리 많은 양의 스프레이(spray) 객체가 할당된다.
(4)에서 t 객체가 p 객체를 참조하고 (5)이후에 p 객체는 spray 객체와 함께 가비지 콜렉터에 의해 메모리 해제 상태가 된다. 그러나 가비지 콜렉터는 아규먼트 객체를 해제하지 못하였으므로 결과적으로 t 객체(arguments)는 댕글링 포인터(Dangling Pointer)가 된다. 이 과정을 요약하면 [그림 7]과 같다.
[그림 7]의 (6)에서 v 객체의 B 프로퍼티(Property)에 1을 할당함으로써 p 객체가 존재하고 있던 기존 해제된 메모리 영역이 특별히 조작된 값으로 덮어 씌워진다. 이때 해제된 p 객체 주소에는 타입 컨퓨전(Type Confusion)으로 인하여 변수 타입(Variant Type)이 정수형(0x03)인 정규 표현식 객체가 저장된다. 정상적으로 정규 표현식 객체의 변수 타입은 0x03이 아닌 0x81이 되어야 한다. [그림 8]은 타입 컨퓨전에 의해 변수 타입이 변경된 메모리의 모습이다. 마지막으로 (7)에서 t 객체를 q 객체에 저장하여 이후 메모리 조작한다.
공격자는 CVE-2019-1367 취약점을 통해 실행하고자 하는 악성 쉘코드 영역(메모리)에 실행 속성을 부여하고, 실행 흐름을 쉘코드로 분기시킨다. 또한 공격자는 [그림 9]와 같이 짧은 기간 동안 메모리의 속성을 부여하는 API인 VirtualProtect 함수의 인자 값을 변경했다. 이는 V3의 행위 기반 탐지 기술을 우회하기 위한 것으로 보인다.
쉘코드 분석
악의적인 쉘코드의 첫 번째 역할은 랜섬웨어 페이로드를 다운로드하는 것으로, 관련 코드는 [그림10]과 같다. 이런 방식을 통해 랜섬웨어가 시스템에 파일 형태로는 생성되지 않고 IE 프로세스 메모리 영역에 인코딩된 형태로 존재하게 된다.
쉘코드의 두 번째 역할은 랜섬웨어를 디코딩하는 것으로, [그림 11]의 코드에서 볼 수 있는 것처럼 별도 제작한(customized) XOR 방식을 사용하고 있다. 다운로드되는 페이로드의 크기에 영향 받는 변수만 변경될 뿐 공격자는 해당 디코딩 방식을 계속 사용하고 있다.
현재 유포되고 있는 쉘코드의 세 번째 기능은 실행 중인 사용자 프로세스에 랜섬웨어를 인젝션(Injection)하는 것으로, 이렇게 인젝션된 프로세스가 파일 암호화 행위를 수행한다. 이는 가장 최근에 확인된 변화로, [그림 12]에서 볼 수 있는 것처럼 안랩의 V3 관련 프로세스인 ASDSvc.exe가 존재할 경우 자기 자신의 프로세스에 인젝션하는 것을 생략하는 코드가 추가되어 있다. 이 역시 V3의 탐지를 피하기 위한 목적으로 짐작할 수 있다.
망설임 없는 매그니베르 랜섬웨어 공격, 예방법은?
해당 보고서를 통해 매그니베르 랜섬웨어의 유포 과정의 변화를 설명하였다. 최근 가장 주목할 만한 변화는 유포 취약점이 새롭게 변경되었다는 점이다.
- AhnLab분석팀 오민택 연구원, 한명욱 연구원